| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-I4IbR1GW6IFBCdq9SiMUsw" |
| name="core_principle_balance,_ssG6MMvpEdqukPpotm3DYg" guid="-I4IbR1GW6IFBCdq9SiMUsw" |
| changeDate="2007-07-03T06:24:43.871-0700" changeDescription="Removed metaphoric photo Removed open_up from page name." |
| version="0.02"> |
| <mainDescription><h3>
 |
| Introduction
 |
| </h3>
 |
| <p>
 |
| Systems are rarely all things to all people. Often, attempts to make them so are wasteful, and result in bloated
 |
| systems.
 |
| </p>
 |
| <p>
 |
| To be successful, stakeholders and the project participants must converge on a clear understanding and agreement of
 |
| these three factors:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Problem to be solved
 |
| </li>
 |
| <li>
 |
| Constraints placed on the development team (cost, schedule, resources, regulations, and so on)
 |
| </li>
 |
| <li>
 |
| Constraints placed on the solution
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The challenge for all project participants is creating a solution that maximizes the value delivered to the
 |
| stakeholders, subject to the constraints. Balance is about making the critical, cost-benefit trade-offs between desired
 |
| features and the subsequent design decisions that define the architecture of the system.
 |
| </p>
 |
| <p>
 |
| Discovering the balance point is challenging, elusive, and ongoing, because the balance point is dynamic. As the system
 |
| evolves, stakeholder needs change, new opportunities appear, risks are resolved, new risks appear, and the development
 |
| team discovers new realities about the system. Change happens throughout the development cycle. Stakeholders
 |
| and team members must be prepared to re-evaluate commitments, reset expectations, and adjust plans
 |
| accordingly as the system evolves.
 |
| </p>
 |
| <h3>
 |
| Practices
 |
| </h3>
 |
| <h4>
 |
| Know your audience
 |
| </h4>
 |
| <blockquote>
 |
| <p>
 |
| You cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really
 |
| want.
 |
| </p>
 |
| <p>
 |
| Get to know your stakeholders. Better yet, work closely with them to ensure that you know their needs. Start
 |
| by identifying all stakeholders, and then maintain open and frequent communication and collaboration between them
 |
| and the development team.
 |
| </p>
 |
| </blockquote>
 |
| <h4>
 |
| Separate the problem from the solution
 |
| </h4>
 |
| <blockquote>
 |
| <p>
 |
| Too often, we run headlong into a solution without understanding the problem. After all, we are taught how to solve
 |
| problems, not how to define problems, so that's easier. However, this limits your understanding of the problem,
 |
| imposes artificial constraints, and makes it difficult to balance trade-offs, or to even know what the
 |
| trade-offs are.
 |
| </p>
 |
| <p>
 |
| Make sure that you understand the problem before you define the solution. By clearly separating the problem (what
 |
| the customer needs) from the solution (what the system must do), it is easier to maintain the proper focus, and
 |
| easier to accommodate alternate ways of solving the problem.
 |
| </p>
 |
| </blockquote>
 |
| <h4>
 |
| Create a shared understanding of the domain
 |
| </h4>
 |
| <blockquote>
 |
| <p>
 |
| Domain experts often have limited technical expertise; developers, architects, and testers often have limited domain
 |
| expertise; and reviewers and other stakeholders often have limited time to commit to the project and learn the
 |
| problem domain. As a result, people often have an inconsistent or poor understanding of the problem domain, which
 |
| causes communication problems and increases the likelihood of delivering poor value to the stakeholders.
 |
| </p>
 |
| <p>
 |
| Enhance and share all parties’ understandings of the domain. A concise and shared understanding of the problem
 |
| domain enhances communication and project effectiveness. Start by defining the problem in the Vision document. As
 |
| your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent,
 |
| shared use of the language of the domain.
 |
| </p>
 |
| </blockquote>
 |
| <h4>
 |
| Use scenarios and use cases to capture requirements
 |
| </h4>
 |
| <blockquote>
 |
| <p>
 |
| Many companies still document requirements as a list of declarative statements, which are sometimes called the
 |
| ”shall statements.” These lists are often difficult for stakeholders to understand, because they require the end
 |
| user to read through and mentally translate the list into a visualization of how the requirements will interact
 |
| with the system.
 |
| </p>
 |
| <p>
 |
| Make use of scenarios and use cases to capture functional requirements in a form that is easy for stakeholders
 |
| to understand. Nonfunctional requirements, such as performance, stability, or usability requirements, are important
 |
| and can be documented as supporting requirements, using traditional techniques.
 |
| </p>
 |
| </blockquote>
 |
| <h4>
 |
| Establish and maintain agreement on priorities
 |
| </h4>
 |
| <blockquote>
 |
| <p>
 |
| Making poor decisions in deciding what to develop next can result in wasted effort, delivering capabilities that
 |
| are never used, or identifying problems late in the project (resulting in delays and even project failure).
 |
| </p>
 |
| <p>
 |
| Prioritize requirements for implementation by regularly working with the stakeholders during product evolution.
 |
| Make choices that deliver value and reduce risks, while building a system that can evolve.
 |
| </p>
 |
| </blockquote>
 |
| <h4>
 |
| Make trade-offs to maximize value
 |
| </h4>
 |
| <blockquote>
 |
| <p>
 |
| Cost-benefit trade-offs cannot be made independent of the architecture. Requirements establish the benefits of the
 |
| system to the stakeholder, while architecture establishes the cost. The cost of a benefit may influence the
 |
| stakeholder's perceived value of the benefit.
 |
| </p>
 |
| <p>
 |
| Work with the stakeholders and team members to prioritize requirements and develop candidate
 |
| architectures to implement those solutions. Use the candidate architectures to evaluate the cost of the benefits.
 |
| Candidate solutions are considered at a high level when determining architectural feasibility. Different
 |
| architectural perspectives can result in different assessments of cost versus benefit. The candidate
 |
| architecture that provides the most coverage at the lowest cost is selected for further development.
 |
| </p>
 |
| </blockquote>
 |
| <h4>
 |
| Manage scope
 |
| </h4>
 |
| <blockquote>
 |
| <p>
 |
| Change is inevitable. Although change presents opportunities to enhance stakeholder value, unconstrained change
 |
| will result in a bloated, deficient system and unmet stakeholder needs.
 |
| </p>
 |
| <p>
 |
| Manage change while maintaining agreements with the stakeholders. Modern processes always manage change,
 |
| continually adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making
 |
| trade-offs, and re-prioritizing work. Stakeholder and developer expectations must be realistic and aligned
 |
| throughout the development lifecycle.
 |
| </p>
 |
| </blockquote>
 |
| <h4>
 |
| Know when to stop
 |
| </h4>
 |
| <blockquote>
 |
| <p>
 |
| Over-engineering a system not only wastes resources, but also leads to an overly complex system.
 |
| </p>
 |
| <p>
 |
| Stop developing the system when the desired quality is achieved. Remember that “Quality is conformance to the
 |
| requirements” <a href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#CRO79" guid="_9ToeIB83Edqsvps02rpOOg">[CRO79]</a>. This is what gives a sense of closure to the practice. Separate the
 |
| problem from the solution, ensuring that the solution does, indeed, solve the problem. After the critical
 |
| requirements are implemented and validated, the system is ready for stakeholder acceptance.
 |
| </p>
 |
| </blockquote></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
