CS4510: Software Engineering

1. CS4510: Software Engineering Laurie Williams Graduate Student

2. Course Objectives • To further your knowledge of process-based approaches to developing software for high-quality software products (xSP) • (1-person) Individual based (Personal Software Process) • (2-person) Collaborative team based (Collaborative Software Process) • (4-person) Team based (Team Software Process) • To gain further knowledge of important Software Engineering techniques • Your future employer will most likely follow A process which will consist of various combinations of what we will be learning . . . the main lesson here is that it is important to know how to follow a process.

3. Software Engineering Techniques • Object Oriented Software Engineering • Unified Modeling Language (UML) • Rational Rose tool • CRC Cards • Software Measurements • Design and Code Reviews   • Quality Management • Testing • Software Planning and Estimating • The Team Software Process (TSP) • NOTE: It is intended that the assignments will not be so big that you end up abandoning these new software engineering techniques “just to get done”

4. Grade Distribution • (Visual C++) Programming Assignments (40%) • (Visual C++) Team Project (20%) • Midterm (20%) • Final (20%)

5. General Information • Prerequisites • Quarter sequence: CS354-CS355-CS356 OR • Semester course: CS3500 • Book / Materials • Required: “Adult” PSP Book “A Discipline for Software Engineering” • Required: “Introduction to the Team Software Process” • Arriving in a shrink-wrapped pack to the bookstore any day • Collaboration vs. Individual Work • Class will be curved according to groups, if need be. • The Institutional Review Board (IRB) has looked out for you! • Schedule • Tues. class in this classroom (EMCB 110) • Thurs. class in NT lab (EMCB 210) • (Mandatory) Free lab time to work on your assignments • (Mandatory) Two hours/week additional lab time . . .we’ll be working out schedule

6. It’s All About Motivation • WIIFY • A teacher who’s research is your class and will work to make everything just right. • Experience with leading edge software development techniques • Get to do 1 ½ hour’s worth of homework on class time • A guaranteed computer in the lab (for two hours) when you get there • WIIFM • Graduation . . . so I can finally be a “real professor” and teach people like you for the rest of my life

7. Tidbits/Standard Stuff • Development Language/Environment: Visual C++ • Class web page: • http://www2.cs.utah.edu/classes/cs4510 • Class lecture notes linked off the web • Will be there by noon (hopefully 10AM) day of class for you to print • Class mailing list: • subscribe to cs4510 • (majordomo@cs) • Class/lecture philosophy (borrowed from medical school): • “See one, do one, teach one” • My Office Hours TBD • TA (Tao Hu) Office Hours TBD

8. Today’s Lecture • A “Process” Perspective • GQM Paradigm • Analysis: Use Cases

9. Process and Profession Dennis J. Frailey

10. What Do These Words Mean? Order Safety Responsibility Organization Consistency Reliability Regulation Loss of Creativity Meddling “Police” Doom and Gloom End of the World PROCESS PROFESSION

11. Who Cares! The Way it Was Software Developers The Public Protective Cloak of Technology and Nerdliness

12. My pacemaker has a computer! Who should we sue for this fiasco? Why does this software crash all the time? The Way it Is Becoming

13. Software Engineering Black Art Profession

14. Good Things I Have Seen with Process Focus • More Accurate Estimates • Software that does Not Crash (at least not often :-) • Higher Productivity …

15. Bad Things I Have Seen with Process Focus • Overly Prescriptive Interpretations • People wanting a Cookbook instead of a Model • Dehumanization of Software Development • Process Blamed because it is not a “Silver Bullet” ... • Employees Leaving because they Don’t Like the Climate (i.e. dropping the class)

16. Proper Use of Process(and Professionalism) • Education and Understanding are the Keys to Effective and Proper Use • True professionals in any field always have good processes and practices • Even if they don’t use that terminology • They know how to make effective use of good processes and practices • And they know when the processes and practices do not apply

17. “Take Aways” • We need to be professionals • We need to follow a process • Could be PSP, CSP . . . or whatever • Alternative: Ad hoc (Black Art) • Need to understand the process enough to know when it it is prudent to apply and when it is not • Programmer • Management

18. when it it is prudent to apply and when it is not . . . • “I know I should be doing a more thorough design but I really don’t feel like it.” • “I’ve been programming for years now, and I forgot one silly semicolon. It’s really not worth the time to record this defect.” • “Note that any predefined process must be an approximation, so some of the exercises in this book may be more helpful to you than others. After you have practiced them all, you will be able to decide which to use and when. Apply the PSP principles where you feel they will help.” • It is a PERSONAL software process . . . It presents many useful techniques, try them and then do what works for you

22. Goal - Question - Metric (GQM) Paradigm • Define the principle goals for your activity • Construct a comprehensive set of questions to help you achieve these goals • Define and gather the data required to answer these questions

23. Goals Motivation!! It’s ALL about GOAL WIIFM What’s standing in your way / What do you need to do to achieve this?How will you know when you accomplished this?

24. Question • Make “vague goals” more concrete • For each process goal, where did I start, where am I going now, and where do I want to go? • How fast can I run now? How fast do I want to run? • What is important about this goal? • WIIFM? • What the best that has been achieved against this goal?

25. Metrics • To explicitly and efficiently answer the questions (which relate to the goals) • Data gathering takes time . . . It’s all about motivation! • The data can effect your performance • “Hawthorne effect” whereby behavior changes depending on what is measured • Best if these software measurements can be personal • In this class, your grade WON’T be based on how fast you code or how many defects you have (as long as you remove them!!) • All I really care about is that you are entering data accurately so that you can learn the lessons of the class • Ideally, this will be the case in industry too

26. A GQM Example • Goal: To produce programs that contain no defects • Question: How can you produce software of such quality that no defects will be found later in test? • Metrics: • No way to GUARANTEE that you have produced an error-free product. • With sufficient data and a suitably controlled process you can improve the likelihood that your program is error-free • Define a strategy for deciding when a program is of high enough quality to be released, if it should be reappraised, or if it should be scrapped and re-engineered . . . Garbage In, Garbage Out (GIGO) • # of defects removed in Code Review • # of defects in test

27. See One Do One Teach One

28. Planning, estimation, organization, process, management, ... System engineering Analysis Design Coding Testing Maintenance Configuration control, metrics, defect tracking, reuse, documentation, ... Object Oriented Software Engineering:Requirements Analysis “How to figure out what it is that you should be doing, before you start doing what it is that you should be doing.”

29. Goals of Performing Analysis • To understand the problem or problems that the eventual software system should solve • To prompt relevant questions about the problem and the system • To provide a basis for answering questions about specific properties of the problem and system • To decide what the system should do • To decide what the system should not do • To ascertain that the system will satisfy the needs of its users, and define acceptance criteria • To provide a basis for the development of the system

30. Visual Modeling(from Terry Quatrani: Visual Modeling with Rational Rose and UML) • A way of thinking about problems using models organized around real-world ideas • We can visualize them in our head • To promote a better understanding of requirements, cleaner designs, and more maintainable systems • We build models because we cannot comprehend such systems in their entirety • Focus on the big picture of how a project’s components interact • Without getting bogged down in the specific details of each component

31. The Triangle for Success Notation: Unified Modeling Language (UML) Process: PSP/CSP/TSP Tool: Rational Rose

32. External System Behavior: Use Case Model • Complete course of events in the system, from the user’s perspective • Use Cases Model: Illustrates • (use cases) the system’s intended functions • (actors) surroundings – external to the system • (use case diagrams) relationships between use cases and actors • Use Case Model is an important communication vehicle between customers (they can understand it!) and developers • The collection of all use cases is everything that can be done to/with the system

33. Actors • Are NOT part of the system – they represent anyone or anything that must interact with the system • Only input information to the system • Only receive information from the system • Both input to and receive information from the system • Represented in UML as a stickman

34. A Case Study: Eastern State University (ESU) Registration Problem: Background • After professors decide which courses they will teach, the Registrar enters in info in the computer • A course catalog is printed and distributed to students • Students fill out form with their choices – usually 4 courses • Registrar enters this info into computer • A batch job is run overnight to assign students to courses • In cases of conflict where the students cannot take the classes they had selected, the registrar contacts the students directly to obtain additional choices. • Once all students have successfully assigned to courses, a hardcopy of the schedule is sent to the student. • Professors obtain student rosters for their classes.

35. Eastern State University (ESU) Registration Problem: Problem Statement • Professors indicate which courses they will teach on-line. • A course catalog is printed • Allow students to select on-line four courses (and two additional choices) for upcoming semester. • No course may have more than 10 students (this is not the U!) or less than 3 students. • When the registration is completed, the system sends information to the billing system. • Professors can obtain course rosters on-line. • Students can add or drop classes on-line. Who are the actors??

36. Use Case • A sequence of transactions performed by a system that yields a measurable result of values for a particular actor • What are the tasks of each actor? • Will any actor create, store, change, remove or read information in the system? • What use cases will create, store, change, remove or read this information? • Will any actor need to inform the system about sudden, external changes? • Does any actor need to be informed about certain occurrences in the system? • What use cases will support and maintain the system? • Can all functional requirements be preformed by the use cases? • A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor. What are the uses cases in the ESU Course Registration System??

37. Flow of Events for a Use Case • Description of the events needed to accomplish the required behavior of the use case. Written in terms of what the system should do, not how the system does it • When and how the use case starts and ends • What interaction the use case has with the actors • What data is needed by the use case • The normal sequence of events for the use case • The description of any alternative or exceptional flows • Done in an iterative manner. • First just the normal flow of the use case • More details • Exceptional flows added

38. Template for Flow of Events X Flow of Events for the <name> Use Case X.1 Preconditions X.2 Main Flow X.3 Subflows (if applicable) X.4 Alternative Flows Where X is a number from 1 to the number of use cases IMPORTANT: Be flexible – do what’s appropriate for the use case.

39. UML Relationships • Between Actor and Use Case • Association / Communication • Arrow can be in either or both directions • Arrow indicates who initiates communication • Between Use Cases (Generalization): • Uses • Where multiple use cases sharepieces of same functionality • Extends • Optional behavior • Behavior only run under certainconditions (such as alarm) • Several different flows run base onuser selection

40. Stereotypes • Provides the capability to extend the basic modeling elements to create new elements • Allows the UML to have a minimal set of symbols that may be extended where needed to provide the communication artifacts that have meaning for the system under development • Included within << >> and placed along the relationship line • << Communicates >> • << Extends >> • << Uses >> • Define your own . . .