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

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

2. OBJECT ORIENTED SOFTWARE PROCESS

3. Dnešní témata Připomenutí co je to OOSP Konstrukční fáze OOSP

4. Opakování! 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

5. Opakování! 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.

6. Opakování! 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

7. Opakování! Scott W. Ambler: Object-OrientedProcess 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, ...

8. Opakování! 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

9. CONSTRUCT PHASE The main goal of the Construction phase is to build working software that is ready to be tested and delivered to your user community.

10. domain programmer infrastructure engineer technical writer test engineer reuse engineer component engineer project manager team leader proof-of-concept engineer software conf. manager test manager architectural modeler subject matter expert mentor quality assurance engineer domain modeler CONSTRUCT PHASE allocated maintenance changes from maintain & support phase The main goal of the construct phase is to build working software that is ready to be tested and delivered to its user community. MODEL TESTin the small management documentsinitial requirementproject infrastructureproject fundingproject charter software applicationdocumentationrequirement allocation matrix models, source codemanagement documents GENERALIZE PROGRAMPROCESS potential roles during this phase:

11. The developers first need to understand what the are supposed to build. This “software analysis and design” process should be performed iteratively, because of developers do not need to do all of the analysis first time, then do all of the design and then all of the coding. MODEL ARCHITECTU-RALMODELING TECHNICALMODELING TASKMODELING requirement documentationmodeling standards models (diagrams, docs)test planrequirement alloc. matrix PROBLEMDOMAINMODELING HUMAN INTERACTIONDOMAINMODELING MANAGEMETRICS

12. During this process the source code is written, documented, reviewed, tested and packaged for delivery. For this to be successful, the models must drive the development of the source code. This process is far more to writing source code of programs. PROGRAM PROCESS UNDERSTANDMODELS MAKESOURCECODE SYNCHRONIZESOURCE CODEWITHMODELS PREPARECODE FORINSPECTIONS PREPAREPROJECTINTEGRATIONPLAN INTEGRATEAND PACKAGE modelsproject infrastructure packaged applicationsource codesoftware components BUILDSOFTWAREAPPLICATION OPTIMIZE CODE REUSEEXISTINGCODE ANDCOMPONENTS DOCUMENTSOURCECODE DOCUMENTSOFTWAREAPPLICATION PERFORMMETRICS

13. This is the recognition that the short-term pressures of software development result in the temptation for developers to settle for specific, non-reusable solutions. In this process, application specific items are identified and then reworked to be reusable by other development teams. GENERALIZE IDENTIFYPOTENTIALREUSABLEITEMS HOLDGENERALIZA-TIONSESSIONS REFACTORCODE project deliverables reusable items MAKEDOCUMENTA-TION RELEASE PERFORMMETRICS

14. This process focuses on the verification, validation, and testing of documents, models, and source code produced. In many ways it is quality assurance techniques such as peer reviews and inspections combined with unit testing techniques for validating code. TEST IN THE SMALL DEVELOPTEST PLAN SCENARIOANDPROCESSTEST REVIEWPROTOTYPES modelssource coderequirementsmaster test quality assurance plan tested artifactstest resultsmaster testquality assurance plan WALK- THROUGHMODELS RECORDDEFECTS PROGRAM CODETESTING USERINTERFACETESTING INSPECTSOURCECODE REVIEWTECHNICALDESIGN

15. CONSTRUCT PHASE Checklist

16. CONSTRUCTto be performed checklist • the models for the application have been developed and validated • the source code for the application have been developed and validated • reusable artifacts have been identified • potential artifacts to be generalized for reuse have been identified and potentially generalized • user documentation has been developed • decisions (both made and forgone) were documented into group memory • metrics have been collected

17. CONSTRUCTexit conditions checklist • requirement allocation matrix has been updated • project plan was updated appropriately • models, source code and documentation were baselined • test plan has been updated for for the test in the large • user, support and operations documentation is ready for testing • application has been packaged for testing • training, release, and project plans have been updated appropriately

18. CONSTRUCT PHASE Model Stage Checklists

19. Model entrance conditions checklist • initial requirements have been documented and accepted • modeling and programming tools were prepared • subject matter experts have been scheduled • team members have been given the appropriate training

20. Model to be performed checklist • models were assembled and validated • user interface prototype was developed and validated • assumptions made during modeling were challenged and documented appropriately • manual processes, legacy applications, and new system development was identified and modeled accordingly • requirement allocation matrix was updated/developed • reusable artifacts have been identified and used • risk assessment document has been updated • decisions (both made and forgone) were documented into group memory • metrics have been collected

21. Model exit conditions checklist • models have been appropriately documented • models have been validated • test plan has been updated • models have been accepted by the team • models have been accepted by senior management

22. CONSTRUCT PHASE Program Stage Cheklists

23. Program entrance conditions checklist • appropriate models are available • development tools are installed • professional programmers are available • team members have appropriate training

24. Program to be performed checklist • programmers worked with the designers to understand models • source code was written and documented • source code was synchronized with models • source code was prepared for inspection during test in the small • integration plan was prepared • reusable artifacts have been used • risk assessment document has been updated • decisions (both made and forgone) were documented into group memory • metrics have been collected

25. CONSTRUCT PHASE Generalize Stage Cheklists

26. Generalize entrance conditions checklist • project deliverable • experienced reuse engineers are available • organizational support for reuse exists • team members have been given the appropriate training

27. Generalize to be performed checklist • potential reusable items have been identified • generalization sessions were held • potentially reusable items were refactored • reusable items were documented • examples of how to reuse reusable items were documented • reusable items were released into the repository and made accessible to all developers • risk assessment document has been updated • decisions (both made and forgone) were documented into group memory • metrics have been collected

28. Generalize exit conditions checklist • generalized items have been submitted to the reuse repository • all developers have been made aware of new items

29. CONSTRUCT PHASE Test in the small Stage Checklists

30. Test in the small entrance conditions checklist • there are artifacts to be tested • test plan exists • requirements have been documented • team members have appropriate training

31. Test in the small to be performed checklist • test plan was updated appropriately • models were reviewed and walked through and accepted • user interface prototypes were reviewed and tested • source code was inspected and improved before being tested • perform software testing • defects were recorded and analyzed • risk assessment document has been updated • decisions (both made and forgone) were documented into group memory • metrics have been collected

32. Test in the small exit conditions checklist • all items have been tested, reviewed and updated accordingly • master test has been updated for “test in the large”

33. Závěr • Konstrukční fáze projektu je to,co se obvykle (+/-) učí jako SI (softwarové inženýrství). • Celé programování je pouze jedna krabička z celé Konstrukční fáze! Čím větší je projekt, tím důležitější pro jeho úspěch jsou věci, které stojí mimo vlastní programování!

34. Závěr • Konstrukční fáze projektu je to,co se obvykle (+/-) učí jako SI (softwarové inženýrství). • Celé programování je pouze jedna krabička z celé Konstrukční fáze! A to nemluvíme vůbec nic o marketingu, atp.! Čím větší je projekt, tím důležitější pro jeho úspěch jsou věci, které stojí mimo vlastní programování!

35. KONEC!