Spiral Process Model

A refined version of the spiral process model

A more refined version, the 'second generation' spiral process model, has six tasks regions, as given below.

• Customer communication
• Planning
• Risk analysis
• Engineering
• Integration support
• Customer evaluation

*Roll the mouse over the bulleted points above for a brief description of each.

The task regions executed in each iteration and the degree of execution depends on the requirements of the iteration. For example, if the first iteration is developing an analysis and design model, the task region for integration support is not relevant, and therefore, will be skipped.

Customizing the spiral process model
The spiral process model can be customized according to the existing requirements of the project.
Another process model can be embedded in the engineering task region during an iteration of the spiral process model. For example, during the first iteration of a project, when the requirements are unclear, the prototyping process model may be used in the 'engineering' task region. The prototype built is the output of that iteration. In the second iteration, when the requirements are clear, the linear sequential process model can be used in the engineering task region to build the product.
The task regions of the spiral model can also be customized based on what needs visibility and management focus
The spiral process model: A cinnamon roll
In his book, 'Rapid Development', while discussing how an iteration moves the project to a larger scale, Steve McConnell refers to the spiral process model as 'the cinnamon roll'.
He says, "You roll up one layer of the cinnamon roll, check to be sure that it is what you wanted, and then you begin on the next layer."
He also points out that each iteration of the spiral can be tailored to suit the needs of the project.
Benefits of the spiral process model

The spiral process model is very flexible and can be adapted for almost any type of project and product. The model has a number of variable components that can be selected suitably for such adaptation. These are as listed below.

• The number of iterations
• The task region definitions
• The tasks performed during a specific iteration
• The work products to be produced in an iteration
• The level of customer evaluation
• The timeline

The spiral process model is flexible because it allows modification of plans as the work progresses and when more is known about the product requirements.

Benefits of the spiral process model: An example
Consider a situation where an organization has launched a project to develop a new software product. The project manager is planning to use the spiral process model for development and has to decide the iterations to be performed.
One possible way of executing the project is by using two iterations of the spiral model. The first iteration can be used to create the concept paper of the system and the second iteration can be used to build the actual product.
The project can also be executed using more than two iterations. For example, the project manager may decide to have four iterations with the first one producing the concept paper, the next two releasing two versions of the prototype, and the last one leading to the creation of the final product.

Drawbacks of the spiral process model

Like all process models, the spiral model also has some drawbacks.
Some managers are not comfortable with the spiral model because they feel that if the model is used it will not be possible to fix a price and schedule for a project.

You can live in your own dream world and assume that the numbers that we generate here are going to remain stable and that we are going to meet those numbers, or you can be realistic and recognize that we are going to have to adjust those numbers as we learn more, collectively, you and I, as it were. That, however, is a major cultural shift. I'm not going to deny that, and some folks will struggle with this concept, and some organizations simply will not be able to accommodate it. Just intellectually, they won't be able to accommodate it.

Planning the iterations of the spiral process model

The spiral process model is iterative in nature. If the process model is not well managed, the iterations can go on indefinitely. To prevent such a situation, it is essential to plan each iteration and define the 'cut-offs' or 'outer limits' so that work progresses according to an overall schedule for delivery. The customer must be involved throughout the process, so that the subsequent iterations can be planned based on the customer feedback.
Although the spiral process model is not suitable for projects with a fixed price and schedule, these problems can be addressed through strong management support. The model is suitable for use only if the management, the project team, and the customer are agreeable to it.

Iterative risk analysis and planning

In an evolutionary process model, the requirements are not fully known at the beginning. Each iteration redefines the scope of the work and the risks associated with it. Therefore, the project plan for an evolutionary process model evolves as the project proceeds. The plan is prepared at the beginning of the project for the initial iteration. When the requirements are known in greater detail at the end of the iteration, the plan for the next iteration is prepared again. Also, the risks associated with the project keep changing; therefore, planning and risk analysis are repeated for each iteration.
In this model, it is not possible to develop fixed cost estimates and static schedules due to the uncertainties involved. However, the outer bounds to cost estimates and time schedules can be fixed.
The incremental process model
It is important to understand what an incremental process model is before we discuss the spiral process model (an example of the evolutionary model) because the two models are often confused with each other.
The incremental process model is used in situations in which the requirements are reasonably well understood, but it is not feasible to deliver the product within the desired time frame. This could be because of time pressure, limited resources, or other business constraints. It combines elements of linear sequential process model with the iterative philosophy of prototyping process model.
The primary objective of the incremental process model is to deliver various increments of the operational software product to the customer according to a planned set of iterations. Each increment aims to provide some useful functionality to the customer. The first increment is often the core product that addresses the basic requirements. In the subsequent increments, subsystems and other features are added to this core product.

An incremental process model involves the definition of increments and their sequence. Each increment delivers the software with some of the required functionalities. The sequence of the increments depends on the sequence in which the customer requires the functionalities.

The steps of an incremental process model are:

1.     Listen to the customer, and establish an incremental delivery strategy for the software product.

2.     Engineer or build increments of the product based on customer needs (for the increment to be delivered).

3.     Allow the customer to evaluate the increment and obtain feedback.

4.     Modify the existing increment based on customer feedback and specify the requirements for the next increment.

5.     Continue with step 2 to 4 until the final increment is delivered.

An example
Alpha Software Inc. is a software organization that specializes in office software. Based on a market survey, it has decided to develop an integrated voice-based word processor product for computers. The business plan demands early entry into the marketplace, with subsequent versions providing increased functionality and voice accuracy over a period of one year.
In this example, the full requirements of the product are reasonably well understood but the time-to-market pressure demands an early delivery. The approach chosen is, therefore, of an incremental process model. Each 'version' of the word processing software would represent one increment.
The spiral process model
The best-known evolutionary model is the spiral process model, proposed by Dr. Barry Boehm. The model is iterative, starting from the innermost point and proceeding radially outwards, with each circuit (cycle) around the spiral representing an iteration. Moving outwards on the spiral means moving towards more complete versions of the software product.
The set of tasks performed in each iteration is organized into 'task regions'. The spiral process model is divided into four task regions—planning, risk analysis, engineering, and customer evaluation.
Each iteration around the spiral can be considered a mini-project with tasks such as communication, planning, engineering, construction, validation, and customer assessment to be performed. The iteration ends with a decision on whether or not the next iteration should be performed.
The spiral process model: Task regions

The spiral model shown here is a 'first generation' evolutionary model and consists of four task regions. The tasks performed in each task region are as given below.

• In the planning task region the project plan (tasks, schedules, project framework, etc.) is established and the effort is estimated.
• In the risk analysis task region the potential risks are identified and analyzed.
• In the engineering task region the product is built using the required technical activities.
• In the customer evaluation task region feedback is obtained from the customer on the product, so that appropriate planning for the next iteration can be done.

The spiral process model: The planning task region
Planning is the first task region of the spiral process model. It involves obtaining preliminary information from the customer in the form of fundamental or baseline documentation. Formal meetings with the customer are used to derive the initial requirements. These form the basis for preparing the preliminary project plan, which includes the initial cost and schedule estimates.
A project using a spiral process model involves multiple iterations. The preliminary project plan also includes the projected number of iterations that the project may require.
The spiral process model: The risk analysis task region
The second task region of the spiral process model is the risk analysis task region. In this region, project risks are analyzed in a formal way. Analysis involves identification of the risks and a quantitative assessment of their probability and loss.
Risk analysis provides the information required to decide whether or not to proceed with the project. The risk analysis task region is followed by the 'go/no-go' axis, which is a decision point. If the risks are high, the decision may be 'not to proceed with the project in its current state'. In case of such decisions, the management needs to be involved.
Risk analysis and the subsequent decision on whether or not to proceed with the project are required because of the evolutionary nature of the project. The risks keep changing, and there is a need to understand the risks involved and whether they are worth taking.
The spiral process model: The engineering task region
The third task region of the spiral process model is the engineering task region.
Once the decision is taken to proceed with the project, the work product for the iteration is engineered.
In the engineering task region, activities that are required to build or modify one or more work products that the iteration has to produce are performed. For example, if the iteration has to produce an analysis model, the engineering task region of the iteration would include only analysis. On the other hand, if the end result of the iteration is a prototype, the engineering task region could involve prototyping.
The engineering task region could also incorporate a full life-cycle sequence of analysis-design-code-test and build a software product from a given set of requirements.
The spiral process model: The customer evaluation task region
The fourth task region of the spiral process model is the customer evaluation task region.
In this task region, the customer evaluates the output of the engineering task region and provides the feedback, which is used for planning the next iteration.
Customer involvement is ensured in each iteration of the customer evaluation task region. This provides control to the customer in the direction and implementation of the project. Besides, involvement in each iteration educates the customer and makes communication more effective.
The spiral process model: Steps in an iteration

Each iteration is one circuit around the spiral that results in an end product for evaluation. Every iteration comprises:

• Planning the iteration, including the estimation of the cost and the schedule. Customer feedback from the previous iteration, if any, is also taken into account
• Evaluating the risks to arrive at a 'go/no-go' decision
• Engineering or building the product based on the end product of the iteration
• Customer evaluating the end product built during the iteration

These iterations continue until either the final product is accepted or it is decided to stop further work on the product.

Evolutionary Process Models

Introduction

The competition in the area of information technology is so intense nowadays that it is necessary to use software process models that help to cope with the changing business requirements.
In most of the software development environments, it is not possible to know the complete set of requirements at the beginning of a project. This is because the requirements either keep evolving as software development proceeds, or the customers keep changing them.
There are various evolutionary process models designed to handle the development of evolving software products. One of the most important evolutionary process models is the spiral process model, which forms a good base for any evolutionary development approach. In this section, you will learn about the concept of evolutionary models with the help of the spiral process model as an example.
Software products often evolve
The business scenarios today are complex, and therefore, it may not be possible to know exactly what the software product should do before starting its development. Although the basic or core requirements may be known at the beginning of a project, the complete set of requirements evolves as the software product is developed. In such a case, a limited version of the software product is built based on the core requirements. This version of the product is put to use as soon as possible. The product then evolves through repeated iterations of development as the requirements become clearer.
In situations, such as given above, we need process models that help to understand the evolving product requirements.
Let us look at an example in which a software product is evolved.
Evolving software products: An example
Blue Valley Consulting has decided to develop a Web site to provide online personal counseling services to the lovelorn. It hopes to capture the attention of thousands of individuals who are facing relationship-based problems but are either too busy or too embarrassed to go to counselors.
Although the requirements for the Web site appear hazy at the moment, the concept seems to be promising. Many advertisers have already signed up and Blue Valley expects that the Web site if developed properly, will be a runaway success.
The organization needs to start the development of the Web site and make the initial product visible. This will help in obtaining funds from the investors for further research and refinement of the product.
This requires the use of a process model that works when the requirements of the Web site are not clearly specified in the beginning. Based on an initial version, the product (the Web site) is expected to evolve over time.
Evolutionary process models

An evolutionary process model is designed to accommodate iterative development of a software product. Iterations are required in case a product is evolving because the requirements get defined in more detail and may also change in subsequent iterations. Even in earlier iterations when the details are not known, some product, concept, or core functionality should be delivered.

In an evolutionary model, the following steps occur iteratively.

• Listening to the customer to understand the requirements for the software product
• Engineering, building, or modifying the software product based on the customer requirements (at the moment)
• Allowing the customer to evaluate the product and provide feedback and suggestions
• Iterating the above steps until an acceptable version of the software product is ready

Accommodating the changing requirements
An evolutionary process model has to accommodate the changing requirements of the evolving software products.
This means that in the evolutionary process model the detailed requirements get defined as the project proceeds. The level of detail increases from top-level specifications at the beginning of a project to more detailed levels as the project proceeds.
While the initial iterations may result in a high-level product such as a concept paper, the later iterations result in more detailed level products such as analysis, design, and the actual code.

The Prototyping Process Model

Introduction

Sometimes, customers find it difficult to visualize the product that they want. Because of this, they are either unable to give the complete specifications or keep changing them.
Software engineers also have a problem in eliciting the requirements from customers in such a situation. If persuaded, the customers may give some specifications; however, they may refuse to accept the end product if they feel it is not quite what they wanted.
In this section, you will learn about the prototyping process model. This model is often used when eliciting requirements is a problem because customers cannot visualize the product they want.

Eliciting requirements

Customers often find it difficult to specify a complete set of requirements in the beginning of a project. Some of the reasons for this are:

• The customer may have an incomplete understanding of what is required.
• The customer may not understand computers and software well enough to think of the features needed from the system.
• The customer may assume that all requirements are known clearly, though this may not be true.
• There may be more than one user, and all of them may not be available during the analysis, resulting in an incomplete understanding of requirements.
• The business requirements may change after the project has started, resulting in changes in the software requirements.

Building a prototype

One of the ways to help a customer specify what is needed, is building a prototype of the software system.
A prototype enables the customer to visualize the system and specify clearly what is needed. The analysts use a prototype to explain their understanding of the requirements. The customer can provide feedback on the prototype and the developers can use this feedback to modify the prototype. This can be done iteratively until a satisfactory prototype is made. The use of prototyping therefore helps in reducing the communication gap between customers and software engineers.
Let us now understand what a prototype is.

What is a prototype?

A prototype is a model of the salient features of a product. It helps in gathering and refining the product requirements.
For a software product, a prototype may help the customer understand the user interface of the system and how data will be gathered and presented.
It is important to note that the prototype is not the actual product. It may be nothing more than a shell or an external layer containing very little computing capability.

Steps in the prototyping process model

The prototyping process model evolved in the 1980s. It has the following six steps.
Step 1: The customer and the developer meet to define the basic requirements. These requirements are assumed to be incomplete but sufficient to build a prototype.
Step 2: The developer builds a prototype of the actual software product to give the customer a feel of the functionality of the product.
Step 3: The customer evaluates the prototype to check which features and functionalities meet the requirements, which are incomplete or inappropriate, and which are missing.
Step 4: The customer provides feedback to the developer based on the evaluation of the prototype.
Step 5: The developer refines the prototype based on the customer feedback by incorporating the changes suggested by the customer.
Step 6: The actual product is built after the prototype is found to be satisfactory by either extending the prototype into an operational product or 'throwing away' the prototype and rebuilding the product.

Note: Steps 3 through 5 are applied iteratively until the customer approves of the prototype.

Eliciting the requirements using the prototyping process model

Building a prototype is helpful because it gives customers a 'feel' of the software product and helps the developers to interact with the customers to understand their requirements in greater detail.
In order to assess the completeness of the product specifications, it is easier for customers to evaluate a tangible entity like the prototype instead of an abstraction, such as a requirements document. Therefore, the prototyping process model can work exceptionally well in situations where the customer does not have a full understanding of what is required.
The prototype forms the basis for detailed discussions with the customer. The interactions help both the developer and the customer to mutually understand the requirements and reduce the risk of a communication gap.
Let us now look at the focus of the prototyping process model

Focus of the prototyping process model

The focus of the prototyping process model is on the:

• Aspects of the system that will be visible to the customer
• Areas where the customer is not able to specify the requirements clearly
• Critical areas of the system that need to be evaluated and approved by the customer
• Algorithms or functions that represent significant technical risk

Building a prototype

A prototype is based on a 'quick' design and is built using simple tools (painted screens, fixed outputs), just like a model of a house is built using cardboard and poster colors.
The prototype can be built at a low cost in a short period of time. It helps in getting customer feedback before the actual product is built. By focusing on areas in which customer feedback is important, the risk of building a product that will not suit the customer is greatly reduced.
The technical methods used to build the prototype focus on 'rapid' construction. These methods do not focus on robustness and solid architecture.
Let us look at a scenario to understand how a prototype helps in specifying the requirements clearly.

Specifying the requirements

Consider the following scenario.
Chris, a customer representative, was very keen to have an elaborate input form with all types of complex data entry. A prototype of this input form was built.
While evaluating the prototype, Chris realized that the form appeared to be confusing, and it might become time-consuming for the data entry operators to enter the data. He discussed the form with the developers and finally decided on a two-level data entry form for clarity. This new scheme had a simple form for typical data and a complex form for the 5% cases in which the data was atypical.
This scenario given above shows that customers may over-specify or under-specify the requirements for the software product they want and later find the product inconvenient to use. In such cases, prototyping is helpful because after viewing the prototype of the final product, the customers are able to understand which features are suitable for actual use. This enables them to be clearer about their requirements and specify them appropriately.

Building the actual product

After the prototype is finally accepted, the actual product is built. There are two valid approaches for building the actual product depending on the project characteristics. These are:

• The throwaway prototype approach
• The evolutionary prototype approach

In the throwaway prototype approach, once the prototype is accepted, the actual product is built from scratch. The accepted prototype is used only to understand and model the requirements that the actual product has to conform to. The prototype as such is 'thrown away' or discarded.

In the evolutionary prototype approach, the prototype is used as the starting point to build the actual product. The product is built by extending and refining the prototype. As a result, the prototype is evolved into the final product.

Choosing the right approach

It is important that the choice of approach is made before the prototype is constructed because it affects the way the prototype is built.
If the throwaway prototype approach is used, the prototype is built using a quick and 'dirty' design. In such a case, the prototype is not based on a proper architecture because it is not worthwhile investing time and effort on designing a throwaway model. This prototype is eventually discarded because the software engineering principles are compromised in order to build the prototype quickly. Therefore, it is risky to extend the prototype into an operational product and the actual product is built afresh.
On the other hand, if the evolutionary prototype approach is used, considerable effort is spent in designing a robust architecture, because the same prototype is eventually evolved into the final product.

Benefits of using the prototyping process model

The prototyping process model is quite popular with both customers and developers. This is because the customer gets to see something tangible within a short period of time, while the developer gets to build something early in the process.
Let us hear why the prototyping model is so popular.

The customer loves this. The customer loves it because they are seeing the dynamic model of the system very early, they are playing with it, the thing looks real. Even though, in actuality, it is only a shell, so the customer loves this. The developers love this. They love it because they are down and dirty on the second day of the project. They are cranking out code on day two, and given that, they are happy they are producing something, and everybody seems to be happy, and yet I will argue prototyping is also (or can also be) problematic. Why?

Problems in using prototyping process model

The prototyping process model is quite useful. However, a problem associated with it is that customers do not understand what they see is only a mock-up or a prototype and not the actual product. They think that the product is almost ready and can be delivered fast.
Another problem with the prototyping process model is that the developers may be tempted to make the actual product by just patching or refining the prototype instead of building the product afresh. They may ignore the fact that the prototype has been built without a robust architecture and by compromising on software engineering principles.
Planning for the prototyping process model
In the prototyping process model, there is no inherent limit to the number of iterations that a prototype undergoes. Therefore, a potential problem is that it might get into repeated refinements and the prototype may not be 'frozen' or accepted. For this reason, project planning should specify a limit for the number of iterations, in consultation with the customer.

Software Model

A software process model is an abstract strategy that provides an approach for building and maintaining a software product. It helps the project management in planning and executing the project. A software process model defines:

• The phases (also called stages) of the software process: These are the major activities to be performed throughout the software process and are defined in terms of the input, the output, the functions to be performed, the work products, the quality checkpoints, etc.
• The sequence of the phases and their flow: This may Include iterations and overlaps of the phases.
• The management and technical tasks performed in each phase: These include scheduling and managing resources.

Over a period of time, several process models have evolved, each using a different approach and suitable in a particular context.

The importance of process models

In his paper, 'A Spiral Model of Software Development and Enhancement', Dr. Barry Boehm explains that a process model addresses the following questions in a software project.

• What shall we do next?
• How long shall we continue to do it?

The primary function of a process model is to determine the order of the stages involved in developing software and to establish the transition criteria for progressing from one stage to another. The process model provides guidance for the order in which the major tasks of the project should be performed.

Dr. Boehm cautions against confusing a process model with a software method, also called a methodology. Methodologies focus on how to navigate through each phase (such as determining the data and partitioning functions) and represent phase products (such as structure charts and state transition diagrams).

Types of process models

Many types of process models have evolved over the years. Although all the process models are used for building software products, they differ in the phases they have, the way these phases are sequenced and overlapped, and the tasks within each phase. Some examples of process models are the linear sequential, prototyping, and spiral models.
While software engineering provides a broad collection of practices, it does not prescribe a rigid approach for building a product.
It is necessary to select a suitable process model to build a software product. However, a project team may adapt or alter a process model to suit the needs of a specific project.

Adapting a process model

A process model can be adapted to suit the project characteristics, the skills of the people available, and the current business requirements. It is important to maintain the integrity of the engineering approach while adapting a process model to a particular project.
Many organizations define a common process framework (CPF) that projects can adapt to their specific needs. This includes all the framework activities and umbrella activities that are essential for building high-quality software. While adapting the CPF for a specific project, care is taken not to compromise on the engineering approach or eliminate any essential activity.
The establishment and use of a CPF is necessary for any organization that wants to use suitable processes for its projects and yet follow an engineering approach and achieve quality.

The linear sequential process model

After looking at what a process model is, let us look at the linear sequential process model as an example.
The linear sequential model evolved in the 1960s and 1970s based on the work done by the U.S. Department of Defense to define a systematic approach for building software.
The linear sequential model provides a simplistic view of software engineering to software developers and customers.
It is also called the 'classic model' or the 'waterfall model'.

The simplest form of the linear sequential model

Although there are many minor variations of the linear sequential model, let us discuss the simplest form of the model, which represents the minimum activities needed to develop a software product.
The linear sequential model, in its simplest form, consists of a set of major activities or phases arranged in a linear sequence. These phases—analysis, design, code, test—address the essential software engineering activities.
In this model, the essential steps that are required to build any software product are captured in the sequence of analysis-design-coding-testing. To build a product, we need to analyze what is required, design the product, build (or code) it, and then test it to check whether it meets the requirements.

Benefits of the linear sequential model

The linear sequential model became popular when it was introduced because of the following reasons.

• It is easy to understand and to explain.
• It identifies a predictable sequence of events.
• It provides a relatively easy means for assessing progress.
• It covers the essence of the engineering activities required to build the software product.

Any product to be built follows the inherent sequence of analysis-design-coding-testing. The analogy of building a house as discussed on the preceding pages, shows how this approach is applicable to areas other than software engineering and can be easily explained to a customer, a project sponsor, or any other person involved in the project. The approach is also useful because it explains the bare essential activities required for building any software product and places them in the correct sequence

Drawbacks of the linear sequential model

Although the linear sequential process model is simple, it has the following drawbacks.

• The requirements are expected to be specified clearly, correctly, and completely at the beginning of the project.
• Customer involvement is low—the customer is only involved during analysis and later when the system is ready to be delivered.
• Development is treated as a long, unidirectional pipeline of activities.
• Changes in requirements are difficult to incorporate in the product.
• Large systems take a long time to be completed.

One of the variations in the model allows iterations back to the previous phase. This provides flexibility and is an improvement on the simple version of the linear sequential process model we have discussed so far.

The Linear Sequential Process Model

Introduction:

To build any software product, we need a process model as a framework for performing all the software engineering activities. The process model guides the software project and is also called a 'life cycle model' or a 'software engineering paradigm'.
Many process models have evolved over time as a part of software engineering.
In this section, you will learn what a process model is by using the linear sequential process model as an example. This model is the earliest process model and the easiest to understand. It is also called the 'waterfall model' or the 'classic model'.

The process used to build software

The process used for building software is similar to any other process used for building a custom-made product, such as a house.
To construct a house we need to analyze what is needed, design the house, construct it, and check if the constructed house meets the requirements. Similarly, for building software we need to understand the customer requirements, design and construct the product, and finally test it.

The process layer of software engineering

To understand what a process model is, it is important to be familiar with the concept of the process layer of software engineering.
Software engineering, the discipline concerned with building software products, has the process layer as its foundation. The process layer provides the framework for all the development and management activities for building a software product. It acts as a harness for placing the technical methods required for engineering the software.
The definition of a process model is a part of this foundation. The process model spans the life cycle of a software product from its initiation, through implementation, support, and maintenance, until it is no longer in use. Therefore, it is also called a life cycle model or a software engineering paradigm

Software life cycle and development cycle

Let us now understand how the two terms related to software process model—software life cycle and software development life cycle—are defined.
IEEE 610.12-1990 defines a software life cycle as 'the period of time that begins when a software product is conceived and ends when the software product is no longer in use'.
It defines a software development cycle as 'the period of time that begins with the decision to develop a software product and ends when the software is delivered'.
These two definitions represent two views of the coverage for a software process model. One view is concerned only with the development activities ending with the delivery of the software to the customer. The other view also takes into account the support and maintenance activities performed after the software is released to the customer.

Software Engineering Layers

Introduction

Any technology product that is designed to meet the specific needs of customers must be 'engineered'. Hence, software too needs to be engineered to achieve its purpose.
This requires an approach that has to be suitable for software and its unique characteristics. To build high-quality software products, you need to understand what this approach involves.
In this section, you will learn about software engineering—the approach used to build software. You will also learn about the three layers of software engineering—process, methods, and tools.

Definitions of software engineering

Let us look at some accepted definitions of software engineering, to understand what it is.
Bauer provided one of the original definitions of software engineering in 1969. He looked at software engineering as an approach for economically building useful software by using sound engineering principles.
Bauer defines software engineering as "the in establishment and use of sound engineering principles order to obtain economically software that is reliable and works efficiently on real machines".
In his book, Software Engineering Economics, Dr. Barry Boehm talks of using science and mathematics for defining how software can be built. He defines software engineering as "the application of science and mathematics by which the capabilities of computer equipment are made useful to man via computer programs, procedures, and associated documentation".

A standard formal definition from IEEE Standard 610.12-1990 states that software engineering is:

1.     The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software

2.     The study of approaches as in (1)

The IEEE definition describes software engineering as a systematic approach covering the aspects of development, operation, and maintenance. This approach is disciplined and quantifiable.

The primary goal of software engineering

You have seen that all definitions of software engineering focus on using a systematic approach for building software.
The primary goal of software engineering is 'to build a high-quality product in a timely manner'. It aims to achieve this primary goal by using an 'engineering approach'.
Engineering involves a set of fundamental principles that should always be followed. These include explicit activities for understanding the problem and communicating with the customer, defined methods for representing a design, the best practices for implementing the solution, and sound strategy and tactics for testing. If the basic principles are followed, it results in technology products of high quality.

Software engineering as a collection of practices

To achieve the goal of building high-quality products within schedule, software engineering employs a set of practices to:

• Understand the problem
• Design a solution
• Implement the solution correctly
• Test the solution
• Manage the above activities to achieve high quality

Software engineering represents a formal process that incorporates a series of well-defined methods for the analysis, design, implementation, and testing of software and systems. In addition, it may encompass a broad array of project management methods and techniques for software quality assurance (SQA) and software configuration management (SCM).

Relevance of software engineering

Now that you understand what software engineering is, let us discuss its relevance in the present scenario.
Today, software products are built with a level of urgency that was not seen in previous years. The top priority for companies is to reduce the time-to-market, which in turn requires 'rapid development'.
Software engineering is perceived by some practitioners as being too formal, time-consuming, and structured for the flexibility required during development today. They argue that they cannot afford the formality of an engineering approach for building software because they need to develop products rapidly. People raising such objections view engineering as a static discipline that they think, cannot adapt to the changing needs of business and industry. The truth however is, software engineering is adaptive and is, therefore, relevant for anyone building a software product.
Software engineering is adaptive
Let us now look at the layers of software engineering.
Software engineering is an adaptive technology and not a fixed methodology. It is a philosophy that can be adapted and applied across all software development activities and application domains.
Software engineering provides a broad array of options that professionals can choose from to build high-quality products. However, there is no single engineering approach or a set of software engineering processes, methods or tools to build a software product.
The software engineering approach, including the processes, methods, and tools, can and should be adapted to the product, the people who build it, and the business environment.
Software professionals, therefore, should not be dogmatic about software engineering. It is not a religion and there are no absolutes
The layers of software engineering

A software engineering approach relies heavily on an organizational commitment to quality because it is not possible to incorporate software engineering in an organization that is not focused on achieving quality.

We can view software engineering as a set of layered components, with the foundation being the organization's quality approach, that is, its Total Quality Management (TQM) philosophy.

The layers resting on this foundation are:

• Process: A framework that helps the project manager control project management and engineering activities
• Methods: The technical activities required for the creation of work products
• Tools: The automated assistance for processes and methods

We will now discuss each of these layers in detail.

The process layer

The process layer defines the process that will be used to build the software and the activities and tasks that a project manager will have to manage. Therefore, it forms the basis for planning and managing all the project activities for building a product. The process layer is essentially the 'harness' into which we place the technology for building the software product.

The process layer:

• Enables the project manager to plan for the successful execution of the project
• Provides practitioners the context of their work

We can view all the activities, including the technical activities, as being part of the process. In addition, any resources, including tools, used for building the software also fit in the process. The process layer is, therefore, the foundation of software engineering and supports the methods and tools layers.
Importance of a process

A process is helpful because it provides clarity on how the work has to be performed. Any complex set of human activities can become chaotic if there is no guidance for the people performing the activities. A defined process answers the following questions:

• Who communicates with whom?
• How are inter-dependent activities coordinated?
• Who is responsible for what work?
• Who produces what work products, and how is each assessed for 'goodness'?

A process:

• Identifies all the software engineering activities and tasks
• Defines the flow of work among activities and tasks
• Identifies the work products that are produced
• Specifies the quality checkpoints that are required

A defined process
Some people view software development with a perspective that it requires artistic skill and craftsmanship and is inherently chaotic. They resist the idea of using a defined process because they view it as being cumbersome and bureaucratic, and therefore hindering creativity.
While there is no doubt that software development requires creativity, most of the quality software in the industry is produced by the coordinated effort of more than one person. For any team effort, coordinated control is a better alternative than anarchy. The road-map provided by a process is useful for people who build software products or manage projects.
All approaches to building software have a process, but in many cases, it is ad hoc, invisible, and chaotic. Good software engineering makes the software process more visible, predictable, and useful to those who build software.
Features of the process layer

The following features are included in the process layer.

• The common process framework (CPF)
• Software engineering activities and tasks
• Quality checkpoints
• Work product definitions
• Project management
• Software quality assurance (SQA)
• Software configuration management (SCM)
• Project monitoring
• Measurement and metrics

The methods layer
You have seen that the process layer identifies the engineering tasks that must be performed to build high-quality software.
The next layer, the methods layer focuses on the technical activities that must be performed to accomplish the engineering tasks. It provides the technical 'how to' and covers the fundamental engineering activities.
Building software involves performing a broad array of technical activities. The methods layer contains the methods defined to perform these activities effectively. It focuses on how the technical activities are to be performed. The practitioners use the methods to perform the fundamental engineering activities that are required to build the software.
Technical activities in the methods layer

Let us obtain an overview of the technical activities that are addressed by the methods layer. The fundamental technical activities required to build software are:

• Analysis: Analysis is the foundation of all engineering work that follows. During analysis, the model of what is required from the software is created.
• Design: Design activities follow analysis and translate the analysis model into how the product will provide this functionality through software.
• Code: Once the design is complete, coding translates the design model into an executable form.
• Test: The testing process helps to uncover errors in the code and the underlying design.

In addition, several umbrella or support activities are also performed as part of the software process.

Technical methods in the methods layer

For various process activities, the methods layer contains the corresponding set of technical methods to be used. These encompass a set of rules, the modes of graphical or text-based representation, and the related guidelines for assessing the quality of the information represented. Let us look at an example.

Consider the activity 'understand and describe a problem' that may be present in the process layer. For this, we need to define the technical methods for attributes such as:

• Communication with the customer
• Requirements elicitation
• Modeling
• Description of the data objects to be manipulated, the functionality to be delivered, and the system behavior

We may decide that the technical method we will use for analysis will be object-oriented analysis and that the specifications will be documented using the standard template of the organization.

Selecting a method
To define a methods layer, we need to select suitable methods from the wide range of available methods.
Consider the analysis and design activities. There is a wide variety of methods available for these, with exhaustive books written for each. The software project team should select the method that is most appropriate to the problem, the development environment, and the knowledge and background of the team members.
For example, analysis and design methods are used to produce models that represent the problem and the design. These models are depicted using text and graphics. Both the technical team and the customer should be able to understand and use the depiction. The models should also be usable as input for subsequent engineering activities. The methods selected, therefore, must provide a clear and concise engineering description of how the models will be created and depicted.
The tools layer

The tools layer provides support to the process and methods layers by focusing on the means that automate the various manual activities. Tools can be used for automating the following activities.

• Project management activities
• Technical methods used in software engineering
• General system support
• Framework for other tools

Automation helps remove the tedium from the work, reduces the chances of mistakes, and makes it easier to use good software engineering practices. When tools are used, documentation becomes an integral part of the work done instead of being an additional overhead activity. Hence, documentation does not have to be performed as a separate activity. Tools can be used for performing project management activities as well as technical activities.
Tools for various activities

Various tools can be used for performing project management and technical activities. The list of tools is as follows:

• Project management tools
• Change control tools
• Analysis and design tools
• Code generation tools
• Testing tools
• Re-engineering tools
• Documentation tools
• Repository support tools
• Prototyping tools

These tools support the process and methods layer in various activities.

Example of what a tool can do

Let us take an example of a project management tool. Some of the activities that can be performed by the tool include:

• The definition of resources
• The definition of tasks
• The allocation of resources to tasks
• The scheduling of tasks and milestones
• The tracking of actual versus scheduled tasks
• The depiction of tasks as a Gantt chart
• The generation of management reports based on the actual data. These reports may be a project summary, the critical tasks and milestones, the slipping tasks, the over-budgeted tasks, a list of over-allocated resources, and who does what and when.

Integrated tools
We have seen a list of the tools that are a part of the tools layer. The tools layer can also use integrated tools, that is, tools that function as an integrated set and use a common repository.
Integrated tools help to provide comprehensive support for development. They use a repository for storing all the software engineering work products, and this repository can be used by all the tools.
We can look at software engineering as a set of activities performed in a workshop called 'integrated project support environment (IPSE)' with the tools supporting it collectively called 'computer-aided software engineering (CASE)'. CASE can be a single tool supporting a specific activity or an integrated set of tools supporting a complex environment that includes software, hardware, and a software engineering database.