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 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
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
Top Related