Overview of Software Engineering Principles

1. Overview of Software Engineering Principles CSCI 599: Software Engineering for Embedded Systems August 27, 2002

2. Engineering • Engineering is … • the application of scientific principles and methods • To the construction of useful structures & machines • Examples • Mechanical engineering • Civil engineering • Chemical engineering • Electrical engineering • Nuclear engineering • Aeronautical engineering

3. Software Engineering in a Nutshell • Development of software systems whose size/complexity warrants team(s) of engineers • multi-person construction of multi-version software [Parnas 1987] • Scope • study of software process, development principles, techniques, and notations • Goal • production of quality software, delivered on time, within budget, satisfying customers’ requirements and users’ needs

4. Ever-Present Difficulties • Few guiding scientific principles • Few universally applicable methods • As muchmanagerial / psychological / sociologicalas technological

5. Why These Difficulties? • SE is a unique brand of engineering • Software is malleable • Software construction is human-intensive • Software is intangible • Software problems are highly complex • Software directly depends upon the hardware • It is at the top of the system engineering “food chain”

6. Software Engineering ≠ Software Programming • Software programming • Single developer • “Toy” applications • Short lifespan • Single or few stakeholders • Architect = Developer = Manager = Tester = Customer = User • One-of-a-kind systems • Built from scratch • Minimal maintenance

7. Software Engineering ≠ Software Programming • Software engineering • Teams of developers with multiple roles • Complex systems • Indefinite lifespan • Numerous stakeholders • Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User • System families • Reuse to amortize costs • Maintenance accounts for over 60% of overall development costs

8. Economic and Management Aspects of SE • Software production = development + maintenance (evolution) • Maintenance costs > 60% of all development costs • 20% corrective • 30% adaptive • 50% perfective • Quicker development is not always preferable • higher up-front costs may defray downstream costs • poorly designed/implemented software is a critical cost factor

9. Relative Costs of Fixing Software Faults 200 30 10 4 3 2 1 Requirements Specification Planning Design Implementation Integration Maintenance

10. Mythical Man-Monthby Fred Brooks • Published in 1975, republished in 1995 • Experience managing development of OS/360 in 1964-65 • Central argument • Large projects suffer management problems different in kind than small ones, due to division in labor • Critical need is the preservation of the conceptual integrity of the product itself • Central conclusions • Conceptual integrity achieved through chief architect • Implementation achieved through well-managed effort • Brooks’s Law • Adding personnel to a late project makes it later

11. Software Development LifecycleWaterfall Model Requirements Design Implementation Integration Validation Deployment

12. Software Development LifecycleSpiral Model

13. Requirements • Problem Definition → Requirements Specification • determine exactly what the customer and user want • develop a contract with the customer • specifieswhat the software product is to do • Difficulties • client asks for wrong product • client is computer/software illiterate • specifications are ambiguous, inconsistent, incomplete • Verification • extensive specification reviews with the customer • identify ambiguity, inconsistency, incompleteness • ascertain feasibility, testability • develop system/acceptance test plan

14. Architecture/Design • Requirements Specification → Architecture/Design • architecture: decompose software into modules with interfaces • design: develop module specifications (algorithms, data types) • maintain a record of design decisions and traceability • specifieshow the software product is to do its tasks • Difficulties • miscommunication between module designers • design may be inconsistent, incomplete, ambiguous • Verification • design inspections to establish conformance to requirements • check module interactions • develop integration test plan

15. Architecture vs. Design[Perry & Wolf 1992] • Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design. • Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.

16. Implementation & Integration • Design → Implementation • implement modules; verify that they meet their specifications • combine modules according to the design • specifieshow the software product does its tasks • Difficulties • module interaction errors • order of integration may influence quality and productivity • Verification • code reviews to establish conformance to requirements & design • check module interactions • develop unit test plan: focus on individual modules • test on unit, integration and acceptance test plans

17. Component-Based Development • Develop generally applicable components of a reasonable size and reuse them across systems • Make sure they are adaptable to varying contexts • Extend the idea beyond code to other development artifacts • Question: what comes first? • Integration, then deployment • Deployment, then integration

18. Different Flavors of Components • Third-party software “pieces” • Plug-ins / add-ins • Applets • Frameworks • Open Systems • Distributed object infrastructures • Compound documents • Legacy systems

19. Verification and Validation • Analysis • Static • “Science” • Formal verification • Informal reviews and walkthroughs • Testing • Dynamic • “Engineering” • White box vs. black box • Structural vs. behavioral • Issues of test adequacy

20. Deployment & Evolution • Operation → Change • maintain software during/after user operation • determine whether the product still functions correctly • Difficulties • rigid design • lack of documentation • personnel turnover • Verification • extensive reviews to ensure correct changes and updates to documentation • test to determine that change is correctly implemented • regression testing: ensure that no inadvertent changes are made to compromise system functionality

21. Configuration Management (CM) [Tichy 1988] • CM is a discipline whose goal is to control changes to large software through the functions of • Component identification • Change tracking • Version selection • Software manufacture • Managing simultaneous updates (team work)

22. 1.1 1.2 2.0 4.0 1.3 2.1 2.2 1.4 3.0 1.5 3.1 CM in Action 1.0

23. Software Engineering Principles • Rigor and formality • Separation of concerns • Modularity and decomposition • Abstraction • Anticipation of change • Generality • Incrementality • Scalability • Compositionality • Heterogeneity

24. From Principles to Tools

25. Software Qualities • Qualities (a.k.a. “ilities”) are goals in the practice of software engineering • External vs. Internal qualities • Product vs. Process qualities

26. External vs. Internal Qualities • External qualities are visible to the user • reliability, efficiency, usability • Internal qualities are the concern of developers • they help developers achieve external qualities • verifiability, maintainability, extensibility, evolvability, adaptability

27. Product vs. Process Qualities • Product qualities concern the developed artifacts • maintainability, understandability, performance • Process qualities deal with the development activity • products are developed through process • maintainability, productivity, timeliness

28. Some Software Qualities • Correctness • ideal quality • established w.r.t. the requirements specification • absolute • Reliability • statistical property • probability that software will operate as expected over a given period of time • relative

29. Some Software Qualities (cont.) • Robustness • “reasonable” behavior in unforeseen circumstances • subjective • a specified requirement is an issue of correctness;an unspecified requirement is an issue of robustness • Usability • ability of end-users to easily use software • extremely subjective

30. Some Software Qualities (cont.) • Understandability • ability of developers to easily understand produced artifacts • internal product quality • subjective • Verifiability • ease of establishing desired properties • performed by formal analysis or testing • internal quality

31. Some Software Qualities (cont.) • Performance • equated with efficiency • assessable by measurement, analysis, and simulation • Evolvability • ability to add or modify functionality • addresses adaptive and perfective maintenance • problem: evolution of implementation is too easy • evolution should start at requirements or design

32. Some Software Qualities (cont.) • Reusability • ability to construct new software from existing pieces • must be planned for • occurs at all levels: from people to process, from requirements to code • Interoperability • ability of software (sub)systems to cooperate with others • easily integratable into larger systems • common techniques include APIs, plug-in protocols, etc.

33. Some Software Qualities (cont.) • Scalability • ability of a software system to grow in size while maintaining its properties and qualities • assumes maintainability and evolvability • goal of component-based development

34. Some Software Qualities (cont.) • Heterogeneity • ability to compose a system from pieces developed in multiple programming languages, on multiple platforms, by multiple developers, etc. • necessitated by reuse • goal of component-based development • Portability • ability to execute in new environments with minimal effort • may be planned for by isolating environment-dependent components • necessitated by the emergence of highly-distributed systems (e.g., the Internet) • an aspect of heterogeneity

35. Software Process Qualities • Process is reliable if it consistently leads to high-quality products • Process is robust if it can accommodate unanticipated changes in tools and environments • Process performance is productivity • Process is evolvable if it can accommodate new management and organizational techniques • Process is reusable if it can be applied across projects and organizations

36. Assessing Software Qualities • Qualities must be measurable • Measurement requires that qualities be precisely defined • Improvement requires accurate measurement • Currently most qualities are informally defined and are difficult to assess

37. Software Engineering “Axioms” • Adding developers to a project will likely result in further delays and accumulated costs • Basic tension of software engineering • better, cheaper, faster — pick any two! • functionality, scalability, performance — pick any two! • The longer a fault exists in software • the more costly it is to detect and correct • the less likely it is to be properly corrected • Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design • detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more