blob: 427aee5525ad7f2c2c4d14615e5ba101d02f68d5 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" rmc:version="7.1.0" epf:version="1.0.0">
<org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_BfL5Edm6Nvont3uinw" guid="_mtb_BfL5Edm6Nvont3uinw"/>
<org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_B_L5Edm6Nvont3uinw" guid="_mtb_B_L5Edm6Nvont3uinw"/>
<org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_CfL5Edm6Nvont3uinw" guid="_mtb_CfL5Edm6Nvont3uinw"/>
<org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_CvL5Edm6Nvont3uinw" guid="_mtb_CvL5Edm6Nvont3uinw"/>
<org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_BvL5Edm6Nvont3uinw" guid="_mtb_BvL5Edm6Nvont3uinw"/>
<org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_C_L5Edm6Nvont3uinw" guid="_mtb_C_L5Edm6Nvont3uinw"/>
<org.eclipse.epf.uma:ProcessDescription xmi:id="_mtb_BPL5Edm6Nvont3uinw" guid="_mtb_BPL5Edm6Nvont3uinw">
<mainDescription>&lt;h3&gt; Introduction &lt;/h3&gt;
&lt;p&gt; Most activities during a typical iteration in Elaboration phase happen in
parallel. Essentially, the main objectives for Elaboration are related to better
understanding the requirements, creating and establishing
a baseline for the architecture for the system, and mitigating top-priority
risks. &lt;/p&gt;
&lt;p&gt; The activities performed in a typical iteration during&amp;nbsp;the
Elaboration phase are described below. &lt;/p&gt;
&lt;h4&gt; Manage iteration &lt;/h4&gt;
&lt;p&gt; This activity is performed throughout the project lifecycle.
The goal of this activity is to identify risks and issues early enough
that they can be mitigated, to establish the goals for the iteration,
and to support the development team in reaching these goals. &lt;/p&gt;
&lt;p&gt; The &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;&gt;project
manager&lt;/a&gt; and the team launche the iteration, allocating work items to team
members (some project teams will prefer to have members volunteer to perform
work). The project manager collaborates with the team to break down the work
items into development tasks to perform in that iteration. This provides a more
accurate estimate of time to spend on what can be realistically achieved. &lt;/p&gt;
&lt;p&gt; As the iteration runs, the project manager performs
monitoring and control of&amp;nbsp;the project by regularly checking the
status of work completed, the work to do
next, and issues blocking the progress&lt;strong&gt;.
&lt;/strong&gt;In some projects, this checking occurs
in daily meetings, which allows for a&amp;nbsp;more precise&amp;nbsp;understanding
of how the work in an iteration is progressing. As
needed, the&amp;nbsp;team makes corrections to achieve what was planned. The overall
idea is that risks and issues are identified and managed throughout the iteration.
And everyone knows the project status.&lt;/p&gt;
&lt;p&gt;The prioritization of work for a given iteration takes place. Project manager,&amp;nbsp;&lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html&quot; guid=&quot;_dTa6gMAYEdqX-s4mWhkyqQ&quot;&gt;stakeholders&lt;/a&gt;,
and the remaining team members agree on what is supposed to be developed during
that iteration.&lt;/p&gt;
&lt;p&gt;As in any other iteration assessment, demonstration of implemented functionality
planned for that iteration is the key success criterion. During iteration assessments
in Elaboration, though, keep the phase objectives in mind. As Elaboration iterations
are performed, an executable architecture evolves, and you establish a baseline
at the end of the phase. In addition, requirements are better understood and
detailed. Essential risks, including the architectural ones, have been mitigated.
These results&amp;nbsp;help the project manager produce more accurate estimates
for the project schedule and cost.&lt;/p&gt;
&lt;h4&gt; Manage requirements &lt;/h4&gt;
&lt;p&gt; This activity is repeated throughout the project lifecycle.
The goal of this activity is to understand and prioritize stakeholder needs
and associated requirements for the system, and also to
capture these in a form that supports effective communication and collaboration
between the stakeholders and development team. &lt;/p&gt;
&lt;p&gt; During the Elaboration phase,
requirements can still be captured and outlined as customer needs arise. The
prioritization of requirements determines when
new requirements are going to be implemented. High-risk, architecturally significant
requirements are detailed to the extent necessary to be
able to use that information as input to architecture and development
activities in the current iteration, plus in planning
for the next iteration.&lt;/p&gt;
&lt;p&gt;&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0ZS-0MlgEdmt3adZL5Dmdw&quot;&gt;Test
cases&lt;/a&gt; describe which&amp;nbsp;requirements are being tested&amp;nbsp;in that iteration.
&lt;p&gt; &lt;strong&gt;Note: &lt;br /&gt;
&lt;/strong&gt;The emphasis on finding, outlining and detailing requirements varies
from phase to phase. Iterations in Inception and early Elaboration tend to focus
more on identifying and outlining requirements in general and on
detailing high-priority and architecturally
significant requirements. During iterations in late Elaboration and early Construction,
the remaining requirements are usually outlined and detailed. &lt;/p&gt;
&lt;h4&gt; Define the architecture &lt;/h4&gt;
&lt;p&gt; This activity is repeated in each iteration in the
Elaboration phase. The main&amp;nbsp;goal of this activity is&amp;nbsp;to propose an
&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0XAf0MlgEdmt3adZL5Dmdw&quot;&gt;architecture&lt;/a&gt;
that addresses the requirements with high architectural risks, thus providing
a solid, yet resilient, foundation on which to build the system functionality.&lt;/p&gt;
&lt;p&gt; The &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;&gt;architect&lt;/a&gt;
analyzes the architectural constraints, identifies available assets to build
the system, defines how the system will be structured, and identifies the initial
abstractions and mechanisms that must be provided by the architecture. &lt;/p&gt;
&lt;p&gt; Throughout all of the iterations, the architect: &lt;/p&gt;
&lt;li&gt; Identifies commonalities between different requirements to leverage reuse
&lt;li&gt; Defines strategies for achieving requirements related
to quality&lt;/li&gt;
&lt;li&gt; Captures and communicates architectural decisions &lt;/li&gt;
&lt;h4&gt; Develop solution for requirement within context&lt;/h4&gt;
&lt;p&gt; This activity is instantiated multiple times, in parallel, for each development
task planned for that iteration. The main goal of this activity is an executable
system that provides the incremental quality and functionality for the specified
requirements within the specified context. &lt;/p&gt;
&lt;p&gt; As the requirements planned for the iteration are broken down into development
tasks, these are assigned by the project managers to &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0YDosMlgEdmt3adZL5Dmdw&quot;&gt;developers&lt;/a&gt;
(some project teams prefer to have team members sign up for development tasks
themselves). &lt;/p&gt;
&lt;p&gt; The solution to be developed is for a particular requirement within a context,
which reflects the idea of breaking down requirements into development tasks.
As an example, a particular use-case scenario within the context of database
access could be assigned to a developer; whereas, the same scenario within the
user interface and business logic contexts could be assigned to a different
developer. In this example, more than one developer is working on a particular
piece of functionality to be delivered in a particular iteration. As they develop
the requirement within the context they were assigned to, they perform&amp;nbsp;&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0YuXEclgEdmt3adZL5Dmdw&quot;&gt;tests&lt;/a&gt;
and integrate their work to create &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0YuXEMlgEdmt3adZL5Dmdw&quot;&gt;builds&lt;/a&gt;.
&lt;h4&gt; Validate build &lt;/h4&gt;
&lt;p&gt; This activity is repeated throughout the project
lifecycle. The main goal of this activity is to validate the current increment
of the system against the requirements allocated to it. &lt;/p&gt;
&lt;p&gt; The intent is to validate that the high-priority requirements implemented
reflect a robust architecture so that remaining requirements can be implemented
on top of that architecture. As developer develop the solution for the requirements
in a given iteration, the integrated source code is unit-tested. Then, a separate
&lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0ZM4MclgEdmt3adZL5Dmdw&quot;&gt;tester&lt;/a&gt;
conducts system-level testing in parallel with development to make sure that
the solution, which is continuously being integrated, matches what is specified
in the requirements. Then, the tester defines what techniques to use, what the
data input is, what &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/guidances/guidelines/test_suite,_0aDz0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0aDz0MlgEdmt3adZL5Dmdw&quot;&gt;test
suites&lt;/a&gt; to create. As tests are performed, defects found are reported and
added to the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;&gt;work
items list&lt;/a&gt;, so they can be prioritized and assigned to team members. &lt;/p&gt;
&lt;h4&gt; Ongoing tasks &lt;/h4&gt;
&lt;p&gt; This activity includes tasks that happen throughout the iteration on an ongoing
basis but are not necessarily part of a plan. For example, at any time, &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0dsWoMlgEdmt3adZL5Dmdw&quot;&gt;any
role&lt;/a&gt; in the project team can issue a &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html&quot; guid=&quot;_6jdvECb3Edqh1LYUOGRh2A&quot;&gt;change
request&lt;/a&gt;, either because there are requests for enhancements, or defects
are found. These change requests are part of the work items list and are prioritized
and assigned to team members. Anyone can be assigned to make changes that develop
enhancements or fix defects. &lt;/p&gt;
&lt;h4&gt;&amp;nbsp; &lt;/h4&gt;</mainDescription>