Home > Articles > Programming

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Process, Process, All the Way

Together ControlCenter doesn't constrain you to work in a particular way, but if you want to change the way you work, then you can. We have a similar aim for this book. We don't want to constrain teams to a particular process; rather, we want to introduce the philosophy and ideas that have inspired us regarding modern development processes and to help you to evolve the appropriate development processes for your own organizations and projects. So, let us lay out some of our goals.

Building only What Is Needed

We asked in the preface to the book, What's the least that a team needs to do to deliver excellent software? There's a related question: Is it a bad thing to do more than this? We think it is.

This is a variant of what might be termed the "girls' boarding school rule," which goes along the lines of, If it's not compulsory, then it's forbidden! While this is probably a slur on modern girls' boarding schools, it is quite useful when considering the standards you want to apply to an agile software development processes. We are looking for the minimum set of artifacts that must be produced and maintained to be consistent with the actual software. At the same time, we want to remove the need to maintain all other artifacts.

To say that additional documents are forbidden is definitely an overstatement. Team members and others should feel free to produce documents that are not in the minimum set if they will be useful. The key point is that such documents will not be maintained unless they are subsequently recognized as being additions to the minimum essential set. At that point, the must be reviewed for completeness and consistency, and updated build by build.

team members often gather around a whiteboard to figure out how to implement some feature or functionality. The diagram on the whiteboard is not considered a deliverable of the project; once it has done its job, it is erased. Only if the content of the diagram becomes the adopted design does the diagram become a delivered artifact. Of course, when you are using Together, you can get the design from the implemented source code or you can enter the diagram and use the resulting code as the starting point for the implementation. Either way, it is these elements that form the essential maintainable artifacts.

Occasionally, a document will be found to be so useful that it will become a formal part of the minimal deliverables. But when this is done, the attendant costs of maintaining that document must be balanced against its usefulness.

A Big Sheet of Paper

Dan Haywood

While contracting at one of the investment banks, I found myself assigned to keep track of hardware and system software (databases and operating systems) for the global credit and market risk department. This was at the end of the last century(!), and the bank had three major projects upcoming: merging with another investment bank, upgrading systems to support the new euro currency, and Y2K.

There was a fair degree of reconciliation required for these projects in terms of decommissioning old hardware,upgrading system software, and rationalizing system and application software onto fewer faster machines. The contingency hardware also was either nonexistent or pitifully underpowered, so this also had to be brought into consideration as part of disaster recovery planning, part and parcel of the Y2K program.

Initial efforts to come to grips with the production, test, and development environments using spreadsheets and such proved ineffective. Then I decided to use a drawing tool, invent a few symbols for elements of the configuration, and print on really big sheets of paper. Suddenly, it all became easy. The managers could immediately see which boxes were to be decommissioned, what system and application software ran on what boxes, what software would be migrating to new hardware, and which system software required upgrade.

I left that contract a while ago, though occasionally still visit the folks at the bank. I note that even now they keep a big sheet of paper up on the wall, even though those three projects are long finished. Though this particular artifact was discovered almost by accident, its value was proved, and so now the effort to keep it up to date is accepted.

Essential Elements

If we are seeking to build only what is needed, what are the essential elements of the system and its documentation? Every development process seems to involve the following essential elements:

  • Requirements (use case, user story, feature, requirements paragraph)

  • Design Statements (interaction diagrams—sequence or collaboration)

  • Implementation Elements (class, operation)

  • Tests (functional test, unit test or level-of-service test)

These are the four basic elements that we must maintain and keep in step and up to date. These elements have a natural relationship with each other, as Figure 1-4 shows.

Figure 1-4Figure 1–4 The essential elements of Requirements, Design, Implementation, and Test.

Each requirement is tested by a functional test, and its design is shown by interactions, for example one or more sequence diagram. These interactions reference a set of operations, each belonging to some class, and in turn tested by at least one unit test.

The relationships between these elements of requirements, design, implementation and test are important, and we need to capture the links in the model we store in Together. The relationships are

  • Design (interaction diagrams) fulfills Requirement(s) (use cases, say)

  • Design is implemented by Implementation Elements (classes and operations)

  • Functional Test tests (Functional) Requirement(s)

  • Unit Test tests Implementation Element(s)

The directionality of these relationships in Figure 1-4 shows the dependency between the elements,which is also important as it shows what needs to be checked and updated when things change. The design fulfills the requirements and so is dependent on it. The design refers to implementation elements, which are used to implement the feature, and so is dependent on them. The implementation elements, however, are not necessarily dependent on the requirements of this project. Many classes and operations, for example, may be reusable elements developed independently from the specific functional requirements.

When a requirement is added, deleted, or changed, the design and its tests must be reviewed to ensure they are still consistent and applicable. Dependency has a well-known effect in source code where it controls, for example, the order of compilation and recompilation. In an iterative lifecycle this effect extends as well to the other elements of the single model and will drive the consequential actions resulting from a change.

We'll revisit the essential elements shortly, looking at how they might be represented within the Together model. Let us consider for a moment the process of change that surrounds them.

Nonlinear lifecycles are always in the middle

Most software development processes get defined in terms of what you do in sequence from the start point, say the award of the contract for the project to customer sign-off of the finished software. Like our waterfall model in Figure 1-2, they are defined from end to end with feedback loops. However, as soon as the process has started and some of the feedback loops have been followed, we are "in the middle" with activities from multiple phases actually happening concurrently. We therefore have to address concurrent updating of all the essential artifacts.

From the point of view of the technical tasks of defining the requirements, the tests, the design, and the implementation, it is perhaps more useful to think of the development process in this way: when a reasonably complete set of artifacts exists (from end to end of a traditional lifecycle), what do you need to do to change the model, rather than define it from scratch? You are never at the start here, or for that matter at the end; you are always in the middle of the lifecycle, addressing the four essential elements of requirements, design, implementation and tests in all the phases of the project.

Linear lifecycles are an oversimplification. It is useful to stress that comprehension (the goal of analysis) must precede invention (the goal of design), and invention must precede implementation. But the actual activities cannot be divided into phases of the project lasting some number of weeks or months. D. L. Parnas and P. C. Clements expressed this well in the title of a paper they published in 1986, "A rational Design Process: How and why to fake it." They emphasized that the usefulness of the linear lifecycle was not that it told team members what activity to do next—many different activities from the different phases of the lifecycle in fact have to be addressed simultaneously. The real value of such a rational design process was that it defined a scheme for organizing the artifacts produced in the process in such a way that designers, reviewers, new members of the project, and maintainers could find the necessary information easily.

When developing a software system, there will be some features that are being specified—the requirements are being gathered and tests for them being defined. Meanwhile, the design is being worked out for other features. Yet other features are being implemented, and there could be a unit, integration, or system test being carried out on yet other features. At different times in the project, a different emphasis and differing amounts of time will need to be spent on each of the four elements. The important point here is that to some extent all of these things are happening at the same time.

We talk more about this style of development and how well it works in Chapter 5, "The Controlling Step: Feature-Centric Management."

The Minimum Metamodel

Let us combine the two ideas presented above: the four essential elements and being always in the middle. We like to refer to the essential elements of the process as the minimum metamodel, constituting the minimum set of deliverables needed for the system.

A Model of Completeness

A metamodel defines the basis of the modeling system (Carmichael 1994a), and this minimum metamodel provides the basis (as simply as possible) for defining the model's completeness. Figure 1-5 shows a metaclass diagram for the concepts concerned. Effectively, this figure views the same metamodel as Figure 1-4 but displays more details. It also shows some optional features, such as business process activity diagrams that describe the process behind a given requirement, and state diagrams, which give more detailed definition to the behavior of a Class.

Figure 1-5Figure 1–5 The minimum metamodel.

The minimum metamodel builds upon the four essential elements introduced earlier, making concrete the artifacts and required relationships that realize these elements within a Together project. Let's walk through this diagram observing how Together can make the relationships concrete.

  • Requirements are realized as use cases, features, or both.

    • Use cases are catalogued in use case diagrams.

    • Features can be recorded using feature lists.

    • Together allows use cases to be hyperlinked to lower level use cases or features that implement a higher level use case.

  • Business process activity diagrams also have a relationship with requirements; usually, such a diagram specifies the human activity or business process associated with the requirement.

    • In Together, activity diagrams can hyperlink to the use cases (or features) that realize the requirements.

    • Units of user documentation can also be hyperlinked to their related requirements.

  • Interactions are realized as either sequence or collaboration diagrams.

  • Interactions fulfill requirements.

    • In Together, interaction diagrams can be linked to their requirements.

  • Interaction diagrams contain references to objects and messages, where an object is instantiated from a class and a message is an instance of a call to an operation provided by the class of the object to which the message is sent.

    • These links are contained within a Together interaction diagram. If an object's class is identified in a sequence diagram, then the message can be associated directly with the operations of that class.

  • Classes have operations.

    • This relationship is explicit in the source for the class. In Together, this relationship is obtained directly by the LiveSource engine parsing the code.

  • Some classes may also have a state chart diagram.

    • The state chart diagram should reference the class directly in Together.

  • State chart diagrams identify a number of actions that can occur.

    • When the target class for the state chart diagram is identified, the actions within the state chart diagram can be associated with the operations of the target class.

  • Test suites consist of test cases, which in turn consist of tests. Tests are functional tests, nonfunctional tests, or simple unit tests.

    • Functional tests link to functional requirements.

    • Unit tests link to operations of classes.

    • Together's test facilities can be used to implement the tests and link them to the tested elements.

When following the minimum metamodel in Together, some links between artifacts are implicit and some are explicit. Explicit links can be defined using Together's hyperlinks or by references in the Properties Inspector. We discuss in more detail which are appropriate links to add in Chapter 6. We also discuss how we can customize the audit facilities to report on the completeness of our models.

Perturbations cause Iterations

The point of this metamodel is to define the set of artifacts (within a single model) that should be created by specifiers, designers, and implementers, and the cross-references between them. When a stable build is produced, its requirements will have corresponding designs, and these designs will reference its implementation, and the requirements and implementation will have valid tests that run and pass. This is our destination, but it is also our starting point—a starting point that unfortunately does not last! Accepting another requirement into the build (or indeed a fault report, which is a kind of requirement) disturbs the equilibrium and will result in the model becoming inconsistent, incomplete, or both.7 This triggers the development process to return the build to equilibrium.

In fact, not all of the requirements that have been defined at any point in time need have valid tests and fully implemented designs available. Requirements can be considered to be in one of two states relative to a given build:

  • on (i.e., implemented in this build), or

  • off (i.e. not implemented in this build, but planned for a later build)

If a requirement is on, then (according to the meta-model)

  • there should be at least one valid functional test.

  • that test should pass (this is verified by running the test).

  • there should be a design for the requirement.

  • the design should reference (be implemented by) implementation elements (that is, classes and operations).

  • all implementation elements should be tested by a valid unit test.

  • that unit test should pass (verified by running the test).

Conversely, if a requirement is off, then the constraints in the metamodel (for example, that there is at least one test) do not apply.

Suppose you have a valid build of your application, and now you wish to start work on a new feature. First, you must ensure that your current build represents a stable system; we are wasting our time if we attempt to make a change to an unstable system. So, accepting the feature into a build triggers the change.

Let's run through some sample iterations:

  • We start off by running the full set of tests on our build. These pass and confirm we have a stable starting point.

  • We then change the state of a particular new requirement from off to on.

  • We retest the existing code with the full set of tests that now include those for our new requirement. Unsurprisingly, the tests fails8 (say, with 20 errors).

  • We consider how to design a solution for this feature and express that as one or more sequence diagrams.

  • We make some changes to the code. We compile, and get compilation errors. We refine our code some more and get a clean compile.

  • We test our code, and it fails, say with 15 errors. We figure out where the problem is (it's either in the implemented code or in the test) and make the correction. We test again, and we now get fewer errors.

  • We continue to refine our code or our tests, all the time learning more about both the problem and the solution.

  • We update our design diagrams to ensure the references to objects and messages link directly to real classes and operations.

  • Maybe we find an error in the specification, so we clarify that and update the tests before continuing.

  • Eventually, all the tests pass; the feature is implemented.

  • We have code that can be integrated with the team's current build. This may be different by now from the build we started from if other team members have integrated changes in parallel, so we book in our changes and rerun the tests.

  • Sadly, an interaction between our change and the parallel changes arises. We go about fixing the problem.

  • Eventually. all the tests pass, and the feature is now implemented and integrated with the team's latest build. We are back to the equilibrium state.

Figure 1-6 shows a simplified view of this sequence of activities.

Figure 1-6Figure 1–6 Perturbations cause iterations.

There are a few observations that we need to make on this process:

  • In order to start enhancing a system, you need to deliver a system; you need a stable state to begin with. This means that delivering a system—even a very small one—is critical to future development.

  • The system you are trying to change must be stable.

  • Testing (and measuring) is the activity that "closes the loop"—it tells us when we no longer need to iterate.

  • Small perturbations will require fewer iterations than larger perturbations.

  • If the perturbation introduced is too large, then there's the chance that no number of iterations will get back to the stable state.

There is another interesting change that this approach to development. The whole team may be involved in evolving all the different artifacts and the different aspects of the application. This is in contrast to more rigid team environments that consist of business analysts, designers, coders, and testers organized into separate teams, possibly even using different tools and languages. Here, everyone is involved in all the aspects of software development lifecycle concurrently, sometimes collaborating with other team members and sometimes working by themselves, in order to deliver a particular feature. One model, one team. We believe this a very positive aspect of the approach and is good for both morale and the effectiveness of development.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020