1. 1 3. Monumentaalmetoodikad 2007

2. 2 Processes

3. 3 Domains of IT

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

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

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

7. 7 Process Decomposition

8. 8 Tagasisideta süsteem

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

10. 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. 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. 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. 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. 14 Tänapäevanõuded metoodikale: 1.“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); 2.“õige raskusega” standardid, protseduurid ja arhitektuurid; 3.riskijuhtimise keskne roll metoodikas.

15. 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. 16 Waterfall model

17. 17 Waterfall Model

18. 18 Waterfall Model: Phases

19. 19 Waterfall Model: Phases (cont)

20. 20 Waterfall Model: Phases (cont)

21. 21 Waterfall Model: Phases (cont)

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

23. 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. 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. 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. 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. 27 V Process Model [basic]

28. 28 V Process Model [extended]

29. 29 Capability Maturity Model (CMM)

30. 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. 31 Total Quality Management Total Quality Management (TQM) is the application of quantitative methods and human resources to improve: –the material and services supplied to an organization –all the processes within an organization –the degree to which the needs of the customer are met, now and in the future

32. 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. 33 Immature vs. Mature Software Organizations In an immature software organization, software processes are generally improvised by practitioners and their management during the course of the project. Even if a software process has been specified, it is not rigorously followed or enforced. The immature software organization is reactionary, and managers are usually focused on solving immediate crises (better known as fire fighting). Schedules and budgets are routinely exceeded because they are not based on realistic estimates. When hard deadlines are imposed, product functionality and quality are often compromised to meet the schedule. In an immature organization, there is no objective basis for judging product quality or for solving product or process problems. Therefore, product quality is difficult to predict. Activities intended to enhance quality such as reviews and testing are often curtailed or eliminated when projects fall behind schedule.

34. 34 Immature Versus Mature Software Organizations (cont.) A mature software organization possesses an organization- wide ability for managing software development and maintenance processes. –The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to the planned process. –The processes mandated are usable and consistent with the way the work actually gets done. These defined processes are updated when necessary, and improvements are developed through controlled pilot-tests and/or cost benefit analyses. – Roles and responsibilities within the defined process are clear throughout the project and across the organization.

35. 35 The Five Levels of Software Process Maturity

36. 36 Organisatsiooni küpsustastmed CMM määratleb organisatsiooni tarkvaraarenduse 5 küpsustaset.

37. 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. 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. 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. 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 kvaliteedit mõõ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. 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. 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. 43 Protsesside atribuudid (Common Features)...... kirjeldavad protsesside tõhusust, korratavust ja püsivust

44. 44 Common Features Tegutsemisvalmidus (Commitment to Perform) Tegutsemisvalmidus kirjeldab protsessi algatamiseks vajalikke toiminguid. Tegutsemisvalmidus seisneb tavaliselt organisatsiooni poliitikate kehtestamises ja juhtkonna toetuses. Teovõime (Ability to Perform) Teovõime kirjeldab lähtetingimusi, mis peavad projektimeeskonnas olema täidetud, et täielikult teostada tarkvaraprotsessi. Tavaliselt seisneb teovõime ressurside, organisatsiooni struktuuri ja treeningu olemasolus. Teostatud toimingud (Activities Performed) Teostatud toimingud kirjeldab rolle ja protseduure, mis on vajalikud protsessi võtmepiirkonna realiseerimiseks. Teostatud toimingud seisneb tavaliselt plaanide ja protseduuride määratlemises, töö teostamises, seires ja korrektsioonides.

45. 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 69 kõrgküpset organisatsiooni Indias (kusjuures 2000. aastal oli neid vaid 24!), 1 Austraalias, 2 Hiinas, 1 Prantsusmaal, 1 Iisraelis.

46. 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. 47 International Standards Organization (ISO)

48. 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. 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. 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 ISO 9001 ja ISO 9000-3 kasutamisest tarkvaraarenduses.

51. 51 ISO 9001 ja CMM ISO 9001-kompatiibel organisatsioon ei pruugi rahuldada kõiki 2se taseme protsesside võtmepiirkondi on isegi võimalik, et CMM 1se taseme organisatsioon saab ISO 9001 sertifikaadi!

52. 52 ISO 9001 ( SPICE) ja CMM SPICECMM Kahedimensionaalne struktuur Ühedimensionaalne struktuur Võimaldab paindlikku strateegiate muutmist Sisaldab täiustamise protsessi Küpsusaste kõikidele protsessidele Üks küpsusaste kogu organisatsioonile Tulemuste interpreteerimine komplitseeritud Tulemuste interpreteerimine lihtne (Äärmiselt) täielik tulemus(Üle)lihtsustatud tulemus

53. 53 OPEN

54. 54 The OPEN Process The OPEN consortium, a group of individuals and organizations promoting and enhancing the use of object-oriented technology, has developed the OPEN Process, a comprehensive software process. Like the Unified Process, the OPEN Process is aimed at organizations using object and component technology, although it can easily be applied to other software development technologies. The OPEN Process supports the UML notation, and the Object Modeling Language (OML) notation, and any other OO notation to document the work products the OPEN process produces. The activities of the OPEN are subject to stated contracts, making OPEN a responsibility-driven process.

55. 55 The OPEN Cross-project activities - this is a major departure from what you've seen in the Unified Process: the lifecycle of the OPEN Process explicitly includes activities outside of the scope of a single project. This is called programme management in the OPEN Process, a programme being a collection of projects and/or releases of an application or suite of applications. Common programme management activities would include organization-wide architectural modeling efforts, process improvement efforts, and standards/guidelines development and support. This sort of effort is often called Enterprise Management or Infrastructure Management within software organizations. It has strong support for process modeling, project management and requirements capture as well as traditional OO "analysis and design".

56. 56 Strengths of the OPEN Process 1.It is the most comprehensive of the three processes presented, including a cradle-to-grave approach to the lifecycle of a project and a multi-project view to software that reflects the actual environment of most organizations. 2.It is the brainchild of a wide variety of practitioners and academics, all of whom are coming to the table with different experiences, skillsets, and backgrounds. This breadth of talent is one reason for the OPEN Processes comprehensiveness and has resulted in a smorgasbord of development techniques from which to choose.

57. 57

58. 58

59. 59

60. 60 The OPEN Process serious drawback: Ineffective marketing. Remember the illfated Object Modeling Language (OML) from the OPEN Consortium, the notation that ran against the Unified Modeling Language (UML) several years ago in the race to become the industry standard notation? The OML was superior in many respects to the UML, but it unfortunately didn't garner the market mindshare that the UML did. It is possible that once again the best candidate will be out marketed by the second best, which more often than not is the norm in our industry.