1 / 98

From Inception to Elaboration

Learn about the inception and elaboration phases of software development, including activities, artifacts, and best practices. Understand the importance of timeboxing iterations, creating stable software architecture, and adapting based on feedback. Gain insights into requirements ranking, planning, and the creation of system sequence diagrams.

kliebert
Download Presentation

From Inception to Elaboration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. From Inception to Elaboration

  2. Objectives • Elaboration is the initial series of iterations during which the team does the following • Serious investigation • Discover & stabilize major requirements • Mitigate/retire risks ( business value ) • Build core architecture elements • Estimate overall schedule and resources • Establish a supporting environment

  3. Inception - Artifacts and Activities (1) • Short Requirements workshop • Naming most actors, goals, use cases • Keep use cases brief (10-20% are in fully dressed) • Identify most risky & influential quality requirements • First version of Supplementary Specification and vision are written

  4. Inception - Artifacts and Activities ( 2 ) • Risk list (including deadlines on demo) • Technical feasibility investigation (does the requirements supported by our used technology? ) • UI oriented prototypes to clarify vision • Buy/build/reuse components (ex: recommendations to buy a tax calculator) • High-level candidate architecture (a rough estimate of various accessories; a java front end? ) • Plan for the first iteration • Candidate tools list

  5. Elaboration - Key Ideas • Not a waterfall model ! • Two to six weeks for each iteration • Timeboxed iterations (deadlines should be strictly maintained) • Each iteration products ends in a stable and tested release

  6. Architecture Prototype/Baseline • Not a partial system • Evolutionary prototype of final product • Don’t create throw-away prototypes • Production subset of final system • Also called Executable Architecture

  7. Best Practices • Start programming early • Adapt based on feedback from tests, users, developers • Design, implement and test adaptively • Test early and realistically • Requirements and use case details through series of workshops (once per iteration)

  8. Requirements and Iterations ranking depends on…. • Risk -includes technical complexity and other factors. • Coverage -whether all major parts are covered or not. • Criticality -functions of high business value.

  9. Ranking • Rank work across iterations • High ranking scenarios in early iterations (ex: process sales, logging, etc.) • Rank adaptively

  10. UP Artifacts planning • Iteration Plan:- only the next iteration is planned • Change Request:- plan written in greater detailed whenever necessary • Software Development Plan:- overall requirement ranking is recorded.

  11. Artifacts starting in Elaboration (this will not be completed rather refined over iterations) • Domain Model (conceptual class diagram) • Design Model (logical design: class diagram, object oriented diagram, etc.) • Software Architecture Document (summary of ideas and motivations) • Data Model (database schemas..) • Test Model • Implementation Model (source code, databases and so on. ) • Use-Case Storyboards and UI Prototypes (description of user interfaces, navigations etc.

  12. Inception and Elaboration • Main output is a stable software architecture, that enables quality planning of Construction and Deployment • 15 to 25 percent of total project cost

  13. You didn’t Understand Elaboration When … • No Timeboxed schedule • Single Iteration • Most requirements already defined • No Risk mitigation/resolution • No Executable Architecture • Requirements Phase • Attempt full and careful design

  14. You didn’t Understand Elaboration When (2)... • Minimal feedback and adaptation • No early and realistic testing • Frozen Architecture • No Proof-of-concept programming • No multiple requirements workshops

  15. Drawing System Sequence Diagrams

  16. Objectives • Identify System Events. • Create System Sequence diagrams for the events.

  17. Iteration 1 • First real development iteration. • The requirement work done during inception phase was to decide if the project was worth more serious investigation. • Before starting iteration 1 design work, further investigation of the problem domain is useful such as clarification of the input and output system events, related to the system.

  18. SSD versus Sequence Diagram • A System Sequence Diagram is an artifact that illustrates input and output events related to the system under discussion. • System Sequence Diagrams are typically associated with use-case realization in the logical view of system development. • Sequence Diagrams (Not System Sequence Diagrams) display object interactions arranged in time sequence.

  19. Sequence Diagrams • Sequence Diagrams depict the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the system. • Sequence diagrams can be used to drive out testable user interface requirements.

  20. SSD—System Behavior • System behaves as “Black Box”. • Interior objects are not shown, as they would be on a Sequence Diagram. :System

  21. System Sequence Diagrams • Use cases describe- • How actors interact with system. • Typical course of events that external actors generate and • The order of the events. • System Sequence Diagrams should be done for the main success scenario of the use-case, and frequent and alternative scenarios.

  22. Notation • Object:Objects are instances of classes. Object is represented as a rectangle which contains the name of the object underlined. • Because the system is instantiated, it is shown as an object. :Object1

  23. Notation (2) • Actor:An Actor is modeled using the ubiquitous symbol, the stick figure. actor1

  24. Notation (3) • Lifeline:The Lifeline identifies the existence of the object over time. The notation for a Lifeline is a vertical dotted line extending from an object.

  25. Notation (4) • Message:Messages, modeled as horizontal arrows between Activations, indicate the communications between objects. messageName(argument)

  26. Example of an SSD • Following example shows the success scenario of the Process Sale use case. • Events generated by cashier (actor)- makeNewSale() enterItem(itemID, quantity) endSale() and makePayment(amount).

  27. SSD for Process Sale scenario

  28. System Sequence Diagrams and Use Cases • System Sequence Diagram is generated from inspection of a use case. • Constructing a systems sequence diagram from a use case- 1.Draw a line representing the system as a black box. 2.Identify each actor that directly operates on the system. Draw a line for each such actor.

  29. System Sequence Diagrams and Use Cases      3.From the use case, typical course of events text, identify the system (external) events that each actor generates. They will correspond to an entry in the right hand side of the typical use case. Illustrate them on the diagram. 4.Optionally, include the use case text to the left of the diagram.

  30. SSDs are derived from use cases.

  31. System Events and System Boundary • Identifying the System events- • Determine the actors that directly interact with the system. • In the process Sale example, the customer does not directly interact with the POS system. Cashier interacts with the system directly. Therefore cashier is the generator of the system events.

  32. Defining system boundary (system itself).

  33. Naming System Events and Operations System event • External input event generated by an actor. • Initiates a responding operation by system. System operation • Operation invoked in response to system event.

  34. Naming System Events and Operations(2) • System events and their associated system operations should be expressed at the level of intent rather than in terms of the physical input medium or widget. • In order to improve the clarity, it is appropriate to start the name of the system event with a verb (for example- add….,enter….,end….,make…. etc.,). It also emphasizes the command origination of these events.

  35. Naming System Events and Operations(3) • For example “enterItem” is better than “scan” as it captures the intent of operation rather than what interface is used to capture the system event (design choice).

  36. Choose event and operation names at an abstract level

  37. Showing Use Case Text • It is desirable to show at least fragments of use case text for the scenario. • The text provides the details and context, while the diagram visually summarizes the interaction.

  38. SSD with use case text

  39. SSD and the Glossary • Since the terms used in SSDs are terse, they may need proper explanation. If these terms are not explained in use cases, glossary could be used. • A glossary is less formal, it is easier to maintain and more intuitive to discuss with external parties such as users and customers. • However, glossary data should be meaningful, otherwise it will be an unnecessary work.

  40. System Sequence Diagrams Within the Unified Process • System Sequence Diagrams are a visualization of the interactions implied in the use cases. • System Sequence Diagrams were not explicitly mentioned in the original UP description. • In UP Phases 1.Inception: System Sequence Diagrams are not usually motivated in inception.

  41. System Sequence Diagrams Within the Unified Process Elaboration:It is useful to createSystem Sequence Diagrams during elaboration in order to - • Identify the system events and major operations. • To write system operation contracts (Contracts describe detailed system behavior) and • To support estimation.

  42. Domain model: visualizing concepts

  43. Domain Model Relationships Domain Model Business Model Classes, attributes, associations Elaboration on some terms Domain objects Use Case Model Glossary Requirements Interaction Diagrams Design

  44. A Domain Model • illustrates meaningful conceptual classes in a problem domain. • is a representation of real-world concepts, not software components. • is NOT a set of diagrams describing software classes, or software objects and their responsibilities. • It may show: • 􀂉 concepts • 􀂉 associations between concepts • 􀂉 attributes of concepts

  45. Domain Model UML Notation • Illustrated using a set of class diagrams for which no operations are defined. • A Domain Model is a description of things in the real world. • 􀂄 A Domain Model is not a description of the software design. • 􀂄 A concept is an idea, thing, or object.

  46. A Domain Model is not a Software Artifact Software Artifacts: A Conceptual class: vs.

  47. Identify Conceptual Classesby Noun Phrase: • Identify Nouns and Noun Phrases in textual descriptions of the domain. • Fully dressed Use Cases are good for this type of linguistic analysis. It’s not strictly a mechanical process: • Words may be ambiguous • Different phrases may represent the same concepts.

  48. Steps to create a Domain Model • Identify Candidate Conceptual classes • Draw them in a Domain Model • Add associations necessary to record the relationships that must be retained • Add attributes necessary for information to be preserved • Apply existing Analysis Patterns

  49. Apply the Mapmaker Strategy • Use existing names for things, the vocabulary of the domain • Exclude irrelevant features • Do not add things that are not there

  50. A Common Mistake - Classes as Attributes • Rule: If we do not think of a thing as a number or text in the real world, then it is probably a conceptual class. • If it takes up space, then it is likely a conceptual class. Examples: • A Store is not an attribute of a Sale • A Destination is not an attribute of a flight

More Related