Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
Padre Process Overview
Portfolio to Deployment
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
1 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
Table of Contents
Table of Contents .......................................................................................................................................... 2
1
Introduction .......................................................................................................................................... 5
2
End-to-End Process ............................................................................................................................... 6
3
Portfolio Management.......................................................................................................................... 7
4
5
6
7
3.1
Business Goals & Strategy............................................................................................................. 7
3.2
Product/Marketing Roadmap ....................................................................................................... 7
3.3
Key Performance Indicators (KPIs) ................................................................................................ 7
3.4
Balanced Scorecard ....................................................................................................................... 7
3.5
Risk Management ......................................................................................................................... 7
3.6
Artifacts ......................................................................................................................................... 8
Governance ........................................................................................................................................... 9
4.1
Project Roadmap........................................................................................................................... 9
4.2
Technology Roadmap.................................................................................................................... 9
4.3
Artifacts .......................................................................................... Error! Bookmark not defined.
Program & Project Management ........................................................................................................ 10
5.1
Management Standards & Terminology ..................................................................................... 10
5.2
Software Configuration Management (SCM) ............................................................................. 10
5.3
Setting up a Project ..................................................................................................................... 10
5.4
Running a Project ........................................................................... Error! Bookmark not defined.
5.5
Closing a Project.......................................................................................................................... 11
5.6
Project Collateral—Schedules, Resourcing, etc. ......................................................................... 11
5.7
Artifacts ....................................................................................................................................... 11
Requirements ...................................................................................................................................... 12
6.1
Requirements—Capturing the user’s Problem Domain ............................................................. 12
6.2
Risk Analysis—Weighing the options .......................................................................................... 12
6.3
Estimation & Quoting—How much work, time and money ....................................................... 12
Software Development ....................................................................................................................... 13
7.1
Architecture—First-level analysis ............................................................................................... 13
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
2 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
7.2
Design—Component analysis ..................................................................................................... 13
7.3
Coding—A few standard guidelines ............................................................................................ 13
7.4
Source Code Management.......................................................................................................... 13
7.5
User Interface Standards ............................................................................................................ 13
7.6
Iterative Development—Scrum .................................................................................................. 13
7.7
Test-Driven Development (TDD) ................................................................................................. 13
7.8
Artifacts ....................................................................................................................................... 13
8
Build Management.............................................................................................................................. 14
9
Testing ................................................................................................................................................. 16
9.1
Unit/Desk Testing........................................................................................................................ 16
9.2
Integration/System Testing......................................................................................................... 16
9.3
Functional Testing ....................................................................................................................... 16
9.4
Performance Testing ................................................................................................................... 16
9.5
Automated/Regression Testing .................................................................................................. 16
9.6
Simulation Testing....................................................................................................................... 16
9.7
Smoke Testing ............................................................................................................................. 16
9.8
Artifacts ....................................................................................................................................... 16
10 Deployment............................................................................................ Error! Bookmark not defined.
10.1
Packaging ....................................................................................... Error! Bookmark not defined.
10.2
User Documentation ................................................................................................................... 17
10.3
Online Help/Documentation ....................................................................................................... 17
10.4
On-site Installation ...................................................................................................................... 17
10.5
Remote Installation ..................................................................................................................... 17
10.6
Post-installation Verification & Validation.................................................................................. 17
10.7
Artifacts ....................................................................................................................................... 17
11 Support................................................................................................................................................ 18
11.1
Artifacts ....................................................................................................................................... 18
12 Change Management (CM) ................................................................................................................. 19
12.1
Workflow..................................................................................................................................... 19
12.2
Artifacts ....................................................................................................................................... 19
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
3 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
13 Process Management ......................................................................................................................... 20
13.1
Artifacts ....................................................................................................................................... 20
14 Quality Assurance (QA) ....................................................................................................................... 21
14.1
Artifacts ....................................................................................................................................... 21
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
4 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
1 Introduction
This document summarises processes in-use at Padre Software. The intention is to provide a high-level
guide rather than provide in-depth details. Typically, this document will be used as (i) a reference guide
for people already familiar with the processes, and (ii) an introduction and survey for those who are new
to the company. A rough rule of thumb is that no single topic in this guide will take more than a page to
describe (on average). If more detail is needed, there will be a separate guide, providing process maps to
the appropriate level and related supporting collateral (as outlined in chapter 13, “Process
Management”).
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
5 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
2 End-to-End Process
The end-to-end process deals with all aspects of getting a product delivered, other than marketing. In
other words, starting with the company’s business goals—Portfolio Management—through to installing
the product on a customer’s site and making sure it is working there. In between those two endpoints,
this document traverses how to estimate the work, how to set up and manage projects , how to
develop software, testing, deployment, support and documentation. This includes how to handle
changes, which may occur at any time in the lifecycle, with varying impacts.
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
6 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
3 Portfolio Management
Portfolio Management is concerned with achieving the company’s financial objectives, within acceptable
bounds of risk. (It is the job of Marketing to bring in Projects that furthers these goals.) Portfolio
Management determines the overall direction of the company. This should reflected in the mix of
Projects being selected and executed, as well as the company’s assets, investments and clientele. Above
all else, Portfolio Management is about making the right decisions about what Programs/Projects to do.
Portfolio Management must be performed by senior management. Alternatively, a PF Manager may be
dedicated to this function, but the decisions must always be reviewed by senior management and
cannot be acted upon without their commitment.
3.1 Business Goals & Strategy
The portfolio strategy captures the company’s long-term vision and purpose and supports them with
business intelligence, experience, insights and analyses. This results in a broad set of Programs which are
reflected in a Roadmap and realised through ongoing Projects. The latter embody the company’s shortterm ‘Tactics’ to achieve the objectives. Portfolio Management operates through Governance to track
the Projects and ensure their effectiveness. Overall effectiveness is measured via KPIs (below).
Portfolio Management may have an impact on the organisational structure, personnel/resources,
technology platforms, capital expenditures, etc.
3.2 Product/Marketing Roadmap
A portfolio-level Roadmap is a long-term view—generally 12 months or longer—of the company’s
objectives. The order of the objectives depends on many factors: need, time-to-market, costs,
resources, availability of technology, lead times, inter-dependencies, and so on.
The Roadmap should be revisited regularly, at least monthly. (The Roadmap is essentially a ‘Product
Backlog’ in the Scrum methodology and is ‘groomed’ in much the same way—see section TBD.)
3.3 Key Performance Indicators (KPIs)
TBD
3.4 Balanced Scorecard
TBD
3.5 Risk Management
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
7 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
3.6 Artifacts
Roadmap, Business Cases, Budgets (OPEX/CAPEX)
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
8 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
4 Governance
Broadly speaking, Governance monitors (but does not manage) Projects to ensure that they are
executing properly and are meeting the Business Goals. The Governance entity interfaces directly with
the Project Management entity by providing explicit targets to the Project Managers and monitoring
Project progress by means of reports, meetings and online dashboards.
Portfolio Management, which feeds into Governance, is inherently vague and ambiguous as it deals
largely with unknowns. Governance must translate business objectives into concrete actions, i.e.,
Projects. There are usually numerous ways to achieve a high-level goal. Governance should examine
alternatives within the scope of the key variables—cost, benefit, resources, risk, etc. These must be
evaluated in conjunction with a particular Customer/Stakeholder in the context of their particular needs
and environment. (The Stakeholder may be internal, in the case of a Product to be sold off-the-shelf.)
It is equally important that Governance provide the development teams with accurate, timely
information, clear goals and expectations, and sufficient resources to perform their duties.
Governance encompasses the company’s policies, standards, processes and best practices for doing
work. It may have its own set of metrics and KPIs to assess and improve its performance, distinct from
the Portfolio KPIs.
4.1 Project Roadmap
TBD
4.2 Technology Roadmap
TBD
4.3 Gates
Ideally, there are very few Gates (but several Checkpoints) in the development process. A ‘Gate’ implies
a full stop until a decision is made. The minimum number of gates is two: (i) decide to develop the
Product and (ii) decide to ship the Product.
4.4 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
9 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
5 Program & Project Management
Programs and Projects are two closely-related, but nonetheless distinct, management concepts. Loosely
defined, a ‘Program’ is collection of Projects with a common business objective. A Program may be
associated with a particular line of business (LOB) or Product within the company and typically has a
long, often indefinite, duration. A ‘Project’, on the other hand, refers to a schedulable unit of work with
particular resources, assembled to achieve a specific ‘Product’. Programs are more closely aligned with
Strategy, and therefore Portfolio Management, while Projects fall under Governance and are more in
the realm of Tactics. Projects have finite budgets and deadlines.
5.1 Management Standards & Terminology
TBD
5.2 Software Configuration Management (SCM)
If you view the entire set of services and features that the company provides as a Catalogue, then SCM is
the maintenance and control of that Catalogue. This includes not only the names and versions, but also
the various combinations of services and features that can be, or have been, delivered together and the
dependencies between them.
SCM tracks and controls source code, configuration parameters, problems, defects, requests and
changes. This pieces of information are collectively referred to a ‘Configuration Items’ (CIs) and are
typically kept in a database (a CMDB). Minimal tracking information includes unique identification,
version, status and history. It is often necessary to relate the various components to hardware and
environments. SCM has impacts on every aspect of delivering a Product, from Marketing (what can we
provide?) through to Deployment (how do we configure the pieces for a target site?). It generally
includes:





Source Code Management,
Build Management,
Change Management,
Build Management, and
Release Management,
which are treated in separate chapters of this guide.
What is the prime goal of SCM? In a nutshell, to be able to easily build any desired configuration of the
software, from production to test to hotfix to ‘sandbox’, and conversely to be able identify exactly which
CIs are being used in any installation.
5.3 Setting up a Project
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
10 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
5.4 Milestones & Dates
TBD
5.5 Running a Project
TBD
5.6 Gates & Checkpoints
As with Governance, there should be few Gates in a Project, but there should be several Checkpoints. A
‘Gate’ is a full stop, requiring a decision to be made before continuing. Once a Project has been kickedoff, it will ideally run unimpeded until the next Governance gate—deciding if the Product is ready for
Release. Nevertheless, it is important to regularly examine the health and progress of the Project, and
this is where Checkpoints come in. Some typical Checkpoints are: Feasibility Study, Requirements
Analysis, Design Review, etc. Many of these will be optional for a given Project, and none prevent the
Project from progressing. However, a Checkpoint may raise flags that do cause an interruption in
development, if severe enough. Checkpoints often coincide with Milestones, which are the completion
of significant steps in the process, but not every Milestone requires a Checkpoint. Both Checkpoints and
Gates require a ‘consensus’, with varying degrees of formality (meeting, phone conference, exchange of
emails, signing off on an online checklist, etc.).
5.7 Closing a Project
TBD
5.8 Project Collateral—Schedules, Resourcing, etc.
TBD
5.9 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
11 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
6 Requirements
TBD
6.1 Requirements—Capturing the user’s Problem Domain
TBD
6.2 Risk Analysis—Weighing the options
TBD
6.3 Estimation & Quoting—How much work, time and money
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
12 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
7 Software Development
Software Development is a particular kind of Project, with the objective of producing or enhancing a
software package. A software Project comes under the Governance umbrella and is typically an
incremental step towards achieving a particular business (Portfolio) objective. It may or may not be part
of a broader Program.
Software Development begins with the collection and analysis of Requirements—having been given a
mandate and resources from Governance—and ends with successful deployment in the field, typically a
Customer Site. It is critical to accurately capture the Problem Domain right at the beginning of the
Project, as the Requirements drive the Cost Estimation and the software Architecture. At the other end
of the spectrum, good Requirements lead directly to good Test Cases, ensuring that the Product does
what the Customer wanted, prior to installing it and supporting it.
7.1 Architecture—First-level analysis
TBD
7.2 Design—Component analysis
TBD
7.3 Coding—A few standard guidelines
TBD
7.4 Code reviews
TBD
7.5 User Interface Standards
TBD
7.6 Iterative Development—Scrum
TBD
7.7 Test-Driven Development (TDD)
TBD
7.8 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
13 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
8 Build Management
TBD
8.1 Source Code Control
Simply put, we need to track and control every single piece of ‘software’—code, configuration files,
binaries, etc. Each such distinct artifact is referred to as a ‘Configuration Item’ (‘ CI’—see section 5.2,
‘Software Configuration Management (SCM)’). We will need to know at least the name, version and
dependencies for each CI.
8.2 Types of Builds
Production
Test
Hotfix
Sandbox
8.3 Types of Releases
TBD
8.4 Continuous Integration
TBD
8.5 Branching / Variants
TBD
8.6 Continuous Integration
TBD
8.7 Automation & Scheduling
TBD
8.8 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
14 of 21
Padre Processes
Revision: 0.1
7-June-2013
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
Author: Frank Kolnick
15 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
9 Testing
Testing is a crucial component of the Product Development lifecycle. Testing has several purposes:
 find defects
 confirm functionality—does it do what it’s supposed to do?
 confirm coverage, i.e., that the entire Problem Domain has been addressed
 confirm compatibility (with other components)
 confirm defect fixes
 establish performance boundaries (speed, scalability, reliability, etc.)
Testing occurs throughout the entire development process, starting with the individual developer.
(Note that Requirements should also be ‘tested’—see chapter TBD.) Each stage provides increased levels
of confidence. Nevertheless, it is also important to perform regular Regression Testing to make sure that
nothing that has recently been added to the system breaks something that was previously working.
9.1 Unit/Desk Testing
TBD
9.2 Integration/System Testing
TBD
9.3 Functional Testing
TBD
9.4 Performance Testing
TBD
9.5 Automated/Regression Testing
TBD
9.6 Simulation Testing
TBD
9.7 Smoke Testing
TBD
9.8 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
16 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
10 Release Management
Once a software Product has been developed, it needs to be made ready for installation on the
Customer’s Site. This is not always as straightforward as it seems, and there can be many artifacts that
have to be in place before a Product is shipped. This may involve assembling various features and subcomponents and configuring them, adding scripts and documentation, verifying the usability of the
package, and so on. Testing, as described above, is mandatory before a Product can be deployed.
10.1 Packaging
TBD
10.2 User Documentation
TBD
10.3 Online Help/Documentation
TBD
10.4 On-site Installation
TBD
10.5 Remote Installation
TBD
10.6 Post-installation Verification & Validation
TBD
10.7 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
17 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
11 Support
‘Support’ refers to the activity of keeping the delivered functionality working in the field (the Customer’s
site) after it has been deployed. It includes aiding the Customer in using the system effectively, via
training course, help lines, on-site visits, etc. It does not include adding new features to the Product.
11.1 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
18 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
12 Change Management (CM)
Once a Project has been defined—resources allocated, quotation provided, requirements analysed and
confirmed, etc.—any deviation from the established plan is considered a ‘Change’. A Change will almost
always have an effect on costs, schedules or resources. At the very least, a Change needs to be assessed
for possible impacts and must be approved by the Project Manager and possibly the Governance team
before being implemented. In extreme cases, a requested Change may ripple up to the Portfolio layer
and need to be assessed in the context of the Business Objectives.
Changes fall into roughly two major categories: (i) requests to enhance (or create) a Product, and (ii)
required fixes to a Product. These can come from Customers or can be generated internally, e.g., driven
by the Roadmaps. Regardless of reason or origin, all changes must be triaged (quickly), prioritised (or
rejected) and scheduled. They then enter the standard development lifecycle.
Note that a effective Change Management process assumes and requires a solid Configuration
Management process. (In fact, Change Management is often considered to be part of Configuration
Management, or at least part of the same workflow, using the same software tool.)
12.1 Workflow
TBD
12.2 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
19 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
13 Process Management
Everything mentioned so far in this document has a process underlying it. Defining, documenting,
maintaining and improving those processes is called Process Management. The primary objectives of a
Process are to be optimally useful as well as easily accessible and easily implementable, with minimal
ambiguity and overhead. Processes exist solely to get Products developed while satisfying the Portfolio
criteria. If desired, Processes may additionally incorporate elements of standards, such as ISO, ITIL or
CMMI. In that case, the standards must be ‘invisible’ within the organisation’s self-consistent processes.
No one can follow two sets of processes simultaneously.
13.1 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
20 of 21
Padre Processes
Revision: 0.1
7-June-2013
Author: Frank Kolnick
14 Quality Assurance (QA)
The Quality Assurance activity pervades all aspects of all processes—requirements, design, coding,
change management, etc.—with the intention of ensuring that all Projects achieve their predefined
goals, i.e., that they produce high-quality Products. A key element of QA is to minimise defects. QA
includes its own processes, goals and metrics. QA standards may be implemented as integral
components of all other processes. QA encompasses Process Measurement and Improvement.
(Note: Quality Control looks at the quality of the Product itself. In this document, QC is covered by
Testing. QC implements the processes established by QA.)
14.1 Artifacts
TBD
Proprietary and Confidential. Not to be copied or distributed without permission.
© Padre Software Inc., 2013, all rights reserved
21 of 21