Coding Standards Risk Management Change Control Coding Standards

Coding Standards Risk Management Change Control

Coding Standards give the program a 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 available on the Internet • • • ASP Assembly Language AIS Fortran-77 GNU Linux • • • Java C C++ Perl asp GUI

Pair 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 • 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 Management • Risks can be categorized as – Internal, within control of the project manager – External, outside control of the project manager.

Risk Management Model Barry Boehm

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

Methods 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 risk • • • Material availability Personnel skills Communication problems Requirements changes

Risk 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 Analysis • Use qualitative and quantitative analysis to determine the value of opportunities to pursue versus the threats to avoid

Older Risk Analysis Techniques • Brainstorming 1. 2. 3. • Offer ideas without judgment or evaluation Build on ideas offered Repeat until all ideas are exhausted Delphi method 1. 2. 3. 4. 5. Select a panel of experts (isolated from each other) Prepare and circulate a questionnaire about a risk Solicit risk handling approaches and opinions Share all responses and statistical feedback with entire group Repeat until there is convergence on a consensus

Newer Risk Analysis Techniques • Sensitivity Analysis 1. 2. 3. • Probability Analysis 1. 2. • Choose a few variables with big impact to the plan Define a likely range of variation Assess effects on project outcome Like sensitivity analysis Adds a probability distribution skewed to eliminate optimism Monte Carlo simulation 1. 2. 3. 4. Like probability analysis Assign randomly chosen values for each variable Run simulations to get a probability distribution for the outcome Produces a range of probabilities

Response Planning • Develop contingency plans and identify reserves required (dollars & person hours) • Possible Management Responses – Buy information – Restructure the project – Buy insurance

Some Software Risks and Engineering Response 1. Unrealistic budget and schedule 1. 2. 3. Track performance level (estimates to actuals) Review overhead activities in the organization Don’t allow client to maneuver an unrealistic estimate 2. Personnel shortfalls 1. 2. 3. Plan for training Establish a learning pattern for team members Cultivate teaming relationships with knowledgeable parties Developing wrong capabilities 1. 2. Insist on meeting with the customer Prototype and demonstrate planned activities

Monitoring and Control • Developing corrective action plans and monitor their implementation

Risk 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 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 Table Risk Factors and Categories L—Low Evidence M--Medium Risk Evidence H--High Risk Evidence Rating (HML) Comments Project fit Directly supports organizational mission indirectly impacts one or more goals does not support organization mission Work flow Little or no change to work flow Small effect on work flow Significant change to work flow Organizational stability Little or no change in management expected Some reorganization expected Management structure changing rapidly etc

Work products have a life cycle

Formative 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 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 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 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 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 under 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