ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 1

[Software Process Models]

Software Process Models

The module aims to introduce and enlighten the students to software

engineering topic which is software process activities and models.
Specifically to the students are expected to:
 define and explain software process activities;
 differentiate three generic process models;
 elucidate outline process models for requirements
engineering, software development, testing and evolution;
 discuss and determine software change management;
 identify modern process models appropriate for the project;
 expound the Rational Unified Process model.

Topic Coverage

 Process activities
 Generic Process models
 Coping with change
 Modern Process Models
 The Rational Unified Process
 Computer AIDED Software Engineering

Introduction
This module has been encompassed to distinguish different software development
processes and activities. In systems design and implementation an automated system –
software is indeed plays a vital role in the success of system implementation process.
Software Process
Let us first discuss process, when we provide a service or create a product we always
follow a sequence of steps to accomplish a set of tasks. You do not usually just do things
just to accomplish an output example: you don’t just put up the drywall before the wiring
for a house is installed or bake a cake before all the ingredients are mixed together. We
usually follow certain steps or procedures to produce an expected output, we can think of a
series of activities as a process.
Any process has the following characteristics: (a) it recommends all of the major activities
(b) it uses resources and produces intermediate and final products or output (c)it may
include sub-processes and has entry and exit criteria (d) the activities are organized in a
sequence (e) constrains or control may apply to activities (budget control, availability of

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 2
[Software Process Models]

resources). When the process involves the building of some product we refer to the process
as a life cycle Software development process – software life cycle. A structured set of
activities required to develop a software system such as specification, design, validation
and evolution. Somerville defined software process is a set of related activities that leads
to the production of a software product. These activities may involve the development of
software from scratch. However, business applications are not necessarily developed in
this way. It is most likely that IT Companies develop business software which is often
developed by extending and modifying existing systems or by configuring and integrating
off-the-shelf software or system components which was discuss in the previous module –
Software Sources.
These are the set of activities in software development or software processes:
1. Software specification: The functionality of the software and constraints on its
operation must be defined.
2. Software design and implementation: The software to meet the specification
must be produced.
3. Software validation: The software must be validated to ensure that it does what
the customer wants.
4. Software evolution: The software must evolve to meet changing customer needs.
These activities that are fundamental to software engineering. But in some form, these
activities are part of all software processes. In practice, of course, they are complex
activities in themselves and include sub-activities such as requirements validation,
architectural design, unit testing, etc. There are also supporting process activities such as
documentation and software configuration management. When we discuss processes, we
usually talk about the activities in these processes such as specifying a data model,
designing a user interface, etc., and the ordering of these activities. However, as well as
activities, process descriptions may also include: (a) products, which are the outcomes of a
process activity. For example, the out- come of the activity of architectural design may be a
model of the software architecture (b) roles, which reflect the responsibilities of the
people involved in the process. Examples of roles are project manager, configuration
manager, programmer, etc. (c) pre- and post-conditions, which are statements that are
true before and after a process activity has been enacted or a product produced.
Software processes most of the time are complex and, like all logical and creative
processes, rely on people making decisions and judgments. There is no ideal process and
most organizations have developed their own software development processes. Processes
have evolved to take advantage of the capabilities of the people in an organization and the
specific characteristics of the systems that are being developed. For some systems, such as
critical systems, a very structured development process is required. For business systems,
with rapidly changing requirements, a less formal, flexible process is likely to be more
effective.

In this moment we will discuss process activities in a more comprehensive manner

presenting different activities and phases.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 3
[Software Process Models]

Process Activities
The four basic process activities of specification, development, validation, and evolution are
organized differently in different development processes as mentioned before. In the
waterfall model, they are organized in sequence, whereas in incremental development they
are interleaved. The manner these activities are carried out depends on the type of
software, people, and organizational structures involved. In extreme programming, for
example, specifications are written on cards. Tests are executable and developed before the
program itself. Evolution may involve substantial system restructuring or refactoring.
Software Specification
Software specification or requirements engineering is the process of understanding and
defining what services are required from the system and identifying the constraints on the
system’s operation and development. Requirements engineering is a particularly critical
stage of the software process as errors at this stage inevitably lead to later problems in the
system design and implementation. The requirements engineering process as illustrated in

Fig. 6.1 aims to produce an agreed requirements document that specifies a system
satisfying stakeholder requirements. Requirements are usually presented at two levels of
detail. End-users and customers need a high-level statement of the requirements; system
developers need a more detailed system specification.

Fig. 6.1. The Requirements Engineering Process

Heads up!!

The following images has been grabbed from Software Engineering 7th Edition by Ian Somerville.

Ian Somerville is a prominent researcher in the field of systems engineering, system dependability and social
informatics, being an early advocate of an interdisciplinary approach to system dependability.

There are four main activities in the requirements engineering process:

1. Feasibility study
An estimate is made of whether the identified user needs may be satisfied using
current software and hardware technologies. The study considers whether the
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 4
[Software Process Models]

proposed system will be cost-effective from a business point of view and if it can
be developed within existing budgetary constraints. A feasibility study should be
relatively cheap and quick. The result should inform the decision of whether or
not to go ahead with a more detailed analysis.
2. Requirements elicitation and analysis
This is the process of deriving the system requirements through observation of
existing systems, discussions with potential users and procurers, task analysis,
and so on. This may involve the development of one or more system models and
prototypes. These help you understand the system to be specified.
3. Requirements specification
Requirements specification is the activity of translating the information gathered
during the analysis activity into a document that defines a set of requirements.
Two types of requirements may be included in this document. User
requirements are abstract statements of the system requirements for the
customer and end-user of the system; system requirements are a more detailed
description of the functionality to be provided.
4. Requirements validation
This activity checks the requirements for realism, consistency, and
completeness. During this process, errors in the requirements document are
inevitably discovered. It must then be modified to correct these problems.
Of course, the activities in the requirements process are not simply carried out in a strict
sequence. Requirements analysis continues during definition and specification and new
requirements come to light throughout the process. Therefore, the activities of analysis,
definition, and specification are interleaved.
The crucial part of this phase is understanding the business environment and its need.
Requirement discovery is vital, conducting rigorous fact finding techniques such interview,
observation, questionnaire etc.
Software Design and Implementation
The implementation stage of software development is the process of converting a system
specification into an executable system. It always involves processes of software design
and programming but, if an incremental approach to development is used, may also involve
refinement of the software specification.
A software design is a description of the structure of the software to be implemented, the
data models and structures used by the system, the interfaces between system components
and, sometimes, the algorithms used. Designers do not arrive at a finished design
immediately but develop the design iteratively. They add formality and detail as they
develop their design with constant backtracking to correct earlier designs.
As illustrated in Fig. 6.2 is an abstract model of this process showing the inputs to the
design process, process activities, and the documents produced as outputs from this
process.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 5
[Software Process Models]

Fig. 6.2. Software Design and Implementation

The figure suggests that the stages of the design process are sequential. In fact, design
process activities are interleaved. Feedback from one stage to another and consequent
design rework is inevitable in all design processes. Most software interfaces with other
software systems. These include the operating system, database, middleware, and other
application systems. These make up the software platform, the environment in which the
software will execute.
Information about this platform is an essential input to the design process, as designers
must decide how best to integrate it with the software’s environment. The requirements
specification is a description of the functionality the software must provide and its
performance and dependability requirements.
Fig. 6.2 shows four activities that may be part of the design process for information
systems:
1. Architectural design, where you identify the overall structure of the system, the
principal components (sometimes called sub-systems or modules), their
relationships, and how they are distributed.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 6
[Software Process Models]

2. Interface design, where you define the interfaces between system components.
This interface specification must be unambiguous. With a precise interface, a
component can be used without other components having to know how it is
implemented. Once interface specifications are agreed, the components can be
designed and developed concurrently.
3. Component design, where you take each system component and design how it
will operate. This may be a simple statement of the expected functionality to be
implemented, with the specific design left to the programmer. Alternatively, it may
be a list of changes to be made to a reusable component or a detailed design model.
The design model may be used to automatically generate an implementation.
4. Database design, where you design the system data structures and how these
are to be represented in a database. Again, the work here depends on whether an
existing database is to be reused or a new database is to be created.
The detail and representation of these vary considerably. For critical systems, detailed
design documents setting out precise and accurate descriptions of the system must be
produced. If a model-driven approach is used, these outputs may mostly be diagrams.
Where agile methods of development are used, the outputs of the design process may not
be separate specification documents but may be represented in the code of the program.
Structured methods for design were developed in the 1970s and 1980s and were the
precursor to the UML and object-oriented design (Budgen, 2003). They rely on producing
graphical models of the system and, in many cases, automatically generating code from
these models. Model-driven development (MDD) or model-driven engineering (Schmidt,
2006), where models of the software are created at different levels of abstraction, is an
evolution of structured methods. In MDD, there is greater emphasis on architectural
models with a separation between abstract implementation- independent models and
implementation-specific models.
Software development tools may be used to generate a skeleton program from a design.
This includes code to define and implement interfaces, and, in many cases, the developer
need only add details of the operation of each program component. Programming is a
personal activity and there is no general process that is usually followed. Some
programmers start with components that they understand, develop these, and then move
on to less-understood components. Others take the opposite approach, leaving familiar
components till last because they know how to develop them. Some developers like to
define data early in the process then use this to drive the program development; others
leave data unspecified for as long as possible.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 7
[Software Process Models]

Fig. 6.3. System Testing

Normally, programmers carry out some testing of the code they have developed. This often
reveals program defects that must be removed from the program. This is called debugging.
Defect testing and debugging are different processes. Testing establishes the existence of
defects. Debugging is concerned with locating and correcting these defects. When you are
debugging, you have to generate hypotheses about the observable behavior of the program
then test these hypotheses in the hope of finding the fault that caused the output anomaly.
Testing the hypotheses may involve tracing the program code manually. It may require
new test cases to localize the problem. Interactive debugging tools, which show the
intermediate values of program variables and a trace of the statements executed, may be
used to support the debugging process.
Software Validation
Software validation or, more generally, verification and validation also known as (V&V) is
intended to show that a system both conforms to its specification and that it meets the
expectations of the system customer. Program testing, where the system is executed using
simulated test data, is the principal validation technique. Validation may also involve
checking processes, such as inspections and reviews, at each stage of the software process
from user requirements definition to program development. Because of the predominance
of testing, the majority of validation costs are incurred during and after implementation.
Except for small programs, systems should not be tested as a single, monolithic unit.
The process is therefore an iterative one with information being fed back from later stages
to earlier parts of the process. The stages in the testing process are:
1. Development testing
The components making up the system are tested by the people developing the
system. Each component is tested independently, without other system
components. Components may be simple entities such as functions or object
classes, or may be coherent groupings of these entities. Test automation tools,
such as JUnit (Massol and Husted, 2003), that can re-run component tests when
new versions of the component are created, are commonly used.
2. System testing
System components are integrated to create a complete system. This process is
concerned with finding errors that result from unanticipated interactions
between components and component interface problems. It is also concerned
with showing that the system meets its functional and non-functional
requirements, and testing the emergent system properties. For large systems,
this may be a multi-stage process where components are integrated to form sub-
systems that are individually tested before these sub-systems are themselves
integrated to form the final system.
3. Acceptance testing
This is the final stage in the testing process before the system is accepted for
operational use. The system is tested with data supplied by the system customer
rather than with simulated test data. Acceptance testing may reveal errors and
omissions in the system requirements definition, because the real data exercise
the system in different ways from the test data. Acceptance testing may also
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 8
[Software Process Models]

reveal requirements problems where the system’s facilities do not really meet
the user’s needs or the system performance is unacceptable.
Normally, component development and testing processes are interleaved. Programmers
make up their own test data and incrementally test the code as it is developed. This is an
economically sensible approach, as the programmer knows the component and is therefore
the best person to generate test cases. If an incremental approach to development is used,
each increment should be tested as it is developed, with these tests based on the
requirements for that increment. In extreme programming, tests are developed along with
the requirements before development starts.
This helps the testers and developers to understand the requirements and ensures that
there are no delays as test cases are created. When a plan-driven software process is used
(e.g., for critical systems development), testing is driven by a set of test plans. An
independent team of testers works from these pre-formulated test plans, which have been
developed from the system specification and design. Fig. 6.4 illustrates how test plans are
the link between testing and development activities. Acceptance testing is sometimes called
‘alpha testing’. Custom systems are developed for a single client. The alpha testing process
continues until the system developer and the client agree that the delivered system is an
acceptable implementation of the requirements.

Fig. 6.4. Testing Phases in a Plan-Driven Software Process

Software Evolution
The flexibility of software systems is one of the main reasons why more and more software
is being incorporated in large, complex systems. Modification of a software product after
delivery to correct faults, to improve performance or other attributes, or to adapt the
product to a modified environment (IEEE 1219, 1993). Maintenance is seen as after-the-
fact activity and no integration with software development process in this definition.
Maintenance can be defined as after acceptance of the original product, all changes to the
software are considered part of the maintenance process. There are different types of
maintenance as enumerated below: (a) Correctives: removes residual faults with no change
in original specifications (b) Enhancement or Update: simply changes to the original
specifications and new developments (c) Perfectives: improves the performance of the
existing functionality (d) Adaptive: involves changes made when the product is a new
software environment.
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 9
[Software Process Models]

When we discuss about evolution CHANGE is expected.

Heads up!!

Software Engineering is the discipline of Software Development

Coping with Change

Change is inevitable in all large software projects, the system requirements change as the
business procuring the system responds to external pressures and management priorities
change. As new technologies become available, new design and implementation
possibilities emerge. Therefore whatever software process model is used, it is essential that
it can accommodate changes to the software being developed.

Fig. 6.4. Change Management

Change adds to the costs of software development because it usually means that work that
has been completed has to be redone. This is called rework. For example, if the
relationships between the requirements in a system have been analyzed and new
requirements are then identified, some or all of the requirements analysis has to be
repeated. It may then be necessary to redesign the system to deliver the new requirements,
change any programs that have been developed, and re-test the system. There are two
related approaches that may be used to reduce the costs of rework:
1. Change avoidance where the software process includes activities that can
anticipate possible changes before significant rework is required. For example, a
prototype system may be developed to show some key features of the system to
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 10
[Software Process Models]

customers. They can experiment with the prototype and refine their requirements
before committing to high software production costs.
2. Change tolerance where the process is designed so that changes can be
accommodated at relatively low cost. This normally involves some form of
incremental development. Proposed changes may be implemented in increments
that have not yet been developed. If this is impossible, then only a single increment
(a small part of the system) may have to be altered to incorporate the change.
In this section, we will discuss two ways of coping with change and changing system
requirements. These are: prototyping and incremental.
1. System prototyping where a version of the system or part of the system is
developed quickly to check the customer’s requirements and the feasibility of some
design decisions. This supports change avoidance as it allows users to experiment
with the system before delivery and so refine their requirements. The number of
requirements change proposals made after delivery is therefore likely to be
reduced.
2. Incremental delivery where system increments are delivered to the customer
for comment and experimentation. This supports both change avoidance and change
tolerance. It avoids the premature commitment to requirements for the whole
system and allows changes to be incorporated into later increments at relatively low
cost.
In this context software process model is introduce to streamline the software process in
which each model represents a process from a particular viewpoint, and thus provides only
partial information about that process.

Software Process Models

A software process model is an abstract representation of a process. It presents a
description of a process from some particular perspective. For example, a process activity
model shows the activities and their sequence but may not show the roles of the people
involved in these activities.

In this segment, we will discuss generic or classical process models sometimes called
process paradigms and present these from different perspective. From an architectural
perspective we will discuss the framework of the process but not the details of specific
activities. Also we will discuss its drawbacks and appropriateness for a certain project.

In the early days before the application of engineering in system development. Developers
tend to use “code and fix” method also known as cowboy coding characterized as anti-
pattern technique wherein the development is not done through a deliberate strategy or
methodology. It is often the result of schedule pressure on the software development team.
Also known as CABTAB “Code a bit and test a bit”. This traditional method has been
replaced by a more systematic and methodical approaches.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 11
[Software Process Models]

The process models that we cover here are: (1) waterfall model, separate and distinct
phases of specification and development (2) incremental development, developed as a
series of versions (increments), with each version adding functionality to the previous
version (3) reuse-oriented software engineering, approach is based on the existence of a
significant number of reusable components which process focuses on integrating these
components into a system rather than developing them from scratch.

These generic or classical model has been the basis of every model process models. These
models are not mutually exclusive and are often used together, especially for large systems
development. For large systems, it makes sense to combine some of the best features of the
waterfall and the incremental development models which leads to the development of
modern process models.

Heads Up!

The waterfall model was first defined by Winston W. Royce in 1970 and has been widely used for software
projects ever since.

Winston W. Royce is an American computer scientist, director at Lockheed Software Technology Center
in Austin, Texas. He was a pioneer in the field of software development.

Waterfall Model
It was the first Process Model to be introduced and the earliest SDLC approach that was
used for software development. Also, it is illustrates the software development process in a
linear sequential flow; hence it is also referred to as a linear-sequential life cycle model. This
means that any phase in the development process begins only if the previous phase is
complete. In waterfall model phases do not overlap. It is very simple to understand and use.
The whole process of software development is divided into separate phases as illustrated
in Figure 6.1. In a waterfall model, each phase must be completed before the next phase can
begin and there is no overlapping in the phases. In Waterfall model, typically, the outcome
of one phase acts as the input for the next phase sequentially.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 12
[Software Process Models]

Fig. 6.5 Waterfall Model

The waterfall model is an example of a plan-driven process—in principle, you must plan
and schedule all of the process activities before starting work on them.
The sequential phases in Waterfall model are:
 Requirement Definition: All possible requirements of the system to be
developed are captured in this phase and documented in a requirement
specification doc.
 System and Software Design: The requirement specifications from first phase
are studied in this phase and system design is prepared. System Design helps
in specifying hardware and system requirements and also helps in defining
overall system architecture.
 Implementation and Unit Testing: With inputs from system design, the
system is first developed in small programs called units, which are integrated
in the next phase. Each unit is developed and tested for its functionality which
is referred to as Unit Testing.
 Integration and System Testing: All the units developed in the
implementation phase are integrated into a system after testing of each unit.
Post integration the entire system is tested for any faults and failures.
 Operation and Maintenance: Once the functional and nonfunctional testing is
done, the product is deployed in the customer environment or released into
the market. There are some issues which come up in the client environment.
To fix those issues patches are released. Also to enhance the product some
better versions are released. Maintenance is done to deliver these changes in
the customer environment.
In principle, the result of each phase is one or more documents that are approved also
referred to as signing off. The following phase should not start until the previous phase
has finished. In practice, these stages overlap and feed information to each other. During
design, problems with requirements are identified. During coding, design problems are
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 13
[Software Process Models]

found and so on. On this event, problems and its drawbacks arise such as inflexible
partitioning of the project into distinct stages and it is difficult to respond to
changing customer requirements therefore, model is only appropriate when the
requirements are well-understood. Which suggests to the specific waterfall model
application in which the model is most appropriate to situation such as: (a)
requirements are very well documented, clear and fixed (b) product definition is stable
(c) technology is understood and is not dynamic (d) there are no ambiguous
requirements (e) ample resources with required expertise are available to support the
product (f) the project is short.
The waterfall model is consistent with other engineering process models and
documentation is produced at each phase. This makes the process visible so managers
can monitor progress against the development plan. Which leads to its primary
advantage of the model which allows for departmentalization and control. Also, schedule
can be set with deadlines for each stage of development and a product can proceed
through the development process model phases one by one. In addition to this,
development moves from concept, through design, implementation, testing, installation,
troubleshooting, and ends up at operation and maintenance. Each phase of development
proceeds in strict order. However as the primary problem presented the model has its
own disadvantage which is that it does not allow for much reflection or revision. Once an
application is in the testing stage, it is very difficult to go back and change something
that was not well-documented or thought upon in the concept stage.

Tips Up!

Why NOT a Waterfall Model?

 No fabrication step
 No body of experience for design analysis (yet)
 Waterfall model takes a static view of requirements
 Unrealistic separation of specification from the design
 Doesn’t accommodate prototyping, reuse, etc

The table below presents the pros and cons of waterfall model which might help the
students to decide whether which process model to use.
Table 6.1
Pros and Cons of Waterfall Model

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 14
[Software Process Models]

Pros Cons

 Simple and easy to understand and use  No working software is produced until late
 Easy to manage due to the rigidity of during the life cycle.
the model. Each phase has specific  High amounts of risk and uncertainty.
deliverables and a review process.  Not a good model for complex and object-
 Phases are processed and completed oriented projects.
one at a time.  Poor model for long and ongoing projects.
 Works well for smaller projects where  Not suitable for the projects where
requirements are very well requirements are at a moderate to high risk
understood. of changing. So risk and uncertainty is high
 Clearly defined stages. with this process model.
 Well understood milestones.  It is difficult to measure progress within
 Easy to arrange tasks. stages.
 Process and results are well  Cannot accommodate changing
documented. requirements.
 Adjusting scope during the life cycle can
end a project.
 Integration is done as a "big-bang. At the
very end, which doesn't allow identifying
any technological or business bottleneck or
challenges early.

Table Source: https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

Principles of Waterfall
 It is a series of steps.
 Each step is user defined.
 Each step creates a definite product.
 Each product forms the basis for the next step.
 The correctness of each step can be checked.
Verification – are we building the right product?
Validation – are we building the product right?
Strengths of Waterfall Model
 It divides a complete task into smaller more manageable task.
 Each task produces a user-defined deliverables.
Drawback of Waterfall Model
 During coding an error in the design (previous stage) is discovered.
 During unit testing design fault is revealed.

In response to the perceived problems and criticisms with the waterfall model,
many modified waterfall models have been introduced.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 15
[Software Process Models]

The Modified Waterfall coined as MWF provides an orderly sequence of development

steps with some flexible iterative stages to facilitate the adequacy of documentation and
design reviews to ensure the quality, reliability, and maintainability of the developed
custom software. The MWF method is the preferred method of choice for highly complex
and technology intensive custom software development project initiatives.
Nevertheless, the model has a few critical principles of a good methodology:
 Work is done in stages primarily in sequence with some minor iterations,
 Content reviews are conducted between certain stages, and
 Reviews represent quality gates, check-points, and decision points for
continuing to the next phase.
The modified waterfall provides an orderly sequence of development steps with some
flexible iterative stages to facilitate the adequacy of documentation and design reviews to
ensure the quality, reliability, and maintainability of the developed custom software. The
MWF method is the preferred method of choice for highly complex and technology
intensive custom software development project initiatives.

Heads Up!

The waterfall model was also refined using mathematical transformations that preserve its consistency into
executable code.

Formal development processes, such as that based on the B method (Schneider, 2001; Wordsworth, 1996)
are particularly suited to the development of systems that have stringent safety, reliability, or security
requirements.

Incremental development
Incremental development is based on the idea of developing an initial implementation,
exposing this to user comment and evolving it through several versions until an adequate
system has been developed as illustrated in Fig. 6.6. Specification, development, and
validation activities are interleaved rather than separate, with rapid feedback across
activities. Phases are divided up into smaller, more easily managed modules. Each module
passes through the requirements, design, implementation and testing phases. A working
version of software is produced during the first module, so you have working software
early on during the software life cycle. Each subsequent release of the module adds
function to the previous release. The process continues till the complete system is achieved.
Incremental software development, which is a fundamental part of agile approaches, is
better than a waterfall approach for most business, e-commerce, and personal systems. It
promotes customer focus development that each and every phase allows intervention or
input with the customer making the project progress or increment in the development.
Generally, the early increments of the system include the most important or most urgently
required functionality. Customer focused development makes it possible to make it a clear
functional and efficient software development.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 16
[Software Process Models]

Fig. 6.6 Incremental Development

According to Somerville incremental development has three important benefits, compared

to the waterfall model:
1. The cost of accommodating changing customer requirements is reduced.
The amount of analysis and documentation that has to be redone is much less
than is required with the waterfall model.
2. It is easier to get customer feedback on the development work that has
been done. Customers can comment on demonstrations of the software and
see how much has been implemented. Customers find it difficult to judge
progress from software design documents.
3. More rapid delivery and deployment of useful software to the customer
is possible, even if all of the functionality has not been included. Customers
are able to use and gain value from the software earlier than is possible with
a waterfall process.
Incremental development in some form is now the most common approach for the
development of application systems. This approach can be either plan-driven, agile, or,
more usually, a mixture of these approaches. In a plan-driven approach, the system
increments are identified in advance; if an agile approach is adopted, the early increments
are identified but the development of later increments depends on progress and customer
priorities.
As enumerated by Somerville from a management perspective, the incremental approach
has two problems:
1. The process is not visible. Managers need regular deliverables to measure
progress. If systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
2. System structure tends to degrade as new increments are added. Unless
time and money is spent on refactoring to improve the software, regular

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 17
[Software Process Models]

change tends to corrupt its structure. Incorporating further software changes

becomes increasingly difficult and costly.
The problems of incremental development become particularly acute for large, complex,
long-lifetime systems, where different teams develop different parts of the system. Large
systems need a stable framework or architecture and the responsibilities of the different
teams working on parts of the system need to be clearly defined with respect to that
architecture. This has to be planned in advance rather than developed incrementally. You
can develop a system incrementally and expose it to customers for comment, without
actually delivering it and deploying it in the customer’s environment. Incremental delivery
and deployment means that the software is used in real, operational processes. This is now
always possible as experimenting with new software can disrupt normal business
processes. The advantages and disadvantages of incremental delivery are enumerated
below:
Advantages:
 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled during it
would iteration.

Disadvantages:
 Needs good planning and design.
 Needs a clear and complete definition of the whole system before it can be broken
down and built incrementally.
 Total cost is higher than waterfall.

When to use the Incremental model:

 This model can be used when the requirements of the complete system are clearly
defined and understood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.

Reuse-oriented software engineering

The reuse-oriented model, also called reuse-oriented development (ROD), is a method
of software development in which a program is refined by producing a sequence of
prototypes called models, each of which is automatically derived from the preceding one
according to a sequence of defined rules. The reuse-oriented model can reduce the overall
cost of software development compared with more tedious manual methods. It can also
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 18
[Software Process Models]

save time because each phase of the process builds on the previous phase which has
already been refined. When carefully carried out, ROD can minimize the likelihood of errors
or bugs making their way into the final product.
The reuse-oriented model is not always practical in its pure form because a full repertoire
of reusable components may not be available. In such instances, some new program
components must be designed. If not thoughtfully done, ROD can lead to compromises in
perceived requirements, resulting in a product that does not fully meet the needs of its
intended users.
Reuse-oriented approaches rely on a large base of reusable software components and an
integrating framework for the composition of these components. Sometimes, these
components are systems in their own right (COTS or commercial off-the-shelf systems)
that may provide specific functionality such as word processing or a spreadsheet.

Fig. 6.7 Reuse-oriented software engineering

A general process model for reuse-based development is shown in Figure 6.7. Although the
initial requirements specification stage and the validation stage are comparable with other
software processes, the intermediate stages in a reuse- oriented process are different.
These stages are:
1. Component analysis
Given the requirements specification, a search is made for components to
implement that specification. Usually, there is no exact match and the
components that may be used only provide some of the functionality
required.
2. Requirements modification
During this stage, the requirements are analyzed using information about the
components that have been discovered. They are then modified to reflect the
available components. Where modifications are impossible, the component
analysis activity may be re-entered to search for alternative solutions.
3. System design with reuse
During this phase, the framework of the system is designed or an existing
framework is reused. The designers take into account the components that
are reused and organize the framework to cater for this. Some new software
may have to be designed if reusable components are not available.
4. Development and integration
Software that cannot be externally procured is developed, and the
components and COTS systems are integrated to create the new system.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 19
[Software Process Models]

System integration, in this model, may be part of the development process

rather than a separate activity.
There are three types of software component that may be used in a reuse-oriented process:
1. Web services that are developed according to service standards and which
are available for remote invocation.
2. Collections of objects that are developed as a package to be integrated with a
component framework such as .NET or J2EE.
3. Stand-alone software systems that are configured for use in a particular
environment.
Advantages:
 Reducing the amount of software to be developed
 Reducing costs and risks
 Faster software delivery
Disadvantages:
 Requirements compromises are inevitable and this may lead to a system that
does not meet the real needs of users
 Control over the system evolution is lost as new versions of the reusable
components are not under the control of the organization using them

The three generic process models has been the basis in the development of software.
However due to software flexibility and business needs variance modern process model
has been introduce. The modern process models has been used by developers based on the
system development situations and the project needs. These models a most likely the
combination and best practices adapted from the generic process models.

Modern Process Models

Prototyping

Fig. 6.8. The Process of Prototype Development

A prototype is an initial version of a software system that is used to demonstrate concepts,

try out design options, and find out more about the problem and its possible solutions.
Rapid, iterative development of the prototype is essential so that costs are controlled and
system stakeholders can experiment with the prototype early in the software process. A

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 20
[Software Process Models]

software prototype can be used in a software development process to help anticipate

changes that may be required:
1. In the requirements engineering process, a prototype can help with the elicitation
and validation of system requirements.
2. In the system design process, a prototype can be used to explore particular soft-
ware solutions and to support user interface design.

Objectives of Prototyping
 to demonstrate the usefulness of the application to management
 user training, a prototype system can be used for training users before the final
system has been delivered
 to established that some new technology will provide activities needed.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 21
[Software Process Models]

Two Types of Prototyping

1. Throwaway – the final system is implemented in some different way. The stages of
throwaway prototyping are enumerated below:
 Outline Specification: contains area of uncertainty
 Establishes of Objectives: objective maybe develop in system to prototype
the user’s interface.
 Selections of Functions: to decide what to put into and which to leave out in
the prototype.
 Prototype Construction: speed and cost of construction
 Evaluation: inconsistencies and short comings in the developer’s perception
of the customer requirements are uncovered.
 Iteration: Refinement rapidly modified
 Completion – Specification to meet the users’ requirements.
2. Evolutionary – prototype becomes the final system. The stages of evolutionary
prototyping are enumerated below:
 Requirements Definition: Initial Specification thorough analysis stage,
creating initial specification.
 Prototype Construction: a prototype is built in a quality manner including
design, documentation, and thorough verification.
 Evaluation: Check with the User prototype serves as a communication
medium, which enables the developer and customer to communicate with
each other.
 Iteration: Define the Prototype evaluation is carried and repeatedly until the
prototype meets the objective.
As defined prototyping is the process of quickly putting together a working model. A
prototype in order to use various aspects, illustrate ideas of features and gather early user
feedback. These are the advantages and disadvantages of prototyping.

Advantages:
 Many provide the proof of concept to attract funding.
 Early visibility of the prototype gave user ideas of what the final system looks
like.
 Encourage active participation among users and producer.
 Last effectiveness
 Increases system development speed.
 Assist to identifying any problems with the efficiency of earlier design
requirements analysis and coding activities.
 Helps to refine potential risks associated with the delivery of the system
being develop.
Disadvantages:
 Possibility of causing system to be kept unfinished
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 22
[Software Process Models]

 Lack of flexibility
 Project management difficulties
 Product might produce a system inadequacy for average organization needs.

Boehm’s Spiral Model

A risk-driven software process framework (the spiral model) was proposed by Boehm
(1988) as shown in Fig. 6.9. Here, the software process is represented as a spiral, rather
than a sequence of activities with some backtracking from one activity to another. Each
loop in the spiral represents a phase of the software process. Thus, the innermost loop
might be concerned with system feasibility, the next loop with requirements definition, the
next loop with system design, and so on. The spiral model combines change avoidance with
change tolerance. It assumes that changes are a result of project risks and includes explicit
risk management activities to reduce these risks.
Each loop in the spiral is split into four sectors:
 Objective setting: Specific objectives for that phase of the project are defined.
Constraints on the process and the product are identified and a detailed
management plan is drawn up. Project risks are identified. Alternative strategies,
depending on these risks, may be planned.
 Risk assessment and reduction: For each of the identified project risks, a detailed
analysis is carried out. Steps are taken to reduce the risk. For example, if there is a
risk that the requirements are inappropriate, a prototype system may be developed.
 Development and validation: After risk evaluation, a development model for the
system is chosen. For example, throwaway prototyping may be the best
development approach if user interface risks are dominant. If safety risks are the
main consideration, development based on formal transformations may be the most
appropriate process, and so on. If the main identified risk is subsystem integration,
the waterfall model may be the best development model to use.
 Planning: The project is reviewed and a decision made whether to continue with a
further loop of the spiral. If it is decided to continue, plans are drawn up for the next
phase of the project.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 23
[Software Process Models]

Fig. 6.9. The Process of Spiral Model

Spiral Model attempts to solve some of the problems of the waterfall model incorporating
its best features. It offers greater flexibility than waterfall model. It also incorporates
prototyping as necessary. A comprehensive stages of spiral model is presented on Fig. 6.9
as it is enumerated below
1. System Requirement
2. Preliminary Design
3. First Prototype
4. Second Prototype – evolved by a fourfold procedure:
4.1 Evaluating the first prototype in terms of strengths, weaknesses, and
risks.
4.2 Defining the requirements of the second prototype.
4.3 Planning and designing the second prototype
4.4 Constructing and testing the second prototype.
5. Risk Analysis
6. Prototype Evaluation
7. Preceding steps are iterated until…
8. The client is satisfied
9. Final System

Advantages of Spiral Model

1. Estimation gets more realistic as work progresses.
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 24
[Software Process Models]

2. More able to cope with changes.

Risks of Spiral Model
1. During a long development, the user requirements are neglected.
2. If someone leaves the development teams…
3. A competitor launches a rival package on the market…
4. When the software occupies too many memory…

The Rational Unified Process

The Rational Unified Process also known as RUP Krutchen (2003) is an example of a
modern process model that has been derived from work on the UML and the associated
Unified Software Development Process, Rumbaugh, et al., (1999 and Arlow & Neustadt(
2005).
RUP brings together elements from all of the generic process models, illustrates good
practice in specification and design and supports prototyping and incremental delivery. It
RUP recognizes that conventional process models present a single view of the process. In
contrast, the RUP is normally described from three perspectives:
1. A dynamic perspective, which shows the phases of the model over time.
2. A static perspective, which shows the process activities that are enacted.
3. A practice perspective, which suggests good practices to be used during
the process.
Most descriptions of the RUP attempt to combine the static and dynamic perspectives in a
single diagram Krutchen (2003). RUP is a method of managing Object Oriented Software
Development.

Fig. 6.10. The Phases in the Rational Unified Process

The RUP is a phased model that identifies four discrete phases in the software process.
However, unlike the waterfall model where phases are equated with process activities, the
phases in the RUP are more closely related to business rather than technical concerns. Fig.
6.10 shows the phases in the RUP. These are:
1. Inception: The goal of the inception phase is to establish a business case for the
system. You should identify all external entities (people and systems) that will
interact with the system and define these interactions. You then use this infor-

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 25
[Software Process Models]

mation to assess the contribution that the system makes to the business. If this
contribution is minor, then the project may be cancelled after this phase.
2. Elaboration: The goals of the elaboration phase are to develop an understanding
of the problem domain, establish an architectural framework for the system,
develop the project plan, and identify key project risks. On completion of this phase
you should have a requirements model for the system, which may be a set of UML
use-cases, an architectural description, and a development plan for the software.
3. Construction: The construction phase involves system design, programming, and
testing. Parts of the system are developed in parallel and integrated during this
phase. On completion of this phase, you should have a working software system and
associated documentation that is ready for delivery to users.
4. Transition: The final phase of the RUP is concerned with moving the system from
the development community to the user community and making it work in a real
environment. This is something that is ignored in most software process models but
is, in fact, an expensive and sometimes problematic activity. On completion of this
phase, you should have a documented software system that is working correctly in
its operational environment.
Iteration within the RUP is supported in two ways. Each phase may be enacted in an
iterative way with the results developed incrementally. In addition, the whole set of phases
may also be enacted incrementally, as shown by the looping arrow from Transition to
Inception in Fig. 6.10. The static view of the RUP focuses on the activities that take place
during the development process. These are called workflows in the RUP description. There
are six core process workflows identified in the process and three core supporting
workflows.
The RUP has been designed in conjunction with the UML, so the workflow description is
oriented around associated UML models such as sequence models, object models, etc. The
core engineering and support workflows are described in Fig. 6.11. The advantage in
presenting dynamic and static views is that phases of the development process are not
associated with specific workflows. In principle at least, all of the RUP workflows may be
active at all stages of the process. In the early phases of the process, most effort will
probably be spent on workflows such as business modelling and requirements and, in the
later phases, in testing and deployment.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 26
[Software Process Models]

Fig. 6.11. Static workflows in the Rational Unified Process

Workflow Description
 Business modelling: The business processes are modelled using business use
cases.
 Requirements Actors: who interact with the system are identified and use cases
are developed to model the system requirements.
 Analysis and design: A design model is created and documented using
architectural models, component models, object models, and sequence models.
 Implementation: The components in the system are implemented and structured
into implementation sub-systems. Automatic code generation from design models
helps accelerate this process.
 Testing: It is an iterative process that is carried out in conjunction with
implementation. System testing follows the completion of the implementation.
 Deployment: A product release is created, distributed to users, and installed in
their workplace.
 Configuration and change management: This supporting workflow manages
changes to the system.
 Project management: This supporting workflow manages the system.
 Environment: This workflow is concerned with making appropriate software tools
available to the software development team.

The practice perspective on the RUP describes good software engineering practices that
are recommended for use in systems development. Six fundamental best practices are
recommended:

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 27
[Software Process Models]

1. Develop software iteratively: Plan increments of the system based on customer

priorities and develop the highest-priority system features early in the development
process.
2. Manage requirements: Explicitly document the customer’s requirements and
keep track of changes to these requirements. Analyze the impact of changes on the
system before accepting them.
3. Use component-based architectures: Structure the system architecture into
components, as discussed earlier in this chapter.
4. Visually model software: Use graphical UML models to present static and
dynamic views of the software.
5. Verify software quality: Ensure that the software meets the organizational
quality standards.
6. Control changes to software: Manage changes to the software using a change
management system and configuration management procedures and tools.
The RUP is not a suitable process for all types of development, e.g., embedded software
development. However, it does represent an approach that potentially combines the three
generic process models as previously discussed. The most important innovations in the
RUP are the separation of phases and workflows, and the recognition that deploying
software in a user’s environment is part of the process. Phases are dynamic and have goals.
Workflows are static and are technical activities that are not associated with a single phase
but may be used throughout the development to achieve the goals of each phase.

Rapid Application Model

RAD model is Rapid Application Development model. It is a type of incremental model. In
RAD model the components or functions are developed in parallel as if they were mini
projects. The developments are time boxed, delivered and then assembled into a working
prototype. This can quickly give the customer something to see and use and to provide
feedback regarding the delivery and their requirements.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 28
[Software Process Models]

RAD Phases
 Requirements planning phase: a workshop utilizing structured discussion of
business problems
 User description phase: automated tools capture information from users
 Construction phase: productivity tools, such as code generators, screen generators,
etc. inside a time-box. “Do until done”
 Cutover phase: installation of the system, user acceptance testing and user training
RAD Strengths
 Reduced cycle time and improved productivity with fewer people means lower costs
 Time-box approach mitigates cost and schedule risk
 Customer involved throughout the complete cycle minimizes risk of not achieving
customer satisfaction and business needs
 Focus moves from documentation to code (WYSIWYG).
 Uses modeling concepts to capture information about business, data, and processes.
RAD Weaknesses
 Accelerated development process must give quick responses to the user
 Risk of never achieving closure
 Hard to use with legacy systems
 Requires a system that can be modularized
 Developers and customers must be committed to rapid-fire activities in an
abbreviated time frame.
When to use RAD
 Reasonably well-known requirements
 User involved throughout the life cycle
 Project can be time-boxed
 Functionality delivered in increments
 High performance not required
 Low technical risks
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 29
[Software Process Models]

 System can be modularized

Agile Development Model

Agile development model is also a type of Incremental model. Software is developed in
incremental, rapid cycles. This results in small incremental releases with each release
building on previous functionality. Each release is thoroughly tested to ensure software
quality is maintained. It is used for time critical applications. Extreme Programming (XP)
is currently one of the most well-known agile development life cycle model.

image source: http://istqbexamcertification.com/what-is-agile-model-advantages-disadvantages-and-when-to-use-it/

Advantages of Agile model:

 Customer satisfaction by rapid, continuous delivery of useful software.
 People and interactions are emphasized rather than process and tools. Customers,
developers and testers constantly interact with each other.
 Working software is delivered frequently (weeks rather than months).
 Face-to-face conversation is the best form of communication.
 Close, daily cooperation between business people and developers.
 Continuous attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

Disadvantages of Agile model:

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 30
[Software Process Models]

 In case of some software deliverables, especially the large ones, it is difficult to assess the
effort required at the beginning of the software development life cycle.
 There is lack of emphasis on necessary designing and documentation.
 The project can easily get taken off track if the customer representative is not clear what
final outcome that they want.
 Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined
with experienced resources.

When to use Agile model:

 When new changes are needed to be implemented. The freedom agile gives to change is
very important. New changes can be implemented at very little cost because of the
frequency of new increments that are produced.
 To implement a new feature the developers need to lose only the work of a few days, or
even only hours, to roll back and implement it.
 Unlike the waterfall model in agile model very limited planning is required to get started
with the project. Agile assumes that the end users’ needs are ever changing in a dynamic
business and IT world. Changes can be discussed and features can be newly effected or
removed based on feedback. This effectively gives the customer the finished system they
want or need.
 Both system developers and stakeholders alike, find they also get more freedom of time
and options than if the software was developed in a more rigid sequential way. Having
options gives them the ability to leave important decisions until more or better data or
even entire hosting programs are available; meaning the project can continue to move
forward without fear of reaching a sudden standstill.
Agile Methods
o Adaptive Software Development (ASD)
o Feature Driven Development (FDD)
o Crystal Clear
o Dynamic Software Development Method (DSDM)
o Rapid Application Development (RAD)
o Scrum
o Extreme Programming (XP)
o Rational Unify Process (RUP)
Extreme Programming
Extreme Programming (XP) is a no nonsense, code first approach to software delivery that
emphasizes four basic activities: coding, testing, listening, and designing. For small-to-
medium-sized teams developing software with vague or rapidly changing requirements.
Coding is the key activity throughout a software project (a) communication among
teammates is done with code (b) Life cycle and behavior of complex objects defined in test
cases – again in code.
It was the first Agile method to truly challenge traditional Waterfall methods. It did away
with traditional requirements gathering techniques, brought testing to the forefront of the
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 31
[Software Process Models]

delivery process, and helped popularize core software engineering practices like automated
testing, refactoring, continuous integration (CI), and test-driven development (TDD).
XP Practices
1. Planning game – determine scope of the next release by combining business
priorities and technical estimates
2. Small releases – put a simple system into production, then release new versions
in very short cycle
3. Metaphor – all development is guided by a simple shared story of how the whole
system works
4. Simple design – system is designed as simply as possible (extra complexity
removed as soon as found)
5. Testing – programmers continuously write unit tests; customers write tests for
features
6. Refactoring – programmers continuously restructure the system without
changing its behavior to remove duplication and simplify
7. Pair-programming -- all production code is written with two programmers at
one machine
8. Collective ownership – anyone can change any code anywhere in the system at
any time.
9. Continuous integration – integrate and build the system many times a day –
every time a task is completed.
10. 40-hour week – work no more than 40 hours a week as a rule
11. On-site customer – a user is on the team and available full-time to answer
questions
12. Coding standards – programmers write all code in accordance with rules
emphasizing communication through the code
XP is “extreme” because: Commonsense practices taken to extreme levels
• If code reviews are good, review code all the time (pair programming)
• If testing is good, everybody will test all the time
• If simplicity is good, keep the system in the simplest design that supports its current
functionality. (simplest thing that works)
• If design is good, everybody will design daily (refactoring)
• If architecture is important, everybody will work at defining and refining the
architecture (metaphor)
• If integration testing is important, build and integrate test several times a day
(continuous integration)
• If short iterations are good, make iterations really, really short (hours rather than
weeks)

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 32
[Software Process Models]

COMPUTER-AIDED SOFTWARE ENGINEERING (CASE)

Computer-Aided Software Engineering (CASE) is software to support software
development and evolution processes
Computer AIDED Software Engineering
 Not automated; still takes human intervention; ASSISTS the human
 Software that automates all or part of the development process
 Software tool that assists in some aspect of the production of software

Software that helps carry out much of the dredge work associated with software
development (e.g., documentation creation and organization)

Organizations use CASE tools to:

 Improve the quality of the system
 Increase speed of design and development
 Ease and improve the testing process
 Improve integration of development activities
 Improve quality and completeness of documentation
 Improve management of the project
 Simplify program maintenance
 Promote reusability

Benefits
 Improve software quality
 Enforce discipline
 Help communication between development team members
 Information is illustrated through diagrams that are typically easier to
understand
 Development information is centralized
Problems
 Limitations in flexibility of documentation
 Major danger: completeness and syntactic correctness does NOT mean
compliance with requirements
 Costs associated with the use of the tool
 Purchase price
 Training

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 33
[Software Process Models]

Activity automation
• Graphical editors for system model development
• Data dictionary to manage design entities
• Graphical UI builder for user interface construction
• Debuggers to support program fault finding
• Automated translators to generate new versions of a program

Case technology has led to significant improvements in the software process though not the
order of magnitude improvements that were once predicted
 Software engineering requires creative thought - this is not readily automatable
 Software engineering is a team activity and, for large projects, much time is spent in
team interactions. CASE technology does not really support these

Classification helps us understand the different types of CASE tools and their support for
process activities

 Functional perspective - Tools are classified according to their specific function

 Process perspective - Tools are classified according to process activities that are
supported
 Integration perspective - Tools are classified according to their organization into
integrated units

Functional Tool Classification

Tool type Examples

Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processors
Change management Requirements traceability tools, change control
tools systems
Configuration Version management systems, system building tools
management tools
Prototyping tools Very high-level languages,
user interface generators
Method-support tools Design editors, data dictionaries, code generators
Language-processing Compilers, interpreters
tools
Program analysis tools Cross reference generators, static analysers, dynamic
analysers
Testing tools Test data generators, file comparators
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 34
[Software Process Models]

Debugging tools Interactive debugging systems

Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring
systems

Activity-based Classification

3 Categories of CASE tools

A tool might be on a workbench or included in an IDE, for example you can get a free
refactoring tool and pattern search tool and plug it into Eclipse (an IDE).
An example of a general tool is the word processor, text editor, spreadsheet used in
software development.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 35
[Software Process Models]

Definitions from Software Engineering, 7th Edition:

 CASE tool: A software tool, such as a design editor or a program debugger, used to
support an activity in the software development process.
 CASE workbench: An integrated set of CASE tools that work together to support a
major process activity such as software design or configuration management.
 CASE workbench: An integrated set of CASE tools that work together to support a
major
 process activity such as software design or configuration management.

CASE TOOLS
 Upper-CASE tools (front-end tools): Assist developer during requirements,
analysis, and design workflows or activities
 Lower-CASE tools (back-end tools): Assist with implementation, testing, and
maintenance workflows or activities
 Integrated CASE tools (I-CASE): provide support for the full life cycle

WORKBENCHES
Collection of tools that together support:
 Process workflows (requirements, design, etc.)
 One or two activities where an activity is a related collection of tasks

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 36
[Software Process Models]

Commercial examples:
 PowerBuilder
 Software Through Pictures
 Software Architect
Environments
 Support the complete software process or, at least, a large portion of the
software process
 Normally include several different workbenches which are integrated in
some way

Components of CASE

Design Analysi
Generato s
r tool

Drawin Code
g Generato
Tool r

Documen CASE Database

t repositor Generato
Generator y r

Error- Prototypin
checking g
tool Tool

Security and Screen and

Version Report
CASE repository Control Generator
 Central component of any CASE tool
 Also known as the information repository or data dictionary

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 37
[Software Process Models]

CASE repository
• Centralized database
• Allows easy sharing of information between tools and SDLC activities
• Used to store graphical diagrams and prototype forms and reports during
analysis and design workflows
• Provides wealth of information to project manager and allows control over
project
• Facilitates reusability
CASE repository acts as:
Information repository
 Combines information about organization’s business information and application
portfolio
 Provides automated tools to manage and control access
Data dictionary
 Used to manage and control access to information repository
 Facilities for recording, storing and processing resources
 Useful for cross-referencing
Diagramming tools
 Allow you to represent a system and its components visually
 Allows higher level processes to be easily decomposed
 Can examine processes or data models at high or low level

Screen and report generators

 Used to
 Create, modify and test prototypes of computer displays and reports
 Identify which data items to display or collect for each screen or report
 Some tools have templates
Analysis tools
 Generate reports that help identify possible inconsistencies, redundancies and
omissions
 Generally focus on
o diagram completeness and consistency
o data structures and usage

CASE documentation generator tools

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 38
[Software Process Models]

Create standard reports based on contents of repository

Need textual descriptions of needs, solutions, trade-offs, diagrams of data and
processes, prototype forms and reports, program specifications and user
documentation
High-quality documentation leads to 80% reduction in system maintenance effort in
comparison to average quality documentation
CASE workbenches
A coherent set of tools that is designed to support related software process activities
such as analysis, design or testing.
Analysis and design workbenches support system modeling during both
requirements engineering and system design.
These workbenches may support a specific design method or may provide support
for a creating several different types of system model.

Structu red Repor t

Data
diag ramming gener atio n
diction ary
too ls facilities

Centr al Qu ery
Co de
infor ma tio n lan guage
gener ator
repos ito ry facilities

Forms Design , anal ys is

Impo r t/e xpor t
cr ea tion and check in g
facilities
too ls too ls

An analysis and design workbench

Analysis workbench components

 Diagram editors
 Model analysis and checking tools
 Repository and associated query language
 Data dictionary
 Report definition and generation tools
 Forms definition tools
Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 39
[Software Process Models]

 Import/export translators
 Code generation tools

Activities and Exercises

 Assignment 1: Article Review No. 4: Software

Process Models and Analysis on Failure of
Software Development Projects

 Assignment 2: Article Review No. 5: Service

oriented architectures: approaches, technologies
and research issues

 Course Project: Identify the appropriate process model for

your project

Glossary
 System – combination of hardware and software that needs the product.
 Methodology – particular approves or paradigm or set of techniques designed to
accomplish a specific phase or a number of phases in software development life cycle.
 Bug – the colloquial term use to refer to a software fault.
 Fault – the actual problem in the code that is causing a failure.
 Failure – the behaviour preceded by the user that resulted from the fault in the code.
 Error – the programmer’s mistake that kept to the code fault in the code.
 Client – the individual or organization who wants a product to be develop.
 Developer – the individual or group responsible for building the product.
 User – the persons who will utilize the product.
 Product – any non-trivial piece of software.

Course Module
 ADVANCED SYSTEMS DESIGN AND IMPLEMENTATION 40
[Software Process Models]

References

 Text Book: Somerville, Ian (2001)Addison-Wesley Software Engineering 7th

Edition). Massachusetts: Addison Wesley
ISBN 0-321-21026-3

 Online Journal: Rupinder Kaur, Dr. Jyotsna Sengupta (2011)Software Process

Models and Analysis on Failure of Software Development Projects
International Journal of Scientific & Engineering Research Volume 2, Issue 2,
February-2011 ISSN 2229-5518 1 M

 Online Journal: “Service oriented architectures: approaches, technologies

and research issues,” Mike P. Papazoglou · Willem-Jan van den Heuvel, The
VLDB Journal (2007) 16:389–415

 Online Journal: "Software Chronic Crisis," W. Wayt Gibbs, Scientific

American, September 1994, pp. 86-95.

Course Module