CS5103Software

Engineering

Lecture 01Introduction and

Software Process Models

UTSA CS51032

Course Instructor     

Name:Dr. Xiaoyin Wang (Sean)

Office: FLN 4.01.58

Email: xiaoyin.wang@utsa.edu

Experiences Got my PhD from Peking University, China Did my postdoc in UC Berkeley Worked for Microsoft (.net project), and Ensighta (a startup comp

any at Berkeley with 7-8 people), sold last winter       

UTSA CS51033

Introduce yourselves!

UTSA CS51034

Course Meetings, Web Pages, etc.       

Course Meetings: TR 6:00pm – 7:15pm

FLN 3.02.07

Office Hours:

TR. 3:00pm - 4:30pm

Course Web Page: http://xywang.100871.net/CS5103.htm       

UTSA CS51035

Course Textbooks      

One of the following Software Engineering books Ian Sommerville, “Software Engineering”, 8th Edition, Addi

son-Wesley, 2006. (Or 9th Edition, Or 7th Edition) Pfleeger and Atlee, “Software Engineering: Theory and Pra

ctice”, 4th Edition, 2010, Prentice Hall, 2006. Pressman, “Software Engineering: A Practitioner’s appro

ach”, 6th Edition, McGraw Hill, 2005. (Or 7th Edition )

UTSA CS51036

Course Topics       

Software Development Process Software Requirements Engineering Unified Modeling Language Architecture & Design Patterns Implementation, coding styles, & tools Software Testing & Debugging

UTSA CS51037

Grading Scheme       

Final Exam: 30% Assignments: 20%

Reading technical articles and write synopsis Reading research papers and present in class

Projects: 40% Phase I: Teamwork Software Project Phase II: Coping with Feature Change Requests

Course participation and presentations: 10%

UTSA CS51038

More on the Course Project

Work in teams (4-5 people) An Android project

Choose from a set of topics (posted later) Specify and fulfill natural-language based

requirements

We will have several preparation classes for android software development

UTSA CS51039

Now, let’s go to the real lecture …

UTSA CS510310

What is Software       

Software is a collection of artifacts Computer programs *

Data

Documents

Characteristics of software Software is complex

Software evolves

UTSA CS510311

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

UTSA CS510312

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 machinesby 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: Quality, Productivity

UTSA CS510313

Software Engineering vs. Civil Engineering

Similarities Size matters Teamwork with careful planning Leverage components Penalties for failures Sharing terms: building, architecture, components,

…

UTSA CS510314

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)

Complex features so that user behaviors are unpredictableConsider a bridge vs. a notepad program (edit,

find/replace, open, save, …)

Need to consider the evolution of software Software is easier to change But it is still expensive to change

UTSA CS510315

The Facts

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 CS510316

Engineer’s fault

Let’s write the code, so that we will be done sooner Writing code sooner may cause it take longer to

finish 80% of effort is spent after the first delivery of code

I have to finish it to assess its quality 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 CS510317

Engineer’s fault

There is no time for software engineering It will take you more time without software

engineering Misunderstood requirements (may need to redo the

whole thing) Comprehensive design / code changes for feature

changes Bug fixes

UTSA CS510318

When to do Software Engineering       

Consider the following cases: Write a text format changer for one-time usage

(nothing) Write a personal utility library

(+design for potential change, +testing) Write a notepad program to share online

(+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 (+design documentation, +coding style, +code review,

+static checker, +other regulations)

UTSA CS510319

Manager’s fault

We add more programmers if we are late Adding programmers to a late software, makes it later

(The mythical man-month, Fred Brooks)

We can outsource it 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 CS510320

Customer’s fault

We do not need to be involved in the project Customers should be involved all the time to

provide requirements (requirement are always changing)

Anyway, we can change the software later Yes But the cost goes exponentially as time goes by

UTSA CS510321

Why learn software engineering 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 CS510322

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

UTSA CS510323

Software Process Models      

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 CS510324

The Waterfall Model     

Design

Implementation

Integration

Requirementsengineering

UTSA CS510325

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

Some requirements can cost too much (but users do not know, so involve developers also)

Including functional & non-functional requirements

Requirement Engineering

UTSA CS510326

Specification A detailed document describes what the system does Covers all situations More precise than raw requirements collected Can be formal or informal

Requirement Engineering

UTSA CS510327

The architecture

How to decompose the software

Define the interfaces between components

Design

UTSA CS510328

Code each module

Sequence of implementing modules Priority

Testability / Dependence

Unit Testing

Implementation

UTSA CS510329

Put things together

Test the whole system

Integration

UTSA CS510330

A standard software process model

Testing or validation after each step

No iterations (some variants allow feedback between steps)

Waterfall Model

UTSA CS510331

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

NASA Example

UTSA CS510332

A third of the effort before coding starts

Long specifications, written down, fully discussed 40k pages of specification (longer than the code)

Change to add GPS support (2500 pages more specification)

Specification is almost pseudo code

NASA Example

UTSA CS510333

When fixing bugs, fix what allowed the mistake Unclear API

Insufficient tests

Improper use of tools

Validation and review at all levels 85% of bugs revealed before testing

NASA Example

UTSA CS510334

Cost 260 people

$32 million

A year

TOO EXPENSIVE!!!

Overkill for normal software

NASA Example

UTSA CS510335

Maybe adopted from civil engineering

Very little software is built with waterfall

What are the main risks?

Where it is most / least applicable?

In practice

UTSA CS510336

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

Risks of waterfall

UTSA CS510337

Defines all the basic activities for a software process

Emphasis on documents and specifications to support high-quality software

Good things of waterfall

UTSA CS510338

More Software Process Models … The prototype model The iterative model Extreme programming

Pre-course quiz on android development 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 )

Next Class

Thanks! Hope you will enjoy the course!

UTSA CS510340

More on the Course Project (Phase I)

Do everything in Phase I: Requirement Design Implementation Documentation Testing

Deadlines on each step

Demo and Presentation

UTSA CS510341

More on the Course Project (Phase II)

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 CS510342

More on the Course Project (Evaluation)

Deliverables Use case diagrams

Class diagrams

Code and binary files

Documentations (design / API documents)

Test cases

Revised code & binary, change report (Phase II)

UTSA CS510343

More on the Course Project (Evaluation)

Teamwork Evaluation Reports on the division of work (each team member sho

uld submit one, describing his/her own work) Email records (Please choose related ones, anonymize y

ou email account if you want, but let me know which email is sent by whom)

submit at the due time of project phase II