This action might not be possible to undo. Are you sure you want to continue?
Software Project Management
DEPTT. : IT Paper Code : CSE 403 E Aug – Dec 2009 SEMESTER: 7th
Text book: Software Project Management by Bob Hughes and Mike Cotterell, 4th ed.
Unit – 1: Introduction to Software Project Management (SPM) LECTURE 1
1.1 Definition of Software Project Management (SPM) Software Project Management (SPM) is an activity of organizing, planning and scheduling of Software Projects. 1.2 Software Projects versus other types of project The following characteristics of software project which make them different from other projects: Invisibility Complexity Conformity Flexibility 1.3 Activities covered by software project management (SPM) The following activities are: The feasibility study Planning Project execution The feasibility/Plan/execution cycle as shown in the figure:
How we do it? Plan Do it?
Is it worth doing?
Fig: Feasibility/Plan/execution cycle
1. The feasibility study We study that whether the project have worth or not, it mean that it has a valid business case. 2. Planning First, we formulate the outline plan for the whole project then later we will go for the detail and accurate plan. 3. Project execution The execution of a project contains the design and implementation subphases.
1.4 Categorizing Software Projects The software projects can be broadly divided into two categories:
whereas in the later case.5 Requirement specification The following are: Functional requirements These define what the end-product of the project is to do. These are also called non-functional requirements.6 What is Management? The management involves the following activities: Planning Organizing Staffing Directing Monitoring Controlling Innovating . On the other hand. the systems interface with a machine eq. Information systems versus embedded systems The difference is that in the former case. LECTURE 3 1. 1. Quality requirements There will be other attributes of the attributes of the application to be implemented that do not relate so much to what the system is to do but how to do it. Objective versus products A project might be to create a project. the details of which have been specified by the client. the system interface with the organization eq. the project may be required to meet certain objectives. Resource requirements A record of how much the organization is willing to spend on the system. response time. the air conditioning equipment in a building. eq. stock control system.
Data processing will be needed to transform this raw data into useful information. . The figures explain the whole system: This will involves the local manages in data collection. It can be seen that a project plan is dynamic and will need constant adjustment during the execution of a project. This is modeling the consequences of a potentials solution.7 Management control It involves setting the objectives for a system and then monitoring the system. Several different proposals could be modeled in this way before one was chosen for implementation. The making decisions/plans will be useful to take decision whether it will be complete on time or not. The project manager can move staff from particular branches. Representing 1. It also considers other aspects.
The real world Actions Data collection Data Data processing Define objective Information Making decisions / plans Modeling Decisions Implementation Fig: The project control cycle .
whereas in the later case. Quality requirements There will be other attributes of the attributes of the application to be implemented that do not relate so much to what the system is to do but how to do it. . response time. the project may be required to meet certain objectives. Resource requirements A record of how much the organization is willing to spend on the system. the air conditioning equipment in a building. On the other hand. Categorizing Software Projects The software projects can be broadly divided into two categories: Information systems versus embedded systems The difference is that in the former case. the details of which have been specified by the client. Objective versus products A project might be to create a project. the systems interface with a machine eq.LECTURE 4 Requirement specification The following are: Functional requirements These define what the end-product of the project is to do. eq. stock control system. These are also called non-functional requirements. the system interface with the organization eq.
Unit -2 Stepwise Project planning LECTURE 5 2. 4th ed.2 Selecting a project The project must be worthwhile such that it should have priority over other projects.Text book: Software Project Management by Bob Hughes and Mike Cotterell. .1 Introduction A major principle of project planning is to plan in outline first and then in more detail as the time to carry out an activity approaches. This evaluate of the merits of projects could be part of strategic planning. An outline of stepwise planning activities is: Select project Identify project scope and objectives Identify project infrastructure Analyze project characteristics Identifies project product and activities Estimate effort for each activity Identify activity risks Allocate resources Review/publicize plan Execute plan/lower levels of planning 2.
3 Identify project scope and objectives The following activities are: Identify objectives and practical measures of the effectiveness in meeting those objectives.2. Establish a project authority Stakeholder analysis – identify all stakeholders in the project and their interests Modify objectives in the light of stakeholder’s analysis Establish methods of communication with all parties .
6 Identify project products and activities The following activities are: .5 Analysis project characteristics The following activities are: Distinguish the project as either objective.LECTURE 5 2.4 Identify project infrastructure The following activities are: Identify relationship between the project and strategic planning Identify installation standards and procedures Identify project team organization 2.or product-driven Analysis other project characteristics (including quality-based ones) Identify high-level risks Take into accounts user requirements concerning implementation Select development methodology and life-cycle approach Review overall resource estimates LECTURE 6 2.
a program design must be created before the program can be written and the program specification must exist . The main product will have sets of component products which in turn may have sub-component products and so on. A framework of a product breakdown structure for a system development task Document generic product flows Some products will need one or more other products to exist first before they can be created. Identify and describe project products (or deliverables) The products will form the hierarchy. For example. It is shown as in the figure. This relationship can be documented in a Product Breakdown Structure (PBS). Project products System products Module products Management products Module design documents Module code Progress report Overall specification Integration case Tested integration software Fig.
Produce ideal activity network It is explained by an example of activities network. User requirements Overall system specification Module design Integration system test cases Module code Integrated/tested software Fig. It is shown as in figure. These relationships can be shown by the Product Flow Diagram (PFD).before the design can be concerned. A framework of a PFD for a software development task Recognize product instances There may be delayed to later in the product when more information is known. .
These are activities which draw together the products activities to check that they are compatible. An example of an activity network Modify the ideal to take into account need for stages and checkpoints There might be a need to modify this by dividing the project into stages and introduces checkpoint activities. which represent the completion of important stages of the project of which they would want to take particular note.Design integration teat cases Specify overall system Design module A Code module A Test integrated software Design module B Code module B Fig. Elapsed time is the time between the start and end of a task. There could be some key attributes.7 Estimate effort for each activity The following activities are: Carry out bottom-up estimates At this point. Revise plan to create controllable activities . Effort is the amount of work that needs to be done. 2. or milestones. the probable elapsed time and the non-staff resources needed for each activity will need to be produced. estimates of the staff effort required.
LECTURE 7 2.8 Identify activity risks The following activities are: Identify and quantify activity-based risks A project plan will be based on a huge number of assumptions. On the other hand. Plan risk reduction and contingency measures where appropriate We can avoid or at least reduce some of the identified risks. the project may be delayed and costly. If it will not take very seriously. contingency plans specify action that is to be taken if a risk materializes.9 Allocate resources Identify and allocate resources The staff available for the project are identified and are allocated to tasks Revise plans and estimates to take into account resource constraints Some staff may be needed for more than one task at the same time and an order of priority is established. identifications of risks are very important factor. by adding new activities which reduce risks 2. . So. Adjust overall plans and estimates to take account of risks We may change our plans.Try to make activities about the length of the reporting period used for monitoring and controlling the project.
4th ed. Unit-3 Project Evaluation and Estimation .10 Review/publicize plan Review quality aspects of the project plan Each task should have quality criteria.2. Document plans and obtain agreement The plans should be carefully documented and all the parties must agree to the commitment required for the plan. These are quality checks that have to be passed before the activity can be ‘signed off’ as completed. Text book: Software Project Management by Bob Hughes and Mike Cotterell.
the difference between the total benefit and the total benefit and the total cost of creating and operating the system. Expressing these costs and benefits in common units We need to evaluate the net benefit.LECTURE 8 Cost-benefit analysis It mainly comprise two steps Identify and estimating all of the costs and benefits of carrying out the project and operating the delivered application. that is. These are: Development costs Setup costs Operational costs Cash flow forecasting A cash flow forecast will indicate when expenditure and income will take place. It is as shown in the figure: . We can categorize cost according to where they originate in the life of the project.
Fig: Typical product life cycle cash flow LECTURE 9 Cost-benefit evaluation techniques The following cost-benefit evaluation techniques are: Net profit The net profit of a project is the difference between total costs and the total income over the life of the project. Return on investment . Payback period The payback period is the time taken to break even or pay back the initial investment.
The return on investment (ROI). The present value of any future cash flow may be obtained by applying the following formula Value in year t Present value = ----------------------(1+r) t Where r is the discount rate and t is the number of years into the future that the cash flow occurs. Internal rate of return The internal rate of return (IRR) attempts to provide a profitability measures as a percentage return that is directly comparable with interest rates. * 100 Risk evaluation The following things are: Risk identification and ranking . Average annual profit ROI = --------------------------Total income Net present value The calculation of net present value is a project evaluation technique that takes into account the profitability of a project and the timing of the cash flows that are produced. also known as the accounting rate of return (ARR). provides a way of comparing the net profitability to the investment required.
Risk profile analysis By study the results of a sensitivity analysis we can identify those factors that are most important to the success of the project. One common approach to risk analysis is to construct a project risk matrix utilizing a checklist of possible risks and to classify each risk according to its relative importance and likelihood. The value of the project is then obtained by summing the cost or benefit for each category. Risk and net present value Where a project is relatively risky it is common practice to use a higher discount rate to calculate net present value.In any project evaluation we should attempt to identify the risks and quantify their potential effects. There are a number of risk analysis applications available and produce the risk profiles of the type. Cost-benefit analysis A more sophisticated approach to the evaluation of risk is to consider each possible outcome and estimate the probability of its occurring and the corresponding value of the outcome. The expected value of each path is the sum of the value of each possible outcome multiplied by its probability of occurrence. This is shown as in the figure: . Using decision trees The analysis of a decision tree consists of evaluating the expected benefit of taking each path from a decision point (It is denoted by D).
2 Extend No expansion D Expansion 0. Structure System Analysis and Design Method (SSADM).Expansion 0. Methodologies include approaches like Unified Software Development Process (USDP). while technologies include appropriate application-building and automated testing environments. The some of the steps of the project analysis are: Identify project as either objectives-driven or product-driven .8 LECTURE 10 Selection of a an appropriate project approach The selection of a particular process model could add new products to the Project Breakdown Structure (PBS) or new activities to the activity network. This will generate inputs for identify the products and activities of the project. and Human-Centered Design.8 Fig. A Decision Tree 0.2 Replace No expansion 0. Choosing technologies An outcome of project analysis will be the selection of the most appropriate methodologies and technologies.
the product to be created is defined before the start of the product. we define the general software solution that is to be implemented.In objective-driven project. Analysis other project characteristics The following point will arise: Is a data-oriented or process-oriented system to be implemented? Will the software that is too produced be a general tool or application specific? Are there specific tools available for implementing the particular type of application? Is the system to be created safety critical? What is the nature of the hardware/software environment in which the system will operate? Identify high-level project risks The following uncertainty will occur: Product uncertainty Process uncertainty Resource uncertainty Take into account user requirement concerning implementation Select general life-cycle approach Some approaches are: Control systems Information systems General tools Specialized techniques Hardware environment . while in product-driven project.
Some of them are rapid application development (RAD). Safety-critical systems Choice of process models The word ‘process’ is used to emphasize the idea of a system in action. waterfall model etc. Structure methods The principle behind structure method is ‘get it right first time’. the system will have to execute one or more activities. The RAD model is a” high-speed” adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. LECTURE 11 The RAD Model Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle. In order to achieve an outcome. A major part of the planning will be choosing development methods and slotting them into an overall process model. The RAD approach encompasses the following phases: Business modeling Data modeling . The structure methods are made up of sets of steps and rules which generate system products such as use case diagrams.
RAD requires sufficient human resources to create the right number of RAD teams. the RAD approach has drawbacks: For large but scalable projects.Fig: The Process Process modeling Application generation Testing and turnover Like all process models. .
RAD is not appropriate when technical risks are high. If commitment is lacking from either constituency. This occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs. there are between three and six task regions. RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system complete in a much abbreviated time frame. If a system cannot be properly modularized. building the components necessary for RAD will be problematic.8 depicts a spiral model that contains six task regions: Customer communication Planning Risk analysis Engineering Construction and release Customer evaluation . LECTURE 12 The Spiral Model The spiral model. Not all types of applications are appropriate for RAD. If high performance is an issue and performance is to be achieved through tuning the interfaces to system components. is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. Figure 2. originally proposed by Boehm. the RAD approach may not work. A spiral model is divided into a number of framework activities. Typically. RAD projects will fail. also called task regions.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.