This action might not be possible to undo. Are you sure you want to continue?
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: Information systems versus embedded systems
The difference is that in the former case. On the other hand. response time. whereas in the later case. the systems interface with a machine eq. Resource requirements A record of how much the organization is willing to spend on the system. 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. the system interface with the organization eq. eq. the details of which have been specified by the client. These are also called non-functional requirements. LECTURE 3 1. the project may be required to meet certain objectives. Objective versus products A project might be to create a project.6 What is Management? The management involves the following activities: Planning Organizing Staffing Directing Monitoring Controlling Innovating Representing . the air conditioning equipment in a building. 1.5 Requirement specification The following are: Functional requirements These define what the end-product of the project is to do. stock control system.
It can be seen that a project plan is dynamic and will need constant adjustment during the execution of a project. .7 Management control It involves setting the objectives for a system and then monitoring the system. Data processing will be needed to transform this raw data into useful information. The making decisions/plans will be useful to take decision whether it will be complete on time or not. It also considers other aspects. The figures explain the whole system: This will involves the local manages in data collection.1. This is modeling the consequences of a potentials solution. The project manager can move staff from particular branches. Several different proposals could be modeled in this way before one was chosen for implementation.
The real world Actions Data collection Data Data processing Define objective Information Making decisions / plans Modeling Decisions Implementation Fig: The project control cycle .
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. the details of which have been specified by the client. the air conditioning equipment in a building. . response time. These are also called non-functional requirements. 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. On the other hand. Objective versus products A project might be to create a project. the system interface with the organization eq. whereas in the later case. Resource requirements A record of how much the organization is willing to spend on the system. 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. eq. the project may be required to meet certain objectives. stock control system.
2 Selecting a project The project must be worthwhile such that it should have priority over other projects. Unit -2 Stepwise Project planning LECTURE 5 2. 4th ed. .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. 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.Text book: Software Project Management by Bob Hughes and Mike Cotterell. This evaluate of the merits of projects could be part of strategic planning.
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 .3 Identify project scope and objectives The following activities are: Identify objectives and practical measures of the effectiveness in meeting those objectives.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.LECTURE 5 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.6 Identify project products and activities The following activities are: .5 Analysis project characteristics The following activities are: Distinguish the project as either objective.
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. The main product will have sets of component products which in turn may have sub-component products and so on. For example. a program design must be created before the program can be written and the program specification must exist . Identify and describe project products (or deliverables) The products will form the hierarchy. 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. It is shown as in the figure.
These relationships can be shown by the Product Flow Diagram (PFD). . User requirements Overall system specification Module design Integration system test cases Module code Integrated/tested software Fig. Produce ideal activity network It is explained by an example of activities network. It is shown as in figure.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.
Elapsed time is the time between the start and end of a task.7 Estimate effort for each activity The following activities are: Carry out bottom-up estimates At this point. the probable elapsed time and the non-staff resources needed for each activity will need to be produced. estimates of the staff effort required.Design integration teat cases Specify overall system Design module A Code module A Test integrated software Design module B Code module B Fig. These are activities which draw together the products activities to check that they are compatible. which represent the completion of important stages of the project of which they would want to take particular note. Revise plan to create controllable activities . Effort is the amount of work that needs to be done. There could be some key attributes. or milestones. 2. 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.
Adjust overall plans and estimates to take account of risks We may change our plans.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. Plan risk reduction and contingency measures where appropriate We can avoid or at least reduce some of the identified risks. contingency plans specify action that is to be taken if a risk materializes. the project may be delayed and costly. So. On the other hand.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. by adding new activities which reduce risks 2.Try to make activities about the length of the reporting period used for monitoring and controlling the project. LECTURE 7 2. identifications of risks are very important factor. If it will not take very seriously. .
2. Unit-3 Project Evaluation and Estimation . 4th ed. 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.10 Review/publicize plan Review quality aspects of the project plan Each task should have quality criteria. Text book: Software Project Management by Bob Hughes and Mike Cotterell.
Expressing these costs and benefits in common units We need to evaluate the net benefit. that is. It is as shown in the figure: . These are: Development costs Setup costs Operational costs Cash flow forecasting A cash flow forecast will indicate when expenditure and income will take place. the difference between the total benefit and the total benefit and the total cost of creating and operating the system.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. We can categorize cost according to where they originate in the life of the project.
Return on investment .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. Payback period The payback period is the time taken to break even or pay back the initial investment.
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.The return on investment (ROI). * 100 Risk evaluation The following things are: Risk identification and ranking . provides a way of comparing the net profitability to the investment required. 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. also known as the accounting rate of return (ARR). 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.
There are a number of risk analysis applications available and produce the risk profiles of the type. This is shown as in the figure: . 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. The value of the project is then obtained by summing the cost or benefit for each category. 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. 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. 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. 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).In any project evaluation we should attempt to identify the risks and quantify their potential effects.
Methodologies include approaches like Unified Software Development Process (USDP). A Decision Tree 0.Expansion 0. and Human-Centered Design.8 Fig. This will generate inputs for identify the products and activities of the project. while technologies include appropriate application-building and automated testing environments. Structure System Analysis and Design Method (SSADM).2 Extend No expansion D Expansion 0.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.2 Replace No expansion 0. Choosing technologies An outcome of project analysis will be the selection of the most appropriate methodologies and technologies. The some of the steps of the project analysis are: Identify project as either objectives-driven or product-driven .
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 .In objective-driven project. the product to be created is defined before the start of the product. we define the general software solution that is to be implemented. while in product-driven project.
waterfall model etc. A major part of the planning will be choosing development methods and slotting them into an overall process model. The structure methods are made up of sets of steps and rules which generate system products such as use case diagrams. 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. the system will have to execute one or more activities. Some of them are rapid application development (RAD). Structure methods The principle behind structure method is ‘get it right first time’. In order to achieve an outcome. The RAD approach encompasses the following phases: Business modeling Data modeling . Safety-critical systems Choice of process models The word ‘process’ is used to emphasize the idea of a system in action.
Fig: The Process Process modeling Application generation Testing and turnover Like all process models. . RAD requires sufficient human resources to create the right number of RAD teams. the RAD approach has drawbacks: For large but scalable projects.
there are between three and six task regions. A spiral model is divided into a number of framework activities. LECTURE 12 The Spiral Model The spiral model. is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. If high performance is an issue and performance is to be achieved through tuning the interfaces to system components. Figure 2. originally proposed by Boehm. 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. the RAD approach may not work. also called task regions. If commitment is lacking from either constituency. 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. Typically. RAD is not appropriate when technical risks are high.8 depicts a spiral model that contains six task regions: Customer communication Planning Risk analysis Engineering Construction and release Customer evaluation . Not all types of applications are appropriate for RAD. If a system cannot be properly modularized. building the components necessary for RAD will be problematic. RAD projects will fail.
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 listening from where you left off, or restart the preview.