X36SSP X36SSP Správa softwarových Správa softwarových produktů produktů 7. 7. přednáška přednáška Ing. Martin Molhanec Ing. Martin Molhanec ČVUT – FEL ČVUT – FEL K13113 K13113
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!