Unit 1 SOFTWARE PROJECT MANAGEMENT CONCEPTS [9Hrs]

Software Project Management [BCA Seventh Semester] [GM College]

1 (Prepared By: Raju Poudel)

Unit – 1 SOFTWARE PROJECT MANAGEMENT CONCEPTS [9Hrs]

Introduction to Software Project Management: An Overview of Project Planning: Select Project, Identifying Project scope and objectives, infrastructure, project products and Characteristics. Estimate efforts, Identify activity risks, and Allocate resources. Introduction to Software Project Management Dictionary definitions of Project:

- ‘A specific plan or design’. - ‘A planned undertaking’. - ‘A large undertaking: for example, a public works scheme’.

The dictionary definitions put a clear emphasis on the projects being a planned activity. Key characteristics that distinguish projects are as follows:

- Non-routine tasks are involved. - Planning is required. - Specific objectives are to me met or a specified product s to be created. - The project has a predetermined time span. - Work is carried out for someone other than yourself. - Work has several specialisms. - Work is carried out in several phases. - The project is large or complex. - The resources that are available for use on the project are constrained.

Project Management Project management is the application of knowledge, skills, tools and techniques to project activities to meet the project requirements. Factors influencing project management are:

Fig: Project Management Triangle

a) Projects must be delivered on time. b) Projects must be delivered within the cost that was estimated for the project

initially. c) Projects must satisfy the scope of the work agreed upon before starting the project. d) Deliverables of the project must meet customer’s quality requirements.



Project Management Activities Planning, Risk Management, Estimating Resources, Allocation of Resources, Organizing the work, Staffing, Directing Activities, Controlling the project execution, Tracking & Reporting progress, Quality management, Forecasting future trends, Issues solving, Defect Prevention, etc. Software Project Management Software project management is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled. Software project management is an essential part of software engineering. It Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organizations developing and procuring the software Software Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software. Project phases & Life cycle or Activities of Software Project Management

Fig: A Software Project Life Cycle

Problems with software projects A survey of managers published by Thayer, Pyster and Wood identified the following commonly experienced problems:

- Poor estimates and plans. - Lack of quality standards & measures. - Lack of guidance about making organizational decisions. - Lack of techniques to make progress visible. - Poor role decision – who does what? - Incorrect success criteria.



Software Projects vs other types of Project: Many of the techniques of general project management are applicable to software project management, but Fred Brooks pointed out that the products of software projects have certain characteristics that make them different. One way of perceiving software project management is as the process of making visible that which is invisible.

a) Invisibility When a physical artefact such as bridge or road is being constructed the progress being made can actually be seen. With software, progress is not immediately visible.

b) Complexity Per dollar, pound or euro spent, software products contain more complexity than other engineered artefacts.

c) Flexibility The software systems are likely to the subject to a high degree of change.

Stakeholders Stakeholders are those who have stake or interest in the project. They can be groups, units, individuals or organization, internal or external to our organization, which are impacted by or can impact, the outcomes of the project. This includes the project team, sponsors, customers and end-users. Stakeholders might be internal to the project team, external to the project team but in the same organization or totally external to the organization.

a) Internal to the project team This means that they will be under the direct managerial control of the project leader.

b) External to the project team but within the same organization For example, the project leader might need the assistance of the information management group to add some additional data types to a database, the assistance of the users to carry out system testing.

c) External to both the project team and the organization Example includes customers and end-users.

The Role of Project Managers Software managers are responsible for planning and managing project development. Their roles are as follows:

a) Estimation of the project effort, time and cost. b) Planning - Scheduling deliverables, review points and allocation of staff to activities. c) Re planning - Re-estimating and rescheduling in the light of unfolding circumstances,

e.g., risks and quality assurance results. d) Organization - Establishing a division of labor which is able to make the most

effective use of available skills and maximizes productivity potential in the context of characteristics (e.g., risk factors) of the particular project.

e) Quality assurance - Planning and carrying out actions to ensure that the software product meets required quality targets.



An Overview of Project Planning: Project planning is part of project management, which relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment. It is probably the most time consuming project management activity. It is a continuous activity form initial concept through to system delivery. Plans must be regularly revised as new information becomes available. Types of project plan

a) Quality plan: describes the quality procedures and standards that will be used in the project

b) Validation plan: describes the approach, resources and schedule used for system validation

c) Configuration Management plan: describes the configuration management procedures and structures to be used

d) Maintenance plan: predicts the maintenance requirements of the system, maintenance costs and effort required

e) Staff Development plan: describes how the skills and experience of the project team members will be developed

Characteristics of Project Planning a) Consists of temporary activities that have predetermined start and end dates. b) Uses restricted resources. c) It has a single goal or a set of goals. d) All events are to be realized to develop a single and new output. e) Usually has a budget. f) Usually a project manager is responsible for co-ordinating all activities.

Following are the steps performed during project planning: Step 0 : Select Project Step 1 : Identify project scope and objectives Step 2 : Identify project infrastructure Step 3 : Analyse the project characteristics Step 4 : Identify project products and activities Step 5 : Estimate effort for each Activity Step 6 : Identify activity risks Step 7 : Allocate Resources Step 8 : Review Plan Step 9 : Execute plan Step 10 : Lower levels of planning Project planning is the first activity of the project management. Planning essentially consists of creation of the project schedule and the subsequent reporting of the project progress with the project baseline. Here, the Work Breakdown Structure (WBS) is determined and individual tasks are listed out. Time needed for each of the task is estimated. The dependencies among the tasks are noted down using Gnatt chart or Network activity diagram.



Fig: An overview of stepwise project planning

Step 0 : Select project This is called step 0 because in a way of project planning, it is outside the main project planning process. Possibility study suggests us that the project is worthwhile or not. Step 1: Identify project scope and objectives The activities in this step ensure that all the parties to the project agree on the objectives and are committed to the success of the project. Here the following tasks are done:

- 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 stakeholder analysis - Establish methods of communication with all parties



Step 2 : Identify project infrastructure There is usually some kind of infrastructure into which the project must fit. Where the project managers are new to the organization, they must find out the precise nature of this infrastructure. Here following tasks are done:

- Identify relationship between the project and strategic planning - Identify installation standards and procedures. - Identify project team organization

Step 3: Analyze project characteristics The general purpose of this part of planning operation is to ensure that the appropriate methods are used for the project. Here following tasks are carried out:

- Distinguish the project as either objective- product driven - Analyze other project characteristics (including quality –based ones) - Identify high level project risks - Take into account user requirement concerning implementation. - Select development methodology and life cycle approach. - Review overall resources estimates

Step 4 : Identify project products and activities The more detailed planning of the individual activities now takes place. The longer term planning is broad and in outline, while the more immediate tasks are planned in some detail. Here following tasks are carried out:

- Identify and describes project products ( or deliverables ) - Document generic product flows - Record product instance - Produce ideal activity network - Modify the ideal to take into account need for stages and checkpoints.

Step 5: Estimate effort for each activity In this stage, effort for each individual activity must be estimated. Here following tasks are carried out:

- Carry out bottom-up estimates - Revise plan to create controllable activities.

Step 6: Identify activity risks

- Identify and quantify activity based risks - Plan risk reduction and contingency measures where appropriate - Adjust overall plans and estimates to take account of the risks

Step 7: Allocate resources In this stage resources required for the success of the project are identified and allocated. Resources includes time, budget, and project team members.

- Identify and allocate resources - Revise plans and estimates to take into account resource constraints

Step 8: Review / Publicize plan - Review quality aspects of the project plan. - Document plans and obtain agreement.



Step 9 & 10: Execute plan / lower level of planning Once the project is started, plans will need to be drawn up in greater detail for each activity as it becomes due. Detailed and lower level of planning of the soon stages will need to be delayed because more information will be available nearer the start of the stage.

Project Planning Tools Fortunately, there is a huge variety of project management tools available to help freelancers and small business owners with their project planning needs. Some of the very best tools require a substantial financial investment on the part of the freelancer. However, there other tools that may not be quite as full-featured that will work fine for a freelancer who is just starting out or for a very small business owner.

- jxProject, dotProject, GanttProject, Open Workbench, SugarCRM, ProjectPier, OpenProj, Project HQ, Clocking IT, TaskJuggler, etc

Importance of Project Planning a) Increases efficiency. b) Reduces business related risks. c) Facilitates proper coordination. d) Aids in organising. e) Gives right direction. f) Keeps good control. g) Helps to achieve objectives. h) Motivates the personnel. i) Encourages creativity and innovation j) Helps in decision making

Advantages and Disadvantages of Project Planning SN Advantages Disadvantages

1 It saves crucial execution time. Too much time can be spent tweaking Gantt charts to get everything lined up.

2 Defines the project in detail. Too long of a plan takes a great deal of time to update.

3 Indicates the project schedule and major milestones.

Getting bogged down in the details of the plan can cause one to lose sight of the big picture.

4 Establishes baseline plan for schedule, scope and cost.

Project sponsors assume every task as set in concrete which reduces your flexibility to change the order of deliverables around and yet still meet the end date.

5 Identifies risks to the project and indicates a response mechanism.

Increases the risk that time is spent managing the plan instead of managing the people.



Unit – 2 SOFTWARE EVALUATION AND COSTING [9Hrs] Project Evaluation: Strategic Assessment, Technical Assessment, cost-benefit analysis, Cash flow forecasting, cost-benefit evaluation techniques, Risk Evaluation. Selection of Appropriate Project approach: Choosing technologies, choice of process models, structured methods. Project Evaluation/Analysis Deciding whether or not to go ahead with a project is really a case of comparing a proposed project with the alternatives and deciding whether to proceed with it or not. That evaluation will be based on strategic, technical and economic criteria and will normally be undertaken as part of strategic planning or a feasibility study for any Information System development. The risks involved also need to be evaluated. Project evaluation is a systematic and objective assessment of an ongoing or completed project. The aim is to determine the relevance and level of achievement of project objectives, development effectiveness, efficiency, impact and sustainability. Evaluations also feed lessons learned into the decision-making process of the project stakeholders, including donors and national partners. Project evaluation is normally carried out in step 0 of step wise project planning. Following are the project evaluation techniques:

1. Strategic Assessment: Strategic Assessment is usual carried out by senior management to assess whether a project fits in the long-term goal of the organization. For assessment of strategic plan is required that clearly defines the objectives of the organization It helps to evaluate individual projects against the strategic plan or the overall business objectives. Following are the characteristics of strategic assessment:

- Use to assess whether a project fits in the long-term goal of the organization - Usually carry out by senior management - Need a strategic plan that clearly defines the objectives of the organization - Evaluate individual projects against the strategic plan or the overall business

objectives Types of Strategic Assessment

a) Programme Management A programme is a collection of projects that all contribute to the same overall organizational goals. Effective programme management requires that there is a well defined programme goal and that all organization projects are selected and tuned to contribute to this goal. It is suitable for projects developed for use in the organizations. Objectives of Programme Management: -

- How does the project contribute to the long-term goal of the organization? - Will the product increase the market share? By how much?



b) Portfolio Management

Portfolio Management suitable for product developed by a software company for an organization for outsourcing. This management assess the product for the client organization by issue the Programme management. It will also need to carry out strategic assessment for the servicing software company.

2. Technical Assessment Technical assessment of a proposed system consists of evaluating the required functionality against the hardware and software available. Technical Assessment are documents providing information on the assessment of the performance of certain, mainly new and innovative construction products in relation to their essential characteristics. It is a strategic IS plan of the organization and any constraints imposed by the IS plan.

3. Economic Analysis/Cost –Benefit Analysis: A cost benefit analysis is done to determine how well, or how poorly, a planned action will turn out. The primary objective is to find or whether it is economically worthwhile to invest in the project or not. If the return on the investment is good, then the project is considered economically worthwhile. Benefits and costs are often expressed in money terms, and are adjusted for the time value of money, so that all flows of benefits and flows of project costs over time are expressed on a common basis in terms of their “present value.” E.g. should we hire an additional sales person or assign overtime? Is it a good idea to purchase the new stamping machine? Will we be better off putting our free cash flow into securities rather than investing in additional capital equipment? Each of these questions can be answered by doing a proper cost benefit analysis. The standard way of evaluating the economic benefits of evaluating the economic benefits of any project is to carry out a cost-benefit analysis, which consists of two steps:

a) Identifying and estimating all of the costs and benefits of carrying out the project. b) Expressing these costs and benefits in common units.

Costs includes:

a) Development costs – includes the salaries and other employment costs of the staff involved in the development project and all associated costs.

b) Setup costs – includes hardware and software costs for setup. It also includes cost of file conversion, recruitment and staff training.

c) Operational costs – includes cost of operating the system once it has been installed. Indirect vs. Direct costs Direct costs are those for activities or services that benefit specific projects. They are associated specifically with each unit of output, e.g., salaries for project staff and materials required for a particular project. Because these activities are easily traced to projects, their costs are usually charged to projects on an item by-item basis. Examples of direct costs are direct labor, direct materials, commissions, piece rate wages, and manufacturing supplies.



Indirect costs are those for activities or services that benefit more than one project. They are all the other costs that cannot be related to or identified with, a particular unit of output. Examples of indirect costs are production supervision salaries, quality control costs, insurance, and depreciation. Tangible and Intangible Benefit Tangible Benefit: Tangible benefits are those that can be easily quantified. They are usually measured in terms of monthly or annual savings or of profit of the firm. It is a benefit to a person or organization which can be felt and touched. It is a real benefit which is straight forward. Tangible benefits are those measured in monetary terms. Examples:

- Improves the productivity of process and personnel - Lowering the cost of products and services purchased - Paper and postage cost reductions Inventory reduction - Faster product / service look-up and ordering saving time and money - Automated ordering and payment, lowering payment processing and paper costs

Intangible Benefit: Intangible benefits are those that are believed to be difficult or impossible to quantify. Unless these benefits are at least identified, it is entirely possible that many projects would not be feasible It is an indirect benefit which can't be felt or touched. Intangible benefits cannot be measured in monetary terms but they do have a very significant business impact. Examples:

- Increases organizational transparency and responsibility - Accurate and faster access to data for timely decisions - Can reach more vendors, producing more competitive bids - Improved customer response - Saves enormous time and effort in data entry - Facilitates strategic planning

The value of the project is obtained by summing the cost or benefit for each possible outcome weighted by its corresponding probability. Below example, illustrates how this may be done.

Buy Right’s Income Forecasts

Sales Annual Sales Income (Rs.) (i)

Probability (P) Expected Value (Rs.) (i x p)

High 800,000 0.1 80,000

Medium 650,000 0.6 390,000

Low 100,000 0.3 30,000

Expected Income 500,000



Buy Right’s, a software house, is considering developing a payroll application for use in academic institutions and is currently engaged in a cost-benefit analysis. Study of market has shown that, if they can target it efficiently and no competing products become available, they will obtain a high level of sales generating an annual income of Rs. 800,000. They estimate that there is a 1 in 10 chance of this happening. However, a competitor launch a competing application before their own launch date and the sales might generate only Rs. 100,000 per year. They estimate there is a 30% chance of this happening. The most likely outcome they believe, is somewhere in between these two extremes – they will gain market lead by launching before any competing product and achieve annual income of Rs. 650,000. Buy Right’s have therefore calculated their expected sales income as Rs. 500,000. Total development costs are estimated at Rs. 750,000 and sales are expected to be maintained at a reasonably constant level for at least four years. Annual costs of marketing and product maintenance are estimated at Rs. 200,000. Would you advise them to go ahead with the project? This approach is frequently used in the evaluation of large projects such as building of new motorways.

4. Cash Flow Forecasting: Cash flow forecasting is the estimation of the cash flow over time. It is necessary because an excess of estimated benefits over the estimated costs is not sufficient. It is needed to forecast the expenditure and the income. Accurate forecast is not easy so need to revise the forecast from time to time. It is the estimate of the timing and amounts of cash inflows and outflows over a specific period (usually one year). A cash flow forecast shows if a firm needs to borrow, how much, when, and how it will repay the loan. Also called cash flow budget or cash flow projection. A cash flow forecast is an estimate of the amount of money you expect to flow in and out of your business and includes all your projected income and expenses. A forecast usually covers the next 12 months, however it can also cover a short-term period such as a week or month.

5. Cost-Benefit Evaluation Techniques a. Net Profit (NP) The net profit of a project is the difference between the total costs and the total income over the life of the project.

Net profit= Total income – Total costs

b. Payback Period (PBP) The payback period is the time taken to break even or pay back the initial investment. Normally, the project with the shortest PBP will be chosen.

Payback period= Time taken to break even



c. Net Present Value (NPV) Net present value (NPV) is determined by calculating the costs and benefits for each period of an investment. This is based on the view that receiving Rs.100 is better than having to wait until next year to receive it, because Rs.100 next year is worth less than Rs.100 now. Present Value = x/(1+r/100)n

Where, x = present value of earnings (total investment) r = rate of interest n = no. of years Suppose it we need to find the present value of Rs.500 due in 2 years at a rate of 6%. We have, Present Value = x/(1+r/100)n

= 500/(1+6/100)2 = 500/(1+0.06)2 = Rs. 445

d. Future Value or Future Worth Future value is the value of an asset at a specific date. It measures the nominal future sum of money that a given sum of money is "worth" at a specified time in the future assuming a certain interest rate, or more generally, rate of return. Suppose Mr. Sharma deposits Rs. 10,000 in a bank account that pays 10% interest annually. How much money will be in his account after 5 years? Here, PV = Rs. 10,000 i = 10% n = 5 years FV = PV(1+i)n = 10,000 (1+1.10)5 = Rs. 16,105.10

e. Return on Investment (ROI)/Average Rate of Return (ARR) It is known as the Accounting Rate of Return (ARR), provides a way of comparing the net profitability to the investment required.

ROI/ARR = (Average Annual profit/Total Investment) x 100 Suppose, calculating ROI for project, the net profit is Rs. 50,000 and total investment is Rs. 100,000. Then (5 years project) ROI = (10,000/100,000) x 100 % = 10 %



f. Internal Rate of Return (IRR) One disadvantage of NPV as a measure of profitability is that, although it may be used to compare projects, it might not be directly comparable with earnings form other investments or the costs of borrowing capital. Such costs are usually quoted as a percentage interest rate. The IRR attempts to provide a profitability measure as a percentage return that is directly comparable with return rates. Thus, a project that showed an estimate IRR of 10% would be worthwhile if the capital could be borrowed for less than 10% or the capital could not be invested elsewhere for a return greater than 10%.

6. Risk Evaluation: There is a risk that software might exceed the original specification and that a project will be completed early and under budget. That is not a risk that need concern us. Every project involves risk of some form. When assessing and planning a project, we are concerned with the risk of the project's not meeting its objectives. In risk evaluation, we are concerned with taking risk into account when deciding whether to proceed with a proposed project. Following are the risk evaluation techniques: a. 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. Note that the importance and likelihood need to be separately assessed - we might be less concerned with something that, although serious, is very unlikely to occur than with something less serious that is almost certain. The project risk matrix may be used as a way of evaluating projects or as a means of identifying and ranking the risks for a specific project.



Fig: A fragment of a basic project risk matrix Above table illustrates a basic project risk matrix listing some of the risks that might be considered for a project, with their importance and likelihood classified as high (H), medium (M), low (L) or exceedingly unlikely (—). So that projects may be compared the list of risks must be the same for each project being assessed. It is likely, in reality, that it would be somewhat longer than shown and more precisely defined. b. 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. This addition or risk premium, might, for example, be an additional 2% for a reasonably safe project or 5% for a fairly risky one. Projects may be categorized as high, medium or low risk using a scoring method and risk premiums designated for each category. The premiums, even if arbitrary, provide a consistent method of taking risk into account. c. Cost Benefit Analysis (Discussed Previously) d. Risk Profile Analysis A risk profile is a quantitative analysis of the types of threats an organization, asset, project or individual faces. The goal of a risk profile is to provide a non-subjective understanding of risk by assigning numerical values to variables representing different types of threats and the danger they pose. In finance, a risk profile can be a useful tool for discussing and evaluating a potential investment's ability to maximize return on investment (ROI) while minimizing risk.



e. Using Decision Tree: A decision tree is a decision support tool that uses a tree-like graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. It is one way to display an algorithm that only contains conditional control statements. Decision trees are commonly used in operations research, specifically in decision analysis, to help identify a strategy most likely to reach a goal, but are also a popular tool in machine learning. Advantages of Decision Trees:

a) Are simple to understand and interpret. b) Have value even with little hard data. c) Help determine worst, best and expected values for different scenarios.

Disadvantages of Decision Trees: a) Calculations can get very complex, particularly if many values are uncertain and/or if

many outcomes are linked.

The best we can do is to reject over risky projects or choose those with the best risk profile. There are many situations, where we can evaluate whether a risk is important and, if it is, indicate a suitable course of action. Many decisions will limit or affect future options and, at any point, it is important to be able to see into the future to access how a decision will affect the future probability of the project.

Fig: A decision tree

Here, they have calculated that extending the existing system will have an NPV of Rs. 75,000 although if the market expands, significantly, this will be turned into a loss with an NPV of

– Rs.100,000 due to lost revenue. If the market does not expand, replacing the new system now has an NPV of Rs. 250,000 due to the benefits of being able to handle increased sales and other benefits such as improvement management information. If sales do not increase, however, the benefits will be severely reduced and the project will suffer a loss with an NPV of –Rs. 50,000. The company estimate the likelihood of the market increasing significantly at 20% and hence, the probability that it will not increase as 80%. This scenario can be seen in above decision tree.



Selection of Appropriate Project approach: Choosing technologies, choice of process models, structured methods. Selection of approach governed by:

a) Risks uncertainties of the project - are requirement well understood? - are technologies to be used well understood?

b) Type and properties of application to be built - information system? embedded system? - criticality? differences between target and development environments?

c) Clients’ own requirements - need to use a particular method

The development of software in-house suggests that the project has certain characteristics:

a) the project team and the users belong to the same organization; b) the project being considered slot into a portfolio of existing computer-based system; c) the methodologies and technologies to be used are not selected by the project

manager, but are dictated by local standards.

Choosing Technologies An outcome of project analysis will be the selection of the most appropriate methodologies and technologies. Methodologies include techniques like Object Oriented Development, SSADM and JSP. Technologies might include an appropriate application-building and automated testing environment. The chosen technology will influence:

a) The training requirement for development staff; b) The types of staff to be recruited; c) The development environment-both hardware and software; d) System maintenance arrangement.

It deals with the selection of appropriate technology and methodologies for any project. It includes hardware, software, case tools, design and analysis tools (DFD, ER Diagram), programming languages, etc.



Choice of Process Models To create a final product there are number of activities. These can be organized in different ways and we call these process models. A major part of planning will be choosing development methods and slotting them into an overall process model. Planner needs not only to select methods, but also to specify how each method is to be applied. Following are the commonly used process models:

a) Waterfall model b) Prototyping model c) Rapid Application Development (RAD) model d) Incremental Model e) Spiral Model f) Agile Model g) V Process Model

Waterfall Model The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed fully before the next phase can begin. This type of software development model is basically used for the for the project which is small and there are no uncertain requirements. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. In this model software testing starts only after the development is complete.



Advantages of waterfall model:

a) This model is simple and easy to understand and use. b) It is easy to manage due to the rigidity of the model – each phase has specific

deliverables and a review process. c) In this model phases are processed and completed one at a time. Phases do not

overlap. d) Waterfall model works well for smaller projects where requirements are very well

understood. Disadvantages of waterfall model:

a) Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.

b) No working software is produced until late during the life cycle. c) High amounts of risk and uncertainty. d) Not a good model for complex and object-oriented projects. e) Poor model for long and ongoing projects. f) Not suitable for the projects where requirements are at a moderate to high risk of

changing. When to use the waterfall model?

a) This model is used only when the requirements are very well known, clear and fixed. b) Technology is understood. c) There are clear requirements d) The project is short.

Prototyping Model: The basic idea in Prototype model is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Prototyping is an attractive idea for complicated and large systems. Prototype model is a software development model. By using this prototype, the client can get an “actual feel” of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system. Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements.



Advantages of Prototype model:

a) Users are actively involved in the development b) Since in this methodology a working model of the system is provided, the users get a

better understanding of the system being developed. c) Errors can be detected much earlier. d) Quicker user feedback is available leading to better solutions. e) Missing functionality can be identified easily f) Confusing or difficult functions can be identified

Disadvantages of Prototype model:

a) Leads to implementing and then repairing way of building systems. b) Practically, this methodology may increase the complexity of the system as scope of

the system may expand beyond original plans. c) Incomplete application may cause application not to be used as the full system was

designed d) Incomplete or inadequate problem analysis.

When to use Prototype model?

a) Prototype model should be used when the desired system needs to have a lot of interaction with the end users.

b) Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model. It might take a while for a system to be built that allows ease of use and needs minimal training for the end user.

Prototyping ensures that the end users constantly work with the system and provide a feedback which is incorporated in the prototype to result in a useable system. They are excellent for designing good human computer interface systems.

Rapid Application Development (RAD) Model: RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model the components or functions are developed in parallel as if they were mini projects. The developments are time boxed, delivered and then assembled into a working prototype. This can quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements.



Advantages of the RAD model: a) Reduced development time. b) Increases reusability of components c) Quick initial reviews occur d) Encourages customer feedback e) Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model: a) Depends on strong team and individual performances for identifying business

requirements. b) Only system that can be modularized can be built using RAD c) Requires highly skilled developers/designers. d) High dependency on modeling skills e) Inapplicable to cheaper projects as cost of modeling and automated code generation

is very high.

When to use RAD model:

a) RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.

b) It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.

c) RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).



Incremental Model In incremental model the whole requirement is divided into various builds. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into smaller, more easily managed modules. In this model, each module passes through the requirements, design, implementation and testing phases. A working version of software is produced during the first module, so you have working software early on during the software life cycle. Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved. Advantages of Incremental model:

a) Generates working software quickly and early during the software life cycle. b) This model is more flexible – less costly to change scope and requirements. c) It is easier to test and debug during a smaller iteration. d) In this model customer can respond to each built. e) Lowers initial delivery cost. f) Easier to manage risk because risky pieces are identified and handled during it’d

iteration. Disadvantages of Incremental model:

a) Needs good planning and design. b) Needs a clear and complete definition of the whole system before it can be broken

down and built incrementally. c) Total cost is higher than waterfall.

When to use the Incremental model:

a) This model can be used when the requirements of the complete system are clearly defined and understood.

b) Major requirements must be defined; however, some details can evolve with time. c) There is a need to get a product to the market early. d) A new technology is being used e) Resources with needed skill set are not available f) There are some high risk features and goals.



Spiral Model: The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed.

Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’. Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented. Engineering Phase: In this phase software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done. Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral. Advantages of Spiral model:

a) High amount of risk analysis hence, avoidance of Risk is enhanced. b) Good for large and mission-critical projects. c) Strong approval and documentation control. d) Additional Functionality can be added at a later date. e) Software is produced early in the software life cycle.



Disadvantages of Spiral model: a) Can be a costly model to use. b) Risk analysis requires highly specific expertise. c) Project’s success is highly dependent on the risk analysis phase. d) Doesn’t work well for smaller projects.

When to use Spiral model?

a) When costs and risk evaluation is important b) For medium to high-risk projects c) Long-term project commitment unwise because of potential changes to economic

priorities d) Users are unsure of their needs e) Requirements are complex

Agile Development Model Agile development model is also a type of Incremental model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is used for time critical applications.



Advantages of Agile model: a) Customer satisfaction by rapid, continuous delivery of useful software. b) People and interactions are emphasized rather than process and tools. Customers,

developers and testers constantly interact with each other. c) Working software is delivered frequently (weeks rather than months). d) Face-to-face conversation is the best form of communication. e) Close, daily cooperation between business people and developers. f) Continuous attention to technical excellence and good design. g) Regular adaptation to changing circumstances. h) Even late changes in requirements are welcomed

Disadvantages of Agile model:

a) In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

b) There is lack of emphasis on necessary designing and documentation. c) he project can easily get taken off track if the customer representative is not clear

what final outcome that they want. d) Only senior programmers are capable of taking the kind of decisions required during

the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

When to use Agile model:

a) When new changes are needed to be implemented. The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced.

b) To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it.

c) Unlike the waterfall model in agile model very limited planning is required to get started with the project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT world. Changes can be discussed and features can be newly effected or removed based on feedback. This effectively gives the customer the finished system they want or need.

d) Both system developers and stakeholders alike, find they also get more freedom of time and options than if the software was developed in a more rigid sequential way. Having options gives them the ability to leave important decisions until more or better data or even entire hosting programs are available; meaning the project can continue to move forward without fear of reaching a sudden standstill.



V Process Model V- model means Verification and Validation model. Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. V-Model is one of the many software development models. Testing of the product is planned in parallel with a corresponding phase of development in V-model.

Advantages of V-model:

a) Simple and easy to use. b) Testing activities like planning, test designing happens well before coding. This saves

a lot of time. Hence higher chance of success over the waterfall model. c) Proactive defect tracking – that is defects are found at early stage. d) Avoids the downward flow of the defects. e) Works well for small projects where requirements are easily understood.

Disadvantages of V-model:

a) Very rigid and least flexible. b) Software is developed during the implementation phase, so no early prototypes of

the software are produced. c) If any changes happen in midway, then the test documents along with requirement

documents has to be updated.



When to use the V-model: a) The V-shaped model should be used for small to medium sized projects where

requirements are clearly defined and fixed. b) The V-Shaped model should be chosen when ample technical resources are available

with needed technical expertise. High confidence of customer is required for choosing the V-Shaped model approach. Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.

Structured Methods: A structured method includes a design process model, notations to represent the design, report formats, rules and design guidelines. Structured methods may support some or all of the following models of a system:

a) An object model that shows the object classes used in the system and their dependencies.

b) A sequence model that shows how objects in the system interact when the system is executing.

c) A state transition model that shows system states and the triggers for the transitions from one state to another.

d) A structural model where the system components and their aggregations are documented.

e) A data flow model where the system is modelled using the data transformations that take place as it is processed. This is not normally used in object-oriented methods but is still frequently used in real-time and business system design.

f) A use-case model that shows the interactions between users and the system. In practice, structured ‘methods’ are really standard notations and embodiments of good practice. Following these methods and applying the guidelines can result in a reasonable design. Designer creativity is still required to decide on the system decomposition and to ensure that the design adequately captures the system specification.



Unit – 3 SOFTWARE ESTIMATION TECHNIQUES [9Hrs] Software Effort Estimation: Problems with over and under estimations, Basis of software Estimation, Software estimation techniques, expert Judgment, Estimating by analogy. Activity Planning: Project schedules, projects and activities, sequencing and scheduling Activities, networks planning models, formulating a network model. Software Effort Estimation Software development effort estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds. Difficulties in Software estimation

a) Subjective Nature of estimating b) Political Implications c) Changing Technology d) Lack of homogeneity of project experience

Estimates are carried out at various stages of software project.

a) Strategic Planning - Decide priority to each project. b) Feasibility Study - Benefits of potential system c) System Specification - Detailed requirement analysis at design stage. d) Evaluation of Suppliers Proposals e) Project Planning - Detailed estimates of smaller work components during

implementation.

Basis for Software Estimation - Need historical data - Measure of work - Complexity

Software Estimation Techniques: a) Algorithmic Models b) Expert Judgment c) Analogy – Similar Completed Project d) Parkinson Estimation e) Price-to-Win Estimation f) Top-down – Overall estimate is formulated g) Bottom-up – Individual components are aggregated

1. Bottom-up Estimating – Break project into smaller and smaller components – Stop when you get to what one person can do in one/two weeks] – Estimate costs for the lowest level activities – At each higher level calculate estimate by adding estimates for lower levels



2. Top-down Estimating

– Produce overall estimate using effort driver (s) – distribute proportions of overall estimate to components

Bottom-up versus top-down Bottom-up

– identify all tasks that have to be done – so quite time consuming – use when you have no data about similar past projects

Top-down

– produce overall estimate based on project cost drivers – based on past project data – divide overall estimate between jobs to be done

3. Algorithmic /Parametric Models COCOMO and function points are the examples of algorithmic models. Problems with these models are as follows:



Function Point Model Function Point model focus on task or system size. FPs originally used to estimate Lines of Code, rather than effort.

Function point analysis has five components:

a) External Input Types (EI) - An EI processes data or control information that comes from outside the system.

b) External Output Types (EO) - An EO is an elementary process that generate data or control information to be sent outside the system.

c) External Inquiry Types (EQ) - An EQ is an elementary process that is made up to an input-output combination that results in data retrieval.

d) Logical Internal File Types (ILF) – A user identifiable group of logical related data or control information maintained within the system.

e) External Interface File Types (EIF) - A user identifiable group of logically related data or control information referenced by the system, but maintained within another system. This means that EIF counted for one system, may be an ILF in another system.

Functions points may compute the following important metrics: – Productivity = FP / persons-months – Quality = Defects / FP – Cost = Rupees / FP – Documentation = Pages of documentation per FP

COCOMO Model COCOMO stands for Constructive Cost Model. This is very popular technique of estimation that is used in software development. It is developed by Barry Bohem and was first published in 1981. This technique estimates the effort and time needed for the project relating it to the size of input and cost drivers. The cost drivers are the parameters that affect the productivity of the project. The below equation provides the basic effort calculation in COCOMO model. PM = C X (KDSI)N Where, PM represents the effort in Person – Month C represents a constant KDSI is thousands (kilo) of delivered source instructions and N is a constant.



COCOMO II For modern software development practices the original COCOMO estimation model’s cost drivers and effort adjustment factors are not very well adaptable. Hence it was evolved into a more comprehensive estimation model, COCOMO II. COCOMO II developed based on changes in software development practices of the 1990s and 2000s, and will continue to evolve over the next few years.

3. Expert Judgment Expert Judgment is a technique in which judgment is provided based upon a specific set of criteria and/or expertise that has been acquired in a specific knowledge area, application area, or product area, a particular discipline, an industry, etc. It is the process of asking for estimate of task effort from someone who is knowledgeable about either application or development environment. Experts use the combination of informal analogy approach where similar projects from past are identified and bottom up estimating. Expert judgment uses the experience and knowledge of experts to estimate the cost of a software project. An advantage of this method is the experience from past projects that the expert brings to the proposed project. The expert also can factor in project impacts caused by new technologies, applications, and languages. Following are the advantages of expert judgement:

- allows for different perspective, - makes valuable use of prior knowledge and experience - helps the team to find creative solutions and - helps the project team avoid re-inventing the wheel

4. Estimating by Analogy Also Called “Case Based Analogy”. Estimator identifies completed projects source cases with similar characteristics to new project (target case). Effort of the source case used as base estimate for target. ANGEL software tool can be used for analogy estimation. Analogous Estimation uses a similar past project information to estimate the duration or cost of your current project, hence the word, "analogy". You can use analogous estimation when there is limited information regarding your current project. Quite often, there will be situations when project managers will be asked to give cost and duration estimates for a new project as the executives need decision-making data to decide whether the project is worth doing. Usually, neither the project manager nor anyone else in the organization has ever done a project like the new one but the executives still want accurate cost and duration estimates. In such cases, analogous estimation is the best solution. It may not be perfect but is accurate as it is based on past data. Analogous estimation is an easy-to-implement technique. The project success rate can be up to 60% as compared to the initial estimates.



5. Parkinson Estimation Parkinson Law says, "Work expands to fill the available volume." A Parkinsonian estimate takes the form: This flight control software must fit on a 65,536-word machine: therefore. Its size will be roughly 65,000 words. It must be done in 18 months, and there are 10 people available to work on it, so the job will take roughly 180 man-months. In some cases, a Parkinsonian estimate has turned out to be remarkably accurate. These have generally been cases in which the estimate left a good deal of extra time and money to continue adding marginally useful "bells and whistles" to the software until the budget ran out, at which point the software was declared complete. Even in these best cases, it is not clear that this final embellishment phase made the best use of the people involved on the project. Parkinsonian estimation is not recommended. Besides not being particularly accurate, it tends to reinforce poor software development practice.

6. Price-to-Win Estimation Here are some examples of price-to-win estimating: I know the cost model estimated $2 million for this job, and none of our experts believe we can do it for less than a million and a half. But I also know that the customer has only $1 million budgeted for this software contract, so that's what we're gonna bid. Now go and fix up the cost estimate and make it look credible. We absolutely have to announce this product at the National Computer Conference next June, and here it is September already. That means we've got 9 months to gel the software ready. The price-to-win technique has won a large number of software contracts for a large number of software companies. Almost all of them are out of business today. The inevitable result is that the money or schedule runs out before the job is done, everybody gets mad at each other, a lot of compromises are made about the software to be delivered, and a lot of programmers work long hours just trying to keep the Job from becoming a complete disaster. The main reason that the price-to-win technique continues to be used is because the technology of software cost estimation has not provided powerful enough techniques to enable software customers or software developers to convincingly differentiate between a legitimate estimate and a price-to-win estimate. One of the primary objectives of the COCOMO model is to begin to provide a way for people to make the 'e differentiations. It is possible to make the COCOMO model give you a lower cost estimate, but only by changing some objectively defined cost driver rating, whose validity can be checked by someone other than the estimator.



Activity Planning The objectives of activity planning

a) Feasibility assessment Is the project possible within required timescales and resource constraints? It is not until we have constructed a detailed plan that we can forecast a completion date with any reasonable knowledge of its achievability.

b) Resource allocation What are the most effective ways of allocating resources to the project. When should the resources be available? The project plan allows us to investigate the relationship between timescales and resource availability.

c) Detailed costing How much will the project cost and when is that expenditure likely to take place? After producing an activity plan and allocating specific resources, we can obtain more detailed estimates of costs and their timing.

d) Motivation Providing targets and being seen to monitor achievement against targets is an effective way of motivating staff, particularly where they have been involved in setting those targets in the first place.

e) Co-ordination When do the staff in different departments need to be available to work on a particular project and when do staff need to be transferred between projects? The project plan, particularly with large projects involving more than a single project team, provides an effective vehicle for communication and coordination among teams.

Activity planning and scheduling techniques place an emphasis on completing the project in a minimum time at an acceptable cost or, alternatively, meeting a set target date at minimum cost One effective way of shortening project durations is to carry out activities in parallel.

Project Schedules A stage of a larger project, the project plan must be developed to the level of showing dates when each activity should start and finish and when and how much of each resource will be required. Once the plan has been refined to this level of detail we call it a project schedule. Creating a project schedule comprises four main stages.

a) First step - step in producing the plan is to decide what activities need to be carried out and in what order they are to be done. From this we can construct an ideal activity plan — that is, a plan of when each activity would ideally be undertaken were resources not a constraint. This activity plan is generated by Steps 4 and 5 of Step Wise.

b) Second step - The ideal activity plan will then be the subject of an activity risk analysis, aimed at identifying potential problems. This might suggest alterations to the ideal activity plan and will almost certainly have implications for resource allocation.

c) Third step - is resource allocation. The expected availability of resources might place constraints on when certain activities can be carried out.

d) Fourth step – is to create project schedule finally.



Projects and Activities Defining Activities Some assumptions that will be relevant when we start to produce an activity plan.

a) Activities must be defined so that they meet these criteria. b) Any activity that does not meet these criteria must be redefined. c) A project is composed of a number of interrelated activities. A project may start

when at least one of its activities is ready to start. d) A project will be completed when all of the activities it encompasses have been

completed. e) If an activity must have a clearly defined start and a clearly defined endpoint,

normally marked by the production of a tangible deliverable. f) An activity requires a resource (as most do) then that resource requirement must be

forecast able and is assumed to be required at a constant level throughout the duration of the activity.

g) The duration of an activity must be forecastable — assuming normal circumstances, and the reasonable availability of resources.

h) Some activities might require that others are completed before they can begin these are known as precedence requirements).

Identifying Activities Essentially there are three approaches to identifying the activities or tasks that make up a project. a) the activity-based approach, b) the product-based approach and c) the hybrid approach.

a) The activity-based approach

The activity based approach consists of creating a list of all the activities that the project is thought to involve. This might involve a brainstorming session involving the whole project team or it might stern from an analysis of similar past projects. When listing activities, particularly for a large project, it might be helpful to subdivide the project into the main lifestyle stages and consider each of these separately. Generating a task list is to create a Work Breakdown Structure (WBS).

Work Breakdown Structure (WBS) The WBS technique is widely used to divide the task into sub tasks and generate the task list form the overall goal of the project. WBS is a way of breaking down the tasks into sub-tasks until each task can be independently estimated and implemented with proper tracking. It can be considered as arranging the tasks in a tree structure with root indicating the overall goal or functionality to be achieved and each layer of the tree indicate the final set of tasks that can be managed in terms of size, complexity and resource allocation.



In the above compiler example, we considered the first level of subtasks we identified the design, code, integrate & test and write manual. Now each of these subtasks can be further broken down if needed. In above example, we sub divide the design task into scanner design, parser design and code generator design.

b) The product based approach It consists of producing a Product Breakdown Structure and a Product Flow Diagram. The PFD indicates, for each product, which other products are required as inputs. The PFD can therefore be easily transformed into an ordered list of activities by identifying the transformations that turn products into others.

c) The Hybrid Approach

It is the combination of both activity based and product based approach. The degree to which the structuring is product based or activity based might be influenced by the nature of the project and the particular development method adopted.

Sequencing and Scheduling Activities Throughout a project, we will require a schedule that clearly indicates when each of the project's activities is planned to occur and what resources it will need. The chart shown has been drawn up taking account of the nature of the development process that is. certain tasks must be completed before others may start) and the resources that are available (for example, activity C follows activity B because Andy cannot work on both tasks at the same time). In drawing up the chart, we have therefore done two things — we have sequenced the tasks (that is, identified the dependencies among activities dictated by the development process) and scheduled them (that is, specified when they should take place). The scheduling has had to take account of the availability of staff and the ways in which the activities have been allocated to them. The schedule might look quite different were there a different number of staff or were we to allocate the activities differently. In the case of small projects. this combined sequencing—scheduling approach might be quite suitable, particularly where we wish to allocate individuals to particular tasks at an early planning stage. However, on larger projects it is better to separate out these two activities: to sequence the tasks according to their logical relationships and then to schedule them taking into account resources and other factors.



Fig: A Project Plan as a Bar Chart

Network Planning Models The two best known models for network planning being CPM (Critical Path Method) and PERT (Project Evaluation & Review Technique). Both of these techniques used an activity-on-arrow approach to visualizing the project as a network where activities are drawn as arrows joining circles, or nodes which represent the possible start and/or completion of an activity or set of activities. More recently a variation on these techniques, called precedence network, has become popular. This method uses activity-on-node networks where activities are represented as nodes and the links between nodes represent precedence (or sequencing) requirements. Critical Path Method (CPM) CPM is a robust technique of network analysis, which is effectively used for the planning, scheduling and controlling of commercial projects and development. CPM networks are generally used for repetitive type of projects like building road, bridge, etc. or for those projects for whose fairly accurate estimate of the completion of each activity can be made and also cost estimations can be made with fair degree of accuracy. However, it isn’t suitable for the research and development projects. Project Evaluation & Review Technique (PERT) PERT, is a statistical tool, used in project management, which was designed to analyze and represent the tasks involved in completing a given project. It was developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. It is commonly used in conjunction with the critical path method (CPM).



Difference between CPM & PERT: a) Orientation

CPM gives emphasis on the activities required to be performed to reach to a particular event or task hence CPM is activity oriented and results of analysis indicate the progress of the activities. While, PERT gives emphasis on the completion of a task hence PERT is event oriented and results of analysis indicate the progress of events.

b) Focus CPM places dual focus on the activities time and cost & evaluates the trade-off between project cost and time. While, PERT basically focuses on the event times so that project can be completed in time.

c) Control device It is difficult to use CPM as a controlling tool simply because, if some changes made into the network, whole evaluation of the project must be repeated each time. While, PERT is an important control tool which has the management in controlling a project by calling attention, making the constant review in the delays in activities completion time.

d) Uses CPM is used for planning, scheduling and controlling of projects which are in the repetitive nature. While, PERT is used for unique and non-repetitive type of project like launching a space craft, developing new Information Systems, developing E-Commerce system, etc.

Constructing CPM Networks a) A project network may have only one start node. b) A project network may have only one end node. c) A link has duration. d) Nodes have no duration. e) Time moves from left to right. f) Nodes are numbered sequentially. g) A network may not contain loops.

h) A network may not contain dangles.



Network Diagram

Example Construct CPM network diagram form the table given below. Also find critical activities, critical paths and total float/slack time for each activity.

Activity Predeccor Time (Weeks)

A - 5

B A 10

C A,B 12

D - 13

E C,D 8

CPM Network Diagram

ES = Early Start EF = Early Finish LS = Late Start LF = Late Finish



Activity Predeccor Time (Weeks)

ES EF LS LF Slack time (LS-ES)

A - 5 0 5 0 5 0 *

B A 10 5 15 5 15 0 *

C A,B 12 15 17 15 17 0 *

D - 13 0 13 4 17 4

E C,D 8 17 25 17 25 0 *

Now, Critical Activities are, A,B,C & E. Critical Path, A B C E Minimum cost is, 25 weeks.



Unit – 4 RISK MANAGEMENT [9Hrs] Risk Management: Nature of Risk, Managing Risk, Risk Identification and Analysis, Reducing the Risk. Resource Allocation: Scheduling resources, Critical Paths, Cost scheduling, Monitoring and Control: Creating Framework, cost monitoring, prioritizing monitoring. Risk Management A risk is indication of occurrence of a loss. It is the combination of both the possibility of occurrence of adverse event and the impact of such bad event that could result in performance issue or revenue and time loss to the company. Risk is indicator to the problem that turn up later during the project. Because of the occurrence of the events listed under the risk, the project might not be able to meet its goals. Risks cannot be eliminated from a project, but luckily can be managed. Risk management is a critical activity of the software project management and planning. Risks can be generated from any one of the following:

a) High employee attrition. b) Failure of team coordination. c) Requirement changes. d) Too many changes to the software code. e) Change in money value (Financial Risk) etc.

The Nature of Risk For the purpose of identifying and managing those risks that may cause a project to overrun its time-scale or budget, it is convenient to identify three types of risks:

- Those caused by the inherent difficulties of estimation. - Those due to assumptions made during the planning process. - Those of unforeseen (or at least unplanned) events occurring.

Following are the risk categories:

a) Project Risks: This identify the risks related to project plan. These project risks are those risks that could result in project slippage, budget related issues, resource & customer requirement related issues, etc.

b) Technical Risks Refers to the potential risks involved in the technology for developing the project, hence could result in poor quality software and also might challenge the timeliness of the software delivery.

c) Business Risks Business Risks threaten the applicability of the software product being built.



Managing Risk

Fig: Risk Management Process

Risk Identification The first stage in any risk management is to identify the hazards that might affect the duration or resource costs of the project. In identifying and analyzing risks, we can usually distinguish both the cause (or hazard), its immediate effect (the problem that it creates) and the risk that it will pose to the project. A common way of identifying hazards is to use a checklist listing all the possible hazards and factors that influence them. Some hazards are generic risks – that is, they are relevant to all software projects. This will include risks such as misunderstanding the requirement or key personnel being ill. There will also be specific risks that are relevant to an individual project and these are likely to be more difficult to identify without an involvement of the members of the project team and a working environment. The categories of factors that will need to be considered include the following:

a) Application factors – Nature of application (Software) – simple or complex. b) Staff factors – include factors like experienced, unexperienced etc. c) Project factors d) Project methods e) Hardware/Software factors f) Changeover factors g) Supplier factors h) Environment factors i) Health & safety factors



Risk Analysis The probability of a hazard’s occurring is known as the risk likelihood; the effect that the resulting problem will have on the project, if it occurs, is known as the risk impact and the importance of risk is known as the risk value or risk exposure. The risk value is calculated as: Risk exposure = risk likelihood x risk impact A better and popular approach is to score the likelihood and impact on a scale, of say, 1 to 10 where hazard that is most likely to occur receives a score of 10 and the least likely a score of 1.

Hazard Likelihood Impact Risk Explosure

R1 Changes to requirements specification during coding

1 8 8

R2 Specification takes longer than expected 3 7 21

R3 Staff sickness affecting critical path activities 5 7 35

R4 Staff sickness affecting non-critical activities 10 3 30

R5 Module coding takes longer than expected 4 5 20

R6 Module testing demonstrates errors or deficiencies in design

1 10 10

Table: Illustrates the part of risk value assessment

Prioritizing the Risks Managing risk involves the use of two strategies:

- Reducing the risk exposure by reducing the likelihood or impact. - Drawing up contingency plans to deal with risk that could occur.

The risk exposure allows us to obtain an approximate ranking in order of importance considering above table, R3 and R4 are, clearly the most important and we could classify them as being high risk concerns. R2 and R5 have similar scores and might be thought of as medium priority risks. The two remaining risks, R1 and R6 have quite low exposure values and can therefore classified as low risks items. In practice, there are generally other factors, in addition to the risk exposure value, that must be taken in account when prioritizing risks.

a) Confidence of risk assessment: Some of our risk assessment exposure will be relatively poor. For that, there is a need for further investigation before action can be planned.

b) Compound risks: Some risks will be dependent on others on that case, they should be treated together as a single task.

c) The number of risks Limit the size of prioritized list.



d) Cost of action:

Some risks, once recognized, can be reduced or avoided immediately with very little cost or effort. For other risks we need to compare the costs of taking action with the benefits of reducing the risks. One method for doing this is to calculate the Risk Reduction Leverage (RRL) using the equation,

RRL = (REbefore - REafter) / risk reduction cost Where, REbefore is the original risk exposure value and REafter is the expected risk exposure value after taking the action Risk reduction cost is the cost of implementing the risk reduction action.

Reducing the Risks: Risks can be reduced by following methods:

a) Hazard Prevention b) Likelihood reduction c) Risk avoidance d) Risk transfer

The impact of some risks can be transferred away from the project by contracting out or taking out insurance.

e) Contingency planning Some risks are not preventable and contingency plans will need to be drawn up to reduce the impact of the hazard occur. A project manager should draw up contingency plans for using agency programmers to minimize the impact of any unplanned absence of programming staff.

Software project risks and strategies for risk reduction a) Personnel shortfalls

Staffing with top talent; team building; training & career development. b) Unrealistic time & cost estimates

Multiple estimation techniques; incremental development; recording & analysis of past projects.

c) Developing the wrong software functions Improved project evaluation; user surveys; prototyping; early user manuals.

d) Developing the wrong user interface Prototyping; task analysis; user involvement.

e) Late changes to requirements Incremental prototyping; incremental development.

f) Shortfalls in externally performed tasks QA procedures; competitive designer prototyping.

g) Real time performance shortfalls Simulation; prototyping; tuning; technical analysis.

h) Development technically too difficult Technical analysis; cost – benefit analysis; prototyping; staff training and development.



Evaluating risks to the schedule using z values: 1. Using PERT to evaluate the effects of uncertainty:

This method is very similar to CPM technique but instead of using a single estimate for the duration of each task, PERT requires three estimates: a) Most likely time – the time we would expect the task to take under normal

circumstances. We shall denote this by the letter m. b) Optimistic time – the shortest time in which we could expect to complete the

activity, barring outright miracles. We shall use the letter a to denote this. c) Pessimistic time – the worst possible time excluding ‘acts of God and welfare’.

We shall denote this by letter b. PERT combines these three estimates to form a single expected duration, te, using the formula:

te = (a+4m+b)/6

2. Activity Standard Deviations This can be calculated using the formula:

S = (b-a)/6 Example

Activity Duration Weeks

Activity Optimistic (a)

Most likely (m)

Pessimistic (b)

Expected (te) Standard Deviation (S)

A 5 6 8 6.17 0.50

B 3 4 5 4.00 0.33

C 2 3 3 2.83 0.17

D 3.5 4 5 4.08 0.25

E 1 3 4 2.83 0.50

F 8 10 15 10.50 1.17

G 2 3 4 3.00 0.33

H 2 2 2.5 2.08 0.08

Calculating the z values, The z value is calculated for each node that has a target date. It is calculate using the formula, Z = (T – te)/S Where, te is the expected date and T is the target date. For T look most likely. The z value for Activity B is, (4-4)/0.33 = 0 The z value for Activity E is, (3-2.83)/0.50 = 0.34



Resource Allocation A resource is any item or person required for the execution of the project. This covers many things form the paper clips to key personnel. The project manager must concentrate on these resources where there is a possibly that, without planning, they might not be sufficiently available when required. Some resources such as project manager will be required for the duration of the project whereas others, such as a specific software developer, might be required for a single activity. In general resources will fall into one of seven categories:

a) Labour They includes members of project team such as project manager, system analysts and developers, quality assurance team, support staff etc.

b) Equipment Workstations and other computing items, office equipment’s, desks and chairs, etc.

c) Materials Materials are items that are consumed, rather than equipment that is used. Software that is to be widely distributed might require supplies of floppy disks to be specially obtained.

d) Space e) Services

Some projects will require procurement of specialist services such as development of wide are distributed systems, for example, requires scheduling of telecommunication services.

f) Time g) Money

The allocation of resources to activities will lead us to review and modify the ideal activity plan. It may cause us to revise stage or project completion dates. The final result of resource allocation will normally be number of schedules including:

a) Activity schedule – indicating the planned start and completion dates for each activity.

b) Resource schedule – showing the dates on which each resource will be required and the level of that requirement.

c) Cost schedule – showing the planned cumulative expenditure incurred by the use of resources over time.

Activities that need to be performed for efficient resource allocation 1. Identifying Resource Requirements The first step in producing a resource allocation plan is too list the resources that will be required along with the expected level of demand. This will normally be done by considering each activity in turn and identifying the resources required. It is likely, however, that there will also be resources required that are not activity specific but are part of the project’s infrastructure (such as the project manager) or required to support other resources (office space, for example, might be required to house contract software developers).



At this stage, it is necessary that the resource requirements list be as comprehensive as possible – it is better that something is included that may later be deleted as unnecessary than to omit something essential.

2. Scheduling Resources Having produced the resource requirement list, the next stage is to map this onto the activity plan to assess the distribution of resources required over time duration of the project. This is best done by representing the activity plan as bar chart and using this to produce a resource histogram for each resource.

Fig: Bar chart and Resource Histogram for analyst/ designer

- Recruiting staff has cost - Smooth the histogram by delaying the start of some activities

It is shown below:



Fig: Bar chart and Resource histogram for analyst/developers after smoothing

3. Creating Critical Paths Scheduling resource can create new critical paths. Delaying the start of an activity because of lack of resources will cause that activity to become critical if this uses up its float. Furthermore, a delay in completing one activity can delay the availability of a resource required for a later activity. If the later one is already critical then the earlier one might now have been made critical by linking their resources.

4. Counting the cost Using additional staff or lengthening the overall duration of the project. The additional costs of employing extra staff would need to be compared to the costs of delayed delivery and the increased risk of not meeting the schedule date.

5. Being Specific Allocating resources and smoothing resource histograms is relatively straightforward where all resources of a given type can be considered more or less equivalent. When allocating laborers to activities in a large building project we need not distinguish among individuals – there are likely to be many labourers and they may be treated as equal so far as skills and productivity are concerned. In allocating individuals to tasks a number of factors need to be taken into account.

a) Availability: We need to know whether a particular individual will be available when required.



b) Criticality Allocation of more experienced personnel to activities on the critical path often helps in shortening project durations or at least reduces the risk of overrun.

c) Risk Identifying those activities posing the greatest risk, and knowing the factors influencing them helps to allocate staff. Allocating the most experienced staff to the highest risk activities is likely to have the greatest effect in reducing overall project uncertainties. More experienced staff are, however usually more expensive.

d) Training e) Team building

5. Publishing the resource schedule In allocating and scheduling resources we have used the activity plan (a precedence network), activity bar charts and resource histograms. Although good as planning tools, they are not the best way of publishing and communicating project schedules. For this we need some form of work plan. Work plans are commonly published either as lists or charts.

6. Cost Schedules It’s now to produce a detailed cost schedule showing monthly or weekly costs over the life of the project. This will provide a more detailed and accurate estimate of costs and will serve as a plan against which project progress can be monitored. Calculating cost is straightforward where the organization has standard cost figures for staff and other resources. Where this is not the case, then the project manager will have to calculate the costs. In general, costs are categorized as follows:

a) Staff cost • Salaries, employer’s contribution to social security, pension, holiday pay, sickness, benefit • Contract staff is charged by the week/month – Even if they are idle

b) Overheads • Expenditures that organization incurs: space rent, interest charges, costs of service departments • These can equal or even exceed the direct employment costs

c) Usage charges • Charged directly for use of resources – computer time



Monitoring and Control The “monitor and control” project management processes typically start with a baseline. The project manager monitors the actual results of the project and compares the results to the baseline. If the actual results and the baseline vary by an unacceptable margin the project manager must react to bring the actual results in line with the variance (or else gain approval to change the baseline). For example, scope management is a process of monitoring the project scope baseline. If the scope changes from the baseline version the project manager invokes scope change management. Likewise, in the planning process you build a baseline schedule. You need to monitor progress against the schedule. If you remain on schedule and your schedule continues to represent the path to project completion, you may not have to update it again. If you detect a variance against your schedule, corrective actions may be necessary. Other “monitor and control” processes include managing budget against baseline, managing risks against baseline and managing vendor performance against contracts. All of this “monitor and control” project management work ends up in the schedule. Having the work in the schedule ensures that it gets done and ensures that the “monitoring and control” work is all appropriately integrated. Following are the project monitoring and control activities:

1. Creating the framework Exercising control over a project and ensuring that targets are met is a matter of regular monitoring, finding out what is happening, and comparing it with current targets. If there is a mismatch between the planned outcomes and the actual ones, then either re planning is needed to bring the project back on target or the target will have to be revised. Below figure illustrates a model of the project control cycle and shows how, once the initial project plan has been published, project control is a continual process of monitoring progress against that plan and, where necessary, revising the plan to take account of deviations. It also illustrates the important steps that must be taken after completion of the project so that the experienced gained in any one project can feed into the planning stages of future projects, thus allowing us to learn from past mistakes.



Fig: Project Control Cycle



Visualizing Progress:

Gnatt Chart: Gnatt chart outline all of the tasks involved in a project and when this tasks need to be finished. Following are the advantages of using Gnatt chart:

a) Avoid completion confusion. b) Understand task relationship. c) Effective allocation of resources. d) It allows graphical representation of a schedule. e) Helps in accurate and easy communication. f) Tracing of the schedule. g) Father the history of the project.

Gnatt chart is named after the inventor Henry L Gnatt. It is a type of bar chart drawn against the time on a horizontal scale. It represents the start date, duration and completion of every task of the project. Additionally, the chart will also represent any dependencies among the task giving the overall graphical representation of the activities of the project. It is shown below:



Slip Chart: Add a slip line on the Gnatt chart. Slip line indicated those activities that are either ahead or behind the schedule. Too much bending indicates a need for rescheduling of the overall plan. It is shown below:



Timeline Chart Timelines are visuals that show important events label on linear scale. They are used in project management to help teams and stakeholders understand what milestones the project needs to achieve and the delivery for each milestone. Timelines are often displayed with project schedules in Gnatt charts.



Ball Chart The ball wall chart provides an incentive for meeting targets.

2. Cost Monitoring Expenditure monitoring is an important component of project control. Not only in itself, but also because it provides an indication of the effort that has gone into (or at least been charged to) a project. A project might be on time but only because more money has been spent on activities than originally budgeted. Earned value Analysis can be used for monitoring the cost. Earned Value Analysis (EVA) EVA is a standard methodology of measuring the project’s progress at any instance of time. EVA helps in analyzing the variance of the project from its baseline cost and schedule and also useful in estimating the probable completion date and cost of the project. The planned amount of work is compared with actually completed amount of the work giving the value measured as “Earned” value. The Earned Value indicates the progress that has been achieved in the work. EVA gives a measure of whether the project is progressing in right direction. For the purpose of tracking the project EVA is used. By calculating the earned values from time to time the project manager can get the feeling if the project is on schedule or slipping. EVA helps to identify if the project is on time and helps to identify the phases or modules causing the slippage in the project so that corrective action can be taken.



It involves calculating three key values for each activity in the Work Breakdown Structure.

a) The planned value (PV) – that portion of the approved cost estimate planned to be spend on the given activity during a given period.

b) The actual cost (AC) – the total of the costs incurred in accomplishing work on the activity in a given period (labour, material, equipment and indirect costs).

c) The earned value (EV) – the value of the work actually completed. These three values are combined to determine at that point in time whether or not work is being accomplished as planned. The most commonly used measure are the cost variance and the schedule variance. Cost Variance (CV) = EV – AC Schedule Variance (SV) = EV – PV These two values can be converted to efficiency indicators to reflect the cost and schedule performance of the project. The most commonly used cost efficiency indicator is the Cost Performance Index (CPI). CPI = EV/AC The sum of all individual EV budgets divided by the sum of all individual ACs is known as the cumulative CPI, and is generally used to forecast the cost to complete the project. The Schedule Performance Index (SPI) is calculated as: SPI = EV/PV A negative schedule variance (SV) calculated at a given point in time means the project is behind schedule, while a negative cost variance (CV) means the project is over budgeted.

3. Prioritizing Monitoring Following are the list of priorities we might apply in deciding levels of monitoring.

- Critical path activities Any delay in an activity on the critical path will cause a delay in the completion date for the project. Critical path activities are therefore likely to have a very high priority for close monitoring.

- Activities with no free float A delay in any activity with no free float will delay at least some subsequent activities even though, if the delay is less than the total float, it might not delay the project completion date. These subsequent delays can have serious effects on our resource schedule as a delay in a free float. Free float is the amount of time an activity may be delayed without affecting any subsequent activity.

Activities with less than a specified float If any activity has very little float it might use up this float before the regular activity monitoring brings the problem to the project manager's attention. It is common practice to monitor closely those activities with less than, say, one-week free float.



High risk activities A set of high risk activities should have been identified as part of the initial risk profiling exercise. If we are using the PERT three-estimate approach we will designate as high risk those activities that have a high estimated duration variance. These activities will be given close attention because they are most likely to overrun or overspend. Activities using critical resources Activities can be critical because they are very expensive (as in the case of specialized contract programmers). Staff or other resources might be available only for a limited period, especially if they are controlled outside the project team. In any event, an activity that demands a critical resource requires a high level of monitoring.



Unit – 5 SOFTWARE QUALITY MANAGEMENT [9Hrs] TQM, Six Sigma, Software Quality: defining software quality, ISO9126, External Standards, Comparison of project management software’s: dot Project, Launch pad, openProj. Case study:PRINCE2 Total Quality Management (TQM) Competition is getting harder and becoming global. Companies now have to be more responsive, offer a better product and keep improving. Total quality management (TQM) increases customer satisfaction by boosting quality. It does this by motivating the workforce and improving the way the company operates. In an increasingly competitive market, firms with a continuous improvement culture and external focus are more likely to survive and prosper. TQM is an approach to improving the effectiveness and flexibilities of business as a whole. It is essentially a way of organizing and involving the whole organization, every department, every activity and every single person at every level. TQM ensures that the management adopts a strategic overview of the quality and focuses on prevention rather than inspection. Objectives of TQM

a) Meeting the customer's requirements is the primary objective and the key to organizational survival and growth.

b) The second objective of TQM is continuous improvement of quality. The management should stimulate the employees in becoming increasingly competent and creative.

c) Third, TQM aims at developing the relationship of openness and trust among the employees at all levels in the organization.

Significance of TQM The importance of TQM lies in the fact that it encourages innovation, makes the organization adaptable to change, motivates people for better quality, and integrates the business arising out of a common purpose and all these provide the organization with a valuable and distinctive competitive edge. Elements of TQM

a) Be customer focused It requires the company to check customers' attitudes regularly and includes the idea of internal customers as well as external ones.

b) Do it right the first time This means avoiding rework, i.e., cutting the amount of defective work.

c) Constantly improve Continuous improvement allows the company gradually to get better.

d) Quality is an attitude Every one has to be committed to quality. That means changing the attitude of the entire workforce, and altering the way the company operates.

e) Telling staff what is going on This involves improved communication. Typically, it includes team briefing.



f) Educate and train people An unskilled workforce makes mistakes. Giving more skills to workers means they can do a wider range of jobs, and do them better. It also means educating staff in the principles of TQM, which is a whole new style of working.

g) Measure the work. Measurement allows the company to make decisions based on facts, not opinion. It helps to maintain standards and keep processes within the agreed tolerances.

h) Top management must be involved If senior management is not involved, the programme will fail.

i) Make it a good place to work Many companies are full of fear. Staffs are afraid of the sack, their boss and making mistakes. There is no point in running a TQM program unless the company drives out fear.

j) Introduce team work Team work boosts employees' morale. It reduces conflict and solves problem by hitting them with a wider range of skills. It pushes authority and responsibility downwards and provides better, more balanced solutions.

k) Organize by process, not by function This element of TQM seeks to reduce the barriers that exist between different departments, and concentrates on getting the product to the customer.

TQM fails because:

a) Top management sees no reason for change. b) Top management is not concerned for its staff. c) Top management is not committed to the TQM programme. d) The company loses interest in the programme after six months. e) The workforce and the management do not agree on what needs to happen.

Six Sigma Analysis Six Sigma seeks to improve the quality of process outputs by identifying and removing the causes of defects. Six Sigma approach is a collection of managerial and statistical concept and techniques that focuses on reducing variation in processes and preventing deficiencies in product. The concept of Variation states “NO two items will be perfectly identical.” In a process that has achieved six sigma capability, the variation is small compared to the range of specification limit. A six sigma process is one in which 99.9999966% of the products manufactured are statistically expected to be free of defects (3.4 defects per million). Six Sigma is a very clever way of branding and packaging many aspects of Total Quality Management (TQM). Sir Bill Smith is the father of Six Sigma. The Characteristics of Six Sigma

a) Statistical Quality Control Six Sigma is clearly derived from the Greek letter (σ), which is used to denote Standard Deviation. Standard Deviation is used to measure variance, which is an important tool for measuring non-conformance as far as the quality of the output is concerned.



b) Fact and Data Based Approach The statistical and methodical aspects of Six Sigma show the scientific basis of the technique. This accentuates an important aspect of Six Sigma that it is fact and data based.

c) Project and Objective Based Focus The Six Sigma process is implemented for an organization’s project tailored to its specifications and requirement. The process is flexed to suit the requirements and conditions in which a project is operating to get the best results. Apart from that, the Six Sigma is also objective based. The management needs some incentive to invest in the Six Sigma process. It is aimed to enhance profitability and to generate financial.

d) The Customer Focus The customer focus is fundamental to the Six Sigma approach. The quality improvement and control standards are based on the explicit customer requirements.

e) Teamwork Approach to Quality Management The Six Sigma process requires organizations to get organized when it comes to controlling and improving quality. Six Sigma actually involves a lot of training depending on the role of an individual in the Quality Management team.

f) Overall Business Improvement Six Sigma methodology focuses on business improvement. Beyond reducing the number of defects present in any given number of products.

g) Remedy Defects/Variability Any business seeking improved numbers must reduce the number of defective products or services it produces. Defective products can harm customer satisfaction levels. Reduced costs equal increased profits. A company implementing Six Sigma principles has to look to reduce costs wherever it possibly can--without reducing quality.

h) Improve Cycle Time Any reduction in the amount of time it takes to produce a product or perform a service means money saved, both in maintenance costs and personnel wages. Additionally, customer satisfaction improves when both retailers and end users receive products sooner than expected. The company that can get a product to its customer faster may win her business.

i) Increase Customer Satisfaction Customer satisfaction depends upon successful resolution of all Six Sigma’s other objectives. But customer satisfaction is an objective all its own.



Six Sigma projects follow two project methodologies : a) DMAIC b) DMADV

DMAIC DMAIC is used for projects aimed at improving an existing business process. The DMAIC project methodology has Five phases:

a) Define b) Measure c) Analyze d) Improve e) Control

a) Define

Define the system, the voice of the customer and their requirements, and the project goals, specifically.

b) Measure Measure key aspects of the current process and collect relevant data.

c) Analyze Analyze the data to investigate and verify cause-and effect relationships. Determine what the relationships are, and attempt to ensure that all factors have been considered. Seek out root cause of the defect under investigation.

d) Improve Improve or optimize the current process based upon data analysis using techniques such as design of experiments, mistake proofing, and standard work to create a new, future state process. Set up pilot runs to establish process capability.

e) Control Control the future state process to ensure that any deviations from target are corrected before they result in defects. Implement control systems such as statistical process control, production boards, visual workplaces, and continuously monitor the process.

DMADV DMADV is used for projects aimed at creating new product or process designs. DMADV project methodology has Five phase:

a) Define b) Measure c) Analyze d) Design e) Verify

a) Define

Define design goals that are consistent with customer demands and the enterprise strategy.

b) Measure Measure and identify CTQs (characteristics that are Critical To Quality), product capabilities, production process capability, and risks.



c) Analyze Analyze to develop and design alternatives.

d) Design Design an improved alternative, best suited per analysis in the previous step

e) Verify Verify the design, set up pilot runs, implement the production process and hand it over to the process owner(s).

Software Quality Quality software is reasonably bug or defect free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. ISO 8402-1986 standard defines quality as “the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs”. There have been several attempts to identify specific product qualities that are appropriate to software. James A. McCall, grouped software qualities into three sets:

a) Product operation qualities; b) Product revision qualities; c) Product transition qualities;

1. Product operation quality factors - Correctness, Reusability, Efficiency, Integrity, Usability. 2. Product revision quality factors - Maintainability, Testability, Flexibility 3. Product transition quality factors - Portability, Reusability, Interoperability (Effort required to couple one system to

another).

Software Quality Management SQM is a management process that aims to develop and manage the quality of software to make sure the product satisfies the user. The goals of SQM is to make sure the product follows regulations and meets quality standards expected by the customer. Software quality managers have to test the product before it is released to the market and they do this by a series of steps called the software cycle in order to reveal and fix bugs before release. Their job is not only to make sure that their software is in good shape for the consumer, but also to encourage the quality culture to everyone and avoid fraud by protecting their software through proper development. The aim of SQM is to manage the quality of Software (QOS) and of its development process. SQM Roles:

a) To ensure that the required level of quality is achieved in a software product. b) To encourage a company – wide “Quality Culture” where quality is viewed as

everyone’s culture. c) To enable in process fault avoidance and fault prevention through proper

development.



ISO 9126 ISO 9126 standard was published in 1991 to tackle the question of the definition of software quality this 13 pages document was designed as foundation upon which further, more detailed standard could be built. ISO 9126 identifies six software quality characteristics:

a) Functionality: which covers the functions that a software product provides to satisfy user needs. Functionality sub characteristics: suitability, Accuracy, Interoperability, Compliance and Security. Compliance refers to the degree to which the software adheres to application related standards or legal requirements. Typically these could be auditing requirement. Interoperability refers to the ability of software to interact with others.

b) Reliability: Which relates to the capability of the software to maintain its level of performance. Reliability sub characteristics: Maturity, Fault Tolerance and recoverability. Maturity refers to frequency of failures due to fault in software more identification of fault more chances to remove them. Recoverability describe the control of access to a system.

c) Usability: Efforts need to use a software. Usability sub characteristics: Understand

ability, Learnability, operability. Understand-ability is a clear quality to grasp, although the definition attributes that bear on the user efforts for recognizing the logical concept and its applicability in our view actually makes it less clear. Learnability has been distinguished from operability. A software tool might be easy to learn but time consuming to use say it uses a large number of nested menus. This is for a package that is used only intermittently but not where the system is used or several hours each day by the end user. In this case learnability has been incorporated at the expense of operability.

d) Efficiency: physical resource used when a software is executed. Efficiency sub characteristics: Time behavior, Resource behavior.

e) Maintainability: Effort needed to the make changes to the software. Maintainability sub characteristics: Analyzability, Changeability, Stability and Testability. Analyzability is the quality that McCall called diagnose ability, the ease with which the cause of failure can be determined. Changeability is the quality that other have called flexibility: the latter name is perhaps a better one as changeability has a slightly different connotation in plain English It implies that the suppliers of the software are always changing it. Stability, on the other hand, does not means that the software never changes, It means that there is a low risk of a modification to the software having unexpected effects.

f) Portability: Availability of the software to be transferred to a different environment. Portability sub characteristics: Adaptability, install ability, Conformance and Replace ability. Conformance is distinguished from compliance relates to those standard that have bearing on portability. The use of a standard programming language common to many software/hardware environment is an example of conformance. Replace ability refers to the factors that give upwards compatibility between old software components and the new ones. Downwards compatibility is specifically excluded from definition.



External Standard (BS EN ISO 9001) Various national and international standards bodies including the British Standard Institution (BSI) in United Kingdom have inevitably become involved in the creation of standards or quality management system. The British standard is now called BS EN ISO 9001:1994. Standards such as the ISO 9000 such as the ISO 9000 series aim to ensure that a monitoring and control system to check quality is in place. An overview of BS EN ISO QMS Requirements. In order for quality management system (QMS) to meet the standard it has to conform to certain requirement which are summarized below:

a) The Management must define and document the policy concerning quality and must ensure that this policy is communicated to all levels of the organization.

b) All Quality control procedures must be documented.

c) All contract to supply goods or services must contain mutually agreed requirements that the developers is capable for delivering.

d) There must be procedures to control and verify the design of the system to be

supplied so that it meets the requirements agreed with customers.

e) There must be procedures to approve design and other documentation.

f) Where components of the system to be supplied to the clients are obtained from third parties there must be procedures to ensure check and maintain the quality of these components.

g) Individuals products must be identifiable as should their components.

h) The process by which the final product is created must be planned and monitored.

i) Inspection and testing must take place during the development phase at its

completion and before delivery. Tests and inspection must also be carried out on the component obtained from third parties.

j) The equipment used in the production process itself must be properly controlled

with respect to quality.

k) The testing status of all components and system must be clearly recorded at all times.

l) Care must be take to ensure that items that are known to be defective or not in

carelessly used.

m) When a defect is detected, measures must be undertaken to remove the defective part and to ensure that the defect does not occur again.



n) Satisfactory procedure must be in place to details with correct handling storage, packaging and delivery of the products.

o) Sufficient records must be maintained to demonstrate that the quality systems

working satisfactorily.

p) The software quality management system must be audited on a regular basis.

q) Servicing and support activities must be subject to the quality management system.

r) The developers must establish appropriate statistical techniques to verify the acceptability of the final product.

TickIT The ISO9000 standard refer to quality management system is general but in the United Kingdom, the department of Trade and Industry (DTI) have formulated the TICKIT standard which give an interpretation of these standards and includes the followings requirements:

a) A detailed development plan is required before development is embarked upon.

b) Change control procedures should be used at all stages of development.

c) Design reviews must take place.

d) The suitability of the design methodology must the reviewed.

e) Progress must be reviewed on a systematic basis.

f) It must be possible to trace back the features of the software design to specification and requirements.

g) Designs must be properly documented.

h) Suitable test plans, specifications and records must be produced.

i) A code of practice must be in place which governs the way the software is developed.

j) The design must be broken down into levels each with identifiable input and outputs

k) Software must be organized into modules.

l) A module must normally performs a single function or a set of related functions.

m) A plan language description must exist for each module



Capability Process Models Rather than just checking that a system is in place to detect faults, a customer might wish to check that a supplier is using a software development methods and tools that are like to produce good quality software. In The United states, an influential capability maturity model (CMM) has be developed at the software engineering institute (SEI), a part of the Carnegie- Mellon University. These levels are defined as. Level 1: Initial: The procedures followed tend to be haphazard. Some project will be successful, but this tends to be because of the skills of particular individuals including project managers. This is no level 0 and so any organization would be at this level by default. Level 2: Repeatable: Organization at this level will have basic project management procedures in place, however, the way an individual task is carried out will largely on the person doing it. Level 3 Defined: the organization have the way in which each task in the software development life cycle is to be done. Level 4 Managed: The product and the processes involved in software development are subject to measurement and control. Level 5 Optimizing: Improvement in procedure are designed and implemented using the data gather from the measurement process.

Table: CMM key process areas



Comparison of project management software’s: dot Project, Launch pad, openProj. dot Project dotProject is a web-based, multi-user, multi-language project management application. It is free and open source software, and is maintained by an open community of volunteer programmers. dotProject was originally developed by Will Ezell at dotmarketing, Inc. to be an open source replacement for Microsoft Project, using a very similar user interface but including project management functionality. Begun in 2000, the project was moved to Sourceforge in October 2001. The project stalled in late 2002 when the original team moved to dotCMS. Subsequently Andrew Eddie and Adam Donnison, two of the more active developers, were granted administration rights to the project. Andrew continued to work on the project until he moved on to Mambo and later Joomla. Adam remains an administrator. In late 2007, the new dotProject team began a major redevelopment using the Zend Framework, with version 3 (dP3) the expected target release to be utilising it. A fork called web2project was initiated at the same time. FEATURES

a) User management b) Email-based remedy ticket system c) Client and company management d) Project listings e) Hierarchical task list f) Contact list g) Calendar h) Discussion forum i) File repository j) Resource-based permissions

dotProject’s core aims are:

a) Consistent and simple user interface b) Project management functionality c) A collaboration tool in a project management environment d) Open access/open source e) Free usage

dotProject is free! dotProject is a volunteer-supported project management software. There is no physical organization supporting this project, as it was developed by a group of volunteers and users. It is currently supported, maintained and managed by this same group. dotProject has undergone some challenging updates, including additions and code changes. They intend to continue this activity ongoing, with the dedication and support of volunteers and users.



Launch pad Launchpad is a web application and website that allows users to develop and maintain software, particularly open-source software. It is developed and maintained by Canonical Ltd. On 21 July 2009, the source code was released publicly under the GNU Affero General Public License. As of January 2013, the Launchpad repository hosts more than 30,000 projects. The domain launchpad.net attracted 1 million visitors by August 2009 according to a Compete.com survey. It has several parts:

a) Answers: a community support site and knowledge base. b) Blueprints: a system for tracking Specifications and new features. c) Bugs: a bug tracker that allows bugs to be tracked in multiple contexts (e.g. in an

Ubuntu package, as an upstream, or in remote bug trackers). d) Code: source code hosting, with support for the Bazaar and Git version control

systems. e) Translations: a site for localizing applications into different human languages.

Launchpad is a collaboration and project management software solution designed to be a unique collaboration and hosting platform for developing software projects. Some of the goals Launchpad was created for are:

Encourage project contribution Develop, endorse and publish software Build communities through teams and mailing lists Improve collaboration with other developers and projects Share cross-project code, bug reports, ideas and translations

Utilizing Launchpad removes the need for external mail hosting and provides users with a single account to manage their involvement in multiple mailing lists. Launchpad mailing lists are user-friendly and team-oriented. They simplify things by allowing teams to manage one central mailing list. All team members are able to subscribe to the team mailing list.

FEATURES

Bugs by email Bug tracking Share bug reports across projects Code hosting and review Direct links to code Mailing lists Blueprint specification tracking Transform patches into fixes Team PPAs Multiple architectures People profiles Team branches Team responsibility



Python library Karma Multi-language Ubuntu package hosting Automatic software updates and distribution Information on publishing your software Commercial project subscriptions Quick and easy account authentication Open to everyone Community support Web services API Launchpad is free to use for open source software projects and is available at a low annual subscription price for all other projects. It can be accessed from anywhere at any time.

openProj OpenProj is an open source project management application that serves over one million users. Microsoft Project is the only other project management application with more users. Many users are selecting this solution over Microsoft Project because it is free and operates on multiple platforms. Network World recognized the application as the Reader’s Choice Open Source Project Management tool in 2009. OpenProj was developed at Projity by Marc O'Brien, Howard Katz and Laurent Chretienneau in 2007. It moved out of beta with the release of Version 1.0, on January 10, 2008. The current version includes (features):

a) Earned Value costing b) Gantt chart c) PERT graph d) Resource Breakdown Structure (RBS) chart e) Task usage reports f) Work Breakdown Structure (WBS) chart

OpenProj is a free and open-source project management software solution that can be operated on several platforms including Unix, Linux, Mac and Windows. The solution offers importing tools, so users can share files Microsoft Project applications. OpenProj supports opening Primavera and Microsoft files. This solution also provides PERT charts and Gantt charts which assist in comparing and scheduling planned budgets and schedules with actual budgets and schedules. OpenProj offers earned value analysis, and existing files can be imported easily from Microsoft Project to OpenProj. OpenProj offers other key features, such as Work Breakdown Structure (WBS) and Resources Breakdown Structure (RBS). WBS enables managers to order and control tasks, while RBS helps in defining the structure of teams, resources and providers.

Case study: PRINCE2

Unit 1 SOFTWARE PROJECT MANAGEMENT CONCEPTS [9Hrs]

Documents

Transcript of Unit 1 SOFTWARE PROJECT MANAGEMENT CONCEPTS [9Hrs]