Software Engineering

1. Software Engineering CIS 375 Bruce R. Maxim UM-Dearborn

2. What is CIS 375 about? • Project Management • Structured Methodology • Object Oriented Analysis / Object Oriented Design • User Interface Design • Testing and Validation

3. Why is software engineering important? To avoid costly errors caused by software: • Lost Voyager Spacecraft (one bad line of code caused failure) • 3 Mile Island (poor user interface design) • Several people killed by a radiation machine (no means of catching operator errors) • Commercial aircraft accidentally shot down during Gulf War (poor user interface)

4. Historical Project Cost Allocation

5. Early Error Detection Saves Money

6. Software Designer Characteristics • Studies have found that many designers tend to suffer from the “not invented here” syndrome • 80% of most software errors can be discovered by peer review (proof reading) the code or document

7. Software Characteristics • Software is both a product and a vehicle for developing a product. • Software is engineered not manufactured. • Software does not wear out, but it does deteriorate. • Most software is still custom-built.

8. Failures Over Time Hardware Software

9. Software Crisis • Software failures receive a lot more publicity than software engineering success stories. • The software crisis predicted thirty years ago has never materialized and software engineering successes now outnumber the failures. • The problems that afflict software development are more likely to be associated with how to develop and support software properly, than with simply building software that functions correctly.

10. Software Myths – Part 1 • Software standards provide software engineers with all the guidance they need. • People with modern computers have all the software development tools they need • Adding people is a good way to catch up when a project is behind schedule. • Giving software projects to outside parties to develop solves software project management problems.

11. Software Myths – Part 2 • A general statement of objectives from the customer is all that is needed to begin a software project. • Project requirements change continually and change is easy to accommodate in the software design. • Once a program is written, the software engineer's work is finished.

12. Software Myths – Part 3 • There is no way to assess the quality of a piece of software until it is actually running on some machine. The only deliverable from a successful software project is the working program. • Software engineering is all about the creation of large and unnecessary documentation not shorter development times or reduced costs.

13. Software Evolution – Part 1 • Law of continuing change • Systems must be continually adapted or they become progressively unsatisfactory • Law of increasing complexity • As system evolves its complexity increases unless work is done to reduce the complexity • Law of self-regulation • System evolution is self-regulating with its process and product measures following near normal distributions

14. Software Evolution – Part 2 • Law of conservation of Organizational Stability • Average effective global activity rate for an evolving systems is invariant over the product lifetime • Law of conservation of familiarity • As system evolves all stakeholders must maintain their mastery of its content and behavior to achieve satisfactory evolution

15. Software Evolution – Part 3 • Law of continuing growth • Functional content of system must be continually increased to maintain user satisfaction over its lifetime • Law of declining quality • System quality will appear to decline unless the system is rigorously maintained and adapted to environment changes • Feedback system law • System evolution processes must be treated as multi-level, multi-loop, multi-agent feedback systems to achieve significant improvement

16. Software Engineering • A strategy for producing high quality software. • Software engineering encompasses a process, management techniques, technical methods, and the use of tools.

17. What is high quality software? • It must be useful (to the original customer). • It must be portable (work at all of the customer’s sites). • It must be maintainable. • It must be reliable. • It must have integrity (produces correct results, with a high degree of accuracy).

18. What is high quality software? • It must be efficient. • It must have consistency of function (it does what the user would, reasonably expect it to do). • It must be accessible (to the user). • It must have good human engineering (easy to learn and easy to use).

19. Software Engineering Phases • Definition phase • focuses on what (information engineering, software project planning, requirements analysis). • Development phase • focuses on how (software design, code generation, software testing). • Support phase • focuses on change (corrective maintenance, adaptive maintenance, perfective maintenance, preventative maintenance).

20. Systems Approach • A set of entities. • A set of activities. • Descriptions of entity relationships. • System boundaries. • Distinguish between activities (processes, methods) and objects (data). • Determine the relationships between the objects.

21. Components and Subsystems

22. Engineering Approach • The art of producing a system involves the craft of software production • Engineers think that computer scientists should be able to fabricate software systems out of off the shelf components like hardware designers do.

23. Why doesn’t this approach work? • Customers are not capable of describing their needs completely or precisely. • Customers or programmers change the specifications as development proceeds

24. Software Life Cycle Phases • Requirements, analysis, and design phase. • System design phase. • Program design phase. • Program implementation phase. • Unit testing phase. • Integration testing phase. • System testing phase. • System delivery. • Maintenance.

25. Umbrella ActivitiesPart 1 • Software project tracking and control (allows team to assess progress and take corrective action to maintain schedule) • Risk management (assess risks that may affect project outcomes or quality) • Software quality assurance (activities required to maintain software quality) • Formal technical reviews (assess engineering work products to uncover and remove errors before they propagate to next activity)

26. Umbrella ActivitiesPart 2 • Measurement (define and collect process, project, and product measures to assist team in delivering software meeting customer needs) • Software configuration management (manage effects of change) • Reusability management (defines criteria for work product reuse and establish mechanisms to achieve component reuse) • Work product preparation and production (activities to create models, documents, logs, forms, lists, etc.)

27. Comparing Process Models Part 1 • Overall flow and level of interdependencies among tasks • Degree to which work tasks are defined within each framework activity • Degree to which work products are identified and required • Manner in which quality assurance activities are applied • Manner in which project tracking and control activities are applied

28. Comparing Process Models – Part 2 • Overall degree of detail and rigor of process description • Degree to which stakeholders are involved in the project • Level of autonomy given to project team • Degree to which team organization and roles are prescribed

29. Linear Sequential Model or Waterfall Model

30. Prototyping Model

31. Spiral Model

32. Fourth Generation Language Techniques

33. Specialized Process Models • Component-Based Development • spiral model variation in which applications are built from prepackaged software components called classes • Formal Methods Model • rigorous mathematical notation used to specify, design, and verify computer-based systems • Aspect-Oriented Programming • provides a process for defining, specifying, designing, and constructing software aspects like user interfaces, security, and memory management that impact many parts of the system being developed

34. Unified Process • Use-case driven, architecture centric, iterative, and incremental software process • Attempts to draw on best features of traditional software process models and implements many features of agile software development

35. Unified Process Phases • Inception phase • customer communication and planning • Elaboration phase • communication and modeling • Construction phase • Transition phase • customer delivery and feedback • Production phase • software monitoring and support

36. Unified Process Work ProductsInception Phase • Vision document • Initial use-case model • Initial project glossary • Initial business case • Initial risk assessment • Project plan (phases and iterations) • Business model • Prototypes

37. Unified Process Work ProductsElaboration Phase • Use-case model • Functional and non-functional requirements • Analysis model • Software architecture description • Executable architectural prototype • Preliminary design model • Revise risk list • Project plan (iteration plan, workflow, milestones) • Preliminary user manual

38. Unified Process Work ProductsConstruction Phase • Design model • Software components • Integrated software increment • Test plan • Test cases • Support documentation (user, installation, increment)

39. Unified Process Work ProductsTransition Phase • Delivered software increment • Beta test reports • User feedback

40. Capability Maturity Model Level 1: Initial Process • Ad-hoc approach to software design. • Inputs are ill defined. • Outputs are expected (transitions not defined or controllable).

41. Capability Maturity Model Level 2: Repeatable Process • Requirements are input. • Code is output. • Constraints are things like budget & time. • Metrics - project related: • Software size. • Personnel effort. • Requirement validity. • Employee turnover.

42. Capability Maturity Model Level 3: Defined Process • The activities of the process have clearly defined entry & exit conditions. • Intermediate products - well defined and easily visible. • Metrics: • Requirements complexity. • Code complexity. • Failures discovered. • Code defects discovered. • Product defect density. • Pages of documentation.

43. Capability Maturity Model Level 4: Managed Process • Information from early process activities can be used to schedule later process activities. • Metrics are defined and analyzed to suit the development organization: • Process type. • Producer reuse. • Consumer reuse. • Defect identification mechanism. • Defect density - model for testing. • Configuration management scheme. • Module completion rate over time.

44. Capability Maturity Model Level 5: Optimizing Process • Measures from activities are used to improve processes • Continuous process improvement is enabled by quantitative feedback from the process and testing innovative ideas • Metrics are selected to enhance feedback into evaluation mechanism

45. Using Metrics • Assess the process level. • Determine metrics to use. • Recommend metrics, tools, techniques. • Estimate project costs and schedule. • Collect metrics at the appropriate level. • Construct a project database. • Evaluate cost and schedule. • Evaluate productivity and quality. • Form a basis for future estimates.

46. Benefits of Using Metrics • Enhanced understanding of the process. • Increased control over the process. • Clear migration path to a more mature process. • More accurate estimates of cost and scheduling of staff. • More objective evaluation of changes needed (techniques, tools, methods, ect.). • More accurate estimation of changes on project cost and schedule.

47. Software Patterns • Templates or methods for describing important characteristics of software processes • Software teams can combine software patterns to construct processes that best meet the needs of specific projects • Task pattern (defines engineering action or work task) • Stage pattern (defines framework activity for the process) • Phase pattern (defines sequence or flow of framework activities that occur within process)