CS 4310 Software Requirements Engineering Dr. Yoonsik Cheon Mr. Irbis Gallegos University of Texas...
-
Upload
anthony-rose -
Category
Documents
-
view
219 -
download
2
Transcript of CS 4310 Software Requirements Engineering Dr. Yoonsik Cheon Mr. Irbis Gallegos University of Texas...
CS 4310 Software Requirements Engineering
Dr. Yoonsik Cheon
Mr. Irbis GallegosUniversity of Texas at El Paso
Department of Computer Science
Fall 2011
Introductions
• CS 4310, Software Requirements Engineering– Required course: – must pass with C or better to take 4311
• Text book: – Van Vliet, Software Engineering– Required: you will need in class sometimes.
• Course Notes: Available online• TA: Neith Estrada, Cesar Yeep
Teams of 3
• Introduce yourselves
• Find one food product and one movie that you all like
• 2 minutes
Teams: Syllabus Review
• Read the syllabus• Quiz to follow• Pay attention to:
– objective: software requirements engineering– email policy– grading– attendance– office hours and policy
Quiz
• Name the other people in your group.
• Four email addresses are listed on the syllabus. What are they?
• Write the pseudo code for the grading algorithm.
• What is the attendance policy?
Assignments
• Resume
• Plan on checking your mail daily.
Fact or Fiction?
• This course is hard.
• This course will take all your time.
• You should concentrate on the exams and not on the project.
• You should concentrate on the project and not the exam.
• Your team mates will cover for you.
Team
What are the major steps needed to develop a reliable software system?
(5 minutes)
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.
Three Critical Dimensions
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 other software failures that have resulted in
significant harm (loss of life, serious risk, or loss of money) in the past 3 years. Attempt to identify the root cause of the failure.
• B: Describe two approaches to eliminating the types of software failures you identify.
• 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 McConnell.
• You must include your citations.
Department of Defense
• "About the only thing you can do with an F-22 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
This is a course about:
• Recognizing, making explicit, and understanding the phases or tasks of developing software
This is a course about:
• Recognizing, making explicit, and understanding the phases or tasks of developing software
• Communicating – between stakeholders and developers– among developers– Among tasks and phases
This is a course about:
• Recognizing, making explicit, and understanding the phases or tasks of developing software
• Communicating – between stakeholders and developers– among developers– Among tasks and phases
• Building reliable, useful, correct software in cost-effective manner
Why a project?
Why a project?
• Experience is better than just spitting back what we 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
"The hardest single part of building a system is deciding what to build."
Brooks.
• 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
Team: Read Software Error Cost
• Why is software difficult to construct so that it works correctly?
• What are the costs associated with software errors?
• What are the sources of errors?• Why is software different from other products?• What is liability?
• (5 minutes)
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: computer 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– Businesses invest heavily in software systems and data– Sales of software exceeds sales of hardware– Developers start to use processes: structured programming,
development life cycle models
• 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. – Time to market drives many developers
History: How did we get here?• 00s: Software becomes ubiquitous.
– Found in nearly every product, frequently defines products
– User interfaces and domain expertise needed– Web is everywhere, begins to replace TV and
newspapers as primary source of information and entertainment
– Mobile computing
• 10s: ???– Cloud computing, intelligent software, datamining,
computational science (e.g., bioinformatics)– …
Teams:
• In theory, we should be able to create software that does almost anything. In practice, this hasn’t happened.
• Identify the top 3 problems with software
Problems
• Software is late
• Software is over budget
• Software does not behave as intended
• Software is unusable
• Some restrictions on activities are based on software capability
Solutions:
• Better management of development
• Better tools and languages
• More life-cycle-centric view of development: software development isn’t just coding anymore
• More rigorous approaches to correct development: verification isn’t just testing anymore