CS5103 Software Engineering

wheatprisonMobile - Wireless

Dec 10, 2013 (3 years and 8 months ago)

133 views

CS5103

Software Engineering

Lecture 01

Introduction and

Software Process Models

UTSA CS5103

2

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
company at Berkeley with 7
-
8 people), sold last winter










UTSA CS5103

3

Introduce yourselves!

UTSA CS5103

4

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 CS5103

5

Course Textbooks








One of the following Software Engineering books


Ian Sommerville, “Software Engineering”, 8
th

Edition,
Addison
-
Wesley, 2006. (Or 9
th

Edition, Or 7
th

Edition)


Pfleeger and Atlee, “Software Engineering: Theory and
Practice”, 4
th

Edition, 2010, Prentice Hall, 2006.


Pressman, “Software Engineering: A Practitioner’s
approach”, 6
th

Edition, McGraw Hill, 2005. (Or 7
th

Edition )

UTSA CS5103

6

Course Topics









Software Development Process


Software Requirements Engineering


Unified Modeling Language


Architecture & Design Patterns


Implementation, coding styles, & tools


Software Testing & Debugging

UTSA CS5103

7

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 CS5103

8

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 CS5103

9

Now, let’s go to the real lecture …

UTSA CS5103

10

What is Software









Software is a collection of artifacts


Computer programs *


Data


Documents


Characteristics of software


Software is complex


Software evolves

UTSA CS5103

11

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 CS5103

12

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:


Quality, Productivity

UTSA CS5103

13

Software Engineering

vs. Civil Engineering


Similarities


Size matters


Teamwork with careful planning


Leverage components


Penalties for failures


Sharing terms: building, architecture, components, …


UTSA CS5103

14

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 unpredictable

Consider 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 CS5103

15

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 CS5103

16

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 CS5103

17

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 CS5103

18

When to 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 project with several people


(+API documentation, +comments, +version control)


Work on a large project in a large company


(+coding style, +code review, +static checker, +other
regulations)

UTSA CS5103

19

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 CS5103

20

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 CS5103

21

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 CS5103

22

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 CS5103

23

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 CS5103

24

The Waterfall Model






Design

Implementation

Integration

Requirements

engineering

UTSA CS5103

25


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 CS5103

26


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 CS5103

27


The architecture


How to decompose the software


Define the interfaces between components

Design

UTSA CS5103

28


Code each module


Sequence of implementing modules


Priority


Testability / Dependence


Unit Testing

Implementation

UTSA CS5103

29


Put things together


Test the whole system





Integration

UTSA CS5103

30


A standard software process model


Testing or validation after each step


No iterations (some variants allow feedback between
steps)

Waterfall Model

UTSA CS5103

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

NASA Example

UTSA CS5103

32


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 CS5103

33


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 CS5103

34


Cost


260 people


$32 million


A year



TOO EXPENSIVE!!!



Overkill for normal software

NASA Example

UTSA CS5103

35


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 CS5103

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

Risks of waterfall

UTSA CS5103

37


Defines all the basic activities for a software process



Emphasis on documents and specifications to support
high
-
quality software


Good things of waterfall

UTSA CS5103

38


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 CS5103

40

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 CS5103

41

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 CS5103

42

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 CS5103

43

More on the Course Project

(Evaluation)


Teamwork Evaluation


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