Roles and responsibilities of SQA in CMMI

SQA (Software Quality Assurance) Engineer in an Organization going for CMMI Assessment has various responsibilities. SQA Team Structure depends on the overall strength of the organization and number of people involved with process implementations (in Software Development or Services Organization). SQA is the mainly responsible for leading the Quality Initiative in the CMMI organization and is responsible for conducting many associated process improvement activities in the organization.

SQA is involved with these CMMI Process Improvement activities:

• Process Improvement Planning
• Conducting Audit of products, projects and services
• Development, modification and updating of a CMMI Compliant QMS
• Implementation Checks and Audits and the Follow-up Audits
• Conducting Training for Process Implementers according to their roles
• Training to Project Team Members on core activities like Project Management, Estimation, Reviews etc.
• Metrics Analysis Report preparation
• Preparation for SCAMPI Assessment Documentation and Training

All these activities are targeted towards the Continuous Process Improvement in the organization using CMMI Framework.

SEPG/QAG qualities required for CMMI

SEPG/QAG Group, here are some of the qualities required in a SEPG Team Member in a CMMI Organization:

• CMMI Knowledge is an added advantage. Knowledge of other Quality Framework and Standards makes you a pro.
• Subject Matter Expertise – you should have good knowledge and skill set in your field. It may in Software Development, Requirements Gathering, Software Design, Testing, Quality or any other field. But should understand Software Development Life Cycle models.
• Should have worked with good number of projects and people.
• Understand Processes and know about Process Improvement. Should have experience in assisting project teams in process implementation.
• Excellent communication and interpersonal skills.
• Good Team Player.
• Should be self motivated and capable of motivating others.
• Should be enthusiast about the process improvement and the organization.
• Should take part in SEPG meetings actively.
• Should complete the tasks on time, assigned by SEPG Team.

TOP 6 BENEFITS OF ADOPTING CAPABILITY MATURITY MODEL – CMMI

The quality of a software product is only as good as the process used to develop and maintain it. Whether a software organization is competing in the marketplace or trying to satisfy internal requirements, its software process is a critical success factor. Well thought out improvements to the process will significantly contribute to the organization’s performance.

Capability Maturity Model Integration (CMMI) is a process improvement training and certification program and service administered and marketed by Carnegie Mellon University and required by manyDOD and Government programs for government contracts, especially software development. Carnegie Mellon University claims CMMI can be used to guide process improvement across a project, division, or an entire organization.

SOME INTERESTING STATS

There are over 5,000 businesses that use CMMI models from over 70 countries, including the U.S., China, Germany, Italy, Australia, India, Turkey, Pakistan, Egypt,Chile,  and Russia.

A research by University of Missouri – St. Louis IS6840 – Fall 2008

TOP 6 BENEFITS OF ADOPTING CMMI QUALITY FRAMEWORK?

CMMI not only rates the maturity of companies’ process, it gives a level of assurance that the company being given the work will be able to complete the job in the time and price quoted for the project.

In order for the local software development industry to become more competitive on a global scale, it will need to fall into line with international standards, so that local companies seeking international contracts will be able to meet the CMMI level specified by international companies.

Having originated in the US defense sector, CMMI is now being adopted increasingly widely to drive Business Improvement in diverse organisations.

1 – CONSISTENCY

CMMI provides a proven approach that has enabled diverse organisations to drive out real benefits in terms of dramatically improved project predictability and consistency. Whilst any or all of the above factors may drive an organisation’s initial interest in CMMI, the key benefit from implementing the model that executives focus on is consistency in delivery.

2 – COST SAVING

CMMI driven process improvement also delivers real cost savings such as earlier and more effective error detection, and hence reduced cost of remediation, more effective management of change so you spend less on re-work, reductions in schedule variability and increased cost predictability.

3 – SELF IMPROVEMENT

There is also the aspect of self improvement. Companies will be able to use CMMI as a way of differentiating themselves locally and by achieving a level of CMMI will have naturally improved their processes which will make them more competitive. The heat of competition is now driving significant interest in CMMI.  Development, Service Provider and Acquisition/Outsourcing organisations are all adopting CMMI both as a differentiator and as an enabler to enhanced performance.

4 – MARKET DEMAND

Competing companies are utilizing CMMI for  industry best practices and reaping the benefit of it. Companies have adopted this approach to best meet the customer demands and competition. —Growing popularity of CMMI in the market is also a big reason of adoption of this practice by companies.

—Subcontractors providing custom software to companies creating solutions for the federal government must either themselves be following CMMI, or be covered by their client.  All the parts of the software product delivered to the government must be following CMMI somewhere in the supply chain.

5 – PERFORMANCE DEMAND

—The purpose of CMMI is to improve upon the performance of the existing organizational standards, processes and procedures and NOT to redefine or them. —CMMI is meant to help organizations improve on their “capability” to consistently and predictably deliver the products, services, and sourced goods their customers want, when they want them and at a price they’re willing to pay.

CMMI can be applied to create a process improvement solution appropriate to the context of each unique organization and can provide a path for an organization to achieve its performance goals.

6 – PROCESS IMPROVEMENT

A CMMI driven improvement project will deliver a framework to standardize your processes, ensuring that your business’s best practices are captured, shared and adopted so that you can move staff around your organization and leavers won’t take business critical information away with them.

—CMMI includes 25 different process areas to cater comprehensive business process improvement solution. —Each process area is made of two kinds of goals, two kinds of practices, and a whole lot of informative information helping management to make strategies.

WHY USE A MODEL?

Without a model of how an organization work, which functions it need, and how those functions interact, it is difficult to lead efforts to improve. A model gives us an understanding of discrete elements in an organization and helps to formulate language and discussion of what needs to be improved and how such improvement might be achieved. A model offers the following benefits:

• provides a common framework and language to help communicate
• leverages years of experience
• helps users keep the big picture in mind while focusing specifically on improvement
• is often supported by trainers and consultants
• can provide a standard to help solve disagreements

CHARACTERISTICS OF THE MATURITY LEVELS

Under the CMMI methodology, processes are rated according to their maturity levels, which are defined as: Initial, Repeatable, Defined, Quantitatively Managed, Optimizing. Currently supported is CMMI Version 1.3. CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

CMMI MODEL FRAMEWORK

—3 Constellations are defined to help improve a given business need.  Currently there are three (3) constellations:

—Development: For improving the development of solutions.
—Acquisition: For improving the purchasing of products, services and/or solutions.
—Services: For improving delivery of services and creation of service systems (say, to operate a solution but not buy it or build it in the first place).

 

MATURITY LEVELS IN CMMI FOR DEVELOPMENT

There are five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The process areas below and their maturity levels are listed for the CMMI for Development model:

• Maturity Level 2 – Repeatable
• Maturity Level 3 – Defined
• Maturity Level 4 – Quantitatively Managed
• Maturity Level 5 – Optimizing

MATURITY LEVELS IN CMMI FOR SERVICES

The process areas below and their maturity levels are listed for the CMMI for Services model:

• Maturity Level 2 – Managed
• Maturity Level 3 – Defined
• Maturity Level 4 – Quantitatively Managed
• Maturity Level 5 – Optimizing

MATURITY LEVELS IN CMMI FOR ACQUISITION

The process areas below and their maturity levels are listed for the CMMI for Acquisition model:

• Maturity Level 2 – Managed
• Maturity Level 3 – Defined
• Maturity Level 4 – Quantitatively Managed
• Maturity Level 5 – Optimizing

SUMMARY

A high maturity organization where all individuals recognize their role and responsibility for business success is an organization that is more likely to achieve success.

What an organization gets out of process deployment and CMMI appraisals is a reflection of what the organization puts into it. Organizations that focus on a just wining the CMMI certification hardly find the real benefits of adopting the quality framework.

High maturity, with its focus on quality and process performance objectives, puts organizations and projects in a position to succeed.

Why is CMMI Appraisal Important for Software Development Companies?

As a software development professional that has been in the IT industry for over 30 years, I think it is fair to say I have a qualified perspective on the effect that process and standardization have on producing software products and services. Back in the day, however, I didn’t always understand the need for these formalities. I would ask questions like, “Is it really necessary to ‘document’ my code?” or “Do we really need to do ‘that’ on ‘all’ of our deliverables?” or say, “I can get so much more done if I didn’t need to worry about ‘dotting the I’s and crossing the T’s.’” I make sure my code is documented and tested; why do I have to consider other approaches?” It all just seemed to be a waste of time and money to me.

Well, that was me as a coder, many moons ago, and I’m sure that these types of concerns still resonate with others today. Now I have a different perspective as an owner and partner ofSegue Technologies, and the current Director of Software Engineering. There are a whole host of challenges that arise with answering those core questions while still maintaining productivity and quality across the enterprise of services and development platforms. As a business owner, I am fully cognizant of the acronym ROI (Return on Investment) and how most decisions, if not all, are based on what the ROI expectations tell us. This both applies to the operations and success of Segue, and to the value and quality of our services for our customers.

Can a balance be achieved between administration and management costs and just “cranking out the code?” Should a formal analysis be conducted and investments made with the hope of the coveted ROI? Or was I right in my junior years? As an organization, you can start to find this balance by delving into process organizations whose whole mission in life is centered on identifying everything under the sun coupled to “best practices.” You know who they are: ISO,ITIL, Six Sigma, IEEE, and a host of others. They all have white-papers and checklists that are truly inspirational and offer practical guidance in possibly achieving that necessary “balance.”

The Importance of a CMMI Appraisal

The Software Engineering Institute (SEI), at Carnegie-Melon University, was initiated by the U.S. Department of Defense. SEI has long been the organization which not only researches and recommends development improvements, processes and practices, but provides an independent and objective “appraisal” as to whether an organization is actively practicing these standards. This last fact alone justifies a CMMI appraisal from a purely compliance perspective. It has become increasingly more common to see the requirement for a development company to have had a successful CMMI appraisal conducted in order to even qualify for Federal Government contracts. Bottom line: if you do work for the Federal government, you better get started with a CMMI Appraisal, if you haven’t already!

The Benefits of CMMI Accreditation

Through experience and (dare I say) wisdom, I have seen first-hand the benefits that CMMI accreditation has brought to our organization, to include:

1.   Expectation of Sustainment for the long haul

2.   A balance between productivity and process by aligning our internal processes, with the Process Areas called out in the CMMI guidance.

Repeatability is the key for process success, and as they have now become the norm and not painful, everyone is in synch with the expectations.

Without an appraisal, it is doubtful that our organization would have implemented a sustainable and measurable process that everyone is aware of and that drives operations. We have seen ROI through optimization of tasks, estimation techniques, ownership/accountability, management, and how all corporate components play a role in quality through a consistent work-flow, just to list a few!

What to Expect During a CMMI Appraisal

This is where the bulk of your investment takes place. It involves all facets of your organization and requires training and management. You will also need to pay for the independent appraisal itself, from a qualified SEI appraiser. In addition, there are options to work with certified CMMI organizations that can consult and guide you through the appraisal preparation. There are also a series of tools and guides available from SEI, at no cost, that allow you to conduct the preparation without need of consultation.

In our journey toward CMMI appraisal, our organizational “pains” occurred when we embarked on the inventory and mapping of what we were currently doing, as compared to the CMMI process areas and generic and specific practices. Gaps were identified and addressed and all of those were found to add value to our organization. It was well worth it though, as we did realize ROI and can measure it routinely now!

The beauty of CMMI is its different levels of maturity. These help guide an organization to continually improve and implement practices in chunks rather than having to deal with everything at once. We can now progress and refine improvement as we mature by building on the CMMI foundation we have established. The more mature your organization becomes, following the CMMI progression/capability levels, the more you become competitive through optimization and quality. Most important to my business and to the value I can provide my customers, is continually improving ROI.

How to Achieve Level 5 Maturity for QA and Testing Process

For any process whether it is a QA process, development process or any non-technical process, there are levels of its maturity. By levels of maturity we mean that the level of formality and processes improvement, like ad-hoc processes – to formally defined steps – to managed result metrics – to optimization of the processes.

CMM (Capability Maturity Model) is process based model which is used to assess the maturity of an organization for different domains. Although this model is normally termed as the software development model but eventually it was used for other processes as well like QA and testing.

It has 5 different levels of maturity from 1 to 5. As we go towards level 5 from 1, variability and inconsistency reduces. Below are the details of 5 levels. Here we will go through the 5 CMM levels with respect to QA process and what all output/result is expected for each level to mature a QA/testing process and reach up to level 5.

Level 1 – Ad-Hoc: Unplanned, unsystematic, and inconsistent

As the word ‘Ad-Hoc’ states: unplanned, unprepared, at this level significance is not given to planning, following processes, guidelines and standards. There is no standardized & consistent way of doing any task. The only thing which is important at this level is meeting the timelines, irrespective of the quality of the end product and deliverables.

As there are no pre-defined standards and processes, same task is done in different ways by different people.

And this becomes even more unsystematic and inconsistent if same task is done differently next time.

Example -
QA – The example would be that in an organization although QA is 1 of the phases in a product life cycle but there are not any standard & no process defined, no templates for QA deliverables like plan, strategy, scenarios, and cases are standardized. Even if these are documented then all team members have their own way of doing it and not consistent at all.

Level 2 – Control: initiate defining processes at high level:

Solution to the problem which we saw at Level 1 of unavailability of QA processes, methodology & standards would be to have all these in place. The standards and processes are not only finalized but also are well documented, so that those can be re-used by any one for similar task.

Example -
QA – Define overall QA process and methodology for different types of testing like functional, data, performance etc. Define the role of a QA engineer in project’s life cycle and prepare templates for deliverables in each phase. Not only define and prepare rather share within team

Level 3 – Core Competency: Come up with a generalized process for wider audience and domains:

At this level 3, people are motivated to follow the standards and processes defined at level 2. For this first of all the processes need to be conveyed to all people and need to identify what all skills are needed to use those effectively and efficiently and also if any training is required for that and then motivated and supported to follow those standards and processes. Here people having more experience share their knowledge with others.

Example -
QA – Conduct webinars and training sessions to let people get acquainted about the newly defined QA process and standards and motivate them to make use of those during their day to day project’s life

Level 4 – Predictable: Measure the processes

At this level processes defined at level 3 are measured quantitatively. This is done to control the effort required on any task. Based on this quantitative analysis, processes can be adjusted if needed, and that to without degrading the quality of the end product. Analysis is done by dividing complete process into smaller sub-processes and then quantitative techniques are applied on these sub-processes and as per the result, sub-processes are adjusted if needed. This level is called predictable as based on prior experience; we can predict the process quantitatively and make use of that for the upcoming processes.

Example -
QA – Performing regular audits would be a good idea here. This can include to check if teams are actually following the processes defined, using the standard templates, adhere to methodology or not.

Level 5 – Innovative: Continuous Improvement

At this level, innovative ways are identified to further improve the pre-defined processes and standards. This is a continuous process. For this our own processes are watched and re-engineered continuously by adding new tools technologies, by continuous studies and by keeping ourselves updated with new information in the market. This can also be achieved by benchmarking other organizations and learn from them and try to improve our process by adding new innovations to it.

Example -
QA – Keep on improving the methodology, processes defined based on prior audit results.

Based on some studies it has been concluded that the organizations at level 1 may spend $1000 for any particular task then for the same task organization at level 5 needs to spend $10.

After going though all 5 levels mentioned above, looks like reaching up to level 3 is difficult. Once it achieved then next levels are not too far and difficult to achieve

What is SEI? CMM? ISO? IEEE? ANSI?

· 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’, developed by the SEI. It’s a model of 5 levels of organizational ‘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 CMM ratings by undergoing assessments by qualified auditors.

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 management processes 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 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 continuous process improvement. The impact of new processes and technologies can be predicted and effectively implemented when required.

· ISO 

= ‘International Organization for Standards’ – The ISO 9001, 9002, and 9003 standards concern quality systems that are assessed by outside auditors, and they apply to many kinds of production and manufacturing organizations, not just software. The most comprehensive is 9001, and this is the one most often used by software development organizations. It covers documentation, design, development, production, testing, installation, servicing, and other processes. ISO 9000-3 (not the same as 9003) is a guideline for applying ISO 9001 to software development organizations. The U.S. version of the ISO 9000 series standards is exactly the same as the international version, and is called the ANSI/ASQ Q9000 series. The U.S. version can be purchased directly from the ASQ (American Society for Quality) or the ANSI organizations. 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 9000 certification does not necessarily indicate quality products – it indicates only that documented processes are followed.

· 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).

More about Prototyping methodology ....

Prototyping Model

The prototyping model assumes that you do not have clear requirements at the beginning of the project. Often, customers have a vague idea of the requirements in the form of objectives that they want the system to address. With the prototyping model, you build a simplified version of the system and seek feedback from the parties who have a stake in the project. The next iteration incorporates the feedback and improves on the requirements specification. The prototypes that are built during the iterations can be any of the following:

• A simple user interface without any actual data processing logic
• A few subsystems with functionality that is partially or completely implemented
• Existing components that demonstrate the functionality that will be incorporated into the system

The prototyping model consists of the following steps.

1. Capture requirements. This step involves collecting the requirements over a period of time as they become available.
2. Design the system. After capturing the requirements, a new design is made or an existing one is modified to address the new requirements.
3. Create or modify the prototype. A prototype is created or an existing prototype is modified based on the design from the previous step.
4. Assess based on feedback. The prototype is sent to the stakeholders for review. Based on their feedback, an impact analysis is conducted for the requirements, the design, and the prototype. The role of testing at this step is to ensure that customer feedback is incorporated in the next version of the prototype.
5. Refine the prototype. The prototype is refined based on the impact analysis conducted in the previous step.
6. Implement the system. After the requirements are understood, the system is rewritten either from scratch or by reusing the prototypes. The testing effort consists of the following:
   • Ensuring that the system meets the refined requirements
   • Code review
   • Unit testing
   • System testing

The main advantage of the prototyping model is that it allows you to start with requirements that are not clearly defined.
The main disadvantage of the prototyping model is that it can lead to poorly designed systems. The prototypes are usually built without regard to how they might be used later, so attempts to reuse them may result in inefficient systems. This model emphasizes refining the requirements based on customer feedback, rather than ensuring a better product through quick change based on test feedback.

More about Rapid Release Methodology..............

The Rapid Release Model
The Internet enables software companies to adopt a new software development model, the Rapid Release Model. In this model, once a product is released, a new version is released on the Internet every 90 days. Each 90-day update includes both bug fixes and new features. The pace of development is no different than in the 18-month development cycle, but new features are released to customers as soon as they are ready. During an 18-month period the customer receives six updates that collectively equal or exceed what he traditionally would have received from a single, monolithic update.
Benefits to Customers
Customers benefit from the rapid release model in three ways:
(1) Higher quality
During a 90-day development cycle, new features are implemented during the first 60 days and are tested and debugged during the last 30 days. Any bugs found during testing are easier to fix because the code is still fresh in the developer's mind. During an 18-month cycle, the code in question could be more than a year old. Also, in the Rapid Release Model, the pressure to release features before they are ready is greatly reduced because the next release is already scheduled in 90 days.

The Rapid Release Model does not increase the pace of software development, but it does increase the pace of releases.

(2) Better service
Releasing an update every 90 days enables the software developer to be more responsive to the needs of its customers. For example, when an update to the operating system ships, customers know that an updated version of their software that supports the new OS will be shipping within 90 days. In addition, software companies can plan releases around major OS updates to further prevent customers from having to wait.
(3) Lower price
The Rapid Release Model is more cost effective for the software developer because it no longer maintains the old version of their product while working on a new version. In the Rapid Release Model, old versions are not maintained; they are replaced by an update that contains both bug fixes and new features. The lower cost of development is a benefit that some software companies will choose to pass on to their customers.
Benefits to Developers
Software developers also benefit from the Rapid Release Model in three ways:
(1) Enhanced competitiveness
Software companies that employ the Rapid Release Model can respond very quickly to changing market conditions, demonstrating greater market agility, the ability to be responsive to customer requirements. This makes companies on longer development cycles struggle to keep up.
(2) Reduced risk
Large, monolithic releases can be very risky because 18 months is an enormous period of time in the technology business. Market conditions today are nothing like they were two years ago. Release dates for large updates are often delayed because customer requirements change during the development cycle as new features must be added to an already complex development project. Releasing every 90 days minimizes risk by reducing the amount of time between planning a product and releasing it.
(3) More marketing opportunities
Before the Internet, marketing software required long-range planning around print advertising and magazine editorial calendars. Today, however, most software marketing takes place online, where software updates are covered on websites and in blogs where content is updated on a daily basis. In the Internet marketing game, each new release provides a fresh opportunity to grab a fleeting moment of coverage and online advertising can be focused on the benefits of each new release.

The Rapid Release Model provides more opportunities for a software product to be mentioned by the media as interesting new product releases are made available more frequently.

The Rapid Release Business Model
One challenge with the Rapid Release Model is finding the right way to sell frequent releases to customers. Clearly it would be problematic to ask a customer to purchase an update every three months. Customers would consider this onerous and corporate purchasing departments would be resistant to authorizing frequent update orders. In addition, determining the correct pricing for each small upgrade would be challenging. For these reasons, the most effective way to package and sell rapid updates is through a software maintenance model, where the customer purchases all of the updates released during a 12-month period. This enables the customer to conduct just one transaction per year while receiving an update every 90 days.

Customers do not want to purchase a software upgrade every 90 days.

The customer's concern with this model is whether the developer will stay on schedule and release an update every 90 days. The solution to this problem is to include six months of updates with every new purchase to demonstrate a commitment to the Rapid Release Model before asking the customer to purchase 12 months of updates.
By the time the six months of updates have ended the customer has received two "free" updates and is convinced of the software developer's ability to rapidly update its product.
Conclusion
The traditional 18-month development cycle is a vestige of pre-Internet sales models. Although some commercial software, such as games, require long development cycles with no updates, most software companies and their customers would benefit from a move towards shorter, faster development cycles.
Consumer benefits of this model include higher quality, better service and lower prices. Developer benefits include greater competitiveness, reduced risk and more marketing opportunities.
Developers who do remain on traditional 18-month schedules will appear slow and unresponsive when compared to their more agile competitors who adopt the Rapid Release Model.

More about Prototyping methodology ....

Prototyping Model

The prototyping model assumes that you do not have clear requirements at the beginning of the project. Often, customers have a vague idea of the requirements in the form of objectives that they want the system to address. With the prototyping model, you build a simplified version of the system and seek feedback from the parties who have a stake in the project. The next iteration incorporates the feedback and improves on the requirements specification. The prototypes that are built during the iterations can be any of the following:

• A simple user interface without any actual data processing logic
• A few subsystems with functionality that is partially or completely implemented
• Existing components that demonstrate the functionality that will be incorporated into the system

The prototyping model consists of the following steps.

1. Capture requirements. This step involves collecting the requirements over a period of time as they become available.
2. Design the system. After capturing the requirements, a new design is made or an existing one is modified to address the new requirements.
3. Create or modify the prototype. A prototype is created or an existing prototype is modified based on the design from the previous step.
4. Assess based on feedback. The prototype is sent to the stakeholders for review. Based on their feedback, an impact analysis is conducted for the requirements, the design, and the prototype. The role of testing at this step is to ensure that customer feedback is incorporated in the next version of the prototype.
5. Refine the prototype. The prototype is refined based on the impact analysis conducted in the previous step.
6. Implement the system. After the requirements are understood, the system is rewritten either from scratch or by reusing the prototypes. The testing effort consists of the following:
   • Ensuring that the system meets the refined requirements
   • Code review
   • Unit testing
   • System testing

The main advantage of the prototyping model is that it allows you to start with requirements that are not clearly defined.
The main disadvantage of the prototyping model is that it can lead to poorly designed systems. The prototypes are usually built without regard to how they might be used later, so attempts to reuse them may result in inefficient systems. This model emphasizes refining the requirements based on customer feedback, rather than ensuring a better product through quick change based on test feedback.

More about Incremental or Iterative methodology

Incremental or Iterative Development

The incremental, or iterative, development model breaks the project into small parts. Each part is subjected to multiple iterations of the waterfall model. At the end of each iteration, a new module is completed or an existing one is improved on, the module is integrated into the structure, and the structure is then tested as a whole.
For example, using the iterative development model, a project can be divided into 12 one- to four-week iterations. The system is tested at the end of each iteration, and the test feedback is immediately incorporated at the end of each test cycle. The time required for successive iterations can be reduced based on the experience gained from past iterations. The system grows by adding new functions during the development portion of each iteration. Each cycle tackles a relatively small set of requirements; therefore, testing evolves as the system evolves. In contrast, in a classic waterfall life cycle, each phase (requirement analysis, system design, and so on) occurs once in the development cycle for the entire set of system requirements.
The main advantage of the iterative development model is that corrective actions can be taken at the end of each iteration. The corrective actions can be changes to the specification because of incorrect interpretation of the requirements, changes to the requirements themselves, and other design or code-related changes based on the system testing conducted at the end of each cycle.
The main disadvantages of the iterative development model are as follows:

• The communication overhead for the project team is significant, because each iteration involves giving feedback about deliverables, effort, timelines, and so on.
• It is difficult to freeze requirements, and they may continue to change in later iterations because of increasing customer demands. As a result, more iterations may be added to the project, leading to project delays and cost overruns.
• The project requires a very efficient change control mechanism to manage changes made to the system during each iteration.

More about Waterfal Model .........

Waterfall Model

The waterfall model is one of the earliest structured models for software development. It consists of the following sequential phases through which the development life cycle progresses:

• System feasibility. In this phase, you consider the various aspects of the targeted business process, find out which aspects are worth incorporating into a system, and evaluate various approaches to building the required software.
• Requirement analysis. In this phase, you capture software requirements in such a way that they can be translated into actual use cases for the system. The requirements can derive from use cases, performance goals, target deployment, and so on.
• System design. In this phase, you identify the interacting components that make up the system. You define the exposed interfaces, the communication between the interfaces, key algorithms used, and the sequence of interaction. An architecture and design review is conducted at the end of this phase to ensure that the design conforms to the previously defined requirements.
• Coding and unit testing. In this phase, you write code for the modules that make up the system. You also review the code and individually test the functionality of each module.
• Integration and system testing. In this phase, you integrate all of the modules in the system and test them as a single system for all of the use cases, making sure that the modules meet the requirements.
• Deployment and maintenance. In this phase, you deploy the software system in the production environment. You then correct any errors that are identified in this phase, and add or modify functionality based on the updated requirements.

The waterfall model has the following advantages:

• It allows you to compartmentalize the life cycle into various phases, which allows you to plan the resources and effort required through the development process.
• It enforces testing in every stage in the form of reviews and unit testing. You conduct design reviews, code reviews, unit testing, and integration testing during the stages of the life cycle.
• It allows you to set expectations for deliverables after each phase.

The waterfall model has the following disadvantages:

• You do not see a working version of the software until late in the life cycle. For this reason, you can fail to detect problems until the system testing phase. Problems may be more costly to fix in this phase than they would have been earlier in the life cycle.
• When an application is in the system testing phase, it is difficult to change something that was not carefully considered in the system design phase. The emphasis on early planning tends to delay or restrict the amount of change that the testing effort can instigate, which is not the case when a working model is tested for immediate feedback.
• For a phase to begin, the preceding phase must be complete; for example, the system design phase cannot begin until the requirement analysis phase is complete and the requirements are frozen. As a result, the waterfall model is not able to accommodate uncertainties that may persist after a phase is completed. These uncertainties may lead to delays and extended project schedules.

Software Testing Methodologies

The best methodologies are:

AGILE SOFTWARE DEVELOPMENT

Agile Software Development

Agile development methods tend to promote teamwork and collaboration. The agile development process isn’t sequential (code, test, debug, release), like traditional development processes; nor is it iterative; it combines concepts of both.
Twelve principles underlie the Agile Manifesto, including:

• Customer satisfaction by rapid delivery of useful software
• Welcome changing requirements, even late in development.
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Sustainable development, able to maintain a constant pace
• Close, daily cooperation between businesspeople and developers
• Face-to-face conversation is the best form of communication (co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

CLEANROOM SOFTWARE ENGINEERING

The Cleanroom Software Engineering process is a software development process intended to produce software with a certifiable level of reliability:

• Cleanroom development uses on formal methods in the design and specification of a software product. A team verifies that the design correctly implements the spec.
• Development and testing is done using an iterative approach, where functionality is added to the product incrementally (as opposed to creating all of the functionality first, THEN testing it).
• Software testing is performed as a statistical experiment.

ITERATIVE SOFTWARE DEVELOPMENT

Iterative Software Development

Iterative development is at the heart of a cyclic software development process; it starts with an initial planning and ends with deployment with the cyclic interactions in between.
Iterative development is NOT the same thing as incremental development, although the two methodologies do complement each other.
Two steps are involved in iterative development:

• Initialization: Creates a base version of the system.
• Iteration: The current version of the system is analyzed, and is redesigned and implemented based on the Project Control list.

RAPID APPLICATION DEVELOPMENT (RAD)

In place of extensive planning, RAD makes heavy use of prototyping.
In Rapid Application Development, structured techniques and prototyping are especially used to define users’ requirements and to design the final system. The development process starts with the development of preliminary data models and business process models using structured techniques. In the next stage, requirements are verified using prototyping, eventually to refine the data and process models. These stages are repeated iteratively.

RATIONAL UNIFIED PROCESS (RUP)

The Rational Unified Process is a framework intended to be customized by software development teams, for their individual needs. It was created by Rational Software (which is now part of IBM).
RUP emphasises six best practices for modern software engineering:

1. Develop iteratively, with risk as the primary iteration driver
2. Manage requirements
3. Employ a component-based architecture
4. Model software visually
5. Continuously verify quality
6. Control changes

Rational Unified Processing

SPIRAL SOFTWARE DEVELOPMENT

The Spiral Model is an iterative model that attempts to combine advantages of the top-down and bottom-up models of software design.

Spiral Software Development

The system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

• A preliminary design is created for the new system. This phase is the most important part of the Spiral Model.

• A first prototype of the new system is constructed from the preliminary design.

• A second prototype is evolved by a fourfold procedure:

1. evaluating the first prototype in terms of its strengths, weaknesses, and risks;
2. defining the requirements of the second prototype;
3. planning and designing the second prototype;
4. constructing and testing the second prototype.

WATERFALL SOFTWARE DEVELOPMENT

Waterfall Software Development

The waterfall model is a sequential design process comprised of the following steps, each of which must be completed before the next starts:

1. Design
2. Construction/implementation
3. Integration
4. Testing/debugging/validation)
5. Installation
6. Maintenance

XP

Extreme Programming

Extreme Programming (XP) is intended to improve software quality and responsiveness to changing customer requirements. by advocating frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Features are not added until they are actually needed. Extreme Programming also encourages programming in pairs, along with frequent communication between members of the development team, and between the developers and clients.

Lean

Lean development could be summarized by seven principles, very close in concept to lean manufacturing principles.
Everything not adding value to the customer is considered to be waste, including:

• unnecessary code and functionality
• delay in the software development process
• unclear requirements
• bureaucracy
• slow internal communication

In order to be able to eliminate waste, one should be able to recognize and see it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra processes and features not often used by customers are waste. Waiting for other activities, teams, processes is waste. Defects and lower quality are waste. Managerial overhead not producing real value is waste.

Scrum

Scrum is an iterative methodology used in agile software development.
During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog”, which is a prioritized set of high level requirements of work to be done. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

V-Model

V-Model

The V-model is a software development process which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

TDD

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.

Quality or Testing Standards

Please find the list of quality or testing standards:

1.	IEEE Standards - Institute of Electrical and Electronics Engineers  ISO Standards - International Standard Organization DOD Standards - Department Of Defence (USA) ANS Standards - American Nuclear Society standard ASTM Standards - American Society for Testing and Materials FIPS Standards - Federal Information Publication System CM Standards Software Configuration Management Standards BS Standards - British Standards NIST Standards - The National Institute for Standards and Technology