Goal-Driven Software Development Process: Difference between revisions

Revision as of 17:52, 20 September 2010

Revision as of 03:45, 27 December 2010

Line 18:

* 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 the user involvement is considered to be a critical project success factor .<ref name="CHAOS">The chaos report. Technical report, Standish Group, 1994.</ref>.

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 49:

: ''For more information see [[Top-down and bottom-up design]]''.

While the top-down orientation supports a horizontal team organization, bottom-up approaches try to provide generalized components or services, leading to a better user satisfaction.<ref name="TDBU">{{cite web

| url = http://portal.acm.org/citation.cfm?id=1018436.1021759

| title = A brief top-down and bottom-up philosophy on software evolution

Line 57:

| coauthors = Bauer, A

| publisher = IPWSE. 2004. IEEE Computer Society

}}</ref>. The collaborative identification of goals introduced by GDP allows combining top-down with bottom-up aspects (“''top-down thinking and bottom-up acting''” <ref name="GDSD" />) to support [[Artifact (software development)|artifacts]] consistency and allowing vertical team organization.

=== Vertical team organization ===

Line 77:

According to GDP, another key to success in large project is to minimize project size in all aspects, i.e. limit the number of goals and software [[Artifact (software development)|artifacts]] like documents, requirement specifications, models, etc. but also to limit the number of staff, to avoid mutual waiting and the size of the code.

Minimizing size leads to an increased maintainability and changeability of the system to business processes as they are the most likely factor to change in the future .<ref name="BPCHANGE">Panas, Löwe, Asmann. Towards the unified recovery architecture for reverse engineering. Proc. of the Intern. Conf. on Software Engineering and Practice SERP’03, volume 1, pages 854–860, Las Vegas, NV, June 2003. CSREA Press.</ref>.

== Activities ==

Line 83:

Every iteration starts with the identification of business goals and their priorities and ends with a running version of the software system corresponding to the selected goals.

While incremental development of the software system is also done in other [[Software development process|software processes]], the scope of GDP iteration is extended to include a discussion of business objectives after ''each'' iteration as is believed the business objectives themselves mature with the availability of usable implementation .<ref name="GDSD" />.

The core activities are: