Monthly Archives: December 2012

ISO/IEC 12207:Software Life Cycle Process

What Is ISO?

Standards are documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose.

The International Organization for Standardization (ISO) is a worldwide federation of national standards bodies from some 100 countries, one from each country, and is a non-governmental organization established in 1947. Many people will have noticed a seeming lack of correspondence between the official title when used in full, International Organization for Standardization, and the short form, ISO. Shouldn’t the acronym be “IOS”? Yes, if it were an acronym – which it is not. International standardization began in the electrotechnical field. The International Electrotechnical Commission (IEC) was created in 1906.


ISO/IEC 12207 was published on 1 August 1995 and was the first International Standard to provide a comprehensive set of life cycle processes, activities and tasks for software that is part of a larger system, and for standalone software products and services. The ISO/IEC 12207 Amendments in 2002 and 2004 added process purpose and outcomes to the International Standard and established a Process Reference Model in accordance with the requirements of ISO/IEC 15504-2.

This International Standard can be used in one or more of the following modes:

  1. By an organization
  2. By a project
  3. By an acquirer and a supplier
  4. By organizations and assessors


The purpose of this International Standard is to provide a defined set of processes to facilitate communication among acquirers, suppliers and other stakeholders in the life cycle of a software product. This International Standard is written for acquirers of systems and software products and services and for suppliers, developers, operators, maintainers, managers, quality assurance managers, and users of software products. Limitation of this International Standard does not detail the life cycle processes in terms of methods or procedures required to meet the requirements and outcomes of a process. It does not provide documentation for that ISO/IEC 15289 is being used.

Application of this International Standard:

This clause presents an overview of the software life cycle processes that can be employed to acquire, supply, develop, operate, maintain, and dispose of software products and services. The objective is to provide a road map for the users of this International Standard so that they can orient themselves in it and apply it judiciously.

  1. Relationship between systems and software:

    As we know a software is a part of a system which performs some functions in that system. It is a fundamental premise of this standard that software always exists in the context of a system, even if the system consists of only the processor upon which the software is executed.

    This standard has a strong relationship with ISO/IEC 15288:2008, System Life Cycle Processes, and may be used in conjunction with it. In many cases, the processes of this International Standard directly correspond to processes of ISO/IEC 15288 but with some specialization for software products and services.

  2. Organizations and parties:

    An organization is a body of persons with identified responsibilities and authorities organized for some specific purpose, such as a club, union, corporation, or society. When an organization, as a whole or a part, enters into a contract, it is a party. Parties may be from the same organization or from separate organizations. An individual is an example of an organization, if the individual is assigned responsibilities and authorities.



Categories of Life Cycle Processes:

This International Standard groups the activities that may be performed during the life cycle of a software system into seven process groups. Each of the life cycle processes within those groups is described in terms of its purpose and desired outcomes and lists activities and tasks which need to be performed to achieve those outcomes.

a) Agreement Processes — two processes

b) Organizational Project-Enabling Processes — five processes

c) Project Processes — seven processes

d) Technical Processes — eleven processes

e) Software Implementation Processes — seven processes

f) Software Support Processes — eight processes

g) Software Reuse Processes — three processes

The purposes and outcomes of the life cycle processes constitute a Process Reference Model.

Summary of Life Cycle Processes:

There are two major sub-divisions of process in this International Standard. Clause 6 provides a system context for dealing with a standalone software product or service or a software system. Clause 7 contains the software-specific processes for use in implementing a software product or service that is an element of a larger system.

[A] System Context Processes:

6.1 Agreement Processes:

These processes define the activities necessary to establish an agreement between two organizations.

6.1.1 Acquisition Process:

The purpose of acquisition process is to obtain the product or service which satisfies the needs needed by acquirer- stakeholder that acquires or procures a product or service from a supplier. The process begins with the identification of customer needs and ends with the acceptance of the product and/or service needed by the acquirer.

The acquirer begins the acquisition process by describing a concept or a need to acquire, develop, or enhance a system, software product or software service, by defining and analyzing system requirements, by preparing acquisition plan. The acquisition documentation should include, as appropriate:

a) System requirements.

b) Scope statement.

c) Instructions for bidders.

d) List of software products.

e) Terms and conditions.

f) Control of subcontracts.

g) Technical constraints (e.g., target environment).

6.1.2 Supply Process:

The purpose of the Supply Process is to provide a product or service to the acquirer that meets the agreed requirements. Outcomes from this process are identification of acquirer for a product, response to the request of acquirer, based on agreed requirements product is delivered.

6.2 Organizational Project-Enabling Processes:

The Organizational Project-Enabling Processes manage the organization’s capability to acquire and supply products or services through the initiation, support and control of projects.

6.2.1 Life Cycle Model Management Process:

The purpose of the Life Cycle Model Management Process is to define, maintain, and assure availability of policies, life cycle processes, life cycle models, and procedures for use by the organization with respect to the scope of this International Standard.

Here in this process which life cycle model is to be used, which policies are best suitable for a software, responsibility for life cycle management are defined.

6.2.2 Infrastructure Management Process:

The purpose of the Infrastructure Management Process is to provide the enabling infrastructure and services to projects to support organization and project objectives throughout the life cycle. The infrastructure elements may include hardware, software, methods, tools, techniques, standards, and facilities for development, operation, or maintenance

6.2.3 Project Portfolio Management Process:

The purpose of the Project Portfolio Management Process is to initiate and sustain necessary, sufficient and suitable projects in order to meet the strategic objectives of the organization. Resources and budgets for each project are identified and allocated in this process

6.2.4 Human Resource Management Process:

The purpose of the Human Resource Management Process is to provide the organization with necessary human resources and to maintain their competencies, consistent with business needs. Human should be skilled enough to perform software life cycle processes to achieve organization.

6.2.5 Quality Management Process:

The purpose of the Quality Management Process is to assure that products, services and implementations of life cycle processes meet organizational quality objectives and achieve customer satisfaction. The organization shall establish quality management policies, standards and procedures, quality management goals

6.3 Project Processes:

In this International Standard, the project has been chosen as the context for describing processes concerned with planning, assessment and control. The principles related to these processes can be applied in any area of an organization’s management. There are two categories of Project Processes. The Project Management Processes are used to plan, execute, assess and control the progress of a project. The Project Support Processes support specialized management objectives.

Project management includes these two processes:

6.3.1 Project Planning Process:

The purpose of the Project Planning Process is to produce and communicate effective and workable project plans.

6.3.2Project Assessment and Control Process:

The purpose of the Project Assessment and Control Process is to determine the status of the project and ensure that the project performs according to plans and schedules, and within projected budgets, and that it satisfies technical objectives.

Project Support Processes includes following processes:

6.3.3 Decision Management Process:

The purpose of the Decision Management Process is to select the most beneficial course of project action where alternatives exist. A decision-making strategy, alternative and preferred course of action is defined during this process.

6.3.4 Risk Management Process:

The purpose of the Risk Management Process is to identify, analyze, treat and monitor the risks continuously

6.3.5 Configuration Management Process:

The purpose of the Configuration Management Process is to establish and maintain the integrity of all identified outputs of a project or process and make them available to concerned parties.

6.3.6 Information Management Process:

The purpose of the Information Management Process is to provide relevant, timely, complete, valid and, if required, confidential information to designated parties during and, as appropriate, after the system life cycle.

6.3.7 Measurement Process:

The purpose of the Measurement Process is to collect, analyze, and report data relating to the products developed and processes implemented within the organizational unit, to support effective management of the processes, and to objectively demonstrate the quality of the products.

6.4 Technical Processes:

The Technical Processes are used to define the requirements for a system, to transform the requirements into an effective product, to permit consistent reproduction of the product where necessary, to use the product, to provide the required services, to sustain the provision of those services and to dispose of the product when it is retired from service

6.4.1 Stakeholder Requirements Definition Process:

The purpose of the Stakeholder Requirements Definition Process is to define the requirements for a system that can provide the services needed by users and other stakeholders in a defined environment.

6.4.2 System Requirements Analysis Process:

The purpose of System Requirements Analysis is to transform the defined stakeholder requirements into a set of desired system technical requirements that will guide the design of the system.

6.4.3 System Architectural Design Process:

The purpose of the System Architectural Design Process is to identify which system requirements should be allocated to which elements of the system.

6.4.4 Implementation Process:

The purpose of the Implementation Process is to realize a specified system element.

6.4.5 System Integration Process:

The purpose of the System Integration Process is to integrate the system elements (including software items, hardware items, manual operations, and other systems, as necessary) to produce a complete system that will satisfy the system design and the customers’ expectations expressed in the system requirements.

6.4.6 System Qualification Testing Process:

The purpose of the Systems Qualification Testing Process is to ensure that the implementation of each system requirement is tested for compliance and that the system is ready for delivery.

6.4.7 Software Installation Process:

The purpose of the Software Installation Process is to install the software product that meets the agreed requirements in the target environment.

6.4.8 Software Acceptance Support Process:

The purpose of the Software Acceptance Support Process is to assist the acquirer to achieve confidence that the product meets requirements.

6.4.9 Software Operation Process:

The purpose of the Software Operation Process is to operate the software product in its intended environment and to provide support to the customers of the software product.

6.4.10 Software Maintenance Process:

The purpose of the Software Maintenance Process is to provide cost-effective support to a delivered software product.

6.4.11 Software Disposal Process:

The purpose of the Software Disposal Process is to end the existence of a system’s software entity. This process destroys or stores system software elements and related products in a sound manner, in accordance with legislation, agreements, organizational constraints and stakeholder requirements. Where required, it maintains records that may be monitored.

[B] Software Specific Process:

6.5 Software Implementation Processes:

The Software Implementation Processes are used to produce a specified system element (software item) implemented in software. Those processes transform specified behaviour, interfaces and implementation constraints into implementation actions resulting in a system element that satisfies the requirements derived from the system requirements

6.5.1 Software Implementation Process:

The purpose of the Software Implementation Process is to produce a specified system element implemented as a software product or service.

6.5.2 Software Requirements Analysis Process:

The purpose of Software Requirements Analysis Process is to establish the requirements of the software elements of the system.

6.5.3 Software Architectural Design Process:

The purpose of the Software Architectural Design Process is to provide a design for the software that implement and can be verified against the requirements.

6.5.4 Software Detailed Design Process:

The purpose of the Software Detailed Design Process is to provide a design for the software that implements and can be verified against the requirements and the software architecture and is sufficiently detailed to permit coding and testing.

6.5.5 Software Construction Process:

The purpose of the Software Construction Process is to produce executable software units that properly reflect the software design.

6.5.6 Software Integration Process:

The purpose of the Software Integration Process is to combine the software units and software components, producing integrated software items, consistent with the software design, that demonstrate that the functional and non-functional software requirements are satisfied on an equivalent or complete operational platform.

6.5.7 Software Qualification Testing Process:

The purpose of the Software Qualification Testing Process is to confirm that the integrated software product meets its defined requirements.

6.6 Software Support Processes:

The Software Support Processes provide a specific focused set of activities for performing a specialized software process. A supporting process assists the Software Implementation Process as an integral part with a distinct purpose, contributing to the success and quality of the software project. There are eight of these processes:

6.6.1 Software Documentation Management Process:

The purpose of the Software Documentation Management Process is to develop and maintain the recorded software information produced by a process.

6.6.2 Software Configuration Management Process:

The purpose of the Software Configuration Management Process is to establish and maintain the integrity of the software items of a process or project and make them available to concerned parties.

6.6.3 Software Quality Assurance Process:

The purpose of the Software Quality Assurance Process is to provide assurance that work products and processes comply with predefined provisions and plans.

6.6.4 Software Verification Process:

The purpose of the Software Verification Process is to confirm that each software work product and/or service of a process or project properly reflects the specified requirements.

6.6.5 Software Validation Process:

The purpose of the Software Validation Process is to confirm that the requirements for a specific intended use of the software work product are fulfilled.

6.6.6 Software Review Process:

The purpose of the Software Review Process is to maintain a common understanding with the stakeholders of the progress against the objectives of the agreement and what should be done to help ensure development of a product that satisfies the stakeholders. Software reviews are at both project management and technical levels and are held throughout the life of the project.

6.6.7 Software Audit Process:

The purpose of the Software Audit Process is to independently determine compliance of selected products and processes with the requirements, plans and agreement, as appropriate.

6.6.8 Software Problem Resolution Process:

The purpose of the Software Problem Resolution Process is to ensure that all discovered problems are identified, analyzed, managed and controlled to resolution.

6.7 Software Reuse Processes:

The Software Reuse Process Group consists of three processes that support an organization’s ability to reuse software items across project boundaries. These processes are unique because, by their nature, they operate outside the bounds of any particular project.

6.7.1 Domain Engineering Process:

The purpose of the Domain Engineering Process is to develop and maintain domain models, domain architectures and assets for the domain.

6.7.2 Reuse Asset Management Process:

The purpose of the Reuse Asset Management Process is to manage the life of reusable assets from conception to retirement.

6.7.3 Reuse Program Management Process:

The purpose of the Reuse Program Management Process is to plan, establish, manage, control, and monitor an organization’s reuse program and to systematically exploit reuse opportunities.

–>Current Existence of ISO 12207:

Software Engineering Process Technology (SEPT):

It is a firm specializing in meeting the software process standards information needs of the professional community, particularly concerning ISO/IEC 12207. SEPT was found in 1992 by stan magee CCP, the principle and president.[2]


[1] ISO/IEC 12207:2008(E) – IEEE std 12207-2008 paper



The  concept of scrum  was  first time introduced by  Jeff Sutherland

Scrum is an agile method designed to add energy,  focus,  clarity,   and transparency  to the project and implementation. because of this today we are using scrum,  in small,  mid size and large soft ware corporation in all the world.

Scrum is an inspect and adapt approach to continuous quality improvement to a business practices.

Actually scrum has emerged from a rough structure,  for iterative incremental development to a refined,  well structured straight forward framework for complex product development.

Scrum structure development is usually in terms of cycles of work known as sprints these cycles or iterations are less than or equal to one month in length and usually measured in weeks.  these sprints takes place one after the other, these sprints are completes irrespective of work has been completed or not and or never ended hence they are said to be time boxed .

At the beginning of each sprint   a functional team selects items from a list.

They will try to complete at the end of sprint and everyday there is a team meeting for re-planning the work to optimize.

At the end of the sprint they  send  whether customers requirement full filled or not.  and also includes feedback’s  from stake holders.



This is How Scrum Works

1)The product backlog

Here the scrum project is expressed in the product backlog

The product backlog is a optimized list of what’s required .

2) The  Sprint

Actually this sprint is usually four weeks in length .

The Sprints are of fixed duration and end on a specific date whether

the work has been completed or not  they are never extended.

3 )Sprint Planning

At the beginning of each Sprint,  the Sprint Planning Meeting takes

place.  The Product Owner and Scrum Team (with facilitation from

the Scrum Master) review the Product Backlog,  discuss the goals and

context for the items,  and the Scrum Team selects the items from the

Product Backlog to commit to complete by the end of the Sprint,

starting at the top of the Product Backlog.

Each item selected from the Product Backlog is designed and then

broken down to a set of individual tasks.  The list of tasks is recorded

in a document called the Sprint Backlog.

4 )Daily Scrum Meeting

This is short fifteen minute meeting that happens every work day at a specific time every one on the team should attend this meeting here the progress of the project is analyzed

This information may results in re-planning and further discussion.

5) Sprint Review and Retrospective

After the Sprint ends,  there is the Sprint Review,  where the Scrum team and stakeholder inspect what was done during the Sprint, discuss it,   and figure out what to do next ? .

Present at this meeting are the Product Owner,  Team Members,  and Scrum Master,  plus customers,   stakeholders,   experts,   executives,  and   anyone else interested.

Following the Sprint Review,  the team gets together for the Sprint

Retrospective which is an opportunity for the team to discuss what’s

working and what’s not working,  and agree on changes to try.

Edit This

Capability Maturity Model 1.1

CMM stands for Capability Maturity model. it is not just a tool for measuring where a company stands but it also acts as a guide on how to move up road. Whenever a new company is established it is at level one that is immature stage as it lacks in experience. Hence it is pone to make a lot of mistakes.

There is some similarity between CMM and a popular game “Need for speed Most wanted”. As the game requires us to fulfill certain criteria to move up the black list to complete the game. Similarity in CMM we are required to fulfill certain standard to move up a level.

There are five levels in CMM 1.1

1. initial (level1): In this kind of company the successful completion of the project depends on the individual efforts. This company dose not provide a stable environment for project development. The company dose not have process for management or engineering. Here the company employees think that the process, documentations, management are waste of time, money and man power. In this whenever a problem arises they drop whatever they planed for and jump to coding. This is also done whenever there tails are on fire (The dead lines are near).

2. Repeatable (level2): a company is rated as level 2 if a proper management is in place. Here the company has learned that without proper management project development is very hard and success rate is vary low. They try to repeat the success on the current project by repeating successful practices developed in earlier projects. Here the manager keeps track of cost, schedule,
the level 2 organizations can be called as disciplined because success in the previous project are repeated by the use of planning and tracking of project is stable.

3. Defined (level3): in this type of organizations proper documentation is done for both management process and engineering process. Here the software process are standardized. Here organization wide training program are conducted to ensure that the employees have the proper knowledge and skill to fulfill there roles in the organization.
In this level project forces the organization to make changes to the software process so that it meets the company needs. A defined software process contains a coherent, integrated set of well-defined software engineering and management processes. The software process capability of Level 3 organizations can be summarized as standard and consistent because both software engineering and management activities are stable and repeatable.

4. Managed (level4): here the organization sets some quality goals for both management and engineering process. Here the database is collected form the entire organization and analyzed for project defined process. Projects achieve control over their products and processes by narrowing the
variation in their process performance to fall within acceptable quantitative boundaries.
The software process capability of Level 4 organizations can be summarized as predictable because the process is measured and operates within measurable limits.

5. Optimizing (level5): at this level the entire organization is focused on improvement of the software process. Here the organization identifies its strengths and weakness innovative ideas are identified and shared through the organization. Software project teams in Level 5 organizations analyze defects to determine their causes. Software process are evaluated to identify defects and to stop them form being repeated. The software process capability of Level 5 organizations can be characterized as continuously improving because Level 5 organizations are continuously striving to improve the range of their process capability, thereby improving the process performance of their project.

The below diagram shows the CMM 1.1


The drawbacks of CMM are as follows
1. The CMM has no formal theoretical basis and in fact is based on the experience “of very knowledgeable people”.
2. The CMM does not have good empirical support and this same empirical support could also be construed to support other models.
3. The CMM ignores the importance of people involved with the software process by assuming that processes can somehow render individual excellence less important.
4. The CMM reveres the institutionalization of process for its own sake.
5. The CMM does not effectively describe any information on process dynamics, which confuses the study of the relationships between practices and levels within the CMM.
6. The CMM encourages the achievement of a higher maturity level in some cases by displacing the true mission, which is improving the process and overall software quality.



The People capability maturity(pcmm) model came into existence in the year 1995.

The main objective of this pcmm is to manage and develop the workforce of  organization. The workforce in the sense ,the level of knowledge and skills that are available for forming the organization.

Actually before this there was Capability Maturity Model(CMM) but it focused on the organization process.

Whereas this PCMM focus on the developing the organization workforce.

As CMM has five maturity levels, this PCMM also has five maturity levels.

So this each maturity level helps to improve the organizational workforce.

If the organization has more mature , then it has greater capability to develop,

Attract  and retain the talented  persons .

The five maturity levels are

1)Initial level

2)Managed level

3)Defined level

4)Predictable level

5)Optimizing level


it is the first maturity level, it is called  adhoc process. Here the organizational will perform things and tasks in random. So the organizational level will have some success and some failures.


It is the second maturity level. It mainly focuses on the managers to take

Responsibilities for managing and developing their people .

The workforce practices implemented in this level focus on activities at uinit level.


It is the third maturity level. Here it mainly focuses on developing its organization workforce. These workforce represent the critical pillars, in supporting the stratergic business plan.


It is the fourth maturity level, the workforce compentices that were created at the defined level will be managed at this level.


At optimizing level , the entire organizational is focused on the continual improvement of the workgroup and organizational capability.

unit 1 -FAKE RATIONAL PROCESS (anudeep)

This concept of Faking of rational process was first proposed by David  L Parnas and Paul C. Clements

The rational way of designing a software is impossible.One can try for rational way of developing software but to acheive it is impossible.There are reasons for inability to      develop a software using rational cannot be a perfect with his requirements to develop a software.

The below given are the 2 ways of approaching to develop a software



rational process: here every phase of software development is done in an rational way i.e   every phase of software development is done in an systematic way.

ideal process:here  every phase of software development is done by deriving and duplicating some of the earlier designed softwares

To become a perfect in developing a software using a rational way , it is required to know what is to be developed,what are the requirements to develop,how to implement the the various phases of software development.

Undoubtedly rational way of developing the software is better  But practically  it  is  impossible to meet the above criteria.we can develop the software  idealy  but  not  in  rational way.duplicating of rational process is not impossible but difficult  but mere getting of perfect rational way of developing software  is highly impossible and striving to acheive rational way of software development is useless




Alan j Perlis, the first Turing award winner for his work in the area of  advanced programming techniques.

He gave “Epigrams on programming” in 1982. These epigrams are basically one line description of his experience that he learned over the year of his work.

Some famous epigrams are :

 Syntactic sugar causes cancer of the semicolon

Syntactic sugar are constructs added to a language, to make it easier for programmers to read and write program code. But looking as a programmer it makes a language hard to learn.

For ex – using  a[i] instead of *(a+i) in c language is a syntactic sugar because it leads to confusion in programmer who doesn’t know what is really happening behind the scene. Actually it hides away a lot of the details of a program. When learning a new program knowing the basic is crucial.

This may be the reason why many language borrow the syntax from popular existing language. Because introducing a new syntactic sugar will lead to a new confusion.

Like c++ is syntactic sugar on C with OOP.

Everything should  be built  top-down,  except  the  first  time.

Consider an example, where in order to compute A , B should be computed first. Now if we follow top-down approach, A code will be written first with function call to B (not-yet-existing). But if we want to test during the whole development, then we would not able to test A , as B is not existing yet.

But if we do this other way around, means write B first, complete with unit test, after that code A and completes  it’s test. If B doesn’t produce the right answer, A won’t either (and thus not pass its Unit test), even though A might be correct.

This epigram is fairly attack on Top-down programming. As it is impossible to think purely top-down.

If a  listener nods  his  head when you’re explaining your program, wake  him  up.

Computer Programming is complex and hard! When you write a computer program, you have to get both the syntax and the semantics absolutely, 100% correct. It’s like writing a large novel in which there can be no spelling errors, no grammar errors. Even  single error can take days to get debugged.  May compiler shows error in line 10, but actual error may be in some other line.

So making someone understand your program by explaining is not going to help.  Even the person keep nodding his head to create an illusion that he is understanding everything, actually he is no more  concerned  about it and may just fall asleep.

So If a listener nods his head when you’re explaining your program, wake him up.



Unit 1: A Spiral Model of Software Development and Enhancement – kishore k

In software development process there was a need to maintain and follow a standard process to develop a software. people started to develop process model, winston W. Royce in the year 1970 came up with waterfall model.

The waterfall model served the purpose in the beginning but due to it’s linear design process failed to serve the purpose. In the year 1986 Barry Boehm came up with A Spiral Model of Software Development and Enhancement.

The spiral model is an iterative model for the software development process which added advantage through continuous refinement in software development phases like requirement phase, analysis phase, design phase and implementation.

Spiral model of software development establishes the transition criteria for progressing from one stage to the next with refinement on each iteration.

The radial dimension in Figure represents the cumulative cost incurred in accomplishing the steps to date; the angular dimension represents the progress made in completing each cycle of the spiral.


Each cycle of the spiral begins with the identification of  goal of portion of the product being elaborated,the alternative means of implementing this portion of the product and the constraints imposed on the application of the alternatives. Frequently this process with identify areas of uncertainly that are significant sources of project risk, once the risk is evaluated- the next step is determined by the relative remaining risks of the product development.

The risk-resolution activities done in the phase1 of spiral model includes surveys and analyses, including structured interviews of software developers and managers. plan in the next phase involves a partitioning into seperate activities to address managemnet improvements, facilities development and development of the  increments of a software development environment.

The key characteristic of a Spiral model is risk management at regular stages in the development cycle.

The Spiral is visualized as a process passing through some number of iterations, with the four quadrant diagram representative of the following activities:

  1. Formulate plans to: identify software targets, selected to implement the program, clarify the project development restrictions
  2. Risk analysis: an analytical assessment of selected programs, to consider how to identify and eliminate risk
  3. Implementation of the project: the implementation of software development and verification

Risk-driven spiral model, emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. However, the spiral model has some restrictive conditions, as follows:

  1. The spiral model emphasizes risk analysis, and thus requires customers to accept this analysis and act on it. This requires both trust in the developer as well as the willingness to spend more to fix the issues, which is the reason why this model is often used for large-scale internal software development.
  2. If the implementation of risk analysis will greatly affect the profits of the project, the spiral model should not be used.
  3. Software developers have to actively look for possible risks, and analyze it accurately for the spiral model to work.

The first stage is to formulate a plan to achieve the objectives with these constraints, and then strive to find and remove all potential risks through careful analysis and, if necessary, by constructing a prototype. If some risks can not be ruled out, the customer has to decide whether to terminate the project or to ignore the risks and continue anyway. Finally, the results are evaluated and the design of the next phase begins.

Spiral model has helped software engineers who can get there hands in and start working on project earlier. it is more able to cope with changes that software development entails. spiral model estimates to get more realistic as work progress. spiral model adds features in phases. product that is implemented using spiral model has increased it’s productivity to a larger extent.