ASE-Chap-01 Introduction To Software Engineering PDF

Chapter- Introduction To Software Engineering -------------------------------------- ISE Part-I Chapter-1 1 Topics covered  Professional software development ▪ What is meant by software engineerin...

Chapter- Introduction To Software Engineering -------------------------------------- ISE Part-I Chapter-1 1 Topics covered  Professional software development ▪ What is meant by software engineering.  Software engineering ethics ▪ A brief introduction to ethical issues that affect software engineering.  Case studies ▪ An introduction to three examples that are used in later chapters in the book. Chapter-1 2 Software engineering  The economies of ALL developed nations are dependent on software.  More and more systems are software controlled  Software engineering is concerned with theories, methods and tools for professional software development.  Expenditure on software represents a significant fraction of GNP in all developed countries. Chapter-1 3 Software costs  Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost.  Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs.  Software engineering is concerned with cost-effective software development. Chapter-1 4 Software products  Generic products ▪ Stand-alone systems that are marketed and sold to any customer who wishes to buy them. ▪ Examples – PC software such as graphics programs, project management tools; CAD software; software for specific markets such as appointments systems for dentists.  Customized products ▪ Software that is commissioned by a specific customer to meet their own needs. ▪ Examples – embedded control systems, air traffic control software, traffic monitoring systems. Chapter-1 5 Product specification  Generic products ▪ The specification of what the software should do is owned by the software developer and decisions on software change are made by the developer.  Customized products ▪ The specification of what the software should do is owned by the customer for the software and they make decisions on software changes that are required. Chapter-1 6 Frequently asked questions about software engineering Question Answer What is software? Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market. What are the attributes of good software? Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production. What are the fundamental software Software specification, software development, software engineering activities? validation and software evolution. What is the difference between software Computer science focuses on theory and fundamentals; engineering and computer science? software engineering is concerned with the practicalities of developing and delivering useful software. What is the difference between software System engineering is concerned with all aspects of engineering and system engineering? computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process. Chapter-1 7 Frequently asked questions about software engineering Question Answer What are the key challenges facing Coping with increasing diversity, demands for reduced software engineering? delivery times and developing trustworthy software. What are the costs of software Roughly 60% of software costs are development costs, engineering? 40% are testing costs. For custom software, evolution costs often exceed development costs. What are the best software engineering While all software projects have to be professionally techniques and methods? managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another. What differences has the web made to The web has led to the availability of software services software engineering? and the possibility of developing highly distributed service- based systems. Web-based systems development has led to important advances in programming languages and software reuse. Chapter-1 8 Essential attributes of good software Product characteristic Description Maintainability Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment. Dependability and Software dependability includes a range of characteristics security including reliability, security and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system. Efficiency Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilisation, etc. Acceptability Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable and compatible with other systems that they use. Chapter-1 9 Software engineering  Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use.  Engineering discipline ▪ Using appropriate theories and methods to solve problems bearing in mind organizational and financial constraints.  All aspects of software production ▪ Not just technical process of development. Also project management and the development of tools, methods etc. to support software production. Chapter-1 10 Importance of software engineering  More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly.  It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of system, the majority of costs are the costs of changing the software after it has gone into use. Chapter-1 11 Software process activities  Software specification, where customers and engineers define the software that is to be produced and the constraints on its operation.  Software development, where the software is designed and programmed.  Software validation, where the software is checked to ensure that it is what the customer requires.  Software evolution, where the software is modified to reflect changing customer and market requirements. Chapter-1 12 General issues that affect most software  Heterogeneity ▪ Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices.  Business and social change ▪ Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new software.  Security and trust ▪ As software is intertwined with all aspects of our lives, it is essential that we can trust that software. Chapter-1 13 Software engineering diversity  There are many different types of software system and there is no universal set of software techniques that is applicable to all of these.  The software engineering methods and tools used depend on the type of application being developed, the requirements of the customer and the background of the development team. Chapter-1 14 Application types  Stand-alone applications ▪ These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network.  Interactive transaction-based applications ▪ Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications such as e-commerce applications.  Embedded control systems ▪ These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system. Chapter-1 15 Application types  Batch processing systems ▪ These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs.  Entertainment systems ▪ These are systems that are primarily for personal use and which are intended to entertain the user.  Systems for modeling and simulation ▪ These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. Chapter-1 16 Application types  Data collection systems ▪ These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing.  Systems of systems ▪ These are systems that are composed of a number of other software systems. Chapter-1 17 Software engineering fundamentals  Some fundamental principles apply to all types of software system, irrespective of the development techniques used: ▪ Systems should be developed using a managed and understood development process. Of course, different processes are used for different types of software. ▪ Dependability and performance are important for all types of system. ▪ Understanding and managing the software specification and requirements (what the software should do) are important. ▪ Where appropriate, you should reuse software that has already been developed rather than write new software. Chapter-1 18 Software engineering and the web  The Web is now a platform for running application and organizations are increasingly developing web-based systems rather than local systems.  Web services (discussed in Chapter 19) allow application functionality to be accessed over the web.  Cloud computing is an approach to the provision of computer services where applications run remotely on the ‘cloud’. ▪ Users do not buy software buy pay according to use. Chapter-1 19  Web software engineering  Software reuse is the dominant approach for constructing web-based systems. ▪ When building these systems, you think about how you can assemble them from pre-existing software components and systems.  Web-based systems should be developed and delivered incrementally. ▪ It is now generally recognized that it is impractical to specify all the requirements for such systems in advance.  User interfaces are constrained by the capabilities of web browsers. ▪ Technologies such as AJAX allow rich interfaces to be created within a web browser but are still difficult to use. Web forms with local scripting are more commonly used. Chapter-1 20 Web-based software engineering  Web-based systems are complex distributed systems but the fundamental principles of software engineering discussed previously are as applicable to them as they are to any other types of system.  The fundamental ideas of software engineering, discussed in the previous section, apply to web-based software in the same way that they apply to other types of software system. Chapter-1 21 Software engineering ethics  Software engineering involves wider responsibilities than simply the application of technical skills.  Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals.  Ethical behaviour is more than simply upholding the law but involves following a set of principles that are morally correct. Chapter-1 22 Issues of professional responsibility  Confidentiality ▪ Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.  Competence ▪ Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence. Chapter-1 23 Issues of professional responsibility  Intellectual property rights ▪ Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.  Computer misuse ▪ Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses). Chapter-1 24 ACM/IEEE Code of Ethics  The professional societies in the US have cooperated to produce a code of ethical practice.  Members of these organisations sign up to the code of practice when they join.  The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession. Chapter-1 25 Rationale for the code of ethics ▪ Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment and society at large. Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance and testing of software systems. ▪ Because of their roles in developing software systems, software engineers have significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. Chapter-1 26 The ACM/IEEE Code of Ethics Software Engineering Code of Ethics and Professional Practice ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional Practices PREAMBLE The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code. Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles: Chapter-1 27 Ethical principles 1. PUBLIC - Software engineers shall act consistently with the public interest. 2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. 3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. Chapter-1 28 Ethical dilemmas  Disagreement in principle with the policies of senior management.  Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system.  Participation in the development of military weapons systems or nuclear systems. Chapter-1 29 Key points  Software engineering is an engineering discipline that is concerned with all aspects of software production.  Essential software product attributes are maintainability, dependability and security, efficiency and acceptability.  The high-level activities of specification, development, validation and evolution are part of all software processes.  The fundamental notions of software engineering are universally applicable to all types of system development. Chapter-1 30 Key points  There are many different types of system and each requires appropriate software engineering tools and techniques for their development.  The fundamental ideas of software engineering are applicable to all types of software system. Chapter-1 31 Key points  Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues.  Professional societies publish codes of conduct which set out the standards of behaviour expected of their members. Chapter-1 32  Chapter- Software Process Improvement Engineering -------------------------------------- SPIE Part-II Chapter-1 33 Topics covered  The process improvement process  Process measurement  Process analysis  Process change  The CMMI process improvement framework Chapter-1 34 Process improvement  Many software companies have turned to software process improvement as a way of enhancing the quality of their software, reducing costs or accelerating their development processes.  Process improvement means understanding existing processes and changing these processes to increase product quality and/or reduce costs and development time. Chapter-1 35 Approaches to improvement  The process maturity approach, which focuses on improving process and project management and introducing good software engineering practice. ▪ The level of process maturity reflects the extent to which good technical and management practice has been adopted in organizational software development processes.  The agile approach, which focuses on iterative development and the reduction of overheads in the software process. ▪ The primary characteristics of agile methods are rapid delivery of functionality and responsiveness to changing customer requirements. Chapter-1 36 Process and product quality  Process quality and product quality are closely related and process improvement benefits arise because the quality of the product depends on its development process.  A good process is usually required to produce a good product.  For manufactured goods, process is the principal quality determinant.  For design-based activities, other factors are also involved, especially the capabilities of the designers. Chapter-1 37 Factors affecting software product quality Chapter-1 38 Quality factors  For large projects with ‘average’ capabilities, the development process determines product quality.  For small projects, the capabilities of the developers is the main determinant.  The development technology is particularly significant for small projects.  In all cases, if an unrealistic schedule is imposed then product quality will suffer. Chapter-1 39 Process improvement process  There is no such thing as an ‘ideal’ or ‘standard’ software process that is applicable in all organizations or for all software products of a particular type. ▪ You will rarely be successful in introducing process improvements if you simply attempt to change the process to one that is used elsewhere. ▪ You must always consider the local environment and culture and how this may be affected by process change proposals.  Each company has to develop its own process depending on its size, the background and skills of its staff, the type of software being developed, customer and market requirements, and the company culture. Chapter-1 40 Improvement attributes  You also have to consider what aspects of the process that you want to improve.  Your goal might be to improve software quality and so you may wish to introduce new process activities that change the way software is developed and tested.  You may be interested in improving some attribute of the process itself (such as development time) and you have to decide which process attributes are the most important to your company. Chapter-1 41 Process attributes Process Key issues characteristic Understandability To what extent is the process explicitly defined and how easy is it to understand the process definition? Standardization To what extent is the process based on a standard generic process? This may be important for some customers who require conformance with a set of defined process standards. To what extent is the same process used in all parts of a company? Visibility Do the process activities culminate in clear results, so that the progress of the process is externally visible? Measurability Does the process include data collection or other activities that allow process or product characteristics to be measured? Supportability To what extent can software tools be used to support the process activities? Chapter-1 42 Process attributes Process Key issues characteristic Acceptability Is the defined process acceptable to and usable by the engineers responsible for producing the software product? Reliability Is the process designed in such a way that process errors are avoided or trapped before they result in product errors? Robustness Can the process continue in spite of unexpected problems? Maintainability Can the process evolve to reflect changing organizational requirements or identified process improvements? Rapidity How fast can the process of delivering a system from a given specification be completed? Chapter-1 43 Process improvement stages  Process measurement ▪ Attributes of the current process are measured. These are a baseline for assessing improvements.  Process analysis ▪ The current process is assessed and bottlenecks and weaknesses are identified.  Process change ▪ Changes to the process that have been identified during the analysis are introduced. Chapter-1 44 The process improvement cycle Chapter-1 45 Process measurement  Wherever possible, quantitative process data should be collected ▪ However, where organisations do not have clearly defined process standards this is very difficult as you don’t know what to measure. A process may have to be defined before any measurement is possible.  Process measurements should be used to assess process improvements ▪ But this does not mean that measurements should drive the improvements. The improvement driver should be the organizational objectives. Chapter-1 46 Process metrics  Time taken for process activities to be completed ▪ E.g. Calendar time or effort to complete an activity or process.  Resources required for processes or activities ▪ E.g. Total effort in person-days.  Number of occurrences of a particular event ▪ E.g. Number of defects discovered. Chapter-1 47 Goal-Question-Metric Paradigm  Goals ▪ What is the organisation trying to achieve? The objective of process improvement is to satisfy these goals.  Questions ▪ Questions about areas of uncertainty related to the goals. You need process knowledge to derive these.  Metrics ▪ Measurements to be collected to answer the questions. Chapter-1 48 GQM questions  The GQM paradigm is used in process improvement to help answer three critical questions: ▪ Why are we introducing process improvement? ▪ What information do we need to help identify and assess improvements? ▪ What process and product measurements are required to provide this information? Chapter-1 49 The GQM paradigm Chapter-1 50 Process analysis  The study of existing processes to understand the relationships between parts of the process and to compare them with other processes.  Process analysis and process measurement are intertwined.  You need to carry out some analysis to know what to measure, and, when making measurements, you inevitably develop a deeper understanding of the process being measured. Chapter-1 51 Process analysis objectives  To understand the activities involved in the process and the relationships between these activities.  To understand the relationships between the process activities and the measurements that have been made.  To relate the specific process or processes that you are analyzing to comparable processes elsewhere in the organization, or to idealized processes of the same type. Chapter-1 52 Process analysis techniques  Published process models and process standards ▪ It is always best to start process analysis with an existing model. People then may extend and change this.  Questionnaires and interviews ▪ Must be carefully designed. Participants may tell you what they think you want to hear.  Ethnographic analysis ▪ Involves assimilating process knowledge by observation. Best for in-depth analysis of process fragments rather than for whole- process understanding. Chapter-1 53 Aspects of process analysis Process Questions aspect Adoption and Is the process documented and standardized across the standardization organization? If not, does this mean that any measurements made are specific only to a single process instance? If processes are not standardized, then changes to one process may not be transferable to comparable processes elsewhere in the company. Software Are there known, good software engineering practices that are engineering not included in the process? Why are they not included? Does the practice lack of these practices affect product characteristics, such as the number of defects in a delivered software system? Organizational What are the organizational constraints that affect the process constraints design and the ways that the process is performed? For example, if the process involves dealing with classified material, there may be activities in the process to check that classified information is not included in any material due to be released to external organizations. Organizational constraints may mean that possible process changes cannot be made. Chapter-1 54 Aspects of process analysis Process aspect Questions Communications How are communications managed in the process? How do communication issues relate to the process measurements that have been made? Communication problems are a major issue in many processes and communication bottlenecks are often the reasons for project delays. Introspection Is the process reflective (i.e., do the actors involved in the process explicitly think about and discuss the process and how it might be improved)? Are there mechanisms through which process actors can propose process improvements? Learning How do people joining a development team learn about the software processes used? Does the company have process manuals and process training programs? Tool support What aspects of the process are and aren’t supported by software tools? For unsupported areas, are there tools that could be deployed cost-effectively to provide support? For supported areas, are the tools effective and efficient? Are better tools available? Chapter-1 55 Process models  Process models are a good way of focusing attention on the activities in a process and the information transfer between these activities.  Process models do not have to be formal or complete – their purpose is to provoke discussion rather than document the process in detail.  Model-oriented questions can be used to help understand the process e.g. ▪ What activities take place in practice but are not shown in the model? ▪ Are there process activities, shown in the model, that you (the process actor) think are inefficient? Chapter-1 56 Process exceptions  Software processes are complex and process models cannot effectively represent how to handle exceptions: ▪ Several key people becoming ill just before a critical review; ▪ A breach of security that means all external communications are out of action for several days; ▪ Organisational reorganisation; ▪ A need to respond to an unanticipated request for new proposals.  Under these circumstances, the model is suspended and managers use their initiative to deal with the exception. Chapter-1 57 Key points  The goals of process improvement are higher product quality, reduced process costs and faster delivery of software.  The principal approaches to process improvement are agile approaches, geared to reducing process overheads, and maturity- based approaches based on better process management and the use of good software engineering practice.  The process improvement cycle involves process measurement, process analysis and modeling, and process change.  Measurement should be used to answer specific questions about the software process used. These questions should be based on organizational improvement goals. Chapter-1 58 Process Improvement Chapter-1 59 Process change  Involves making modifications to existing processes.  This may involve: ▪ Introducing new practices, methods or processes; ▪ Changing the ordering of process activities; ▪ Introducing or removing deliverables; ▪ Introducing new roles or responsibilities.  Change should be driven by measurable goals. Chapter-1 60 The process change process Chapter-1 61 Process change stages  Improvement identification ▪ This stage is concerned with using the results of the process analysis to identify ways to tackle quality problems, schedule bottlenecks or cost inefficiencies that have been identified during process analysis.  Improvement prioritization ▪ When many possible changes have been identified, it is usually impossible to introduce them all at once, and you must decide which are the most important.  Process change introduction ▪ Process change introduction means putting new procedures, methods and tools into place and integrating them with other process activities. Chapter-1 62 Process change stages  Process change training ▪ Without training, it is not possible to gain the full benefits of process changes. The engineers involved need to understand the changes that have been proposed and how to perform the new and changed processes.  Change tuning ▪ Proposed process changes will never be completely effective as soon as they are introduced. You need a tuning phase where minor problems can be discovered, and modifications to the process can be proposed and introduced. Chapter-1 63 Process change problems  Resistance to change ▪ Team members or project managers may resist the introduction of process changes and propose reasons why changes will not work, or delay the introduction of changes. They may, in some cases, deliberately obstruct process changes and interpret data to show the ineffectiveness of proposed process change.  Change persistence ▪ While it may be possible to introduce process changes initially, it is common for process innovations to be discarded after a short time and for the processes to revert to their previous state. Chapter-1 64 Resistance to change  Project managers often resist process change because any innovation has unknown risks associated with it. ▪ Project managers are judged according to whether or not their project produces software on time and to budget. They may prefer an inefficient but predictable process to an improved process that has organizational benefits, but which has short- term risks associated with it.  Engineers may resist the introduction of new processes for similar reasons, or because they see these processes as threatening their professionalism. ▪ That is, they may feel that the new pre-defined process gives them less discretion and does not recognize the value of their skills and experience. Chapter-1 65 Change persistence  The problem of changes being introduced then subsequently discarded is a common one. ▪ Changes may be proposed by an ‘evangelist’ who believes strongly that the changes will lead to improvement. He or she may work hard to ensure the changes are effective and the new process is accepted. ▪ If the ‘evangelist’ leaves, then the people involved may therefore simply revert to the previous ways of doing things.  Change institutionalization is important ▪ This means that process change is not dependent on individuals but that the changes become part of standard practice in the company, with company-wide support and training. Chapter-1 66 The CMMI process improvement framework  The CMMI framework is the current stage of work on process assessment and improvement that started at the Software Engineering Institute in the 1980s.  The SEI’s mission is to promote software technology transfer particularly to US defence contractors.  It has had a profound influence on process improvement ▪ Capability Maturity Model introduced in the early 1990s. ▪ Revised maturity framework (CMMI) introduced in 2001. Chapter-1 67 The SEI capability maturity model  Initial ▪ Essentially uncontrolled  Repeatable ▪ Product management procedures defined and used  Defined ▪ Process management procedures and strategies defined and used  Managed ▪ Quality management strategies defined and used  Optimising ▪ Process improvement strategies defined and used Chapter-1 68 Process capability assessment  Intended as a means to assess the extent to which an organisation’s processes follow best practice.  By providing a means for assessment, it is possible to identify areas of weakness for process improvement.  There have been various process assessment and improvement models but the SEI work has been most influential. Chapter-1 69 The CMMI model  An integrated capability model that includes software and systems engineering capability assessment.  The model has two instantiations ▪ Staged where the model is expressed in terms of capability levels; ▪ Continuous where a capability rating is computed. Chapter-1 70 CMMI model components  Process areas ▪ 24 process areas that are relevant to process capability and improvement are identified. These are organised into 4 groups.  Goals ▪ Goals are descriptions of desirable organisational states. Each process area has associated goals.  Practices ▪ Practices are ways of achieving a goal - however, they are advisory and other approaches to achieve the goal may be used. Chapter-1 71 Process areas in the CMMI Category Process area Process management Organizational process definition (OPD) Organizational process focus (OPF) Organizational training (OT) Organizational process performance (OPP) Organizational innovation and deployment (OID) Project management Project planning (PP) Project monitoring and control (PMC) Supplier agreement management (SAM) Integrated project management (IPM) Risk management (RSKM) Quantitative project management (QPM) Chapter-1 72 Process areas in the CMMI Category Process area Engineering Requirements management (REQM) Requirements development (RD) Technical solution (TS) Product integration (PI) Verification (VER) Validation (VAL) Support Configuration management (CM) Process and product quality management (PPQA) Measurement and analysis (MA) Decision analysis and resolution (DAR) Causal analysis and resolution (CAR) Chapter-1 73 Goals and associated practices in the CMMI Goal Associated practices The requirements are analyzed and Analyze derived requirements systematically to ensure that validated, and a definition of the they are necessary and sufficient. required functionality is developed. Validate requirements to ensure that the resulting product will perform as intended in the user’s environment, using multiple techniques as appropriate. Root causes of defects and other Select the critical defects and other problems for analysis. problems are systematically determined. Perform causal analysis of selected defects and other problems and propose actions to address them. The process is institutionalized as a Establish and maintain an organizational policy for planning defined process. and performing the requirements development process. Chapter-1 74 Examples of goals in the CMMI Goal Process area Corrective actions are managed to closure Project monitoring and control (specific when the project’s performance or results goal) deviate significantly from the plan. Actual performance and progress of the Project monitoring and control (specific project are monitored against the project goal) plan. The requirements are analyzed and Requirements development (specific goal) validated, and a definition of the required functionality is developed. Root causes of defects and other problems Causal analysis and resolution (specific are systematically determined. goal) The process is institutionalized as a defined Generic goal process. Chapter-1 75 CMMI assessment  Examines the processes used in an organisation and assesses their maturity in each process area.  Based on a 6-point scale: ▪ Not performed; ▪ Performed; ▪ Managed; ▪ Defined; ▪ Quantitatively managed; ▪ Optimizing. Chapter-1 76 The staged CMMI model  Comparable with the software CMM.  Each maturity level has process areas and goals. For example, the process area associated with the managed level include: ▪ Requirements management; ▪ Project planning; ▪ Project monitoring and control; ▪ Supplier agreement management; ▪ Measurement and analysis; ▪ Process and product quality assurance. Chapter-1 77 The CMMI staged maturity model Chapter-1 78 Institutional practices  Institutions operating at the managed level should have institutionalised practices that are geared to standardisation. ▪ Establish and maintain policy for performing the project management process; ▪ Provide adequate resources for performing the project management process; ▪ Monitor and control the project planning process; ▪ Review the activities, status and results of the project planning process. Chapter-1 79 The continuous CMMI model  This is a finer-grain model that considers individual or groups of practices and assesses their use.  The maturity assessment is not a single value but is a set of values showing the organisations maturity in each area.  The CMMI rates each process area from levels 1 to 5.  The advantage of a continuous approach is that organisations can pick and choose process areas to improve according to their local needs. Chapter-1 80 A process capability profile Chapter-1 81 Key points  The CMMI process maturity model is an integrated process improvement model that supports both staged and continuous process improvement.  Process improvement in the CMMI model is based on reaching a set of goals related to good software engineering practice and describing, standardizing and controlling the practices used to achieve these goals.  The CMMI model includes recommended practices that may be used, but these are not obligatory. Chapter-1 82