CSC308-F06-L1-2 Slide

CSC 308 Lecture Notes Weeks 1 and 2
Introduction to Software Engineering,
Requirements Analysis, and Specification

  1. Scheduling details for the first two weeks.
    1. First day's activities:
      1. In lecture:
        1. Tour of syllabus and other handouts.
        2. Introduction to the software system life cycle and requirements analysis.
      2. In lab:
        1. Choice of project teams and projects.
        2. Preparation for initial customer interviews.
    2. Second day's activities (Wednesday):
      1. Initial customer interviews, possibly in both lecture and lab.
      2. If necessary to provide ample interview time, there will be no normal lecture on the second day.
    3. Third day's activities (Friday):
      1. Normal lecture.
      2. Introduction to project repository and CVS.
    4. Second week and beyond:
      1. Normal lectures.
      2. Lab meetings as described in syllabus.

    Syllabus
    • Instructor
      • Gene Fisher
      • 14-210, gfisher@calpoly.edu
      • Office Hrs:
        • MWF 11-12, Tu 9-11, by appt
    • Course Objectives
    • Class Materials
    • Activities
    • Evaluations
    • Bi-Weekly Activity Reports
    • How to Submit Project Work
    • Team Work
    • Computer Work
    • Lecture, Lab, Milestone Scheduling
    Projects
    1. Grader
    2. Test Tool
    3. Electric Classroom
    4. Scheduler
    5. CS Tutor
    6. Electronic World
    Milestone 1:
    • Due: 2nd week
    • Tasks:
      1. Organize group
      2. Brainstorm about system features
      3. Look for related systems
      4. Prepare interview questions
      5. Rough draft Section 1 of requirements
    Specification Document Outline
    1. Introduction
    2. Functional Requirements
    3. Non-Functional Requirements
    4. Developer Overview
    5. Formal Specifications
    6. Rationale
      Possible Appendices ...

  2. What is software engineering?
    1. The disciplined creation of software.
    2. Well-known principles of scientific problem solving are applied, including:
      1. Defining a problem clearly before starting its solution.
      2. Using a "divide and conquer" strategy to manage the complexity of a problem and its solution.
    3. Well-known principles of engineering are applied, including:
      1. Using formal mathematics to specify a system precisely.
      2. Formally verifying that a problem solution meets its specification.

  3. The different types of software.
    1. There are three broad categories of software, based on the application domain, i.e., the general area in which the software is applied.
      1. End-user software.
        1. Used by people to get work done.
        2. Has a human-computer interface (HCI).
      2. System software.
        1. Provides underlying support to end-user software.
        2. Has an application programmer interface (API), and perhaps limited HCI.
      3. Embedded software
        1. Used within hardware devices.
        2. Has no HCI; the interface is directly with the hardware.
    2. There are two categories of software based on the clientele who purchase it.
      1. Off-the-shelf (or shrink-wrap) software is built by software developers who sell it on the open marker.
      2. Custom (or bespoke) software is built to satisfy the needs of specific customers, typically an organization of some kind.
    3. In 308, we are building custom end-user software.

  4. The people involved with software .
    1. The following are software "stakeholders", i.e., people who have some interest in a software product and/or its development.
      1. end users -- people who will use the software or people who represent those who will use it
      2. customers -- people who purchase the software, which they may or may use themselves
      3. domain experts -- people who fully understand the application domain in which the software will run
      4. analysts -- members of the software development staff who specialize in requirements analysis and specification
      5. implementors -- members of the development staff who specialize in software design and implementation
      6. testers -- members of the development staff and user community who test the software to ensure that it meets the requirements specification
      7. managers -- those who manage the development process, as well as those who manage end users when the software is installed in an organization
      8. visionaries -- those who have the "big picture" for what the software is intended to do and how it will be developed
      9. maintainers and operators -- those who conduct post- development maintenance and operations, as necessary
      10. other interested parties -- anyone else interested in the software product, such as those with a financial investment
    2. The first four groups work together as a team to develop the requirements, perhaps with some individuals in more than one group.
    3. It is frequently the case that the members of the implementation team do not participate at all in the requirements specification, but rather accept the requirement specification document as input.
    4. In CSC 308, you will primarily play the roles of analyst and tester, with a secondary roles as domain experts and end users as appropriate.
    5. CSC 309 is concerned with project implementation.

  5. The software development process.
    1. For software to be properly engineered, its development must be conducted in an orderly process.
    2. The diagram in Figure 1 depicts the major stages of the software development process.

      Figure 1: Major phases of the software development process.


    3. The Analyze step of the process addresses the requirements to be met by the software.
      1. For software that is to be used directly by humans, the primary activity of the Analyze phase is to acquire and organize the functional requirements of the human users.
      2. This part of the analysis involves a considerable amount of human-to-human communication.
    4. The Specify step of the process involves the development of a formal model of the requirements.
      1. The model represents the requirements in a form that can be mechanically analyzed.
      2. Developing the formal specification allows the requirements to be analyzed for completeness and consistency.
    5. The Design step of the process involves organizing the major components of the software system.
      1. The initial design is derived from the components of the formal specification model.
      2. The initial design is then refined into an efficient software architecture, consisting of packages, classes, and methods.
    6. The Implement step fills in the operational details
      1. Class data structure details are determined.
      2. The code for methods is implemented.
    7. The following are some noteworthy considerations about the process.
      1. Ideally, each step of the process should be completed before the next step is begun.
        1. If we ignore the upward-pointing dashed arrows in Figure 1, we can view the process diagram as a "waterfall chart".
        2. In this view, information only flows down from higher steps to lower steps.
      2. In practice, the ideal waterfall view is rarely possible.
        1. In diagrammatic terms, water sometimes needs to flow up hill (the dashed lines).
        2. This view allows feed-back from a lower phase to a higher phase.
      3. The process we follow in CSC 308 and 309 has the following properties:
        1. There is substantial feedback between the Analyze and Specify steps of the process.
        2. There is also substantial feedback between the Design and Implement steps.
        3. The feedback from the Design step back up to the Specify step is limited, and controlled by specification change orders (SCOs).
          1. The reason is that it is important to have a complete and sound specification before design and implementation begin.
          2. Further, it is important to control any requirements specification changes during design and implementation.
          3. A common source of problems in software system development is that of the "shifting requirements" -- requirements and/or specifications that change significantly once the design and implementation phases have begun.
    8. Viewing the software process as a problem solving exercise, it is clear why changing requirements and specification are troublesome:
      1. The requirements analysis and specification can be considered the "problem statement" phase.
      2. The design and implementation are the "problem solution" phase.
      3. When the system requirements or specification change after the design and implementation are in progress, it is like changing the problem to be solved while the solution is being developed.