Project Planning Phase

Consists of:
Project Planning

Estimation

Scheduling

Resource Allocation

Risk Analysis Risk Resolution

Effort

Cost

Time

HW / SW Res Alloc

Human Res Alloc

Estimation
Effort = The amount of work involved in a project = no. of people x time

Units man-days, man-hours, man-months etc. E.g. if a project takes 6 people 100 days to complete, then the effort estimate is 600 mandays = 600*8 man-hours (considering 8 hours of work per day) = 600/23 man-months (23 working days per month). There are many methods of estimating the effort from the given requirements, some of which will be covered here. The very first thing determined in project planning is effort estimate. After the effort is known, the cost and time can be easily calculated. Also, scheduling of the work and resource allocation can be done.

Tasks Involved in Software Development

The following tasks are involved in the development of each screen, report, object, DB table etc. Each task takes time according to the complexity of the item. So, you cannot say that you will make one screen for displaying data within 1 or 2 hours. If you do so, then that item will not do most of the important functions. You need time for each of the following:

Tasks Required for Screen Coding:

1. Screen layout design

2. Input data validation, (e.g. valid phone number, email address, numeric fields, date

etc) 3. Output data formatting (e.g. currency format, date format etc.)
4. Calculation of auto-calculated fields, such as totals etc, 5. Database queries for displaying a list of records, for displaying each record, for

inserting a new record and for updating an existing record, and for deleting records
6. Code for Functions for each button on the screen. Enabling and disabling of buttons

in different states 7. Any other business logic and calculation formulas 8. Field tab sequences

Tasks Required for Report Coding

1. Search Parameter Screen for each report to input the search fields 2. Output data formatting 3. Very complex database queries to search, collect information from the whole database, perform calculations and output the required results (business logic and calculation formulas) 4. Report layout design 5. Drill-down features, such that if you click on one number or item in a report, it opens another report showing the details or calculation of that item.

Tasks Required for Object Coding

1. Object Definition 2. Code for all of the object functions (business logic and calculation formulas) 3. Constructors and destructors 4. Getter and Setter Functions 5. Access restrictions

Tasks Required for Database Tables

1. Table creation 2. Table relationships 3. Table and field properties (e.g. nullable, unique, valid ranges of values etc) 4. Access Restrictions

5. Creation of views, indexes, and other fast access methods

Tasks Required for Procedures and Functions Coding

Can be object functions, structured programming functions, or database procedures/functions 1. The entire complex business logic and calculation formulas which need to be implemented 2. Can be thousands of lines, and can all several functions to do parts of the work

External System Interfaces

Perform data input from or output to other external systems, which are not part of this system, e.g. purchasing and sale systems need to post financial vouchers in the accounting system, and stock update records in the inventory system. If all these are separate systems, then external system interfaces are required. These can be in some standard format, such as web services, CORBA etc, or any other remote API, in which one system can remotely call the functions of another system, or can be through writing the necessary information into temporary database tables from which the other system reads it, or can be through generation of text or binary files of the information, which are read by the other system. In every case, the system running on one machine needs to either call functions of or access data written by another system running on another machine

Effort Estimation Method 1: Based on Screens, Reports, Functions

This method estimates the programming effort required for the known number of items to be developed, and uses percentage distribution of effort to estimate the work in all other phases of software development The following are the numbers of items to be developed in a project or in a module of a project. These can be easily obtained from the requirements. (the estimate can be module-wise or of the whole project) (numbers are only examples, you fill the numbers for your own project)

Number of Items to be Developed

Item Screens Reports Objects Functions or Procedures Database Tables External System Interfaces Anything else Simple 5 8 12 Medium 10 5 15 Complex 3 10 20

Count the number of simple, medium and complex items required from the software requirements and design, and fill the above table.

The effort estimate for each item

Again, these are examples. You fill in the number of man-days required by your team for the specific technology you are using)

Item Screens Reports Objects Functions or Procedures Database Tables

Simple (man-days) 1 1 1 1 0.25

Medium (mandays) 2 2 2 2 0.5

Complex (mandays) 4 4 4 4 1

External System Interfaces Anything else

3 ?

5 ?

10 ?

Total Coding Effort

Multiply the numbers in table 1 and table 2 to get the total effort. Add for all items and for simple, medium and complex. e.g. screen effort = 5*1 + 10*2 + 3*4 man-days

Effort for all Phases

Use a percentage breakdown of effort for all phases. The below is only an example. Fill the percentages which are suitable for your team and your type of project.

Phase Requirements Specifications Project Planning Project Management Architecture Design Coding Integration User Documentation QA Total Add time for other activities, such as deployment, training, client acceptance testing etc.

% effort 8% 8% 8% 8% 4% 12% 24% 4% 4% 20%

Example with Coding effort = 100 man-days 33 33 33 33 17 50 100 17 17 83 417

Suppose the total coding effort for a project is 100 man-days. The table above shows the example results for all other phases The total effort for all phases = coding effort *100 / coding percentage = 100 *100/24 = 417 man-days

The effort for each phase = total effort * phase percentage / 100 = 417 *8 / 100 = 33 man-days

Unless you spend this amount of effort on all phases, a well-designed and good quality software will not be developed.

Function Point Analysis

Definition: Function points are a measure of the size of computer applications and the projects that build them. The size is measured from a functional, or user, point of view. It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application. FP Analysis tries to quantify data in motion and data at rest. The software to be developed has the following components:

Transactional Function Points (Data in Motion) 1. EI External Input a data input screen with record insert or modify functions 2. EO External Output a data / results calculation and display screen or report, with query and view of records and with some calculated results or logical processing 3. EQ External Query a data display screen or report, with no calculated results, but just data queried and displayed from a database, such as a record view and search function

Data Function Points (Data at Rest) 4. ILF Internal Logical File A file or database table for saving the data within the system 5. EIF External Interface File a file or table belonging to an external system, from which our system accesses and uses the data. The responsibility of inputting and maintaining data in the EIF is of the external system. Our system only reads and uses the data of the EIF. E.g. if a purchasing system needs the account codes for billing, it reads the account codes from the accounting system. The account codes belong to, and are saved and modified by the accounting system, not by the purchasing system. For the accounting system, they are an ILF, but for the purchasing system, they are an EIF.

If a single screen has read as well as write functions insert, modify, view, search, then it will be counted as both EI as well as EO or EQ (i.e. either EI and EO, or EI and EQ).
A screen cannot be counted as both EO and EQ. If it has any calculated + queried

data, then it is counted as EO, otherwise if it has only queried data, then it is counted as EQ.

The above components can have the following characteristics: 1. DETs Data Element Types. All of the above components can have DETs.

1.1. For screens (EI, EO, EQ), DETs are the data fields + Error Messages + 1 DET for

all of the buttons on the screen, including 1 DET for each calculated value.
1.2. Each error message that the screen can produce, (e.g. each validity check of

the fields) counts as a DET. 1.3. A group of radio buttons, that together present a single choice field count as one DET. However, separate check boxes which provide independent choices count as separate DETs. 1.4. 1.5. All command buttons on the screen together count as a single DET. For Reports (EO / EQ), DETs are the no of data fields.

1.6. For tables or files (ILF, EIF), DETs are the data fields

2. RETs Record Element Types. These are the number of logical entities within one file or table. It is a user recognizable subgroup of data elements within a file or table. In case of normalized tables, there is only one RET in each table. In case of un-normalized tables, there can be multiple entities or RETs in one table E.g. Un-normalized sale table: SaleID, SaleDate, SaleType, Customer ID, CustomerName, CustomerPhone, Item, Quantity, Price, Total. This contains 3RETs: Sale, Customer, and Sale Items.

3. FTRs - File Type Referenced. A FTR is a file type referenced by a transaction. An FTR must also be a internal logical file or an external interface file. It is the number of logical entities that are used in a transaction.

Examples

1 Item
EI
A

Hawk P ILF

Function Point Calculation

UFP=Unadjusted Function Points

EI Table

Shared EO and EQ Table

UFP

Data Elements 1-4 0-1 2-3 >3 5-15 > 15 Ave Hig h

FTRs Data Elements 1-5 0-1 2-3 >3 6-19 > 19 Ave Hig h Hig h

Rating

UFP EO EQ EI

Low Low Low Ave Ave

Low Low Low Ave Ave Hig h

Low Average High

4 5 7

3 4 6

3 4 6

High Hig h

ILF / EIF Table

RETs 1-19 1 2-5 >5 Low Low Ave Data Elements 20-50 Low Ave High > 50 Ave High High Low Average High Rating ILF 7 10 15 UFP EIF 5 7 10

Value Adjustment Factor (VAF)

14 general characteristics to be ranked by degree of influence from 0-5 Degree of Influence Measures Not Present, or no influence present Insignificant Influence Moderate Influence Average Influence Significant Influence Strong influence, throughout =1 =2 =3 =4 =5 =0

14 General Characteristics:
1. Data Communications 2. Online Update 3. Distributed Functions 4. Complex Processing 5. Performance 6. Reusability 7. Heavily Used Configuration 8. Installation Ease 9. Transaction Rate 10. 11. 12. 13. 14. 15. Result: Total Degrees of Influence(DI) = sum of above factors (total 0 to 70) VAF = 0.65+0.01 x DI (VAF value from 0.65 to 1.35) Adjusted Function Points AFP = UFP x VAF Operational Ease Online Data Entry Multiple Sites End User Efficiency Facilitate Change

Benefits
1. Is a structured technique of classifying components of a system based upon systematic rules.

2. Measures software by quantifying its functionality provided to the user based primarily on the logical design instead of the implementation 3. A standard method for measuring software development from the customers point of view 4. Can be used to size software applications accurately. 5. Can be counted by different people, at different times, to obtain the same measure within a reasonable margin of error. 6. Are easily understood by the non technical user.

Cost Estimation
The basic calculation of cost from effort is simple: Cost = Effort x Rate x any conversion factor E.g. Effort = 100 man-days, Rate = $18 per hour, Cost = 100 man-days x $ 18 per hour * 8 hours per day = $14400. However there are the following 3 modifications to this simple approach.
1. For different tasks/phases of the project, the rates can be different, depending on

whether senior or junior persons perform these tasks. So, their effort should be totaled separately and multiplied by their own rates e.g. Phase Requirements and Specs Rate $25 per hour Effort 100 man-days 50 100 200 150 50 Cost ?

Proj Planning and $30 per hour Mgmt Design Coding and Integration QA User Documentation $25 per hour $18 per hour $15 per hour $10 per hour

2. If you are making something very new and unique, for which only your software

house has the knowledge and new creative ideas, and which will help the client to save or earn a lot of money, then the price for that work is generally not related to the actual cost or effort of performing the work. Instead the price depends on how much the client will benefit from using this software, or its value to the client. This is called value pricing. E.g. if you provide a very new and unique ticketing system to an airline that enables the airline to save (or earn additional) $ 1 million per year, and no other software house has your new and unique ideas, and if it costs you $200,000 to develop this software according to the actual effort estimate, then you can demand from the client $750,000 for it, because unless the client pays this amount, he cannot save or earn $1 million per year. In this case, the client will be pleased to pay this amount, since he knows he can recover it easily. This is the price not of the work done, but of the intellectual contribution. However, care must be taken to sign confidentiality and intellectual property rights agreements with the client, so that the client cannot take your ideas and go to another cheap software house for development.
3. For bidding, you also need to consider not only how much effort is required in the

project, but also who may be your competitors, and how much they might bid for the project (which is usually a guess). This is because when bidders are equally qualified, the bidder with the lowest price gets the contract. So, if your rate is $18 per hour and your total price is $100,000, then another company bidding $ 99,000 may get the contract and you may lose it. On the other hand, if you think that all other companies concerned will bid over $200,000, then there is no benefit for you

to bid $100,000, since you can also get the contract, as well as more money by bidding higher.

Time Estimate
Again, the basic time estimate is very easy, if the effort estimate is known. Time = Effort / People e.g. Effort 100 man-days, people = 10, time = 10 days. Public holidays and week-ends must be considered in calculating the calendar days. The above is valid as long as the work consists of small pieces which can be easily divided between the team members. (e.g. if 20 screens and 20 reports are to be developed which are not dependent on each other, then each developer can develop X screens and X reports. However, for a large team size, you cannot achieve a very small completion time, e.g. for 100 man-days effort, with 50 people, the work cannot be completed in 2 days. This is because for each person, there is some overhead of understanding the project and the work to be performed, as well as there is communication overhead, which increases as the team becomes larger. So for large team size, the effort estimate increases. E.g. Team Size Effort Estimate (or actual amount of work to be done) man-days 50 50 75 100 Time days 50 10 7.5 5

1 5 10 20

There is no formula for these numbers, and they may be different for your project. They have to be estimated from experience.

The Constructive COst Model developed by Boehm.

Intermediate COCOMO

This is an effort estimation technique based on the lines of code required in a software. If the number of lines of code can be estimated by some other method, then COCOMO gives the effort estimate for those lines of code in man-days. There are 4 types of COCOMO, Basic, Intermediate, Detailed, and COCOMO-II (a revised and extended version) They use different formulas and parameters for effort estimation. For a detailed explanation of all types, See Futrell, Ch. 11. Here, we will study Intermediate COCOMO briefly. Input: KLOC = 1000 line of code Effort E (man-months) = a x KLOCb x fifteen multipliers There are 3 types of projects which have different values of a and b. The definitions and formulas of those types of projects are given below:

Project Type

Code Size

Project Size

Innovation

Deadline and Constraint s Not tight

Developm ent environme nt Stable, wellknown Medium Complex

Organic

2-50 KLOC

Small

Little (wellknown project) Medium Large (new, innovative )

Semidetatched Embedded

50-300 KLOC Over 300 KLOC

Medium Large

Medium Severe

Project Type Organic

Definition Simple systems, small projects, e.g. payroll, inventory, scientific calculation etc More complex systems, larger projects, e.g. operating system, compilers, databases (oracle etc)

Effort Estimate formula 3.2 x KLOC1.05 x fifteen multipliers 3.0 x KLOC1.12 x fifteen multipliers

Semidetatc hed

Embedded

Very complex Real time systems, such as medical, aerospace, military etc.

2.8 x KLOC1.2 x fifteen multipliers

Example, for an organic project, with all multiplying factors =1, it takes 3.2 manmonths for 1000 lines of code, or approx 13-14 lines of code per day. Note that this is the total effort for the project, for all phases not just the coding effort. The effort for each phase can be estimated using the percentage distribution of effort between phases. In many books, the lines of code is called as KDSI (1000 delivered source instructions) instead of KLOC, and it includes counting of each computer instruction separately. There may be more than one instructions in a line, e.g. c=d++ has 2 instructions.

Cost Drivers
The fifteen multipliers in the formula are called cost drivers, which give some multiplying factors depending on certain properties of the project, the language and the team. These factors are all multiplied in the above formula to get the final effort estimate. The cost drivers or multiplying factors are as follows Cost Drivers and Categories Product Attributes Required Software Reliability Database Size Product Complexity Computer Attributes Execution Time Constraint Main Storage Constraint Virtual Machine Volatility Computer Turnaround Time Personnel Attributes Analyst Capability Application Experience Programmer Capability Virtual Machine Experience 1.46 1.29 1.42 1.21 1.19 1.13 1.17 1.1 1.00 1.00 1.00 1.00 .86 .91 .86 .9 .71 .82 .7 .87 .87 1.00 1.00 1.00 1.00 1.11 1.06 1.15 1.07 1.3 1.21 1.3 1.15 1.66 1.56 .7 .75 .88 .94 .85 1.00 1.00 1.00 1.15 1.08 1.15 1.4 1.16 1.3 1.65 Very Low Low Nomin al High Very High Extra High

Programming Language Experience Project Attributes Use of modern programming practices Use of software tools Required development schedule

1.14

1.07

1.00

.95

1.24 1.24 1.23

1.1 1.1 1.08

1.00 1.00 1.00

.91 .91 1.04

.82 .82 1.1

Disadvantages of COCOMO
1. This is not really an estimation method, as you cannot determine the effort from the requirements given. You still need another method to estimate the number of lines of code required. However, lines of code can again be estimated from experience from the number of screens, reports, objects, procedures etc required and their complexity. E.g. how many lines of code are required for a simple, medium or complex screen, report, procedure etc. These can be totaled for all the development items required. 2. The lines of code required for the same task vary greatly with the selected development environment and language, and also the time/effort taken for the same number of lines of code varies with the development environment and language, depending on the automation and facilities in the tool being used. 3. Nowadays, a huge amount of code is auto-generated using a wizard, and only some specific user-defined logic is added by hand. So, the auto-generated code should be excluded from the effort, since it does not take manual effort or time 4. Different developers would perform exactly the same task in different number of lines, e.g. some developers will often combine 2 or 3 lines in one line e.g. if((c=a+ +)==0). So it is very difficult to estimate (a) how many lines of code a particular developer will use for a task and (b) how much time it will take. Comments are often included in the lines of code, and they should be excluded from counting lines of code, so counting the lines of code needs a tool which can analyze the lines and count. However, adding detailed comments also takes some extra time/effort.