Contents

• CS372+375 Objectives
• : Relevant ABET Accreditation Goals
• : 372/5 Mission
• : 372/5 Content
• : 372/5 Objectives
• : 372/5 Options
• Standard Definitions

CS372+375 Objectives

This document describes the objectives of the combined 372/375 sequence. Items covered in CS372 only are indicated (372).

Relevant ABET Accreditation Goals



1. Analysis and design IV-6
2. Role of IS in Organisations IV-6
3. Theoretical foundations IV-7
4. Communication skills IV-14 (oral + written)
5. Collaborative skills IV-16
6. Study in an IS environment IV-2



372/5 Mission

To know how computer technology is used in real organizations and use this knowledge to manage software development projects and analyze existing systems, propose improvements, identify problems, generate and evaluate hardware/software solutions, and draw up software requirement specifications.

372/5 Content

There should be evidence on file that demonstrates that during CSCI372/5 sequence the students:

1. Worked in small groups/teams to analyze systems and propose solutions.
2. Studied two or more existing information systems.(372)
3. Studied how software is developed in at least one organization, for example on campus.(372)
4. Presented their work for review by peers, faculty, and IS workers.
5. Used at least one CASE tool.
6. Completed a UML model for a computerized solution to a problem in an existing system.
   
   1. (Note. The solution may expressed on paper, as a presentation, and/or as a web site.
   2. It may or may not include simply prototypes.
   3. It may be a photographic or software record of a presentation.
   4. )
   
   
7. Carried out a group simulation of at least one object-oriented program design.



372/5 Objectives

After completing the 372/375 sequence a student will be able to:

1. Describe real computerized systems including: enterprise servers/mainframes, dept servers, e-commerce and web-based systems, POS and office workstations, mobile systems, embedded systems, etc.(372)
2. Quote and apply general systems theory (boxes and arrows).(372)
3. Describe a typical information systems department and some variants.(372)
4. Describe the traditional systems development life cycle (SDLC) and some variants(RAD, Agile,...).(372)
5. Select and justify a suitable process/SDLC for a given situation.(372)
6. Describe & apply simple planning techniques: CPA PERT.(372)
7. Describe & apply simple cost/benefit techniques.(372)
8. Use record structures to describe and evaluate existing/proposed data/information.
9. Quote and apply elementary information theory to estimating data volumes/rates.
10. Define a use case and give examples.
11. Define a scenario and write simple examples of scenarios.
12. Distinguish actors from use cases and give examples of actors.
13. Study an existing system and describe it using data flows, processes and data stores (DFD).(372)
14. Describe an existing system architecture using UML deployment and component diagrams.
15. Record existing activities and business logic using UML activity diagrams (flowcharts).(372)
16. Use structured English, UML activity diagrams, flowcharts, or tables to express business rules/logic.(372)
17. Read and critique a set of DFDs.(372)
18. Correct errors in a DFD model of a system.(372)
19. Plan a new system using high level DFDs.(372)
20. Select parts of a DFD to be computerized and justify the selection (372)
21. Propose and justify a way to implement a part of a DFD (Application, script, user-developed, COTS, bespoke, ..., expert system). (372)
22. Use simple UML use case diagrams + scenarios to state requirements.
23. Correctly utilize use case extension, includes and generalization.
24. Draw object-oriented domain models using UML class diagrams with classes, associations, roles, and multiplicities.
25. Use state diagrams to trace the life-cycle of an object in a system.
26. Use a state diagram to map out a session on a web site.
27. Extend a domain model to include attributes/data based on DFDs and logic.
28. Allocate responsibilities to classes and test result vs scenarios.
29. Use UML message sequence diagrams to describe interactions between objects.
30. Use UML collaboration diagrams to describe interactions between objects.
31. Use UML collaboration diagram sequence numbers correctly.
32. Use iteration and conditions correctly in collaboration and sequence diagrams.
33. Translate between message sequence and collaboration diagrams.
34. Know how to draw, read, and critique a UML class diagram with attributes and operations.
35. Use visibility and derivation symbols correctly in a class diagram.
36. Cross-validate a use case model plus collaboration/message sequence diagrams against a class diagram.
37. Use the General Responsibility Assignment Patterns to place operations in a design model.
38. (Design model = class diagram + either message sequence or collaboration diagrams).
39. Extend simple class diagrams to include generalization, aggregation, and composition.
40. Use some simple design patterns correctly: State, Composite, Observer, Factory, Adapter, ...
41. Use simple deployment and component diagrams to describe a proposed architecture.



372/5 Options

After completing the 372/375 sequence a student may:

1. Use either CASE tools or low-tech techniques (chalk board, posters, cards) for documentation.
2. Use the UML notation for parameterized, active, and interface classes.
3. Use symbols or stereotypes to distinguish boundary, control, entity classes.
4. Develop simple prototypes and tests as executable specifications of components.
5. Develop a first iteration of a set of components.



. . . . . . . . . ( end of section CS372+375 Objectives) <<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.

End