04-12-2012, 03:24 PM
Introduction to software project management
1software project.docx (Size: 39.13 KB / Downloads: 23)
Overview of software project planning
Software development has inherit problem with determining the time it takes to complete it. Software programming is quite different than say, nail production. When one produces nails it is known how many nails machine produces per hour. If you need to produce x number of nails figuring the time it takes is easy. If you need 12h of time, you know that one of your workers can handle the overtime and omitting for the sake of argument certain safety concerns, your worker will be as productive at hour 1 as hour 12. Unfortunately, software development is much harder than nail manufacturing. There are many more unknowns - risks that have to be accounted for. In order to attain rapid software development, four different aspects have to be considered. These are:
• Risk management
• Avoiding common mistakes
• Practicing development fundamentals
• Following practices leading to best possible schedule
The rest of this guide will discuss each of above four elements of project management. All of above are equally important, if any of above four is omitted then the whole structure might fail. The reason for "might" is the risk based aspect - as mentioned before things may go right or wrong. It's all about leaning in favor of successful resolution instead of using methods that increase the chance of failure. One of the methods that increase risk, but are widely used due to their simplicity, is programmer total commitment. This disorganized way of project management has its successes, however these successes are a result of inefficient, hard work - not of smart work that can be achieved by following above four principles.
Development speed
• The speed with which project is completed depends on four competing factors that are pooling the project in their respective directions.
• To achieve rapid development, you need to optimize all four factors listed underneath:
o People - select top talent that is motivated in well organized team structure
o Technology -
o Process - create customer oriented software that incorporates high level of quality achieved with help of development fundamentals. Manage risks with lifecycle model and efficient use of resources.
o Product - remember that size does matter, flexible requirements help in shortening of schedules.
Software development fundamentals
• Development fundamentals reduce time and cost needed to develop software. However, they are not sufficient to develop software quickly, they are only necessary conditions for rapid development (ie if you don't have them you are almost certain to fail, but if you have them you are not guaranteed success).
• Development fundamentals can be divided into three areas that share fuzzy boundaries, non-technical, technical and quality assurance
• Non-technical fundamentals control all aspects of well known trade-off triangle (time, cost and product quality)
o Ability to estimate project size. Once project size is narrowed down, ability to estimate effort needed to develop project based on project size. When effort needed is known, rough schedule can be created.
o Ability to plan and stick to the plan under pressure. Planning can be further broken down into these components:
Team members, team size and team organization.
Lifecycle model choice.
Control over feature set.
Risk management in software development
• Risk management in general is a relatively new discipline, with software risk management playing the role of one of it's most recent advances.
• Risks come in three different forms, each associated with a branch of the "trade-off triangle". Software projects deal with risks associated with schedule, cost and quality.
• The goal of risk management is to minimize crisis management and failure and fix management styles while at the same time maximizing the prevention and elimination of problematic areas of the project.
• In order to achieve above goal risks have to be assessed first and then put under control.
• Risk assessment is made of:
o Risk identification
o Likelihood of events identified as risks
o Impact study of each risk, with priority given to most dangerous scenarios
• Risk control is made of:
o Preparing list of actions that have to be taken when each predicted event takes place
o Making sure risk resolution plan is followed
• There are too many different types of risk to be enumerated here. Risks generally are mirror image of best practices, for example, inadequate design is a risk, while good design is a best practice.
• Risk exposure is the likelihood of the event multiplied by the impact the even will have. Events that are common but have small impact will produce the same risk exposure as events that are rare but have large impact.
• Risk resolution techniques can be as simple as avoiding the task that is risky, to as complex as development of contingency plans.
• Risks don't stay static throughout project development, they change. Risks need to be monitored. A good way to monitor risks is to keep a list of the most current top 10 risks.
• Be aware of projects that are very risky, projects with more than 90% failure probability. These projects don't pay in the long run.