Coding StandardsCoding StandardsRisk ManagementRisk ManagementChange ControlChange Control

Coding Standards give the program Coding Standards give the program a common look and feela common look and feel

Coding standards typically address • Use of comments• Variable names• Function names• Maximum length of a routine (lines of code)• Maximum number of routines within a class• Degree of complexity allowed (nested loops, compound boolean

testing, etc)• Naming convention of source code files• Source code directory structure for developer machines, build

machines and source code control tools• Source code file contents (i.e. one C++ class per file)• Ways to indicate incomplete code in source.

Some programming standards Some programming standards available on the Internetavailable on the Internet

• ASP• Assembly Language• AIS• Fortran-77• GNU• Linux

• Java• C• C++• Perl• asp• GUI

Pair ProgrammingPair Programming

“A dialog between two people trying to simultaneously program (and analyze and design and test) and understand how to program better”.

– Kent Beck

Pair programming Pair programming

• Encourages communication

• Reduces coding errors

• Improves code quality(while one person types, the other thinks at a more

strategic level – where is this line of development going? Is there an opportunity to refactor?)

Risk ManagementRisk Management

• Risks can be categorized as– Internal, within control of the project manager– External, outside control of the project

manager.

Risk Management ModelRisk Management ModelBarry BoehmBarry Boehm

Risk IdentificationRisk Identification

• Identifying sources of risk, potential risk events and the symptoms of risk

Methods of Identifying RisksMethods of Identifying Risks

• Customer and team brainstorm potential risks• Problems from previous projects• Examine all project assumptions for the slightest

hint of lists.• Types of risks such as: technical, operational,

political, legal, regulatory, market, social, internal and external

• Use checklists

Programmatic sources of riskProgrammatic sources of risk

• Material availability

• Personnel availability

• Personnel skills

• Communication problems

• Requirements changes

Risk QuantificationRisk Quantification• Risk Event: the precise description of what might

happen• Risk Probability: the degree to which the risk event is

likely to occur• Amount at Stake: the loss if the outcome is

unsatisfactory• Risk exposure: the overall liability potential of the risk.

Formula for risk exposure: RE = P x L

P = probability, L = loss

Risk AnalysisRisk Analysis

• Use qualitative and quantitative analysis to determine the value of opportunities to pursue versus the threats to avoid

Older Risk Analysis TechniquesOlder Risk Analysis Techniques

• Brainstorming1. Offer ideas without judgment or evaluation

2. Build on ideas offered

3. Repeat until all ideas are exhausted

• Delphi method1. Select a panel of experts (isolated from each other)

2. Prepare and circulate a questionnaire about a risk

3. Solicit risk handling approaches and opinions

4. Share all responses and statistical feedback with entire group

5. Repeat until there is convergence on a consensus

Newer Risk Analysis TechniquesNewer Risk Analysis Techniques

• Sensitivity Analysis1. Choose a few variables with big impact to the plan

2. Define a likely range of variation

3. Assess effects on project outcome

• Probability Analysis1. Like sensitivity analysis

2. Adds a probability distribution skewed to eliminate optimism

• Monte Carlo simulation1. Like probability analysis

2. Assign randomly chosen values for each variable

3. Run simulations to get a probability distribution for the outcome

4. Produces a range of probabilities

Response PlanningResponse Planning

• Develop contingency plans and identify reserves required (dollars & person hours)

• Possible Management Responses– Buy information– Restructure the project– Buy insurance

Some Software Risks Some Software Risks and Engineering Responseand Engineering Response

1. Unrealistic budget and schedule• Track performance level (estimates to actuals)• Review overhead activities in the organization• Don’t allow client to maneuver an unrealistic estimate

2. Personnel shortfalls• Plan for training• Establish a learning pattern for team members• Cultivate teaming relationships with knowledgeable parties

3. Developing wrong capabilities• Insist on meeting with the customer• Prototype and demonstrate planned activities

Monitoring and ControlMonitoring and Control

• Developing corrective action plans and monitor their implementation

Risk CategoriesRisk Categories

• Mission and goals (fits the organization)• Organization management (disorganized)• Customer (no input)• Budget/cost • Schedule (development team has no input)• Project content (no documentation )• Performance (inadequate testing)• Project management ( no domain or project knowledge)• Development process (no configuration management or

quality assurance process)• Staff• Environment

Developing a Risk Management PlanDeveloping a Risk Management Plan

1. Construct a risk categorization table (starting point for identification of risks)

2. Rank the risks for each category

3. Sort the table to get high-risk items first

4. Establish a regular weekly risk report

5. Ensure risk management is an ongoing process (new risks must be identified, prioritized and added to the list)

Risk Categorization TableRisk Categorization Table

Risk Factors andCategories

L—Low Evidence

M--Medium Risk Evidence

H--High RiskEvidence

Rating (HML) Comments

Project fitDirectly supportsorganizationalmission

indirectly impactsone or more goals

does not supportorganizationmission    

Work flowLittle or no change towork flow 

Small effect on work flow 

Significant changeto work flow     

Organizational stability

Little or no change in management expected

Some reorganization expected 

Management structure changing rapidly     

etc           

Work products have a life cycleWork products have a life cycle

Formative DevelopmentFormative Development

• Code and supportive documentation undergo frequent and rapid changes before becoming stable.

• Although the work is not complete, it still represents a significant effort and would be costly to lose

Informal Revision ControlInformal Revision Control

• refers to the ability to capture sequential changes to electronic documents

• If necessary, changes can be undone to revert to a prior version of the document

• This gives historical backup and some measure of control

• Be sure to create a backup of the backup.

Accepted ProductAccepted Product

• When the work is completed, the software developer will submit it to a formal acceptance procedure which will:– Review the work to determine whether it is

complete. (Change Control Board) – Formally sign-off the work product.

Formal Revision ControlFormal Revision Control

• a procedure by which changes to an accepted product are proposed, assessed, conditionally accepted, and applied.

• Notify interested parties regarding change proposals.

Assessing Impact of ChangesAssessing Impact of Changes

• Effort to revise the schedule and notify affected parties • Distraction of affected parties from their primary work• Impact on

– user manual – on-line help – product specifications – design documents – source code – test procedures and source code – installation program or procedures – training materials

• The general tendency of quality to degrade with change • Dramatically increased cost of change at later stages of the project

Consider placing the following Consider placing the following under revision controlunder revision control

• Change control plan• Vision statement• Software development plan• User interface prototype• User interface style guide• User manual• Requirements specification• Quality assurance plan• Software architecture• Software integration procedure• Staged delivery plan• Individual stage plans

• Coding standard• Software test cases• Source code • Media used in the product• Software build instructions• Detailed design document for

each stage• Software construction plan for

each stage• Deployment document• Release checklist• Software project log• Software project history

document