Tgp Process

The TGP Process

The Setup Phase

• Putting TgpMethodology into practice means that first; the business professionals and the developers collaborate to create a shared model. According to the TgpArchitecture the declarative visual shared model molds the functionality of the software into a concrete format. the modules of the software that fit are selected. This encourages a quick setup of the system, so most of the development will be with working software. The setup of the system is presented in the following figure:

Incremental Development

Once the system is working, the incremental development begins (presented in the figure below). This is the major phase of the development and maintenance, in which requirements are fulfilled by adjusting and creating new profiles generated by the collaborative work of the the business professionals and developers.

Building Model in a Common Language

In Building the Visual Shared Model and Setting its Borders, the different expertises are expressed in a common language, one that is in-between business domain terminology and computer science terminology. The shared model uses terms from the business domain, obeying grammar rules derived from the IT world, serving as the common formal language. The shared model decreases misunderstandings and misinterpretation errors, and enhances the development cycles by avoiding the need for translation.

Expression of Concepts using Metaphors

In the first steps of creating the shared model, it can be based on a well-known metaphor (e.g., the product works like a washing machine or it works like a physician). Following this initial phase, the basic terms of the models (the Types) are sharpened, and it becomes more concrete. The concretization becomes visual as the graphic editor of shared model is handed to the TBAs to affect the software directly in a confined declarative environment. The graphic editor is part on the unique TGP infrastructure.

Development in two parts (Hot modules, and Cold modules)

The development of the stable parts of the software, which are not likely to be changed, can then be carried out by traditional development methods (see more below, TGP and Other Methodologies). TGP is highly effective in keeping the dynamic parts of the software alive. So, when constructing the shared model, the appropriate hot modules are focused on, whereas the cold ones may be developed by other methods.

Transformation of Working Software

The shared model is quickly transformed into working software. The first version of the software will cover only a small portion of the desired functionality; yet, it quickly moves the development into the next and major phase, Incremental Development - rapid, iterative agile development on top of working software. In the setup phase the following components are implemented:

• The frozen part of the software.
• The main types and interfaces must be in place.

If it takes a long time to provide the frozen parts, Stubs should be developed that emulate the frozen part. Then the frozen parts can be developed in parallel, as a different sub-system.

IncrementalDevelopment

From this stage on, the development process is incremental. with the generation and adjustment of profiles to allow the extension of the software as a stream of concrete requirements.

Generating Profiles

In a well tuned model most of the requirements are fulfilled by this activity of the TBAs. Generating the profiles by the TBAs holds a double meaning; not only do the profiles adjust the software to address desired functions, but also, with the collaboration of the developer, these profiles are transformed into automatic tests and serves as the foundation of the Organic Testing (see more below).

Adding Profile Templates

In certain cases, when the requirements are not fulfilled by the creation or adjusting of a profile, it may be necessary to define new ProfileTemplates (PTs), in collaboration with developers. This is most often a local task since it provides a new implementation to an existing interface the type defined in the architecture. Extending the software may result in the need to create new types. Since these interfaces do not contradict each other, this should also be a local task.

Changing Architecture

The quality of the model is measured by the stability of its Types - interfaces. However, from time to time, new insights or new perspectives may lead to modifications in the existing Type system. These modifications are expensive since they are not local, although, they are beneficial by reducing the cost of future extensions by keeping the model clean. In this process, we are finding the right balance between preserving a clean architecture without ongoing and expensive re-write projects. The OrganicTesting environment and the built-in patterns for model upgrade, provide the means to make wide changes in the model.

OrganicTesting

The involvement of the business professionals can also be used to close the circle, by utilizing their skills to write Organic Tests. Organic Tests contribute greatly to the time to market and the quality of the software. Organic Tests are a large set of automatic tests, created and maintained by the business professionals, which are run constantly by developers. These are mainly end-to-end tests that activate the whole software and check only specific inputs-outputs. The set of tests is built gradually as the software develops; every use case and every feature is reflected in a collection of tests. Using OrganicTesting, the development process gains another dimension of flexibility, the freedom to change the code without the fear of breaking working functionality.

-- ShaiBenYehuda and OriInbar

---

CategoryAgileMethodology IncrementalDevelopment TgpMethodology TgpArchitecture OrganicTesting