| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\openup_basic\capabilitypatterns\develop_solution\content.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: content.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_h2-iAfimEdmugcVr9AdHjQ CRC: 2237470038 -->Develop Solution (for requirement) (within context)<!-- END:presentationName,_h2-iAfimEdmugcVr9AdHjQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_h2-iAfimEdmugcVr9AdHjQ CRC: 1575460021 -->Design, implement, test and integrate the solution for a requirement within a given context.<!-- END:briefDescription,_h2-iAfimEdmugcVr9AdHjQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,_h6zSEPimEdmugcVr9AdHjQ CRC: 788556680 --><h3> |
| Introduction |
| </h3> |
| <p> |
| Project managers use this Capability Pattern as a way to perform a goal-based planning and management. Work |
| is assigned to developers and work progress is tracked based on the goals to be achieved using the designed, |
| unit-tested, and integrated source code. |
| </p> |
| <h4> |
| Context of what is being developed |
| </h4> |
| <p> |
| A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is |
| to be developed in a iteration. Development may focus on a layer (such as the user interface, business logic, |
| or database access), on a component, and so on. |
| </p> |
| <p> |
| Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that |
| requirement, then to write and run unit tests against the implementation to make sure the implementation |
| works as designed, both as a unit and integrated into the code base. |
| </p> |
| <h4> |
| Overview of workflow |
| </h4> |
| <p> |
| To accommodate major changes or major functionality to be developed, architecture may have to be refined. Small |
| changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial |
| changes and functionality to be developed, only the source code may be affected. |
| </p> |
| <p> |
| In any case, there is no strict sequence for how writing code and creating or running developer tests should |
| happen, because they can happen in parallel. You may choose to create developer tests and run them before the actual |
| code is created or the reverse sequence. |
| </p><!-- END:mainDescription,_h6zSEPimEdmugcVr9AdHjQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: purpose<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:purpose,_h6zSEPimEdmugcVr9AdHjQ CRC: 2872432095 --><ul> |
| <li> |
| For developers: To create a solution for the requirement assigned to them |
| </li> |
| <li> |
| For project managers: To have a goal-based way of assigning work and tracking project status |
| </li> |
| </ul><!-- END:purpose,_h6zSEPimEdmugcVr9AdHjQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: usageNotes<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:usageNotes,_h6zSEPimEdmugcVr9AdHjQ CRC: 3966273720 --><p> |
| This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each |
| requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to |
| be assigned to a developer, and it should be renamed to include the actual requirement name. Optionally, the word |
| <strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way: |
| </p> |
| <blockquote> |
| <p align="left"> |
| Develop requirement_name (within context_name context) |
| </p> |
| </blockquote> |
| <p> |
| If a context is specified, there will be one instance of this pattern for each requirement for each |
| context. |
| </p> |
| <blockquote> |
| <p> |
| <strong>Example</strong> |
| </p> |
| <ol> |
| <li> |
| Develop scenario 1 (within user interface context) |
| </li> |
| <li> |
| Develop scenario 1 (within business logic and DB access context) |
| </li> |
| <li> |
| Develop scenario 2 |
| </li> |
| <li> |
| Develop supplemental requirement 1 |
| </li> |
| </ol> |
| </blockquote> |
| <p> |
| Note that there are four instances of this pattern in the preceding example: |
| </p> |
| <ul> |
| <li> |
| The first two are related to the same requirement (scenario 1) but within two different contexts |
| </li> |
| <li> |
| The last two are related to different requirements, with no context specified. |
| </li> |
| </ul><!-- END:usageNotes,_h6zSEPimEdmugcVr9AdHjQ --> |
| </body> |
| </html> |
