The Unified Process

The Unified Process PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on
  • Presentation posted in: General

History. The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT methodsIn the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (

Download Presentation

The Unified Process

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


1. The Unified Process Also known as RUP – Rational Unified Process

2. History The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT methods In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method. Jacobson had worked with software development at Ericsson in Sweden for many years. He brought with him Use Case-thinking and what later became Unified process. Rational developed tool support to UML (Rational Rose) and to Unified Model (then called Rational Unified Process RUP)) Rational was later bought by IBM

9. The Unified Software Development Process: Classification of Iterations Inception iterations: preliminary interaction with stakeholders primarily customer users financial backers etc. Elaboration iterations : finalization of what’s wanted and needed; set architecture baseline Construction iterations : results in initial operational capability Transition iterations : completes product release

10. USDP vs. Standard Terminology ½ (Booch, Jacobson & Rumbaugh)

11. Unified Process Matrix

13. The Six USDP Models (Views of the Application)

17. Process Trade-offs

18. Identify the Process you will use Decide which of waterflow, spiral, and incremantal processes is appropriate Usually Spiral for a semester project Combining parts is OK, e.g. start with spiral, end with incremantal Decide how many iterations Usually two for a semester project Three provides lots of practice – but this is a challenge, make first increment as minor as possible Three promotes the collection and use of metrics data – use metric data collected from each iteration on the next Rough out a weekly schedule Coordinate with course assignments

19. Dokumentasjon Dokumentasjon ekstremt viktig i programvareutviklingsprosjekter Dokumentasjon er mye mer enn kode Selve koden må også dokumenteres – se neste 3 lysark

20. Undocumented Code

21. Somewhat Documented Code

22. Documented Code

23. Dokumentasjonsstandarder Forbedrer kommunikasjon mellom utviklerne Effektiviserer og homogeniserer Viktig at utviklere er med på å lage standarder Noen viktige utviklere av standarder IEEE ISO SEI OMG

24. Project Documentation

25. 1. Document the way documents & code are accessed otherwise, chaos results “Software Configuration Management Plan*” -- section 7.3.2 2. Specify who will do what, and when they will do it “Software Project Management Plan*” -- chapter 2 3. Document what is to be implemented for yourself, your customer, and your team “Software Requirements Specification*” -- chapters 3 and 4 4. Document the design of the application i.e., prior to programming “Software Design Document*” -- chapters 5 and 6 5. Write and document code the “code base” -- chapter 7 6. Plan and document the tests you perform so that they can be re-run, extended etc. “Software Test Documentation*” -- chapters 8 and 9 Identify Your Documentation Needs

26. Kvalitet Det er forskjell på å levere en funksjonalitet og en kvalitetsfunkjon En kvalitetsfunksjon: Tilfredsstiller klart uttrykte krav Sjekker input og reagerer på uriktige verdier Har vært gjenstand for inspeksjon Har vært grundig teste på flere uavhengige måter Er grundig dokumentert Har en feilrate som er tilfredsstillende Kriterier på en høykvalitetsdesign Extensible (kan utvides med mer funksjonalitet) Evolvable (kan tilpasses endrede og justerte krav) Portable (kan benyttes i flere ulike miljøer) General (kan benyttes i mange ulike situasjoner)

27. Målinger I alle ingeniørdisipliner er det viktig å kunne måle og sammenligne Innsamling og analyse av målinger er viktig også i systemutvikling Typiske målinger i programvareutvikling Hvor mye arbeid er utført, f.eks LOC Hvor lang tid tok det Feilrate, feil per 1000 LOC, per side dokumentasjon el.l. Subjektiv vurdering av kvaliteten (1-10) Viktig å sette mål og så følge opp mot målsetningen, eks. 0,15 feil per side i SRD

29. Introduksjon til inspeksjoner Inspeksjon: ”hvit boks”-teknikk som sikrer kvalitet Inspeskjon av deler av produktet (dokumenter, kode, planer,…) for å finne feil Utføres grundig og på samme detaljnivå som forfatteren har utviklet produktet Hjelper ”forfatter” å finne feil ”Medarbeiderne” gjør inspeksjonen (peer)

30. Inspeksjonsprinsipper Finne feil, ikke rette dem Foregår blant ”likesinnede” (peers) Spesifiserte roller: Moderator Forfatter Leser Skriver Omfattende forberedelse

32. Eksempel på kostnad per 100 LOC Inspeksjoner

33. Viktig å finne feilene fortest mulig etter at de er produsert

35. Forbered og gjennomfør Inspeksjoner

36. IEEE 730-1989 Software Quality Assurance Plans Table of Contents

37. IEEE 1012-1986 Software Verification & validation Plans Table of Contents (Reaffirmed 1992)

39. Produce a Quality Product 1. Quantify your quality goals minimum: number of defects per KLOC team: # defective requirements; # classes missing from design; # defects in testing; # defects found in operation. personal: apply # defects to code, compile, unit test separately 2. Build inspections and reviews into the schedule (see scheduling, next chapter) follow the inspection procedure (see figure 1.27 on page ??) 3. Document your quality goals and procedures use a documentation standard to avoid missing issues SQAP (see case study for example); If time allows: SVVP

40. Dokumentstyring Dokumentstyring i programvareutviklings-prosjekter er krevende Mange dokumenter Dokumentene endres hele tiden av flere ulike aktører Krever kompletthet, konsistens og konfigurasjon (koordinering av ulike versjoner av deler av dokumenter og kode) Det kan være en god ide å dokumentere hver entitet ett sted (”single source documentation”) Kan gjøres ved hjelp av hyperlinker – se neste side

41. Example of Hyperlinked Documentation Set (with Dynamic Content shown)

42. Neste uke Onsdag: Use case (diagrammer og tekst) Sekvensdiagrammer (Thomas) Fredag: Kravanalyse (Torbjørn)

  • Login