Goal-Driven Software Development Process

Goal-Driven Software Development Process (GDP) is an iterative and incremental software development technique. Although similar to other modern 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 [1] where the GDP concept was introduced.

## Justification

[edit]

The first argument to embrace the GDP principles is the aspect of requirements. When developing software, the strong concentration on requirements (e.g. typical for the waterfall model) causes excessive costs and reduced quality of the outcome, mainly due to the following reasons:[1]

* Requirements are usually not identical with business objectives because of the author’s limited knowledge about technical possibilities and their costs – such requirements tend to include unnecessary expensive wishes while excluding technically simple features that would provide substantial benefit.
* 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.[2]

Secondly, while established 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 the technical platform in an iterative process, equally considering and adjusting business goals and technical aspects to come to an optimal, convergent solution.

Goal-driven development process allows stakeholders to:[3]

* Discover use cases that are tailored to the requirements according to business goals
* Establish a bridge between goals and IT architecture

## Key principles

[edit]

Goal-driven software development process

### Collaborative goal identification

[edit]

As closely related to the 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 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

[edit]

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.[4] The collaborative identification of goals introduced by GDP allows combining top-down with bottom-up aspects (“top-down thinking and bottom-up acting” [1]) to support artifacts consistency and allowing vertical team organization.

### Vertical team organization

[edit]

In contrast to horizontally organized project teams where programmers implement the solution specified by the modeling team, the vertical organization implied by the GDP requires skilled and qualified generalists. As stated by IBM Rational Unified Process, individual developers can and should take multiple roles on a project to avoid unnecessary communication overhead and conflicts.

### Roles and people

[edit]

Because of its vertical organization the GDP requires skilled generalists with the ability to fulfill many roles of the process:

* Programmers (responsible for top-down and bottom-up convergence)
* Business analysts (collaborate with the programmers during goal identification and later-on during testing)
* Software architects (keep an eye on the whole project)
* Project manager (assigns resources, keeps track of time and effort, creates a productive environment)
* Requirement engineer

### Minimizing project size

[edit]

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 artifacts like documents, requirement specifications, models, etc. but also to limit the number of project 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.[5]

## Activities

[edit]

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 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.[1]

The core activities are:

1. Identification and prioritization of goals (small groups of at most 5 people consisting of stakeholders and/or business analysts, and programmers)
2. Vertical distribution of tasks (selected goals are assigned to groups of at most 4 programmers)
3. 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:[3]

1. Group business requirements by goals
2. Formalize goal-driven system behaviors inside processes
3. Monitor advancement in the realization of the goals (optional)
4. Assign responsibilities to participants of the processes
5. Plug behaviors in the goal-driven architectural backbone and play
6. Integrate application constraints of the actors

## References

[edit]

1. ^ a b c d Schnabel, I.; Pizka, M (2006). "Goal-Driven Software Development". 2006 30th Annual IEEE/NASA Software Engineering Workshop. SEW. 2006. IEEE Computer Society. pp. 59–65\. doi:10.1109/SEW.2006.21. ISBN 0-7695-2624-1. S2CID 2964715. Retrieved 2008-12-30.
2. ^ The chaos report. Technical report, Standish Group, 1994.
3. ^ a b Berkem, Birol (March–April 2006). "How to align IT with the Changes using UML and according to BMM". Journal of Object Technology. 5 (2): 85–102\. doi:10.5381/jot.2006.5.2.c9. Retrieved 2008-12-30.
4. ^ Pizka, M.; Bauer, A. "A brief top-down and bottom-up philosophy on software evolution". IPWSE. 2004. IEEE Computer Society. Retrieved 2008-12-30.
5. ^ 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.

## External links

[edit]

* How to align IT to changes on a Goal-Driven Service Oriented Architecture using UML, MDA and BMM

* v
* t
* e

Software engineering

Fields|

* Computer programming
* DevOps
* Empirical software engineering
* Experimental software engineering
* Formal methods
* Requirements engineering
* Search-based software engineering
* Site reliability engineering
* Social software engineering
* Software deployment
* Software design
* Software maintenance
* Software testing
* Systems analysis

Concepts|

* Abstraction
* CI/CD
* Compatibility
* Backward compatibility
* Compatibility layer
* Compatibility mode
* Forward compatibility
* Software incompatibility
* Component-based software engineering
* Data modeling
* Enterprise architecture
* Functional specification
* Modeling language
* Programming paradigm
* Software
* Software archaeology
* Software architecture
* Software configuration management
* Software development process/methodology
* Software quality
* Software quality assurance
* Software system
* Software verification and validation
* Structured analysis
* Essential analysis

Orientations|

* Agile
* Aspect-oriented
* Object orientation
* Ontology
* SDLC
* Service orientation

Models|

| Developmental|

* Agile
* EUP
* Executable UML
* Incremental model
* Iterative model
* Prototype model
* RAD
* Scrum
* Spiral model
* UP
* V-model
* Waterfall model
* XP
* Model-driven engineering
* Round-trip engineering

|

Other|

* CMMI
* Data model
* ER model
* Function model
* Information model
* Metamodeling
* Object model
* SPICE
* Systems model
* View model

Languages|

* IDEF
* SysML
* UML
* USL

Systems design|

|  Requirements|

* Functional requirement
* Non-functional requirement

|

Capacity|

* Users
* Compute
* Memory
* Storage
* Network
* Web traffic

Interface|

* API
* SOAP
* REST
* GraphQL
* gRPC
* Webhook

High-level design|

* Client
* Load balancing
* Application server
* Message queue

Integration|

* Vertical
* Peer-to-peer
* API Gateway
* pub-sub
* Event Source
* ETL
* Batch
* Stream
* Orchestration

Architectures|

* Monolithic
* Microservices
* Event-Driven
* Client–server
* Serverless
* Circuit breaker
* Rate limiting

Database|

* Relational
* NoSQL
* Graph
* Key–value
* LSM Tree
* Time series
* Column Oriented

Principles|

* Consistency
* Reliability
* CAP theorem
* Maintainability
* Configurability
* Modularity
* Durability

Scalability|

* Stateless
* Asynchronous I/O
* Loose coupling

Availability|

* Fault tolerance
* Failover
* Single point of failure
* Replication
* Consistent hashing
* Circuit breaker

Latency|

* Cache
* CDN
* Shard
* Database index
* Pre-caching

Storage|

* Object storage
* Block storage

Observability|

* Logging
* Metrics
* Tracing
* Error rate
* Queries per second
* Notification system
* Anomaly detection

Related fields|

* Computer engineering
* Computer science
* Information science
* Project management
* Risk management
* Systems engineering

* Category
* Commons

*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template