Download
1 / 36
360 likes | 372 Vues
ICS 52: Introduction to Software Engineering. Lecture Notes for Summer Quarter, 2003 Michele Rousseau Set 2
E N D
ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Set 2 Partially based on lecture notes written by Richard N. Taylor, André van der Hoek, Dan Frost, Doris Tonne & Sommerville. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited.
The goal of Software Engineering • Overcoming the Software Crises = “often late, over budget and not what the customer wanted” (Brooks) • “High quality software” -- what does that mean??? • There are many qualities - • Which to choose?
Software Qualities • Correctness - behaves according to specifications • Reliability – Statistical property • i.e. Mean time between failures • Robustness - behaves “reasonably” in unanticipated circumstances. • Performance - uses resources economically (efficient) • Usability – easy to use • Keep in mind the intended audience
More Qualities • Maintainability - conducive to corrective, adaptive, and perfective maintenance • Corrective – removal of bugs • Adaptive – adjust to changing enviornment • Perfective – change to improve qualities • Repairability - conducive to correction of defects (which area of maintainability does this address?) • Evolvability – easy to add functionality or modify existing functions (which area of maintainability does this address?)
… and More qualities • Reusability – how easily can you use it for another application (minor modifications allowed) • Portability – how easily can it run on different environments • Safety – deals with the absence of unsafe conditions • Verifiability – satisfaction of desired properties can easily be determined
Why Not Implement Them All? • So many qualities… so little time? • How do you choose?
The essence of software engineering • Or, What makes software engineering difficult?
…Invisibility • Software as is cannot be viewed meaningfully • Stack of paper • Set of files • Software cannot be interpreted easily • How to read source code? • How to read a million lines of source code? • How to read a part of source code? • Invisibility affects process • How to measure progress? • Is a bigger stack of paper closer to the end-result than a smaller stack of paper?
…Unmanageable Complexity • Software cannot be easily abstracted • Formulas • Only in very few domains • Diagrams, graphs, and other representations • Typically non-hierarchical • Far too many cross-references • Tension between high-level understanding and low-level detailed specification • High-level understanding leaves out important details • Aggregation often does not work
…Environment Cannot Be Changed • Software has to adhere to the “world” it is placed in • Cannot change the hardware • Cannot change the way people do business • The “world” is often not clearly specified • How can you change something that you cannot specify? • Leads to many software changes • Perception is that software is easier to change (malleability)
…Major Changes • Software is remarkably easy to change • Change the source code, recompile, rerun • “One line here, one line there” • Unfortunately, even small changes can have disastrous consequences • A single wrong character can surreptitiously change the behavior of the software • The effects of most changes are only visible in certain circumstances • Sometimes, the environment does change • Software is used in different organizations • Software is used for different purposes
Drastic Consequences • Deceased patients • X-ray machine delivered very high doses because of a timing problem in its control software • Crashed planes • Software prevented pilots from performing emergency maneuvers • Decreased national security • NSA computers down for four days due to a “software problem” Peter Neumann’s Risks Forum: http://catless.ncl.ac.uk/Risks
High Cost Analysis 2% Specification 5% Design 6% Maintenance 67% Module Coding 5% Module Testing 7% Integration 8% [Schach]
Cost of Change Progressively Higher [Schach]
Processes as a Remedy • Institute processes through which software is engineered • Cover all steps from initial idea and requirements to delivery, maintenance, and final retirement • Make sure we do the right things/things right • Make sure we do not forget to do anything • Different processes for different kinds of software • Not a silver bullet [Brooks “No Silver Bullet”] • Software is still intrinsically difficult to deal with • Processes help, but cannot guarantee anything Remember: People + Processes + Tools Product
Software Process • “A set of activities and associated results which lead to the production of a software product.” • Four fundamental activities: • Software specification • Design and implementation • Validation (Testing) • Evolution (Maintenance) • Think about differences for “generic” (shrink-wrapped) and “bespoke” (custom-made).
Product and Process • Products: can be sold, bring in revenue • Process: retained by company • Company culture • Determines key properties of your products • A key factor in the cost / reliability / up-to-dateness of the product • E.g.: Just-in-time, “Quality is job 1” • Which is the more important: product or process?
Process and Product • Which is possible? • Good process --> good product • Good process --> bad product • Bad process --> good product • Bad process --> bad product • In studying Software Engineering, we focus on both process and product
Software Life Cycle Models • Build-and-fix • Waterfall • Rapid prototyping • Incremental • Synchronize-and-stabilize • Spiral A software life cycle model is a high-level process
What is a Software Lifecycle Model? • “A software life cycle model is either a descriptive or prescriptive characterization of how software is or should be developed. “ [scacchi] • “abstract representation of a process”[sommerville]
Operations mode Retirement Build-and-Fix Build first version Modify until client is satisfied Development Maintenance
Stage-wise Development [Benington, late 1950s] • operation plan • machine and operational specifications • program specifications • coding specifications • coding • testing specifications • system evaluation
Waterfall [Royce , 1970s] Requirements phase Changed requirements Verify Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Development Test Maintenance Operations mode Retirement
Specification phase Design phase Implementation phase Changed requirements Verify Verify Test Verify Operations mode Retirement Rapid Prototyping Build and discardsimple prototype Integration phase Development Maintenance Test
Spiral [Boehm] Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Verify Verify Specification Verify Design Verify Implementation Full spiral model is discussed in Sommerville
Personnel shortfalls Unrealistic schedules and budgets Developing the wrong software functions Developing the wrong user interface “Gold plating” Continuing stream of requirements changes Shortfalls in externally furnished components Shortfalls in externally performed tasks Real-time performance shortfalls Straining computer-science capabilities Boehm’s Top Ten Software Risks
Requirements phase Specification phase Verify Verify Operations mode Retirement Incremental [Mills] Architectural design Verify FOR EACH BUILD Perform detailed design, implementation, and integration. Test. Deliver to client. Development Maintenance
Synchronize-and-Stabilize(AKA Daily build and smoke test) Specifications Design Implementation, Integration Deliver to client (version 1) Specifications Design Implementation, Integration Deliver to client (version 2) Specifications Design Implementation, Integration Deliver to client (version 3) Specifications Design Implementation, Integration Deliver to client (version n) Specification team Design team Implementation/integration team
SEI's Capability Maturity Model Optimizing (5) Process change management Technology change management Defect prevention Continuously improving process Predictable process Managed (4) Software quality management Quantitative process management Defined (3) Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Standard, consistent process Repeatable (2) Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Disciplined Process Initial(1)
ICS 52 Software Life Cycle • Requirements specification • Interview customer (TA) • Focus on “what”, not “how” • Architectural and module design • Based on provided “official” requirements specification • Focus on interfaces • Implementation • Based on provided “official” design • Focus on good implementation techniques • Testing • Based on provided “official” implementation • Focus on fault coverage and discovery
Your Tasks • Read and study slides of this lecture • Read and study Chapters 4.4, 8 and 5 of Sommerville • Make sure to study the details of the complete spiral model • Visit Peter Neumann’s Risks Forum • Spend two hours (or more) reading the articles
