Transcript Requirements Engineering-1 - Index

CS 4310 Software Requirements
Engineering
Dr. Steve Roach
Dr. Tanja Magoc
University of Texas at El Paso
Department of Computer Science
Fall 2009
Introductions
• CS 4310, Software Requirements Engineering
– Required course:
– must pass with C or better to take 4311
• Text book:
– Van Vliet, Software Engineering
– Wiegers, Software Requirements
– Required, bring it next time.
• Course Notes: Available online
• TA: Evelyn Torres
Syllabus. Key points
• 0:3-0:5
• GROUP: split into groups of 3
• Groups introduce selves, select a team scribe who writes
down decisions of team
•
•
•
•
•
objective: software requirements engineering
email
grading
attendance
office hours and policy
Quiz
• Three email addresses are listed on the
syllabus. What are they?
• Write the pseudo code for the grading
algorithm.
• What is the attendance policy?
Assignments
• Email
• Reading: Ch 1 Van Vliet; Ch 1, Wiegers (by
Thurs)
• Quiz
– Open notes, not open book
email
Plan on checking your mail daily.
Instructor notes
• 0:10-0:15
• GROUP: discuss and answer the questions:
What are the major steps needed to develop
a reliable software system?
Discuss and answer the question
What are the major steps needed to develop a
reliable software system?
Teams should record answers and team
members.
Instructor Notes
• 0:15-0:20 GROUP DISCUSSION:
• ask each group to contribute to list. When done,
we should have
–
–
–
–
–
–
–
–
–
idea
feasibility study
requirements analysis
specification
design
coding and unit testing
integration and system testing
delivery
maintenance
Software Engineering
What is software engineering?
Software engineering is an attempt to
formalize the construction of software. In
particular, we are concerned with large,
complex systems, systems that require
multi-person effort and usually multiple
versions.
Do we need software
engineering?
Do we need software
engineering?
• All great software is written by small teams:
look at unix (2 guys), Apple (started in a
garage), …
Do we need software
engineering?
• All great software is written by small teams:
look at unix (2 guys), Apple (started in a
garage), …
• Writing software is a creative process, an
“art” or a “craft”, and cannot be engineered
Ariane 5
• June 4, 1996
• European Space Agency lost newest rocket,
the Ariane 5, successor to the Ariane 4
• $500 Million lost on first flight
Ariane 5
• Problem was overflow in the conversion of a 64-bit
float to a 16-bit signed number in the SRI inertial
reference system (why do you take architecture?)
• The broken data serves no purpose in the SRI after
takeoff. But in the A-4, the software ran after takeoff so
that if the launch sequence was interrupted, it could be
restarted quickly. This was not necessary in the A-5.
• The A-5 accelerated much faster than the A-4. The A-4
never had an overflow. The A-5 did overflow.
• The backup system on the A-5 was identical to the
original, and it failed for exactly the same reason. The
rocket broke apart and was destroyed.
Therac 25
• Late 1980's.
• Radiation therapy device with 3 modes:
– light: for alignment
– electron: low power, magnets to spread beam
– X-ray: high power, flattener plate to spread
beam
• Needed flattener plate in place in X-ray
operation.
Therac 25
• There was a race condition in the operator
interface. If the operator made a mistake, used the
back space to correct it, the machine could run in
X-ray mode without the flattener in place.
• Previous version of machine had hardware
interlock to prevent X-ray mode without flattener.
• Therac-25 depended on software.
• Difficult to reproduce. The physicist spent at least
two weeks practicing once he had seen the
technician reproduce the problem.
• Several rather horrible deaths resulted.
Others:
• 1998 GM ABS recall
• 2003 East Coast Power Failure: power cut to parts
of at least 5 states (cost, $7-$10 billion)
• 2004: Air traffic control system shuts down voice
communication system in southwest US, losing
contact with 400 aircraft in flight.
• 2009: Washington DC Metro crash kills 9 people:
train under software control at the time
Assignment Due Before Next Class
• A: find two more software failures that have
resulted in significant harm (loss of life, serious
risk, or loss of money) in the past 3 years.
• B: Describe two approaches to eliminating the
types of software failures discussed here.
• You must find no less than two independent
citations for each.
• Legitimate citations include IEEE or ACM
publications, web sites sponsored by Fortune 500
companies, or Prentice-Hall, Wiley, O’Rielly,
Addison-Wesley, or Microsoft Press. Or anything
by Parnas or McConnel.
• You must include your citations.
• Email this list to me before the next class.
Department of Defense
• "About the only thing you can do with an F22 without software is to take a picture of
it."
– --Unidentified Air Force General
• The DoD estimates it will field systems
utilizing 20 million LOC.
» CMMI Distilled, Ahern
NASA’s Need
“The continued growth in scope, complexity,
and cost of software systems represents a
threat to the success of NASA missions.
NASA must take proactive steps to
strengthen its capability in software
engineering and management:
• Minimize technical, cost, and schedule issues
• Increase safety, quality, and reliability
Orlando Figueroa
Former Deputy Chief Engineer for Systems Engineering
April, 2001
Instructor Notes
• 0:40-0:50
– A key feature of 4310/11 is the project.
– You will need to bring to bear all of the things
you know, not just what I say
Project course
• "The hardest single part of building a
system is deciding what to build." Brooks.
• Why a project?
– Experience is better than just spitting back what
I tell you.
– Employers know this, and will ask at your
interviews.
– It gives you the chance to think "outside the
box" out of the context of class
Requirements Engineering:
• requirements elicitation: developers and
customers discover and articulate users' needs
• requirements analysis: analyze the customer and
user needs to arrive at a definition
• requirements specification: develop a document
• requirements verification: show the document is
correct
• management of requirements: control the
process
Outline of course:
•
•
•
•
•
•
•
Build software teams
Interview customer, interview report
Feasibility study
Prototype
Analysis: use cases, diagrams, modeling
Specification (SRS)
Tracing
GROUP:
• (15 minutes total)
– Read the article, answer the questions
Why is software difficult to construct so that
it works correctly? (5 minutes)
Software error costs
• In your groups:
– Read the article
– Answer the questions:
•
•
•
•
What are the costs associated with software errors?
What are the sources of errors?
Why is software different from other products?
What is liability?
Why software projects fail
(Software Runaways, Robert Glass, 1998, Prentice)
• runaway: fails to deliver or is 30% or more over
budget
• faulty specification 51%
• faulty planning and estimation 48%
• based on unstable new technology 45%
• inadequate management: 42%
• lack of senior programming staff: 42%
• problems with hardware/software from vendors: 42%
Trends with failures:
• overly ambitious
• result from multiple causes
• schedule overruns are more common than
cost overruns
• most failures are spotted by development
team before management
• most did not do risk management
Problems with Specifications
•
•
•
•
too many specs: project is large
unstable specs
ambiguous specs
incomplete specs
Do we need software
engineering?
• What is a large software system?
• What is a complex software system?
• What is safety critical/high consequence?
Cost of SE vs Cost of not SE
• Each stage of software development has overhead
costs
– management
– time reporting
– testing
– requirements analysis
– design
• Imagine stripping everything except the parts that
lead directly to the program itself: coding
• SE entails overhead. The amount of overhead
should match the project.
History: How did we get here?
• 1930s-40s: we only had very highly skilled users:
the builders, physicists, EE's.
• 50's and 60's: The advent of 3GLs and programmers
– More general, but still highly skilled
– They started generating output for users.
• Mid 60s: started having large projects like OS360:
5000 man-years.
– Too big for a single person to understand.
– Lots of scaling problems.
– Projects are over budget and late.
History: How did we get here?
• 1970s & 80s: Mainframes running mostly batch
programs and microcomputers running simple
software
• 90s: windowing and multitasking OS on PCs, the
rise of the internet
– The platforms for software become more sophisticated,
but not enough for the software running on top of them
– Lots of people writing software, not all are highly skilled.
• 2000: Software becomes ubiquitous. Software
defines products.
– User interfaces and domain expertise needed
Solutions:
• Better management
• Better tools and languages
• More life-cycle-centric view of
development: software development isn’t
just coding anymore