CS 3141: Team Software Project – Introduction to Software Engineering

1. CS 3141:Team Software Project – Introduction to Software Engineering Ali Ebnenasir Department of Computer Science Michigan Technological University

2. Acknowledgement • Evelyn Stiller • Cathie LeBlanc • Betty H.C. Cheng

3. What is Software Engineering? • Systematic approach for developing software • Methods and techniques to develop and maintain quality software to solve problems. (Software Engineering: Methods and Management, Pfleeger, 1990) • Study of the principles and methodologies for developing and maintaining software systems. (``Perspectives on Software Engineering,'' Zelkowitz, 1978)

4. What is Software Engineering? • Practical application of scientific knowledge in the design and construction of computer programs and the associated documentationrequired to develop, operate, and maintain them. (``Software Engineering,'' Boehm, 1976) • Deals with establishment of sound engineering principles and methods in order to economically obtain software that is reliable and works on real machines. (``Software Engineering,'' Bauer, 1972)

5. Why Engineer Software? • Air traffic control case study • $2.3 Billion spent without any usable deliverable • 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 are addressed by good software engineering practices

6. Sources of Complexity in Software Development • Technical staff lacks expertise in the complex application domain • Difficulty in interpersonal communications • Ambiguity of natural language, used to express user needs • Difficulty of mentally grasping and coordinating the details of a large-scale development project

7. How Software Development Projects Fail • No functioning software results • The resulting software does not adequately address the need of the users • Software contains incorrect computations • The software is too difficult to use correctly • The system response time is too slow to be used without frustration

8. Why Inter-personal Communication is Difficult • Technical staff and end users have different background knowledge • Technical staff often do not possess the vocabulary used in the application domain • End users frequently do not understand how to effectively express their needs in terms that are clear to systems developers. • Ambiguity of natural language

9. Maintaining Software Systems • Maintenance is an inevitable aspect of software development • It allows software to evolve with an organization • Too often too many resources are directed to maintenance and away from new development • Software requires excessive maintenance efforts if it is poorly structured • It is better to invest in well-structured software up front than to invest excessively in maintenance later

10. 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

11. 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

12. More History of SE Techniques • 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

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

14. Sample Entity Relationship Diagram LibraryPatron Address Has-a Checks out Requests Has-a 1:M 1:M Book Has-a Publisher

15. Principles of the Object-Oriented Paradigm • Abstraction • Modularity • Modeling • Inheritance • Encapsulation(covered later) • Polymorphism(covered later) Shared by other paradigms

16. Abstraction • Expressing the user 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

17. 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.

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

19. Modeling • Modeling is the process of use a graphic notation to express requirements and 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, which is very difficult!

20. 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

21. 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

22. 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

23. Software Engineering Phases and Process Models

24. Software Engineering Phases • Definition: What? • Development: How? • Maintenance: Managing change • Umbrella Activities: Throughout lifecycle

25. Definition • Requirements definition and analysis • Developer must understand • Application domain • Required functionality • Required performance • User interface

26. Definition (cont.) Project planning Allocate resources Estimate costs Define work tasks Define schedule System analysis Allocate system resources to Hardware Software Users

27. Development • Software design • User interface design • High-level design • Define modular components • Define major data structures • Detailed design • Define algorithms and procedural detail

28. Development (cont.) Coding Develop code for each module Unit testing Integration Combine modules System testing

29. Maintenance • Correction - Fix software defects • Adaptation - Accommodate changes • New hardware • New company policies • Enhancement - Add functionality • Prevention - make more maintainable

30. Umbrella Activities • Reviews - assure quality • Documentation - improve maintainability • Version control - track changes • Configuration management - integrity of collection of components

31. Development Process • Step-by-step procedure to develop software • Typically involves the major phases: • analysis • design • coding • testing

32. Process Model / Methodology • Set of activities, notations, tools, in defined sequence • Goal: Order, predicitability, quality, cost control • Follows requirements=>design=>coding, etc. sequence (usually) • Usually defines phases or steps • Often has notations • Sometimes has tools

33. Waterfall Process Model Requirements Design Coding Testing Maintenance

34. Prototyping Process Model Requirements Quick Design Prototype Evaluate Design

35. When to use prototyping? • Help the customer pin down the requirements • Concrete model to “test out” • Often done via the user interface • Explore alternative solutions to a troublesome component • e.g., determine if an approach gives acceptable performance • Improve morale • Partially running system provides visibility into a project Never press down a prototype to final product!

36. Spiral Process Model Planning Risk Analysis Customer Evaluation Engineering

37. Process Models • Idealized view of the development process • Different models are often used for different subprocesses • may use spiral model for overall development • prototyping for a particularly complex component • waterfall model for other components

38. CMM: Capability Maturity Model Level 1: Initial ad hoc success depends on people Level 2: Repeatable track cost, schedule, functionality Level 3: Defined use standardized processes Level 4: Managed collect detailed metrics Level 5: Optimizing continuous process improvement “built-in” process improvement Software Engineering Institute: http://www.sei.cmu.edu/cmm/

39. Why is software development so difficult? Communication Between customer and developer Poor problem definition is largest cause of failed software projects Within development team More people = more communication New programmers need training Project characteristics Novelty Changing requirements 5 x cost during development up to 100 x cost during maintenance Hardware/software configuration Real time requirements

40. Why is software development difficult?(cont.) Personnel characteristics Ability Prior experience Communication skills Team cooperation Training Facilities and resources Identification Acquisition Management issues Realistic goals Cost estimation Scheduling Resource allocation Quality assurance Version control Contracts Crosscutting concerns Availability requirements Security requirements Reliability requirements Correctness/High assurance

41. Summary • Software lifecycle consists of • Definition (what) • Development (how) • Maintenance (change) • Different process models concentrate on different aspects • Waterfall model: maintainability • Prototype model: clarifying requirements • Spiral model: identifying risk • Maintenance costs much more than development

42. Bottom Line • U.S. software is a major part of our societal infrastructure • Costs upwards of $200 billion/year • Need to • Improve software quality • Reduce software costs/risks

43. Impact of SE Research • Impact of research is measured over time and utility • Who do you think has had the most impact on the field of software engineering? • Why?

44. People you should know… • David Parnas: modularity, reuse, abstraction • Edsger Dijkstra: structured programming • Harlan Mills: clean room programming • Mark Weiser: ubiquitous computing

45. Software vs. Hardware Engineering

46. Hardware and Hardware Engineering • Characteristics: • Components are packaged as individual building blocks • Standardized interfaces among components • Large number of off-the-shelf components • Performance, cost, and availability easily determined/measured • Hardware configuration built from a hierarchy of "building blocks"

47. Hardware Engineering • Phases to system engineering of hardware: • Development Planning and requirements analysis: • best classes of hardware for problem • availability of hardware • type of interface required • identification of what needs to be designed and built • Establish a Plan or "road map" for design implementation • May involve a hardware specification • Use Hardware Description Languages (HDL) • Use CAE/CAD to develop a prototype (breadboard) • Develop printed circuit (PC) boards • Manufacturing of boards

48. Software and Software Engineering • Function may be the implementation of a sequential procedure for data manipulation • Performance may not be explicitly defined (exception in real-time systems) • Software element of computer-based system consists of two classes of programs, data, and documentation • Application Software: • implements the procedure that is required to accommodate information processing functions • System Software: • implements control functions that enable application software to interface with other system elements

49. Three high-level phases ofSoftware Engineering • Definition phase: • Software planning step  Software Project Plan • scope of project • risk • resource identification • cost and schedule estimates • Software Requirements Analysis  Requirements Specification • System element allocated to software is defined in detail • Formal information domain analysis to establish models of information flow and structure (expand to produce specification) • Prototype of software is built and evaluated by customer • Performance requirements or resource limits defined in terms of software characteristics • Definition and Requirements must be performed in cooperation

50. Development Phase • Development Phase: • Translate set of requirements into an operational system element • Design  Design Specification • Coding (appropriate programming language or CASE tool) • Should be able to directly trace detail design descriptions from code.; i.e., traceability • Verification, release, and maintenance phase: • Testing software  Testing Plan • to find maximum number of errors before shipping • Testing shows software has errors, it does not show the lack of errors! • Prepare software for release  Quality Assurance • Maintain software throughout its lifetime