Coding Standards Risk Management Change Control

1. Coding StandardsRisk ManagementChange Control

2. 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.

3. ASP Assembly Language AIS Fortran-77 GNU Linux Java C C++ Perl asp GUI Some programming standards available on the Internet

4. 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

5. 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?)

6. Risk Management • Risks can be categorized as • Internal, within control of the project manager • External, outside control of the project manager.

7. Risk Management ModelBarry Boehm

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

9. 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

10. Programmatic sources of risk • Material availability • Personnel availability • Personnel skills • Communication problems • Requirements changes

11. 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

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

13. Older Risk Analysis Techniques • Brainstorming • Offer ideas without judgment or evaluation • Build on ideas offered • Repeat until all ideas are exhausted • Delphi method • 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

14. Newer Risk Analysis Techniques • Sensitivity Analysis • Choose a few variables with big impact to the plan • Define a likely range of variation • Assess effects on project outcome • Probability Analysis • Like sensitivity analysis • Adds a probability distribution skewed to eliminate optimism • Monte Carlo simulation • 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

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

16. Some Software Risks and Engineering Response • 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 • Personnel shortfalls • Plan for training • Establish a learning pattern for team members • Cultivate teaming relationships with knowledgeable parties • Developing wrong capabilities • Insist on meeting with the customer • Prototype and demonstrate planned activities

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

18. 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

19. Developing a Risk Management Plan • Construct a risk categorization table (starting point for identification of risks) • Rank the risks for each category • Sort the table to get high-risk items first • Establish a regular weekly risk report • Ensure risk management is an ongoing process (new risks must be identified, prioritized and added to the list)

20. Risk Categorization Table

21. Work products have a life cycle

22. 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

23. 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.

24. 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.

25. Formal Revision Control • a procedureby which changes to an accepted product are proposed, assessed, conditionally accepted, and applied. • Notify interested parties regarding change proposals.

26. 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

27. 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 Consider placing the following under revision control