X 36 SSP Správa softwarových produktů 6 přednáška

X 36 SSP Správa softwarových produktů 6. přednáška Ing. Martin Molhanec ČVUT – FEL K 13113

OBJECT ORIENTED SOFTWARE PROCESS

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

Opakování! SOFTWARE DEVELOPMENT PROCESS project initiation in-house development using packages maintenance & support CONSTRUCTION INITIATION • well define user requirements • well end efficient performed analysis • select optimal solution • best system assembling and testing • prepare all required for project start success. . . • to have good documentation. . . DELIVER • start system use seamless and efectively • well prepare users of the system . . . MAINTAIN & SUPORT • 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

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

Opakování! SOFTWARE DEVELOPMENT PROCESS project initiation in-house development using packages CONSTRUCT INITIATE JUSTIFY define and validate REQUIREMENTS define initial management DOCUMENTS define INFRASTRUCTURE MODEL TEST in the small GENERALIZE PROGRAM PROCESS project office team user experts maintenance & support MAINTAIN & SUPORT DELIVER TEST in the large REWORK development team RELEASE SUPPORT ASSESS identify defects and enhancements support team end-users quality assurance, manage project, trainig&education, manage people, manage risk, manage reuse, manage metrics, manage deliverables, manage infrastructure GO NEXT

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

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

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.

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

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 ARCHITECTURAL MODELING requirement documentation modeling standards PROBLEM DOMAIN MODELING TECHNICAL MODELING HUMAN INTERACTION DOMAIN MODELING TASK MODELING models (diagrams, docs) test plan requirement alloc. matrix MANAGE 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. PROGRAM PROCESS UNDERSTAND MODELS MAKE SOURCE CODE SYNCHRONIZE SOURCE CODE WITH MODELS PREPARE CODE FOR INSPECTIONS PREPARE PROJECT INTEGRATION PLAN INTEGRATE AND PACKAGE BUILD SOFTWARE APPLICATION OPTIMIZE CODE REUSE EXISTING CODE AND COMPONENTS DOCUMENT SOURCE CODE DOCUMENT SOFTWARE APPLICATION PERFORM METRICS models project infrastructure packaged application source code software components

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 IDENTIFY POTENTIAL REUSABLE ITEMS HOLD GENERALIZATION SESSIONS REFACTOR CODE project deliverables reusable items MAKE DOCUMENTATION RELEASE PERFORM METRICS

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

CONSTRUCT PHASE Checklist

CONSTRUCT to be performed checklist R R R R 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

CONSTRUCT exit conditions checklist R R R R requirement allocation matrix has been updated project plan was updated appropriately models, source code and documentation were baselined test plan has been updated 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

CONSTRUCT PHASE Model Stage Checklists

Model entrance conditions checklist R R 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

Model to be performed checklist R R R R R 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

Model exit conditions checklist R R R 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

CONSTRUCT PHASE Program Stage Cheklists

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

Program to be performed checklist R R R R R 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

CONSTRUCT PHASE Generalize Stage Cheklists

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

Generalize to be performed checklist R R R R R 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

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

CONSTRUCT PHASE Test in the small Stage Checklists

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

Test in the small to be performed checklist R R R R R 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 analyzed risk assessment document has been updated decisions (both made and forgone) were documented into group memory metrics have been collected

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

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í!

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í!