1 / 101

Overview of Software Engineering

Overview of Software Engineering. CS 330 Spring 2007. Key Ingredients in successful organizations . Process. People. Customer. Technology. Pyramids are stable. Wedges are not!. A better view Process and Technology supporting people. People. Solution. Processes. Technology.

lawson
Download Presentation

Overview of Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related