CIS 375 SOFTWARE ENGINEERING

UNIVERSITY OF MICHIGAN-DEARBORN

DR. BRUCE MAXIM, INSTRUCTOR

Date: 9/8/97

Week 1

SOFTWARE ENGINEERING IS:

• Structured Methodology.
• Object Oriented Analysis / Object Oriented Design.
• User Interface Design.
  (Up to 80% of code may be for the user interface alone).

WHY IS SOFTWARE ENGINEERING IMPORTANT?

• To avoid costly errors caused by software (such as):
  • The lost Voyager Spacecraft.
    One incorrect line of code caused it to fly off into space uncontrollably.
  • 3 Mile Island.
    Poor user interface design (green = close; red = open), caused operator confusion.
  • Several people killed by a radiation machine.
    Due to a poor user interface.
  • Commercial aircraft accidentally shot down.
    Due to poor user interface.

HISTORICAL SYSTEM IMPLEMENTATION COSTS:

WHY HAS STRUCTURED DESIGN BECOME SO IMPORTANT?

CHARACTERISTICS OF SOFTWARE DESIGNERS:

• They tend to suffer from "not invented here syndrome"
  (If they didn't create the problem they cannot fix it).
• 80% of their errors can be discovered through simple "peer review".

SOFTWARE CHARACTERISTICS:

• Software is developed or engineered, not manufactured.
• Software doesn't "wear-out".

• Most software is custom built, not assembled from components.

DEFINITION OF SOFTWARE ENGINEERING:

• A strategy for producing high quality software.

DEFINITION OF 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).
• 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).

SOFTWARE DEVELOPMENT MODELS:

SYSTEMS APPROACH:

• Distinguish between activities (processes, methods) and objects (data).
• Determine the relationships between the objects.

ADVANTAGES OF BOUNDED SYSTEMS:

• Makes problem identification easier.
  (It is often useful to think of a system as a sub-system, for the purpose of extension).

SOFTWARE ENGINEERING APPROACH:

• The art of producing systems involves the craft of programming.
• Fabricating software using "off the shelf" components.

WHY DOESN'T THIS WORK WELL:

• Customers are not capable of describing their needs completely or precisely.
• Customers change the specifications.

SOFTWARE LIFECYCLE MODELS:

PHASES:

1. Requirements, analysis, and design phase.
2. System design phase.
3. Program design phase.
4. Program implementation phase.
5. Unit testing phase.
6. Integration testing phase.
7. System testing phase.
8. System delivery phase.
9. System delivery.
10. Maintenance.

Date: 9/10/97

Week 1

MODELS:

WATERFALL MODEL:

• Errors require at least one step back in the cycle.
• Change Failure.

RAPID PROTOTYPING MODEL:

• Start with user interface (probably most important to customer).
• When customer is happy with that, then work on the behind the scenes stuff.
• Customer is involved throughout the entire process.

SPIRAL MODEL:

• Prototyping is used to reduce risk.

FOURTH GENERATION TECHNIQUES:

• Non-procedural data-base query languages.
• Some type of report generator.
• Often capable of high-level graphics.
• Spreadsheets.

CAPABILITY MATURITY MODEL:

MATURITY MODELS:

LEVEL ONE; INITIAL PROCESS:

• Ad-hoc approach to software design.
• Inputs are ill defined.
• Outputs are expected (transitions not defined or controllable).

LEVEL TWO; REPEATABLE PROCESS:

• Requirements are input.
• Code output.
• Constraints - budget & time.
• Metrics - project related:
  • Software size.
  • Personnel effort.
  • Requirement validity.
  • Employee turnover.

LEVEL THREE; 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.

LEVEL FOUR; MANAGED PROCESS:

• Information from early process activities can be used to schedule later process activities.
• Metrics:
  • Defined and analyzed to suit the development organization.
  • Data:
  • Process type.
  • Producer reuse.
  • Consumer reuse.
  • Defect identification mechanism.
  • Defect density - model for testing.
  • Configuration management scheme.
  • Module completion; rates over time.

LEVEL FIVE; OPTIMIZING PROCESSES:

• Measures from activities are used to improve processes.

HOW ARE METRICS USED?

• 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.

BENEFITS OF PROCESS MATURITY AND 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.

PROJECT MANAGEMENT: (3 PARTS)

1. People
   • Customers
   • Managers
   • Software Engineers
   • Users
2. Problem
   • Scope
     • Context
     • Information
     • Function
     • Performance
3. Process
   • Engineering Paradigm (How to build?)
     90/10 Rule (90% of the effort on project, to accomplish 10% of the work)

SOFTWARE DEVELOPMENT TEAMS:

PROBLEMS WITH SOFTWARE DEVELOPMENT:

• Changing constraints and requirements.
• Phased system development:
• Development system.
• Production system.
• Interaction with other systems.
• Nature of the computer system itself:
• Digital vs. Analog vs. Hybrid.
• Logic of software development.
• The type of software project.