Page 1 DRAFT Table of Content Summary SW development process overview Flow of deliverables Process...
-
Upload
linette-simpson -
Category
Documents
-
view
216 -
download
0
Transcript of Page 1 DRAFT Table of Content Summary SW development process overview Flow of deliverables Process...
Page 1 DRAFT
Table of Content
• Summary
• SW development process overview
• Flow of deliverables
• Process descriptions
• Deliverable description
• Roles descriptions
• Process models
• Operational processes
• Appendix A: Testing process and approach
• Appendix B: Quality assurance
• Appendix C: Test categories
• Appendix D: Test documentation
• Appendix E: Testing team
• Appendix F: Possible metrics to collect
• Appendix G: Service Level Agreements
• Appendix H: Capability Maturity Model
• Appendix I: Model cards
Page 3 DRAFT
Summary of impact of IT distribution on IT processes• SW Development and Support Processes
– Processes are described in details in process models and narrative part of this document.
• Software Configuration Management
– All project deliverables including intermediary releases must be placed in the central repository to be available everywhere in the distributed environment.
• Infrastructure Development
– Distribution of environment must be supported by a specific infrastructure:» central repository » remote user’s desktop» videoconferencing facilities» scanning facilities» electronic wall board» telephones
– All environments e.g. development, test or operation should be maintained only by IT operations.
• Metrics Management– Current informal and intuitive measurements based on common sense will disappear in distributed environment. Formal
measurement process should be installed.
• Reuse Management– Current informal reuse information sharing spread among people will not work anymore in distributed process environment,
therefore a formal process has to be introduced using the central repository of knowledge.
• Vendor Management
– The process is not affected by distribution, it must remain centralized.
• Risk Management– The risks related to distributed organization should be properly planned, assessed and mitigated.
Summary
Page 4 DRAFT
Summary of impact of IT distribution on IT processes (cont.)• Security Management
– Remote sites usually use to be less loyal an organized as people in headquarters. Distributed organization creates bigger IT security risk that should mitigated e.g., formal security policy and procedures should be in place.
• Quality Assurance– Quality Assurance features for projects are incorporated in new SW development processes and supported by new role of
Quality Assurance people.– Quality Assurance features for IT operations should covered by SLAs (for major applications at least).– New IT Support process has been designed, using the central Help Desk.
• Standards, architectures and tools administration– All tools and standards must stay unified, administrated centrally, while access will be distributed. Architecture should be
developed and maintained by group of architects responsible for particular groups of the system.
• IT operations management/administration– Major functions and services should be controlled by the mean of SLA.
– IT operation function will stay centralized, only operating staff will be distributed among sites.
• People Management and Training
– The people evaluation process will have to be more formalized (based on the Assess process). Nevertheless there will remain the HR soft issues, to be sensitively managed in distributed environment. The training process itself will not be affected by distribution, only the training planning will have to reflect more remote location.
• IT Function Management– Capability Maturity Model (CMM) is a method for continuous improvement of the IT organization.
– Distribution of the organization should be ideally justified with the risks related to each level of CMM. The higher level of CMM, the lower risk resulting from the distributed environment.
• IT functions planning– The process is not affected by distribution, it must remain centralized. Workflow distribution will come due as an additional
element of the planning process.
Summary
Page 5 DRAFT
Summarized features of the new SW development processes
• SW development process was formalized and broken down in several smaller processes
– Break down of processes can support their better distribution
– Follow-up of the procedures will increase quality and stimulate knowledge sharing
• New roles in IT were defined or some existing roles were redefined:
– Problem Manager– to take care about resolution of an assigned problem in SW support
– IT Project Office – to assure project infrastructure in IT
– Analyst Cleaner – to document applications developed in extreme mode
– Document Writer – to create SW manuals
– IT Tester, Test Designer – to perform SW testing
• New roles outside of IT were recommended:
– Project Manager from user side (PM user) – should assure that the process is moving ahead and all required resources from user departments are available at the right time.
– Project Office – First approves, that an effort should be invested to develop detailed project definition (Project Charter). In the second phase approves, that project can start. – Project Office should coordinate also smaller projects, if they concern more departments, have multiple sponsorship or are business critical projects.
– Regular IT vs. other department meeting (IT vs. dpt. Meeting) approves small projects in the same way as the Project Office does for big projects. It releases resources for project specification and project itself.
• Some process deliverables have either new or enhanced structure
• IT should maintain one shared repository that should be used by all teams. This repository should be able to store documents of all eventual types which should be later retrievable at any of RadioMobil’s location.
Summary
Page 6 DRAFT
Summary of changes in SW development processes
• Projects will start only after approval of their detailed definitions (Project Charter). Development of a Project Charter is now considered as a part of the pre-project phase, but as it requires participation of both parties i.e., users and IT personnel, it is also subject of approval (approval of Project Definition). This will improve the project planning and prevent from unmanageable exceeding of project scope. Note: Current Specification of Requirements activity will be split between creation of Project Charter and development of Business model in the modeling phase of the project.
• If project will divert more than by X% in later phases the project will be returned back to the initial phase by the means of the change management procedure an later even be redefined in a new project.
• The Extreme approach was defined for cases when standard approach is not applicable e.g., due to time constrains. This process will bring results sooner however it is still well managed and documented process. Consequently, it costs more resources than the standard approach.
• Separate Modeling process precedes the programming.
• Once programming activities are finished, generalization activities will start. Through the generalization the source code is optimized and cleansed to better support new upgrades and maintenance.
• All processes pay attention to utilization and creation of reusable fragments and also to creation of group memory and knowledge sharing.
• Testing procedures are more formalized. Testing process actually starts with definition of acceptance criteria already in the Project Charter.
• Pilot operation phase, which is to prove SW under live conditions, is a planned activity properly teamed up. Project is closed after pilot is successfully finished.
• All requests or problems are processed through the Help Desk in the Support process. More difficult problems are handed over to the Problem Manager, who is responsible resolution that takes longer time.
Summary
Page 8 DRAFT
Principles for different types of the projects
• There are three types of projects:
– Standard - the recommended approach whenever it is possible.
– Extreme - for cases when standard approach is not applicable e.g., due to time constrains. This process mode will bring results sooner however it is still well managed and documented process. Consequently, it costs more resources than the standard approach. It is assumed, that not all projects will be treated in this way, and those ones, must be properly staffed.
– Tiny development - for very small development activities, when standard project administrative time would significantly exceed the development time. Typically such project should not exceed X mandays. This project does not require formal approvals.
• CIF receives all Requests for Support, consults the expected scope of potential projects with other IT teams and finally classifies projects in respective categories.
• Proceeding a project under Extreme approach is purely an IT internal decision (done by the IT meeting), however the involved risk must be reported. Both parties i.e., users and IT, must be able to release appropriate resources.
• Standard and Extreme projects have also another dimension - they can be either Big or Small (measured by their impact, size and complexity). If CIF classify the project to be a “Big” one, it should imply that a project manager from user side will be nominated.
Process Overview
Page 9 DRAFT
Process model structure for Initiate and Construct phases
ModelsModel content
• Gather initial requirements
• Cathegorize requirements
• Approve requirements
• Develop detailed
project charter
• Approve projects
• Develop and approve
Business model
• Develop and approve
Conceptual model
• Develop program code
• Generalize program code
• Perform system test
• Initiate documentation
Define management documents
Model
Program, generalize and
test
Tiny development
projects
Small,Big standard projects
Small,Big “Extreme” projects
Tiny projects
Init
iate
Co
ns
tru
ct
Define requirements
and justify
Program, generalize, test
and model - extr. projekt
Process Overview
Page 10 DRAFT
Process model structure Deliver and Support phases
ModelsModel content
• Develop all manuals
• Provide training
• Perform tests
• Release SW
• Prove SW under
real-life conditions
• Manage SW problems
during pilot
• Close project
• Evaluate project
• Record “lessons learned”
• Manage user problems
• Fix SW defects and
user problems
Pilot
Support
(Small, Big)
Standard / “Extreme” projects Tiny projects
Support in pilot
ModelProgram, generalize, test and model - extr. projekt
Tiny development projects
ModelProgram, generalize, test and model - extr. projekt
Deliver and test
(Small, Big)
Assess
De
liv
er
Su
pp
ort
Process Overview
Page 11 DRAFT
10 Features of Extreme Projects in Contrast with Standard ProjectsIn our approach, the concept of extreme project is inspired by the Kent Beck’s theory (www.xprogramming.org), but saves the sequential/waterfall development style in major development phases. From this viewpoint, our extreme project concept stays between the standard project concept and “pure” extreme programming style.
Extreme project is not an overloaded standard project, where is no time for deliverables other than code. Extreme project is well driven and follows its process map.
1
In extreme project, software is produced earlier, but there are also generated all other deliverables as those of standard project. (manuals, models, metrics, ...)
2
The privilege and responsibility for selecting the project as extreme or standard has IT and not customer. This decision must be done in initial phase of the project before project itself is started.
3
If the project is selected to be extreme, this information must be visible in PD (project definition) and PC (project charter) documents.
4
In extreme project, the user must be more involved in the development process. The user must be properly trained to be able toassist developers during construct phase. (Or IT must help users with this role)
5
In extreme projects, there are required exceptional skills from development team. Not every developer is suitable for this approach. As the consequence, all projects can not be Extreme.
6
Extreme project has more risk than standard project. (Because of higher dependency on development and user experts and technologies, for example)
7
Extreme project is more expensive than standard project. (Shorter software development time is not for free)8
Extreme project requires better quality management. Quality administrator needs strong assistance of programmer and analysis specialists, because each recognized problem must be immediately repaired.
9
The success of extreme project is dependent on well working technical infrastructure (shared repository, for example).10
Page 13 DRAFT
Phases Initiate and Construct for standard projects
Phase Proj. mgmt. System
Deliverable type
Test Manuals
Define requirementsand justify
Define management documents
Model
Program, generalizeand test
RFSRFS
Project Definition
Approved PD
Project Charter
Approved PCH
BusinessModel
ConceptualModel
ProgramCode
UpdatedPCH
UpdatedPCH
Init
iate
Co
ns
tru
ct
Flow of deliverables
Page 14 DRAFT
Phases Initiate and Construct for tiny projects
Phase Proj. mgmt. System
Deliverable type
Test Manuals
Define requirementsand justify
Define management documents
Model
Program, generalizeand test
RFSRFS
SmallProject Charter
UpdatedBusinessModel
Updated ConceptualModel
ProgramCode
BusinessModel
Conc.Model
Init
iate
Co
ns
tru
ct
Flow of deliverables
Page 15 DRAFT
Phases Initiate and Construct for extreme projects
Phase Proj. mgmt. System
Deliverable type
Test Manuals
Define requirementsand justify
Program, generalize, test and model
RFSRFS
Project Definition
Approved PD
UpdatedPCH
BusinessModel
ConceptualModel
ProgramCode
SimpleProject Charter
Init
iate
Co
ns
tru
ct
Flow of deliverables
Page 16 DRAFT
Phase Deliver
Phase Proj. mgmt. System
Deliverable type
Test Manuals
Deliver and test
Pilot
Assess
UpdatedPCH
Pro
gra
mC
od
e
User manual
Operationalmanual
Testscripts
Trainingmanual
Testresults
UpdatedPCH
Pilotresults
UpdatedPCH
Projectevaluation
Bu
s.M
od
el
Co
nc.
Mo
del
De
liv
er
Flow of deliverables
Page 17 DRAFT
Phase Support
Phase Proj. mgmt. System
Deliverable type
Test Manuals
Support,Support in pilot
User problem
User problem
Trouble report
InternalRFS
Pro
gra
mC
od
e
Bu
s.M
od
el
Co
nc.
Mo
del
User manual
Operationalmanual
User problem
Su
pp
ort
Flow of deliverables
Page 19 DRAFT
Define requirements and justifyEntrance conditions checklist• vision for the project has been defined by user community
• appropriate maintenance changes for previous versions have been identified
To be performed checklist • user requests (RFS) have been documented, validated and prioritized
• technical requirements have been documented and validated
• operation and support requirements have been documented and validated
• reusable artifacts have been identified
• team roles were identified
• implementation alternatives were identified and considered, including decision about Extreme project approach
• economic feasibility of each alternative was determined
• cost/benefit analysis was performed
• risk assessment document has been developed
• alternatives were suggested to senior management (Project office/IT vs. dpt. Meeting) for approval
• senior management (Project office/IT vs. dpt. Meeting) approved or rejected project
• decisions (both made and forgone) were documented into group memory
• metrics have been collected
• in case of Extreme project approach the project Kick-off workshop was organized
Process description
Exit conditions checklist• requirement documents have been validated and accepted by the user
community and senior management (PD was approved)
• initial version of the project plan has been accepted by senior management and by the development team
• initial version of the risk assessment has been accepted by senior management
• feasible implementation alternative has been accepted by senior management
• group memory has been initiated
New process features, process issues• Project manager from user side (PM user) should have the primary
responsibility for requirements specification (creation of Project definition). He should assure, that process is moving ahead.
• For small projects, this role can be substituted by CIF.
• If CIF substitutes PM user in bigger projects, it creates significant risk, that should be evaluated.
• CIF can aggregate more RFS to one, but should ask for confirmation Project office or IT vs. department meeti ng.
• Only projects treated as Extreme projects, will start directly after this phase. All other projects will be in next phase evaluated in bigger detail.
• This process does not concerns urgent SW defect fixing. On the other hand, some impacts of this fixing can result in issuing internal RFS.
• Projects can also be initiated internally by IT. If this affects other RDM departments, a formal approval should be obtained from those departments, before project can start.
• About Extreme project approach must decide IT meeting, based on CIF recommendation.
Page 20 DRAFT
Define management documentsEntrance conditions checklist PD was approved by senior management
user community and IT department are committed to the project
access to key users, technical experts, and financial experts has been obtained
the project objectives have been identified and agreed to (in PD)
initial requirements have been defined (in PD)
development of the risk assessment has begun (in PD)
definition of the project infrastructure has begun (in PD)
development of the project plan has begun (in PD)
the feasibility study has been at least started (in PD)
To be performed checklist business process requirements have been documented and validated technical requirements have been documented and validated reusable artifacts have been identified build-versus-buy decisions have been made application release schedule has been defined or updated project estimate has been developed and accepted metrics plan has been developed and accepted project plan has been developed and accepted assumptions and constraints have been documented test plan has been developed and accepted implementation alternatives were identified and considered economic feasibility of each alternative was determined cost/benefit analysis was performed technical and operational feasibility of each alternative was determined alternatives were suggested to senior management for approval project team has been defined
Process description
skill assessment for each team member has been defined potential subcontractor/ vendors have been contracted project deliverables have been negotiated with senior management and
agreed to risk assessment document has been updated group memory has been organized decisions (both made and forgone) were documented into group memory metrics have been collected
Exit conditions checklist project plan has been accepted by senior management (PCH was
approved)
the scope of the project has been defined and accepted - definition of the functionality that will, and will not, be implemented
risk assessment document has been updated
the team has been accepted by senior management
New process features, process issues• Project Charter is developed and approved during this process, as the full
project description. If project will in later phases divert more than by X%, the change management procedure will return project back to initial phase to be redefined like new project.
• Project Charter is being updated during all phases of the SW development process.
• Significant user community involvement is required and should be assured, as the project has been already approved by senior management in previous phase.
• As project is assessed in bigger detail now, it could even happen, that it will not be finally approved, even if it was approved in previous phase.
Page 21 DRAFT
ModelEntrance conditions checklist project plan has been accepted by senior management (PCH was
approved)
the scope of the project has been defined and accepted (PCH was approved)
the team has been created and accepted
subject matter experts (expert user) have been scheduled
To be performed checklist business and conceptual models were assembled 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
Process description
Exit conditions checklist business and conceptual models have been appropriately documented
and validated
test plan has been updated
business and conceptual models have been accepted by the team and by senior management
New process features, process issues• All requirement are already defined before project starts. Therefore the
purpose the modeling phase is not to specify requirements, but to transform them into business and than conceptual models.
• If requirements and project scope have to be changed anyway by more than X%, project should be redefined (in Initiate phase).
Page 22 DRAFT
Program, generalize and testEntrance conditions checklist appropriate business and conceptual models are available
project plan has been accepted by senior management (PCH)
the team has been created and accepted
To be performed checklist programmers worked with the designers to understand models
models were reviewed and walked through and accepted
(user interface prototypes were reviewed and tested)
source code was written and documented
source code was synchronized with models
code testing was performed (code was inspected)
integration plan was prepared
reusable artifacts have been used
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
test plan was updated appropriately
source code was inspected and improved before being tested
Process description
system testing was performed
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
Exit conditions checklist source code has passed inspection
the source code works
the source code has been optimized
the application has been packaged for the delivery
generalized items have been submitted to the reuse repository
all developers have been made aware of new items
all items have been tested during system test, reviewed and updated accordingly
master test has been updated for “test in the large”
New process features, process issues• The process contains activities related to reuse. Reuse components
should be identified even before generalization.
• The purpose of generalization is to optimize and clean (already functional) source code. Generalized code should be easier to maintain and to release new versions.
• The user and software documentation has been started already in this phase.
Page 23 DRAFT
Program, generalize, test and model - Extreme projects Entrance conditions checklist IT meeting decided about application of Extreme project approach
PD was approved by senior management
user community and IT department are committed to the project
access to key users, technical experts, and financial experts has been obtained
the project objectives have been identified and agreed to (in PD)
initial requirements have been defined (in PD)
development of the risk assessment has begun (in PD)
definition of the project infrastructure has begun (in PD)
development of the project plan has begun (in PD)
the feasibility study has been at least started (in PD)
To be performed checklist programmers worked with the Expert users to develop requirements
(user interface prototypes were reviewed and tested)
source code was written and documented
code testing was performed (code was inspected)
integration plan was prepared
reusable artifacts have been used
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
Process description
reusable items were released into the repository and made accessible to all developers
test plan was updated appropriately
source code was inspected and improved before being tested
system testing was performed
defects were recorded and analyzed
business and conceptual models were assembled (based on source code) and validated
assumptions made during modeling were challenged and documented appropriately
manual processes, legacy applications, and new system development was identified and modeled accordingly
risk assessment document has been updated decisions (both made and forgone) were documented into group
memory metrics have been collected
(cont.)
Page 24 DRAFT
Program, generalize, test and model - Extreme projects (cont.) Exit conditions checklist source code has passed inspection
the source code works
the source code has been optimized
the application has been packaged for the delivery
generalized items have been submitted to the reuse repository
all developers have been made aware of new items
all items have been tested, reviewed and updated accordingly
master test has been updated for “test in the large”
models have been appropriately documented
models have been validated
test plan has been updated
models have been accepted by the team and by senior management
New process features, process issues• This Extreme approach saves time, but is more demanding on resources,
comparing to standard approach. All major activities from standard approach are applied, but some in reverse order or in parallel with slight delay.
• The project is also more demanding for user experts, who must work closely with programmers, to develop requirements in parallel with programming.
• Project starts based on approved PD. At this moment therefore are not requirements and project plan fully defined. Project manager should develop simple variant of Project Charter as his first activity in the process.
• Models and documentation are being developed during programming (with slight delay). Programming is not normally backward influenced by modeling.
Process description
Page 25 DRAFT
Tiny development projects Entrance conditions checklist vision for the project has been defined by user community
To be performed checklist user requests (RFS) have been documented, validated and prioritized technical requirements, operation and support requirements have been
documented and validated reusable artifacts have been identified economic feasibility was determined project estimate has been developed and accepted project plan has been developed and accepted assumptions and constraints have been documented test plan has been developed and accepted technical and operational feasibility was determined project team has been defined risks has been judged and documented “Small Project Charter” has been created programmers worked with the Expert users and analysts to develop requirements source code was written /SW was customized and documented code/customization testing was performed (code was inspected) integration plan was prepared reusable artifacts have been used potential reusable items have been identified 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 test plan was updated appropriately source code was inspected and improved before being tested
Process description
system testing was performed defects were recorded and analyzed business and conceptual models were updated and validated decisions (both made and forgone) were documented into group
memory metrics have been collected
Exit conditions checklist source code/ customization has passed inspection
the source code / customization works
the source code / customization has been optimized and tested
project plan (incl. test plan) has been created
the application has been packaged for the delivery
New process features, process issues• This process is applicable only for very small development projects, or
even just customization projects, where administrative activities would take longer than development work itself.
• No senior management approval is necessary to start the project.
• This process can not be used for projects with vendors evolvement. The only exception is when already proven vendor supplies only manpower and is managed by RDM IT manager.
• About Tiny project approach must decides CIF.
Page 26 DRAFT
Deliver and testEntrance conditions checklist• development activities finished
• the application has been packaged for delivery
• unit tests passed and test results are available
• draft user manual submitted
• the master test/QA plan in available
• team members are trained
To be performed checklist system test kick-off was conducted
• the master test/QA plan was accepted
• test procedures, cases, scripts were developed
• all particular tests were performed
• discrepancies have been recorded and assigned for resolution
• 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
• train the trainer process was started
Process description
Exit conditions checklist the application has passed system testing
• test results were documented
• no serious discrepancies with heavy impact on application are left
New process features, process issues• testing is done in structured manner going through a sequence of
tests each having different purpose
• master test plan and test objectives are developed in early project phases
• testing effort is supported by adequate team
• acceptance test is responsibility of users
Page 27 DRAFT
Pilot operationEntrance conditions checklist all development efforts are finished and all development programs are
fully integrated tested and accepted (formal signed off)
conversion procedures tested, static data prepared
• all programs and customizing settings moved from test environments to the production environment using the configuration management procedure
users trained and confirmed readiness for pilot
senior management and project office informed
IT operation staff properly trained
helpdesk procedures defined and staff properly trained
IT trouble shooting team prepared
pilot support team established
To be performed checklist pilot operation kick-off meeting conducted
provide user support and monitor performance of all developed programs
establish infrastructure to support post implementation development
prepare a SW implementation cutover workplan for all of the development work required to cutover if necessary
• review the Integration Test Scenarios to determine the data loading sequencing, include the check reports into the workplan as well as manual tasks that need to be done between runs
Process description
Exit conditions checklist system satisfies acceptance criteria (contracted)
pilot result submitted to project office, users, helpdesk and supporting team
system acceptance (sign-off) reported to vendor
New process features, process issues• pilot operation is planned activity and properly teamed up
• system in pilot operation is monitored and status is reported what requires extra effort to do and evaluate
Page 28 DRAFT
Support in pilotEntrance conditions checklist pilot operation successfully started
pilot supporting team established
helpdesk procedures defined and staff properly trained
IT trouble shooting team in operation
To be performed checklist all problems are properly described and recorded at helpdesk
problems are either resolved or have problem manager assigned
pending problems are evaluated as having no major impact on system or operation
all trouble reports sent from trouble shooting are either closed or evaluated as having no bad impact
request for support was promptly and politely responded, requester was informed about the escalation and consequencies of the request
Process description
Exit conditions checklist system satisfies acceptance criteria (contracted)
operation runs without serious problem, no stopshow errors are occurring
all problems are either resolved or documented with problem owner assigned
major problems and their resolution generalized
recognized defects and solutions were recorded
New process features, process issues• pilot support is planned activity, support team is properly appointed
• all problems are passed through helpdesk that resolves them directly or escalates them further in the organization
• IT trouble shooting describes any problem solving in the Trouble Report which is submitted for impact assessing before it is closed
Page 29 DRAFT
AssessEntrance 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
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
Process description
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
New process features, process issues• whole concept of assessment is new, should be only used as vehicle
to improve, not to solve HR issues
• process of developing learning history is new
Page 30 DRAFT
SupportEntrance conditions checklist pilot operation successfully started
supporting team established
helpdesk procedures defined and staff properly trained
IT trouble shooting team in operation
To be performed checklist all problems are properly described and recorded at helpdesk
problems are prioritized and either resolved or have problem manager assigned
pending problems are evaluated as having no major impact on system or operation
all trouble reports sent from trouble shooting are either closed or evaluated as having no bad impact
• maintenance changes were allocated and impact of each maintenance change was determined
• each maintenance change was scheduled
• the initiator of each change request 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
Process description
Exit conditions checklist system satisfies acceptance criteria (contracted)
operation runs without serious problem, no stopshow errors are occurring
all problems are either resolved or documented with problem owner assigned
major problems and their resolution generalized
recognized defects and solutions were recorded
New process features, process issues• all problems are passed through helpdesk that resolves them directly
or escalates them further in the organization
• IT trouble shooting describes any problem solving in the Trouble Report which is submitted for impact assessing before it is closed
Page 32 DRAFT
List of deliverables
• Request for Support (RFS)
• Project Definition (PD)
• Project Charter (PC)
• Simple Project Charter (Extreme Project)
• Small Project Charter (Tiny Project)
• Business Model
• Conceptual Model
• User Manual
• Operational Manual
• Training Manual
• Test Scripts
• Test Results
• Pilot Results
• Project Evaluation
• Program Code
Deliverables
Page 33 DRAFT
Request For Support (RFS)
Purpose
Request For Support is document containing the definition of user
request.
Content1. COVER SHEET
1.1 General InformationProject nameCode nameDescriptionCategoriesProject sponsorProject manager UserProject manager ITStart dateEnd date
1.2 Comments1.3 Document history1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION3. PROJECT GOAL4. PROJECT SCOPE
4.1 Project scope4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES5.1 Project Output/deliverables
Deliverables
6. PROJECT IMPACTS6.1 Dependencies
7. PROJECT ORGANIZATIONProject SponsorProject Steering CommitteeProject Manager UserProject Team (user side)
8. ASSUMPTIONS AND CONSTRAINS9. ENCLOSURES
Legend: Italic letters shows new items comparing to current PM documentation
Page 34 DRAFT
Project Definition (PD)
PurposeProject definition is a document containing the definition of user
request and and high level description of the approach, how project can be realized. If potentially exist more implementation alternatives, it is expected, that they will be described separately in sections 6-13. After PD is approved, more detailed definition will start.
Content1. COVER SHEET
1.1 General InformationProject nameCode nameDescriptionCategoriesProject sponsor:Project manager UserProject manager ITStart dateEnd dateBudget, SAP IDInternal resource (MD)
1.2 Comments1.3 Document history1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION3. PROJECT GOAL4. PROJECT SCOPE
4.1 Project scope4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES5.1 Project Output/deliverables5.2 Acceptance criteria
Deliverables
6.TECHNICAL SOLUTION6.1 Technical approach6.2 Reusable artifacts that can be used6.3 Reusable artifacts that will be developed
7. PROJECT IMPACTS7.1 Dependencies7.2 Organizational impacts7.3 Risks
8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN8.1 Work breakdown and time plan8.2 Test plan8.3 Summary of internal resources8.4 Metrics plan8.5 Quality plan
9. BUDGET9.1 Summary
CAPEX: … ths. KčOPEX: … ths. KčTotal: … ths. Kč
9.2 Timing9.3 Major deliveries (suppliers)
10. ECONOMIC STATEMENT (cost benefit analysis)11. PROJECT ORGANIZATION
Project SponsorProject Steering CommitteeProject Manager UserProject Manager ITProject TeamQuality Assurance
12. FEASIBILITY STUDY12.1 Technical feasibility12.2 Economical feasibility 12.3 Operational feasibility
13. ASSUMPTIONS AND CONSTRAINS14. ENCLOSURESLegend: Italic letters shows new items comparing to
current PM documentation
Page 35 DRAFT
Project Charter (PCH)
PurposeProject Charter is the detailed and final project definition, containing all
justified user requests and proposed technical approach. PCH is assembled after approval of PD, when the project has been accepted. It builds on PD but it provides more details and accuracy. Project can start only after PCH is approved (with the exceptions of Extreme project approach and Tiny development projects). PCH follows only the selected implementation alternative.
Content1. COVER SHEET
1.1 General InformationProject nameCode nameDescriptionCategoriesProject sponsor:Project manager UserProject manager ITStart dateEnd dateBudget, SAP IDInternal resource (MD)
1.2 Comments1.3 Document history1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION3. PROJECT GOAL4. PROJECT SCOPE
4.1 Project scope4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES5.1 Project Output/deliverables5.2 Acceptance criteria
Deliverables
6.TECHNICAL SOLUTION6.1 Technical approach6.2 Reusable artifacts that can be used6.3 Reusable artifacts that will be developed
7. PROJECT IMPACTS7.1 Dependencies7.2 Organizational impacts7.3 Risks
8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN8.1 Work breakdown and time plan8.2 Test plan8.3 Summary of internal resources8.4 Metrics plan8.5 Quality plan
9. BUDGET9.1 Summary
CAPEX: … ths. KčOPEX: … ths. KčTotal: … ths. Kč
9.2 Timing9.3 Major deliveries (suppliers)
10. ECONOMIC STATEMENT (cost benefit analysis)11. PROJECT ORGANIZATION
Project SponsorProject Steering CommitteeProject Manager UserProject Manager ITProject TeamQuality Assurance
12. FEASIBILITY STUDY12.1 Technical feasibility12.2 Economical feasibility 12.3 Operational feasibility
13. ASSUMPTIONS AND CONSTRAINS14. ENCLOSURES
14.1 vendor contract14.2 vendor PCH (equal to vendor accepted proposal)Legend: Italic letters shows new items comparing to
current PM documentation
Page 36 DRAFT
Small Project Charter
PurposeSmall Project Charter is the detailed and final project definition,
containing all justified user requests and proposed technical approach for Tiny development projects. Small Project Charter should use simpler forms than PCH.
Content1. COVER SHEET
1.1 General InformationProject nameCode nameDescriptionCategoriesProject sponsor:Project manager UserProject manager ITStart dateEnd dateBudget, SAP IDInternal resource (MD)
1.2 Comments1.3 Document history1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION3. PROJECT GOAL4. PROJECT SCOPE
4.1 Project scope4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES5.1 Project Output/deliverables5.2 Acceptance criteria
Deliverables
6.TECHNICAL SOLUTION6.1 Technical approach6.2 Reusable artifacts that can be used6.3 Reusable artifacts that will be developed
7. PROJECT IMPACTS7.1 Dependencies7.2 Organizational impacts7.3 Risks
8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN8.1 Work breakdown and time plan8.2 Test plan8.3 Summary of internal resources8.4 Metrics plan8.5 Quality plan
9. BUDGET9.1 Summary
CAPEX: … ths. KčOPEX: … ths. KčTotal: … ths. Kč
9.2 Timing9.3 Major deliveries (suppliers)
10. ECONOMIC STATEMENT (cost benefit analysis)11. PROJECT ORGANIZATION
Project SponsorProject Manager ITProject TeamQuality Assurance
12. ASSUMPTIONS AND CONSTRAINS13. ENCLOSURES
Legend: Italic letters shows new items comparing to current PM documentation
Page 37 DRAFT
Simple Project Charter
PurposeSimple Project Charter is the project definition for Extreme project.
Simple PCH is created after project starts and its purpose is to facilitate management and document process of definition of requirements and construct phase and develop deliver project plan. It should assure the quality of the development process even in Extreme approach.
Content1. COVER SHEET
1.1 General InformationProject nameCode nameDescriptionCategoriesProject sponsor:Project manager UserProject manager ITStart dateEnd dateBudget, SAP IDInternal resource (MD)
1.2 Comments1.3 Document history1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION3. PROJECT GOAL4. PROJECT SCOPE
4.1 Project scope4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES5.1 Project Output/deliverables5.2 Acceptance criteria
Deliverables
6.TECHNICAL SOLUTION6.1 Technical approach6.2 Reusable artifacts that can be used6.3 Reusable artifacts that will be developed
7. PROJECT IMPACTS7.1 Dependencies7.2 Organizational impacts7.3 Risks
8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN8.1 Work breakdown and time plan8.2 Test plan8.3 Summary of internal resources8.4 Metrics plan8.5 Quality plan
9. BUDGET9.1 Summary
CAPEX: … ths. KčOPEX: … ths. KčTotal: … ths. Kč
9.2 Timing9.3 Major deliveries (suppliers)
10. ECONOMIC STATEMENT (cost benefit analysis)11. PROJECT ORGANIZATION
Project SponsorProject Steering CommitteeProject Manager UserProject Manager ITProject TeamQuality Assurance
12. FEASIBILITY STUDY12.1 Technical feasibility12.2 Economical feasibility 12.3 Operational feasibility
13. ASSUMPTIONS AND CONSTRAINS14. ENCLOSURES
14.1 vendor contract14.2 vendor PCH (equal to vendor accepted proposal)
Legend: Italic letters shows new items comparing to current PM documentation
Page 38 DRAFT
User manual
Purpose• User manual is part of system documentation. It explains how to use the system.
Content• System background
Reason and purpose of the system, basic properties.• Relations to other systems
Interactions to other systems, main interfaces, transferred data.• Brief descriptions of system functions
Overview of major functions with basic description to get initial understanding• Description of system functions
Description of functions from the user point of view.• Processing of non automated activities
Descriptions of related actions which are not automated by the system. Activities which were automated by previous system but not by this one.
Deliverables
Page 39 DRAFT
Operational manual
Purpose• Operational manual is part of system documentation. It explains how to administer and operate the system.
ContentAdministration part• List of system components.
List of system components like programs, libraries, parameter files etc. including their location.• Installation
Installation of the system, sequence of particular installation activities, verification of installation.• Configuration, static data and parameter set up
System configuration (primary and ongoing), list of static data, meaning static data and their setting, description of static data.• Maintenance of users
User administration.• System security
Description of system security. Used security features.• System maintenance
Description of activities assuring system operation, e.g. archiving, cleansing of work areas.
Operational part• Description of daily operations
Picture of daily operations, description of operators’ activities.• Description of batches
List of system batches and their description.• Error messages
Dictionary of system error messages, reactions, error resolution.• Handling of exceptional statuses
Outline of exceptional statuses handling, e.g. technical disaster, communication line break-down.• Archiving
Outline of data archiving and backup, data backup and restore organization.
Deliverables
Page 40 DRAFT
Test scripts and Test results
Test Scripts
Purpose• Test scripts is the name in common jargon for whole set of test documentation that is used to control test execution, describe individual tests
and the way of executing them. See appendix Test documentation for more details.
ContentTest Plan• Explanation why particular set of tests is being run, when they will run, and what will be required in order to run them.
Test Design• List of test cases each listed explicitly referring to one or more objectives in the test plan so that completeness of coverage can be evaluated
and so that test execution can be prioritized.
Test Procedure Specification• Definition of how a test case will be applied to the system, detailing actions, inputs, expected outputs and Pass / Fail criteria for each test.
Test Results PurposeResults of particular test runs and test cases. Documentation of any test discrepancies.
ContentRun Management Log• Log detailing where defects have been found or resolved in the application under test.
Test Incident Report• Data on the nature of the incident, who is dealing with the problem, and when it is likely to be resolved.
Deliverables
Page 41 DRAFT
Project evaluation
Purpose• Project evaluation is to conduct and document assessment of project mission and objective, project management, project team and return on
investment after the project is finished and to write “Lessons Learned” for future projects.
Content• Project management functions, project plan quality, scope management, deliverable vs. deadline management, budget management.
• Knowledge of project methodology, design methods, development tools, adherence to standards.
• Team organization, clarity of team’s roles and responsibilities, teamwork and personal interactions, communication processes among parties involved in the project.
• Evaluation of project team members — their performance during the project (formal and informal way). These appraisals shoul be used for career planning and development.
• Familiarity with process models and concepts, ability to translate models, policy, procedures to training content.
• Quality of deliverables, testing process, system installation and cut over.
• User training, fit of training with project goals and timelines, initial user satisfaction.
Deliverables
Page 42 DRAFT
Pilot Result
Purpose• Description of pilot operation
Content• matching with acceptance criteria (to be signed off)
• user satisfaction and experience
• observations from IT operations and helpdesk
• overview of errors or problems reported, status of their solution
• overview of system performance and results from system monitoring
• remarks and requests for enhancements
• lessons learned
Deliverables
Page 44 DRAFT
Roles description
Project Manager User (PM User)• have the primary/ overall responsibility for the project• his major role on the beginning is requirements specification and project
definition (creation of Project definition and Project Charter). Later in project assures that project follows project plan, decides about project phases closing and solves problems.
• assures, that Project is moving ahead• In technical issue relies on PM IT
Project Manager IT (PM IT)• manage IT side of the project• hands over project deliverables for Quality assurance
Quality Assurance (QA)• assess deliverables quality in QA check-pointsThis role is not explicitly described in process maps, as QA always acts on the
request of PM IT at the end of each process phase and also inside of processes, if defined.
Ordering User• clearly formulates user or business requirements in the form of RFS• contributes to Project definition
CIF• gather RFSs, plays role of interface between users and IT. For small projects can substitute PM User role. If CIF substitutes PM user in bigger projects, it creates significant risk, that
should be evaluated.
IT Meeting• represents decision maker role for IT dept. global issues.• decides about Extreme project approach.
IT vs. Dept. Meeting• regular meeting between IT and other departments• approves smaller projects (PD, PCH)• receives project status info
Project office• approves bigger projects (PD, PCH)• receives project status info
IT Architekt• responsible for consistency of all IT architecture components.
IT Project office• creates IT project infrastructure to support PM IT
• maintains group memory•gathers metrics•gather and provide reuse etc.
• formally checks completeness of project phases
Senior Management• approves bigger projects (PD, PCH) • receives project status info• is not contacted directly but through Project Office or IT vs. Dept. Meeting
Business Analyst• transforms user requirement into business model• requires strong communication and modeling skills, partly knowledge of user
business
User Expert• subject matter expert from user side, represents user requirements.• knows user business
Roles description
Page 45 DRAFT
Roles description (cont.)
Environment Specialist• assist to all other functions with technical advice and expertise on
architectural components
Programmer• develop program code according to the design• maintain and keep the system repository up to date• execute unit test
Technical Documentation Processor• gather supporting documentation and develop system documentation
Userguide Writer• gather supporting documentation and develop user manual
SAP Superuser• responsible for assigned module• during a SW customization project plays the role of PM User, and
coordinates even IT personnel from SAP team.• control module development - gather and sort out all requests, sign off all
changes• responsible for application access and security control, grant access to
other users• control user training, couch the train the trainers approach
Analyst• do analysis on given subject, creates conceptual model• document the results
IT Operations• responsible for the operation e.g., running of the system HW, network and
software• operation, tuning and maintenance of the systems processing units.
IT Tester• execute integration and system tests and performance tests• record test results• prepare run management log detailing the test results
Test Designer• create test designs and test cases according to the testing process• work with the business users to confirm test objectives and acceptance
criteria
User Tester• execute system integration and user acceptance tests and regression tests,
prepare testing scripts• record test results
End User Support (Help Desk)• receive user requests, document them, refine description• resolve simple problems• escalate difficult problems
User Trainer• deliver training to users• update training material
User• responsible for applications and their proper use• own the applications and are responsible for the data• clearly specify requirements that should be communicated through CIF only• visit user training
Roles description
Page 46 DRAFT
Roles description (cont.)
IT Support Team• assist the users in the new process operations• monitor process performance e.g. systems operations, preparation of input
forms, processing of transactions, generation of system reports and provision of user support
• resolve process problems as the occur • stabilize process operations and fine-tune all procedures to address
identified problems
IT Trouble Shooting• be on disposal for resolution of difficult problems• resolve problem, document properly all activities done• cooperate during the impact assessing and problem closing
Administrator• administration of the systems assets including current hardware and
software inventories.
Problem Manager• lead all activities related to problem resolution• contact other specialists and experts to cooperate on problem resolution
Roles description
Page 48 DRAFT
Define requirements and justify
IT Project Office
Ordering User
receiverequirem
ents
subm itrequ irem ent
com pleterequirem
ents
PM User
receiverequirem
ents
rece ivedrequ irem ents
coord inateevaluation andpropose team
roles
fin ish andpresent PD
w ait fo r decis ion
com pletePD
receivedecis ion
aboutpro ject
CIF
recordrequirem
ents
rece ivedrequ irem ents
consultreguirem ents
pass overrequest
and startPD
w ait fo r decis ion
receivedecis ion
aboutpro ject
Project Office
receivePD
has P D
consult PD
re jectpro ject
IT vs. Dpt Meeting
Analyst &Programmer &Expert User &EnvironmentSpecialist& ITArchitect
assessfeasib ility
afte r feasib ilityassessm ent
am endPD
request for support
am endPD
necessaryPD
PD
PD
if necessary
draft PD
big pro ject
if necessary
PD
PD
if needed
receivedecis ion
aboutpro ject
if necessary
gatherm etrics
com pleteand present
PD
sm allpro ject
approvepro ject
receive PD
has P D
consultPD
re jectpro ject
approvepro ject
providereuse in fo
receivedecis ion
aboutpro ject
assem blePD
before P Dbefore P Dassess
feasib ilityassess
feasib ility
organizek ick -off
workshop
extrem e pro ject
IT meeting
judgedevelopm ent
through extrem eprojectin case of conflic t
(tim e, resources)
PM IT
be in form edabout h is /her
team nom ination
w ait fo rdecis ion
receive decis ionabout pro ject
rece ivedrequ irem ents
com pletePD
sm all pro jectb ig pro ject
approved PD
com pletePD
PD
nom inatePM IT
if ne
cess
ary
Page 49 DRAFT
Define management documents
PM Vendor
specify technica lso lution
specifiedtechn ica l so lu tion
propose vendorProject C harter
c lose contract
PM IT
PM User / CIF
has approvedP D
re finerequirem ents -develop P ro ject
C harter
obta inedtechn ica lpro jectspecifica tion
re fineresources
Project Office
receiveProjectC harter
has P ro jectC harter
IT vs. Departmentmeeting
receiveProjectC harter
has P ro jectC harter
Analyst &Programmer &Expert User &EnvironmentSpecialist
re finetechnica lso lution
specifiedtechn ica lso lu tion
re fineresources
IT Architect
re fine technica lso lution
w ait fo r p ro jectdecis ion
receivepro ject
decis ion
SeniorManagement
receivepro jectstatusreports
Vendor PC
fina lized P C H
hand over PC H forapproval
w ait fo r p ro jectdecis ion
receiveapprovem ent
receivedeny
receiverequest
foram endm
ent
consultPC H
approve
deny
requiream endm
ent
big pro ject
approverequire
am endment
deny
sm all pro ject
w ait fo rpro jectdecis ion
receive pro jectdecis ion
consultPC H
IT Project Office
organizeworkshop,
c lose"IN IT IAT E"phase and
open pro ject
co llectm etrics
Project Charter
PCH
PCH
m etrics
Ordering User
adjust teamand specify
requirem ents
refineresources
re finedrequ irem ents
w ait fo r p ro jectdecis ion
receive pro jectdecis ion
refine technica lrequirem ents
re finedtechn ica lrequ irem ents
re fine resources,assis t w ith PC H
receive pro jectdecis ion
w ait fo rpro jectdecis ion
closevendor
contractapproved PCH
if necessary
before c losingcontract
Page 50 DRAFT
ModelExpert User
consultbusinessm odelling
fin ishedbusiness m ode lconsu lta tions
partic ipate inbusiness
m odelworkshop
PM User / CIF
startm odelling
w ait fo rm odeling fin ish
receivebusiness
m odel andpartic ipate in
workshop
receiveconceptual
m odel
PM - IT
appoint businessm odel team
w ait fo rbusiness m ode l
receive businessm odel and reuse
inform ation
has businessm odels
conduct businessm odel workshop
afte rbusinessm odelw orkshop
requestfor
businessm odel
revis ion
appointconceptualm odelling
team
Business Analyst /Vendor
develop businessm odel and provide
reuse in fo
fin ishedbusiness m ode l
presentbusiness
m odel
EnvironmentSpecialist &Programmer & ITArchitect
consult bus inessm odel
fin ishedbusiness m ode lconsu lta tions
partic ipate inbusiness m odel
workshop
afte r businessm odelw orkshop
consultconceptual
m odel
fin ishedconceptua lm odelconsu lta tions
partic ipate inconceptual
m odelworkshop
afte r businessm odel isfin ished
afte r businessm odelw orkshop
IT Project Office
develop conc.m odel and
provide reuseinfo
fin ishedconceptua lm odel
presentconceptual
m odel
gather m etrics
consultconceptual
m odel
fin ishedconceptua lm odelconsu lta tions
partic ipate inconceptual
m odelworkshop
w ait fo rconceptua lm odel
receiveconceptual
m odel and reuseinfo
has conceptua lm odels
conduct conceptualm odel workshop
afte rconcept.m odelw orkshop
requestconceptual
m odelrevis ion
TechnicalDocument W riter
gatherunderlying
m ateria l andupdatem odels
receive reuseinfo
provide reuseinfo
businessm odel
m odelapproved
m odel notapproved
m odelapproved
m odel notapproved
con
cep
tual
mo
del
acceptvendorproduct
PM Vendor
receiveacceptance
Page 51 DRAFT
Program, generalize and test
PM Vendor
receiveacceptance
SeniorManagement
receiveproject s tatus
info
PM User / CIF
w ait fo r phaseend
receiveproject s tatus
info
Programmer /Vendor
program
fin ishedprogram m ing
test code
EnvironmentSpecialist& ITArchitect
consultprogram m ing
fin ishedprogram m ingconsu lta tion
consult codetest
Analyst/Vendor
consultprogram m ing
fin ishedprogram m ingconsu lta tion
consult codetest
afte r code test a fte r code testa fte r code test
IT Project Office
generalize code
fin ished codegenera liza tion
partic ipate ingeneralized
code test
co llectm etrics
consult codegeneralization
fin ished codegenera liza tion
partic ipate ingeneralized
code test
consult codegeneralization
fin ished codegenera liza tion
partic ipate ingeneralized
code test
w aits fo rfin ished code
accept code,conduct
workshop andclose
C O N ST R U C Tphase
Project Office / ITvs. Dept. Meeting
receiveproject s tatus
info
Userguide W riter /Vendor
TechnicalDocument W riter /Vendor
gathersupporting
m ateria l
gathersupporting
m ateria l andupdatem odels
receivereuse
IT Tester /Vendor
IT Operation
prepare testenvironm ent
preparetest
report testresults
in system test
test
updatem odels
fin ishedgenera lizedcode test
fin ishedgenera lizedcode test
fin ishedgenera lizedcode test
acceptvendorproduct
code
partic ipate insystem test
partic ipate insystem test
partic ipate insystem test
PM - IT
appointprogram m ing
team
w ait fo rprogram m ing
receive code
has code
check code testresults
afte r codetest
re turncode forrework
startgeneralizati
on
w ait fo rgenera lized code
receivegeneralized
code
has genera lizedcode
check genera lizedcode test resu lts
afte rgenera lizedcode test
requestrepair o f
generalized code
hand overcode and
in itia tesyst. test
code O K
w ait fo r systemtest resu lts
check system testresults
afte r system test
handovercode
requestrepair o f
generalized code
code after systemtest
code O K
generalized code
generalized code
Page 52 DRAFT
Program, generalize, test and model - extreme project
SeniorManagement
receiveproject s tatus
inform ation
PM User/ CIF
w ait fo r phaseend
receiverequirem ents
receiveproject s tatus
info
PM - IT
appointprogram m ing
team
w ait fo r p rogramcode
rece ive codeand requirem ents
step by step
has code
check code testresults
afte r codetest
requestcoderepair
in itia tegeneralizat
ion
Programmer/Vendor
program
fin ishedprogram m ing
test code
EnvironmentSpecialist & ITArchitect
consultprogram ing
fin ishedprogram ingconsu lta tion
consult codetest
code
afte r code testa fte r code test
IT Project Office
generalize code
fin ished codegenera liza tion
testgeneralized
code
collect m etrics
consult codegeneralization
fin ishedgenera liza tionconsu lta tion
partic ipate ingener. code
test
w ait fo rgenera lizedcode
receivegeneralized code
has genera lizedcode
check genera lizedcode test resuls
afte rgenera lizedcode test
requestrepair o fgeneralized code
w ait fo r fin ishedcode
accept code,conduct
workshop andclose
"construct"phase
hand overcode and
in itia tesyst. test
Project Office / ITvs. Dept. Meeting
receiveproject s tatus
inform ation
Userguide W riter/Vendor
TechnicalDocument W riter /Vendor
gathersupporting
m ateria l
gather supportingm ateria l and
update m odels
receivereuse
IT Tester/Vendor
IT Operation
prepare testenvironm ent
preparetest
report testresult
in system test
test
fin ishedgenera lizedcode test
fin ishedgenera lizedcode test
Analyst-Cleanser /Vendor
Expert Userconsultpro ject
prepare form odel
c leansing
"c leanse" a fte rprogram m ing
developbusiness
m odel
developconceptual
m odel
fin ishedrequ irem entsspecifica tion
receive pro jectstatus in form ation
and accepts results
create S im pleProject C harter
partic ipate insystem test partic ipate in
system test
w ait fo r system testresu lts
check system testresults
afte r system test
handovercode
codeO K
requestrepair o f
generalized code
acceptvendorproduct
code after systemtest
PM Vendor
receiveacceptance
gen
eral
ized
cod
e
Page 53 DRAFT
Tiny Development Projects
PM - IT
in itia teprogram m ing/custom ization
Programmer
EnvironmentSpecialist & ITArchitect & ExpertUser
Analyst
IT Project Office
program /custom ize
fin ishedprogram m ing/custom ization
partic ipate intest
co llect m etrics
consultprogram m ing/custom ization
fin ishedconsu lta tion
partic ipate intest
consultprogram m ing/custom ization
fin ishedconsu lta tion
partic ipate intest
w ait fo r code /custom ization
rece ive code/custom ization
has code /custom ization
checkcode/custom ization
test
afte r code/custom izationtest
requestcode
custom izationrepair
w ait fo r fin ishedcode
accept code/C ustom ization
and c lose"C O N ST R U C T "
phase
handover
code/custom .
andin itia tesystem
test
IT vs. Dept.Meeting
rece ivepro ject s ta tus
inform ation
TechnicalDocument W riter
gathersupporting
m ateria l andupdatem odels
take overreuse
IT Tester
IT Operation
prepare testenvironm ent
preparesystem
test
report testresu lts
during systemtest
test
updatem odels
fina lized test fina lized test fina lized test
Ordering User(SAP Superuser)
send requirem ents
send requ irem ents
com pleterequirem ents
CIF
recordrequirem ents
rece ivedrequ irem ents
consultrequirem ents
Code
if necessary
tiny project
create Sm all P ro jectC harter and hand
over to developm ent
sm all projectcharter
w ait fo rsyst. testresu lts
check syst.test results
afte r syst. test
hand overcode/
custom ization
requestcode/
custom ization repair
partic ipatein system
test
partic ipatein system
test
partic ipatein system
test
code
assessfeasib ility
w ait fo rpro ject sta rt
assessfeasib ility
assessfeasib ility
w ait fo rpro ject sta rt
w a it fo rpro ject sta rt
Page 54 DRAFT
Deliver & Test
PM Vendor
receiveacceptance
IT Operation
PM User / CIF PM IT Technical DocumentW riter /Vendor
partic ipate in thestart m eeting
after start m eeting
take over draftoperational
m anual
before test p lan
partic ipate in testp lan developm ent
before testing
coord inate andexecute tests
w ait fo r test resu lts
receive andinterpret test
results
hand over draftoperational
m anual
subm itted dra ftvers ion
subm it fina loperational
m anual
update m anual
operationalm anual
organize andconduct test s tart
m eeting
after test startm eeting
take over draftuser m anual
before test p lan
in itia tedevelopm ent o f
test p lan
before testing
start and contro ltesting
w ait fo r test resu lts
re turn pro jectback to
C O N ST R U C Tphase
Userguide W riter/ Vendor
subm it draft userm anual
dra ft user m anualsubm itted
subm it fina l userm anual
update userm anual
use
r m
anu
al
test plan
test plan
test scripts
CIF / Vendor / OrderingUser
prepare tra in ingof the testing
team
in tra in ing
reports end oftra in ing of testing
team
tra in testing team
m anage tra in ingof the testing
team
trai
nin
g m
ater
ial
Test Designer/Vendor
IT Project Office
subm it testscrip ts
test scripts (IT Tester / Vendor) &User Tester
test
test
scr
ipts
receive m anualsand tra in ing
m ateria l
use
r m
anu
alo
per
atio
nal
man
ual
trai
nin
g m
ater
ial
SoftwareC onfigurationM anagem ent
receive ongoingtest resu lts
preparere lease
contro lresolution of
d iscrepanciesin test discrepancies in test
a ll right
seriousdiscrepancies
before c losing testw orkshop
conduct c los ingtest workshop
official releaseversion
user m aual operationalm anual
Senior Management
be inform ed aboutpro ject c los ing
before user tra in ing
tra ins the tra iners
user m anual
prepare operationsupport (he lpdesks, ...)
report test results
in terpret testresults
Administrator
transfer applicationto productionenvironm ent
require sw itchof test
environm ents
receive ongoingtest resu lts
update testscrip ts
acceptvendorproduct
transfer applicationto other testenvironm ent
Programmer &Analyst &EnvironmentSpecialist &IT Architect &Expert User
in terpret testresults
test results
test results
Page 55 DRAFT
Pilot OperationUser Trainers/Vendor
confirm user readinessfor p ilo t
IT vs. Dept. Meeting/Project Office
receive in fo about p ilo toperation start
Senior Management
receive in fo about p ilo toperation results
PM User PM IT User End User Support (HelpDesk)
Support Team/Vendor
w ait fo r read iness
organize k ick -offm eeting of p ilo t
operation
receivereadiness in fo
ready fo r p ilo topera tion
partic ipate ink ick -off m eetingof p ilo t operation
confirmreadiness
ready fo r p ilo topera tion
receive p ilo toperation k ick -off
in fo
confirmreadiness
ready fo r p ilo topera tion
partic ipate ink ick -off m eetingof p ilo t operation
confirmreadiness
ready fo r p ilo topera tion
partic ipate ink ick -off m eetingof p ilo t operation
confirmreadiness
in p ilo t opera tion
m onitor p ilo toperation
resolve prob lem s
consult prob lem s
in p ilo t opera tion in p ilo t opera tion
pilot supportunder
progress
in p ilo t opera tionpilot
supportunder
progress
in p ilo t opera tion
pilot supportunder progress
report p ilo toperation
results
receiveinform ation about
p ilo t operationresults
has in form ationabout p ilo topera tion resu lts
report p ilo toperation
results
confirm ssuccessfu ll
p ilo t
recom m endproject
cancelation
recom m endreturn to
C O N ST R U C Tphase
fin ish p ilo t andpro ject
cancel pro ject
re turn pro jectto
C O N ST R U C Tphase
receive in fo about p ilo toperation results
receive in form ationabout p ilo t operation
results
decide aboutp ilo t extension
pilotsupportunder
progress
PM Vendor
receiveacceptance
Page 56 DRAFT
Support in Pilot OperationUser / Expert User(Supervisor)
report problem
afte r prob lem report
re fine problemdescription
subm itproblem
resolutionreport
be in form edon progressof problemresolution
w ait fo r p rob lemreso lu tion
cooperate onproblem
resolution
receive in form ationabout the way of
problem resolution
End User Support (HelpDesk)
receive problem report
rece ived prob lemreport
re fineproblem
description
subm itproblem
resolutionreport
requireproblem
resolutionon IT
resolveproblemwith own
power
doesn't need anyresolution cannot be
resolved
can be resolved w ithow n pow er
w ait fo r p rob lemreso lu tion
liase w ith user
receive in form ationabout the way of
problem resolution
IT Project Officeoffer in form ation
abou s im ilarproblem s
PM IT
receiveproblem
description
rece ived prob lemdescrip tion
decide on theway of problem
resolution
announcethe way ofproblem
resolution
in ita teC O N ST R U C T
process
coord inateproblem
resolution
standard w ay ofresolution
can beresolvedquick ly
notnecessaryto resolveim m ediate ly
Expert User (Supervisor)
consult the way ofproblem resolution
IT Trouble Shooting /Vendor
consult the way ofproblem resolution
resolve anddocum ent problem
Senior Management
be inform ed about seriousproblem that needs to be
resolved
if necessary
problemdescription
if necessary
problemdescription
if necessary
acute
hastroub lereport
report aboutresolution
w ithout anyconsequences
report aboutresolution and
in itia teC O N ST R U C T
process
IT architect & IT Operations
assess im pact o f repairon whole IS
if necessary
reportedaboutreso lu tion
generalizeproblem and its
resolution
collect m etrics andfiles resolution
Trouble Report
Administrator
resolve problem
pass overthe
problem forresolutio
depends on scope
PM User
decide onprolongation of the
pilo t operationphase
problem doesn't deal w ithapplication
Page 57 DRAFT
AssessPM ITTechnical
Document W riter
subm it currentvers ion of
m anual
Userguide W riter
subm it currentvers ion of
m anual
CIF
in form abouttra in ing s tatus
PM User
receive a ll ex is tingpro ject outputs
beforeassessm entw orkshop
conductassessm ent
workshop
afte rassessm entw orkshop
in formabout
pro ject
Project Office / ITvs. Dept. meeting
receiveinform ation
about pro ject
operational m anual
use
r m
anu
al
tra
inin
g s
tatu
sre
po
rt
IT Project Office
evaluatem etrics
m etrics evaluation
Analyst &Programmer &Expert User &EnvironmentSpecialist
partic ipate inassessm ent
workshop
IT Meeting
update SWdevelopm ent
process
collectm etrics
subm it a ll pro jectoutputs
beforeassessm entw orkshop
partic ipate inassessm ent
workshop
afte rassessm entw orkshop
in formabout
pro ject
m etrics evaluation
update groupm em ory
PM Vendor
obta infeedback
Page 58 DRAFT
SupportUser / Expert User
report problem
afte r prob lem report
re fine problemdescription
receiveproblem
resolutionreport
be in form edon problemresolution
w ait fo r p rob lemreso lu tion
cooperate onproblem
resolution
receive in fo about theway of problem
resolution
End User Support (HelpDesk)
receive prob lem report
rece ived prob lemreport
re fineproblem
description
subm itproblem
resolutionreport
requireproblem
resolutionon IT
resolveproblemwith own
power
no resolutionneeded
cannot beresolved
can be resolved w ithow n pow er
w ait fo r p rob lemreso lu tion
liase w ith user
receive in fo about theway of problem
resolution
IT Project Officeoffer in form ation
about s im ilarproblem s
Problem Manager
receiveproblem
description
rece ived prob lemdescrip tion
decide on theway of problem
resolution
announcethe way ofproblem
resolution
in itia te"IN IT IAT E"
process,create in ternal
R FS
coord inateproblem
resolution
standard w ay ofresolution
can beresolvedquick ly
not necessary toresolve im m ediate ly
Expert User (Supervisor)
consult the way ofproblem reolution
IT Trouble Shooting
consult the way ofproblem resolution
resolve anddocum ent problem
Senior Management
be inform ed about seriousproblem that needs
resolution
if necessary
problemdescription
if necessary
problemdescription
if necessary
acute
hastroub lereport
in form aboutresolution
w ithout anyother
consequencesreport about
resolution andin itia te
C O N ST R U C Tprocess
IT Architect & Administrator& IT Operations
assess im pact o f repairon the whole IS
if necessary
reportedreso lu tion
generalizeproblem and its
resolution
collect m etrics andfile reso lution
trouble report
Administrator
resolve prob lem
pass overthe
problem forresolution
depends on scope
problem doesn't deal w ithapplication