1_software Development Process

SOFTWARE DEVELOPMENT PROCESS 1. Introduction

Computers are becoming a key element in our daily lives. Slowly and surely they are taking over many of the functions that affect our lives critically. They are now controlling all forms of monetary transactions, manufacturing, transportation, communication, defense systems, process control systems, and so on. In the near future, they will be found in our homes, controlling all forms of appliances. Left to themselves, they are harmless pieces of hardware. Load the right kind of software; they can take you to the moon, both literally and figuratively. It is the software that gives life to them. When they are going to play such a crucial role, one small flaw either in the hardware or the software can lead to catastrophic consequences. The sad part is, while there are well defined processes based on theoretical foundations to ensure the reliability of the hardware, same thing can not be said about software. There is no theory for software development as yet. But at the same time, it is mandatory that software always behaves in a predictable manner, even in unforeseen circumstances. Hence there is a need to control its development through a well defined and systematic process. The old fashioned 'code & test' approach will not do any more. It may be good enough for 'toy' problems, but in real life, software is expected to solve enormously complex problems. Some of the aspects of real life software projects are: •

Team effort: Any large development effort requires the services of a team of specialists. For example the team could consist of domain experts, software design experts, coding specialists, testing experts, hardware specialists, etc. Each group could concentrate on a specific aspect of the problem and design suitable solution. However no group can work in isolation. There will be constant interaction among team members.

•

Methodology: Broadly there are two types of methodologies, namely, 'procedure oriented methodolgies' and 'object oriented methodologies'. Though theoretically either of them could be used in any given problem situation, one of them should be chosen in advance.

•

Documentation: Clear and unambiguous documentation of the artifacts of the development process are critical for the success of the software project. Oral communication and 'back of the envelop designs' are not sufficient. For example, documentation is necessary if client signoff is required at various stages of the process. Once developed, the software lives for a long time. During its life, it has to undergo lot of changes. Without clear design specifications and well documented code, it will be impossible to make changes.

•

Planning: Since the development takes place against a client's requirements it is imperative that the whole effort is well planned to meet the schedule and cost constraints.

•

Quality assurance: Clients expect value for money. In addition to meeting the client's requirements, the software also should meet additional quality constraints. They could be in terms of performance, security, etc.

•

Lay user: Most of the time, these software packages will be used by noncomputer savvy users. Hence the software has to be highly robust.

•

Software tools: Documentation is important for the success of a software project, but it is a cumbersome task and many software practitioners balk at the prospect of documentation. There are tools known as Computer Aided Software

Engineering

(CASE)

tools

which

simplify

the

process

of

documentation. •

Conformance to standards: We need to follow certain standards to ensure clear and unambiguous documentation. For example, IEEE standards for requirements specifications, design, etc. Sometimes, clients may specify the standards to be used.

•

Reuse: The development effort can be optimised, by reusing well-tested components. For example, mathematical libraries, graphical user interface tool kits, EJBs, etc.

•

Non-developer

maintenance:

Software

lives

for

a

long

time.

The

development team, may not be available to maintain the package. Some other team will have to ensure that the software continues to provide services. •

Change management: Whenever a change has to be made, it is necessary to analyse its impact on various parts of the software. Imagine modifying the value of global variable. Every function that accesses the variable will be

effected. Unless care is taken to minimise the impact, the software may not behave as expected. •

Version control: Once changes are made to the software, it is important that the user gets the right copy of the software. In case of failures, it should be possible to roll back to the previous versions.

•

Subject to risks: Any large effort is subject to risks. The risks could be in terms of non-availability of skills, technology, inadequate resources, etc. It is necessary to constantly evaluate the risks, and put in place risk mitigation measures.

2. Software Quality The goal of any software development process is to produce high quality software. What is software quality? It has been variously defined as: •

Fitness for purpose

•

Zero defects

•

Conformability & dependability

•

The ability of the software to meet customer's stated and implied needs

Some of the important attributes that can be used to measure software quality are: •

Correctness: Software should meet the customer's needs

•

Robustness: Software must always behave in an expected manner, even when unexpected inputs are given

•

Usability: Ease of use. A software with a graphical user interface is considered more user-friendly than one without it

•

Portability: The ease with which software can be moved from one platform to another

•

Efficiency: Optimal resource (memory & execution time) utilization

•

Maintainability: Ease with which software can be modified

•

Reliability: The probability of the software giving consistent results over a period of time

•

Flexibility: Ease with which software can be adapted for use in different contexts

•

Security: Prevention of unauthorised access

•

Interoperabilty: The abilty of the software to integrate with existing systems

•

Performance: The ability of the software to deliver the outputs with in the given constraints like time, accuracy, memory usage

Correctness is the most important attribute. Every software must be correct. The other attributes may be present in varying degrees. For example, it is an expensive proposition to make a software 100% reliable and it is not required in all contexts. If the software is going to be used in life critical situations, then 100% reliability is mandatory. But, say, in a weather monitoring system, a little less reliability may be acceptable. However, the final decision lies with the client. One should keep in mind that some of the above attributes conflict with each other. For example, portability and efficiency could conflict with each other. To improve efficiency, one may resort to using system dependent features. but that will effect the portability. In the days, when DOS ruled the world, it was possible to access the internal architecture directly to improve performance. To port such a program to any other platform would require enormous changes. So in practice there will always be a tradeoff.

3.1 What is a Process? A Process is a series of definable, repeatable, and measurable tasks leading to a useful result. The benefits of a well defined process are numerous. •

It provides visibility into a project. Visibility in turn aids timely mid-course corrections

•

It helps developers to weed out faults at the point of introduction. This avoids cascading of faults into later phases

•

It helps to organize workflow and outputs to maximize resource utilization

•

It defines everybody's roles and responsibilities clearly.

•

Individual productivity increases due to specialization and at the same time the team's productivity increases due to coordination of activities

A good software development process should: •

view software development as a value added business activity and not merely as a technical activity

•

ensure that every product is checked to see if value addition has indeed taken place

•

safeguard against loss of value once the product is complete

•

provide management information for in-situ control of the process

To define such a process the following steps need to be followed: •

Identify the phases of development and the tasks to be carried out in each phase

•

Model the intra and inter phase transitions

•

Use techniques to carry out the tasks

•

Verify and Validate each task and the results

•

Exercise process and project management skills

The words 'verify' and 'validate' need some clarification. Verify means to check if the task has been executed correctly, while validate means to check if the correct task has been executed. In the context of software, the process of checking if an algorithm has been implemented correctly, is verification, while the process of checking if the result of the algorithm execution is the solution to the desired problem, is validation. The generic phases that are normally used in a software development process are: •

Analysis: In this phase user needs are gathered and converted into software requirements. For example, if the user need is to generate the trajectory of a missile, the software requirement is to solve the governing equations. This phase should answer the question: what is to be done to meet user needs?

•

Design: This phase answers the question: How to meet the user needs? With respect to the above example, design consists of deciding the algorithm to be used to solve the governing equations. The choice of the algorithm depends on design objectives like execution time, accuracy, etc. In this phase we determine organisation of various modules in the software system

•

Construction: Coding is the main activity in this phase

•

Testing: There are three categories of testing: unit testing, integration testing, and system testing. There are two types of testing: Black box testing and White box testing. Black box testing focuses on generating test cases

based on requirements. White box testing focuses on generating test cases based on the internal logic of various modules •

Implementation

4. Software Life Cycle Models In practice, two types of software life cycle models are used - sequential model and iterative model.

4.1 Waterfall Model: Sequential model, also known as water fall model, is pictorially shown thus:

It represents the development process as a sequence of steps (phases). It requires that a phase is complete before the next phase is started. Because of the explicit recognition of phases and sequencing, it helps in contract finalisation with reference to delivery and payment schedules. In practice it is difficult to use this model as it is, because of the uncertainity in the software requirements. It is often difficult to envisage all the requirements a priori. If a mistake in understanding the requirements gets detected during the coding phase, then the whole process has to be started all over again. A working version of the software will not be available until late in the project life cycle. So, iteration both within a phase and across phases is a necessity.

4.2 Prototyping Prototyping is discussed in the literature as a separate approach to software development. Prototyping as the name suggests, requires that a working version of the software is built early in the project life. There are two types of prototyping models, namely: •

Throw away prototype and

•

Evolutionary prototype

The objective of the throw away prototyping model is to understand the requirements and solution methodologies better. The essence is speed. Hence, an ad-hoc and quick development approach with no thought to quality, is resorted to. It is akin to 'code and test'. However, once the objective is met, the code is discarded and fresh development is started, ensuring that quality standards are met. Since the requirements are now well understood, one could use the sequential approach. This model suffers from wastage of effort, in the sense that developed code is discarded, because it does not meet the quality standards. Evolutionary prototyping takes a different approach. The requirements are prioritised and the code is developed for the most important requirements first, always with an eye on quality. Software is continuously refined and expanded with feedback from the client. The chief advantage of prototyping is that the client gets a feel of the product early in the project life cycle. As can be seen, evolutionary prototyping is an iterative model. Such a model can be characterised by doing a little analysis, design, code, test and repeat the process till the product is complete.

4.3 Spiral Model Barry Boehm has suggested another iteartive model called the spiral model. It is more in the nature of a framework, which needs to be adapted to specific projects. Pictorially it can be shown thus:

It allows best mix of other approaches and focusses on eliminating errors and unattractive alternatives early. An important feature of this model is the stress on risk analysis. Once the objectives, alternatives, and constraints for a phase are identified, the risks involved in carrying out the phase are evaluated, which is expected to result in a 'go, no go' decision. For evaluation purposes, one could use prototyping, simulations, etc. This model is best suited for projects, which involve new technology development. Risk analysis expertise is most critical for such projects.

4.4 ETVX model IBM introduced the ETVX model during the 80's to document their processes. 'E' stands for the entry criteria which must be satisfied before a set of tasks can be performed, 'T' is the set of tasks to be performed, 'V' stands for the verification & validation process to ensure that the right tasks are performed, and 'X' stands for the exit criteria or the outputs of the tasks. If an activity fails in the validation check, either corrective action is taken or a rework is ordered. It can be used in any development process. Each phase in the process can be considered as an activity and structured using the ETVX model. If required, the tasks can be further subdivided and each subtask can be further structured using the ETVX model.

4.5 Rational Unified Process Model Among the modern process models, Rational Unified Process (RUP) developed by Rational Corporation is noteworthy. It is an iterative model and captures many of the best practices of modern software development. RUP is explained more fully in the module OOAD with UML. More information on RUP can be obtained from http://en.wikipedia.org/wiki/Rational_Unified_Processand from http://www128.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIsthe RationalUnifiedProcessJan01.pdf

4.6 Agile Methodologies All the methodologies described before are based on the premise that any software development process should be predictable and repeatable. One of the criticisms against these methodologies is that there is more emphasis on following procedures and preparing documentation. They are considered to be heavyweight or rigorous. They are also criticised for their excessive emphasis on structure. There is a movement called Agile Software Movement, questioning this premise. The proponents argue that software development being essentially a human activity, there will always have variations in processes and inputs and the model should be flexible enough to handle the variations. For example: the entire set of software requirements cannot be known at the begining of the project nor do they remain static. If the model cannot handle this dynamism, then there can be lot of wastage of effort or the final product may not meet the customer's needs. Hence the agile methodolgies advocate the principle "build short, build often". That is the given project is broken up in to subprojects and each subproject is developed and integrated in to the already delivered system. This way the customer gets continuous

delivery of useful and usable systems. The subprojects are chosen so that they have short delivery cycles, usually of the order of 3 to 4 weeks. The development team also gets continuous feedback. A number of agile methodologies have been proposed. The more popular among them are SCRUM, DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM), CRYSTAL METHODS, FEATURE-DRIVEN DEVELOPMENT, LEAN DEVELOPMENT (LD), EXTREME PROGRAMMING (XP). A short description of each of these methods follows: •

SCRUM: It is a project management framework. It divides the development in to short cycles called sprint cycles in which a specified set of features are delivered. It advocates daily team meetings for coordination and integration. More information on SCRUM can be obtained http://www.controlchaos.com/

•

DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM): It is characterised by nine principles: 1. Active user involvement 2. Team empowerment 3. Frequent delivery of products 4. Fitness for business purpose 5. Iterative and incremental development 6. All changes during development are reversible 7. Baselining of requirements at a high level 8. Integrated testing 9. Collaboration and cooperation between stakeholders More information on DSDM can be obtained http://www.dsdm.org/

•

CRYSTAL METHODOLOGIES: They are a set of configurable methodologies. They focus on the people aspects of development. The configuration is carried out based on project size, criticality and objectives. Some of the names used for the methodologies are Clear, Yellow, Orange, Orange web, , Red , etc. More information can be obtained from http://crystalmethodologies.org/

•

FEATURE DRIVEN DEVELOPMENT (FDD): It is a short iteration framework for software development. It focuses on building an object model, build

feature list, plan by feature, design by feature, and build by feature. More informtion can be obtained from http://www.featuredrivendevelopment.com

•

LEAN DEVELOPMENT (LD): This methodology is derived from the principles of

lean

production,

the

restructuring

of

the

Japanese

automobile

manufacturing industry that occurred in the 1980s. It is based on the following principles of lean thinking: Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build the integrity in,

See

the whole.

More

informtion can

be

obtained

from

http://www.poppendieck.com/

•

EXTREME PROGRAMMING (XP): This methodology is probably the most popular among the agile methodologies. It is based on three important principles, viz., test first, continuous refactoring, and pair programming. More information can be obtained from http://www.extremeprogramming.org/

One of the important concepts popularised by XP is pair programming. Code is always developed in pairs. While one person is keying in the code, the other person would be reviewing. http://pairprogramming.com/ is dedicated to pair programming. The

paper

http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF

by Laurie

Williams et al., demonstrates the efficacy of pair programming. The site agilealliance.com is dedicated to promoting agile software development methodologies.

5. How to choose a process Among the plethora of available processes, how can we choose one? There is no single answer to this question. Probably the best way to attack this problem is to look at the software requirements. •

If they are stable and well understood, then waterfall model may be sufficient.

•

If they are stable, but not clear, then throw away prototyping can be used.

•

Where the requirements are changing, evolutionary prototyping is better.

•

If the requirements are coupled with the underlying business processes, which are going through a process of change, then a model based on Boehm's spiral model, like the Rational Unified Process should be used.

•

In these days of dynamic business environment, where 'time to market' is critical, and project size is relatively small, an agile process should be chosen.

These are but guidelines only. Many organisations choose a model and adapt it to their business requirements. For example, some organisations use waterfall model, modified to include iterations within phases.

6. Conclusions The most important take away from this module is that software development should follow a discplined process. The choice of the process should depend upon the stabilty of the requirements, completeness of requirements, underlying business processes, organisational structure, and the prevailing business environment.

7. References For Further Reading In addition to the links provided, the following references may be consulted:

1. " An Integrated Approach to Software Engineering", by Pankaj Jalote, Springer-Verlag

2. " Software Engineering: A Practitioner's Approach", by Roger S. Pressman, McGraw-Hill, Inc.

3. " Software Engineering", by Ian Sommerville, Addison-Wesley Publishing Company

4. " The Rational Unified Process, An Introduction", by Philippe Kruchten, Addison-Wesley Publishing Company

5. " Agile Software Develoment Ecosystems", by Jim Highsmith, Addison-Wesley Publishing Company