B Process Models MCA

8/10/2019 B Process Models MCA

1/33


2/33

2

A Generic Process Model


3/33

3

Process Flow


4/33

4

Identifying a Task Set

A task set defines the actual work to be done to

accomplish the objectives of a software

engineering action.

A list of the task to be accomplished

A list of the work products to be produced

A list of the quality assurance filters to be applied


5/33

5

Process Assessment and Improvement

Standard CMMI Assessment Method for Process Improvement(SCAMPI)

CMM-Based Appraisal for Internal Process Improvement (CBA IPI)

SPICE - (ISO/IEC15504)

ISO 9001:2000 for Software

a generic standard that applies to any organization thatwants to improve the overall quality of the products,systems, or services that it provides.


6/33

Process Models

6


7/33


8/33

8

V-Model


9/33

9

Incremental Model

SoftwareFu

nctionalityandFeatures

Project Calendar Time

Communication

Planning

Modeling

Construction

Deployment

Increment #1Delivery of

1st increment Core product

Increment #2Delivery of

2nd incrementMore features

and functionali ty

Increment #nDelivery of

nth increment


10/33

Incremental Process Models

The Rapid Application Development (RAD) Model

Communication

Planning

Modeling

business modeling

data modeling

process modeling

Team #1

Construction

component reuse

automatic code

generation

testing

Modeling

business modeling

data modeling

process modeling

Team #n

Constructioncomponent reuse

automatic code

generation

testing

Deployment

integration

delivery

feedback

Require sufficient

human resources.

Require commitment to

the rapid-fire activities fromboth developers andcustomers.

If a system cannot be

properly modularized, RADmay not work.

RAD is not

appropriate whentechnical risks are

high.


11/33

Deployment

Delivery& Feedback Construction

of prototype

Evolutionary Process Models: Prototyping

Quick Plan

Modeling

Quick design

Communication


12/33

12

Evolutionary Models: The Spiral

communication

planning

modeling

constructiondeployment

delivery

feedback

start

analysis

design

code

test

estimation

scheduling

risk analysis


13/33

Evolutionary Models: Spiral Model

ReviewCommitment

Partition

Risk

analy-sis

Prototype 1

Simulations, models, benchmarksRequirementsplan, life-cycle

planConcept ofoperation

Prototype 2

Riskanalysis

Softwarerequirements

Requirements

validation

Develop-ment plan

Riskanalysis

Prototype 3

Softwareproduct

design

Design validation andverification

Integrationand

test plan

Riskanalysis

Operationalprototype

Detaileddesign

Unittest

Code

Integrationand test

Acceptancetest

Implementation

Plan next phases

Develop, verify next-

level product

Determine

objectives,

alternatives,

constrains

Evaluate alternatives,identify, resolve risks

Cumulative cost

Progress through steps


14/33

14

Evolutionary Models: Concurrent

Under review

Baselined

Done

Under

revision

Await ing

changes

Under

development

none

Modeling act ivit y

represents the state

of a software engineering

activity o r t ask


15/33

15

Other Process Models Component based developmentthe process to

apply when reuse is a development objective.

Formal methodsemphasizes the mathematicalspecification of requirements.

Unified Processa use-case driven, architecture-

centric, iterative and incremental software processclosely aligned with the Unified Modeling Language(UML).


16/33

The Unified Process (UP)

A use-casedriven, architecture-centric, iterativeand incrementalsoftwareprocess closely aligned with the Unified Modeling Language (UML)

Software increment

Release

Inception

Elaborat ion

Construct ion

Transit ion

Product ion


17/33

17

UP PhasesInception Elaborat ion Const ruct ion Transit ion Product ion

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support


18/33

Agile Model

18


19/33


20/33

Principles of Agile method


21/33

21

Agility Principles - I

1. Our highest priority is to satisfy the customer through early and continuous delivery ofvaluable software.

2. Welcome changing requirements, even late in development.

3. Deliver working software frequently, from a couple of weeks to a couple of months,with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and supportthey need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within adevelopment team is facetoface conversation.


22/33

22

Agility Principles - II

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, andusers should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity.

11. The best architectures, requirements, and designs emerge from selforganizingteams.

12. At regular intervals, the team reflects on how to become more effective, then tunesand adjusts its behavior accordingly.


23/33

Human Factors

the process molds to the needs of the peopleand teamnot the other way around

key traits must exist among the people on an agile team and the team itself:

Competence.( talent, skills, knowledge)

Common focus. ( deliver a working software increment )

Collaboration. ( stakeholders)

Decision-making ability. ( freedom to control its own destiny)

Fuzzy problem-solving ability. (ambiguity and constant changes, today

problem may not be tomorrow

s problem)

Mutual trust and respect.

Self-organization.( themselves for the work done, process for its local

environment, the work schedule)


24/33

Extreme programming (XP)

Perhaps the best-known and most widely used agilemethod: Good practice:

1. iterative development.

2. customer involvement to EXTREME levels.

Extreme Programming (XP) takes an EXTREMEapproach to iterative development.

All requirements are expressed asscenarios (called user stories).

Scenarios are implemented as series of task.

New versions may be built several times per day;

Increments are delivered to customers every 2 weeks;

All tests must be run for every build and the build is only accepted iftests run successfull .


25/33

25

Extreme Programming (XP)

XP Planning

Begins with the creation of user stories

Agile team assesses each story and assigns a cost

Stories are grouped to for a deliverable increment

A commitment is made on delivery date

After the first increment project velocity is used to help define

subsequent delivery dates for other increments

XP Design

Follows the KIS principle

Encourage the use of CRC cards

For difficult design problems, suggests the creation of design prototype

Encourages refactoringan iterative refinement of the internal programdesign


26/33

26


XP Coding

Recommends the construction of a unit test for a storebeforecoding commences

Encourages pair programming

XP Testing

All unit tests are executed daily

Acceptance tests are defined by the customer and

executed to assess customer visible functionality


27/33

27


unit t est

cont inuous integrat ion

acceptance t est ing

pair

programming

Release

user stor ies

values

accept ance t est crit eria

it erat ion plan

simple design

CRC cards

spike solut ions

pro t ot ypes

refacto ring

software increment

pro ject ve locity computed


28/33

XP and agile principles

Incremental development is supported through small,frequent system releases.

Customer involvement means full-time customer

engagement with the team. People not process through pair programming,

collective ownership and a process that avoids longworking hours.

Change supported through regular system releases. Maintaining simplicity through constant refactor ingof

code.


29/33

Component Assembly Model


30/33

"Design"

Strategy

Testing

Requirementsgathering

Implementationusing 4GL

Fourth Generation Techniques (4GT)


31/33

4GT Characteristics

Use of software tools that allow software engineer to specify s/w

characteristics at higher level.

The tools generate codes based on specification.

More time in design and testing - increase productivity.

Tools may not be easy to use, codes generated may not be

efficient


32/33

32

Personal Software Process (PSP)

Planning. This activity isolates requirements and develops both size and resourceestimates. In addition, a defect estimate (the number of defects projected for the work) ismade. All metrics are recorded on worksheets or templates. Finally, development tasksare identified and a project schedule is created.

High-level design. External specifications for each component to be constructed aredeveloped and a component design is created. Prototypes are built when uncertaintyexists. All issues are recorded and tracked.

High-level design review.Formal verification methods (are applied to uncover errors inthe design. Metrics are maintained for all important tasks and work results.

Development. Thecomponent level design is refined and reviewed. Code is generated,

reviewed, compiled, and tested. Metrics are maintained for all important tasks and workresults.

Postmortem. Using the measures and metrics collected (this is a substantial amount ofdata that should be analyzed statistically), the effectiveness of the process is determined.Measures and metrics should provide guidance for modifying the process to improve itseffectiveness.


33/33

Documents

B Process Models MCA