Maturity Model in Software Engineering - Assignment Example

SOFTWARE ENGINEERING EXAM b) Evaluate the points for and against the SEIs of each level of the capability Maturity Model (CMM) as a well-defined plateau on the path towards becoming a mature software organisation. CMM - its Levels The CMM consists of five different levels of increasing process maturity. This five-stage structure of the CMM is based on the various principles developed through SEI. These five stages helps measure the overall maturity level of an IT organizations software processes under SEI. They include: Level 1 - Initial Level 2 - Repeatable Level 3 - Defined Level 4 - Managed Level 5 - Optimizing Level 1 - Initial level Organizations at this entry level carry out their work on an ad hoc basis. A handful of formal processes are defined properly while project management discipline is, at best, unclear. As such success and failures have little impact on future undertakings. Results therefore become unpredictable, processes are poorly controlled and the ultimate success depends on the dedicated effort of a few enterprising individuals instead of the entire organization as a whole. Level 2 - Repeatable level At this second level, organizations depend mainly on policies for managing a software project and measures to apply those policies are established. These measures help the organizations to repeat successfully the previously mastered tasks and avoid the repetition of failures. The major chunk of an organizations processes at this level stays institutionalized, through staff experience instead of detailed documentation procedures. Level 3 - Defined level The various engineering activities and the processes of management at this level is formally defined, documented and integrated. In the process of development and maintenance of software, the organizations staff follows this defined standard process. At this third level, newer methods and tools can be added, and it becomes easier to train new staff to adapt according to the requirement of the organization. Level 4 - Managed level At this level, organizations stress the importance of quantitatively measuring the quality of the products delivered by each process. Detailed measures of the software process and product quality are collected and used to identify and correct issues with process performances. Organizations set quantitative goals for both software products as well as processes. As part of the organizations measurement program, productivity and quality of all software process activities and its supporting activities are measured. As new sets of tools or processes are added, or adjustments are made to already existing processes, measurement data enables the organization to access the success of the adjustment as well as prevent the recurrence of defects. Level 5 - Optimizing level At level 5, focus is on the continuous process improvement. The organization proactively identifies strengths and weakness in process, with the aim of preventing the occurrence of defects. Here continuous improvement becomes institutionalized into the development process. Instead of merely correcting defects as they are found, the main aim at this highest level is to stall future defects and address the key to those defects by planning in advance. Pros 1. Increased Productivity/Decreased Cost Contractors have reported an increase in productivity due to the improvement of their software development process. Various organizations have realized benefits from maturing from one level to the next. Productivities have increased from as little as 2.5 percent to as much as 130 percent0. Studies of software engineering improvements measured by the CMM indicate significant cost savings or profit return. This implies that software testing and maintenance costs were reduced, since the software better met verification and validation requirements...” Contractors have also experienced a decrease in rework, code problems, and retesting costs. 2. Increased Competitiveness It is generally accepted that higher CMM levels lead to better quality software products and therefore a better company reputation. CMM compliance may also change the manner in which a company interacts with its customers, because there are stringent requirements for maintaining a high maturity level. Highly rated organizations are more adept at handling quick demands by the customer. Fortunately, compliance leads to higher quality software at lower cost. Also compliance improves a company’s reputation, which should be a very potent ingredient for winning and maintaining contracts. 3. Increased “On-Time” Deliveries One organization cited that they went from delivering products on time 51 percent of the time to 94 percent of the time. Some organizations have experienced a savings as high as 20 percent in their schedule. “Generally, the more mature an organization is in the way it does business, the more successful it will be in delivering a quality product within project constraints.” 4. Increased Quality “[Participating] companies are looking at meeting their quality goals, meeting their requirements, building a maintainable product, and seeking better and improved quality as well as stabilizing schedule, meeting commitments, and accelerating or reducing schedule.” Several software organizations have experienced a reduction in defects that ranged from as low as 10 percent to as high as 80 percent. One organization reported a 45 percent decrease in its reduction error rate, while two more organizations’ product error rates decreased from 2.0 to 0.11 per thousand source lines of code and from 0.72 to 0.13 per thousand non-commented source statements. Cons 1. Increased Spending for Process Implementation In order for a software organization to mature, there has to be capital to support the effort. “Many organizations have expended large amounts of money and effort in support of their initiatives, yet they have little idea of what, if any, return they are accruing from their investments.” Costs for CMM-based process improvement programs have shown increases in software and hardware, data collection, design defects repair, code defects repair, first-time testing and overhead costs. “One nearly universal complaint is that moving from level to level can cost hundreds of thousands or even millions of dollars.” 2. Increased Training Time, Decreased Manufacturing Time Improving the software development process also includes increased training time and less time for working on projects. An organization has to continue business as usual or make the sacrifice to improve the process which will result in higher quality products. “Some organizations had difficulty finding the time to work on software-process improvement because they had extreme commitments to deliver customer products.”Additionally, in order to mature from one level to the next, extensive training is required so that the organization understands the processes. Path towards becoming a mature software organ Maturity Level Key Process Areas Optimizing level a. Defect Prevention b. Technology Change Management c. Process Change Management Managed level a. Software Quality Management b. Quality Process Management Defined level a. Organizational Process Focus b. Organizational Process Definition c. Training Program d. Software Product Engineering e. Integrated Software Management f. Inter-Group Coordination g. Peer Review Managed level a. Software Requirement Management b. Software Project Planning c. Software Project Tracking & Oversight d. Software Subcontract Management e. Software Quality Assurance f. Software Configuration Management Initial level No KPAs 1 (c) If you were working within a medium-sized software house what factors would influence your decision-making in choosing to adopt or reject the CMM process, and why ?(10 marks)   Factors influencing decision-making in choosing to adopt the CMM process In a medium-sized software house we need to view following aspects regarding the decision-making in choosing to adopt CMM process: Hundreds of employees spread over several locations or countries working jointly on a same system Multiple-year projects involving dozens of employees and budgets of millions of dollars Involves the customer from the international community The latest-generation hardware and software involved in system development Projects to develop real-time, embedded, mission-critical, defense, or aerospace systems Compliance with international standards as a usual requirement from customers Little visibility among system modules Limited access to technical consultation Require better Communications Factors influencing decision-making in choosing to reject the CMM process In a medium-sized software house we need to view following aspects regarding the decision-making in rejecting the adoption of CMM process. Mostly the in small and medium sized Enterprises (SMEs) are primarily having no such great concentration on the implementation of the CMM process. Here we have following issues regarding the rejection of the CMM process: Higher costs Issue team management Internal bureaucracy Documentation conflicts Lack of communication Lack of organizational creativity and flexibility Less time regarding development 2(a) Briefly explain the role that risk analysis plays in enabling evolutionary process models such as the spiral model to support effective software development. (5 marks) Software development requires members of the software development team to make a number of decisions including choices of technology, software development methods, usage of prototyping and inclusion of requirements. In order to make the best decisions individuals need to know how to make the best decisions and they must be motivated to make those decisions in the best interest of the organization. The goal of the evolutionary process models (spiral model) is to outline risk drives, so that the risks in a given cycle are determined during the Analyzing Risks section. In order to manage these risks, certain additional project-specific activities may be planned to address the risks, such as Requirements Prototyping, if the risk analysis indicates that the software requirements are not clearly understood. These project specific risks are termed process drivers. For any process driver, one or more project specific activities need to be performed to manage the risk. In evolutionary process models we have stage of Performing Risk Analysis that involves activity regarding the analysis of Approved Estimate of Situation, Project Planning Documents, and Supporting Documents those are used to perform risk analysis activities. The output from this object is a Draft Risk Management Plan (RMP), which is sent to the Reviewing Risk Analysis activity. Here we perform activity regarding risk management and takes the Updated Draft Risk Management Plan as input and produces the Risk Management Plan. During this activity, all the major risks of cycle are resolved. The Risk Management Plan is sent to the next quadrant, Developing Product. In spiral model uses prototyping as a risk reduction mechanism but, more important, enables the developer to apply the prototyping approach at any stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework that more realistically reflects the real world. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become but like other paradigms, the spiral model is not a panacea. It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur. Finally, the model has not been used as widely as the linear sequential or prototyping paradigms. It will take a number of years before efficacy of this important paradigm can be determined with absolute certainty. 2(b) Define software risk, give brief descriptions of the three classes of software development risk. ( 8 marks ) “Risk are future uncertain events with a probability of occurrence and a potential for loss”. Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work. Schedule Risk: Project schedule get slip when project tasks and schedule release risks are not addressed properly. Schedule risks mainly affect on project and finally on company economy and may lead to project failure. Schedules often slip due to following reasons: Wrong time estimation  Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.  Failure to identify complex functionalities and time required to develop those functionalities.  Unexpected project scope expansions. Budget Risk:  Wrong budget estimation.  Cost overruns  Project scope expansion Project Change Technical risks: Technical risks generally leads to failure of functionality and performance. Causes of technical risks are:  Continuous changing requirements  No advanced technology available or the existing technology is in initial stages.  Product is complex to implement.  Difficult project modules integration. The stage of the SEIs Risk Management Paradigm are: (i) identify , (ii) analyse, (iii) plan , (iv) track ,and (v) control ,And at the centre of the paradigm is "communication". 2(c) Outline the key features of each stage (5 marks). The Software Engineering Institute (SEI) has identified 6 elements of a Risk Management Paradigm. The six elements are: Identify, Analyze, Plan, Track, Control, and Communicate. Each phase is briefly described as follows: -Identify: Search for and locate risks before they become problems. Risk identification is a process where uncertainties and issues about a project are trans-formed into tangible risks, which can be described and measured. Everyone on a project is responsible for identifying risks. The following table describes the components of risk identification. Techniques used to identify risks include structured or unstructured brainstorming, peer-group interviews, and voluntary reporting. -Analyze: Transform risk data into decision-making information. Evaluate impact, probability, and timeframe, classify risks, and prioritize risks. Risk analysis is a process in which risks are examined in detail. The purpose is to determine the extent of the risks, how they relate to each other, and which ones are the most important. Personnel who have the appropriate knowledge, expertise, and background to effectively deal with risk information are responsible for evaluating, classifying, and prioritizing the risks. -Plan: Translate risk information into decisions and mitigating actions (both present and future) and implement those actions. Planning is a process whereby decisions are made about what should be done with a risk. The results of planning are risk action plans for individual risks or sets of related risks. Personnel who have the knowledge, expertise, background, and resources to effectively deal with risks are responsible for developing their plans. In general, the goal of planning is to answer the following questions: • Is it my risk? (responsibility) • What can I do? (approach) • How much and what should I do? (scope and actions) -Track: Monitor risk indicators and mitigation plans. Tracking is a process in which risk data are acquired, compiled, and reported by the person(s) responsible for tracking watched and mitigated risks. The metrics gathered during tracking are defined during planning and are presented to decision makers in tracking documents or presentations. The information is then used to make control decisions about watched risks and mitigation plans. The following table describes the components of risk tracking. -Control: Correct for deviations from the risk mitigation plans. Control is a process in which a decision maker analyzes the data contained in tracking reports, makes a decision, and implements the decision. The person who has accountability for a risk normally makes the control decision for that risk. -Communicate: Provide information and feedback internal and external to the project on the risk activities, current risks, and emerging risks. Risk communication deals with two subjects that people don’t normally communicate well: probability and negative consequences. Managers need to establish a culture where risks are identified and addressed as a part of everyday business and where risk information is viewed positively and rewarded. Successful risk communication surfaces relevant issues and potential problems, allows information to be exchanged within and between all project levels, values the individual voice, and preserves non-attribution and trusted use of all risk information. Communication is an enabler of the other paradigm functions and ensures that • Risks and their mitigation plans are understood • Risk information is visible to all project members • Appropriate attention is applied to risk information • An effective, ongoing dialog between the manager and the project team is established 2(d) and discuss value of using this paradigm , in particular explaining why the SEI believe it is so important to put communication at the centre of risk management ( 7 marks)   The functions of the SEI risk management paradigm implementation through the project manager having experience and expertise of their personnel to effectively manage risks; the knowledge derived from participation in an activity as well as the unique skills of team members provide managers with additional information that they might not have had otherwise. All relevant risk data, including decisions made and actions taken, should be kept in a repository, because the data might be relevant to the present project or to other projects within the organization. A risk will typically progress through the paradigm functions sequentially, but the risk management functions are performed continually (i.e., risks are managed continuously throughout all phases of a project), concurrently (i.e., mitigation plans for risks are developed and tracked while new risks are being identified and analyzed), and iteratively (i.e., a mitigation plan for one risk may be used to identify another risk) throughout a project’s life cycle. Acquisition risk management requires sustaining constant vigilance and managing risks routinely throughout all phases of the project’s lifecycle. The risk management functions need further definition in order for a project to put these concepts into practice. The next section expands the definition of each function and provides components that can be used by a project to define a risk management process. Risk communication deals with uncertainty and negative consequences, which are two subjects that most people have difficulty discussing. Communication is essential for managing risks within an organization. Risk communication must allow a free flow of information within and between all project levels, value the individual voice, and pre-serve non-attribution and trusted use of data. If done successfully, it will surface relevant issues and potential problems on a project, and as a result, project personnel will feel that they are informed. Management is instrumental in establishing and sustaining an environment that encourages risk communication. The following list includes a few of the environmental and cultural traits that can help to enhance risk communication in an organization: • establishing upper management sponsorship of risk management • rewarding positive behavior • making risk actions and decisions visible to project members • setting an example by being a role model • selecting a risk management advocate within the organization to help sustain the motivation for risk management Read More