4 Slide 1

Software Processes

4 Slide 2

Objectives

To introduce software process models Plan driven(generic) and Agile Process To describe generic process models and when

they may be used

4 Slide 3

Plan-driven and agile processes Plan-driven processes are processes where all

of the process activities are planned in advance and progress is measured against this plan.

In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.

In practice, most practical processes include elements of both plan-driven and agile approaches.

There are no right or wrong software processes.

4 Slide 4

The software process

A structured set of activities required to develop a software system• Specification;• Design;• Implementation• Validation;• Evolution.

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

4 Slide 5

Generic software process models The waterfall model

• Separate and distinct phases of specification and development.

• The V model –extension of waterfall model Evolutionary development

• Specification, development and validation are interleaved.

Component-based software engineering The system is assembled from existing components.

Code and Fix RUP-Rational Unified Process There are many variants of these models e.g. formal development where a

waterfall-like process is used but the specification is a formal specification that

is refined through several stages to an implementable design.

4 Slide 6

Waterfall model

Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation and

maintenance

4 Slide 7

Waterfall model phases

Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The main drawback of the waterfall model is

the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.

4 Slide 8

Waterfall model problems

Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

Few business systems have stable requirements. The waterfall model is mostly used for large systems

engineering projects where a system is developed at several sites.

4 Slide 9

The V-Model

4 Slide 10

Evolutionary development

Exploratory development • Objective is to work with customers and to evolve

a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.

Throw-away prototyping• Objective is to understand the system

requirements. Should start with poorly understood requirements to clarify what is really needed.

4 Slide 11

Evolutionary development

Concurrentactivities

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

4 Slide 12

Software prototyping

A prototype is an initial version of a system used to demonstrate concepts and try out design options.

A prototype can be used in:• The requirements engineering process to help

with requirements elicitation and validation;

• In design processes to explore options and develop a UI design;

• In the testing process to run back-to-back tests.

4 Slide 13

Throw-away prototypes

Prototypes should be discarded after development as they are not a good basis for a production system:• It may be impossible to tune the system to meet

non-functional requirements;

• Prototypes are normally undocumented;

• The prototype structure is usually degraded through rapid change;

• The prototype probably will not meet normal organizational quality standards.

4 Slide 14

Evolutionary Models: Prototyping

Constructionof prototype

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

4 Slide 15

The process of prototype development

4 Slide 16

Benefits of prototyping

Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort.

4 Slide 17

Evolutionary development

Problems• Lack of process visibility;

• Systems are often poorly structured;

• Special skills (e.g. in languages for rapid prototyping) may be required.

Applicability• For small or medium-size interactive systems;

• For parts of large systems (e.g. the user interface);

• For short-lifetime systems.

4 Slide 18

Process iteration

System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems.

Iteration can be applied to any of the generic process models.

Two (related) approaches• Incremental delivery;

• Spiral development.

4 Slide 19

Incremental delivery

Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.

User requirements are prioritised and the highest priority requirements are included in early increments.

Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

4 Slide 20

The Incremental Model

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e ry f e e d b a c k

analys is

des ign code

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

increment # n

project calendar time

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

De p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des ign code

t es t

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des igncode t es t

4 Slide 21

Incremental development advantages

Customer value can be delivered with each increment so system functionality is available earlier.

Early increments act as a prototype to help elicit requirements for later increments.

Lower risk of overall project failure. The highest priority system services tend to

receive the most testing.

4 Slide 22

Spiral development Spiral model

• I t explicitly embraces prototyping and an iterative approach to software development

– Start by developing a small prototype

– Followed by a mini-waterfall process, primarily to gather requirements

– Then, the first prototype is reviewed

– In subsequent loops, the project team performs further requirements, design, implementation and review

– The first thing to do before embarking on each new loop is risk analysis

– Maintenance is simply a type of on-going development

An evolutionary software process model which is a combination of an iterative nature of prototyping and controlled aspects of waterfall model

4 Slide 23

Boehm’s detailed spiral model of the software process

4 Slide 24

A simple Spiral model

4 Slide 25

Spiral model usage

Spiral model has been very influential in helping people think about iteration in software processes and introducing the risk-driven approach to development.

In practice, however, the model is rarely used as published for practical software development.

4 Slide 26

Component-based software engineering

Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.

Referred also as CBSE Process stages

• Component analysis;• Requirements modification;• System design with reuse;• Development and integration.

This approach is becoming increasingly used as component standards have emerged.

4 Slide 27

Types of software component

Web services that are developed according to service standards and which are available for remote invocation.

Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.

Stand-alone software systems (COTS) that are configured for use in a particular environment.

4 Slide 28

Examples of Commercial-off-the-shelf (COTS) software

 Individual packages such as word processors and spreadsheets.

Libraries that entail making a connection with existing application code, such as Windows DLLs, browser add-ons, game engines and graphics engines.

Development environments with runtime modules, such as Visual BasicTM and SybaseTM

Retailer device drivers such as screens and printers. Information acquisition applications such as data mining tools. Operating System functionalities such as memory

management and file processes

4 Slide 29

Advantages of COTS

World-wide trends indicate a swift increase in preference to Commercial-off-the-shelf (COTS) software in comparison to Custom Made software solutions. This trend is as a result of the following advantages of using Commercial-off-the-shelf (COTS) software:

Time used to purchase software is much shorter than time spent developing the software.

Less resources in terms of human capital, office space and money are required when purchasing Commercial-off-the-shelf (COTS) software compared to development of customized software.

Commercial-off-the-shelf software have a greater chance of incorporating industry set standards.

Commercial-off-the-shelf software have less dependence on platform since they support components across different environments.

Reliability of the system is greater since commercial software is generally tested for a larger variety of use.

 

4 Slide 30

COTS-disadvantages

The following factors must be considered when making the decision to acquire Commercial-off-the-shelf software:

Business and technical functionality: The solution must provide the highest functionality for the business/ organization. It must fit with the required performance and quality standards of the organization.

Vendor experience in developing software packages: the vendor must have extensive knowledge in providing quality standard software

Pre-existing systems within the organization: The solution sought must integrate well with the legacy systems within the organization.

Size of the Organization for which the software is to be deployed: purchasing software with a general licence is better for a larger organization compared to investing in single-user-licence software.

Future need for maintenance and upgrades: purchased software should ideally require less maintenance from the vendor and low-cost upgrades in order to reduce the overall cost of ownership.

4 Slide 31

Code and Fix Model

The code and fix model probably is the most frequently used development methodology in software engineering. It starts with little or no initial planning. You immediately start developing, fixing problems as they occur, until the project is complete.

Code and fix is a tempting choice when you are faced with a tight development schedule because you begin developing code right away and see immediate results.

Unfortunately, if you find major architectural problems late in the process, you usually have to rewrite large parts of the application. Alternative development models can help you catch these problems in the early concept stages, when making changes is easier and less expensive.

The code and fix model is appropriate only for small projects that are not intended to serve as the basis for future development.

4 Slide 32

The Unified Process (UP)

The Rational Unified Process is a modern generic process model that is organized into phases (inception, elaboration, construction and transition) but separates activities (requirements, analysis and design, etc.) from these phases.

This modern and iterative generic process derived from the work on the UML and associated process brings together aspects of generic process models .Normally described from 3 perspectives

•A dynamic perspective that shows phases over time;•A static perspective that shows process activities;•A practive perspective that suggests good practice.

4 Slide 33

The Unified Process (UP)

software increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration

4 Slide 34

RUP phases

Inception• Establish the business case for the system.

Elaboration• Develop an understanding of the problem domain

and the system architecture. Construction

• System design, programming and testing. Transition

• Deploy the system in its operating environment.

4 Slide 35

UP Phases

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

4 Slide 36

UP Work Products

Inception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment

Delivered software increment Beta test reports General user feedback

4 Slide 37

RUP-advantages and drawbacks

Advantages of RUP Software Development This is a complete methodology in itself with an emphasis on accurate documentation It is proactively able to resolve the project risks associated with the client's evolving requirements requiring

careful change request management Less time is required for integration as the process of integration goes on throughout the software

development life cycle. The development time required is less due to reuse of components. There is online training and tutorial available for this process.

Disadvantages of RUP Software Development The team members need to be expert in their field to develop a software under this methodology. The development process is too complex and disorganized. On cutting edge projects which utilize new technology, the reuse of components will not be possible. Hence

the time saving one could have made will be impossible to fulfill. Integration throughout the process of software development, in theory sounds a good thing. But on

particularly big projects with multiple development streams it will only add to the confusion and cause more issues during the stages of testing

4 Slide 38

Still Other Process Models

Formal methods—emphasizes the mathematical specification of requirements

Formal methods are techniques used to model complex systems as mathematical entities. By building a mathematically rigorous model of a complex system, it is possible to verify the system's properties in a more thorough fashion than empirical testing

AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects

AOSD methodology seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program's business logic. AOSD allows multiple concerns to be expressed separately and automatically unified into working systems

4 Slide 39

Key points

Software processes are the activities involved in producing and evolving a software system.

Software process models are abstract representations of these processes.

Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.

Iterative process models describe the software process as a cycle of activities.

The Rational Unified Process is a generic process model that separates activities from phases

4 Slide 40

References

Sommerville I. (2010). Software engineering (9th ed.). Pearson – International Edition: New York. ISBN-10: 0137053460

Pressman, R. S. (2009). Software engineering: A practitioner's approach (7th ed.). McGraw-Hill Higher Education. ISBN-10: 0071267824.

Galorath,D.(2004) Software Reuse and Commercial Off-the-Shelf Software. Pp6-10

Turner,S., S.Taylor and Strassburger,S.(2008) Commercial-Off-The-Shelf Simulation Package Interoperability: Issues and Futures. Pp206-207

Reifer, Donald, J. (1997) Practical Software Reuse.Pp17