View
214
Download
0
Tags:
Embed Size (px)
Citation preview
Common Mistakes Over committing (“big eyes”) Unrealistic schedules
TrainingAccess to people or materialsHours in the day
Level of detailVague descriptionsOver specification
Not knowing your user Assuming that you’ll get it right the first time
Software Engineering Objective
The right software
delivered defect free,
on time and
on cost,
every time.
Carnegie Mellon Software Engineering Institute
Transparency
Track what you do AND document it …not as an afterthought Living, heavily-used documentation
For Every Paper You Read What did you learn? What surprised you?
When was it written? What has changed? What hasn’t?
Who is the author? What are his credentials?
Engineering Turning ideas into reality
Creating something usefulfrom other things
using science and math
Software Engineering vs.
Other Engineering Disciplines
MaturityRoman aqueducts 2000 years agoSoftware engineering 50 years ago
Startup costsBarriers to entry
Rate of change
Different Types of Projects Consider 4 different types of systems
COMP 523 projectsProductivity suitesCommercial web sitesAirplane systemsPacemakers
How do they differ in criticality? What does that mean for the development
process?
All software projects are different
but …Requirements will change.
Surprises will happen.
Schedules will slip.
Life will happen.
Fundamental Steps
Step Documentation
Requirements Design Implementation Test Deployment Maintenance
Functional Spec Design Document Code Test Plan User Documentation Design Document
Need to Start with a Concept How do you tell people about your project Why are you doing it What makes it unique or different
brochure elevator speech
Capture Essence of Project Refer back if losing your way
Remind yourself and others why
Prominent: first page of your web
Clients vs. Users The client is the person “paying the bill” The users are the ones that will
Use your systemMaintain your systemAdminister your system
Know theirSkill levelTime constraintsTolerancesExpectations
Requirements Analysis To build something, we first must understand what
it is we’re building Establish expectations Understandable by both the client and the
developer
Why Written Requirements? Unambiguous
Defines goals
Cost of finding a requirements bug later can be 100 times more expensive