1. ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Topic 3 Partially based on lecture notes written by Richard N. Taylor, André van der Hoek, Dan Frost, David Redmiles & Doris Tonne. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

2. Topic 3Summer 2003 2 Today’s Lecture n Principles of software engineering n An introduction to requirements

3. Topic 3Summer 2003 3 Principles of Software Engineering n Deal with both process and product n Applicable throughout the lifecycle n Principles form the basis of methods, techniques, methodologies and tools n Principles become practice through methods and techniques –often methods and techniques are packaged in a methodology –methodologies can be enforced by tools

4. Topic 3Summer 2003 4 Relationship between Principles, Methods, Methodologies and Tools

5. Topic 3Summer 2003 5 7 Recurring, Fundamental Principles of S/w Engineering n Rigor and formality n Separation of concerns n Modularity n Abstraction n Anticipation of change n Generality n Incrementality These principles apply both to product and to process.

6. Topic 3Summer 2003 6 Rigor and Formality n Rigor: to be exact or strictly precise n Rigor is a necessary complement to creativity –Creativity often leads to imprecision and inaccuracy –Thus, it must be practiced systematically n Rigor helps.. –…understandability, Improve reliability, facilitates assessment, control cost, increase confidence in products n Formality is the highest degree of rigor –mathematically sound –Often used for mission critical systems

7. Topic 3Summer 2003 7 Rigor & Formality (2) n Process example: Rigorous documentation of development steps helps project management and assessment of timeliness n Product examples: –Mathematical (formal) analysis of program correctness –Systematic (rigorous) test data derivation

8. Topic 3Summer 2003 8 Separation of Concerns n To dominate complexity, separate the issues to concentrate on one at a time n Trying to do too many things at the same time often leads to mistakes –Software development is comprised of many parallel tasks, goals, and responsibilities –Software development cannot tolerate mistakes n "Divide & conquer" n Allows concentration on individual aspects –product features: functions, reliability, efficiency, environment, user interface, etc. –process features: development environment, team organization, scheduling, methods, –economics and management n Separation of Concerns helps… –…divide a problem into parts that can be dealt with separately –…create an understanding of how the parts depend on/relate to each other

9. Topic 3Summer 2003 9 Separation of Concerns (2) n Process: –Go through phases one after the other (as in waterfall) –Management: separation of responsibilities, expertise –Requirements, design, implementation, testing, … n Product –Qualities Efficiency and user friendliness

10. Topic 3Summer 2003 10 Modularity n A complex system may be divided into simpler pieces called modules n Permits separation of concerns: –deal with each module in isolation (ignore rest of system) –deal with overall system (ignore module details) n Promotes reuse n Promotes understandability n Modules should have high cohesion and low coupling –high cohesion: all elements within are strongly related module understandable as a meaningful unit –low coupling: modules are largely independent of each other

11. Topic 3Summer 2003 11 Modularity Big Small

12. Topic 3Summer 2003 12 Coupling VERSUS

13. Topic 3Summer 2003 13 Cohesion VERSUS

14. Topic 3Summer 2003 14 Abstraction n Identify the important aspects of a phenomenon and ignore its details n Separation into individual, logical parts –Relevant versus irrelevant details Use relevant details to solve task at hand Ignore irrelevant details n The type of abstraction to apply depends on purpose n Example : the user interface of a watch (its buttons) abstracts from the watch's internals for the purpose of setting time; other abstractions needed to support repair

15. Topic 3Summer 2003 15 Abstraction Big Abstraction Details

16. Topic 3Summer 2003 16 Anticipation of Change n Constant change is inevitable in large-scale software systems –software repair & error elimination –evolution of the application –evolution of the social order n Not anticipating change often leads to high cost and unmanageable software –Software development deals with inherently changing requirements –Software development can tolerate neither high cost nor unmanageable software n What to do? –Identify likely changes and plan for change software requirements usually not entirely understood users and environments change also affects management of software process n Anticipation of change helps to… –…create a software infrastructure that absorbs changes easily –…enhance reusability of components –…control cost in the long run

17. Topic 3Summer 2003 17 Generality n Focus on discovering more general problem than the one at hand –fosters potential reuse –facilitates identification of OTS solution n Not generalizing often leads to continuous redevelopment of similar solutions –Software development involves building many similar kinds of software (components) n Trade-offs between initial costs vs. reuse savings n Generality leads to… –…increased reusability –…increased reliability –…faster development –…reduced cost

18. Topic 3Summer 2003 18 Incrementality n Process proceeds in a stepwise fashion (increments) n Delivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product that is “not quite right” –Software development typically delivers one final product –Results in “not what the customer wanted” n Identify and “deliver” early subsets to gain early feedback –fosters controlled evolution n Incremental concentration on required qualities n Intermediate deliverables may be prototypes n Incrementality leads to… –…the development of better products –…early identification of problems –…an increase in customer satisfaction Active involvement of customer

19. Topic 3Summer 2003 19 Provided Interface Implementation Required Interface A Good Separation of Concerns, 1 Abstraction through the use of provided/required interfaces Modularity through the use of components Low coupling through the use of hierarchies High cohesion through the use of coherent implementations Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface

20. Topic 3Summer 2003 20 Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface A Good Separation of Concerns, 2 Abstraction through the use of provided/required interfaces Modularity through the use of components Low coupling through the use of a central “blackboard” High cohesion through the use of coherent implementations Implementation Provided Interface

21. Topic 3Summer 2003 21 Benefit 1: Anticipating Change Separating concerns allows for anticipation of change Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Implementation Provided Interface

22. Topic 3Summer 2003 22 Benefit 2: Promoting Generality Separating concerns promotes generality Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface

23. Topic 3Summer 2003 23 Benefit 3: Facilitating Incrementality Separating concerns facilitates incrementality Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Implementation Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface

24. Topic 3Summer 2003 24 ICS 52 Life Cycle Requirements phase Verify Design phase Verify Implementation phase Test Testing phase Verify

25. Topic 3Summer 2003 25 ICS 52 Software Life Cycle n Requirements specification –Interview customer (TA) –Focus on “what”, not “how” n Architectural and module design –Based on provided “official” requirements specification –Focus on interfaces n Implementation –Based on provided “official” design –Focus on good implementation techniques n Testing –Based on provided “official” implementation –Focus on fault coverage and discovery

26. Topic 3Summer 2003 26 Requirements Phase n Terminology –Requirements analysis/engineering Activity of unearthing a customer’s needs –Requirements specification Document describing a customer’s needs n Note: requirements address what a customer needs, not what a customer wants –A customer often does not know what they want or how to express it –Time-lag between initial desire and future need –Long and arduous, sometimes educational, process

27. Topic 3Summer 2003 27 Requirements Analysis n System engineering versus software engineering –What role does software play within the full solution? –Trend: software is everywhere –Even in computer chips n Contract model versus participatory design –Contract: carefully specify requirements, then contract out the development –Participatory: customers, users, and software development staff work together throughout the life cycle

28. Topic 3Summer 2003 28 Techniques for Requirements Analysis n Interview customer n Create use cases/scenarios n Prototype solutions n Observe customer n Identify important objects/roles/functions n Perform research n Construct glossaries n Question yourself Use the principles

29. Topic 3Summer 2003 29 Why have a Requirements Specification (the Document)? n Contract –Serve as the fundamental reference point between builder and buyer/user/"consumer " n Defines capabilities to be provided without saying how they should be provided –Defines the “what” –Does not define the “how” n Define constraints and environmental requirements on the software to guide the implementers –e.g. performance, platforms, language n Defines software qualities

30. Topic 3Summer 2003 30 Why Spend a Lot of Time? n A requirements specification is the source for all future steps in the software life cycle –Lays the basis for a mutual understanding Consumer (what they get) Software producer (what they build) –Identifies fundamental assumptions –Potential basis for future contracts n Better get it right –Upon delivery, some software is actually rejected by customers n Changes are cheap –Better make them now rather than later

31. Topic 3Summer 2003 31 Characteristics of a Requirements Specification (the Document) n Unambiguous –Requires precise, well-defined notations/language n Complete: any system that satisfies it is acceptable n Verifiable (testable) n No implementation bias (external properties only) –"One model, many realizations"

32. Topic 3Summer 2003 32 Software Qualities n Correctness n Reliability n Robustness n Performance n User friendliness n Verifiability n Maintainability n Repairability n Safety n Evolvability n Reusability n Portability n Understandability n Interoperability n Productivity n Size n Timeliness n Visibility These qualities often conflict with each other

33. Topic 3Summer 2003 33 Your Tasks 1. Read and study slides of this lecture