1. X36SSP Správa softwarových produktů 7. 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 Fáze odbavení OOSPFáze odbavení OOSP Fáze podpory OOSPFáze podpory OOSP

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

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

6. DELIVER PHASE The main goal here is to deploy the application, including the appropriate documentation, to the user community.

7. TEST in the large RELEASE REWORK ASSESS packaged application documentation models and source code management documents requirement alloc. matrix potential roles during this phase: tested application documentation models requirement alloc. matrix project manager support manager operations manager training manager developer support engineer operations engineer trainer project auditor testing manager test engineer technical writer DELIVER PHASE The main goal here is to deploy the application, including the appropriate documentation, to the user community.

8. TEST IN THE LARGE ACCEPT TEST PLAN packaged application master test quality assurance plan previous test results FUNCTION TEST OPERATIONS TEST STRESS TEST ALPHA/BETA TEST INSTALLATION TEST tested application test results PERFORM METRICS USER ACCEPTANCE TEST RECORD DEFECTS The goal here is to ensure that the application works on its entirety. This includes user testing in which the application is specifically tested by members of user community.

9. Test in the large entrance conditions checklist  The application has been packaged for delivery  The master test/QA plan in available  Previous test results are available  Team members are trained

10. Test in the large to be performed checklist  The master test/QA plan was accepted  Defects have been recorded  All particular tests were performed  Artifacts that are potentially reusable by this project team have been identified and used  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

11. Test in the large exit conditions checklist  The application has passed testing  Test results were documented

12. REWORK PRIORITIZE DEFECTS tested application tested results, documents models, source code requirement alloc. matrix organizational priorities REMODEL TEST IN THE SMALL UPDATE DOCUMENTA- TION PERFORM METRICS REPROGRAM reworked application models, source code documentation requirement alloc. matrix The focus of this process is to fix the critical defects discovered by the “test in the large” process to ensure the successful deployment of the application. It is like a miniature version of the “construct” process.

13. Rework entrance conditions checklist  The test results are available  The organization priorities are known  The current version of software is able to be reworked  Team members are trained

14. Rework to be performed checklist  Defects have been prioritized  The models have been reworked  The requirement allocation matrix has been reworked  The support documentation has been reworked  The user documentation has been reworked  The operations documentation has been reworked  The source code has been reworked  The application was tested in the small (system tests)  Reusable artifacts were used  Risk assessment document was updated  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

15. Rework exit conditions checklist  The selected and prioritized defects have been reworked  The construct phase deliverables (code, doc, models) are consistent  The application has been repackaged for testing

16. RELEASE ACCEPT TRAINING AND RELEASE PLANS release procedures training plans application package operations and support documentation ACCEPT USER SUPPORT AND OPERATIONS DOCUMENTS DEPLOY THE OPERATION PROCESS FINALIZE CONVERSION OF LEGACY DATA DEPLOY THE SUPPORT PROCESS TRAIN OPERATIONS STAFF ANNONCE ACTUAL RELEASE TO USERS TRAIN SUPPORT STAFF PACKAGE APPLICATION released application procedures documentation TRAIN USERS PERFORM METRICS DEPLOY THE APPLICATION The goal of this process is to deploy the application and its corresponding documentation successfully to the user community (end users and also operations department staff that will help the users work with the application effectively).

17. Release entrance conditions checklist  The application has been packaged for release  Organization release procedures are available  The training plan for user, operations and support communities are available  The documentation is available to be deployed  Team members are trained

18. Release to be performed checklist  The training and release plans have been accepted  The user, support and operations documentation has been accepted  The legacy data has been converted  The product baseline and version description has been finalized  The release notes have been finalized  The installation procedures have been finalized  The operation staff has been trained  The support staff has been trained  The release was announced  The user community was trained  The application was deployed to user community  Risk management document was updated  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

19. Release exit conditions checklist  The user, support, and operations communities have been trained  The application has been deployed  The application and its documentation has been accepted  The support environment has been installed

20. ASSESS project deliverables project metrics group knowledge base REVIEW PROJECT DELIVERA- BLES ASSESS TEAM MEMBER PERFORMANCE DEVELOP LEARNING HISTORY DEVELOP PROJECT ASSESSMENT learning history project and staff assessment process improvement plan ANALYZE METRICS DEVELOP STAFF ASSESSMENT ASSESS USER INVOLVEMENT DEVELOP SOFTWARE PROCESS IMPROV. PLAN This process has two goals: a) for the project team, to learn from its experiences developing the application b) to provide an opportunity to evaluate the members of the project team to support their personal growth

21. Assess entrance conditions checklist  Management support exists  Project members and key user representatives are available  Project deliverables, including the group memory and collected metrics are available  Team members are trained

22. Assess to be performed checklist  Project deliverables were reviewed  Metrics collected during the project were presented and analyzed  The performance of individual team members was assessed  The involvement of user community was assessed  The involvement of support community was assessed  The involvement of operations community was assessed  The project assessment was documented  The learning history was developed  The software process improvement plan was developed  Risk assessment document has been updated  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

23. Assess exit conditions checklist  All staff assessments are complete  The project assessment has been presented to senior management  The software process improvement plan has been accepted

24. potential roles during this phase: support manager support engineer operations manager operations engineer config. control board mgr. configuration item owner SUPPORT identify defects and enhance- ments tested application documentation models requirement alloc. matrix allocated maintenance changes to initiate or construct phase MAINTAIN & SUPPORT PHASE The goal here is to keep the application running in production and to ensure that changes to the application are well identified and acted on.

25. SUPPORT RESPOND TO REQUEST support requests DETERMINE SOLUTION IDENTIFY HW AND SW UPGRADES IDENTIFY TRAINING PLAN RECORD SOFTWARE CHANGE REQUESTS PROVIDE RESOLVE INFORMATION solution software change requests The objective of this process is to respond to incoming support requests from users, to identify a resolution for the request, and then to oversee the implementation of that resolution. This is performed on a continual, daily basis way.

26. Support to be performed checklist  The support request was responded to promptly and politely  Information was collected about the support request  The support request priority was determined  The problem was simulated, if necessary  If necessary, an upgrade for requester was determined and scheduled  Recognized defects were recorded  The support request was closed out with permission of the requester  The requester was informed of the escalation and expectations were set

27. IDENTIFY DEFECTS AND ENHANCEMENTS ANALYSE SOFTWARE CHANGE REQUESTS software change requests models requirement alloc. matrix documentation release schedule PRIORITIZE MAINTENANCE CHANGES ALLOCATE MAINTENANCE CHANGES TO CONF. ITEMS allocated maintenance changes The purpose of this process is to analyze software change requests defined during the “support” process so that maintenance changes to the application may be identified and allocated to the appropriate configuration items. This manages basic change control issues and identifies requirements for future releases of the application.

28. Identify defects and Enhancements to be performed checklist  The type of each SCR was determined and prioritized  Maintenance changes were allocated and impact of each maintenance change was determined  Each maintenance change was scheduled  The initiator of each SCR was notified of the status  Reusable artifacts were used  Risk assessment document was updated  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

29. product baseline Software Configuration Management SCM is a set of engineering procedures for tracking and documenting software, including all its related deliverables, throughout their life cycles to ensure that all changes are recorded and the current state of the software is known and reproducible. TermDefinition Revision is any change to a deliverable.revision Version encompasses one or more revisions.version Baseline is a tested and certified version. A baseline represents a milestone which thereafter serves as the basis for further development and that can be modified only through formal change control procedures. A particular version becomes a baseline when a responsible group decides to designate it as such. There are four different types of baselines. baseline The application requirements, and related test criteria, that are defined in such a manner that software development can be performed. functional baseline A baseline where all requirements defined by the functional baseline are designed/mapped to entities within your design. allocated baseline This represents the incremental software builds needed to develop the application. Developmental baselines are major deliverables of the Program stage. developmental baseline The exact version of the software that is released to the user community.product baseline developmental baseline allocated baseline functional baseline

30. Software Configuration Management SCM is comprised of four major activities: Configuration Identification Configuration identification is the procedure of designating configuration items (CIs), any deliverable and the components. For the most part, CIs are identified during the Construct phase. Configuration Control Configuration control is the management of changes to CIs. The basic idea is that you should not make changes to software just because somebody asked for the changes, instead you should make changes because is makes sense to do so. Developers should be willing to accept constructive criticism, but at the same time be prepared to stand up and fight for the integrity of their work. A critical component here is the prioritization of requested changes and allocation the work to the developers. Configuration Auditing Configuration auditing is the procedure of verifying and validating the fact that a proposed configuration is complete and consistent. The main goals are to verify that a deliverable exists, is complete, is accurate, and contains an up- to-date revision history. Be aware that developers will often fight the necessity of maintaining revision history for their deliverables until a defect in their work is discovered and they need to go back and fix it. Configuration Status Accounting Configuration Status Accounting is the procedure of keeping records of the other three SCM activities. The goal is to develop and maintain key status reports about the SCM process, including information such as proposed changes, approved changes, and problem reports sorted in priority order. These reports are used by the configuration control board of the project. SCM Tips: CIs should encapsulate a single, cohesive concept. Record every problem and change request. Close important changes/problems first. Put all deliverables under SCM control, not just code. All developers should be subject to SCM procedures.

31. Závěr Fáze odbavení bývá podceňována – nicméně je nesmírně důležitá z hlediska budoucího uživatele produktu. Fáze podpory produktu nám ukazuje, že prodejem vše nekončí! Dnešní doba si žádá nejen dobře naprogramovaný užitečný produkt, ale i produkt s dobrým odbavením a supportem!