Software Project and Quality Management

SOFTWARE PROJECT AND QUALITY MANAGEMENT
UNIT I
NOTES
INTRODUCTION
CHAPTER 1
PRODUCT LIFE CYCLE
INTRODUCTION TO THE UNIT This chapter covers the life cycle of a software product for software industry. It is products that give rise to projects and hence a good understanding of the project life cycle will help in understanding the project life cycle. The study of various projects and the sampling projects were also discussed. UNIT LEARNING OBJECTIVES After learning this chapter the learner will have a wide knowledge of the following: Introduction to product life cycle Idea Generation Initial Prototype Development Alpha Testing Beta Testing Production Maintenance and Obsolescence.
1.1 INTRODUCTION TO PRODUCT LIFE CYCLE A product life cycle consists of the following phases: 1. Idea generation 2. Initial prototype development 3. Alpha testing 4. Beta testing 5. Production 6. Maintenance and obsolescence
1 ANNA UNIVERSITY CHENNAI
DBA 1728
NOTES
1.2 IDEA GENERATION Inputs from 1. Customers which contain their multiple requirements. 2. Suppliers that may open up new opportunities to introduce new features or exploit technology better. 3. Employees. 4. Competitive information and marketplace demands. Various type of projects that the idea generation phase generated: 1. Study the requirements of customer XYZ and come up with a list of features they 2. want. 3. What new enhancements can be made to feature ABC in our product. 4. What kind of bugs were filed against our product in the previous version(s)? Identify the root causes. 5. Study the competition and find out why we lost those sales. 1.3 PROTOTYPE DEVELOPMENT PHASE Prototyping builds simplistic model of the final product and putting together a demo. The demo addresses issues such as 1. User interface. 2. Look and feel. 3. Work flow. Various type of project generated during prototyping phase are : 1. User Interface Specification and design. 2. Target Market Positioning. 3. Work Flow Specification. 1.4 ALPHA PHASE The main objective of the Alpha phase is to move from a skeleton prototype to a somewhat usable product. Various type of project developing from the Alpha phase are : 1. Migrate data from the existing system. 2. Get the internal application XYZ on the new product. 3. Formulate some of the standards to be followed during the product development.
ANNA UNIVERSITY CHENNAI
1.5 BETA PHASE The purpose of the Beta phase is to more functionality is added and the existing functionality is refined. The product is also tried at certain external customer sites. The external customers work as trusted partners, testing the untried functionality of the product, being fully aware that the product may have problems. If the number of Beta customers is too small, then there will not be sufficient variety of tests nor the diversity of testing environments. A variety of other activities and projects get started. Some of these projects are: 1. Getting documentation ready. 2. Planning the installability of the product. 3. Setting up support teams and processes to attend to customers problems. 4. Formation of special teams dedicated to attend to specific customers. 1.6 PRODUCTION PHASE Different types of projects and activities come into play with increased emphasis: Process Teams
NOTES
The process-oriented projects gain momentum during the production phase. There would, for example, be a Standards team, a Configuration Control team and a tooling team. Training
The project teams in this case would necessarily have to be cross functional the developers, the marketing people, curriculum developers and instructors. Documentation
This project will encompass decisions such as the format of the documentation, choice of the distribution media, etc. Testing
Testing projects covers taking lessons from the Alpha and Beta phases and putting them into test suites. Supportability
This generates a slew of projects: Engineering the code to be more diagnosable, and putting in the support infrastructure (e.g. , hiring and training the support staff, etc.) becomes very critical at this juncture.
DBA 1728
NOTES
Marketing Programs
There would be a set of projects requiring the product designers and the marketing teams to work in unison in order to put together Marketing Programs 1.7 MAINTENANCE AND OBSOLESCENCE PHASE During the maintenance phase, some of the issues that arise are: 1. How to you classify an incoming problem as a bug or a request for a new feature? 2. How to you prioritise the incoming problem? 3. How to you balance the workload on development of future versions with the maintenance activity? The maintenance phase activities are usually bug fixes and therefore each bug fix itself can be considered a separate project; but given the short term nature of a bug, this view is normally not taken. Table: 1.1 Product Life Cycle and resulting sample projects
Phase Idea generation Prototype
Alpha Phase
Beta Phase
Production
Maintenance and Obsolescence
Types of projects Competitive analysis Customer feedback analysis Product-past history analysis User interface design Work flow simulation Internal application XYZ upgrade / install project Developments teams Data migration Preliminary training Customer liaison Evolving process for standards, change control, etc. Product development Installation Documentation Supportability Product development Testing Preparing training material User documentation Installability Supportability Usually big fixes; very difficult to classify as projects
Summary In this chapter we have described the product life cycle procedures for software products indicating few examples of various projects of software industry. It also includes Introduction to product life cycle-Idea Generation-Initial Prototype Development-Alpha Testing-Beta Testing-Production- Process Teams, Training, Documentation, supportability and marketing programs-Maintenance and Obsolescence. The procedure given in the product life cycle can be applied to service industry of IT products also. Further insights of software projects can be discussed in the next unit. Review questions 1.Inputs from Customers which contain their requirements. a. Single b. Double c. Multiple d. None of the above 2.builds simplistic model of the final product and putting together a demo a. Prototyping b. Model c. Analysis d. Validation 3. The main objective of the Alpha phase is to move from a skeleton prototype to a somewhat product a. Multiple b. Usable c. Not usable d. None of the above 4. The purpose of the Beta phase is to functionality is added and the existing functionality is refined a. More b. less c. greater d. None of the above 5. The process-oriented projects gain momentum during the production phase. a. product-oriented b. process-oriented
5
NOTES
DBA 1728
NOTES
c. system-oriented d. None of the above 6. The maintenance phase activities are usually bug a. Fixer b. Remover c. Cleaner d. None of the above 7. Define Product. 8. What is alpha phase? 9. Why we go for Beta phase? 10. What are the inputs for idea generation phase? 11. What are the steps taken to initiate a prototype development phase? 12. Define Testing. 13. What is the need for studying maintenance and obsolescence phase? 14. Explain the various projects applicable to various phases of product life cycle? 15. Describe in detail about the product life cycle of a Network software industry? 16. Why Testing phase considered to be very important? Explain its significance? 17. Take any case about the software products and apply the steps you have studied in the product life cycle and explain its advantages and limitations. 18. Consider the applicability of the life cycle activities discussed in the following nonsoftware scenarios: a. Launch of a new automobile model You are the General Manager of a large automobile company in India, with some foreign equity. You are evaluating which models of cars you want to launch into the Indian markets in the next three years. Your company already has several models in the market and you want to ensure that you are not cannibalizing an existing product. During the last few years, there has been an increased emphasis on the construction of roads and flyovers; but parking space is becoming a problem in most Indian cities. In addition, road safety is also a serious issue. Besides, fuel costs are going up and fuel efficiency would become a very essential component of whatever models you choose. For each of the above scenarios, describe: a. Which participants would you consult to get such ideas? b. What criteria would you consult to get such ideas? c. What criteria would you use to evaluate the ideas?
d. What criteria would you use to arrive at the mix of things you would do (assuming you do try multiple things and not just one) i.e., the project portfolio? e. What constraints would you face? f. What would be the equivalents of Alpha Test and Beta Test activities for the solution?
NOTES
g. What feedback mechanism would you provide to encapsulate the learning from similar previous efforts? 19. Why should the alpha testing of a product not ne done with external customers straightaway? 20. How mny beta customers should a product have? What are the essential attributes that a customer must have to be a beta customer? What commitments should the product development organization make to beta customers?
DBA 1728
NOTES
CHAPTER 2
PROJECT LIFE CYCLE MODELS
INTRODUCTION TO THE UNIT This chapter basically describes the various project life cycle models and its applicability. The main contents of the project life cycle models are classical waterfall model, iterative waterfall model, prototyping model, evolutionary model, spiral model. The project life cycle model also describes the advantages, disadvantages, applications suitability and limitations. UNIT LEARNING OBJECTIVES After reading this chapter the learner may find the usefulness of the project life cycle model for software industry. Explanation of Classical and Iterative waterfall model. Prototyping model and its application Evolutionary model and its usefulness Spiral model and its variants.
2.1 CLASSICAL WATERFALL MODEL The classical waterfall model divides the life cycle into the phases shown in below figure. This model breaks down the life cycle into an intuitive set of phases. The different phases of this model are: feasibility study, requirements analysis and specification, design, coding and unit testing, integration and system testing, and maintenance. The different phases starting from the feasibility study to the integration and system testing phase are known as the development phases. The part of the life cycle model between the feasibility study and product testing and delivery is known as the development part. At the end of the development part of the life cycle, the product becomes ready to be delivered to the customer. The maintenance phase commences after completion of the development phase.
Feasibility study Requirement analysis and specification Design Coding and unit testing Integration and system testing Maintenance
Figure 2.1: Classical waterfall model.

2.1.1 Feasibility Study The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product. The feasibility study activity involves the analysis of the problem and collection of all relevant information relating to the product such as the different data items which would be input to the system, the processing required to be carried out on these data, the output data required to be produced by the system, as well as various constraints on the behavior of the system. The collected data are analyzed to arrive at the following: An abstract problem definition. An abstract problem definition is a rough description of the problem which considers only the important requirements and ignores the rest. Formulation of the different solution strategies. Analysis of alternative solution strategies to compare the benefits and shortcomings.
NOTES
2.1.2 Requirements Analysis and Specification The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely requirements gathering and analysis, and requirements specification. 2.1.3 Requirements gathering and analysis The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed with a view to clearly understanding the customer requirements and weeding out the incompleteness and inconsistencies in these requirements The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. For example, to perform the requirements analysis of a business accounting software required by on organization, the analyst might interview all the accountants of the organization to ascertain their requirements. The data collected from such a group of users usually contain several contradictions and ambiguities, since each user typically has only a partial and incomplete view of the system. Therefore, it is necessary to identify all ambiguities and contradictions in the requirements and resolved them through further discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly understood, the requirements specification activity can start. During this activity, the user requirements are systematically organized into a Software Requirements Specification (SRS) document.
DBA 1728
NOTES
2.1.4 Requirements specification The customer requirements identified during the requirements gathering and analysis activity are organized into a SRS document. The important components of this document are the functional requirements, the nonfunctional requirements, and the goal of implementation. Documenting the functional requirements involves the identification of the functions to be supported by the system. Each function can be characterized by the input data, the processing required on the input data, and the output data to be produced. The non-functional requirements identify the performance requirements, the required standards to be followed, etc. The SRS document is written using the end user terminology. This makes the SRS document understandable by the customer. After all, it is important that the SRS document be reviewed and approved by the customer. The SRS document normally serves as a contract between the development team and the customer. Any future dispute between the customer and the developers can be settled by examining the SRS document. It is therefore an important document which must be thoroughly understood by the developer team, and reviewed jointly with the customer. The SRS documents provides not only the basis for carrying out all the development activities, but also the basis for several other documents such as the design document, the users manuals, the system test plan, etc.
Input
System
Output
Black-box view of a system. 2.1.5 Design The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the soft ware architecture is derived from the SRS document. Two distinctly different design approaches are available: the traditional design approach and the object-oriented design approach. 2.1.6 Traditional design approach The traditional design approach is currently being used by many software development houses. Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. This is followed by a structure design activity. During structured design, the results of structured analysis are transformed into the software design.
Structured analysis involves preparing a detailed analysis of the different functions to be supported by the system and identification of the data flow among the different functions. Data flow diagrams (DFDs) are used to perform structured analysis and to document the results. 2.1.7 Object-oriented design approach Object-oriented design (OOD) is a relatively new technique. In this technique, various objects that occur in the problem domain and the solution domain are first identified and the different relationships that exist among these objects are identified. The object structure is further refined to obtain the detailed design. The OOD approach has several benefits such as lower development time and effort, and better maintainability of the product. 2.1.8 Coding and Unit Testing The purpose of the coding and unit testing phase of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end- product of this phase is a set of program modules that have been individually tested. A coding standard addresses issues such as the standard ways of laying out of the program codes, the template for laying out the function and module headers, commenting guidelines, variable and function naming conventions, the maximum number of source lines permitted in each module, and so forth. During the phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage. 2.1.9 Integration and System Testing During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. System testing usually consists of three different kinds of testing activities: Alpha-testing: It is the system testing performed by the development team; Beta-testing: It is the system testing performed by a friendly set of customers. Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product.
NOTES
11
DBA 1728
NOTES
2.1.10 Maintenance Maintenance of a typical software product requires much more effort than the effort necessary to develop the product itself. Maintenance involves performing any one or more of the following three kinds of activities: Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving the implementation of the system, and enhancing the functionalities of the system according to the customers requirements. This is called perfective maintenance. Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance.
2.2 ITERATIVE WATERFALL MODEL Feedback paths are needed in the classical waterfall model from every phase to its preceding phases as shown in figure to allow for the correction of the errors committed during a phase that are detected in later phases.
Feasibility study Requirement analysis and specification
Design Coding and unit testing
Integration and system
12
NOTES
Time Distribution of effort over time for various phases in the iterative waterfall model. Some of the glaring shortcomings of the waterfall model are the following: The waterfall model cannot satisfactorily handle the different types of risks that a reallife software project is subjected to. For example, the waterfall model assumes that the requirements be completely specified before the rest of the development activity can start. Therefore, it cannot accommodate the uncertainties that exist at the beginning of most of the projects. As a result, it cannot be satisfactorily used in projects where only rough requirements are available at the beginning of the project. To achieve better efficiency and higher productivity, most real-life projects cannot follow the rigid phase sequence imposed by the waterfall model. A rigid adherence to the waterfall model creates blocking states in the system. That is, some team members would have to wait for a phase to be complete before they can start their next activity. This is clearly a wastage of resources and such wastages are rarely tolerated in real projects. For example, if an engineer works fast and completes the design of the parts assigned to him early, he should not idle, waiting for the others to complete their designs. Instead, he should proceed to the next phase. 2.3 PROTOTYPING MODEL The prototyping model suggests that before carrying out the development of the actual software, a working prototype of the system should be built. A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software. An important
DBA 1728
NOTES
purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customers needs. In this regard, the prototype model is very useful in developing the Graphical User Interface (GUI) part of a system. The prototyping model of software development is shown in figure. In this model, product development starts with an initial requirements gathering phase. A quick design is carried out and the prototype is built. The developed prototype is submitted to the customer for his evaluation. Based on the customer feedback, the requirements are refined and the prototype is suitably modified. This cycle of obtaining customer feedback and modifying the prototype continues till the customer approves the prototype. The actual system is developed using the iterative waterfall approach. However, in the prototyping model of development, the requirements analysis and specification phase becomes redundant as the working prototype approved by the customer becomes redundant as the working prototype approved by the customer becomes an animated requirements specification.
Requirements gathering
Quick design
Refine requirements incorporating customer suggestions
Build prototype
Customer evaluation of prototype
Acceptance by customer
Design
Implement
Test
Maintain
Prototyping model of software development

2.4 EVOLUTIONARY MODEL This life cycle model is also referred to as the successive versions model and sometimes as the incremental model. In this life cycle model, the software is first broken down into several modules which can be incrementally constructed and delivered. The development team first develops the core modules of the system. This initial product skeleton is refined into increasing levels of capability adding new functionalities in successive versions. Each evolutionary version may be developed using an iterative waterfall model of development. The evolutionary model is shown in figure.
C B A A B A
NOTES
2.5 SPIRAL MODEL The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with requirements specification, the next one with design, and so on. This model is much more flexible compared to the other models, since the exact number of phases through which the product is developed in this model is not fixed. The phases we mentioned are just examples and may vary from one project to another. For instance, it is possible that for some other project the design might be accomplished over three or four consecutive loops and in some other project the design might be over in just one loop. A,B,C are modules of a software product that are incrementally developed and delivered Evolutionary development of a software product.
R o u gh re q u irem en ts sp e c ifica tio n Id e n tif y th e co re an d o th er p arts to b e d ev e lo p ed in cre m e n tally D ev e lo p th e co re p a rt u sin g a n iterativ e w a te rfall m o d el C o llec t cu s to m e r fe ed b a c k an d m o d ify req u ire m en ts D ev e lo p th e n e x t id e n tifie d fe atu res u s in g an itera tiv e w aterfa ll m o d el A ll fea tu res co m p le te M ain ten a n ce
Evolutionary model of software development

DBA 1728
NOTES
Spiral model of software development Each phase in this model is split into four sectors as shown in figure. The first quadrant identifies the objectives of the phase and the alternative solutions possible for the phase under consideration. During the second quadrant, the alternative solutions are evaluated to select the best solution possible. For the chosen solution, the potential risks are identified and dealt with by developing an appropriate prototype. A risk is essentially any adverse circumstance that might hamper the successful completion of a software project. Activities during the third quadrant consists of developing and verifying the next level of the product. Activities during the fourth quadrant concern reviewing the results of the stages traversed so far with the customer and planning the next iteration around the spiral. With each iteration around the spiral, progressively a more complete version of the software gets built. After several iterations along the spiral, all risk are resolved and the software is ready for development. At this point, a waterfall model of software development is adopted. The radius of the spiral at any point represents the cost incurred in the project till then, and the angular dimension represents the progress made in the current phase.
16
Summary This chapter discusses various models of software project life cycles and their applicability. It should be noted that in real life situations, the actual life cycle model could be a combination of the features of one or more of the above models. These models are basically to be the guidelines rather than be prescriptive. At the end of the day it is important not to twist the natural and most appropriate way of working on a project to suit the above models. Review questions 1. What is a life cycle model for a project? 2. What are the principles behind the waterfall model? 3. Explain the advantages, disadvantages and applicability of the waterfall model? 4. Describe the waterfall model with suitable examples? 5. What are the main principles adopted in the prototyping model? 6. List out the advantages, disadvantages and the applications of prototyping model? 7. What are the basic moralities of Evolutionary model? 8. Explain the key advantages, disadvantages of Evolutionary model? 9. Explain the various conditions applicable for the Evolutionary model? 10. Describe the features of the Spiral model and its variants? 11. Briefly explain the key advantages, disadvantages of the Spiral model? 12. Is the Waterfall model always incpplicable in the case of projects with a very short life cycle? Give a counter-example if it indeed is applicable. 13. Let us assume that you are developing a general purpose accounting software for use by multiple customers. Which life cycle model would you choose to use? What adaptations would you make to the chosen models? 14. In todays hosted model of deployment, new versions are hosted on the Internet and customers try out the latest versions from the Internet. Discuss the applicability of the various models (discussed in this chapter) to the present day scenario. 15. Describe at least one scenario where Waterfall model is preferable to all other models?
NOTES
17
DBA 1728
NOTES
CHAPTER -3
PROCESS MODELS
INTRODUCTION TO THE UNIT This chapter covers the detailed methodology of process models and its application towards software industry. The chapter explains the concepts of product, process, What constitutes in effective process? And process models ie ISO 9001-quality system elements, CMM model, five broad characteristics of CMM (Key practice) and common misconceptions about process and SEI CMM Model. UNIT LEARNING OBJECTIVES After reading this chapter, the learner will know the following things in detail: Product Process Process Model ISO 9001 quality system elements CMM Model 3.8 SEI - CMM Model.
3.1 PRODUCT A product is something that is deliverable to an internal or an external customer 3.2 PROCESS A process is of documented and followed way that constitutes one or more steps in producing & product characteristics of a process 1. Each process has a well defined set of inputs that it operates on 2. Each process produces and set of outputs that are used as inputs to other processes 3. Each process has & set of steps that are to be followed to produce outputs from the inputs. 4. Each process fet engineered by a set of criteria 5. \each process has a set of success measures 6. The successful execution of each process is verifiable by & set of quality records. 7. Finally, each process has an owner who is authorized to change the process
3.3 WHAT CONSTITUTES IN EFFECTIVE PROCESS? 1. Start with what is being practiced 2. Document what is being practiced 3. Ensure that the process are adaptable to & no of projects 4. Train the staff on the use of the documented process 5. Demand and enforce the use of processes 6. Measure the effectiveness of compliance to the process 7. Ensure that the processes are amendable for continuous improvement. 3.4 PROCESS MODELS ISO 9001 & SEIs SW-CMM for s/w industry ISO came up with ISO-9001-3 2000 version of ISO 9001 is a common std. 3.5 ISO 9001 QUALITY SYSTEM ELEMENTS 1. Management 2. Quality system 3. Contract review 4. Design control 5. Document & data control 6. Purchasing 7. Control of customer supplied products 8. Product identification & Traceability 9. Process control 10. Inspection & Testing 11. Control of Inspection, measuring and test equipment 12. Inspection & test status 13. Control of non-conforming product 14. Corrective & preventive action 15. Handling, storage, packaging, preservation & delivery 16. Control of quality records 17. Internal quality audits 18. Training 19. Servicing 20. Statistical techniques
19
NOTES
DBA 1728
NOTES
3.6 CMM MODEL Five broad characteristics of CMM (key practice) Hierarchy of estimates 1) 2) 3) 4) 5) commitment to perform ability to perform activities performed measurements verification Requirement management Configuration management S/w quality assurance Sub contractor management Project planning Project tracking Org process focus Org process definition Integrated s/w management Training programs s/w product engineering Inter group coordination Peer review Quantitative Process mgmt s/w quality mgmt defect prevention process change mgmt technology change mgmt 1) Customer 2) Organization 3) Employee 4) Share holder 5) Stake holder
20
NOTES
Why are the process important 1. Reduced time to market 2. Simplification of training of employees 3. Quality is more predictable and consistent 4. Scope for improvement Any KPAS in CMM has 5 broad characteristics called key practices 1. commitment to perform 2. ability to perform 3. activity performed 4. measurements 5. verification Common misconceptions about process 1. process inhibit creativity 2. process 3. processes do not apply to short cycle time projects 4. certification is just & marketing activity
21
DBA 1728
NOTES
What is CMM? A commonsense application of process mgmt and quality improvement concepts to software development and maintenance A community developed guide A model for organizational improvement
What the CMM does not cover? Issues that are addressed only directly, or by implication include specific tools methods and technologies concurrent engg & team work system engg, marketing, etc human resources organizational behavior
3.7 SEI CMM MODEL

Optimizing(5) focus on process improvement Continuously improving process Managed process (4) measured controlled Predictable process
Defined (3) Process characterized fairly well understood
Std consistent process Repeatable (2) In repeat previously mastered tasks Disciplined process Initial (1) Unpredictable & poorly controlled
Summary This chapter discusses the two process models- the ISO 9001 Model and the CMM. The following conclusions can be drawn from this chapter: 1. Process models are introduced only to enhance the predictability and consistency of the product quality. 2. ISO 9001 and CMM are just two popular process models. 3. ISO 9001 and CMM embody commonsense, sound business practices. 4. Even though we have separately described the ISO and CMM Models, these are not completely apart, As both ISO and CMM address common practices it is natural that the CMM KPAs and ISOs 20 clauses have some commonality. 5. Following some of these well-defined process models sets the stage for continuous improvement. Review questions 1. Define product and process. 2. What are the characteristics of a process? 3. What constitutes an effective process? 4. Why are the processes are important? 5. Explain the elements of ISO-9001 model with an example? 6. What is CMM? 7. What are the characteristics of CMM? 8. Explain the various key process areas of CMM? 9. What are the common misconceptions about processes? 10. You are the purchase manager for a leading software company. It is your job to purchase all the hardware and software required for all the projects while keeping in mind criteria like: reasonable costs, predictable quality and timeliness of deliveries, reliability of service after the sale, etc,. Being with a software organization which has young, bright ( and often impatient!) people, you may get requests from various people saying, this is required very urgently, As a purchase manager, you also need to endure that the purchase is duly authorized. As the purchase involves money, it is likely to be under the close scrutiny of the management (and auditors) and hence it is you responsibility to ensure that the quality records/ audit trails are in order and at the same time, the quality and timeliness goals are satisfied. Design a set of processes to satisfy the above requirements. Document each process using the guidelines given in the text and also present a block diagram showing the interaction between the various processes.
23
NOTES
DBA 1728
NOTES
11. The following extract from a document describes the activities/ start criteria / end criteria for a project initiation process. Comment on what is wrong in each case and suggest corrective action to make them complaint with the suggestions given in the text i. Start criteria: The project initiation shall happen at the earliest possible opportunity after the management approvals are obtained ii. End criteria: The project is deemed successful and complete when the customer is satisfied. iii. Activities: 1. As the first step in project initiation, ensure that the travel needs are documented 2. the incoming hardware is checked for absence of disk errors 3. the project manager, the executive director or the president signs off the Requirements Specifications 12. Both ISO and CMM embody commonsense approaches and sound business practices. Work out a mapping to show which clauses of ISO-9001 correspond to which Key Process Areas of Software CMM. 13. Do all the KPAs of SW-CMM apply in all situations in an organisation? Give examples when certain KPAs are not applicable. 14. Study the other common process models ( One example is SPICE) and identify the areas of synergy and differences between them, and the ones discussed in the text.
24
UNIT II
NOTES
PROJECT MANAGEMENT PROCESS AND ACTIVITIES

CHAPTER-4
PROJECT INITIATION
INTRODUCTION TO THE UNIT This chapter covers project initiation activities for a well planned software projects. The contents of this chapter are Introduction, In-Stream Activities. Project Initiation., Activities during Project Initiation, Management Team Building, Scope and High level work division agreements, Management Reporting and Escalation Procedures, Involvement of Infrastructural/ Support Groups, Team formation, Project Kick-off Meeting UNIT LEARNING OBJECTIVES After reading this chapter the learner will experience in starting a software project with various activities mentioned inside the chapter. 4.1 INTRODUCTION Project initiation starts with project life cycle activities ie In-stream activities. However umbrella activites takes place throughout the life cycle of a project. Let us discuss in detail about the In-steam activites. 4.2 IN-STREAM ACTIVITIES In-stream activites takes place sequentially and only at some specific times during the project life cycle. The steps adopted in In-Stream Activties are: i. Organizational and operational processes.
ii. The project plans for the various projects/products in the organization (Schedule, resources, etc.) iii. Snapshots/status information on the various projects that gives a point in time view of the projects (Progress, Status reports, alarms, etc.)
DBA 1728
NOTES
iv. Metrics about the projects (End goal metrics, In-process Metrics) v. Lessons Learnt form the project (What went right, what went wrong, etc) 4.3 PROJECT INITIATION Project Initiation is an activity that marks the formal start of a project the senior managements also identifies a project manager whose charter is to take the responsibility and work towards achieving these high level goals. In case of a geographically distributed team, local project managers are usually identified at this stage. 4.4 ACTIVIES DURING PROJECT INTIATION 1. Management Team Building 2. Scope and very high level work division agreements. 3. Decision of management reporting/escalation proecedures 4. Involvement of Infrastructure/supports groups 5. Team formation 6. Project kick-off meeting 4.5 MANAGEMENT TEAM BUILDING i. It enters the team members to understand one another and to build a cohesive management team.
ii. Minimize the impact of cultural and language barriers iii. It is a sign of commitment 4.6 SCOPE AND HIGH LEVEL WORK DIVISON AGREEMENTS i. Verifying that the scope is clearly documented and consistently understood by all the members concerned
ii. Identifying any obvious bottlenecks or impossible constraints and alerting the management on these points iii. Doing some initial risk analysis and contingency/mitigation planning. 4.7 MANAGEMENT REPORTING AND ESCALATION PROCEDURES 1. Whose reponsisbility is to document the programs and actions? 2. who would track the action items to completion? 3. what would be the time out period for resolutions/responses to issues raised? 4. There should be a uniform understanding with respect to prioritizing the issues and the time frames in which to except resolution of these issues based on the set priorities. 5. Who would be the receipents of the reports and what action would they be expected to take on the reports?
6. What would the level of detail, content and format of the status reports? 7. What would be the modalities of communication between the various groups: Travel? Conference Calls? What would be the frequency? 4.8 INVOLVEMENT OF INFRASTRUCTURAL/ SUPPORT GROUPS A project group does not operate in isolation. For success, it requires the active participation, support and co-operation of other infrastructure groups. i. HR groups
NOTES
ii. Facilities Managmenet Group iii. Administration Group iv. Hardware Infrastructure Group v. Finance vi. Coporate Quality group vii. Senior Management Needs from this Infrastructure group for this project Aggregate & Optimize Aggregate Plan to satisfy Infrastructure Group (HR) organizational Need from this group in an optimal way Needs from this infrastructure group for this project Fig : 4.1 Operation of the infrastructure groups 4.9 TEAM FORMATION Team formation is related to the hiring activity. In geographically distributed project teams, a seed team is formed first and the planning starts later. Various teams joined together for the project to the extent support from the management team. Once the people come on board this rapport building must percolate down to the next level through personal visits, videoconferencing etc., 4.10 PROJECT KICK-OFF MEETING 1. The Project manager arrives at some initial estimate of the service levels and resources needed from each of the infrastructure groups and conveys the same to them in a project kick-off meeting. 2. The infrastructure groups take these inputs in the context of similar information they have from the other project groups and arrive at an estimate. 3. The Infra groups work together to identify common dependencies among themselves.
Project Group1
Project Group n
DBA 1728
NOTES
4. The infra groups come up with the aggregate plans and optimize optimally. 5. As and when the requirements for the project change, the project groups convey them to the infra groups who in turn fine-tune their processes to cater to the changing scenarios. 4.10.1 The requirements for a project to be successful are i. Delivery demands
ii. Government Regulations iii. Minimizing Time iv. Building Team-work 4.10.2 Outputs of Project Initiation i. A statement of understanding of what the requirements and constraints of the project are
ii. A statement of understanding of the requirements from the support. Infrastructure groups. iii. Identified set of people to work on the project forming a seed team with clear hiring targets. Summary A planned and executed projects initiation usually has very good project relationships. The intensity of some aspects like team building depends on the relationship that already exists between the different project team members and whether they have already worked together. The activities like scope review and requirements definition, a certain amount of formulism is usually in order and is also effective. The challenge of the project initiation is striking a balance between formulism and relationship building in the initial stages. Review Questions 1. What are the project in-stream activities? 2. Explain the various activities during project initiation? 3. What are escalation procedures in the project initiation? 4. List out the various support groups of project initiation activities? 5. When does project kick-off meeting takes place? 6. An audit of an organization revealed that there were 3 different maitainance projects and that each of them had its own methods and procedures for what is essentially the same generic function. Do you think this is acceptable? Now assume that the organization is embarking on a forth maintainence project. You are the quality manager of the organization and you are at the kick-off meeting for this new project. How would you add value to the meeting and to the project?
CHAPTER-5
PROJECT PLANNING AND TRACKING
NOTES
INTRODUCTION TO THE UNIT This chapter covers the components of project planning and tracking, identification and qualification of goals arriving at work breakdown structure and size estimates (the WHAT part), prioritization of features and translating size estimates to effort estimates (The WHAT COST part), identifying dependencies and milestones, (the When part) tailoring of organizational processes for the project (the HOW part) work assignment (by WHOM part) etc., UNIT LEARNING OBJECTIVES After reading this chapter the learner will have a wide knowledge in the implementation of project planning and tracking of software industry. The components learnt are Contents (The What Part) WBS Execution Money, Quality of Design and Conformance (The What Cost Part) Schedules (The When part) Internal Milestones. Processes (The How Part) Assigning Resources (By Whom Part)
5.1 INTRODUCTION The project planning and tracking consists of five components mainly: i. Contents (The What Part)
ii. Money, Quality of Design and Conformance (The What Cost Part) iii. Schedules (The When Part) iv. Processes (The How Part) v. Assigning Resources (By Whom Part) 5.2 CONTENTS (The What Part) The What needs to be delivered (project scope) and it will translate into features to deliver. On what platforms and in what environments and mainly the success measures of the project and Work Breakdown Structure.
DBA 1728
NOTES
Work Breakdown Structure [WBS] WBS is the decomposition (dividing) of the project into smaller and more manageable parts called WBS units, with each part satisfying the following five criteria: i. Each WBS unit has a clear outcome
ii. The outcome has a direct relationship to achieve the overall project goal. iii. Each WBS unit has a single point of accountability iv. Each WBS unit is can be tracked and monitored as an unit v. Each WBS unit has a well defined interface to other WBS units. Other important points followed in WBS are: i. Estimation of the size of final product more accurately
ii. Explore the re-use possibility iii. Identifying various range of still sets required for the project iv. Scheduling of machine resources v. WBS can utilize the resources (Hardware) at the maximum vi. Linking WBS units with milestones as a means of measuring progress vii.Partitioning the work needed for the entire project and milestones the timeframe is also important viii.An ideal WBS delivers meaningful interfaces ix.The biggest advantage of WBS is easy to specify, debug and Maintain. 5.3 WBS EXECUTION It starts with module design and proceeds to module development. Module testing plays the major role here. It is divided into various units and their output is integrated and tested accordingly. The success factors of WBS are: 1. Identification of Logical Components : Starts as Logical components and ends as functional components. 2. Identifying Discrete components of a project 3. Accurate Deliverables is necessary : Examples are Requirement Specification documents or Test case design document or Source code or Size estimate. 4. Identifying well-defined Interfaces: 5. Reducing communication overheads between WBS units. 6. Provision for autonomy and authority for WBS units is necessary.
30
5.4 MONEY, QUALITY OF DESIGN AND CONFORMANCE (The What Cost Part) The what cost part is about understanding the constraints clearly and accounting for them in the project plan so that constraints are not violated. To understand the scope of the work and focuses on how to get maximum. Once the requirements crystallize into stated requirements, they should be prioritized as per the following list: 1. Features of the product should be possessed, we call it has unique selling propositions 2. Desirable in a product should be very high 3. Low priority and effort estimation : The technologies, projects and skill sets of individual should be similar. Re-use are considered to minimize cost. 5.5 SCHEDULES (THE WHEN PART) The when part is about timelines of when we will deliver what parts of the project or the product. Project tracking is about ensuring timeline targets and target time by completing each activity as per the schedule. 1. Identification of external dependencies ie Staffing, Training, Acquisition and commissioning of new hardware, availability, completion of modules , products from other projects and vendors. 2. Identification of Internal Milestone 5.6 INTERNAL MILESTONES Internal milestones are measurable and quantifiable attributes of progress, they are intermediate points in the project to ensure the right track and it is fully controlled by project manager Characteristics of Internal Milestones 1. Milestones are outcome based 2. Should be reasonable time intervals to the duration of the project 3. It should be absolute 4. Communication to all the team members is a must. 5.7 PROCESSES (The How Part) The how part should specify what processes are to be followed, how they are different from the processes currently being used in the organization. How to re-use the existing processes and fine-tune them for the specific needs of the project.
NOTES
31
DBA 1728
NOTES
1. Identifying and using certain processes, as they are, without any modifications 2. Continuance of an existing process by making some minor changes to it to reflect its application in the case of a particular project 3. Deleting some of the process that are not applicable to the project 4. Addition of new processes for a project 5.8 ASSIGNING RESOURCES (By Whom Part) The whom part lays out the roles and responsibilities of the various members and expectation. Development is based on the local team. 1. People Resource Allocation 2. Roles and Responsibilities 3. Staffing Plans 4. Escalation and Reporting Mechanisms Summary Project planning and tracking is a continuous activity that takes place throughout the project life cycle. It ensures pro active planning and detecting changes that can result in controlled reactions. The effectiveness of changes comes by experience and by taking into considerations the learnings from the previous projects of similar type. The learnings are covered in the project closure phase which is discussed in the next chapter. Review questions 1. What is project planning? 2. What is project tracking? 3. List out the components of project planning and tracking? 4. What is work breakdown structure? 5. How will you work the WBS work software products? 6. How is WBS executed? 7. What are the factors that determine the success of effective WBS units? 8. What are the categories of cost part of a project plan? 9. Identify the difference between internal milestones and external dependencies? 10. Is it appropriate to call project planning and tracking as in-stream activities? What characteristics do they share with the umbrella activities? What are the differences.
32
CHAPTER-6
PROJECT CLOSURE
NOTES
INTRODUCTION TO THE UNIT This chapter covers the project closure happenings and explicit closure of a project, project closure processes, issues discussed during project closure and metrics for the project closure. UNIT LEARNING OBJECTIVES After reading this chapter the learner will have a knowledge in the following: Project Closure Processes Metrics for Project Closure
6.1 INTRODUCTION Project closure refers to the conclusion of a project or some logical part of the project. The release of a given version can be taken as a closure of the development project for that version. Also as the beginning of the maintenance phase for that particular version. The deliverables of the project closure are: 1. the actual product or service that the project was aimed to deliver to the customer 2. The learning process or the knowledge acquired through by executing the project by the organization. 6.2 PROJECT CLOSURE PROCESSES The project closure processes objective is the entire team working on the project should participate in the closure. Project teams from different locations and infrastructure providers, etc. The meeting should have a point of focus, the focus should be on learning ie the major discussions should on the issues and accusation of people should be avoided in order not to deviate the objective. Preparation for the meeting is a must. Everyone should address the meeting in order to voice their views regarding the project. The following are the suggested process 1. The project manager is the leader for the closure 2. Project manger gives instructions to the members to come prepared on the agenda. 3. Vertical Distribution: The process of learning is divided into several areas and each member is asked to come prepared on a specific area 4. Horizontal Distribution: Members are asked to introspect in the entire project with no boundaries.
DBA 1728
NOTES
5. The PM provides a framework to each member which is used for preparing the presentation 6. Document the proceedings of the closure meeting and sends them to the top level management 7. Identify common organization wide problems and tries to resolve such problems 8. The process team analyses the entire contents of the closure reports so that a common process is identified and in order to generalize and make it as abstract The useful points that has to be discussed during the project closure are: 1. Are the goals are achieved properly? 2. Does the in-process metrics is useful? 3. Any over-achievement or under-achievement? 4. Is it estimation is correct? 5. Any system gain from the environment? 6. Was the use of communication channel is appropriate? 7. Any changes or adoptions carried out so that organizational process is applicable to this project 8. Did we set and use customer feedback appropriately? 6.3 METRICS FOR PROJECT CLOSURE 1. Size variance 2. Effort Variance 3. Software tools enhancements 4. Employee Satisfaction. Summary This chapter has discussed the best practices and how it is practiced, understanding of past mistakes, and ensuring not to repeat. It also provides a formal framework to achieve the above said. Combining the information captured at the project closure stage and using it along with the information capture through the duration of the project. Review Questions 1. When does project closure happen? 2. Why should we explicitly do a closure process? 3. What are the characteristics of a effective closure process? 4. List out the suggestions for the effective closure process? 5. Explain in detail the issues that get discussed during project closure? 6. Describe the various metrics for project closure?
UNIT III
NOTES
ENGINEERING ACTIVITIES
CHAPTER-7
SOFTWARE REQUIREMENTS GATHERING
INTRODUCTION TO THE UNIT This chapter has focused mainly on the software requirements and the collection of the reaquirements for the software industry. The main components of the software requirements gathering are dimensions of requirements gathering, steps that happen during requirements gathering, responsibilities, current system requirements, targets and ongoing needs. UNIT LEARNING OBJECTIVES After reading this chapter the user may find the details of software requirements and their components. Requirements Engineering Responsibilities Current System Requirements Targets Ongoing Needs.
7.1 INTRODUCTION In this chapter, we try to understand the issues regarding requirements and What requirements engineering is. We know that problems in requirements affect all subsequent phases. We will try to see how to go about eliciting, analyzing, documenting and reviewing requirements so that problems due to requirements in later phases are minimized. Problems in requirements typically lead to incorrect estimates, creation of an unsatisfactory system and frequent changes. Many errors in requirements definition are passed undetected to later phases of the life cycle and correcting these errors during or after implementation becomes extremely costly. Focusing on the requirements engineering activities we can increase the probability of delivering a much better system and reduce the cost incurred due to correction and rework.
DBA 1728
NOTES
7.2 REQUIREMENTS ENGINEERING IEEE standard 610.12.1990 defines requirement in the context of a software project as follows: 1. A condition of capability needed by a user to solve a problem or achieve an objective; 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents; 3. A documented representation of a condition or capability as mentioned in the points one and two. 7.2.1 Software Requirements The definition of software requirements as Any function, constraint or other property that must be provided, met, or satisfied to fulfill the need of the systems intended user(s) The term requirements is used to refer all the requirements ie functional or nonfunctional. Functional requirements typically focus on the what of the system and identify the functions and data related requirements. Non-functional requirements focus on the how well aspects of the system and identify attributes like performance, maintainability, scalability, iner-operability, reliability, portability and the constraints under which the system needs to operate. Requirements Defintion consists of: 1. Requirements gathering of requirements 2. Requirements Analysis or modeling 3. Requirements Documentation 4. Requirements Review Requirements Management consists of: 1. Requirements change management: It involves systematic handling of changes to agreed requirements (SRS) during the course of the project 2. Requirements Traceability: It consists of maintaining traceability between the agreed (and changed) SRS and the other work products (like design documents, test plans) cerated downstream in the software life cycle. (Though these activities are listed in a sequential order, the process is iterative with each activity revisited many times.) 7.2.2 Dimensions of Requirements Gathering Requirements gathering can be viewed as maximizing customer satisfaction at the end of the project and not in the narrow context of a technical process just to capture the
functionality requirements of a given system. Requirements Management is made up of four dimension: 1. Responsibilities 2. Current system needs 3. Targets 4. Ongoing needs 7.3 RESPONSIBILITIES Responsibilities can be further divided into Single contact/Sign-off authority, Organizational SLAs, Change Control Norms and Statutory Compliance. 7.3.1 Single Contact/Sign-off Authority: Single Point of contact starts with customer organization for stating and arbitrating the requirements. It was nominated by the Top Management of the customer organization. Generally, the single point of contact would be Head, Information systems or the Chief Information Officer. This single point of contact knows the complete requirements of the organization and articulates the needs. The single point of contact nominates the module owners who can give specific details of these individual components. Sometimes single point of contact act as a tie-breaker in the case of conflicts (in the case of multiple and conflicting requirements).The single of point contact eventually decides which requirements should take precedence. During the requirements gathering two points are clarified namely, clarification of certain unclear or conflicting issues that need clarification from the customer and if the requirements are agreed upon initially may change later on. 7.3.2 Service Level Agreement (SLA) SLA address the response time to queries for resolving any conflicts. Since requirements eventually translate into costs and schedules. It includes response to queries like how long would the single point of contact take to resolve conflicts? 7.3.3 Change Control Norms Change-control addresses procedures to request, identify, evaluate changes in requirements. When the system definition is evolving, changes will take place almost continually, such changes can be aggregated and consolidated. 7.3.4 Statuary compliance Statuary process can be followed in customer organization, in turn it has to be followed by the development organization also.
NOTES
37
DBA 1728
NOTES
7.4 CURRENT SYSTEM REQUIREMENTS Current system requirements can be further divided into Functionality, Performance, Availability, Security and Environmental. 7.4.1 Functionality The following are the aspects to be covered under functionality requirements: 1. What are the sub-components that make up the system? 2. What are the inputs and outputs of each module? 3. What is the business logic in each module? 4. What is the persistent data that is maintained by the system? 5. What are the interfaces between the modules? 6. What are the external interfaces that the product should present? 7. What is the relationship between this system to manual system or other legacy systems? 7.4.2 Performance The following are the parameters to be gathered in performance requirements are : 1. 2. 3. 4. Data storage requirements Maximum number of users expected on the system Peak loads that can be expected on the system in terms of transactions Throughput that the system must satisfy
5. Expected Response time for transactions 7.4.3 Availability Needs The following are the factors that up-time expectations include: 1. Amount of Redundancy to be built into the system 2. Sophistication of the underlying tools like databases 3. Operational issues like scheduling of back-ups and the resultant demands on speed of such operations. 7.4.4 Security The following are the issues addressed by the security requirements are 1. Who are the authorized users of the system? 2. How are they authenticated? 3. What access rights do each of the users have on various business modules, inputs and outputs 4. Who is an authorized person to administer the security rights?
7.4.5 Environmental The following are the issues regard to the environmental definition: 1. Specification of any constraint with regard to software and hardware platforms of the system should run. 2. The hardware and software platform influence the performance of the system. 7.5 TARGETS Targets can be further divided into success measures and acceptance criteria. 7.5.1 Success Measures The following are the issues address the success measures 1. Are there any drop-dead dates on completion? 2. Is there a limit on the rupee amount that can be spent on the project? 7.5.2 Acceptance Criteria Meeting the needs of the customer is tested using acceptance criteria. It is characterized by the following factors: 1. Acceptance criteria is specified early in the development cycle 2. Independence of implementation 3. It reflects the real life use of the product 4. It covers all aspects of requirements. 7.6 ONGOING NEEDS Ongoing needs basically include the non-software part of the product. It includes documentation, Training and ongoing support. 7.6.1 Documentation Some of the kinds of documentation required for a product are: 1. Installation guides 2. On-line help 3. Design and Internal documentation 4. User manuals
NOTES
39
DBA 1728
NOTES
7.6.2 Training There are different levels of training for different people: 1. The users may need training on the modules they would be using 2. The system administrators on providing security, back-up, restore, etc/ 3. The developers in the customer organization have to be trained on the actual programs. 7.6.3 Ongoing support The following are the questions to be addressed 1. What constitutes a requirements change and how to handle it? 2. For how often are codes fixes needed? 3. For how long should the product be maintained? 4. What are the things that cannot be changed? Summary Capturing the requirements sets the scene for the software product to be designed, developed and deployed.\ Review questions 1. Under what circumstances would environmental constraints be identified at the requirements gathering phase itself? 2. Who should specify the acceptance criteria for the project and why? 3. How do the activities during requirements gathering change with projects with rapidly changing needs and different life cycle model used? 4. Explain in detail the dimensions of requirements gathering? 5. Discuss the advantages and disadvantages of having the requirements gathering done by someone with no domain expertise in the area of system being developed?
40
CHAPTER -8
SOFTWARE ESTIMATION
INTRODUCTION TO THE UNIT This chapter covers the estimation of software products. The main components of the software estimation are size estimate, effort estimate, schedule estimate and cost estimate. The software estimation methodology is also discussed in this chapter. UNIT LEARNING OBJECTIVES After reading this chapter the learner will have a wide exposure to software estimation practices and methodologies. 8.1 INTRODUCTION TO SOFTWARE ESTIMATION Software requirements become clearer, the software organization as well as the user organization want to have a reasonably accurate estimate of the cost of development and the time frame within which the development will be completed. Software estimation is particularly important because it decides the execution boundaries of the project in terms of the resources that will be made available for the project execution and the duration of such availability. It also determines whether or not the project is considered feasible in terms of cost and the ability to meet the required end date. In case of software development project to be executed by external vendors, estimates from the basis of contract between vendor software organization and the customers organization. This contract lays down what the vendor will deliver, when he will deliver and the money that will paid by the customer. Many contracts also specifies stiff penalty for delay or poor quality. Software organizations need to be able to quote to the user organization in terms of project delivery time and total cost. The estimates typically become targets when the project proceeds to the stages of detailed planning and execution. Improper estimates can lead to a variety of problems for both software organization and user organization, example (i) In case of an overestimate the bidding software organization may loose a project, because a competing software organization has estimated more accurately and quoted lower. (ii) In case of underestimate, the software organization will make a loss and also delay the delivery of sotware. The delay can cause disruption to the user organization and also invites penalty on the software organization. The problem with the estimation is that the project manager is trying to quantify the cost, effort and delivery period before completing the design. Estimates made for the
41
NOTES
DBA 1728
NOTES
purpose of preparing the quotation are usually made on very sketchy requirement definition. As more information become available, estimates can become more accurate, but the need and the criticality of the doing the estimate will reduce. Unfortunately most projects starts with wrong estimates and therefore planned with lesser resources and unrealistically tight schedule. Estimation often suffer due to incomplete knowledge, lack of time, and various competitive pressures that are directly and indirectly put on the estimator to arrive at more acceptable estimates. The common conclusion in estimation, and in people examining estimates is the confusion between calendar time and man power requirement. Calendar time is the time between the start date and the end date of a particular project. As against this, the man power required is expressed as personmonth of the effort that go into the project. The effort of project is in person-months which are arranged over time to complete the project within the required calendar time. Since mangers are concerned with both effort and schedule, both are to be estimated. Before we go any further, we need to define the term estimate. A dictionary meaning of estimate is A tentative judgment of the approximate value, worth, cost, size are other attributes of significance. For a software project, we are interested primarily in estimating the cost and duration of the project. To arrive at these, we need to have a fix on the size of the software that is to be developed. Since a major part of the cost of any software project is the effort expended by the skilled software developers, accurate estimation of effort is the key to accurate estimation of cost and schedule.
Software Requirements Specifications Other Project Parameters Size Estimation Customer Imposed Schedule Effort Estimation Other Cost Components Schedule Estimation Cost Estimation
Figure 8.1 Components of Software Estimation

8.2 SIZE ESTIMATE The size of the software to be developed is one of the parameters to be estimated. This forms the basis for estimating the amount of work to be done, so that the effort and schedule can be estimated. If the size is estimated in terms of functionality that the user shall obtain from system, it is also a measurement that tells you the user what the system shall do and what has to be paid for. Size estimation can also be relevant for valuing existing software assets or estimating maintenance cost for existing software. Some size measures of software are Line of code, No of function points, No of objects, No of reports, etc. 8.3 EFFORT ESTIMATION The estimate for the man power that is required for software product. This is the major cost constituent in any software project. Along with the schedule estimate it determines the team size and build up. Effort is normally measured in terms of person-hour or persondays with conversion factors to convert from one measurement unit o another. It is driven by size and many project related factors such as skill and capability of the team , the language and the platform to be used, the availability and suitability of the platform, the stability of team, the level of automation that will be employed, etc. 8.4 SCHEDULE ESTIMATE Schedule is the duration between the start of the project and the end of the project. Schedule estimate may include the high level intermediate milestones, like end of various phases. Estimate is at project level, and is not a substitute for the detailed task wise scheduling, which forms the basis for project planning and control. It may or may not meet the customer or end users need. In case of the customer needs the software earlier than what is estimated in the first iteration of the estimate, the effort estimate may need to be revised to meet the customer imposed schedule. 8.5 COST ESTIMATE The estimate of cost for a software project. A major component of cost is the man power cost in any software project. Apart from that other cost such as travel, communication facilities, project specific training, hardware and software for the project team need to be estimated. These along with manpower cost can be used to estimate the total cost of the project. To convert the art of estimating the into a scientific process that satisfies the rigors of an engineering discipline, software estimation needs to be based on well defined estimation methods. These estimation methods or combination of methods together should have certain characteristics.
NOTES
43
DBA 1728
NOTES
8.6 THE ESTIMATION METHODS (i) Should be able to convert requirements into one or more size estimates. (ii) Should specify how effort, schedule and cost can be derived from the size estimate and other project characteristics. (iii) Must take into account variation in important project execution characteristics, such as life cycle models selected, skill level, platform stability, user characterisctics, requirements stability, use of automation in software development and process maturity of development teams processes. (iv) Must be person independent. (v) Must qualify the estimates with certain degree of accuracy or tolerance. (vi) Must support re-estimation at various phases of a project, to provide more accurate estimate. Some of the causes associated with problems in estimation are listed below: (i) Estimation without integrity: Often what the customer is willing to pay or what the competitor is quoting, drives the estimate. The competition and customers budget are important factors for a quotation, they cannot drive the estimate. (ii) No time to estimate: Often quotation preparation and estimation is performed in the Want it Yesterday Mode. This forces the estimator to bypass the process and make hasty assumptions leading to grossly inaccurate estimates. There are instances were projects worth hundreds of person months are estimated in one or two days. (iii) Incomplete or incorrect requirements: If many of the requirements are incorrect or missing , the estimates will be inaccurate irrespective of the sophistication of the estimation methods. Which is why we need to conform that the requirements are correct and complete. Before starting to compute the estimates. (iv) No past data available: Estimates should not only be based on the requirements, but also on the past data on productivity and factors that influence productivity. Many organizations do not have past data. Some that do have the past productivity data notice considerable variance between projects, but do not analyze and document the reason for this variance. This becomes a handicap when estimating for a new project. (v) Productivity is independent of size of software: It is obvious that as the size of software increases, the effort to build software increases. What is not obvious is that the size increases, the effort increases exponentially. (vi) Productivity is independent of imposed schedule: If there are more team members in the project, the interactions and misunderstandings, due to interactions will grow exponentially and the effort to deliver the project will no longer be in expected person-months.
44
8.7 THE KEY PROJECT FACTORS THAT INFLUENCE EFFORT ESTIMATES ARE 1. Availability and stability of the development environment 2. Team capability and experience 3. Team stability 4. Maturity of processes 5. Accounting of reusable software available 6. Estimating for reusable software to be built 7. Extent of communication possible with the user or customer 8. Extent of automated tools used for software development & maintenance 9. Cohesion of state holders and teams Summary This chapter has covered various components of software estimation like size, effort, cost and schedule. Review questions 1. Explain the various components of software estimation? 2. Describe the methodology followed in software estimation? 3. Does the choice of estimation model depend on the life cycle model choosen? 4. Your project is in the maintainence mode, fixing bugs in the products. What size estimates would you apply for this?
NOTES
45
DBA 1728
NOTES
CHAPTER -9
DESIGN AND DEVELOPMENT PHASE
INTRODUCTION TO THE UNIT This chapter aims for salient features of design and development phases. The salient attributes of design address the following: Evolving an Architecture / Blueprint Design for Reusability Technology choices / Constraints Design to Standards Design for Profitability User Interface Issues Design for Testability Design for Diagnosability Design for Maintainability Design for Instability
UNIT LEARNING OBJECTIVES How the users requirements will finally be realized The first visualization of the product takes place Development is the actual realization of the design Design and development are probably the most technical activities in a software product life cycle Which design methodology to use, what algorithm to choose What data structures to deploy, the implementation trade-off
9.1 SALIENT FEATURES OF DESIGN 1. Evolving an architecture / blueprint 2. Design for re-usability 3. Technology choices / constraints 4. Design to standards 5. Design for profitability 6. User interface issues
7. Design for testability 8. Design for diagnosability 9. Design for Maintainability 10. Design for installability 11. Inter- operability design 9.2 EVOLVING AN ARCHITECTURE / BLUEPRINT The Architecture of a system identifies the various units of the system These units can be viewed as building blocks Also identifies how these basic building blocks communicate (interface) with one another Example: Object oriented paradigm Building blocks = Basic Objects that make up a system (own data and method) These object represent the modules of the design level Acts as bridge between required and implementation Enables early identification of dependencies Serves as the basis to performing preliminary scheduling estimation and costing
NOTES
9.3 DESIGN FOR REUSABILITY The building blocks identified during the architecture serve as a good starting point to attempt Re-Use Possible trade- off one has to make between performance and Re-use Reusable across multiple instances, some generalization would have to be made To identify the re-use opportunities, it lies in the existence of a systematic and consistent down of design Detail of functionality, input and output of the various building blocks Some of the case tools that exist in the market provide such functionality
9.4 TECHNOLOGY CHOICES / CONSTRAINTS Choice of the enabling system software, versions, etc (eg: compilers, Integrated development environment (IDE). Choice of Infra structure S/W (database, etc) Choice of utility tools (back-up, diagnostics, etc) Make vs buy decisions for some of components
47
DBA 1728
NOTES
9.5 DESIGN TO STANDARDS I. External standards Characterise external product behavior Compliance to a published long syntax Compatibility to a set of call level interfaces (JDBC) Adherence to a common protocol (eg: WAP) Reflecting a standard user interface Some of the common attributes of external standards are : They are not proprietary They are published by an authorized consortium Compliance or adherence is objectively determined by successful passing of certain pre-defined text II Internal standards Determine what mechanisms are to be followed internally to deliver the product Documented processes specifies what logistics are to be followed during development Includes coding standard, documentation standard, testing standard, etc They proprietary in nature They pertain to the methods of realization of product rather than the product itself Customers would normally not get to know the internal standard fallowed by the development organization When consistent internal standard are fallowed a. Gets more speed in employees b. Provides more job rotation c. Skill acquisition opportunities 9.6 DESIGN FOR PROFITABILITY If a software product is to run on multiple platforms, then profitability should be kept as a design criteria and the product must be designed accordingly Some of the principles that can be followed for designing for profitability are a. Separating out generic functionality and platform specific functionality b. Laying down standard means of communication between generic and platform specific functionality c. Using portable development environments
9.7 USER INTERFACE ISSUES a. Different types of users like different types of interfaces b. Consistency of platform Look-AND-Feel c. Context sensitive online help d. Context sensitive option display e. Personalization User interface should be customizable with mass personalization as a goal, especially in the context of the internet. 9.8 DESIGN FOR TESTABILITY a. Identification of test data to ensure that the design reflects the requirements precisely and that development reflects the design b. Modularization with clear specification of inputs and outputs c. Specification of limiting conditions and the action limiting conditions. Eg: How many concurrent users should be allowed to log on? How much cache should be allocated to store the recently used d. Error conditions and how they are handled 9.9 DESIGN FOR DIAGNOSABILITY [tracing the root cause from symptoms] a. Providing enough foot prints Which modules got called in what sequence What are the parameters passed from one module to the next What were the return values from each module to the caller module b. c. Making the context self contained Simple condition is violated is the use of global variables in programming languages Having self identifying data structures 1. Not taking care of boundary conditions 2. Not checking the limits of an array 3. Infinite loop wiping out the contents of memory d. Providing validatable redundancy in data structures
NOTES
9.10 DESIGN FOR MAINTAINABILITY How do we fix the problem? a. b. Module level accountability Clear single point of accountability for a module Usage of proper code or design
DBA 1728
NOTES
c.
Proper documentation Cross-reference documentation refers to documenting which modules are called by a given module Change history documentation is done by any person making the actual changes to keep track of what changes are made Serves as audit trail to track down the changes Template for module documentation covering cross reference document and change history recording
Module identifier: Module name: Module description: Module owner: Module input parameters: Module output parameters: Module logic specifications: CROSS REFERENCE DOCUMENTATION Called modules: CHANGES: CHANGED BY CHANGED DATE CHANGE DESCRIPTION
9.11 ESIGN FOR INSTALLABILITY a. It should conform to a standard look and feel. Eg: windows platform. b. Should be consistent in the presentation and processing format c. Should be easy to install and should ideally require no documentation d. Where documentation is necessary, it should be completely in sync with the actuall installation e. Should assume intelligent, context sensitive defaults
50
INTER- OPERABILITY DESIGN a. How is the inter-operability of the multiple systems achieved? To enable data interchange the design should take care of Providing data structures that take care of what data needs to go in and out Input and output data to A/C for different in data formats and required across systems Handling the M/C specific issues of data stored in various systems b. c. d. How can data be migrated from one system to another? How can the more recent version of the S/W access data be created in older versions? Is there a call level compatibility across different versions?
NOTES
9.12 CHALLENGES DURING DESIGN AND DEVELOPMENT PHASES a. I dont need design, I am in RAD mode! b. That cool one line change! c. Design change control and need for feedback d. Anticipating future growth length of fields, storage requirement and transaction volumes e. Keeping documentation current through changes 9.13 SKILL SETS FOR DESIGN AND DEVELOPMENT Metrics for design and development phases It exits for cohesion,coupling,complexity,interface etc. a. How well does design/development reflect the require? b. How often did the design change because subsequent phases could not move ahead using the current design? The quality of design could have an impact on more than just the development phase. It could well extend into the maintenance phase Summary Design and development are the ideal phases for the software development team. This chapter provides a framework that enables the designer to look into the total cost of the product development.
51
DBA 1728
NOTES
Review questions 1. Describe the salient features of design phase? 2. What are the challenges faced during design and development phase? 3. What are the skill set required for design and development phase? 4. Explain the metrics used for design and development phase?
52
CHAPTER-10
PROJECT MANAGEMENT IN THE SOFTWARE TESTING
INTRODUCTION TO THE UNIT This chapter discusses various methods of testing to ensure a quality product. The main components of the testing phase are: Software Testing Fundamentals Software Testing Objectives Software Testing Principles Good Test Attributes Software Testability The Six Essentials of Software Testing Person Responsible for Testing Importance of Testing Outcome of Testing The Work Product of Testing The Steps Involved in Testing Verification Testing Formal Structure Type of Verification Validation Methods validation Activities Integration Testing Options High Level Testing Validation Testing Configuration Review Acceptance Testing System Testing The Debugging Process Software Testing Tools Project Management in the Testing Phase Management structures for Systems in Global Teams Metric for Testing Phase Role of Testing in Software Life Cycle
53
NOTES
DBA 1728
NOTES
UNIT LEARNING OBJECTIVES After reading this chapter the user will have a very good scope for implementing the testing tools and methodologies in a software industry. 10.1 DEFINITION Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user. Testing refers to activities that are carried out to ensure that the final software product meets the requirements that the product is intended to satisfy. 10.2 SOFTWARE TESTING FUNDAMENTALS Testing is intended to demolish the software that has been built QUESTION: Is testing really destructive? NO, testing is done to correct the software and improve its quality by finding a high probability of errors. 10.3 SOFTWARE TESTING OBJECTIVES Testing is the process of executing a program with the intent of finding errors. A good test case is one with a high probability of finding an as-yet undiscovered error. A successful test is one that discovers an as-yet-undiscovered error.
10.4 SOFTWARE TESTING PRINCIPLES All tests should be traceable to customer requirements. Tests should be planned long before testing begins. The Pareto principle (80% of all errors will likely be found in 20% of the code) applies to software testing. Testing should begin in the small and progress to the large. Exhaustive testing is not possible. To be most effective, testing should be conducted by an independent third party.
10.5 GOOD TEST ATTRIBUTES A good test has a high probability of finding an error. A good test is not redundant. A good test should be best of breed. A good test should not be too simple or too complex.
10.6 SOFTWARE TESTABILITY Operability: the better it works the more efficiently it can be tested. Observability: what you see is what you test. Controllability: the better software can be controlled the more testing can be automated and optimized. Decomposability: by controlling the scope of testing, the more quickly problems can be isolated and retested intelligently. Simplicity: the less there is to test, the more quickly we can test. Stability: the fewer the changes, the fewer the disruptions to testing. Understandability: the more information known, the smarter the testing.
NOTES
10.7 THE SIX ESSENTIALS OF SOFTWARE TESTING Essential 1: The quality of the test process determines the success of the testing effort. Essential 2: Prevent defect migration by using early life-cycle testing techniques. Essential 3: The time for software testing tool is now. Essential 4: A real person must take responsibility for improving the testing process. Essential 5: Testing is a professional discipline requiring trained, skilled people. Essential 6: Cultivate a positive team attitude of creative destruction. 10.8 PERSON RESPONSIBLE FOR TESTING Software Developer: Tests the software during early stages of testing. Test specialists & Independent test group: Performs testing during later stages. 10.9 IMPORTANCE OF TESTING Every time a program is executed, the customer tests it, therefore, we have to execute the program before it gets to the customer with the specific intent of finding and removing all errors. 10.10 OUTCOME OF TESTING Errors Requirements conformance Performance Indication of quality
DBA 1728
NOTES
10.11 THE WORK PRODUCT OF TESTING A set of test cases to exercise both internal logic and external requirement is designed and documented, expected results are defined, actual results are recorded. 10.12 THE STEPS INVOLVED IN TESTING Software is tested from two different perspectives: 1. internal program logic is exercised using white box test case design techniques. 2. software requirements are exercised using block-box test case design techniques. In both cases, the intent is to find the maximum number of errors with the minimum amount of effort and time. 10.13 VERIFICATION TESTING Basic verification methods verification is a human examination or review of the work product. 10.14 ORMAL STRUCTURED TYPES OF VERIFICATION Inspection: The objective of inspections is to obtain defects and collect data and to communicate important work product information. Walkthroughs: Walkthroughs are less formal than inspections mainly because of the lack of preparation. In walkthrough the participants simply come to the meeting; the presenter prepares (usually the author of the product), and theres no additional effort by the participants prior to the meeting. Buddy checks: Any form of human testing, even undisciplined testing, is better than none, provided it is performed by someone other than the author and objective is to detect defects. GETTING LEVERAGE ON VERIFICATION Check list: the verification tool. Verifying documents at different phases. Verifying requirements Verifying the functional design Verifying the internal design Verifying the code
56
Three Critical Success Factors For Implementing Verification Success factor 1: Process ownership Success factor 2: Management support Success factor 3: Training 10.15 VALITATION METHODS Test Case Design Strategies: [fundamental testing strategies] Black-box or behavioral testing: Knowing the specified function a product is to perform and demonstrating correct operation based solely on its specification without regard for its internal logic.
NOTES
Definition: Is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. Black-box Methods for function-based tests the following methods are commonly used Equivalence partitioning Boundary value Analysis Error guessing
White-box Methods for internals-based Test Statement coverage Decision (branch) coverage Condition coverage Path coverage
10.16 VALIDATION ACTIVITIES Validation activities can be divided into the following: 1. Low-level testing i. Unit testing / module
ii. Integration testing 2. High-level testing i. Validation testing
ii. System testing iii. Acceptance testing
57
DBA 1728
NOTES
Low-level testing Low-level testing involves individual program components, one at a time or in combination. It requires intimate knowledge of the programs internal structure and is therefore most appropriately performed by developer.
Unit testing Unit or module testing is the process of testing the individual components (subprograms or procedures) of a program. The module interface is tested to ensure that information properly flows into and out of the program under unit test. The local data structure is examined to ensure that data stored temporarily maintains its integrity during all steps in an algorithms execution. Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing. All independent paths through the control structure are exercised to ensure that all statements in a module have been executed at least once. Finally, all errors handling paths are tested.
10.17 INTEGRATION TESTING Integration testing is the process of combining and testing multiple components together. The primary objective of integration testing is to discover errors in the interfaces between the components. 10.18 OPTIONS Big bang approach: In the non-incremental big bang integration all components are combined at once to form the program. The integrated result is then tested. Incremental integration: Incremental integration is where we unit test the next program component after combining it with the previously tested components. There are two approaches to integration to incremental integration: Bottom-up integration Top-down integration
Bottom-up integration The steps in bottom-up integration are: Begin with the terminal modules of the hierarchy. A driver module is produced for every module.
58
The next module to be tested is any module whose subordinate modules have been tested. After a module has been tested, its driver is replaced by an actual module and its driver.
NOTES
Top-down integration The steps in top-down integration are: Begin with the top modules of the hierarchy. Stubs module produced and some may require multiple versions. Stubs are often more complicated than they first appear. The next module to be tested is any module with at least one previously tested super ordinate module. After a module has been tested, one of its stubs is replaced by an actual module and its required stubs.
10.19 HIGH LEVEL TESTING 10.20 VALIDATION TESTING Validation succeeds when software functions in a manner that can be reasonably expected by customer.
10.21 CONFIGURATION REVIEW (OR) AUDIT An important element of the validation process is a configuration review. The intent of the review is to ensure that all Elements of the software configuration have been properly developed, are cataloged, and have the necessary detail to bolster the support phase of the software life cycle. 10.22 ACCEPTANCE TESTING ALPHA TESTING The alpha test is conducted at the developers site be customer. The software is used in a natural setting with developer looking over the shoulder of the user recording errors and usage problems. Alpha tests are conducted in a controlled environment.
BETA TESTING The beta test is conducted at one or more customer site the end-user of the software. Unlike alpha testing, the developer is generally not press. There fore, the Beta test is a live application of software in an environment that can not be controlled by developer.
DBA 1728
NOTES
10.23 SYSTEM TESTING System testing is the process of attempting to demonstrate that a program or system does not meet its original requirements and objectives, as stated in the requirements specification.
Types /goals of system testing are as follows Volume testing: to determine whether the program can handle the required volumes of data requests, etc. Load /stress testing: to identify peak load conditions at which the program will fail to handle required processing loads with in required time spans. Security testing: to show that the programs security requirements can be subverted. Usability testing: to identify those operations that will be difficult or inconvenient for users. Publications, facilities, and manual procedure are tested. Performance testing: to determine whether the program meets its performance requirements. Resource usage testing: to determine whether the program users resources (memory, disk space etc) at levels which exceed requirements. Configuration testing: to determine whether the program operates properly when the software and hardware is configured in a required manner.
10.24 THE DEBUGGING PROCESS Debugging is not testing, but it always occurs as a consequence of testing. The debugging process begin with execution of a test case. Results are assessed and lack of correspondence between expected and actual is encountered.
Debugging approaches In general, three categories of debugging approaches may be proposed. Brute force Backtracking Cause elimination
10.25 SOFTWARE TESTING TOOLS The use of testing tools can make testing easier, more effective and more productive. A wide variety of computer- aided software testing (CAST) tools are available, addressing many aspects of the process.
Categorizing test tools There are a number of ways to categorize testing tools: 1. By the testing activity or risk in which it is employed. Eg., code verification test planning, test execution. 2. By descriptive functional keyword. Eg., capture /playback, logic coverage, comparator. 3. By major area of classification. Eg., grouping of tools, a small number of high level classes. Tools for Reviews and Inspections The types of tools required are: Complexity analysis Code comprehension Syntax and semantic analysis
NOTES
Tools for Test Planning The types of tools required for test planning are Templates for test plan documentation Test schedule and staffing estimates Complexity analyzer Tools that help with reviews and inspections will also help with test planning
Tools for Test Design and Development Test data generator Requirements based test design tool other tools Capture /playback Coverage analysis
Test Execution and Evaluation Tools The types of tools required for test execution and evaluation are: Capture /playback Coverage analysis Memory testing Test case management
61
DBA 1728
NOTES
10.26 PROJECT MANAGEMENT IN THE TESTING PHASE WHAT IS TESTING Testing refers to activities that are carried out to ensure that the final software project meets the requirements that the product is intended to satisfy. THE ACTIVITIES OF TESTING Test includes the following activities Test specification Test design Test development Test registration Test execution Test maintenance
10.27 MANAGEMENT STRUCTURES FOR TESTING IN GLOBAL TEAMS INTEGRATED TESTING TEAM MODEL In the above model there is one project manager who manages both the development and testing functions. DEDICATED TESTING TEAM MODEL In this model the testing team report directly to the next level of senior management. Thus the conflict between operational delivery responsibility and testing responsibility are avoided. Testing team in geographically distributed product teams Hybrid models
62
10.28 METRIC FOR TESTING PHASE
SIGNIFICANCE The greater the code coverage, the fewer are the chances of the existence of Code coverage untested pieces of code. Hence the chances of deviations from their behavior are also lower. Number of defects that get The purpose of testing is to detect the Caught after the testing phase presence of defects. Thus post-testing defects indicate possible improvement areas in testing. Also, if problems get detected after the testing phase, then the chances are that the customers are encountering the problems. This adds to the direct and indirect costs. Rate of reappearance of Is an indication of the effectiveness of problems the regression tests, if a particular set of problem keeps re-appearing in different versions, it means that the regression tests have not been planned properly.
10.29 ROLE OF TESTING IN SOFTWARE LIFE CYCLE Point to Note There is one to one correspondence between development and test phases in there respective life cycle. 10.30 SOFTWARE TESTING-REFERENCE TO SOFTWARE QUALITY MANAGEMENT SYSTEMS/MODELS: ISO 90F00 COMPATIBILITY ISO 9000 contains three clauses which are concerned with testing. 13.4.10 Inspection and Testing 13.4.11 Control of inspection, measuring and test equipment 13.4.12 Inspection and Test Status 10.31 CMM COMPATIBILITY An organized process of testing is part of the LEVEL 3 KPA- Software Product Engineering. Activity 5,6,7 of Software Product Engineering KPA deal with Testing activity.
METRIC
NOTES
63
DBA 1728
NOTES
CMMI SE/SW/IPPD STAGED CMMI Staged contains two process areas in the Maturity Level 3 DEFINED which are concerned with testing. Verification Validation CMMI SE/SW/IPPD CONTINUOUS CMMI Continuous representation contains two process areas in the Maturity Level 4 QUANTITATIVELY MANAGED which are concerned with testing. Verification Validation Summary Testing is an area which provides the project manager with some of the most complex management challenges. After testing the product goes out to the customers and enters into the maintenance phase. Review Questions: 1. Define testing? 2. What are the Software Testing Fundamentals? 3. Explain the Software Testing Objectives? 4. Describe the Software Testing Principles and Test Attributes? 5. List out the Six Essentials of Software Testing? 6. Who are the Person Responsible for Testing? 7. What are the outcomes of Testing? 8. What are the steps involved in testing a software product? 9. Define Verification Testing? 10. Explain the Formal Structure Type of Verification? 11. Describe the Validation Methods and validation Activities? 12. What is Integration Testing? 13. Differentiate high level testing versus low level testing? 14. What is Configuration Review? 15. Explain the Acceptance Testing and System Testing? 16. What is Debugging Process? 17. Briefly explain the Software Testing Tools? 18. What are the phases in the Project Management of the Testing Phase? 19. Explain the Metric for Testing Phase?
CHAPTER -11
PROJECT MANAGEMENT IN THE MAINTENANCE
NOTES
INTRODUCTION TO THE UNIT This chapter focuses the software maintenance phases. The activities carried during the maintenance phase is listed below: 1. problem reporting 2. problem resolution 3. solution distribution 4. proactive defect prevention The various types of maintenance is also covered in this chapter. UNIT LEARNING OBJECTIVES After reading this chapter the user will have a wide knowledge in the maintenance of the following: Relative Cost of Maintenance Maintenance Categories Seven Step Approach Project Management in the Maintenance Phase Management Issues during the Maintenance Phase Pull Model.
Why Maintenance? Migration becomes the need of the day for the S/W to adapt itself to the change S/W maintenance is more to do with fixing errors or with evolution
11.1 DEFINITION OF MAINTENANCE Is a set of S/W engineering activities that occur after S/W has been delivered to the customer and put into operation. Cause for maintenance: Change of require accounts for the majority of maintenance effort. The only S/W which is not subject to change, is S/W which never gets used.
65
DBA 1728
NOTES
Focus is on change based on: 1. Error correction 2. Adaptations required due to change of S/W environment 3. changes due to enhancements brought by changing customer requirements. All this done on EXISTING CODE. 11.2 RELATIVE COST OF MAINTENANCE 3% Required def 3% Preliminary design 5% Detailed design 7% Implementation 15% Testing 67% Operation & maintenance
Software Evaluation: A continuous change from a lesser, simpler or worse state to a higher or better state. Software maintainer: Person whose mission is to support existing S/W systems 11.3 MAINTENANCE CATEGORIES a. Corrective b. Adaptive c. Perfective 11.3.1 Corrective Change the software to correct defects found by customer, focuses on fixing defects, Is a reactive process - Defects generally needed to be corrected either immediately or in the near future.
11.3.2 Adaptive Is the modification to the software to accommodate changes to external environment Includes all work related to how the software functions relates to enhance software functionality. Includes all changes to meet the evolving needs of the user and environment system changes, additions, insertion, deletions, modification, extensions and enhancements
66
11.3.3 Perfective Includes all efforts to improve the quality of the software. Includes restructuring code, creating and updating documentation, improving reality or efficiency.
NOTES
The maintenance process Begins When a request for change is initiated by a user Ends When the system passes testing, is accepted by the user and is released for operation In between There are many activities that must be planned and coordinated by use of change management. Change request or error report is input Analyze impact Update regarding- including quality assurance and configuration management Issue revised system
11.4 SEVEN STEP APPROACH 1. change management 2. Impact analysis 3. system release planning 4. design changes 5. coding 6. testing 7. system release Change management To uniquely identify, describe and track the status of each requested change. Impact analysis Identifies all system product affected by a request change request developing an estimate of the resources needed to accomplish the change System release planning To establish the schedule of system releases, determine the contents of a system
DBA 1728
NOTES
Design changes To develop a revised logical (system level) and physical (program level) design for the change Code To clarify existing code and simplify changing it. Software testing - Easier to test incrementally. - Data collected during impact analysis is identifies what must be tested at each level System release - Documents, software, training, hardware, other product. - Deliver the system to the user Install the system release with backup procedures ACT= KLOC added + KLOC deleted KLOC total 11.5 PROJECT MANAGEMENT IN THE MAINTENANCE PHASE The maintenance phase deals with the process of evaluating the customers product changes requirement ascertaining its applicability making the necessary changes to the product Testing that the requested change is implemented Delivering the change to the affected user
Activities during the maintenance phase: 1. problem reporting 2. problem resolution 3. solution distribution 4. proactive defect prevention Solution Distribution: when should the fix be sent to the customer? Should it be sent as soon as it is made & the product re-built? Distributing multiple small fixes not only cuts into the resources but also introduces multiple configuration to support
1.
To accumulate multiple fixes into a patch for an immediate release These release are usually cumulative
NOTES
Proactive Defect Prevention: Analyzing common user errors & updating documentation as necessary 2. 3. 4. 5. no of errors is more (user errors) or documentation is not very clear provide on line help initial understanding of the product requirements is unclear
Analyzing common user errors & changing the product as necessary Publishing common user errors & work-arounds on a bulletin board or a website Performing root cause Analysis of probability & cleaning up the code of such areas beefing up regression tests with tests for critical/ oft-appearing bugs
11.6 MANAGEMENT ISSUES DURING THE MAINTENANCE PHASE Incomplete information from the customers Use checklist of min info that is required to be gathered from a customer Product(s) used: Version Number(s): Hardware Details: RAM Disk space Drivers / Devices: Software environment Details: OS/ Version Any supporting S/W versions (database, applications, etc) Network drivers & similar software Problem description: Is the problem reproducible? During the problem occurrence what other software is running? How critical is the problem ? Problems that do not reproduce Whose problem is it? Who gets the fixes? How to distribute the fixes?
Sample checklist of information to be gathered for problem Analysis
69
DBA 1728
NOTES
Two models for fix distribution Push: development organization pushes the fixes to the customers customers get the software distribution without their explicitly asking for specific fixes # It can be on a physical medium like a CD or through email or Internet 11.7 PULL MODEL Fixes for all the problems lie in repository (typically a website) and the customer pull the fixes they want based on the symptoms or problems they encounter Developers unwilling to do maintenance Balancing maintenance with the new development Regression and chain maintenance Effective use of configuration management
Configuration management during the maintenance phase Customers environment is not directly under the control of the development organization Fixes have some inherent dependencies A way to identify the configuration in a customer site Mapping the customer environment to the source environment Regression testing for fixes
Skill sets for people in the maintenance phase Strong understanding of the product functionality Good communication abilities to talk to the customer and get specific details Ability to take balanced, objective view of the problem: both from the customers view point and the product view point Good follow-through attitude.
Estimating size, effort and people resource for the maintenance phase I. How do we predict the inflow of work? II. How do we then estimate the staffing resources? Historical data on the arrival and resolution rates of bugs Customer expectation Seasonal variations Release schedules
Advantage of using geographically distributed teams for the maintenance phase Or mission critical problems or metrics for the maintenance phase
Minimizing the impact of problems on customer while at the at the same time balancing the maintenance workload with the development of new features and products
Metrics Arrival rate of problems (MTBF) Percentage of problems Classified as not a problem Problem occurrence classified by area, product are platform Problem occurrence classified by the severity of the impact MTTR (ie) Average time to fix a problem Rate of re-appearance of problems Significance Instability in the quality of design, development & testing process Unclear or inaccurate documentation Requirements were not captured properly Identifies high risk develop areas Product is completely unusable or the method of classification is not appropriate Effectiveness of implementation Effectiveness of the configuration management and the regression testing mechanisms
Product developer
NOTES
Customer
Support analyst
Customer encounter a problem
All basic info available
Obtain information From customer

User error?
Inform customer of Error and corrective action

Known problem ?
Inform customer of work around, if any Update problem repository
Create new problem development start repository record looking at the problem
Problem repository
71
DBA 1728
NOTES
Summary This chapter has covered the various types of maintenance phase and activities carried out during the maintenance phase. Review questions 1. Define Maintenance? 2. Explain various types of software maintenance phase? 3. What are Relative Cost of Maintenance? 4. Explain the Seven Step Approach of maintenance phase? 5. Describe the activities carried out during the Maintenance Phase? 6. What are the management issues occurred during the maintenance phase? 7. Explain the Pull Model approach of maintenance phase?
72
UNIT IV
NOTES
INTRODUCTION TO SOFTWARE QUALITY

CHAPTER -12
SOFTWARE QUALITY VIEWS AND STANDARDS
INTRODUCTION TO THE UNIT This chapter covers the basic concepts of software quality and standards. The coverage starts with quality, process, process quality, reviews and metrics and basic QC tools. UNIT LEARNING OBJECTIVES After reading this chapter the learner will understand the concepts of the following: 12.1 Quality Quality Control Quality Assurance Process Characteristics of Quality and Process Example of QC, AQ and Process Software Standards SOFTWARE QUALITY
The American Heritage Dictionary defines quality as a characteristics or attribute of something. As an attribute of an item, quality refers to measurable characteristic-things we are able to compare to known standards such as length, color, electrical properties, malleability, and so on. However, software, largely an intellectual entity, is more challenging to characterize than physical objects. When we examine an item based on its measurable characteristics, two kinds of quality may be encountered: Quality of design and Quality of conformance. In software development, quality of design encompasses requirements, specifications and the design of the system. Quality of conformance is an issue focused primarily on implementation. If the implementation follows the design and the resulting system meets its requirements and performance goals, conformance quality is high.
DBA 1728
NOTES
Quality control is the series of inspections, reviews, and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it. Quality control includes a feedback loop to the process which created the work product. The combination of measurement and feedback allows us to tune the process when the work products created fail to meet their specifications. This approach views quality control as part of the manufacturing process. Quality assurance consists of the auditing and reporting functions of management. The goal of quality assurance is to provide management with the data necessary to be informed about product quality, thereby gaining insight and confidence that product quality is meeting its goals. Cost of quality includes all costs incurred in the pursuit of quality or in performing quality related activities. Cost of quality studies are conducted to provide a baseline for the current costs of quality, to identify opportunities for reducing the cost of quality, and to provide a normalized basis of comparison. Quality costs may be divided into costs associated with prevention, appraisal and failure. Prevention costs include quality planning, formal technical reviews, test equipment and training. Appraisal costs include activities to gain insight into product condition the first time through each process. Examples of appraisal costs include in-process and inter process inspection, equipment calibration and maintenance and testing. Failure costs are costs that would appear if no defects appeared before shipping a product to customers. Failure costs may be divided into internal failure costs and external failure costs. Internal failure costs include rework, repair and failure mode analysis. External failure costs include complaint resolution, product return and replacement, help line support and warranty work. Software quality is defined as Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. Software quality definition serves to emphasize three important points: Software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality. Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result. There is a set of implicit requirements that often goes unmentioned (e.g., the desire for good maintainability). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect.
74
Standards for quality assurance for software are introduced in military contract software development during the 1970s and have spread rapidly into software development in the commercial world. Software quality assurance (SQA) is an umbrella activity that is applied throughout the software process. SQA is comprised of a variety of tasks associated with two different constituencies: the software engineers who do technical work, and a SQA group that has responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting. Software engineers address quality by applying solid technical methods and measures, conducting formal technical reviews, and performing well-planned software testing. The charter of the SQA group is to assist the software engineering team in achieving a high quality end product. The Software Engineering Institute recommends a set of SQA activities that address these issues namely: Prepare a SQA plan for a project. Participates in the development of the projects software process description. Review software engineering activities to verify compliance with the defined software process. Audits designated software work products to verify compliance with those defined as part of the software process. Ensures that deviations in software work and work products are documented and handled according to a documented procedure. Records any noncompliance and reports to senior management. What is quality? The common perception is it is often uneconomical to make quality improvement since it strings down productivity and cost and investment In reality It is possible to improve quality continuously without reducing productivity cost by W.E. Deming says Productivity goes up and cost comes down as quality goes up. This fact is well known, but only to a selected few Two views of quality 1. Meeting Requirements 2. Fitness for use The gap is due to the presence of implied needs Quality assurance closes the gap ISO Definition
75
NOTES
DBA 1728
NOTES
Quality The totality of characteristics of an entity (product or service) that bear on its ability to satisfy stated and implied need Quality control The operational techniques and activities that are use and to fulfill requirements for quality
Quality Assurance All those planned & systematic activities implemented within the quality system and demonstrated as needed to provide adequate confidence that an entity would fulfill requirements for quality Difference between QC Vs QA Examples
QC Product oriented Line function Reactive Defect detection

What is a process?
QA Process Oriented Staff function proactive Defect prevention
Review Walk through Inspection Testing
Defining processes quality audit Selection of tools Training
A sequence of steps performed for a given purpose Eg. Coding process, review process A matured process Consistent with the way work actually gest dome -Defined -Trained -Used -Continuously improving -Living
-Documented -understrod -meausred
S/W process management The quality of a s/w systems is governed by the quality of the process used to develop and evolve it 12.2 SOFTWARE STANDARDS: In software, standards comprises of following: 1. ISO 9000 2. SEI CMM Standard 3. P-CMM Standard 4. CMMI Standard 5. COBIT Standard 6. Six-Sigma The standards mentioned above can be applied to software industry to determine the quality. The standards need not be all; it can be any one of the above. The details of these standards are seen in coming chapters. Summary This chapter has covered the basic concepts of quality in particular software quality and standards. The various quality initiatives ie standards followed in industry are also discussed. Review questions: 1. What is software quality? 2. What is quality assurance 3. What is quality control? 4. Differentiate QC Vs QA. 5. What is SQA? 6. Define Process 7. Classify standards in software quality? 8. List out the examples for software quality control, assurance and process?
NOTES
77
DBA 1728
NOTES
CHAPTER -13
FUNDAMENTAL MEASURES, SIZE EFFORT AND DEFECTS
Introduction to the unit This chapter covers the detailed concepts of fundamental measures ie defect and size effort. The concepts comprises operational definition, various levels of measurement, basic measures and measurement errors. Unit learning objectives After reading this chapter the learner will understand the following: Definition, Operational Definition and Measurement Operational Definition Level of measurements Nominal scale and Ordinal Scale Basic Measures: Ratio, Proportion, Percentage and Rate Measurement Errors
13.1 DEFINITION, OPERATIONAL DEFINITION AND MEASUREMENT One operational definition rigours implementation may be inspection coverage expressed in terms of percentage of the estimated lines of code or function points that are actually inspected. Another indicator of good reviews and inspections could be the scoring of each inspection by the inspector at the end of inspection, based on set of criteria. We may want to operationally use a 5-point Likert Scale to denote the degree of effectiveness, there may also be other indicators. In addition to design, design review, code implementation and code inspection, development, testing is part of our definition of front end development process. We also need to operationally define rigours execution this test. Two indicators that could be used are the percent coverage in terms of instructions executor and the defect rate expressed in terms of number of defects removed per thousand lines of source code or per function point. 13.1.1 Operational Definition It spells out the metrics and the procedure to be used to obtain data. An operational definition of body weight could indicate how the weight of a person to be measured, the instrument to be used and the measurement unit to record the result. An operational definition
78
of software product rate would indicate the formula for defect rate, the defect to be measured, denominator, how to measure and so forth. 13.2 LEVEL OF MEASUREMENTS The four levels of measurement are nominal scale, ordinal scale, interval scale and ratio scale. 13.2.1 Nominal Scale The most simple operation in science and thelowest level of measurement is classification. In classifying we attempto sort a elements into categories with respect to certain attributes. If we classify software development process models through which the products were developed, then we may have catetgory such as waterfall development process, spiral model, iterative development process and others. In nomial scale the two key requirements for the categories are jointly exhaustive and mutually exclusive. Mutally exclusive means a subject can be classified as into one and only one categories. If the attributes are more categories than we are interested in, an other category immediate is needed to make the categories jointly exhaustive. 13.2.2 Ordinal Scale Ordinal scale refers to the measurement operations through which the subjects can be compared in order. For eg., we may classify families 13.3 BASIC MEASURES Regardless of the measurement scale, when the data are gathered we need to analyse them to extract meaningful information. Various measures and statistics are available for summarizing the raw data and for making comparisons across groups. The basic measures available are: 1. 1.Ratio 2. Proportion 3. Percentage 4. Rate 13.3.1 Ratio A ratio results from dividing one quatity by another. The numerator and denominator are from two distinct populations and are mutually exclusive. For ex., in demography, sex ratio is defined as number of males / number of females * 100 %. If the ratio is less than 100, there are more females than males; otherwise there are more males than females.
NOTES
79
DBA 1728
NOTES
13.3.2 Proportion Proportion is different from ratio in that the numerator in a proportion is a part of the denominator: P = a / (a + b) Proportion also differs from ratio in that the ratio is best used for two groups where as proportion is used for multiple categories ( or populations) of one group. In other words the denominator in the preceeding formula can be more than just a + b . For ex., the following gives the proportion of satisfied customers of the total customer set: number of satisfied customers / total number of customers of a software product. 13.3.3 Percentage A proportion or a fraction becomes a percentage when it is expressed in terms of per 100 units. The word percent means per hundred. A proportion P is therefore equal to 100P percent( 100P%). Percentages are frequently used to report results and as such are frequently misused. First, because percentages represent relative frequencies, it is important that enough contextual information be given, especially the total number of cases, so that the readers can interpret the information correctly. Ex., the project consist of 8 KLOC. During its development a total of 200 defects were detected and removed, giving a defect removal rate of 25 defects per KLOC of the 200 defects requirements bugs constituted 15%, design bugs 25%, coding bugs 50%, and other bugs made up 10%. 13.3.4 Rate The concept of rate is associated with the dynamics ( Change) of the phenomena of interest. Generally it can be defined as a measure of change in one quantity (x) per unit of another quantity (y) on which the former x depends. Usually the y variable is time. It is important that the time unit always be specified and describing a rate associated with time. The concept of exposure to risk is also central to the definition of rate, which distinguishes rate from proportion. In quality the risk exposure concept is defined as opportunities for error (OFE). The numerator is the number of defects of interest. Therefore, Defect rate = number of defects / OFE * K In software defect rate is usually defined as the number defects per thousand source lines of code. In a given time unit. Note, this metric defects per KLOC is a crewd measure. First, the opportunity for error is not known. Second, any LOC may be subject to error, a defect may involve many source lines, so the metrics is only a proxy measure of defect rate, even assuming no other problems. Such limitations should be taken into account when analysing results or interpreting data pertaining to software quality.
80
13.4 MEASUREMENT ERRORS There are two type of measurement error: Systematic and random. Systematic measurement error is associated with validity. Random error is associated with reliability. Formula for the measurement error is M=T+s+e Where M is the observed or measured score T is the true score s is systematic error and e is random error. Summary Measurement is related to the concept or entity of interest and the operation definition of the concept. Depending on the operational definition, different levels of measurements can be applied: Nominal scale, Ordinal scale, Interval scale. The measurement scales are hierarchical: each scale posses all properties of scales at lower levels. Basic measures such as ratio, proportion, percentage, and rate all have specific purposes. Care should be exercised to avoid misuse. Validity is associated with systematic measurement errors and reliability with random measurement errors. Measurement is the key to making software development a true engineering discipline. To improve the practice of software measurement it is important to understand the fundamentals of measurement theory. Review questions 1. What is operational definition and measurement? 2. What are the various levels of measurement? 3. Define Nominal Scale 4. Define Ordinal scale 5. Describe the various basic measures available for software measurement? 6. What is Ratio? 7. What is Rate? 8. What is Proportion? 9. What is Percentage? 10. Briefly explain the measurement errors?
81
NOTES
DBA 1728
NOTES
CHAPTER 14
SOFTWARE QUALITY METRICS
INTRODUCTION TO THE UNIT This chapter covers the detailed concepts of software quality metrics, various types of metrics, product metrics, process metrics and ideal metrics, basic QC tools and template metrics. UNIT LEARNING OBJECTIVES After reading this chapter the user tries to know the fundamentals of software quality metrics. The basic concepts of metrics are the following: Metrics in a project mgmt context is about measurements Measuring your progress in order to know where you are What mid-course corrections you need to take to achieve your goals Measurements to measure your progress In process metrics How well you achieved the goals end result metrics or business goals Umbrella activities in software project .mgmt
14.1 INTRODUCTION TO SOFTWARE QUALITY METRICS 14.1.1 Define Metrics A quantitative determination of the extent to which a system, component or process possess a certain attribute generally a ration 14.1.2 Ideal Metrics Simple, precise, Definable Objective Easily obtainable Valid Robust
14.1.3 The Metrics Road Map Any metrics program or measurements should provide gauges that measure our progress towards both short term as well as long term objectives 1. Act plan 2. Check Do 3. The deming PDCA cycle for metrics
The questions to ask in a metrics program i) ii) iii) iv) Where are we today? Where do we want to go? What do we have to do? How do we measure progress?
NOTES
14.1.4 Metrics Strategy i. Measure things that make an impact on the company goals ii. Classification of Metrics 14.2 TYPES OF METRICS 14.2.1 Product Metrics 1)Measurement of size Lines of code(LOC) Function points Feature points 2)Measurement of quality -Defect -Reliability -Complexity
14.2.2 Project Metrics 1)Project - Productivity - schedule & effort 2)Organization -Schedule & effort -schedule variation -effort variation -productivity A typical Metrics strategy 1. Decide what you want to measure & how are you are going to measure it 2. Set targest & track them 3. Understand variability and work towards minimizing it 4. Act on data and strive for continuous improvement 5. Consider the human angle 14.3 DATA COLLECTION 1) Through project plan 2) Process database 3) Review & Inspection
DBA 1728
NOTES
4) Audits 5) Test Results 6) Test logs, Test summary Reports Frequency of Data collection 1) Size : collected in the beginning, during re-estimations and during wind-up 2) Schedule & effort: once in a week 3) Review effectiveness : During reviews and testing Data Analysis 1) collected data analyzed using std statistical methods 2) Analysis of the data presented in metrics report 14.4 SET TARGETS AND TRACK THEM To ensure that the targets satisfy the SMART criteria. The SMART is an acronym for Specific, Measurable, Aggressive yet achievable, Results oriented and Time-bound Specific: The target should be specific in terms of numbers Measurable: The value of target should be measurable unambiguously and interpreted consistently Aggressive Yet Achievable: The target that one is trying to achieve should not be utterly impossible to achieve Results-oriented: Need to convey is how this measurement of the symptom has an impact on the final business outcome or project outcome. Time-Bound: The targets should be achieved within a given time-frame Use of Metrics for process Improvement 1) Exceptional data points are inspected eg: control charts 2) The underlying reasons examined eg: fish bone/Root cause Analysis 14.5 UNDERSTANDING AND TRYING TO MINIMIZE VARIABILITY 1) 2) To achieve consistency and predictability, there are always variations Unclear understanding of the requirements, changing technology The variability is within reasonable limits (called LCL lower control limits and UCL upper control limits) and an expected mean value When the variability exceeds these limits, we should understand exactly why this happens and how we can minimize such a wide variation in future.
benchmarking against the industry norms

Track record in similar projects Required value of metrics as targets to shoot for 14.6 POSSIBLE ROOT CAUSE ANALYSIS FOR OBSERVATIONS 14.6.1 Root cause 1) 2) Machine outage happened during the time that these bugs were being tired The bugs required some information from the customer and the customer did not get the information on time. These bugs were the first bugs fired by a new recruit into the organization. The bugs turned out to be much more complex that the normal bug.
NOTES
14.6.2 Corrective Actions Redundant marks Allocating more reliable machines to critical bugs Changing the supplier for the machines Get into a service level agreement with the customer to provide all the information Design a template or check list that elicits all the information needed Change the metrics from obsolete 10 of days after the complete inform is available. Increase the effectiveness of training Arrive at a mechanism of classifying the bags in the categorize and provide target metrics separately for each of the categorize rather than providing one universal target for all categorize of bugs
14.6.3 Act on Data 1) Metrics collection & analysis is a expensive and skilled-labor intensive process 2) Continuous improvement is absolutely essential even if we wont to stay where we are in the market 3) All the constituents do end up putting in an extra effort into gathering these metrics The specific actions for recommendation i) ii) iii) iv) v) What if, why not, so what? Arrive at root causes Decide whether the resultant action is a process change of a product change or no change. Analyze whether, on the basis of the change the current metric still makes sense Complete the feedback loop to the people who supplied the data for the metrics\
85
DBA 1728
NOTES
14.7 PEOPLE AND ORGANIZATIONAL ISSUES IN METRIC PROGRAMS i) ii) iii) iv) v) vi) Management commitment is essential for the success of metrics Metrics and targets should not be thrust top down Not shooting the messenger Focus on analysis of aggregate results-not individual performance Do not violate privacy laws in the name of metrics Make sure the operational issues of metrics are understood consistently by everyone
14.8 COMMON PITFALLS TO WATCH OUT FOR IN METRICS PROGRAM overdose of metrics Deciding on how to measure before you decide what to measure Using metrics data for individual performance appraisal Not flexible and open in metrics Not allocating clear responsibility for collection, analysis and reporting of metrics Metrics as a policing activity Metrics as being incompatible with gut feel Metrics as an extra step after the actual work Not closing the feedback loop fast enough : ______________Managers__________________
Template for project success factors in order of priorities Company Name Division Name : Project Name :
S.No. 1 2 3
Success factor:
Inprocess metric
Success factor
Acceptable range
Evaluator
In process Metrics
Mean
UCL LCL Collection Collecting Reporting Responsibility freq responsibility freq. and reporting
86
14.9 BASIC QC TOOLS The seven Quality Control tools of software quality are: a. Check sheets b. Pareto Analysis c. Flow charts(stratification Analysis) d. Cause & effect Diagrams e. Scatter diagram (XY graph) f. Control charts g. Histograms Why do we need seven tools? i) ii) iii) iv) Effective problem solving is data driven Data and impersonal Provides common methods of analysis to help problem solving teams effectively Operational problems usually may be solved using 7 tools
NOTES
14.9.1 Check sheets Check sheets are used to record & compile data to study a process (eg defects, complaints,etc) Feed back form
Compliant Store Compliant consistent
Purpose 1) Highlight key features where attention is needed 2) Check sheets force agreements and the process metrics and failure modes 3) Include open ended responds (eg. Author, music) 4) Describe defects using short phrases 14.9.2 Pareto Analysis 1) Ranking of data by importance in descending frequency 2) Purpose: quickly identify high impact access 3) Go/zo rule 4) Vital few trival many
DBA 1728
NOTES
5) Quality defects or problems will constitute a high 6) Of the quality losses(Costs) 7) Other applications of pare to analysis Inventory, cost accounting 14.9.3 Flow charts 1) A diagrammatic picture showing all steps or stages in a process 2) Flow charges help facilitate a greater understanding of the entire process by identifying where problems have occurred or may occur 14.9.4 Cause & effect Diagram (Ishikawa/Fish bone Diagram) Cauese and effect diagram are used to sort out potential causes of problems and Organize theories by cause-and effect relationship. 1) Effect-failure 2) Branch-Broad categories 3) Tung-1st level cause 4) Twiglets-2nd level cause Advantages: i) ii) iii) iv) Marketing the diagram is educational in itself Diagram demonstrates knowledge of problem solving team Diagram results in active searches for causes Diagram provides a guide for process Analysis
14.9.5 Histogram Graphical representation of individual measured values according to frequency or relative frequency of occurrence. It is used to show distribution shape for one variable (location, dispersion). Histogram Data and Samples were taken randomly. Table 14.1: Sample for using the histogram table
Sample 1 A B C
30
1) Graphical representation of individual measured values according to frequency or relative frequency of occurrence 2) Used to show distribution shape for one variable
88
13.9.6 Scatter Plots Scatter plots are used to visualize relationship (correlation) between and variables and common types of correlations are: a) Between features of a single product (within product) b) Between product o/p & process input c) Between two different products Issues: a) Strength of correlation b) Non-linear relationships Summary This chapter has covered the basic concepts of software quality metrics especially for software product and service industry. Various types of metrics, QC seven tools and detailed description has also covered in this chapter. Review questions: 1. What is software quality metrics? 2. Define Metrics 3. What is Ideal Metrics? 4. Explain the Road map for a metrics program? 5. What is metrics strategy? 6. Classify and explain the various types of Metrics? 7. Define Product Metrics 8. Define Project Metrics 9. Explain in detail about the data collection in Metrics? 10. Briefly explain the set targets and track them in a metrics program? 11. How will you understand the variations and in what way do you minimize variability? 12. Explain the various root cause analysis for any case? 13. Explain the various issues found in People and organizational metric programs? 14. What are the drawbacks in metrics program? 15. What is the need for basic seven QC tools? 16. Describe the seven QC tools with illustrations?
NOTES
89
DBA 1728
NOTES
CHAPTER 15
COMPLEXITY METRICS
INTRODUCTION TO THE UNIT This chapter covers the detailed description of the complexity metrics and models. The various models studied are Lines of Code (LOC), Halsteads Software Science, Cyclomatic complexity, Syntactic Constructs, Structure Metrics, Card and Glasss model. The basic steps, procedures, equations, applications and limitations of complexity metrics and models were discussed. OBJECTIVES OF THE UNIT After reading the chapter, the learner may find the usefulness of complexity metrics and models for the software industry. LOC model description and applications. Halsteads Software Science model procedure and applications. Cyclomatic complexity applications. Syntactic Constructs descriptions. Structure metrics equations and applications. Card and Glasss models applications.
15.1 LINES OF CODE (LOC) The Lines of Code count is usually for executable statements. It is actually a count of instructions statements. The interchangeable use of the two terms apparently originated from assembler program in which the loc and an instruction statement are the same thing. Because the loc count represents the program size and complexity, it is not a surprise that the more loc there are in a program, the more defects are expected. Researches found that defect density( defec ts per KLOC) is also significantly related to loc count. Early studies pointed to a negative relationship. The larger the module size the smaller the defect rate. Interface errors are more or less constant regardless of module size, and smaller modules are subject to higher error density because of smaller denominators. 15.2 HALSTEADS SOFTWARE SCIENCE A computer program according to software science is a collection of tokens that can be classified as either operators or operands. The primitive measures of Halsteads Software Science are:
90
n1 = number of distinct operators in a program n2 = number of distinct operands in a program N1 =number of operator occurrences N2 = number of operand occurrences Based on these primitive measures Halsteads Software Science developed a system of equations expressing the total vocabulary, the overall program length, the potential minimum volume of an algorithm, the actual volume (number of bits required to specify a program), the program level(the measure of software complexity), the program difficulty, and other features such as development efforts and the projected number of faults in the software. The major equations include the following Vocabulary (n) Length (N) = n1 Volume (V) Level (L) Difficulty (D) Effort (E) Faults (B) L= V=N /V n = n1 + n2 N = N1 + N2 + n2
NOTES
D=V/ E=V/L B=V/
Where = minimum volume represented by a built in function performing the task of the entire program , S* = mean number of mental discriminations (decisions) between errors 15.2.1 Limitations of Halsteads Software Science 1. Empirical studies provide little support to the equations except for the estimation of program length. 2. The equation for B appears to be over simplified for the project management, lacks empirical support, and provides no help to software engineer This metric is therefore a static metric ignoring the huge variations in fault rates observed in software products and among modules. 15.3 CYCLOMATIC COMPLEXITY The measurement of cyclomatic complexity by McCabe(1976) was designed to indicate a program testability and understandability (maintainability). It is a classical graph
DBA 1728
NOTES
theory cyclomatic number, indicating the number of regions in a graph. As applied to the software it is the number of linearly independent paths that comprise the program. As such it can be used to indicate the effort required to test a program. To determine the paths, the program procedure is represented as a strongly connected graph with unique entry and exit points. The general formula to compute cyclomatic complexity is: M = V(G) =e n + 2p Where V(G) = cyclomatic number of G e = number of edges n = number of nodes p = number of unconnected paths of the graph As an example, figure is a control graph of a simple program that might contain two If statements. If we count the edges, nodes and disconnected paths of the graph we see that e = 8 n = 7 and p= 1, and that M = 8 7 + 2 * 1 = 3.
g
Figure 15.1 : Simple control graph example. The cyclomatic complexity metric is additive. The complexity of several graphs considered as a group is equal to the sum of the individual graphs complexities. However, it ignores the complexity of sequential statements. Neither does the metric distinguish different kinds of control flow complexity such as loops versus If - then else statements or cases versus nested If then else statements. To have a good testability and maintainability, McCabe recommends that no program module should exceed a cyclomatic complexity of 10. Because the complexity metric is based on decisions and branches, which is consistent with the logic pattern of design and
programming, it appeals to software professionals. Since its inception, cyclomatic complexity has become an active area of research and practical applications. Many experts in software testing recommend use of the cyclomatic representation to ensure adequate test coverage. The use of cyclomatic complexity measure has been gaining acceptance by software practitioners. Because of its appeal to programmers and researchers, many studies have been conducted to relate complexity measure to defect rate, and moderate to strong correlation were observed. For ex., in a study of software metrics of a large SQL product that consisted of about 1300 modules, troster (1992) found a relatively strong correlation between McCabes cyclomatic complexity index and the number of test defects. Studies found that the complexity index also correlates strongly with program size lines of code. 15.4 SYNTACTIC CONSTRUCTS McCaBes cyclomatic complexity index is a summary index of binary decisions. It does not distinguish different kinds of control flow complexity such as loops versus If then elses or cases versus If then elses. Researches of software metrics also studied the association of individual syntactic constructs with defect level. The field defects at the module level can be estimated through the following equations: Field defects = -2.5 +0.003 LOC + 0.001 unique operands ( = 0.66) 15.5 STRUCTURE METRICS Structure metrics tries to take into account of the interactions between modules in a product or system and quantifying such interactions. Perhaps the most common design structure metrics are the fan in and fan out metrics which are based on the ideas of coupling proposed by Yourdon and Constantine (1979) and Myers (1978). Fan in : a count of the modules that call a given module Fan out : a count of modules that have called by a given module In general, modules with a large fan in are relatively small and simple, and are usually located at the lower layers of the design structure. In contrast, modules that are large and complex are likely to have a small fan in . Therefore, modules or components that have a large fan in and large fan out to indicate a poor design. Such modules have probably not been decomposed correctly and are candidates for re design. From the complexity and defect point of view modules with a large fan in are expected to have negative or insignificant correlation with defect levels and modules with a large fan out are expected to have a positive correlation. Finally the overall data complexity is defined as the average of data complexity of all new modules.
93
NOTES
DBA 1728
NOTES
15.6 CARD AND GLASSS MODEL The system complexity measure was significantly correlated with subjective quality assessment by a senior development manager and with development error rate. Specifically the correlation between system complexity and development defect rate was 0.83, with complexity accounting for fully 69 % of the variation in error rate. This model appears quite promising and as an appeal to software development practitioners. They also provide guidelines on achieving a low complexity design. Summary This chapter describes several major metrics and models with regard to software module and design from the view point of the metrics correlation with defect level. Regardless of whether the metrics are LOC, the software science metrics, cyclomatic complexity, other syntactic constructs, or structure metrics, these metrics seems to be operational definitions of the complexity of the software design and module implementation. In retrospect, the key to achieving good quality is to reduce the complexity of the software design and implementation, given a problem domain for which the software is to provide a solution. Review Questions 1. Explain the following complexity metrics and models a. Lines of Code (LOC) b. Halsteads Software Science c. Cyclomatic complexity d. Syntactic Constructs e. Structure metrics f. Card and Glasss models 2. Describe the various complexity metrics and models applicable to software industry? 3. Briefly explain the cyclomatic complexity model with an example? 4. In what way does the structure metrics complexity model superior to other models? 5. In todays scenario for a software product industry which model will be suitable? Explain its significance? 6. How will you differentiate LOC model with cyclomatic complexity model? 7. What are the limitations of Halsteads Software Science model? 8. List out the applications of complexity metrics and models? 9. Define Fan in and fan out of Structure metrics. 10. Take any software industry (in particular maintenance projects) of your own choice and analyze how the complexity metrics models can be really useful in identifying the defect rate and what are the measures can be adopted to overcome the defect injection?
CHAPTER 16
DEFECT IDENTIFICATION AND REMOVAL EFFICIENCY
NOTES
INTRODUCTION TO THE UNIT This chapter will cover the activities associated with defect injection and removal, Defect injection and removal during one process step, Phase based defect removal model. UNIT LEARNING OBJECTIVES After reading this chapter, the learner will understand the concepts of the following: Defect Identification and Removal Efficiency Defect injection and removal during one process step Phase based defect removal model
16.1 Defect Identification and Removal Efficiency Fagan (1976) touches on the concept of defect removal effectiveness. He defined error definition efficiency as:
Errors found by an inspection * 100 Total errors in the product before inspection
Re moval efficiency
Defects found by removal operation * 100 Defects present at the removal operation
Defects found * 100 Defects found Defects not found (found later)
IBM used to manage quality is the early detection percentage, which is actually inspection defect removal effectiveness. From Ryan (1987) and kolkhorst and Macina (1988)
Early det ection percentage Number of major inspection errors *100 Total number of errors
Where total number of error is the sum of major inspection errors and valid discrepancy reports (discrepancy report is the mechanism for tracking test defects). Dunns definition is,
95
E = (N / N+S )*100
DBA 1728
NOTES
Where, E = effectiveness of activity (development phase) N = number of faults (defects) found by activity (phase) S = number of faults (defects) found by subsequent activities (phases) Daskalantonakis (1922) describes the metrics used at Motorola for software development. Two of the metrics are in fact for defect removal effectiveness: Total defect containment effectiveness (TDCE) and phase containment (PCEi).
TDCE
Number of prerelease defects Number of prerelease defects Number of postrelease defects Number of phase i errors Number of phase i errors Number of phase i defects
PCEi
Where phase i errors are problems found during development phase in which they were introduced, and phase i defects are problems found later than the development phase in which they were introduced. Defect removal effectiveness for each development step is defined as,
Defects removed (at the step) *100 Defects existing on step entry Defects injected during development (of the step)
Table 16.1: Activities associated with defect injection and removal
Development phase Requirements
Defect injection Requirements- gathering process and the development of programming functional specifications Design work Design work Coding Integration and build process Bad fixes Bad fixes Bad fixes
Defect removal Requirement analysis and review High-level design inspections Low level design inspections Code inspections Build verification testing Testing itself Testing itself Testing itself
High-level design Low-level design Code implementation Integration / build Unit test Component test System test
The defect removed is equal to detects detected minus incorrect repairs.

16.2 DEFECT INJECTION AND REMOVAL DURING ONE PROCESS STEP
NOTES
Undetected defects Defects Existing on Step entry Defects injected during development Defect detection incorrect Defect repair Defects existing
repair
after the step exit
Defects removed
Figure 16.1: Defect Injection and Removal during one process step 16.3 PHASE BASED DEFECT REMOVAL MODEL The phase based defect removal model (DRM) summarizes the relationship among three metrics defect injection, defect removal and effectiveness. The DRM takes a set of error-injection rates and set of phase effectiveness rate as input, then models the defect removal pattern step by step. Defects at the exit of development step = Defects escaped from previous step + Defects injected in current step - Defects removed in current step Summary This chapter has covered the basics of defect identification and removal efficiency of software products. The various formulas studied can be applied to a software product, process and service industry. Review Questions 1. What is defect removal effectiveness? 2. What is error definition efficiency? 3. Define Removal efficiency 4. How will you define Early detection percentage? 5. Explain the term total defect containment effectiveness (TDCE) and phase containment (PCEi) with suitable illustrations? 6. Describe the various activities associated with defect injection and removal? 7. Briefly explain the defect injection and removal during one process step? 8. What is Phase based defect removal model? 9. What is the significance of defects at the exit of development step?
DBA 1728
NOTES
CHAPTER -17
FUNCTION POINTS
INTRODUCTION TO THE UNIT This chapter covers the estimation of function points and their applications towards software industry. The function point types and procedure is explained in detail. Further the calculation of the unadjusted function point count and function point is calculated using the value adjustment factor is also covered. UNIT LEARNING OBJECTIVES After reading this chapter the learner will have a wide knowledge in estimation of function points in particular towards the software products or projects. The components covered can give good scope for estimation. The following are the details of the function point component: Introduction and Review of Function Points Data in Motion Data at Rest Function Point Extensions Feature Point Object Point 3-D Function Points Advantages of Function Points Methodology of Function Point Analysis to a software product Determination of type of function point count Determination of the application boundary Components of Function Points Function types Determination of the Value Adjustment Factor (VAF) Calculation of the adjusted function point count
17.1 INTRODUCTION AND REVIEW OF FUNCTION POINTS Function Point was developed by Albrecht (1979) at IBM in the late 1970s. This is a method to break systems into smaller components, so that they can be understood and analyzed. It also provides a structured technique for problem solving. Function Point Analysis
is very similar to completing a functional decomposition. Function Point measures software by quantifying its functionality provided to the user primarily based on the logical design. A relatively small number of factors have the greatest potential in affecting reliability, and recommendations are made for using these results to improve reliability of function point counting in organizations (Chris and Benjamin 1992). The Lines of Code Measure Checklist for the system definition, report forms and supplemental forms to support measurement definitions has been developed by Park (1992). Taghi et al (1992) have introduced two new estimation producers and compares their performance in terms of predictive quality and the quality of fit with more traditional least squares and absolute value estimation techniques. Several published statistical regression models that relate software development effort to software size measured in function points are available. Tridas and Sunder (1992) have suggested the use of the COCOMO and Function points based approach for early software cost estimation. To overcome the problems with the current methods for measuring function points that constrain the effective use of function points regression models a modification to the approach has been suggested which should enhance the accuracy of prediction models based on function points in the future (Jack et al 1994). Software cost estimation models are calibrated on data sets from a large air force database. The development effort accuracy of each model has been evaluated before and after calibration using a hold-out sample, or data not used in calibration. Results on a variety of data sets showed that calibrating the checkpoint model improved its accuracy for development effort. The accuracy of model was especially noteworthy on data sets that used function points as a measure of size (Karen et al 1997). David Longstreet (2002) has described that function points are a method to break systems into smaller components, so that can be better understood and analyzed. Function Points measure software by quantifying its functionality provided to the user based primarily on the logical design. Function Point counts to not depend on the source language used. It can be obtained early in the development cycle. Function Point counts are oriented toward the customers view rather than the producers view; this emphasis as the focus on value received rather than on the particular design that is employed. Function point counts are not equally applicable to all kinds of software. Although effective in business environments, they have not enjoyed wide spread success in embedded systems or heavily computational applications. Organizations can apply Function Point Analysis as: 1. A tool to determine the size of a purchased application package by counting all the functions included in the package. 2. A tool to help users to determine the benefit of an application package to their organization by counting functions that specifically match their requirements.
99
NOTES
DBA 1728
NOTES
3. A tool to measure the units of a software product to support quality and productivity analysis. 4. A vehicle to estimate cost and resources required for software development and maintenance. On a conceptual level, Function point analysis helps to define two abstract levels of data. 1. Data in Motion 2. Data at Rest 17.2 DATA IN MOTION Data in Motion is handled via transactional function types or transactions. All software application will have numerous elementary processes or independent processes to move data. Transactions (or elementary processes) that bring data from outside the application domain (or application boundary) to inside application boundary are referred to as external inputs. Transactions that take data from a resting position (normally on a file) to outside the application domain are referred to as either an external outputs or external inquiries. 17.3 DATA AT REST Applications stored information for processing at a later time. Data at rest that is maintained by the application in question is classified as internal logical files. Data at rest that is maintained by another application are classified as external interface files. 17.4 FUNCTION POINT EXTENSIONS The concepts of Function Point Analysis can be used for any type of software project, and it is consider most effective while sizing Management Information System applications. An extension is usable only if tested on a sufficiently large base of applications and suitably calibrated. The extensions of the Function Point Analysis are: 17.4.1 Feature Point Feature Points is a method developed by Caper Jones (1988) at Software Productivity Research, Inc. to apply function point logic to software such as system software, communication software, etc. Feature point extends the function points to include algorithms as a new class. An algorithm is defined as a set of rules, which must be completely expressed to solve a significant computational problem. For example, a square root routine can be considered as an algorithm. Each algorithm used is given a weight ranging from 1 (elementary) to 10 (sophisticated algorithms) and the future point is the weighted sum of the algorithms plus the function points. This measurement is especially useful for system with few input/ output and high algorithmic complexities, such as mathematical software, discrete simulations, and military applications.
Another extension of function points is Full Function Point (FFP) used for measuring real-time applications, by also taking into consideration the control aspect of such applications. FFP introduces two new control data function types and four new control transaction function types. 17.4.2 Object Point While future point and FFP extend the function point, the object point (Pfleeger 1989) measures the size from a different dimension. This measurement is based on the number and complexity of the following objects such as screens, reports and 3GL (Generation language) components. Each of these objects is counted and given a weighted sum of all these objects. This is a relatively new measurement and it has not been very popular. But because it is easy to use at the early phase of the development cycle and also measures software size reasonably well, this measurement has been used in major estimation models such as COCOMO II. 17.4.3 3-D Function Points 3-D function points (Whitmire 1992) were proposed in the internal paper at the Boeing Company and published in 1992 at the Pacific Northwest Software Quality Conference. It addresses the problem of applying function points to scientific and realtime applications. The model uses three dimensions to measure-data, function and control. Transformation and algorithms are counted for using the function dimension, while changes to the state of the application are handled by the control dimension. It has also been claimed that the model is suitable for object oriented development. 17.5 ADVANTAGES OF FUNCTION POINTS Function points offer several significant advantages over lines of code counts: 1. It is possible to estimate them early in the life cycle, at the time of the requirements definition. 2. They avoid the effects of language and other implementation differences. 3. It is easier to demonstrate to the sponsor the impact of a seemingly little change to the requirements has on the project. 4. The function point count is a good basis for a quality measure. The number of bugs per function point is more meaningful than the number of bugs per 1,000 lines of code. 5. Function points can also be more useful in measuring programmer productivity. The average number of function points produced per day is more meaningful than the average number of lines of code produced per day because the latter will depend on Programming language and programming style. Proponents maintain that an early function point analysis based on a projects initial requirements definition can give developers a
101
NOTES
DBA 1728
NOTES
good first-pass estimate of its size. However, that estimate may vary by as much as plus or minus 35% or more. Because the function point counts are based on features of the system to be developed, estimates made before the logical design are really of little value. However, the accuracy improves to about 10% by the time development reaches the design definition stage. Counting function point is not a trivial matter. Evaluating each function point for its correct complexity and size can be quite laborious. It is easy to undercount functions, and the error can have a ripple effect on the calculations. Analysts who are expected to perform FPA require extensive training. Until they become experienced, an experienced consultant or other FPA expert should assist them. There are many excellent tools to help automate FPA. MicroMan Esti-Mate, first CASE, size plus and Project Bridge are just a few of the many software development project estimating tools in the market today that incorporate some type of FPA. There are also a number of organizations dedicated to the promotion and use of Function Points. The advantage of the function-point measurement is that it can be obtained based on the system requirement specification in the early stage of software development of FPA. 7.6 METHODOLOGY OF FUNCTION POINT ANALYSIS TO A SOFTWARE PRODUCT Function point analysis applicable to a software product consists of the following steps (IFPUG 1999) 1. Determination of type of function point count. 2. Determination of the application boundary. 3. Identify the components of Function Points. a) Identify and rate data function types to determine their contribution to the unadjusted function point count. b) Identify and rate transactional function types to determine their contribution to the unadjusted function point count. 4. Determination of the value adjustment factor (VAF). 5. Calculate the adjusted function point count. The schematic diagram (Figure 4.1) shows the procedure to determine the function point count in a software project.
102
Count data
NOTES
Determine Unadjusted Function Point Count Calculate Adjusted Function Point Count
Determine type of count
Identify scope and application boundary
Count transaction
Determine VAF
Figure 17.1 Function Point Analysis Procedure 17.6.1 Determination of type of function point count Function point counts can be associated with either projects or application software. There are 3 types of function point counts. (a) Development project function point count Function points can be counted at all phases of a development project from requirements up to and including implementation. This type of count is associated with new development work. (b) Enhancement project function point count It is common to enhance software after it has been placed into production. This type of function point count tries to determine the size of enhancement projects. (c) Application function point count Application counts are done on existing production applications. This base like count can be used with overall application metrics like total maintenance hours. 17.6.2 Determination of the Application Boundary The boundary indicates the border between the project or application being measured and the external applications or user domain. The application boundary is identified by the following: (a) Review the purpose of the function point count (b) Look at how and which applications maintain data (c) Identify the business areas that support the applications.
103
DBA 1728
NOTES
17.6.3 Components of Function Points 17.6.3.1 Function types Function Point Analysis defines data as Data in Motion or Transactional function types and Data at Rest or Data Function types. Transactional function types include External Inputs, External Outputs and External Inquiries. Data Function types include Internal Logical Files and External Interface Files. (a) Internal Logical Files (ILF) An ILF is a user identifiable group of logically related data or control information maintained within the boundary of the application. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being counted. (b) External Interface Files (EIF) An EIF is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application counted. (c) External Inputs (EI) An EI is an elementary process that processes data or control information that comes from outside the applications boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system. (d) External Outputs (EO) An EO is an elementary process that sends data or control information outside the applications boundary. The primary intent of an external output is to present information to the user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at-least one mathematical formula or calculation, or create derived data. (e) External Inquiries (EQ) An EQ is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. To determine the complexity and the contribution of the Data and Transactional Function types the following terms need to be defined:
104
i. Record Element Type (RET): A RET is user recognizable sub group of data elements within an ILF or an EIF. Logical grouping of data help to identify them.
NOTES
ii. File Type Referenced (FTR): A FTR is a file type referenced by a transaction. An FTR must also be an ILF or EIF. iii. Data Element Type (DET): A DET is a unique user recognizable, non-recursive (non-repetitive) field. 17.6.4 Determination of the Value Adjustment Factor (VAF) The VAF indicates the general functionality provided to the user for the application. The VAF comprises of 14 general system characteristics that assess the general functionality of the system. Each characteristic has associated description that helps to determine the degree of influence of the characteristics. The degrees of influence range on a scale of 0 to 5, from no influence to strong influence. Appendix 2 (Figure A2.8) shows the details of estimating VAF. 17.6.5 Calculation of the Adjusted Function Point Count The adjusted function point count is calculated using specific formulae for development, enhancement and application function point counts. The final function point count is obtained by multiplying the VAF with the Unadjusted Function Point (UAF). The function point equation is given by. FP where, FP UAF VAF Ci = = = = = Adjusted Point Count Unadjusted Function Points Value Adjustment Factor 0.65 + 0.01 Ci Rating of the ith general system characteristic = UAF x VAF (1)
105
DBA 1728
NOTES
Table 17.1 Rating of general system characteristics
S No 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

Summary
System Characteristics Data Communications Distributed Data Processing Performance Heavily Used Configuration Transaction Rate On-line data entry End User Efficiency On-line Update Complex Processing Reusability Installation Ease Operational Ease Multiple Sites Facilitate Change
Rating 3 2 2 2 3 0 4 4 3 5 1 5 0 4
This chapter has covered the in-depth in function point definition, methodology, applications, and determination of function point count to software industry. The reader will a very good scope and knowledge in estimation of function points. Review Questions 1. Highlight the various contributions of function points in the estimation of software products. 2. Define data in motion and rest. 3. Explain in detail about the Function Point Extensions with suitable example? 4. List out the advantages of Function Points? 5. Describe the methodology of Function Point Analysis to a software product? 6. Explain the determination of type of function point count? 7. How will you determine the application boundary in function points? 8. What are the Components of Function Points? 9. Explain the Function types of function points? 10. Briefly explain the determination of the Value Adjustment Factor (VAF)? 11. How will you calculate the adjusted function point count?
106
CHAPTER 18
BENCHMARKING FOR SOFTWARE QUALITY
NOTES
INTRODUCTION TO THE UNIT It is difficult to improve software quality by relying on conformance to industry standards by continuously upgrading from one standard or model to another standard or model because this exercise is complicated for some software organizations. Many multinational companies, developed internal standards based on the military standards, and then sought to improve the standard even further as their software development processes matured. The software development systems based on these internal, commercial standards, and improved over the years have proved to be good systems. This chapter will show you how to build up an efficient, workable system from basic principles through to writing Quality Manuals, Forms and Templates that can improve software quality by using CMMI (SW), CMM (SW) and ISO 9000-3:1997. UNIT LEARNING OBJECTIVES After reading this chapter, the user will try to understand the benchmarking for software quality with the following components: ISO 9000-3:1997 Mappings of ISO 9000-3:1997, CMM (SW), CMMI (SW) Structure of Quality Management System Manual (QMSM) Scope of QMSM Documentation Structure
18.1 INTRODUCTION TO BENCHMARKING FOR SOFTWARE QUALITY A huge number of software standards, methodologies, practices, models and guidelines are introduced to current era of software engineering. These standards tend to be one size fits all approach that may be optimum for some projects but is often times ill-suited for others because they are continually improving which has become a complicated exercise for software industries, however, many companies developed internal standards based on the military standards, and then improve the process as their software development processes matured. The software development systems based on these internal, commercial standards, and improved over the years have proved to be good systems.
107
DBA 1728
NOTES
18.2 ISO 9000-3:1997 ISO 9000-3:1997 is the guidelines for the application of ISO 9001 to the development, supply, installation and maintenance of computer software while audit will be carried out against all clauses of ISO 9001:1994/ ISO 9001:2000. 18.3 MAPPINGS OF ISO 9000-3:1997, CMM (SW), CMMI (SW) Clause level mapping between ISO 9000-3:1997 with CMM for Software is explained by CMU/SEI. Note that ISO 9000-3:1997 is mapped with CMM (SW) and reason for mapping ISO 9000-3 with CMM (SW) , instead of mapping CMM (SW) with ISO 9000-3 is due to the fact that ISO 9000-3 has predefined list of clauses and audits are performed against ISO 9001:2000 clauses while CMM (SW) has no specific clause ids and CMM assessment are considered against KPAs including Goals, Commitment, Abilities and Activities etc., so if any KPAs is missing in this mappings then we will assume that they do not mapped with ISO 9000-3 (for software) and thus missing KPAs would be focused individually in the suggested Quality Management System Manual. Similarly, 1 to N mapping between CMMI (staged representation, SW) against the practices of CMM (SW) is explained by US Air Force Software Technology Support Centre., which is also supported by CMU/SEI. The mappings can be complemented by additional descriptions and current research suggest researchers to use benchmarking approach after mapping different standards, later conduct a survey of software quality engineering practices and interview certified/assessed and non certified/non assessed organizations. From the survey, select an existing Quality Manual for an in-depth study Finally, based on the mappings, and research survey, map a Quality Manual as defined by ISO 9001:2000 with existing software standards, thus we can demonstrate an efficient, workable system from basic principles to writing Quality Manual, Forms and Templates that can improve software quality. 18.4 STRUCTURE OF QUALITY MANAGEMENT SYSTEM MANUAL (QMSM) In 2004, an Integrated Model of ISO 9001:2000 and CMMI (SW) will show the combination of CMMI (SW) practices and ISO 9001:2000 requirements because they target the integrated model to be useful to ISO 9001:2000 registered organization(s) that plan to adopt CMMI (SW). The quality manual presented in this chapter focuses initial cycles of software development that can improve software quality and considered the mapping of different software standards in order to make them compatible with industry standard. The structure of quality management system manual for improving software quality will follow ISO 9001:2000 clause 4.2 guidelines as a base to show the structure but the guidelines ISO 9000-3:1997 will be followed.
108
18.5 SCOPE OF QMSM Scope of QMSM is divided in three levels e.g. 1-Initial Level, 2-Defined Level and 3-Advanced Level. Initial Level is the scope of current practices which will target ISO 9000-3:1997, CMM (SW level2) and CMMI (staged-level2) while Defined Level and Advanced Level are for future considerations. 18.6 DOCUMENTATION STRUCTURE Irrespective of scope levels, documentations are divided in five categories in a specific flow. The documentation requirement is carried out as per ISO 9001:2000 clause 4.2. Throughout the quality management system manual, the documentation structure will be carried out to meet any scope of QMSM. Summary This chapter began by forwarding the conclusions from other researchers, Later, it was forwarded by studying some software standards namely ISO 9000-3:1997, CMM (SW 1.1) and CMMI (staged, SW 1.1) and addressing the similarities among them. The feedback from market survey and study of existing quality manual help in representing a better quality management system manual else only the mapping among standards will not guarantee the improvement in software quality. It is required to focus the QMSM at initial level rather than skipping initial level and selecting the level of choice but if the scope of QMSM is ignored then there is no guarantee of quality improvement. Review questions 1. What is the significance of benchmarking for software quality? 2. What is ISO 9000-3:1997? 3. How will you Map ISO 9000-3:1997, CMM (SW), CMMI (SW) for software quality? 4. Explain the Structure of Quality Management System Manual (QMSM)? 5. Briefly explain the Scope of QMSM? 6. What is the need for Documentation Structure in benchmarking for software quality?
NOTES
109
DBA 1728
NOTES
110
NOTES
UNIT V
SOFTWARE QUALITY ASSURANCE

CHAPTER -19
RELIABILITY MODELS FOR SOFTWARE QUALITY
INTRODUCTION TO THE UNIT This chapter will cover the software reliability models applicable to software industry. Mainly it focuses on reliability models, formulation, modeling process, assumption and applicability for software products, process and services. UNIT LEARNING OBJECTIVES After reading this chapter, the learner will try to understand the various reliability models used in software industry. The following are the various types of software reliability models: Jelinski-Moranda Model Littlewood Models Goel-Okumoto imperfect Debugging Model Goel- Okumoto Nonhomogenous Poisson process model Musa- Okumoto Logarithmic Poisson execution Time model The Delayed S and Inflection S models J-M ModelS Five Assumption Criteria for Model Evaluation Modeling process
19.1 INTRODUCTION TO SOFTWARE RELIABILITY MODELS Software reliability modeling has been one of the most active areas in software engineering. Elbert and associates (1992) examined seven reliability models with data from a large and complex software system that contained millions of lines of source code.
DBA 1728
NOTES
They found that some models gave reasonable results, and others provided unrealistic estimates. Despite a good fit between the model and the data, some models predicted the probability of error detection as a negative value. The range of the estimates of the system from these models is incredibly wide from 5 to 6 defects up to 50,000. Software reliability growth models can be classified into two major classes depending on the dependent variable of the model. For the time between failures models, the variable under study is the time between failure. This is the earliest class of models proposed for software reliability assessment. It is expected that the failure time will get longer as defect are removed from software product. A common approach of this class of model is to assume that the time between , the (i-1)st and the ith failures follows a distribution whose parameters are related to the number of latent defects remaining in the product after the (i1)st failure. The distribution used is supposed to reflect the improvement in reliability as defects are detected and removed from the product. The parameters of the distribution are to be estimated from the observed values of time between failures. Mean time to next failure is usually the parameter to be estimated for the model. For the fault count models the variable criterion is number of faults or failures (or normalized rate) in a specified time interval. The time can be CPU execution time or calendar time such as hour, week, or month. The time interval is fixed a priority and the number of defects or failures observed during the interval is treated as a random variable. As defects are detected and removed from the software, it is expected that the observed number of failures per unit time will decrease. The number of remaining defects or failures is the key parameter to be estimated from this class of models. The following paragraph describe several models in each of the two classes. The models were selected based on experience and may or may not be a good representation of the many models available in the literature. We first summarize three time between failures models, followed by three fault count models. 19.2 JELINSKI-MORANDA MODEL The Jelinski-Moranda (J-M) model is one of the earliest models in software reliability research (Jelinski and Moranda, 1972). It is a time between failures model. It assumes N software faults at the start of testing, failures occur purely at random, and all faults contribute equally to cause a failure during testing. It also assumes the fix time is negligible and that the fix for each failure is perfect. Therefore, the software products failure rate improves by the same amount at each fix. The hazard function (the instantaneous failure rate function) at time ti , the time between the (i-1)st and ith failures, is given Z(ti) = [N-(i-1)] where N is the number of software defects at the beginning of testing and is a proportionality constant. Note that the hazard function is constant between failures but
decreases in steps of following the removal of each fault. Therefore, as each fault is removed, the time between failures is expected to be longer. 19.3 LITTLEWOOD MODELS The Littlewood (LW) model is similar to the J-M model, except it assumes that different sizes, thereby contributing unequally to failures (Littlewood,1981). Larger-sized faults tend to be detected and fixed earlier. As the number of errors is driven down with the progress in test, so is the average error size, causing a law of diminishing return in debugging. The introduction of the error size concept makes the model assumption more realistic. 19.4 GOEL-OKUMOTO IMPERFECT DEBUGGING MODEL In the process of fixing a defect, new defect may be injected. Indeed, defect fix activities are known to be error-phone. During the testing stages, the percentage of defective fixes in large commercial software development organizations may range from 1% or 2% to more than 10%. Goel and Okumoto (1978) proposed an imperfect debugging model to overcome the limitation of the assumption. In this model the hazard function during the interval between the (i-1)st and the ith failures is given Z(ti) = [N-p(i-1)] where N is the number of faults at the start of testing , p is the probability of imperfect debugging, and is the failure rate per fault. 19.5 GOEL- OKUMOTO NONHOMOGENOUS POISSON PROCESS MODEL Goel and Okumoto propose that the cumulative number of failure observed at time t, N(t), can be modeled as a non-homogenous Poisson (NHPP) as a Poisson with a timedependent failure rate fallows an exponential distribution. The model is, P{N(t) = y} = [m(t)]y *e-m(t), y = 0,1,2. Y! Where, m(t) = a(1-e-bt) (t) a m(t) = abc-bt In the model, m(t) is expected number of failure observed by time t, (t) is the failure density; a is the expected number of failure to be observed eventually; and b is the fault detection rate per fault. As seen, m(t) and (t) are the cumulative distribution function [F(t)] and the probability density function [f(t)], respectively, of the exponential function discussed in the preceding section. The parameters a and b correspond to k and .
113
NOTES
DBA 1728
NOTES
Therefore, the NHPP model is a straight application of the exponential model. The reason it is called NHPP is perhaps because of the emphasis on the probability distribution of the estimate of the cumulative number of failures at a specific time t, as represented by the first equation. Fitting the model curve from actual data and for projecting the number of faults remaining in the system, is done mainly by means of the men value, or cumulative distribution function(CDF). In this model the number of faults to be detected, a, is treated as a random variable whose observed value depends on the test and other environmental factors. This is fundamentally different from models that treat the number of faults to be fixed unknown constant. Goel (1982) proposed a generalization of the Goel- Okumoto NHPP model by allowing one more parameter in the mean value function and the failure density function. Such a model is called the Goel generalized nonhomogenous Poisson process model; m(t) = a(1-e-btc) (t) a m(t) = abc e-btc t c-1 where a is the expected number of faults to be eventually detected and b & c are constant that reflect the quality of testing. The main value function and failure density function is actually the weibull distribution 19.6 MUSA- OKUMOTO LOGARITHMIC POISSON EXECUTION TIME MODEL Similar to the NHPP model, in the Musa- Okumoto (M-O) model the observed number of failures by a certain time, , is also assumed to be a nonhomogenous Poisson process (Musa and Okumoto, 1983). It attempts to consider that later fixes have a smaller effect on the software reliability than earlier ones. The logarithmic Poisson process is claimed to be superior for highly nonuniform operational user profiles, where some function are executed much more frequently than others. Also the process modeled is the number of failure in specified execution-time intervals. A systematic approach to convert the result to calendar-time data (Musa et al., 1987) is also provided. The model, therefore, consist of two components the execution-time component and the calendar- time component. The mean value function of this model is u() = (1/ )[ln (0 + 1)] where is the initial failure intensity , and is the rate of reduction in the normalized failure intensity per failure.
114
19.7 THE DELAYED S AND INFLECTION S MODELS Yamada et al. (1983) argue that a testing process consist of not only a defect detection process, but also a defect isolation process. Because of the time needed for failure analysis, significant delay can occur between the time of the first failure observation and the time of reporting. They offer the delayed S-shaped reliability growth model for such a process, in which the observed growth curve of the cumulative number of detected defects is Sshaped. The model is based on the nonhomogenous Poisson process but with a different mean value function to reflect the delay in failure reporting, m (t) = k [1(1+ t) e t ] where t is the time, is the error detection rate, and K is the total number of defects or total cumulative defect rate. In 1984, Ohba proposed another S-shaped reliability growth model the inflection S model (Ohba, 1984 ). The model describes a software failure detection phenomenon with a mutual dependence of detected defects. Specially the more failure we detect , the more undetected failures become detectable. This assumption brings a certain realism into software reliability modeling and is a significant improvement over the assumption used by earlier models-the independence of faults in a program. I (t) = K [(1- e t)/ (1+ie t)] Where t is time, is the error detection rate, i is the inflection factor, and k is the total number of defects or cumulative defect rate. The delayed S and inflection S models can be regarded as accounting for the learning period during which testers become familiar with the software at the beginning of a testing period. The learning period is associated with the delayed or inflection pattern as described by the mean value functions. The mean value function (CDF) and the failure density function (PDF) curve of the two models, in comparison with the exponential model. 19.8 J-M MODELS FIVE ASSUMPTION There are N unknown software faults at the start of testing. Failures occur randomly times between failure are independent. All faults contribute equally to cause a failure. Fix time is negligible. Fix is perfect for each failure; there are no new faults introduced during correction. The basic assumption of the fault count model are as follows (Goel, 1985): Testing intervals are independent of each other. Testing during interval is reasonably homogenous. Number of defects detected during nonoverlapping intervals are independent of each other.
115
NOTES
DBA 1728
NOTES
19.9 CRITERIA FOR MODEL EVALUATION In 1984 a group of experts (Iannino et al., 1984) devised a set of criteria for Reliability model assessment and comparison. The criteria are listed as fallows, by order of importance as determined by the group. (i) Predictive validity : The capability of the model to predict failure behavior or the number of defects for a specified time period based on current data in the model. (ii) Capability: The ability of the model top estimate with satisfactory accuracy quantities needed by software managers, engineers, and users in planning and managing software development projects or controlling change in operational software systems. (iii) Quality of assumptions: The likelihood that the model assumptions can be met, and assumption plausibility from the viewpoint of logical consistency and software engineering experience. (iv) Applicability: The models degree of applicability across different software products. Simplicity: A model should be simple in three aspects: Simple and inexpensive to collect data. Simple in concept and does not require extensive mathematical background for software development practitioners to comprehend. Readily implemented by computer programs.
19.10 MODELING PROCESS To model software reliability, the following process or similar procedures should be used. 1. Examine the data. Study the nature of data the unit of analysis the data tracking system, data reliability, and any relevant aspects of the data. Plat the data points against tine in the form of a scatter diagram, analyze the data informally, and gain an insight into the nature of the process being modeled. 2. Select a model or several models to fit the data based on an understanding of the test process, the data, and the assumptions of the models. The plot in step 1 can provide helpful information for model selection.
116
3. Estimate the parameters of the model. Different methods may be required depending on the nature of the data. The statistical techniques (e.g., the maximum likelihood method, the least squares method, or some other method) and the software tools available for use should be considered. 4. Obtain the fitted model by substituting the estimates of the parameters into the chosen model. At this stage, you have a specified model for the data set. 5. Perform a goodness-of-fit test and assess the reasonableness of the model. If the model does not fit, a more reasonable model should be selected with regard to model assumptions and the nature of the data. 6. Make reliability prediction based on the fitted model. Assess the reasonableness of the predictions based on other available information-actual performance of a similar product or of a previous release of the same product, subjective assessment by the development team, and so forth. Summary This chapter has covered numerous software reliability models, each with its own assumptions, applicability and limitations. Based on the criteria variable they use, software reliability growth models can be classified into two major classes: time between failures models and fault count models. From the practitioners point of view, the most important criteria for evaluating and choosing software reliability growth models are predictive validity, simplicity, and quality of assumptions. Software reliability models are most often used for reliability projection when development work is complete and before the software us shipped to customers. They can also be used to model the failure pattern or the defect arrival pattern in the field and thereby provide valuable input to maintenance planning. Review Questions 1. What is software reliability modeling? 2. Define Reliability growth model. 3. Explain the Jelinski-Moranda Model with an example? 4. Describe the Littlewood Models with applicability and limitations? 5. Explain wny Goel-Okumoto imperfect Debugging Modelling is used in software? 6. Briefly explain the Goel- Okumoto Nonhomogenous Poisson process model? 7. Describe the Musa- Okumoto Logarithmic Poisson execution Time model with suitable example? 8. Explain the Delayed S and Inflection S models? 9. List out the J-M ModelS Five Assumption? 10. What are the Criteria for Model Evaluation? 11. Describe the Modeling process of software reliability model?
NOTES
117
DBA 1728
NOTES
CHAPTER-20
ISO 9000 FOR SOFTWARE QUALITY
INTRODUCTION TO THE UNIT This chapter covers the ISO 9000 for software quality. It is one of the standards followed in the software industry. It covers the Range of activities, structure of ISO 9000 and ISO 9001 clauses. UNIT LEARNING OBJECTIVES After reading this chapter, the learner will try to understand the following things: Introduction to ISO 9000 for Software Quality ISO 9001, 9002, and 9003 Range of activities Structure of ISO 9000 ISO 9001 CLAUSES
20.1 INTRODUCTION TO ISO 9000 FOR SOFTWARE QUALITY Basic approach Agree what you do current practices Say what you do define practices in the formal management system Do what you say ensure compliance Record what you did Check on the results Act on the difference Standard first published in 1990 for quality systems Revised in 1994 Revised and rationalized in 2000
What is ISO 9000? International standard for quality assurance Quality by focus on process. Need for quality policy, standard and procedures ISO is NOT a product standard. ISO defines whats and not how Focus on- documented quality system covering all ISO requirements, and functionality in compliance to the documented quality system
20.2 ISO 9001, 9002, AND 9003 RANGE OF ACTIVITIES
NOTES
Supplier
Design Production Final Sub contractor inspection testing 9003 9002 9001 customer
installation
serving
20.3STRUCTURE OF ISO 9000

ISO 9000
FRAME WORK
LIFE CYCLE ACTIVITY
SUPPORTING ACTIVITIES
Management responsibility Quality system Internal audit Corrective action
contract review purchasers requirement development planning quality planning Design and implementation Testing and validation Acceptance Replication, delivery Maintenance
configuration management document control quality records measurements rules, practice conversions tools and techniques purchasing included s/w product training
119
DBA 1728
NOTES
20.4 ISO 9001 CLAUSES Management responsibility quality policy organization responsibility and authority resources management representative management review
Quality system quality system procedure quality planning
Contract review review-measurable, non-ambiguous amendment records
Design control planning organizational and technical interfaces input review verification validation changes
Document Control There must be proper procedures for document approval, issue and removal Document changes must be controlled. Purchasing Purchased material, including bought-in software must be checked for conforming to requirements. Purchases supplied product Material supplied by a purchaser, for example client-provided software must be properly managed and checked.
Product Identification The product must be identifiable at all stages of the process. In software terms this means configuration management. Process Control The development must be properly managed and quality requirements must be identified in a quality plan. Inspection and Testing In software terms this requires effective testing, ie unit testing, integration testing and system testing. Test records must be maintained. Inspection, Measuring and Test Equipment If integration, measuring and test equipment are used, they must be properly maintained and calibrated. Inspection Test status The status of an item must be identified. In software terms this implies configuration management and release control. Control of Non-conforming product In software terms, this means keeping untested or faulty software out of the released product or other places whether it might cause damage. Corrective action This requirement is both about correcting errors when found and also investigating why the errors occurred and improving the process to prevent occurrences. Handling This clause deals with the storage, packing and deliver of the software product. Quality Records Recording the steps taken to control the quality of the process is essential in order to be able to conform that they have actually taken place. Quality audits Audits of the quality system must be carried out to ensure that it is effective
NOTES
121
DBA 1728
NOTES
Training Training needs must be identified and met. Summary This chapter has covered the ISO 9000 clauses for software quality. Review Questions 1. What is ISO 9000? 2. What are the ranges of Activities followed in ISO 9000? 3. Explain the structure of ISO 9000 4. Describe the ISO 9000 clauses?
122
CHAPTER-21
CMM STRUCTURE
NOTES
INTRODUCTION TO THE UNIT: This chapter will cover the CMM structure in detail ie All the five levels, Key practices and various Key Process Areas. UNIT LEARNING OBJECTIVES After reading this chapter, the user will have a very good scope for implementation of SW-CMM in the software company. Key Practices Key Process Areas Five Levels of CMM Detailed study of KPAs
21.1 INTRODUCTION TO CAPABILITY MATURITY MODEL [CMM] STRUCTURE Definition for CMM A common sense application of process management and quality improvement concepts to software development and maintenance. A community developed guide. A model for organizational improvement. What the CMM does not cover? Issues that are addressed only directly, or by implication include: Specific tools, methods and technologies Concurrent engineering and teamwork Systems engineering, marketing, etc. Human Resources Organizational Behavior
The CMM structure is shown in the diagram (Figure 21.1). It consists of Key practices and Key Process Areas. This standard is followed in almost all the software industry.
123
DBA 1728
NOTES
Continuously Improving Process
OPTIMIZING(5) FOCUS ON PROCESS

IMPROVEMENTS
Predictable Process
MANAGED(4) PROCESS
MEASURED
Std Consistent
DEFINED(3) PROCESS
CHARACTERIZED FAIRLY WELL UNDERSTOOD
Process
Disciplined Process
REPEATABLE(2) CAN REPEAT

PREVIOUSLY MASTERED TASKS
INITIAL (1) UNPREDICTABLE &

POORLY CONTROLLED
Figure 21.1 SEI-CMM MODEL 21.1.1 Key Practices Of Cmm

CMM V1.1
LEVEL 2
LEVEL 3
LEVEL 4
LEVEL 5
A total of 18 KAPS each with established details. Key process areas organized by common features commitments to perform ability to perform activities performed measurements & analysis verifying implementation each of the KAPS are organized by common features that contain key practices a total of 316 key practices in CMM v1.1 21.1.2 Ability to perform The CMM describes the preconditions that must exist in the project or organization to implement the s/w process competently. Typically includes function, Resource, Delegation, Training and Orientation.
124
Activities performed Describe the roles & procedures necessary to implement & KPA Typically includes Establishing plans & procedures Performing the work Tracking it Taking corrective actions of necessary
NOTES
Measurement and analysis Describes the need to measure the process & analyze the measurements Typically includes examples of the measurements that could be taken to determine the status and effectiveness of the activities performed common feature
Verifying implementation Describes the steps to ensure that the activities are performed in compliance with the process that has been established Typically includes reviews & audits by Senior management Project management Software quality. assurance
21.2 INTENT OF THE INITIAL MATURITY LEVEL Performance driven by the competence and heroics of the people doing the work High quality and exceptional performance possible so long as the best possible can be hired Unpredictable for food or ill The major problems facing the s/w organization are managerial, not technical Over commitment Abandon plans & procedures Product may work but exceed budget schedule Not respectable
21.3 INTENT OF THE REPEATABLE MATURITY LEVEL The predominant need is to establish effective s/w project mgmt Software process management processes are documented & followed Organizational policies guides the projects in establishing mgmt processes Successful practices developed on earlier projects can be repeated
DBA 1728
NOTES
Realistic commitments Project standard Control integrity of work products Standards defined and followed Track cost, schedule & functionality Effective relationships with subcontractor
21.4 INTENT OF THE DEFINED MATURITY LEVEL this level builds on the software project management foundation To control a process, it must be defined, documented and understood The output of one task flow smoothly into the inputs of the next task At this level, the organization builds processes that empower the individuals doing the work
BEST PRACTICES Organizations standard software process Projects standard software process Software engineering processes Software management processes Organization with training program Technical concepts 1. peer reviews 2. Inter-group co-ordination 3. Software product engineering 4. Integrated software management Other than technical 1. Training program (centralized project training) 2. Organization process definition 3. Organization process focus 4. Overall organization 21.5 INTENT OF THE MANAGED MATURITY LEVEL Apply the principles of statistical process control Address the special causes of process variation 1. Software quality management
2. Quantitative process management The organization sets quantitative quality goals For processing ( control = narrowing variance of process performance ) For products (predictable high quality) 21.6 INTENT OF THE OPTIMIZING MATURITY LEVEL Identify and eliminate chronic causes of poor performance Continuously improve the software process 1. Process change management 2. Technology change management 3. Defect prevention Everyone is involved Prevent recurrence cost/benefit analysis of new Technologies best practices & lessons Disseminated Maturity levels cannot be skipped processes at high maturity levels may be performed, although perhaps ineffectively, even by the organization at the initial level process capability is built in stages, since some processes are ineffective when others are not stable Each level provides and necessary foundation for improvements and undertaken at the next level improvement is a way of life continuous process Analysis of weakness & defects to
NOTES
Other capability maturity models people (Developing human talent) software acquisition integrated product development Maturity model integration SE CMM Integrated - CMM
127
DBA 1728
NOTES
Applying the CMM (i) Appraisals (ii) Assessments Software process Assessment (Spa) Internal process improvement(ipi) (current) Interior profile(ip) (iii) Evaluations (source selection and contract a manufacturing) (iv) process improvement efforts 21.7 MOVING FROM LEVEL 2 TO LEVEL 3 At level 2, the focus is on projects At level 3 the emphasis shifts to the organization
Best practices are gathered across the organization Process are tailored as appropriate the organization supports the projects by establishing common process common measurements training Key process Areas
Maturity levels
Maturity Levels
Indicates
contains Key process areas
Process Capability Achieve
Organized by Common Feature
Goals
Address Implementation or institutionalization
contain
Key practices
Infrastructure or activities
Well-defined evolutionary plateaus on the path to becoming a mature SW organization. Each level is layer in the foundation for continuous process improvement there are 5 maturity levels in the CMM Maturity levels are key process area
describe
128
Key Process Areas

Maturity Levels
Indicates contains
Key process Areas
NOTES
identify a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability Identify the issues that must be addressed to achieve a maturity level
Process Capability
achieve Goals
Organized by
Address Summarize the key practices of the key process areas Considered important for enhancing process capability for maturity level Can be used to guide organizations and appraisal teams in assessing alternative ways to implement process improvement
Implementation or institutionalization
contain Key
describe
Infrastructure or activities
21.7.1 Organization process focus (OPF) The purpose is to establish the organizational responsibility for software process activities that improves the organizations overall software process capability. It Involves : 1. Developing & maintaining & understanding of the organizations & projects processes 2. coordinating the activities to access, develop, maintain & improve these processes Dedicating people to process A dedicated group of people is responsible for the organizations software process activities: eg Appraisals software process improvement plans Includes maintaining the organizations software process database and providing training about the organizations s/w process Dedicated groups may vary A software engg process group(SEPG) is the typical means of providing process focus for the organization other ways of focusing on process are possible process review board quality tricks process steering committee software quality assurance
these mechanism may work in conjunction with, or in place of, an SEPG

DBA 1728
NOTES
Responsibilities of SEPG Establish process standards Maintain the process database Serve as the focal point for technology transition Provide process education Provide project consultation Make periodic assessments and status reports
Relation to organization process Definition organization process focus & organization process definition are tightly coupled organization process focus focuses on the who organization process definition focuses on what
21.7.2 Organization Process Focus Entry criteria AB.1 process group Co.2 senior mgmt sponsorship Co.3 senior mgmt oversight Organization process definition Purpose is to develop and maintain a usable set of software process assists that improve process performance and provide & basis for cumulative, long-term benefits Involves Developing and maintaining the organizations std software process and related process assets
Software process assets A collection of entities, maintained by an organization, for use by projects in developing, tailoring, maintaining, and implementing their s/w practices include the organizations std s/w process description of s/w life cycle approved for use guidelines & criteria for tailoring the organizations std s/w process the organizations s/w process database a library of s/w process-related documentation.
Tailoring guidelines How to use OSSP guidelines for tailoring the organizations std s/w process are available to individual projects
what can be tailored out? What cannot? How much can a process element be modified? What parts of the process element should be considered for tailoring?
NOTES
Organizations s/w process database: Measurement Data A central repository for organization measurement data contains Actual measurement data (the numbers) from individual projects The related into needed to understand the measurement data & apply it to new projects
Library of s/w process related documentation The library where best documents used on past projects are kept Also contains lessons learned reports, ex documents & document fragments In general, contains any documents that can be used as model & example for future projects
Organization process definition

PROJECTS DEFINED S/W PROCESS
Co.1 ORGANIZATIO N-AL POLICY
Ac.1 TAILOR OSSP FOR INDIVIDUAL PROJECT AC.2 REVISE DEFINED S.P AC.3 DEVELOP SDP AC.4 MANAGE BASED ON DEFINED S/W
PROCESS AC.5 USE S/W PROCESS DATABASE AC.6-8 MANAGE SIZE, EFFORT, COSTS, CRITICAL COMPUTER RESOURCES AC.9 MANAGE CRITICAL DEPENDENCIES AC.10 MANAGE RISKS AC.11 PERFORM PERIODIC REVIEWS
SDP
AB.1 ADEQUATE RESOURCES
REVISED SIZE, EFFORT, COST,

RESOURCE ESTIMATES
AB.2-3 TRAINING
TRAINING
NEEDS
131
DBA 1728
NOTES
Co.1 ORGANIZATI ON-AL
POLICY
Ac.1 ADDRESS PROCESS AC.2 PLAN PROCESS IMPROVEMENT AC.3 COORDINATE PROCESS IMPROVEMENT AC.4 COORDINATE USE OF ORGANIZATION
PROCESS DATA BASE AC.5 EVALUATE AND TRANSFER TECH AC.6 COORDINATE TRAINING AC.7 DISSEMINATE PROCESS INFO
Process Improvement Plan
Assessmen t technology evaluation reports
AB.2 ADEQUATE RESOURCES
AB.3-4 TRAINING, ORIENTATION
eNTRY CRITERIA AB.1 PROCESS GROUP CO.2 SENIOR MANAGEMENT

SPONSORSHIP CO.3 SENIOR MANAGEMENT OVERSIGHT
Training Needs Process imp status info
21.7.3 Training program Purpose is to develop the skills and knowledge of individuals also they can perform their roles effectively & efficiently Involves Identifying the training needs of the organization, projects and individuals Developing and/or procuring training to address these needs Software training is identified, developed & established by an organization training group The training group Begins by reviewing each s/w projects training needs and plans Analyses the skills needed by the organization and row & when needed training will occur Prepares, develops and maintains training courses Maintain training records
Organizational training (OT): OT needs are identified base on the organizations S.S.P project, needs organizations culture individual needs
132
Required Training At level 2, the phrase receive training is used Training at level 2 may not be institutionalized across the organization At level 3 and above, the phrase receive required training is used Institutionalization of training is expected
NOTES
Alternative vehicles Training may include informal as well as formal instructions to transfer skills and knowledge Mentors & on-the0job training can be very very effective when implemented properly Remember that informal vehicles are frequently abused
ORGANIZATI ON TRAINING PLAN AC.2 DEVELOP ORGANIZATION TRAINING
PLAN AC.3 TRAIN AC.4 PREPARE TRAINING COURSES AC.5 ESTABLISH WAIVER PROCEDURE
Co.1 ORGANIZATION -AL POLICY
AB.2 ADEQUATE
RESOURCES
TRAINING
COURSES
AB.4 ORIENTATION
AC.6 MAINTAIN TRAINING NEEDS
WAIVERS
Ac.1 pROJECT
TRAINING PLAN
ENTRY CRITERIA AB.1 TRAINING GROUP AB.3 SKILLED TRAINERS
TRAINING
RECORDS
TRAINING
NEEDS
Various Training vehicles formal classroom training, interactive video/computer training, after hours training, self instruction, on-the-job, mentoring, university related & vendor supplied
21.7.4 Integrated software mgmt(ISM) Involves Developing the projects defined s/w process by tailoring the OSSP Managing the s/w project according to this defined s/w process
purpose is to integrate the projects s/w engg & mgmt activities into a coherent, defined s/w process tailored from the organization software process assets
DBA 1728
NOTES
Tailoring organizational process at level 3 each project tailors the organizationals ssp for particular needs includes SLC,stds, procedures etc., uses the lessons learned & data from previous projects feedback of appropriate measurement data dn documents to the organization fro use by other projects.
Project Mgmt Evolves S/w development plan is now based on the projects defined s/w process Process can use & share process data & lessons learned Integrated s/w management is the evolution of s/w project planning & s/w project tracking & oversight KPAs
21.7.5 Software Product Engineering(SPE) Purpose is to consistently perform a well designed engg process that integrate all the s/w engg activities to produce correct, consistent s/w products effectively & efficiently Involves performing the engg tasks to build & maintain the s/w using appropriate tools & methods
Software life cycle processes Development & maintenance activities include s/w requirements Analysis, s/w design, coding, Testing, Integration, Testing services include, unit, Integration & system acceptance
Documentation Addresses needs that span the life cycle Customer and end user documentation includes] User manuals, Training materials, operator manuals Developer/maintainer documentation includes s/w requirements documents, design documents, Test documents & maintenance manuals
Consistency and Traceability Consistency & Traceability among documents are critical to their usefulness If specifications are not consistent, they are not usable If the relationship between documents is not clearly traceability, their usefulness is minimized
21.7.6 Inter Group Coordination(IC) Purpose is to establish & means for the software engg group to participate actively with other engg groups so that the project is better able to satisfy the customers needs effectively and efficiently. Involve Disciplined interaction and coordination of the project engg groups with each other to address system level requirements, objectives, and plans
NOTES
Interdisciplinary Groups The s/w Engg group actively interfocus with a variety of groups. Examples of these groups, to whom the interface must be managed include Systems Engg, Marketing, Training, subcontract mgmt, documentation
Inter group coordination is a first step on the road to concurrent Engg.

S/W
Co.1 ORGANIZATIO N-AL POLICY
REQUIREMENTS
AB.1 ADEQUATE
RESOURCES
Ac.1 INTEGRATE TOOLS & METHODS AC.2 ANALYZE REQUIREMENTS AC.3 DESIGN AC.4 CODE AC.5-7 TEST- INTEGRATION, SYSTEM
ACCEPTANCE AC.8 DOCUMENT AC.9 COLLECT DEFECT DATA AC.10 MAINTAIN CONSISTENCY ACROSS WORK PRODUCTS
S/W
DESIGN
CODE
AB.2-4 TRAINING, ORIENTATION
TEST PLANS, PROCEDURES, CASES, LOGS
USER MANUALS TRACE ABILITY
Figure 21.2Inter Group Coordination Peer Reviews (PR) Purpose is to remove defects from the software work products early and efficiently. An important corollary effect is to develop & better understanding of the software work products and of defects that might be prevented.
135
DBA 1728
NOTES
Involves 1. Methodical examination of work products by the producers peers to identify defects and dreds where changes are needed 2. Identifying products that will undergo peer review in project defined software process Performing peer reviews Plan and schedule peer reviews Train leaders and participants Give materials to reviewers in advance Assign each reviews and specified role Specify criteria to begin and reviews Use preplanned checklists Identify action items and track the closure Collect and analyze data for product and peer review process
21.8 MOVING FROM LEVEL 3 TO LEVEL 4 (LEVEL 4 MANAGED) At level 3 measurements have been defined and collected systematically At level 4, decisions are made based on data collected KPAS MANAGED LEVEL software quality management quantitative process management
Quantitative process management (QPM) purpose is to control the process performance of the software project quantitatively Involves establishing goals for process performance measuring the performance of the project analyzing these measurements making adjustments to maintain process performance within acceptable limits
Controlling special cause of variation An important concern is identifying variations in performance that are not within the normal range of process performance Extraordinary events outside the bounds of process capability (special cause)
136
Taking corrective action at level 4 Quantitative process management focuses on the process Process capability is quantitatively known When performance falls outside the limits Take corrective action when appropriate meaning of quantitative control Quantitative control in the CMM implies any quantitative statistically based techniques The word statistical and Quantitative imply data Data reflects facts Fact based management result in objective decisions
NOTES
21.9 MOVING FROM LEVEL 4 TO LEVEL 5 (LEVEL -5 - OPTIMIZING) At level 4, the process is quantitatively understood At level 5, continuous improvement is a way of life In immature organizations, no one may be responsible for process improvement Mature organizations usually have 70-80% participation in improvement activities at any given point in time- everyone is involved
Addressing common causes of variation continuous process improvement means controlled this means measurably improving process capability KPAs optimizing level Process change environment Technology change management Defect prevention
21.9.1 Defect Prevention Purpose is to identify the cause of defect and prevent them from reusing INVOLVES analyzing defects that were encountered in the past taking specific action to prevent the occurrence of these types of defects in the future
Fixing problems before occurrence focus is an causal analysis what in the process permitted the defect to occur what in the process need to be corrected to prevent from occurring in the future
137
DBA 1728
NOTES
Identify defects Causal analysis meeting Implement actions Review results
Change projects Defined process
Change organization standard software process
Figure 21.3 Defect Prevention
21.9.2 Technology Change Management Involves Identifying selecting, and evaluating new technologies Incorporating effective technologies into the organization Purpose is TO IDENTIFY NEW TECHNOLOGIES ( ie, Tools, methods, and process) and transfer them in an organization in an orderly manner
Reacting to innovation Technology changes occur at all maturity levels at level 5, innovation is Introduced into the process in a disciplined way Part of the culture (institutionalize
21.9.3 Process Change Management purpose is to continuously improve the software process used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development Defining process improvement goals Systematically identifying, evaluating, and implementing improvements to the organizations standard software process and the projects defined s/w processes
Involves
138
Change is a process Disciplined change is the key to success improvement includes 1. Planning 2. Evaluating improvement proposals and planning actions 3. Establishing process improvement teams 4. Conducting pilot programs for process improvements 5. Updating procedures, training, etc. 6. Improvements are transferred into everyday practice across the organization Summary This chapter has covered the details of CMM and its structure ie mainly Key practices, Key process areas and Five levels. It is best practiced in software industry. Review questions 1. Describe the CMM structure in detail? 2. Explain the various key practices of CMM? 3. Describe the Key process Areas of CMM? 4. Explain the applications of various key process areas? 5. Briefly explain the various key process level from one level to another with suitable example?
NOTES
139
DBA 1728
NOTES
CHAPTER 22
CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
Introduction to the unit This chapter will cover the details of CMMI in terms of stage representation and maturity levels. It also covers benefits of CMMI. Unit learning objectives After reading this chapter the user tries to understand the architecture of CMMI in terms of the following: CMMI Model Staged Representation CMMI Maturity levels CMMI Benefits 22.1 INTRODUCTION TO CMMI Capability Maturity Model Integration is to provide guidance for improving the organizations processes and ability to manage the development, acquisition, and maintenance of products and services. Actually CMMI has both Software and System Engineering and it has two representations. One is the staged representation. The other is the continuous representation. In the staged representation maturity level of an organization ranges from level 1 to 5. In the continuous representation each process capability level ranges from 0 to 5. The staged representation is most suitable for an organization that does not know which processes need to be improved first because the staged representation offers process areas applicable to each maturity level. The continuous representation provides flexibility for selecting processes fit for achieving business goal of the organization. The staged representation has 25 process areas. The concept of goals in CMMI is the same as in SW CMM. 22.2 CMMI MODEL STAGED REPRESENTATION The following figure 22.1 shows the staged representation of CMMI and Maturity level
5
FOCUS ON PROCESS IMPROVEMENT

4
O PTIMIZING
PROCESS MEASURED AND CONTROLLED

3
Q UANTITATIVELY MANAGED
PROCESS CHARACTERIZED FOR THE ORGANIZATION DEFINED
AND IS PROACTIVE 2
PROCESS CHARACTERIZED FOR PROJECTS

AND ITS OFTEN REACTIVE 1
MANAGED
PROCESS UNPREDICTABLE POORLY INITIAL

CONTROLLED AND REACTIVE
Figure 22.1: Staged representation of CMMI

22.3 CMMI MATURITY LEVELS Level 1: Initial In this maturity level the processes are performed but often in an ad-hoc or chaotic manner, Performance dependent on competence of individuals, Performance is difficult to predict and Management practices may not be effective. Level 2: Managed In this maturity level the Project management is more disciplined, Organizational policies are documented and followed, Project plans and process descriptions are documented and followed, Resources are adequate, Responsibility and authority is assigned, Measurements and reviews occur at defined points. Level 3: Defined In this level the Engineering processes are more effectively implemented, Organization is more proactive, Organizational training needs are identified and provided; Organization has a standard process, which individual projects tailor to their needs. Level 4: Quantitatively managed In the Quantitatively Managed level the statistical and other quantitative methods are used at the organization and project levels to understand past process performance, predict the future process performance, and predict the future product quality and service quality. Level 5: Optimizing In this level the measurements are used to select process improvements and innovations, estimate the cost and benefits of the improvements and innovations, measure the actual cost and benefits of the process improvements and innovations. the analyses are concerned with addressing common Causes of process variation. Both, the projects defined processes and the organizations set of standard processes are targets of the improvement activities. The quantitative process improvement objectives for the organization are established and continually revised to reflect changing business objectives. The incremental and innovative improvements that measurably increase process capabilities are identified, evaluated and deployed. The following are some of the benefits and business reasons for implementing process improvement: The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it.
NOTES
141
DBA 1728
NOTES
Process improvement increases product and service quality as organizations apply it to achieve their business objectives. Process improvement objectives are aligned with business objectives.
22.4 CMMI BENEFITS The CMMI product suite is at the forefront of process improvement because it provides the latest best practices for product and service development and maintenance. The CMMI models improve upon the best practices of previous models in many important ways. CMMI best practices enable organizations to do the following: 1. More explicitly link management and engineering activities to their business objectives 2. Expand the scope of and visibility into the product life cycle and engineering activities to ensure that the product or service meets customer expectations 3. Incorporate lessons learned from additional areas of best practice (e.g., measurement, risk management, and supplier management) 4. Implement more robust high-maturity practices 5. Address additional organizational functions critical to their products and services 6. More fully comply with relevant ISO standards Summary This chapter has covered the architecture of CMMI, staged representation, maturity levels and benefits. Review questions 1. What is CMMI? 2. Explain the CMMI Model Staged Representation with neat sketches? 3. What are the various CMMI Maturity levels? Explain? 4. List out the CMMI Benefits?
142
CHAPTER-23
PEOPLE CMM [P-CMM]
INTRODUCTION TO THE UNIT This chapter covers the entire architecture of P-CMM, objectives, assessments, advantages and challenges lies in the P-CMM. UNIT LEARNING OBJECTIVES After reading this chapter, the user tries to understand the following concepts in the P-CMM: Purpose of P-CMM Objectives of P-CMM P-CMM Assessments Architecture of P-CMM Advantages of P-CMM Challenges in P-CMM.
NOTES
23.1 DESCRIPTION / INTRODUCTION TO P-CMM P-CMM is a maturity framework developed in 1995 by the SEI, Carnegie Mellon University, U.S. P-CMM maximize the potential of the workforce as well as retain it. To help software organizations groups on improving the capability of their workforce It describes on evolutionary improvement path from adhoc. Its practices have been included in industrial experience, because they have significant impact individual, team, unit and organizational performance. Model for effective management of people. Managing and developing workforce of an organization. Mature, disciplined document of the knowledge, skills an d motivation of the people that fuel enhanced the performance.
23.2 PURPOSE OF P-CMM To enhance the readiness of software development Information systems organizations To undertake increasingly complex applications By helping them to attract, grow, motivate and deploy Retaining the talent necessary to improve their software development capability
DBA 1728
NOTES
23.3 OBJECTIVES OF P-CMM To help organization to characterize the maturity of their workforce practices To guide a program of continuous workforce development To set priorities for immediate action To integrate workforce development with process improvement To establish a culture of professional excellence
23.4 P-CMM ASSESSMENTS Use trained teams of 4-8 experienced professionals Use a questionnaise Review relevant documentation Interview process owners, managers and other members of the workforce Provide findings to the assessment sponsor\
23.5 ARCHITECTURE OF P-CMM The P-CMM follows a structure that is similar to Software CMM. Five levels of maturity are identified. Each level is characterized by a set of key Process Areas (KPAs). In order to be at a given level, all the Key Process Areas of all the preceding levels must be satisfied. The five levels and the KPAs for each level are shown in the diagram. The brief discussion of various levels and there are following to the common practices. At Level 1- called the Initial level, the performance of the organization is highly dependent on individuals and hence is inconsistent. There are no institutionalized procedures for most of the people related functions. Managers are not formally trained in people skills. Important job functions like interviewing, performance appraisals, etc., are performed in an ad-hoc manner. There is no conscious effort made to develop employees skills. People do not see a synergy between their personal aspirations and the organizational goals. Just as in the case of an organization at the Software CMM Level 1, an organization at people CMM Level 1 need not necessarily be under- performing and nor should the managers of this organization be perceived as people with no skills who are guiding the others. At Level 2 called the Repeatable level, the focus is on Insist basic management discipline into workforce activities. The Key process areas are compensation, training, performance management and staffing. At Level 3 called the Define level, the focus is on to identify core competencies and align workforce activities with them. The key process areas are Participatory culture, competency-based practices, career development, competency developed work force planning and knowledge skills and analysis (competence management).
At Level 4 called the Managed level, the focus is on qualitatively mangement, organizational growth in workforce capabilities and establish competency based teams. The Key process areas are Organizational performance alignment (team management), organizational competency management, Team based practices and team building mentoring. At Level 5 called the optimizing level, the focus is on continuously improve methods for developing personal and organizational competence. The key process areas are continuous workforce improvement coaching, personal competency development (Capability management). 23.6 ADVANTAGES OF P-CMM P-CMM provides is a way to identify and institutionalize the best practices. P-CMM embodies the practices of successful organizations.
NOTES
23.7 CHALLENGES IN P-CMM Faced in developing organization-wide competency-based practices is the rapid change in technologies. As the technology changes and the demand for shorter cycle time increases, defining the competencies required to succeed becomes difficult. In the area of compensation and performance management when the teams are geographically distributed. Compensation levels are different in different countries and this may lead to the perception of lack of parity or equity across the teams.
Summary This chapter has covered the details of People CMM and its various limitations, applicability, and objectives towards software industry. Review Questions 1. What is the Purpose of P-CMM? 2. What are the Objectives of P-CMM? 3. How does the P-CMM Assessments are made? 4. Explain the Architecture of P-CMM in detail? 5. List out the Advantages of P-CMM? 6. What are the Challenges in P-CMM.?
145
DBA 1728
NOTES
CHAPTER -24
PERSONAL SOFTWARE PROCESS [PSP]
INTRODUCTION TO THE UNIT This chapter covers the basic concepts of Personal Software Process i.e., PSP for software industry. The PSP contains time measurement, planning and various levels pertaining to software. UNIT LEARNING OBJECTIVES: After reading this chapter the learner will get expose to personal software process in terms of the following: Time measurement PSP Planning PSP Levels
24.1 INTRODUCTION TO PSP PSP is based on the work of David Humphrey [Hum 1997]. PSP is suitable for individual use. It is important to note that SEI CMM does not tell software developers how to analyze, design, code, test or document software products, but assumes that engineers use effective personnel practice. PSP recognizes that the process for individual usage different from the necessary for a team. The quality and productivity of an engineer is to a great extent dependent on its process. PSP is a framework that helps engineers to measure and improve the way they work. It helps in developing personal skills methods by estimating and planning, by showing how to track performance against plans and by providing a defined process which can be tuned by the individual. 24.2 TIME MEASUREMENT PSP advocates that engineers should track they way they spend time. Because boring activities gets stretched in time and interesting activities shortened, therefore, actual time spent on a task should be measured with a help of stop clock to get an objective picture of the time spent. An engineer should measure the time he spends for designing, writing code, testing, etc. The clock may be stopped for an example when attending an telephone call, taking a coffee break, etc. 24.3 PSP PLANNING Individuals most plan the projects. They must estimate the maximum, minimum and the average LOC required for the product. They should use their productivity in minutes/ LOC to calculate the Maximum, Minimum and the average development time. They must record the plan data in a project plan summary.
The PSP is schematically shown in the figure 24.1. While carrying out different phases, individuals must record log data using time measurement. During Post- Mortem, they can compare the log data with their project plan to achieve the better planning in the future projects in order to improve their process
Planning Designing Coding Compiling Testing Logs Project Plan Summary
NOTES
Post-Mortem
Figure 24.1 Diagram Schematic Representation of PSP 24.4 PSP LEVELS The PSP levels are summarized in diagram. PSP2 introduces defect management via the use of checklist for code and design reviews. The checklists are developed from gathering and analyzing defect data from earlier projects.
PSP3
Personal Process Evolution
PSP2 Personal quality management Design and code Review PSP1 Time and schedule planning PSP0
Personal Measurement, Basic size measures and coding standards
Figure 24.2 Diagram Levels of PSP Summary This chapter has covered the details of personal software process for the software industry.
DBA 1728
NOTES
CHAPTER-25
COCOMO [CONSTRUCTIVE COST MODEL]
INTRODUCTION TO THE UNIT This chapter will cover the software cost estimation of COCOMO model. This model has the components of basic effort and schedule. A case study is also discussed in this chapter. UNIT LEARNING OBJECTIVES: After reading this chapter the user will estimate the software products using COCOMO by the following components: COCOMO Basic Effort and Schedule Estimating Formulas Assumptions Life-Cycle Description Software work breakdown structure A Typical COCOMO Project Profile
25.1 INTRODUCTION TO COCOMO One popular, open, and well-documented software cost model is the Constructive Cost Model (COCOMO) developed by Barry Boehm. The evolution of COCOMO provides an interesting window for observing the evolution of software engineering economics over the fast 20 years. The COCOMO estimating equations follow this simple form: Effort = C1 EAF (size)p1 Time = C2 (Effort)p2 Where: Effort = number of staff-months C1 = a constant scaling coefficient for effort EAF = an effort adjustment factor that characterizes the domain, personnel, environment, and tools used to produce the artifacts of the process Size = size of the end product (in human-generated source code), measured by the number of delivered source instructions (DSI) required to develop
148
the required functionality P1 = an exponent that characterizes the economics of scale inherent in the process used to produce the end product, in particular the ability of the process to avoid non-value-adding activities (rework, bureaucratic delays, communication overhead) Time = total number of months C2 = a constant scaling coefficient for schedule P2 = an exponent that characterizes the inherent inertia and parallelism in managing a software development effort 25.2 COCOMO The original COCOMO model [Boehm, 1981] was one of the minor breakthroughs in software engineering during the early 1980s. It was breakthrough partly because of its inherent technology contribution but primarily because it provided a welldefined framework for communication of trade-offs and priorities associated with software cost and schedule management. A huge benefit offered by the COCOMO model was the ability to make an estimate, reference a credible basis for it, reason about its strengths and weaknesses, and negotiate with the stakeholders. The original COCOMO model was based on a database of 56 projects. Its three modes reflected the differences in process across a range of software domain. These modes were identified as organic, semidetached, and embedded. Organic mode projects were characterized by in-house, less-complex developments that had flexible processes. Features, qualities, cost, and schedule could be freely changed with minimal overhead. Embedded mode systems represented typical defense community projects: Complexity, reliability, and real-time issues were dominant, and the contractual nature of the business resulted in a highly rigorous process. Features, qualities, costs, and schedules were tightly controlled, and changes required approvals by many stakeholders. Semidetached mode projects represented something in between.
NOTES
25.3 BASIC EFFORT AND SCHEDULE ESTIMATING FORMULAS These were the original COCOMO cost estimation relationships: Organic mode Effort = 3.2 EAF (size)1.05 Time (in months) = 2.5 (Effort)0.38
DBA 1728
NOTES
Semidetached mode Effort = 3.0 EAF (size)1.12 Time (in months) = 2.5 (Effort)0.35 Embedded mode Effort = 2.8 EAF (size)1.2 Time (in months) = 2.5 (Effort)0.32 Where: Effort = number staff-months EAF = product of 15 effort adjustment factors Size = number of delivered source instructions (in units of thousands of lines of code) The effort adjustment factor (EAF) multiplier represents the combined effects of multiple parameters. These parameters allow the project to be characterized and normalized against the projects in the COCOMO database. Each parameter is assessed as very low, low, normal, high, or very high. The effect of each parameter setting is a multiplier that typically ranges from 0.5 to 1.5. The product of these 15 effects is used as the coefficient in the cost equation. Table 25.1 Various parameters of COCOMO
IDENTIFIER EFFORT ADJUSTMENT FACTOR Required reliability Database size Product complexity Execution time constraint Main storage constraint Virtual machine volatility Computer turnaround time Analyst capability Applications experience Programmer capability Virtual machine experience Language experience Use of modern practices Use of software tools Required development schedule PARAMETER RANGE 0.75-1.40 0.94-1.16 0.70-1.65 1.00-1.66 1.00-1.56 0.87-1.30 0.87-1.15 1.46-0.71 1.29-0.82 1.42-0.70 1.21-0.90 1.14-0.95 1.24-0.82 1.24-0.83 1.23-1.10 POTENTIAL IMPACT 1.87 1.23 2.36 1.66 1.56 1.49 1.32 2.06 1.57 2.03 1.34 1.20 1.51 1.49 1.23
RELY DATA CPLX TIME STOR VIRT TURN ACAP AEXP PCAP VEXP LEXP MODP TOOL SCED
150
25.4 ASSUMPTIONS Several assumptions are inherent in the COCOMO formulas. Delivered source instructions include all (noncomment) lines of computer- processed code. The development life cycle starts at the beginning of product design and ends with acceptance test at the conclusion of integration and rest phase. The activities include only direct-charged project efforts and exclude typical overhead activities such as administration support, facilities, and capital equipment. A staff-month consists of 152 hours. The project will be well managed. The project will experience stable requirements. 25.5 LIFE-CYCLE DESCRIPTION The COCOMO life cycle includes five basic phases: 1. Plan and requirements. 2. Product design. 3. Detailed design. 4. Code and unit test. 5. Integration and test. COCOMO provides recommendation for distributing the effort and schedule across the basic phases of conventional waterfall model. These recommendation vary some what with mode and scale; The table below provides a typical profile for a large, embedded mode project. COCOMO estimates the effort and schedule to develop the solution. Formulating the problem is estimated as an additional percentage over and above the development effort and schedule.
NOTES
Table 25.2 Effort and schedule partition across conventional life-cycle phases
ACTIVITY Plans and requirements Product design. Detailed design. Code and unit test. Integration and test
EFFORT (%) (+8) 18 25 26 31
SCHEDULE (%) (+36) 36 18 18 28
25.6 Software work breakdown structure Most conventional work breakdown structures are organized around the product subsystem at the higher level and around the detailed at the lower levels. The standard activities estimated by COCOMO and included in software WBS are requirement analysis, product design, programming, test planning, verification, project office functions, configuration management and quality assurance, and manual.
151
DBA 1728
NOTES
COCOMO also recommends a top-level distribution of effort across the activities of the WBS. Again, these profiles are dependent on mode and scale. The table below shows the expenditure profile among the activities in the WBS for large, embedded mode project. An important caveat is that in COCOMO, the programming activity includes detailed design, coding, unit testing and integration. Table 25.3 Budget allocation of various activities
ACTIVITY Requirements analysis Product design Programming Test planning Verification and validation Project office Configuration management and quality assurance Manuals
25.7 A Typical COCOMO Project Profile
BUDGET(%) 4 12 44 6 14 7 7 6
The following discussion focuses on a specific example project in order to illuminate some of the project planning implication. Assume a large, 100000 source-line (100-KDSI) mission-critical system built under contract for a government agency. Figure B1 illustrates the COCOMO estimated profile for this project. COCOMO would estimate 900 staff-month for development plus 72 staff-month for requirement specification for this project. The schedule required would be 22 month from initiation of design through test, plus 8 month for requirements.
25.8 EXAMPLE 100,000-SLOC project that require 972 staff-month of effort and 30 month of schedule Effort = 2.8 EAF (KDSI)1.2 = 2.8 (1.28) (100)1.2 = 900 Staff-month of development effort + 72 staff-month for plans, requirements = 972 staff-months of total effort
152
Table 25.4 Cost Drivers of example problem
NOTES
Effect 1.0 1.0 1.0 1.0 1.0 1.0 0.88 1.0 1.0 1.10 1.0 1.15 1.15 1.0
Cost Driver Language experience Schedule constraint Database size Turnaround time Virtual machine experience Virtual machine volatility Use of software tools Modern programming practices Storage constraint Applications experience Timing constraint Required reliability Product complexity Personnel/team capability
Time = 2.5 (Effort)0.32 = 2.5 (900)0.32 =22 months of development schedule + 8 months for plans, requirements =30 months Staffing Profile and Activity Mix
Setting Nominal Nominal Nominal Nominal Nominal Nominal High Nominal Nominal Low Nominal High High Nominal
Plans and requirement Product design Detailed design Code and Unit test Integration and test
153
DBA 1728
NOTES
Requirement analysis Product design Programming Test planning Verification and validation Project office Configuration management and quality assurance Manual 36 108 398 54 126 63 54
Staff-month
4% 12% 44% 6% 14% 7% 7% 6%
54
The COCOMO life-cycle schedule distribution and activity vary depending on the scale, domain, and business context. The schedule phases and activity mix illustrated here are typical. Summary This chapter has covered the detailed estimation of software products using COCOMO model. The details is shown in the form of a case study for further understanding. Review Questions 1. What is COCOMO? 2. What are the formulas used in COCOMO? 3. How will you calculate the Basic Effort and Schedule Estimating for COCOMO? 4. List down the Assumptions of COCOMO? 5. Explain the Life-Cycle Descriptions used in COCOMO? 6. What do you understand by Software work breakdown structure? 7. Explain the case study which is given in the chapter?
154
CHAPTER-26
TOTAL QUALITY MANAGEMENT (TQM) FOR SOFTWARE QUALITY
INTRODUCTION TO THE UNIT This chapter covers the TQM concepts for software quality in software industry. The TQM coverage includes definition, characteristics, models, benefits and PDCA cycle. UNIT LEARNING OBJECTIVES After reading this chapter the learner will have a very good understanding in TQM concepts, definition, benefits, software industry and PDCA cycle. 26.1 TQM ORIGIN AND BACKGROUND In mid 1940s, Dr. W. Edward Deming picked up some of the ideas from Walter Shewhart (who discovered that quality can be measured, and that there are measures of variability) and developed what is known as TQM. In 1940s, Dr. Deming was working as an advisor in sampling at the Bureau of Census and later became a statistics professor at the New York University Business School. At that time, he had little success convincing American businesses to adopt TQM, but his management methods did gain a huge success in Japan. While the Japanese were concentrating on producing quality products, businesses in the United States were more concerned with producing large quantities of products. Their emphasis on quantity at the expense of quality let the Japanese, with their inexpensive, high quality products, gain a substantial foothold in American markets. In the 1970s and 1980s, many American companies, including Ford, IBM, and Xerox, began adopting Dr Demings principles of TQM. This gradually led to their regaining some of the markets previously lost to the Japanese. 26.2 TQM DEFINITION A comprehensive approach to improving competitiveness and flexibility through planning, organizing and understanding each activity, and involving everyone at each level. TQM ensures that the management adopt a strategic overview of quality and focus on prevention rather than inspection (Oakland, 1993). A positive attempt by the organization concerned to improve structural, infrastructural, attitudinal, behavioral and methodological ways of delivering to the end customer, with emphasis on: consistency, improving in quality, competitive enhancements, all with the aim of satisfying or delighting the end customer (Zairi et al., 1994).
155
NOTES
DBA 1728
NOTES
TQM means that the organizations culture is defined by the constant attainment of satisfaction through an integrated system of tools, techniques, and training. Total Quality Management is a management style based upon producing quality service as defined by the customer. TQM is defined as a quality-centered, customer-focused, fact-based, teamdriven, senior-management-led process to achieve an organizations strategic imperative through continuous process improvement. T = Total = everyone in the organization Q = Quality = customer satisfaction M = Management = people and processes
26.3 CHARACTERISTICS OF TQM The following are the characteristics of TQM: TQM is the management philosophy to guide a process of change. TQM ensures that the quality be recognized as a corporate strategic priority, along with financial and other priorities. TQM starts at the top. TQM calls for planning. TQM requires organization- wide involvement. TQM calls for everyone to be skilled and knowledgeable. TQM promotes teamwork. TQM is about achieving results by process based approach. TQM focuses on the customer. TQM recognizes internal customer-supplier relationship. TQM considers suppliers as part of the organizations process. TQM seeks disciplined approach in continuous improvement efforts. TQM aims to instill a prevention and not an inspection ethic. TQM emphasizes the importance of measurement. TQM reduces total cost of meeting customer requirements.
156
26.4 A TQM MODEL
NOTES
Teams COMMUNICATION Process Customer supplier
COMMITMENT
Systems CULTURE
Tools
Figure 26.1 A Model of TQM (OAKLAND, 1993) In the UK, the models proposed by Oakland and by Kanji & Asher (1993) are two of the better known ones. The core theme of the former model is the identification and management of the processes within the organization. The processes are as chains of internal and external customer-supplier relationships that must be managed effectively and efficiently. Surrounding the processes are the soft outcomes of TQM- culture, communication and commitment (i.e. the so-called foundation elements)- and the hard management necessities of TQM- the use of teams (ranging from high powered quality councils to work area quality circles), quality tools (for systematic data collection and analysis) and systems (based on recognized international standards). The Bradford model is shown in figure 26.1 26.4.1 Principles and Concepts of Pyramid Model: Kanji & Asher (1993) used a 4-sided pyramid model to show the structure of TQM. It encompasses a set of four general governing principles, represented by the four sides. Each of the principles is translated into practice by using two core concepts. Leadership is at the base of the pyramid, aptly emphasizing the critical role of leadership to make TQM happen. Table 26.1: principles and concepts of pyramid model:
Principles Delight the customer Management-by-fact People-based management Continuous improvement Concepts Internal customers are real All work is a process Measurement Teamwork People make quality Continuous improvement cycle Prevention Customer satisfaction
DBA 1728
NOTES
Other quality authorities used different ways to explain their models, some of them novel. Kano (1993) used The House of TQM to show the structure of TQM. Using various parts of the house, namely, floor, base and pillars, he describes the factors and characteristics needed to achieve customer satisfaction and create a prevention not inspection management system, represented by the roof. Among the essentials for TQM, he talks about maximizing employee involvement, training, management-by-fact, the need for building in quality, continuous improvement, tools and techniques, management by policy, and teams. Cullen (1991) used a picture of a shield to put forward the hypothesis that there is a set of five conditions which are necessary and sufficient to establish TQM, namely, Leadership from the top, The cost of quality, Focus on customer satisfaction, Continuous improvement and involvement of everyone. 26.5 TQM BENEFITS TQM has few short-term advantages. Most of its benefits are long-term and come into effect only after it is running smoothly for some time. In large organizations, it may take several years before long-term benefits are realized. Long-term benefits that may be expected from TQM are higher productivity, increased morale, reduced costs, and greater customer commitment. These benefits may lead to greater public support and improvement of an organizations public image. 26.6 TQM & SOFTWARE INDUSTRY TQM was originated in the manufacturing sector but it has been successfully adopted by almost every type of organization imaginable - for example - hotel management, highway maintenance, churches, schools & universities. If you look closely at Software development, it is no different from any other industry. We develop software using processes. We know our processes are not perfect. What can we do to improve quality and bring more discipline into our processes? TQM has the answer. Remember, we cant test quality into our software, we design in it. And the only way we can design quality in is by continuously monitoring and improving our processes. Since TQM requires extensive statistical analysis to study processes and improve quality, we need be able to define a variable (or set of variables) to monitor a certain process. We should be able to then make a corrective action whenever we find that the process is going out-of-control. But, how do we know if the process is going out-ofcontrol? Note: A process in-control means its repeatable.
158
26.6.1 PROCESS IS GOING OUT-OF-CONTROL Use Control-Charts. They are also known as XBAR and R-Charts. Its hard to explain without a diagram, but Ill try to explain. You measure a process variable and define the target mean i.e. its acceptable average value. Note: To be able to begin monitoring a process, it must be in-control. Then define the Upper Control Limit (UCL) and Lower Control Limit (LCL). Use XBAR Charts to track if the process is going out-of-control. This URL provides more insight into how to define UCL and LCL. Note: if the LCL drops below some practical value, then choose zero. 26.7 PDCA Cycle Plan-Do-Check-Act is also known as Shewhart Cycle. Instead of following a Dilbert Cycle, where one only react to changes, PDCA shows a more sophisticated way to welcome change. Look at the problem in detail and check whats wrong (Plan). Then try improvement in small steps (Do). Gather data and analyze results (Check). In the end, make a decision (Act) and repeat the cycle for next problem. Its common sense, isnt it? But we still find managers suffering from Dilbert Syndrome almost everyday! Summary We cant test quality into our software, we design in it A chain is as strong as its weakest link. We must find and fix the bottlenecks first. Processes needs to be continually improved The People who do the work generally knows best how to improve it Use quantitative methods to support decisions, whenever possible Plan a flight, and fly the plan
NOTES
Review Questions 1. Explain the TQM Origin and Background? 2. What are the definitions of TQM? 3. Explain the characteristics of TQM? 4. Describe the various models of TQM? 5. Briefly explain the principles and concepts of pyramid model? 6. Highlight the TQM Benefits? 7. How is TQM & Software Industry related? 8. What is PDCA Cycle?
159
DBA 1728
NOTES
NOTES
160
NOTES
NOTES
161
DBA 1728
NOTES
NOTES
162

Software Project and Quality Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Project and Quality Management

Uploaded by

Copyright:

Available Formats

SOFTWARE PROJECT AND QUALITY MANAGEMENT

ANNA UNIVERSITY CHENNAI