Problem:
Why is it that software organizations often struggle when they embark on an effort to improve local software process?
Answer:
4633-30-1P SA: 9420
SR: 6376
Software process improvement includes a set of activities that will lead to a better software process and as a consequence, higher-quality software delivered in a more-timely manner.
Some software organizations often struggle when they embark on an effort to improve local software process because they have little more than ad hoc software process. Their practices are hit-and-miss, and their process is ad hoc. Occasionally, their work is spectacular, but in the main, each project is an adventure, and no one knows whether it will end badly or well.
Problem:
Describe the concept of “process maturity” in your own words.
Answer:
Process Maturity:
Process maturity is an indication of the quality of the software process, the degree to which practitioner’s understand and apply the process, and the general state of software engineering practice.
The process maturity defines five levels:
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
Level 4: Managed
Level 5: Optimized
1. Initial: Until the process is under statistical control, no orderly progress in process improvement is possible.
2. Repeatable: Basic project management processes are established to track cost, schedule, and functionality.
3. Defined: This is a process for management and engineering are documented, standardized and integrated into a standard software process for the software organization.
4. Managed: Detailed software process and product quality metrics establish the quantitative evolution foundation. Meaningful variations in process performance can be distinguished from random noise, and trends in process and product qualities can be predicated.
5. Optimized: The organization has quantitative feedback systems in place to identify process weakness and strengthen them pro-activity. Project teams analyze defects to determine their causes; software processes are evaluated and updated to prevent known types of defects from recurring.
Problem:
Do some research (check the SEI website) and determine the process maturity distribution for software organizations in the United States and worldwide.
Answer:
4633-30-3P SA: 4475
SR: 6376
A process maturity model provides an overall indication of the “process maturity” exhibited by a software organization. It provides a qualitative feel for the relative effectiveness of the software process. It is applied within the context of an SPI frame work.
By the distribution for software organizations in the and world web, the maturity model accomplished using some type of ordinal scale. The Process Maturity Model defines five levels of process maturity:
1. Initial (worship the hero)
2. Repeatable (plan the work)
3. Defined (work the plan)
4. Managed (measure the work)
5. Optimizing (work the measures)
The extent to which Key Process Areas (related clusters of activities that enhance process capability) are implemented at each level determines the process maturity level rating of an organization.
SEI Process Maturity Model:
Level 5: Optimized- The organization has quantitative feedback systems in place to identify process weaknesses and strengthen them pro-actively. Project teams analyze defects to determine their causes; software processes are evaluated and updated to prevent known types of defects from recurring.
Level 4: Managed - Detailed software process and product quality metrics establish the quantitative evaluation foundation. Meaningful variations in process performance can be distinguished from random noise, and trends in process and product qualities can be predicted.
Level 3: Defined - Processes for management and engineering are documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing software.
Level 2: Repeatable - Basic project management processes are established to track cost, schedule, and functionality. Planning and managing new products is based on experience with similar projects.
Level 1: Initial - Few processes defined, and success depends more on individual heroic efforts than on following a process and using a synergistic team effort.
4633-30-3P SA: 4475
SR: 6376
A process maturity model provides an overall indication of the “process maturity” exhibited by a software organization. It provides a qualitative feel for the relative effectiveness of the software process. It is applied within the context of an SPI frame work.
By the distribution for software organizations in the and world web, the maturity model accomplished using some type of ordinal scale. The Process Maturity Model defines five levels of process maturity:
1. Initial (worship the hero)
2. Repeatable (plan the work)
3. Defined (work the plan)
4. Managed (measure the work)
5. Optimizing (work the measures)
The extent to which Key Process Areas (related clusters of activities that enhance process capability) are implemented at each level determines the process maturity level rating of an organization.
SEI Process Maturity Model:
Level 5: Optimized- The organization has quantitative feedback systems in place to identify process weaknesses and strengthen them pro-actively. Project teams analyze defects to determine their causes; software processes are evaluated and updated to prevent known types of defects from recurring.
Level 4: Managed - Detailed software process and product quality metrics establish the quantitative evaluation foundation. Meaningful variations in process performance can be distinguished from random noise, and trends in process and product qualities can be predicted.
Level 3: Defined - Processes for management and engineering are documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing software.
Level 2: Repeatable - Basic project management processes are established to track cost, schedule, and functionality. Planning and managing new products is based on experience with similar projects.
Level 1: Initial - Few processes defined, and success depends more on individual heroic efforts than on following a process and using a synergistic team effort.
" Problem:
You work for a very small software organization—only 11 people are involved in developing software. Is SPI for you? Explain your answer.
Answer:
The SPI (software process improvement) is need for small organizations because a SPI implies a defined software process, an organizational approach, and a strategy for improvement.
Many small software organizations have struggled to deliver quality software with in time and budget. Generally quality of software is dependent on the quality of software process used in the development of software. The SPI implies that elements of an effective software process can be defined in an effective manner, and an existing organizational approach to software development can be assessed against those elements and finally a meaningful strategy for improvement can be defined.
An organization can choose a relatively informal approach to SPI, because the SPI framework defines
• A set of characteristics that must be present if an effective software process is to be achieved.
• A method for assessing whether those characteristics are present
• A mechanism for summarizing the results of any assessment
• A strategy for assisting a software organization in implementing those process characteristics that been found to be weak or missing.
Problem:
Assessment is analogous to an annual physical exam. Using a physical exam as a metaphor, describe the SPI assessment activity.
Answer:
Assessment helps in determining the quality level of a process. Just like an annual physical exam helps in examining how well the physical activities were carried out throughout, assessment helps in examining how well the software process and its activities have been followed and whether they are sufficient for a good quality product.
Assessment helps in finding out the strong as well as the weak points in the current software process of an organization. A high-quality process can be viewed as a result of different activities and tasks examined by assessment. The goal of assessment is simply to find if the activities that are performed conform to the best practices or not.
Other issues to be considered while assessment is performed are whether or not important activities including tasks and actions applied to all the software projects consistently. Consistency is very important as all software teams must adhere to best practices in a process for good quality products. In order to incorporate these in an organization, the management actions and technical activities are first thoroughly understood. These practices should thus be accepted widely by the entire technical and management staff. In order to achieve a consistent, sophisticated and well accepted approach to adhere to best practices, the management should be able to provided resources as needed by the teams.
Problem:
What is the difference between an “as is” process, a “here to there” process, and a “to be” process?
Answer:
The “as is” process, “here to there” and “to be” are three different process models of SPR (Software Process Redesign).
The “as is” process is existing process that used for the process to be redesigned in its inheritance.
The “to be” process is target process for resulting from redesign.
The “here to there” process is a transitional process that provides a series of way points that enable the software organization’s culture to adapt to small changes over a period of time.
Problem:
How is risk management applied within the context of SPI?
Answer:
4633-30-7P SA: 4475
SR: 6376
Risk Management for SPI:
SPI is a risky undertaking. In fact, more than half of all SPI efforts end in failure. SPI often fails because risks were not properly considered and no contingency planning occurred. So the role for those chartered with the responsibility is to analyze likely risks and develop an internal strategy for mitigating them.
A software organization should manage risk at three key points in the Software process improvement (SPI) process. They are
1. Prior to initiation of the SPI road map
2. During the execution of SPI activities and
3. During the evaluation activity that follows the instantiation of some process characteristic.
Problem:
Select one of the critical success factors noted in Section 37.2.7. Do some research and write a brief paper on how it can be achieved.
Answer:
4633-30-8P SA: 9420
SR: 6376
The top five critical success factors (CSFs) are:
1. Management commitment and support
2. Staff involvement
3. Process integration and understanding
4. A customized SPI strategy
5. Solid management of the SPI project
Management commitment and support:
Let us consider the factor “Management commitment and support”. It can be achieved in the following manner.
• If management is actively involved then SPI (Software process improvement) will succeed.
• Find the nature of position in the marketplace like a firm’s current position in the industry and define its strategy, resources and facilities.
• The visibility of leadership support is a main aspect in achieving widespread approval for change.
• Good quality results and changed behavior must be rewarded. At the same time, unchanged behavior and poor results should not be rewarded.
• Senior business managers should recognize the importance of software to their company and be active sponsors of the SPI effort.
• Appointing the right people in the right roles.
• Technical managers should be heavily involved in the development the local SPI strategy.
• Demanding the right reports and taking an action.
• Software process improvement is not feasible without investing time, money and effort.
• Management commitment and support are essential to sustain the investment.
Problem:
Do some research and explain how the CMMI differs from its predecessor, the CMM.
Answer:
The CMM stands for ‘Capability Maturity Model’. This is defined to software engineering.
The CMMI stands for ‘Capability Maturity Model Integration’, this is defined both software engineering and system engineering.
The both CMMI and CMM are used for software process improvement. But the CMM is superseded by CMMI and The CMMI is using multiple CMM for sort out problems in software improvement.
And the CMMI another difference from its predecessor is, the CMM is a reference model of matured practices in system engineering, software, people and so on, but here integration is difficult, but The CMMI is the successor of the CMM, combining components of CMM.
The above all steps are defined the CMMI differs from its predecessor (CMM).
Problem:
Select one of the SPI frameworks discussed in Section 37.5, and write a brief paper describing it in more detail.
Answer:
ISO/IEC 15504 is one of the SPI (software process improvement) frameworks. The ISO/IEC 15504 is a software process assessment; it is based on the process dimension and capability dimension.
Process dimension: The process dimension is a set of processes characterized by statements of process purpose and process outcomes. The process dimension is defined by external PRM (Process Reference Model).
The process dimension is defines processes, this is divided into the five process types:
1. Customer-supplier
2. Engineering
3. Supporting
4. Management
5. Organization
Capability dimension: The capability dimension have framework comprising six PCL (Process Capability Levels) and their associated process attributes. And this output consists of a set of process attributes ratings for each process assessed, and capability level achieved by that process.
Capability levels:
Level Name
1 Incomplete process
2 Performed process
3 Managed process
4 Established process
5 Predictable process
6 Optimizing process
Process attributes:
1. Process performance and performance management.
2. Work product management.
3. Process definition and Process deployment.
4. Process measurement and Process control.
5. Process innovation and Process optimization.
The ISO/IEC 15504 also knows as Software Process Improvement and Capability dEtermination (SPICE). It is developed by both ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission).
The software process assessment can be generalized as:
a. Initiate an assessment.
b. Select assessor and assessment team.
c. Plan the assessment, including processes and organizational unit to be assessed.
d. Pre-assessment briefing.
e. Data collection.
f. Data validation.
g. Process rating.
h. Reporting the assessment result.
The ISO/IEC 15504 is used in both Process improvement and Capability determination.
Solution: CHAPTER37: SOFTWARE PROCESS IMPROVEMENT
37.1 Failure to allow successful development process to succeed. All problems are perceived to be technical problems. Managerial and quality assurance activities are deemed to be overhead and superfluous to the task of software development process. Counterproductive processes are imposed. Processes are rigidly defined and adherence to the form is stressed. Collective management precludes assigning responsibility. Maintain status quo. Disregard for good software engineering institutionalized. Disconnect between software development activities and software process improvement activities. Complete lack of a training program. Total neglect of own charter, conscious discrediting of peer organizations software process improvement efforts. Rewards failure and poor performance
37.2 Process maturity might be described as how close a developing process is to being complete, and capable of continuous improvement through quantitative measure and feedback.
37.3 Answers will vary
37.4 Regardless of the size of the software organization it’s reasonable to consider the business motivation for SPI (financial leverage). Financial leverage is demonstrated by examining technical benefits (e.g., fewer defects delivered to the field, reduced rework, lower maintenance costs, or more rapid time to market) and translating them into dollars
37.5. Like a physical exam, which checks to be sure that a person is free of curable diseases an SPI assessment attempts to assess whether a software process is free of preventable problems and has a means of correcting process activities that are controllable by the project team.
37.6 An “as is” process is a process that is currently being used, a “here to there” process is process introduced to transform an “as is” process into the “to be” process, the “to be” process is a new process that a team would like to adopt
37.7.Software organizations to manage risks at three key points in the SPI process
- Prior to initiation of SPI roadmap
- During execution of SPI activities (assessment, education, selection, installation)
- During evaluation activity following instantiation of some process characteristic
37.8 Answers will vary
37.9 The CMM is limited to management and software engineering practices. The CMMI expands the CMM to address systems engineering and integrated product development as well. The CMMI is organized around a set of Process Areas (PAs). The PAs are divided into groups associated with what are called maturity levels. CMMI can be used as either a continuous model or staged model. CMM is only implemented as a staged model.
37.10 Answers will vary