11 Software and Systems Design and Development

22 "software engineering"?: the "art" of building and maintaining software systems "…software engineering is a discipline whose aim is the production of fault-free software, delivered on time and within budget, that satisfies the user’s needs.” Schach, Object-Oriented and Classical Software Engineering, 5th ed., Mc-Graw-Hill 2002, p. 4 in embedded systems we extend these goals to mixed hardware / software systems, namely: --fault-free / fault-tolerant --delivered on time --delivered within budget constraints --MEETS THE USER’S NEEDS

33 Importance of “fault-free” … Software bugs can be lethal. The 2003 North America blackout was triggered by a local outage that went undetected due to a race condition – 55 million people were without power Smart ship USS Yorktown was left dead in the water in 1997 for nearly 3 hours after a divide by zero error So can hardware errors or bad design: The Therac-20 had hardware interlocks to prevent lethal doses of radiation that were removed in the Therac-25. Thus, unknown software defects that were effectively neutralized in the Therac-20 were exposed in the Therac-25 and caused several deaths (both machines used the same basic software).

44 Product Life Cycle Easier--Gather requirements (cheaper)(levels:1. functional to fix2. performance mistakes 3. implementation 4. use 5. maintenance) --Develop specifications --Design --Implement harder to fix--Test mistakes--Maintain

55 People (Stakeholders)—Roles, Goals, Functions RoleResponsibility CustomerHigh level requirements, project scope UserWhat tasks must system carry out? What is level of expertise? System salespersonGet requirements; delivery dates, cost Business ManagerOrganize, track work Technical ManagerManage technical issues DeveloperDesign, implement, test Technical WriterDocumentation, manuals Goals / Functions – conflicts?

66 Questions to Think About some points to ponder: "software crisis"--systems become more and more complex: --what can we automate? --what can we put into hardware? will this improve reliability? --how can we verify/ test such complex systems? "hardware/software" boundary --how can we do "co-design"? --where is the boundary? types of systems --how do important application-specific systems differ? --what impact do differences have on development? --which systems will be most important in coming years?

77 Important System Types Some Common System Types—what is the same/different? Databases Communication systems Entertainment systems Web-based applications Medical systems Manufacturing / transportation systems Defense systems Simulation programs to support engineering and science Parallel/distributed applications Systems for consumer products-home, entertainment Intelligent systems / robots Utilities for computer systems (compilers, routers, e.g.) Utilities for general users (spreadsheets, e.g.)

8 Engineering Phases Engineering: Systematic, disciplined quantifiable approach to the development, operation and maintenance of the product. Three distinct phases “product life cycle”): Definition phase: WHAT, i.e., what information, function, performance Development phase: HOW Support Phase: CHANGE, i.e., correction, adaptation, enhancement, prevention Analyze— Requirmnts, Spec. Develop— Design, Code. Maintain

9 Developing a program / system How do you develop a program / system from scratch? For example: --what did you do in your first computing/ dig design class? --what do you do differently now? --what good / bad practices have seen in co-op / jobs? --what are differences for small / large projects?

10 Capability Maturity Model CMM : capability maturity model--defines level of the development process itself 1. Initial: ad hoc 2. Repeatable: basic project management processes in place 3. Defined: documented process integrated into an organization-wide software process 4. Managed: detailed measures are collected 5.Optimizing--desired level: Continuous process improvement from quantitative feedback Question: what process models have you used? How large / complex was the project? What level did the associated process represent?

11 Process Model Process Model: --A development strategy that encompasses the process, methods, and tools --Specific model is chosen based upon the project/application, the methods/tools to be used, resources available, and the deliverables required basic model: problem  develop  integrate each step is carried out recursively until an appropriate level of detail is achieved

12 Process Model Types Process Model Types: “Prescriptive” Model includes a specific set of tasks, along with a workflow for these tasks and definite milestones and outcomes for each task; end result is the desired product "Agile" Model tends to be simpler than prescriptive models; emphasis is on incremental development, customer satisfaction, and minimal process overhead "Mathematical" Formal Method Model stresses mathematical rigor and formal proofs that product is meeting carefully-defined goals

13 Some Common Prescriptive Models Some common models used in practice: Prescriptive: "Basic": Linear Sequential (“Waterfall”) Model Prototyping Model "Evolutionary" (product evolves over time): Incremental Model Component-based Model “Formal Methods” Z-based methods “Agile”—for products requiring frequent updates / releases Extreme Programming

14 Waterfall Model AnalysisDesignCodeTestMaintain Linear Sequential Model (“waterfall model”): Sequential approach from system level through analysis, design, coding, testing, support--oldest and most widely used paradigm Advantages: --better than nothing --can be appropriate for small, well-understood projects Disadvantages: --Real projects rarely follow a sequential flow --Requirements usually not fully known. --Working version not available until late in project.

15 Prototyping Model Prototyping Model: customer defines set of general objectives; no details on input, processing, output requirements; may be unsure of algorithm efficiency, adaptability, OS, human/machine issues Advantages: --Focuses on what is visible to customer --Quick design leads to a prototype --Prototype evaluated by the customer who can refine requirements --Ideal mechanism for identifying and refining SW requirements Disadvantages: --Customer sees something that appears to work and wants it. --Less than ideal choices move from prototype to product SW Prototyping:A-->D-->C-->T-->M (A=analysis, D=design, C=coding, T=testing, M=maintenance)

16 Evolutionary Models

17 Incremental Model Incremental: A-->D-->C-->T-->M-->A-->D-->C-->T--> ……-->M (A=analysis, D=design, C=coding, T=testing, M=maintenance) Incremental Model: Elements of linear sequential (applied repetitively) with prototyping. As result of use, a plan is developed for next increment. Advantages: Unlike prototyping, an operational product is delivered at each increment. Disadvantages: Variable staffing at each increment (task dependent). Risk analysis must be done at each increment.

18 Component Based Development Component based: A-->D-->Library-->Integrate-->T-->M C (A=analysis, D=design, C=coding, T=testing, M=maintenance) Component Based Development: emphasizes the creation of classes that encapsulate data and the algorithms to manipulate the data. Reusability. Evolutionary and iterative. But composes applications from prepackaged SW components (classes) Process steps: --candidate class is identified --library is searched for existing class --if none exists, then one engineered using object-oriented methods. Advantages: Faster development and lower costs. Disadvantages: requires expertise in this type of development

19 Process Models--Comparison Graphical comparison of basic and evolutionary models: Basic waterfall model: A-->D-->C-->T-->M (A=analysis, D=design, C=coding, T=testing, M=maintenance) Prototyping:A-->D-->C-->T-->M Incremental: A-->D-->C-->T-->M-->A-->D-->C-->T--> ……-->M  Component based:A-->D-->Library-->Integrate-->T-->M C

20 Formal Methods Formal Methods: formal mathematical specification of SW. Uses rigorous mathematical notation. Advantages: --Ambiguity, incompleteness, inconsistency found more easily. --Serves as a basis for program verification. --”promise” of defect-free SW Disadvantages: --Very time consuming --extensive training required --not a good communication mechanism (especially for customer) --handles syntax well; not so successful with semantics uses: Safety critical SW (medicine and avionics) or when severe economic hardship will be incurred by developer if error occurs

21 Extreme Programming—an Agile Process Model Extreme Programming-- An Agile Process Model

22 Review of Process Models In process models discussed previously: problem  develop  integrate each step is carried out recursively until an appropriate level of detail is achieved Basic method:

23 Introduction to Extreme Programming

24 “12 Practices” of XP

25 Metaphor

26 Release Planning 2. release planning requirements are given in terms of "user stories" each "story" is a short (~ 1 index card) description of what the customer wants, in natural language requirements are prioritized by customer resources and risks are estimated by developer "planning game"--each increment is restricted to a "time box"; highest priority and highest risk user stories are in early time boxes; after each increment, replay the "planning game"

27 Testing 3. testing development is test-driven tests are written before code unit must run at 100% before going on acceptance tests written with customer; they act as "contract", measure progress

28 Pair Programming 4. pair programming two engineers, one task, one computer "driver" controls keyboard & mouse "navigator" watches, identifies defects, participates in brainstorming roles are rotated periodically (you use this approach in week 1 lab to gain some java skills)

29 Refactoring 5. refactoring improve design of existing code, but don't change functionality relies on testing; no new errors can be introduced

30 Simple Design 6. simple design no big design up front "do the simplest thing that could possibly work" don't add features you won't need may use "CRC cards"

31 Collective Code Ownership 7. collective code ownership code belongs to project, not individual engineers may browse into and modify ANY class

32 Continuous Integration 8. continuous integration pair writes unit test cases & code pair tests code to 100% pair integrates pair runs ALL test cases to 100% pair moves on to next task

33 On-Site Customer 9. on-site customer clarifies stories, participates in critical decisions developers don't make assumptions no waiting for decisions face-to-face communication

34 Small Releases 10. small releases timeboxed as small as possible, but with "business value" get feedback early and often do planning game after each iteration

35 40-Hour Work Week hour work week burning midnight oil kills performance tired developers make more mistakes workforce is more content

36 Coding Standards 12. coding standards use coding conventions write intention-revealing code

37 “13th Practice” "13th practice": stand up meeting 15 minutes at start of each day stand up to keep meeting short each participant says --what they did yesterday --what they plan to do today --any obstacles they are facing pairs can be reformed based on meeting

38 Contrast with Waterfall Model example contrasts: "waterfall model” || XP planning: upfront || incremental control of project, "people" questions: centralized || distributed customer involvement: only for specification, reviews || ongoing risk analysis, scheduling: all at beginning || in increments code development: assigned sections || collective ownership testing: specific phase || ongoing and required to 100% project type: well-understood, static || new, dynamic

39 Question 1: How are analysis and specification done --in the “extreme programming” model? --in the waterfall model? Question 2: How adaptable are these process models to embedded systems (mixed hardware / software systems)? Analysis and specification in XP