Process Control

1. Process Control Lecture 11

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

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 Lecture 11

4. Clean, sized features In-plan features Feature specifications Candidate builds Gold Build Sample SDLC Feature Candidate Identification Feature Candidate Identification Initial Release Planning Specification Coding Testing Lecture 11

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

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 Lecture 11

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). Lecture 11

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. Lecture 11

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 Lecture 11

10. Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build Sample SDLC Feature Candidate Identification Initial Release Planning Initial Release Planning Specification Coding Testing Lecture 11

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 (delta=0). • A prioritized list of alternate features Lecture 11

12. 7. IRP – Release Plan Meetings • Scope: • all sized, valid-verified features • repeat when current plan predicts a gold build slip > 1 month • Actors: • Product Manager • 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. Lecture 11

13. Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Lecture 11

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. Lecture 11

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. Lecture 11

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. Lecture 11

17. Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Lecture 11

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. Lecture 11

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 Lecture 11

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. Lecture 11

21. Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Lecture 11

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. Lecture 11

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 Lecture 11

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 Lecture 11

25. Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Lecture 11

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 • ... Lecture 11

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 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 Lecture 11