X36SSP Správa softwarových produktů 5. přednáška

1. X36SSPSpráva softwarových produktů5. přednáška Ing. Martin Molhanec ČVUT – FELK13113

2. OBJECT ORIENTED SOFTWARE PROCESS

3. Dnešní témata Historie SP Co je to OOSP Z jakých částí se skládá Inicializační fáze OOSP

4. Software proces • Způsob vytváření softwarových produktů • Programů • Informačních systémů • Webových sídel • …

5. Co je? • Proces • Série akcí, která má svůj vstup a svůj výstup • Pattern (vzor) • Popis obecného způsobu dobrého řešení • Antipattern • Popis obecného způsobu špatného řešení • OOSP • Object-Oriented Software Process

6. Historie SP • Sériový vývoj (vodopád) • Nevýhodou je malá pružnost • Inkrementální (spirálový) • U velkých projektů je náročný na zdroje • Iterativní • Vývoj se děje po kouskách • Paralelní • Vývoj se děje současně Dobrá cesta Agilní metodiky

7. objektově orientované paradigmaa velké projekty Velké projekty je potřeba kvalifikovaně plánovat a řídit tak, aby se přednosti OO paradigmatu projevily a ne aby se staly ohrožením projektu. Není možné se pouze spoléhat na „zázračné“ vlastnosti nových programovacích jazyků a nástrojů. pro oblast řízení a podpory softwarových projektů máme různé metodiky: Rational Software Corporation.: RUP - Rational Unified Process S. W. Ambler: Object-Oriented Process Pattern • rozsáhlá sada různých nástrojů a technik, je třeba si umět vybrat • nepokrývá fázi údržby a provozu • je šitý na míru smíšeným vývojovým nástrojům • předpokládá klasický vývoj s UML • jednodušší, procesně orientovaný, zahrnuje CMM, SCM, metriky, ... • fáze údržby a provozu je aktivní součástí celého procesu • důraz na využití refactoringu, znovupoužitelnosti a vlastností čistých nástrojů • použitelný i pro XP, BORM

8. SOFTWARE DEVELOPMENT PROCESS project initiation in-house development using packages maintenance & support INITIATION CONSTRUCTION DELIVER MAINTAIN & SUPORT • well define user requirements • select optimal solution • prepare all requiredfor project start success. . . • well end efficient performed analysis • best system assembling andtesting • to have good documentation. . . • start system useseamless and efectively • well prepare usersof the system. . . • to have satisfied users • repair defects • to have good knowledge base for possible new version start. . . key performance issues Each phase has associate its key performance issues, corresponding roles, activities etc. GO NEXT

9. Advanced SW Development Model (ASDM) • Vychází z praktických zkušeností na IT projektech. • Inspirace metodikou „object-oriented process pattern“ (Scott W. Amblera). • Inspirace některými prvky metody RUP. INICIACE KONSTRUKCE DODÁNÍ PROVOZ • správně definovatpožadavky na systém • vybrat optimálnívariantu řešení • naplánovat a připravitvše potřebné k zahájení projektu. . . • provést dobřea efektivně analýzu • co nejlépe sestavit a otestovat systém • mít řádnoudokumentaci. . . • efektivně zahájitprovoz systému • dobře zaškolit uživatele . . . • spokojenost uživatelů s podporou • rychlá oprava chyb • mít dostatečnou znalostní bázipožadavků a návrhůpro novou verzi. . . oblasti klíčovýchvýkonnostníchpožadavků Pro každou fázi jsou identifikovány charakteristické činnostia k nim jsou definovány pracovní role a odpovědnosti.

10. SOFTWARE DEVELOPMENT PROCESS project initiation in-house development using packages maintenance & support INITIATE CONSTRUCT DELIVER MAINTAIN & SUPORT JUSTIFY define and validateREQUIRE-MENTS MODEL TESTin the small TESTin the large RELEASE SUPPORT define initialmanagementDOCUMENTS define INFRA-STRUCTURE GENERALIZE PROGRAMPROCESS REWORK ASSESS identifydefects andenhance-ments project office team development team support team user experts end-users quality assurance, manage project, trainig&education, manage people, manage risk, manage reuse, manage metrics, manage deliverables, manage infrastructure GO NEXT

11. Scott W. Ambler: Object-Oriented Process Pattern činnosti provozované na vývojové a testovací platformě činnosti provozované na provozní platformě INITIATE CONSTRUCT DELIVER MAINTAIN & SUPPORT JUSTIFY DEFINEREQUIRE-MENTS MODEL TESTSIN THE SMALL TESTSINTHE LARGE RELEASE SUPPORT DEFINEMGMTDOCUMENTS DEFINEINFRA-STRUCTURE GENERALIZE PROGRAM REWORK ASSESS IDENTIFY DEFECTS zahajovací tým pracovní tým provozní tým podpora týmem projektové kanceláře podpora týmem „help desk“ spolupráce zástupců budoucích uživatelů spolupráce všech budoucích uživatelů PODPŮRNÉ PROCESYzajištění kvality, people management, risc management, reuse management, právní zabezpečení, bezpečnost, řízení infrastruktury, ...

12. SUPPORT PROCESSES FOR THE ADVANCE SOFTWARE DEVELOPMENT MODEL QUALITYASSURANCE RISK MANAGEMENT TRAINING & EDUCATION IDENTIFYA RISK ASSESSTHE RISK DEVELOPMITIGATIONSTRATEGIES PERFORM INTROTRAININGS PERFORM DETAILEDTRAININGS FOLLOWISOSTANDARDS DEVELOPA RISKMANAGEMENTPLAN MITIGATETHE RISK REPORTRISK DEVELOPA TRAININGPLAN REUSEMANAGEMENT METRICSMANAGEMENT DELIVERABLESMANAGEMENT INFRA-STRUCTUREMANAGEMENT COLLECTREUSABLEITEMS DEVELOPMETRICSPLAN PERFORMAND DISCUSS MANAGE SOFTWARECONFI-GURATION APPLYCMM, …TECHNIQUES

13. Nasazení rolí v jednotlivých fázích je odlišné Složení týmu a nasazení jeho členů se v různých fázích ASDM mění.

14. Alokace lidských zdrojů INITIATE CONSTRUCT DELIVER MAINTAIN & SUPPORT !!! při zahájení projektu se nemá plýtvat pracovní silou !!! poměr programátorských profesí k analytickým klesá se mění v závislosti na fázi projektu.

15. Struktura ASDM Co do dané fáze vstupuje! Co se v dané fázi dělá! Co je výstupem dané fáze! Jaké role se v dané fázi uplatňují!

16. Struktura ASDM

17. INITIATE PHASE The main goal of the Initiate phase is to lay the foundation for a successful project.

18. estimator / planner tools specialist standards specialist process specialist quality assurance engineer subject matter expert project sponsor project manager JAD / meeting facilitator technical writer infrastructure engineer analyst INITIATE PHASE allocated maintenance changes from maintain & support phase The main goal is to lay the foundation for a successful project. This is hard due to pressures by senior management and developers to start “real work” as soon as possible. JUSTIFY define and validateREQUIRE-MENTS management documentsinitial requirementproject infrastructureproject fundingproject charter define initialmanagementDOCUMENTS define INFRA-STRUCTURE to construct phase potential roles during this phase:

19. This is determining what needs to be built. Initial requirements area foundation from which modeling can begin. DEFINE AND VALIDATE INITIAL REQUIREMENTS DEFINESYSTEMFUNCTIONS DEFINESYSTEMSCENARIOS DRAWPROCESMAPS visioncommitmentreasibility studyexisting applicationsmaintenance changes requirement documentation(forms, tables, diagrams, ...)project scope HOLD SESSIONS CREATEMODELINGCARDS PRIORITIZEREQUIRE-MENTS INTERVIEWUSERS SIMULATESCENARIOS WALK THROUGHPROTOTYPES Analýza požadavků

20. Purpose of this process is to initiate documents such as the project plan and project risk assessment.They must be started at the beginning of the project and then maintained throughout its life. DEFINE INITIAL MANAGEMENT DOCUMENTS DEFINETASKS CREATEINITIALSCHEDULE DEFINEPROJECTSCOPE reasibility studyproject infrastructureinitial requirementsproject objectives project planrisk assessmentmaster testquality assurance plan CREATEINITIALESTIMATE CREATEINITIAL RISKASSESMENT CREATEINITIAL QUALITY ASSUR. PLAN Definice dokumentů pro management

21. The purpose is to determine whether or not an application should be built. It is a reality check to determine whether or not a project makes a sense. JUSTIFY IDENTIFYIMPLEMEN-TATIONALTERNATIVES DETERMINEOPERATIONALFEASIBILITY IDENTIFYRISKS visionestimaterequirements documentationschedulerisk assessment feasibility studyrecommendationsproject fundingrisk assessment DETERMINEECONOMICFEASIBILITY DETERMINETECHNICALFEASIBILITY CHOOSEALTERNATIVE Studie proveditelnostiFeasibility Study

22. The project infrastructure is made up of the project team,the tools that they will use,and a tailored versionof the software development process that the team will follow. DEFINE INFRASTRUCTURE SELECTTOOLS DEFINE TEAM GREATEGROUPKNOWLEDGEBASE project planinitial requirementsfeasibility studyexisting infrastructure team definition(profile, skill database, ...)tools selectiontailored software processgroup knowledges SELECT METHODO-LOGY SELECT STANDARDSANDGUIDELINES NEGOTIATEDELIVE-RABLES Definice infrastruktury(Architektury projektu)

23. INITIATE PHASE Checklists

24. INITIATEentrance conditions checklist • senior management support exists to initiate a new project • maintenance changes pertaining to previous version (if any) are identified • infrastructure is available

25. INITIATEto be performed checklist • the initial requirements have been defined and validated • the initial management documents have been defined • the project has been technically, economically and operationally justified • required project infrastructure has been defined • potential reusable artifacts have been identified • project team has been identified and trained where appropriate

26. INITIATEexit conditions checklist • project plan has been accepted by senior management • project schedule has been accepted by senior mgmt • initial risk assessment has been performed • initial requirements have been accepted by senior management • appropriate standards and guidelines have been identified • software development process has been tailored to meet specific needs for the project • appropriate tools are prepared/installed • project funding has been obtained • project charter has been defined and accepted • project team has been assembled • lessons learned have been identified - team should take the time to consider the processes that could be improved

27. INITIATE PHASE Define and validate initial requirements Stage Checklists

28. Define and validate initial req.to be performed checklist • business process models have been developed and validated • user interface prototype has been developed and validated (if appropriate) • technical requirements have been documented and validated • operation and support requirements have been documented and validated • requirements have been prioritized • requests of appropriate stakeholders have been considered • reusable artifacts have been identified • risk assessment document has been updated • decisions (both made and forgone) were documented into group memory • metrics have been collected

29. Define and validate initial req.exit conditions checklist • requirement documents have been validated and accepted by the user community • requirement documents have been validated and accepted by the senior management • the scope of the project has been defined and accepted - definition of the functionality that will, and will not, be implemented

30. INITIATE PHASE Define the initial management documents Stage Checklists

31. Define the initial mgmt documents entrance conditions checklist • the project infrastructure has been selected • the feasibility study has been at least started • the project objectives have been identified and agreed to • initial requirements have been defined

32. Define the initial mgmt documents to be performed checklist • build-versus-buy decisions have been made • application release schedule has been defined or updated • project estimate has been developed and accepted • metric plan has been developed and accepted • project plan has been developed and accepted • assumptions and constraints have been documented • risk assessment has been started • test plan has been developed and accepted • reusable artifacts have been identified • risk assessment document has been updated • decisions (both made and forgone) were documented into group memory • metrics have been collected

33. Define the initial mgmt documents exit conditions checklist • initial version of the project plan has been accepted by senior management • initial version of the project plan has been accepted by the development team • initial version of the risk assessment has been accepted by senior management

34. INITIATE PHASE Justify Stage Checklists

35. Justifyentrance conditions checklist • development of the requirements documents has begun • development of the project plan has begun • development of the risk assessment has begun • definition of the project infrastructure has begun • access to key users, technical experts, and financial experts has been obtained

36. Justifyto be performed checklist • implementation alternatives were identified and considered • economic feasibility of each alternative was determined • cost/benefit analysis was performed • technical feasibility of each alternative was determined • operational feasibility of each alternative was determined • alternatives were suggested to senior management for approval • risk assessment document has been update • decisions (both made and forgone) were documented into group memory • metrics have been collected

37. INITIATE PHASE Define infrastructure Stage Checklists

38. Define infrastructureentrance conditions checklist • development of the initial requirements has begun • development of the project plan has begun • development of the feasibility study has begun • existing infrastructure is available

39. Define infrastructureto be performed checklist • project team has been defined • skill assessment for each team member has been defined • required training for each member has been defined and performed • project skill matrix was developed • potential subcontractors have been contracted • project deliverables have been negotiated with senior management and agreed to • group memory has been organized • shared library of books etc. is available • reusable artifacts have been identified • risk assessment document has been updated • decisions (both made and forgone) were documented into group memory • metrics have been collected

40. Define infrastructureexit conditions checklist • the team has been accepted by senior management • the tailored software process has been accepted by the team members • the tailored software process has been accepted by senior management • group memory has been initiated

41. Poznámky Co je to studie proveditelnosti Co je to infrastruktura projektu Rizika v inicializační fázi Co je to Group Memory Co je to tým Co je to Change request

42. Feasibility study • can the system be built (technically feasible) • can we afford to build the system(economically feasible) • can we maintain and support the system(operationally feasible)

43. Project infrastructure • team defined for the project • tools defined for the project • processes defined/selected for the project

44. Potential risks in initiate phase • senior management pressures to start too early • pressure to bring people on the project too early • beware the new toy syndrome • resistance to change

45. Group memory • records of what team accomplished • decisions made • lessons learned

46. Team definition • description of who will be involved with a project incl. its reporting structure • project skill matrix • organization chart

47. Change requests • software change request for potential improvements of the deliverable or inconsistency with the requirements • software problem report of potential software defects identified

48. A na závěr! Pro řízení velkých projektů využívajících objektovou technologii je třeba nastavit procesy včetně rolí participantů v procesech • zajistit potřebnou infrastrukturu (projektová kancelář, nástroje, ...) • vyřešit problém měření kvality • vhodně nastavit motivační faktory podporovat objektově orientované paradigma • shromažďovat znovupožitelné komponenty (CONSTRUCT/generalize) • uchovávat všechna rozhodnutí a informace, budovat “group memory” • využívat “group memory” (INITIATE/justify) • rozvíjet lidský potenciál (DELIVER/assess) rozlišovat platformy (vývojová, testovací, provozní) • není možné se spoléhat na “zázračné” vlastnosti moderních nástrojů

49. KONEC!