Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.
There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.
Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.
History
The modern definition of agile software development evolved in the mid 1990s as part of a reaction against "heavyweight" methods, as typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software engineers actually perform effective work. A case can be made that agile and iterative development methods are a return to development practice seen early in the history of software development. Initially, agile methods were called "lightweight methods." In 2001, prominent members of the community met at Snowbird, Utah, and adopted the name "agile methods." Later, some of these people formed The Agile Alliance, a non-profit organization that promotes agile development.
Comparison with other methods
Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive".Agile methods exist on the "adaptive" side of this continuum.
Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.
Agile methods have much in common with the "Rapid Application Development" techniques from the 1980's as espoused by James Martin and others.
.
LEAN implementation
System engineering
Lean is about more than just cutting costs in the factory. One crucial insight is that most costs are assigned when a product is designed. Often an engineer will specify familiar, safe materials and processes rather than inexpensive, efficient ones. This reduces project risk, that is, the cost to the engineer, while increasing financial risks, and decreasing profits. Good organizations develop and review checklists to review product designs.
Companies must often look beyond the shop-floor to find opportunities for improving overall company cost and performance. At the system engineering level, requirements are reviewed with marketing and customer representatives to eliminate costly requirements. Shared modules may be developed, such as multipurpose power-supplies or shared mechanical components or fasteners. Requirements are assigned to the cheapest discipline. For example, adjustments may be moved into software, and measurements away from a mechanical solution to an electronic solution. Another approach is to choose connection or power-transport methods that are cheap or that used standardized components that become available in a competitive market.
Lean is about more than just cutting costs in the factory. One crucial insight is that most costs are assigned when a product is designed. Often an engineer will specify familiar, safe materials and processes rather than inexpensive, efficient ones. This reduces project risk, that is, the cost to the engineer, while increasing financial risks, and decreasing profits. Good organizations develop and review checklists to review product designs.
Companies must often look beyond the shop-floor to find opportunities for improving overall company cost and performance. At the system engineering level, requirements are reviewed with marketing and customer representatives to eliminate costly requirements. Shared modules may be developed, such as multipurpose power-supplies or shared mechanical components or fasteners. Requirements are assigned to the cheapest discipline. For example, adjustments may be moved into software, and measurements away from a mechanical solution to an electronic solution. Another approach is to choose connection or power-transport methods that are cheap or that used standardized components that become available in a competitive market.
LEAN
Lean manufacturing is the production of goods using less of everything compared to mass production: less human effort, less manufacturing space, less investment in tools, and less engineering time to develop a new product. Lean manufacturing is a generic process management philosophy derived mostly from the Toyota Production System (TPS) and also from other sources. It is renowned for its focus on reduction of the original Toyota 'seven wastes' in order to improve overall customer value but has some key new perspectives on how to do this. Lean is often linked with Six Sigma because of that methodology's emphasis on reduction of process variation (or its converse smoothness) and Toyota's combined usage (with the TPS). Toyota's steady growth from a small player to the most valuable and the biggest car company in the world has focused attention upon how it has achieved this, making "Lean" a hot topic in management science in the first decade of the 21st century."Lean" is viewed by many as the latest management fad in the cost-reduction arena. It has for many the advantage of a very descriptive active name and has been, in many cases, used like any other cost-reduction approach. This has meant that the "Lean" word can be found in many places, projects and proposals. This has meant that for many it has hit the same implementation other approaches which has created a level of cynicism in some quarters about its effectiveness. However, there are enough high-profile high-success implementations (headed by Toyota) that attitudes to it are quite mixed overall.
Overview
For many, Lean is the set of TPS 'tools' that assist in the identification and steady elimination of waste, the improvement of quality, and production time and cost reduction. The Japanese terms from Toyota are quite strongly represented in "Lean". To solve the problem of waste, Lean Manufacturing has several 'tools' at its disposal. These include continuous process improvement, the "5 Whys" and mistake-proofing. In this way it can be seen as taking a very similar approach to other improvement methodologies.
There is a second approach to Lean Manufacturing, which is promoted by Toyota, in which the focus is upon improving the 'flow' or smoothness of work (thereby steadily eliminating mura, unevenness) through the system and not upon 'waste reduction' per se. Techniques to improve flow include production leveling, "pull" production (by means of kanban) and the Heijunka box. This is a fundamentally different approach to most improvement methodologies which may partially account for its lack of popularity.
The difference between these two approaches is not the goal but the prime approach to achieving it. The implementation of smooth flow exposes quality problems which already existed and thus waste reduction naturally happens as a consequence. The advantage claimed for this approach is that it naturally takes a system-wide perspective whereas a 'waste' focus has this perspective, sometimes wrongly, assumed. Some Toyota staff have expressed some surprise at the 'tool' based approach as they see the tools as work-arounds made necessary where flow could not be fully implemented and not as aims in themselves.
Both Lean and TPS can be seen as a loosely connected set of potentially competing principles whose goal is cost reduction by the elimination of waste. These principles include: Pull processing, Perfect first-time quality, Waste minimization, Continuous improvement, Flexibility, Building and maintaining a long term relationship with suppliers, Autonomation, Load leveling and Production flow and Visual control. The disconnected nature of some of these principles perhaps springs from the fact that the TPS has grown pragmatically since 1948 as it responded to the problems it saw within its own production facilities. Thus what one sees today is the result of a 'need' driven learning to improve where each step has built on previous ideas and not something based upon a theoretical framework. Toyota's view is that the methodology is not the tools but the method of application of muda, mura, muri to expose problems systematically and to use the tools where the ideal cannot be achieved. Thus the 'tools' are, in their view, 'workarounds' adapted to different situations which explains any apparent incoherence of the 'principles' above.
The TPS has two pillar concepts: JIT (flow) and autonomation (smart automation).Adherents of the Toyota approach would say that the smooth 'flowing’ delivery of 'value' achieves all these improvements as a side-effect. If production 'flows' perfectly then there is no inventory, if customer valued features are the only ones produced then product design is simplified and effort is only expended on features the customer values. The other of the two TPS pillars is the very human aspect of 'autonomation' whereby automation is achieved with a human touch. This aims to give the machines enough 'intelligence' to recognize when they are working abnormally and flag this for human attention. Thus humans do not have to monitor normal production and only have to focus on abnormal, or fault, conditions. A reduction in human workload that is probably much desired by all involved since it removes much routine and repetitive activity that humans often do not enjoy and where they are therefore not at their most effective.
Lean implementation is therefore focused on getting the right things, to the right place, at the right time, in the right quantity to achieve perfect work flow while minimizing waste and being flexible and able to change. These concepts of flexibility and change are principally required to allow production leveling, using tools like SMED, but have their analogues in other processes such as R&D. The flexibility and ability to change are not open-ended and therefore often not expensive capability requirements. More importantly, all of these concepts have to be understood, appreciated, and embraced by the actual employees who build the products and therefore own the processes that deliver the value. The cultural and managerial aspects of Lean are just as, and possibly more, important than the actual tools or methodologies of production itself. There are many examples of Lean tool implementation without sustained benefit and these are often blamed on weak understanding of Lean in the organization.
Lean aims to make the work simple enough to understand, to do and to manage. To achieve these three at once there is a belief held by some that Toyota's mentoring process (loosely called Senpai and Kohai relationship), so strongly supported in Japan, is one of the best ways to foster Lean Thinking up and down the organizational structure. This is the process undertaken by Toyota as it helps its suppliers to improve their own production. The closest equivalent to Toyota's mentoring process is the concept of Lean Sensei, which encourages companies, organizations, and teams to seek out outside, third-party "Sensei" that can provide unbiased advice and coaching.
Overview
For many, Lean is the set of TPS 'tools' that assist in the identification and steady elimination of waste, the improvement of quality, and production time and cost reduction. The Japanese terms from Toyota are quite strongly represented in "Lean". To solve the problem of waste, Lean Manufacturing has several 'tools' at its disposal. These include continuous process improvement, the "5 Whys" and mistake-proofing. In this way it can be seen as taking a very similar approach to other improvement methodologies.
There is a second approach to Lean Manufacturing, which is promoted by Toyota, in which the focus is upon improving the 'flow' or smoothness of work (thereby steadily eliminating mura, unevenness) through the system and not upon 'waste reduction' per se. Techniques to improve flow include production leveling, "pull" production (by means of kanban) and the Heijunka box. This is a fundamentally different approach to most improvement methodologies which may partially account for its lack of popularity.
The difference between these two approaches is not the goal but the prime approach to achieving it. The implementation of smooth flow exposes quality problems which already existed and thus waste reduction naturally happens as a consequence. The advantage claimed for this approach is that it naturally takes a system-wide perspective whereas a 'waste' focus has this perspective, sometimes wrongly, assumed. Some Toyota staff have expressed some surprise at the 'tool' based approach as they see the tools as work-arounds made necessary where flow could not be fully implemented and not as aims in themselves.
Both Lean and TPS can be seen as a loosely connected set of potentially competing principles whose goal is cost reduction by the elimination of waste. These principles include: Pull processing, Perfect first-time quality, Waste minimization, Continuous improvement, Flexibility, Building and maintaining a long term relationship with suppliers, Autonomation, Load leveling and Production flow and Visual control. The disconnected nature of some of these principles perhaps springs from the fact that the TPS has grown pragmatically since 1948 as it responded to the problems it saw within its own production facilities. Thus what one sees today is the result of a 'need' driven learning to improve where each step has built on previous ideas and not something based upon a theoretical framework. Toyota's view is that the methodology is not the tools but the method of application of muda, mura, muri to expose problems systematically and to use the tools where the ideal cannot be achieved. Thus the 'tools' are, in their view, 'workarounds' adapted to different situations which explains any apparent incoherence of the 'principles' above.
The TPS has two pillar concepts: JIT (flow) and autonomation (smart automation).Adherents of the Toyota approach would say that the smooth 'flowing’ delivery of 'value' achieves all these improvements as a side-effect. If production 'flows' perfectly then there is no inventory, if customer valued features are the only ones produced then product design is simplified and effort is only expended on features the customer values. The other of the two TPS pillars is the very human aspect of 'autonomation' whereby automation is achieved with a human touch. This aims to give the machines enough 'intelligence' to recognize when they are working abnormally and flag this for human attention. Thus humans do not have to monitor normal production and only have to focus on abnormal, or fault, conditions. A reduction in human workload that is probably much desired by all involved since it removes much routine and repetitive activity that humans often do not enjoy and where they are therefore not at their most effective.
Lean implementation is therefore focused on getting the right things, to the right place, at the right time, in the right quantity to achieve perfect work flow while minimizing waste and being flexible and able to change. These concepts of flexibility and change are principally required to allow production leveling, using tools like SMED, but have their analogues in other processes such as R&D. The flexibility and ability to change are not open-ended and therefore often not expensive capability requirements. More importantly, all of these concepts have to be understood, appreciated, and embraced by the actual employees who build the products and therefore own the processes that deliver the value. The cultural and managerial aspects of Lean are just as, and possibly more, important than the actual tools or methodologies of production itself. There are many examples of Lean tool implementation without sustained benefit and these are often blamed on weak understanding of Lean in the organization.
Lean aims to make the work simple enough to understand, to do and to manage. To achieve these three at once there is a belief held by some that Toyota's mentoring process (loosely called Senpai and Kohai relationship), so strongly supported in Japan, is one of the best ways to foster Lean Thinking up and down the organizational structure. This is the process undertaken by Toyota as it helps its suppliers to improve their own production. The closest equivalent to Toyota's mentoring process is the concept of Lean Sensei, which encourages companies, organizations, and teams to seek out outside, third-party "Sensei" that can provide unbiased advice and coaching.
IT Governance
Information Technology Governance, IT Governance or ICT Governance, is a subset discipline of Corporate Governance focused on information technology (IT) systems and their performance and risk management. The rising interest in IT governance is partly due to compliance initiatives (e.g. Sarbanes-Oxley (USA) and Basel II (Europe)), as well as the acknowledgment that IT projects can easily get out of control and profoundly affect the performance of an organization.
Problems with IT governance
Nicholas Carr has emerged as a prominent critic of the idea that information technology confers strategic advantage. This line of criticism might imply that significant attention to IT governance is not a worthwhile pursuit for senior corporate leadership. However, Carr also indicates counterbalancing concern for effective IT risk management.
The manifestation of IT governance objectives through detailed process controls (e.g. in the context of project management) is a frequently controversial matter in large scale IT management. See Agile methods. The difficulties in achieving a balance between financial transparency and cost-effective data capture in IT financial management (i.e., to enable chargeback) is a continual topic of discussion in the professional literature, and can be seen as a practical limitation to IT governance.
Relationship to other IT disciplines
IT governance is supported by disciplines such as:
- Business Service Management
- Business Technology Optimization
- Enterprise architecture
- IT asset management
- IT portfolio management
- IT security assessment
- IT service management
- Project governance Project management and Program management in the enterprise IT context (including software engineering where appropriate)
Problems with IT governance
Nicholas Carr has emerged as a prominent critic of the idea that information technology confers strategic advantage. This line of criticism might imply that significant attention to IT governance is not a worthwhile pursuit for senior corporate leadership. However, Carr also indicates counterbalancing concern for effective IT risk management.
The manifestation of IT governance objectives through detailed process controls (e.g. in the context of project management) is a frequently controversial matter in large scale IT management. See Agile methods. The difficulties in achieving a balance between financial transparency and cost-effective data capture in IT financial management (i.e., to enable chargeback) is a continual topic of discussion in the professional literature, and can be seen as a practical limitation to IT governance.
Relationship to other IT disciplines
IT governance is supported by disciplines such as:
- Business Service Management
- Business Technology Optimization
- Enterprise architecture
- IT asset management
- IT portfolio management
- IT security assessment
- IT service management
- Project governance Project management and Program management in the enterprise IT context (including software engineering where appropriate)
SQA and SQC in CMMI Validation (VAL)
Validation confirms that the product, as provided, will fulfill its intended use. In other words, validation ensures that “you built the right thing.” As with Verification, Validation is mainly the domain of SQC. The term Acceptance Test could also apply to Validation, in most cases the Acceptance test is carried out by a different group of people from the SQC team that performed Verification, as the product was being built. In the case where an application is going to be used internally, then the end user or business representative would perform the Acceptance testing. Wherever this is done it is in essence a SQC activity. As with Verification, SQA makes sure that these processes conform to standards and documented procedures. The Validation process itself is subject to continuous improvement and measurement.
SQA and SQC in CMMI Verification (VER)
The purpose of Verification is to ensure that selected work products meet their specified requirements Theses activities are only carried out by SQC, the role of SQA would be to make sure that SQC had documented procedures, plans etc. by audit. SQA would also measure the effectiveness of the Verification processes by tracking defects that were missed by SQC during Verification. Note the term Verification, as opposed to Validation. In essence Verification answers the question ‘Are we building the product correctly’ while Validation answers the question ‘Are we building the correct product’. Validation demonstrates that the product satisfies its intended purpose when place in the correct environment while Verification refers to building to specification. The FURPS+ model identifies both Customer and Product requirements; Verification applies to both these types of requirements and can be applied to the intermediary work products. Design or Code reviews are examples of Verification. These terms Verification and Validation are often mixed, CMMI makes this comment about the distinction:- Although “verification” and “validation” at first seem quite similar in CMMI models, on closer inspection you can see that each addresses different issues. Verification confirms that work products properly reflect the requirements specified for them. In other words, verification ensures that “you built it right.” While SQC carries out all the Verification activities the Verification process itself is still subject to SQA and process improvement.
SQA & SQC in CMMI Technical solution (TS)
The purpose of Technical Solution is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related life-cycle processes either singly or in combinations as appropriate.
SQA role To observe that documented standards, processes, and procedures are followed. SQA would also establish metrics in order to measure the effectiveness of this process. Clearly testing the end product against the requirements (which is itself a SQC activity) will reveal any defects introduced during this process. The number of defects is a common measure for the Design\Build phase. This metric is usually further quantified by some form of scope, for example defects per 100 lines of code, or per function.
SQC role The major SQC role during this process will be testing.
The finished product does not have to be present before testing can begin. Unit and Component can both take place before the product is complete. Design and Code reviews are also something that SQC could get involved with.
SQA role To observe that documented standards, processes, and procedures are followed. SQA would also establish metrics in order to measure the effectiveness of this process. Clearly testing the end product against the requirements (which is itself a SQC activity) will reveal any defects introduced during this process. The number of defects is a common measure for the Design\Build phase. This metric is usually further quantified by some form of scope, for example defects per 100 lines of code, or per function.
SQC role The major SQC role during this process will be testing.
The finished product does not have to be present before testing can begin. Unit and Component can both take place before the product is complete. Design and Code reviews are also something that SQC could get involved with.
SQA & SQC in CMMI Requirements Management (REQM)
The purpose of REQM is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products.
This process involves version control of the requirements and the relationship between the requirements and other work products. One tool used in Requirements Management is a Traceability Matrix.
The Traceability Matrix maps where in the Software a given requirement is implemented, it is a kind of cross reference table. The traceability matrix also maps which test case verify a given requirement.
SQA role To observe (audit) that documented standards, processes, and procedures are followed. SQA would also establish metrics in order to measure the effectiveness of this process. A common metric for measuring the Requirements Management would be the how many times the wrong Version was referenced. Another measure (for the Traceability Matrix) would be lack of test coverage, that is defects detected in the shipped product that were not tested due to the fact that they were not referenced in the Traceability matrix that referenced the requirements.
SQC role As with the actual Requirements Development, SQC would be involved in inspecting the actual deliverable’s (e.g. Traceability Matrix) from this process.
This process involves version control of the requirements and the relationship between the requirements and other work products. One tool used in Requirements Management is a Traceability Matrix.
The Traceability Matrix maps where in the Software a given requirement is implemented, it is a kind of cross reference table. The traceability matrix also maps which test case verify a given requirement.
SQA role To observe (audit) that documented standards, processes, and procedures are followed. SQA would also establish metrics in order to measure the effectiveness of this process. A common metric for measuring the Requirements Management would be the how many times the wrong Version was referenced. Another measure (for the Traceability Matrix) would be lack of test coverage, that is defects detected in the shipped product that were not tested due to the fact that they were not referenced in the Traceability matrix that referenced the requirements.
SQC role As with the actual Requirements Development, SQC would be involved in inspecting the actual deliverable’s (e.g. Traceability Matrix) from this process.
SQA & SQC in CMMI Requirement Development(RD)
The CMMI Requirements Development process area describes three types of requirements:- customer requirements, product requirements, and product-component requirements.
SQA role To observe that documented standards, processes, and procedures are followed. SQA would also establish software metrics in order to measure the effectiveness of this process. A common metric for measuring the Requirements process would be the number of errors (found during system testing) that could be traced to inaccurate or ambiguous requirements (note: SQC would perform the actual system testing but SQA would collect the metrics for monitoring and continuous improvement).
SQC role SQC takes an active role with Verification (this is a process itself that is described later). Verification of the requirements would involve inspection (reading) and looking for clarity and completeness. SQC would also verify that any documentated requirement standards are followed. Note there is a subtle difference between SQA and SQC with regard to standards, SQC’s role is in verifying the output of this process (that is the Requirement document itself) while SQA’s role is to make sure the process is followed correctly. SQA is more of an audit role here, and may sample actual Requirements whereas SQC is involved in the Verification of all Requirements. The type of requirement need not be just the functional aspect (or customer\user facing requirements) they could also include product and\or component requirements.
SQA role To observe that documented standards, processes, and procedures are followed. SQA would also establish software metrics in order to measure the effectiveness of this process. A common metric for measuring the Requirements process would be the number of errors (found during system testing) that could be traced to inaccurate or ambiguous requirements (note: SQC would perform the actual system testing but SQA would collect the metrics for monitoring and continuous improvement).
SQC role SQC takes an active role with Verification (this is a process itself that is described later). Verification of the requirements would involve inspection (reading) and looking for clarity and completeness. SQC would also verify that any documentated requirement standards are followed. Note there is a subtle difference between SQA and SQC with regard to standards, SQC’s role is in verifying the output of this process (that is the Requirement document itself) while SQA’s role is to make sure the process is followed correctly. SQA is more of an audit role here, and may sample actual Requirements whereas SQC is involved in the Verification of all Requirements. The type of requirement need not be just the functional aspect (or customer\user facing requirements) they could also include product and\or component requirements.
SQA, SQC and CMMI Definitions
Software Quality Assurance
The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.
Software Quality Control
The function of software quality that checks that the project follows its standards, processes, and procedures, and that the project produces the required internal and external (deliverable) products.
CMMI
A process improvement approach to software development. CMMi identifies a core set of Software Engineering process areas as:-
- Requirements Development
- Requirements Management
- Technical Solution
- Product Integration
- Verification
- Validation
CMMI also covers other process areas, such as Process Management, Project Management and Support but only the core Software Engineering development processes are used here by way of example.
It is also interesting to note that SQA and SQC are processes defined within CMMI, they are under the Support process area. In CMMI SQA\SQC is defined as Process and Product Quality Assurance.
CMMI is an approach to process improvement, in which SQA\SQC play a major but not exclusive role.Everyone in a software development organization takes part in both the CMMI processes and any improvement initiatives for those processes. Each of the main Engineering process areas is now described together with the role that SQA\SQC plays within those areas.
The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.
Software Quality Control
The function of software quality that checks that the project follows its standards, processes, and procedures, and that the project produces the required internal and external (deliverable) products.
CMMI
A process improvement approach to software development. CMMi identifies a core set of Software Engineering process areas as:-
- Requirements Development
- Requirements Management
- Technical Solution
- Product Integration
- Verification
- Validation
CMMI also covers other process areas, such as Process Management, Project Management and Support but only the core Software Engineering development processes are used here by way of example.
It is also interesting to note that SQA and SQC are processes defined within CMMI, they are under the Support process area. In CMMI SQA\SQC is defined as Process and Product Quality Assurance.
CMMI is an approach to process improvement, in which SQA\SQC play a major but not exclusive role.Everyone in a software development organization takes part in both the CMMI processes and any improvement initiatives for those processes. Each of the main Engineering process areas is now described together with the role that SQA\SQC plays within those areas.
SCAMPI
The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the official SEI method to provide benchmark-quality ratings relative to CMMI models. SCAMPI appraisals are used to identify strengths and weaknesses of current processes, reveal development/acquisition risks, and determine capability and maturity level ratings. They are mostly used either as part of a process improvement program or for rating prospective suppliers. The method defines the appraisal process as consisting of preparation; on-site activities; preliminary observations, findings, and ratings; final reporting; and follow-on activities.
Class A, B, and C Appraisals
The suite of documents associated with a particular version of the CMMI includes a requirements specification called the Appraisal Requirements for CMMI (ARC), which specifies three levels of formality for appraisals: Class A, B, and C. Formal (Class A) SCAMPIs are conducted by SEI-authorized Lead Appraisers who use the SCAMPI A Method Definition Document (MDD) to conduct the appraisals. Class A, the most formal, is required to achieve a rating (Level 1 (lowest) to Level 5 (highest)) for public record or for response to U.S. Department of Defense requirements.
Class A, B, and C Appraisals
The suite of documents associated with a particular version of the CMMI includes a requirements specification called the Appraisal Requirements for CMMI (ARC), which specifies three levels of formality for appraisals: Class A, B, and C. Formal (Class A) SCAMPIs are conducted by SEI-authorized Lead Appraisers who use the SCAMPI A Method Definition Document (MDD) to conduct the appraisals. Class A, the most formal, is required to achieve a rating (Level 1 (lowest) to Level 5 (highest)) for public record or for response to U.S. Department of Defense requirements.
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 the best practices of previous models in many important ways. CMMI best practices enable organizations to do the following:
· more explicitly link management and engineering activities to their business objectives
· expand the scope of and visibility into the product lifecycle and engineering activities to ensure that the product or service meets customer expectations
· incorporate lessons learned from additional areas of best practice (e.g., measurement, risk management, and supplier management)
· implement more robust high-maturity practices
· address additional organizational functions critical to their products and services
· more explicitly link management and engineering activities to their business objectives
· expand the scope of and visibility into the product lifecycle and engineering activities to ensure that the product or service meets customer expectations
· incorporate lessons learned from additional areas of best practice (e.g., measurement, risk management, and supplier management)
· implement more robust high-maturity practices
· address additional organizational functions critical to their products and services
Subscribe to:
Posts (Atom)