iteration devpt

8/12/2019 Iteration DEvpt

1/67

Systems Analysis and Design5th Edition

Chapter 4. Use Case Analysis

Roberta Roth, Alan Dennis, and Barbara Haley Wixom

4-0 Copyright 2011 John Wiley & Sons, Inc.


2/67

BBC

4-1


3/67

British Broadcasting Corporation

Project type : Digital archiveProject name : The Digital Media InitiativeDate : May 2013 Cost : 100MThe BBCs archive of broadcast materials is unparalleledand as production continues to this day since 1922, thecorporation has one of the largest archives of mediamaterials in the world.In 2008, BBC initiated the Digital Media Initiative ( DMI),which was intended to provide a single tool that wouldenable video and radio production from raw materialsthrough to final edit.

4-2


4/67

Lack of Clarity in Requirements

No tender process Without going through a formal tender process, the contract to

develop DMI was awarded to the BBCs existing technology provider(Siemens) in 2008.

Fixed price contract source of being lack of clarityin requirements

The fixed price contract established a plan that would see the projectcompleted in 18 months at a cost 82M.

In theory, a fixed priced contract protects the buyer from costoverruns.

In practice, this is not always the case as lack of clarity inrequirements, changing needs and other real world complicationsoften leave the door open to continual changes that can impact

delivery dates and costs. 4-3


5/67

Aftermath

No-fault termination of the contract in Jul2009 end of 18-month contractBecoming an in house project

No accurate picture of the projects true status being given tothe BBC Trust

Results: Failure to deliver a working system Project being abandoned in May 2013 100M being written off

Reference: Why Projects Fail: British Broadcasting Corporation, Sept 2, 2013

http://calleam.com/WTPF/?p=5998 4-4
http://calleam.com/WTPF/?p=5998http://calleam.com/WTPF/?p=5998


6/67

New Zealand Ministry ofEducation

4-5


7/67

New Zealand Ministry of Education

Project type : Payroll systemProject name : NovopayDate : Sep 2012 May 2013 Cost : $30M NZDThe Novopay system was intended to be a tool that would

streamline payments to the 110,000 teachers, administrators andstaff throughout New Zealands educational system.2005 Decision

The project had its origins in a 2005 decision.

2010 Being Implemented, Originally

Following a bid process, Australias Talent2 was selected to both implement the new systemand then operate it on a service contract basis until 2020.

Delay till Aug 2012 The original project called for the system to be implemented in 2010, but following a number

of delays the project only reached operationally status in Aug of 2012.

4-6


8/67

Operational Problems

Some school employees reported receivingincorrect payments while others were paidnothing at all.Dubbed the Novopay debacle, at one pointaffected staff had reported more than 18,000payroll errors and the operational staff

supporting the system appear to have beenoverwhelmed by the amount of manualintervention needed to correct those errors.

4-7


9/67

Failure Factors

Tracking and analysis of the errors identified after thelaunch, identified more than 500 distinct defects in thesystem.Of those 44 were deemed to be very serious.In Aug of 2012 when the system went live reports indicatethat only 147 defects were known meaning that QualityAssurance testing had failed to identify several hundredproblems in the system.Many of those problems were traced back to errors in theoriginal project requirements and the design of the newsystem that allowed incorrect data to be entered into thesystem thereby leading to incorrect payroll payments and

related problems. 4-8


10/67

Aftermath

Affecting daily life Those problems continued to grow and the issues became headline

news in New Zealand as affected employees struggled to maintaintheir personal finances in the face of the cash flow problems the

systems failures were causing.Result:

A Mar 2013 review performed by Deloitte raised serious questionsabout the stability of the system and outlined a 1-year remedial planthat needed to be followed to ensure the operational stability of thesystem and that the originally planned business benefits were realized.

Reference: Why Project Fail: New Zealand Ministry of Education, May 28, 2013

http://calleam.com/WTPF/?p=5835

4-9
http://calleam.com/WTPF/?p=5835http://calleam.com/WTPF/?p=5835


11/67

US DoD US Air Force

4-10


12/67

US Department of Defense U.S. Air Force

Project type : Integrated supply chain and logisticssystemProject name : Expeditionary Combat Support

System (ECSS)Date : Nov 2012, Cost :$1BIssues:

The Air Force IT environment consisting of over 700 systems

Many being duplicative, stand-alone and ineffective A multitude of metrics with competing goals Non-standardized reporting causing credibility issues and time-

inefficiencies Limited visibility across the supply chain

4-11


13/67


14/67

Problems

By 2010, signs of major problems had surfaced.Between 2010 and early 2012, the project had beenthrough no less than three project resets.

No results even spending more time & money By 2012, the Air Force had determined that the $1B spent to date had

yielded negligible benefits and if they proceeded they would need$1.1B more to deploy just 25% of the original scope.

Even with such a scaled back proposal, deployment would be pushed

back to 2020 meaning that significant additional work and riskremained.

Deciding to scrap it Recognizing that a partial solution negated the overall vision of an

integrated system, the Air Force scrapped the Project in Nov 2012.4-13


15/67

Failure Factors

Failure to baseline existing practices and to establisheffective measures for the desired outcomesFailure to establish an effective governance structure

Selecting an Oracle based Commercial-Off-the-Shelf(COTS) based product that was a poor fit for theproject requirementsLack of experience in large scale, complex integrated

systems development and deploymentOrganizational silosFailure to effectively engage all affected stakeholdersLack of collaboration and a lack of understanding ofchange management 4-14


16/67

Aftermath

For the $1B spent, nothing could be saved.$1 billion wasted on Air Force computersystem, NBC Nightly News, February 08,2013

http://www.nbcnews.com/video/nightly-news/50749586#50749586

http://www.youtube.com/watch?v=M_x_E4UkgV0 Reference:

Why Projects Fail: US Department of Defense US AirForce

http://www.youtube.com/watch?v=M_x_E4UkgV0 4-15
http://www.nbcnews.com/video/nightly-news/50749586http://www.nbcnews.com/video/nightly-news/50749586http://localhost/var/www/apps/conversion/tmp/scratch_9/Air%20Force%20Scraps%20_Expeditionary%20Combat%20Support%20System_%20After%20$1.03%20Billion%20In%20Costs%20Since%202005(360p_H.264-AAC).mp4http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://localhost/var/www/apps/conversion/tmp/scratch_9/Air%20Force%20Scraps%20_Expeditionary%20Combat%20Support%20System_%20After%20$1.03%20Billion%20In%20Costs%20Since%202005(360p_H.264-AAC).mp4http://www.nbcnews.com/video/nightly-news/50749586http://www.nbcnews.com/video/nightly-news/50749586http://www.nbcnews.com/video/nightly-news/50749586http://www.nbcnews.com/video/nightly-news/50749586


17/67

US Census Bureau Field DataCollection Automation (FDCA)

4-16


18/67

US Census Bureau Field DataCollection Automation (FDCA)

Project type : Field Data CollectionProject name : Field Data Collection

Automation (FDCA)Date : Apr 2008, Cost :$595MIssues:

Due to concerns about escalating costs and questionsabout the accuracy of the data being collected, in2001 the US Census Bureau decided to undertake amajor modernization program in preparation for the

2010 census. 4-17


19/67

IT Development

Having first attempted to do the project in-house, field testing in 2004 demonstrated thatthe project was more complex than anticipated.As a result the Bureau changed direction andengaged an external provider to complete theproject.

Taking a further year to get the Request forProposal published time remaining before dressrehearsals in 2006 and 2008 was running short.

4-18


20/67

Failure Factors

Underestimation of complexity.The projects problems continued even after engaging anoutside supplier to complete the work.Lack of due diligence on behalf of the Bureau and failure toestablish effective communications with the supplierresulted in a significant number of missing requirements.Failure to establish and stabilize requirements resulting insignificant requirements volatility (at one point 400 plus

change orders had been raised).Despite warnings from external auditors the problems wereallowed to persist and ultimately time ran out.

4-19


21/67

Aftermath

The Bureau was left with no choice otherthan reverting back to using pen and paper.The failure of the project resulted in theBureau having to request an addition $3B infunding to complete the work using theexisting manual procedures.

Reference: US Census Field Data Collection Automation Case Study Why Project Fail: US Census Bureau Field Data Collection

Automation (FDCA) Case Study http://calleam.com/WTPF/?p=1894

4-20
http://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/WTPF/?p=1894http://calleam.com/WTPF/?p=1894http://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdf


22/67

4-21


23/67


24/67

System

Advanced Information Based Allocation (AIBA), an intelligentdispatch and fleet management system is utilized to allocate abooking to the most appropriate vehicle (including bicycles,motorbikes and vans of varying sizes) and sends a message to the

courier to alert them to the job through their handheld terminal.Couriers are rewarded and motivated with high pay for the servicelevels they provide, supported by the technology, thus rendering acourier service that is reliable, trustworthy and transparent.In addition to systems for employees, the customer has been

provided with a real time tracking of their parcel on a map, utilizingGPS technology.eCourier.co.uk Demo

http://www.youtube.com/watch?v=92pxg91HYbE

4-23
http://localhost/var/www/apps/conversion/tmp/scratch_9/eCourier.co.uk%20Demo(360p_H.264-AAC).mp4http://www.youtube.com/watch?v=92pxg91HYbEhttp://www.youtube.com/watch?v=92pxg91HYbEhttp://www.youtube.com/watch?v=92pxg91HYbEhttp://localhost/var/www/apps/conversion/tmp/scratch_9/eCourier.co.uk%20Demo(360p_H.264-AAC).mp4


25/67

eCouriers Success Factors

Building a well structured teamDefining success criteria clearly withstakeholders

Understanding market needs Its especially important for being a first -mover

Understanding and managing technical issuesManaging the project through the proposedcontrol cycleReference:

Case Study of Successful Complex IT Projects - BCS

4-24
http://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdf


26/67

What Makes Projects Succeed?

How often do projects succeed?

Reference: What M akes Projects Succeed ? Synergy Profe ssional

Services, http://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdf 4-25
http://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdf


27/67

Common Success Factors

Customer InvolvementAgreement on the goals of the projectFrequent progress checks and coursecorrectionsA plan that shows overall path andresponsibilitiesConstant and effective communicationto everyoneControlled scope

Management support 4-26


28/67

Common Failure Causes RegardingRequirements Engineering

Lack of formality in the scope definition process results invagueness and different people having differentunderstandings of what is in and what is out of scopeVague or open ended requirements (such as requirementsthat end with etc ) Failure to address excessive scope volatility oruncontrolled scope creepFailure to fully understand the operational context in

which the product being produced needs to function oncethe project is overRequirements are defined by an intermediary withoutdirectly consulting or involving those who will eventually

use the product being produced 4-27


29/67

Common Failure Causes RegardingRequirements Engineering (cont.)

Individual requirements are never vetted against theprojects overall objectives to ensure each requirementsupports the projects objective and has a reasonable Returnon Investment (ROI)The project requirements are written based on theassumption that everything will work as planned.Requirements to handle potential problems or morechallenging situations that might occur are never considered

Failure to broker agreement between stakeholders withdiffering perspectives or requirements.Reference:

Why Projects Fail: 101 Common Causes,http://calleam.com/WTPF/?page_id=2338

4-28
http://calleam.com/WTPF/?page_id=2338http://calleam.com/WTPF/?page_id=2338http://calleam.com/WTPF/?page_id=2338


30/67

Five Common Issues inRequirements Analysis

Customers don't (really) know what they wantRequirements change during the course of theproject

Customers have unreasonable timelinesCommunication gaps exist between customers,engineers and project managersThe development team doesn't understand the

politics of the customer's organizationReference:

Five common errors in requirements analysis (and how to avoid them) http://www.techrepublic.com/article/five-common-errors-in-

requirements-analysis-and-how-to-avoid-them/ 4-29
http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/


31/67

Solving Issues about CustomersBeing Uncertain

Ensure that you spend sufficient time at the start of the project onunderstanding the objectives, deliverables and scope of the project .Make visible any assumptions that the customer is using, andcritically evaluate both the likely end-user benefits and risks of the

project.Attempt to write a concrete vision statement for the project, whichencompasses both the specific functions or user benefits it providesand the overall business problem it is expected to solve.Get your customer to read , think about and sign off on the

completed software requirements specification, to alignexpectations and ensure that both parties have a clearunderstanding of the deliverable.

4-30


32/67

Solving Issues about ChangingRequirements

Have a clearly defined process for receiving,analyzing and incorporating change requests, andmake your customer aware of his/her entry point

into this process.Set milestones for each development phase beyondwhich certain changes are not permissible -- forexample, disallowing major changes once a module

reaches 75 percent completion.Ensure that change requests (and approvals) areclearly communicated to all stakeholders , togetherwith their rationale, and that the master project planis updated accordingly. 4-31


33/67

Solving Issues aboutUnreasonable Timelines

Convert the software requirements specification into aproject plan , detailing tasks and resources needed at eachstage and modeling best-case, middle-case and worst-casescenarios.Ensure that the project plan takes account of availableresource constraints and keeps sufficient time for testingand quality inspection.Enter into a conversation about deadlines with your

customer , using the figures in your draft plan as supportingevidence for your statements. Assuming that your plan isreasonable, it's quite likely that the ensuing negotiation willbe both productive and result in a favorable outcome for

both parties. 4-32


34/67

Solving Issues aboutCommunication Gaps

Take notes at every meeting anddisseminate these throughout theproject team.Be consistent in your use of words .Make yourself a glossary of the termsthat you're going to use right at thestart, ensure all stakeholders have acopy, and stick to them consistently.

4-33


35/67

Solving Issues about Not Familiarwith Politics in Customers Site

Review your existing network and identify both theinformation you need and who is likely to have it.Cultivate allies, build relationships and think

systematically about your social capital in theorganization.Persuade opponents within your customer'sorganization by framing issues in a way that is

relevant to their own experience.Use initial points of access/leverage to move youragenda forward.

4-34


36/67

Chapter 4 Outline

Use Cases

Elements of a use case.Alternative use case formats.Use cases and functional requirements.Use cases and testing.Building use cases.

Copyright 2011 John Wiley & Sons, Inc. 4-35


37/67

INTRODUCTION

Use cases are a means of expressing userrequirements.Use cases are used extensively in the analysis phase.

A use case represents how a system interacts with itsenvironment by illustrating the activities that areperformed by the users and the systems responses. The text-based use case is easy for the users to

understand, and also flows easily into the creation ofprocess models and the data model.



38/67

USE CASES

A use case depicts a set of activities that producesome output result.Each use case describes how an external user

triggers an event to which the system mustrespond.With this type of event-driven modeling , everything in the system can be thought of as aresponse to some triggering event.Creation of use cases is often done as a part ofinterview session with users or a part of JADsessions.



39/67

Elements of a Use Case

Basic InformationEach use case has a name and number , and briefdescription.

The priority may be assigned to indicate the relativesignificance.The actor refers to a person, another system, or ahardware device that interacts with the system to

achieve a useful goal.The trigger for the use case the event that causesthe use case to begin.



40/67

Example



41/67

Example: Basic Information



42/67

Preconditions

It is common practice to create smaller,more focused use cases breaking the

whole process down into parts.It is important to define clearly whatneeds to be accomplished before each

use case begins. The preconditions define the state thesystem must be in before the use case

commences. Copyright 2011 John Wiley & Sons, Inc. 4-41


43/67

Example: Preconditions



44/67

Normal Course

The next part of a use case is thedescription of the major steps that

are performed to execute theresponse to the event , the inputsused for the steps, and the outputs produced by the steps.The normal course lists the steps.



45/67

Example: Normal Course



46/67


47/67


48/67

Postconditions

The postconditions section ofdefines the final product of the use

case.These postconditions also serve todefine the preconditions for the nextuse case in the series.



49/67

Example: Postconditions



50/67


51/67

Example: Exceptions



52/67

Summary of Inputs and Outputs

The final section of the use casesummarizes the set of major inputs

and outputs of the use case, alongwith their source or destination.


E l S f I &


53/67

Example: Summary of Inputs &Outputs



54/67

Additional Use Case Issues

Additional sections may be included,e.g.,

- Frequency of use- Business rules- Special requirements- Assumptions- Notes and issues



55/67

Chain of use cases an example



56/67

Alternative Use Case Formats

A full-dressed use case is verythorough, detailed, and highly

structured. The project team may decide that amore casual use case format isacceptable.


Example: An Alternative Case Format


57/67


U C d h F i l


58/67

Use Cases and the FunctionalRequirements

Use cases are very useful tools to us to understanduser requirements. However, use cases only conveythe users point of view.

Transforming the users view into the developersview by creating functional requirements is one ofthe important contributions of system analyst.

The derived functional requirements give moreinformation to the developer about what the systemmust do.


Example: Functional Requirements


59/67

p q



60/67

St 2 Id tif th j t f


61/67

Step 2: Identify the major steps foreach use case



62/67


63/67

Step 4. Confirm the use case


Revise functional requirements based


64/67

Revise functional requirements basedon use cases

The functional requirements in therequirements definition may be

modified to reflect the more detailedunderstanding and to provide insightto the development team on some

back -end processing.


Example: Revising Functional Requirements


65/67



66/67

SUMMARY

A use case contains all the information neededto build one part of a process model, expressedin an informal, simple way.

When writing a use case,- identify the triggering event,- develop a list of the major steps,- identify the input(s) and output(s) for everystep,- have the users role-play the use case to verify.



67/67

Copyright 2011 John Wiley & Sons, Inc.

All rights reserved. Reproduction or translation of this workbeyond that permitted in Section 117 of the 1976 United StatesCopyright Act without the express written permission of thecopyright owner is unlawful. Request for further informationshould be addressed to the Permissions Department, John Wiley& Sons, Inc. The purchaser may make back-up copies for his/herown use only and not for redistribution or resale. The Publisherassumes no responsibility for errors, omissions, or damages,caused by the use of these programs or from the use of theinformation contained herein.

Notes : Each symbol used in this slide set links to a video file downloadedfrom YouTube. However, all locally linked videos are not stored in the classwebsite. They can all be accessed through corresponding YouTube links.

iteration devpt

Documents