1. Software Engineering
Spring, 2014

2. Class information Instructor
Prof. Wonhong Nam
Office: New Millennium Building 1301
Tel:
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 week
Students are expected to study 6-9 hours in a week.
Secondary: Software Engineering 9, Sommerville, Pearson.
Course web page
Grade: 10% attendance, 60% project, 30% final exam.
Each team consists of 4 students.
Send an for your team on 3/7.

3. 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 participants 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%.

4. Preface: US NAS US National Airspace System (NAS) Complex systems
monitors and controls air traffic in US, and it includes more than 18,300 airports, 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.
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.

5. Preface [Som]
The name ‘software engineering’ was proposed in 1969 at a NATO conference to discuss software development problems—
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, communications, and transport—all rely on complex and mostly reliable computer systems.
Humanity is now faced with a new set of challenges
climate change and extreme weather, declining natural resources, an increasing 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 problems and, for sure, software will play a central role in these technologies.

6. Ch. 1. Intro to Software Engineering (SE)
The term SE was coined in 1969
as 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 resources necessary to attain those objectives, and manage the customers’ expectations.
The emphasis in SE is on both words, software and engineering.

7. 1.1 Software (Engineering) Failures
Year 1900 bug
In 1992, Mary from Minnesota, received an invitation to attend a kindergarten. Mary was 104 at the time.
Interface misuse
In 1990, in London, an underground train left the station without its driver.
Late and over budget
In 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 delivery
After 18 months of development, a $200-millon system was delivered to a health insurance company in WI in However, the system did not work correctly: $60 million in overpayments were issued. The system took 3 years to fix.

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

9. 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 telecommunications.

10. 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 associated documentation and configuration data that is required to make these programs operate correctly.
A professionally developed software system is often more than a single program. The system usually consists of a number of separate programs and configuration files that are used to set up these programs.
It may include system documentation, which describes the structure of the system; user documentation, which explains how to use the system, and websites for users to download recent product information.

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

12. 1.1.1 Software Engineering [Som]
The systematic approach that is used in software engineering 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 processes.
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 customer and market requirements.
SE is a set of techniques for the software process to improve the software quality.

14. 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 engineers 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.

15. 1.2.1 Modeling The purpose of science is
to describe and understand complex systems, such as a system of atom, a society 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

16. 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. Testing

17. 1.2.3 Knowledge Acquisition
Knowledge acquisition is a nonlinear process.
The addition of a new piece of information may invalidate some of the knowledge 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 waterfall model.
Risk-based development
attempts to anticipate surprises late in a project by identifying the high-risk components.
Issue-based development
attempts to remove the linearity altogether.
All activities which can influence any other activity are executed in parallel.

18. 1.2.4 Rationale Developers make about a system change constantly.
Design and implementation faults discovered during testing and usability problem 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 current 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, evaluated, and argued.
Rationale information is often not explicit.
Developers make many decisions based on their experience and intuition.

19. 1.3 SE concepts Project Activity Task
whose purpose is to develop a SW system
is composed of a number of Activities.
Activity
It is performed toward a specific purpose.
E.g., requirement elicitation, analisys, delivery, management
is composed of a number of Tasks.
Task
represents 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.

20. 1.3 SE concepts

21. 1.3.1 Participants and Roles
Developing a SW system requires the collaboration of many people with different backgrounds and interests.
TicketDistributor system
TD 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.

23. 1.3.2 Systems and Models System: a collection of interconnected parts.
Modeling
to deal with complexity by ignoring irrelevant details.
to refer to any abstraction of the system
TicketDistributor
is 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 Products
An 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 Requirements
Specification of a function that the system must support
Constraint on the operation of the system that is not related directly to a function of the system.

24. 1.4 SE Development Activities

26. 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 actions between an actor and the system for a given piece of functionality.

27. 1.4.1 Requirement Elicitation

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

29. 1.4.2 Analysis

30. 1.4.3 System Design (Ch. 6 & 7)
Developers define the design goals of the project and decompose 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 design
Clear description of each of these strategies, subsystem decomposition, and a deployment diagram representing the HW/SW mapping of the system.
System decomposition

31. 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 defined during system design.
Precisely describing subsystems and subsystem interfaces, selecting off-the-shelf components, and so on.
The result of the object design
Detail object model annotated with constraint and precise descriptions for each subsystem.

32. 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 testing
to discover as many faults as possible such that they can be repaired before the delivery of the system.

33. 1.5 ARENA Case Study
A multi-user, Web-based system for organizing and conducting tournament.
Game independent
Organizers 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.

34. Problem Statement Fig 4.17 (P.188)
Due & Presentation: 3/27
Submission:

35. Problem statement (proposal)
Current situation
Motivation

36. Problem statement (proposal)
2. Objectives
Contribution/definition of the project

37. Problem statement (proposal)
3. Functional requirements
Who can use this system?
What does the system provide/do for each user?

38. Problem statement (proposal)
4. Nonfunctional requirements
5. Target environment