Overview of Software Engineering

1. Overview of Software Engineering CS 330 Spring 2007

2. Key Ingredients in successful organizations Process People Customer Technology

3. Pyramids are stable. Wedges are not! A better viewProcess and Technology supporting people People Solution Processes Technology

4. What is software? • Computer programs and associated documentation • Software products may be developed for a particular customer or may be developed for a general market • Software products may be • Generic/COTS - developed to be sold to a range of different customers • Custom- developed for a customer according to their specification

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

6. Software Engineering • The term is 35 years old: NATO Conferences • Garmisch, Germany, October 7-11, 1968 • Rome, Italy, October 27-31, 1969 • The reality is it is finally beginning to arrive • Computer science one the scientific basis • Years of studies/experience/statistics provide basis too • Many aspects have been made systematic • Methods/methodologies/techniques • Languages • Tools • Processes

7. Why Engineer Software ? • The problem is complexity • Many sources, but size is a key: • Mozilla contains 3 Million lines of code • UNIX contains 4 million lines of code • Windows 2000 contains 108 lines of code • Second is role and combinatorics of “state” • Third is uncertainty of “inputs” and their timing • Fourth is the continuing changing “environment” and demands. Software engineering is about managing all the sources of complexity to produce effective software.

8. 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/management principles, techniques, tools and notations • Goal • production of quality software, delivered on time, within budget, satisfying customers’ requirements and users’ needs

9. What does a software engineer do? Software engineers should • adopt a systematic and organised approach to all aspects of software development. • use appropriate tools and techniques depending on • the problem to be solved, • the development constraints and • the resources available • Understand and communicate processes for improved software development within their organization • Be effective team members and/or leaders. • Can be very technical or more managerial depending on organizational need.

10. the practicalities of developing • delivering useful software • theory • fundamentals What is the difference between software engineering and computer science? Computer Science Software Engineering is concerned with Computer science theories are currently insufficient to act as a complete underpinning for software engineering, BUT it is a foundation for practical aspects of software engineering

11. What is the difference between software engineering and system engineering? • Software engineering is part of System engineering • System engineering is concerned with all aspects of computer-based systems development including • hardware, • software and • process engineering • System engineers are involved in systemspecification, architectural design, integration and deployment

12. Difficulties? • SE is a unique brand of engineering • Software is malleable • Software construction is human-intensive • Software is intangible and generally invisible • Software problems are unprecedentedly complex • Software directly depends upon the hardware • It is at the top of the system engineering “food chain” • Software solutions require unusual rigor • Software “state” means behaviors can depend on history. • Software has discontinuous operational nature

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

14. 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 60%-80% of overall development costs

15. Economic and Management Aspects of SE • Software Engineering is about improved ROI (can be Capital and/or Social ROI) • Software production =development + maintenance • Maintenance costs 60%-80% of all (successful) development costs • 20% corrective (12%-16% total costs) • 30% adaptive (18%-24% total costs) • 50% perfective (30-40% total costs) • Quicker development is not always preferable • higher up-front costs may defray downstream costs • poorly designed/implemented software is a critical cost factor in system cost and delays

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

17. 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 • “software developers” are not interchangeable work units. • Brooks’ Law • Adding personnel to a late project makes it later

18. Software Engineering:From Principles to Tools

19. Software Qualities • Qualities are goals in the practice of software engineering, and directly relate to many of the guiding principles. • External vs. Internal qualities • Product vs. Process qualities

20. Critical Quality Attributes Correctness Maintainability Dependability Usability Reliability Other Attributes Completeness Compatibility Portability Internationalization Understandability Scalability Robustness Testability Reusability Customizability Efficiency Software Qualities

21. External vs. Internal Qualities • External qualities are visible to the user • reliability, usability, efficiency (maybe), robustness, scalability • Internal qualities are the concern of developers • they help developers achieve external qualities • verifiability, maintainability, extensibility, evolvability, adaptability, portability, testability, reusability

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

23. 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/inputs • relative

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

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

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

27. 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, distributed programming interfaces (CORBA, DCOM), plug-in protocols, etc.

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

29. Process Principles • Prescribes all major activities • Uses resources, within a set of constraints, to produce intermediate and final products • May be composed of sub-processes • Each activity has entry and exit criteria • Activities are organized in a sequence • Has a set of guiding principles to explain goals • Constraints may apply to activity, resource or product

30. Software Development Stages • Requirements Analysis & Specification • Conceptual/System/Architectural Design • Detailed/Program Design • Implementation/Coding • Unit & Integration Testing • System Testing/Validation • System Delivery/Deployment • Maintenance • Note there are many “variations” on the names. You are responsible for the main categories above (an on the next pages)..

31. Software Lifecycle Models • Waterfall Model • V Model • Phased Development Model • Incremental Model • Prototyping Model • Spiral Model

32. Plan/Schedule Replan/Reschedule Software Development LifecycleWaterfall Model Requirements Design Implementation Integration Validation Deployment

33. V Model [Pfleeger 98]

34. Phased Development Model [Pfleeger 98]

35. Requirements Design Requirements Requirements Design Implementation Design Implementation Implementation Integration Integration Integration Validation Validation Deployment Deployment Validation Deployment Software Development LifecycleIncremental Model Version 1: Complete General Design Version 2: Design/Implement first set of planned “new” features. Note overlap with V1 schedule Version 3: Design/Implement second set of planned “new” features

36. Prototyping Model Listen to Customer Build/Revise Mock-Up Customer Test-drives Mock-up [Pressman 97]

37. Prototyping Model [Pfleeger 98]

38. Spiral development • Process is represented as a spiral rather than as a sequence of activities with backtracking. • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. • Risks are explicitly assessed and resolved throughout the process.

39. Spiral model of the software process

40. Spiral model sectors • Objective setting • Specific objectives for the phase are identified. • Risk assessment and reduction • Risks are assessed and activities put in place to reduce the key risks. • Development and validation • A development model for the system is chosen which can be any of the generic models. • Planning • The project is reviewed and the next phase of the spiral is planned.

41. Evolutionary development • Exploratory development • Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer. • Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

42. Evolutionary development

43. Evolutionary development • Problems • Lack of process visibility; • Systems are often poorly structured; • Special skills (e.g. in languages for rapid prototyping) may be required. • Applicability • For small or medium-size interactive systems; • For parts of large systems (e.g. the user interface); • For short-lifetime systems.

44. Component-based software engineering • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Process stages • Component analysis; • Requirements modification; • System design with reuse; • Development and integration. • This approach is becoming increasingly used as component standards have emerged.

45. Reuse-oriented development

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

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

48. Process iteration • System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. • Iteration can be applied to any of the generic process models. • Two (related) approaches • Incremental delivery; • Spiral development.

49. Incremental delivery • Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. • User requirements are prioritised and the highest priority requirements are included in early increments. • Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

50. Incremental development