chapters 5‐6‐7 - emory university biology department · hill, 2009). slides copyright 2009 by...
TRANSCRIPT
Chapter05:QualityFuncGonDeployment
• FuncGondeploymentdeterminesthe“value”(asperceivedbythecustomer)ofeachfuncGonrequiredofthesystem
• InformaGondeploymentidenGfiesdataobjectsandevents• Taskdeploymentexaminesthebehaviorofthesystem
• ValueanalysisdeterminestherelaGvepriorityofrequirements
CS‐584/Fall2009/EmoryU 2
3
PlanningPrinciples(fromChapter04)
• Principle #1. Understand the scope of the project. It’s impossible to use a roadmap if you don’t know where you’re going. Scope provides the software team with a destination.
• Principle #2. Involve the customer in the planning activity. The customer defines priorities and establishes project constraints.
• Principle #3. Recognize that planning is iterative. A project plan is never engraved in stone. As work begins, it very likely that things will change.
• Principle #4. Estimate based on what you know. The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of the work to be done.
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009)Slidescopyright2009byRogerPressman.
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009)Slidescopyright2009byRogerPressman. 4
PlanningPrinciples(fromChapter04)
• Principle #5. Consider risk as you define the plan. If you have identified risks that have high impact and high probability, contingency planning is necessary.
• Principle #6. Be realistic. People don’t work 100 percent of every day. • Principle #7. Adjust granularity as you define the plan. Granularity
refers to the level of detail that is introduced as a project plan is developed.
• Principle #8. Define how you intend to ensure quality. The plan should identify how the software team intends to ensure quality.
• Principle #9. Describe how you intend to accommodate change. Even the best planning can be obviated by uncontrolled change.
• Principle #10. Track the plan frequently and make adjustments as required. Software projects fall behind schedule one day at a time.
RequirementsvsExpectaGons
• Customers“expect”theproducttodocertainthings– SomeareclearlystatedexpectaGons– Othersareassumedbutnotstated– FiguringouttheassumpGonsiswheretherealchallengelies
• ExpectaGonsleadtorequirementsspecificaGon– Inputs+acGononinputsoutputs– Eachhasconsequencesfordesign&implementaGon– Somerequirementsmayneedtobere‐thought,re‐defined,orpostponed
• Thisfirst“negoGaGon”withthecustomermustbemanagedwithaneyetowardrealisGcproducGon– Gettherequirements– UnderstandtheimplicaGons– Assessfeasibility– Thenreturnwithaproposal(releaseplan)– Validateplan
CS‐584/Fall2009/EmoryU 5
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
6
Chapter05:UML&Use‐Cases
• UML(UnifiedModelingLanguage)usedtomodelmanykindsofsystems• BasedonconceptofuserinteracGngwithsystem–hardwareandsofware• UseCase:AcollecGonofuserscenariosthatdescribethethreadofusageofasystem• Eachscenarioisdescribedfromthepoint‐of‐viewofan“actor”—apersonordevicethat
interactswiththesofwareinsomeway• EachscenarioanswersthefollowingquesGons:
– Whoistheprimaryactor,thesecondaryactor(s)?– Whataretheactor’sgoals?– WhatprecondiGonsshouldexistbeforethestorybegins?– WhatmaintasksorfuncGonsareperformedbytheactor?– Whatextensionsmightbeconsideredasthestoryisdescribed?– WhatvariaGonsintheactor’sinteracGonarepossible?– WhatsysteminformaGonwilltheactoracquire,produce,orchange?– Willtheactorhavetoinformthesystemaboutchangesintheexternalenvironment?– WhatinformaGondoestheactordesirefromthesystem?– Doestheactorwishtobeinformedaboutunexpectedchanges?
7
Chapter05:UMLUse‐CaseDiagram
homeowner
Arms/disarmssystem
Accesses systemvia Internet
Reconfigures sensorsand related
system features
Responds toalarm event
Encounters anerror condition
systemadministrator
sensors
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
8
Chapter05:UMLClassDiagram
Sensor
name/idtypelocationareacharacteristics
identify()enable()disable()reconfigure()
From the SafeHome system …
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
9
Chapter05:UMLStateDiagramReading
Commands
Systemstatus=“ready”Displaymsg=“entercmd”Displaystatus=steady
Entry/subsystemsreadyDo:polluserinputpanelDo:readuserinputDo:interpretuserinput
Statename
Statevariables
StateacGviGes
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
Chapter06:ModelingtheRequirements
• Scenario‐basedmodels
• Datamodels• Class‐orientedmodels
• Flow‐orientedmodels• Behavioralmodels
CS‐584/Fall2009/EmoryU 10
DFD:DataFlowDiagram
Chapter06:UMLAcGvity&SwimlaneDiagrams
SwimlaneDiagram
CS‐584/Fall2009/EmoryU 11
enter passwordand user ID
select major function
valid passwords/ID
prompt for reentry
invalid passwords/ID
input tries remain
no inputtries remain
select surveillance
other functionsmay also be
selected
thumbnail views select a specific camera
select camera icon
prompt foranother view
select specificcamera - thumbnails
exit this function see another camera
view camera outputin labelled window
enter passwordand user ID
select major function
valid passwords/ID
prompt for reentry
invalidpasswords/ID
input triesremain
no inputtries remain
select surveillance
other functionsmay also be
selected
thumbnail views select a specific camera
select camera icon
generate videooutput
select specificcamera - thumbnails
exit thisfunction
seeanothercamera
h om e own e r c a m e ra i n t e rf a c e
prompt foranother view
view camera outputin labelled window
AcGvityDiagram
12
Chapter06:DataModeling
• examinesdataobjectsindependentlyofprocessing
• focusesalenGononthedatadomain• createsamodelatthecustomer’slevelofabstracGon
• indicateshowdataobjectsrelatetooneanother
13
Chapter06:WhatisaDataObject?
• a representation of almost any composite information that must be understood by software. – composite information—something that has a number of different
properties or attributes • can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file).
• The description of the data object incorporates the data object and all of its attributes.
• A data object encapsulates data only—there is no reference within a data object to operations that act on the data.
15
Chapter06:WhatisaRelaGonship?
• Data objects are connected to one another in different ways. – A connection is established between person and car because
the two objects are related. • A person owns a car • A person is insured to drive a car
• The relationships owns and insured to drive define the relevant connections between person and car.
• Several instances of a relationship can exist • Objects can be related in many different ways
16
Chapter06:ERDNotaGon(EnGty‐RelaGonshipDiagram)
(0,m) (1,1)
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
17
Chapter06:BuildinganERD
• Level1—modelalldataobjects(enGGes)andtheir“connecGons”tooneanother
• Level2—modelallenGGesandrelaGonships• Level3—modelallenGGes,relaGonships,andthe
alributesthatprovidefurtherdepth
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
18
Chapter06:AnERDExample
(1,1) (1,m)placesCustomer
requestforservice
generates(1,n)
(1,1)
workorder
worktasks
materials
consistsof
lists
(1,1)(1,w)
(1,1)
(1,i)
selectedfrom
standardtasktable
(1,w)
(1,1)
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
19
Chapter06:Class‐BasedModeling
• Class-based modeling represents: – objects that the system will manipulate – operations (also called methods or services) that will be applied
to the objects to effect the manipulation – relationships (some hierarchical) between the objects – collaborations that occur between the classes that are defined.
• The elements of a class-based model include classes and objects, attributes, operations, CRC models, collaboration diagrams and packages.
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
Chapter06:Class‐Responsibility‐CollaboratorModeling(CRC)
• Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler [Amb95] describes CRC modeling in the following way:
– A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.
CS‐584/Fall2009/EmoryU 20
Class:Description:
Responsibility: Collaborator:
Class:Description:
Responsibility: Collaborator:
Class:Description:
Responsibility: Collaborator:
Class: FloorPlanDescription:
Responsibility: Collaborator:
incorporates walls, doors and windowsshows position of video cameras
defines floor plan name/typemanages floor plan positioningscales floor plan for displayscales floor plan for display
WallCamera
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
OtherclassescollaboraGng
22
Chapter07:FlowModelingNotaGon
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
Chapter07:DataFlowDiagramExample
CS‐584/Fall2009/EmoryU 23TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
Chapter07:RequirementsModelingforWebApps
ContentAnalysis.ThefullspectrumofcontenttobeprovidedbytheWebAppisidenGfied,includingtext,graphicsandimages,video,andaudiodata.DatamodelingcanbeusedtoidenGfyanddescribeeachofthedataobjects.
InteracGonAnalysis.ThemannerinwhichtheuserinteractswiththeWebAppisdescribedindetail.Use‐casescanbedevelopedtoprovidedetaileddescripGonsofthisinteracGon.
FuncGonalAnalysis.Theusagescenarios(use‐cases)createdaspartofinteracGonanalysisdefinetheoperaGonsthatwillbeappliedtoWebAppcontentandimplyotherprocessingfuncGons.AlloperaGonsandfuncGonsaredescribedindetail.
ConfiguraGonAnalysis.TheenvironmentandinfrastructureinwhichtheWebAppresidesaredescribedindetail.
CS‐584/Fall2009/EmoryU 24TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
25
TheConfiguraGonModel
• Server‐side– ServerhardwareandoperaGngsystemenvironmentmustbespecified
– InteroperabilityconsideraGonsontheserver‐sidemustbeconsidered– Appropriateinterfaces,communicaGonprotocolsandrelated
collaboraGveinformaGonmustbespecified
• Client‐side– BrowserconfiguraGonissuesmustbeidenGfied
– TesGngrequirementsshouldbedefined
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
26
NavigaGonModeling‐I
• Shouldcertainelementsbeeasiertoreach(requirefewernavigaGonsteps)thanothers?WhatisthepriorityforpresentaGon?
• ShouldcertainelementsbeemphasizedtoforceuserstonavigateintheirdirecGon?
• HowshouldnavigaGonerrorsbehandled?• ShouldnavigaGontorelatedgroupsofelementsbegivenpriorityover
navigaGontoaspecificelement.• ShouldnavigaGonbeaccomplishedvialinks,viasearch‐basedaccess,orby
someothermeans?• Shouldcertainelementsbepresentedtousersbasedonthecontextof
previousnavigaGonacGons?• ShouldanavigaGonlogbemaintainedforusers?
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
27
NavigaGonModeling‐II
• ShouldafullnavigaGonmapormenu(asopposedtoasingle“back”linkordirectedpointer)beavailableateverypointinauser’sinteracGon?
• ShouldnavigaGondesignbedrivenbythemostcommonlyexpecteduserbehaviorsorbytheperceivedimportanceofthedefinedWebAppelements?
• Canauser“store”hispreviousnavigaGonthroughtheWebApptoexpeditefutureusage?
• ForwhichusercategoryshouldopGmalnavigaGonbedesigned?
• HowshouldlinksexternaltotheWebAppbehandled?overlayingtheexisGngbrowserwindow?asanewbrowserwindow?asaseparateframe?
TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.
Fact/FallacyTidbit
• Fact26Thelistof“derivedrequirements”canbe50xlongerthanthelistoforiginalrequirements
• Discussion– Requirementsinformthedesign;thedesigninformsthesoluGon;thesoluGoncreates
newrequirements– Complexitymayincreaseaswell– Requirementstraceabilityisaffected
• Traceabilityinvolvesmappingacustomerrequirementtoeachpartofthedesign/code/test/documentaGon
• SomeGmesusedforcodeanalysis–idenGfyingdanglingcode,forexample(i.e.,codethatnolongermeetsarequirement)
• Design“consequences”(implicitrequirements)aren’tGeddirectlytoanoriginalcustomerrequirement,somappingisunclearatbest
• EachphaseoftheprojectandaddiGonoffurtherimplicitrequirementsaddstothetraceabilityproblem;nojustasimplelinked‐listproblembutlinked‐listsoflinked‐lists–extremelycomplex
FromRobertGlass,“Facts&FallaciesofSofwareEngineering”
CS‐584/Fall2009/EmoryU 28