We realized a few antipatterns of the OpenUP process, including “analysis paralysis”. Meaning, we lingered too long on requirements without working towards a product increment. These sections describe our effort to get back on track. In other words, this is our plan to realign our process with OpenUP.
We followed these steps to create our realignment plan. Determine which phase best fits our current log of completed work Given the chosen phase, identify gaps in completed work Fill those gaps to bring the project up to speed ## Analysis First, we needed to decide which OpenUP phase to enter starting 10/13/2015. We have extracted useful information for the phases into this document; some of it is copied verbatim from the OpenUP wiki. ### Inception Phase OpenUP provides documentation for the inception phase. There are four objectives of the phase. We have marked which objectives we believe have been met.
- Understand what to build (Complete)
- Identify key system functionality (Complete)
- Determine at least one possible solution
- Understand the high-level schedule and risks (Partial, no scheduling of phases)
In order to move on from the inception phase, the team must agree on project scope and objectives.
OpenUP provides documentation for the elaboration phase. There are three objectives:
- Get a more detailed understanding of the requirements
- Design, implement, validate, and establish the baseline for the architecture.
- Mitigate essential risks, and produce accurate schedule and cost estimates.
In order to move on from the elaboration phase, “do we agree on the executable architecture to be used for developing the application, and do we find that the value delivered so far and the remaining risk is acceptable?”
Which Phase are We In?
Based on the OpenUP wiki, we should be in the elaboration phase. However, there are unfilled gaps from the inception phase. We need to schedule the OpenUP phases on a calendar, with milestones and gating criteria listed there. Also, we should have started design and implementation straight away. This bit from the “Detail Use-Case Scenarios” task highlights this:
Some use cases and scenarios might need to be described in more detail to validate the understanding of the requirements and to permit software development to begin. This does not imply that all use cases and scenarios will be detailed prior to commencing implementation on them. The level of detail captured will vary depending upon the needs of the project and the complexity of the use case. Capture the use case and scenarios details in the use case specification.
The biggest gap between our current status and the elaboration phase is an envisioning of the architecture. We need to look at the ASR’s and develop quality attributes. We need to create an initial architecture for what we know today.
- Analyze QA’s and architecturally significant requirements
- Plot out phases and iterations specifically on our calendar
- Find out if narratives are still in the project scope
- Start prototyping / implementing
- Create the first iteration plan