UTSA CS51032
Course Instructor
Name:Dr. Xiaoyin Wang (Sean)
Office: FLN 4.01.58
Email: [email protected]
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 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 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 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 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
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
Top Related