1. Project planning and scheduling
1.1. PROPOSAL PLANNING
1.1.1. Planning may be necessary with only outline software requirements.The aim of planning at this stage is to provide information that will be used in setting a price for the system to customers.
1.2. PROJECT PLANNING
1.2.1. Project planning involves breaking down the work into parts and assign these to project team members, anticipate problems that might arise and prepare tentative solutions to those problems
1.3. PLANNING STAGES
1.3.1. At the proposal stage, when you are bidding for a contract to develop or provide a software system.
1.3.2. During the project startup phase, when you have to plan who will work on the project, how the project will be broken down into increments, how resources will be allocated across your company, etc.
1.3.3. Periodically throughout the project, when you modify your plan in the light of experience gained and information from monitoring the progress of the work
1.4. SOFTWARE PRICING
1.4.1. Estimates are made to discover the cost, to the developer, of producing a software system. You take into account, hardware, software, travel, training and effort costs.There is not a simple relationship between the development cost and the price charged to the customer.Broader organisational, economic, political and business considerations influence the price charged.
1.4.1.1. FACTORS AFFECTING SOFTWARE PRICING
1.4.1.1.1. Market opportunity, Cost estimate uncertainty, Contractual terms, Requirements volatility, Financial health
1.5. PLAN-DRIVEN DEVELOPMENT
1.5.1. Plan-driven or plan-based development is an approach to software engineering where the development process is planned in detail. Plan-driven development is based on engineering project management techniques and is the 'traditional' way of managing large software development projects.
1.5.1.1. PLAN-DRIVEN DEVELOPMENT – PROS AND CONS
1.5.1.1.1. The arguments in favor of a plan-driven approach are that early planning allows organizational issues (availability of staff, other projects, etc.) to be closely taken into account, and that potential problems and dependencies are discovered before the project starts, rather than once the project is underway.
1.5.1.1.2. The principal argument against plan-driven development is that many early decisions have to be revised because of changes to the environment in which the software is to be developed and used
1.6. PROJECT PLANS
1.6.1. project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work
1.6.1.1. Plan sections
1.6.1.1.1. Introduction, Project organization, Risk analysis, Hardware and software resource requirements, Work breakdown, Work breakdown, Monitoring and reporting mechanisms
1.6.2. PROJECT PLAN SUPPLEMENTS
1.6.2.1. Quality plan, Validation plan, Configuration management plan, Maintenance plan, Staff development plan
1.7. THE PLANNING PROCESS
1.7.1. Project planning is an iterative process that starts when you create an initial project plan during the project startup phase.
1.7.1.1. Plan changes are inevitable.
1.7.1.1.1. As more information about the system and the project team becomes available during the project, you should regularly revise the plan to reflect requirements, schedule and risk changes.
1.7.1.1.2. Changing business goals also leads to changes in project plans. As business goals change, this could affect all projects, which may then have to be re-planned.
2. Risk management process
2.1. RISK ANALYSIS
2.1.1. Assess probability and seriousness of each risk. Probability may be very low, low, moderate, high or very high. Risk consequences might be catastrophic, serious, tolerable or insignificant.
2.2. Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.
2.3. THE RISK MANAGEMENT PROCESS
2.3.1. Risk identification
2.3.1.1. Identify project, product and business risks
2.3.2. Risk analysis
2.3.2.1. Assess the likelihood and consequences of these risks
2.3.3. Risk planning
2.3.3.1. Draw up plans to avoid or minimise the effects of Risk planning the risk
2.3.4. Risk monitoring
2.3.4.1. Monitor the risks throughout the project
2.4. RISK IDENTIFICATION
2.4.1. Technology risks, People risks, Organisational risks, Requirements risks. Estimation risks.
2.5. RISK PLANNING
2.5.1. Consider each risk and develop a strategy to manage that risk. Avoidance strategies • The probability that the risk will arise is reduced; Minimisation strategies • The impact of the risk on the project or product will be reduced; Contingency plans • If the risk arises, contingency plans are plans to deal with that risk;
2.6. RISK MONITORING
2.6.1. Assess each identified risks regularly to decide whether or not it is becoming less or more probable. Also assess whether the effects of the risk have changed. Each key risk should be discussed at management progress meetings.
2.7. RISK INDICATORS
2.7.1. Technology
2.7.1.1. Technology Late delivery of hardware or support software; many reported technology problems.
2.7.2. People
2.7.2.1. Poor staff morale; poor relationships amongst team members; high staff turnover.
2.7.3. Organizational
2.7.3.1. Organizational gossip; lack of action by senior management.
2.7.4. Tools
2.7.4.1. Reluctance by team members to use tools; complaints about CASE tools; demands for higher-powered workstations.
2.7.5. Requirements
2.7.5.1. Many requirements change requests; customer complaints.
2.7.6. Estimation
2.7.6.1. Failure to meet agreed schedule; failure to clear reported defects
3. Software Management Process
3.1. SOFTWARE PROJECT MANAGEMENT
3.1.1. activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software
3.1.2. Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software
3.2. MANAGEMENT ACTIVITIES
3.2.1. Project planning
3.2.2. Reporting
3.2.3. Risk management
3.2.4. People management
3.2.5. Proposal writing
3.3. SUCCESS CRITERIA
3.3.1. Deliver the software to the customer at the agreed time.
3.3.2. Keep overall costs within budget
3.3.3. Deliver software that meets the customer’s expectations
3.3.4. Maintain a happy and wellfunctioning development team
3.4. SOFTWARE MANAGEMENT DISTINCTIONS
3.4.1. Software processes are variable and organization specific
3.4.1.1. We still cannot reliably predict when a particular software process is likely to lead to development problems
3.4.2. The product is intangible.
3.4.2.1. Software cannot be seen or touched. Software project managers cannot see progress by simply looking at the artefact that is being constructed.
3.4.3. Many software projects are 'one-off' projects
3.4.3.1. Large software projects are usually different in some ways from previous projects. Even managers who have lots of previous experience may find it difficult to anticipate problems