Content deleted Content added
Citation bot (talk | contribs) Alter: title, template type. Add: s2cid, isbn, doi, pages, year, chapter, chapter-url. Removed or converted URL. Formatted dashes. | Use this bot. Report bugs. | Suggested by Abductive | Category:Software development process | #UCB_Category 70/120 |
Removing link(s) to "Standish Group": Removing links to deleted page Standish Group. |
||
| (One intermediate revision by one other user not shown) | |||
Line 24:
* Formalization of the supported business process during development usually reveals inconsistencies and gaps within that process which need to be compensated with changes to the process itself or to the role of the software system.
The result of these two effects is usually a large number of change requests during and after development (entailing time and cost overruns), therefore user involvement is considered to be a critical project success factor.<ref name="CHAOS">The chaos report. Technical report,
Secondly, while established [[Software development process|software processes]] refine requirements down to an implementation, the Goal-driven Development Process recommends trying to find an optimal mapping between business objectives and capabilities of
Line 51:
As closely related to the [[GQM|Goal-Question-Metric]] paradigm, a '''top-level goal''' is defined as an informal description of what a stakeholder wants to change or improve in his business environment, decomposing itself to more specific '''sub-goals'''. Moreover, a set of questions is linked to every goal, which characterizes the way how software will be tested against defined goals after each [[iterative and incremental development|iteration]].
Being this the key GDP principle, the collaborative identification of goals brings knowledge of users and software developers together. While goal definition is top-down driven, deciding
=== Top-down and bottom-up convergence ===
| |||