What Artifacts May Start in Inception? - UML

Table lists common inception (or early elaboration) artifacts and indicates the issues they address. Subsequent chapters will examine some of these in greater detail, especially the Use - Case Model. A key insight regarding iterative development is to appreciate that these are only partially completed in this phase, will be refined in later iterations, and should not even be created unless it is deemed likely they will add real practical value. And since it is inception, the investigation and artifact content should be light.

For example, the Use - Case Model may list the names of most of the expected use cases and actors, but perhaps only describe 10% of the use cases in detail - done in the service of developing a rough high - level vision of the system scope, purpose, and risks.

Note that some programming work may occur in inception in order to create "proof of concept" prototypes, to clarify a few requirements via (typically) Ul - oriented prototypes, and to do programming experiments for key "show stopper" technical questions.

Table Sample inception artifacts

Table Sample inception artifacts

Isn't That a Lot of Documentation?

Recall that artifacts should be considered optional. Choose to create only those that really add value for the project, and drop them if their worth is not proved.

And since this is evolutionary development, the point is not to create complete specifications during this phase, but initial, rough documents, that are refined during the elaboration iterations, in response to the invaluable feedback from early programming and testing.

Also, often the point of creating artifacts or models is not the document or diagram itself, but the thinking, analysis, and proactive readiness. That's an Agile Modeling perspective: that the greatest value of modeling is to improve understanding, rather than to document reliable specifications. As General Eisenhower said, "In preparing for battle I have always found that plans are useless, but planning indispensable" [Nixon 90, BFOO].

Note also that artifacts from previous projects can be partially reused on later ones. It is common for there to be many similarities in risk, project management, testing, and environment artifacts across projects. All UP projects should organize artifacts the same way, with the same names (Risk List, Development Case, and so on). This simplifies finding reusable artifacts from prior projects on new engagements.

You Know You Didn't Understand Inception When...

  • It is more than "a few" weeks long for most projects.
  • There is an attempt to define most of the requirements.
  • Estimates or plans are expected to be reliable.
  • You define the architecture (this should be done iteratively in elaboration).
  • You believe that the proper sequence of work should be:
    1. define the requirements;
    2. design the architecture;
    3. implement.
  • There is no Business Case or Vision artifact.
  • All the use cases were written in detail.
  • None of the use cases were written in detail; rather, 10 - 20% should be written in detail to obtain some realistic insight into the scope of the problem.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics