development process framework - madasafish

DevelopmentProcessFramework

Editor: Richard Veryard

For: SCIPIO Consortium

Status: Beta Version

Version: 0.91

Filename: SCIPIOdpf.pdf

SCIPIO

SCIPIO Development Process Framework Version 0.91

Copyright ©1998 Richard Veryard 17 April, 1998 Page ii

Contents

INTRODUCTION 1

GENERAL 2

PERFORMANCE ASSESSMENT 5

ANALYSIS 7

DESIGN 9

DELIVERY 11

PROJECT SCENARIOS 13

DETAILED TASK STRUCTURE 18


Copyright ©1998 Richard Veryard 17 April, 1998 Page 1

Introduction

This guide describes the tasks of SCIPIO, and indicates their interdependencies. It is intended forthree groups of reader:

Ø SCIPIO practitioners, wishing to understandhow the concepts and techniques can beapplied on projects of various kinds.

Ø The guide offers several scenarios, to showhow SCIPIO may be applied to a range ofbusiness, application and technologicalprojects.

Ø The guide shows the purpose of each task interms of its contribution to parallel orsubsequent tasks.

Ø The guide shows the concepts and techniquesapplicable for each task.

Ø Project managers, needing a basicunderstanding of the task structure of SCIPIOin order to plan and manage a SCIPIO project

Ø The guide provides a detailed task structure,which may be used to derive the content ofproject plans and schedules for a SCIPIOproject.

Ø People in various support roles, who need toknow what SCIPIO practitioners are likely tobe engaged in at different stages of a project inorder to provide adequate support. Thissupport may include skills training, softwaretools, development infrastructure and otherresources.

Ø The guide indicates the knowledge, skills andresources needed at each stage of a SCIPIOproject.

Assumptions

This guide does not provide advice about the project planning process itself. We assume that projectplanning and management will conform to DSDM. If you want to use an alternative method, youmust make the appropriate adjustments yourself.

Acknowledgements

Valuable contributions to this document have been made by other members of the SCIPIOConsortium, especially Clive Mabey and Michael Mills.

Sources

SCIPIO draws upon several sources including ISO 9126 (Software Quality), ISO 10746 (ODPReference Model), the Unified Modelling Language (UML) and DSDM.



General

Overall Structure

Solution Delivery

PerformanceAssessment

Analysis

DeliveringAchievement

Design

Solution Management

ProjectManagement

PeopleManagement

RiskManagement

QualityManagement

Figure 1: Overall Structure of SCIPIO

Interworking of old and new techniques

Delivery

Legacy Wrapping/Interfacing

Component Acquisition

Package Selection

Ass

embl

eWorkflow Development

Infrastructure Development

Build

Components

Applications

ApplicationRestructuring

Keyrepresents Scipio with OO Modellingrepresents existing methodsrepresents methods under development

Analysis

As-Is

BusinessProcessAnalysis

ApplicationSystemsAnalysis

TechnologyInfrastructure

Analysis

ApplicationSystemsAnalysis

SolutionDesign

To-Be

PerformanceAssessment

Benchmark

BusinessAssessment

TechnologyAssessment

ApplicationAssessment

ApplicationSystemsDesign

BusinessProcessDesign

TechnologyInfrastructure

Design

ApplicationSystemsDesign

Figure 2: Solution Development Structure

A key feature of the method is that there is some communication or exchange of information betweenmany of the activities. At this high level, no sequence can be inferred, and the diagram should not beread simply from left to right. Note, for example, that the assessment is iterative: some of theperformance assessment subtasks can only be done after the relevant portions of the analysis andsolution design have been done.



Working in Parallel

The essence of solution provisioning lies in the design of the solution and the planning of transitionfrom the existing situation (As-Is). To illustrate how this might work we take a close look at Analysisand Solution Design. Although there is no single route through the method, one has been chosen forpurposes of illustration. This presupposes that a business process is to be improved.

TOBE

4. DETAIL

5. SOURCECOMPONENT

5. DETAIL

Business Process

Activities

TasksApplications

Components

3. REDESIGN

5. REUSE

Invariant

1. IDENTIFY

2. GENERALIZE

5. DETAIL (Selectively)

ASIS

Figure 3: Detail: Analysis and Design Process

In rough terms, the steps are as follows. (A more formal task structure will be presented in afollowing chapter.)

1. Individual activities are understood through a process of investigation and communication withthose who undertake the activity.

2. When sufficient information is available the individual activities are synthesized into a holistic andtechnology independent view of the business process.

3. Changes to the process are designed bearing in mind available technology and assumed possibilitiesfor reuse. The new process design is recorded in a technology free manner.

4. The process is mapped to the underlying components by a process of decomposition into sub-processes, tasks, manual procedures and software components.

5. As the refinement of the new process proceeds validation is sought for assumptions about reuse oflegacy systems. Candidates for reuse are selectively investigated in sufficient detail to establishwhat role they might play. As candidates are confirmed the design is adjusted to accommodatethem. As this is going on component libraries both external and internal are also investigated.

The modelling and design work does not go strictly top-down, from broad structures to detailedspecifications, nor strictly bottom-up, from detailed specifications to broad (‘strategic’) summaries,but middle-out. This can be seen from Figure 3. This means that each task or subtask may beexecuted at several levels in parallel.



Singular and Plural Tasks

Some tasks refer to a single object being analyzed or designed. For example Analyze Organization, orMap Current Application. In a real project, it may be necessary to carry out these tasks several times.There may be several separate organizations to be analyzed, or several current applications to bemapped. Wherever possible, such tasks are defined in the singular, so that they can be separatelyscheduled for each object. Metrics for such tasks are defined for a single object, and should bemultiplied by the number of objects for which this task is required.

Project Management Concerns

Many methods call for iteration of tasks. A given design technique may be executed at one stage ofthe project to produce a ‘first cut’ deliverable, and then may be re-executed at a later stage of theproject to produce a ‘final’ deliverable.

We regard the control of such iteration as a project management concern. For this reason, we do notexplicitly specify iteration and related matters within the solution development task lists. Instead, weleave them to be ‘plugged in’ as part of the project management approach. In other words, the taskiterations are to be generated when the project plan is created, based on the preferred projectmanagement approach.

In general, we recommend a RAD approach to iteration. The DSDM consortium, which hasdeveloped some industry-wide recommendations on RAD, suggests that, to control iteration, eachimportant design technique be iterated three times. However, some situations or organizations mayprefer to plug in an alternative approach.

Furthermore, the actual project management tasks, such as project planning, are assumed to be partof the project management plug-in, and are not contained within the Solution Provisioning task lists.

Quality Management Concerns

Similarly, the quality management tasks, such as quality planning, training, reviews and audits, arenot contained in the Solution Provisioning task lists but are plugged in as part of the preferred QualityManagement approach. The SCIPIO consortium is able to advise on a standard Quality Process,based on ISO 9000, TickIT and the SEI Capability Maturity Model, but SCIPIO is open to alternativequality management approaches being plugged in.

Production and Maintenance

We do not include Production (i.e. routine operation of the improved business process, applicationand/or infrastructure) within the scope of SCIPIO. However, Production typically spawns a numberof minor improvement opportunities. These may either be managed as mini-projects or assembledinto an ongoing maintenance program.



Performance Assessment

Overview

Performance Assessment (sometimes referred to as System Assessment) considers the characteristicsof the system from several viewpoints, including:

• Business process performance (including cycle time, cost and quality of service);

• Application characteristics (typically the quality characteristics identified by ISO 9126:functionality, maintainability, usability, reliability, efficiency and portability);

• Technological infrastructure characteristics (including value-for money, technical performanceand flexibility).

There are six types of performance assessment, which may be considered at different stages of theproject. These are:

Evaluation: An estimation or measurement of past orpresent performance.

Prediction: An estimation or declaration of futureperformance.

1. Current performance of system. This istypically what triggers the improvementproject.

2. Target performance (or objective setting) ofsystem.

3. Benchmark performance of system.Benchmarks may be internal or external.

4. Simulated performance of current system.This is an optional step; it provides aconfirmation of our analysis, by showing thatour model of the existing system is consistentwith the observed performance and isexplained by it.

6. Actual performance of redesigned system.This is an evaluation of the success of theproject, and may result in furtherimprovement projects.

5. Simulated performance of redesigned system.This provides a prediction of the businessbenefits of a proposed solution, and anidentification of any associated risks. Thisprovides a confirmation that the solution islikely to work.

Thus many of the assessment subtasks can only be carried out after some analysis, design and/ordelivery subtasks have been carried out.



Task Structure

Process Assessment Application Assessment Infrastructure Assessment

Evaluating the performance of anexisting business process, and/orpredicting the performance of aproposed business process.

Evaluating the performance of anexisting application, and/orpredicting the performance andother characteristics of aproposed application.

Evaluating the performance andother characteristics of anexisting technologicalinfrastructure, and/or predictingthe performance and othercharacteristics of a proposedtechnological infrastructure.

Ø Identify Business ProcessObjectives

Ø Review Performance ofCurrent Business Processagainst Objectives

Ø Establish Business ProcessBenchmark

Ø Set Targets for BusinessProcess Improvement

Ø Explain ProcessPerformance

Ø Estimate Performance ofSolution (simulation)

Ø Review Performance ofSolution (post-implementation evaluation)

Ø Identify ApplicationObjectives

Ø Review Current Applicationagainst Objectives

Ø Establish ApplicationBenchmark

Ø Set Targets for ApplicationImprovement

Ø Explain ApplicationCharacteristics

Ø Estimate Characteristics ofSolution (simulation)

Ø Review Characteristics ofSolution (post-implementation evaluation)

Ø Identify InfrastructureObjectives

Ø Review CurrentInfrastructure againstObjectives

Ø Review Technology Trends

Ø Establish InfrastructureBenchmark

Ø Set Targets forInfrastructure Improvement

Ø Explain InfrastructureCharacteristics

Ø Estimate Characteristics ofSolution (simulation)

Ø Review Characteristics ofSolution (post-implementation evaluation)



Analysis

Overview

The purpose of Analysis (sometimes known as Diagnosis) is to understand the structure of whatalready exists, and to identify the causes of any problems or restrictions. A series of models of thecurrent situation is produced, showing how various people, roles, departments, companies andsystems interact. These models (known as As-Is models) serve several purposes:

• They provide an explanation of the current level of performance, both in absolute terms and incomparison with benchmarks. They allow the immediate symptoms of performance problems tobe traced to their underlying causes.

• They provide a basis for the design of an improved business process, and provide a basis for thepossible restructuring and redeployment of parts of the current system to support the redesignedbusiness process.

Task Structure

Process Analysis ApplicationAnalysis

ComponentExploration

InfrastructureAnalysis

Ø AnalyzeOrganization

Ø Analyze Tasks,Collaborations andInterfaces

Ø DocumentWorkflow Pathsand Mechanisms

Ø Document BusinessRule Structure

Ø Document BusinessResponsibilities

Ø Document Process

Ø Map CurrentApplication

Ø DocumentApplicationComponents

Ø DocumentApplicationInterfaces andProtocols

Ø DocumentApplicationResponsibilities

Ø Map Process toApplication

Ø Formulate SearchCriteria

Ø Create Shortlist ofAvailableComponents

Ø ObtainSpecification ofComponent

Ø IdentifyTechnologyRequirements andConstraints

Ø Map Infrastructure

Ø DocumentInfrastructureComponents

Ø DocumentInfrastructureInterfaces andProtocols

Ø Map Application toInfrastructure



Process Analysis

This task develops a series of models to describe the existing process. By preference, SCIPIO uses anextension of the UML notation for OO modelling. However, if process models have been producedusing previous methods and notations, this work can often be reused.

Application Analysis

This task develops a series of models to describe the structure and functionality of existingapplications. By preference, SCIPIO uses an extension of the UML notation for OO modelling.However, if application models have been produced using previous methods and notations (includingdata models and data flow diagrams), this work can often be reused.

Analysis of legacy systems, although essential for reuse and transition purposes, is often difficult andtedious, especially when documentation is out-of-date, unreliable or completely lacking. SCIPIOtherefore undertakes careful planning of legacy systems analysis activity, and ensures that details areproduced on a just-as-required basis.

Infrastructure Analysis

This task develops a series of models to describe the existing technology infrastructure. Bypreference, SCIPIO uses an extension of the UML notation for OO modelling. However, iftechnology models have been produced using previous methods and notations, this work can often bereused.

Component Exploration

This task finds and analyses existing application packages and components for potential use. It yields adescription of the functionality and other characteristics of a package or component, defined in termsof its vocabulary and behaviour.

It uses a requirements specification as input, which may be based on a preliminary design. Thisspecification need not be complete: indeed, it is normal to carry out a preliminary search for availablepackages or components with a rough and partial specification.

Components may be found in existing in-house component libraries, or via the World Wide Web.



Design

Overview

Solution Design includes the definition of the solution as well as its planning and sourcing. Theimproved (To-Be) business process is represented in the same way as the current (As-Is) businessprocess: as a set of interactions between people, roles, departments, companies and systems.

• The interactions may be improved and made more effective.

• Wholly new components may be introduced into the system. These may be businesscomponents, application components or technological components.

• Existing components may be adapted to fit the improved system context in which they are tooperate. Opportunities are identified to make the existing components and their interfaces moregeneric, to enhance future adaptability.

• The business rules are reformed and mapped onto the components. Each component is assignedthe responsibility for maintaining one or more rules.

• A holistic picture of the solution is produced.

• An implementation plan is developed, indicating the selected source for each new or modifiedcomponent.

Task Structure

Process Design Application Design Infrastructure Design

Ø Determine OptimizationStrategy

Ø Business RuleRationalization

Ø Business ResponsibilityAssignment

Ø Workflow Structure Design

Ø Workflow MechanismSelection

Ø Solution Verification

Ø Release Planning

Ø Information Sourcing

Ø Component Identification

Ø Component Protocol Design

Ø Component ResponsibilityAssignment

Ø Data Storage Design

Ø Component Specification

Ø Component Sourcing

Ø Envision Solution

Ø Develop UpgradedTechnical Architecture

Ø Determine Re-useOpportunities

Ø Allocate Components toPlatforms



Process Design

This task uses an extension of UML for specifying the future process.

Application Design

This task uses an extension of UML for specifying the future application as a set of collaboratingcomponents. It yields a description of the solution as a combination of new application componentsand existing portions of the legacy system (which may require some wrapping or modification towork properly as components).

We can also link to traditional techniques, especially during the transition from previous tools andskills. For example, we can use entity-relationship modelling and process decomposition to specifythe functional requirements of the future application. We can also use dialog flow diagramming andwindow design to specify the user interface and implementation of the future application. Such linksto traditional techniques also allow for continuity and reuse of existing design work.

Infrastructure Design

This task uses an extension of UML for specifying the future technology infrastructure as a set ofcollaborating components.



Delivery

Overview

Delivery divides into Component Acquisition, Component Development, Assembling andCommissioning. The provisioning of the new components may follow a variety of paths,including:

• Existing components may be wrapped, repackaged or restructured.

• Modifications to existing components may be hand-crafted. Alternatively, if a suitable componentalready exists elsewhere, it may be cheaper and easier to replace the old component with animproved version satisfying the requirements.

• New components may be bought ‘off-the-shelf’ from a component library. Or a component withsimilar description may be bought and customized.

• Finally, and only where necessary, new components may be commissioned from componentbuilders, either in-house or external.

These considerations apply to the provisioning not only of software application components but alsoof other pieces of the solution, including business process components (such as user guides andstationery) and infrastructure components (such as hardware and system software).

The development and maintenance of components will normally follow a prototyping approach.Furthermore, whole business solutions may be assembled and piloted before roll-out to theremainder of the target organization - this can be regarded as a business-level equivalent of aprototyping approach.

Note: the planning of development and implementation is regarded as part of project management.



Task Structure

Task Description Subtasks

Component Acquisition Obtain application andtechnology components fromexternal sources. Includescomponents supplied bycustomer.

Ø Negotiate Ownership

Ø Take Delivery

Ø Verify AcquiredComponent

Acquired ComponentImplementation

This task includes themodification and installationof components, packages andtemplates from externalsources (including customer).

Ø Modify ComponentDesign

Ø Set ComponentParameters

New ComponentConstruction

This task includes theconstruction of newcomponents.

Ø Build Component

Ø Unit-Test Component

Transition ComponentConstruction

This task consists of wrappingand/or modifying legacy codeto produce applicationcomponents that offer therequired interface/service.The legacy code usually (butnot necessarily) remains onthe original platform.

Ø Wrap Legacy code

Ø Modify Legacy code

Component Publication Make component (and/or theservices it provides) availableto a defined user community.

Ø Define Terms ofAvailability

Ø Publish ComponentSpecification

Ø Establish ComponentDelivery Mechanism

Solution Testing Verifies that the solutionsatisfies the requirements,executes satisfactorily on theinstalled technologicalplatform, and provides theexpected support for thebusiness process.

Ø Define Test Plan

Ø Establish TestEnvironment

Ø Install Test Data Storage

Ø Execute Test Plan

Solution Deployment Installs all new technologycomponents. Configurestechnology infrastructure.Installs all applicationcomponents on theappropriate technologycomponents. Installs processcomponents. Go live.

Ø Install Components

Ø Configure System

Ø Install Live Data Storage

Ø Commission System



Project Scenarios

SCIPIO covers a broad range of project scenarios from application assembly to BPR. In this chapter,we identify four main solution-oriented scenarios, each with some variations.

• Business Process Improvement

• Reengineering

• Object Development from Scratch

• Middleware

SCIPIO identifies three different flavors of improvement, at each of the three levels (business process,application and technology). This is based on the wisdom that it usually makes sense (at all threelevels) to simplify before integrating (“Don’t pave the cow paths!”), and to integrate beforetransforming. The four scenarios cover all nine variations, as shown in Figure 4.

BusinessProcess

Simplification

Using IT to eliminateredundant steps in a businessprocess, or to reduce excessivevariety.

Integration

Using workflow managementtools and new softwarecomponents to link businessprocesses together moreeffectively.

Transformation

Radical BPR

Scenario: Business Process Improvement

Applica-tion

Simplification

Using CBD in a tightly focusedway to eliminate specificproblems in legacy systems.

Integration

Using middleware to linkinformation systems togethermore effectively.

Transformation

Building new InformationSystem solutions usingcommercially availablecomponents.

Scenario: Reengineering Scenario: Object Development from Scratch

Infra-structure

Simplification

Replacing unnecessarycomplications or variations inthe technological infrastucture.

Integration

Linking heterogeneoustechnologies together moreeffectively.

Transformation

Satisfying new technicalrequirements, or exploitingnew technologicalopportunities.

Scenario: Middleware Scenario: Object Development from Scratch

Figure 4: Four Project Scenarios, covering nine kinds of improvement



Scenario: Business Process Improvement

Process Simplification

OR

Process Integration

OR

ProcessTransformation

SCIPIO Tasks

Start with an existingbusiness process, whoseperformance is problematicin some way - tooexpensive, too slow, tooerror-prone.

Start with a series ofpoorly coordinatedbusiness activities.

-----------------------→ Process Assessment

OR -----------------------→ Start with an entirelynew process concept.

Determine OptimizationStrategy

Model the as-is process, toidentify which specificsubprocesses andcomponents are causing theproblems.

Model the currentmechanisms (if any) thatlink these activities.

Process Analysis

• Analyse Organization

• Analyse Tasks,Collaborations andInterfaces

• Document Workflow Pathsand Mechanisms

• Document Business RuleStructure

• Document BusinessResponsibilities

Produce an abstract modelto show what is essentialabout the process.

Create an overallbusiness process thatbrings all these activitiestogether.

Process Analysis

• Document Process

OR -----------------------→ Analyse the newconcepts to identify itskey components (at thebusiness level).

Process Design

• Business ResponsibilityAssignment

Prune the process to cut outwhatever is causing theproblems, and replace withsimpler, more robustcomponents.

Design an improvedmechanism for linkingthese activities. Thismay typically involveworkflow managementsoftware.

Process Design

• Determine OptimizationStrategy

• Business RuleRationalization

• Business ResponsibilityAssignment

• Workflow Structure Design

• Workflow MechanismSelection



Process Simplification

OR

Process Integration

OR

ProcessTransformation

SCIPIO Tasks

Application Design(first cut)

• Information Sourcing

• Component Identification

• Component ProtocolDesign

• Component ResponsibilityAssignment

• Component Specification

• Component Sourcing

Analyse the existingsystems to discoverhow many of therequired componentsalready exist.




• Document ApplicationComponents

Application Design(second cut)

Estimate the performance ofthe redesigned process.

Estimate theperformance of theredesigned process.

Estimate theperformance of the newprocess.

Process Assessment

• Estimate performance ofsolution (simulation)

Application Assessment

• Estimate characteristics ofsolution (simulation)

Application Design(third cut)

Implement the newcomponents one by one, toyield a simpler, more robustprocess with the desiredperformance.

Modify existingcomponents and/oracquire new componentsto work within theimproved mechanism.

Reconfigure the businessprocess.

Acquire newcomponents asrequired.

Install newcomponents.

Implement newbusiness process.

Process Design

• Release Planning

Application Design

• Component Sourcing

Delivery



Scenario: Reengineering

Application Simplification Application Integration SCIPIO Tasks

Start with an existing application that isproblematic in some way - fails to satisfyimportant business requirements, too expensiveor too slow to maintain, too error-prone.

Start with a series of poorly coordinatedcomputer systems. There may be high levels ofdata duplication, complex data conversions, orother inefficiencies.


Model the as-is application, to identify whichspecific subprocesses and components arecausing the problems.

Identify the current mechanisms (if any) thatlink these systems. (The current mechanismswill often be manual - in the worst case, theymay involve rekeying data from one computersystem into another computer system.)


Prune the application to cut out whatever iscausing the problems, and replace with simpler,more robust components.

Design an overall application architecture thatbrings all these systems together. Designimproved mechanisms for linking these systems.This may typically involve open distributedcomputing.

Application Design

Implement the new components one by one, toyield a simpler, more robust application withthe desired characteristics.

Modify existing components and/or acquirenew components to work with the chosenmechanism. Reconfigure the applications.

Delivery

Scenario: Middleware

Infrastructure Simplification Infrastructure Integration SCIPIO Tasks

Start with an existing infrastructure that isproblematic in some way - fails to satisfyimportant business requirements, tooexpensive or too slow to maintain, tooerror-prone.

Start with a series of poorly coordinatedplatforms and protocols.

Infrastructure Assessment

Model the as-is infrastructure, to identifywhich specific platforms and protocols arecausing most of the problems.

Identify the current mechanisms (if any)that link these platforms and protocols.

Infrastructure Analysis

Rationalize the infrastructure to phase outwhatever is causing the problems, andreplace with simpler, more robusttechnologies.

Design an overall technical architecturethat brings all these systems together.


• Envision Solution

• Develop Upgraded TechnicalArchitecture

• Determine re-useopportunities

Implement the new components one byone, to yield a simpler, more robustinfrastructure with the desiredcharacteristics.

Introduce new middleware to implementthe technical architecture. Modify existingcomponents and/or acquire newcomponents to work with the chosenmechanism. Reconfigure theinfrastructure.


• Develop Upgraded TechnicalArchitecture

• Determine re-useopportunities

Delivery



Scenario: Object Development from scratch

Application Transformation Infrastructure Transformation SCIPIO Tasks

Start with an entirely new applicationrequirement.

----------------------------------------→ Process Design

• DetermineOptimization Strategy

OR Start with an entirely new technologicalrequirement or opportunity.


• Envision Solution

Analyse the new requirement to identify itskey components.

Analyse the new requirement oropportunity to identify its keycomponents.

Process Design

Analyse the existing systems to discover howmany of these components already exist.

Analyse the existing systems to discoverhow many of these components alreadyexist (probably externally).


• ComponentIdentification

Acquire new components as required. Acquire new components as required. Application Design

• Information Sourcing

• ComponentIdentification

• Component ProtocolDesign

• ComponentResponsibilityAssignment

• ComponentSpecification

Install new components. Install new components. Delivery

Implement new application. Implement new infrastructure. Delivery



Detailed Task Structure

Major Task Task Description Purpose / Motivation Key Decisions / Issues Dependency /Assumption / Resource

Subtasks Outputs/Outcome /Deliverables

ProcessAssessment

Identify Business ProcessObjectives

Identify all the businessobjectives for theprocess.

To provide acomprehensive basis forassessment.

Include

• constraints (whatcannot be changed)

• opportunities (whatmay be changed)

• goals (what must bechanged).

Input from processowner

Assumes that the scopeof the business processhas been (at leastprovisionally) defined.

Describe BusinessProcess Objective

Determine BusinessProcess Metric

For each objective:

description

how it is measured

Review Performance ofCurrent Business Processagainst Objectives

Measure or estimateperformance of processseparately against eachobjective.

Documentmanagement attitude toany identified processweaknesses.

To identify the prioritiesfor improvement.

Consider the strengths ofthe current businessprocess, as well as itsweaknesses.

Does the processperform consistently, orare there peaks andtroughs of performance?

Which of the identifiedweaknesses are mostcritical to the business?Which must beaddressed most urgently?

Business ProcessObjectives

Performance Data ifavailable. Otherwisedirect observation of thebusiness process formeasurement.

Assemble AvailablePerformance Data

Conduct PerformanceMeasurements

Determine CurrentPerformance Level

Determine CurrentPerformance Variations

Assess PerformanceAdequacy

Assess Priority of Action

For each objective:

• current levelachieved (with anyimportant variations)

• judgment ofadequacy

• judgment of priority





Establish Business ProcessBenchmark

Identify external orinternal best-in-class forthis process. Measuretheir achievementsagainst our objectives.

To stimulateimprovement effort.

To identify realisticproject targets.

And to identify specificpractices that can beconsidered for adoption.

Are the resultsobtainable frompublished figures, orfrom a benchmarkingclub, or do they have tobe estimated? Howreliable is the estimate?

How much do we know(or can find out) abouthow they actuallyachieve these results?

How fair is thecomparison with thebenchmark?


Define BenchmarkStrategy and Scope

Identify BenchmarkTargets

Establish ExternalContacts

Define BenchmarkChecklist

Obtain BenchmarkInformation

Obtain CollateralInformation

Identify Issues andOpportunities

Analyze BenchmarkResults

For each benchmark andobjective:


• any significantdifferences betweentheir situation and ours

• objectives

• priorities

• constraints

Set Targets for BusinessProcess Improvement

Define goals for theproject in terms of thebusiness processobjectives.

Required for projectmanagement.

Consider what has beenachieved elsewhere,when setting targets.


Current Business ProcessPerformance

Business ProcessBenchmarks

Determine AchievablePerformance Level

Estimate Costs andBenefits of PerformanceImprovement

Determine Cost-Effective PerformanceLevel

Set ImprovementTimescale

For each objective:

• how muchimprovement?

• by when?





Explain processperformance.

When the businessprocess has beenmodelled, check thatthe AS IS model isconsistent with andexplains the currentperformance.

Validates the analysis. Is all process cycle timeaccounted for?

Is all the resourceexpenditure accountedfor?

Can the actual quality ofservice be explained interms of the AS ISmodel?

AS IS models(from Analysis)

Establish SimulationApproach (manual /automated)

Develop SimulationModel

Execute SimulationModel

Analyze SimulationResults

The simulation of the ASIS model should yieldresults consistent withthe actual processperformance.

This task may result inchanges to the AS ISmodel.

Estimate performance ofsolution (simulation)

When the process hasbeen redesigned,estimate itsperformance against thebusiness processobjectives.

In complex or high-riskprojects, simulationtools may be used.

Validates the solutionbefore you start buildingit.

Is the new process goingto work?

What is it likely toachieve against thebusiness processobjectives?

Will the improvementtargets be met?

TO BE models(from Design)





The simulation of theTO BE model shouldyield results consistentwith the project targets.

This task may result inchanges to the TO BEmodel, and/or to theproject targets.

Review performance ofsolution (post-implementationevaluation)

When the redesignedprocess has beenimplemented, measurethe actual performanceachieved against each ofthe business processobjectives.

Evaluates the success ofthe project.

Identifies lessons andopportunities for futureprojects.

Is the new processworking?

Have improvementtargets been met?

Project targets

Actual measurements ofthe improved businessprocess.

Check solutionbehaviour

Measure solutionperformance

Compare solutionperformance withimprovement targets

Identify outstandingactions and opportunities

This task may result in afurther improvementcycle, and/or to changesin the solutiondevelopment processitself.






Identify ApplicationObjectives

Identify all theobjectives for theapplication.

Consider what thebusiness or technologymay require fromapplications in future aswell as the currentrequirements


Include




Consider all aspects ofapplication quality andperformance, including:functionality, usability,maintainability,efficiency, reliability andportability.

In some projects, theobjectives may bederived from thebusiness processobjectives. On otherprojects, they will begiven as part of the termsof reference.

Assumes that the scopeof the application hasbeen (at leastprovisionally) defined.

Describe ApplicationObjective

Determine ApplicationQuality Metric

For each objective:

• description

• how it is measured

Review CurrentApplication againstObjectives

Measure or estimatequality of theapplication separatelyagainst each objective.


Consider the strengths ofthe current application,as well as its weaknesses.

Does the applicationperform consistently, orare there peaks andtroughs of performance?


Application Objectives

Performance Data ifavailable. Otherwisedirect measurement ofthe application.

Assemble AvailableQuality Data

Conduct QualityMeasurements

Determine CurrentQuality Level

Determine CurrentQuality Variations

Assess ApplicationAdequacy


For each objective:

current level achieved(with any importantvariations)

judgment of adequacy

judgment of priority





Establish ApplicationBenchmark

Identify any equivalentapplication (eitherelsewhere in thecompany or outside),with which the qualityof this application canbe compared. Measuretheir achievementsagainst our objectives.







Application Objectives Define BenchmarkStrategy and Scope









current level achieved(with any importantvariations)

any significantdifferences betweentheir situation and ours

• objectives

• priorities

• constraints

Set Targets forApplication Improvement

Define goals for theproject in terms of theapplication objectives.



Relate applicationimprovement targets tobusiness processimprovement targets.

Application Objectives

Business ProcessImprovement Targete

Application BenchmarkResults

Determine AchievableQuality Level

Estimate Costs andBenefits of QualityImprovement

Determine Cost-Effective Quality Level


For each objective:

how muchimprovement?

by when?





Explain ApplicationCharacteristics

When the applicationhas been modelled,check that the model isconsistent with andexplains the currentquality of service.

Validates the analysis Are all the response timeand processing delaysaccounted for?


Can the actual quality ofservice be explained interms of the model?

AS IS models(from Analysis)






Estimate characteristics ofsolution (simulation)

When the applicationhas been redesigned,estimate its behaviouragainst the applicationobjectives.



Is the new applicationgoing to work?

What is it likely toachieve against theapplication objectives?


TO BE models(from Design)





This task may result inchanges to the TO BEmodel.

Review characteristics ofsolution (post-implementationevaluation)

When the redesignedapplication has beenimplemented, measurethe actual behaviourachieved against each ofthe applicationobjectives.



Is the new applicationworking?


Project targets

Actual measurements ofthe improvedapplication.

Check solutionbehaviour









InfrastructureAssessment

Identify InfrastructureObjectives

Identify all theobjectives for theinfrastructure.

Consider what thebusiness or applicationsmay require fromtechnology in future aswell as the currentrequirements


Include




Consider all aspects ofsystem quality, includingfunctionality, usability,maintainability,efficiency, reliability andportability.

In some projects, theseobjectives may bederived from thebusiness process orapplication objectives.On other projects, theywill be given as part ofthe terms of reference.

Describe InfrastructureObjective

DetermineInfrastructure QualityMetric

For each objective:

description

how it is measured

Review CurrentInfrastructure againstObjectives

Measure or estimatequality of theinfrastructure separatelyagainst each objective.


Consider the strengths ofthe currentinfrastructure, as well asits weaknesses.

Does the technologyperform consistently, orare there peaks andtroughs of performance?


Infrastructure Objectives Assemble AvailableQuality Data

Conduct QualityMeasurements

Determine CurrentQuality Level

Determine CurrentQuality Variations

Assess InfrastructureAdequacy


For each objective:


• judgment ofadequacy

• judgment of priority

Review TechnologyTrends

Consider the likelyfuture capabilities of thetechnologies currentlybeing used.

To identify futureopportunities and threats

Are these expectedcapabilities likely to beavailable within atimeframe to satisfyfuture requirements?

Infrastructure Objectives





Establish InfrastructureBenchmark

Identify any equivalentinfrastructure (eitherelsewhere in thecompany or outside),with which the qualityof this infrastructure canbe compared. Measuretheir achievementsagainst our objectives.







Infrastructure Objectives Define BenchmarkStrategy and Scope










• any significantdifferences betweentheir situation and ours

• objectives

• priorities

• constraints

Set Targets forInfrastructureImprovement

Define goals for theproject in terms of theinfrastructureobjectives.



Relate infrastructureimprovement targets tobusiness process andapplicationimprovement targets.

Infrastructure Objectives

InfrastructureBenchmark Results

Determine AchievableQuality Level

Estimate Costs andBenefits of QualityImprovement

Determine Cost-Effective Quality Level


For each objective:

• how muchimprovement?

• by when?





Explain InfrastructureCharacteristics

When the infrastructurehas been modelled,check that the model isconsistent with andexplains the currentquality of service.

Validates the analysis Are all the response timeand processing delaysaccounted for?


Can the actual quality ofservice be explained interms of the model?

AS IS model Establish SimulationApproach (manual /automated)





Estimate characteristics ofsolution (simulation)

When the infrastructurehas been redesigned,estimate its behaviouragainst the applicationquality objectives.



Is the new infrastructuregoing to work?

What is it likely toachieve against theinfrastructure objectives?


TO BE model Establish SimulationApproach (manual /automated)




This task may result inchanges to the TO BEmodel.

Review characteristics ofsolution (post-implementationevaluation)

When the redesignedinfrastructure has beenimplemented, measurethe actual behaviourachieved against each ofthe infrastructureobjectives.



Is the new infrastructureworking?


Delivered Solution Check solutionbehaviour









ProcessAnalysis

Analyze Organization Understand the actualstructure of theorganization.

Identifies the internalstakeholders in thecurrent process, andtheir responsibilities andrelationships.

This will be importantfor planning anychanges.

Do roles correspond topersons or departments?

Who controls whom?What are theorganizational patterns:

• management byobjectives

• self-managing teams

Scope (provisionally)defined

Identify people andgroups

Identify roles

Identity organizationalrelationships

Organizational StructureDiagram

RAEW matrix

Analyze Tasks,Collaborations andInterfaces

Understand theactivities of theorganization.

Since the currentmechanisms forcommunication betweenactivity steps are likely tochange, we need amodel of the process thatis independent ofmechanisms andsequence.

For each activity,identify the collaboratingactors:

• human actor

• external relationship

• internal relationship

• upstream activity

• downstream activity

• technology support foractivity

Scope (provisionally)defined

Decompose Process intoSub-Processes

Decompose Sub-Processes into Activities

Detail Collaborations

Analyze interfacesbetween organizationunits

Analyze interfacesbetween tasks

Analyze user interfaces

Collaboration orExchange Diagram





Document WorkflowPaths and Mechanisms

Analyze how theseparate activity stepsare joined together tomake a completeprocess.

Process control tasksshould be included, aswell as processexecution tasks.

Performance problemsin a process (whether todo with speed orreliability) can often betraced to weakcommunication betweenactivity steps, rather thanto weak performance ofa given step.

How are messagespassed between steps ofthe process?

Where are the queues inthe process? How arethey managed?

How is a given workitem allocated to one ofmany interchangeableservers or caseworkers?

How is the progress andcompletion of workcontrolled?

Identify exchanges

Decompose exchangesinto separate flows

Document flowmechanisms andprotocols

Activity Diagram(Process Flow)

Document Business RuleStructure

Identify the businessrules actuallyimplemented by thecurrent work andprocedures.

Allows business rules tobe explicitly revalidatedand rationalized beforebeing re-implemented inthe new solution.

What are the implicitobjectives andconstraints of each taskor component?

What is supposed tohappen for each logicalcombination ofconditions?

Identify explicit andimplied rules for eachrole.

Identify explicit andimplied rules for eachcomponent.

Consolidate rules intorule diagram.

Rule Diagram

Document BusinessResponsibilities

Identify where theresponsibility lies forguaranteeing each rule

Identifies overlaps andgaps in the currentimplementation of thebusiness rules

Helps the analyst toensure continuity ofrule-governed behaviourduring the transition tothe new solution.

How is each ruleenforced?

Rule Diagram

Organizational StructureDiagram

Matrix mappingbetween Rule Diagramand OrganizationalStructure Diagram





Document Process Understand the actualoverall structure of theprocess.

Provides a high-levelsummary of the process,which should bemeaningful to businessmanagement.

This task may be startedat any time, but cannotbe completed until theother tasks in this sectionare complete.

Activity Diagram

ApplicationAnalysis

Map Current Application Identify subsystems ofthe current application,to be documented ascomponents.

Provides starting pointfor planningimprovements to theapplication

How reliable is systemdocumentation?

Does systemdocumentation identifymeaningful clusters oflegacy application?

Can more meaningfulclusters be identifiedafter some detailedanalysis?

Collaboration Diagram:Application Map

Document ApplicationComponents

Describe thefunctionality andperformance of eachidentifiable subsystemof the currentapplication systems

Helps determine whichcomponents can beredeployed in the new orimproved application,and which componentsneed to be altered orreplaced.

Abstract collaborationsto single actions.

Abstract groups to singleobjects.

Specify abstract actionswith postconditions.

Class Diagrams

Document ApplicationInterfaces and Protocols

Identify how theapplication componentstalk to each other atruntime.

Helps fix the interfacesbetween thecomponents that aregoing to remain and thecomponents that aregoing to be replaced.

Are there performanceor quality of serviceassumptions /constraints on theinterfaces?

Sequence Diagram





Document ApplicationResponsibilities

Identify which businessrules are currentlyencapsulated insoftware

Identifies overlaps andgaps in the currentimplementation of thebusiness rules.

Helps the analyst toensure continuity ofrule-governed behaviourduring the transition tothe new solution.

Rule Diagram

Application Map

Matrix mappingbetween Rule Diagramand Application Map

Map Process toApplication

Understand therelationship betweenthe actual structure ofthe process and theactual structure of thecurrent applications.

Helps to justify changesto the application interms of improvementsto the business process.

Process Flow Diagram

Application Map

Matrix mappingbetween Process FlowDiagram and ApplicationMap

ComponentExploration

Formulate Search Criteria Define theprocurementrequirements.

Understand what we'relooking for.

Search Criteria

Create Shortlist ofAvailable Components

Determine the names,sources and costs ofcomponents that matchthe search criteria.

Limit the search tocomponents that mightbe relevant to thesolution.

Search Criteria Component Shortlist

Obtain Specification ofComponent

Get details of thebehaviour andvocabulary of thecomponent.

Enables the designer tocreate detailed designs ofsolutions that wouldinclude this component.

Component Shortlist Ideally we can produce aClass Diagram for thecomponent.

Identify TechnologyRequirements andConstraints

Get details of theoperationalprerequisites of thecomponent.

Understand thepracticalities of acquiringthis component, and thecosts of using it.

Component Shortlist Running costs.

Preconditions forinstallation.





InfrastructureAnalysis

Map CurrentInfrastructure

Identify parts of thecurrent infrastructure,to be documented asinfrastructurecomponents.

Provides starting pointfor planningimprovements to theinfrastructure

As for application map Collaboration Diagram:Infrastructure Map As Is

Document InfrastructureComponents

Describe thefunctionality andperformance of eachchunk of the currentinfrastructure

Helps determine whichcomponents can beredeployed in the new orimproved application,and which componentsneed to be altered orreplaced.

Type Diagrams

Document InfrastructureProtocols

Identify how theinfrastructurecomponents talk to eachother at runtime.

Helps fix the interfacesbetween thecomponents that aregoing to remain and thecomponents that aregoing to be replaced.

Sequence diagramsaddress information flowbehaviour requirementscenarios for centralizedaccess, distributedaccess, and connection-free or on-demandaccess.

Sequence Diagram

Map Application toInfrastructure

Understand therelationship betweenthe actual structure ofthe current applicationand the actual structureof the currentinfrastructure.

Helps to justify changesto the infrastructure interms of improvementsto the business processand/or application.

Application Map

Infrastructure Map

Matrix mappingbetween ApplicationMap and InfrastructureMap

ProcessDesign

Determine OptimizationStrategy

Identify the processimprovement pattern(s)to be applied.

Establishes a coherentstyle for the design.

Provides consistentdirection to individualdesigners.

for example:Simplification,Generalization,Integration





Business RuleRationalization

Restructure or simplifythe Rule Diagram.

Ensures that essentialrules are implementedreliably and cost-effectively.

Are all business rules stillappropriate? Are thereany rules that cost moreto enforce than isjustified by their value tothe business?

Are any business rulesduplicated or redundant?

Start from Rule Diagram(As Is)

Rule Diagram (To Be)

Business ResponsibilityAssignment

Identify where the ruleswill be implemented.

Ensures the solutioncovers the business rulescompletely and cost-effectively.

Does each activity have ameaningful cluster ofresponsibilities?

Rule Diagram

Process Flow Diagram

Mapping between RuleDiagram and ProcessFlow Diagram

Workflow StructureDesign

Identify the flows ofwork between tasks andorganization units.

Ensure that the solutionis sufficiently flexible.

Provide basis foracceptance testing anduser training.

Establish control modelfor workflow engine (ifappropriate).

Is it necessary orappropriate to fix theworkflow? How muchflexibility is possible?

Start from Process FlowDiagram (As Is)

Process Flow Diagram(To Be)

Workflow MechanismSelection

Identify how the workwill flow.

In some situations, it isappropriate to specifymechanisms in advance.

In many situations, it isnecessary to estimaterequired communicationcapacity (both humanand technological).

Are selected mechanismsrobust enough? Arecontingency mechanismsrequired?

Workflow StructureDesign

Process Flow Diagram(To Be)

Sequence Diagram(To Be)





Solution Verification Check solution meetsrequirements.

Reduce risk that theproject fails to meet itsobjectives.

Check solution beforeinvesting in acquisitionor development.

Concentrate on thecomponents whoseacquisition involves thegreatest expectedleadtime, cost or risk.

This task may result inchanges to any of thediagrams representingthe solution.

Release Planning Cluster the changes tothe process into severalself-contained steps orreleases.

Ensure the solution canbe easily implementedwith limited disruptionto ongoing business andtechnical operations.

Consider other businessevents with which theimplementation mayneed to be coordinated.

Annotated Process FlowDiagram and TypeDiagram for eachrelease.

Release Schedule

ApplicationDesign

Information Sourcing Defines where theapplication will obtaindata from, either atinstall-time or at run-time.

Ensure completeness andcorrectness ofinformation to supportbusiness needs.

What are the keyqueries? What data arecurrently available tosupport these queries?

Data Stores

Information Needs

Matrix mappingbetween queries anddata stores.

Component Identification Identifies thecomponents fromwhich the applicationwill be constructed.

The various tasks thatthe software actorsperform are candidateactions for softwarecomponents. We candetail a component interms of its operationsand vocabulary. This isthe external design.

To confirm that theexternal design is at asufficiently fine level ofgranularity to beimplemented as a singlecomponent, it isnecessary to furtherdecompose its actions.

Is the external design at asufficiently fine level ofgranularity to beimplemented as a singlecomponent?

Consider how the lowerlevel items, or interfacetypes, might bepackaged intocomponents.

Components in existingsystem. These may beexplicit (actual) orhidden (potential).

Components readilyavailable from othersources.

Identify External Designof ApplicationComponent

Decompose the Actions

Package Actions intoImplementableComponents

List of components, withoutline description offunctionality and otherrequirements





Component ProtocolDesign

Defines howcomponents will talk toeach other.

Needed for specifyingcomponent interfaces.

Are there standardpatterns or protocols thatcan be used across theproject?

Component List Sequence Diagram

ComponentResponsibilityAssignment

Defines which businessrules will beencapsulated in whichsoftware components.

Ensures all business rulesare covered by solution.

We want to designcomponents with highinternal cohesion andlow coupling with othercomponents.

Does each componenthave a meaningful clusterof responsibilities?

Rule Diagram

Component List

Matrix mappingbetween Rule Diagramand list of Components

Data Storage Design Specify the structureand mechanisms forpersistent data storage.

Ensures the solution willpossess data integrity.

Component Specification Produces a detaileddescription of thevocabulary andbehaviour of all newcomponents.

Enables newcomponents to be foundor built.

Initially Assume OneComponent per Type

However, ComponentsNeed Each Other. TheyWill Be Developed andSold in Suites

Executables May BeDelivered as CoarserGrained Components

Complete theSpecification of AllComponents

Type Diagram, withRule Diagrams to specifypre- and post-conditions.

Component Sourcing Plans the acquisition ofnew components, asReuse, Buy or Build.

Get the most rapid andcost-effective solution.

What is budget forprocurement?

What is budget fordevelopment?

What are timescale andcost implications of eachoption?

Plan





InfrastructureDesign

Envision Solution Create a picture of thenew infrastructure.

How to achieve anappropriate level offlexibility.

Collaboration Diagram:Infrastructure Map ToBe

Develop UpgradedTechnical Architecture

As the varioustechnology componentsare identified they needto be fitted into anarchitecture.

It is here that technologyneeds to look not only atthe information accessrequired but thetechnology behaviouraspects as well. This isthe strength of opendistributed computingand its attractiveness tolarge companiesespecially at theenterprise level.

Components Allocate eachComponent to aPlatform

Determine re-useopportunities

Examine opportunitiesto replace or enhanceother business processesand their technologicalsupport both now andin the future.

The cost justification ofcertain componentsmay require a morebusiness managementviewpoint.

The key projectobjective is to solve thebusiness process issue.This task checks whetherwe have a plan thatachieves a timelyimplementation of asolution for the currentbusiness problem.

If possible, thetechnology layer shouldprovide benefits acrossthe entire enterprise.Can we identify longerterm or broaderopportunities? Towhom (beyond thecurrent project team)should these potentialbenefits be presented?

Allocate Components toPlatforms

Decide how theapplication componentsand services will besupported by specificinfrastructurecomponents.

To produce a technicallyefficient and reliablesolution.

ComponentArchitecture

Technology Architecture

Technology Objectives

Deployment Diagram





ComponentAcquisition

Negotiate Ownership Agree price and otherterms for acquisition.

Ensure this projectbenefits from using thiscomponent.

Consider total cost ofownership.

Consider support andupgrade arrangements.

Component AcquisitionAgreement

Take Delivery Obtain application andtechnology componentsfrom external sources,including customer-supplied product.

Make correct version ofacquired componentavailable to developers.

Component and itsdocumentation

Verify AcquiredComponent

Test or inspectdelivered component.

Check that the correctversion has beendelivered.

Confirm that thecomponent is fit-for-purpose.

Can this be done prior tocontract?

ComponentSpecification

Component and itsdocumentation

Non-conformance log

AcquiredComponentImplementa-tion

Modify ComponentDesign

Customize componentto requirements.

Sometimes it's morecost-effective to alterone component than toalter all its neighbours.

But consider theimplications for supportand future upgrades.

Specification ofRequired Component

Specification of AcquiredComponent

Component

Modified Component

Set ComponentParameters

Set initial conditions oroptions for component.

Align interfaces ofconnecting components.

May also want to reducevariety and complexityof test and operations.

What are the operationaloptions built into thecomponent?

Does componentsupplier offer any advice?

ComponentDocumentation





NewComponentConstruction

Build Component Develop a newcomponent.

Satisfy a requirementthat is not covered byexisting components orcode. Support a newinterface or service.

Is it worth building forreuse?


Confirm technologyplatform

Write code

Component

Unit-Test Component Test component inisolation.

Check that thecomponent conforms toits specification.

Use of test harness.

Range of operatingparameters

Component


Tested Component

TransitionComponentConstruction

Wrap Legacy Code Write an interface orbridge to a definedchunk of legacy code.

Reuse legacy code toproduce applicationcomponents that offerthe requiredinterface/service.

The legacy code usually(but not necessarily)remains on the originalplatform.

Legacy Code


Component

Modify Legacy Code Alter a chunk of legacycode so that it satisfiesnew requirements atthe same time as itcontinues to play itsrole in the legacysystem.

Reuse and generalizelegacy code to produceapplication componentsthat offer the requiredinterface/service.

The legacy code usually(but not necessarily)remains on the originalplatform.

The legacy system willnow access this codethrough the componentinterface.

Legacy Code


Component





ComponentPublication

Define Terms ofAvailability

Establish who can haveaccess to a givencomponent (or set ofcomponents), underwhat terms.

Both producer and usershould gain somethingfrom the wider use ofthis component.

We also need to setlimits to the proper orappropriate use of thecomponent.

What is the likely valueof this component tovarious potential users?

What are the costs,benefits and risks ofmaking this componentavailable to potentialusers?

How should the costsand risks be shared withpotential or actual usersof the component?

Identify any risks ofover-extended use.

Define scope ofavailability (to whom)

Define serviceguarantees (if any)

Define charges

Define supportarrangements

Component AccessTerms

Create ComponentCollateral

Produce other materialsto be delivered withcomponent.

Enhance proper use ofcomponent.

Reduce support costs.


Component

Component Collateral -may include ReadMefiles, SetUp routines andother documentation.

Publish ComponentSpecification

Make specification ofcomponent or serviceavailable to potentialusers, either within thesame company oroutside.

Allows potential users toidentify and locate thecomponent.

May use third partyrepositories or brokerageservices.







Establish ComponentDelivery Mechanism

Defines procedure forauthorized users toaccess the componentor service itself.

Facilitate proper use ofcomponent, whileinhibiting improper use.

If wide use is desired orexpected, an automaticdelivery and controlmechanism may berequired.

Component

Component Collateral


Define procedure foridentifying andauthorizing user

Define procedure forconfirming that useraccepts terms of use

Define mechanism fordelivering componentand collateral to user

Define chargingmechanism

SolutionTesting

Define Test Plan Specify how thesolution will be tested,including:

§ assembly test

§ computer systemtest

§ performance test

§ user acceptance test

Ensure that the tests willbe effective in verifyingsolution, and will useresources efficiently.

Test againstspecification.

Test against intendedimprovements and userexpectations.

Specification Define Test Strategy

Create Test Cases

Document ExpectedResults

Test Plan

Establish TestEnvironment

Install all componentsrequired for a givenseries of tests within acontrolled testenvironment

Gain the maximumrelevant informationfrom a series of tests.

Minimize impact of testson productionenvironment.


Components

Install Test Data Storage Generate and installpersistent data storagefor the testenvironment.

Allows data integrity andpersistencecharacteristics to betested.

Is it appropriate toreplicate live data in thetest environment?

Data Storage Design

Test Data





Execute Test Plan Check that the systemproduces the expectedresults under testconditions.

Verifies that the solutionsatisfies therequirements, executessatisfactorily on theinstalled technologicalplatform, and providesthe expected support forthe business process.

Does it executesatisfactorily on theinstalled technologicalplatform?

Does it provide theexpected support for thebusiness process?

Test Plan Execute Test Cases

Compare actual resultswith expected results

Analyse and resolvediscrepancies

Document outstandingrisks and issues

Test Log

Known characteristics ofoperational solution.

SolutionDeployment

Install Components Install all componentsrequired for this releaseof the solution.

Prepares for release. Do all components haveto be installedsimultaneously?

Does a distributedcomponent have to besimultaneously installedin all locations?


Components (availableand tested)

Install technologycomponents.

Install applicationcomponents on theappropriate technologycomponents.

Install processcomponents.

Configure System Configure technologyinfrastructure.

Set operationalparameters.

Prepares for release.

Install Live Data Storage Load or convert datainto productiondatabases.

Prepares for release.

Commission System Commence operation.Go live.

Desired Improvements

development process framework - madasafish

Documents