A simple way to software sizing measures

There are different ways of measuring the size of software applications, such as measuring lines of code or functions points. With lines of code the size is measured after the application has been built. This approach is dependent on the technology used to build the application, its design and the programming languages used for code. Applications coded using different programming languages cannot be easily compared and this might compromise efficient code.

With function Points the size is a measure of delivered functionalities that is relatively independent of the technology used to develop the application, and it's measured from the user's perspective. Therefore, sizing the application is done by counting external data (inputs, outputs, interfaces, files and inquiries); this might not be so intuitive and difficult to communicate.

A simple way to size an application is to use a more intuitive approach. This is analogous to function points approach, but it's made more simple by using parameters in an approximative way. For example, during the analysis phase, it's possible to capture information related to the number of use cases, user interfaces, reports, rules/algorithms, and data tables needed for a particular application. Each component (i.e., each UI, each UC, each Report, etc...) is multiplied by the estimated effort needed to build it. This operation is done for all components, and a total effort is calculated and easily converted into costs.

Project Cost


Project cost is defined as the approximate (estimated) cost of all resources (people, materials and equipment) consumed by the performing organization necessary to achieve the project deliverables.


If a WBS (Work Breakdown Structure) scenario is used to contain information related to resources, estimated effort and activity duration, then, if costs are added to the WBS, it could represent the project cost center. In organizations the administration-finance department will supply an average cost per hour or per day of different types of resources. These rates would represent their average salary rate plus company burden, overhead and profit margins.

In for some reason, it's not possible to post rates against resources (because of company policy), then it's possible to calculate the cost of the project on a person day basis. 

For example: 1 person day = 8 effort-hours = 1 day (8 hours) x 100% (1 person)

In general: Resource Effort (or Work) = Time Elapsed (or Duration) x Percentage of Utilization (or Units)

This cost estimating process will help to verify which portions of the project can be kept in-house versus work that can be farmed out for cost saving measures.

If the WBS is loaded with the cost and the activities scheduled, it's possible to conduct financial time phased analysis (Cash Burn Rate Analysis: that is, measure the rate of negative cash flow (cash going out > cash coming in), over a given period of time). This is important particularly for large projects that require multi year financing.

Using PERT for estimating tasks


A simple way for estimating tasks is to use the PERT (Program Evaluation review technique) weighted average method. This method uses a weighted average duration estimate to calculate task duration, it gives the opportunity to take into account information based on different types of estimates values (such as poorly defined areas, probabilistics, and ranges for the schedule). This method is based on the Beta distribution model because it can model events which are constrained to take place within an interval defined by a minimum and maximum value. (For this reason, the Beta distribution is used extensively in PERT, CPM and other project planning/control systems to describe the time to completion of a task).



The term weighted average means that the equation uses weighted factors to calculate the expected task duration.

The equation and process modelling a task for PERT is the following
E=(O+4M+P)/6 (equation) 
E= Expected Value 
O= Optimistic Value (this is equivalent to a minimum value) 
M= Most Likely Value 
P= Pessimistic Value (this is equivalent to a maximum value)

(i) Fist, acquire estimates for the pessimistic value, most likely value and optimistic value time to completion. For example, let's suppose that: P=20 programmer days M=12.5 programmer days O=10 programmer days

(ii) Then, using the "PERT Weighted Average" equation: E=[(10+4(12.5)+20]/6 = 13.333 programmer days = expected task duration = mean value

The Needs/Requirements Life Cycle

Specifying what the project should accomplish is not an easy task and is not to be taken for granted that everything is clear. It's easy to misunderstand requirements and transform the whole project into a tragedy.

What causes the need for requirements?

Well, something has to happen to trigger it...maybe a cause-effect situation, or a change request for something or an action that causes some changes. 

For example, let's suppose tha a legal company expands its offices throughout the nation, and as a result they need to enhance their information system and improve communication perfomance. From this situation a need emerges and, in order to meet these needs (system and human), it must be recognized through conscientious effort. Asking questions (from both points of views: ours and the customer) on the cause and, consequently, on the need will help, and it might be best to establish procedures for identifying these needs in a systematic way. Also, it's important to give special attention to focusing on anticipating needs, and not just on the existing needs. Anticipating needs can be accomplished with a two-hour brainstorming session. This session is useful to develop ideas of what future needs might be. This forecasting is called scenario building.

Once the need is recognized, it must be clearly articulated. This entails an in-depth scrutiny of the recognized need. Look also underneath the surface, so as not to lose sight on reality. The face value is fine, but don't neglect the rest. Articularing the need has a practical side too: it serves as the basis for the developement of functional requirements, by stipulating in concrete terms what has to be done to achieve it.

To minimize the risk of doing a poor job in articulating the need, it's best to:
(i) ask those who have the need to define it as clearly as possible,
(ii) ask a full set of questions about the need (information, curiosity, data,...),
(iii) carry out whatever research is necessary to better understand the need,
(iv) in view of insights gained in the first three steps, try to formulate the need the best way you can,
(v) ask the customer to respond to the formulation of the need and revise accordinly.

Carry out the above steps only by working closely with the customers, getting their reactions to the newly articulated needs, and revising the needs statement to reflect customers desire.

After the needs have been carefully defined, it's possible to use them as the basis for developing a project plan. This is done by formulating the needs as functional requirements.

Functional requirements describe the characteristics of the deliverable in ordinary non-technical language, i.e., what emerges from the project. Here it's possible to use graphic images to strengthen its contents.

They should be understandable to the customers, and customers should play a major direct role in their development.

While functional requirements are designed to assure that customers know what they are getting out of a project, technical requirements are written for the technical staff. They describe the features of the deliverable in detailed technical terms (such as physical dimensions and performance specifications). They offer project staff guidance on what they should be doing on the project. Because of their technical nature, technical requirements are often incomprehensible to the customers, who lack the training to know what they mean.

In a software project, for example, the functional requirements may stipulate that a data base system will be developed to allow access to a finacial data through remote access; the corresponding technical requirements would spell out the architecture of the data structure, the language in which the data in which the data base management system will written, the hardware on which the system will run, telecommunications protocol that should be used, and so forth....

Hence, project requirements are important for two reasons
(i) They are a tangible embodiment of the customer's needs (needs emerge, needs recognition, needs articulaton, and then they are translate into requirements, which serve as the basis for the project plan). This will reduce the effort of determining how best to meet requirements.
(ii) Requirements are important because they define the project team's obligation to the customers.

They also describe the team's responsibilites. Projects that run under contracts, the requirements may be written as a statement of work (SOW), and compliance or non compliance with the contract is determined by resolving whether the contractor has fulfilled the SOW.