1 EE29B Feisal Mohammed EE29B: Introduction to Software Engineering Feisal Mohammed [email protected] Ph: 662-2002 x3156

1 EE29B Feisal Mohammed

EE29B: Introduction to Software Engineering

Feisal Mohammed

[email protected]

Ph: 662-2002 x3156


EE29B: Introduction to Software Engineering

This course is examined by coursework (40%) and by examination (60%)

There will be three projects, the first one will be an individual project and the rest done in groups. Groups are to be 3-4 students.

There are no lab exercises.

Demonstrators are Jason Yuk Lee and Jason Cox


What is Software Engineering?The IEEE Computer Society defines

software engineering as:

The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software.

The study of approaches as above.


Problem solving (Analysis)

We typically solve a problem by analysing it, that is by breaking it down into pieces.

Problem

14

32

14

32


Problem solving (Synthesis)Once we have analysed the problem, we

must construct our solution from components that address the problem's various aspects

Solution

14

32

14

32


How are software projects different?

Invisibility No physical presence

Flexibility After all it's software

Complexity no physical constraints


The Software IcebergThe

ProductWhat the customers see

Compilers, Operating Systems, Utilities

DBMSCASE

Configuration Management

CodeData Definitions

Databases

SpecificationsPlans

Standards & ProceduresManuals

SimulatorsDevelopment Systems

Automatic test Equipment


Key Issues facing Software Developers

Unfulfilled demand

Increasing complexity

Greater customer expectations

Rapid obsolescence

Increasing competition

Shorter product cycle times

Producing more with less

Evolving methods and tools


Do projects ever fail?

15% of all projects never deliver a useful product

20% of large projects ( 25 or more work-years) failed to deliver

Most common reported cause was sociological


Terminology for describing “bugs”

A fault occurs when a human makes a mistake, called an error in performing some software activity.

A failure is a departure from the systems required behaviour It can be discovered before or after system delivery or during operation and maintenance. Since requirements documents can contain faults, failures can exist even though the system is performing as specified!


What does project failure mean?

Late delivery? No delivery at all?

Not delivering what was agreed to or what was announced?

Over budget?

Not meeting revenue expectations?

Quality below expectations?


Some reasons projects fail

Not understanding what the product must do

Uncontrolled changes

Optimistic thinking

Insufficient resources

Lack of disciplined development

Confusion about what needs to be done

Ineffective teamwork

Failure to consider business needs


Some reasons products fail

Price

Mature market

Lack essential capabilities

Difficult to use

Unreliable

Poor developer reputations

Poor product support


Some reasons projects succeed

Good understanding of the problem to solve

Good planning and execution

Extraordinary effort and commitment by individuals

Luck


Some reasons products succeed

Satisfy an unfulfilled need

Novelty

Value

Marketing strategy


What is good software?

Quality of the product?

Quality of the process?

Quality in the context of the Business Environment?


Quality of the product

Correctness

Reliability

Efficiency

Integrity

Usability

Maintainability

Testability

Flexibility

Portability

Reuseability

Interoperability


Quality of the process

Where and when are we likely to find a particular kind of fault?

How can we find faults earlier in the development process?

How can we build in fault tolerance so that we can minimize the likelihood that a fault will become a failure?

Are there alternative activities that can make our process more effective or efficient at assuring quality?


Quality in the context of the business environment

A view in terms of the products and services being provided by the business in which the software is embedded. That is, we look at the business value. This can be as simple as Return On Investment (ROI) or some more elaborate measure.


Who does software engineering?CustomerSponsors systemdevelopment

DeveloperBuildssystem

UserUsessystem

$$$,needs

Contractualobligation

Needs

Software system


Systems Approach

Activities and Objects

Relationships and the System Boundary

Consider nested systems and system interrelationships


Activities and Objects

Distinguish between activities and objects

An activity is something that happens in a system.

The elements involved in the activities are called the objects or entities.


Relationships and the System BoundaryA system is defined as a collection of

things: a set of entities, a set of activities, a description of the relationships among entities and activities, and a definition of the boundary of the system.

Examples: the human respiratory system, a paycheck production system


Nested systems

It is possible for one system to exist within another system, e.g. sensor system

One can have various functions of the sensors nested within each other.


An analogy of software engineering

Determining and analysing requirements

Producing and documenting the design

Detailed specifications

Identifying and designing components

Requirements analysis and definition

System design

Program design


Analogy ...

Building components

Testing components

Integrating components

Making final modifications

Continuing maintenance

Writing programs

Unit testing

Integration testing

System testing

System delivery

Maintenance

Documents

1 EE29B Feisal Mohammed EE29B: Introduction to Software Engineering Feisal Mohammed [email protected] Ph: 662-2002 x3156