process control
Download
Skip this Video
Download Presentation
Process Control

Loading in 2 Seconds...

play fullscreen
1 / 27

Process Control - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Process Control' - Audrey


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
process control

Process Control

Lecture 11

the process document
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

documenting process
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

sample sdlc

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

1 fci feature request
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

2 fci feature triage
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

3 fci feature identification
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

4 fci feature validation
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

5 fci sizing
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

sample sdlc1

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

6 irp release plan prep
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

7 irp release plan meetings
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

sample sdlc2

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

8 spec specification meeting
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

9 spec specification creation
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

10 spec specification review
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

sample sdlc3

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

11 coding coding unit testing
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

12 coding feature demo meeting
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

13 coding component test
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

sample sdlc4

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 test integration
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

15 test system test
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

16 test regression test
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

sample sdlc5

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

process enhancement
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

process enactment
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

ad