CS5103 Software Engineering Lecture 01 Introduction and Software Process Models

UTSA CS Course Instructor  Name: Dr. Xiaoyin Wang (Sean)  Office: FLN   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 CS Introduce yourselves!

UTSA CS Course Meetings, Web Pages, etc.  Course Meetings: TR 6:00pm – 7:15pm FLN  Office Hours: TR. 3:00pm - 4:30pm  Course Web Page:

UTSA CS Course Textbooks  One of the following Software Engineering books Ian Sommerville, “Software Engineering”, 8 th Edition, Addison-Wesley, (Or 9 th Edition, Or 7 th Edition) Pfleeger and Atlee, “Software Engineering: Theory and Practice”, 4 th Edition, 2010, Prentice Hall, Pressman, “Software Engineering: A Practitioner’s approach”, 6 th Edition, McGraw Hill, (Or 7 th Edition )

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

UTSA CS 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 CS 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 CS Now, let’s go to the real lecture …

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

UTSA CS 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 CS 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 CS Software Engineering vs. Civil Engineering  Similarities  Size matters  Teamwork with careful planning  Leverage components  Penalties for failures  Sharing terms: building, architecture, components, …

UTSA CS 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 CS 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 CS 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 CS 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 CS 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 CS 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 CS 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 CS 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 CS 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 CS 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 CS The Waterfall Model Design Implementation Integration Requirements engineering

UTSA CS  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 CS  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 CS  The architecture  How to decompose the software  Define the interfaces between components Design

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

UTSA CS  Put things together  Test the whole system Integration

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

UTSA CS  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 CS  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 CS  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 CS  Cost  260 people  $32 million  A year  TOO EXPENSIVE!!!  Overkill for normal software NASA Example

UTSA CS  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 CS  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 CS  Defines all the basic activities for a software process  Emphasis on documents and specifications to support high-quality software Good things of waterfall

UTSA CS  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 ( ) Next Class

Thanks! Hope you will enjoy the course!

UTSA CS 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 CS 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 CS 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 CS 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