construx.com - Remaining variability in project scope (cost, size, or features)

DEVELOPMENT PLANNING & PREREQUISITES
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious". - Fred Brooks, The Mythical Man-Month.

Our approach is adaptable, allowing us to engage and provide testable solutions at any stage in the software development life-cycle. From planning and pre-definition strategy to post-release usability, we blend a variety of methods and best practices on the net. This allows us to create valuable solutions in every stage of the development.

----------------------------------------------------------------------------------------
DEVELOPMENT PLANNING & PREREQUISITES
Cone of Uncertainty:
All software projects are subject to inherent errors in early estimates.
The Cone of Uncertainty represents the best-case reduction in estimation error and improvement in predictability over the course of a project.
Skillful project leaders treat the cone as a fact of life and plan accordingly.
0. Initial concept
1. Approved product definition
2. Marketing / business requirements complete
3. Detailed technical requirements complete
4. Detailed design complete
Software development is a process of continuous refinement.
A well-run software project attacks areas of highest variability first to narrow the cone as rapidly as possible. Active control is needed throughout the project to keep the cone from widening again.
•
construx.com - Remaining variability in project scope (cost, size, or features)
----------------------------------------------------------------------------------------
--------------------------
Da bi se mogla napraviti što reralnija procjena obima posla i započeti planiranje, maralo bi se imati odgovor na još ova dva pitanja:
1. koje pretpostavke i preduvjeti još nisu ispunjeni da bi se mogla napraviti procjena obima posla i započeti planiranje razvoja?
2. Dobro bi bilo da krajnji korisnik POTVRDI mockup solucije (izgled sučelja i operativne procedure)
[09:33:46] John Jan Popovic: http://www.construx.com/uploadedFiles/Construx/Construx_Content/Resources/Templates/ActorTable.pdf
..................................

EXPERT COCOMO
Expert COCOMO was developed by Dr. Ray Madachy and uses heuristics to flag potential risks found in specified project development conditions.
It aids planning projects by identifying, categorizing, quantifying and prioritising projects risks. It also detects cost estimate input anomalies. Further information can be found in [Expert COCOMO] or [Boehm et al. 2000a].

COCOMO® II can be used for the following major decision situations
★ Making investment or other financial decisions involving a software development effort
★ Setting project budgets and schedules as a basis for planning and control
★ Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance or quality factors
★ Making software cost and schedule risk management decisions
★ Deciding which parts of a software system to develop, reuse, lease, or purchase
★ Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc
★ Setting mixed investment strategies to improve organization's software capability, via reuse, tools, process maturity, outsourcing, etc
★ Deciding how to implement a process improvement strategy, such as that provided in the SEI CMM

------------------------------------------
http://c2.com/cgi/wiki?IterativeDevelopment

Iterative Development
The word "iterative" means that it involves repetition.
Iterative Development is a development approach that "cycles" through the development phases, from gathering requirements to delivering functionality in a working release.

Contrast this with the WaterfallModel, where you gather all the requirements up front, do all necessary design, down to a detailed level, then hand the specs to the coders, who write the code; then you do testing (possibly with a side trip to IntegrationHell) and deliver the whole thing in one big end-all release. Everything is big including the risk of failure.

Consider also IncrementalDelivery; (an XP page that may actually be talking about IterativeDevelopment) IncrementalDelivery also delivers functionality to users in cycles, but is historically less focused on reworking existing functionality. So a traditional "IncrementalDelivery" project will deliver one subsystem at a time to the end users, with "as little change as possible" to each subsystem, after it's delivered.
A key differentiation between the traditional WaterFall and the Iterative processes is how the project tasks are boxed in the plan. If they are functionally boxed you are probably WaterFalling?, if they time-boxed you are probably Iterating.

The mantras of IterativeDevelopment are:
★ Phases are Time-Boxed not Functionally-Boxed.
★ Test early, Test often.
★ Deliver early, Deliver often.
★ Production Quality.

Iterative Development processes grew out of ObjectOrientedDevelopment? where it quick appreciated that a Class could be considered a mini-project and developed in isolation, the task was naturally boxed by its responsibilities.

The problem I have is with iteration 1. For example I am given a high level spec which says "Build a system which can control the equipment to carry men to the moon and land them on the surface. The system must also be able to bring them safely back to Earth". Which piece should/can I design, code and deliver in the first 1 to 2 months, giving my customer usable/valuable functionality?
-- BarryAllebone?

In XP terms, how about a series of spikes:
1. build a rocket engine that has enough thrust
2. build a rocket that can lob a man into space
3. build one that can lob him into orbit
4. dock two space vehicles in orbit
5. land an unmanned one-way vehicle on the moon to check the environment
6. fly round the moon
7. test out the lander near the moon
etc
Learn from each spike and refactor your design
http://c2.com/cgi/wiki?IterativeDevelopment
land on the moon.
-- TomAyerst
Decompose the system into functional parts and implement one of them. E.g. build software which controls the amount of oxygen in the air, or or or...


-------------------------------------------------------------------------------------
Iterative Vs Incremental
----------------------------
IterativeDevelopment is often confused with IncrementalDevelopment. IterativeDevelopment is about planned rework. You create something, review it and then change it (hopefully improving it) based on the feedback.
A good analogy is when authors write books. Typically they have 2 or 3 external reviews and rewrites before it goes to the copy editors. The iterations are planned rework. Having reviewed lots of initial drafts, believe me when I say you wouldn't want to pay to read the first draft of many books. It's bad enough reading initial drafts when you are being paid to read it (a sentiment I hope is not shared by my reviewers). -- PeteMcBreen
Let me see if I've got this, I'll use the book writing analogy:


IterativeDevelopment means:
- I write loads of stuff that's a complete mess
- I go through it throwing out the irrelevant drivel, expanding on the important bits, and sorting out the structure
- I go through it again now I can start to see the shape of it, sorting it some more
- I go through it yet again, etc, until it's GoodEnough

Incremental Development means:
- I write part one
- I write part two
- I write part three, etc, until the book is finished
Now incremental development may work OK for novelists (e.g. Charles Dickens, or J.K. Rowling), but when you try doing it with computer systems you find that in writing part two, you need to revise and rework some of part one (e.g. to allow reuse), and in writing part three you need to reworks parts one and two, etc..., especially if you subscribe to OnceAndOnlyOnce and MercilessRefactoring.
So in practice, at least in XP practice, your development is both incremental and iterative. - StephenHutchinson
True - The danger is when people confuse the two. I saw a 200 person project iterating on their requirements (allowing arbitrary amount of change) when they should have been incrementing through their requirements, and incrementing & iterating (as you describe) through their design. They were, of course, not making any progress. Also saw a 100 person project claiming they were iterating through their entire novel, when in fact they were doing neither - they were stuck in the mud. They needed to get at least some part working first so they could tell they were moving - once again, needed incrementing as a base. -- AlistairCockburn
------------------------------------------------------------------------------------
.
.
REFINEMENT OF THE PRODUCT REQUIREMENTS
"The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements."
Fred Brooks