1

Software EngineeringDr. K. T. Tsang

Lecture 1

Introduction to SW Engineering

http://www.uic.edu.hk/~kentsang/SWE/SWE.htm

2

Textbook : general

• Software Engineering: 8th Edition

• By Ian Sommerville

• Pearson Education Limited, 2007

• ISBN 7-111-19770-4• This book is thick & contains many useful material, a

good reference for your future SW career as well. It is nice to have it handy but doesn’t necessary have to own it now.

3

Textbook : Object Orientated

• Object oriented modeling and design with UML, 2nd edition

• By Michael Blaha & James Rumbaugh

• Pearson Education, Inc., 2005

• ISBN 7-115-14076-6• This book is concise and unintimidating, a bible for OO

approach. You should own and read it carefully for this class.

4

Supplementary materials

• MIT OpenCourseWare: Software Engineering

• http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-171Fall2003/CourseHome/index.htm

• Plus other materials available on the web

Requirements for this Class

• You are proficient in a programming language, but you have no experience in analysis or design of a system

• You want to learn more about the technical aspects of analysis and design of complex software systems

5

Objectives of the Class• Appreciate Software Engineering:

– Build complex software systems that are easy to maintain

• Understand how to – produce high quality software system within time

limit– while dealing with complexity and changes

• Acquire technical knowledge (main emphasis)

• Acquire managerial knowledge

6

Acquire Technical Knowledge• Understand System Modeling• Learn UML (Unified Modeling Language)• Learn different modeling methods:

• Use Case modeling• Object Modeling• Dynamic Modeling• Issue Modeling

• Learn how to use Tools: – CASE (Computer Aided Software Engineering)

• Component-Based Software Engineering– Learn how to use Design Patterns and Frameworks

7

Acquire Managerial Knowledge

• Understand the Software Lifecycle– Process vs Product– Learn about different software lifecycles– Greenfield Engineering, Interface

Engineering, Reengineering

8

How to learn from this CourseReadings:

textbook

and Readings files on the Web site [I will direct you later].

Technical writing:

use the project documentation to improve your technical writing skill.

Grading (Subject to Change)

FINAL 20%??

Projects

A large part of the course is built around the projects

• Preferably real project for real client.

• Select your own project, but I will give my suggestions.

• Project teams, about 5 people each.

• Feasibility study and plan: due ??

• Three group presentations and written reports:

either: requirements, design, finalor: 1st iteration, 2nd iteration, final

The tutorials will be used to discuss the projects.

Now, let us start the fun!

12

13

What is software?

• More than just computer programs, including all documentation and the configuration (operating environment)

• Generic products– developed by software company/organization, sold to any customer

• Customized products– commissioned by customer, developed by software contractor

14

Why does SW matters?• SW’s contribution to US economy (1996)

– Greatest trade surplus of export– $24B software exported, $4B imported– Compare: agriculture 26 -14, aerospace 11 -3,

chemicals 26 -19, vehicles 21 -43, manufactured goods 200 -265

• Role in infrastructure– Not just the Internet– Transportation, energy, medicine, finance

15

What is software engineering?

• Engineering– the discipline to build things (systems) that works, applying theories, methods and tools available

• Software engineering– the entire technical process of software development, and the management of the whole process

20

Software Engineering: Definition

Software Engineering is a collection of techniques, methodologies and tools that help with the production of

• a high quality software system

• with a given budget

• before a given deadline

while change occurs.

Why software engineering?

• Demand for software is growing dramatically– Software costs are growing per system– Many projects have cost overruns– Many projects fail altogether– Software engineering seeks to find ways

to build systems that are on time and within budget

Software development costs

Software costs are increasing as hardware costs continue to decline.

•Hardware technology has made great advances•Simple and well understood tasks are encoded in hardware•Least understood tasks are encoded in software•Demands of software are growing•Size of the software applications is also increasing•Hence “the software crisis”

Software costs

Hardwarecosts

Time

Hardware costs vs. Software costs

19

Difference between software engineering & computer science

• Computer science is the academic study of theories and methods underlying computers and software systems

• Software engineering is the practice of producing software for specific applications. When the problem has no solution in theory, engineers often use ad hoc (“for this purpose only”) approaches to develop the software.

Scientist vs. Engineer• Computer Scientist

– Proves theorems about algorithms, designs languages, defines knowledge representation schemes

– Has infinite time…

• Engineer– Develops a solution for an application-specific problem for a client– Uses computers & languages, tools, techniques and methods

• Software Engineer– Works in multiple application domains– Has only 3 months...– …while changes occurs in requirements and available

technology

21

Software engineering & system engineering

• System engineering is concerned with all aspects of development and evolution of complex systems which often contain hardware as well as software

• System engineers are involved in specifying the system, defining the architecture, and integrating the different parts to create the finished system

Factors affecting the quality of a software system

• Complexity:– The system is so complex that no single programmer

can understand it anymore– The introduction of one bug fix causes another bug

• Change: – The “Entropy” of a software system increases with each change:

Each implemented change erodes the structure of the system which makes the next change even more expensive

– As time goes on, the cost to implement a change will be too high, and the system will then be unable to support its intended task. This is true of all systems, independent of their application domain or technological base.

23

How good is our software?

• Failed developments

• Accidents

• Poor quality software

A story about- Air Traffic Control

• FAA awarded IBM Federal Systems contract in 1989

• Deadline 2001, cost $2.5Billion• Constraints: 24x7x365, no

downtime, 2-3 secs response time• Budget: $80K hardware,

$2.5Billion software

ATC

• 1994: Cost estimate > $5Billion, nothing delivered• IBM federal systems, bought by Loral, had already

spent $2.3Billion• FAA enquiry:

– Not enough oversight over IBM

– FAA indecisive over requirements

– Technology had evolved faster than their ability to use it

• 1995/6: Formation, NJ to develop stopgap system• Lockheed Martin bought Loral, then lost most of the

contract to Raytheon

26

Development failures• IBM survey, 1994

– 55% of systems cost more than expected– 68% overran schedules– 88% had to be substantially redesigned

• Advanced Automation System (FAA, 1982-1994)– industry average was $100/line, expected to pay $500/line– Ended up paying $700-900/line– $6B worth of work discarded

• Bureau of Labor Statistics (1997)– For every 6 new systems put into operation, 2 cancelled– probability of cancellation is about 50% for biggest systems– average project overshoots schedule by 50%– 3/4 systems are regarded as ‘operating failures’

State of the SW development practice

Estimate Early On Time Delayed Canceled

13,000 6.06% 74.77% 11.83% 7.33%

130,000 1.24% 60.76% 17.67% 20.33%

1,300,000 0.14% 28.03% 23.83% 48.00%

13,000,000 0.00% 13.67% 21.33% 65.00%

Source: Patterns of software failures and successes, Capers Jones, 1996

•Delays common with mid- to –large projects.•Majority of the large projects are canceled.

What can you infer from this chart?

28

Accidents

“The most likely way for the world to be destroyed, most experts agree, is by accident. That’s where we come in. We’re computer professionals. We cause accidents.”Nathaniel Borenstein, inventor of MIME

Programming as if People Mattered: Friendly Programs, Software Engineering and Other Noble Delusions (Princeton University Press, Princeton, NJ, 1991)

29

Accidents: Therac-25 (1985-87) A standard case study in software control of safety-critical systems & health informatics

Radiation therapy machine with software controller• Two modes of operation: either low doses

electron beam mode• or high power e-beam with target plate

intervening to generate X-rays• Software failed to detect the target not rotated

into proper position in the X-ray mode• Several deaths due to burning• Programmer had no experience with concurrent

programming

30

Accidents: Ariane-5 (June 1996)

• European Space Agency

• complete loss of unmanned rocket shortly after takeoff

• due to exception thrown in Ada code

• faulty code was not even needed after takeoff

• due to change in physical environment: undocumented assumptions violated

Why is SE difficult? Complexity

• Application domain is complex• Domain experts are not software engineers• Difficulty for people with different background,

knowledge, and vocabularies to communicate effectively.

• Working in large teams is complicated– Difficult to grasp the details of large development projects

– Integration

• Ambiguity of natural language– “Render the tertiary (3D) structure on the screen in such a way that

the scientist can manoeuvre around the graphic representation”

32

What’s the problem?

• ‘Hacking code’ isn’t all there is to building software.

• In fact, it’s only a small part of it. Don’t think of code as part of the solution; often it’s part of the problem.

• We need better ways to talk about software than code, that are less cumbersome, more direct, and less tied to technology that will rapidly become obsolete.

33

Role of design and designers

• thinking in advance always helps!

• contrast with reliance on testing: more effective, much cheaper

• makes delegation and teamwork possible

• design flaws affect user: incoherent, inflexible and hard to use software

• design flaws affect developer: poor interfaces, bugs multiply

34

Software process

• The set of activities that lead to the final software product, this includes:– Specification- engineer & customer define the

requirement– Development- design & implementation– Validation- check to make sure the

requirements are satisfied– Maintenance/evolution- modification to adapt

to changing customer needs

Basic Process Steps in Software Development

• Feasibility and planning

• Requirements

• System and program design

• Implementation and testing

• Acceptance testing and release

• Operation and maintenance

It is essential to distinguish among these process steps.

35

Process Step: Feasibility and Planning

• A feasibility study precedes the decision to begin a project.

• What is the scope of the proposed project?

• Is the project technically feasible?

• What are the projected benefits?

• What are the costs, timetable?

A feasibility study leads to a decision: go or no-go.

36

Process Step: Requirements

37

Requirements define the function of the system from the client's viewpoint.

The requirements establish the system's functionality, constraints and goals by consultation with the client and users. They are then defined in a manner that is understandable by both the client and the development staff.

This phase is sometimes divided into:• Requirements analysis• Requirements definition• Requirements specification

Process Step: System and Program Design

38

Design describes the system from the software developers' viewpoint

System design: Match the requirements to hardware or software systems. Establishes an overall system architecture

Program design: Represent the software system functions in a form that can be transformed into one or more executable programs

• Unified Modeling Language (UML)

Process Step: Implementation and Testing

39

Implementation (coding)

The software design is realized as a set of programs or program units. (The software components may be written specifically, acquired from elsewhere, or modified.)

Testing

Individual components are tested against specifications.

The individual program units are integrated and tested against the design by the development staff as a complete system.

Process Step: Acceptance Testing and Release

40

Acceptance testing

The complete system is tested against the requirements by the client.

Delivery and release

The complete system is delivered to the client and released into production.

Process Step: Operation and Maintenance

41

Operation: The system is put into practical use.

Maintenance: Errors and problems are identified and fixed.

Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.

Phase out: The system is withdrawn from service.

This is sometimes called the Software Life Cycle

Software Life-Cycle

42

0

10

20

30

40

50

60

70

80

Req

uire

men

ts

Des

ign

Imp

lem

ent

atio

n

Tes

ting

Mai

nten

ance

Cost

Cost to fix an error increases as it is found later and later in the software lifecycle

Relative costs to fix errors:

Sequence of Processes

44

Every software project will include these basic processes, in some shape or form, but:

• They may be formal or informal

• They may be carried out in various sequences

Major alternatives

• Sequential: Complete each process step before beginning the next (but see the next few slides). Waterfall model.

• Iterative: Go quickly through all process steps to create a rough system, then repeat them to improve the system. Iterative refinement.

45

Software process models

• A simplified description of the software process that present one view of the process

• Some examples are:– Workflow models: the sequence of human activities in

the process of producing the software– Dataflow model: more concern with how inputs are

transformed to outputs in the process– Role/action model: concerns with the role of people

involved

46

Most used software process (workflow) models

• Waterfall approach: step-by-step approach from specifying requirements, designing, implementing to testing of software

• Iterative approach: similar to the Waterfall approach, but in each step engineer & customer will interact to refine or make sure requirements will be satisfied

• Component-based approach: many parts of the system already exist. The process focuses on integrating these parts to form the final system.

• SCRUM -- http://en.wikipedia.org/wiki/Scrum_(development)

47

Waterfall Model

Effort involved in the Waterfall Model

48

Waterfall Model

49

Advantages:

• Process visibility• Separation of tasks• Quality control at each step• Cost monitoring at each step

Disadvantages:

Each stage in the process reveals new understanding of the previous stages, that often requires the earlier stages to be revised.

Problem of the waterfall model

• Due to the inflexible nature of the division of a project into separate stages, commitments are usually made early on. So it is difficult to react to changes in requirements.

• Waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change radically in the course of the project.

50

Modified Waterfall Model

51

A pure sequential model is impossible

52

Examples:

• A feasibility study cannot create a proposed budget and schedule without a preliminary study of the requirements and a tentative design.

• Detailed design or implementation usually reveals gaps in the requirements specification.

The plan must allow for some form of iteration.

Iterative Development: evolutionary/incremental approach

53

Concept: Initial implementation for client and user comment, followed by refinement until system is complete.

• Vaporware: user interface mock-up

• Throw-away software components

• Dummy modules

• Rapid prototyping

• Successive refinement

Get something working as quickly as possible!

Iterative Development

54

55

Iterative Model

• Development process starts with a simple implementation of a subset of the software requirements.

• The developer takes advantage of what was being learned during this development of the earlier, incremental, deliverable version of the system. Learning comes from both the development and use of the system, where possible.

• Repeat the first step with a larger subset of the software requirements. Iteratively enhance the evolving sequence of versions until the full system is implemented.

• At each iteration, design modifications are made and new functional capabilities are added.

56

Rational Unified Process (RUP)

• One of the better known Iterative Process, developed by Rational Software (www.rational.com).

• The early iterations tend to be heavy on the requirements end of things (you need to define a

reasonable amount even to get started), while the later iterations have more of their effort in the design and build areas.

57

RUP Iterations can be grouped into phasesaccording to their stage in the overall project.

Each phase may have one or more iterations.

– In the inception phase iterations tend to be heavy on the requirements/analysis end, while any build activity may be limited to emulation of the design within a CASE tool.

– In the elaboration phase iterations tend to be completing the specification of the requirements, and starting to focus on the analysis and design, and possibly the first real built code.

– In the construction phase iterations the requirements and analysis are more or less completed, and the effort is mostly in design and build.

– Finally, in the deployment phase iterations are largely about build activity, and in particular the testing of the software.

58

Agile software development methods • A kind of iterative methods minimizing risk by developing software in

short amounts of time.• Each iteration may last from one to four weeks. Each iteration is an

entire software project: including planning, requirements analysis, design, coding, testing, and documentation.

• An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release at the end of each iteration.

• At the end of each iteration, the team re-evaluates project priorities.• Most agile methods share other iterative and incremental development

methods' emphasis on building releasable software in short time periods.

• http://en.wikipedia.org/wiki/Agile_software_development

59

Mixed Processes: Phased Development

60

Combine sequential and iterative elements

A simple system with basic functionality is brought quickly into production (Phase 1).

Subsequent phases are based on experience gained from users of each previous phase.

Advantages

• Pay-back on investment begins soon.

• Requirement are more clearly understood in developing subsequent phases

What is the primary driver of software costs?

3%8%

7%

15%

67%

Requirements -- 3%Design -- 8%Implementation -- 7%Testing -- 15%Maintenance -- 67%

•Most money and effort spent in testing and maintenance

•But: 85% of errors are introduced during requirements analysis and design

62

Costs of software engineering

• Waterfall model:– Spec 15%– Design 25– Development 20– Integrating & testing 40

• Iterative development– Spec 10%– Iterative development 60– System testing 30

63

Software engineering methods

• Structured analysis: function-oriented method, focus on identifying the basic functional components of the system

• Object oriented method: focus on the object model of the system– “United Modeling Language” (UML)

64

CASE: Computer Aided Software Engineering

• Tools supporting requirement analysis, system modeling debugging & testing

• Some CASE tools may include automatic code generator from the system model

65

Attributes of good software

• Maintainability- easy to maintain to meet changing needs

• Dependability- reliability, security, safety

• Efficiency- not wasting system resources

• Usability- user friendly, good documentation

66

Key challenges SW engineering

• Heterogeneous systems- in hardware & OS, in integrating new code with older legacy systems

• Delivery of quality sw on time

• Critical sw system must be dependable & trustworthy

67

Ethical responsibilities of SW engineer

• Confidentiality

• Competence

• Intellectual property rights

• Computer misuse

What software engineering is and is not..

• Software engineering is concerned with “engineering” software systems, that is, building and modifying software systems:– on time,

– within budget,

– meeting quality and performance standards,

– delivering the features desired/expected by the customer.

• Software engineering is not…– Just building small or new systems.

– Hacking or debugging until it works.

– Easy, simple, boring or even pointless!

Summary• Critical aspects of our day to day lives depend on

software, yet software development lacks the rigor and discipline of mature engineering disciplines:– Too many projects get delayed, costs and schedules

slip• Software engineering seeks to bring discipline and rigor

to the building and maintenance of software systems– Study of software engineering focuses on three key

elements: process, methods and tools• Why is important to consider alternative models of the

software development process?

Class web-page

• http://www.uic.edu.hk/~kentsang/SWE/SWE.htm