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


    Questions on the Inception Phase

      Chapter 1 Page 11 -- Forward engineering

      What does the author mean by "forward engineering?"

      See [ 02q.html ] on foarward and reverse engineering.

      Previous Quarters

        If we continue our 372 project is this a re-inception

        Yes -- I guess it is. The Traditional Systems Analysis tends to provide a lot of useful input into Inception that will need re-evaluation.

        What are the difference between artifacts in the inception phase and

        later phases First: as the project proceeds the artifacts are refined: edited, improved, etc..

        Second they are initially incomplete and get more complete in each phase.

        How does skill interact with methodology

        Older methodologies attempted to deskill software development. This means replacing personal abilities by given (no brain) procedures.

        Modern agile processes stress people and their skills more than the procedures. They stress the skill of picking procedures (and artifacts) that work at the particular time and project.

        Why do people still use the waterfall.

        Tradition. Comfort. Ignorance. Egotism.

        Also the text books are lagging behind the research and practice.

        Also some projects (very few) have no risks and so the waterfall works for them and is likely to be most efficient.

      . . . . . . . . . ( end of section Previous Quarters) <<Contents | End>>

    . . . . . . . . . ( end of section Questions and answers for Session 3) <<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.