3. Monumentaalmetoodikad

1. 3. Monumentaalmetoodikad 2007

2. Processes

3. Domains of IT

4. Set of activities carried out to produce an application Process • Development sequence: • Waterfall • Iterative

5. Process Set of activities carried out to produce an application • Development sequence: • Waterfall • Iterative • Process frameworks: • Personal Software ProcessSM • Team Software ProcessSM • Capability Maturity ModelSM • -- for organizations • Standards: • Institute of Electrical and Electronic Engineers • International Standards Organization • ...

6. Protsess Protsess teisendab sisendid kliendile väärtust omavateks väljunduteks

7. Process Decomposition

8. Tagasisideta süsteem

9. Tagasisidega süsteem Tagasisidega süsteemidel on mitemeid eeliseid

10. What is a software process? • A set of activities whose goal is the development or evolution of software • Generic activities in all software processes are: • Specification - what the system should do and its development constraints • Development - production of the software system • Validation - checking that the software is what the customer wants • Evolution - changing the software in response to changing demands

11. What is a software process model? • A simplified representation of a software process, presented from a specific perspective • Examples of process perspectives are • Workflow perspective - sequence of activities • Data-flow perspective - information flow • Role/action perspective - who does what • Generic process models • Waterfall • Iterative and evolutionary development • Formal transformation • Integration from reusable components

12. Traditional Structured Analysis Described by W. W. Royce, 1970, IEEE WESCON, Managing the development of large software systems. Decomposition in terms of Function and Data Modularity available only at the file level cf. C language's static keyword (=="file scope") Data was not encapsulated: Global Scope File Scope Function Scope (automatic, local) Waterfall Method of Analysis and Design

13. Structured Analysis Problems: coding changes need to be made in several different places changing the function often changes the API which breaks other functions dependent upon that API data type changes need to be made each time they are used throughout the application

14. Tänapäevanõuded metoodikale: • “parasjagu” (“just enough”) metoodika, mis tagab piisava riskide maandamise, korrektse IT ja äripoole koostöö ning toodab ka piisaval määral dokumentatsiooni (nii sisemisteks vajadusteks kui ka klientide ja audiitorite rahuldamiseks); • “õige raskusega” standardid, protseduurid ja arhitektuurid; • riskijuhtimise keskne roll metoodikas.

15. Võtmeküsimused • Kuidas peavad tarkvaraloojad reageerima ärivajaduste kiirele evolutsioonile? • Kas võimaldavad kavandamise ja arenduse protseduurid toime tulla hajussüsteemide ja heterogeensete keskkondade probleemidega? • Missugused kavandamise ja arenduse muutused on vajalikud, et arvestada tehnoloogia muutustega? • Missugused uued protsessid, mudelid ning oskused on vajalikud muutuvas olukorras?

16. Waterfall model

17. Waterfall Model

18. Waterfall Model: Phases

19. Waterfall Model: Phases (cont)

20. Waterfall Model: Phases (cont)

21. Waterfall Model: Phases (cont)

22. Why a Pure Waterfall Process is Usually Not Practical • Don’t know up front everything wanted and needed • Usually hard to visualize every detail in advance • We can only estimate the costs of implementing requirements • To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones • We will probably need to modify requirements as a result • We often need to execute intermediate builds • Stakeholders need to gain confidence • Designers and developers need confirmation they're building what’s needed and wanted • Team members can't be idle while the requirements are being completed • Typically put people to work on several phases at once

23. Waterfall Process Assumptions • Requirements are known up front before design • Requirements rarely change • Users know what they want, and rarely need visualization • Design can be conducted in a purely abstract space, or trial rarely leads to error • The technology will all fit nicely into place when the time comes (the apocalypse) • The system is not so complex. (Drawings are for wimps)

24. Waterfall Method Requirements Analysis Analysis Specification Design Specification Coding from Design Specification Unit Testing System Testing User Acceptance Testing Ship It (????) Measuring rod is in the form of formal documents (specifications).

25. Waterfall Process Limitations • Big Bang Delivery Theory • The proof of the concept is relegated to the very end of a long singular cycle. Before final integration, only documents have been produced. • Late deployment hides many lurking risks: • technological (well, I thought they would work together...) • conceptual (well, I thought that's what they wanted...) • personnel (took so long, half the team left) • User doesn't get to see anything real until the very end, and they always hate it. • System Testing doesn't get involved until later in the process.

26. “Control” and “Regulation” • Systems theory distinguishes between • “control” (i. e.“feed forward” or “open loop” control systems) and • “regulation”(i. e. “feedback” or “closed loop” control systems).

27. V Process Model [basic]

28. V Process Model [extended]

29. Capability Maturity Model (CMM)

30. Capability Maturity Model (CMM) • Tarkvaraarendus on keeruline tegevus, mille tulemus sõltub selles osalevatest inimestest, kasutatavast tehnoloogiast ja metoodika(te)st (arendusprotsesside kogumist). • 1984. aastal loodi DoD poolt uurimiskeskus Software Engineering Institute (SEI). • 1992. aastal avaldati Capability Maturity Model (CMM). • CMM on välja töötatud Total Quality Management (TQM) kontseptsioonide alusel töötati SEIsja koosneb mitmetestpaljudest välja mitmed standarditestd tarkvarametoodikate arendamiseks/tarkvara kvaliteedi tagamiseks. • CMM for Software (SW-CMM), People CMM (P‑CMM), CMM Integration (CMMI) jt.

31. Total Quality Management • Total Quality Management (TQM) is theapplication of quantitative methods and humanresources to improve: • the material and services supplied to anorganization • all the processes within an organization • the degree to which the needs of the customerare met, now and in the future

32. Põhimõisted eesti keeles • Tarkvaraprotsessi võimekus (software process capability) näitab, millist tulemit võib loota organisatsiooni järgmiselt tarkvaraprojektilt. • Tarkvaraprotsessi tulemuslikkus (software process performance) esindatab tegelikku tulemit, mis saadi tarkvaraprotsessi järgides. • Tarkvaraprotsessi küpsus (software process maturity) on määr, milleni protsess on määratletud, juhitud, mõõdetud, kontrollitud – on tarkvaraprotsessi tõhususe mõõt. 09.02

33. Immature vs. Mature SoftwareOrganizations • In animmature software organization, software processes are generally improvisedby practitioners and their management during the course of the project. • Evenif a software process has been specified, it is not rigorously followed orenforced. The immature software organization is reactionary, and managersare usually focused on solving immediate crises (better known as fire fighting). • Schedules and budgets are routinely exceeded because they are not basedon realistic estimates. When hard deadlines are imposed, productfunctionality and quality are often compromised to meet the schedule. • In an immature organization, there is no objective basis for judging productquality or for solving product or process problems. Therefore, product qualityis difficult to predict. Activities intended to enhance quality such as reviewsand testing are often curtailed or eliminated when projects fall behindschedule.

34. Immature Versus Mature SoftwareOrganizations (cont.) • A mature software organization possesses anorganization-wide ability for managing software development andmaintenance processes. • The software process is accurately communicated toboth existing staff and new employees, and work activities are carried outaccording to the planned process. • The processes mandated are usable andconsistent with the way the work actually gets done. These defined processesare updated when necessary, and improvements are developed throughcontrolled pilot-tests and/or cost benefit analyses. • Roles and responsibilitieswithin the defined process are clear throughout the project and across theorganization.

35. The Five Levels of Software Process Maturity

36. Organisatsiooni küpsustastmed • CMM määratleb organisatsiooni tarkvaraarenduse5küpsustaset.

37. 1. tase 1. tase – Initial – metoodika puudumine (=häkkerlus, “põõsametoodika”), organisatsioon on mitteküps. Mitteküpses organisatsioonis pole enamasti tarkvaraprotsess määratletud. Ja isegi kui mingi protsess on määratletud, ei peeta sellest kinni. Mitteküps organisatsioon lahendab probleeme nende esilekerkimise järjekorras, tegevus seisneb peamiselt “tulekahjude kustutamises”. Kuna tähtaegadest ei suudeta kinni pidada, on meeskonnal vaja pidevalt sooritada töökangelastegusid. Ka (juhuslikult) õnnestunud projekti kordamiseks peaks meeskond ja selle liikmete rollid samad olema. Seega, 1se taseme puhul võime küll rääkida üksikisikute võimekusest ja küpsusest, mitte aga organisatsiooni küpsusest.

38. 2. tase 2. tase – Repeatable – korratav. Sellel tasemel on määratletud tarkvaraprojekti juhtimise poliitikad ja nende poliitikate elluviimise protseduurid määratletud. Uute projektide plaanimine ja juhtimine toetub kogemustele analoogsete projektidega. Protsessid on praktikas läbiproovitud, dokumenteeritud, kohustuslikud, on läbi viidud õppused ja treeningud. On loodud tingimused protsesside edasiseks täiustamiseks. Paneme tähele, et tunduvalt on vähenenud sõltuvus üksikisikust, mis tõsisemate ettevõtmiste korral (nt. finantsinstitutsioonid) on turvalisuse seisukohalt äärmiselt oluline.

39. 3. tase 3. tase – Defined – määratletud. Sellel tasemel on kehtestatud ja dokumenteeritud organisatsiooni standardprotsess tarkvara arendamiseks. Organisatsiooni standardprotsess sisaldab nii tarvaratehnika- kui ka juhtimisprotsesse, mis on terviklikult integreeritud. Organisatsiooni standardprotsessi haldamiseks on moodustatud tarkvaratehnika protsesside grupp; on evitatud kogu organisatsiooni hõlmav õppe- ja treeningprogramm, et tagada kõigi töötajate ja juhtide vastavad teadmised ja oskused. Organisatsiooni standardprotsessi kohandatakse vastavalt konkreetsete projektide eritingimustele/-nõuetele – projekti poolt määratletud tarkvaraprotsess. 3nda taseme organisatsioonides on projekti funkstionaalsus, ajagraafik ja maksumus täielikult kontrollitav.

40. 4. tase 4. tase – Managed – juhitav. Sellel tasemel organisatsioon seab kvantitatiivsed kvaliteedinõuded nii tarkvaratoodetele kui ka -protsessidele. Üle kõikide projektide oluiliste protsesside on olemas mõõdetud tootlikkuse ja kvaliteeditmõõt. On loodud üleorganisatsiooniline protsesside andmebaas, mida kasutatakse protsesside analüüsiks. Projektide parameetrid on määratletavad, kõikumised tootlikkuses, tähtaegades jmt. on reeglina tühised. 4nda taseme organisatsioonid tagavad tarkvaratoodete kõrge kvaliteedi.

41. 5. tase 5. tase – Optimizing – optimeeriv. 5nda taseme organisatsioon täiustab pidevalt oma protsesse. Organisatsioonil on vahendid protsesside nõrkuste selgitamiseks ja nende preventiivseks parendamiseks. Andmeid tarkvaraprotsessi efektiivsusest kasutatakse uute tehnoloogiate ja protsesside analüüsiks. Tehnoloogia ja protsesside muudatused on planeeritud ja viiakse läbi vastavate protseduuride alusel.…,

42. Protsesside võtmepiirkonnad(Key Process Areas) Näiteks, 2se taseme protsesside võtmepiirkonnad on: • Software configuration management – tarkvara konfiguratsiooni haldus • Software quality assurance – tarkvara kvaliteedi tagamine • Software subcontract management – tarkvara alltöövõtu haldus • Software project tracking and oversight – tarkvaraprojektide seire • Software project planning – tarkvaraprojektide planeerimine • Requirements management – vajaduste haldus

43. Protsesside atribuudid (Common Features) ... ... kirjeldavad protsesside tõhusust, korratavust ja püsivust

44. Common Features

45. Kõrgküpsed organisatsioonid • 2001. a. seisuga oli 132 kõrgküpset organisatsiooni: • 71 neljanda taseme ja • 61 viienda taseme organisatsiooni • väljaspool USA-d oli 69kõrgküpset organisatsiooni Indias (kusjuures 2000. aastal oli neid vaid 24!), 1  Austraalias, 2 Hiinas, 1 Prantsusmaal, 1 Iisraelis.

46. Kus vajatakse CMMi? • väga suured programmid, mille täitmisest võtab osa palju organisatsioone • virtuaalprojektid või -organisatsioonid • geograafiliselt hajutatud projektid • arendusorganisatsioonid (research and development, R&D)

47. International Standards Organization (ISO)

48. International Standards Organization (ISO) • ISO 15504, tuntud ka kui SPICE – Software Process Improvement and Capability Determination; • ISO 12207, Software Life Cycle Processes; • ISO 15288, System Life Cycle Processes; • ISO 9000, Quality Management and Quality Assurance Standards – Guidelines for Selection and Use – standardite kogum (ka tarkvara) kvaliteedi tagamiseks;

49. International Standards Organization (ISO) • ISO 9001, Quality Systems – Model for Quality Assurance in Design/Development, Production, Installation, and Servicing – “ISO 9000 seeria tarkvaranduse põhistandard”, mis käsitleb kavandamist, arendamist, tootmist, installeerimist ja teenindamist – kogu tarkvara elutsüklit; • ISO 9002, Quality Systems; • ISO 9003, Quality Systems – Model for Quality Assurance in Final Inspection and Test;

50. International Standards Organization (ISO) • ISO 9004, Quality Management and Quality System Elements – Guidelines; • ISO8402, Quality – Vocabulary • mitmed juhised, näiteks ISO 9000-3, Guidelines for the application of ISO 9001 to the development, supply, and maintenance of softwar. Veelgi enam: • Briti juhis TickIT annab täiendavat informatsiooni ISO9001ja ISO 9000-3 kasutamisest tarkvaraarenduses.