What is Software Development Life Cycle (SDLC)? The various activities that are undertaken when developing software are commonly modelled as a software development lifecycle. The software development lifecycle begins with the identification of a requirement for software and ends with the formal verification of the developed software against that requirement.
The software development lifecycle does not exist by itself; it is in fact part of an overall product lifecycle. Within the product lifecycle, software will undergo maintenance to correct errors and to comply with changes to requirements. The simplest overall form is where the product is just software, but it can become much more complicated with multiple software developments, each forming part of an overall system to comprise a product.
There are a number of different models for software development lifecycles. Some of the more commonly used models are:
-> Waterfall Lifecycle Model -> Modified Waterfall Lifecycle Model -> V Lifecycle Model -> Progressive Development Lifecycle Model -> Iterative / Incremental Lifecycle Model -> Spiral Lifecycle Model -> Prototyping Model -> RAD Lifecycle Model
In statistics "sigma" refers to a variation. Six Sigma methodology focuses on reducing variation as a way to improve process. In particular, it uses sigma to measure the performance of a process to produce defect-free results. A defect is anything that causes customer dissatisfaction, such as a product that doesn't meet the customers specifications, poor service, or a price tag that's too high. The term Six Sigma defines an optimum measurement of quality. A company operating at Six Sigma quality produces 3.4 defects per million opportunities; that is, the work is 99.999966% defect free. Today, most organizations operate between 2 and 3 sigma. Even the best companies in the world operate at the 99% perfect level. 99% perfect (3.8 sigma) is still 6,000 to 66,0000 defects per million.
CMMI stands for "Capability Maturity Model Integration". It is a quality model, published and developed by the Software Engineering Institute in Pittsburgh, PA. CMMI has two representations, Staged and Continuous. In this article, I will give an overview of the continuous representation of CMMI. The main components in the structure of CMMI are Process Areas. A process area is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area.
Each process area has some specific goals and generic goals, which in turn have specific practices and generic practices respectively. These specific and generic practices are categorized under different Capability Levels. The capability levels for each process area are as follows: - Level 0: Not Performed - Level 1: Performed - Level 2: Managed - Level 3: Defined - Level 4: Quantitatively Managed - Level 5: Optimizing
In the continuous representation, all process areas are segregated under the following domains: - Process Management (Examples of process areas: Organizational Process Focus and Organizational Training) - Project Management (Examples of process areas: Project Planning and Project Monitoring and Control) - Engineering (Examples of process areas: Requirements Management and Requirements Deployment) - Support (Examples of process areas: Configuration Management and Process & Product Quality Assurance)
Specific goals and generic goals are required model components. They must be achieved by an organization's planned and implemented processes. They are essential to rating the achievement of a process area. Specific practices and generic practices are expected model components. They describe what an organization will typically implement to achieve a required component. Either the practices as described or acceptable alternatives to them are expected to be present in the planned and implemented processes of the organizations before goals can be considered satisfied.
Sub-practices, typical work products, discipline amplifications, generic practice elaborations, goal and practice titles, goal and practice notes, and references are informative model components. These help model users understand the goals and practices and how they can be achieved. According to the specific and generic practices followed by an organization, the process area can be said to be in a particular capability level. Thus according to this model, different process areas can be in different capability levels.
Some of the main benefits achieved from adopting this quality model: - Knowing your trade: Everybody involved in the projects knows exactly what their job is and how it relates with what everyone else is doing. - Understanding where you stand: CMMI is both complete and universally relevant, allowing for very precise and detailed benchmarking of process performance within as well as across organizations and industry segments. - Getting structured, logical, time-proven roadmap for improvement: Aligning your improvement plan to the CMMI levels ensures that you don't forget anything and effectively protects you from the infamous "tunnel vision" effect. - Positioning yourself as a best-practice company: Adhering to the principles and practices of the CMMI will make your clients look up to you as a disciplined, knowledgeable, reliable and trustworthy supplier.
Level 1 Characterized by chaos, periodic panics, and heroic efforts required by individuals to successfully complete projects. Few if any processes in place; successes may not be repeatable.
Level 2 Software project tracking, requirements management, realistic planning, and configuration managementprocesses are in place; successful practices can be repeated.
Level 3 Standard software development and maintenance processes are integrated throughout an organization; a Software Engineering Process Group is is in place to oversee software processes, and training programs are used to ensure understanding and compliance.
Level 4 Metrics are used to track productivity, processes, and products. Project performance is predictable, and quality is consistently high.
Level 5 The focus is on continouous process improvement. The impact of new processes and technologies can bepredicted and effectively implemented when required.
SEI = 'Software Engineering Institute' at Carnegie-Mellon University; initiated by the U.S. Defense Department to help improve software development processes.
CMM = 'Capability Maturity Model', now called the CMMI ('Capability Maturity Model Integration'), developed by the SEI. It's a model of 5 levels of process 'maturity' that determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense Department contractors. However, many of the QA processes involved are appropriate to any organization, and if reasonably applied can be helpful. Organizations can receive CMMI ratings by undergoing assessments by qualified auditors.
ISO = 'International Organisation for Standardization' - The ISO 9001:2000 standard (which replaces the previous standard of 1994) concerns quality systems that are assessed by outside auditors, and it applies to many kinds of production and manufacturing organizations, not just software.It covers documentation, design, development, production, testing, installation, servicing, and other processes. The full set of standards consists of: (a)Q9001-2000 - Quality Management Systems: Requirements; (b)Q9000-2000 - Quality Management Systems: Fundamentals and Vocabulary; (c)Q9004-2000 - Quality Management Systems: Guidelines for Performance Improvements.
To be ISO 9001 certified, a third-party auditor assesses an organization, and certification is typically good for about 3 years, after which a complete reassessment is required. Note that ISO certification does not necessarily indicate quality products - it indicates only that documented processes are followed. Also see http://www.iso.ch/ for the latest information.
IEEE = 'Institute of Electrical and Electronics Engineers' - among other things, creates standards such as 'IEEE Standard for Software Test Documentation' (IEEE/ANSI Standard 829), 'IEEE Standard of Software Unit Testing (IEEE/ANSI Standard 1008), 'IEEE Standard for Software Quality Assurance Plans' (IEEE/ANSI Standard 730), and others.
ANSI = 'American National Standards Institute', the primary industrial standards body in the U.S.; publishes some software-related standards in conjunction with the IEEE and ASQ (American Society for Quality).Other software development/IT management process assessment methods besides CMMI and ISO 9000 include SPICE, Trillium, TickIT, Bootstrap, ITIL, MOF, and CobiT.
Difference between Quality Assurance (QA) and Quality Control (QC)
What is Software Quality? Though there are a number of definitions propounded by the gurus in the field - each having its own adherents, two definitions that are widely accepted and that are complementary to each other are: - Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. - The degree to which a system, component, or process meets specified requirements and customer or user needs or expectations.
Quality assurance and quality control both contribute in delivering a high quality software product though the way they go about it is different. This can be illustrated by looking at the definitions of the two.
What is Software Quality Assurance? Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to ’prevention’.
This is a ’staff’ function, and is responsible for establishing standards and procedures to prevent defects and breakdowns in the SDLC. The focus of QA is prevention, processes, and continuous improvement of these processes.
What is Software Quality Control? This is a department function, which compares the standards to the product, and takes action when non-conformance is detected for example testing.This involves operation of a system or application under controlled conditions and evaluating the results (e.g., ’if the user is in interface A of the application while using hardware B, and does C, then D should happen’). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. It is oriented to ’detection’.
Relationship between QC and QA An application that meets its requirements totally can be said to exhibit quality. Quality is not based on a subjective assessment but rather on a clearly demonstrable, and measurable, basis. Quality.
- Quality Control is a process directed at validating that a specific deliverable meets standards, is error free, and is the best deliverable that can be produced. It is a responsibility internal to the team. - QA, on the other hand, is a review with a goal of improving the process as well as the deliverable. QA is often an external process. QA is an effective approach to producing a high quality product.
One aspect is the process of objectively reviewing project deliverables and the processes that produce them (including testing), to identify defects, and then making recommendations for improvement based on the reviews. The end result is the assurance that the system and application is of high quality, and that the process is working. The achievement of quality goals is well within reach when organizational strategies are used in the testing process. From the client's perspective, an application's quality is high if it meets their expectations.
