1 / 43

CS5103 Software Engineering

CS5103 Software Engineering. Lecture 01 Introduction and Software Process Models. 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

darin
Download Presentation

CS5103 Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS5103Software Engineering Lecture 01 Introduction and Software Process Models

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

  3. Introduce yourselves! 3 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 4 UTSA CS5103

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

  6. Course Topics 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 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% 7 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 8 UTSA CS5103

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

  10. What is Software 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 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 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 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 Requirements engineering Design Implementation Integration 24 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 25 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 26 UTSA CS5103

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

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

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

  30. A standard software process model Testing or validation after each step No iterations (some variants allow feedback between steps) Waterfall Model 30 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 31 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 32 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 33 UTSA CS5103

  34. Cost 260 people $32 million A year TOO EXPENSIVE!!! Overkill for normal software NASA Example 34 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 35 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 36 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 37 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 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

  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

  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

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

More Related