Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

Similar presentations

Presentation on theme: "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"— Presentation transcript:

1 1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

2 CS4275-2 Previous lecture zProject initiation yDecide whether to proceed xCost-benefit analysis yConvince others to proceed, use documents xVision xBusiness case xInitial use-case model xInitial risk assessment xInitial project plan

3 CS4275-3 Requirements analysis zHow do you learn… y…what the problem is? y…what you can change? y…what the computer should do? y…whether you were correct? zToday: (more on) requirements and risks

4 CS4275-4 Requirements zFunctional requirements ySoftware inputs, outputs, and their relationship zNon-functional requirements ySecurity yReliability yUsability yScalability yMaintanability yEfficiency y…

5 CS4275-5 Functional requirements (1) zInputs, outputs, and the relationship between them zUse cases zFormats, standard interfaces zBusiness rules and complex formula

6 CS4275-6 Functional requirements (2) zCommand language yThe “get” command will transfer... zWeb pages yInput forms, dynamic pages zConnections to other systems yFiles, sockets, XML, … zReports, displays

7 CS4275-7 Example requirements zFunctional requirements in your projects

8 CS4275-8 Requirements vs. spec Spreadsheet Operator Machine Required behavior of spreadsheet Lathe Operator Machine Required behavior of lathe SpecificationRequirements

9 CS4275-9 Non-functional requirements zPerformance yMust answer a query in 3 seconds zUsability yNew user must be able to finish buying a book in 15 minutes y90% of users must say they like interface zMaintainability yNew programmers should be able to fix first bug in two weeks on the job

10 CS4275-10 Example requirements zNon-functional requirements in your projects

11 CS4275-11 Completeness zFunctional requirements - in theory, can specify completely zNon-functional requirements - hard to specify, can’t specify completely zRequirements should be specific, so you can tell whether you met them zRequirements should be as precise as necessary, but no more

12 CS4275-12 Comparison of requirements zRUP yUse cases yRequirement document that covers non- functional requirements zXP yStories yOn-site customer

13 CS4275-13 Risks zTechnical risks zProject risks zBusiness risks zSuccess does not require winning big, but avoiding failure

14 CS4275-14 What can go wrong? zProblem harder than we thought zWe waste time, take too long zCustomers don’t know what they want zSystem is too slow zStock options become worthless, developers quit zDevelopers get bored and quit zDevelopers like new technology; it doesn’t work zCustomers run out of money and kill the project

15 CS4275-15 Example risks zRisks in your projects

16 CS4275-16 Common risks zProjects get killed for same old reasons zUse database of problems to identify risk yAssess risks yAvoid risks yMonitor risks you can’t avoid yManage risks

17 CS4275-17 Biggest risks zProcess should address biggest risks: yWrong requirements xIterative development xWork closely with customer yConstantly changing requirements xManage changes xKeep schedule up to date yInadequate schedule xKeep schedule up to date

18 CS4275-18 Risk management zRisk assessment: a document listing risks, their likelihood, and their severity zDecide whether you are going to try to avoid this risk or just to monitor it

19 CS4275-19 Managing risk in RUP zIterations alleviate risk yFeedback yChance to try out new technology zArchitecture should address known risks zRank use cases by customer priority and risk zManagement is responsible for non- technical risk

20 CS4275-20 Managing risk in XP zIteration zDo the simplest thing that could possibly work (DTSTTCPW) zCustomer picks most important stories zDevelopers estimate time yStories that can’t be estimated or have long estimates are risky; developers must work (prototype) to make reliable estimate

21 CS4275-21 Differences (1) zRisk: Later iterations need more sophisticated design than first ones yRUP: Elaboration phase should consider all use cases and should select ones that are risky yXP: Keep design clean and simple and change it if necessary

22 CS4275-22 Differences (2) zRisk: As developers leave the project, new ones must learn the system yRUP: Document the architecture and key use cases yXP: Use pair programming to teach new developers the system and to make sure that knowledge of the system is spread as widely as possible (diversify)

23 CS4275-23 Example managing risk zManaging risk in your projects

24 CS4275-24 Next: Use Cases zRead chapters 2-5 of Cockburn zReading is IMPORTANT; probably repeated enough times by now

Download ppt "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"

Similar presentations

Ads by Google