Chapter 3 Process Models

1

PROCESS MODELS• Prescriptive process models define a distinct

set of activities, actions, tasks, milestones, and work products that require to engineer High quality software.

• These process models are not perfect but they provide a road map to the Software Engineering.

• Software Engineers and their Managers adopt these Prescriptive process models to their needs.

• These models provide a stability, control, and organization to an activity .

2

3

•These prescriptive process models are referred as “rigorous process models” because they encompasses the capabilities of CMMI

• The process guides a software team through a set of frame work activities that are organized into a process flow.

• The flow may be

• Linear

•Incremental or Evolutionary.

• The terminology and the details of each process model differ but the generic framework activities remain consistent.

4

• The work products are the programs, documents and data that are produced as a consequence of the activities and tasks defined by the process.

• There are number of process assessment mechanism that enable organizations to determine the “MATURITY” of their software process.

• The quality, timeliness, and long term viability (life time) of the product we build are the Best indicators of the efficacy of the process that we use.

5

Prescriptive ModelsA prescriptive process model populates a process framework with a set of software Engineering actions and define in terms of a task set that identifies the work and work products to accomplish to meet development goals.

Regardless of the process model software Engineers have traditional generic framework activities that encompasses the frame work activities like :

Communication

Planning

Modeling

Construction and Deployment

THE WATERFALL MODEL

6

Here we examine a number of prescriptive software process models. Here “prescriptive” prescribe a set of process elements- Framework activities, Software Engineering actions , Tasks, Work Products, Quality assurance, and change control mechanism for each project. Each process model prescribe a Workflow

The Waterfall Model

7

Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback

8

The WATERFALL MODEL is often called as the CLASSIC LIFE CYCLE Suggests a systematic Sequential approach to the software development that begins with Customer Specification of Requirement and progresses through Planning, Modeling, Construction, and Deployment, Providing a on-going support to the complete Software.

The Waterfall Model is the oldest paradigm for Software Engineering.

There are some problems that are sometimes encountered when the waterfall model is applied are.

1. Real projects rarely follow the Sequential flow that the model proposes. The linear model can accommodate iteration , but done indirectly which cause confusion as project leads.

9

2. It is often difficult for the customer to state all requirements Explicitly. The Waterfall Model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects.

3. The customer must have patience. A working version of the programs will not be available until the working is reviewed .

10

INCREMENTAL MODEL PROCESS

There are many situations in which initial software requirements are reasonably well-defined .

The overall scope of the development effort precludes purely a linear process .

THE INCREMENTAL MODEL

The Incremental Model

11

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

12

• The incremental model combines elements of the WATERFALL MODEL applied in an iterative fashion.

• The incremental model applies linear sequences in a staggered fashion as time progresses. Each linear sequence produces deliverable “increments” of the software.

•E.g.: Consider the Word-processing software which was developed using the incremental model.

•At first it might deliver Basic File Management, Editing, and document production functions in the first increment.

13

•In the second increment more sophisticated editing, and document production capabilities are achieved.

•Spelling and Grammar checking is in the third increment is achieved.

•And Advanced page layout capability in the 4th increment are achieved.

When an incremental model is used, the first increment is often a Core product. i.e. basic requirements are addressed. Many supplementary features are remain undelivered , The product is used by the customer. As a requirement of use/Evaluation a plan is developed for the next increment. The plan addresses the modifications for the core product to meet the needs of the customer and this process is repeated until the complete product is produced.

14

• The incremental process model, like prototyping and other Evolutionary approaches, are iterative in nature.

•The incremental model focus on the delivery of an operational product with an increment.

Incremental Model Strengths • IT is useful when staffing is unavailable for when staffing

is unavailable for a complete implementation by a business deadline that has been established for the project.

• Early increments can be implemented for fewer people. Additional staff can be added in next iteration.(if required).

• Increments can be planned to manage technical risks.

15

Incremental Model Weaknesses

• Requires good planning and design• Requires early definition of a complete and

fully functional system to allow for the definition of increments

• Well-defined module interfaces are required (some will be developed long before others)

• Total cost of the complete system is not lower

16

When to use the Incremental Model • Risk, funding, schedule, program complexity, or need

for early realization of benefits.• Most of the requirements are known up-front but

are expected to evolve over time• A need to get basic functionality to the market early• On projects which have lengthy development

schedules• On a project with new technology

17

18

The RAD Model•RAPID APPLICATION DEVELOPMENT(RAD) is an incremental software process model that emphasizes a short development cycle.

•The RAD model is a “High-speed” adoption of the waterfall model, in which rapid development is achieved by using a Component based construction approach.

•Like other Process models, the RAD approach map into the generic framework activities presented earlier. Communication works to understand the business problems and the information characteristics that a software must accommodate.

•Planning is important since Multiple Software Teams works in parallel in different systems.

19

Modeling encompasses 3 major phases-Business Modeling

Data Modeling&

Process Modeling-and establishes design representations that serve as the basis for RAD’s construction activity.Construction emphasizes the use of pre-existing software components and the application of automatic code generation.Deployment establishes a basis for subsequent iterations when required.

The RAD Model

20

Communication

Planning

Modelingbusiness modeling data modeling process modeling

Constructioncomponent reuse automatic code generation testing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling process modeling

Constructioncomponent reuse automatic code

generation test ing

Modelingbusiness modeling data modeling process modeling

Const ruct ioncomponent reuse automatic code generation testing

Team # 2

Team # n

integration delivery feedback

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• For large projects RAD requires sufficient human

resources to create the right number of RAD teams.• The RAD project fails if the customer and developer are

not committed to the rapid fire activities.• RAD becomes problematic in building the components if

they are not properly modularized.• RAD may not be appropriate when technical risks are

high.• If performance is an issue and if it is to be achieved

through tuning the interfaces to system components, RAD approach may not be suitable.

23

EVOLUTIONARY PROCESS MODELS Software, like all complex systems evolves over a period of time .Business and product requirements often change as development proceeds, stright-line path to the end of the product unrealistic; tight market deadlines make completion of the project impossible. a set of core product or system requirements is well understood but the details of the product or system requirements are not yet been defined. In these similar situations, software engineers need a process model that has been designed to accommodate a product that evolves long time. EVOLUTIONARY MODELS are iterative, They are characterized in a manner that enable software engineers to develop increasingly more complete versions of the software.

A customer defines a set of general objectives for software, but does not identify detailed input, processing, or output requirements. The developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form a human-machine interaction should take.In many other situations a Prototyping paradigm would be the best approach. The prototyping can be used as a standalone process model.The prototyping paradigm assists the software engineer and the customer to better understand what is to be built when requirements are fuzzy(Complex).

The prototyping model also begins with Communication. The software engineer and customer meet and define the overall objectives for the software, identify whatever requirements are known ,and outline areas in which future definition is Mandatory.A prototyping iteration is planned quickly and modeling occurs.The quick design focuses on the representation of the aspects of the software that are visible to the customer / End-user.The quick design leads to the construction of the prototype.The Prototype is deployed and the evaluated by the Customer/User.Feedback is used to refine requirements for software.

Iteration occurs to the prototype to satisfy the needs of the customer and also enable the developer to better understand the needs to be done.The prototype serves as a mechanism for identifying software requirements. If a working prototype is developed the developer attempts to make us of the existing program fragments or applied tools that helps to generate working programs quickly. The prototyping can serve as “The First System”. The developers and customers prefer this model. The user get a feel for a actual system, and developers build them immediately.

Evolutionary Models: Prototyping

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

The Prototyping can be problematic because :1.The Customer sees what appears to be a working version of the software , The developers prefer more in development rather than Software Quality or long-term Maintainability. To achieve “High-quality” it is to be rebuilt so the customer may fell that the project had developed with some additional fixes done to the Prototype to make it a working product.2.The developer often make implementation comparisons in order to get a prototype working quickly. An inappropriate operating system or programming languages may be used simply because it is available and known. An inefficient algorithm may be implemented to demonstrate capability. After a time ,the developer may become comfortable with these choices and forget all the reasons for which why they are inappropriate.

THE SPIRAL MODELThe spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.It provides the potential for rapid development of increasingly more complete versions of the software.Using the spiral model, Software is developed in a series of evolutionary models . A spiral model is divided into a set of framework activities defined by the software engineering team. We use the generic framework activities. Each of the framework activities represent one segment of the spiral path as shown in figure. As this evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center.

Risk is considered as each revolution is made. Anchor points mile stones- A combination of work products and conditions that are attained along the path of the spiral are noted for each evolutionary pass. The first circuit around the spiral might result in development of the product specification. The subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software.The spiral model can be adapted to the hole life of the computer software.The first circuit around the spiral might represent a “concept development project” which begins at the core of the spiral and continues for multiple iterations until concept development is completed.

Evolutionary Models: The Spiral

31

communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

The spiral model is realistic approach to the development of large-scale systems and software.The developer and the customer better understand and react to risk at each evolutionary model.It maintains the systematic stepwise approach of the classic life cycle but incorporates it into iterative framework activities.The spiral model demands a direct consideration of technical risk at all stages of the project and, if properly applied it reduces risk before they become problematic.The spiral model is panacea (Universal Remedy).It may be difficult to convince customers that the approach is controllable.

33

The concurrent development model is also called as concurrent engineering can be represented as a series of frame work activities, software engineering actions and tasks, and their associated states.For E.g.: The MODELING activity is defined for the spiral model is accomplished by invoking the following actions: Prototyping and/or analysis modeling and specification and design.The below figure provides a schematic representation of one software engineering task within the concurrent activity for the concurrent process model.

Evolutionary Models: Concurrent

34

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task

•The activity-modeling may be in any one of the states noted at any given time. Similarly other activities/tasks can be represented in any analogous manner.•All activities exits concurrently but reside in different states.Consider a project in which the Communication activity has completed its first iteration and exists in the awaiting changes state The modeling activity which existed in the none state while initial communication was completed, now it transits into the under development state and if the customer indicates the change in the requirements the modeling activity moves from the under development state into awaiting changes state.

•The Concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of the project.•Each activity, action or task on the network exists simultaneously with other activities, actions or tasks. Events generated at one point in the process trigger transitions among the states.

Specialized Process ModelsSpecial process models take on many of the characteristics of one or more of the conventional models.These models are applied when a narrowly defined software engineering approach for process model to a specific software development goal.

COMPONENT-BASED DEVELOPMENTThe component-based development (CBD) model incorporates many of the characteristics of the spiral model.It is evolutionary in nature, demanding an iterative approach to the creation of software. The model composes applications from prepackaged software components.Modeling and Construction activities begin with the identification of candidate components. These components can be designed as either conventional software modules or object-oriented classes or packages of classes.The component-based development model incorporates the following steps:

38

Available component-based products are researched and evaluated for the application domain in question.Component integration issues are considered. A software architecture is designed to accommodate the components.Components are integrated into the architecture.Comprehensive testing is conducted to ensure proper functionality.The component-based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits. The component assembly leads to a 70percent reduction in development cycle time; an 84 percent reduction in project cost, and a productivity index of 26.2..

These results are a function of the robustness of the component library, but there is little question that the component-based development model provides significantadvantages for software engineers.

THE FORMAL METHODS MODELoThe formal methods model encompasses a set of activities that leads to formal mathematical specification of computer software. Formal methods enable a software engineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation. A variation on this approach, called clean room software engineering is applied by some software development organizations. When formal methods are used during development, theyprovide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms. Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily, i.e. by the application of mathematical analysis.

When formal methods are used during design, they serve as a basis for program verification and therefore enable the software engineer to discover and correct errors that mightgo undetected.Although it is not destined to become a mainstream approach, the formal methods model offers the promise of defect-free software. Yet, the following concerns about its applicability in a business environment have been voiced:1. The development of formal models is currently quite time consuming and expensive.2. Because few software developers have the necessary background to apply formal methods, extensive training is required.3. It is difficult to use the models as a communication mechanism for technically unsophisticated customers.

Aspect-Oriented Software DevelopmentRegardless of the software process that is chosen, the builder of complex software invariably implement a set of localized features, functions, and information content.The localized software characteristics are modeled as components and then constructed within the context of the system architecture.When concerns cut across multiple system functions, features, and information they are often referred as Crosscutting concerns.Aspectual requirements define those crosscutting concerns that have impact across the software architecture. Aspect-Oriented Software Development(AOSD) is also referred as Aspect-Oriented Programming(AOP). Which is a new paradigm that provides a process methodological approach for defining, Specifying, designing, and construction aspects .

AOCE uses a concept of horizontal slices through vertically decomposed software components called “aspects”, to characterize cross-cutting functional and non-functional properties of components. Common systematic aspects include user interfaces, Collaborative work, distribution, persistency, memory management, transaction processing, security, integrity and so on. Components may provide or require one or more “Aspect details” relating to particular aspect.Each aspect detail has a number of properties relating to functional and/or Non-functional characteristics of the aspect detail. A distinct aspect-oriented process is not yet matured. A process will adopt characteristics of both the spiral and concurrent process models.

THE UNIFIED PROCESS

During the 1980’s and in early 1990’2 Object-oriented methods and Programming languages gained a widespread throughout the software engineering community.

A wide variety of Object-Oriented Analysis (OOA) and Design (OOD) methods were also proposed during that period, and a general purpose Object-Oriented Process models was introduced.

In the early 1990’s JAMES RUMBAUGH and GRABY BOOCH and IVARY JACOBSON worked on a ”UNIFIED METHOD” that would combine the best features of their individual methods and adopt some additional features proposed by Experts, which resulted UML-UNIFIED MODELING LANGUAGE that contains a robust notation for the modeling and development of OO systems.

UML provides necessary technology to support object-oriented Engineering practice, which dose not provide the process framework to guide in their application of the technology.

Jacobson, Rumbaugh and Gooch had developed a the UNIFIED PROCESS(UP) a framework for Object-Oriented for software engineering using UML.

Now a days The UNIFIED PROCESS and UML are widely used on OO projects of all kinds.

The INCREMENTAL and ITERATIVE model proposed by the UP are adapted to meet specific project needs.

An Array of work products i.e. Models and Documents are produced as a consequence of applying UML.

Phases of the Unified Process

The 5 generic frame work activities are used to describe any software

process model. The Unified process no exception as shown in below figure.

The Unified Process (UP)

46

inceptioninception

software increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration

The “Phases” of the UP are described in figure and these are related to the 5 generic activities.

The INCEPTION phase of the UP encompasses both CUSTOMER COMMUNICATION and planning activities.

By collaborating with the customer and the end-users, business requirements are identified, a rough architecture for the system are is proposed and a plan for the iterative or incremental nature of ensuring project is developed.

Fundamental business requirements are described through a set of pre-liminary Use-cases are that describe what functions and features are described by each major class users.

A use-case describes a sequence of actions that are performed by a actor (stake holder).

Use-cases help to identify the project scope of the project and provides a basis for project plan.

Planning identifies resources, assesses major risks, defines a schedule, and establishes basis for the phases that are applied as the software increment is developed.

The ELABORATION phase encompasses the Customer Communication and Modeling activities of the process model.

ELABORATION refines and expands the preliminary use-case diagrams that were developed as part of the inception phase and expands the architectural representation to include 5 different views of the software- the use-case model, the analysis model, the design model, the design model, the implementation model and the deployment model.

In some cases the elaboration phase creates an “Executable Architecture Baseline” that represents a “first cut” executable system.

The architectural baseline demonstrates the viability of the architecture but dose not provide all features and functions used in the system.

The plan is carefully reviewed and at the culmination of the elaboration phase to ensure that scope risks and delivery dates remain reasonable.

Modifications to the plan are done at this time.

The CONSTRUCTION phase of the UP is identical to the construction activity defined for the generic process.

Using the architectural model as input, the construction phase develops or acquires the software component that will make each Use-case operational for the end users.

All necessary and required features and functions of the software increment are then implemented in the source code.

As components are being implemented, Unit-tests are designed and executed for each.

Integration activities are conducted. Use-cases are used to derive a suit of acceptance tests that are executed prior to the initiation of the next UP phase.

The TRANSITION phase of the UP encompasses the latter stages of the generic deployment activity.

Software is given to end-user for beta testing and user feedback reports both defects and necessary support changes.

The software team creates the necessary support information that is required to release.

At the conclusion of the TRANSITION phase, the software increment becomes a useable software release.

The PRODUCTION phase of the UP coincides with the deployment activity of the generic process.

The on-going use of the software is monitored supported for the operated environment is provided and defects reports and requests for changes are submitted and evaluated.

The 5 UP phases do not occur in a sequence, but with staggered concurrency.

A software engineering workflow is distributed across all UP phases. A workflow is analogous to the task set, i.e. A workflow identifies the tasks required to accomplish an important software engineering and the work products that are produced as a consequence of successful completing the task.

UNIFIED PROCESS WORK PRODUCTS The below figure illustrates the key WORK PRODUCTS produced as a

consequence of the four technical phases of the 4 UP phases. In the inspection phase, the intent is to establish an overall “VISION” for

the project, identifying a set of business requirements, make a business case for the software, and define project and business risks that may represent a threat to success.

The most important work product produced during inception is the Use-case model –A collection of use-cases that describe how outside actors (Human and Non-human users) interact with the system and gain value from it. The Use case value model is a collection of usage scenarios described with standardized templates that imply software features and functions by describing a set of preconditions, a folw of events or a scenario.

During the inception phase only 10 to 20 percent of the use-case model is completed

After elaboration 80 to 90 percent of the model has been created. The elaboration phase produce a set of work products that elaborate

requirements and produce an architectural description and a preliminary design.

The UP analysis model is the work product that is developed as a consequence of this activity.

The classes and analysis packages defined as a part of the analysis model are refined future into a design model which identifies design classes, subsystems, and the interfaces between subsystems.

Both the analysis and design models expand and refine an evolving representation of software architecture.

The elaboration phase reviews risks and the project plan to ensure that each remains valid.

The Construction phase produces an implementation model that translates design classes into software components.

UP Work Products

53

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

A Deployment model maps components into the physical computing environment. Finally a test model describes tests that are used to ensure that Use-cases are properly reflected in the software that has been constructed.

The transition phase delivers the software increment and assesses work products that are produced as end users work with the software.

Feed backing from beta testing and qualitative requests for change are produced at this time.

UP Phases

55

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support