11001655

Introduction:

Project measures should be identified and evaluated carefully, insufficient measures and analysis may lead to project incomplete. Many measures not good for the project as it increases complexity and makes analysis confusing. Definition of the measures depends upon type of organisation and project goals. If we do not measure, then there is no way to track our processes or program. Measurement enables us to assess the status of program and processes and determine whether it is in trouble or need any process improvement. Early detection of problems can be done with the help of good measurement program and as it also provides quantitative clarification of complex development issues. Metrics has the ability to identify and resolve critical risk issues before their occurrence. Measurement is important for strategic, program and technical level. Before defining measures, the first task is to established organization/projects goals, then identification of questions and finally identification of measure (Woodword, 2009).

For successful software product development, six commonly used measures are identified which includes, Lines of Code, Defects, Schedule duration, Efforts and Function points. This document includes definition, descriptions, utilization and recommendation of each measures described above. Managers need to work on measures described below for successful product development project: Product Development Measures

Function Points

Definition: The volume of software functionality contained in a application quantified by the unit of measure known as Function point (WOODWORD, Steven M, 2009). It expresses the amount of business functionality in an application program which is provided to the user.

Description: The International Function Point Users Group (IFPUG) provides framework and guidelines for consistent functional sizing of any software. Function point depends upon the functionality of the application using function point like military weapon system, financial applications. Function points are the weighted sum of different factors related to the user requirements.

Five different factors related to the user requirements (ALBRECHT, A.J, 1979):- Inputs- Outputs- Logic- Inquiries- Interfaces

Utilization: We need to develop, enhanced and support the software functionality; function points are the key units to assess project size, managing risk and establishment of estimates. In order to count function points, we need to first tally functions which are inputs, outputs, logic, inquiries and interfaces;

21001655

then multiplied by values established. Product total then adjusted by degree of complexity, which are domain specific and depends upon number of factors.

Simple Average Complex TotalInputs 2X 5X 2 4X 2 18Outputs 4X 1 3X 3 3X 10Inquiries 2X 2X 7X 0Files 4X 7X 1 10X 7Interfaces 5X 9X 3X 1 3Unadjusted function point

= 38

Table: Function Point Computation

Functions points includes many drawbacks like, it is difficult to estimate function points during the early stages of System Development, complexity factor mentioned above in equation depends upon analyst judgement, which is subject to change according to personnel.

Recommendation: Function points is a standardised process by an internationally recognition organisation (IFPUG) and should be the core measure for software product development. Function points helps technical team in delivering software functionality which is most important factor while developing product that satisfies user needs and lastly helps business in building customer base.

Effort Hours

Definition: Number of hours required to complete software activity and tasks associated with software development is known as Effort hours. It is important to know effort hours so that we can assign resources to determine project duration and estimation of labour and non-labour costs.

Description: Project effort hours should be tracked appropriately in order to satisfy project requirements. There are no international standards established for effort hours like Function points. Every organisation needs to check which should be included or excluded from the project like, vacation time, training, management.

Utilization: To monitor progress and report productivity, effort hours will be the measure. It can be estimated with the help of organisation historical data as well. Collection of this measure should be consistent to ensure accurate performance analysis.

Process to estimate total effort required for product development (MOCHAL, 2006):

1. Determination of accurateness of estimatesMore accurate estimate requires more details with time, if rough order of magnitude estimate (-25% - +75%), shows completeness of the work more

31001655

quickly with minimum amount of detail at high level. With estimate within 10% requires more time with work at a low level.

2. Initial estimationThere are many ways to create initial estimation with the help of work break down structure, expert opinion, analogy etc.Word break down structure is dynamic tool which can be revised according to the project requirement. It is a tool to define and group projects discrete work tasks and elements. It may be product, data, a service or combination. It starts with objective and then subdivided into managerial components in terms of size, duration and responsibility (HAUGAN, 2001). Work break down structure provides universal platform for the ordinary development of the overall preparation and control of a project. It divides work into definable augmentation from which assertion of work can be developed and technical, schedule, cost and labour hour coverage can be established (AMITESH, 2010).

Source: Work breakdown structure, Amitesh, 2010

A Workplan Example

Work Plan Information Example

Name of task Perform economic feasibilityStart date Jan 10, 2008Completion date Jan 20, 2008Person assigned Project sponsor: Rahul JainDeliverable(s) Cost-benefit analysisCompletion status OpenPriority HighResources needed SpreadsheetEstimated time 16 hours

Actual time 14.5 hoursSource: (ALAN DENNIS, Barbara Haley Wixom, and Roberta Roth, 2006)

41001655

3. Addition of specialist resource hourPart time and specialist resources need to be included while estimating effort hours. This includes freelancer, training, administrative, procurement and legal associates.

4. Rework (Optional)Uncertainties are everywhere and even in real projects as well. Rework is optional during estimation of effort hours; however, never underestimate rework as many projects sometimes ended up with rework.

5. Add Project Management TimeIt included effort required to successfully manage project. Addition of 15% in effort hours required for project management.For example : If project estimate 10,000 hours (5-6 people) then add 1500 hours for full-time project manager.

6. Contingency hoursUncertainty and risks associated with the estimate comes under contingency hours. For work which is not well defined, we need to add 50% or 75% to reflect contingency. Contingency can be reduced to 5% for the people who worked in product development project before.

7. Total effortCalculation of total effort can be done by adding all the detailed work components.

8. Review and adjustmentAfter addition of total efforts, sometime estimation become too high or low, if effort hours seems improper, its require to review and do the necessary adjustment in order to fix the effort hours problem.

9. Documentation of assumptionsAll assumptions should be documented while estimating effort hours, sometimes it’s important to document.

Recommendation: Accuracy in accounting time critical in order to evaluate accuracy of estimates. Establishment of specific guideline needed in organisation. Scope of activities to be included should be agreed upon early in the project life cycle. Project manager required to create work break down structure in order to get detailed estimation of cost and control along with scheduled development.

Cost

Definition: Funds requires delivering and developing the software solution comes under Cost.

Description: In order to estimate cost, we need to multiply effort hours with hourly rate. Many additional costs involved such as hardware/software installation, maintenance and support. Documentation of costs which should be included or excluded in the project is required and it is also an important measure for product development.

Utilization: Cost analysis depends upon the appropriateness of costs estimated, collected and tracked. Constructive Cost Model (COCOMO) is a software cost estimation model by Barry Boehm. COCOMO model used basic regression formula and some perimeters (derived from previous project).

51001655

COCOMO II allows us to estimate the cost, effort and schedule when planning for new software product development. This model is mostly used for analysis and forecasting. This model comes in three forms: simple, intermediate and detailed. In order to use this model, first we need to decide type of system we building (Key Software Metrics, 1999):

Organic: Refer to separate in-house DP systemEmbedded: Refers to real time systemsSemi-detached: The system between organic and embedded

For example:

Effort Applied = ab(KLOC)bb

Development Time = cb(Effort Applied)db [months]

People required = Effort Applied / Development Time [count]

KLoC- estimated number of thousands of delivered lines of code for the project ai, bi are 

Software project ai bi

Organic 3.2 1.05 Semi-detached 3.0 1.12 Embedded 2.8 1.20

Recommendation: Which costs should be included and which should be excluded need to specify in advance during consideration. Purchasing costs of hardware/software, maintenance and customization need to be agreed upon early in the project.

Project Duration Days

Definition: Project duration days is the measure which is used to calculate calendar days from the beginning of requirements through implementation. It is the period of time when efforts of project manager and team members applied to accomplish project successfully (Project Management Duration,2011).

Description: There is no industry standards defined for project duration, we need to decide what start/end dates to track progress, with the establishment of criteria.

Utilization: Project duration directly connected to the amount of effort needs to be performed during the project to achieve primary and secondary goals. Projects with smaller calendar days sometimes cost higher with high defects rate. It is primarily due to the ineffective communication and coordination between teams and people. Project duration is required measure while evaluating project progress. Simple process for estimating project duration:1. Estimate the productive hours per day

We need to determine, how many productive hours of work each person working per day. On an average 6.0 to 6.5 productive hours per day after excluding socializing, breaks, bathroom breaks etc.

61001655

2. Factor in multitasking productivity loss for part time resourcesFurther reduction in productivity caused when one person working on multiple projects or combination of projects. Person shared on two or more unrelated efforts and its time consuming process to stop one task and start another. Example: if one person working on two projects for 20 hours each week, then this led to reduction in productivity by 10%.

3. Determination of resources to each activityMore resources led to faster completion of task, two resources will complete task faster than assigning two people.

4. Factor in available workdaysNon-project time which includes holidays, training and vacations need to be scheduled and accounted in advance.

5. Non full time resourcesHalf or 50% of resources will consume twice time to do any individual activity.

6. Calculate delays and lag-timesDelays caused by vendors in delivering resources should be taken into consideration. These are the activities which caused small effort hours but long durations.

7. Identification of resource constraintsIdentification of activities that can be done sequentially and parallel need to be defined while building an initial work plan. All parallel activities can be done in parallel if we have enough resources. If there is lack of resources then we need to switch resources from parallel to sequential, this result in extending project duration.

8. Documentation of assumptionsDocumentation of all the assumptions alone with estimation is required.

Recommendation: Project duration should be tracked, by predefined definitions, “When the clock starts” and “when the clock end”.

Lines of Code

Definitions: Lines of code or Kilo lines of code refers codes which need to be executed. A line of code is easy to measure and impossible to interpret, mostly used to measure complexity or productivity. Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs (Bill Gates).

Description: LOC should be executable line of code not physical. Things like comments and black spaces should not be counted in LOC. Lines of code are the traditional way to measure size of application.

Utilization: Line counts are different for different programming languages. Line of C++ code is not same as code of VB. Implementing lines count in VB6 is more complex than VB.Net, as well as, while measuring programmer performance, lines count is not the perfect metric. It is useful to measure productivity but programming style can have impact on the values.There are many ways to count lines of code, LOC seems like simple concept but its not, there are numerous ways to count LOC. Below mentioned are the ways to count LOC(Project Metrics,2011):

71001655

Metric Supported as DescriptionPhysical lines

Lines This metric counts the physical lines but excludes VB form codes and descriptions

Physical lines of code

Not supported

It counts lines but excludes empty lines and codes. It also known as SLOC (Source lines of code)

Logical Lines

LLines It covers one or more physical lines.

Logical lines of code

LLOC This contains actual source code excluding empty lines or comment lines.

Statements STMT This is statement count, VB programs contains one statement per lines.

Recommendation: It is easy to get LOC in languages such as COBOL, but it is very difficult when coding in PowerBuilder or VB plus at the end of project completion, it is difficult to get LOC. Therefore, concerns should be made when using LOC for product development.

Defects Definition: Defects are the problems or error that produces unsatisfactory

results. Defects need to be consider while defining measures for product development as they

Description: Defects are referred by different names like Bugs, problem or supplemental features. Defects cane be anywhere, not only in software, it could be in design, documentation or requirement analysis. Origin (source), category and severity level (impact).

Utilization: Defects are useful in estimating quality of the software program and allows us to take required needed corrective actions during product development phase. This information is useful is forecasting maintenance staff levels, because, applications which are more prone to defect requires more support staff. It is recommended to use defect metrics on an ongoing basis to keep track on how product quality is shaping up. Root cause analysis provided useful information to improve requirements.Defect Analysis template (BORYSOWICH,12):

81001655

Recommendation:

thing for the

business. As it increases customer loyalty and helps business in making strong customer base.

Descriptions of Roles and Responsibilities (WHITSON, 2003):

Role Responsibilities Participant(s)

Project Sponsor

Final decision-maker and tie-breaker Provide project oversight and

direction Review/approve project elements

xxxxxx

Steering Committee

Manage department resources Approves major funding and

resource allocation strategies, and significant changes to funding/resource allocation

Resolves conflicts and issues Provides direction to the Project

Manager Review project deliverables

xxxxxxx

Project Manager

Manages project in accordance to the project plan

Serves as liaison to the Steering Committee

Receive guidance from Steering Committee

xxxxxxx

DEFECT CAUSAL ANALYSIS ACTION ITEMS

Project Name:   Meeting Date:

 

Identifier:   Group Name:

 

Project Name:   Meeting Date:

 

Action Item Number

Source Defect Number

Date Assigned

Action Assigned To

Due Date

 

           

           

           

91001655

Role Responsibilities Participant(s) Supervises consultants Supervise vendor(s) Provide overall project direction Direct/lead team members toward

project objectives Handle problem resolution Manages the project budget

Project Participants

Understand the user needs and business processes of their area

Act as consumer advocate in representing their area

Communicate project goals, status and progress throughout the project to personnel in their area

Review and approve project deliverables

Creates or helps create work products

Coordinates participation of work groups, individuals and stakeholders

Provide knowledge and recommendations

Helps identify and remove project barriers

Assure quality of products that will meet the project goals and objectives

Identify risks and issues and help in resolutions

To be identified by Steering Committee

Subject Matter Experts

Lend expertise and guidance as needed

To be identified by Steering Committee

Effective coordination of activities is required in product development. There is need to develop communication plan, which includes communication methodology.Communication methodology utilizes three direction of effective communication:

- Top down: All contributors of in this product development project intellect executive support. Executives need to verbalize straight to all levels of organisation.

- Bottom Up: It is important to communicate in a way in which solutions were created.

- Middle-Out: Full support at all levels where changes will have to be implemented.

Communication outreach Follow are the list of communication events needs to create in this project:

- Monthly Status Report: Project manager need to provide monthly status report to the Steering committee. Report should include:

Summary to task completed in previous month

101001655

Summary to task scheduled for next month Summary of issues status and resolutions

- Monthly Steering committee meeting: This meeting should be help in once every month and all members of Steering committee mandatory to participate in this meeting. Project manager required to send status report to each member of committee prior to meeting time.

- Monthly project Team Status meeting: Should be held every month and every member of project team required to participate. Project manager need to send status report to all team member prior to meeting.

- Website Use: Project manager need to post information about project on the projects website.

Summary: Above mentioned are the key measures which is require for software product development. Project managers needs to careful analyse these measures. Managers are required to work on measures described above while coordinating with other product development activities.

References:ALAN DENNIS, Barbara Haley Wixom, and Roberta Roth. 2006. Project Management. [online].

AMITESH. 2010. Work Breakdown Structure. [online].

BORYSOWICH, Craig. 12. toolbox.com. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://it.toolbox.com/blogs/enterprise-solutions/defect-causal-analysis-action-item-template-17591"

HAUGAN, Gregory T. 2001. Effective Work Breakdown Structures. Management Concepts, p.17.

Key Software Metrics. 1999. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://www.eecs.qmul.ac.uk/~norman/papers/qa_metrics_article/section_5_key_metrics.html"

MOCHAL, Tom. 2006. Use this process to estimate effort hours. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://www.techrepublic.com/article/use-this-process-to-estimate-effort-hours/6142489" Project Management Duration. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://www.taskmanagementguide.com/planning-tasks/project-management-duration.php"

Project Metrics. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://www.aivosto.com/project/help/pm-loc.html "

111001655

WHITSON, Debbie. 2003. Project Plan. [online].

WIKIANSWERS. 2011. COCOMO Model II Formula. [online].