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

2. 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

3. UTSA CS5103 3 Introduce yourselves!

4. 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

5. 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 )

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

7. 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%

8. 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

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

10. UTSA CS5103 10 What is Software  Software is a collection of artifacts Computer programs * Data Documents  Characteristics of software Software is complex Software evolves

11. 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

12. 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

13. 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, …

14. 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

15. 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

16. 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

17. 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

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

19. 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

20. 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

21. 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

22. 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

23. 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

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

25. 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

26. 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

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

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

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

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

31. 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

32. 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

33. 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

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

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

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

37. 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

38. 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 ) http://developer.android.com/training/index.html Next Class

39. Thanks! Hope you will enjoy the course!

40. 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

41. 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

42. 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)

43. 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