1. CIS 375 Bruce R. Maxim UM-Dearborn
Software Engineering
CIS 375
Bruce R. Maxim
UM-Dearborn
4/5/2019

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

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/5/2019

4. Historical Project Cost Allocation
4/5/2019

5. Early Error Detection Saves Money
4/5/2019

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
4/5/2019

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.
4/5/2019

8. Failures Over Time
Hardware
Software
4/5/2019

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.
4/5/2019

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.
4/5/2019

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.
4/5/2019

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.
4/5/2019

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
4/5/2019

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
4/5/2019

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
4/5/2019

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

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).
4/5/2019

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).
4/5/2019

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).
4/5/2019

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.
4/5/2019

21. Components and Subsystems
4/5/2019

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.
4/5/2019

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
4/5/2019

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.
4/5/2019

25. Umbrella Activities Part 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)
4/5/2019

26. Umbrella Activities Part 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.)
4/5/2019

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
4/5/2019

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
4/5/2019

29. Linear Sequential Model or Waterfall Model
4/5/2019

30. Prototyping Model
4/5/2019

31. Spiral Model
4/5/2019

32. Fourth Generation Language Techniques
4/5/2019

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
4/5/2019

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
4/5/2019

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
4/5/2019

36. Unified Process Work Products Inception Phase
Vision document
Initial use-case model
Initial project glossary
Initial business case
Initial risk assessment
Project plan (phases and iterations)
Business model
Prototypes
4/5/2019

37. Unified Process Work Products Elaboration 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
4/5/2019

38. Unified Process Work Products Construction Phase
Design model
Software components
Integrated software increment
Test plan
Test cases
Support documentation (user, installation, increment)
4/5/2019

39. Unified Process Work Products Transition Phase
Delivered software increment
Beta test reports
User feedback
4/5/2019

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).
4/5/2019

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.
4/5/2019

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.
4/5/2019

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.
4/5/2019

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
4/5/2019

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.
4/5/2019

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.
4/5/2019

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)
4/5/2019