Overview of Software Engineering
 
About This Lecture

This course is intended to cover the object-oriented approach to software engineering, combining both the theoretical principles and the practical aspects of software design using the JAVA language. Students will learn the fundamentals of object-oriented software engineering and participate in a group project on software design using JAVA.

Lecture Menu

About this Lecture

The Software Crisis

Summary

Scope of Software Engineering

Software Life Cycle

Programming Team

An Example

The Software Crisis

The Problems

• Schedule slippage


• cost over-runs


• questionable quality


• customer dissatisfaction


• poor maintainability

The Reasons

• Poor/inadequate planning


• loose control and review


• technical incompetence


• non-engineering approach

Development Myths

• A general statement of objectives" is all I need from the customer. I will fill in the details later.
  
• As a customer I can keep changing my mind and redefining the intent of a program. After all, software is flexible, isn't it?


• I have got to begin coding because we are already late!
  
• The only deliverable for a successful project is a source code listing.


• It is impossible to assess the quality of a program until after it is written and working.


• Once the program is written, we are done.


• Any competent engineer can write programs.


• Let us run a few test cases and then we'll be finished!


• I know what the program does, I don't have time to document it.


• I am working on programs that were originally written 30 years ago. How can I use modern software engineering techniques?

• Apply an engineering approach to software development.


• Include procedures for planning, development, quality control, validation and maintenance.


• Apply the approach consistently, across all types of software.

A software lifecycle

• Planning


• Development


• Maintenance

Computer-based products and systems require a coordinated engineering effort for both software and hardware. Other system elements must also be integrated properly.

Key Criteria

• A well-defined methodology


• Predictable milestones


• traceability among steps


• documentation


• control

Software Configuration

The collection of documents including: software plan, requirements, specification, design documents, walk-through reports, source codes, testing results, maintenance reports. and other related documents.

• A software crisis encompasses many problems


• Myths cause management confusion and technical resistance


• A software life cycle model helps to deal with problems


• Software engineering addresses the life cycle in a systematic way

Characteristics of Software

What is the difference between building bridges and building operating systems?

Answer: Bridges are engineered to withstand every reasonably anticipated condition; while operating systems are often built so that damages caused by unanticipated conditions are minimized.

Corollary: Bridges are assumed to be perfectly engineered; while operating systems are assumed to be imperfectly engineered.

Another major difference: Bridges are not drastically modified during its useful life; while operating systems are often drastically modified. (People don't rotate the bridge 90% in the maintenance phase, but people do want to modify a batch operating system so that it supports time-sharing operation!)

Software Engineering is defined as the discipline whose aim is the production of fault-free software that satisfies th user's needs and that is delivered on time and within budget.

Software Life Cycle

The waterfall model considers software design as consisting of a number of stages, or phases.
1. Requirement Phase
2. Specification Phase
3. Planning Phase
4. Design Phase
5. Implementation Phase
6. Testing and Integration Phase
7. Maintenance Phase
8. Retirement

Approximate Costs of the Various Phases of the Software Life Cycle

1. Requirement Phase (2%)
2. Specification Phase (4%)
3. Planning Phase (1%)
4. Design Phase (6%)
5. Implementation Phase (5%)
6. Testing and Integration Phase (15%)
7. Maintenance Phase (67%)
8. Retirement

We need techniques, tools and practices to reduce maintenance costs!

Errors
The cost of fixing a fault increases at later stages of the software life cycle.

Many faults are introduced at the early stages of the design process.

We need better techniques to produce better specification and design.

Programming Team

Unless the team is properly organized, an inordinate amount of time can be wasted in conferences between team members.

If you put more people on a project that is already late, it can only delay it further!

There are different types of teams:

• chief-programmer team


• democratic team


• hierarchical team
  

Common Problems:

• Lack of understanding of other team members' job functions, expertise, etc.


• Improper delegation of authority


• Failure to report changes to other team members


• Failure to coordinate efforts


• Constant turn-over of team members

Object-Oriented Paradigm

The structured paradigm consists of structured systems analysis, structured design, structured programming and structured testing. They were introduced between 1975 and 1985, and looked promising at the time.

Two problems with structured paradigm:

• Could not scale up: Good for products with 5,000 or 50,000 LOC (lines of code), but inadequate for products with 500,000 LOC or more.


• Could not reduce maintenance costs.

The reason is that structured techniques are either action oriented (such as data flow analysis) or data oriented (such as Jackson method) but not both.

Object-oriented paradigm considers data and action to be of equal importance.

In structured paradigm, there are abrupt transitions between specification phase and the design phase. In object-oriented paradigm, the transition is smooth, because objects enter the life cycle at the very beginning. The objects are extracted in the analysis phase, designed in the design phase, and coded in the implementation phase. Thus, the object-oriented paradigm is an integrated approach.

Structured Paradigm

Specification phase
. Determine what the product does

Design Phase
. Architectural design (extract the modules)
. Detailed design (refine the modules)

Object-Oriented Paradigm

An Example

Suppose you live in New Orleans and you want to have a floral arrangement delivered to our aunt in Iowa City on her birthday. One way would be to try to obtain a list of all the florists in Iowa City and then determine which one is closest to your aunt's home. The other way is to call 1-800-FLOWERS and leave the entire responsibility for delivering the floral arrangement to that organization. You do not have to know the identity of the Iowa City florist who will deliver the flowers.
In exactly the same way, when a message is sent to an object, the object itself is totally responsible for every detail of carrying out the message.

This leads to the concept of responsibility-driven design or design by contract.