INF308J/102/2010

SOFTWARE PROJECT MANAGEMENT SAGTEWARE PROJEKBESTUUR TUTORIAL LETTER 102 STUDIEBRIEF 102 FOR / VIR INF308J

IMPORTANT INFORMATION ABOUT EXAM ADMISSION

Due to new regulations by the Department of National Education, students must meet the following deadline for this module: Submit at least one assignment for Software Project Management BEFORE 31 May 2010 If you do not meet this requirement you cannot be granted examination admission in Software Project Management

School of Computing Skool vir Rekenaarkunde

INF308J/102

BELANGRIKE KENNISGEWING: Nota aan Afrikaanssprekende studente: hierdie brief is slegs in Engels beskikbaar. Kontak ons gerus indien u probleme met enige van die terme ondervind.

TUTORIAL LETTER COSALLF/301/2010' AND THE BOOKLET YOUR SERVICE GUIDE @ UNISA CONTAIN IMPORTANT GENERAL INFORMATION AS WELL AS LECTURERS CONTACT DETAILS THAT YOU WILL NEED DURING THE YEAR. DO READ IT CAREFULLY!
Please Note: References in this tutorial letter pertains to the 5th edition of the prescribed textbook: Bob Hughes and Mike Cotterell, 2009. Software Project Management - Fifth edition. McGraw-Hill (London). ISBN: 9780077122799

INF308J/102

TABLE OF CONTENTS

1. 2. 3. 4.

PREFACE .......................................................................................................................... 4 HOW TO USE THIS TUTORIAL LETTER ......................................................................... 5 MODULE OBJECTIVES AND OUTCOMES ...................................................................... 6 SECTION 1 ........................................................................................................................ 6 4.1 Unit 1: Introduction to software project management................................................... 6 4.2 Unit 2: Project evaluation ............................................................................................. 7 4.3 Unit 3: Step Wise - an overview of project planning................................................... 12 4.4 Unit 4: Selection of an appropriate project approach ................................................. 19 5. SECTION 2 ...................................................................................................................... 26 5.1 Unit 5: Activity planning ............................................................................................. 26 5.1.1 Example 1: Drawing a CPM Diagram .................................................................. 27 5.1.2 Example 2: Converting a CPM Diagram into Precedence Network Diagram ...... 28 5.1.3 Example 3: How to draw a Precedence network diagram .................................. 29 5.2 Unit 6: Risk management .......................................................................................... 34 6. SECTION 3 ...................................................................................................................... 36 6.1 Unit 7: Resource allocation ........................................................................................ 37 6.2 Unit 8: Monitoring and Control .................................................................................. 38 6.3 Unit 9: Software effort estimation ............................................................................... 40

INF308J/102

1. PREFACE
Project management is not a new concept! Throughout the documented history of the human race there have been projects encompassing more than a single person could accomplish alone. Think of examples such as the pyramids in Egypt, the cathedrals in Europe and the Great Wall of China! Nowadays effective management of projects in the Information Technology environment is seen to be increasingly important as a discipline. The aim of this module is thus to equip students with the necessary knowledge to successfully evaluate a prospective project and methods to initiate, plan, estimate, schedule, manage, control, and report on projects. After completing this module, you should have a good understanding of important aspects such as: proper planning, resource management, feasibility analysis, risk assessment and management, monitoring and control, scope and change control, quality assurance and configuration management.

The textbook that you will use in this course, makes use of case studies to implement the techniques and concepts. It is necessary for IT professionals and practitioners, systems analysts, programmers, DBAs, etc., to gain an appreciation of software project management concepts and to understand how these aspects can best be employed to develop effective and efficient business systems. The aspects covered in this module are aimed at satisfying these requirements of business-oriented students. In software project management there is no substitute for experience. The textbook prescribed for this module uses two running case studies to illustrate and implement software project management concepts. To enhance theoretical knowledge and expertise, the assignments are designed to guide you through most of the important software project management techniques used in the development process. We hope that you will find this module stimulating and enjoyable. Regards Software Project Management Lecturers

Acknowledgements:
The assistance of Prof. A Barnard, Prof. M Eloff as well as Mrs. R Nienaber, Mrs. K Engelbrecht and Mrs. E Kritzinger with the previous version of this study material is appreciated. Mr. E Nenzhelele and Ms. E van Rijn also supplied valuable input in this version. Mrs. M Hillebrands provided valuable input in compiling Unit 9.

INF308J/102

2. HOW TO USE THIS TUTORIAL LETTER

The purpose of this tutorial letter is not to duplicate the aspects and topics already covered sufficiently in your prescribed textbook, but rather to serve as supplementary material to guide and support you in your study process. We will provide you with a list of objectives and outcomes related to the study material. The outcomes should be used as a checklist when you work through the relevant chapters in the prescribed textbook and when you prepare for the examination. The following items constitute the study material for this module: the prescribed textbook: Bob Hughes and Mike Cotterell, 2009. Software Project Management Fifth edition. McGraw-Hill (London). ISBN: 9780077122799 the first tutorial letter: INF308J/101/2010; this second tutorial letter: INF308J/102/2010; to be used in conjunction with the first tutorial letter assignment questions: the questions for all of the assignments are given in Tutorial Letter INF308J/101/2010; solutions to the assignments: numbered as INF308J/201/2010, INF308J/202/2010, and so on, which will be sent to you during the year; and the examination tutorial letter: sent in August or September informing you on issues regarding the examination paper, such as the format, work to be covered, etc.

This tutorial letter should be read in conjunction with your prescribed textbook. Section 1 corresponds to the work covered by Assignment 01, Section 2 to the work covered by Assignment 02 and Section 3 to the work covered by Assignment 03. Each unit corresponds to a chapter from the textbook, namely: Unit in the tutorial Unit 1: Introduction to software project management Unit 2: Step Wise: an overview of project planning Unit 3: Project evaluation Unit 4: Selection of an appropriate project approach Unit 5: Activity planning Unit 6: Risk management Unit 7: Resource allocation Unit 8: Monitoring and control Unit 9: Software effort estimation Chapter in the textbook: Chapter 1. Introduction to software project management Chapter 2. Project evaluation and programme management Chapter 3. An overview of project planning Chapter 4. Selection of an appropriate project approach Chapter 6 Activity planning Chapter 7 Risk management Chapter 8 Resource allocation Chapter 9 Monitoring and control Chapter 5 Software effort estimation

INF308J/102

3. MODULE OBJECTIVES AND OUTCOMES

Module objectives:
The aim of this module is to: Introduce you to software project management techniques to successfully initiate, evaluate, plan, manage and control Information Technology projects. Cover most aspects of software project management such as project planning, feasibility analysis, estimation, risk assessment and management, resource management, and scope and change control. Use two case studies to illustrate and implement software project management techniques and concepts.

Module outcomes:
After studying this module you should have attained the specific understanding, knowledge and skills to: evaluate a proposed project; plan a newly proposed project using different techniques; do a realistic estimation of a proposed project; and schedule, manage, monitor and control a project successfully.

4. SECTION 1
Software Project Management - basic concepts
This section of the tutorial letter deals with the work covered in Assignment 01, namely Chapter 1 up to and including Chapter 4 of Hughes and Cotterell. Amongst other things, we will study what the scope of a project is, in particular a software project. You will be introduced to topics such as management control, who the stakeholders are in a software project, requirement specification, project planning and evaluation, including techniques such as cost-benefit analysis and how to select an appropriate project approach. Each of the 4 units in this section corresponds to a chapter in Hughes and Cotterell. For example, Unit 1 corresponds to Chapter 1, and so on. Study this section of the work carefully and then complete Assignment 01 and hand it in on or before 8 April 2010. Note that this is a compulsory assignment.

4.1

Unit 1: Introduction to software project management

This unit defines the scope of software project management by considering what is meant by the term project, the management of projects, and how software projects differ from other projects. Study Chapter 1 in the textbook.

INF308J/102

Unit 1 objectives: The aim of Chapter 1 of the textbook is to introduce the following concepts: what a project is; the difference between software projects and other types of projects; contract and technical project management; activities covered by software project management; plans, methods and methodologies; categorising software projects; management and management control; problems experienced with software projects; setting realistic objectives; who the stakeholders in a project are; business models and projects; and requirement specification. Unit 1 outcomes: After studying Chapter 1 of the textbook, you will be able to: define the scope of software project management; distinguish between software and other types of development projects; understand some problems and concerns of software project managers; define the usual stages of a software project; explain the main elements of the role of management; understand the need for careful planning, monitoring, and control; identify the stakeholders of a project and their objectives, as well as ways to measure the success in meeting stakeholder objectives; and measure the success of a project in meeting its objectives. Case Study 1: Brightmouth College Case studies form an important part of explaining, illustrating and applying the different techniques of software project management. The textbook uses two case studies throughout to do just this, and the first one appears as part of Exercise 1.2 on page 7 of the textbook. This case study deals with the payroll administration system of Brightmouth College. Carefully study the entire case study as presented in the textbook.

4.2

Unit 2: Project evaluation

This unit discusses techniques that can be used to decide whether it is feasible to proceed with a given project or not. It is obviously very important to be able to decide whether or not the development of a software project will be cost-effective, as the high expense incurred by software development projects in general, has the potential to bankrupt an organisation if the costs outweigh the potential benefits. Study Chapter 2 of the textbook.

INF308J/102

Unit 2 objectives: The aim of Chapter 2 of the textbook is to introduce the following concepts: strategic assessment; technical assessment; cost-benefit analysis; cash flow forecasting; cost-benefit evaluation techniques; and risk evaluation. Unit 2 outcomes: After studying Chapter 2 of the textbook, you should be able to: carry out an evaluation and selection of projects against strategic, technical, economic and risk criteria; use a variety of cost-benefit evaluation techniques in order to choose among different project proposals; and evaluate the risk involved in a project and select appropriate strategies for minimising potential costs. Cost-benefit evaluation techniques: This is a very important section of Chapter 2, and you must study it in detail and ensure that you understand, and can apply, the different techniques as discussed on pages 26 to 34 of the textbook. Some of the techniques described may at first glance not be entirely clear. In this context, please take note of the following: ! Return On Investment (ROI) - Exercise 2.4

The formula for ROI on the next page is given on page 30 of the textbook as:

Average Annual Profit ROI =

-------------------------------------

x 100

Total Investment
Exercise 2.4 now asks that the ROI for Project 1 be calculated. Refer to Table 2.1 on page 29 for the cash flow projection figures of Project 1. Using these figures, we obtain a net profit of 50 000 over a period of 5 years. The average annual profit is thus: 50 000 5 = 10 000 Substitution of average annual profit by 10 000 and total investment by 100 000 in the formula for ROI, yields: 10 000 --------- x 100 = 10% 100 000 The present value (PV) and net present value (NPV) of a project are discussed on pages 30 to 31 of the textbook. The following variables are used in the formula for PV and NPV:

INF308J/102

t is the number of years into the future that the cash flow occurs and r is the discount rate, i.e. the annual rate by which future earnings are discounted.

Note that r is a rate and thus expressed as a percentage %. Wherever r is used in a formula, we should remember that it is used as a rate and should thus be interpreted as (r x (1 100)) = (r 100). In order to compute the present value (PV) of a future cash flow, we need to multiply the cash flow by the discount factor, where the discount factor is calculated by the following formula:

Discount factor =

(1 + r% )

1 r 1 + 100
t

See page 31, table 2.2, for some discount factors. Use the discount factors in the table instead of calculating them with the formula. The present value of a future cash flow in year t is then calculated as: PV = cash flow in year t x discount factor The net present value for a project with t years worth of cash flows is merely the sum of the present values for each year, thus: NPV = PV, where this sum is taken over t. See exercise 2.5 on page 32 and exercise 2.6 on page 32 for relevant examples. A fictitious scenario: Consider the following fictitious scenario and some questions related to it. The table below gives the estimated cash flow for three different projects (in rands R): Year 0 1 2 3 4 5 6 Project 1 - R 175 000 - R 10 000 + R 20 000 + R 50 000 + R 50 000 + R 65 000 + R 60 000 Project 2 - R 150 000 +R 5 000 + R 25 000 + R 35 000 + R 80 000 + R 95 000 - R 10 000 Project 3 - R 280 000 + R 10 000 + R 30 000 + R 50 000 + R 120 000 + R 120 000 + R 120 000

Table for fictitious scenario: Estimated cash flow for three different projects Based on the above table, answer the following questions: 1 Calculate the net profit of each project.

10

INF308J/102

2 3 4 5 6 7

Based on your answer to Question 1 above, which project would you select to develop? Using the shortest payback method as discussed in Hughes and Cotterell, which project would you now select for development and why? Calculate the Return on Investment (ROI) of each of these projects. Based on your calculation of the ROI of each project in Question 4 above, which project would you select to develop? Assume a discount rate of 12%. Calculate the Net Present Value (NPV) of each project. Based on your calculation of each projects NPV, which project would you now select for development? In general, what conclusion do you reach regarding the viability of these projects? (Base your answer on the NPVs of each project.)

Answers: 1 The net profit is the difference between the total cost and the total income of a project over its lifetime. This net profit of each project is indicated in the last row of the table below: Year 0 1 2 3 4 5 6 Project 1 - R 175 000 - R 10 000 + R 20 000 + R 50 000 + R 50 000 + R 65 000 + R 60 000 Project 2 - R 150 000 +R 5 000 + R 25 000 + R 35 000 + R 80 000 + R 95 000 - R 10 000 Project 3 - R 280 000 + R 10 000 + R 30 000 + R 50 000 + R 120 000 + R 120 000 + R 120 000

Net profit
2

+ R 60 000

+ R 80 000

+ R 170 000

Table for answer to question 1 Project 3 shows the largest net profit, R 170 000, followed by Project 2 and then Project 1 with R 80 000 and R 60 000 net profit respectively. We would therefore select Project 3 for implementation. The payback period is the time taken to break even or pay back the initial investment (at year 0). All three projects paid back the initial investment at the end of year 5. However Project 1 earns R 0 during this year, whereas Project 2 earns R 90 000 and Project 3 earns R 50 000 profit during year 5. The actual payback time can be calculated as follows: Payback: project 1 = Breakeven yr - (Profit made in breakeven yr/ Income in breakeven yr) = 5-(65000/65000) = 5 years Payback: project 2 = Breakeven yr - (Profit made in breakeven yr/ Income in breakeven yr) = 5-(90000/95000)

11

INF308J/102

= 4.05 years Payback: project 3 = Breakeven yr - (Profit made in breakeven yr/ Income in breakeven yr) = 5-(50000/120000) = 4.6 years This actual payback time, together with the profit earned in year 5 already, makes Project 2 the most desirable project to choose (as opposed to Project 3 in question 2). 4 ROI provides a way of comparing the net profitability to the investment required. The ROI of each project is given in the last row of the table below: Year 0 1 2 3 4 5 6 Project 1 - R 175 000 - R 10 000 + R 20 000 + R 50 000 + R 50 000 + R 65 000 + R 60 000 Project 2 - R 150 000 +R 5 000 + R 25 000 + R 35 000 + R 80 000 + R 95 000 - R 10 000 Project 3 - R 280 000 + R 10 000 + R 30 000 + R 50 000 + R 120 000 + R 120 000 + R 120 000

Net profit Average Profit ROI

+ R 60 000 + R 10 000 5.71

+ R 80 000 + R 13 333 8.89

+ R 170 000 + R 28 333 10.12

Table for answer to question 4 5 Project 3 has the highest ROI, 10.12, followed by Project 2 and then Project 1 with ROIs of 8.89 and 5.71 respectively. According to the ROI calculation, Project 3 therefore seems the most appropriate project to develop. The Net Present Value (NPV) of each project is given in the table below:

12 Discount factor at 12% 1.000 0.8929 0.7972 0.7118 0.6355 0.5674 0.5066 Discounted cash flow - R 175 000 - R 8 929 +R 15 944 + R 35 590 + R 31 775 + R 36 881 + R 30 396 Discounted cash flow - R 150 000 + R 4464.50 + R 19 930 + R 24 913

INF308J/102 Discounted cash flow - R 280 000 +R 8 929

Year 0 1 2 3 4 5 6 Net profit NPV

Project 1 - R 175000 - R 10 000 + R 20 000 + R 50 000 + R 50 000 + R 65 000 + R 60 000 + R 60 000

Project 2 - R 150 000 + R 5 000 + R 25 000 + R 35 000 + R 80 000 + R 95 000 - R 10 000 + R 80 000

Project 3 - R 280 000 + R 10 000 + R 30 000 + R 50 000

+ R 23 916 + R 35 590 + R 76 260 + R 68 088 + R 60 792

+ R 50 840 + R 120 000 + R 53 903 + R 120 000 -R 5 066 + R 120 000 + R 170 000 - R 1 015.50

- R 33 343

- R 6 425

Table for answer to question 6 7 A project should be selected for implementation if its NPV is positive, and rejected if it yields a negative NPV. As all three projects have negative NPV, we will abandon all of them (however, if pressed to make a selection, Project 2 has the smallest negative NPV, followed by Project 3 and then Project 1 - this would correspond to our order of selection). However, note that Project 2 yields a negative return in year 6, whereas Project 3 still shows a positive return. This may very well indicate that Project 2 has reached the end of its viable economic lifetime.

4.3

Unit 3: Step Wise - an overview of project planning

This unit deals with the different phases of project planning in a step-by-step fashion. Step Wise, a project planning method, is introduced. Study Chapter 3 in the textbook. Unit 3 objectives: The aim of Chapter 2 of the textbook is to introduce the following concepts: the Step Wise project planning method; step 0 of Step Wise: selection of a project; step 1 of Step Wise: identification of the projects scope and objectives; step 2 of Step Wise: identification of the projects infrastructure; step 3 of Step Wise: analysis of the projects characteristics; step 4 of Step Wise: identification of the projects products and activities; step 5 of Step Wise: estimation of the effort associated with each activity; step 6 of Step Wise: identification of activity risks; step 7 of Step Wise: allocation of applicable resources; step 8 of Step Wise: review/publicise the project plan; step 9 of Step Wise: execution of plan; and step 10 of Step Wise: lower levels of planning.

13

INF308J/102

Unit 3 outcomes: After studying Chapter 3 of the textbook, you should be able to: approach project planning in an organised, step-by-step manner; be able to identify where techniques described in subsequent chapters fit into an overall planning approach; and repeat the planning process in more detail for sets of activities within a project as the time approaches to execute these activities. Case Study: International Office Equipment (IOE): The second case study that will be used throughout the textbook is introduced in chapter 3 on page 50 of the textbook. Study this case study in detail. Note that Amanda has been appointed as project manager for IOEs expansion project, while Brigitte has been appointed as project manager of Brightmouth Colleges new payroll administration system. PRINCE 2 PRINCE 2 is a project management method developed by the Central Computer and Telecommunications Agency in the UK, and is discussed in Appendix A on pages 325 to 336 of the textbook. Example Consider the following scenario: You are appointed IT project manager for a marketing and sales company. Making use of the companys existing intranet environment, your brief is to investigate how to: 1. 2. 3. 4. Support and design a website for external clients to peruse. Enable individual home page creation. Create and maintain a web page for marketing purposes. Create and maintain a web page for sales purposes.

This project has been dubbed Using the Internet by management. In the initial phase you are required to present management with a PBS (product breakdown structure) including at least three levels. As only one member of the management team is conversant with technical topics, you are requested to concentrate on generic topics, rather than technical-level detail (e.g. rather than giving a series of technical links for a specific page and functionality, merely indicate this as a hyperlink etc.). In the follow-up phases you are also to present a (product-flow diagram) PFD as well as an activity network. The same constraints as for the PBS apply to these diagrams. Draw the PBS, the PFD and the activity network. Discussion of example We note that many different answers possibly apply to this question. However, to make the marking of such a question as objective as possible, the following marking scheme can be used as a guideline: (Each positive answer count 1 mark with the total per diagram indicated in brackets below.) [15 marks]

14

INF308J/102

PBS

(5)

Is the PBS represented as a hierarchical (tree structure) diagram? If it is a descriptive diagram, can the hierarchical levels be identified (indents or numbers)? Has the main product been correctly identified? The main product is Using the Internet, or could even be Using the Intranet. Does the decomposition start with the main product(s) and does it contain sufficient levels (more than 2) of sub-products so that the products and its sub-products can be clearly identified? Is the content logically represented on the diagram as outlined in the question? PFD (5)

Based on the PBS? Does it show dependencies / relationship between sub-products and products? Does it show the logical assembly from the sub-products to the product(s) and does it end with the construction / creation of the main product? Is the flow acceptable as per specification? A detailed or generic flow is acceptable. ACTIVITY NETWORK (5)

Does the Activity Network represent the activities required to derive the product(s) shown in the PBS? Are the activities / tasks arranged in a logical sequence and does it end with the activity that creates the main product? Does the Activity Network show which activities can run concurrently? Does the Activity Network conform to the detail in the specification? This question deals with product based project planning (akin to the concept of product-driven software projects as in Chapter 1, section 1.7, of the textbook). This implies that we plan the project according to, or by considering the deliverables, or products, that need to be produced. In this way we will focus only on the products that must be produced (and in the activity network on all the activities and sub-activities which we must undertake), that will be required for delivery of the end product. A very important part of this method is the construction of a Product Breakdown Structure (PBS for short). A PBS is a diagrammatical approach that describes the system in a hierarchical manner as a tree structure that identifies the required products to be produced by the project. The higher-level products are decomposed through a number of levels (as required by the relevant software project application) down to the individual components of each product. PBS for Using the Internet: Ultimately a new website for (both existing and new) clients perusal is to be created. However, this question does not deal with the entire application of the web site, but focuses on four of the subactivities of this project, listed as points 1 - 4 in the question statement. Also note that we need not include technical level detail at this point already, nor are we concerned with linking the site to the Internet. We are thus conducting a feasibility study. Once all the groundwork has been completed, we will presumably be instructed by management to make the web site available on the Internet. It is with these aspects in mind, that we create the PBS on the next page. Please note that this is a suggested, and not necessarily only acceptable, solution to this problem:

15

INF308J/102

Using the Internet

External webpage=envisaged link to the internet

Individual Homepage Creation

Marketing Homepage

Sales Homepage

Training of possible users

Develop & implement

Specify requirements

Design & implement

Investigate existing website creation tools

Investigate possible user requirements

Specify requirements

Design & implementation

Future maintenance

Peruse external & other website Investigate website standard

Survey Literature Prepare & analyse possible user questionnaire

Poll marketing department

Investigate Ecommerce techniques

Report finding

Investigate secure shopping techniques

Investigate website design methodologies & tools

Document findings

Possible literature investigation

Investigate Authentication techniques

Document findings

Future maintenance

Figure 1: PBS for Using the Internet PFD for Using the Internet: In a Product Flow Diagram (PFD for short), the logical sequence of events leading to the products as defined by the PBS, are shown. A PFD shows how products are derived from each other, and what their relationships and dependencies are. Below we give a generic PFD indicating the logical product flow of multiple page-creations.

16

INF308J/102

Overall system Specification

Collect Information & Analyse Define Requirements Page(s) Specification Page(s) Design

Code Page(s) Test Page(s) Evaluate Page(s)

Implement

Report findings

Figure 2: PFD for Using the Internet Activity Network for Using the Internet: An activity network depicts all the activities in logical sequence. This enables us to estimate time scales and prepare work schedules.

17

INF308J/102

Collect & analyse information

Design external page(s)

Code/Develop &test external page(s)

Using the Intranet: Overall specification

Gather information, teach users, specify individual home page(s) layout

Design individual home-page creation

Code/Develop individual home page creation & carry out separate testing Integrate/Test entire system

Specify requirement for marketing page

Design marking page

Code/Develop marketing page

Specify requirements for sales

Design sales pages

Code/Develop sales page

Figure 3: Activity Network for Using the Internet Additional Notes on PBS and PFD Product breakdown structure Product-based planning works by progressively decomposing the project products into smaller products until we reach a sensible, unitary product level. To illustrate this, PRINCE approach standard is used. In PRINCE, the top-level of products is known as project products. These subdivide into three main categories. Look at the product breakdown structure below.

Project Products

Management products
Figure 4: Product breakdown structure

Specialist products

Quality products

Management products are those products associated with the planning and control of the project. For example: Project initiation documents

18

INF308J/102

The project plan The quality plan Acceptance criteria Check points report Quality products are associated with the definition and control of quality. For example: Product description Quality review report Project issue report Specialist products are those things that the project has been set up to create. Look at the breakdown structure below

Specialist products

Analysis products
Figure 5: Specialist products

Feasibility report

We could subdivide the analysis products further as shown below on the breakdown structure

Analysis products

Interview notes
Figure 6: Breakdown structure

Requirement catalogue

Data flow diagrams

Package reports

Data flow diagrams can also be subdivided as shown below

19

INF308J/102

Data flow diagrams

Draft data flow diagrams

Figure 7: Data flows

Reviewed data flow diagrams

Combining these breakdowns plus those of Quality products and management products we come up with a full breakdown structure of the project. Product flow diagram With our list of products, we can now consider the work we will need to do to create the products. PRINCE uses a technique known as a product flow diagram. The idea is simple: we look at the products in relation to each other and consider how one product is transformed into another. For example if we want to transform our interview notes into entries in our requirements catalogue and into data flow diagrams, our PFD will look like this:

Create requirements catalogue

Draft requirement catalogue

Review requirements catalogue

Interview notes

Add extra requirements

Reviewed requirements catalogue

Create data flow

Review DFD

Draft data flow diagram

Agreed DFDs

Figure 8: PFD

4.4

Unit 4: Selection of an appropriate project approach

This unit deals with the different approaches that can be followed when a project is developed, and based on the characteristics of a project, a specific Software Development Lifecycle (SDLC) will be selected. Study Chapter 4 of the textbook.

20

INF308J/102

Unit 4 objectives: The aim of Chapter 4 of the textbook is to introduce the following concepts: choosing amongst different technologies; technical plan content list; choice of process model; structured methods VS speed of delivery; waterfall model; V-process model; spiral model; software prototyping; ways to categorise prototypes; controlling changes during prototyping; incremental delivery; the dynamic systems development method; extreme programming; management of iterative processes; and selection of the most appropriate process model. Unit 4 outcomes: After studying Chapter 4 of the textbook, you will be able to: take into account the characteristics of a software system to be developed whilst planning a project; select an appropriate process model; make the best use of the waterfall process model where appropriate; reduce risk by creation of appropriate prototypes; reduce other risks by implementing the project in increments; and identify where unnecessary organisational obstacles can be ameliorated by making use of socalled agile development methods. In the tables on the following seven pages, we summarise the different life-cycle models that you may encounter in your studies. This only presents a summary of the current situation and you should refer to the textbook used in your second year of study, as well as Hughes and Cotterell, for further information:

21
b Model Incremental Approach

Life cycle model

Main characteristics Allows maintenance and enhancements to be reviewed throughout the project

Waterfall model This is the so-called classical model for system development and is also referred to as the one-shot approach Each Step in this life cycle must be completed before the next step can be started In the b-model maintenance is open-ended and a series of cycles

Advantages

Large projects may benefit from the limited iteration process allowed Logical flow aids in understanding Sequential project processes are easier to plan and implement Allows project completion times to be forecast with a relative degree of accuracy It is relatively simple and easy to understand Enables allocation of tasks within a phase The progress can be evaluated at the end of each phase If changes are made to the project, they have to follow in a pattern: feasibility, analysis, design, production acceptance and final operation Time consuming as validation processes may require a great deal of investigation May lead to increased resource requirements The process is heavy on documentation It assumes that it is possible to arrive at near-perfect documentation that is complete, and is truly representative of the ultimate "requirements" Can be frozen and the authors, i.e. the stakeholders, can be held accountable to those requirement specifications

V- Process Model This model is an elaboration of the Waterfall model and thus sometimes also referred to as a one-shot approach The left side of the model is a design analysis for programming The right side of the model is used for assembly and testing Stresses validation of phase deliverables Allows for the identification of potential problems earlier in the life cycle Ensure more interaction between developers and end-users

Disadvantages

Inherent rigidity of the model eliminates flexibility and adaptability which is often called for in the dynamic IT industry Where there is uncertainty how a system is to be implemented, more flexibility is required End-product (functional model) is produced only very late in the life-cycle The requirements change over time, and this life cycle does not allow any opportunity to review and evaluate with users, thereby making this model inflexible The maintenance phase is not adequately covered. Projects rarely flow in a sequential process Difficult to define all requirements at the beginning of the project Unresponsive to changes A working version of the system is not seen until late in the projects life Repairing problems further along the life cycle becomes progressively more expensive Maintenance costs can be as much as 70% of systems costs

Similar to prototyping Focuses on delivery of operational product All early increments are stripped down into a version of the final product Feedback from early increments can influence later stages positively Possible changes to requirements at late stages of the project, is smaller than for larger projects User gets benefits earlier Early delivery of useful components may improve cash flow as return on investment occurs early on in the life cycle Smaller sub-projects are easier to manage and control Risk can be detected earlier Later increments may require substantial modification of earlier increments The development team may be more productive when working on one large system rather than a series of smaller ones Degenerate to build and fix model

22
This model may be used where the requirements are clearly defined, but where the project is relatively complex and where a number of stakeholders may be involved The incremental approach involves breaking the project down into smaller sub-projects which correspond to smaller sub-systems (components) of the larger system and allows these individual components to be implemented and delivered in sequence Each such component must produce some tangible benefit to the user Where the requirements of a systems are relatively certain, but there are many complexities and deadlines are tight, an incremental approach would be favoured This model forces the project documentation and requirements to be clearly outlined before the increments are defined

When to use

This model would typically be used in a traditional development environment where most of the methodologies and technologies are regarded as stable, where the scope is clearly defined, where similar projects have been undertaken and the development team can specify and design a solution to a high degree of certainty

How does it fit with project management?

This life cycle fits comfortably with project management because it views development as a series of processes that are expected to be completed and planned only once for the project When a system needs ongoing maintenance during its life cycle. When the business requirements are continuously changing, thereby forcing review of the project, and take up more time (and time is money) Component-Based Development (CBD) It allows us to isolate key objectives and thereby establish core business, expressed as processes and/or concepts These can be designed and implemented as robust components, and then plugged together to rapidly build scalable systems Component-based approach to development is incremental

This is a good model when compared to project management because changes to the project are made by following certain rules, which make the project feasible and realistic

When does it work best?

This model works best when the requirements do not change over time

It works best when minimum maintenance is required for a project Not appropriate where scope of the project is poorly defined or undecided

When doesnt it work well?

When business or system requirements change over time

This model shows correspondence between the stages of the life cycle thereby enabling maintenance and updates to be performed throughout the projects life cycle It also enables delivery stages to be identified and the deliverables to be validated This system works best when accurate most up to date documentation is maintained and applied to the project This process is highly dependant on documentation: if the information in a document is not accurate; neither will be the outcome of the project Package-based IS projects Turnarounds are "Work Package" oriented, in that all work for a specific exchanger needs to be kept together in the same package so that the planning and scheduling of the work can be networked and for the most part kept together for a crew of workers

Life cycle model

Rapid Application Development (RAD) RAD uses hybrid teams RAD makes use of specialized tools RAD uses time boxing RAD uses iterative, evolutionary prototyping to accelerate requirements analysis and systems design

Main characteristics

Spiral model (Variation on Waterfall model) Iterative. Divided into 4 quadrants

23
Component-Based Development (CBD) CBD masters development complexity CBD reduces time to market CBD changes the nature of Information Systems CBD builds on the past CBD enables autonomous development of parts CBD covers whole software life cycle Assists developer (not end-user) Installs locally (not globally) Hides decomposition Easy to download Easy to build/configure Development/maintenance might be easier if all functionality is contained in the distribution Package-based IS projects Rapid Application Development (RAD)

Life cycle model

Advantages

Spiral model (Variation on Waterfall model) An iterative approach whereby additional levels of detail are added at each stage Hidden costs and complexity will be discovered earlier in the life cycle Allows more end-user interaction Testing initiatives are expanded on Requirements, issues and solutions are clarified along the project

Disadvantages

Extra time spent on testing and documentation

More time consuming than both the waterfall and V-process models because of iterative processes and more thorough testing principles May take longer to deliver a solution and create an end-product Estimated cost and time increase throughout the life cycle

Focuses on the clear separation of static, stable business concepts from more dynamic business processes and practices

Large Hard to reuse (functionality is entangled) Hard to extend Many dependencies Complex configuration/building Complex structure (strong coupling)

When to use

The spiral models is best used when most of the requirements are clearly defined, but only a small number of unclear variables exist, for example, it is not clear how the users see the finished end-products functionality

Delivers business application sooner than many other approaches Enforces interaction between developers and all stakeholders (Joint Application Development - JAD - approach) Time-boxing results in absolute deadlines Buying may save you time and money as compared to building Deliverables are sometimes easier to port Development is conducted at a higher level of abstraction Early visibility because of prototyping Greater flexibility Greatly reduced manual coding Increased user involvement Possibly fewer defects Possibly reduced costs Shorter development cycles Requires skilled RAD and JAD team leaders and members that understands the particular tools and technologies Documentation is produced as by-product of completed tasks, which may result in a high degree of non-usability and unreliability Time intensive Buying may not save money as compared to building Cost of integrated tool set and hardware to run it are high Harder to gauge progress Less efficient and possible loss of scientific precision May accidentally empower a return to uncontrolled practices Prototype may not scale up a problem Standardized look and feel Successful efforts difficult to repeat As RAD makes extensive use of JAD techniques for data collection and requirements analysis and specification, it is best suited for decision support and management information systems

24
Component-Based Development (CBD) They reuse components instead of starting form the beginning thus quality, time and cost is improved Delivery on industry standard platforms including the J2EE When developing a new system from the outset It decreases the time taken when using the project life cycle Package-based IS projects Rapid Application Development (RAD)

Life cycle model

How does it fit with project management?

Spiral model (Variation on Waterfall model) Fit well since it introduces concepts of objective setting, risk management and planning into the overall cycle

When does it work best?

When requirements are not well specified and in an unstable environment When system quality is the driving force

Because RAD is considered an iterative technique, project management control is crucial to the management of each process within the RAD process The application will be run standalone Major use can be made of pre-existing class libraries Performance is not crucial Product distribution will be narrow Project scope is constrained Reliability is not crucial System can be spilt into several independent modules The product is aimed at a highly specialized IS market

When doesnt it work well?

When requirements are well formed and environment stable

Other unknown platforms

When the components dont fit into the requirements of the system and components need to be redeveloped and customized - thus more cost will be incurred Structured methods User involvement. Separation of logical and physical Emphasis on data Diagrammatic documentation Defined structure SSADM Only cover analysis and design phases Include a set of modeling techniques Default structured model with 5 modules

Object-Oriented (OO) development methods Its model-driven and data-centered but a process-sensitive technique Information Engineering continues with the data and process models as the primary mechanisms used to communicate information system requirements and design concepts between users and developers

Information Engineering

Main Characteristics

OO development involves: Using an OO approach to system analysis Using an OO approach to system design Using an OO approach to programming System is defined as a collection of objects that work together to accomplish tasks

25
Information Engineering Information Engineering attempts to use its techniques on the organization as a whole, modeling the organizations entire data requirements Information Engineering focuses primarily on the data building blocks Focus on users Give a consistent and complete approach to the work Structured methods SSADM Give an accurate and complete picture of the system

Object-Oriented (OO) development methods

Advantages

Disadvantages

Productivity: Object-oriented methodology can increase the productivity of the project team and can reduce the project schedule as much as an order of magnitude due to the intrinsic power of the object oriented programming languages and reuse of classes and objects Rapid development: Reusability Prototyping Quality: Absence of defects better in object-oriented methodology (e.g. reuse and encapsulation) Maintainability: Greater in object-oriented methodology (due to encapsulation) than in conventional architectures based on hierarchy of functions Identifying classes Fuzzy boundaries between design analysis and implementation Too expensive to set up because it has to be used on an enterprise-wide basis Business requirements change too fast to make Information Engineering approach effective Detailed definition in each phase Project is comprehensively supported. When introduced to an environment where intensive use is not currently made of IS When range of current and disparate computer systems have to be considered

Over prescriptive and bureaucratic

It helps the project manager co-ordinate processes

Can fit well since it has links to PRINCE methodology For group project For individual project must use SSADM4

How does it fit with project management? When does it work best?

Increased level of documentation Training of users and analysts necessary to understand documentation Long users time required Does not fit well with PM since managing users is an integral part of the process and is very complex When user involvement is required e.g., user centered design When users and developers are not trained and experienced

When doesnt it work well?

Rapid development Reusability Prototyping Fuzzy boundaries between design, and both analysis and implementation

26

INF308J/102

5. SECTION 2
Software Project activity planning and risk management
This section of the tutorial letter deals with the work covered in Assignment 02, namely Chapters 6 and 7 of Hughes and Cotterell. Amongst other things, we will study the importance of activity planning in software project management and focus on the important impact that risk may have on software projects, as well as learn how to identify and manage risk. Each of the 2 units in this section corresponds to a chapter in Hughes and Cotterell: for example, Unit 5 corresponds to Chapter 6 and Unit 6 corresponds to Chapter 7. Study this section of the work carefully and then complete Assignment 02 and hand it in on or before 3 June 2010.

5.1

Unit 5: Activity planning

Chapter 6 of the textbook, which corresponds to this unit, deals with software project activity planning. Study Chapter 6 of the textbook.

Unit 5 objectives:
The aim of Chapter 6 of the textbook is to introduce the following concepts: the objectives of activity planning; when to plan; project schedules; sequencing and scheduling; network planning models including: o formulation of network models, o precedence networks, o lagged and hammock activities, o time dimensions, o forward and backward pass, and o critical path identification; activity float; shortening project duration; identification of critical activities; and activity-on-arrow networks.

Unit 5 outcomes:
After studying chapter 6 of the textbook, you should be able to: produce an activity plan for a project; estimate the overall duration of a project; and create a critical path and a precedence network for a project. In this chapter the use of the critical path method and precedence networks are discussed as methods to obtain an ideal activity plan. This is an important part of the software project management process and you must study it in detail and ensure that you understand, and can apply, the techniques as discussed in Chapter 6. The network planning model is explained in detail in the textbook, utilising the two case studies. We include another example for you to study.

27

INF308J/102

5.1.1 Example 1: Drawing a CPM Diagram

Consider the list of tasks with dependencies and estimated durations (in weeks) in the table below:
Task A B C D E F G H I J Precedents None A B A C, D E A G F, H D, I Duration (weeks) 1 2 2 5 5 2 4 4 1 2

Sample Table in Unit 5 1. 2. 3. Draw a CPM network for the list of tasks in the table below to illustrate the interaction of activities. Identify the critical path and its duration. After carefully considering the problem again, the project team decides that an alternative to the original plan would be to extend the duration of activity C to four weeks. This would allow activity E to drop to three weeks. Identify what the resulting critical activities are. Do these changes affect the total duration of the project?

A few aspects to bear in mind when drawing a CPM network: make sure that you understand and can apply the rules on pages 140 to 144 of the textbook; the forward pass calculates the earliest date each event may start and the earliest date on which it may be completed; the backward pass calculates the latest date when each event may be started and the latest date when it can be achieved or finished; event dates are recorded on the diagram and activity dates on the activity table. In this example both processes D and C have to be finished and serve as input to process E, but process D and I also serve as input to process J. Thus a dummy activity was created, namely process 4a, to illustrate the duality. 1. The diagram is given below:

28
4a 0

INF308J/102

6 D=5 1 0 A=1 2 1 0 B=2 3 G=4 3 1

C=2

4 0

E=5

11 11 0 F=2

14

8 0

J=2 14 16

9 0

16

I=1 6 5 4 9 H=4 7 13 0 13

Figure 9: CPM diagram for Example 1

2. In order to determine the critical path, we first of all list all of the different paths: path 1 path 2 path 3 path 4 A, D, E, F, I, J = 16 weeks A, B, C, E, F, I, J = 15 weeks A, G, H, I, J = 12 weeks A, D, J = 8 weeks

Path 1 is thus the critical path. 3. Path 1 drops to 14 weeks and path 2 to15 weeks. Now the critical path will be path 2: A, B, C, E, F, I, J. The minimum duration drops to 15 weeks.

5.1.2 Example 2: Converting a CPM Diagram into Precedence Network Diagram

Once you have drawn the CPM diagram: 1. 2. 3. 4. 5. Replace the 1st event or node of the CPM with a Start node (they are equal) Replace every activity on the CPM with a precedence diagram node Replace the last event or node on the CPM diagram with a Finish node (they are equal) Do the forward pass Do the backward pass

29

INF308J/102

See the following diagram:

5.1.3 Example 3: How to draw a Precedence network diagram

Consider the following activities: Task A B C D E F G H Precedents Duration None 6 None 7 None 28 B 7 A 6 A 9 D,E 5 F,G 8

Step1 Draw diagram You start by finding all activities that have no precedents, in other words the tasks that can start immediately. In this case it is activities A, B and C. Also indicate the activity duration which is given in above table.

30

INF308J/102

Next find all activities which are dependent on A, B or C and draw them on your diagram. In this case D is dependent on B and both E and F are dependent on A.

9 F 6 A 6 E 7 Start B 7 D 28 C

Repeat this process for the rest of the activities. Up to this point all the information indicated on the diagram has been given to you - that is the activity name and duration. Now you are ready to do the forward pass Step2- Forward Pass A, B and C can start as soon as the project kicks-off, so their earliest start is week 0. Fill this on your diagram. The earliest finish is then simply the earliest start + activity duration. A = 0+6 = 6 B = 0+7 = 7 C = 0+28 = 28

31

INF308J/102

6 A

0 Start

7 B

28 C

28

Now activities E and F can only start once activity A is completed, so the earliest start for both E and F is 6 Once again you find their earliest finish by adding their earliest start to their duration. E = 6+6 = 12 F = 9+6 = 15

After completing the same exercise for D ( which is dependent on B) D will look as follows:

G is dependent on both D and E, so G cannot start until both D and E have been completed. From the information thus far on the diagram, you can see that the earliest completion date for E is week 12 and for D it is week 14. Activity G will there for have to wait until week 14 (when both E and D is completed) before it can start.

Repeat this process for the rest of the activities. Before you do backward pass, you first need to identify the critical path(s)

32

INF308J/102

Step3 Identify the critical path

First you determine all possible paths. You do this by starting at the START node and following the links to the FINISH node without moving backwards in the diagram at anytime.
Path 1 Path 2 Path 3 Path 4 A-F-H A-E-G-H B-D-G-H C

You then add the individual activities durations to calculate the total path duration. 1. A-F-H = 6+9+8 = 23 2. A-E-G-H = 6+6+5+8 = 25 3. B-D-G-H = 7+7+5+8 = 27 4. C = 28 The critical path is the path with the longest duration, in this case path 4 which consists of only 1 activity C Now you are ready for the backward pass. Step 4 Backward Pass Having completed the forward pass, your diagram should now look like this:
0 6 A 6 0 Start 7 B 7 0 28 C 28 Finish 7 D 14 7 6 E 14 5 G 19 19 8 H 27 12 6 6 9 F 15

We have also established that C is our critical path and has a duration of 28 weeks This means the latest finish date of all nodes linked directly to the finish node should be 28 in order not to delay completion of the project Fill in 28 as the latest finish for nodes C and H so that it looks like this:

33

INF308J/102

From this point it is quite simple to calculate the latest start for an activity by simply subtracting the activitys duration from the activitys latest finish. For C: 28 28 = 0 For H: 28 8 = 20

You have now calculated the latest start date for activity H as week 20. Since H is dependent on activities F and G it means that both F and G must be completed at the latest in week 20. Fill in 20 as the latest finish date for F and G as follows:

Then calculate the latest start date for these activities by subtracting their duration from their latest finish date F = 20 9 = 11 G = 20 5 = 15

Repeat this process for the other activities. Step 5 Calculate the activity slack Slack = Latest finish Earliest finish e.g. for F it would be 20 15 = 5 Slack can also be calculated by: Latest start Earliest start 11 6 = 5 Repeat for all nodes Diagram Complete!!

34

INF308J/102

5.2

Unit 6: Risk management

The chapter in the textbook that corresponds to this unit deals with the very important topic of risk identification and management when confronted with the development of software projects. Study Chapter 7 in the textbook carefully and ensure that you understand, and can apply, the different topics introduced.

Unit 6 objectives:
The aim of Chapter 7 of the textbook is to introduce the following concepts: the nature of risk; types of risk; management of risk; identification of risk; analysis of risk; reducing risk by means of planning and control; evaluating risk to project schedules; and calculating Z values.

Unit 6 outcomes:
After studying Chapter 7 of the textbook, you will be able to: identify the factors putting a project at risk; categorise and prioritise action for risk elimination or containment; and quantify the likely effects of risk on project time-scales. One method that is mentioned in this section is the PERT method. The difference between the CPM and the PERT methods is that the CPM uses a single estimate for the duration of each task, whereas the PERT method uses 3 estimates. These 3 estimates include: Optimistic (a) Most Likely (m) Pessimistic (b)

These 3 estimates are combined to calculate the te values. The formula is depicted below:

35

INF308J/102

te = a + 4m + b 6
After the te values are calculated, the standard deviation(s) can be calculated using the following formula:

s = b-a 6
The next step is to calculate the z value. The formula to calculate the z value is depicted below:

z=

T - te s

Remember that the T value is the target date of the specific project and the z value is calculated on the last activity. Consider the following example: In the table below the optimistic, most likely and pessimistic values are shown. The table also indicates the expected and standard deviation. The Target date is 17. Optimistic (a) A B C D E F G 2 5 3 1 2 1 2 Most Likely (m) 3 6 4 3 2 3 4 Pessimistic (b) 4 8 5 4 3 5 5 Expected (te) 3 6.2 4 2.8 2.2 3 3.8 Standard Deviation (s) 0.3 0.5 0.3 0.5 0.2 0.7 0.5

The te and s values are indicated in the figure below.

36

INF308J/102

Calculating the s value of activity 4. Path B+D: and Path A+C:

(0.5) + (0.5) = 0.7 (0.3) + (0.3) = 0 .4

Path B+D has the greater answer. Therefore the s value of activity 4 is 0.7. Calculating the s value of activity 5. Path (B+D) + E =

(0.7) + (0.2) = 0.7

and Path F = 0.7 (from the table).

The answers are equal, therefore the s value of activity 5 is 0.7. Calculating the z value: z = 17 - 15 / 0.9 = 2.2 According to Figure 7.8 on page 181 of the textbook, the probability of not meeting the target date is less than 10 %.

6. SECTION 3
Software Project resources, monitoring, control and estimation
This section of the tutorial letter deals with the work covered in Assignment 03, namely Chapters 8, 9 and 5 of Hughes and Cotterell. A topic of importance in software project management is how to identify resource requirements and the subsequent allocation of resources to different tasks. We will also study effective ways of monitoring and controlling software projects. Lastly we consider the importance of accurate estimation of the costs involved in developing software projects. Most software projects are very expensive to develop, and any organisation undertaking the development of a software system should, in the light of the many failed expensive software systems, undertake to minimise potential losses. Software effort estimation plays an important role in assisting an organisation to decide whether or not to proceed with the development of a software project. You will be introduced to different software estimation techniques such as function and object point analysis, procedural code and COCOMO, to name but a few. Each of the 3 units in this section corresponds to a chapter in Hughes and Cotterell. For example, Unit 7 corresponds to Chapter 8, Unit 8 corresponds

37

INF308J/102

to Chapter 9 and Unit 9 corresponds to Chapter 5. Study this section of the work carefully, complete Assignment 03 and hand it in on or before 17 July 2010.

6.1

Unit 7: Resource allocation

During the development phase of a project, the need will arise for various types of resources at different times. Ensuring the timely delivery of these resources to the project development team is of great importance, as late delivery will most probably mean that the project development will fall behind schedule. Study Chapter 8 of the textbook, which deals with resource allocation.

Unit 7 objectives:
The aim of Chapter 8 of the textbook is to introduce the following concepts: the nature of resources; identification of resource requirements; scheduling of resources including: o creation of critical paths, and o counting cost; being specific; publishing the resource schedule; cost schedules; and the scheduling sequence.

Unit 7 outcomes:
After studying Chapter 8 of the textbook, you should be able to: identify the resources required for a project; ensure that the demand for resources is more evenly distributed throughout the life of a project; and produce a work plan and resource schedule. Consider the following example on cost and resources: The third month of a seven-month project has just been completed and actual figures (in personmonths) are given in the table below: Month 1 2 3 4 5 6 7 1. Budgeted effort 11 15 20 20 16 13 5 Value completed 5 7 11 Actual effort 7 8 12

What percentage of work should be completed at this stage, according to the original plan?

38

INF308J/102

2. 3. 4.

What percentage of work is actually complete? What percentage of the total budget has been expended? What do these figures tell us about the project?

Solutions to this example: 1. Total budget Budget months 1 to 3 Estimated % complete (46 / 100 * 100) Total budget Value completed months 1 to 3 Estimated % complete (23 / 100 * 100) Total budget Actual effort months 1 to 3 Estimated % complete (27 / 100 * 100) 100 46 46 100 23 23 100 27 27

2.

3.

4.

The project is late with regard to completion: 23% actually completed ( = value completed during month 1 to month 3 = 5+7+11 = 23) versus 46% planned completion ( = budgeted effort = 11+15+20 = 46). Estimating 15% low: 23% of the work is actually complete (refer q.2) and 27% of the budget has been spent (refer q.3). Not too much has been overspent, i.e. the budget was estimated (27-23)/27 * 100% = 4/27 * 100% = 15%. Resource allocation seems to be the main culprit: 27% actually spent versus 46% planned. Seeing that the budget has only been underestimated by 15%, it doesn't seem to be a problem. The only other alternative to the work being so far behind schedule is that resources are a problem. (for example, too few staff, incompetent staff, incorrectly allocated staff, etc.). Insufficient resources have had a much greater impact than under-estimating.

6.2

Unit 8: Monitoring and Control

Chapter 9 of the textbook, which corresponds to this unit, deals with monitoring and control of a project, as well as change requests. Study Chapter 9 of the textbook.

Unit 8 objectives:
The aim of Chapter 9 of the textbook is to introduce the following concepts: creation of a framework; collection of data; visualising progress; cost monitoring including: o earned value, and o prioritisation; getting the project back on target; and change control.

39

INF308J/102

Unit 8 outcomes:
After studying Chapter 9 of the textbook, you should be able to: monitor the progress of projects; assess the risk of slippage; visualise and assess the state of a project; revise targets to correct or counteract drift; and control changes to a projects requirements. Example: Consider a six-person project that has been running for 15 months. The original estimate for the duration of the project was 18 months and for the first 12 months it kept to schedule. However, three months ago Amanda, the project manager, left the company and the project is now about two months behind schedule. (All other team members have been with the project since it started.) The company management told the new project manager, Peter that two graduates will be joining the company directly from university in one weeks time and he could use them on this project to help get it back on schedule, if he wanted to do so. 1. 2. What are the various factors Peter should bear in mind while considering this offer? In terms of completing the project as soon as possible, what should Peter do?

Solution to example: 1. What should Peter bear in mind? More often than not adding people to a late project has the potential to make it later. This is caused mainly by learning time (specific system and technology used) and the increased communication overhead. Is the team divided into subteams to start with? If it is a single team, six people already constitute quite a large team and two more will likely make the communication overhead worse unless the team can be divided into clearly identifiable and contained subprojects. Consider the answer to the following question: Is the work technically complex, or are there sections where the new graduates can perform with little technical training, with little knowledge of the rest of the system, and that existing team members do not depend on in order to complete their work? If the answer to this question is yes, the addition of the two graduates may offer some potential for getting the project back on track. A no answer, however, may mean that the two new team members may have little or no impact on the effort to try and get the project back on track, and the project manager will have to consider the deployment of the two new team members carefully. Peter should also consider whether the delivery date of this project is critical, and to what extent, or even whether it will be possible that a further delay be tolerated in order to provide a training opportunity for the new graduates. What should Peter do? Use new graduates only with favourable responses to the above. Support the existing team as far as possible by: minimising interruptions,

2.

3.

4.

1. 2.

40

INF308J/102

if not too late already, provide necessary tools that the team may believe to be beneficial, and boost morale.

6.3

Unit 9: Software effort estimation

This unit deals with the very important topic of software effort estimation, and you will be introduced to various software estimation techniques. Study Chapter 5 in the textbook carefully and ensure that you understand, and can apply, the different techniques.

Unit 9 objectives:
The aim of Chapter 5 of the textbook is to introduce the following concepts: when and where software estimation is done; problems with estimation with reference to over- and under-estimation; the basis for software estimation; and software estimation techniques including: o expert judgement, o analogy, o function points (Albrecht and Mark II analysis), o object points, o procedural code, and o COCOMO.

Unit 9 outcomes:
After studying Chapter 5 of the textbook, you should be able to: avoid the dangers of unrealistic estimates; understand the range of estimating methods that can be used; estimate projects using a bottom-up approach; count the function points and object points for a system; estimate the effort required to implement software using a procedural programming language; and understand the COCOMO approach to develop effort models.

Extra reading material:

The function point methodology is not explained clearly in the textbook. We include additional notes on function points and some examples in the remainder of Unit 9. Hughes and Cotterel describe two function point methodologies. The first is the International FP User Group (IFPUG) methodology. This methodology superseded the original Allan Albrecht Function Point methodology. The second is the Mark II function point methodology, which is often referred to as an alternative to the IFPUG methodology.

41

INF308J/102

Function Point Methodology:

Purpose of function point analysis: * * * * * * It determines the size of the software application or project in order to estimate the time and effort required to complete it. It measures productivity in function points per staff or calendar month. It estimates the cost of changing systems. It evaluates support requirements. It monitors outsourcing agreements. It normalises the comparison of software modules.

Determining the function point count: In order to accomplish the purpose of the function point methodology above, Garmus D, & Herron D, [2]; suggest the following steps to size function points: 1. 2. 3. Determine the type of function point count. Is it a new development, an enhancement, or an existing application that has to be counted? Identify the counting scope and application boundaries. Identify all: 3.1 IFPUG - Data functions (internal logical files and external interface files) and their complexity; 3.2 Mark II - Logical Transactions (LT). Identify all 4.1 IFPUG - External user types also referred to as transactional functions (external input, external output, and external inquiries) and their complexity. 4.2 Mark II - Functional size of each input, output & process transaction associated with each LT. Determine the unadjusted function point count. Determine the value adjustment factor. Calculate the value adjustment factor.

4.

4. 5. 6.

These seven steps can be loosely grouped into two distinct phases: steps 1 to 5 focus on the counting of a project or applications function points, whereas steps 6 and 7 adjust the value of these function points. We will limit the discussion below to steps 2 to 5 in order to illustrate the application of both methodologies. Application of steps 2 to 5 in the IFPUG function point methodology: Step 2 - Determine the project or application boundary: The project or application boundary identifies the border between the application being measured, the users and the external applications. In IFPUG, the boundary is based on the scope of the project as seen by the user. Garmus & Herron [2] recommend that boundaries should not be established at the individual software program level, but at a higher application level such as system level. Steps 3 and 4 The IFPUG 4.0 methodology analyses software requirements or user functionality relative to five component types, two of which are data-related and the remaining three are transaction-related.

42

INF308J/102

Step 3 - Identify the data-related components: * * IFPUG makes use of two data-related components. The classification of the data into Internal Logical files (ILF) or External Interface files (EIF) depends on whether the maintenance of the files (or database) falls within the project or application boundary or outside the boundary. From the above it is clear that EIF and ILF are mutually exclusive, contrary to the information contained in the textbook. Refer to page 114. A file can therefore not be classified as both an ILF and an EIF.

Internal Logical File types (ILF) * An internal logical file type (ILF) is a group of logically related data elements maintained within the boundary of the application. The primary intent of the ILF is to hold data maintained through one or more elementary processes of the application being counted. [2] * Each file or database can consist of subgroups referred to as record types. If different processing logic is required for each record type, the record types are counted separately. * The complexity of the file is determined by assigning each file a functional complexity of low, average or high; based on the number of data element types and record element types associated with the ILF according to Table 5.3 on page 115 of the textbook. External Interface File types (EIF) * IFPUG defines an external interface file type (EIF) as a group of logically related data elements referenced by the application but maintained within the boundary of a different application. The purpose of the EIF is to hold data referenced through one or more elementary processes within the boundary of the application counted. An EIF for an application must be an ILF in another application. [2] * The complexity of the EIF file is determined by assigning each file a functional complexity of low, average or high; based on the number of data element types and record element types associated with that EIF according to Table 5.3 on page 115 of the textbook. Step 4 - Determine the transactional functions: External Input transactions (EI) * An EI is a user-generated input transaction that: - Enters from outside the project boundary. - Processes data or systems control information. - Maintains one or more ILFs and/or changes the behaviour of the system. * The following table is used to determine the complexity rating of the EI based on the number of data types and number of file types (ILF and EIF) accessed by the EI.

External Output transactions (EO) * An EO is an: - elementary process of the application that generates data or control information that exits the boundary of the application. - The primary intent of an EO is to present information to a user through the retrieval of data or control information from an ILF or EIF. - The processing logic must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILF's, or alter the behaviour of the system. [2] * The number of data and file types referenced determine the complexity of an EO. Refer to Table 5.5 (see below). External Inquiry (EQ) * An External Inquiry (EQ): - Consists of an input/output pair that crosses the boundary. - Results in retrieval of data or control information that is sent outside the application boundary.

43

INF308J/102

* *

- The primary intent is to present information to a user through the retrieval of data or control information from an ILF or EIF. - The processing logic contains no mathematical formulas or calculations and creates no derived data. No ILF is maintained during processing, and the behaviour of the application is not altered. [2] The classification of transactions as EI and EO or EQ is mutually exclusive. The complexity of an EQ is determined by establishing a complexity rating for both the input and output part of the enquiry separately as per Table 5.4 and 5.5 (see below). The higher complexity rating is chosen as the complexity score for the EQ.

Step 5 - Determine the unadjusted function point count: * * Based on the complexity rating derived for the five component types, Table 5.2 on page 115 of the textbook is referenced to determine the function point score for each component or external user type. The function points are summed to give the total IFPUG unadjusted function point count for the project or application being sized.

Application of steps 2 to 5 in the Mark II function point methodology The Mark II (Mk II) methodology assumes a model of software where all user requirements are expressed in terms of Logical Transactions (LT). Each LT comprises an input, some processing and an output component. An LT is triggered by an event outside the systems boundary, such as a request for information.

44

INF308J/102

Step 2 - Determine the project or application boundary: * As with IFPUG, the boundary of the project or application must be established. The boundary determines which logical transactions are to be included in the count, as well as the interfaces required to link to LT outside the application boundary.

Step 3 - Identify the Logical Transactions (LT): * * * * Logical transactions are the smallest complete units of information processing that are meaningful to the end user. As an example, Maintain Customer Details is not the lowest-level business process, but implies a series of LT such as View an existing item, if Not Found add a new item, Change the viewed item or Delete it, etc. Each LT consists of three components: input across an application boundary, processing involving stored data within the boundary and output back across the boundary. Each LT must be self-contained and leave the application in a consistent state.

Step 4 - Identify and determine the functional size of the three components of each LT: The processing component of the LT * The processing component of each LT is analysed by: - referencing its manipulation (i.e. create, read, update, list or delete), - stored data expressed logically as primary and primary entity subtypes in third normal form. * A primary entity type is: One of the main entity-types which has the attributes that the application has been designed to process and/or store. [5] Example: An Employee would be an entity type in a Personnel system. * The primary entity type may consist of primary entity subtypes. It is a subdivision of an entity type which has all the attributes and relationships of its parent entity type, and may have additional unique attributes and relationships i.e. the Employee entity may consist of Personal, Work Experience and Job History detail with different processing rules. Subtypes are counted separately, depending on the processing logic used. (Subtypes can roughly be compared to IFPUG's record types.) * The processing component of a LT is sized by counting the number of primary entity or sub-entity types that are referenced by the LT. Input and output components of LT * The input element consists of the retrieval and validation of incoming data, such as a request for information or data input by the user. * The output element consists of formatting and presentation of information to the user. * The input and output components are sized by counting the number of data element types crossing the application boundary (inside and outside). * A data element type is a uniquely processed item of information that is indivisible for the purposes of a LT being sized. Step 5 - Determine the unadjusted function point count: * * * The functional size of a LT is the weighted sum of the input, processing, and output components of the LT. The industry standard weights are as follows: Wi=0.58, We=1.66 and Wo=0.26. The sum of all LT determines the Mark II FP count.

A comparison between Mark II and IFPUG function point methodologiesGeneral:

45

INF308J/102

1. IFPUG has a user base exceeding 1200 member companies in the USA. Mark II is mainly used in Europe and the UK. Although Mark II had some advantages over the initial Albrecht FPA, IFPUG has been enhanced to such an extent that the advantages have largely disappeared. 2. One aspect in which Mark II offers more refinements is in the area of Technical Complexity Adjustment factors. Both techniques use similar approaches to adjust for qualitative requirements. They also use a list of non-functional system characteristics which are evaluated on a scale from 0 (no influence) to 5 (high impact). IFPUG uses 14 factors whereas Mark II adds another five to IFPUG's already existing 14, and also allows practitioners to add more to the list. 3. Both methodologies express functional requirements in terms of Base Logical Components (BLC). Mark II uses a single type of BLC and expresses all functional requirements as a catalogue of LT. IFPUG uses five BLC types namely EI, EO, EQ, ILF and EIF. 4. Both focus on logical business requirements. 5. Both define specific rules with regard to the boundary. 6. Both derive base counts, the difference being in how the counts are constructed (refer to the previous sections). In Mark II, the base counts are used directly in the calculation of the functional size index. In IFPUG the base counts are used to determine the complexity (high, medium or low) of each BLC. 7. Weighting - in Mark II, three different weights are used which add up to 2.5, so as to correspond to IFPUG function points. The weighing values have been calculated and are periodically validated, from historical data of numerous projects in a number of large development organisations. These values may be calibrated. 8. Weighting - in IFPUG FPA the weighting system is more complex due to the larger number of BLC types. Owing to the classification used, IFPUG's weighting system has a distinct upper limit, which has an impact on the calculation of FP for complex systems. * Various differences in detail exist, i.e. the handling of error messages and control information. These differences are not considered vital for our understanding of the concepts and are therefore ignored.

A comparison between Mark II and IFPUG function point counting in particular: When the Mark II weighting scale was first developed, the aim was to produce sizes, which were comparable to those of the IFPUG FPA scale. As a result of this pegging process, for the range of 200-400 IFPUG UFP (unadjusted function points), the two scales should on average give the same size, once converted. If the IFPUG raw data is available, an additional analysis is made to map the file types of IFPUG to entity types and IFPUG's transaction types to Mark II's LT types. Based on this, the Mark II FP size for the same software can be calculated. The FP size relationship for larger applications requires more complex calculations [6]. Examples to illustrate IFPUG FPA and Mark II FPA: The question discussed here is similar to Question 7 of the Additional Exercises given on page 115 of the textbook. Particular detail:

46

INF308J/102

A program in the College Time-Tabling system produces a report showing students who should be attending each time-tabled teaching activity per semester. The report is produced by an online request. The following information is input: o course code and o semester number. The request does not update files. The report is printed on the local printer. Information printed on the report includes: o course code, o course description, o location, o days of the week course is presented, o time of course presentation, o student numbers, and o student names who have enrolled for the course. No calculations are made for the report. Information is extracted from the following files (data groups):

System Timetabling system

File Time-tabling file. The file is wholly maintained within the boundaries of the Time-Tabling system (of which the report forms part). The Student detail file is maintained fully by the Student system and is read by the timetabling report.

Record Types The file consists of 2 data groups (record types): one contains location data and the other contains course data.

Data Entity Types All the course information is extracted from this file, i.e. location, course code and description, days of the week course is presented, time and duration.

Student system:

The file consists of 3 data sets For the report, student number, (record types), i.e. general name, course code are extracted student detail, course detail and from this file. financial detail.

Questions: Calculate the UFP using the IFPUG methodology. (Error messages can be ignored for counting purposes.) Convert the FP count into SLOC for a C system. Calculate the cost to the University to produce the report, if the programmer who is responsible for producing the report, is charged out at R 500 per day. Calculate the UFP using the Mark II methodology. counting purposes.) (Error messages can be ignored for

47

INF308J/102

Solution: Step Define the boundary Identify all data functions Identify all transactional functions

Calculate the UFP using the IFPUG methodology. Analysis The boundary of the report is the time-tabling system. All files updated within the borders of the time-tabling system will be regarded as Internal Logical Files (ILF); all other files will be regarded as External Interface Files (EIF). ILF: The Time-Tabling file is an ILF. It lies within the boundary of the Time-Tabling system and is maintained only by that system. EIF: The Student details file is external to the time-tabling system as it is updated solely by the student system. It is used in a read-only capacity by the report. External Input - The request for the report is not an EI. To classify as an EI, the request must update one or more ILF or change the behaviour of the system. External Output - The report does not classify as an EO transaction. For an EO, it must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILF, or change the behaviour of the system. External Inquiry - The input and output parts of the report request comply with the EQ rules. The primary intent of the input request is to produce a report without updating any ILF. The report printed likewise does not update any ILF nor does it perform any calculation or print any total.
Name Time Tabling Student Request Report TOTAL: Record/ File Types 2 Record Types 3 Record Types 1 Time Tabling 2 Time Tabling & Student Data Types 6 3 2 8 Table 5.3 5.3 5.4 5.5 Rating low low low average Value Table 5.2 7 5 Greater of two ratings selected: 'average' IFPUG FP 7 5

Transaction ILF

Determine the unadjusted function point count

EIF EQ -Input EQ -Output

4 16 IFPUG FP

Solution: Converting the UFP to SLOC for a program written in C. According to steps 6 & 7, technical complexity factors can be applied to the UFP before converting it into SLOC. In our case, the unadjusted (raw) FP will be used. Depending on the programming language used, the FP can be converted into SLOC. This is a measure of the size of the program or system. The SLOC represents time and cost. For example, it may be possible for a Programmer to write 100 SLOC per day. Using this, the Project Manager can calculate the cost of new or enhancements to existing systems. According to page 103 of the textbook, 1 IFPUG FP translates to 128 C lines of code. Therefore: 17 FP = 16*128 C LOC = 2048 C LOC Solution: Calculate the cost to produce the report. The SLOC must be converted into code per day. If the Programmer can write 100 tested LOC per day, then: 2048 / 100 = 20.48 20.5 days to write the report. Cost to the University: 20.5 days * R 500 per day = R 10 250.00

48

INF308J/102

Solution: FP calculation according to Mark II Function Point Methodology. Step

Define the boundary of the count. Identify logical transactions. Identify and categorise the data and entity types. Identify the input and output components of LT. Calculate the logical transaction size in Mark II function points.

Analysis
As for IFPUG. Determining the boundary determines the logical transactions to be included in the count, as well as any interfaces across the boundary. A LT consists of an input, output and process part. It is the lowest process supported by the application. In our case, we are dealing with one LT, which will produce a report with data from the Time-Tabling and Student entities. This is essentially a LIST transaction in Mark II terms. Mark II refers to entity types in third normal form. Each occurrence of such an entity type must be counted. The Student file consists of 3 data entity types and the Time-Tabling file of 2 data entity types. The input transaction consists of an inquiry, containing two data element types. The output transaction consists of the report, containing 8 data element types. (The error message is ignored in this Question). Type: Entity Types: Mark II Weight: Mark II FP: Input 2 data 0.58 1.16 Process 3+2 1.66 8.30 Output 8 data 0.26 2.08 Total 11.54

Latest Developments on the FP Front. Modern IT practitioners may think that these productivity methodologies are more at home in a traditional third-generation environment. However, some of the latest software measure-ment tools such as COSMIC FFP are based on principles determined by IPFUG and Mk II and set out to measure and estimate complexity of multi-tier, multi-layer software architectures [7]. References used in compilation of Unit 9 - Extra reading material: [1] Burn-Murdoch, M J. Issues with IFPUG Counting Practices. Version 4. Software Measurement Services. http://www.gifpa.co.uk [2] Garmus, D. and Herron, D. 2001. Function Point Analysis: Measurement Practices for Successful Software Projects. Addison-Wesley. [3] Garmus, D. Function Point Counting in a real-time Environment. David Consulting Group. [4] Mark II FPA Counting Practices Manual CPM1.3.1, website address: http://www.uksma.co.uk/html/cpm_1.31.html [5] Rule, G. A Comparison of the Mark II and IFPUG Variants of Function Point Analysis. Software Measurement Services, website address: http://www.gifpa.co.uk//library/Papers/Rule/MK2IFPUG.html [6] Software Measurement Services, Conversion between IFPUG 4.0 and MkII Function Points, Version 3, 24 Aug 1999. [7] Software Measuring Services, The Power of Cosmic FFP, Issue 8, Spring 2001. http://www.gifpa.co.uk/news/8/p2 cosmic.html

UNISA (2010)