Software Quality

39

SOFTWARE QUALITY
Introduction-:
In the previous chapter, we have discussed various definitions of quality and how they fit the perspective of different stakeholders. One of the definitions i.e., 'Conformance to explicitly stated and agreed functional and non-functional requirements', may be termed as 'quality' for the software product offered to customers/final users from their perspective. Customers may or may not be the final user and sometimes, developers have to understand requirements of final users in addition to the customer. If the customer is a distributor or retailer or facilitator who is paying for the product directly, then the final user's requirements may be interpreted by the customer to make a right product. It is not feasible to put all requirements in requirement specifications. A large number of requirements remain undefined or implied as they may be basic requirements for the domain and the customer perceives them as basic things one must know. It gives importance to the documented and approved software and system requirement specifications on which quality of final deliverables can be decided. It shifts the responsibility of making a software specification document and getting it approved from customer to producer of a product. There are many constraints for achieving quality for software application being developed using such software requirement specifications.

2.2 CO NS TRAI NTS O F S O FTW ARE PRO D U CT Q U ALI TY ASS ESS M EN T Generally, requirement specifications are made by business analysts and system analysts. Testers may or may not have direct access to the customer and may get information through requirement statements, queries answered, etc. either from the customer or business system/analyst, etc. There are few limitations of product quality assessment in this scenario. Software is virtual in nature. Software products cannot be seen, touched or heard. Our normal senses and measuring instruments are not capable of measuring quality of software, which is possible in most of (he other engineering products. There is a huge communication gap between users of software and developers/testers of the product. Generally 5-8 agencies are involved between these two extreme ends. If an average communication loss of 10% at each stage is considered, then huge distortion is expected from user's perspective of requirements and actual product. Software is a product which is unique in nature. Similarities between any two products are superficial ones. The finer requirements, designs foundation, architecture, actual code. etc. may be completely different for different products.Way of software design, coding, and reusability may differ significantly from product to product though requirements may look similar at a global level.

Copyrighted material

Software Quality

39

All aspects of software cannot be tested fully as number of permutations and combinations for testing all possibilities tend to infinity. There are numerous possibilities and all of them may not be tried in the entire life cycle of a software product in testing or even in usage. Exhaustive testing is neither feasible nor justifiable with respect to cost. A software program executes in the same way every time when it is executing some instruction. An application with a problematic code executes wrongly every time it is executed. It makes a very small defect turn into a major one as the probability of defect occurrence is 100% when that part is executed.

2.3 CUSTOMER ISA KING

The customer is the most important person in any process of developing a product and using itsoftware development is not an exception. All software life cycle processes such as development, testing, maintenance, etc. arc governed by customer requirements, whether implied or expressed. An organization must be dedicated to exceed customer satisfaction with the latter s consent. Exceeding customer satisfaction must not be received with surprise by the customer. He must be informed about anything that has been provided extra and must be in a position to accept it or reject it. Any surprise may be considered as defect.

2.3.1 FACTORS DETERMINING SUCCESS

To be a successful organization, one must consider the following factors, entities, and their interactions with each other.

Internal Customer and Internal Supplier

Internal customer satisfaction" philosophy is guided by the principles of 'Total Quality Management'. When an organization is grouped into various functions.'' departments, then one function/department acts as a supplier or a customer of another function/department. If every function/department identifies its customers and suppliers and tries to fulfill their requirements, in turn, external customer requirements get satisfied.

External Customer and External Supplier

External customers may be the final users, purchasers of software, etc. Software requirement specifications arc prepared and documented by developing organizations to understand what customer/final user is looking for when he wishes to acquire a particular product. Customers are actually paying for getting their needs served and not for the implementation of the requirements as defined in the specifications document. External suppliers arc the entities who are external to the organization and who are supplying to the organization.

Copyrighted material

Software Quality

39

2.4 QUALITY AND PRODUCTIVITY RELATIONSHIP

Many people feel that better quality of a product can be achieved by more inspection or testing, reworking, scrapping, sorting, etc. More inspection cycles mean finding more defects, fixing defects mean better quality (as it will expose maximum possible defects to be fixed by developers), and ultimately, the customer may get a better product. This directly means that there would be more rework/scrap and it will lead to more cost/ price or less profit for such products as more effort and money is spend in improving quality. In such cases, time and effort required would be much higher. In reality, quality improvement does not talk about product quality only but a process quality used for making such a product. If the processes of development and testing are good, a bad product will not be manufactured in the first place. It will reduce inspection, testing, rework, and cost/price. Thus quality must improve productivity by reducing wastage. It must target for doing 'first-time right.'

Improvement in Quality Directly Leads to Improved Productivity

Improved quality does not mean more inspection, testing, sorting and rejection but improving the processes related to product development. AH products are the outcome of processes, and good processes must be capable of producing good product at the first instance. This approach reduces frustration, rejection, rework, inspection, and improves quality and customer satisfaction. As this hidden factory producing scrap and wastage stops working, productivity and efficiency improves. Thus, quality products must give more profitability to the supplier and is a cheaper option for the customer.

The Hidden Factory Producing Scrap, Rework, Sorting, Repair, and Customer Complaint is Closed
Customer does not intend to pay for scrap, rework, sorting, etc. to get a good product. Engineering industry has faced this problem of unwillingness of customer to pay even for first-time inspection/testing as they represent deficiencies in manufacturing processes. Customer complaints arc mostly due to the problems associated with products and aligned services. Problems in products can be linked to faulty development processes. Either the defects are not found in the product during process of development or testing, or fixing of the defects found in these processes introduces some more defects in the product offered.

Effective Way to Improve Productivity is to Reduce Scrap and Rework by Improving Processes
Productivity improvement means improving number of good parts produced per unit time and not the parts produced per unit time. It is not hard work but smart and intelligent work which

Copyrighted material

Software Quality

39

can help an organization in improving product quality, productivity and customer satisfaction by reducing rework, scrap, etc. It necessitates that an organization must incorporate and improve quality in the processes which lead to better product quality. As wastage of resources reduce with improvements in quality, productivity and efficiency improves as a direct result by improvements in processes.

Quality Improvements Lead To Cost Reduction

Quality improves productivity, efficiency and reduces scrap, rework, etc. Improvement in quality increases profit margins for producer by reducing cost of development, cost of quality and reduces sales price for customer. Thus quality implementation must reduce the cost and price without sacrificing profitability.

Employee Involvement inQuality Improvement

Employee is the most important part of quality improvement program and crucial element for organizational performance improvement. Management leadership and employee contribution can make an organization quality conscious while lack of either of the two can create major problems in terms of customer dissatisfaction, loss of profitability, loss of goodwill, etc. Employees are much nearer to problematic processes and know what is going wrong and how it can be improved. Employee involvement in quality implementation is essential as the employees facing problems in their work indicate the process problems. Management must include employees in quality improvement programs at all stages.

Proper Communication Between Management and Employee is Essential

Communication is a major problem in today's environment. One of the communication hurdles is that the chances of face-to-face communication are reducing due to technological improvements and distributed teams. Mostly, communication is by virtual appliances like emails, video conferencing, etc. where it is difficult to judge the person through body language. Either there is no communication or there is excessive communication leading to a problematic situation. There are huge losses in communication and distortions leading to miscommunication and wrong interpretation. The reasons for 'Producer's gap' and 'User's gap' are mainly attributed to communication problems. Different words and terms used during the message, tone, type of message, speaking skills, listening skills, etc. contribute to quality of communication.

Employees Participate and Contribute in Improvement Process

In quality improvement program design and implementation, employees perform an important part of identification of problems related to processes and giving suggestions for eliminating them. They are the people doing actual work and know what is wrong and what can be improved in those processes to eliminate problems. They must be closely associated with the organization's goal of achieving customer satisfaction, profitability, name and fame in market, etc. Every employee needs to play a part in implementation of 'Total Quality Copyrighted material

Software Quality

39

Management' in respective areas of working. This can improve the processes by reducing any waste.

Employee Shares Responsibility for Innovation and Quality Improvement

Management provides support, guidance, leadership, etc. and employees contribute their part to convert organizations into performing teams. Everyday work can be improved significantly by establishing small teams for improvement which contribute to innovations. An organization must not wait for inventions to happen for getting better products but perform small improvements in the processes everyday lo achieve big targets in the long range. The theory of smart work in place of hard work helps.
Table 2.1 Difference between inventions and innovation Invention Innovation a.) Innovation is a planned activity leading to changes. a.) Inventions may be accidental in nature. They are generally unplanned. b.) Innovation is done by people in a team, possibly b.) Invention may or may not be acceptable to people cross-functional teams, involved in doing a work. There doing the work immediately. Inventions are done by is higher acceptability by people as they are involved in scientist and implementation and acceptance by it. people can be cumbersome as general level of c.) Innovations can be applied to every day work easily. acceptance is very low. The existing methods and processes are improved to c.) Inventions may not be directly applied to everyday eliminate waste. work. It may need heavy customization to make it d.) Changes in small steps are possible by innovation. suitable for normal usage. e.) Innovation generally leads to administrative d.) Breakthrough changes are possible due to improvements, whereas technological or breakthrough improvements are not possible. inventions. c.) Invention may lead to major changes in technology, f.) Innovation may lead to rearrangement of things but there may not be a fundamental change. It generally way of doing work, etc. works on elimination of waste. d.) Invention may lead to scraping of old technologies, old skills and sometimes, it meets with heavy resistance-

2.5 Requirement Of A Product

*********Notes Not Available*********

2.6 ORGANISATION CULTURE

An organisation has a culture based on its philosophy for existence, management perception and employee involvement in defining future. Quality improvement programs are based on the ability of the organisation to bring about a change in culture. Philip Crosby has prescribed quality improvement for cultural change. Quality culture of an organisation is an understanding of the Organizations virtue about its people, customer, suppliers and all Copyrighted material

Software Quality

39

stakeholders. 'Q' Organizations are more quality conscious Organizations, while 'q' Organizations are less quality conscious Organizations. The difference between 'Q' Organizations and 'q' organisation is enumerated as follows.
Difference between *Q' organisation and *q' organization Quality culture is *Q' A.) These Organizations believe in listening to customers and determining their requirements. B.) These Organizations concentrate on identifying cost of quality and focusing on it to reduce cost of failure which would reduce overall cost and price. C.) Doing things right for the first time and every time is the motto of success. D.) They concentrate on continuous/continual process improvement to eliminate waste and get better output. E.) These Organizations believe in taking ownership of processes and defects at all levels. F.) They demonstrate leadership and commitment to quality and customer satisfaction. Quality culture is not 'q' A.) These Organizations assume that they know customer requirements. B.) These Organizations overlook cost of poor quality and hidden factory effect. They believe in more testing to improve product quality. C.) Doing things again and again to make them right is their way of working. Inspection, rework, scrap, etc. are essential. D.) They work on the basis of finding and fixing the problem as and when it is found. Onetime fix for each problem after it occurs. E.) These Organizations try to assign responsibility of defects to someone else. F.) They believe in assigning responsibility for quality to others.

2.6.1 S HI FT I N FO CUS FRO M 'q' TO ' Q'

As the organisation grows from *q' to 'Q\ there is a cultural change in attitude of the management and employees towards quality and customer. In initial stages, at the level of higher side of *q\ a product is subjected to heavy inspection, rework, sorting, scrapping, etc. to ensure that no defects are present in final deliverable to the customer while the final stages of 'Q* organisation concentrate on defect prevention through process improvements. It targets for first-time right.

Quality Control Approach (Finding and Fixing Defects)-: Quality control approach is the oldest approach in engineering when a product was subjected to rigorous inspection for finding and fixing defects to improve it. Organizations with higher end of q believe in finding and fixing defects to the extent as the possible way as to improve quality of product before delivering into customer and achieving customer satisfaction. The Quality management basically works on correction attitude involving defect fixing, scrap, rework, segregation, etc. Copyrighted material

Software Quality

39

Quality Assurance Approach (Creation of Process Framework) -: Quality

assurance is the next stage of improvement from quality control where the focus shifts from testing and fixing the defects to first-time right. An Organisation does investment in defining processes, policies, methods for handling various functions so that it can incorporate a process approach for doing various things. It becomes a learning organisation as it shifts its approach from 'quality control' to 'quality assurance'. The management approach shifts from corrections to corrective actions through root cause analysis.

Quality Management Approach-:

There are three kinds of system in the universe, viz. completely closed systems, completely open systems and systems with semi permeable boundaries. Completely closed systems represent that nothing can enter inside the system and nothing can go out of the system. On the other hand, open system represents a direct influence of universe on system and vice-a-versa. Completely closed systems or completely open systems do not exist in reality. Systems with semi permeable boundaries are the realities, which allow the system to get impacted from external changes and also have some effect on external environment. Organizations try to assess the impact of the changes on the system and try to adapt to the changes in the environment to get the benefits. They are highly matured when they implement Quality Management as a management approach. Management includes planning, organising, staffing, directing, coordinating, and controlling to get the desired output. It also involves mentoring, coaching, and guiding people to do better work to achieve organisational objectives. 2.7 CH ARACTERISTI CS O F S O FTW ARE

There are many products available in the markets which are intended to satisfy same or similar demands. There is a vast difference between software products and other products due to their nature. a.) Software cannot be sensed by common methods of inspection or testing, as it is virtual in nature. The product is in the form of executable which cannot be checked by any natural method available to mankind like touch, smell, hearing, taste, etc. It cannot be measured by some measuring instruments commonly available like weighing balance, scales, etc. It needs testing in real environment but nobody can do exhaustive testing by trying all permutations and combinations. b.) There are different kinds of software products and their performance, capabilities, etc. vary considerably from each other. There are no same products though there may be several similar ones or satisfying similar needs. Every product is different in characteristics, performance, etc. Software is always unique in nature. c.) Every condition defined by the software program gets executed in the same way every time when it gets executed. But the number of conditions, and algorithm combinations may be very large tending to infinity and testing of all permutations/combinations is practically impossible. 2.8 S O FTW ARE D EVELO PM ENT PRO CESS

Copyrighted material

Software Quality

39

Software development process defines how the software is being built. Some people also refer to SDLC as system development life cycle with a view that system is made of several components and software is one of these components. There are various approaches to build software. Every approach has some positive and some negative points. Let us talk about few basic approaches of developing software from requirements. It is also possible that different people may call the same or similar approach by different names. Waterfall development approach/model Iterative development approach/model Incremental development approach/model Spiral development approach/model Prototyping development approach/model Rapid application development approach/model Agile development approach/model

2.8.1 W ATERFALL D EVELO PMEN T APPRO ACH / MO D EL Waterfall model is (he simplest software development model and is used extensively in development process study. There are many offshoots of waterfall model such as modified waterfall model, iterative waterfall model-etc. Though it is highly desirable to use waterfall model, it may not be always feasible to work with it Still, waterfall model remains as a primary focus for study purpose. It is also termed as classical view of software development as it remains the basis or foundation of any development activity. Most of the other models of development are based upon the basic waterfall model as it represents a logical way of doing things. Typical waterfall model is shown in Fig. 2.2. Arrows in the waterfall model are unidirectional It assumes that the developers shall get all requirements from a customer in a single go. The requirements arc converted into high level as well as low level designs. Designs are implemented through coding. Code is integrated and executable are created. Executables are tested as p er test pl an . The f in al output in the form of an executable is deployed at customer premises. Future activities are handled through maintenance. If followed in reality, waterfall model is the shortest route model which can give highest efficiency, a nd productivity. Waterfall models are used extensively in fixed price/fixed schedule projects where estimation is based on initial requirements. As the requirement changes, estimation is also revised.

Limitations of Waterfall Cycle

There is no feedback loop available in waterfall model. It is assumed that requirements are stable and no problem i s encountered during entire development life cycle. Also, no rework is involved in waterfall model.

Copyrighted material

Software Quality

39

2.8.2 I TERATI VE D EVELO PM EN T APPRO ACH/ M OD EL Iterative development process is more practical than the waterfall model. It does not assume that the customer gives all requirements in one go and there is complete stability of requirements. It assumes that changes may come from any phase of development to any previous phase and there are multiple permutations and combinations of changes. Changes may have a cascading effect where one change may initiate a chain reaction of changes. Figure 2.3 shows a feedback loop which is the fundamental difference between waterfall model and iterative development model. Limitations of Iterative Development -: Iterative development consists of many cycles of waterfall model. It gives problems in fixed price projects for estimation. Another problem faced by iterative development is that The product architecture and design becomes fragile due to many iterative changes.

Copyrighted material

40

SOFTWARE TESTING: Principles, Techniques andTools

2.8.3 I N CREMEN TAL D EVELOPM EN T APPROACH /M O D EL Incremental development models are used in developing huge systems. These systems are made of several subsystems which in themselves are individual systems. Thus, incremental systems may be considered as a collection of several subsystems. An individual subsystem may be developed by following waterfall methodology and iterative development. These subsystems may be connected to each other externally, either directly or indirectly. A directly interconnected system allows the subsystems to talk with each other while indirectly interconnected system has some interconnecting application between two subsystems. Direct connectivity makes a system more robust but flexibility can be a major issue. Th e in cr ement al model gives fl exibil it y to a customer. One s yst em may b e cr eat ed and th e custo mer may start using it. The customer can learn the lessons and use them while second part of the system is developed. Once those are integrated, third part may be developed and so on. The customer does not have to give all r equir ement s at th e start of d ev elop ment phase.

Copyrighted material

The model in Fig, 2.4 shows a common communication system and incremental subsystems where different subsystems communicate through a common communication system.

Limitations Of Incremental Development

Incremental models with multivendor product integration are a major challenge as parameter passing between different systems may be difficult. Incremental models help in integration of big systems at the cost of loss of flexibility. When a system is incremented with new subsystems, it changes the architecture of that system. Increment in the system is followed by heavy regression testing to find that when multiple systems come together, can th ey work individually as well as collectively. 2.8.4 S PI RAL DEVELO PM EN T APPRO ACH/ MO D EL Spiral development process assumes that customer requirements are obtained in multiple iterations, and development also works in iterations. Many big software systems are built by spiral models of ever-increasing size. First some functionalities are added, then product is created and released to customer. After getting the benefits of first iteration of implementation, the customer may add another chunk of requirements to the existing one. Further addition of requirements increase the size of the software spirally. Sometimes, an individual part developed in stages represents a complete system, and it may communicate with th e next developed system through some interfaces. In many ERPs, initial development concentrated around material management part which later increased spirally to other parts such as purchasing, manufacturing, sales, warehousing, cash control, etc. Many banking softwares also followed a s i mi l ar route. Figure 2.5 shows a spiral development model.

Spiral development is considered as a miniature form of the incremental model.

Limitations of Spiral Development Spiral models represent requirement elicitation as the software is being
developed. Sometimes, it may lead to refactoring and changes in approach where initial structures become nonusable. Spiral development also needs huge regression testing cycles to find whether additions in the given system have affected overall system working or not. 2.8.5 P R O TO TY PE DEVELO PM EN T APPRO ACH/ MO D EL Prototype development approach represents top to bottom reverse integration approach. Major problem of software development is procuring and understanding th e customer requirements for th e product. Prototyping is one of the solutions to help in this problem.

In prototyping, initially a prototype of th e system is createdthis is similar to cardboard model of a building. It helps the customer to understand what they can expect from the given set of requirements. It also helps the development team to understand th e possible application's look and feel. Once the elicitation is done, die logic is build behind it to implement the elicited requirements.

Limitations of Prototype Development

Though, one may get a feel of the system by looking at the prototype, one must understand that it is not th e actual system but a model. The customer may get the feeling that the system is already ready and may pressurize development team to deliver it immediately. (Applications not having much graphical user interfaces are difficult to model.)

2.8.6 RAPI D APPLI CATI ON D EVELO PM EN T APPRO ACH /M O D EL Rapid application development is not a rapid w ay of developing software as one may interpret from the name. I t is one way to create usable software at a fast speed, and still give an opportunity to th e user to understand the development and application being created. 2.8.7 AG I LE DEVELO PM EN T APPRO ACH /M O D EL Agile development methodologies are becoming popular due to their dynamic nature and easy adaptability to the situation. One of the surveys indicated that in case of waterfall model, many functionalities are added in requirement statement with a fear that changes in scope would not be appreciated by the development team. Some surveys show that many of the functionalities (about 3Ath) developed using waterfall or iterative model ar e n ev er used by the users. A gil e gives complete freedom to the user to add requirements at an y stage of development, and development team has to accept these changes. Agile methodologies work on small chunk of work in each

iteration and release working software at the end of iteration. The main thrust of Agile methodologies is complete adaptability to user environment and continuous integration of a product. I t also gives importance to delivering working software rather than achieving requirements defined in requirement specifications. Agile represents a family of development methodologies and there are many methodologies under its umbrella. Some of them are as listed below. Scrum Extreme Programming Feature Driven Development Test Driven Development

Agile works on th e following principles, Individuals and interactions are more important th an formal sign-ofTs for requirements, designs, etc. I t concentrates more on 'Fitness for use' and what the customer needs are. Working software is the outcome of each milestone rather than concentrating on deliverables as defined in the project plans. Success of software product is that it is working at each stage. Customer collaboration is required to get usable software rather than signing various documents for approvals. Requirement clarifications, requirement elicitation, and prototyping need customer involvement. Responding to changes required by the customer at any moment. There may be many changes suggested by the customer as he has better knowledge about what his business needs are. 2.8.8 M AIN TEN AN CE D EVELO PM EN T APPRO ACH/ M OD EL Major cost of the software is in its maintenance phase. Every product including software has man y defects which may create problems to its users in the long term. Every technology has a life span. New technologies may offer

better services and options, and may replace existing technologies. Every now and then, technological updations are required for the software as well as system to perform better and

2.8.7 AG I LE DEVELO PM EN T APPRO ACH /M O D EL Agile development methodologies are becoming popular due to their dynamic nature and easy adaptability to the situation. One of the surveys indicated that in case of waterfall model, many functionalities are added in requirement statement with a fear that changes in scope would not be appreciated by the development team. Some surveys show that many of the functionalities (about 3Ath) developed using waterfall or iterative model ar e n ev er used by the users. A gil e gives complete freedom to the user to add requirements at an y stage of development, and development team has to accept these changes. Agile methodologies work on small chunk of work in each iteration and release working software at the end of iteration. The main thrust of Agile methodologies is complete adaptability to user environment and continuous integration of a product. I t also gives importance to delivering working software rather than achieving requirements defined in requirement specifications. Agile represents a family of development methodologies and there are many methodologies under its umbrella. Some of them are as listed below. Scrum Extreme Programming Feature Driven Development Test Driven Development

Agile works on th e following principles,

 Individuals and interactions are more important th an formal sign-ofTs for requirements, designs, etc. I t concentrates more on 'Fitness for use' and what the customer needs are. Working software is the outcome of each milestone rather than concentrating on deliverables as defined in the project plans. Success of software product is that it is working at each stage. Customer collaboration is required to get usable software rather than signing various documents for approvals. Requirement clarifications, requirement elicitation, and prototyping need customer involvement. Responding to changes required by the customer at any moment. There may be many changes suggested by the customer as he has better knowledge about what his business needs are. 2.8.8 M AIN TEN AN CE D EVELO PM EN T APPRO ACH/ M OD EL Major cost of the software is in its maintenance phase. Every product including software has man y defects which may create problems to its users in the long term. Every technology has a life span. New technologies may offer better services and options, and may replace existing technologies. Every now and then, technological updations are required for the software as well as system to perform better and i n the most cost effective way. New functionalities may be required due to changing business needs. Maintenance activities of software may be put under 4 different groups namely, Bug fix ing where the defects present in th e given software are fixed. This may involve retesting and regression testing. During bug fixing, analysis of bug is an important consideration. There is always a possibility that w hil e fixing a bug. new bugs may h ave been added in the product. Enhancement where new functionalities are added in the existing software. These functionalities may be required due to changes in the way business is done. Some functionalities may be introduced due to changes in user requirements.

 Porting where software is taken from older technologies to n ew er technologies. In porting, one is ex pected to port the functionalities and not the code. Whatever functionalities are available in the old technologies, all those are expected to be present in the new technology. Reengineerlng where there is some change in the logic or algorithm used due to changes in business environment.

2.9 TYP ES OF PRO D U CTS Similar to software development methodologies, software products have some peculiarities defined as criti-calities of software. Criticality of the software defines, how much important it is to a user/customer. There are various schemes of grouping the products on the basis of criticality to the users. Few of them are listed below. 2.9.1 LIF EAFF ECTI NG P RO D UCTS Products which directly/indirectly affect human life are considered as the most critical products in th e world from user's perspective. Such products generally come under the purview of regulatory and safety requirements, in addition to normal customer requirements. The quality requirements are more stringent, and testing i s very critical for such products as failures may result into loss of life or disablement of a user. This type of product may be furt he r grouped into 5 different categories. Any product failure resulting into death of a person. These will be the most critical products as they can affect hu man life directly.

 Any product failure which may cause permanent disablement to a patient. These are second-level criticality products. Any product failure which may cause temporary disablement to a patient Any product failure which may cause minor injury and docs not result into anything as defined above Other products which do not affect health or safety directly Such software needs huge testing to try each an d every conceivable fault in the product. I t talks about very high level of confidence that application will not fail under normal and abnormal situations. 2.9.2 PRO DU CT AFFECTI N G HU G ES U M O F MO N EY A product which has direct relationship with loss of huge sum of money is second in the list of criticality of the product. Such products may need large testing efforts and have many regulatory as well as statutory requirements. E Commerce and e business softwares may be pu t in this category- Security, confidentiality, and accuracy are some of the important quality factors for such products. These products also need very high confidence level and huge testing will represent the criticality. They need testing lesser than the products which directly/indirectly affect h u man life. 2.9.3 PRO D U CTS WH I CH CAN B E TES TED O N LY B Y SI M ULATORS Products which cannot be tested in real-life scenario but need simulated environment for testing are third in the ranking of criticality. In this case, real life scenario is either impossible to create or may not be economically viable. Products used in aeronautics, space research, etc. may be put in this category. Such products also need huge testing, although lesser than the earlier two types. 2.9.4 O TH ER PRO DUCTS

All other products which cannot be categorized in any of the above schemes may be put in this category. Unfortunately, 'criticality" is not very easy to define. Let us consider an example of auto piloting software where we have three combinations of criticality together. It does affect the life of passengers traveling, cost of an airplane is huge and it cannot be tested in real environment. Thus, all the three criticalities coming together make a product most critical.

2.10 SOME OTHER SCHEMES OF CRITICALITY DEFINITIONS

There may be several other ways of classifying criticality of a product. It has direct relationship with business dependability and the extent of loss to the user organisation/person in case of failure. 2.10.1 FRO M US ER'S PERS PECTI VE

This classification mainly discusses dependency of a business on a system. The criticality may range from complete dependency to no/minimal dependency on the system. Product's failure which disrupts the entire business can be very critical from business point of view. There is no fallback arrangement available or possible in case of failure of a product which is completely dependent on the system. Product's failure which affects business partially as there may be some fallback arrangements is a type of criticality. Business may be affected temporarily, affecting profitability or service level but can be restored with some efforts. Product's failure which does not affect business at all is one of the options. If it fails, one may have another method to achieve the same result. Rearrangement may not have significant distortion of business process.

2.10.2

AN O TH ER WAY O F D EFI NI NG U S ER'S PERS PECTI VE

This classification considers the environment in which the product is operating. It may range from very complex user environment to very easy user environment. Products where user environment is very complex such as aeronautics, space research, etc. may be considered as very critical. Any failure of product can result into major problems as the environment where these products are working is not an easy environment. As the environment is very complex, system is already under stress, and failure of a product may add to the situation. Products where user environment is comparatively less complex (such as banks) may represent the second stage of complexity. Huge calculations may be affected, if the system collapses but there may be workaround available. People may find it inconvenient, but still the operations can be performed with some tolerable level of problems. For example, banks were running for so many years without computers and if centralised system fails, they may be able to withstand the pressure to some extent Products where user environment is very simple, and product failure may not add to the consequences represents th e lowest level of complexity. If there is any failure, it can be restored quite fast or some other arrangements can be used, and work can be continued. 2.10.3 CRI TI CA LI TY F ROM D EVELO PER'S PERSP ECTI VE This classification defines the complexity of th e system on th e basis of development capabilities r equir ed . It may range from very complex systems to very simple systems. Form based software where user inputs are taken an d stored in some database. As and when required, those inputs arc manipulated and shown to a user on screen or in form of a report. There is not much manipulation of data and no heavy calculations/algorithms are involved.

 Algorithm based software, where huge calculations arc involved and decisions are taken or prompted by the system on the basis of outcome of these calculations. Due to usage of different mathematical models, the system becomes complex and designing, developing and testing all combinations become problematic. Artificial intelligent systems which learn things and use them as per circumstances are very complex systems. A n important consideration is that the 'learnings' acquired by the system must be stored and used when required. This makes t h e system very complicated. There may be a possibility of combination of criticalities to various extends for different products at a time. A software used in aviation can affect human life, and also huge money at a time. I t may not be feasible to test it in real-life scenario. It may i nvolv e some extent of artificial intelligence where system is expected to leam and use those 'learnings*. Thus, th e combination increases severity of failure further.

2.11 PROBLEMATIC AREAS OF SOFTWARE DEVELOPMENT LIFE CYCLE

Let us discuss some problematic areas of software development life cycle. 2.11.1 PRO BLEM S WI TH REQU I REM EN T PHAS E Requirement gathering and elicitation is th e most important phase in software development life cycle. M an y surveys indicate that the requirement phase introduces maximum defects in th e product. Problems associated with requirement gathering are,

Requirements Are Not Easily Communicated

Communication is a major problem in requirement statement creation, software development and implementation. Communication of requirements from customer to

development team i s marked by problems of listening to customer, understanding business domain, and usage of language including domain specific terms and terminologies. The types of requirements are.

Technical Requirements Technical requirements talk about platform, language, database, operating system, etc.
required for the application to work. Many times, the customer may not understand the benefits of selecting a specific technology over the other options and problems of using these technically specified configurations. Selection of technology may be done as directed by the development team or as a fashion. Development organisation is mainly responsible for definition of technical requirements for software product under development on the basis of product usage. (Technical requirements also cover (his type of system, whether a stand alone or client server or web application etc, tiers present in the system, processing options such as online, batch processing etc). It also talks about configuration of machines, routers, printers, operating systems, databases, etc. Economical Requirements Economics of software system is dependent on its technical and system requirements. The technical as well as system requirements may be governed by the money that the customer is ready to put in software development, implementation and use. It is governed by cost-benefit analysis. These requirements are defined by development team along with the customer. The customer must understand the benefits and problems associated with different approaches, and select the approach on the basis of some decision-analysis process. The consequences of any specific selection may be a responsibility of the customer but development Organizations must share their knowledge and experience to help and support the customer in making such a selection.

Legal Requirements There are many statutory and regulatory requirements for software product usage. For any
software application, there may be some rules and regulations by government, regulatory bodies, etc. applicable to the business. There may be some rules which keep on changing as per decisions made by government, regulatory authorities, and statutory authorities from time to time. There may be numerous business rules which are defined by customers or users for doing business. Development team must understand the rules and regulations applicable for a particular product and business.

Operational Requirements Mostly operational requirements are defined by customers or users on the basis of
business needs. These may be functional as well as non-functional requirements. They tell the development team, what the intended software must do/must not do when used by the normal user. Operational requirements are derived from the business requirements. This may include non-functional requirements like security, performance, user interface, etc.

System Requirements System requirements including physical/logical security requirements are defined by a
customer with the help of a development team. These include requirements for hardware, machine configurations, types of backup, restoration, physical access control, etc. These requirements are defined by customer's management and it affects economics of the system. There may be some specific security requirements such as strong password, encryption, and privilege definitions, which are also declared by the customer.

Requirements Change Very Frequently Requirements are very dynamic in nature. There are many complaints by
development teams that requirement change is very frequent. Many times, development teams get confused because customer requirements change continuously. 'Customer does not know what he wants1 is a very common complaint made by development teams. As the product is being built and shown to customer, lot of new ideas are suggested. Some ideas may have significant effect on cost, schedule, and effort while some other may change the architecture, basic approach, and design of software. The time gap between requirement definition and actual product delivery also plays a major role in changing requirements. Top-down approach, rapid application development, and joint application development are some of the techniques used to develop applications by accommodating changes suggested by customers.

2.11.2 GENERALLY A UNIQUE PRODUCT IS DEVELOPED EACHTIME -: ** ****** *Notes No t Availab le**** *****

2.12 SOFTWARE QUALITY MANAGEMENT

Quality management approaches talk about managing quality of a product or service using systematic ways and methods of development and maintenance. It is much above achieving quality factors as defined in software requirement specifications. Quality management involves management of all inputs and processing to the processes defined so that the output from the process is as per defined quality criteria. It talks about three levels of handling problems, namely.

Correction-: Correction talks about the condition where defects found in the product or service are immediately
sorted and fixed. This is a natural phenomenon which occurs when a tester defines any problem found during testing. Many Organizations stop at fixing the defect though it may be defined as corrective action by them. Responsibility of finding and fixing defects may be given to a line function. This is mainly a quality control approach.

Corrective Actions-: Every defect needs an analysis to find the root causes for introduction of a defect in the
system. Situation where the root cause analysis of the defects is done and actions are initiated to remove the root causes so that the same defect does not recur in future is termed as corrective action. Corrective action identification and implementation is a responsibility of operations management group. Generally, project leads are given the responsibilities of initiating corrective actions. This is a quality assurance approach where process-related problems are found and resolved to avoid recurrence of similar problems again and again.

Preventive Actions-: On the basis of root causes of the problems, other potential weak areas are identified.
Preventive action means that there are potential weak areas where defect has not been found till that point, but there

exists a probability of finding the defect, in this situation, similar scenarios are checked and actions are initiated so that other potential defects can be eliminated before they occur. Generally identification and initiation of preventive actions are a responsibility of senior management. Project managers are responsible for initialing preventive actions for the projects. This is a quality management approach where an organisation takes preventive action so that there is no defect in the first place. Quality management is a set of planned and systematic activities which ensures that the software processes and products conform to requirements, standards and processes defined by management, customer, and regulatory authorities. The output of the process must match the expectations of the users.

2.13 WHY SOFTWARE HAS DEFECTS?

One very important question about a product is, 'Why there are defects in the product at all?'. There is no single answer to this question. After taking so much precaution of defining and implementing the processes, doing verification and validation of each artifact during SDLC, yet nobody can claim mat the product is free of any defects. In case of software development and usage, there are many factors responsible tor its success/ failure. Few of them are, There are huge communication losses between different entities as requirements get converted into the actual product. Understanding of requirements is a major issue and majority of the defects can be attributed to this. Development people are more confident about their technical capabilities and do not consider that they can make mistakes. Sometimes self review and/or peer review does not yield any defects. Requirement changes are very dynamic. As the traceability matrix is not available, impact analysis of changing requirements becomes heuristic.

 Technologies are responsible for introducing few defects. There are many defects introduced due to browsers, platforms, databases, etc. People do not read and understand release notes, and consequences of failure are attributed to technologies. Customer may not be aware of all requirements, and the ideas develop as the product is used. Prototyping is used for clarifying requirements to overcome this problem to some extent.

2.14 PROCESSES RELATED TO SOFTWARE QUALITY

Quality environment in an organisation is established by the management. Quality management is a temple built by pillars of quality. Culture of an organisation lays the foundation for quality temple. Every organisation has different number of tiers of quality management system definition. Figure 2.6 shows a relationship between vision, mission(s), policy(ies), goal(s), objective(s) strategy(ies) & values of organisation.

2.14.1 VISI O N The vision of an organisation is established by the policy management. Vision defines in brief about what the organisation wishes to achieve in the given time horizon. 'To become a billion-dollar company within 3 years' can

be a vision for some Organizations. Every organisation must have a vision statement, clearly defining the ultimate aim it wishes to achieve with respect to time span. 2.14.2 M ISSI O N Jn an organisation, there are several initiatives defined as missions which will eventually help the organisation realise its vision. Success of all these missions is essential for achieving the organisation's vision. The missions are expected to support each other to achieve the overall vision put by management. Missions may have different lifespans and completion dates. 2.14.3 PO LI CY

Policy statement talks about a w ay of doing business as d efin ed by senior management. This statement helps employees, suppliers and customers to understand the thinking and intent of management. There may be several policies in an organisation which define a way of achieving missions. Examples of policies may be security policy, quality policy, and human resource development policy.

2.14.4

O BJ ECTI VES

Objectives define quantitatively what is meant by a successful mission. It defines an expectation from each mission and can be used to measure the success/failure of it. The objectives must be expressed in numerals along with the time period defined for achieving them. Every mission must have minimum one objective. 2.14.5 S TRATEGY

Strategy defines the way of achieving a particular mission. It talks about the actions required to realise th e mi ss ion and w ay of doing th ings . Poli cy is conv ert ed in to act ions through st rat eg y. Str ategy mu st h av e a time frame and objectives along with goals associated with it. There may be an action owner to lead the strategy. 2.14.6 G O ALS

Goals define the milestones to be achieved to make t h e mission successful. For a mission to be declared as successful/failure at the end of the defined time frame in terms of whether the objectives are achieved or not, one needs a milestone review to understand whether the progress is in proper direction or not. Goals provide these milestone definitions. 2.14.7 VALU ES

Values can be defined as the principles, or way of doing a business as perceived by the management. 'Treating customer with courtesy' can be a v alu e for an organisation. The manner in which th e organisation and management think and behave, is governed by the values it believes in.

2.15 QUALITY MANAGEMENT SYSTEM STRUCTURE

Every organisation has a different quality management structure depending upon its need and circumstances. Generic view of quality management is defined below. Figure 2.7 shows a structure of quality management system in general.

2.15.1 I S T TIER QU ALI TY POLI CY Quality policy sets the wish, intent and direction by the management about how activities will be conducted by the organisation. Since management is the strongest driving force in an organisation, its intents are most important. It is a basic framework on which the quality temple rests.

2.15.2 2NDTI ER Q U ALI TY O BJ ECTIVES Quality objectives are the measurements established by the management to define progress and achievements in a numerical way. An improvement in quality must be demonstrated by improvement in achievements of quality factors(test factors) in numerical terms as expected by the management. The achievements of these objectives must be compared with planned levels expected and results and deviations must be acted upon. 2.15.3 3 R D TI ER Q U ALI TY M AN U AL Quality manual, also termed as policy manual is established and published by the management of the organisation. It sets a framework for other process definitions, and is a foundation of quality planning at organisational level.

2.16 PILLARS OF QUALITY MANAGEMENT SYSTEM

Top part of the quality temple is build upon the foundation of following pillars.

2 .16 .1 QUALITY PROCESSES/QUALITY PROCEDURES/WORK INSTRUCTIONS

Quality processes, quality procedures, work instructions, methods, etc. are defined at an organisation level by the functional area experts, and at project and function level by the experts in those areas separately. Organisation level processes act as an umbrella, whereas project and function level processes are in the purview of these top-level process definitions. Organisation level set of processes may differ from the process definition for different projects and functions. It is also defined as quality planning at project level. Quality procedures must be in sync with the tone established by quality manual at an organisation level.

2.16.2

G U ID ELI N ES AN D S TAN D ARDS

Guidelines and standards are used by an organisation's project team for achieving quality goals for the products and services delivered to customers. Many a times, guidelines defined by customers are termed as standards for the project, as the project team takes the recommendations by customers as mandatory. Difference between a guideline and a standard is defined as, shown in Table 2.3.
Table 2.3 Difference between guidelines and standards

Guidelines A.) Guidelines are suggested ways of doing things. They are made by experts in individual fields. B.) Guidelines may be overruled and there is no issue if somebody does not follow it. C.) Guidelines may or may not be written. Generally it is recommended that one must write the guidelines to capture the tacit knowledge.

Standards A.) Standards are mandatory ways of doing things. These are also described by experts in respective fields. B.) Overruling of standards is a punishable offence. It may lead to nonconformance during reviews and audits. C.) Standards must be written to avoid any misunderstanding or loss of communication. Guidelines and standards may need revision from time to time. Revisions must be done to maintain suitability over a time period.

2 .16 .3 FO RM ATS AN D TEM PLATES Common formats and templates are used for tracking a project, function, and department information within an organisation. It creates same understanding across the board where outputs can be compared for the projects and

functions. This also acts as a checklist to maintain consistency across the projects in the organisation. Formats and templates, if made compulsory, are considered as standards whereas if they are indicative or suggestive, they are considered as guidelines. Generally templates are mandatory while formats arc suggestive in nature.

2.17 IMPORTANT ASPECTS OFQUALITY MANAGEMENT

Quality improvement is not an accident but a planned activity. An organisation must plan for improvement under the leadership of management and with employee participation. 2 .17 .1 QU ALI TY PLAN NI N G AT O RG AN IS ATIO N L E V E L- : ********* Not es N ot A v ail abl e********* *********Further Notes Available On E Book*********