CS5103
Software Engineering
Lecture 01
Introduction and
Software Process Models
Course Instructor

Name:
Dr. Xiaoyin Wang (Sean)

Office:
NPB 3.208

Email:
xiaoyin.wang@utsa.edu

Experiences



2
Got my PhD from Peking University, China
Did my postdoc in UC Berkeley
Worked for Microsoft (.net project), and Ensighta (a startup
company at Berkeley with 7-8 people), sold last winter
UTSA CS5103
Introduce yourselves!
3
UTSA CS5103
Course Meetings, Web Pages, etc.

Course Meetings:
TR 6:00pm – 7:15pm
NPB 1.226

Office Hours:
TR. 2:00pm - 3:30pm

4
Course Web Page:
http://xywang.100871.net/CS5103.htm
UTSA CS5103
Course Textbooks

One of the following Software Engineering books



5
Ian Sommerville, “Software Engineering”, 8th Edition,
Addison-Wesley, 2006. (Or 9th Edition, Or 7th Edition)
Pfleeger and Atlee, “Software Engineering: Theory and
Practice”, 4th Edition, 2010, Prentice Hall, 2006.
Pressman, “Software Engineering: A Practitioner’s
approach”, 6th Edition, McGraw Hill, 2005. (Or 7th Edition )
UTSA CS5103
Course Topics
6

Software Development Process

Software Requirements Engineering

Unified Modeling Language

Architecture & Design Patterns

Implementation, coding styles, & tools

Software Testing & Debugging
UTSA CS5103
Grading Scheme

Mid-Term Exam: 20% * 2

Assignments: 20%


Reading technical articles and write synopsis

Reading research papers and present in class
Projects: 30%


7
Teamwork Software Project on the Android
Platform
Course participation and presentations: 10%
UTSA CS5103
More on the Course Project

Work in teams (4-5 people)

An Android project

Choose from a set of topics (posted later)


8
Specify and fulfill natural-language based
requirements
We will have several preparation classes for android
software development
UTSA CS5103
Now, let’s go to the real lecture …
9
UTSA CS5103
What is Software


10
Software is a collection of artifacts

Computer programs *

Data

Documents
Characteristics of software

Software is complex

Software evolves
UTSA CS5103
What makes quality software

Attributes of quality software

Dependability
availability, reliability, security, and safety

Efficiency
processing time, memory utilization, responsiveness,

Usability
appropriate user interface and adequate documentation

Maintainability
ease of change
11
UTSA CS5103
What is software engineering

[Software engineering is] the establishment and use of sound
engineering principles in order to obtain economically
software that is reliable and works efficiently on real
machines
by Prof. Fritz Bauer at the 1968 NATO conference on software technology,
in Garmisch, Germany.


In short, software engineering is about developing quality
software in a productive way.
Key phrases:

12
Quality, Productivity
UTSA CS5103
Software Engineering
vs. Civil Engineering

Similarities





13
Size matters
Teamwork with careful planning
Leverage components
Penalties for failures
Sharing terms: building, architecture, components, …
UTSA CS5103
Software Engineering
vs. Civil Engineering

Much Harder to predict the behavior of the product

Physics laws guide civil engineering, no such laws for software

Software systems are more complex (incomputable)


Need to consider the evolution of software


14
Complex features so that user behaviors are unpredictable
Consider a bridge vs. a notepad program (edit, find/replace,
open, save, …)
Software is easier to change
But it is still expensive to change
UTSA CS5103
The Facts



15
Only 32% of software projects are considered
successful (full featured, on time, on budget)
$63 billion spent on failed projects in the US
Blame can be partly passed to:
 The engineer
 The manager
 The customers
UTSA CS5103
Engineer’s fault

Let’s write the code, so that we will be done sooner



I have to finish it to assess its quality



16
Writing code sooner may cause it take longer to finish
80% of effort is spent after the first delivery of code
Design reviews help to find severe design defects
Good coding style leads to fewer bugs
Static checker and unit testing help to find bugs earlier
UTSA CS5103
Engineer’s fault

There is no time for software engineering
 It will take you more time without software
engineering



17
Misunderstood requirements (may need to redo the whole
thing)
Comprehensive design / code changes for feature changes
Bug fixes
UTSA CS5103
When to do Software Engineering

Consider the following cases:

Write a text format changer for one-time usage


Write a personal utility library



(+requirement collection, + usage documentation)
Collaborate on a small project with several people
 (+modeling, +API documentation, +comments, +version control)
Work on a large project in a large company

18
(+design for potential change, +testing)
Write a notepad program to share online


(nothing)
(+design documentation, +coding style, +code review, +static
checker, +other regulations)
UTSA CS5103
Manager’s fault

We add more programmers if we are late


We can outsource it



19
Adding programmers to a late software, makes it later (The
mythical man-month, Fred Brooks)
If you do not manage it well inside, you cannot do it good
outside
Much more communications, more risk for requirement
misunderstanding
Impairs long-term maintenance
UTSA CS5103
Customer’s fault

We do not need to be involved in the project


Anyway, we can change the software later


20
Customers should be involved all the time to provide
requirements (requirement are always changing)
Yes
But the cost goes exponentially as time goes by
UTSA CS5103
Why learn software engineering



21
Software engineer is the most required jobs in the
IT field, and you maybe want to be a successful one
of them
Other related positions: requirement engineer, test
engineer, etc.
As long as you still write program, software
engineering will help you
UTSA CS5103
To Understand Software
Engineering

Software engineering is a discipline that integrates
 Process
provides a framework for software development

Methods
provide “how to’s” for building software

Tools
provide automated or semi-automated support for the
process and the methods
22
UTSA CS5103
Software Process Models


23
A process model describes:

What steps you go through

Which development artifacts are produced, and when

How activities are coordinated
Different process models

The waterfall model (today)

The prototyping model

The iterative model
UTSA CS5103
The Waterfall Model
Requirements
engineering
Design
Implementation
Integration
24
UTSA CS5103
Requirement Engineering

Figure out what the software is supposed to do…

Collection

Talking to users, customers, etc.

Note: customers != users

Sometimes people are not sure about what they want


25
Some requirements can cost too much (but users do not
know, so involve developers also)
Including functional & non-functional requirements
UTSA CS5103
Requirement Engineering

26
Specification

A detailed document describes what the system does

Covers all situations

More precise than raw requirements collected

Can be formal or informal
UTSA CS5103
Design

The architecture

How to decompose the software

Define the interfaces between components
27
UTSA CS5103
Implementation

Code each module

Sequence of implementing modules

28

Priority

Testability / Dependence
Unit Testing
UTSA CS5103
Integration

Put things together

Test the whole system
29
UTSA CS5103
Waterfall Model

A standard software process model

Testing or validation after each step

30
No iterations (some variants allow feedback between
steps)
UTSA CS5103
NASA Example

31
Each execution handles $4Billion equipments,
human lives, dreams

No prototypes

420k lines of code, 17 errors in 11 versions

Commercial equivalent would have 5000 bugs
UTSA CS5103
NASA Example

A third of the effort before coding starts

Long specifications, written down, fully discussed
32

40k pages of specification (longer than the code)

Change to add GPS support (2500 pages more specification)

Specification is almost pseudo code
UTSA CS5103
NASA Example


When fixing bugs, fix what allowed the mistake

Unclear API

Insufficient tests

Improper use of tools
Validation and review at all levels

33
85% of bugs revealed before testing
UTSA CS5103
NASA Example

Cost

260 people

$32 million

A year

TOO EXPENSIVE!!!

Overkill for normal software
34
UTSA CS5103
In practice

Maybe adopted from civil engineering

Very little software is built with waterfall

What are the main risks?

Where it is most / least applicable?
35
UTSA CS5103
Risks of waterfall





36
Relies on precise and stable requirements
Users cannot involve much (specifications are difficult to
understand)
Takes too long to finish
Small errors (or requirement changes) at the beginning
steps are unaffordable
Suitable: projects for specific task, no competition,
enough resources
UTSA CS5103
Good things of waterfall


37
Defines all the basic activities for a software process
Emphasis on documents and specifications to support
high-quality software
UTSA CS5103
Next Class

More Software Process Models …




Pre-course quiz on android development



38
The prototype model
The iterative model
Extreme programming
Bring your pen with you
Will not affect your grades
Better do some preparations if not familiar with
android at all
(http://developer.android.com/training/index.html )
UTSA CS5103
Thanks! Hope you will enjoy the course!
More on the Course Project (Phase I)

Do everything in Phase I:

Requirement

Design

Implementation

Documentation

Testing

Deadlines on each step

Demo and Presentation
40
UTSA CS5103
More on the Course Project (Phase II)

41
Adaptation for Feature Change

Announced after phase I

Software refactoring to accommodate the change

Regression Testing

Write a change report for main design changes
UTSA CS5103
More on the Course Project (Evaluation)

42
Deliverables

Use case diagrams

Class diagrams

Code and binary files

Documentations (design / API documents)

Test cases

Revised code & binary, change report (Phase II)
UTSA CS5103
More on the Course Project
(Evaluation)

Teamwork Evaluation



43
Reports on the division of work (each team member
should submit one, describing his/her own work)
Email records (Please choose related ones, anonymize
you email account if you want, but let me know which
email is sent by whom)
submit at the due time of project phase II
UTSA CS5103