Application Software Process Implementation Paths

About Application Software Process Implementation Paths

The combination of optional processes and alternative processes that is chosen and agreed for any

Application Software Process Implementation segment is known as a Path.  I have identified number of standard paths that my apply.  These are described in Path Templates, i.e. a list of all processes normally conducted within a segment when a given approach is called for.

Path Templates do not define all possible paths.  On the contrary, Path Templates only define example paths.  Application Software Process Implementations can function with any path, provided that it contains a valid and logical combination of related processes.

The actual combination of processes for any given project is defined in the project’s Path Plan. The Path Plan gives a high-level “management plan” view of the overall project.  It would show the processes and key high-level deliverables along with an initial summary view of resourcing and timescale requirements.  This Path Plan is agreed before or during the Project Launch segment.  

A basic framework of Application Software Process Implementation Path Templates explains the basic concepts.  It shows the main choices for the Requirements, Selection and Delivery segments along with inter-segment, management paths.  This is shown and discussed below.  For each of the work segments, the main illustrated Path Templates allow for a full way of doing things, a faster shorter way, and by-passes - i.e. situations where the normal work is not required.

More Path Templates can be created, in particular, those prepared for building integrated package solutions.

The diagram above only illustrates the concept of paths.  One important point to note is that the parallel concepts in Application Software Process Implementations can also apply to the paths and segments.  It is feasible for the paths or segments to overlap, for example, some tasks in a preceding segment may be being finalised while the QA review is taking place, and while the planning and launch for the next segment is being started, and, possibly, where some initial tasks of the following segment are already in progress.

Processes may be mandatory, normal or optional.  Alternative processes may sometimes be defined for the same aspect of a project where there are differing needs and market conditions to address.  In many cases there will be alternative processes depending on the circumstances of the client or the scope of the business requirements.  In this way Application Software Process Implementations can be left open so that many different valid paths can be defined through the processes. Where a new need is identified, new or revised processes can be added into this framework without disturbing the overall design of Application Software Process Implementations  This allows Application Software Process Implementations to be extensible simply and rapidly to meet all needs in the ever-changing marketplace.

The standard Path Templates in Application Software Process Implementations were defined as follows:

• Project Launch
• Segment Launch - Requirements Segment
• * Requirements - Full
• * Requirements - Catalogue
• * Requirements - Validate
• Quality Audit - Requirements
• Review Path Plan (Post Requirements
• Segment Launch - Selection Segment
• * Selection - Full
• * Selection - Short Form
• * Requirements/Selection - Fast-Track Selection
• * Selection - Confirm
• Quality Audit - Selection
• Review Path Plan (Post Selection)
• Segment Launch - Delivery Segment
• * Delivery - Integrated Design Development and Implementation
• * Delivery - Brief Delivery
• * Delivery - Implementation Only
• Delivery - Quality Audit
• Terminate project

The following paths have also been identified, but have not yet been detailed:

• * Delivery - Attached Bespoke Development
• Post-Implementation Launch
• Post-Implementation Support and Maintenance
• Post-Implementation Review
• Post-Implementation - Review of Benefits
• * - alternative paths for same segment

The following represent other related types of work that Consultants may undertake.

• Roll out implementation - similar to "implementation only" but with specific issues to address
• IT Strategy - Check Prerequisite information
• Requirements definition by prototyping
• Feasibility Study / Business Case - concerns how a project is originally defined and justified
• Joint Bidding - the implementation team pre-select preferred vendor(s) then bid jointly to the potential client for the supply and implementation of the complete business solution including software (and possibly hardware)
• Selection of partners - where an implementation is to be performed in conjunction with other partners or sub-contractors.
• Selection - validate - possible path to validate the fit of imposed solution, as opposed to the existing “Selection - Confirm” which should concentrate on confirming a client’s own work.
• Acceptance Testing - where the team is only concerned with independent testing of a new system implemented by other people
• Upgrade - more than routine management of the system but less than a completely new project
• Re-engineering - taking an existing (and probably ageing) package and re-engineering the way it is used, concentrating on business processes and improvements in the way the software is being used.

These are shown in the diagram below.

The Path Templates for “integrated packages” are:

Project Model - a form of Requirements investigation which assumes a pre-chosen package and bases the business process re-design around that known choice of package, modelling the final solution using package specific base models and tools.

Design, Prototyping and Construction - building the solution primarily using iterative prototyping within an IDDI approach

Readiness and Rollout - the testing, preparation and rollout tasks, broken out into a separate Path Template.

Also shown on this diagram is the Requirements/Selection Fast-Track Path Template - a high-speed form of requirements and selection, run  as a single segment.