X36SSPX36SSPSpráva softwarových Správa softwarových

produktůproduktů7. 7. přednáškapřednáška

X36SSPX36SSPSpráva softwarových Správa softwarových

produktůproduktů7. 7. přednáškapřednáška

Ing. Martin MolhanecIng. Martin MolhanecČVUT – FELČVUT – FEL

K13113K13113

OBJECT ORIENTEDOBJECT ORIENTED

SOFTWARE PROCESSSOFTWARE PROCESS

Dnešní témataDnešní témataDnešní témataDnešní témata

•Připomenutí co je to Připomenutí co je to OOSPOOSP•Fáze odbavení OOSPFáze odbavení OOSP•Fáze podpory OOSPFáze podpory OOSP

maintenance & supportmaintenance & support

in-house developmentusing packagesin-house developmentusing packages

project initiationproject initiation

INITIATEINITIATE CONSTRUCTCONSTRUCT DELIVERDELIVER MAINTAIN & SUPORTMAINTAIN & SUPORT

JUSTIFYJUSTIFY

define and validate

REQUIRE-MENTS

define and validate

REQUIRE-MENTS

define initial

managementDOCUMENTS

define initial

managementDOCUMENTS

define INFRA-

STRUCTURE

define INFRA-

STRUCTURE

MODELMODEL TESTin the small

TESTin the small

GENERALIZEGENERALIZE PROGRAMPROCESSPROGRAMPROCESS

TESTin the large

TESTin the large RELEASERELEASE

REWORKREWORK ASSESSASSESS

SUPPORTSUPPORT

identifydefects and

enhance-ments

identifydefects and

enhance-ments

SOFTWARE DEVELOPMENT PROCESS

project office teamproject office team development teamdevelopment team support teamsupport team

user expertsuser experts end-usersend-users

quality assurance, manage project, trainig&education, manage people, manage risk, manage reuse, manage metrics,

manage deliverables, manage infrastructure

Opakování!

SUPPORT PROCESSES FOR THE ADVANCE SOFTWARE DEVELOPMENT MODEL

RISK MANAGEMENTRISK MANAGEMENT

IDENTIFYA RISK

IDENTIFYA RISK

ASSESSTHE RISKASSESS

THE RISK

DEVELOPMITIGATIONSTRATEGIES

DEVELOPMITIGATIONSTRATEGIES

MITIGATETHE RISKMITIGATETHE RISK

REPORTRISK

REPORTRISK

QUALITYASSURANCE

QUALITYASSURANCE

FOLLOWISO

STANDARDS

FOLLOWISO

STANDARDS

TRAINING & EDUCATIONTRAINING & EDUCATION

DEVELOPA TRAINING

PLAN

DEVELOPA TRAINING

PLAN

REUSEMANAGEMENT

REUSEMANAGEMENT

COLLECTREUSABLE

ITEMS

COLLECTREUSABLE

ITEMS

METRICSMANAGEMENT

METRICSMANAGEMENT

DEVELOPMETRICS

PLAN

DEVELOPMETRICS

PLAN

DELIVERABLESMANAGEMENT

DELIVERABLESMANAGEMENT

INFRA-STRUCTURE

MANAGEMENT

INFRA-STRUCTURE

MANAGEMENT

MANAGESOFTWARE

CONFI-GURATION

MANAGESOFTWARE

CONFI-GURATION

APPLYCMM, …

TECHNIQUES

APPLYCMM, …

TECHNIQUES

DEVELOPA RISK

MANAGEMENTPLAN

DEVELOPA RISK

MANAGEMENTPLAN

PERFORMINTRO

TRAININGS

PERFORMINTRO

TRAININGS

PERFORMDETAILEDTRAININGS

PERFORMDETAILEDTRAININGS

PERFORMAND

DISCUSS

PERFORMAND

DISCUSS

Opakování!

DELIVER PHASEDELIVER PHASEDELIVER PHASEDELIVER PHASEThe main goal here is to deploy The main goal here is to deploy the application, including the the application, including the

appropriate documentation, to the appropriate documentation, to the user community.user community.

TESTin the large

TESTin the large RELEASERELEASE

REWORKREWORK ASSESSASSESS

packaged applicationdocumentationmodels and source codemanagement documentsrequirement alloc. matrix

potential roles during this phase:

tested applicationdocumentationmodelsrequirement alloc. matrix

project managerproject manager

support managersupport manager

operations manageroperations manager

training managertraining manager

developerdeveloper

support engineersupport engineer

operations engineeroperations engineer

trainertrainer

project auditorproject auditor

testing managertesting manager

test engineertest engineer

technical writertechnical writer

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

TEST IN THE LARGE TEST IN THE LARGE

ACCEPTTESTPLAN

ACCEPTTESTPLAN

packaged applicationmaster testquality assurance planprevious test results

FUNCTIONTEST

FUNCTIONTEST

OPERATIONSTEST

OPERATIONSTEST

STRESSTEST

STRESSTEST

ALPHA/BETATEST

ALPHA/BETATEST

INSTALLATIONTEST

INSTALLATIONTEST

tested applicationtest results

PERFORMMETRICS

PERFORMMETRICS

USERACCEPTANCE

TEST

USERACCEPTANCE

TEST

RECORDDEFECTSRECORDDEFECTS

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.

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

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

Test in the large exit conditions checklist

The application has passed testing Test results were documented

REWORK REWORK

PRIORITIZEDEFECTS

PRIORITIZEDEFECTStested application

tested results, documentsmodels, source coderequirement alloc. matrixorganizational priorities

REMODELREMODEL

TESTIN THESMALL

TESTIN THESMALL

UPDATEDOCUMENTA-

TION

UPDATEDOCUMENTA-

TION

PERFORMMETRICS

PERFORMMETRICS

REPROGRAMREPROGRAM

reworked applicationmodels, source codedocumentationrequirement 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.

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

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

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

RELEASERELEASE

ACCEPT TRAINING

AND RELEASEPLANS

ACCEPT TRAINING

AND RELEASEPLANS

release procedurestraining plansapplication packageoperations and supportdocumentation

ACCEPT USERSUPPORT ANDOPERATIONSDOCUMENTS

ACCEPT USERSUPPORT ANDOPERATIONSDOCUMENTS

DEPLOY THE

OPERATIONPROCESS

DEPLOY THE

OPERATIONPROCESS

FINALIZECONVERSION

OF LEGACY DATA

FINALIZECONVERSION

OF LEGACY DATA

DEPLOY THE

SUPPORTPROCESS

DEPLOY THE

SUPPORTPROCESS

TRAINOPERATIONS

STAFF

TRAINOPERATIONS

STAFF

ANNONCEACTUAL

RELEASETO USERS

ANNONCEACTUAL

RELEASETO USERS

TRAINSUPPORT

STAFF

TRAINSUPPORT

STAFF

PACKAGEAPPLICATION

PACKAGEAPPLICATION

released applicationproceduresdocumentation

TRAINUSERSTRAINUSERS

PERFORMMETRICS

PERFORMMETRICS

DEPLOY THE

APPLICATION

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).

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

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

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

ASSESS ASSESS

project deliverablesproject metricsgroup knowledge base

REVIEWPROJECT

DELIVERA-BLES

REVIEWPROJECT

DELIVERA-BLES

ASSESSTEAM

MEMBERPERFORMANCE

ASSESSTEAM

MEMBERPERFORMANCE

DEVELOPLEARNINGHISTORY

DEVELOPLEARNINGHISTORY

DEVELOPPROJECT

ASSESSMENT

DEVELOPPROJECT

ASSESSMENT

learning history project and staff assessmentprocess improvement plan

ANALYZEMETRICSANALYZEMETRICS

DEVELOPSTAFF

ASSESSMENT

DEVELOPSTAFF

ASSESSMENT

ASSESSUSER

INVOLVEMENT

ASSESSUSER

INVOLVEMENT

DEVELOPSOFTWAREPROCESS

IMPROV. PLAN

DEVELOPSOFTWAREPROCESS

IMPROV. PLAN

This process has two goals: a) for the project team, to learn from its experiences developing the applicationb) to provide an opportunity to evaluate the members of the project team to support their personal growth

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

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

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

potential roles during this phase:

support managersupport manager

support engineersupport engineer

operations manageroperations manager

operations engineeroperations engineer

config. control board mgr.config. control board mgr.

configuration item ownerconfiguration item owner

SUPPORTSUPPORT

identifydefects and

enhance-ments

identifydefects and

enhance-ments

tested applicationdocumentationmodelsrequirement alloc. matrix

allocatedmaintenance

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.

SUPPORT SUPPORT

RESPONDTO

REQUEST

RESPONDTO

REQUEST

support requests

DETERMINESOLUTION

DETERMINESOLUTION

IDENTIFYHW AND SWUPGRADES

IDENTIFYHW AND SWUPGRADES

IDENTIFYTRAINING

PLAN

IDENTIFYTRAINING

PLAN

RECORDSOFTWARE

CHANGEREQUESTS

RECORDSOFTWARE

CHANGEREQUESTS

PROVIDERESOLVE

INFORMATION

PROVIDERESOLVE

INFORMATION

solutionsoftware 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.

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

IDENTIFY DEFECTS AND ENHANCEMENTS IDENTIFY DEFECTS AND ENHANCEMENTS

ANALYSESOFTWARE

CHANGEREQUESTS

ANALYSESOFTWARE

CHANGEREQUESTS

software change requestsmodelsrequirement alloc. matrixdocumentationrelease schedule

PRIORITIZEMAINTENANCE

CHANGES

PRIORITIZEMAINTENANCE

CHANGES

ALLOCATEMAINTENANCECHANGES TOCONF. ITEMS

ALLOCATEMAINTENANCECHANGES TOCONF. 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.

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

product baselineproduct baseline

Software Configuration ManagementSCM 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.

Term Definition

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 baselinedevelopmental baselineallocated baselineallocated baselinefunctional baselinefunctional baseline

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.

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!