[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] 02q.html Wed Jan 11 07:25:25 PST 2012


    Questions and Answers on the Introduction

      Project in this class

      I was wondering in this class we had to fully program our project, or if we were just going to be doing everything but programming?

      I regret this but we only have 9 weeks, no machines, and no lab time:-(

      Programming is optional. At most I may ask you to show how you might code an interaction diagram.

      From 2007

      1 pp 14 -- UML1 &2

    1. what was the major change or difference between the first version of UML to UML2?

      This took a couple of presentations by me and by a student [ 2005 in index ]

      1 pp 15 -- UML History

      Is the difference from UML1 and UML2 basically scope?

      I guess so.... UML2 has a lot more diagrams and can be used for a lot more purposes in a project -- for example flow charting and timing diagrams.

      There are also some big revisions and refinements.

      2 pp 19-21 -- Iterative and Evolutionary Development

      In the UML development model the complexity of a system is given by the number of iterations or by the number of components?

      When done the number of pieces will depend on the complexity of the project.

      The number of iterations is more of a planning and guesstimating thing. But you would be wise to plan for more iterations on a complex project than on a simple one. Each iteration is really a simple project that adds complexity to the whole. The other thing is that early iterations should tell you to change your plans.

      The development plan is a guess.... only the next iteration or so is set in stone...

      2 pp 022-023 -- How long is an iteration

      When It comes to Iteration times, what are the major factors that decide how long the iterations will be for a project?

      Experience and risk. I would say that a project with many risks and novel things will need lots of small iterations.

      IN this class, quite arbitrarily, I've gone with the XP value: one iteration = one week.

      However in this class project we do not do a complete iteration because I do not require your to produce tested executable code. This is because we are not scheduled any lab time or development systems.

      page 23 Time boxing

      In a project using timeboxing, what happens when all requirements for a specific iteration cannot be completed in the given amount of time; since there are no requirements that can be completed in the given amount of time, is the time length for the iteration extended or does the old iteration end and a new one start from that point? pg. 23

      The unmet requirement is moved to a future iteration. A wise team will try to understand why it was not met and adjust their plans for the future: did they have too many requirements in this iteration? if so they must adjust their model of how fast they can work. Or, is there something evil in that requirement? In this case it may need some rethinking and scheduling.

      number pp 037-038 -- cs375 question - Development Case

      Are there rules or a special format in which a development case must follow in order for it to be a development case?

      Development Cases are a formal way of recording what parts of the UP/RUP you plan to use. I am not a fan of formal Development Cases. Each organization will have it's own way of documenting them. All the examples I've seen are tables like Table 2.1 (page 38). I used this table as inspiration for the project work in this class.

      I'll be asking you in [ w1.html ] to choose the artifacts you will need to deliver to get your project off the ground. Notice -- you should think about what artifacts are developed in an iteration before starting each iteration.

    . . . . . . . . . ( end of section Questions and Answers on the Introduction) <<Contents | End>>

    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.