X36SSP Správa softwarových produktů 6. přednáška Ing. Martin Molhanec ČVUT – FEL K13113.

Prezentace na téma: "X36SSP Správa softwarových produktů 6. přednáška Ing. Martin Molhanec ČVUT – FEL K13113."— Transkript prezentace:

1 X36SSP Správa softwarových produktů 6. přednáška Ing. Martin Molhanec ČVUT – FEL K13113

2 OBJECT ORIENTED SOFTWARE PROCESS

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

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

5 Advanced SW Development Model (ASDM) INICIACE KONSTRUKCE DODÁNÍ PROVOZ 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. správně definovat požadavky na systémsprávně definovat požadavky na systém vybrat optimální variantu řešenívybrat optimální variantu řešení naplánovat a připravit vše potřebné k zahájení projektu...naplánovat a připravit vše potřebné k zahájení projektu... správně definovat požadavky na systémsprávně definovat požadavky na systém vybrat optimální variantu řešenívybrat optimální variantu řešení naplánovat a připravit vše potřebné k zahájení projektu...naplánovat a připravit vše potřebné k zahájení projektu... oblasti klíčových výkonnostních požadavků Pro každou fázi jsou identifikovány charakteristické činnosti a k nim jsou definovány pracovní role a odpovědnosti. provést dobře a efektivně analýzuprovést dobře a efektivně analýzu co nejlépe sestavit a otestovat systémco nejlépe sestavit a otestovat systém mít řádnou dokumentaci...mít řádnou dokumentaci... provést dobře a efektivně analýzuprovést dobře a efektivně analýzu co nejlépe sestavit a otestovat systémco nejlépe sestavit a otestovat systém mít řádnou dokumentaci...mít řádnou dokumentaci... efektivně zahájit provoz systémuefektivně zahájit provoz systému dobře zaškolit uživatele...dobře zaškolit uživatele... efektivně zahájit provoz systémuefektivně zahájit provoz systému dobře zaškolit uživatele...dobře zaškolit uživatele... spokojenost uživatelů s podporouspokojenost uživatelů s podporou rychlá oprava chybrychlá oprava chyb mít dostatečnou znalostní bázi požadavků a návrhů pro novou verzi...mít dostatečnou znalostní bázi požadavků a návrhů pro novou verzi... spokojenost uživatelů s podporouspokojenost uživatelů s podporou rychlá oprava chybrychlá oprava chyb mít dostatečnou znalostní bázi požadavků a návrhů pro novou verzi...mít dostatečnou znalostní bázi požadavků a návrhů pro novou verzi... Opakování!

6 maintenance & support in-house development using packages in-house development using packages project initiation INITIATE CONSTRUCT DELIVER MAINTAIN & SUPORT JUSTIFY define and validate REQUIRE- MENTS define initial management DOCUMENTS define INFRA- STRUCTURE MODEL TEST in the small GENERALIZE PROGRAM PROCESS TEST in the large RELEASE REWORK ASSESS SUPPORT identify defects and enhance- ments SOFTWARE DEVELOPMENT PROCESS 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 Opakování!

7 činnosti provozované na provozní platformě činnosti provozované na vývojové a testovací platformě INITIATEINITIATECONSTRUCTCONSTRUCTDELIVERDELIVER MAINTAIN & SUPPORT PODPŮRNÉ PROCESY zajištění kvality, people management, risc management, reuse management, právní zabezpečení, bezpečnost, řízení infrastruktury,... JUSTIFYJUSTIFY DEFINE REQUIRE- MENTS DEFINE MGMT DOCUMENTS DEFINE INFRA- STRUCTURE MODELMODEL TESTS IN THE SMALL GENERALIZEGENERALIZEPROGRAMPROGRAM TESTS IN THE LARGE RELEASERELEASE REWORKREWORKASSESSASSESS SUPPORTSUPPORT IDENTIFY DEFECTS podpora týmem „help desk“ podpora týmem projektové kanceláře spolupráce všech budoucích uživatelů spolupráce zástupců budoucích uživatelů provozní tým pracovní tým zahajovací tým Scott W. Ambler: Object-Oriented Process Pattern Opakování!

8 SUPPORT PROCESSES FOR THE ADVANCE SOFTWARE DEVELOPMENT MODEL RISK MANAGEMENT IDENTIFY A RISK ASSESS THE RISK DEVELOP MITIGATION STRATEGIES MITIGATE THE RISK REPORT RISK QUALITY ASSURANCE FOLLOW ISO STANDARDS TRAINING & EDUCATION DEVELOP A TRAINING PLAN REUSE MANAGEMENT COLLECT REUSABLE ITEMS METRICS MANAGEMENT DEVELOP METRICS PLAN DELIVERABLES MANAGEMENT INFRA- STRUCTURE MANAGEMENT MANAGE SOFTWARE CONFI- GURATION MANAGE SOFTWARE CONFI- GURATION APPLY CMM, … TECHNIQUES DEVELOP A RISK MANAGEMENT PLAN PERFORM INTRO TRAININGS PERFORM INTRO TRAININGS PERFORM DETAILED TRAININGS PERFORM DETAILED TRAININGS PERFORM AND DISCUSS Opakování!

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 MODEL TEST in the small GENERALIZE PROGRAM PROCESS allocated maintenance changes management documents initial requirement project infrastructure project funding project charter potential roles during this phase: project manager software application documentation requirement allocation matrix models, source code management documents team leader software conf. manager test manager architectural modeler domain programmer subject matter expert quality assurance engineer domain modeler mentor infrastructure engineer technical writer component engineer reuse engineer test engineer proof-of-concept engineer from maintain & support phase CONSTRUCT 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.

11 MODEL ARCHITECTU- RAL MODELING requirement documentation modeling standards TECHNICAL MODELING HUMAN INTERACTION DOMAIN MODELING PROBLEM DOMAIN MODELING MANAGE METRICS TASK MODELING models (diagrams, docs) test plan requirement alloc. matrix 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.

12 PROGRAM PROCESS UNDERSTAND MODELS models project infrastructure MAKE SOURCE CODE PREPARE PROJECT INTEGRATION PLAN PREPARE CODE FOR INSPECTIONS INTEGRATE AND PACKAGE INTEGRATE AND PACKAGE SYNCHRONIZE SOURCE CODE WITH MODELS packaged application source code software components OPTIMIZE CODE BUILD SOFTWARE APPLICATION REUSE EXISTING CODE AND COMPONENTS DOCUMENT SOFTWARE APPLICATION DOCUMENT SOURCE CODE PERFORM METRICS 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.

13 GENERALIZE IDENTIFY POTENTIAL REUSABLE ITEMS project deliverables HOLD GENERALIZA- TION SESSIONS RELEASE MAKE DOCUMENTA- TION PERFORM METRICS REFACTOR CODE reusable items 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.

14 TEST IN THE SMALL DEVELOP TEST PLAN DEVELOP TEST PLAN models source code requirements master test quality assurance plan SCENARIO AND PROCESS TEST RECORD DEFECTS WALK- THROUGH MODELS WALK- THROUGH MODELS USER INTERFACE TESTING PROGRAM CODE TESTING PROGRAM CODE TESTING REVIEW TECHNICAL DESIGN INSPECT SOURCE CODE REVIEW PROTOTYPES tested artifacts test results master test quality assurance plan 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.

15 CONSTRUCT PHASE Checklist

16 CONSTRUCT to 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 CONSTRUCT exit 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 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! Závěr Čí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