Software Engineering

Spring, 2014

Class information

Instructor

Prof. Wonhong Nam http://home.konkuk.ac.kr/~wnam

Office: New Millennium Building 1301

Email: wnam@konkuk.ac.kr, Tel: 2049-6128

Office hours: Tue 4-5pm, Fri 1:30-2:30pm

Textbook

Object-Oriented Software Engineering Using UML, Patterns, and Java. Bernd Bruegge & Allen H. Dutoit, 3rd Edition, Pearson.

Chapter 1 – 7 (or 8)

cover approx. 25 pages in every weekStudents are expected to study 6-9 hours in a week.

Secondary: Software Engineering 9, Sommerville, Pearson.

Course web page

http://home.konkuk.ac.kr/~wnam/class/se2014/

Grade: 10% attendance, 60% project, 30% final exam.

Each team consists of 4 students.

Send an email for your team on 3/7.2

Preface: K2 towers (8,611 meters)

The second highest peak of the world.

An expedition requires thousands of pounds of equipment, including climbing gear, severe weather protection gear, tents, food, communication equipment, and pay and shoes for hundreds of porters.

Planning such an expedition takes a significant amount of time in the life of a climber and requires dozens of partici-pants in supporting roles.

Once on site, many unexpected events, such as avalanches, porter strikes, or equipment failures, will force the climbers to adapt, find new solutions, or retreat.

The success rate for expeditions to the K2 is less than 40%.

3

Preface: US NAS

US National Airspace System (NAS)monitors and controls air traffic in US, and it includes more than 18,300 air-ports, 21 air route traffic control centers, and over 460 control towers.

These add up to more than 34,000 pieces of equipment, including radar systems, communication switches, radios, computer systems, and displays.

The previous modernizing efforts of NAS was suspended in 1994 because of software-related problems, after missing its initial deadline by several years and exceeding its budget by several billions of dollars.

In 1996, US government initiated a program to modernize NAS infrastructure.

However, such a complex infrastructure can only be modernized incrementally.While new components offering new functionality are introduced, older components still need to be supported.

4

Complex systems• External conditions can trigger unexpected changes.• Complexity puts the problem beyond the control of any single

individual.• Change forces participants to move away from well-known

solutions and to invent new ones.• Several participants need to cooperate and develop new

techniques to address these challenges.• Failure to do so results in failure to reach the goal.

Preface [Som]

The name ‘software engineering’ was proposed in 1969 at a NATO conference to discuss software development prob-lems—

large software systems were late, did not deliver the functionality needed by their users, cost more than expected, and were unreliable.

National utilities and infrastructure—energy, communica-tions, and transport—all rely on complex and mostly reliable computer systems.

Humanity is now faced with a new set of challengesclimate change and extreme weather, declining natural resources, an increas-ing world population to be fed and housed, international terrorism, and the need to help elderly people lead satisfying and fulfilled lives.

We need new technologies to help us address these prob-lems and, for sure, software will play a central role in these technologies.

5

Ch. 1. Intro to Software Engineering (SE)

The term SE was coined in 1969as a response to the desolate state of the art of developing quality SW on time and within budget.

SW developers were not able to set concrete objectives, predicate the re-sources necessary to attain those objectives, and manage the customers’ ex-pectations.

The emphasis in SE is on both words, software and engi-neering.

6

1.1 Software (Engineering) Failures

Year 1900 bugIn 1992, Mary from Minnesota, received an invitation to attend a kindergarten. Mary was 104 at the time.

Interface misuseIn 1990, in London, an underground train left the station without its driver.

Late and over budgetIn 1995, the new Denver Airport opened 16 months late, $3.2 billion over budget, with mostly manual luggage system.

In 2002, the Swanick Air Traffic Control System covers all the enroute air traffic over England and Wales. The system was delivered over budget (cost 623 M pounds, originally planned at 350 M pounds) and 6 years late.

On-time deliveryAfter 18 months of development, a $200-millon system was delivered to a health insurance company in WI in 1984. However, the system did not work correctly: $60 million in overpayments were issued. The system took 3 years to fix.

7

Software (Engineering) Failures

Each of failures resulted from a SW-related problem.Developers did not anticipate seldom-occurring situations.

Developers did not anticipate the user actively misusing the system.

System failures resulted from management failures.

Obstacles: SW systems are complex creations.They perform many functions.

Many participants from difference disciplines take part in the development.

The development process and the software life cycle often spans many years.

Complex systems are difficult to understand completely by any single person.

SW development projects are subject to constant change.

8

Ch 1. Introduction [Som]

We can’t run the modern world without software.

There are many different types of software systems, from simple embedded systems to complex, worldwide information systems.

It is pointless to look for universal notations, methods, or techniques for software engineering because different types of software require different approaches.

All of these applications need software engineering; they do not all need the same software engineering techniques.

Without software engineering, we would not have explored space, would not have the Internet or modern telecommuni-cations.

9

1.1 Professional Software Development [Som]

Software engineering is intended to support professional software development, rather than individual programming.

It includes techniques that support program specification, design, and evolution.

Many people think that software is simply another word for computer programs.

However, when we are talking about software engineering, software is not just the programs themselves but also all as-sociated documentation and configuration data that is re-quired to make these programs operate correctly.

A professionally developed software system is often more than a single pro-gram. The system usually consists of a number of separate programs and con-figuration files that are used to set up these programs.

It may include system documentation, which describes the structure of the sys-tem; user documentation, which explains how to use the system, and websites for users to download recent product information.

10

1.1 Professional Software Development [Som]

This is one of the important differences between professional and amateur software development.

If you are writing a program for yourself, no one else will use it and you don’t have to worry about writing program guides, documenting the program design, etc.

If you are writing software that other people will use and other engineers will change then you usually have to provide additional information as well as the code of the program.

When we talk about the quality of professional software, we have to take into account that the software is used and changed by people apart from its developers.

Quality is therefore not just concerned with what the software does. Rather, it has to include the software’s behavior while it is executing and the structure and organization of the system programs and associated documentation.

11

1.1.1 Software Engineering [Som]

The systematic approach that is used in software engineer-ing is sometimes called a software process.

A software process is a sequence of activities that leads to the production of a software product.

There are four fundamental activities that are common to all software pro-cesses.

1. Software specification, where customers and engineers define the software that is to be produced and the constraints on its operation.

2. Software development, where the software is designed and programmed.

3. Software validation, where the software is checked to ensure that it is what the customer requires.

4. Software evolution, where the software is modified to reflect changing cus-tomer and market requirements.

SE is a set of techniques for the software process to improve the software quality.

12

13

1.2 What is Software Engineering?

1) SE is a modeling activity.SW engineers deal with complexity through modeling, by focusing at any one time on only the relevant details and ignoring everything else.

2) SE is a problem-solving activity.Models are used to search for an acceptable solution.

SW engineers do not have infinite resources and are constrained by budget and deadline.

3) Knowledge acquisition activity.In modeling the application and solution, SW engineers collect data, organize it into information, and formalize it into knowledge.

4) Rationale-driven activity.When acquiring knowledge and making decisions about the system, SW engi-neers also need to capture the rationale behind these decisions.

Rationale information enables SW engineers to understand the implication of a proposed change when revising a decision.

14

1.2.1 Modeling

The purpose of science isto describe and understand complex systems, such as a system of atom, a soci-ety of human beings, or a solar system.

One of the basic methods of science is modeling.A model is an abstract representation of a system that enables us to answer questions about the system.

abstract: a brief statement of the main points

to take out or remove something

15

1.2.2. Problem solving

Engineering is a problem-solving activity.Engineer search for an appropriate solution, often by trial and error, evaluating alternatives empirically, with limited resources and incomplete knowledge.

In its simplest form, the engineering methods five steps:1. Formulate the problem

2. Analyze the problem

3. Search for solutions

4. Decide on the appropriate solution

5. Specify the solution

Object-oriented SW development typically includes:1. Requirements elicitation

2. Analysis

3. System design

4. Object design

5. Implementation

6. Testing16

1.2.3 Knowledge Acquisition

Knowledge acquisition is a nonlinear process.The addition of a new piece of information may invalidate some of the knowl-edge we have acquired for the understanding of a system.

There are several SW processes that deal with this problem by avoiding the sequential dependencies inherent in the wa-terfall model.

Risk-based developmentattempts to anticipate surprises late in a project by identifying the high-risk components.

Issue-based developmentattempts to remove the linearity altogether.

All activities which can influence any other activity are executed in parallel.

17

1.2.4 Rationale

Developers make about a system change constantly.Design and implementation faults discovered during testing and usability prob-lem discovered during user evaluation trigger changes to the solution models.

Changes can also be caused by new technology.

To change the system, it is not enough to understand its cur-rent components and behavior.

It is also necessary to capture and understand the context in which each design decision was made.

This additional knowledge is called the rationale of the system.

Capturing and accessing the rationale is not trivial.For every decision made, several alternatives may have been considered, eval-uated, and argued.

Rationale information is often not explicit.Developers make many decisions based on their experience and intuition.

18

1.3 SE concepts

Projectwhose purpose is to develop a SW system

is composed of a number of Activities.

ActivityIt is performed toward a specific purpose.

E.g., requirement elicitation, analisys, delivery, management

is composed of a number of Tasks.

Taskrepresents an atomic unit of work that can be managed.

consumes Resources and produces a WorkProduct.

Resources are either Participants, Time, or Equipment.

A WorkProduct can be either a system, a model, or a document.

19

1.3 SE concepts

20

1.3.1 Participants and Roles

Developing a SW system requires the collaboration of many people with different backgrounds and interests.

TicketDistributor systemTD is a machine that distributes tickets for trains.

Travelers have the option of selecting a ticket for a single trip or for multiple trips, or selecting a time card for a day or a week.

TD computes the price of the requested ticket.

TD must be able to handle several exceptions.

21

22

1.3.2 Systems and Models

System: a collection of interconnected parts.

Modelingto deal with complexity by ignoring irrelevant details.

to refer to any abstraction of the system

TicketDistributoris a system.

Blueprints for the TD, schematics for its electrical wiring, and object models of its SW are models of TD.

1.3.3 Work ProductsAn artifact is produced during the development, such as a document or a piece of SW for other developers or for the client.

Internal work product vs. Deliverable

1.3.5 Functional and Nonfunctional RequirementsSpecification of a function that the system must support

Constraint on the operation of the system that is not related directly to a func-tion of the system.

23

1.4 SE Development Activities

24

25

1.4.1 Requirement Elicitation

Client and developers define the purpose of the system.

The result of this activity is a description of the system in terms of actors and use cases.

Actors represent the external entities that interact with the system. E.g., end users, other computers and environment.

Use cases are general sequences of events that describe all the possible ac-tions between an actor and the system for a given piece of functionality.

26

1.4.1 Requirement Elicitation

27

1.4.2 Analysis

Developers aim to produce a model of system that is correct, complete, consistent, and unambiguous.

Developers transform the use cases produced during requirements elicitation into an object model that completely describes the system.

Developers discover ambiguities and inconsistencies in the use case model that they resolve with the client.

The result of analysis is a system model described in terms of its structure and its dynamic interoperation.

Object model for TD

28

1.4.2 Analysis

29

1.4.3 System Design (Ch. 6 & 7)

Developers define the design goals of the project and de-compose the system into smaller subsystems that can be realized by individual teams.

Developers also select strategies for building the system, such as hardware/software platform on which the system will run.

The result of the system designClear description of each of these strategies, subsystem decomposition, and a deployment diagram representing the HW/SW mapping of the system.

System decomposition

30

1.4.4 Object Design (Ch. 8 & 9)

Developers define solution domain objects to bridge the gap between the analysis model and the HW/SW platform de-fined during system design.

Precisely describing subsystems and subsystem interfaces, selecting off-the-shelf components, and so on.

The result of the object designDetail object model annotated with constraint and precise descriptions for each subsystem.

31

1.4.5 Implementation & 1.4.6 Testing

Developers translates the solution domain model into source code.

1.4.6 Testing

Developers find differences between the system and its models by executing the system with sample input data sets.

Unit testing

Integration testing

System testing

The goal of testingto discover as many faults as possible such that they can be repaired before the delivery of the system.

32

1.5 ARENA Case Study

A multi-user, Web-based system for organizing and conduct-ing tournament.

Game independentOrganizers can adapt a new game to ARENA game interface, upload it to the ARENA server, and immediately announce and conduct tournaments with player and spectators located anywhere on Internet.

Organizers can also define new tournament styles.

To recover their operational costs, organizers can also invite potential sponsors to display advertisement banners.

33

Problem Statement Fig 4.17 (P.188)

34

Due & Presentation: 3/27

Submission: se.kuim@g-mail.com

Problem statement (proposal)

1. ProblemCurrent situation

Motivation

35

Problem statement (proposal)

2. ObjectivesContribution/definition of the project

36

Problem statement (proposal)

3. Functional requirementsWho can use this system?

What does the system provide/do for each user?

37

Problem statement (proposal)

4. Nonfunctional requirements

5. Target environment

38