CS 594 Software Engineering

1. CS 594Software Engineering Lecture 1 - 1/24/2000 Dr. Thomas E. Potok potokte@ornl.gov 865-574-0834 T. E. Potok - University of Tennessee

2. Agenda • Class introduction • Why study software engineering • History • Evolving structure • Requirements T. E. Potok - University of Tennessee

3. Who are you? Setup Volunteer?? T. E. Potok - University of Tennessee

4. Class Overview T. E. Potok - University of Tennessee

5. Course Description • Overview of practical and theoretical software engineering techniques and approaches • 2 Small Projects • Class formed into groups • Define requirements, design, prototype code • Simulate industrial software development • 1/2 hour of each class on project • Texts: • R. S. Pressman, Software Engineering: A Practitioner’s Approach, Fourth Edition, McGraw-Hill, 1997 • R. L. Glass, Software Runaways, Prentice Hall, 1998. • Assigned papers T. E. Potok - University of Tennessee

6. Course overview • Requirements Gathering and Analysis (1 week) • Project size estimation (3 weeks) • Planning (5 weeks) • Team interaction (2 weeks) • Methodology (3 weeks) • Runaway Projects (2 weeks) T. E. Potok - University of Tennessee

7. Tests and Grading • Tests and Grading • Mid-term exam 30% • Final exam 30% • Homework (including projects) 40% • Last year roughly 30% of the class made an A, the rest received a B. • Office Hours • 1 hour before/after class by appointment • Email or phone calls are fine T. E. Potok - University of Tennessee

8. Class format • Professional conduct • Class starts and ends on time • Contact me if you are going to miss a class • I will most likely miss one or two classes • Schedule • 50 Minutes lecture - 10 Minute break • 50 Minute lecture - 10 Minute break • 10 minute Summary • 30 minutes project time • Guest • There will be several guests in the class, I expect them to be treated with the utmost respect T. E. Potok - University of Tennessee

9. Projects • The class will develop components of software to meet the needs of two real customers with hypothetical problems • Using the techniques learned in class • Working in groups • Simulating a realistic software development environment T. E. Potok - University of Tennessee

10. Why Study Software Engineering? T. E. Potok - University of Tennessee

11. Why study software development? • Just hire the best people you can, and let them go • Look at any successful project, and you will find that one key person who was willing to do what ever it takes to succeed. • You can document processes and techniques all day long, no one ever follows them. • “Software development is more of an art form than engineering”. T. E. Potok - University of Tennessee

12. Have programmers gotten better? • Do you think that the value added to a corporation by the typical software engineer has increased in the last 20 years? • If so, by how much? • Abdel-Hamid notes spending on application development tools has increased at a 19 percent annual growth rate or higher, • However, looking at the value that was added per software developer adjusted for inflation, shows no improvement in the past two decades [Abdel-Hamid (1996)]. T. E. Potok - University of Tennessee

13. Productivity Crunch • 70’s 3-5 year development cycles • 80’s 2-3 year development cycles • 90’s 12-18 months • 6 week feasibility studies are common • “Web year” 3 months • My two most recent software research projects were 4 months, and 9 months in duration T. E. Potok - University of Tennessee

14. High Stakes Development • IRS - Computerworld: IRS wastes $50 billion per year resulting from repeated failures to integrate its "stovepipe" computer systems. • Denver baggage claim system 16 months late, 2 Billion dollars over budget • Air traffic control... T. E. Potok - University of Tennessee

15. There has got to be a better way • Technology - Better tools and languages • Methodology - Structured analysis, Object-oriented, agent-oriented,... • People - Better trained, better paid (???) • Process - CMM, ISO 9000 • Better management - Focus on deliverables, not people T. E. Potok - University of Tennessee

16. What is software development? • Engineering? • Art? • Craft? • Science? T. E. Potok - University of Tennessee

17. Software Development • Art • For entertainment and enjoyment • Can make a statement • Creator extremely significant • One of a kind, unrepeatable • Engineering • Based on scientific foundation • Can be very creative and innovative • Process followed is significant (patents) • A repeatable process can be define, followed, and standardized T. E. Potok - University of Tennessee

18. Software Development • Craft • Mainly for function • Artistic features • Craftsman important • Elements are repeatable • Science • Mainly for discovery • Based on time honored method • Scientists reputation is very important • Discovery needs to be reproduced T. E. Potok - University of Tennessee

19. Why most software is not art • Think of two outstanding programmers, and two great artists, Picaso and Monet. • The programmers can both produce software to solve a problem, and it will not be obvious who wrote what. • The artists can paint a vase, it is clear who painted what • A program that works better than others will replace the competition. Obsolete software is useless. • A Picaso and a Monet are not replaceable. They gain value over time. • A group of skilled programmers can duplicate any software currently on the market given time and money • A skilled artist can duplicate a Picaso, or a Monet, to fool most experts, but it has little value. T. E. Potok - University of Tennessee

20. Software as craft • Similar to art, craft work is distinctive based on the talent of the craftsman • Handmade work is more valuable than machine made work • With software it is hard to tell who wrote what, or whether the code was hand crafted, or machine generated. • Are you interested in the credentials of the people who write the software you use? T. E. Potok - University of Tennessee

21. Computer “Science” • Scientist are interested in problems that have not been solved • They show a solution to a problem which is often little more than a prototype • Most software solves a problems that have been solved many times before • Software that is not industrial strength is of little value T. E. Potok - University of Tennessee

22. So Software Development is Engineering • What science underlies software development? • Mathematics? • Is standardization in progress? • Windows, HTML, Java… • Programmers seem more influenced by style than convention T. E. Potok - University of Tennessee

23. So who cares? • If software is art • The artist’s creatively is the key to producing software • If a craft • Learning is done through apprenticeships • Ability is more important than education • If software in engineering • There is a process to it that can be • Repeated, and can be • Improved over time T. E. Potok - University of Tennessee

24. Brief History of Software Engineering • Nato conference in 1968 • Software should follow an engineering paradigm • Brook’s Mythical Man Month • Experiences from the development of the IBM 360 operating system • Brook’s law T. E. Potok - University of Tennessee

25. The 60’s • Remember ‘2001 a Space Odyssey’? One large intelligent computer running a spaceship... • In the 60’s and 70’s software was written to solve some very basic problems, such as how to tell the computer to manage it’s own resources. • The trick in those days was to actually get the software working. • Computer time was scarce and the computers themselves were quite limited, however, there seemed to be no bounds on what a computer could do. T. E. Potok - University of Tennessee

26. Programming in the 70’s • Shift from mainframe computers to mini-computers. • A change in understanding what computer can really do. • The hardware gets faster, smaller, and cheaper, while the software becomes more complicated with less promise. • Software was written by elite, well trained, well paid programmers who worked for industry. • The most expensive part of developing software was now the programmer’s time, not the computer time. • Customers of this software were elated if you ignored only 90% of their requirements, and were a mere 6 months late T. E. Potok - University of Tennessee

27. Programming in the 80’s • The start of the personal computer revolution, PC on desk tops, and even in homes. • A college dropout could work in his garage with a clone PC developing and sell software. • Virtually anybody with a home computer could develop software in his or her garage or carport and sell it on the open market. • The trick was no longer merely to get it working, but now to make it useful and useable. • Software was now sold in stores for the average user. T. E. Potok - University of Tennessee

28. Programming in the 90s • Large and small powerful computers connected throughout the world that can communicate with each other. • Develop software faster, with more function, and cheaper than the competition. • Like in the old garage computing days, anyone can develop a software package, but now, they can do it anywhere in the world. • However, • there are not as many interesting problems to solve anymore. • Either they have been solved many times over, or no one can figure out how to solve them. T. E. Potok - University of Tennessee

29. Summary • The software development environment has changed quite a bit over the past 30 years. • Lessons learned in the 60’s and 70’s may be irrelevant to current software development, or they may be fundamental principles of creating software. • Without a yardstick to measure the results of such concepts, it is merely one opinion against another. T. E. Potok - University of Tennessee

30. Software Process Improvement T. E. Potok - University of Tennessee

31. History • Deming is legendary for advising the Japanese to focus on process to revolutionize their post-war manufacturing. • Japanese products out performed American products mainly due to quality and ability to meet customer needs • This approach was adopted by a variety of industries, and was seen as a way to revolutionize software development as well. • You define how you do something (a process), • Next, you repeat this process for every project that you develop • Then you measure and analyze the process, • Finally make any improvements necessary. • This should eventually improve the quality of the software produced and increasing the productivity of your programming teams. T. E. Potok - University of Tennessee

32. Why Process? • Management wants a forecast of how many widgets will be produced • How can this be accurately done without: • Knowing the steps required to make a widget • The machine capacity needed • The skills needed • The material needed • It can not be, therefore any forecast is little more than a random number T. E. Potok - University of Tennessee

33. Maximize output? • Once a process is understood, then what • Maximize process output? No • Maximize process consistency! • Is is better to consistently produce a widget in 8-16 days, or 5-20 days. • This consistency provides for greater control over the process. T. E. Potok - University of Tennessee

34. Variance Reduction What curve do you want your team to follow? T. E. Potok - University of Tennessee

35. SEI Capability Maturity Matrix • Broadly agree to define how a software organization matures and improves • Based on manufacturing process improvement and “best practices” from software engineering • Some dramatic successes... T. E. Potok - University of Tennessee

36. Capability Maturity Matrix • Developed by the Software Engineering Institute (SEI) by Watts Humphry and Mark Paulk. • Five levels of maturity for an organization • Level 1 - Initial; • Level 2 - Repeatable; • Level 3 - Defined; • Level 4 - Managed; • Level 5 - Optimizing. T. E. Potok - University of Tennessee

37. Initial • Poorly defined procedures and controls • No management mechanism to to ensure they are followed • Heroic efforts by one or two people saves the day. • Projects are late, crisis to crisis T. E. Potok - University of Tennessee

38. Repeatable • Basic project controls • Quality problems • No framework for orderly improvement • Fault data is being collected T. E. Potok - University of Tennessee

39. Defined • Commitment to software process evaluation and improvement • Appropriate software engineering standards and methods are in place • Strong qualitative understanding of the process T. E. Potok - University of Tennessee

40. Managed • Process is quantified • Quality and productivity measured for each key task • Wide dissemination of process related information • Errors can be predicted with acceptable accuracy T. E. Potok - University of Tennessee

41. Optimizing • Process improvement feed-back and feed-forward controls • Rigorous defect causal analysis and defect prevention • Proactive management T. E. Potok - University of Tennessee

42. More on CMM • There are 18 key process areas defined by CMM, including • Requirements Management, • Software Configuration Management • Process Change Management • Defect Prevention • Each key process area has five common features: • 1) goals to be achieved; • 2) ability to perform; • 3) activities performed; • 4) measurement and analysis; • 5) verification T. E. Potok - University of Tennessee

43. Level of an organization • Levels are determined by audit. • Like ISO 9000, the program can be of great value, or can be done to merely reach a level. T. E. Potok - University of Tennessee

44. Requirement Analysis T. E. Potok - University of Tennessee

45. Three basic types of requirements • Requirements against an existing product • Make a change or modification to an existing product • A new project with requirements directly from a customer • Building a project for a specific customer • Market requirements for a new product • Building a new product that the market may need T. E. Potok - University of Tennessee

46. Requirements against an existing product • A very structured environment • Requirements are usually clearly understood • Determining the priority of the requirements is the challenge. • Not implementing a much needed requirements can could a loss of market share • Implementing trivial requirements may result is a wasted investment • Assessing priorities will be covered later in the course T. E. Potok - University of Tennessee

47. New project requirements • Customer need special software built for his or her need • This need is typically described informally to the programming team • The programming team then attempts to transform the requirements into running code T. E. Potok - University of Tennessee

48. How to gather and record requirements • Traditional approach is the JAD (Joint Application Development) session • Domain experts are taught rudimentary data modeling and data flow diagramming techniques, then lead by an expert into developing a design • A beginning design can be developed in a few days T. E. Potok - University of Tennessee

49. JAD Sessions • Entity relationship modeling is used to capture the data requirements • These ER models are then translated into a database definition • Data flow diagrams are used to capture the functions that are needed by the system • These DFDs are then translated into functional designs T. E. Potok - University of Tennessee

50. Entity Relationship Modeling Enrolls Name Number Description Department Credit hours Student limit 5,m 1,m Student Class Grade 1,m Name ID number Classification Major Teaches 1,1 Teacher Name Department T. E. Potok - University of Tennessee