spm notes 1-5%281%29

8/19/2019 spm notes 1-5%281%29

1/168

CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT

UNIT I

DEVELOPMENT LIFE CYCLE PROCESS

1.1 Overview of software develo!e"t life #$#le

There are various software development approaches defined and designed which are used/employed

during development process of software, these approaches are also referred as “Software Development

Process Models” (eg !aterfall model, incremental model, "#model, iterative model, etc$ %ach process

model follows a particular life cycle in order to ensure success in process of software development

Software life cycle models descri&e phases of the software cycle and the order in which those phases are

e'ecuted %ach phase produces delivera&les reuired &y the ne't phase in the life cycle )euirements

are translated into design *ode is produced according to the design which is called development phase

+fter coding and development the testing verifies the delivera&le of the implementation phase against

reuirementsThere are following si' phases in every Software development life cycle model

- )euirement gathering and analysis

. Design

0mplementation or coding

1 Testing

2 Deployment

3 Maintenance

1% Re&'ire!e"t (at)eri"( a"d a"al$sis* 4usiness reuirements are gathered in this phase This

phase is the main focus of the pro5ect managers and sta6e holders Meetings with managers, sta6e

holders and users are held in order to determine the reuirements li6e7 !ho is going to use the

system8 9ow will they use the system8 !hat data should &e input into the system8 !hat data should

&e output &y the system8 These are general uestions that get answered during a reuirements

gathering phase +fter reuirement gathering these reuirements are analy:ed for their validity and the

possi&ility of incorporating the reuirements in the system to &e development is also studied

;inally, a )euirement Specification document is created which serves the purpose of guideline for the

ne't phase of the model

+% Desi("* 0n this phase the system and software design is prepared from the reuirement specificationswhich were studied in the first phase System Design helps in specifying hardware and system

reuirements and also helps in defining overall system architecture The system design specifications

serve as input for the ne't phase of the model

,% I!le!e"tatio" - Codi"(*

8/19/2019 spm notes 1-5%281%29

2/168


% Testi"(* +fter the code is developed it is tested against the reuirements to ma6e sure that the

product is actually solving the needs addressed and gathered during the reuirements phase During this

phase unit testing, integration testing, system testing, acceptance testing are done

/% Delo$!e"t* +fter successful testing the product is delivered / deployed to the customer for their use

0% Mai"te"a"#e*

8/19/2019 spm notes 1-5%281%29

3/168


process num&er

program counter (P*$

stac6 pointer (SP$

general purpose register contents

floating point register contents

memory state

0/< state

scheduling information

accounting information

9ow can several processes share one *P>8

8/19/2019 spm notes 1-5%281%29

4/168


The goal of the PSP is to help developers produce :ero#defect, uality products on schedule @ow#defect

and :ero defect products have &ecome the reality for some developers and TSP teams, such as the

Motorola division in ;lorida that achieved :ero defects in over -C pro5ects through implementing PSP

techniues

PSP strucure

PSP training follows an evolutionary improvement approach an engineer learning to integrate the PSP

into his or her process &egins at the first level # PSP # and progresses in process maturity to the final

level # PSP.- %ach @evel has detailed scripts, chec6lists and templates to guide the engineer through

reuired steps and helps the engineer improve his own personal software process 9umphrey

encourages proficient engineers to customise these scripts and templates as they gain an understanding

of their own strengths and wea6nesses

Pro#ess

The input to PSP is the reuirements7 reuirements document is completed and delivered to the engineer

PSP23 PSP2.1 I"trod'#es ro#ess dis#ili"e a"d !eas're!e"t%

PSP has phases planning, development (design, coding, test$ and a post mortem + &aseline is

esta&lished of current process measuring time spent on programming, faults in5ected/removed, si:e of a

program 0n a post mortem, the engineer ensures all data for the pro5ects has &een properly recorded andanalysed PSP- advances the process &y adding a coding standard, a si:e measurement and the

development of a personal process improvement plan (P0P$ 0n the P0P, the engineer records ideas for

improving his own process

PSP13 PSP1.1 I"trod'#es esti!ati"( a"d la""i"(%

4ased upon the &aseline data collected in PSP and PSP-, the engineer estimates how large a new

program will &e and prepares a test report (PSP-$ +ccumulated data from previous pro5ects is used to

estimate the total time %ach new pro5ect will record the actual time spent This information is used for

tas6 and schedule planning and estimation (PSP--$

PSP+3 PSP+.1 I"trod'#es &'alit$ !a"a(e!e"t a"d desi("%

PSP. adds two new phases design review and code review Defect prevention and removal are the

focus at the PSP. %ngineers learn to evaluate and improve their process &y measuring how long tas6s

4

8/19/2019 spm notes 1-5%281%29

5/168


ta6e and the num&er of defects they in5ect and remove in each phase of development %ngineers

construct and use chec6lists for design and code reviews PSP.- introduces design specification and

analysis techniues

(PSP is a legacy level that has &een superseded &y TSP$

8/19/2019 spm notes 1-5%281%29

6/168


• productivity

• reuse percentage

• cost performance inde'

• planned value

• earned value

• predicted earned value

• defect density

• defect density &y phase

• defect removal rate &y phase

• defect removal leverage

• review rates

• process yield

• phase yield

• failure cost of uality (*

8/19/2019 spm notes 1-5%281%29

7/168


0n com&ination with the Personal Software Process (PSP$, the Tea! Software Pro#ess (TSP$ provides a

defined operational process framewor6 that is designed to help teams of managers and engineers

organi:e pro5ects and produce software products that range in si:e from small pro5ects of several

thousand lines of code (G@S Department of Defense was pu&lished in Jovem&er

. The &oo6 &y !atts 9umphrey,Introduction to the Team Software Process, presents a view the TSP

intended for use in academic settings, that focuses on the process of &uilding a software production team,

esta&lishing team goals, distri&uting team roles, and other teamwor6#related activities

9ow TSP !or6s

4efore engineers can participate in the TSP, it is reuired that they have already learned a&out the PSP,

so that the TSP can wor6 effectively Training is also reuired for other team mem&ers, the team lead, and

management

The TSP software development cycle &egins with a planning process called the launch, led &y a coach

who has &een specially trained, and is either certified or provisional The launch is designed to &egin the

team &uilding process, and during this time teams and managers esta&lish goals, define team roles,

assess ris6s, estimate effort, allocate tas6s, and produce a team plan During an e'ecution phase,

developers trac6 planned and actual effort, schedule, and defects, meeting regularly (usually wee6ly$ to

report status and revise plans + development cycle ends with a Post Mortem to assess performance,

revise planning parameters, and capture lessons learned for process improvement

The coach role focuses on supporting the team and the individuals on the team as the process e'pert

while &eing independent of direct pro5ect management responsi&ility The team leader role is different

from the coach role in that, team leaders are responsi&le to management for products and pro5ect

outcomes while the coach is responsi&le for developing individual and team performance

7

http://en.wikipedia.org/wiki/Personal_Software_Processhttp://en.wikipedia.org/wiki/Personal_Software_Process

8/19/2019 spm notes 1-5%281%29

8/168


-2 U"ifiedro#esses

The U"ified Software Develo!e"t Pro#ess or U"ified Pro#ess is a popular iterative and

incremental software development process framewor6 The &est#6nown and e'tensively documented

refinement of the >nified Process is the )ational >nified Process ()>P$ P or from )>P, and so the names tend to &e used interchangea&ly

The name Unified Process as opposed toRational Unified Process is generally used to descri&e the

generic process, including those elements which are common to most refinements The Unified

Process name is also used to avoid potential issues of trademar6 infringement since Rational Unified

Processand RUP are trademar6s of 04M The first &oo6 to descri&e the process was titled The Unified

Software Development Process (0S4J #.-#2K-3I#.$ and pu&lished in -III &y 0var Laco&son, rady

4ooch and Lames )um&augh Since then various authors unaffiliated with )ational Software have

pu&lished &oo6s and articles using the name Unified Process, whereas authors affiliated with )ational

Software have favored the name Rational Unified Process

>nified Process *haracteristics

8

http://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Special:BookSources/0201571692http://en.wikipedia.org/wiki/Ivar_Jacobsonhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/James_Rumbaughhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Special:BookSources/0201571692http://en.wikipedia.org/wiki/Ivar_Jacobsonhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/James_Rumbaughhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Software

8/19/2019 spm notes 1-5%281%29

9/168


Iterative a"d I"#re!e"tal

Diagram illustrating how the relative emphasis of different disciplines changes over the course of the

pro5ectThe >nified Process is an iterative and incremental development process The %la&oration,

*onstruction and Transition phases are divided into a series of time&o'ed iterations (The 0nception phase

may also &e divided into iterations for a large pro5ect$ %ach iteration results in an increment , which is a

release of the system that contains added or improved functionality compared with the previous

release+lthough most iterations will include wor6 in most of the process disciplines (e.g.)euirements,

Design, 0mplementation, Testing$ the relative effort and emphasis will change over the course of the

pro5ect

Use Case Drive"

0n the >nified Process, use cases are used to capture the functional reuirements and to define the

contents of the iterations %ach iteration ta6es a set of use cases or scenarios from reuirements all the

way through implementation, test and deployment

4r#)ite#t're Ce"tri#

The >nified Process insists that architecture sit at the heart of the pro5ect teamHs efforts to shape the

system Since no single model is sufficient to cover all aspects of a system, the >nified Process supports

multiple architectural models and views

9

http://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Scenario_(computing)http://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Scenario_(computing)

8/19/2019 spm notes 1-5%281%29

10/168


nified Process reuires the pro5ect team to focus on addressing the most critical ris6s early in the

pro5ect life cycle The delivera&les of each iteration, especially in the %la&oration phase, must &e selected

in order to ensure that the greatest ris6s are addressed first

Pro5ect @ifecycle

The >nified Process divides the pro5ect into four phases

• 0nception

• %la&oration

• *onstruction

• Transition

I"#etio" P)ase

0nception is the smallest phase in the pro5ect, and ideally it should &e uite short 0f the 0nception Phase is

long then it may &e an indication of e'cessive up#front specification, which is contrary to the spirit of the

>nified Process

The following are typical goals for the 0nception phase

• %sta&lish a 5ustification or &usiness case for the pro5ect

•

%sta&lish the pro5ect scope and &oundary conditions•

8/19/2019 spm notes 1-5%281%29

11/168


Develop an appro'imate vision of the system, ma6e the &usiness case, define the scope, and produce

rough estimate for cost and schedule

Ela6oratio" P)ase

During the %la&oration phase the pro5ect team is e'pected to capture a healthy ma5ority of the system

reuirements 9owever, the primary goals of %la&oration are to address 6nown ris6 factors and to

esta&lish and validate the system architecture *ommon processes underta6en in this phase include the

creation of use case diagrams, conceptual diagrams (class diagrams with only &asic notation$

and pac6age diagrams (architectural diagrams$

The architecture is validated primarily through the implementation of an %'ecuta&le +rchitecture 4aseline

This is a partial implementation of the system which includes the core, most architecturally significant,

components 0t is &uilt in a series of small, time &o'ed iterations 4y the end of the %la&oration phase the

system architecture must have sta&ili:ed and the e'ecuta&le architecture &aseline must demonstrate that

the architecture will support the 6ey system functionality and e'hi&it the right &ehavior in terms of

performance, scala&ility and cost

The final %la&oration phase delivera&le is a plan (including cost and schedule estimates$ for the

*onstruction phase +t this point the plan should &e accurate and credi&le, since it should &e &ased on

the %la&oration phase e'perience and since significant ris6 factors should have &een addressed during

the %la&oration phase

Co"str'#tio" P)ase

*onstruction is the largest phase in the pro5ect 0n this phase the remainder of the system is &uilt on the

foundation laid in %la&oration System features are implemented in a series of short, time&o'ed iterations

%ach iteration results in an e'ecuta&le release of the software 0t is customary to write full te't use cases

during the construction phase and each one &ecomes the start of a new iteration *ommon >M@ (>nified

Modelling @anguage$ diagrams used during this phase include +ctivity, Seuence, *olla&oration, State

(Transition$ and 0nteraction

11

http://en.wikipedia.org/wiki/Use_case_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Package_diagramhttp://en.wikipedia.org/w/index.php?title=Executable_Architecture_Baseline&action=edit&redlink=1http://en.wikipedia.org/wiki/Use_case_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Package_diagramhttp://en.wikipedia.org/w/index.php?title=Executable_Architecture_Baseline&action=edit&redlink=1

8/19/2019 spm notes 1-5%281%29

12/168


Tra"sitio" P)ase

The final pro5ect phase is Transition 0n this phase the system is deployed to the target users ;eed&ac6

received from an initial release (or initial releases$ may result in further refinements to &e incorporated

over the course of several Transition phase iterations The Transition phase also includes system

conversions and user training

)efinements and "ariations

)efinements of the >nified Process vary from each other in how they categori:e the

pro5ect disciplines or workflows The)ational >nified Process defines nine disciplines 4usinessModeling, )euirements, +nalysis and Design, 0mplementation,Test, Deployment, *onfiguration and

*hange Management, Pro5ect Management, and %nvironment The %nterprise >nified Process e'tends

)>P through the addition of eight AenterpriseA disciplines +gile refinements of >P such

as P/4asicand the +gile >nified Process simplify )>P &y reducing the num&er of disciplines

)efinements also vary in the emphasis placed on different pro5ect artifacts +gile refinements streamline

)>P &y simplifying wor6flows and reducing the num&er of e'pected artifacts

)efinements also vary in their specification of what happens after the Transition phase 0n the )ational>nified Process the Transition phase is typically followed &y a new 0nception phase 0n the %nterprise

>nified Process the Transition phase is followed &y a Production phase

The num&er of >nified Process refinements and variations is countless nified

Process invaria&ly incorporate their own modifications and e'tensions The following is a list of some of

the &etter 6nown refinements and variations

• +gile >nified Process (+>P$, a lightweight variation developed &y Scott ! +m&ler

• 4asic >nified Process (4>P$, a lightweight variation developed &y 04M and a precursor

to P

• %nterprise >nified Process (%>P$, an e'tension of the )ational >nified Process

• %ssential >nified Process (%ss>P$, a lightweight variation developed &y 0var Laco&son

• nified Process (P$, the %clipse Process ;ramewor6 software development process

• )ational >nified Process ()>P$, the 04M / )ational Software development process

12

http://en.wikipedia.org/wiki/Workflowshttp://en.wikipedia.org/wiki/Workflowshttp://en.wikipedia.org/wiki/Workflowshttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/Business_process_modelinghttp://en.wikipedia.org/wiki/Business_process_modelinghttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Implementationhttp://en.wikipedia.org/wiki/Test_(assessment)http://en.wikipedia.org/wiki/Software_deploymenthttp://en.wikipedia.org/w/index.php?title=Configuration_and_Change_Management&action=edit&redlink=1http://en.wikipedia.org/w/index.php?title=Configuration_and_Change_Management&action=edit&redlink=1http://en.wikipedia.org/wiki/Project_Managementhttp://en.wikipedia.org/wiki/Environment_disciplinehttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/OpenUP/Basichttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Scott_W._Amblerhttp://en.wikipedia.org/wiki/Basic_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Essential_Unified_Processhttp://en.wikipedia.org/wiki/Ivar_Jacobsonhttp://en.wikipedia.org/wiki/Open_Unified_Processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Workflowshttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/Business_process_modelinghttp://en.wikipedia.org/wiki/Business_process_modelinghttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Implementationhttp://en.wikipedia.org/wiki/Test_(assessment)http://en.wikipedia.org/wiki/Software_deploymenthttp://en.wikipedia.org/w/index.php?title=Configuration_and_Change_Management&action=edit&redlink=1http://en.wikipedia.org/w/index.php?title=Configuration_and_Change_Management&action=edit&redlink=1http://en.wikipedia.org/wiki/Project_Managementhttp://en.wikipedia.org/wiki/Environment_disciplinehttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/OpenUP/Basichttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Scott_W._Amblerhttp://en.wikipedia.org/wiki/Basic_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Essential_Unified_Processhttp://en.wikipedia.org/wiki/Ivar_Jacobsonhttp://en.wikipedia.org/wiki/Open_Unified_Processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Rational_Software

8/19/2019 spm notes 1-5%281%29

13/168


• nified Method (M$, the nified Process#System %ngineering ()>P#S%$, a version of )>P tailored &y )ational

Software for System %ngineering

1.0 4(ile Pro#esses

0n software development life cycle, there are two main considerations, one is to emphasi:e on

process and the other is the uality of the software and process itself +gile software processes is an

iterative and incremental &ased development, where reuirements are changea&le according to

customer needs 0t helps in adaptive planning, iterative development and time &o'ing 0t is a

theoretical framewor6 that promotes foreseen interactions throughout the development cycle There

are several SD@* models li6e spiral, waterfall, )+D which has their own advantages SD@* is a

framewor6 that descri&es the activities performed at each stage of a software development life

cycleThe software development activities such as planning, analysis, design, coding, testing andmaintenance which need to &e performed according to the demand of the customer 0t depends on

the various applications to choose the specific model 0n this paper, however, we will study the agile

processes and its methodologies +gile process is itself a software development process+gile

process is an iterative approach in which customer satisfaction is at highest priority as the customer

has direct involvement in evaluating the software

The agile process follows the software development life cycle which includes reuirements gathering,

analysis, design , coding , testing and delivers partially implemented software and waits for the

customer feed&ac6 0n the whole process , customer satisfaction is at highest priority with faster

development time

C)ara#teristi#s of a(ile ro7e#ts

+gile process reuires less planning and it divides the tas6s into small increments +gile process is

meant for short term pro5ects with an effort of team wor6 that follows the software development life

cycle Software development life cycle includes the following phases 1.Re&'ire!e"ts (at)eri"(3

+.4"al$sis3 ,.Desi("3 .Codi"( 3 /.Testi"(3 0.Mai"te"a"#e The involvement of software team

management with customers reduces the ris6s associated with the software This agile process is an

iterative process in which changes can &e made according to the customer satisfaction 0n agileprocess new features can &e added easily &y using multiple iterations

1. Iterative

The main o&5ective of agile software processes is satisfaction of customers, so it focuses on single

reuirement with multiple iterations

+. Mod'larit$

13

http://en.wikipedia.org/wiki/Oracle_Unified_Methodhttp://en.wikipedia.org/wiki/Oracle_Corporationhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/System_Engineeringhttp://en.wikipedia.org/wiki/Oracle_Unified_Methodhttp://en.wikipedia.org/wiki/Oracle_Corporationhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/System_Engineering

8/19/2019 spm notes 1-5%281%29

14/168


+gile process decomposes the complete system into managea&le pieces called modules Modularity

plays a ma5or role in software development processes

,. Ti!e 8o9i"(

+s agile process is iterative in nature, it reuires the time limits on each module with respective cycle

. Parsi!o"$

0n agile processes parsimony is reuired to mitigate ris6s and achieve the goals &y minimal num&er of

modules

/. I"#re!e"tal

+s the agile process is iterative in nature, it reuires the system to &e developed in increments, each

increment is independent of others, and at last all increments are integrated into complete system

0. 4dative

Due to the iterative nature of agile process new ris6s may occurs The adaptive characteristic of agile

process allows adapting the processes to attac6 the new ris6s and allows changes in the real timereuirements

:. Co"ver(e"t

+ll the ris6s associated with each increment are convergent in agile process &y using iterative and

incremental approach

;. Colla6orative

+s agile process is modular in nature, it needs a good communication among software development

teamDifferent modules need to &e integrated at the end of the software development process

8/19/2019 spm notes 1-5%281%29

15/168


,% Least do#'!e"tatio" The documentation in agile methodology is short and to the point though it

depends on the agile team enerally they don=t ma6e documentation on internal design of the

software The main things which should &e on the documentation are product features list, duration

for each iteration and date This &rief documentation saves time of development and deliver the

pro5ect in least possi&le time

% Red'#es ris5s of develo!e"t +s the incremented mini software is delivered to the customers

after every short development cycle and feed&ac6s are ta6en from the customers, it warns

developers a&out the upcoming pro&lems which may occur at the later stages of development 0t also

helps to discover errors uic6ly and they are fi'ed immediately

DIS4DV4NT4=ES

-$ *ustomer interaction is the 6ey factor of developing successful software +gile methodology is&ased on customer involvement &ecause the entire pro5ect is developed according to the

reuirements given &y the customers So if the customer representative is not clear a&out the product

features, the development process will go out of the trac6

.$ @ac6 of documentation Though the least documentation saves development time as an advantage

of agile method, on the other hand it is a &ig disadvantage for developer 9ere the internal design is

getting changed again and again depending on user reuirements after every iteration, so it is not

possi&le to maintain the detail documentation of design and implementation &ecause of pro5ect

deadline So &ecause of less availa&le information, it is very difficult for the new developers who 5oin

the development team at the later stage to understand the actual method followed to develop the

software

$ Time consuming and wastage of resources &ecause of constant change of reuirements 0f the

customers are not satisfied &y the partial software developed &y certain iteration and they change

their reuirements then that incremented part is of no use So it is the total wastage of time, effort and

resources reuired to develop that increment

1$ More helpful for management than developer The agile methodology helps management to ta6e

decisions a&out the software development, set goals for developers and fi' the deadline for them 4ut

it is very difficult for the &aseline developers to cope up with the ever changing environment and every

time changing the design, code &ased on 5ust in time reuirements

15

8/19/2019 spm notes 1-5%281%29

16/168


COMP4RISON OF 4=ILE PROCESS >IT? OT?ER SDLC MODELS

T48LE I. PRCOESS MODELS

Differe"t Pro#ess Models

Feat'res 4(ile Pro#ess Siral Model R4D Model

Defi"itio" 4(ile ro#ess is t)e

a6ilit$ to 6ot) #reate

a"d reso"d

to#)a"(i"(

re&'ire!e"ts of

software.

Siral !odel is t)e

software develo!e"t

!odel w)i#) fo#'ses

o" !a"a(i"( ris5s.

R4D !odel is @)i()

seed adatatio" of

li"ear se&'e"tial

!odel3 i" w)i#)

#o!o"e"t 6ased

#o"str'#tio" is 'sed.

4data6ilit$ $ $ "Testi"( P)ase U"it3 I"te(ratio" 3

S$ste! testi"(

U"it3 I"te(ratio" a"d

S$ste! testi"(

U"it

A'alit$ Fa#tors $ $ "

Ris5 4"al$sis " $ "

OffBt)eB Tools " " $

Fail're "or!all$ d'e to Code Code 4r#)ite#t're a"d

desi("

"owled(e Re&'ired Prod'#t a"d do!ai" Prod'#t a"d do!ai" Do!ai"

E"tr$ e9it Criteria " " $

Mo#5 ' $ $ "

E9te"da6ilit$ $ $ "

Pro7e#t

!a"a(e!e"t

i"volve!e"t

$ " $

?i()er Relia6ilit$ $ $ "

Ti!e 8o9i"( $ " $

16

8/19/2019 spm notes 1-5%281%29

17/168


1.: C)oosi"( t)e ri()t ro#ess

Software process consists of four fundamental activities

-Software specification where engineers or/and customers define what the product should do and how

should it operate

. Software development is designing and actual coding

Software validation is generally testing 0t is important to chec6 if the system is designed and

implemented correctly

1 Software evolution is modifying the system according to new needs of customer (s$

Different types of software need different development process

Software process model is a simplified description of a software process that presents one view of a

process +nd again, choice of a view depends on the system developing, sometimes it is useful to apply awor6flow model, sometimes, for e'ample E a role/action model

Most software process models are &ased on one of three general models or paradigms of software

development

- The waterfall approach 0n this case the development process and all activities are divided into

phases such as reuirement specification, software design, implementation, testing etc Development

goes phase#&y#phase

. 0terative development +n initial system is rapidly developed from very a&stract specifications

8/19/2019 spm notes 1-5%281%29

18/168


The process of ris6 analysis consists of four steps

- Ris5 ide"tifi#atio" Potential ris6s that might arise are identified These are dependent on the

environment in which the system is to &e used 0n safety#critical systems, the principal ris6s are ha:ards

that can lead to an accident %'perienced engineers, wor6ing with domain e'perts and professional safety

advisors, should identify system ris6s roup wor6ing techniues such as &rainstorming may &e used to

identify ris6s

. Ris5 a"al$sis a"d #lassifi#atio" The ris6s are considered separately Those that are potentially

serious and not implausi&le are selected for further analysis )is6s can &e categorised in three ways

a I"tolera6le The system must &e designed in such a way so that either the ris6 cannot arise or, if it

does arise, it will not result in an accident 0ntolera&le ris6s are those that threaten human life or the

financial sta&ility of a &usiness and which have a significant pro&a&ility of occurrence

& +s low as reasona&ly practical (4L4RP$ The system must &e designed so that the pro&a&ility of an

accident arising &ecause of the ha:ard is minimised, su&5ect to other considerations such as cost anddelivery +@+)P ris6s are those which have less serious conseuences or which have a low pro&a&ility of

occurrence

c 4##eta6le !hile the system designers should ta6e all possi&le steps to reduce the pro&a&ility of an

Naccepta&le= ha:ard arising, these should not increase costs, delivery time or other non#functional system

attri&utes

Ris5 de#o!ositio" %ach ris6 is analysed individually to discover potential root causes of that ris6

Different techniues for ris6 decomposition e'ist The one discussed in the &oo6 is ;ault#tree analysis,

where analyst puts ha:ard at the top and place different states which can lead to that ha:ard a&ove

States can &e lin6ed with Nor= and Nand= sym&ols )is6s that reuire a com&ination of root causes are

usually less pro&a&le than ris6s that can result from a single root cause

1 Ris5 red'#tio" assess!e"t Proposals for ways in which the identified ris6s may &e reduced or

eliminated are made Three possi&le strategies of ris6 deduction that can &e used are

a Ris5 avoida"#e Designing the system in such a way that ris6 or ha:ard cannot arise

& Ris5 dete#tio" a"d re!oval Designing the system in such a way that ris6s are detected and

neutralised &efore they result in an accident

c Da!a(e li!itatio" Designing the system in such a way that the conseuences of an accident are

minimised0n the -ICs and -IIs, as computer control &ecome widespread, the safety engineering community

developed standards for safety critical systems specification and development The process of safety

specification and assurance is part of an overall safety life cycle that is defined in an international

standard for safety management 0%* 3-2C (0%*, -IIC$

Security and safety reuirements have something in common7 however, there are some differences

&etween these types of reuirements

18

8/19/2019 spm notes 1-5%281%29

19/168


UNIT II

REAUIREMENT M4N4=EMENT

+.1 F'"#tio"al re&'ire!e"ts a"d A'alit$ attri6'tes

Fuality attri&utes, such as response time, accuracy,security, relia&ility, are properties that affect the

systemas a whole Most approaches deal with uality attri&utes separately from the functional

reuirements of a systemThis means that the integration is difficult to achieve and usually is

accomplished only at the later stages of thesoftware development process ;urthermore, current

approaches fail in dealing with the crosscutting nature ofsome of those attri&utes, ie it is difficult to

represent clearly how these attri&utes can affect severalreuirements simultaneously Since this

integration is not supported from reuirements to the implementation,some of the software engineering

principles, such as a&straction, locali:ation, modularisation, uniformity andreusa&ility, can &e

compromised !hat we propose is a model to identify and specify uality attri&utes that crosscut

reuirements including their systematic integration into the functional description at an early stage of the

software development process, ie at reuirements

4 !odel for earl$ &'alit$ attri6'tes

The process model we propose is >M@ compliant and is composed of three main activities identification,

specification and integration of reuirements The first activity consists of identifying all the reuirements

of asystem and select from those the uality attri&utes relevant to the application domain and

sta6eholders Thesecond activity is divided into two main parts (-$specifying functional reuirements

using a use case &ased approach7 (.$ descri&e uality attri&utes using special templates and identify

19

8/19/2019 spm notes 1-5%281%29

20/168


those that cut across (ie crosscutting$ functional reuirements The third activity proposes a set of

models to represent the integration of crosscutting uality attri&utes and functional reuirements ;igure -

depicts this model

20

8/19/2019 spm notes 1-5%281%29

21/168


To identify the crosscutting nature of some of the uality attri&utes we need to ta6e into account the

informationcontained in rows !here and )euirements 0f a uality attri&ute cuts across (ie is reuired

&y$ several reuirements and models, then it is crosscutting

The integration is accomplished &y “weaving” the uality attri&utes with the functional reuirements in

three different ways

(-$ Overla the uality attri&ute adds new &ehaviour to the functional reuirements it transverses 0n this

case, the uality attri&ute may &e reuired before those reuirements, or, it may &e reuired after them

(.$ Override the uality attri&ute superposes the functional reuirements it transverses 0n this case, its

&ehaviour su&stitutes the functional reuirements &ehavior

($ >ra the uality attri&ute “encapsulates” the reuirements it transverses 0n this case the &ehaviour

of the reuirements is wrapped &y the &ehaviour of the uality attri&ute !e weave uality attri&utes with

functionalreuirements &y using &oth standard diagrammatic representations (eg use case diagram,interaction diagrams$ and &y new diagrams

Ide"tif$ re&'ire!e"ts

)euirements of a system can &e classified into functional and non#functional (ie uality attri&utes$

;unctional reuirements are statements of services the system should provide, how the system should

react to particular inputs and how the system should &ehave in particular situations Different types of

methods are used to specify functional reuirements >se case driven approaches descri&e “the ways in

which a user uses a system” that is why use case diagram is often used for capturing functional

reuirements Fuality attri&utes define glo&al properties of a system >sually these are only dealt with in

the later stages of a software development process, such as design andimplementation

Ide"tif$ a#tors a"d 'se #ases.

;or the road pricing system, the actors we identified are

"ehicle owner is responsi&le for registering a vehicle7

• "ehicle driver comprehends the vehicle, the driver and the gi:mo installed on it7

• 4an6 represents the entity that holds the vehicle owner=s account7

•

System cloc6 represents the internal cloc6 of the system that monthly triggers the calculation of de&its

The following are the use cases reuired &y the actorslisted a&ove

• )egister vehicle is responsi&le for registering a vehicle and its owner, and communicate with the

&an6 to guarantee a good account7

• Pass single toll is responsi&le for dealing with tolls where vehicles pay a fi'ed amount 0t reads

thevehicle gi:mo and chec6s on whether it is a good one 0f the gi:mo is o6 the light is turned

21

8/19/2019 spm notes 1-5%281%29

22/168


green, andthe amount to &e paid is calculated and displayed 0f the gi:mo is not o6, the light is

turned yellow and aphoto is ta6en

• %nter motorway chec6s the gi:mo, turns on the light and registers an entrance 0f the gi:mo is

invalid a photo is ta6en and registered in the system

• %'it motorway chec6s the gi:mo and if the vehicle has an entrance, turns on the light

accordingly, calculates the amount to &e paid (as a function of the distance travelled$, displays it

and records this passage 0f the gi:mo is not o6, or if the vehicle did not enter in a green lane, the

light is turned yellow and a photo is ta6en

• Pay &ill sums up all passages for each vehicle, issues a de&it to &e sent to the &an6 and a copy

to the vehicle owner

Ide"tif$ &'alit$ attri6'tes.

Fuality attri&utes can &e assumptions, constraints or goals of sta6eholders 4y analysing the initial of set

reuirements, the potential uality attri&utes are identified ;or e'ample, if the owner of a vehicle has toindicate, during registration, his/her &an6 details so that automatic transfers can &e performed

automatically, then security is an issue that the system needs to address +nother fundamental uality

attri&ute is response time that is a issue when a vehicle passes a toll gate, or when a customer activates

his/her own gi:mo in an +TM the toll gate components have to react in time so that the driver can see the

light and the amount &eing displayed M@ models, such as use cases, seuence and class

diagrams The uality attri&utes are descri&ed in templates of the form presented in ;igure .

8'ild t)e 'se #ase dia(ra!.

The set of all use cases can &e represented in a use case diagram, where we can see the e'isting

relationships&etween use cases and the ones &etween use cases and actors ;igure shows the use

case diagram of the roadtraffic system

22

8/19/2019 spm notes 1-5%281%29

23/168


I"te(rate f'"#tio"al re&'ire!e"ts wit)#ross#'tti"( &'alit$ attri6'tes

0ntegration composes the uality attri&utes with the functional reuirements, to o&tain the whole system

!e use >M@ diagrams to show the integration The two e'amples given a&ove (for response time and

security$ fall into two of the categories already descri&ed overlap and wrapper !e could e'tend the >M@

diagrams to represent some uality attri&utes ;or e'ample, the seuence diagram shown in ;igure 1 can

&e e'tended to show how response time affects a scenario

+.+ Eli#itatio" te#)"i&'es

+ ma5or goal of )euirements %licitation is to avoid the confusions &etween sta6eholders and analysts

This will often involve putting significant sort into reuirements elicitation >nfortunately, )euirements

23

8/19/2019 spm notes 1-5%281%29

24/168


%ngineering is an immature discipline, perhaps not entirely unfairly characteri:ed as a &attlefield occupied

&y competing commercial methods, firing competing claims at each other, and leaving the consumers

weary and confused

The goal of this paper is to analy:e and compare of the different methods of the reuirements elicitation

process, which will &e useful to compare the different characteristics and the performance of the different

elicitation methods 9ence, all the reuirement elicitation techniues are very handy for e'tracting the

reuirements and different organi:ations, which can use different reuirement elicitation techniues

according to organi:ational culture and needs

+s reuirements elicitation is a process in which intensive interaction &etween sta6eholders and the

analysts, so for finding the interaction &etween sta6eholders and analysts will &e easy for improving the

uality of e'tracted reuirements 0t is important to distinguish different elicitation methods according tothe four methods of communication

- *onversational

. nderstanding

the method category helps engineers understand different elicitation methods and guides them to select

appropriate method for reuirements elicitation

Fo'r Met)ods of Co!!'"i#atio"

i. Conversational Methods

The conversational method provides a means of ver&al communication &etween sta6eholders and

+nalysts +s conversation is a natural way of communication and an effective mean of e'pressing needs

and ideas, and the conversational methods are used massively to understand the pro&lems and to elicit

generic product reuirements The *onversational Methods are also 6nown as ver&al methods, such as

0nterviews, Fuestionnaire, and 4rainstorming

a.I"terviews: + typical conversational method is interviews 0t is most commonly used method inreuirements elicitation +n 0nterview is generally conducted &y an e'perienced analyst, who has some

generic 6nowledge a&out the application domain as well 0n an interview, +nalyst discusses the desired

product with different sta6eholders and develops an understanding of their reuirements enerally

0nterviews are divided in two groups

- *losed 0nterview 0n this interview the reuirements, we have to prepare some predefined uestions

and try to get the answers for these uestions for the sta6eholder

24

8/19/2019 spm notes 1-5%281%29

25/168


.

8/19/2019 spm notes 1-5%281%29

26/168


Proto#ol a"al$sis 0n protocol analysis a sta6eholder is o&served when he is engaged in some tas6, and

concurrently spea6s out loud and e'plains his thought !ith the protocol analysis it is easy to identify

0nteraction pro&lems in e'isting systems and it gives &etter and closer understanding of !or6 conte't and

wor6 flow

;or

8/19/2019 spm notes 1-5%281%29

27/168


Do#'!e"tatio" st'dies: 0n this techniue different availa&le documents (eg

8/19/2019 spm notes 1-5%281%29

28/168


S#e"arios3 assive stor$6oards: 0t is an interaction session 0n this session a seuence of actions and

events descri&ed for e'ecuting some generic tas6 which the system is intended to accomplish !ith the

help of this techniue, clear reuirement related to procedure and data flow can &e achieved !ith this

techniue initial set of reuirement can &e prepared in lesser cost

Protot$i"(3 I"tera#tive stor$6oards: 0n this techniue, a concrete &ut partial system is discussed with

sta6eholders This concrete &ut partial system is e'pected to &e delivered at the end of pro5ect The

purpose of showing this system to sta6eholders is to elicit and validate functional reuirement The p

4D-R4D sessio": 0t stands for Loint +pplication Development/)apid +pplication Development and

emphasi:es user involvement through group sessions with un&iased facilitator L+D is conducted in the

same manner as &rainstorming, e'cept that the sta6eholders and the users are also allowed to participate

and discuss on the design of the proposed system The discussion with the sta6eholders and the userscontinues until the final reuirements are gathered

Co"te9t'al i"&'ir$* this techniue is a com&ination of open#ended interview, wor6place o&servation, and

prototyping This method used for interactive systems design where user interface design is critical

+ll four reuirement elicitation methods are commonly used &ut the selection of reuirement elicitation

method entirely depends on the needs and organi:ational structure Jo matter what development pro5ect

is, reuirements development nearly always ta6es place in the conte't of a human activity system, and

pro&lem owners are people 0t is essential for reuirements engineers to study how people perceive,

understand, and e'press the pro&lem domain, how they interact with the desired product, and how the

physical and cultural environments affect their actions

The conversational methods provide a direct contact channel &etween engineers and sta6eholders, and

the reuirements are mainly no tacit The o&servational methods provide an indirect channel &y o&serving

user=s interaction with his wor6 setting and conte't, and the reuirements fall into tacit 6nowledge The

analytic methods form one complementary indirect contact channel to e'tract reuirements proactively

The synthetic methods focus more on collective effort on clarifying the features of desired products, and

the communication channel is therefore a mi' of direct contact and indirect contact %ach type of techniues has trade#offs 0n reality, of course, the &oundary &etween different types of method is &lurred

4dva"ta(e a"d Disadva"ta(e of Re&'ire!e"t Eli#itatio"

+fter the discussion the different of the four group of reuirement elicitation method 0n order to

understand the each )euirement elicitation Methods and effective use them in the real case ,we have to

28

8/19/2019 spm notes 1-5%281%29

29/168


focus on the advantages and disadvantages of different reuirement elicitation methods *onversational,

8/19/2019 spm notes 1-5%281%29

30/168


$ *onversational or

8/19/2019 spm notes 1-5%281%29

31/168


4oth the system and software architectures are 6ey to reali:ing uality attri&ute reuirementsin the

implementation +lthough an architecture cannot guarantee that an implementation willmeet its uality

attri&ute goals, the wrong architecture will surely spell disaster +s an e'ample,consider security 0t is

difficult, may&e even impossi&le, to add effective security to a systemas an afterthought *omponents as

well as communication mechanisms and paths must &edesigned or selected early in the life cycle to

satisfy security reuirements The critical ualityattri&utes must &e well understood and articulated early in

the development of a system, so thearchitect can design an architecture that will satisfy them The F+!

is one way to discover,document, and prioriti:e a system=s uality attri&utes early in its life cycle

0t is important to point out that we do not aim at an a&solute measure of uality7 rather our purposeis to

identify scenarios from the point of view of a diverse group of sta6eholders (eg,architects, developers,

users, sponsors$ These scenarios can then &e used &y the system engineersto analy:e the system=s

architecture and identify concerns (eg, inadeuate performance,successful denial#of#service attac6s$

and possi&le mitigation strategies (eg, prototyping,modeling, simulation$

A4> Met)od

The F+! is a facilitated, early intervention method used to generate, prioriti:e, and refineuality attri&ute

scenarios &efore the software architecture is completed The F+! is focusedon system#level concerns

and specifically the role that software will play in the system TheF+! is dependent on the participation of

system sta6eholders?individuals on whom the systemhas significant impact, such as end users,

installers, administrators (of data&ase managementsystems BD4MSO, networ6s, help des6s, etc$, trainers,

architects, acuirers, system andsoftware engineers, and others The group of sta6eholders present

during any one F+! shouldnum&er at least 2 and no more than for a single wor6shop 0n preparation

31

8/19/2019 spm notes 1-5%281%29

32/168

8/19/2019 spm notes 1-5%281%29

33/168


representing the &usiness and/or mission concerns (typicallya manager or management representative$

spends a&out one hour presenting

the system=s &usiness/mission conte't

high#level functional reuirements, constraints, and uality attri&ute reuirements

During the presentation, the facilitators listen carefully and capture any relevant informationthat may shed

light on the uality attri&ute drivers The uality attri&utes that will &e refined inlater steps will &e derived

largely from the &usiness/mission needs presented in this step

Ste ,* 4r#)ite#t'ral Pla" Prese"tatio"

!hile a detailed system architecture might not e'ist, it is possi&le that high#level systemdescriptions,

conte't drawings, or other artifacts have &een created that descri&e some of thesystem=s technical

details +t this point in the wor6shop, a technical sta6eholder will presentthe system architectural plans as

they stand with respect to these early documents 0nformationin this presentation may include plans and strategies for how 6ey &usiness/mission reuirements will &e satisfied

6ey technical reuirements and constraints?such as mandated operating systems, hardware,

middleware, and standards?that will drive architectural decisions

presentation of e'isting conte't diagrams, high#level system diagrams, and other writtendescriptions

Ste * Ide"tifi#atio" of 4r#)ite#t'ral Drivers

During steps . and , the facilitators capture information regarding architectural drivers thatare 6ey to

reali:ing uality attri&ute goals in the system These drivers often include high#levelreuirements,

&usiness/mission concerns, goals and o&5ectives, and various uality attri&utes4efore underta6ing this

step, the facilitators should e'cuse the group for a -2#minute &rea6,during which they will caucus to

compare and consolidate notes ta6en during steps . and

!hen the sta6eholders reconvene, the facilitators will share their list of 6ey architectural driversand as6

the sta6eholders for clarifications, additions, deletions, and corrections The idea isto reach a consensus

on a distilled list of architectural drivers that include high#level reuirements,&usiness drivers, constraints,

and uality attri&utes The final list of architectural driverswill help focus the sta6eholders during scenario

&rainstorming to ensure that theseconcerns are represented &y the scenarios collected

Ste /* S#e"ario 8rai"stor!i"(

+fter the architectural drivers have &een identified, the facilitators initiate the &rainstormingprocess in

which sta6eholders generate scenarios The facilitators review the parts of a goodscenario (stimulus,

environment, and response$ and ensure that each scenario is well formedduring the wor6shop

33

8/19/2019 spm notes 1-5%281%29

34/168


%ach sta6eholder e'presses a scenario representing his or her concerns with respect to the systemin

round#ro&in fashion During a nominal F+!, at least two round#ro&in passes are madeso that each

sta6eholder can contri&ute at least two scenarios The facilitators ensure that atleast one representative

scenario e'ists for each architectural driver listed in Step 1Scenario generation is a 6ey step in the F+!

method and must &e carried out with care

!esuggest the following guidance to help F+! facilitators during this step

- ;acilitators should help sta6eholders create well#formed scenarios 0t is tempting forsta6eholders to

recite reuirements such as “The system shall produce reports for users”!hile this is an important

reuirement, facilitators need to ensure that the uality attri&uteaspects of this reuirement are e'plored

further ;or e'ample, the following scenario shedsmore light on the performance aspect of this

reuirement “ remote user re!uests a databasereport via the "eb during peak usage and receives the

report within five seconds.”Jote that the initial reuirement hasn=t &een lost, &ut the scenario further e'plores the performanceaspect of this reuirement ;acilitators should note that uality attri&ute names

&y themselves are not enough )ather than say “ the s#stem shall be modifiable$” the scenarioshould

descri&e what it means to &e modifia&le &y providing a specific e'ample of amodification to the system

vis#Q#vis a scenario

. The voca&ulary used to descri&e uality attri&utes varies widely 9eated de&ates oftenrevolve around

to which uality attri&ute a particular system property &elongs 0t doesn=tmatter what we call a particular

uality attri&ute, as long as there=s a scenario thatdescri&es what it means

;acilitators need to remem&er that there are three general types of scenarios and to ensurethat each

type is covered during the F+!

a use case scenarios # involving anticipated uses of the system

& growth scenarios # involving anticipated changes to the system

c e'ploratory scenarios # involving unanticipated stresses to the system that can includeuses and/or

changes

1 ;acilitators should refer to the list of architectural drivers generated in Step 1 from time totime during

scenario &rainstorming to ensure that representative scenarios e'ist for eachone

Ste 0* S#e"ario Co"solidatio" +fter the scenario &rainstorming, similar scenarios are consolidated when reasona&leTo do that,

facilitators as6 sta6eholders to identify those scenarios that are very similar in contentScenarios that are

similar are merged, as long as the people who proposed them agree andfeels that their scenarios will not

&e diluted in the process *onsolidation is an important step&ecause it helps to prevent a “dilution” of

votes during the prioriti:ation of scenarios (Step K$Such a dilution occurs when sta6eholders split their

votes &etween two very similar scenarios+s a result, neither scenario rises to importance and is therefore

34

8/19/2019 spm notes 1-5%281%29

35/168


never refined (Step C$ 9owever,if the two scenarios are similar enough to &e merged into one, the votes

might &e concentrated,and the merged scenario may then rise to the appropriate level of importance and

&erefined further;acilitators should ma6e every attempt to reach a ma5ority consensus with the

sta6eholders&efore merging scenarios Though sta6eholders may &e tempted to merge scenarios with

a&andon,they should not do so 0n actuality, very few scenarios are merged

Ste :* S#e"ario Prioritiatio"

Prioriti:ation of the scenarios is accomplished &y allocating each sta6eholder a num&er ofvotes eual to

R of the total num&er of scenarios generated after consolidation The actualnum&er of votes allocated

to sta6eholders is rounded to an even num&er of votes at the discretionof the facilitators ;or e'ample, if

scenarios were generated, each sta6eholder gets ', or I, votes rounded up to - "oting is done

in round#ro&in fashion, in two passes Sta6eholders can allocate any num&er oftheir votes to any

scenario or com&ination of scenarios The votes are counted, and the scenariosare prioriti:edaccordingly

Ste ;* S#e"ario Refi"e!e"t

+fter the prioriti:ation, depending on the amount of time remaining, the top four or five scenariosare

refined in more detail ;acilitators further ela&orate each one, documenting the following

;urther clarify the scenario &y clearly descri&ing the following si' things

- stimulus # the condition that affects the system

. response # the activity that results from the stimulus

source of stimulus # the entity that generated the stimulus

1 environment # the condition under which the stimulus occurred

2 artifact stimulated # the artifact that was stimulated

3 response measure # the measure &y which the system=s response will &e evaluated

Descri&e the &usiness/mission goals that are affected &y the scenario

Descri&e the relevant uality attri&utes associated with the scenario

+llow the sta6eholders to pose uestions and raise any issues regarding the scenario Suchuestions

should concentrate on the uality attri&ute aspects of the scenario and any concernsthat the sta6eholders

might have in achieving the response called for in the scenarioSee the e'ample template for scenariorefinement in +ppendi' + This step continues untiltime runs out or the highest priority scenarios have

&een refined Typically, time runs out first

A4> 8e"efits

The F+! provides a forum for a wide variety of sta6eholders to gather in one room at onetime very early

in the development process 0t is often the first time such a meeting ta6es placeand generally leads to the

35

8/19/2019 spm notes 1-5%281%29

36/168

8/19/2019 spm notes 1-5%281%29

37/168


in the appropriate view pac6et or overviewdocumentation Details that e'plain how to transition these

artifacts into architecturaldocumentation is the su&5ect of ongoing research0n addition to the more

immediate &enefits cited a&ove, the scenarios continue to provide &enefitsduring later phases of

development They provide input for analysis throughout the life ofthe system and can &e used to drive

test case development during implementation testing

+. 4"al$sis 3rioritiatio"3a"d trade off 4r#)ite#t're Ce"tri# Develo!e"t Met)od4CDM%

Lust as &lueprints in the &uilding construction industry guides the construction of a &uilding, the software

architecture serves a &lueprint that addresses technical concerns and programmatic issues of a pro5ect

+n architectural focus will

• help refine the functional reuirements, uality attri&ute reuirements, and constraints

• help set and maintain e'pectations in sta6eholders

• define the team structure

• aid in creating more accurate pro5ect estimates

• esta&lish the team voca&ulary

• help identify technical ris6 early

• guide the creation of a more realistic and accurate production schedule and assist in pro5ect

trac6ing and oversight

• provide an early vision of the solution/system

+ num&er of methods have &een created &y the Software %ngineering 0nstitute to help practitioners create

&etter architectures Some of these methods include Fuality +ttri&ute !or6shop (F+!$ ,+rchitecture

Tradeoff +nalysis Method (+T+M$ O, +ttri&ute Driven Design (+DD$ These methods have provided great

value to practitioners trying to &uild &etter architectures 9owever, these methods have two main

pro&lems ;irst, they are intervention oriented These methods were not designed with a particular

development philosophy (lifecycle or process$ in mind +s such, they do not fit neatly into e'isting

development models or processes without significant tailoring

@ittle guidance e'ists that descri&es how to tailor these methods to fit into an organi:ation=s developmentmodel To ma'imi:e their effectiveness, these methods should &e used together and this reuires

significant tailoring 0n order to tailor these methods, someone in an organi:ation has to 6now a great deal

a&out each of them in order to tease them apart, and reassem&le them into a cohesive, usa&le

development method/process This is a ris6y and difficult proposition in many organi:ations The second

pro&lem with these methods is that in their originally authored form they tend to &e heavy#weight and

e'pensive for the smaller teams, pro5ects, short deadlines, and iterative deliveries

8/19/2019 spm notes 1-5%281%29

38/168


hurdles has prevented many organi:ations in industry from em&racing these methods, and more

importantly, adopting the entire &ody of wor6

8/19/2019 spm notes 1-5%281%29

39/168


!hile +*DM emerged from small teams and pro5ects (1 to 3 team mem&ers, - to . year pro5ects$, it is

designed to scale up to meet the needs of larger teams and pro5ects as well 0n larger pro5ects, the +*DM

is used &y a core architecture team to create and refine the overall system architecture The output from

this +*DM cycle is an initial partitioning of the system (or system of systems$ into suelements (or

su&systems$ and their interactions Detailed architecting of the various elements is deferred to smaller

teams, each using +*DM to architect their part of the system (which may &e another system$ @ater

integration of the entire system is underta6en in production stages 3 and K The +*DM has &een evolved

over a five year period (since -III$ on small pro5ects and is now &eing further refined for use on larger

pro5ects in industry

39

8/19/2019 spm notes 1-5%281%29

40/168


4CDM Pre#o"ditio"s

+ precondition to &eginning step - of +*DM is to esta&lish the team roles for pro5ect The

recommended roles and responsi&ilities for +*DM are listed in the ta&le &elow

The +*DM also assumes that the functional reuirements and constraints e'ist &ut does not discuss

in detail how to get them, document them, and organi:e them This may seem somewhat naive &ut

this is intentional since reuirement gathering, documenting, and organi:ation varies widely even in

our small studio pro5ects !hile +*DM does not address the gathering of initial reuirements and

constraints, it will help refine them, clarify them, as the architecture is designed and matures The

relative completeness of the functional reuirements varies from pro5ect to pro5ect and may have to

&e discovered and refined as a conseuence of &uilding the system Some clients provide a

documented list of functional reuirements7 others 5ust &ring ideas to the team The initial gathering of

functional reuirements is assumed to have occurred prior to &eginning step - of +*DM The

reuirements engineer will coordinate the gathering and documenting of functional reuirements The

term “constraints” as applied in this conte't can &e confusing + “constraint” is an imposed design

decision or a design decision that the architect is not at li&erty to ma6e or change %'ample

constraints include &eing forced to use a particular operating system, use a particular commercial off#

the#shelf product, adhere to a particular standard, or &uild a system using a prescri&ed

implementation framewor6

+./ Re&'ire!e"ts do#'!e"tatio" a"d se#ifi#atio"

+ Software re&'ire!e"ts se#ifi#atio" (S)S$, a reuirements specification for a software system, is a

description of the &ehavior of a system to &e developed and may include a set of use cases that descri&e

40

http://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Use_case

8/19/2019 spm notes 1-5%281%29

41/168


interactions the users will have with the software 0n addition it also contains non#functional reuirements

Jon#functional reuirements impose constraints on the design or implementation (such as performance

engineering reuirements, uality standards, or design constraints$

Software reuirements specification esta&lishes the &asis for agreement &etween customers and

contractors or suppliers (in mar6et#driven pro5ects, these roles may &e played &y the mar6eting and

development divisions$ on what the software product is to do as well as what it is not e'pected to do

Software reuirements specification permits a rigorous assessment of reuirements &efore design can

&egin and reduces later redesign 0t should also provide a realistic &asis for estimating product costs,

ris6s, and schedules

The software reuirements specification document enlists enough and necessary reuirements that are

reuired for the pro5ect developmentTo derive the reuirements we need to have clear and thorough

understanding of the products to &e developed or &eing developed This is achieved and refined with

detailed and continuous communications with the pro5ect team and customer till the completion of the

software

+.0 C)a"(e !a"a(e!e"t

=lo6aliatio" and the constant innovation of te#)"olo($ result in a constantly evolving &usiness

environment Phenomena such as social media and mo&ile adapta&ility have revolutioni:ed &usiness and

the effect of this is an ever increasing need for change, and therefore change management The growth in

technology also has a secondary effect of increasing the availa&ility and therefore accounta&ility of

6nowledge %asily accessi&le information has resulted in unprecedented scrutiny from stoc6holders and

the media and pressure on management

!ith the &usiness environment e'periencing so much change, organi:ations must then learn to &ecome

comforta&le with change as well Therefore, the a&ility to manage and adapt to organi:ational change is

an essential a&ility reuired in the wor6place today et, ma5or and rapid organi:ational change is

41

http://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Social_mediahttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Social_media

8/19/2019 spm notes 1-5%281%29

42/168


profoundly difficult &ecause the structure, culture, and routines of organi:ations often reflect a persistent

and difficult#to#remove AimprintA of past periods, which are resistant to radical change even as the current

environment of the organi:ation changes rapidlyB-O

Due to the growth of technology, modern organi:ational change is largely motivated &y e'terior

innovations rather than internal moves !hen these developments occur, the organi:ations that adapt

uic6est create a competitive advantage for themselves, while the companies that refuse to change get

left &ehind This can result in drastic profit and/or mar6et share losses

8/19/2019 spm notes 1-5%281%29

43/168


+s a multi#disciplinary practice that has evolved as a result of scholarly research, organi:ational change

management should &egin with a systematic diagnosis of the current situation in order to determine &oth

the need for change and the capa&ility to change The o&5ectives, content, and process of change should

all &e specified as part of a *hange Management plan

*hange management processes should include creative mar6eting to ena&le communication &etween

changing audiences, as well as deep social understanding a&out leadership=s styles and group dynamics

+s a visi&le trac6 on transformation pro5ects,

8/19/2019 spm notes 1-5%281%29

44/168


• Personality !ide *hanges

+.: Tra#ea6ilit$ of re&'ire!e"ts

Tra#ea6ilit$ is the a&ility to verify the history, location, or application of an item &y means of documented

recorded identification

G (JP@$ the Jational 0nstitute of Standards and Technology (J0ST$ in

the >S+, the Physi6alisch#Technische4undesanstalt (PT4$ in ermany, and the 0stitutoJa:ionale di

)icercaMetrologica (0J)iM$ in 0taly +s defined &y J0ST, ATracea&ility of measurement reuires the

esta&lishment of an un&ro6en chain of comparisons to stated references each with a stated uncertaintyA

@ogistics

0n logistics, tracea&ility refers to the capa&ility for tracing goods along the distri&ution chain on

a &atch num&er or series num&er &asis Tracea&ility is an important aspect for e'ample in the automotive

industry, where it ma6es recalls possi&le, or in the food industry where it contri&utes to food safety

The international standards organi:ation %P*glo&al under S- has ratified the %P*glo&al

Jetwor6 standards (especially the %P* 0nformation Services %P*0S standard$ which codify the synta'

44

http://en.wikipedia.org/wiki/Measuring_instrumenthttp://en.wikipedia.org/wiki/Measurementhttp://en.wikipedia.org/wiki/Standard_(metrology)http://en.wikipedia.org/wiki/Calibrationhttp://en.wikipedia.org/wiki/Accuracy_and_precisionhttp://en.wikipedia.org/wiki/Accuracyhttp://en.wikipedia.org/wiki/Chain_of_custodyhttp://en.wikipedia.org/wiki/Calibrationhttp://en.wikipedia.org/wiki/National_Physical_Laboratory,_UKhttp://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technologyhttp://en.wikipedia.org/wiki/Physikalisch-Technische_Bundesanstalthttp://en.wikipedia.org/w/index.php?title=Istituto_Nazionale_di_Ricerca_Metrologica&action=edit&redlink=1http://en.wikipedia.org/w/index.php?title=Istituto_Nazionale_di_Ricerca_Metrologica&action=edit&redlink=1http://en.wikipedia.org/wiki/Logisticshttp://en.wikipedia.org/wiki/Batch_productionhttp://en.wikipedia.org/wiki/Food_safetyhttp://en.wikipedia.org/wiki/EPCglobalhttp://en.wikipedia.org/wiki/GS1http://en.wikipedia.org/wiki/EPCglobal_Networkhttp://en.wikipedia.org/wiki/EPCglobal_Networkhttp://en.wikipedia.org/wiki/EPCIShttp://en.wikipedia.org/wiki/Measuring_instrumenthttp://en.wikipedia.org/wiki/Measurementhttp://en.wikipedia.org/wiki/Standard_(metrology)http://en.wikipedia.org/wiki/Calibrationhttp://en.wikipedia.org/wiki/Accuracy_and_precisionhttp://en.wikipedia.org/wiki/Accuracyhttp://en.wikipedia.org/wiki/Chain_of_custodyhttp://en.wikipedia.org/wiki/Calibrationhttp://en.wikipedia.org/wiki/National_Physical_Laboratory,_UKhttp://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technologyhttp://en.wikipedia.org/wiki/Physikalisch-Technische_Bundesanstalthttp://en.wikipedia.org/w/index.php?title=Istituto_Nazionale_di_Ricerca_Metrologica&action=edit&redlink=1http://en.wikipedia.org/w/index.php?title=Istituto_Nazionale_di_Ricerca_Metrologica&action=edit&redlink=1http://en.wikipedia.org/wiki/Logisticshttp://en.wikipedia.org/wiki/Batch_productionhttp://en.wikipedia.org/wiki/Food_safetyhttp://en.wikipedia.org/wiki/EPCglobalhttp://en.wikipedia.org/wiki/GS1http://en.wikipedia.org/wiki/EPCglobal_Networkhttp://en.wikipedia.org/wiki/EPCglobal_Networkhttp://en.wikipedia.org/wiki/EPCIS

8/19/2019 spm notes 1-5%281%29

45/168


and semantics for supply chain events and the secure method for selectively sharing supply chain events

with trading partners These standards for tracea&ility have &een used in successful deployments in many

industries and there are now a wide range of products that are certified as &eing compati&le with these

standards

Materials

0n materials, tracea&ility refers to the capa&ility to associate a finished part with destructive test results

performed on material from the same ingot with the same heat treatment, or to associate a finished part

with results of a test performed on a sample from the same melt identified &y the uniue lot num&er of the

material Destructive tests typically include chemical composition and mechanical strength tests + heat

num&er is usually mar6ed on the part or raw material which identifies the ingot it came from, and a lot

num&er may identify the group of parts that e'perienced the same heat treatment (ie, were in the same

oven at the same time$ Material tracea&ility is important to the aerospace, nuclear, and process industry

&ecause they freuently ma6e use of high strength materials that loo6 identical to commercial low

strength versions 0n these industries, a part made of the wrong material is called Acounterfeit,A even if the

su&stitution was accidental

Supply chain

0n the supply chain, tracea&ility is more of an ethical or environmental issue %nvironmentally friendly

retailers may choose to ma6e information regarding their supply chain freely availa&le to customers,

illustrating the fact that the products they sell are manufactured in factories with safe wor6ing conditions,

&y wor6ers that earn a fair wage, using methods that do not damage the environment

Software development

0n software development, the term tracea&ility (or )euirements Tracea&ility$ refers to the a&ility to lin6

product reuirements &ac6 to sta6eholdersH rationales and forward to corresponding design artifacts,

code, and test cases Tracea&ility supports numerous software engineering activities such as

change impact analysis, compliance verification or trace&ac6 of code, regression test selection, and

reuirements validation 0t is usually accomplished in the form of a matri' created for the verification and

validation of the pro5ect >nfortunately the practice of constructing and maintaining a reuirements trace

matri' ()TM$ can &e very arduous and over time the traces tend to erode into an inaccurate state unless

45

http://en.wikipedia.org/w/index.php?title=Materials&action=edit&redlink=1http://en.wikipedia.org/wiki/Heat_numberhttp://en.wikipedia.org/wiki/Heat_numberhttp://en.wikipedia.org/wiki/Supply_chainhttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Requirements_Traceabilityhttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Change_impact_analysishttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Verification_and_Validationhttp://en.wikipedia.org/wiki/Verification_and_Validationhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/w/index.php?title=Materials&action=edit&redlink=1http://en.wikipedia.org/wiki/Heat_numberhttp://en.wikipedia.org/wiki/Heat_numberhttp://en.wikipedia.org/wiki/Supply_chainhttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Requirements_Traceabilityhttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Change_impact_analysishttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Verification_and_Validationhttp://en.wikipedia.org/wiki/Verification_and_Validationhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Traceability_matrix

8/19/2019 spm notes 1-5%281%29

46/168


date/time stamped +lternate automated approaches for generating traces using information

retrieval methods have &een developed

0n transaction processing software, tracea&ility implies use of a uniue piece of data (eg, order date/time

or a seriali:ed seuence num&er$ which can &e traced through the entire software flow of all relevant

application programs Messages and files at any point in the system can then &e audited for correctness

and completeness, using the tracea&ility 6ey to find the particular transaction This is also sometimes

referred to as the transaction footprint

;ood processing

0n food processing (meat processing, fresh produce processing$, the term tracea&ility refers to therecording through means of &arcodes or );0D tags other trac6ing media, all movement of product and

steps within the production process

8/19/2019 spm notes 1-5%281%29

47/168


Mostly led out of %urope, and targeting countries where illegal logging has &een a 6ey pro&lem

(;@%T countries$, tim&er trac6ing is now part of daily &usiness for many enterprises and 5urisdictions

;ull tracea&ility offers advantages for multiple partners along the supply chain &eyond certification

systems, including

• Mechanism to comply with local and international policies and regulations

• )educing the ris6 of illegal or non#compliant material entering the supply chains

• Providing coordination &etween authorities and relevant &odies

• +llowing automatic reconciliation of &atches and volumes availa&le

•

8/19/2019 spm notes 1-5%281%29

48/168


advance, which could prevent the pro5ect from meeting one or more of its

o&5ectives

0ssue +n event or circumstance that has occurred with pro5ect impact that needs to

&e managed and resolved, with escalation if appropriate

Tas6 / +ction

0tem

!or6 pac6ages from the !or6 4rea6down Structure (!4S$ or wor6 resulting

from pro5ect meetings or conversations

Ris5 Ma"a(e!e"t 4roa#)

The pro5ect team will implement a continuous ris6 management process which entails two ma5or

processes E ris6 assessment and ris6 mitigation

)is6 assessment includes activities to identify ris6s, analy:e and prioriti:e )is6 mitigation includes

developing ris6 contingency and mitigation strategies, as well as monitoring the impact of the issue, actionitems, strategies and residual ris6s

Ris5 Tolera"#e

The company has a very low threshold for ris6s to

o The client e'perience

o The e'perience of users who directly support the client

o Jon#pu&lic information (JP0$

o Potential for fraud or loss related to insufficient control or security

Ris5 Ma"a(e!e"t Tas5s

)is6 Management activities are documented in the )is6 Management wor6&oo6 The wor6&oo6 is used

to identify, prioriti:e, analy:e, and plan a ris6 response

)is6 0dentification The process of determining which ris6s may affect the pro5ect and documenting their

characteristics

48

Communicati

Risk

Monitoring

and Control

Risk

Response

Planning

Risk Analysis

and

Prioritization

Risk

Identifcatio

n

8/19/2019 spm notes 1-5%281%29

49/168


• Ris5 4ssess!e"t*The )is6 +ssessement and Mitigation ta& in the )is6 Management

wor6&oo6 has a set of uestions that need to &e answered that help determine the ris6 level

of the pro5ect %ach uestion has a potential rating of 9igh, Medium, or @ow in terms of

potential impact

• Ris5 Re(ister* This is located on the pro5ect=s SharePoint site where pro5ect specific ris6s

can &e entered +ll ris6s identified through any means should &e entered individually in the

)is6 )egister on SharePoint @i6e all company documentation, discretion should &e used in

documenting ris6 all statements should &e fact#&ased and conclusions should &e reviewed

&y management (and if appropriate, @egal$ )is6s should &e stated in a standard format, to

help the team stay focused on ris6s versus root causes and results *ause E )is6 E %ffect

o *ause specific situation that introduces ris6

o )is6 uncertain event that can impact the pro5ect

o %ffect potential conseuences of the ris6 occurring

%&ample: shortage of skilled 'usiness nal#sts (cause) could result in man# missed

re!uirements (risk)$ leading to rework or customer dis

spm notes 1-5%281%29

Documents