5. UP evitamisest ettevõttes

1. 5. UP evitamisest ettevõttes 2007

2. Unified Processi ajaloost • 1988: Objectory v1.0 määratletakse Ivar Jacobsoni firma Objectory AB poolt. Objectory-protsess määratles tuumprotsessi, millest arenes UP ja hilisemad UP modifikatsioonid. • 1995: Rational Corporation ostab Objectory AB. • 1996: Grady Booch, James Rumbaugh ja Ivar Jacobson (the Three Amigos) esitasid tarkvaraarendusprotsessi Rational Objectory Process (ROP) 4.0.

3. Unified Processi ajaloost • 1998: Rational Unified Process (RUP) 5.0 redaktsioon. Peale ROPi nimetamise RUPiks lisandus UML-diagrammide kasutamine objekt-orienteeritud süsteemide arendamiseks. • 1999: Ilmus raamat The Unified Software Development Process, kus detailselt kirjeldati RUPi karkassi. • 1999: RUP 5.5 redaktsioon. Põhitäiendused: reaalaja- ja veebisüsteemide arendus. • 2000: RUP 2000 redaktsioon. Põhitäiendused: ärimodelleerimise tehnikad

4. Unified Processi ajaloost • 2002: IBM ostab Rational Corporationi • 2003: RUP 2003 redaktsioon. Põhitäiendused: testimisdistsipliini detailiseerimine, lisati ka mõned agiilse arendusideoloogia kontseptsioonid • 2005: Scott W. Ambler teavitab agiilse UP (Agile Unified Process (AUP)) loomisest. • 2005: Ivar Jacobson teavitab oma agiilse UP versiooni Essential Unified Processi (essUP) loomisest. • 2005: IBM teavitab Basic Unified Processi (BUP), (jälle) UP agiilne versioon, loomisest. • Märts 2006: BUP nimetatakse OpenUPks. • September 2006: OpenUP 0.9 redaktsioon.

5. SEB Unified Process ver 2.0 January 2007

6. Information About Previous Releases • SEB Unified Process ver 1.0 June 2006 • SEB Unified Process ver 1.1 July 2006 • SEB Unified Process ver 1.2 September 2006

8. Development Case • A development case describes how SEB UP is tailored to specific situations. • Minor enhancement activity • Standard SEB Development effort • Infra-structure development

9. SEB UP Process:the Most Essential Work Products: • Use-Case Model Survey – A document that describes the functional requirements on a high level. The document includes the Use-Case model and brief descriptions of each Use Case in the system, as well as brief descriptions of all Actors (human as well as other systems) that interact with the system. The Use-Case Model Survey is of particular interest to stakeholders, requirements specifiers, software architects, designers, testers, and reviewers.

10. SEB UP Process:the Most Essential Work Products: • Supplementary Specification – A specification of all non-functional requirements such as requirements on performance, security, usability and so on. The Supplementary Specification is of particular interest to stakeholders, requirements specifiers, software architects, designers, testers, and reviewers. • Overall Plan of Phases and Iterations - This work product describes the plan of the project; phases and iterations, their objectives, duration, how many iterations each phase should include etc.

11. SEB UP Process:the Most Essential Work Products: • Iteration Plans - This work product is a time-sequenced set of activities and tasks, with assigned resources, containing any task dependencies, for the iteration; a fine-grained plan. • Change Requests - A general term for a request from anyone (Project Member or not) to change a Work Product.

12. SEB UP Process:the Most Essential Work Products: • Test Cases - A step-by-step instruction on what to do and what result to expect. Defines preconditions and Test Data needed for running the Test Case. Developed by the Test Analyst, used by the Tester during tests. • Software Architecture Document (SAD) – The software architecture document provides a comprehensive overview of the architecture of the software system. It serves as a communication medium between the software architect and other development team members regarding architecturally significant decisions which have been made for the development effort.

13. Templates:Business Modeling • Business Architecture Outline.dot 

14. Templates: Requirements • SEB UP Glossary.dot • SEB UP Supplementary Specification.dot • SEB UP System Vision.dot • SEB UP Use Case Prioritization.xlt • SEB UP Use-Case Model Survey.dot • SEB UP Use-Case Specification.dot

15. Templates: Analysis & Design • SEB UP Template Software Architecture Document template.dot • SEB UP Template Use Case Specification Appendix - Interaction Design.dot • Use-Case Realization Specification.dot • Subsystem Report.dot

16. Templates: Test • Final Test Report.dot • Test Case.dot • Test Coverage Matrix.xlt • Test Environment Configuration.dot • Test Execution Log.xlt • Test Plan.dot • Test Report.dot • Test Strategy.dot

17. Templates: Deployment • Deployment plan.dot • Deployment_schedule.dot

18. Templates: Configuration and Change Control Management • Change Request.dot • Configuration Management Plan.dot

19. Templates: System Development Project Management • Agenda - Lifecycle milestone review.ppt • RISK LIST.xls • SEB UP Iteration Plan.dot

20. Templates: Environment • Infra-structure development.xls • Minor Enhancement Activity.xls • Standard SEB development effort.xls

21. SEB General Templates • SEB Project Order • SEB Project Contract • SEB Status Report • SEB Final Report • SEB Decision Memo for Ventures • SEB Architecture Outline

26. Agile Unified Process (AUP) (2005)

27. Agile Unified Process (AUP)

28. AUP distsipliinid • AUP faaside sihid ja sisu on samad mis Unified Processil. Distsipliinid on aga sootuks erinevad. • Esiteks • modelleerimise (Model) distsipliin hõlmab UP ärimodelleerimise (Business Modeling), • nõuete halduse (Requirements) ning analüüsi ja kavandamise (Analysis & Design) distsipliine. • Modelleerimine on küll AUPis oluline, kuid mitte domineeriv: agiilsus eeldab, et luuakse minimaalselt mudeleid ja dokumente (just barely good enough). • Teiseks, • konfiguratsiooni ja muudatuste halduse (Configuration & Change Management) distsipliin on AUPs konfiguratsiooni haldus (Configuration Management). • Agiilses arenduses on muudatuste haldus nõuete halduse loomulik osa (meenutame näiteks ekstreemprogrammeerimise tuntud teesi: embrace the change). • Mõistetavalt vastab AUP projektijuhtimise distsipliin (Project Management) agiilse projektijuhtimise ideoloogiale

29. AUP distsipliinid • Modelleerimine – organisatsiooni ärikontseptsiooni/-probleemide mõistmine ja võimalike lahenduste määratlemine. • Implementeerimine – mudeli(te) teisendamine käitatavasse koodi, komponenditestid (unit testing). • Testimine – süsteemi tasemel testimine, tarkvara kliendi nõuetele vastavuse tagamine, lahenduse kvaliteedi tagamine. • Evitamine – süsteemi kliendile üleandmise problemaatika, sealjuures kasutajate väljaõpe jmt. • Konfiguratsioonihaldus – projekti (kaas)tulemite (artifacts) haldus, tulemite versioonide ja muudatuste haldus. • Projektijuhtimine – riskide haldus, meeskonna juhtimine, koostöö kliendiga, projekti skoobi, ajaskaala ja maksumuse seire. • Keskkond – protsessihaldus, juhised, tulemite mallid (artifact’s templates).

30. AUP printsiibid • Meeskond teab, mis teeb. Arendajatel pole vaja lugeda sadu lehekülgi protsessi dokumentatsiooni, kuid nad vajavad kõrgtaseme juhendamist/koolitust. AUP • Lihtsus. Kõik, mis AUPs vajalik, on kirjeldatud mõnel lehel, mitte tuhandeil (RUPi kirjeldus on üle 3000 HTML-lehe, AUP kirjeldus – 30 HTML-lehte). • Agiilsus. AUP vastab Agile Alliance printsiipidele. • Fookuses on (kõrg)väärtust andvad toimingud. Tähelepanu pööratakse neile projekti aspektidele, mis tõepoolest loevad/tulemit annavad, mitte aga aega raiskavatele formaalsustele. • AUP on kohandatav. AUP kui toode sisaldab HTML-põhist protsesside redigeerimise vahendit, mille abil on hõlbus AUP protsesse vastavalt oma vajadustele modifitseerida. 

31. Kas AUP on teie arendusprotsess? • AUP pole kõigile sobiv arendusprotsess – see, mis sobib kõigile, ei sobi mittekellelegi. • Kui te vajate äärmiselt lakoonilist ja agiilset protsessi, mis lähtub UP põhimõtetest ja „räägib UPga sama keelt”, siis AUP on teie protsess. • Näiteks, ekstreemprogrammeerimine (XP) on paljudele organisatsioonidele „liiga kerge”: XP ei toeta mudelite ja dokumentide loomist, mis on kehtestatud organisatsiooni poliitikatega. • Standard-UP on aga paljudele „liiga raske(kaaluline)”: tohutult on vahe- ja kaastulemeid (artifact), mille loomisele kulub palju aega, kuid mis osutuvad väiksemate projektide puhul mittevajalikuks. • Seejuures on standard-UP „kerge(ma)ks muutmine” komplitseeritud ja kõrget kvalifikatsiooni nõudev toiming.

32. OpenUP/Basic(September 2006)

33. OpenUP/Basic OpenUP/Basic on minimaalne, täielik ja laiendatav iteratiivne tarkvara arendusprotsess. • Protsessi minimaalsus tähendab, et protsessi on lülitatud vaid oluline (hädavajalik). • Protsessi täielikkus tähendab, et protsessi järgides saame luua nõuetele vastava tarkvarasüsteemi • Protsessi laiendatavus tähendab, et protsessi saab modifitseerida ja täiendada vastavalt vajadusele

34. OpenUP/Basic kui agiilmetoodika • OpenUP/Basic on UP põhimõtteid rahuldav agiilmetoodika, mis hindab projektis osalejate koostööd enam kui formaalsust ja dokumentatsiooni • (pole üllatav, et OpenUP/Basicu ja AUP alustalad samad on).

35. OpenUP/Basicut iseloomustab: • iteratiivne arendus, • kasutuskaasuste poolt tüüritav arendus, • riskide haldus ja • arhitektuurikeskne lähenemine.

36. Mõned arvulised andmed OpenUP/Basicu kohta: • Vähem kui 200 lehekülge teksti • 6 rolli (role), 18 toimingut (task), 20 töötulemit (work product)

37. OpenUP/Basicu printsiibid OpenUP/Basicu põhiprintsiipideks on: • Koostöö huvide joondamiseks ja projektist ühtse arusaamise tagamiseks. • Tasakaal eri prioriteetide vahel kliendile maksimaalse väärtuse andmiseks. • Rõhk on arhitektuuril, tehnilised otsused formuleeritakse arhitektuuri terminates. • Tagasiside kliendilt: project on jaotatud lühikesteks iteratsioonideks, mis võimaldab saada kliendilt pidevat tagasisidet.

38. OpenUP/Basicu struktuur • OpenUP/Basic on “kergekaaluline” agiilne protsess. OpenUP/Basic koosneb alamprotsessidest ja koostöökihist. • Koostöökihi elemendid toetavad agiilmanifesti (Agile Manifesto) deklaratsioone: • Juhtimine (Management) – muudatustele reageerimine vs. plaani järgimine • Kavatsus (Intent) – koostöö kliendiga vs. lepingutingimuste arutelud • Lahendus (Solution) – töötav tarkvara vs. täielik dokumentatsioon • Kommunikatsioon & koostöö (Communication&Collaboration) – isikud ja nende suhted vs. protsessid ja vahendid

39. OpenUP/Basicu agiilkontseptsioonid • Lisaks agiilprintsiipidele sisaldab OpenUP/Basic terve rea agiilkontseptsioone: • testid-kõigepealt-kavandamine, • fikseeritud pikkusega iteratsioonid (sand-boxed-iterations), • refaktoriseerimine

40. OpenUP/Basicu koostöökihi elementide lühikese iseloomustus: • Kavatsus – määratleda tarkvaratoote omadused. Oluline on tagada kasutajate ja huvigrupi (stakeholders) kavatsuste/soovide kommunikeerimine. • Juhtimine – projekti juhtimine: projekti seire, riskide leevendamine jmt. • Lahendus – toote loomine: primaarne on arendustiimi vaade, koostete (build) loomine ja verifitseerimine. • Kommunikatsioon & koostöö – sellele elemendile (kihile) toetuvad ülejäänud koostöökihi is elemendid: meeskonna koostöö, meeskonna liikmete rollid ja vastutused.

41. OpenUP/Basicu struktuur

42. Distsipliinid OpenUP/Basic määratleb järgmised distsipliinid (moodustavad UP distsipliinide alamhulga – erinevalt AUPst) : • Nõuded (Requirements), • Analüüs ja kavandamine (Analysis and Design), • Implementeerimine (Implementation), • Testimine (Test), • Projektijuhtimine (Project Management), • Konfiguratsiooni ja muudatuste haldus (Configuration & Change Management)

43. Rollid • Huvigrupp (Stakeholder) – kõik (kasutajad, administraatorid, juhtkond jmt), kelle huvisid/vajadusi project peab rahuldama. • Analüütik (Analyst) – huvigrupi vajaduste alusel projekti nõuete määratlemine. • Arhitekt (Architect) – loodava süsteemi tarkvara arhitektuuri väljatöötamine. • Arendaja (Developer) – süsteemi osade/komponentide kavandamine, implementeerimine, komponenditestide läbiviimine, komponentide integreerimine. • Testija (Tester) – integratsiooni ja süsteemitestide plaanimine, läbiviimine ja analüüs. • Projektijuht (Project Manager) – projektiplaanide koostamine, koostöö huvigrupiga, aruandlus projekti verstapostides jmt.

44. Roles: Analyst

45. Roles: Architect

46. Roles: Developer

47. Roles: Project Manager

48. Roles: Tester

49. Any Role

50. Process • Reusable method content is created separate from its application in processes. • Method contentprovides step-by-step explanations, describing how specific development goals are achievedindependent of the placement of these steps within a development lifecycle. • Processes take these method elements and relate them into semi-ordered sequences that arecustomized to specific types of projects.