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 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 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 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?
Top Related