Jan. 19, 2004 CS 509 - WPI 1

CS 509Design of Software Systems

General Dynamics, NeedhamMondays 4 – 8 pm

Instructor: Diane Kramer

Jan. 19, 2004 CS 509 - WPI 2

Review General Course Info & SyllabusTerm Project:

Overview handout Project Journal

Lecture #1: Intro to Software Engineering (Chapter 1) Requirements (Chapter 4)

Requirements Discussion – Marketing Magic

Class Format for Today

Jan. 19, 2004 CS 509 - WPI 3

General Course Info

Course Web Site: http://www.cs.wpi.edu/~cs509/s04

Lecture slides, handouts, announcements, etc.Prerequisites, grading, project journalAcademic Integrity:

Collaboration work on project, not for quizzes Cheating = not acknowledging the

contributions of others

Jan. 19, 2004 CS 509 - WPI 4

Syllabus

Reading order: arranged by needLecture topics include book chapters

plus additional material: Functional Specifications (YES) Rationale Management (NO) Testing (Will discuss but won’t

implement)In class activities include reviews &

statusQuiz schedule for reading topics

Jan. 19, 2004 CS 509 - WPI 5

Term Project – CTS Overview

Project PlanDevelopment ScheduleDescription of project

Review preliminary requirements during break

Learning more about requirements: Write down questions as you think of

them! Use email to get answers as needed

Jan. 19, 2004 CS 509 - WPI 6

The Nature of this Course

Simulate a workplace environment How is it similar, different?

Take an active role in learning processConfused about something?

Interrupt me, ask questions!Requirements are not laws or absolute

truthsHelp define the work you will accomplishTake responsibility for scheduling:

Keep track of your time - No Surprises!

Jan. 19, 2004 CS 509 - WPI 7

Contact Info

Pass around sign-up sheet Print name (neatly) Print email address Phone number & best time to contact

Send email to class list

Later we will discuss working in groups

Jan. 19, 2004 CS 509 - WPI 8

Lecture #1: Introduction

What is Software Engineering?What is Engineering in general?How does engineering apply to

software development?Why do we need it? What problems does it solve?

Jan. 19, 2004 CS 509 - WPI 9

What is Software Engineering?

Managing Software DevelopmentProcess and Planning Engineering in general?

a: the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people

b: the design and manufacture of complex products <software engineering>

--Merriam-Webster On-line Dictionary

Jan. 19, 2004 CS 509 - WPI 10

Why is SW Eng. Useful?

Computer Science used to be obsessed with Algorithms Why? Why has this changed?

Now more concerned with process Complexity of SW systems Correctness, Reliability Ease of use (HCI)

Jan. 19, 2004 CS 509 - WPI 11

Text Book Definition

ModelingProblem SolvingKnowledge AcquisitionRationale Management

Jan. 19, 2004 CS 509 - WPI 12

What is Modeling?

Dealing with complexity through Abstraction

Focus on only the relevant details Problem Domain

• Understanding of environmental factors• Description of relevant aspects of “real-world”

Solution Domain• Understanding of trade-offs• Descriptions of alternative possible solutions

Jan. 19, 2004 CS 509 - WPI 13

Problems & Knowledge

Problem Solving Search for solution Driven by experimentation

Knowledge Acquisition Collect data Organize into information Formalize into knowledge What does it mean to be “nonlinear”?

Jan. 19, 2004 CS 509 - WPI 14

Rationale Management

Capture decision contextDocument issues that go into decision making Implications of proposed changeUseful when revisiting a decisionUsed throughout software development Ideal: Rationale doc is produced and

maintainedRealistic: Rationale is kept in mind,

documented wherever possible (e.g. as comments in code)

Jan. 19, 2004 CS 509 - WPI 15

Software Engineering Concepts

Participants and RolesSystems and ModelsWork ProductsActivities, Tasks, and ResourcesGoals, Requirements, and

ConstraintsNotations, Methods, and

Methodologies

Jan. 19, 2004 CS 509 - WPI 16

Software engineering concepts, depicted as a UML class diagram (OMG, 1998).

consumes

Activity

Work Product ResourcesTask

Equipment

Participant

Document

Model

System

is produced by *

*

**

Project

Time

Figure 1-1, Page 11

“contains”“zero or more”

“is a”

“relationship”

Jan. 19, 2004 CS 509 - WPI 17

Participants and Roles

Who is involved in Software Development? Client, end user Developer Project Manager Others?

What responsibilities are involved? Each set of tasks constitutes a role The same participant can fulfill multiple

roles

Jan. 19, 2004 CS 509 - WPI 18

Systems, Models, Work Product

The System is the underlying RealityA Model is an AbstractionA Work Product is an Artifact

Internal/External Documents• Functional Specification• User Guide

Source/Executable code• Deliverables defined in advance

Jan. 19, 2004 CS 509 - WPI 19

Activities, Tasks, Resources

An Activity is a set of Tasks A Role may define the Activities

A Task is an Atomic Unit of work Small enough to be manageable

Resources are Assets used by Tasks Examples: time, equipment, labor, etc.

All of these need to be planned & managed

Jan. 19, 2004 CS 509 - WPI 20

Goals, Req’s, Constraints

Goals define important Attributes Examples: Safe, Reliable, Fast, etc. Goals sometimes conflict, require trade-

offsRequirements define Features of a

systemConstraints typically limit features and

requirements Examples: time, cost, platform, etc.

Jan. 19, 2004 CS 509 - WPI 21

Notations & Methodologies

Notation = Graphical (or textual) representation of a Model Examples: Alphabet, UML, Set Notation

Method = Repeatable problem-solving technique Examples: Recipe, Algorithm, etc.

Methodology = Collection of methods for solving a class of problems Typically involves decomposition

Jan. 19, 2004 CS 509 - WPI 22

Development Activities

Requirements AnalysisFunctional SpecificationsSystem & Object DesignTest PlanningImplementation & TestingQA: What’s the best way to

produce Quality Software?

Jan. 19, 2004 CS 509 - WPI 23

Requirements

Elicitation of requirements from client Define Purpose of system Describe Problem(s) to be solved Determine Goals and Constraints

Work Product: description of system in terms of Actors and Use Cases External entities that interact with system Sequences of events describing interactions

Jan. 19, 2004 CS 509 - WPI 24

Analysis

Produce model of system that is correct, complete, consistent and unambiguous

“Object” model, in the problem domainUncover ambiguities and

inconsistenciesSystem model annotated with

attributes, operations and associations

Jan. 19, 2004 CS 509 - WPI 25

Functional Specifications

How problems will be solvedWhat will be done to solve problemsDescribe high-level implementation

from Client or End User perspective: Assume they don’t know programming No algorithms, pseudo-code or techno-

babble Often includes Mock-up or Prototype –

why?

Jan. 19, 2004 CS 509 - WPI 26

System & Object Design

Define goals of systemProduce models in the solution domainDecomposition into smaller subsystemsStrategy decisions

Examples: Hardware/Software platforms, data management, control flow

What objects are needed in the system?Formalize interfaces between objects

Jan. 19, 2004 CS 509 - WPI 27

Test Planning

Strategy for verifying correctness of implementation

Unit tests, System tests, Regression tests

Design activity – testability built in Can’t be retro-fitted after implementation

OO Classes make testing easier - how?

Jan. 19, 2004 CS 509 - WPI 28

Implementation & Testing

Translate development models into source code & run experiments to verify correct functionality

This is the easy part!

Jan. 19, 2004 CS 509 - WPI 29

Quality Assurance

How is QA usually done? Write the code Get someone else to test it Testing is the last bottleneck before

shipping QA often blamed for defects

Does this produce Quality software?How can we build quality into the process of Software Development?

Jan. 19, 2004 CS 509 - WPI 30

Managing Software Development

CommunicationRationale ManagementTestingSoftware Configuration

ManagementProject ManagementSoftware Life Cycle

Jan. 19, 2004 CS 509 - WPI 31

Communication

Critical and time-consuming Exchange of ideas - models, documents,

etc. Status reporting Raising, negotiating & resolving issues

Why is it difficult?How can we make it easier?

Conventions: everyone must agree to use them!

Jan. 19, 2004 CS 509 - WPI 32

Rationale Management

Justification of decisions: Problems addressed, alternatives

considered, evaluation criteria, etc.Often exists only in our heads

Not accessible to others Sometimes we forget!

Complex information, difficult to record, update and maintain

Jan. 19, 2004 CS 509 - WPI 33

Testing

Strategies: Uncover defects Verify correct functionality

Types of testing (unit, integration, etc.)Variety of input dataUseful to have someone else test our

code Why?

Jan. 19, 2004 CS 509 - WPI 34

Configuration Management

Source Code or Revision controlProvides control over Builds &

ReleasesEnables historical tracking, recovery

of known stateAllows branching for customizationPowerful SCC systems allow multi-

user access: sharing, diff, merge, etc.

Jan. 19, 2004 CS 509 - WPI 35

Project Management

Oversight activities, attempt to ensure delivery of high-quality system On time Within budget

Planning, scheduling, budgeting, hiring, organizing, and monitoring status

Requires knowledge of SW dev processesRequires flexibility - things change!

Jan. 19, 2004 CS 509 - WPI 36

Software Life Cycle

Modeling the software development process

Usually not linearMore about life cycles in Chapt. 12

Levels of maturity Types of Models

• E.g. Waterfall, “V” model, Spiral, etc.

Jan. 19, 2004 CS 509 - WPI 37

Discussion: Process & Planning

What are the Processes in SW Engineering? What purpose does each serve? What tasks are involved?

How do we plan software development? How long do things take? (Keep track!) Scheduling:

• Make a guess• Improve accuracy with experience

Metrics - measuring how we’re doing

Jan. 19, 2004 CS 509 - WPI 38

Preview - Requirements

Handout – Requirements Documentation

Download sample from course web site

Handout from Marketing MagicStart thinking about requirements

for CTS Bring questions after the break

Jan. 19, 2004 CS 509 - WPI 39

Short Break

Review Preliminary Requirements

for CTS

Jan. 19, 2004 CS 509 - WPI 40

Questions?

Lecture from Chapter 1About Marketing Magic documentAnything else?

More time to discuss requirements later

Jan. 19, 2004 CS 509 - WPI 41

Intro. to Requirements

Define Requirements: What are they? What goes into a requirements document?

Why do we need requirements? What purpose do they serve?

What can go wrong without them?Why do we write Requirements

documents?

Jan. 19, 2004 CS 509 - WPI 42

Requirements Elicitation

Chapter 4

Jan. 19, 2004 CS 509 - WPI 43

Requirements Activities

Identify ActorsIdentify Participating ObjectsIdentify ScenariosIdentify Use CasesIdentify relationships among use

casesIdentify nonfunctional

requirements

Jan. 19, 2004 CS 509 - WPI 44

Participating ObjectsActors

Who will use the system? What parts of the system are used by

which actor?Other participating objects

Main concepts in application domain Glossary of terminology:

• define terms• same concept always has same name• different concepts always get different names

Jan. 19, 2004 CS 509 - WPI 45

Scenarios & Use Cases

Scenarios are concrete, focused descriptions of a single feature of the system

A scenario is an instance of a Use Case

Use Cases are generalizations of scenariosA Use Case captures all possible scenarios

for a given piece of functionality

Jan. 19, 2004 CS 509 - WPI 46

Heuristics

What are Heuristics?How do they differ from an

Algorithm?See box on top of page 139.

Jan. 19, 2004 CS 509 - WPI 47

Use Case Relationships

Communication relationships - indicate flow of information

Extend relationships - used for exceptional, optional or seldom-occurring cases

Include relationships - used for sub-cases which are shared by two or more use cases

Do you need these relationships in your Requirements document?

Jan. 19, 2004 CS 509 - WPI 48

Nonfunctional Requirements

User-visible aspects of the systemNot directly related to functional

behaviorHave impact on design,

development and cost of the systemSee bullet list on page 147 in

textbook

Jan. 19, 2004 CS 509 - WPI 49

Objectives & Success Criteria

What are typical objectives of a SW system? Fast execution – how fast is fast enough? Small in storage requirements – how

small? User friendly Other examples?

What are success criteria? How do you determine whether you’ve

met an objective?

Jan. 19, 2004 CS 509 - WPI 50

Other notes about RAD

See outline on page 152.2 sections for terminology: 1.4, 4.

Use what seems applicableSample Requirements Doc on course

web site Functional requirements could be expanded Scenarios section incomplete – needs more

work Use Cases only just started

Jan. 19, 2004 CS 509 - WPI 51

Requirements

Exercises

Jan. 19, 2004 CS 509 - WPI 52

Exercise #1 - Definitions

(From textbook, exercise #11, page 170)

Get out a clean sheet of paperWrite down a brief definition for the

term “menu”Pass your papers up to the frontCompare definitions

Are there differences? If so, what are they?

Discuss.

Jan. 19, 2004 CS 509 - WPI 53

Exercise #2 - Features

Design and build a “chair”

Definition - what is a chair? What is its purpose? What are its salient characteristics?

Design decisions: What choices are there? Who decides?

Jan. 19, 2004 CS 509 - WPI 54

Exercise #3 – Elicitation

Collaboration Tool Suite

What are various parts of the system?

Review requirements for these parts Ask questions

Assignments for Phase 1 Which part(s) are you interested in

working on?

Jan. 19, 2004 CS 509 - WPI 55

For Next Time

Turn in Phase 1 assignment: Requirements

Turn in project journalRead chapters 1, 2, 4, 5

Quiz will be on chapters 1, 2, 4We will review chapters 2 & 5

Modeling with UML Analysis