Sept. 4, 2003 CS 509 - WPI 1

CS 509Design of Software Systems

Fuller Labs, Room 311Thursday Evenings 6 - 9pmInstructor: Diane Kramer

Sept. 4, 2003 CS 509 - WPI 2

Attendance, Add/Drop, etc.Handouts:

General Course Info & Syllabus Term Project – Meeting Coordinator

Other administrivia: Student survey Assign groups for MC project

Lecture #1: Intro to Software Engineering

Class Format for Today

Sept. 4, 2003 CS 509 - WPI 3

General Course Info

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

lecture slides, handouts, announcements, etc.

Prerequisites, grading, project journalAcademic Integrity:

Work in groups, no sharing across groups! Cheating = not acknowledging the

contributions of others

Sept. 4, 2003 CS 509 - WPI 4

Syllabus

Reading order: arranged by needLecture topics include book

chapters plus additional material: Functional Specifications (YES) Rationale Management (NO) Test & Development Plans (YES)

May have more peer reviews if time permits

Sept. 4, 2003 CS 509 - WPI 5

Term Project – Meeting Coord.

Project PlanReviews & group evaluationsDevelopment ScheduleDescription of projectLearning more about

requirements - write down questions as you think of them!

Sept. 4, 2003 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!

Sept. 4, 2003 CS 509 - WPI 7

Administrivia

Student surveys – this is not a test!Group assignments – after the

break

You will be doing a lot of group work this term. Get your group together briefly (tonight, after class) to decide on a weekly meeting time.

Sept. 4, 2003 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?

Sept. 4, 2003 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

Sept. 4, 2003 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)

Sept. 4, 2003 CS 509 - WPI 11

Text Book Definition

ModelingProblem SolvingKnowledge AcquisitionRationale Management

Sept. 4, 2003 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

Sept. 4, 2003 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”?

Sept. 4, 2003 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)

Sept. 4, 2003 CS 509 - WPI 15

Software Engineering Concepts

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

ConstraintsNotations, Methods, and

Methodologies

Sept. 4, 2003 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”

Sept. 4, 2003 CS 509 - WPI 17

Participants and Roles

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

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

roles

Sept. 4, 2003 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

Sept. 4, 2003 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.

Sept. 4, 2003 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.

Sept. 4, 2003 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

Sept. 4, 2003 CS 509 - WPI 22

Development Activities

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

produce Quality Software?

Sept. 4, 2003 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

Sept. 4, 2003 CS 509 - WPI 24

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?

Sept. 4, 2003 CS 509 - WPI 25

System & Object Design

Define goals of systemDecomposition into smaller subsystemsStrategy decisions

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

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

Sept. 4, 2003 CS 509 - WPI 26

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?

Sept. 4, 2003 CS 509 - WPI 27

Implementation & Testing

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

This is the easy part!

Sept. 4, 2003 CS 509 - WPI 28

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?

Sept. 4, 2003 CS 509 - WPI 29

Managing Software Development

CommunicationRationale ManagementTestingSoftware Configuration

ManagementProject ManagementSoftware Life Cycle

Sept. 4, 2003 CS 509 - WPI 30

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!

Sept. 4, 2003 CS 509 - WPI 31

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

Sept. 4, 2003 CS 509 - WPI 32

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?

Sept. 4, 2003 CS 509 - WPI 33

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.

Sept. 4, 2003 CS 509 - WPI 34

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!

Sept. 4, 2003 CS 509 - WPI 35

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.

Sept. 4, 2003 CS 509 - WPI 36

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

Sept. 4, 2003 CS 509 - WPI 37

Preview - Requirements

Handout – Requirements Documentation

Download sample from course web site

Handout – Sample use caseStart thinking about requirements

for MC Bring questions for next time