CSC444F'06Lecture 111 Process Control

CSC444F'06Lecture 112 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”.

CSC444F'06Lecture 113 Documenting Process E.g., IEEE Std –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

CSC444F'06Lecture 114 Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Clean, sized features In-plan features Feature specifications Candidate builds Gold Build Feature Candidate Identification

CSC444F'06Lecture 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.

CSC444F'06Lecture 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

CSC444F'06Lecture 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).

CSC444F'06Lecture 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.

CSC444F'06Lecture 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

CSC444F'06Lecture 1110 Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build Initial Release Planning

CSC444F'06Lecture 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

CSC444F'06Lecture 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.

CSC444F'06Lecture 1113 Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build

CSC444F'06Lecture 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.

CSC444F'06Lecture 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.

CSC444F'06Lecture 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.

CSC444F'06Lecture 1117 Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build

CSC444F'06Lecture 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.

CSC444F'06Lecture 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

CSC444F'06Lecture 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.

CSC444F'06Lecture 1121 Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build

CSC444F'06Lecture 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.

CSC444F'06Lecture 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

CSC444F'06Lecture 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

CSC444F'06Lecture 1125 Sample SDLC Feature Candidate Identification Initial Release Planning Specification Coding Testing Clean, sized features In-plan features Feature specifications Candidate buidls Gold Build

CSC444F'06Lecture 1126 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 –...

CSC444F'06Lecture 1127 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