Process control
Download
1 / 27

Process Control - PowerPoint PPT Presentation


  • 118 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