Goal-Driven Software Development Process

Last updated

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.

Contents

The following sections are based on the paper Goal-Driven Software Development [1] where the GDP concept was introduced.

Justification

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]

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]

Key principles

Goal-driven software development process Goal-driven software development.png
Goal-driven software development process

Collaborative goal identification

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

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

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

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

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

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

Related Research Articles

Acceptance testing Test to determine if the requirements of a specification or contract are met

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

Spiral model

The spiral model is a risk-driven software development process model. Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping.

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through to the final manifestation of the software, typically in a planned and structured process. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.

Requirements analysis Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

Systems development life cycle Systems engineering term

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life-cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software development, agile practices include requirements discovery and solutions development through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), adaptive planning, evolutionary development, early delivery, continual improvement, and flexible responses to changes in requirements, capacity, and understanding of the problems to be solved.

Dynamic systems development method

Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution delivery rather than being focused specifically on software development and code creation and could be used for non-IT projects. The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

V-Model

The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models. The V-model falls into three broad categories, the German V-Modell, a general testing model and the US government standard.

Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a product or process. Based on the results of testing the most recent iteration of a design, changes and refinements are made. This process is intended to ultimately improve the quality and functionality of a design. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

In software engineering, behavior-driven development (BDD) is an agile software development process that encourages collaboration among developers, quality assurance testers, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

Extreme programming (XP) is an agile software development methodology used to implement software projects. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

View model

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of a whole system from the perspective of a related set of concerns.

In software engineering, a software development process is the process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.

Extreme programming Software development methodology

Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

References

  1. 1 2 3 4 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. 1 2 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.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.