Process Control

1
Process Control
2
The Process Document

• A document that concisely describes the steps we
  go through to produce the next release of a
  product.
• The first version should aim to capture what is
  going on right now, not aim to improve it.
• Can be problematic
• Mgmt believes certain steps are always carried
  out.
• Are they consistently?
• Writing it down can help
• Write to give everybody a clear understanding of
  necessary steps
• Though not necessarily sufficient!
• Ensure quality records can be gathered and
  examined
• QR is a record that a step took place
• Once proven to be consistently followed can than
  use it to suggest improvements and monitor to
  ensure it takes.

3
Documenting Process

• E.g., IEEE Std 1074-1997
• IEEE Standard for Developing Software Life Cycle
  Processes
• A bit formal (!) common sense will do
• Need
• Scope
• When, on-what, duration, repeated?
• Actors
• Primary
• Participants
• Inputs
• What needs to be ready to start this step
• As concrete as possible
• Outputs
• What does this step produce
• Concrete
• Description
• Description of the process step

4
Sample SDLC
Feature Candidate Identification
Feature Candidate Identification
Initial Release Planning
Specification
Coding
Testing
5
1. FCI Feature Request

• Scope
• feature-by-feature
• duration continuous
• Actors
• Marketing Product Manager
• Staff with ideas
• Partners
• Customers
• Champion
• Inputs
• Ideas for product features
• Competitive research
• Outputs
• A feature in the feature tracking system in state
  New
• There is a short meaningful title for the feature
  (1-5 words).
• There is a lt one paragraph description of the
  feature.
• The feature has the product set appropriately.

6
2. FCI Feature Triage

• Scope
• feature-by-feature
• within 1 day of a New feature being submitted
• Actors
• Product Manager
• Inputs
• Features in state New
• Outputs
• Feature moved to state Closed if already doable,
  a duplicate, or makes no sense
• Feature moved to state Valid if a reasonable
  request for that product

7
3. FCI Feature Identification

• Scope
• feature-by-feature
• only for those likely to be in-plan on the next
  release
• repeat until the feature passes Feature
  Validation
• Actors
• Product Manager
• Inputs
• Features in state Valid for the product in
  question.
• Outputs
• A feature that is a candidate for the next
  release.
• Any marketing requirements are listed.
• The feature is cohesive (only grouping
  highly-related functionality)
• The feature cannot be reasonably be divided into
  meaningful, stand-alone sub-features.
• The feature is constrained in scope, not
  open-ended.
• The feature has the target release set
  appropriately.
• The feature is placed into a priority class
  relative to other features.
• The feature is in state Valid-Ready indicating it
  is ready for feature validation (see next step).

8
4. FCI Feature Validation

• Scope
• feature-by-feature
• repeat until pass
• Actors
• QA
• Inputs
• A candidate feature marked for the appropriate
  target release in the Valid-Ready state.
• Outputs
• If passed this will be indicated by moving the
  state to Valid-Verified.
• If failed this will be indicated by moving the
  feature back to state Valid with the Log field
  indicating the no-pass reason.

9
5. FCI - Sizing

• Scope
• feature-by-feature
• repeat whenever new information arises for a
  feature
• Actors
• Coding Manager
• Developers
• Inputs
• A feature in the Valid-Verified, state marked for
  the appropriate target release.
• A feature in the In-Plan or WIP state if resizing
  is called for
• Outputs
• A (new) sizing in ECD (effective coder days)
  attached to the feature.
• (optional) one (or more) assigned coders for whom
  the sizing was made

10
Sample SDLC
Feature Candidate Identification
Initial Release Planning
Initial Release Planning
Specification
Coding
Testing
11
6. IRP Release Plan Prep

• Scope
• all sized, valid-verified features
• Actors
• Product Manager
• Coding Manager
• Inputs
• sized, prioritized, valid-verified candidate
  feature list for this release.
• an initial, suggested end-date for the release
• an understanding of the initial assignment of
  coding resource to the release
• Outputs
• A preliminary, prioritized suggestion for a
  feasible release plan (delta0).
• A prioritized list of alternate features

12
7. IRP Release Plan Meetings

• Scope
• all sized, valid-verified features
• repeat when current plan predicts a gold build
  slip gt 1 month
• Actors
• Product Manager
• Coding Manager
• Release Planning Committee
• Inputs
• A preliminary suggestion for a feasible release
  plan (delta0).
• A prioritized list of alternate features
• Outputs
• A feasible release plan (delta0).
• In-plan features moved to the In Plan state.

13
Sample SDLC
Feature Candidate Identification
Initial Release Planning
Specification
Coding
Testing
14
8. SPEC Specification Meeting

• Scope
• feature-by-feature for in-plan features
• may deal with multiple features at once
• repeat as required by the spec writer
• Actors
• Coding Manager
• Spec Writer
• Product Manager
• staff with ideas
• Inputs
• An in-plan feature.
• Outputs
• A decision recorded with the feature on if a
  written specification is required.
• Notes taken by spec writer attached to the Spec
  Notes field of the feature.

15
9. SPEC Specification Creation

• Scope
• feature-by-feature
• only those features marked as requiring a written
  spec
• refine as spec defects are identified prior to
  code start
• Actors
• Spec Writer
• Staff with ideas
• Inputs
• An in-plan feature requiring a spec.
• Spec notes from the specification meeting.
• Outputs
• A specification document attached to the Spec
  Notes field of the feature.
• The specification must describe all user-visible
  aspects concerning how the feature will work.

16
10. SPEC Specification Review

• Scope
• feature-by-feature
• only those features marked as requiring a written
  spec
• repeated only if a feature spec fails miserably
• Actors
• QA
• Spec writer
• Reviewers drawn from qualified staff
• Inputs
• An in-plan feature that has a spec.
• The specification document.
• Outputs
• A list of defects with the specification
• spec fails to specify what happens under certain
  conditions
• spec does not satisfy all the user requirements
• spec does more than satisfy the user requirements
  
• spec is internally inconsistent or inconsistent
  with how things already existing or specified
  function.
• The list is saved into the Spec Notes section of
  the feature.

17
Sample SDLC
Feature Candidate Identification
Initial Release Planning
Specification
Coding
Testing
18
11. CODING Coding Unit Testing

• Scope
• feature-by-feature
• repeat as defects are identified
• Actors
• Developer
• Architect
• Spec Writer
• Inputs
• An in-plan feature with a reviewed specification
  document (or marked as not requiring a spec).
• Outputs
• Code that fully implements the spec and in
  conformance with architect's technical vision.
• COM API code that can be called by a test script
  and that executes the specified functions.
• Tested by the developer.

19
12. CODING Feature Demo Meeting

• Scope
• feature-by-feature
• may deal with multiple features at once
• repeated only if a feature fails miserably or
  requires very extensive changes
• Actors
• QA
• Developer
• Spec Writer
• Product Manager
• Interested staff
• Scribe
• Inputs
• A new feature nearing the code complete state
• A nightly build clean on all regression tests
  containing the new feature
• Outputs
• a list of defects/corrections to be made to the
  feature
• saved into the Log field of the feature.
• A determination on if this step is passed

20
13. CODING Component Test

• Scope
• feature-by-feature
• repeated as desired by tester after further code
  changes
• Actors
• QA
• Inputs
• a nearly code complete feature
• nightly build containing reviewed code, clean on
  all regression tests
• Outputs
• A list of defects with the feature.
• The list is saved into the Log field of the
  feature.
• Automated regression tests are added to the
  regression testing system to fully or partially
  test the feature.

21
Sample SDLC
Feature Candidate Identification
Initial Release Planning
Specification
Coding
Testing
22
14. TEST Integration

• Scope
• requires all in-plan features to be finished
• feature-by-feature
• repeated on each new build if judged necessary
• Actors
• QA
• Inputs
• A post-DCUT build, clean on all regression tests.
  
• Outputs
• Defects recorded in the defect tracking system.

23
15. TEST System Test

• Scope
• requires all in-plan features to be finished
• feature-by-feature
• repeated for each new build
• Actors
• QA
• Inputs
• A candidate gold master CD, clean on all
  regression tests.
• Complete with installation scripts.
• Other products that need to work with this one.
• Outputs
• go/no-go decision on ship
• Defects in the defect tracking system

24
16. TEST Regression Test

• Scope
• continuous throughout release cycle
• repeated each night
• Actors
• QA
• Development
• Inputs
• A nightly build that compiles
• Outputs
• a report on tests passed and failed
• Defects reported to developers or new baselines

25
Sample SDLC
Feature Candidate Identification
Initial Release Planning
Specification
Coding
Testing
26
Process Enhancement

• Sample process featured
• QA step to validate features
• Spec meeting for each feature with notes taken
• A written spec where called for
• A spec review meeting
• A feature demo meeting
• Further enhancements
• Design meeting, written doc, review
• GUI prototype demo meeting
• Debugger walkthrough by a code buddy
• Formal code review
• Explicit step for automated regression test
• ...

27
Process Enactment

• Easy to define a very complete process
• Hard to enact it!
• Process enactment must happen by steps
• Write down what you think you have
• Establish QRs and reporting on them
• Get to an acceptable level of compliance
• Decide what the next (one) enhancement will be
• Establish QRs for it
• Make it work
• Be dogged, mgmt should not lose focus
• (or abandon it)
• Repeat...
• Mgmt focus is the bottleneck for process
  enhancement