SOFTWARE PROCESSES

Introduction

Software process can be defined as a series of predictable steps that are followed in order to create high quality software. It can also be defined as the road map that you follow in order to create high quality software. It can also be defined as the framework for the tasks that are required to create high quality software .

3.1    Characterisation of Software Process

Software process can be characterised or classified as follows:

1. Common Process Framework:

This is a small number of framework activities that are applicable to all software projects, regardless of their size and complexity

• Task Sets:

Each task set is a number of software engineering work tasks, project milestones, work products, and quality assirance points

• Umbrella Activities

These are activities that are independent of any framework activity and they occur throughout the process. They include the following activities: software quality assurance, software configuration management and measurement.

3.2    Software Process Maturity Levels

These are the different levels of capabilities that an organisation can attain in the use of software engineering. Each software process maturity level is characterised based on the unique features of that level, as follows:

1. Level 1 (initial):

The software process is characterised as ad hoc, and occasionally chaotic. Few software processes are defined in this level and success of software project in any organisation that belongs to this level depends on individual effort.

• Level 2 (Repeatable):

Any organisation that belongs to this level in the use of software engineering in software project means that such organisation will use basic project management processes to track cost, schedule and functionality.

• Level 3 (Defined)

Any organisation that belongs to this level in the use of software engineering means that they document, standardize and integrate into its nationwide  software process for both management and software engineering. All project use documented and approved version of the organisation ‘s process for developing and supporting software.

• Level 4 (Managed)

Any organisation in this level performs detail measurement of software process and product quality. All the characteristics of level 3 are practiced in this level.

• Level 5 (Optimizing)

The level is characterised by continuous process improvement , which is enabled by quantitative feedback and testing of new ideas and technology.

3.2    Key Process Areas (KPAs)

These are those software engineering functions that must be present in order to satisfy good practice in each of the maturity levels, like software project planning, requirements management etc. Each Key Process Area (KPA) can be described using the following charactristics:

1. Goals

The overall objectives of the KPA

• Commitments

The requirements imposed on the organisation, which must be met in order to achieve the goals.

• Abilities

The organisational and technical things that must be in place in order to enable the organisation to meet the commitments.

• Activities

The specific tasks required in order to achieve the KPA function.

• Methods for monitoring implementation

The manner in which the activities are monitored as they are put into place.

• Method for verifying implementation

The manner in which proper practice for the KPA can be verified.

3.3    KPAs for the Various Process Maturity Levels

            The table below shows the various KPAs of the various software process maturity levels.

Levels	KPAs
1	None
2	Software configuration management, software quality assurance, software subcontract management, software project tracking and oversight, software project planning, requirement management
3	Peer reviews, intergroup coordination, software product engineering, integrated software management, training program, organisation process definition, organisation process focus
4	Software quality management, quantitative process management
5	Process change management, technology change management, defect prevention

•  
  • Key Practices and Key Indicators of KPAs

The key pratices of a KPA are the policies, procedures and activities that must be in place before a KPA can be fully instituted in any software project, while key indicators are those key practices that offer the greatest insight into wheather the goal of a KPA is achieved.

• Software Process Model

Software process model is also called software engineering paradigm, it is a development strategy that encompasses the process, methods and tools. The chosen software process model depends on the nature of the project and the application. The following are the various software process model:

• Linear Sequential Model

This software process model is also called classic life cycle or waterfall model. It is the oldest and most widely used software engineering paradigm. It is a systematic and sequential approach to software development. It begins at the system level and progresses through analysis, design, coding, testing and support. It consists of the following activities:

• System/Information engineering and modelling

This activity consists of requirement gathering at the system level with a small amount of top level design and analysis.

• Software requirement analysis

This activity intensifies information gathering with focus on the software. This activity will help the analyst to understand the nature of the program to be built, the information domain for the software, the required functions of the software, behaviour, performance and interface. This activity and system/information engineering and modelling form the detail analysis, as shown in figure 3.6.1, below.

• Design

The design activity translates requirements into a representation of the software that can be judged for quality, under the following four distinct attributes of the software:

• Data design: Representation that will be used to store the data requirement of the software.
• Architectural design: Representation that will be used to structure and organise the software.
• Human-computer interface design: Representation that will be used for data input and output.
• Algorithmic design: Representation that will be used to denote the steps that performs the software function.

• Code generation

                        This activity translates the design into computer readable form.

• Testing

Program testing commences as soon as the codes are generated. It focuses on the internal logic of the software and on the functional externals. The aim of program testing is to uncover errors and ensures that the defined inputs will produce the actual results that meet the required results.

• Support

This activity reapplies all the previous activities of the linear sequential model whenever there is need to change or modify the software due to change in user requirement or due to error.

Support

Analysis

Testing

Coding

Design

Figure 3.6.1 Activities of the linear sequential model.

Though the linear sequential model is the oldest and most widely used software engineering paradigm, its effectiveness has been questioned due to the following problems:

1          Real projects rarely follow sequential flow, which the linear sequential process model proposes.

2          Natural uncertainty exists in most real projects, therefore, it is difficult to state all the requirements at the beginning of the software project.

3          The working version of the software will not be available until late in the project time span, therefore a major blunder, if undetected until the working program is review can be disastrous.

4          The sequential nature of the linear sequential process model means that some team members must wait for other team members to finish dependent work. Time spent in waiting can exceed time spend in productive work. This is called blocked state.

• Prototyping Model

Due to the natural uncertainty that exists in most real project, the prototyping software process model is ideal in such situation. It begins with requirement gathering. Developer and customer meet to define the overall objective for the software and to identify known requirements and outline areas where further definition is necessary. Afterwards, a quick design occurs. The quick design focuses on representing the aspect of the software that will be visible to the customer/user, like the input and output design. The quick design leads to the construction of a prototype, which is a version of the actual software.

After evaluation by the customer/user, the prototype is used to refine the requirements of the software. The prototype, therefore serves as a representation for identifying software requirement. The first prototype (version) in most cases is not usable because it may be too big, too slow or awkward. The first version will be thrown away and a new version can be developed faster than the earlier prototype. The following are the disadvantages of this software process model:

• Customers can be discouraged when they realise that the prototype will be thrown away and another one built.
• Implementation compromises can be made by the developer in order to develop the prototype quickly.

• Rapid Application Development Model

The Rapid Application Development (RAD) software process model emphasises short software development cycle. It is a high speed adaptation of the linear sequential model. A fully functional system can be created within 90 days. It is ideal for software projects that can be modularized , so that each major module can be assigned to a separate RAD team, and each of the major modules completed between 60 and 90 days. It includes the following phases.

• Business modelling

This phase of the RAD process model models information flow among business functions, with the aim of answering the following question: What information drives the business process? What information is generated? Who generates the information? Where does the information go? Who processes the information?

• Data modelling

This phase of the RAD process model models the requirements of the business modelling phase into a set of data objects/entities that supports the business. This phase does that by identifying the attributes of each data object/entity, and the relationship between data objects/entities.

• Process modelling

This phase transforms the data entities/attributes into information flow, which implements a particular business function. It does this by using process description for adding, modifying, deleting, retrieving an instance of data object/entity.

• Application generation

This phase uses fourth generation application generators, rather than third generation programming language. The phase also uses existing program components to create reusable components.

• Testing and turnover

In this phase, the software is tested with the aim of identifying and correcting errors. However, testing is reduced since existing components that it uses have undergone testing, but new components must be tested.

                        The following are the disadvantages of this the RAD process model.

1. It requires sufficient human resources for large projects, because RAD teams must be created for each module of the software. This means high cost for hiring the required human resources.
2. It requires developers and customers that are committed to short development cycle. Sometimes it may not be easy to find them.
3. All software projects may not be ideal for the RAD software process model since all software projects may not easily be partitioned into modules.
4. When high technical risk are involved, it may not be an ideal process model to use.

• Evolutionary Software Process Model

This software process model is used to accommodate a product, like software, which evolves/metamorphoses over time. Computer software evolves over time because of the following reasons:

1. Business/product requirements changes during software development.
   1. Since tight market deadline can make completion of software impossible, therefore, limited version must be introduced to meet business pressure, while complete version can be delivered later.
   1. Uncertainty in the detail of business description.

Because of these reasons, software can change over time, the evolutionary process model is the ideal software process model to use in such situation. It is iterative, which enables developers to develop increasing more complete versions of the software. It consists of the following models:

1. Incremental Model

This evolutionary model combines sequential model with the prototyping philosophy. The linear sequential model is applied in a staggered fashion as software calendar progresses. Each linear sequential model produces a deliverable software product, called increment, which is always an improvement of the previous deliverable. The initial increment is usually the core product with the basic requirement.

Code

Design

Analysis

Test

Design

Analysis

Test

Code

Test

Code

Design

Analysis

Code

Design

Analysis

Test

                                                                              Initial increment

                                                                                          First increment

                                                                                                Second increment

                                                                                                           3^rd increment

                                                                  Calendar Time

Figure 3.6.4.1, Increament model

Therefore, the incremental model is iterative, incremental and useful when staffing is unavailable for full or complete implementation.

• Spiral Model

This is another evolutionary software process model, which combines prototyping principle with linear sequential model. It provides potential for rapid development of the increment versions of the software. It is divided into various framework activities called task regions, which consist of the following:

• Customer communication: This task is for effective communication between customer and developer.
• Planning: This task is for defining resources and timelines.
• Risk analysis: This task is for defining technical and managerial risks.
• Engineering: This task is for building one or more representations of the software.
• Construction and release: This task constructs, test, install and provide support.
• Customer evaluation: This task provides customer feedback based on the evaluation of software representations that were created during engineering.

This process model is ideal for large projects that can be broken into sub-projects.

Suppose a project consists of the following small projects:

1. Concept development project
2. New product development project
3. Product enhancement project
4. Product enhancement project

Figure 3.6.4.2 shows the spiral evolutional software process model.

• Win-win Spiral Model

This process model focuses on the customer communication activity of the spiral model. Ideally, in customer communication activity, developer ask question and customer provide the detail, but in reality, in win-win spiral model, customer and developers engage in negotiation. In the negotiation strive, the best negotiation is a win-win situation. Customers win by having a good number of requirement being implemented in the product, and developers also win by working under realistic and achievable budget and timeline.