CSC444F'05Lecture 111 Process Control. CSC444F'05Lecture 112 The Process Document A document that concisely describes the steps we go through to produce

CSC444F'05 Lecture 11 1

Process Control


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


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


Sample SDLC

Feature Candidate Identification

Initial Release Planning

Specification

Coding

Testing

Clean, sized features

In-plan features

Feature specifications

Candidate buidls

Gold Build



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 < one paragraph description of the feature. – The feature has the product set appropriately.


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


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


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


4. FCI – Feature Validation


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


5. FCI - Sizing


– 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


Sample SDLC



Specification

Coding

Testing


In-plan features


Candidate buidls

Gold Build



6. IRP – Release Plan Prep

• Scope: – all sized, valid-verified features


– 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

(delta=0).

– A prioritized list of alternate features


7. IRP – Release Plan Meetings

• Scope: – all sized, valid-verified features

– repeat when current plan predicts a gold build slip > 1 month


– Coding Manager

– Release Planning Committee

• Inputs: – A preliminary suggestion for a feasible release plan (delta=0).

– A prioritized list of alternate features

• Outputs: – A feasible release plan (delta=0).

– In-plan features moved to the In Plan state.


Sample SDLC



Specification

Coding

Testing


In-plan features


Candidate buidls

Gold Build


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.


9. SPEC – Specification Creation


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


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.


Sample SDLC



Specification

Coding

Testing


In-plan features


Candidate buidls

Gold Build


11. CODING – Coding & Unit Testing


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


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


13. CODING – Component Test


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


Sample SDLC



Specification

Coding

Testing


In-plan features


Candidate buidls

Gold Build


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.


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


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


Sample SDLC



Specification

Coding

Testing


In-plan features


Candidate buidls

Gold Build


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

– ...


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 QR’s and reporting on them– Get to an acceptable level of compliance– Decide what the next (one) enhancement will be– Establish QR’s for it– Make it work

• Be dogged, mgmt should not lose focus• (or abandon it)

– Repeat...

• Mgmt focus is the bottleneck for process enhancement

Documents

CSC444F'05Lecture 111 Process Control. CSC444F'05Lecture 112 The Process Document A document that concisely describes the steps we go through to produce