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:

Feasibility study

How we do it? Plan Do it?

Is it worth doing?

Project execution

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.

LECTURE 2
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, the system interface with the organization eq. stock control system, whereas in the later case, the systems interface with a machine eq. the air conditioning equipment in a building. Objective versus products A project might be to create a project, the details of which have been specified by the client. On the other hand, the project may be required to meet certain objectives. 1.5 Requirement specification The following are: Functional requirements These define what the end-product of the project is to do. 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. response time. Resource requirements A record of how much the organization is willing to spend on the system. These are also called non-functional requirements.

LECTURE 3
1.6 What is Management? The management involves the following activities: Planning Organizing Staffing Directing Monitoring Controlling Innovating Representing

1.7 Management control It involves setting the objectives for a system and then monitoring the system. The figures explain the whole system: This will involves the local manages in data collection. 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 project manager can move staff from particular branches. This is modeling the consequences of a potentials solution. Several different proposals could be modeled in this way before one was chosen for implementation. It can be seen that a project plan is dynamic and will need constant adjustment during the execution of a project.

The real world

Actions

Data collection

Data Data processing Define objective Information Making decisions / plans Modeling

Decisions Implementation

Fig: The project control cycle

LECTURE 4
Requirement specification The following are: Functional requirements These define what the end-product of the project is to do. 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. response time. Resource requirements A record of how much the organization is willing to spend on the system. 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, the system interface with the organization eq. stock control system, whereas in the later case, the systems interface with a machine eq. the air conditioning equipment in a building. Objective versus products A project might be to create a project, the details of which have been specified by the client. On the other hand, the project may be required to meet certain objectives.

Text book: Software Project Management by Bob Hughes and Mike Cotterell, 4th ed.

Unit -2 Stepwise Project planning LECTURE 5

2.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.2 Selecting a project The project must be worthwhile such that it should have priority over other projects. This evaluate of the merits of projects could be part of strategic planning.

2.3 Identify project scope and objectives The following activities are: Identify objectives and practical measures of the effectiveness in meeting those objectives. Establish a project authority Stakeholder analysis identify all stakeholders in the project and their interests Modify objectives in the light of stakeholders analysis Establish methods of communication with all parties

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.5 Analysis project characteristics The following activities are: Distinguish the project as either objective- 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:

 Identify and describe project products (or deliverables) The products will form the hierarchy. The main product will have sets of component products which in turn may have sub-component products and so on. This relationship can be documented in a Product Breakdown Structure (PBS). It is shown as in the figure.

Project products

System products

Module products

Management products

Module design documents

Module code

Progress report

Overall specification

Integration case

Tested integration software

Fig. 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. For example, a program design must be created before the program can be written and the program specification must exist

before the design can be concerned. These relationships can be shown by the Product Flow Diagram (PFD). It is shown as in figure. User requirements

Overall system specification

Module design

Integration system test cases

Module code

Integrated/tested software
Fig. 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. Produce ideal activity network It is explained by an example of activities network.

Design integration teat cases

Specify overall system

Design module A

Code module A

Test integrated software

Design module B

Code module B

Fig. 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. These are activities which draw together the products activities to check that they are compatible. There could be some key attributes, or milestones, which represent the completion of important stages of the project of which they would want to take particular note. 2.7 Estimate effort for each activity The following activities are: Carry out bottom-up estimates At this point, estimates of the staff effort required, the probable elapsed time and the non-staff resources needed for each activity will need to be produced. Effort is the amount of work that needs to be done. Elapsed time is the time between the start and end of a task. Revise plan to create controllable activities

Try to make activities about the length of the reporting period used for monitoring and controlling the project.

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. So, identifications of risks are very important factor. If it will not take very seriously, the project may be delayed and costly. Plan risk reduction and contingency measures where appropriate We can avoid or at least reduce some of the identified risks. On the other hand, contingency plans specify action that is to be taken if a risk materializes. Adjust overall plans and estimates to take account of risks We may change our plans, by adding new activities which reduce risks 2.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.

2.10 Review/publicize plan Review quality aspects of the project plan Each task should have quality criteria. These are quality checks that have to be passed before the activity can be signed off as completed. Document plans and obtain agreement The plans should be carefully documented and all the parties must agree to the commitment required for the plan.

Text book: Software Project Management by Bob Hughes and Mike Cotterell, 4th ed.

Unit-3 Project Evaluation and Estimation

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. Expressing these costs and benefits in common units We need to evaluate the net benefit, that is, the difference between the total benefit and the total benefit and the total cost of creating and operating the system. We can categorize cost according to where they originate in the life of the project. 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:

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. Return on investment

The return on investment (ROI), also known as the accounting rate of return (ARR), provides a way of comparing the net profitability to the investment required. 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. 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

In any project evaluation we should attempt to identify the risks and quantify their potential effects. 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 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. 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 value of the project is then obtained by summing the cost or benefit for each category. 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. There are a number of risk analysis applications available and produce the risk profiles of the type. 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). 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:

Expansion 0.2 Extend No expansion D Expansion 0.2 Replace No expansion 0.8

Fig. A Decision Tree

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. This will generate inputs for identify the products and activities of the project. Choosing technologies An outcome of project analysis will be the selection of the most appropriate methodologies and technologies. Methodologies include approaches like Unified Software Development Process (USDP), Structure System Analysis and Design Method (SSADM), and Human-Centered Design, 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

In objective-driven project, we define the general software solution that is to be implemented, while in product-driven project, the product to be created is defined before the start of the product. 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

 Safety-critical systems Choice of process models The word process is used to emphasize the idea of a system in action. In order to achieve an outcome, the system will have to execute one or more activities. A major part of the planning will be choosing development methods and slotting them into an overall process model. Structure methods The principle behind structure method is get it right first time. The structure methods are made up of sets of steps and rules which generate system products such as use case diagrams. Some of them are rapid application development (RAD), waterfall model etc.

LECTURE 11
The RAD Model Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a high-speed adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. The RAD approach encompasses the following phases: Business modeling Data modeling

Fig: The Process

Process modeling Application generation Testing and turnover Like all process models, the RAD approach has drawbacks: For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams.

 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 commitment is lacking from either constituency, RAD projects will fail. 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. If high performance is an issue and performance is to be achieved through tuning the interfaces to system components, the RAD approach may not work. RAD is not appropriate when technical risks are high. 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.

LECTURE 12
The Spiral Model The spiral model, originally proposed by Boehm, is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. A spiral model is divided into a number of framework activities, also called task regions. Typically, there are between three and six task regions. Figure 2.8 depicts a spiral model that contains six task regions: Customer communication Planning Risk analysis Engineering Construction and release Customer evaluation