This project is read-only.

Chapter 4 - Project Context Model

The Project Context Model is a way to better understand the goals of the project and the constraints under which it must operate. It is not a formal model; instead, it is a set of information to be collected and factored into other activities. It includes information such as the following:
  • Usage Context. What is the overall context in which the software will exist?
  • Business goals. An example question to gather information for these is, "What is the business value to be provided by the system and how is it to be achieved (strategy)?"
  • Scope. An example question to gather information for this is "What functionality is in scope and what is out of scope for this project?"
  • Stakeholders and users. An example question to gather information for these is "Who are the intended users and who are the other project and system stakeholders?"
  • Budget. An example question to gather information for this is "How much money is available to achieve the business goal?"
  • Hard deadlines. An example question to gather information for these is "What deadlines must be met for the project to be considered a success?" Examples of hard deadlines include trade shows, contractual deadlines, and regulatory deadlines.
  • Constraints. An example question to gather information for these is "What resources (such as people, space, and equipment) are available to the project?" A follow-up question might include "Which resources are negotiable and which are hard constraints?"
The sections of this chapter provide more information about each of these factors. Other contextual factors not discussed in this chapter also have an influence on software acceptance. These factors include:
  1. Criticality of the system, which affects defect tolerance levels, how comprehensive acceptance testing should be, and what constitutes “good enough” quality [Cockburn], for example, defines four zones of criticality of the system based on the failure impact: Loss of Life (clearly the highest), Loss of Essential Money, Loss of Discretionary Money, or Loss of Comfort. Boehm & Turner’s criticality scale is similar but distinguishes Loss of Many Lives from Loss of Single Life [BoehmTurner]);
  2. Processes and Tools available and used in the project, such as continuous integration, automated builds, and source code management tools , which affect the timing, style, amount, and frequency of acceptance testing ; and
  3. Trust, which affects how much and what kind of retesting to perform based on testing data and results from previous stages or from other teams (e.g., how much does the product owner performing acceptance testing trust the product development team performing readiness assessment).

Usage Context

Software can be built for many different kinds of usage and the organization that builds or commissions it affects how the software is built and accepted. Figure 1 – The Product Context illustrates one way of classifying the software-intensive systems we build.
Figure 1
Figure 1 The Product Context (courtesy of Jeff Patton; used with permission)
Some organizations build software for their own internal usage to reduce costs while others build products to sell to others to generate revenue. The left side of the quadrant diagram describes what is commonly called enterprise software; software that is built by the enterprise for its own use. The right side of the diagram represents software that is built for sale to other parties either as software in its own right (which may be installed on site or software-as-a-service) or as software embedded in a hardware product. Some of the products built on the right side of the diagram show up as tools, components, frameworks or products used in the construction of the enterprise products on the left side of the diagram. Independently of this, the users of the software may be captive users who are compelled to use the product once it is available or they may choose to use the product or a competing product. The process of accepting software can vary based on this context.

Enterprise Systems

Enterprise systems are commissioned by an enterprise for its own internal use. The systems automate all or part of various business processes. The use cases of each system implement one or more steps of a business process, either in whole or in part as illustrated by the left side of Figure 2. They may be built from scratch by writing code, composed of purchased components or created by configuring a packaged product purchased from a vendor (on the right side of Figure 2.) The work may be done by a part of the enterprise, often called the Information Technology (IT) or Information Systems (IS) department, or the development may be outsourced to a third party. Many of these systems tend to be integrated with other systems within the enterprise (which often include legacy systems) and a large part of the challenge of building and accepting these systems is ensuring that the integration works correctly as illustrated by the right side of Figure 2.
Figure 2
Figure 2 Business Process vs. Systems Integration View
The integration requirements may take many forms including data replication/synchronization and transactional interactions to name just a few, but all should be driven from the business requirements. Acceptance of enterprise systems involves determining whether or not the system will meet its business-enablement or cost reduction targets.
Figure 2 also points out the cause of many potential issues: acceptance is done from a business process perspective while many Product Develoment Teams are focused exclusively on a subset (often just one) of the systems that implement the process. This can lead to mismatches between business expectations and what the IT department delivers. This is especially true when IT is organized around the systems (as component teams) rather than business processes (as feature teams) (see discussion on component teams vs feature teams in the Accepting Complex Product section of Chapter 2) or when development of the system is outsourced. The latter is particularly fraught with peril as the outsourcer may not understand anything about the business.
Because the software is commissioned by the enterprise itself, there is the potential for a large degree of business involvement in the development process. This can result in software that is a very good fit for the business. Unfortunately, many businesses delegate the hard work of defining their requirements to the product development team, whether internal or outsourced, and effectively abdicate control over what is built. This often results in barely usable systems that have long, painful acceptance phases. A good way to avoid this is to have strong business ownership and stewardship of the development of these systems in the form of an informed product owner who makes the critical decisions about what the systems should support and what it should not. This position goes by various formal titles such as business sponsor, business lead or product owner. If a critical decision requires technical knowledge and the product owner is not technically-savvy, the product owner needs assistance from the product development team or outside advice to make the decision.
The software in the bottom left quadrant of Figure 1 is typically embedded in a business workflow implementing one or many steps of the business process. The users do not have a choice of whether or not to use the software because using it is part of their job. Users are highly accessible therefore can be used for usability testing and acceptance testing but because usage is non-optional there is an unfortunate tendency of the product owner to ignore the usability attributes of the system. The users are often involved in the acceptance testing process in an activity often called user acceptance testing (UAT).
The software in the top left quadrant of Figure 1 is different in that users are not compelled to use the product even though it was built for internal use. The product owner tries to represent the needs of the real user who may or may not be accessible. For example, the software may be used primarily by in-house users who are accessible, or it may be designed for the use of people outside the company including customers or business partners. The system may be standalone but is more likely to be integrated behind the scenes with other software within the enterprise.

Software-Intensive Products

Many products in the modern world, from toys to automobiles, have a software component and the amount of such embedded components is steadily increasing, especially with regards to the portion of the value-added to the final product. This software is what provides the complex behaviors that characterize products in the 21st century. These products have been a large part of the growth of modern economies. Acceptance of these products involves deciding whether the product as built will meet its revenue targets, contribute or detract from the brand image, and possibly other factors. The product requirements are typically driven by a product manager.
The software in the bottom right quadrant of Figure 1 is built by one company for sale to another company. This software may be purchased and used as-is. Or it may be designed to be configured or customized by or for the customer to fit within their enterprise environment (on the left side of the diagram.) The notion of acceptance then has an interesting twist in that the generic product must first be accepted by the product manager before being made available to the customers who may then have it configured or customized before accepting it for deployment within their organizations. This is described in more detail in section Accepting Customizable Products in Chapter 1 -- The Acceptance Process.
The software in the top right quadrant may be purely software for use by consumers (so called “shrink wrapped” software) or it may be embedded in a hardware product. In either case the end user is too numerous (and is often not available) to involve in the acceptance process. Note that there may be additional specialized techniques used for building and assessing embedded products and these specialized techniques are out of scope for this guide but many of the techniques described here do apply to embedded products.

Business Goals

Business goals affect how the software will be accepted. Too many projects are run with a majority of the staff not understanding (or even caring about) the business goals of the project. Sometimes this is the result of deliberate decisions by management to withhold information, and sometimes it is just an oversight. Either way, we should expect to get suboptimal results if each team member is focused on optimizing his or her own job assignment instead of ensuring that business goals are achieved.
As a bare minimum, we should ensure that everyone on the project has a clear understanding of what the project is expected to deliver and how that will provide value to the business. Example of different ways to add value to the business include reduced costs, increased sales, more satisfied users, and improved market perception/branding.

Scope

Scope determines what needs to be included before the product will be accepted. The scope of the project should realize the business goals. At the broadest levels, the scope can be defined in terms on the types of users we expect to support and the types of functionality that the product will supply to them. It is as important to explicitly indicate what is outside the scope as it is what is inside; otherwise we risk wasting time and energy discussing, and possibly building and testing functionality, that is supposed to be excluded. When the requirements change or evolve after development starts and the scope needs to be revisited, the decision to change already scoped functionality or expand it to include any previously excluded functionality should be intentional, rational, and explicit. An important question the Product Development Team should ask the Product Owner in that case is what existing stories/features in the product backlog should be replaced with a new story.

Stakeholders and Users

Stakeholders and users affect who plays what role in the acceptance process. Accepting software requires the involvement of various stakeholders. Some are directly involved in the acceptance testing and decision-making process, while others need to have their interests protected even though they are not involved.

Users

The most obvious usage goal holders are the people (or systems) who are to use the core functionality of the system. Typically, these people are referred to as “the users.” They are the ones who use a Web site for doing their banking, entertainment, or online shopping; use an application for executing one or more steps of a business process; or operate a combined software/hardware product such as a medical imaging system. But these are not the only people interacting with the system. Other users include the people who administer the system by populating the catalog of the online store or set up the content in an online entertainment system; the people who run diagnostics on and maintain the system. There are also people (or systems) who install the system, start it, monitor its status, and shut it down when the servers need maintenance. They all have requirements with respect to how they use the system. For more information about users and their goals, see the User Modeling activity in Volume 2 of this series.

System Stakeholders

There are also stakeholders [ACUC] who will not directly interact with the system when it is in operation but who expect the system to look out for their interests as it is used (or abused) by others. For example, a system that contains personal information about someone has that person as a stakeholder even if they themselves do not directly interact with the system. This is an example of a non-functional requirement.

Project Stakeholders

Products and IT systems are usually developed within a project. There may be many defined roles within the project, some of which may be played by users or system stakeholders and some by unique parties. These project stakeholders may be involved in the acceptance testing or acceptance decision-making process without being a direct system stakeholder or user. For example, the product manager or product owner may never use the system, nor be a system stakeholder, but they definitely have a stake in the acceptance decision process. The business sponsor of an IT project may never use the product in the field or even view a report it generates, but the person in this role has a clear stake in the project’s outcome in the form of the expected business benefits in return for the investment of time and money.

Communication Between Stakeholders

The likelihood of acceptance of a software-intensive system is directly proportional to the effectiveness of the communication between those who commissioned the software (the product owner or the product owner team) and the team building the software (the product development team). The requirements and the tests are part of this communication. The communication is made much more effective if there is a common language that everyone agrees to use consistently.
The common language that everybody in the product development team and the product owner team shares is often referred to as a Ubiquitous Language [EvansOnDomainDrivenDesign]. The members of the product owner team are the domain experts and articulate the requirements in the language of the domain. However this language should be accessible to and understood by the product development team. Conversely, the technical jargon that the development team uses to express general development concepts relating to the customer facing aspects of the project (in the design, architecture, testing, and acceptance of the product) should not need to be accessible to and understood by the product owner team. The Ubiquitous Language of the whole team should be developed through close interaction across and within the product owner and development teams early in the project to be effective in reducing the communication overhead and avoiding costly, late misunderstandings.

Budget

Most projects have a fixed budget. This tends to constrain the number of people who will work on the project both in number and in rate of pay. Once the team size and composition is defined, the team will exhibit a well-defined burn rate and any extension of the project timelines due to late delivery of the software will translate into budget overruns unless a significant buffer is held back when planning the project.
An incremental funding approach [DenneCleland-Huang] is a viable alternative to a fixed budget, and provides flexibility in cost management, scheduling, resource allocation, team composition, and scoping. Incremental funding relies on prioritizing and scheduling groups of usable , high-value features early in the process and committing resources for such chunks of functionality in a piecemeal manner. Incremental funding is particularly suitable for projects that exhibit high cost, schedule, business and technical, uncertainty.

Hard Deadlines

All projects face deadlines of one sort or another. Some projects routinely miss many of these deadlines. When the business consequence of missing a deadline is significant, we should take the appropriate measures to ensure that the deadlines are not missed, such as a planning contingency buffer or cutting scope. Therefore, it is essential to understand which deadlines are arbitrary (such as in "It would be really great if we could have that functionality by September") or critical (such as in "We need to demonstrate this functionality at the trade show in September and failure to do so could significantly affect our fourth quarter sales and our share price.") In the former case, missing the deadline may result in slight or even no inconvenience. In the latter case, the value of the delivery could diminish to zero making the product and the project that delivers it completely irrelevant.

Recovery from Development Schedule Slippage

A major issue with hard delivery deadlines relates to the perceived compressibility of the acceptance testing phase (and testing in general.) This is particularly an issue when the delivery date is fixed and immovable. When the development phase is running late, as it often does on waterfall project, there is great pressure on the entire team to recover the schedule slippage somehow. There are two techniques commonly employed, each with their own difficulties.

Compressing the Test Cycle

Readiness assessment and acceptance testing will typically start late but is often expected to make up the schedule slippage by reducing the length of the test cycle. This results in less testing than planned and therefore likely more bugs slip through to production. In other words, the acceptance decision is made based on incomplete data about the quality of the product.

Overlapping Test Cycle with Development

The other schedule recovery technique that is often used with hard deadlines is to ask the testers to start testing the product before it is completely finished. While this practice, Incremental Acceptance Testing , is considered normal on an agile project, a project planned as a strictly sequential project cannot adopt this practice easily mid-project. For example, many features may be 80% done rather than 80% of the features being completely done and testable. Therefore it is hard for the testers to know what to test because there isn’t a clear list of what should be working now. Another issue is that Incremental Acceptance Testing usually includes extensive automated regression testing so that the testers can focus on the newly completed functionality rather than having to manually retest everything. The automated regression testing is also a key form of bug repellent used by the developers to avoid introducing regression bugs by detecting these bugs as part of readiness assessment so they can be fixed before the new release candidate is passed on to the testers.

Constraints

Most projects operate under some kind of constraints. Constraints can include people and skills or facilities and equipment. Sometimes these constraints can be loosened, while they are strictly limited at other times. A company may not be able to hire additional staff or recruit people with specific skills. For example, the skill level of the staff performing testing may have a significant influence on the testing approaches used, the amount of testing done, and the time it takes to test. In these cases we need to create the best possible plan that allows us to meet our goals without hiring additional staff. This may result in very different plans than if we were able to hire additional staff.

Resources

[ACUC] Alistair Cockburn “Writing Effective Uses Cases” Addison Wesley
[BoehmTurner] Barry Boehm and Richard Turner. “Balancing Agility and Discipline” Addison Wesley
[Cockburn] Alistari Cockburn “Methodology per project”, Figure 9, http://alistair.cockburn.us/Methodology+per+project, Oct 19, 2009
[DenneClelandHuang] DenneClelandHuang0]"} Mark Denne and Jane Cleland-Huang, "The Incremental Funding Method: Data-Driven Software Development," IEEE Software, vol. 21, no. 3, pp. 39-47, May/June 2004
[EvansOnDomainDrivenDesign] Eric Evans, Domain-Driven Design, Addison-Wesley, 2003.

Last edited Nov 5, 2009 at 8:12 PM by rburte, version 4

Comments

No comments yet.