Software Project Management (CS-042) Unit 1 Notes by: Prof RK Bassi Software Software is a collection of computer programs, procedures,

rules and associated documents and data [IEEE 87]. Another definition of SW is: (a) Computer programs (instructions) that when executed provide desired function and performance, (b) Data structures that enable the program to adequately manipulate information, and (c) Documents that describe the operation and use of information. What is Management? Management involves planning, organizing, staffing, directing, monitoring, controlling, innovating and representing. Project Characteristics What is a Project? - Project is a non-routine planned activity, i.e., if a job is repeated number of times it is not a project. Therefore if some large or complex task is done first time, it will be considered as a project, but if same thing is done repetitively then it will not be considered as project. The Key characteristics of a project are: 1. Non routine tasks are involved 2. Planning is required 3. A project has a specific purpose. It should have a well defined objective or specific product is to be created. 4. Project is temporary. It has a definite beginning & End. It has a predetermined time span. 5. Work is carried out for some one else. It should have a primary sponsor or customer. 6. Work involves several specialisms 7. Work is carried out in several phases. 8. Project requires resources, from various areas. Resources available for the project are constrained. 9. Project is large or complex, and involves uncertainty. Project Benefits 1. 2. 3. 4. 5. 6. Cost reduction and avoidance. Error reduction. Increased flexibility. Increased speed of activity. Improvement of management planning and control. Opening new markets and increasing sales opportunities.

Triple Constraints of a Project Every project is constrained by three main factors. These are Project scope, time and cost. Scope means what the project is trying to achieve. Time or schedule is the time taken to complete a project. Cost is the money required to complete a given project. In the beginning of the project, each of these dimension has a

target. Managing these three constraints involves making trade offs between scope, time and cost. It is rare that a project is completed within the target values of these three parameters. In addition to these three constraints, quality and sponsors satisfaction are the other important factors to be considered for successful completion of a project. One may meet scope, time and cost factors, but do not meet quality standards required by the sponsors. The project will not be taken as successfully completed. Project Management It is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholders needs and expectations from a project. It means that Project Managers must not only try to meet the scope, time, cost and quality of the product, but should endeavour to meet the needs and expectations of the stakeholders. Stakeholders: Stakeholders are the peoples affected by the project activities and those involved in the project. It includes sponsors, project team, support staff, customers, users, suppliers and even the opponents to the project. Stakeholders need and expectations are important from the beginning of the project till its completion. A good project manager must maintain good relationship with the stakeholders. Project Management Life Cycle The Project Life Cycle refers to a logical sequence of activities to accomplish the projects goals or objectives. To reduce the complexity of the system, it is a common practice to divide a project into phases. Project activities are grouped into phases because by doing so, the project manager and the core team can efficiently plan and organize resources for each activity, and also objectively measure achievement of goals and justify their decisions to move ahead, correct, or terminate. It is of great importance to organize project phases into industry-specific project cycles. Why? Not only because each industry sector involves specific requirements, tasks, and procedures when it comes to projects, but also because different industry sectors have different needs for life cycle management methodology. And paying close attention to such details is the difference between doing things well and excelling as project managers. Therefore a project life cycle is a collection of project phases. A project must successfully complete a phase, before moving to next phase. Regardless of scope or complexity, any project goes through a series of stages during its life. There is first an Initiation or Birth phase (called as feasibility), in which the outputs and critical success factors are defined, followed by a Planning phase, characterized by breaking down the project into smaller parts/tasks, an Execution phase, in which the project plan is executed, and lastly a Closure or Exit phase, that marks the completion of the project. Diverse project management tools and methodologies prevail in the different project cycle phases. Brief detail of activities in each of these stages are:

1) Initiation In this first stage, the scope of the project is defined along with the approach to be taken to deliver the desired outputs. The project manager is appointed and in turn, he selects the team members based on their skills and experience. The most common tools or methodologies used in the initiation stage are Project Charter, Business Plan, Project Framework (or Overview), Business Case Justification, and Milestones Reviews. 2) Planning The second phase should include a detailed identification and assignment of each task until the end of the project. It should also include a risk analysis and a definition of a criteria for the successful completion of each deliverable. The governance process is defined, stake holders identified and reporting frequency and channels agreed. The most common tools or methodologies used in the planning stage are Business Plan and Milestones Reviews. 3) Execution and controlling The most important issue in this phase is to ensure project activities are properly executed and controlled. During the execution phase, the planned solution is implemented to solve the problem specified in the project's requirements. In product and system development, a design resulting in a specific set of product requirements is created. This convergence is measured by prototypes, testing, and reviews. As the execution phase progresses, groups across the organization become more deeply involved in planning for the final testing, production, and support. The most common tools or methodologies used in the execution phase are an update of Risk Analysis and Score Cards, in addition to Business Plan and Milestones Reviews. 4)Closure In this last stage, the project manager must ensure that the project is brought to its proper completion. The closure phase is characterized by a written formal project review report containing the following components: a formal acceptance of the final product by the client, Weighted Critical Measurements (matching the initial requirements specified by the client with the final delivered product), rewarding the team. The project team should document their experience on the project and prepare a list of lessons learnt report, releasing project resources, and a formal project closure notification to higher management. No special tool or methodology is needed during the closure phase. Project Management Framework
The project management framework is a set of processes, tools and templates, designed to be used together to manage a project through its lifecycle. Its application is flexible as required for an individual project. The central document of the framework is:

Proposing a Project Project Sponsorship Managing a Project Forming a Project Steering Committee Starting a Project (after approval) Reporting on your Project Project Budget Tracking

Managing Risk on your Project Managing Issues on your Project Task Assignment Agreements Post Implementation Review Benefits Realisation Communications plan

SW Projects Versus other projects 1. SW projects are invisible (progress can not be seen or visualized), 2. They are complex (not easy to design and develop visa-vis other engineering systems), and 3. They have flexibility (SW systems can easily be changed, therefore they are susceptible to large amount of changes). Knowledge Areas for Project Managers Knowledge areas are the areas in which a Project Manager should have competency. There are nine knowledge areas, which a Project Manager should have. Out of these nine knowledge areas, four core areas are scope mgmt(management), time mgmt, cost mgmt, and quality mgmt. These are called as core knowledge areas, because they lead to specific core objectives. Other four facilitating areas are HR mgmt, communication mgmt, risk mgmt and procurement mgmt. Ninth knowledge area, the most important one, is Project Integration mgmt. Brief description of these knowledge areas is given below: Scope mgmt: it involves defining and managing all the work required to successfully complete the project. Time mgmt: it includes estimating the time required for the project, developing acceptable project schedule and ensuring timely completion of the project. Cost mgmt: it consists of preparing and managing the budget of the project. Quality mgmt: it ensures that the project will satisfy stated or implied needs for which it was undertaken. HR mgmt: it is concerned with making effective use of the people involved with the project. Communication mgmt: it involves generating, collecting, disseminating, and storing project information. Risk mgmt: it includes identifying, analyzing, and responding to risks related to the project. Procurement mgmt: It involves acquiring or procuring goods and services that are needed for a project from outside the performing organisation. Project Integration Mgmt: it is an important function of the project that affects and is affected by all other knowledge areas. It involves successfully integrating all the knowledge areas for completion of the project during project life cycle. It ensures that all elements of the project come together at the right time to complete the project. The main processes involved in project integration management include: (a) Project Plan Development, which involve taking the result of other planning processes and putting them together in a document, which is called Project Plan Document. (b) Project Plan Execution, this involves execution of the project as per project plan, and carrying out the activities included in the plan. (c) Overall Change Control, it involves coordination of changes across the complete Project.

Project Integration management, carried out by Project Manager, is considered as the key to overall success of the project. It involves coordinating all peoples, plans and work required for completion of the project. It also requires interface management. It requires identifying and managing the points of interaction between various elements of the project. Number of interfaces increases exponentially as the number of people involved in the project increases. Therefore one of the most important job of Project Manager , who carries out Integration management is to establish and maintain good communication and relationships with all the peoples involved in the project and with stakeholders. Another important point to be kept in view by the Project Manager is that he should consider the project as part of overall organisation structure, and not be limited to just within a project. It must view the project in the context of changing needs of the organisation, and respond to requests from senior management. Therefore Project Integration Management involves integrating the other knowledge areas within the project as well as integrating different knowledge areas outside the project. Therefore a good project plan must be drawn to carry out integration within and outside the project. Project Management relation with other disciplines: A good Project Manager, in addition to the knowledge in the 9 project management knowledge areas, should also have knowledge in general management like organisation behaviour, financial analysis and planning techniques. In addition he should have some knowledge in the application area of the project itself. It means that if a project is in the area of IT, the project manager should also have IT background, for successful completion of the project. Skills for a Project Manager: Lead by example, visionary, technically competent, decisive, good motivator, stand up to upper management when necessary, support team members, encourage new ideas. System View of Project Management A systems philosophy is an overall model for thinking about things as systems. Systems are a set of interacting components working within an environment to achieve certain aim/objective. System Analysis involves defining the scope of the system to be studied, dividing it into component parts, and then evaluating its problems, opportunities, constraints, and needs. The analyst then analyses the system, examines alternative solutions for improving current working of the system, identifies an optimum or a satisfactory solution or action plan, and examines the plan against entire system. Systems Management addresses the business, technological and organizational issues associated with making change to the system. For a successful project management, system approach is a critical factor. Senior managers and Project Managers must identify key business, technological and organizational issues related to each project in order to identify and satisfy key stakeholders and do what is best for the entire organisation. Project management activities Project management is composed of several different types of activities such as: 1. 2. 3. 4. 5. Analysis & design of objectives and events Planning the work according to the objectives Assessing and controlling risk (or Risk Management) Estimating resources Allocation of resources

6. Organizing the work 7. Acquiring human and material resources 8. Assigning tasks 9. Directing activities 10. Controlling project execution 11. Tracking and reporting progress (Management information system) 12. Analyzing the results based on the facts achieved 13. Defining the products of the project 14. Forecasting future trends in the project 15. Quality Management 16. Issues management 17. Issue solving 18. Defect prevention 19. Identifying, managing & controlling changes 20. Project closure (and project debrief) 21. Communicating to stakeholders 22. Increasing/ decreasing a company's workers

Project objectives
Project objectives define target status at the end of the project, reaching of which is considered necessary for the achievement of planned benefits. They can be formulated as S.M.A.R.T.

Specific, Measurable (or at least evaluable) achievement, Achievable (recently Acceptable is used regularly as well), Realistic and Time terminated (bounded).

The evaluation (measurement) occurs at the project closure. However a continuous guard on the project progress should be kept by monitoring and evaluating. Categorisation of Projects or Project Characteristics Information systems versus embedded systems: in information system the system interfaces with the organization or carries out its work. In Embedded systems it interfaces with a machine. Projects could be for real time systems, avionics, pay roll, inventory management, resource planning, power control systems etc. Objective versus products: whether it produces a product or meets certain objectives. Management of Software Engineering The main job of management is to enable a group of people to work towards a common goal. It is standard to consider management comprising following five functions:

Planning A manager must decide what objectives are to be achieved, what resources are required to achieve the objective, how and when the resources are to be acquired, and how the goals are to be achieved. Planning basically involves determining the flow of information, people, and products within the organization. Organisation: Organisation involves the establishment of clear lines of authority and responsibility for group of activities that achieve the goal of the enterprise. Organisation is necessary at the level of small group, such as a five person team of software engineers, all the way up to a large corporation composed of several independent divisions. The choice of the organizational structure affects the efficiency of the enterprise. Clearly, the best organizational structure can be devised only when the goals of the enterprise are clear, and this depends on effective planning. Staffing. Staffing deals with hiring personnel for the positions that are identified by the organizational structure. It involves defining requirements for personnel; recruiting (identifying, interviewing, and selecting candidates); compensating, developing, and promoting employees. Directing: Directing involves leading subordinates. The goal of directing is to guide the subordinates to understand and identify with the organizational structure and the goals of the enterprise. This understanding must be continuously refined by effective and exemplary leadership. Setting examples is especially important in software engineering, where measures of good engineering are lacking. The best training for a beginning engineer is to work alongside a good engineer. Controlling Controlling consists of measuring the correcting activities to ensure that goals are achieved. Controlling requires the measurement of performance against plans and taking corrective action when deviations occur. Elements of Project Planning 1. Describing the project scope, alternatives, and feasibility. 2. Dividing the project into manageable tasks. 3. Estimating resources and creating a resource plan. 4. Developing a preliminary schedule. 5. Developing a communication plan. 6. Determining project Standards and Procedures. 7. Identifying and assessing risk. 8. Creating a preliminary budget. 9. Developing a Statement of Work (SOW). 10. Setting a baseline project plan. Stepwise Project Planning

During project planning number of activities are to be carried out. The project to be handled is large and complex, therefore it is broken down in number of phases/ steps / activities for easier and better control / monitoring and reducing the complexity of activities. The steps are shown in figure given below :

0. Select project

1. Identify project scope and objectives

2. Identify project infrastructure

3. Analyse project characteristics

Review

4. Identify the products and activities

Lower level detail

5. Estimate effort for each activity

for each activity

6. Identify activity risks

10. Lower level planning

7. Allocate resources

9. Execute plan

8. Review/ publicize plan

1. Project Scope and Objectives The purpose of this activity is to develop a clear understanding of the content and complexity of the project. Scope is very important, since it draws the boundary of the system to be engineered and delivered. The objectives are clearly defined and written down. It should include what problems and opportunities does this project address, business needs that sparked the project, characteristics of the product or services which this project will produce, the quantifiable results to be obtained, what are the deliverables, what needs to be done, how will success be measured and how will we know when we have finished. Cost, schedule and quality measures are established. Deliverables may include WBS (work breakdown structure). During this step we also establish a Project Authority, so that there is unity of purpose among all those involved. We must also identify the stakeholders in the project and their interests, and if required the objectives could be modified based on their inputs and analysis. During this step, methods of communication with all parties are also established. The communication procedures among management, project team members and customer are established. 2. Identify Project Infrastructure: It includes identifying relationship between the project and strategic planning, identifying installation standards and procedures which includes change control procedures, configuration management, quality standards and procedures, project planning and control standards, and identifying project team organization. 3. Analyse Project Characteristics: Distinguish the project as either objective- or product driven, analyse other project characteristics and identify high level project risks, take into account user requirements concerning implementation, select general life cycle approach based on above analysis and review overall resource estimates. 4. Identify Project Products and Activities: Identify and describe project products /deliverables, document generic product flows, recognize product instances, produce ideal activity network then modify ideal to take into account need for stages and checkpoints. 5. Estimate effort for each activity: Carry out bottom up estimates and revise plans to create controllable activities. 6. Identify activity risks: Identify and quantify activity based risks, plan risk reduction and contingency measures wherever required, and adjust plans and estimates to take into account risks. 7. Allocate resources it includes identification and allocation of resources needed for various activities of the project The staff available for different activities is identified and allocated. For tasks provisionally. It will also include revision of plan and estimates taking into account resource constraints. 8. Create a preliminary budget 9. Review /publicize plans plan is reviewed by stakeholders, and if any changes required the steps 5 to 8 are repeated till the project is approved by stakeholders., this step includes review of quality aspects of the plan. Once the plan is approved it is publicized, and all concerned informed. 10. Developing a statement of works (SOW). 11. Execute plan and lower levels of planning. Project Plan After the Project Analysis is over a Project Plan is prepared. This document is used to coordinate all project planning documents and help guide a projects execution and control. It also documents project planning assumptions and decisions regarding choices, facilitate communication amongst stakeholders, define the content, extent and timing of key management reviews, and provide a baseline for project progress measurement and project control. Plan should be dynamic, flexible, and subject to change

depending on the project environment. It should assist the project manager in leading the project team, execute the project and assessing project status. Size of Project Plan will vary as per the size of the project. Therefore it should be drawn to fit all the needs of a project. It should guide the work to be carried out , and accordingly the details in a plan are needed. The contents of a Project Plan as per IEEE Std 1058.1-1987 are: 1. Introduction: Project overview; project deliverables; evolution of SW Project Management Plan; reference material; and definitions and acronyms. It will contain project name, brief description of the project giving the goal and the need it addresses. In it give rough estimate of time and cost. Give name of sponsors, project manager and key team members and contact information. It will have list of SW products, technical reports, training materials etc. to be delivered as part of the project. It will also have list of important reference material such as history of related projects, plans produced for other knowledge areas such as scope mgmt, schedule mgmt, cost mgmt, quality mgmt, staffing mgmt, communication mgmt, risk mgmt and procurement mgmt. It will contain list of definitions and acronyms unique to that project, industry or technology. 2. Project Organisation: Process model; organizational structure; organizational boundaries and interfaces; and project management responsibilities. It will have organizational chart of the company sponsoring the project and the customers company, project organizational chart showing line of authority, responsibilities and communication for the project. It should describe major functions and activities and identify those responsible for them. It will also include documents in respect of other process related information. 3. Management Process: Management objectives and priorities; assumptions, dependencies, and constraints; risk management; monitoring and controlling mechanisms; and staffing plan. It will include views of senior management of the project, priorities and major assumptions/constraints for the project. It will also describe how to monitor project progress, handle changes, carry out control by having monthly/ quarterly review/progress meetings. How the risks are identified, managed and controlled, and if a risk management plan is required for the project. It will give details of staff for the project. 4. Technical Process: Methods, tools, and techniques: software documentation; and project support functions. This section has specific methodologies a project might use and how the information is to be documented. 5. Work Packages, Schedule, and Budget: Work packages; dependencies; resource requirements; budget and resource allocation; and schedule. It will details of work packages, WBS and a Statement of Works (SOW) to describe the work in detail. This should briefly summarize the main work packages for the project and refer to appropriate section of the scope management. It will include key deliverables and their quality requirements. It will have other work related information about the project, type of HW/SW used. It will include summary schedule and detailed schedule and summary budget and detailed budget, and other schedule/budget related information. Technical Plan for the project will have following 1. Introduction and summary of constraints: (a) Characteristics of system to be developed. (b) Risks and uncertainties. (c) User requirement concerning implementation.

2. Recommended approach: (a) Selected methodology or process model. (b) Development methods. (c) Required SW tools. (d) Target HW/SW environment. 3. Implementation: (a) required development environment. (b) Required maintenance environment. (c) Required training. 4. Implications: (a) project products and activities- these will have an effect on the schedules duration and overall project effort. (b) Financial- this report will be used to produce costing. Project management tools and technique help/assist in monitoring, managing and controlling the project core knowledge areas. Requirement Specification defines the project objectives in terms of functional requirements (tells what the system is supposed to do at the end of project), quality requirements(response time, reliability, ease of use) and resource requirements. Problems with SW Projects Poor estimates and plans, lack of quality standards, lack of guidance about making organizational decisions, lack of techniques to make project visible, poor definition of role of persons, incorrect success criteria, inadequate specifications, management lacks IT knowledge, lack of knowledge of application area, lack of standards, lack of up to date documentation lack of communication between project team members, lack of personnel commitments, changing SW environments, pressure of deadlines, lack of quality control, lack of training and management by remote control. Programme management A programme is a group of projects that are managed in a coordinated way to gain benefits that would not be possible were the projects to be managed independently. Programmes can exist in different forms as given below.

Strategic programmes : Several projects together can implement a single strategy.

Business cycle prorammes The collection of projects that an organization undertakes within a particular planning cycle is sometimes referred to as a portfolio. Many organizations have a fixed budget for ICT development. Decisions have to be made about which projects to implement within that budget within the accounting period, which often

coincides with the financial year. If expenditure on one project is delayed to a later year, then this could release resources for some other project. On the other hand, if a project absorbs more resources than expected, then this could be at the expense of other projects. Planners need to assess the comparative value and urgency of projects within a portfolio. This is straightforward if external circumstances such as the adoption of the euro dictate the priorities. However, balancing the relative needs of different groups of users can become very political. Often the projects in the portfolio have to compete for a share of common pools of resources, such as terms of software developers. The allocation of available staff between projects poses particular problems,

Infrastructure programmes In a local authority, one department might have responsibilities for the maintenance of highways, another for refuse collection, and another for education. These distinct activities will probably require distinct databases and information systems. However, other applications, such as those to do with accounting cross over these boundaries. In such a situation, the central ICT function would have responsibility for setting up and maintaining the ICT infrastructure, including the networks, workstations and servers, upon which these distinct applications run. A uniform infrastructure would allow the sharing of applications between departments where that was desirable, and would make life easier for the central ICT function, as it would allow the bulk purchasing of equipment and the development of expertise for standard products. In these circumstances, a programme would refer to the activities of identifying a common ICT infrastructure and its implementation and maintenance.

Research and development programmes Truly innovative companies, especially those that are trying to develop new products for the market, are well aware that projects will vary in terms of their risk of failure and the potential returns that they might eventually reap. Some development projects will be relatively safe, and result in the final planned product, but that product might not be radically different from existing ones on the market. Other projects might be extremely risky, but the end result, if successful, could be a revolutionary technological breakthrough that meets some pressing but previously unsatisfied need.

The risks associated with an innovative project will fluctuate. Research work may lead to technological breakthroughs or to the discovery of insurmountable problems, so the portfolio of projects needs to be reviewed on a regular basis. Innovative partnerships

Some technological developments, if handled properly, benefit whole industries. Often, technological products can only be exploited if they inter-operate with other products. Companies therefore often come together to work collaboratively on new technologies in a pre-competitive phase. Separate projects in different organizations need to be coordinated and this might be done as a programme. 1. Strategic programme management

A different form of programme management is where a portfolio, of projects all contribute to a common objective. A business objective might require changes to a number of different systems which until now have been largely self-contained. The work to reorganize each individual area could be treated as a separate project, coordinated at a higher level as a programme. These types of programme are most often needed by large organizations which have a large and complicated organizational structure. Government departments are typical examples. 2. Creating a programme

The programme mandate The OGC envisages that the planning of a programme will be triggered by the creation of an agreed programme mandate. This should be a formal document describing: The new services or capabilities the programme should deliver; How the organization will be improved by use of the new services or capability; How the programme fits with corporate goals and any other initiatives.

At this point, a programme director ought to be appointed to provide initial leadership for the programme. The programme brief A programme brief is now produced which would be the equivalent of a feasibility study for the programme. It will have sections setting out: A preliminary vision statement which describes the new capacity that the organization seeks it is described as preliminary because this will later be elaborated; The benefits that the programme should create-including when they are likely to be generated and how they might be measured; Risks and issues; Estimated costs, timescales and effort.

The vision statement

The programme brief should have given the sponsoring group enough information to decide whether it is worth moving to a more detailed definition of the programme. This next stage will involve a lot of detailed planning work and would justify the setting up of a small team. This group can now take the vision statement outlined in the project brief and refine and expand it. It should describe in detail the new capability that the programme will give the organization. If estimates for costs, performance, and service levels cannot be provided, then there should at least be an indication of how they might be measured. For example, the headings under which costs will be incurred can be recorded. Similarly, for performance, one might be able to say that repeat business will be increased, even if the precise size of the increase cannot be provided. The blueprint The achievement of the improved capability described in the vision statement can only come about when changes have been made to the structure and operations of the organization. These are detailed in the blueprint. This should contain: Business models outlining the new processes required; Organizational structure-including the numbers of staff required in the new systems and the skills they will need; The information systems, equipment and other, non-staff, resources that will be needed; Data and information requirements; Costs, performance and service level requirements.

The blueprint will need to be supported by benefit profiles which estimate when the expected benefits will start to be realized following the implementation of the enhanced capability. 3. Aids to programme management

Dependency diagrams There will often be physical and technical dependencies between projects. For example, a project to relocate staff from one building to another might not be able to start until a project to construct a new building has been completed. Dependency diagrams, which are very similar to activity networks at project level, can be used to show these dependencies. Where projects run concurrently in a programme and pass products between one another, the dependency diagrams could become very quite complicated. . Figure given below shows a dependency diagram for this programme after merger of two organizations, the constituent parts of which are explained below.

Corporate image design

G Implement Corporate interface E Training

A System study/design

C Build Common Systems

F Data migration

D Relocate offices

Figure: An example of a dependency diagram

A. Systems study/design

A project is carried out which examines the various existing IT applications in the two old organizations, analyses their functionality, and makes recommendations about how they are to be combined

B. Corporate image design: Independently of Project A, this project is designing the corporate

image for the new organization. This would include design of the new logo to be put on company documents.
C. Build common systems: Once Project A has been completed, work can be triggered on the

construction of the new common ICT applications.

staff in the two former organizations. In this scenario, this has to wait until the completion of Project A because tht project has examined how the two sets of applications for the previous

organizations could be brought together, and this has repercussions on the departmental structure of the new merged organization.
E. Training

Once staff has been brought together, perhaps with some staff being made redundant; training in the use of the new systems can begin. When the new, joint, applications have been developed and staff have been trained in their use, data can be migrated from existing data-bases to the new consolidated database. Before the new applications can go lve, the interfaces, including the documentation generated for external customers, must be modified to conform to the new company image.

F. Data migration

G. Implement corporate interface:

4. Benefits management define the expected benefits from the programme; analyse the balance between costs and benefits; plan how the benefits will be achieved and measured; allocate responsibilities for the successful delivery of the benefits; monitor the realization of the benefits.

Benefits can be of many different types, including; Mandatory compliance Governmental or European legislation might make certain changes mandatory.

Quality of service an insurance company, for example, might want to settle claims by customers more quickly. Productivity The same, or even more, work can be done at less cost in staff time.

More motivated workforce This might be because of an improved rewards system, or through job enlargement or job enrichment. Internal management benefits(for instance, better decision making) To take an insurance example, again, better analysis of insurance claims could pinpoint those categories of business which are most risky and allow an insurance company to adjust premiums to cover this.

Risk reduction The insurance example might also be applicable here, but measures to protect an organizations networks and databases from intrusion and external malicious attack would be even more pertinent. Economy The reduction of costs, other than those related to staff-procurement policies might be put in place which encourages the consolidation of purchasing in order to take advantage of bulk-buying at discount. Revenue enhancement /acceleration The sooner bills reach customers, the sooner they can pay them. Strategic fit A change might not directly benefit a particular group within the organization but has to be made in order to obtain some strategic advantage for the organization as a whole.

Quantifying benefits Benefits can be: Quantified and valued-that is, a direct financial benefit it experienced; Quantified but now valued-for example, a decrease in the number of customer complaints; Identified but not easily quantified-for example, public approval of the organization in the locality where it is based. Can you explain in precise terms why this benefit should result from this business change? Can you identify the ways in which we will be able to see the consequences of this benefit? If the required outcomes do occur, can they be attributed directly to the change, or could other factors explain them? Is there any way in which the benefits can be measured?

SW Effort Estimation Most of the SW projects are delayed or have cost overruns. Problem is because it is difficult to have proper SW project effort estimates or realistic estimates. Estimating SW effort realistically is not an easy job since SW is inherently complex and invisible, and is largely dependent on human capability. Other problems with SW effort estimation are (a) Novel application of SW- most of the time SW is developed for a new application and not for already developed applications. (b) SW technology is changing very rapidly, (c) lack of homogeneity of project experience, (d) subjective nature of estimating, (e) political implications. When are estimates done?

Estimates are carried out during following stages of system engineering: Strategic planning, feasibility study, system specification, evaluation of suppliers proposals, project planning, Problems with over estimation and under estimation Problem With Over Estimation If project team knows the estimate, it will influence the project implementation time. An over estimate might cause the project to take longer than it would otherwise take. This can be explained by Parkinsons law and Brooks law. Parkinsons law states that work expands to fill the time available. Which means that the staff will work less hard or with less efficiency if the target is easy. Moreover, the effort required to implement a project will go up disproportionately with the number of staff assigned to the project. As the project team grows in size so will the effort that has to go into management, co-ordination and communication. This as stated by Brookes law putting more people on late job makes it later. If there is an over estimate of the effort required, then this might lead to more staff being allocated for the project, which will increase overheads and the project will take longer time. Problem with Under Estimation Danger with under estimation is that it might affect quality. Staff, especially those with less experience, might respond to pressing deadlines by producing substandard product. If we look at Weinbergs zeroth law of reliability; if a system does not have to be reliable, it can meet any other objective. Which means that if there is no need for a program to work, then it can meet any programming dead line that might be set. Sub-standard work may become visible only at a later date during testing phases of a project, which are difficult to control and extensive rework may have catastrophic effect on project cost and time. Basis for SW estimation The need for Historical Data most of the estimating methods need data about previously carried out projects to make estimates for new projects. New environments for the project such as programming language, SW tools, standards etc are to be taken into account while considering data of old projects. Measure of Work- work required can be measured by considering SLOC or KLOC or function points. Complexity two programs may have same SLOC but may have different complexity, therefore while taking into account SLOC for SW effort estimation, complexity factor should also be taken into account to get accurate estimate of effort and time required. SW Effort estimation Techniques 1. Algorithmic models- these models use effort drivers representing characteristics of the target system and the environment to predict effort. Constructive Cost Model (COCOMO) is one such parametric model developed by Boehm. 2. Top down- effort required for the complete project is calculated, and then broken down into effort required for component tasks. 3. Bottom up individual component sizes are calculated, and then added up to calculate total effort for the project.

4. Analogy a similar old project is identified, and its actual effort is used as a basis to calculate effort for new project. 5. Expert Judgment- advice of knowledge/experienced staff is taken to estimate the effort. 6. Parkinson- it identifies the staff effort available to do the project, and uses that as estimate. 7. Price to Win where the estimate is a figure, very low to win the contract. Bottom Up Estimating In this approach , estimator breaks the project into smaller component, and estimate is made of the effort required to carry out these tasks. With a large project, the process of breaking down into smaller tasks is repetitive one. The breaking down continues till we reach to the stage where a task can be carried out by a single person in week or two. The reason for calling this approach as bottom up is that the effort required to carry out each task is calculated, and then total effort calculated by adding up all these subtasks efforts. The bottom up approach will be appropriate at the later/more detailed stage of project planning. If it is carried out in the early stage, a number of assumptions will have to be made about the number and size of modules. This approach is most appropriate when a project is novel or there is no historical data available for the project. Top Down Estimation This approach is adopted normally for parametric or algorithmic models. The effort needed for a project will be related mainly to the characteristics of the final system. Normally the formula used to calculate effort for this model will be: Effort = system size * productivity rate System size could be in KLOC or Number of FPs, whereas productivity rate in no. of days per KLOC. This will give effort in number of days. Therefore for this model, first effort is to calculate size and next is to calculate productivity. Some parametric models such as FP are more focused on system or task size, whereas others like COCOMO are more concerned with productivity factors. After calculation of total effort, the next step is to calculate effort for components or subtasks within that project. For example, after calculating total effort required for a SW development project, we find the percentage of effort, of system effort, required for system requirement, design, coding etc as percentage of total effort. Then we calculate effort for each of these stages. Estimating by Analogy- This is also called as Case-Based reasoning. In this method the estimator first finds out efforts for various projects completed earlier and have characteristics similar to the new project to be undertaken. For example suppose we have earlier completed two projects proejct1 and project2, and the parameters of these two projects are no. of inputs, outputs, no. of files etc. These two earlier projects have characteristics similar to the characteristics required in the new project (target project). Then we find no. of similar parameters (input, output etc.) in the new project, and calculate Euclidean distance between each source project parameter and similar target project parameter for all parameters. The formula used is: Euclidean Distance1 = square root of ((target param1- project1 param1) 2 + (target param2 project1 param2) 2 + ----)) Euclidean Distance2 = square root of ((target param1- project2 param1) 2 + (target param2 project2 param2) 2 + ----))

The source project for which Euclidian distance is shortest from target project is deemed to be closest match. Therefore it is concluded that target project effort will be nearer to the effort for project having minimum Euclidean distance. Advantage of this method is that it is very easy and simple way of estimating project effort. Problem in this method is how to actually identify the similarities and differences between the systems. Albrecht Function Point analysis: This is a top down method given by Allan Albrecht, while he was working with IBM. In this approach it is assumed that each program comprises five basic component types, these are external input types, external output type, logical internal file type, external interface file types and external inquiry type. External inputs are input transactions which update internal computer files. External output types are transactions where data is output to the user, such as screen displays, print outs, etc. Logical internal files are the standing files used by the system. Files refer to a group of data that are accessed together. External interface file types refer to the output and input that might pass to and from other applications. External inquiry types are transactions initiated by the user that provide information but do not update internal files. Only unique input and outputs are considered. We have to first determine the different unique instances of different user types. The count of each external use type in each complexity band is calculated These external user types are divided into low, average and high, and are allotted different weightages. For these external user types, multiplier counts for low, medium and high type of the user types are found depending on the type of function and then Function Points are calculated. Albrecht complexity multipliers External user type Multiplier ------------------------------------------------------------------------Low Average High 3 4 7 5 3 4 5 10 7 4 6 7 15 10 6
j th

External input type External output type Logical internal file type External interface file type External inquiry type
i =5 j =3 i =1 j =1

UFP = wij Cij Where: i is the row, and j is column, wij is the entry in the i th row and

column in the table, and Cij is the count for the i th row user type and having complexity corresponding to j th column. After calculating UFP ( Unadjusted FP), it is adjusted for environment complexity for which 14 factors are taken. These 14 factors are data communication, distributed processing, performance objectives, operation configuration load, transaction rate, on-line data entry, end user efficiency, on-line update, complex processing logic, re-usability, installation ease, multiple sites, and desire to facilitate change. The degree of influence of each of these factors is taken to be from 0 to 5, representing 6 different levels. These are: 0 not present, 1 insignificant influence, 2 - moderate influence, 3 - average influence , 4 significant influence, and 5- strong influence. These 14 degree of influence are then summed up giving a total of N. Value of N will lie between 0 and 70. Using N we calculate complexity adjustment factor:

CAF = 0.65 + 0.01*N and final FP will be: FP = CAF * UFP FP are extensively used for size calculation of SW. Studies have been conducted to correlate function point to size of SW. This is given below: --------------------------------------------------------------------------------------------------------------------Language SLOC per UFP Language SLOC per UFP Language SLOC per UFP --------------------------------------------------------------------------------------------------------------------Assembly 320 C 128 FORTRAN 77 105 COBOL 85 91 Ada 83 71 C++ 56 Ada 95 55 Java 55 Visual Basic 35 --------------------------------------------------------------------------------------------------------------------The drawback of function point calculation is that it is highly subjective. Therefore now International FP User Group (IFPUG) has laid down certain guide lines for taking the five user types as low/simple, average or high/complex. It depends on the number of data types and file types accessed for input and output, and number of record types and data types for logical files. Function Point Mark II: Under this number of Input data element, output data element and entity type are found out. Each type is given a predefined weight. ( wi = 0.58, wo = 0.26, and we = 1.66). It also uses technical complexity adjustment factors. In addition to 14 factors used by Albrecht, it has five more factors. These are: interfaces to other applications, direct access for third parties, special security features, user training features and documentation requirements. Object Points: This approach uses count of screen, reports, and 3GL components as objects. Then points for these objects are determined as simple, medium or difficult. For each of these complexity factors weighting factors are taken to calculate total object points. COCOMO Parametric model: This parametric model was defined by Boehm and has three system types, organic, semidetached and embedded. Organic systems are simple systems to be developed and on which organisation has previous experience, whereas Embedded systems are complex systems such as avionics, real time systems, operating systems etc on which the company does not have much previous experience. Semidetached systems are in between systems. First model of Boehm was called simple model, and this model did not have any effort multipliers. Second model of Boehm was called Intermediate model, and had 15 effort multipliers. Each system has its own formula to calculate the effort based on size (KLOC). Intermediate model, the most commonly used model, has 15 cost drivers grouped into four categories, viz., product attributes(3 reliability(RELY), complexity (CPLX) and database size (DATA) ); computer attributes(4) execution time constraint (TIME), main storage constraint (STOR), virtual machine volatility (VIRT), computer turn around time (TURN); personal attributes(5 - analysts capability (ACAP), application experience (AEXP), programmer capability (PCAP), virtual machine experience (VEXP), programming language experience (LEXP)); and project attributes (3 - use of modern programming languages (MODP), use of SW tools (TOOL) and development schedule (SCED)). Each factor had ratings viz., very low, low, nominal, high, very high and extra high. The multiplying factors for all the cost drivers are taken and multiplied to get a multiplying factor M f . Depending on the type of system, initial effort for a project is calculated as per given formula based on KDLOC. The initial effort is

then multiplied by M f to get Total or Actual Effort. Based on the effort , the time required for the project can then be calculated. Knowing the percentage of total effort or time an activity or sub task will take, one can calculate effort and time for sub tasks. COCOMO Intermediate Model As per COCOMO Intermediate model, effort & time equations for different systems are: Organic systems:
Ei = 3.2( KDLOC

)1.05 PM,

where Ei is the initial effort without taking into account the 15 multiplication factors. KDLOC is the kilo developed lines of code. If developed lines of code is 100000, KDLOC will be equal to 100. If M f is the multiplication factor taking into account all the 15 adjustment/multiplication factors, then the actual effort E will be given by: E = M f Ei in PM (persons month) Average duration or time for the Organic systems in months is given by : T = 2.5E 0.38 M (months) 1.12 Ei = 3.0( KDLOC ) Semidetached systems: PM and E = M f Ei PM (persons month) Average duration or time for the Semidetached systems in months is given by : T = 2.5E 0.35 M (months) Embedded systems:
E i = 2.8( KDLOC
E = M f Ei

)1.20 PM and

PM (persons month) Average duration or time for the Embedded systems in months is given by : T = 2.5E 0.32 M (months) COCOMO II In 2000, Boehm and his team have come out with third model called as COCOMO II, it takes into account the latest technology being used in SW development and project management. This model offers a means of processing all the project characteristics to construct a SW estimate. This model introduces two more capabilities. One of them is phase sensitive effort multiplier: Some phases (design, programming, integration/test) are more affected than others by factors defined by cost drivers. The detailed model provides a set of phase sensitive effort multipliers for each cost driver. This helps in determining man power allocation for each phase of the project. Estimates are required at different stages in the system life cycle, and COCOMO II has been designed to accommodate this by having models for three different stages. These are: Application composition: this is the early part of life cycle with lot of external features of the system coming into considerations. In this stage Object Point analysis is carried out for effort evaluation.

Early Design stage: in this stage fundamental SW structures are designed, and requires careful attention in large projects. In this stage 7 design effort multipliers are taken into account. Function Points are used to calculate the effort Post Architecture: In the last/third stage which is called as post architecture, 17 effort multipliers are taken into account. These are product attributes(5), platform attributes(3), personnel attributes((6) and project attributes(3). Function Points converted into KDLOC are used to calculate the effort. In this stage the estimates will be best. In both Early Design and Post Architecture, the formula for effort calculation is: Effort = 2.45 xsize sf xem 1 xem 2 x... xem n PM ; where: sf is the scale factor, em are effort multipliers. As mentioned earlier for early design stage there are 7 effort multipliers (em), and for post architecture there are 17 effort multipliers (em). Scale factor is given by:
sf =1.01 +0.01 (exp onent

driver ratings)

There are five exponent drivers, each has value between 0 to 5. In case of exponent drivers the value is large if the exponent driver applicability is less. Which means that lack of quality increases the effort. The five drivers are: 1. Precedentedness: It refers to the degree to which there are similar precedents, similar cases in the past, for the project being planned. Greater the novelity of the new system, more effort required. Therefore value of exponent driver will be higher. 2. Development flexibility: this is the degree of flexibility available to complete the project in different ways. More flexible means less effort or higher value. 3. Architecture/risk resolution: it relates to the degree of uncertainty about the project. If Requirements are not firm, uncertainty is more and effort more, therefore high value to effort driver. 4. Team cohesion: it reflects the degree to which there is large dispersed team ( in several place) as opposed to a small team at one location. 5. Process maturity: it depends on the process maturity level (CMM) of the organisation. Higher CMM means less effort or small exponent driver.
The 7 effort multipliers during Early Design are: Product reliability and complexity, required usability, platform difficulty, personnel capability, personnel experience, facilities available, and schedule pressure. Their values varies between 0.5 to 1.5. The 17 effort multipliers during post architecture are: Product attributes: required SW reliability, database size, documentation match to life cycle needs, product complexity, and required reusability. Platform attributes: execution time constraint, main storage constraint and platform volatility. Personnel attributes: Analyst capability, application experience, programmer capability, platform experience, programming language experience, and personnel continuity. Project attributes: Use of SW tools, multi-site development, schedule pressure

Another interesting upgrade in COCOMOII is the schedule estimating equation, which is now a function of both the effort estimate and the process parameters. The resulting impact of a better process is a reduction in both effort and schedule. Overall COCOMOII is a good improvement over conventional cost models, many of which are grossly out of date. It is a good match for iterative development, modern technology, and the modern process.