Author Archives: Smitha Iddalgave
Activity 1: ISO 9001 and ISO 9126 clauses suitable for this case study:
Clause 4: Quality Management System
- The company must define its processes and show the sequence and interaction of these processes. (This can be done using process mapping or process flow charts.)
- Determine the testing and documentation needed.
- Documentation is less restrictive and the company can determine most of the documentation they require.
Clause 6: Resource Management
- The organization must determine basic competence for employees, hire to meet the competencies, provide training, and determine effectiveness of training.
- The organization must identify, provide and maintain the facilities it needs to achieve conformity of product including: workspace and associated facilities; equipment, hardware and software; and supporting services.
- The organization must identify and manage the work environment with consideration of the human and physical factors needed to achieve conformity of product.
Clause 7: Product Realization
- Planning: The organization needs to plan the activities leading to your product.
- The organization must determine customer requirements including those product requirements not specified by the customer but necessary for intended product use and regulatory and legal requirements.
- Must determine and keep records of the review of contracts or orders.
- The organization must plan and implement customer communications processes including product information, inquiries, order handling/contracts and amendments and customer feedback.
- Design and Development
- There are very specific requirements and records required for design and development planning, inputs, outputs, review, verification, validation and changes.
- The organization must determine criteria for evaluation, selection and re-evaluation of suppliers.
- There are requirements for purchasing information and requirements for verification of purchased product.
- Production and Service Provision: Determine the controls necessary to provide your product including any process validation, identification and traceability, customer property, and preservation of product.
- Control of measuring devices: Determine measuring devices and calibrate according to the standard requirements.
Clause 8: Measurement, Analysis and Improvement
- Collect data to provide information on customer satisfaction and dissatisfaction and conformance to customer requirements. These methods shall confirm the continuing ability of each process to satisfy its intended purpose.
- Audit your quality management system according to the requirements.
- Monitor your processes to ensure they are operating effectively.
- At appropriate stages of the product realization process, the organization must measure and monitor the characteristics of the product to verify that requirements are met.
- Collect and analyze data in order to provide a consistent product and improve the effectiveness of your quality management system.
- The organization must facilitate the continuous improvement of the quality management system through the use of the quality policies, objectives, audit results, data analysis, corrective and preventive actions, and management review.
- Fix your problems. Establish corrective and preventive action processes to determine and fix problems and potential problems. Determine root cause, fix the problem and check that the fix was appropriate and successful.
Activity 2: Software Configuration Management:
Software Configuration Management (SCM) provides a mechanism for identifying, controlling and tracking the versions of each software item. In many cases earlier versions still in use must also be maintained and controlled.
The procedures involved in SCM are
- Configuration Identification
- Configuration Control
- Configuration Status Accounting
- Configuration auditing
- Build Management
- Process Management
- Environment Management
- Defect Tracking
The procedures used in this case study are:
System building: System building involves assembling a large amount of information about the software and its operating environment.
Change Management: CM involves assessing proposals for changes from system customers and other stakeholders and deciding if it is cost-effective to implement these in a new version of a system.
Process Management: PM ensures the carrying out of the organization’s procedures, policies and life cycle model.
Status Accounting: Recording and reporting all the necessary information on the status of the development process.
Auditing: Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals.
Release Management: RM involves preparing software for external release and keeping track of the system versions that have been released for customer use.
Version Management: VM is the process of keeping track of different versions of software components or configuration items and the systems in which these components are used
Activity 3: Testing- reliability, compatibility, maintainability, usability, affordability
Reliability: For reliability we need to test for consistency, accuracy and error tolerance.
Maintainability: For maintainability we need to test for simplicity, conciseness, Instrumentation, self-descriptiveness.
Usability: For usability we need to test for simplicity and how easy it is for users to access it and perform some activities on it without much prior knowledge about the system.
Compatibility: for compatibility we need to test for machine independence like the memory usage limit, generality, modularity.
Affordability: For affordability we need to check how much does it cost to recover from a failure in terms of cost for system downtime, cost for repair.
Description of Test cases:
While testing a web application you need to consider following Cases:
• Functionality: In testing the functionality of the web sites the following should be tested:
i. Internal Links
ii. External Links
iii. Mail Links
iv. Broken Links
i. Field validation
ii. Error message for wrong input
iii. Optional and Mandatory fields
• Database: * Testing will be done on the database integrity.
• Cookies: * Testing will be done on the client system side, on the temporary Internet files.
Performance : Performance testing can be applied to understand the web site’s scalability, or to benchmark the performance in the environment of third party products such as servers and middleware for potential purchase.
• Connection Speed:Tested over various networks like Dial Up, ISDN etc
i. What is the no. of users per time?
ii. Check for peak loads and how system behaves
iii. Large amount of data accessed by user
i. Continuous Load
ii. Performance of memory, CPU, file handling etc..
Usability: Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction.
• Ease of learning
• Subjective user satisfaction
• General appearance
Server Side Interface: In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.
Client Side Compatibility:
The client side compatibility is also tested in various platforms, using various browsers etc.
Security: The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them.
• Network Scanning
• Vulnerability Scanning
• Password Cracking
• Log Review
• Integrity Checkers
• Virus Detection
In Aspect oriented programming, we break program logic into the so called concerns. This paradigm can mainly be used when there is a single requirement that has to be implemented in multiple modules/components. The key benefit of Aspect Oriented Programming is they provide separation of concerns. That means each element(method, class) in a program does one thing and only one thing. Concerns might be different to different stakeholders, it is not right to assume that all the stakeholders of particular system can have same concern. Hence, it can be defined as “Something that is of interest or significance to a stakeholder or a group of stakeholders.”
These concerns can be divided into core concerns and cross-cutting concerns.
- Core concerns : These are the functional concerns that relate to its primary purpose.
- Cross-cutting concerns : These are the concerns which effect other concerns. These can not be clearly decomposed from the rest of the system. The cross-cutting concerns give rise to tangling and scattering. Tangling occurs when a module in a system included some code that implements different system requirements.
The aim of Aspect oriented programming is to encapsulate(group) these cross cutting concerns into a single aspect. Hence, aspect is a common feature in a system that is scattered across methods, classes etc..The aspect also tells where the requirement it describes has to be included in the system i.e. the location where the particular cross cutting concern has to be executed in the program.
Below are certain terminologies that are commonly used and are basics to understand the aspect oriented programming.
Advice : The code implementing a concern.
Aspect : A program abstraction that defines a cross-cutting concern. It includes the definition of a pointcut and the advice associated with that concern.
Join Point : An event in an executing program where the advice associated with an aspect may be executed.
Pointcut : A statement, included in the aspect, that defines the join points where the associated aspect advice should be executed.
Weaving : The incorporation of advice code at the specified join point by an aspect weaver.
Aspect Weaver: These are extensions to compilers that process the definition of aspects and the object classes and methods that define the system.
Consider an example:
A medical records system such as the MHC-PMS includes components that handle logically related patient information. The patient component maintains personal information about a patient, the medication component holds information about medications that may be prescribed, and so on. This organization requires that information in the database has to be updated from a number of different places in the system. For example, patient information may be modified when their personal details change, when their assigned medication changes, when they are assigned to a new specialist, etc. For simplicity consider all the database update methods begin with update* keyword.
updatePersonalInformation (patientId, infoupdate)
updateMedication (patientId, medicationupdate)
All the updates are made by hospital staff, who are logged into the system. Suppose a security breach occurs , i.e., a hospital staff accidentally left his/her system logged on and an unauthorized person makes some malicious changes to patient database. In order to avoid this the organization might decide to include some security features such as reauthenticating the use before making any updates to database and logging the details of who made made the changes in a separate file.
- One way of implementing this new policy is to modify the update method in each component to call other methods to do the authentication and logging. This will result in tangled implementation as the authentication and logging are two different concerns, these might be implemented at different places in the system.
- Alternatively, the system could be modified so that each time an update method is called, method calls are added before the call to do the authentication, and then after to log the changes made. This will result in scattered implementation as the same code has to be included at several different places in the system.
Here, authentication and logging from the cross-cutting concerns which cut across the core concerns of the system and may have to be included in several different places. Hence these can be written as two separate aspects in AOP.
before: call (public void update* (..)) // this is a pointcut
// this is the advice that should be executed when woven into the executing system
int tries = 0 ;
string userPassword = Password.Get ( tries ) ;
while (tries < 3 && userPassword != thisUser.password ( ) )
// allow 3 tries to get the password right
tries = tries + 1 ;
userPassword = Password.Get ( tries ) ;
if (userPassword != thisUser.password ( )) then
//if password wrong, assume user has forgotten to logout
System.Logout (thisUser.uid) ;
} // authentication
In this example,
Pointcut : before: call (public void update* (..))
Tells before executing every update method the advice, for reauthenticating, in the aspect has to be executed.
Advice : In this case, the advice gets a password from the person requesting the change and checks that it matches the password of the currently logged-in user. If not, the user is logged out and the update does not proceed.
Weaving: The inclusion of advice at the join points specified in the pointcuts is the responsibility of an aspect weaver. This is shown in below diagram. The weaver then generates a new program with the aspects included at the specified join points such that the cross-cutting concerns are executed at the right places in the final system.
There are three different approaches to aspect weaving:
1. Source code pre-processing, where a weaver takes source code input and generates new source code in a language such as Java or C++, which can then be compiled using the standard language compiler.
2. Link time weaving, where the compiler is modified to include an aspect weaver.
3. Dynamic weaving at execution time. In this case, join points are monitored and when an event that is referenced in a pointcut occurs, the corresponding advice is integrated with the executing program.
The most commonly used approach to aspect weaving is link time weaving, as this allows for the efficient implementation of aspects without a large run-time overhead. Dynamic weaving is the most flexible approach but can incur significant performance penalties during program execution. Source code pre-processing is now rarely used.
Below are few quality models from the so called Quality Management Gurus.
McCall’s Quality model (1977)
Also called as General Electrics Model. This model was mainly developed for US military to bridge the gap between users and developers. It mainly has 3 major representations for defining and identifying the quality of a software product, namely
Product Revision : This identifies quality factors that influence the ability to change the software product.
(1) Maintainability : Effort required to locate and fix a fault in the program within its operating environment.
(2) Flexibility : The ease of making changes required as dictated by business by changes in the operating environment.
(3) Testability : The ease of testing program to ensure that it is error-free and meets its specification, i.e, validating the software requirements.
Product Transition : This identifies quality factors that influence the ability to adapt the software to new environments.
(1) Portability : The effort required to transfer a program from one environment to another.
(2) Re-usability : The ease of reusing software in a different context.
(3) Interoperability: The effort required to couple the system to another system.
Product Operations : This identifies quality factors that influence the extent to which the software fulfills its specification.
(1) Correctness : The extent to which a functionality matches its specification.
(2) Reliability : The systems ability not to fail/ the extent to which the system fails.
(3) Efficiency : Further categorized into execution efficiency and storage efficiency and generally means the usage of system resources, example: processor time, memory.
(4) Integrity : The protection of program from unauthorized access.
(5) Usability : The ease of using software.
McCall’s Quality Model
Boehm’s Quality model (1978):
Boehm’s model is similar to the McCall Quality Model in that it also presents a hierarchical quality model structured around high-level characteristics, intermediate level characteristics, primitive characteristics – each of which contributes to the overall quality level.
The high-level characteristics represent basic high-level requirements of actual use to which evaluation of software quality could be put – the general utility of software. The high-level characteristics address three main questions that a buyer of software has:
• As-is utility : How well (easily, reliably, efficiently) can I use it as-is?
• Maintainability: How easy is it to understand, modify and retest?
• Portability : Can I still use it if I change my environment?
The intermediate level characteristic represents Boehm’s 7 quality factors that together represent the qualities expected from a software system:
• Portability (General utility characteristics): Code possesses the characteristic portability to the extent that it can be operated easily and well on computer configurations other than its current one.
• Reliability (As-is utility characteristics): Code possesses the characteristic reliability to the extent that it can be expected to perform its intended functions satisfactorily.
• Efficiency (As-is utility characteristics): Code possesses the characteristic efficiency to the extent that it fulfills its purpose without waste of resources.
• Usability (As-is utility characteristics, Human Engineering): Code possesses the characteristic usability to the extent that it is reliable, efficient and human-engineered.
• Testability (Maintainability characteristics): Code possesses the characteristic testability to the extent that it facilitates the establishment of verification criteria and supports evaluation of its performance.
• Understandability (Maintainability characteristics): Code possesses the characteristic understandability to the extent that its purpose is clear to the inspector.
• Flexibility (Maintainability characteristics, Modifiability): Code possesses the characteristic modifiability to the extent that it facilitates the incorporation of changes, once the nature of the desired change has been determined.
The lowest level structure of the characteristics hierarchy in Boehm’s model is the primitive characteristics metrics hierarchy. The primitive characteristics provide the foundation for defining qualities metrics – which was one of the goals when Boehm constructed his quality model. Consequently, the model presents one more metrics supposedly measuring a given primitive characteristic.
Though Boehm’s and McCall’s models might appear very similar, the difference is that McCall’s model primarily focuses on the precise measurement of the high-level characteristics “As-is utility”, whereas Boehm’s quality model is based on a wider range of characteristics with an extended and detailed focus on primarily maintainability.
Dromey’s Quality model(1995):
Dromey has built a quality evaluation framework that analyzes the quality of software components through the measurement of tangible quality properties. Each artifact produced in the software life-cycle can be associated with a quality evaluation model. Dromey gives the following examples of what he means by software components for each of the different models:
• Variables, functions, statements, etc. can be considered components of the Implementation model;
• A requirement can be considered a component of the requirements model;
• A module can be considered a component of the design model;
According to Dromey, all these components possess intrinsic properties that can be classified into four categories:
• Correctness : Evaluates if some basic principles are violated.
• Internal : Measure how well a component has been deployed according to its intended use.
• Contextual : Deals with the external influences by and on the use of a component.
• Descriptive : Measure the descriptiveness of a component (for example, does it have a meaningful name.) Dromey proposes a product based quality model that recognizes that quality evaluation differs for each product and that a more dynamic idea for modeling the process is needed to be wide enough to apply for different systems. Dromey is focusing on the relationship between the quality attributes and the sub-attributes, as well as attempting to connect software product properties with software quality attributes.
This quality model presented by R. Geoff Dromey is most recent model which is also similar to McCall’s and Boehm’s model. Dromey proposes a product based quality model that recognizes that quality evaluation differs for each product and that a more dynamic idea for modeling the process is needed to be wide enough to apply for different systems. Dromey focuses on the relationship between the quality attributes and the sub-attributes, as well as attempts to connect software product properties with software quality attributes.
1) Product properties that influence quality.
2) High level quality attributes.
3) Means of linking the product properties with the quality attributes.
Dromey’s Quality Model is further structured around a 5 step process:
1) Choose a set of high-level quality attributes necessary for the evaluation.
2) List components/modules in your system.
3) Identify quality-carrying properties for the components/modules (qualities of the component that have the most impact on the product properties from the list above).
4) Determine how each property effects the quality attributes.
5) Evaluate the model and identify weaknesses.
Jack W Reeves argues that “programming is fundamentally a design activity and the source code is the only final and true representation of “the design” .” He explains this in 3 essays, each of which are explained below.
Essay1 : “What is Software Design?”
The growing popularity of C++ is because it makes software design and programming easier at the same time. Also, the lesson to be learnt from C++’s sudden popularity is that “programming is not about building software but about designing software”.
In any engineering activity the final goal is to come up with some documentation. Once the design document is complete it will be handed over to manufacturing team for developing the product. In case of software engineering the design document includes the source code listing, which is nothing but coding.
This essay was published in 1992.
Essay2 : “What is Software Design : 13 Years Later”
This essay was written by Reeves after receiving an email from Bob Martin who informed Reeves that there was a wiki page about his article Ward Cunningham’s c2.com web site. He started following the discussions on this page addressed the following criticisms
Critic A : ‘If source code is design then programmers are designers; but obviously they are not, therefore source code cannot be the design’.
Critic B : ‘Don’t do design, just code’.
Reeves condemns this critic by restating “In software engineering, we desperately need good design at all levels. In particular, we need good top level design. The better the early design, the easier detailed design will be. Designers should use anything that helps.”
Critic C : ‘Source code is still too high level to be a design’.
Some of arguments in the wiki states that “source code is a specification”. As per Reeves, specification states what and the design document states how to accomplish that. There will be no human creativity required in the design document. When a document is clear enough and can be easily interpreted by a compiler or assembly line worker then that document itself is a design document, hence source code is design and not specification.
Finally, Reeves concludes this essay by saying that “In software development, the design document is a source code listing.”
Essay3 : “Letter to the Editor”
This letter was a response from Reeves to the response of editor for his previous article. In this letter Reeves tries to convince the editor saying that for software engineering to ‘mature into a disciplined science” we, the software engineers must understand what software design is, i.e, we must understand the difference between doing software design and the finished software design. This is explained by taking the example of bridge design.
Before constructing a bridge the design of the bridge gets refined considerably. Structural analysis is performed, computer models are created and simulations are run. All these are done to ensure that the design is good before actually building the bridge. These activities are called engineering. When applied all these concepts in software engineering, testing and debugging can be considered as engineering activities. But these activities are not that efficient as of other engineering for example in civil engineering or electrical engineering. The reason being, these activities are quite costly and time consuming (sometimes more than 50% of the software life cycle might be needed for testing and debugging). Hence, these are given least importance.
In this letter he also specifies that auxiliary documentation is also of major importance as the source code comments can not provide sufficient information of the problem for which the design was built. For this we need more expressive programming languages such as C++.
DRM is a class of access control technologies that are used with the intent to limit the use of digital content and devices after sale. DRM is not a specific technology, it is any technology that inhibits uses of digital content that are not desired or intended by the content provider. The use of DRM is controversial. The content providers claim DRM is necessary to fight copyright infringement and helps copyright holder maintain their creative commons, whereas the opposing argue that DRM serves only to inconvenience to legitimate customers and helps big business stifle innovation and competition. Also, if the DRM scheme changes or is discontinued then the works might become permanently inaccessible.
Some of the opponents such as Free Software Foundation say that the term “rights” in the abbreviation is misleading as DRM policies are mainly about imposing restrictions and not about giving rights.
DRM Technologies enable content providers to enforce their own policies on content, like restrictions on copying and viewing.
Common DRM Techniques:
Restrictive Licensing Agreements: The access to digital materials, copyright and public domain is controlled. Some restrictive licenses are imposed on consumers as a condition of entering in a website or when downloading software.
Encryption, Scrambling of expressive material, and embedding of a tag: This technology is designed to control access and reproduction of online information. This includes backup copies of personal use.
1. DRM and computer Games:
a) Limited install activations: Most computers from 2006 onwards limited the number of systems on which the game could be installed. This had a negative impact, wherein if a system was reformatted or if operating system was upgraded then the games re-installation would be treated as a new installation and subsequently adding up to the count limit of number of installations.
b) Persistent online authentication: “a need for an always-on connection”.
c) Software tampering: To prevent usage of pirated software. For example, in Croteam gaming while using a pirated software a foe I the game becomes invincible and constantly attack the player until the player is dead.
2. DRM and documents: Enterprise digital rights management is the application of DRM technology to the control of access of corporate documents such as PDF etc. Now it s commonly known as Information rights management(IRM) is intended to prevent the unauthorized use of proprietary documents.
3. DRM and e-books: Ebooks use DRM to limit copying, printing and sharing of e-books. There are four main ebook DRM schemes in common use, each for Amazon, Adobe, Apple and the Marlin Trust Management Organization.
a) Amazon’s DRM is applied to Amazon’s Mobipocket, KF8 and Topaz format.
b) Adobe’s Adept DRM is applied to ePubs and PDFs.
c) Apple’s Fairplay DRM is applied to ePubs.
d) Marlin DRM is maintained in an open industry group known as Marlin developer community.
4. DRM and film:
a) CSS Content Scrambling System: employed by DVD forum, uses an encryption algorithm to encrypt content on DVD.
b) Microsoft’s Windows Vista contains a DRM called Protected Media Path which contains the Protected Video Path which tries to stop DRM-restricted content from being played.
c) Advanced Access Control System is a DRM system for HD DVD.
5. DRM and music
a) Audio CDs: Discs with digital rights management schemes are not legitimately standards-compliant Compact Discs (CDs) but are rather CD-ROM media. Therefore they all lack the CD logotype found on discs which follow the standard . Therefore these CDs could not be played on all CD players.
b) Internet music: Many online music stores employ DRM to restrict usage of music purchased and downloaded online.
6. DRM and television
a) Cable card standard provided by cable television providers in US restricts contents to only the services which the customer has subscribed.
b) Broadcast Flag developed by Fox in 2001 required that all HDTVs obey a stream specification determining whether or not a stream can be recorded. This was later adopted by DVB.
Programming paradigm used:
Object oriented programming paradigm is used in this case as there are many modules to be implemented and involves reusable components such as login module, add/delete/update items to shipping cart.
(1) There shall be a maximum of 80 characters per line
(2) Abbreviations/acronyms shall be mixed case with the first letter upper case and all following letters lower case.
(3) Each variable shall be defined or declared on a separate line.
(4) Use familiar variable names.
(5) Variable names shall be in lowercase.
(6) Local variables (those which are defined within functions) shall be defined before the first line of executable code within a function.
(7) Local variables (those which are defined within a block surrounded by braces) shall be defined before the first line of executable code within a block.
(8) Functions shall explicitly define the return type.
(9) There shall be no space between the function name and the opening parenthesis.
(10)The comment shall appear directly above the line (or block) to be commented for comments describing the methodology or flow of the code.
(11)The comment shall begin at the same indentation as the commented portion.
(12)Comments shall be written in the third person form.
(13)Use nouns to name variables. Ex: username
(14)Use uppercase for words and separate with underscore for naming constants.ex: MAX_VALUE
(15)Do not use names that differ only in case.Ex: theInstance and TheInstance
(16)Use verbs when naming functions.ex: login
Link to sourceforge: