What is a Software Process?
- a set of ordered tasks involving activities, constraints and resources that produce a software system
- a process is important because it imposes consistency and structure on a set of activities
- it guides our actions by allowing us to examine, understand, control and improve the activities that comprise the process
- the process of building a product is sometime called a lifecycle because it describes the life of that product from conception through to its implementation, delivery, use and maintenance
Software Process Models
- you need to model the process because:
- when a team writes down a description of its development process it forms a common understanding of the activities, resources and constraints involved in software development
- creating a process model helps the team find inconsistencies, redundancies and commissions in the process, as these problems are noted and corrected the process becomes more effective
- the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
- each development is different and a process has to be tailored for different situations, the model helps people to understand these differences.
Types of Software Process Models
- Waterfall model
- Prototyping models
- Evolutionary models
- The spiral model
- Formal development
- Incremental development
- Rapid Application Development
- Unified Process
- Agile Process
- Extreme Programming (XP)
1. Waterfall model
The waterfall model is a classical model used in system
development life cycle to create a system with a linear and sequential
approach. It is termed as waterfall because the model develops systematically
from one phase to another in a downward fashion. This model is divided into
different phases and the output of one phase is used as the input of the next
phase. Every phase has to be completed before the next phase starts and there
is no overlapping of the phases.
Separate and distinct phases of specification and
development
A linear sequential model
Waterfall model I
Software Requirement Analysis and Specification
The system’s services, constraints and goals are established
with the consultation with the users.
This would include the understanding of the information domain for the
software, functionality, behavior, performance, interface, security and
exceptional requirements. These requirements are then specified in a manner
which is understandable by both users and the development staff.
Software design
The design process translates requirements into a
representation of the software that can be implemented using software tools.
The major objectives of the design process are the identification of the
software components, the software architecture, interfaces, data structures and
algorithms.
Coding (implementation)
The design must be translated to a machine-readable
form. During this stage the software
design is realized as a set of programs or program units. Programming languages or CASE tools can be
used to develop software.
Testing
The testing process must ensure that the system works
correctly and satisfies the requirements specified. After testing, the software
system is delivered to the customer.
Maintenance
Software will undoubtedly undergo changes after it is
delivered to the customer. Errors in the system should corrected and the system
should be modified and updated to suit new user requirements.
Problems with the Waterfall Model
- Real
projects rarely follow the sequential flow that the model proposes.
Although the Waterfall model can accommodate iteration, it does so
indirectly.
- It is often very difficult for the
customer to state all requirements explicitly. The Waterfall model has the
difficulty of accommodating the natural uncertainty that exists at the
beginning of many projects.
- The customers must have patience. A
working version of the program(s) will not be available until late in the
project time-span. A major blunder,
if undetected until the working program is reviewed, can be disastrous.
Important Note:
The Water Fall model is suitable for projects which have clear and stable requirements.
2. Prototyping models
It is very difficult for end-users to anticipate how they
will use new software systems to support their work. If the system is large and
complex, it is probably impossible to make this assessment before the system is
built and put into use.
A prototype (a small version of the system) can be used to
clear the vague requirements. A
prototype should be evaluated with the user participation.
There are two types of Prototyping techniques
* Throw-away
Prototyping
* Evolutionary Prototyping
Throw-away Prototyping
The objective is to understand the system requirements
clearly. Starts with poorly understood requirements. Once the requirements are cleared,
the system will be developed from the beginning.
This model is suitable if the requirements are vague but
stable.
Problems with Throw-away Prototyping
- Important
features may have been left out of the prototype to simplify rapid
implementation. In fact, it may not be possible to prototype some of the
most important parts of the system such as safety-critical functions.
- An
implementation has no legal standing as a contract between customer and
contractor.
- Non-functional requirements such as those concerning reliability, robustness and safety cannot be adequately tested in a prototype implementation.
Click here to Continue to part 2
0 Comments
Post a Comment