Cost Estimation in Agile Software Development E-Book

Stefan Luckhaus

• Herausgeber: tredition
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch
• Veröffentlichungsjahr: 2016

Seitenzahl: 50

Beschreibung

Whenever software is developed based on contracts with binding agreed conditions it is exposed to risks; conditions such as the delivery of a clearly defined functional scope at a fixed price and at an agreed delivery date. Many of these risks can be mitigated by the principles of agile development. Being able to navigate projects within all agreed parameters requires cost estimation methods to be integrated into planning and controlling processes. In order to prevent these methods from eroding the advantages of agile development, they must be rapidly applicable - ideally automatable - and allow for self-calibration after every sprint. This book illustrates, how size metrics can be utilised profitably in software development processes oriented towards agile values. It points out differences and restrictions, how the accuracy of cost estimations can be increased with each sprint and examines the feasibility of automated measurements.

Leseprobe

Stefan Luckhaus

Cost Estimationin Agile SoftwareDevelopment

Utilizing Functional Size Measurement Methods

© 2016 Stefan Luckhaus

Publisher: tredition GmbH, Hamburg

ISBN

Paperback:

978-3-7345-4371-5

Hardcover:

978-3-7345-4372-2

e-Book:

978-3-7345-4373-9

This work, including all of its parts, is protected by copyright. Any utilization without the consent of the publisher and the author is prohibited. This applies in particular to electronic reproduction or any other copying, translating, distributing or making contents publicly available.

Contents

Characteristics and Importance of Agile Software Development

Genesis

Status quo

Reliability

Direct and indirect Cost Estimation Methods

Principle of Incremental Development

Expert Estimations

Indirect Estimations with Story Points

Indirect Estimations by measuring the Functional Size

Summary

Methods for Functional Size Measurement

Function Point Analysis

COSMIC Method

Data Interaction Point Method

Extending Methods for measuring the Size of Further Development

The Impact of Complexity

The Complexity of an Implementation

Interactional Complexity

Algorithmic Complexity

Method Comparison

Further Methods

Measuring the Reference Value for an indirect Cost Estimation

Regular Measuring of Productivity

Process Scope regarding Work

Process Scope regarding Sub-Processes

Process Scope regarding Quality

Automated Measurements

Mapping of Objects to be counted on Structural Characteristics

Possible Restrictions

Iterative Refinement of the measured Productivity

Considering non-functional Requirements

Regular Measurements

The Relationship of Productivity and Quality

Conclusion

Glossary

Bibliography

About the Author

Introduction

Indirect estimations of development costs, which put the methodically determined size of planned software into relation with a precisely measured value of the own productivity, are a best practice approach for planning software development projects. However, utilizing them requires a minimum degree of specification. Briefly described user stories must be refined by use cases and elementary processes. As a consequence, the size of the planned software will be rendered measurable, while the measurement process is lean and does not require much effort.

This book describes briefly and based on the author’s own experience the basics of methodological cost estimations. It demonstrates that this approach agrees well with agile development and especially supports principles such as

• the flexible consideration of new or changed requirements and

• continuous improvement due to retrospectives.

Characteristics and Importance of Agile Software Development

Genesis

At the beginning of the 90s many large-scale projects ran into difficulties – due to their long process times, rigid roles and inflexible structures in conjunction with frequently changing requirements. In this context the C3 project of the Chrysler group (Chrysler Comprehensive Compensation) is often mentioned, which had applied the waterfall model in the beginning. In these days, many US companies experimented with lightweighted development processes and found out that shorter process times, a closer and selfresponsible collaboration of the project teams or the uncomplicated handling of change requests lead to a better mitigation of typical risks and in consequence to more successful projects - successful in terms of early benefits by the customer. Process models such as Scrum or Crystal were developed. The Chrysler C3 project could be prevented from failing by introducing some of these lightweighted methods, which afterwards became popular as Extreme Programming [Wells 2009].

In February 2001, experts exchanged their experience with software development processes at a meeting in Utah (USA) and formulated a system of values, laying the foundation for the way of software development which, since then, is called agile – the Agile Manifesto [Agile Manifesto 2001]:

We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions

over processes and tools

Working software

over comprehensive documentation

Customer collaboration

over contract negotiation

Responding to change

over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto is often misinterpreted. It is commonly used as an excuse to forego any documentation. However, especially the last paragraph makes it evident that it is just a matter of priorities, and that activities such as documentation are adjudged as certainly valuable.

This system of values was refined by the following twelve principles [Agile Manifesto Principles 2001]:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The success of agile methods got around. According to a study performed by Forrester Research at the end of 2005, 14% of the companies in Europe and North America were already using agile processes in software development, while an additional 19% intended to do so in future [Forrester 2005].

Status quo

The technology provider VersionOne, specialized in agile methods, ascertained in 2013 through its seventh annual survey on agile methods that already 84% of all companies employed agile development processes [VersionOne 2013]. In the meantime this number might have increased even further. Even if hybrid process models are applied instead of pure agile ones such as Scrum, e.g. by combining agile methods with project management standards, the following three core characteristics of agile development often remain:

•Incremental