Table of Content

1
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

2
Summary
3
Summary of impact of IT distribution on IT
processes
Summary

• 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 users 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.

4
Summary of impact of IT distribution on IT
processes (cont.)
Summary

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

5
Summarized features of the new SW development
processes
Summary

• 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
  RadioMobils location.

6
Summary of changes in SW development processes
Summary

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

7
SW development process overview
8
Principles for different types of the projects
Process Overview

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

9
Process model structure for Initiate and
Construct phases
Process Overview
Models
Model content

• Gather initial requirements
• Cathegorize requirements
• Approve requirements

Tiny development projects
Define requirements and justify
Initiate

• Develop detailed project charter
• Approve projects

Define management documents

• Develop and approveBusiness model
• Develop and approveConceptual model

Model
Program, generalize, test and model - extr.
projekt
Construct

• Develop program code
• Generalize program code
• Perform system test
• Initiate documentation

Program, generalize and test
Small,
Tiny projects
Small,
Big Extreme projects
Big standard projects
10
Process model structure Deliver and Support phases
Process Overview
Models
Model content
Tiny development projects
Program, generalize, test and model - extr.
projekt
Model

• Develop all manuals
• Provide training
• Perform tests
• Release SW

Deliver and test

• Prove SW under real-life conditions
• Manage SW problems during pilot
• Close project

Program, generalize, test and model - extr.
projekt
Pilot
Model
Deliver
Support in pilot

• Evaluate project
• Record lessons learned

Assess

• Manage user problems
• Fix SW defects and user problems

Support
Support
Tiny projects
Standard /
Extreme projects
(Small, Big)
(Small, Big)
11
10 Features of Extreme Projects in Contrast with
Standard Projects
In our approach, the concept of extreme project
is inspired by the Kent Becks 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.
1
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.
2
In extreme project, software is produced earlier,
but there are also generated all other
deliverables as those of standard project.
(manuals, models, metrics, ...)
3
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.
4
If the project is selected to be extreme, this
information must be visible in PD (project
definition) and PC (project charter) documents.
5
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)
6
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.
7
Extreme project has more risk than standard
project. (Because of higher dependency on
development and user experts and technologies,
for example)
8
Extreme project is more expensive than standard
project. (Shorter software development time is
not for free)
9
Extreme project requires better quality
management. Quality administrator needs strong
assistance of programmer and analysis
specialists, because each recognized problem
must be immediately repaired.
10
The success of extreme project is dependent on
well working technical infrastructure (shared
repository, for example).
12
Flow of deliverables
13
Phases Initiate and Construct for standard
projects
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
RFS
Define requirementsand justify
RFS
Project Definition
Approved PD
Initiate
Define management documents
Project Charter
Approved PCH
Model
BusinessModel
Updated PCH
ConceptualModel
Construct
Program, generalizeand test
Updated PCH
ProgramCode
14
Phases Initiate and Construct for tiny projects
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
RFS
Define requirementsand justify
RFS
Small Project Charter
Initiate
Define management documents
UpdatedBusinessModel
Model
Updated ConceptualModel
Construct
Program, generalizeand test
BusinessModel
ProgramCode
Conc.Model
15
Phases Initiate and Construct for extreme
projects
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
RFS
Define requirementsand justify
RFS
Project Definition
Initiate
Approved PD
Program, generalize, test and model
Simple Project Charter
Construct
Updated PCH
BusinessModel
ConceptualModel
ProgramCode
16
Phase Deliver
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
Conc.Model
Deliver and test
ProgramCode
Bus.Model
Updated PCH
User manual
Operationalmanual
Updated PCH
Training manual
Test scripts
Deliver
Test results
Pilot
Pilot results
Updated PCH
Assess
Projectevaluation
17
Phase Support
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
Conc.Model
User problem
User manual
Operationalmanual
ProgramCode
Bus.Model
Support, Support in pilot
User problem
User problem
Support
Trouble report
InternalRFS
18
Process descriptions
19
Define requirements and justify
Process description

• Entrance 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

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

20
Define management documents
Process description

• Entrance 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

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

21
Model
Process description

• Entrance 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

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

22
Program, generalize and test
Process description

• Entrance 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

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

23
Program, generalize, test and model - Extreme
projects
Process description

• 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

• 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.)
24
Program, generalize, test and model - Extreme
projects (cont.)
Process description

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

25
Tiny development projects
Process description

• 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

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

26
Deliver and test
Process description

• Entrance 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

• 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

27
Pilot operation
Process description

• Entrance 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

• 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

28
Support in pilot
Process description

• Entrance 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

• 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

29
Assess
Process description

• 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
• 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

• 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

30
Support
Process description

• Entrance 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

• 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

31
Deliverable description
32
List of deliverables
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

33
Request For Support (RFS)
Deliverables
6. PROJECT IMPACTS 6.1 Dependencies 7. PROJECT
ORGANIZATION Project Sponsor Project Steering
Committee Project Manager User Project Team (user
side) 8. ASSUMPTIONS AND CONSTRAINS 9. ENCLOSURES
Purpose Request For Support is document
containing the definition of user
request. Content 1. COVER SHEET 1.1 General
Information Project name Code name Description C
ategories Project sponsor Project manager
User Project manager IT Start date End date 1.2
Comments 1.3 Document history 1.4 Checked /
approved by 2. CURRENT STATUS DESCRIPTION 3.
PROJECT GOAL 4. PROJECT SCOPE 4.1 Project
scope 4.2 Out of project scope 5. PROJECT
OUTPUT/DELIVERABLES 5.1 Project
Output/deliverables
Legend Italic letters shows new items comparing
to current PM documentation
34
Project Definition (PD)
Deliverables
6.TECHNICAL SOLUTION 6.1 Technical approach 6.2
Reusable artifacts that can be used 6.3 Reusable
artifacts that will be developed 7. PROJECT
IMPACTS 7.1 Dependencies 7.2 Organizational
impacts 7.3 Risks 8. WORK BREAKDOWN, LABOURISNESS
TIME PLAN 8.1 Work breakdown and time plan 8.2
Test plan 8.3 Summary of internal resources 8.4
Metrics plan 8.5 Quality plan 9. BUDGET 9.1
Summary CAPEX ths. Kc OPEX ths. Kc Total
ths. Kc 9.2 Timing 9.3 Major deliveries
(suppliers) 10. ECONOMIC STATEMENT (cost benefit
analysis) 11. PROJECT ORGANIZATION Project
Sponsor Project Steering Committee Project
Manager User Project Manager IT Project
Team Quality Assurance 12. FEASIBILITY STUDY 12.1
Technical feasibility 12.2 Economical feasibility
12.3 Operational feasibility 13. ASSUMPTIONS AND
CONSTRAINS 14. ENCLOSURES
Purpose Project 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. Content 1. COVER
SHEET 1.1 General Information Project name Code
name Description Categories Project
sponsor Project manager User Project manager
IT Start date End date Budget, SAP ID Internal
resource (MD) 1.2 Comments 1.3 Document
history 1.4 Checked / approved by 2. CURRENT
STATUS DESCRIPTION 3. PROJECT GOAL 4. PROJECT
SCOPE 4.1 Project scope 4.2 Out of project
scope 5. PROJECT OUTPUT/DELIVERABLES 5.1 Project
Output/deliverables 5.2 Acceptance criteria
Legend Italic letters shows new items comparing
to current PM documentation
35
Project Charter (PCH)
Deliverables
6.TECHNICAL SOLUTION 6.1 Technical approach 6.2
Reusable artifacts that can be used 6.3 Reusable
artifacts that will be developed 7. PROJECT
IMPACTS 7.1 Dependencies 7.2 Organizational
impacts 7.3 Risks 8. WORK BREAKDOWN, LABOURISNESS
TIME PLAN 8.1 Work breakdown and time plan 8.2
Test plan 8.3 Summary of internal resources 8.4
Metrics plan 8.5 Quality plan 9. BUDGET 9.1
Summary CAPEX ths. Kc OPEX ths. Kc Total
ths. Kc 9.2 Timing 9.3 Major deliveries
(suppliers) 10. ECONOMIC STATEMENT (cost benefit
analysis) 11. PROJECT ORGANIZATION Project
Sponsor Project Steering Committee Project
Manager User Project Manager IT Project
Team Quality Assurance 12. FEASIBILITY STUDY 12.1
Technical feasibility 12.2 Economical feasibility
12.3 Operational feasibility 13. ASSUMPTIONS AND
CONSTRAINS 14. ENCLOSURES 14.1 vendor
contract 14.2 vendor PCH (equal to vendor
accepted proposal)
Purpose Project 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. Content 1.
COVER SHEET 1.1 General Information Project
name Code name Description Categories Project
sponsor Project manager User Project manager
IT Start date End date Budget, SAP ID Internal
resource (MD) 1.2 Comments 1.3 Document
history 1.4 Checked / approved by 2. CURRENT
STATUS DESCRIPTION 3. PROJECT GOAL 4. PROJECT
SCOPE 4.1 Project scope 4.2 Out of project
scope 5. PROJECT OUTPUT/DELIVERABLES 5.1 Project
Output/deliverables 5.2 Acceptance criteria
Legend Italic letters shows new items comparing
to current PM documentation
36
Small Project Charter
Deliverables
6.TECHNICAL SOLUTION 6.1 Technical approach 6.2
Reusable artifacts that can be used 6.3 Reusable
artifacts that will be developed 7. PROJECT
IMPACTS 7.1 Dependencies 7.2 Organizational
impacts 7.3 Risks 8. WORK BREAKDOWN, LABOURISNESS
TIME PLAN 8.1 Work breakdown and time plan 8.2
Test plan 8.3 Summary of internal resources 8.4
Metrics plan 8.5 Quality plan 9. BUDGET 9.1
Summary CAPEX ths. Kc OPEX ths. Kc Total
ths. Kc 9.2 Timing 9.3 Major deliveries
(suppliers) 10. ECONOMIC STATEMENT (cost benefit
analysis) 11. PROJECT ORGANIZATION Project
Sponsor Project Manager IT Project Team Quality
Assurance 12. ASSUMPTIONS AND CONSTRAINS 13.
ENCLOSURES
Purpose Small 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. Content 1. COVER SHEET 1.1 General
Information Project name Code name Description C
ategories Project sponsor Project manager
User Project manager IT Start date End
date Budget, SAP ID Internal resource (MD) 1.2
Comments 1.3 Document history 1.4 Checked /
approved by 2. CURRENT STATUS DESCRIPTION 3.
PROJECT GOAL 4. PROJECT SCOPE 4.1 Project
scope 4.2 Out of project scope 5. PROJECT
OUTPUT/DELIVERABLES 5.1 Project
Output/deliverables 5.2 Acceptance criteria
Legend Italic letters shows new items comparing
to current PM documentation
37
Simple Project Charter
Deliverables
6.TECHNICAL SOLUTION 6.1 Technical approach 6.2
Reusable artifacts that can be used 6.3 Reusable
artifacts that will be developed 7. PROJECT
IMPACTS 7.1 Dependencies 7.2 Organizational
impacts 7.3 Risks 8. WORK BREAKDOWN, LABOURISNESS
TIME PLAN 8.1 Work breakdown and time plan 8.2
Test plan 8.3 Summary of internal resources 8.4
Metrics plan 8.5 Quality plan 9. BUDGET 9.1
Summary CAPEX ths. Kc OPEX ths. Kc Total
ths. Kc 9.2 Timing 9.3 Major deliveries
(suppliers) 10. ECONOMIC STATEMENT (cost benefit
analysis) 11. PROJECT ORGANIZATION Project
Sponsor Project Steering Committee Project
Manager User Project Manager IT Project
Team Quality Assurance 12. FEASIBILITY STUDY 12.1
Technical feasibility 12.2 Economical feasibility
12.3 Operational feasibility 13. ASSUMPTIONS AND
CONSTRAINS 14. ENCLOSURES 14.1 vendor
contract 14.2 vendor PCH (equal to vendor
accepted proposal)
Purpose Simple 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. Content 1. COVER
SHEET 1.1 General Information Project name Code
name Description Categories Project
sponsor Project manager User Project manager
IT Start date End date Budget, SAP ID Internal
resource (MD) 1.2 Comments 1.3 Document
history 1.4 Checked / approved by 2. CURRENT
STATUS DESCRIPTION 3. PROJECT GOAL 4. PROJECT
SCOPE 4.1 Project scope 4.2 Out of project
scope 5. PROJECT OUTPUT/DELIVERABLES 5.1 Project
Output/deliverables 5.2 Acceptance criteria
Legend Italic letters shows new items comparing
to current PM documentation
38
User manual
Deliverables

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

39
Operational manual
Deliverables

• Purpose
• Operational manual is part of system
  documentation. It explains how to administer and
  operate the system.
• Content
• Administration 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

40
Test scripts and Test results
Deliverables

• 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.
• Content
• Test 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
• Purpose
• Results of particular test runs and test cases.
  Documentation of any test discrepancies.
• Content
• Run Management Log
• Log detailing where defects have been found or
  resolved in the application under test.

41
Project evaluation
Deliverables

• 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 teams 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.

42
Pilot Result
Deliverables

• 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

43
Roles descriptions
44
Roles description
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-points
• This 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

• 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

45
Roles description (cont.)
Roles description

• 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

• 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

46
Roles description (cont.)
Roles description

• 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

47
Process models

• Please print from attached file on A3 paper format

48
Define requirements and justify
49
Define management documents
50
Model
51
Program, generalize and test
52
Program, generalize, test and model - extreme
project
53
Tiny Development Projects
54
Deliver Test
55
Pilot Operation
56
Support in Pilot Operation
57
Assess
58
Support