Docstoc

A Case Study Point-of Sale

Document Sample
A Case Study Point-of Sale Powered By Docstoc
					                                Object-oriented Analysis and Design




                         Chap 8
                       Iteration 1
                         Basics




Software Engineering                                                  1
                                Object-oriented Analysis and Design


                  Requirements
   We    review here the requirements for first
    iteration of our case studies.
      They are a subset of the requirements as
       described by the use cases, the vision, and the
       supplementary specification;
      Subsequent iterations will grow these until a
       full system is implemented;
      The current requirements are not complete,
       they will evolve and benefit from feedback …


Software Engineering                                                  2
                                Object-oriented Analysis and Design


                       Iteration 1
   Iteration 1 of the elaboration phase
     Requirements and Emphasis: Core OOA/D
       Skills
     Architecture-centric and risk-driven.
   In Iterative Development, Don't Implement All
    the Requirements at Once
   Incremental Development for the Same Use
    Case Across Iterations



Software Engineering                                                  3
                                                  Object-oriented Analysis and Design


                            Iteration 1
    Use case implementation may be spread across iterations

                                                  A use case or feature is
               1     2      3     ...             often too complex to
                                                  complete in one short
                                                  iteration.

                                                  Therefore, different parts
        Use Case     Use Case     Use Case        or scenarios must be
       Process Sale Process Sale Process Sale     allocated to different
                                                  iterations.




                                   Use Case
                                Process Rentals
         Feature:
         Logging



Software Engineering                                                                    4
                                Object-oriented Analysis and Design


                 POS Iteration 1
   Requirements       for iteration 1 of the POS
    application
     Implement a basic, key scenario of the
      Process Sale use case: entering items and
      receiving a cash payment.
     Implement a Start Up use case as necessary to
      support the initialization needs of the
      iteration.
     Nothing fancy or complex is handled, just a
      simple happy path scenario, and the design
      and implementation to support it.
Software Engineering                                                  5
                              Object-oriented Analysis and Design


                 POS Iteration 1
     There   is no collaboration with external
      services, such as a tax calculator or product
      database.
     No complex pricing rules are applied.
     The design and implementation of the
      supporting UI, database, and so forth, would
      also be done




Software Engineering                                                6
                             Object-oriented Analysis and Design


            Planning the iteration
   After   the initial inception phase, the most
    important software requirements have been
    identified, some of which have been detailed.
     Other requirements remain to be discovered;
     Most will need further analysis;




Software Engineering                                               7
                               Object-oriented Analysis and Design


            Planning the iteration
   However    after the inception phase we must have
    a basic, documented, set of requirements:
     These need to be scheduled over the next few
       development cycles (the elaboration phase);
     Only the first few cycles need to be scheduled
       at this stage (a very detailed schedule is not
       feasible at this point in time due to the
       fuzziness of the remaining requirements);
     An iteration must be time-boxed, say between
       2 weeks and 8 weeks (why?)

Software Engineering                                                 8
                                        Object-oriented Analysis and Design


               Planning the iteration
     To decide which requirements should be tackled early in
      the project we can use the following criteria:
         Risk : includes both technical complexity and other
          factors, such as uncertainty of effort or usability.
         Coverage : implies that all major parts of the system
          are at least touched on in early iterations, perhaps a
          "wide and shallow" implementation across many
          components.
         Criticality : refers to functions the client considers of
          high business value.



Software Engineering                                                          9
                                              Object-oriented Analysis and Design
   We can then rank use cases, and other high-level features, according to
    these criteria:
               Rank  Requirement      Comment
                     (Use Case or
                     Feature)
             High     Process Sale     Scores high on all rankings
                      Logging          Pervasive. Hard to add later
                      …                …
             Mediu    Maintain Users   Affects security
             m        …                …
             Low      …                …

   This ranking should be reviewed after each iteration as new
    requirements and new insights will influence it:
       The schedule needs to be adaptive;.




    Software Engineering                                                            10
                                   Object-oriented Analysis and Design


      From Inception to Elaboration
   The inception phase may only last 1 week (typically
    more) : it is not very long:
      It determines basic feasibility, risk, and scope, to
       decide if the project is worth more serious
       investigation (Elaboration).
   During the Inception phase the following may occur:
      a short requirements workshop;
      most actors, goals, and use cases named;
      most use cases written in brief format; 10 to 20% of
       the use cases are written in fully dressed detail to
       improve understanding of the scope and complexity;


Software Engineering                                                     11
                                Object-oriented Analysis and Design


     From Inception to Elaboration
     most       influential and    risky      quality
      requirements identified;
     version one of the Vision and Supplementary
      Specification written;
     risk list;
        For example, leadership really wants a
         demo at the POSWorld trade show in
         Hamburg, in 18 months. But the effort for
         a demo cannot yet be even roughly
         estimated until deeper investigation.

Software Engineering                                                  12
                              Object-oriented Analysis and Design


     From Inception to Elaboration
     technical   proof-of-concept prototypes and
      other investigations to explore the technical
      feasibility of special requirements;
     user interface-oriented prototypes to clarify
      the vision of functional requirements
     recommendations on what components to
      buy/build/reuse, to be refined in elaboration




Software Engineering                                                13
                                      Object-oriented Analysis and Design


     From Inception to Elaboration
      high-level   candidate architecture and components
       proposed
         This is not a detailed architectural description,
           and it is not meant to be final or correct. Rather, it
           is brief speculation to use as a starting point of
           investigation in elaboration. For example, "A Java
           client-side application, no application server,
           Oracle for the database, …" In elaboration, it may
           be proven worthy, or discovered to be a poor idea
           and rejected.
      plan for the first iteration;
      candidate tools list;


Software Engineering                                                        14
                               Object-oriented Analysis and Design


     From Inception to Elaboration
   On to the Elaboration phase:
     Elaboration is the initial series of iterations
      during which:
        the core, risky software architecture is
          programmed and tested
        the majority of requirements are
          discovered and stabilized
        the major risks are mitigated or retired


Software Engineering                                                 15
                               Object-oriented Analysis and Design


     From Inception to Elaboration
     Elaboration   often consists of two or more
      iterations; each iteration is recommended to
      be between two and six weeks; prefer the
      shorter versions unless the team size is
      massive. Each iteration is timeboxed,
      meaning its end date is fixed.
     Build the core architecture, resolve the high-
      risk elements, define most requirements, and
      estimate the overall schedule and resources.


Software Engineering                                                 16
                                Object-oriented Analysis and Design


                       Elaboration
 Elaboration is not a design phase or a phase when
  the models are fully developed in preparation for
  implementation.
 Executable    architecture/Architectural baseline/
  Architectural prototype
   to describe the partial system.
   a production subset of the final system.




Software Engineering                                                  17
                                     Object-oriented Analysis and Design


                       Elaboration
   Some key ideas and best practices will manifest in
    elaboration:
      do short time boxed risk-driven iterations
      start programming early
      adaptively design, implement, and test the core and risky
       parts of the architecture
      test early, often, realistically
      adapt based on feedback from tests, users, developers
      write most of the use cases and other requirements in
       detail, through a series of workshops, once per
       elaboration iteration


Software Engineering                                                       18
                                              Object-oriented Analysis and Design


                         Elaboration
   Artifact                                Comment
Domain Model This is a visualization of the domain concepts; it is similar
             to a static information model of the domain entities.
Design Model    This is the set of diagrams that describes the logical design.
                This includes software class diagrams, object interaction
                diagrams, package diagrams, and so forth.

Software        A learning aid that summarizes the key architectural issues
Architecture    and their resolution in the design. It is a summary of the
Document        outstanding design ideas and their motivation in the system.

Data Model      This includes the database schemas, and the mapping
                strategies between object and non-object representations.
Use-Case        A description of the user interface, paths of navigation,
Storyboards,    usability models, and so forth.
UI Prototypes
Software Engineering                                                                19
                                         Object-oriented Analysis and Design


         Planning the Next Iteration
     Organize requirements and iterations by risk, coverage,
      and criticality.
        Risk  includes both technical complexity and other factors,
         such as uncertainty of effort or usability.
        Coverage implies that all major parts of the system are at
         least touched on in early iterations perhaps a "wide and
         shallow" implementation across many components.
        Criticality refers to functions the client considers of high
         business value.




Software Engineering                                                           20
                                              Object-oriented Analysis and Design


                          Discussion
     What ability is important to a System Analyst/Pre-Sales?
        Beinitiative
        Communication skills
            good understanding
            presentation/expression skills
            Situation handling
        Domain   knowledge




Software Engineering                                                                21

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:3/9/2012
language:English
pages:21