1. CS5103 Software Engineering
Lecture 01
Introduction and
Software Process Models

2. Course Instructor 2 Name: Office: Email: Experiences
Dr. Xiaoyin Wang (Sean)
Office:
NPB 3.208
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
        2
UTSA CS5103

3. Introduce yourselves! 3
UTSA CS5103

4. Course Meetings, Web Pages, etc.
Course Meetings: TR 6:00pm – 7:15pm
NPB 1.226
Office Hours:
TR. 2:00pm - 3:30pm
Course Web Page:         4
UTSA CS5103

5. Course Textbooks 5 One of the following Software Engineering books
Ian Sommerville, “Software Engineering”, 8th Edition, Addison-Wesley, (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, (Or 7th Edition ) 5
UTSA CS5103 5

6. Course Topics 6 Software Development Process
Software Requirements Engineering
Unified Modeling Language
Architecture & Design Patterns
Implementation, coding styles, & tools
Software Testing & Debugging 6
UTSA CS5103

7. Grading Scheme Mid-Term Exam: 20% * 2 Assignments: 20% Projects: 30%
Reading technical articles and write synopsis
Reading research papers and present in class
Projects: 30%
Teamwork Software Project on the Android Platform
Course participation and presentations: 10% 7
UTSA CS5103 7

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 8
UTSA CS5103 8

9. Now, let’s go to the real lecture …9
UTSA CS5103 9

10. What is Software 10 Software is a collection of artifacts
Computer programs *
Data
Documents
Characteristics of software
Software is complex
Software evolves 10
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 11
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 12
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, … 13
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 14
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 15
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 16
UTSA CS5103

17. Engineer’s fault 17 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 17
UTSA CS5103

18. 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) 18
UTSA CS5103

19. Manager’s fault 19 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 19
UTSA CS5103

20. Customer’s fault 20 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 20
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 21
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 22
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 23
UTSA CS5103

24. The Waterfall Model 24 Requirements engineering Design Implementation
Integration 24
UTSA CS5103

25. 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
Some requirements can cost too much (but users do not know, so involve developers also)
Including functional & non-functional requirements 25
UTSA CS5103

26. Requirement Engineering
Specification
A detailed document describes what the system does
Covers all situations
More precise than raw requirements collected
Can be formal or informal 26
UTSA CS5103

27. Design 27 The architecture How to decompose the software
Define the interfaces between components 27
UTSA CS5103

28. Implementation 28 Code each module Sequence of implementing modules
Priority
Testability / Dependence
Unit Testing 28
UTSA CS5103

29. Integration
Put things together
Test the whole system 29
UTSA CS5103

30. Waterfall Model 30 A standard software process model
Testing or validation after each step
No iterations (some variants allow feedback between steps) 30
UTSA CS5103

31. NASA Example
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 31
UTSA CS5103

32. NASA Example 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 32
UTSA CS5103

33. NASA Example 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 33
UTSA CS5103

34. NASA Example 34 Cost TOO EXPENSIVE!!! Overkill for normal software
260 people
$32 million
A year
TOO EXPENSIVE!!!
Overkill for normal software 34
UTSA CS5103

35. In practice 35 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

36. 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 36
UTSA CS5103

37. Good things of waterfall
Defines all the basic activities for a software process
Emphasis on documents and specifications to support high-quality software 37
UTSA CS5103

38. Next Class 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 ( ) 38
UTSA CS5103

39. Thanks! Hope you will enjoy the course!

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 40
UTSA CS5103 40

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 41
UTSA CS5103 41

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) 42
UTSA CS5103 42

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)
records (Please choose related ones, anonymize you account if you want, but let me know which is sent by whom)
submit at the due time of project phase II 43
UTSA CS5103 43