1) Introduction to Project Management

Transcription

1 1) Introduction to Project Management a) Project: A temporary endeavour consisting of a series of activities and tasks undertaken to create a unique product or service. b) Project Management: The application of knowledge, skills, tools, and techniques to project activities to complete the project. It involves project planning, organising, staffing, directing, monitoring, controlling, innovating, and representing. c) Project Manager: Develops a plan through which the project can be tracked and controlled to ensure the project meets preset objectives. He is responsible for organising, staffing, budgeting, directing, planning and controlling the project. d) Characteristics of Software Development Projects: i) Invisibility: It is difficult for project managers to assess real progress on the project, as the project is intangible. ii) Complexity: Per dollar, software products contain more complexity than other engineered artefacts. iii) Conformity: Software developers have to conform to the requirements of human clients, organizations, etc. with diverse opinions. iv) Flexibility: Software projects have the strength of flexibility to accommodate a lot of changes. e) Project Stakeholders: The people who have a stake or interest in the project. i) Internal to the Project Team: under the direct managerial control of the project leader ii) External to the project Team (Same organisation): people and the departments from whom the project team may need assistance. iii) Totally External to the Organisation: The customers (or users) who will benefit from the system that the project implements; or contractors who will carry out the project work. f) Project Proposal: is a summary of development decisions based on the client s information, the project manager s experience, and the discussions held amongst the project team about the possible alternative treatments for the project. i) Characteristics of Project Proposal: (1) General introduction and executive summary (2) Statements of what the client and users want from the project (3) Description of the general treatment and reasons for choice along with possible variations, if any. (4) Outline diagram of the proposed structure (5) Description of the human/non human resources needed (6) Work breakdown and schedule structure (7) Cost/Payment structure (8) Limitations of the proposal g) Contract: An agreement between two parties (a client and a contractor) defining their benefits and responsibilities. The contract comes into the picture after the client is satisfied and agrees with the proposal. h) Project management information system (PMIS): helps in diagramming, scheduling, and tracking all the tasks present in a project. It enables the project manager and project team members to plan the project, assess its progress, etc. i) Microsoft Project: helps to put together a plan of action, fill in and organise all the details that must be completed in order to achieve the project s goal. The software handles all the activities right from building a new project to preparing project documentation, tracking progress, analysing costs, assessing the quality of the project and managing multiple projects. Status of tasks, resources, costs, etc. can be easily monitored by generating respective reports, graphs, etc. Page 1

2 i) Project Life Cycle: is a systems approach to a project where the project is described as passing through four (4) to six (6) phases from initiation to termination. i) The project life cycle is extremely useful for project managers: because it helps them to define the level of effort needed to perform various tasks associated with each stage. ii) 4 Phase Project Life Cycle: (1) Initiation (Conceptualisation): Top managers determine that a project is necessary. Preliminary goals and alternative approaches are specified, as well as possible ways to accomplish these goals. (2) Planning: Establishment of formal plans to accomplish the project s goals. Activities include scheduling, budgeting, and allocation of other specific tasks and resources. (3) Execution: This is the actual work of the project. This is where effort is most required. Materials and resources are procured, the project is produced, and performance capabilities are verified. (4) Termination: Final activities that must be performed once the project is completed. These include releasing resources, transferring the project to clients, and, if necessary, reassigning project team members to other duties. iii) 6 Phase Project Life Cycle: (1) Concept: Investigation of technology, feasibility studies, survey of competition. (2) Definition: Specification of objectives, establishing targets, quality assurance procedures, set up control system, establishes project organization. (3) Design: Architectural and engineering, design reviews, assessment reports, revise cost and performance targets. (4) Construction: (Most effort expended), first units, begin sales campaign, quality control procedures. (5) Application (Installation): Install and field test, begin de staffing, advertising begins, debug and redesign. (6) Post Completion: Final de staffing, post mortem analysis, final reports, closeout. iv) Advantages of Project Life Cycle: (1) Project managers do not have to re invent the wheel for each new project. (2) Senior management and steering committee groups will be able to compare projects meaningfully. (3) Project reporting and terminology can be consistent in terms of the phases and review points. (4) Expertise can be built up with respect to the estimating techniques and past performances. (5) Standard project plans can be built up in tools especially, which need only slight modification to provide a solid, comprehensive plan for a new project. v) Activities that overlap with the entire project life cycle. (1) People management, (2) Risk management, and (3) Quality management. j) System Development Life Cycle (SDLC): The life cycle provides the stages that a typical system passes through during its life. k) Differences between project life cycle and SDLC i) The project life cycle addresses project issues better than the SDLC. ii) The SDLC will specify the tasks, deliverables and quality standards for each phase. iii) For a system development project, execute consists of specification, design, programming, system testing and installation. Whereas the SDLC will specify the tasks, deliverables and quality standards for each phase. iv) Many phases of SDLC may coincide with phases of the project life cycle, but the project life cycle is more extensive when it comes to real projects. v) A generic project life cycle is suitable for all kinds of IT projects. There are some activities that occur once for example initiation, determining feasibility, and termination, while other activities occur repeatedly for every phase, and some others occur for every task of the technical life cycle of the project. Page 2

3 2) Project Initiation a) Project Scope: Project scope is basically a definition of the end results of the project in specific, tangible and measurable terms. b) Project Scope Definition: A document that will be published and used by the project owner and project participants for planning and measuring the project success. It contains items to be covered in the project. c) Scope: The coverage area that you are expected to deliver to your customer when the project is complete. d) Project Scope Check List (Statement of Work, SOW): i) Project Objectives: Define the major objectives to meet your customer s needs. Describe the things to be achieved in a project and the ways to achieve them successfully. What, when and how much. ii) Deliverables: Define major deliverables (expected outputs) over the life of the project. Eg. Manual iii) Milestones: A milestone is a significant event in a project that occurs at a point in time. iv) Technical Requirements: Product or service will have this to ensure proper performance. v) Limits and Exclusions: Limits and Exclusions define the boundary of project by stating what are and are not included. vi) Review with Customer: Scope Checklist ends with review with customer, internally and externally. e) Priority Matrix Checklist: Used to understand the nature of priorities of the project. It identifies which criterion is constrained, which should be enhanced, and which can be accepted f) Work Breakdown Structure (WBS): The structure that shows the way of breaking the work down into smaller elements that is manageable, independent, integrate able and measurable. It involves identifying the main tasks required and then breaking each of these down into a set of lower level tasks, thus providing a greater probability that every major and minor activity will be accounted for. g) Outline Planning: It is a warming up to the real planning, giving a structure to the detailed plan. It overlaps with the initiation or conception stage of the project life cycle. i) Ten Step Basic Plan: The following ten (10) steps constitute this outline plan: (1) Verify from Report: Project manager to verify from the feasibility report, or other documents, about the scope of the project to be undertaken. (2) Terms of reference: Project manager must know the roles of a project manager, identify the project sponsor and his roles, identify the accountable executive, know project manager s job description, know project manager s authority and accountability. (3) Responsibilities: To establish clear objectives and prepare all project plans approved by the key stakeholders, to agree on approval procedures with the stakeholders, to establish a control system and measurement criteria, to produce status report regularly, to establish the project budget, to resolve all conflicts, to deliver expected outcome at each stage, on time, and within budget (4) Key result areas: Planning, organizing, directing, and controlling the outcomes of these activities. (5) Clarify objectives: Objectives could be stated and derived from discussions with the project sponsor, other key stakeholders, including the team members (6) Core Team Members: Identify your core team members, and get them involved in the actual planning of the project. (7) Identify Stakeholders: Stakeholders are people whom you and your team believe as people with interest in the project, including those affected by the project. (8) Scope of work: Can be defined better by drawing up a Project Specification List. (9) Project Tasks: Using the brainstorming technique together with all those in the core team. Cluster together closely all the related tasks. Identify key stages of the project. (10) Logical Diagram: Develop a complete picture of the project logic out of the key stages and activities identified, in the following sequence; Activity 1, Activity 2, Activity 3, until the last activity. Page 3

4 h) Project Definition Form: A document that officially records the start of a new project so that everyone is aware of its taking place in the company. This document also describes briefly about the project its title, the project manager, budget, deadlines, and so on. 3) Project Selection and Evaluation a) Project Selection: Process of evaluating individual projects or groups of projects, and then choosing to implement some set of them so that the objectives of the parent organisation will be achieved. b) Criteria of Choice of Project Selection Model: i) Realism: The model should reflect the reality of the manager s decision situation, including the multiple objectives of both the firm and its managers. ii) Capability: The model should be sophisticated enough to deal with multiple time periods, simulate various situations both internal and external to the project and optimise the decision. iii) Flexibility: It should have the ability to be easily modified, or to be self adjusting in response to changes in the firm s environment; Eg. new technology can change risk levels iv) Ease of Use: The model should be reasonably convenient, not taking a long time to execute, and be easy to use and understand. v) Cost: Data gathering and modelling costs should be relatively low compared with the cost of the project and must surely be less than the potential benefits of the project. vi) Easy Computerization: It must be easy and convenient to gather and store the information in a computer database, and to manipulate data in the model through the use of a widely available, standard computer package. c) Types of Project Selection Models: 2 types i) Numeric Project Selection Models: Usually financially focused and quantifies the project in terms of either the time to repay the investment (payback) or the return on investment (ROI). Uses profit/profitability and scoring as the measures of acceptability (1) Profit/Profitability Models: Numeric models using profitability as the sole measure of acceptability (a) Payback Period: The payback period for a project is the initial fixed investment in the project divided by the estimated annual net cash inflows from the project. The ratio of these quantities is the number of years required for the project to repay its initial fixed investment. (b) Average Rate of Return: The average rate of return is the ratio of the average annual profit (either before or after taxes) to the initial or average investment in the project. This models advantage is the simplicity, but it does not take into account the time value of money. (c) Discounted Cash Flow (or NPV method): This method determines the net present value of all cash flows by discounting them by the required rate of return. (d) Internal Rate of Return: In a set of expected cash inflows and cash outflows, the internal rate of return is the discount rate that equates the present values of the two sets of flows. (e) Profitability Index (or Benefit Cost ratio): The profitability index is the net present value of all future expected cash flows divided by the initial cash investment. If this ratio is greater than 1.0, the project may be accepted. (2) Numeric Scoring Models: In attempt to overcome the disadvantages of models above (a) Unweighted 0 1 Factor Model: The management selects a set of relevant factors and then usually lists in a pre printed form. One or more raters score the project on each factor, depending on whether or not it qualifies for an individual criterion (either 1 or 0). (b) Unweighted Factor Scoring Model: Unlike the above, this model uses a five point scale. (c) Weighted Factor Scoring Model: In this model, the numeric weights reflecting the relative importance of each individual factor are added. (d) Constrained Weighted Factor Scoring Model: The temptation to include marginal criteria can be partially overcome by allowing additional criteria to enter the model as constraints rather than weighted factors. Page 4

5 ii) Non Numeric Project Selection Models: Look at a much wider view of the project considering items from market share to environmental issues. (1) Sacred Cow: A senior and powerful official in the organisation suggests the project. (2) Operating Necessity: If the project is required in order to keep the system operating, the primary question becomes: Is the system worth saving at the estimated cost of the project? (3) Competitive Necessity: Decision to undertake the project is based on a desire to maintain the company s competitive position in the market. (4) Product Line Extension: A project to develop and distribute new products would be judged on the degree to which it fits the firm s existing product line, fills a gap, strengthens a weak link, or extends the line in a new, desirable direction. (5) Comparative Benefit Model: Senior management selects a subset from amongst many projects available that would most benefit the firm. d) Project Evaluation: A project is evaluated in different ways depending on the influencing factors. i) Strategic Assessment (1) Programme Management: It is being increasingly recognised that individual projects need to be seen as components of a programme and should be evaluated and managed as such. (a) Programme: A collection of projects that all contribute to the same overall organisation or organisational goals. (2) Portfolio Management: Where an organisation, such as a software house, is developing a software system they could be asked to carry out a strategic and operational assessment on behalf of the customer. (3) Technical Assessment of a proposed system consists of evaluating the required functionality against the hardware and software available (4) Cost Benefit Analysis Assessment: Based upon the question of whether the estimated costs are exceeded by the estimated income and other benefits. (5) Risk Evaluation: Considering each possible outcome and estimating the probability of its occurring and the corresponding value of the outcome. 4) Project Planning a) Project Plan: Result of the entire planning process. Provides a clear picture of the project to the customers as well as to the project team members. b) Planning: Is to answer the questions: i) What must be done? ii) How long will it take? iii) Who will do it? iv) How should it be done? v) How good it has to be? vi) How much will it cost? c) Cardinal rule of Planning: The people who must implement a plan should participate in preparing it. d) Proper steps in Project Planning: i) Define the problem based on customer s requirements; ii) Develop statements of major objectives; iii) Develop a project strategy: the waterfall model, prototyping, etc; iv) Define project boundaries: what will and will not be done; v) Develop a work breakdown structure (WBS); vi) Using WBS, estimate activity duration, resource requirements and costs; vii) Prepare the project master schedule and the budget; viii) Decide on the project organisation structure; Page 5

6 ix) Set up the project notebook; and x) Get the plan signed off by all the stakeholders. e) IT projects can be simplified as follows: i) One project should focus on one system only; ii) One large project should be broken down into several sub projects; iii) One sub project should focus on one subsystem only; iv) A hierarchy of sub projects can be executed sequentially or in parallel; v) Each subsystem then has its own lifecycle; vi) Each sub project then has its own process model; and vii) In this way, system developers can supply a series of deliverables quite frequently, thereby assuring the users and stakeholders of getting improved functionality each time. f) Scope (functional specification): A statement that defines the boundaries of the project. It tells not only what will be done but also what will not be done. Scope of a project is best achieved by defining the principal deliverables from the project. It is also important, in order to avoid confusion, misunderstanding and argument later, to define anything that is not included in the project. g) Project Objectives: describe the things to be achieved in a project and the ways to achieve them successfully. Objectives should be clearly defined so as to guide and motivate the project team. Objectives form a basis for dealing with risk and future decisions. h) Functional Requirements: These define what the functions of the end product of the project are. i) Quality Requirements: The quality requirements relate to what the application system is supposed to do to implement other attributes of the application. j) Resource Requirements: These requirements give a clear record of how much the organisation is willing to spend on the system. There may be trade off between the cost and the time it takes to implement the system. There may also be a trade off between the functional and quality requirements and the cost. k) Project Team Formation Life Cycle: contains four basic stages: i) Individual Identities: During the initial phases of the project, each team member must: (1) Discover individual and team goals; (2) Understand accepted individual behaviour; (3) Establish a personal role on the team; and (4) Determine personal level of responsibility and accountability. ii) Cluster Identities: In this phase, each team member concentrates on: (1) Forming alliances with other team members; (2) Establishing lines of power and authority; (3) Challenging assignment approach and validity; (4) Maintaining decision making independence; and (5) Increasing/decreasing responsibility. iii) Group Identities: In this phase, the members of the team begin to: (1) Define acceptable group behaviour; (2) Create group standards; (3) Set and support group goals; (4) Form conflict resolution approaches; (5) Compete with other groups; (6) Share opinions and confidences; and (7) Move from individual successes to group successes. Page 6

7 iv) Team Identity: The greatest benefits are reached during this last phase, if the team can reach this point: (1) Individual identity fuses with team identity; (2) Individuals strive to achieve team goals; (3) The team follows optimal problem solving and decision making approaches; (4) Team clusters move from inner group competitiveness to full team cooperation; and (5) Everyone moves from individual and group successes to team success. l) Project: Composed of a number of interrelated activities. m) Activity: Any task, job or operation which must be performed to complete the work package or project. n) Activity plan (Action Plan): Describes the list of activities that need to be carried out and the order they are to be done. i) Ideal activity plan: A plan of when each activity would ideally be undertaken even when resources are not a constraint. ii) Activity plan enables to: (1) Ensure that the appropriate resources will be available precisely when required; (2) Avoid different activities competing for the same resources at the same time; (3) Produce a detailed schedule showing which staff carry out each activity; (4) Produce a detailed plan against which actual achievement may be measured; (5) Produce a timed cash flow forecast; and (6) Re plan the project during its life to correct drift from the target. o) Work Breakdown Structure (WBS): The structure that shows the way of breaking the work down into smaller elements that is manageable, independent, integrate able and measurable. It involves identifying the main tasks required and then breaking each of these down into a set of lower level tasks, thus providing a greater probability that every major and minor activity will be accounted for. i) Starts when the statement of work (SOW) is completely defined. There should be agreement between the final SOW and WBS. ii) Hierarchically structured: in accordance with the way the work will be performed. iii) Is a Communications tool: providing detailed information to different levels of management. iv) Steps for Designing and Using the WBS: (1) Using the information from the action plan, list the task breakdown in successively finer levels of detail. (2) Continue until all meaningful tasks or work packages have been identified and each task can be individually planned, budgeted, scheduled, monitored, and controlled. (3) For each of such work packages, identify the data relevant to the WBS, like vendors, durations, equipment, materials, special specifications, etc. (4) List the personnel and organisations responsible for each task. (5) All work package information should be reviewed with the individuals or organisations that have responsibility for doing or supporting the work in order to verify the WBS s accuracy. (6) Resource requirements, schedules and subtask relationships can be aggregated to form the next higher level of the WBS, continuing on to each succeeding level of the hierarchy. (7) At the uppermost level, there will be a summary of the project, its budget, and an estimate of the duration of each work element. (8) As the project is carried out step by step, the project manager can continually examine the actual resource utilisation, by work element, work package, task, and so on up to the full project level. (9) Finally, the project schedule may be subjected to the same comparisons as the project budget. Actual progress is compared to scheduled progress by work element, package, task, and complete project, to identify problems and take corrective action. Page 7

8 v) Uses of WBS: (1) Thought Process Tool: WBS is useful to visualise exactly how the project work can be defined and managed effectively. (2) Architectural Design Tool: WBS is a picture of the project work and it gives a picture about how the items of work are related to one another. (3) Planning Tool: WBS gives the project team a detailed representation of the project as a collection of activities that must be completed in order to complete the project. E.g., estimating effort, elapsed time, resource requirements, building schedule, etc. (4) Project Status Reporting Tool: WBS is used as a structure for reporting project status. The project activities are consolidated from the bottom as lower level activities are completed. WBS defines milestone events that can be reported to senior management and to the customer. vi) Major: events in the project often used for identifying key progress reporting points. vii) Schedule of Milestones: Allows you to keep everyone in the picture about the project objectives and how you want them to be achieved through intermediate deadlines that you have frozen into milestones. viii) Risk Management Plan: Must be started at before starting the actual work, so that further risk identification can be extended to include the technology of the process/product, the project s schedule, resource base, and a myriad of other risks facing the project but not really identifiable until the project plan has begun to take shape. 5) IT Project Estimates a) Information Systems (IS) projects have special problems in estimating their effort, time, cost, resources, etc. b) Estimate: Assessment of the likely quantitative result. c) Software Estimates: include estimates of effort, costs, schedule and staffing (number of persons). d) Effort: Total time duration that one person needs to complete a task. Measured in person hours, personweeks, person months etc. e) Schedule: Total duration planned to complete the task. f) A Good Estimate: Consists of a description of the project s scope, the estimation technique used, and the accuracy of the estimate. g) The benefits of software estimates are: i) To quantitatively define success or failure and their level for product, processes and people. ii) To quantify improvement or degradation in the products, process and people. iii) To make meaningful and useful managerial and technical decisions. iv) To identify trends. h) Stages Where Estimates are Done: i) Strategic Planning: The costs and benefits of computerising potential applications should be estimated to decide on the priority to be given to each project. This also helps in deciding the numbers of various types of technical people to be recruited by the organisation. ii) Feasibility Study: Feasibility study should ascertain that the benefits of the proposed system would justify the costs iii) System Specification: The effort needed to implement different design proposals will need to be estimated. Estimates at the design stage will also confirm that the feasibility study is still valid. iv) Evaluation of Supplier s Proposals: Staff in the software houses that are considering a proposal or a (tender) bid would need to scrutinise the system specification and produce estimates as a base for evaluation of the proposals. v) Project Planning: As the planning and implementation of the project progress to greater levels of detail, more detailed estimates of smaller work elements will be made. Page 8

9 i) Over Estimation: Might cause the project to take longer than it would otherwise. j) Under Estimation: Might cause the project to take shorter time than a more generous estimate. The danger with the under estimate is the effect on quality. k) Parkinson s Law: Work expands to accommodate the time available. This implies that given an easy target, staff will work less hard. l) Brooks Law: Putting more people on a late job makes it later. The effort required to implement a project will go up disproportionately with the number of staff assigned to the project. m) Software Estimating Process: i) Estimate Size: Software product size is generally measured in Source Lines Of Code (SLOC). WBS, and either SLOC or function points may be used to estimate software product size. ii) Estimate Cost and Effort: The key input to this stage is size estimate for the project. The estimate should include all labour activities charged directly to the task. iii) Estimate Schedule: The purpose of the schedule estimate is to determine the length of time needed to complete the project and determine when major milestones and reviews will occur. iv) Inspect and Approve Estimate: The purpose of this stage is to improve the quality of the estimates produced and obtain senior management commitment. v) Track Estimates: The purpose of this stage is to check the accuracy of the estimate over time and to develop some empirical data over time. Estimates should be tracked over time by comparing planned to actual outcomes. n) Basis for Software Estimation: i) The Need for Historical Data: Most of the estimating methods need information about how projects have been implemented in the past. ii) Measure of Work: The time taken to write a program may vary according to the competence or experience of the programmer. iii) Complexity: Two programs with the same SLOC or KLOC (thousands lines of code) will not necessarily take the same time to write, even if done by the same developer in the same environment. o) Software Effort Estimation Techniques: i) Bottom Up Estimation: With bottom up approach, the estimator breaks the project into its component tasks and then estimates the effort required to carry out each task, starting from the bottom, adding up to the top. Where a project has no historical data available, it would be better to use bottom up approach for estimation. ii) Top Down Estimation: This is an overall estimate for the project. It is normally derived from global properties of the software product. This estimate will usually be based on previous projects and will include the costs of all the functions in a project. iii) Expert Judgement: This method relies on one or more people who are considered experts in some endeavour related to the problem, iv) Estimating by Analogy: Comparison of the proposed project to the completed projects of a similar nature whose costs are known. (1) Advantage: Enables a broad brush estimate for a whole project fairly quickly (2) Disadvantage: There are actually fewer similarities between the two projects than initially appears to be the case. Page 9

10 v) Analysis Effort Method: Estimate the effort required to perform the analysis work for an assumed number of project functions and then to derive the estimates for subsequent project stages via the use of ratios to the analysis effort. Next step is to assess by three key factors: (1) Size: Number of people who will be involved in the project at its peak (2) Familiarity: Concerns the familiarity that project staff are likely to have with the type of work and with the business and technical environments. (3) Complexity. Takes into account the types of technical issue likely to be associated with the project. vi) Programming Method: Examining the programming effort required and deriving values for the rest of the project tasks, then decide if each is likely to be small, medium or large. vii) Three point Technique / Three Time Probabilistic Model: Uses three estimates for time duration: (1) Optimistic time (O): shortest time the activity could be completed, barring outright miracles. (2) Pessimistic time (P) is the worst possible time allowing for all reasonable eventualities. (3) Most likely time (M) is the time usually experienced under normal circumstances. Using the above three estimates, the expected time (Te) for an activity is calculated using the formula, Te = (O + 4M + P)/6 viii) Delphi Technique: Based on the idea of obtaining estimates from suitably qualified people and then synthesising them to produce the final estimate. ix) COCOMO: Constructive Cost Model: A hierarchy of three costing models. The model presents formulae for calculating the effort and elapsed time needed to develop software based on an assessment of the amount of program code to be developed. (1) Basic COCOMO: This is a static single valued model. It calculates software development and cost as a function of program size expressed estimated lines of code. (2) Intermediate COCOMO: this model considers many other factors which affect the resources required by a project. The factors include resource estimates in addition to the basic COCOMO model effort. This way, there are 15 cost drivers identified and grouped into four major categories, namely: (a) Product attributes (3 cost drivers); (b) Computer or hardware attributes (4); (c) Project attributes (3); and (d) Personnel attributes (5). (3) Advanced COCOMO (COCOMO2): This model considers the different factors, which apply during the different stages of a system development and produces more detailed estimates on a phase byphase basis. (4) Advantage is its simplicity, because it requires a small amount of data (LOC) to determine the effort and cost. (5) Disadvantage is that it is an empirical estimation model. The empirical data that supports its models are derived from a limited sample of projects. This increases the likelihood of producing inaccurate results x) Function Point (FP) Analysis: Used to quantify the functional size of programs independently of the programming languages in which they had been coded. (1) The method has three stages: (a) Analysing the system in terms of its information processing requirements at a logical level, independent of implementation considerations and calculating unadjusted function points (UFPs); Page 10

11 (b) A processing complexity adjustment (PCA) is calculated to allow for technical considerations such as ease of use, distributed processing, maintainability and so on; and (c) The UFPs are factored by the PCA to derive the final function point score for the project. (2) MARK II Approach: This version consider three aspects of a system: (a) Its information processing logic size, derived from the system s inputs, processing and outputs, (b) Its technical complexity, whether batch or online, if it involves demanding criteria for performance or ease of use, and (c) Performance influencing factors, such as the general development environment, available staffing and so on. xi) COCOMO vs FPA (1) Size Oriented Metrics: Software engineering activities include analysis, design, coding, testing and documentation. In short, it is more than just programming. Based on these activities, it is not easy to measure the nature of a software product. One obvious way of measuring it is based on its size, and COCOMO is a famous type of the size oriented metrics. (2) Function Oriented Metrics: Function Point Analysis (FPA) is a deepening of the function oriented metrics. This type of software metrics uses a measure of the functionality delivered by the software application as a common denominator. Thus, besides the size, you can also use the software functions to represent software complexity of some sort. (3) Reconciling COCOMO and FPA: Lines of code (LOC) can be mapped into function points, and vice versa. For the FPA, it does not matter which programming language being used since the software functions are independent of the programming language. However, for the COCOMO, programming languages need to be taken into account. (a) Both LOC and FP measures are often used to derive productivity metrics. (b) They are relatively accurate predictors of software development effort and cost. Page 11