[Skip Navigation] [ CSUSB ] / [CNS] / [Comp Sci & Engineering] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Question] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 03.html Mon Sep 28 15:44:15 PDT 2009

Contents

    CSci 375/03 Inception
    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous2Introductionvii-40Mock W0-
    Today3Inception41-59Q1(1-59)W0 due
    Next4Use Cases61-89-W1 (section 4.3)

    (Close Table)

    Project Kickoff

     Hand in a brief description of your project: what, who, what,.... and be ready to tell the class about who the team is.

    Input: The Inception Phase
    1. Case Studies:
      1. General
      2. NextGen Point Of Sale -- in many chapters.
      3. The Monopoly Game System -- in many chapters.

    2. Inception is Not Requirements
      1. ++ The jungle mission analogy
      2. ** Key questions for inception:
        • WHY are we doing this project?
        • WHAT might it involve?
        • Can we make it work and how much effort will it take?
        • Should we proceed or stop?
        • ++ FEASIBILITY!
        • WHAT should we do first?
      3. Length of inception
      4. ** Artifacts that might be required(used in W1)
      5. Misapredelusions
      6. * UML?

    3. ** Requirements Evolve
      1. Definition
      2. Evolution vs "waterfall"
      3. BDUF::="Big Design Up Front".
      4. Skill
      5. Types of Requirements: FURPS+
      6. ++ My acronym: PQRST: Purposes, Qualities, Realities, Systems, Technologies.
      7. ++ Or: Why? How? What? Where? Using?
      8. ++ Key point: not just use cases.
      9. Organization
      10. Examples
      11. Resources


    Example of a Simple system

      Name -- Shopping Aid

      Team -- Me

      Vision

       A handheld, wireless device that helps shoppers buy the items that they want. A shopper has a list of items that they want. They are sold at different stores. The device keeps an up-to-date list of wanted items as the user shops.

      More TBA.

    . . . . . . . . . ( end of section Example of a Simple system) <<Contents | End>>

    Questions and Answers

    [ 03q.html ]

    Review Exercises

     The Unified Process. List the 4 phases, list 3 disciplines, and draw a diagram showing how they are related.

    Object-Oriented Analysis and Design. List the four steps described in the previous chapter leading from what the user wants to a design for the software.

    Assigned Work for next time -- use cases I


    (Preparation): Use Cases. Start with [ 04.html ] and take it from there. Submit one question before the deadline.

    Quiz 1 The Unified Process
    (Q1): Fill in blanks in a diagram that I handed out.

    Review Questions

    [ 03r.html ]

    Standard Definitions
  1. CS202::= See http://cse.csusb.edu/dick/cs202/.
  2. CS372::= See http://cse.csusb.edu/dick/cs372/.

  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. DRY::XP="Don't Repeat Yourself".

  5. ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

  6. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  7. GoF::="Gang of Four", [ patterns.html#GoF ]
  8. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  9. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  10. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

  11. OO::shorthand="Object-Oriented".

  12. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  13. patterns::="Documented families of problems and matching solutions", see Patterns.
  14. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  15. Process::="How to develop software".

  16. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
  17. RUP::Process="Rational UP", a proprietary version of UP.

  18. SSD::="System Sequence Diagrams", see chapter 10.

  19. TBA::="To Be Announced".

  20. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  21. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  22. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need it now. In this class it means "It won't be on the final or in quizzes".

  23. XP::="Extreme Programming", the ultimate iterative code-centric, user-involved process.

End