1. Personal Chitra Chandavarkar chandava@clunet.edu Office: D5 Office Hours: T 4:30-5:30 http://public.clunet.edu/~chandava

2. Course Requirements Homework –Question/Answers (written) –Design documents –Not going to do any programming Exams (midterm and a final) In Class Assignments & Participation –Classroom discussions are a great teaching/learning tool and communication will be critical to your success in industry Project

3. Books Required text –Project-Based Software Engineering – An Object-Oriented Approach References –There are many books on software engineering ranging from general “theory” to specialty topics (object oriented, agile methods, classical, …)

4. Why Do We Study Software Engineering? Chapter 1

5. Examples of Software failures Air traffic control System by FAA –$2.3 Billion spent without any usable deliverable Mars Climate Orbiter –Crashes into surface of Mars Travel reservation system CONFIRM – is cancelled after the investment of $125m

6. Examples of Software failures Faye receives an electric bill for $6.3 m instead of $63 –Error in data input Credit card denial –Credit history of two individuals with same name were merged

7. Why Do Software Systems Fail? System Complexity Communication Management People(users, developers, management) Maintenance

8. Sources of Complexity in Software Development Non linear (multithread) nature Technical staff lacks expertise in the complex application domain Difficulty of mentally grasping and coordinating the details of a large-scale development project

9. Why Inter-personal Communication is Difficult Impedance mismatch –Technical staff often do not possess the vocabulary used in the application domain –Technical staff and end users have different background knowledge –System knowledge resides in domain expert –Implementation knowledge resides in software expert End users frequently do not understand how to effectively express their needs and goals, in terms that are clear to systems developers.

10. Problems Aren’t Always Due to the Software Engineers Project Manager –Unrealistic expectations (technical and/or scheduling)

11. Limitations of People People –Bad decisions –Ego –Stress –Reluctance to admit to mistakes –Fear of losing job/livelihood –Incompetence

12. Maintaining Software Systems Inevitable aspect of software development evolves with an organization Too often too many resources are directed to maintenance and away from new development Poorly structured Software requires excessive maintenance

13. Why Engineer Software? Enormous social cost of NOT engineering software Too many large-scale software development failures for too many decades Software development initiatives fail for many different reasons, most of which can be addressed by good software engineering practices

14. How Can Software Fail? Non-functioning software –“it doesn’t work” Software that doesn’t do what it’s supposed to do –“right answer, wrong problem” Incorrect implementation –“right problem, wrong answer”

15. How Can Software Fail? (cont.) Fragile software –“all I did was enter 1027733 when the program asked for a number between 1 and 10” Software that runs too slow Software that is obsolete before it’s finished

16. How Do We Address These Problems? Address the “impedance mismatch” situation –Being a good programmer isn’t enough –You must be able to understand and extrapolate specifications [from the domain expert] –This is why CS students take non-CS courses (math, science, engineering, language, sociology, psychology, history,…)

17. How Do We Address These Problems? (cont.) Continuously consult the domain expert(s) Continuously consult the customer –“Classical” software engineering methodologies don’t incorporate this very well –“Agile” methods make this a central theme Continuously monitor progress –Predict [and therefore, avoid] disasters Software Engineering (as opposed to “hacking code”)

18. How Do We Address Maintenance Issues? Clear/concise designs Well documentation implementations Code reuse wherever possible Organization Software Engineering It is better to invest in well-structured software up front then to invest excessively in maintenance later

19. Elements of a Software Development Paradigm Conceptualization –What elements are instrumental in how the developers think about the software system? Representation –Must convey what the software project is all about –Most effectively done with a software modeling notation Implementation –Addresses how the source code is structured

20. Elements of a Software Engineering Paradigm Conceptualization –How one “looks” at the system to be developed Process oriented Data oriented Object oriented –The choice of conceptualization primitive will drive how the implementation approach –Note that the designers may not be the ones that do the implementation

21. Elements of a Software Engineering Paradigm (cont.) Conceptualization (cont.) –Object-oriented conceptualization is [reportedly] the more intuitive approach Less likely to omit a critical process More easily understood (conveyed to/extracted from) the domain expert

22. Elements of a Software Engineering Paradigm (cont.) Representation –Writing down (communicating) the conceptualization Must be concise (want the reviewers to fully understand the system) Must be efficient (don’t want to risk losing the audience) Must be unambiguous (leave nothing to interpretation) –The set of rules for creating the representation is called the notation

23. Elements of a Software Engineering Paradigm (cont.) Implementation –This is where code development begins –Process oriented Focus is on functions –Object oriented Focus is on class definitions –May be driven by the representation used for the conceptualization

24. Elements of a Software Engineering Paradigm (cont.) Implementation (cont.) –Choice of programming language –Coding standards –Source control –Version control –Lots of other headaches

25. A Brief History of Software Engineering Techniques Structured Programming –No gotos Functional Decomposition –Top-down organization of subprograms Structured Analysis –Recognition that analyzing the problem statement has critical influence on the success of the overall project –Formal modeling of subprogram interaction with dataflow diagrams

26. More History of SE Methodologies Data-centered analysis –Uses techniques developed in structured analysis –Data modeling occurs using entity relationship diagrams before functional modeling Object-oriented analysis –No longer segregates the modeling of functions and data –Objects aggregate data with functions that operate on the data

27. Sample Dataflow Diagram Check for overdue books Check-out books Read Patron record Change book status Read book record Write book record Patron ID True/false Patron ID Patron record or null Book ID, out Book ID Book record

28. Sample Entity Relationship Diagram Checks out Library Patron Address BookPublisher Requests 1:M Has-a

29. Principles of the Object-Oriented Paradigm Abstraction Modularity Modeling Inheritance Encapsulation(covered in chapter2) Polymorphism(covered in Chapter2) Shared by other paradigms

30. Abstraction Expressing the software requirements in abstract terms, suppressing details so that a comprehensive portrayal can be made The abstract representation must then be connected to more detailed expressions, so that no information is lost in modeling the system This allows us to reason about the breadth of functionality of the developing system

31. Modularity Breaking a complex software system into smaller modules allows reduces its overall complexity Modules should aggregate some coherent aspect of the system Modules should present a simple interface Classes, functions, and abstract data types are examples of modules.

32. Abstract Data Type Example STACKSTACK POP() PUSH(item) ISEMPTY() Interface Accesses Implementation Option: Array 12 24 98 33 13 Implementation Option: Linked list 13 98 24

33. Modeling Modeling is the process of use a graphic notation to express properties of the software system Models express how the system is built out of modules and how these modules interact One objective of modeling is to express characteristics of the software system in an unambiguous manner

34. Inheritance A property distinguishing classes from abstract data types Allows characteristics from one class to be passed on its subclasses Subclasses may override inherited characteristics

35. Cost of not Engineering Software Need to restructure code High maintenance costs Software is unacceptable to end users Unreliable code Need to rewrite code Difficulty integrating system modules Difficult project management Budget and time overruns

36. Why Software Engineering is not Universal Understanding software development as programming only without recognition of importance of analysis and design Short-sighted technical management Pressure of deadlines Poor project estimation, thus unreasonable deadlines

37. A Project Done Without Software Engineering

47. Is this a fact or a myth?… Writing new software is easy. –“All I need is a program to…it shouldn’t take you very long to get that going”

48. Is this a fact or a myth?… Modifying existing software is even easier than writing new software. –“That’s really good…but can you modify it to do…”

49. Is this a fact or a myth?… Anyone [and therefore, everyone] can write software. –“Since you’re so busy, we’ll get…over in hardware design to work on this part of the code.”

50. Is this a fact or a myth?… Since software is, by definition, programmable, software can be made to do anything. –“Last night I got this great idea. All your program has to do is…”

51. Is this a fact or a myth?… Software can always be made to run faster. –“Don’t worry about the speed right now. Just get it working. We’ll make it go faster later.”

52. Is this a fact or a myth?… Assigning more people to write software will linearly reduce the time to completion. –“Two months! We need it in two weeks. But don’t worry, we’ll get you 3 more programmers.”

53. Are they“facts” or “myths”? Clearly, the previous “facts” are actually “myths” More myths... –Software is often misunderstood by non-software people –Pressure of time/money/etc. causes people to make bad decisions and unreasonable demands –Many tasks are performed easily by people and thus assumed to be even easier to carry out by an expensive, high powered computer

54. The real “facts” Discipline –Think before you do. Organization –Keep records of what you do. Tools/techniques –The tools exist to support the development effort –Don’t utilize the tools just because they exist

55. When is Software Engineering Important? Always (?) When designing a complex system (?) When more than one person is assigned to work on the system (?) When designing a system that is “mission critical” (?) Software Engineering at some level is always important –The particular project will determine the level

56. What is a “mission critical” system? (cont.) Any/every system can be viewed as “mission critical” It depends on the user What is “mission critical” to some may be completely irrelevant and unimportant to others You should assume that any system you design is “mission critical”