[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [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] projects.html Wed Jan 11 07:26:19 PST 2012
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).


    Assigned field / Project work


      The ideal team size is about 4.


      The work is assigned on a Thursday so you have more days to do it. There will be time at the end of each Thursday class to start each iteration.

      The work is timeboxed: Present what you have at the start of the class when it is due.

      Give me the Deliverables then.

      Exception -- the final version of the project is due at the start of the final.

      Project deliverables can be hard copy or a link plus access to the information on the web. If you elect to put artifacts on the web keep with the safer formats: .html, .txt, .pdf, .gif, .jpg.

      You are building up a packet of artifacts, increment by increment. In theory source code, tests, and executables would be a major part of each iteration.... but we won't have time in this class to do this.

      Contents of Final Report

      1. Vision + Business case
      2. Use case Diagram
      3. Use cases: details on interesting scenarios.
      4. Supplementary specifications: desirable qualities.
      5. Architecture -- package diagram
      6. Domain model class diagram
      7. Glossary
      8. Business Rules
      9. System Sequence Diagrams for nearly all interesting scenarios.
      10. Interactions: sequence or communication diagrams for all interesting messages in your SSD....
      11. Design classes (DCD) that support all your interactions.

      Schedule of Field / Project Work

      Due in Class#Project Work(10 pts)
      03W0 (Project Vison) [ w0.html ]
      05W1 (Inception: section 4.3) [ w1.html ]
      07W2(Use Case Model 1) [ w2.html ]
      09W3(Domain Model 1) [ w3.html ]
      11W4(transition to design: SSD+packages) [ w4.html ]
      13W5(Interaction + Class Diagrams) [ w5.html ]
      15W6(GRASP) [ w6.html ]
      17W7(Model 2: use cases, domain, objects, classes) [ w7.html ]
      19W8(Model 3: model 2 improved) [ w8.html ]
      FinalW9(Model 4: model 3) [ w9.html ]

      (Close Table)

      Other Work

      Don't forget to read the web pages and the assigned part of the book, and do the review questions.

    Standard Definitions

  1. Artifact::="Anything that is created in the course of a project".
  2. artifact::=see above.
  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  6. GoF::="Gang of Four", [ patterns.html#GoF ]
  7. 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 ]
  8. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  9. 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.

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

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

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

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

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

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

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

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

  21. 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 now. In this class it also means "It won't be on the final or in quizzes".

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