Goal-Driven Software Development Process: Difference between revisions

Revision as of 18:05, 7 March 2013

Latest revision as of 05:51, 15 April 2025

(7 intermediate revisions by 7 users not shown)

Line 1:

'''Goal-Driven Software Development Process''' (GDP<!-- gdp -->) is an [[iterative and incremental development|iterative and incremental]] [[software development]] technique. Although similar to other modern [[process modeling|process models]], GDP is primarily focusing on identifying goals ''before'' setting the requirements and explicitly utilizing the bottom-up design approach.

The following sections are based on the paper ''Goal-Driven Software Development'' <ref name="GDSD">{{cite webbook

| chapter-url = http://portal.acm.org/citation.cfm?id=1263550.1264132

| titlechapter = Goal-Driven Software Development

| accessdate = 2008-12-30

| last = Schnabel

| first = I.

| coauthors author2= Pizka, M

| title = 2006 30th Annual IEEE/NASA Software Engineering Workshop

| year = 2006

| pages = 59–65

| publisher = SEW. 2006. IEEE Computer Society

| doi = 10.1109/SEW.2006.21

| isbn = 0-7695-2624-1

| s2cid = 2964715

}}</ref> where the GDP concept was introduced.

Line 31 ⟶ 37:

| first = Birol

| journal = Journal of Object Technology | volume = 5| issue = 2 | date= March–April 2006|pages = 85–102

| doi-access = free

}}</ref>

* Discover use cases that are tailored to the requirements according to business goals

Line 44 ⟶ 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, if a goal is feasible is bottom-up oriented.

=== Top-down and bottom-up convergence ===

Line 56 ⟶ 63:

| last = Pizka

| first = M.

| coauthors author2= 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.

Line 76 ⟶ 83:

=== Minimizing project size ===

According to GDP, another key to success in large projects 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 staffproject members, 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>

Line 88 ⟶ 95:

The core activities are:

# '''Identification and prioritization of goals''' (small groups of at most 5 people consisting of stakeholders and/or business analysts, and programmers)

# '''Vertical distribution of tasks''' (selected goals are assigned to groups of at most 4 programmers)

# '''Implementation and testing''' (implementation-driven tests during implementation, goal-driven tests at the end of each iteration)

These activities can be also divided into six main steps:<ref name="CASE" />

# '''Group business requirements by goals'''

# '''Formalize goal-driven system behaviors inside processes'''

# '''Monitor advancement in the realization of the goals (optional)'''

# '''Assign responsibilities to participants of the processes'''

# '''Plug behaviors in the goal-driven architectural backbone and play'''

# '''Integrate application constraints of the actors'''

== References ==