1 / 63

Software Engineering Chapter 4 Software processes

Software Engineering Chapter 4 Software processes. Ku-Yaw Chang canseco@mail.dyu.edu.tw Assistant Professor Department of Computer Science and Information Engineering Da-Yeh University. Objectives. Understand the concept of software process and software process model

patriciahayes
Download Presentation

Software Engineering Chapter 4 Software processes

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. Software EngineeringChapter 4 Software processes Ku-Yaw Chang canseco@mail.dyu.edu.tw Assistant ProfessorDepartment of Computer Science and Information Engineering Da-Yeh University

  2. Objectives • Understand the concept of software process and software process model • Understand three generic software process models and when they might be used • Understand, in outline, the activities involved in software requirements engineering, software development, testing and evolution • Understand how the Rational Unified Process integrates good software process practice to create a modern, generic process model • Have been introduced to CASE technology that is used to support software process activities Software processes

  3. Preamble • A software process • A set of activities that leads to the production of a software product • No ideal process • Many organizations have developed their own approach to software development • Fundamental activities to all software processes • Specification • Design and implementation • Validation • Evolution Software processes

  4. Contents 4.1 Software process models 4.2 Process iteration 4.3 Process activities 4.4 The Rational Unified Process 4.5 Computer-Aided Software Engineering 4.6 Exercises Software processes

  5. 4.1 Software process models • A software process model • An abstract representation of a software process • Represent a process from a particular perspective • General process models ( sometimes called process paradigms) • The waterfall model • Evolutionary (Iterative) development • Component-based software engineering • The above models are not mutual exclusive • Often be used together Software processes

  6. 4.1.1 The waterfall model Software processes

  7. Waterfall model phases • Requirements analysis and definition • Service, constraints and goals • Consultation with system users • System and software design • System design • Partition the requirements to either hardware or software systems • Establish an overall system architecture • Software design • Identify and describe the fundamental software abstractions and their relationships Software processes

  8. Waterfall model phases • Implementation and unit testing • Software design is realized • A set of programs or program units • Unit testing • Verify that each unit meets its specification • Integration and system testing • Integrate individual program units or programs • Be tested as a complete system • Operation and maintenance • Install the system and put it into practical use • Maintenance • Correct errors • Improve the implementation • Enhance services Software processes

  9. The waterfall model • Advantages • The documentation is produced at each phase • It fits with other engineering process models • Particularly when the software project is part of a larger system engineering project. • Disadvantages • Inflexible partitioning of the project into distinct stages • Commitments must be made at an early stage • Difficult to respond to changing customer requirements • Only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. • Few business systems have stable requirements. Software processes

  10. 4.1.2 Evolutionary development • Based on the idea of • Developing an initial implementation • Exposing this to user commitment • Refining it through many versions • Specification, development and validation activities are interleaved rather than separate • With rapid feedback across activities Software processes

  11. Evolutionary development Software processes

  12. Two fundamental types • Exploratory development • Work with customers and to evolve a final system from an initial outline specification • Start with well-understood requirements and add new features as proposed by the customer • Throwaway prototyping • Understand the system requirements • Start with poorly understood requirements to clarify what is really needed Software processes

  13. Evolutionary development • Often more effective than the waterfall approach • In producing systems that meet the immediate needs of customers • Advantage • The specification can be developed incrementally • Disadvantages • The process is not visible • Not cost-effective to produce documents that reflect every version of the system • Systems are often poorly structured • Continual change tends to corrupt the software structure Software processes

  14. Evolutionary development • Applicability • For small or medium-size systems (up to 500,000 lines of code) • For parts of large systems (e.g. the user interface) • A mixed process incorporating the waterfall and evolutionary models • A throwaway prototyping to resolve uncertainties in the system specification • Implement the system in a more structural approach • The user interface could be developed using an exploratory approach • For short-lifetime systems Software processes

  15. 4.1.3 Component-basedsoftware engineering • Software reuse • The majority of software projects • Essential for rapid system development • CBSE • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems • Becoming increasingly used as component standards have emerged Software processes

  16. Component-basedsoftware engineering Software processes

  17. CBSE stages • System specification • Component analysis • A search is made for components • Usually no exact match • Requirements modification • Analyze requirements using information about components that have been discovered • System design and reuse • Take into account the components that are reuse • Reorganize the framework of the system • Some new software may be designed reusable components are not available • Development and integration • Develop software that cannot be externally procured • Integrate newly developed software and COTS systems • System validation Software processes

  18. Component-basedsoftware engineering • Advantages • Reduce the amount of software to be developed • Costs and risk • Lead to faster delivery of the software • Disadvantages • Requirements compromises are inevitable • Some control over the system evolution is lost Software processes

  19. Contents 4.1 Software process models 4.2 Process iteration 4.3 Process activities 4.4 The Rational Unified Process 4.5 Computer-Aided Software Engineering 4.6 Exercises Software processes

  20. Process iteration • Change is inevitable in large software projects • The essence of iterative processes • The specification is developed in conjunction with the software • Conflict with the procurement model of many organizations • The complete system specification is part of the system development contract • Two process models to support process iteration • Incremental delivery • Spiral development Software processes

  21. 4.2.1 Incremental delivery • Waterfall model • Separation of design and implementation leads to well-documented systems that are amenable to change • Evolutionary development • May be poorly structured and difficult to understand and maintain • Incremental delivery • An in-between approach that combines the advantages of the above models Software processes

  22. Incremental delivery • Customers outline the services • Identify which are most/least important • Define a number of delivery increments • Each increment provide a sub-set of the system functionality • Develop an increment • Requirements are defined in detail • Further requirements analysis for later increments can take place • Put an increment into service • New increments are integrated with existing increments Software processes

  23. Incremental delivery Software processes

  24. Incremental development • Advantages • Customer value can be delivered with each increment so system functionality is available earlier • Early increments act as a prototype to help elicit requirements for later increments • Lower risk of overall project failure • The highest priority system services tend to receive the most testing Software processes

  25. Incremental development • Problems • Difficult to map requirements onto increments of the right size • Relatively small – no more than 20,000 lines of code • Hard to identify facilities that are needed by all increments • Extreme programming • An approach to development • Based on the development and delivery of very small increments of functionality • Relies on constant code improvement, user involvement in the development team and pairwise programming. Software processes

  26. 4.2.2 Spiral development • The software process is represented as a spiral • Each loop represents a phase Software processes

  27. Spiral model Software processes

  28. Contents 4.1 Software process models 4.2 Process iteration 4.3 Process activities 4.4 The Rational Unified Process 4.5 Computer-Aided Software Engineering 4.6 Exercises Software processes

  29. Process Activities • Basic process activities • Specification, development, validation, and evolution • Organized in sequence in the waterfall model • Interleaved in evolutionary development • No right or wrong way to organize these activities • Depend on the type of software, people and organizational structures involved Software processes

  30. 4.3.1 Software specification • Also called requirements engineering (RE) • The process of • Understanding and defining required services • Identifying constraints on operation and development • Four main phases in the RE process • Feasibility study • Requirements elicitation and analysis • Requirements specification • Requirements validation Software processes

  31. The requirements engineering process Software processes

  32. 4.3.2 Software design and implementation • Software development • The process of converting a system specification into an executable system • Design process • Developing several models of the system at different levels of abstraction • Stages are sequential • A specification for the next stage is the output of each design activity Software processes

  33. A general model ofthe design process Software processes

  34. Structured methods • Structured methods • Be invented in 1970s to support function-oriented design • Produce graphical models of the system • Automatically generating code from these models • Various competing methods to support object-oriented design were unified in the 1990s • Unified Modeling Language (UML) • Current official version : 2.1.1 (2007/04) • Unified design process • Rational Unified Process (RUP) Software processes

  35. Structured methods • Support part or all of the following models • An object model • Object classes and dependencies • A sequence model • Objects interaction during execution • A state transition model • System states and triggers for the transitions • A structural model • System components and their aggregations • A data flow model • Focus on the data transformations Software processes

  36. The debugging process • Testing • Establish the existing of defects • Debugging • Locating and correcting these defects Software processes

  37. 4.3.3 Software validation • Verification and Validation ( V & V ) • Verification • a system conforms to its specification • Validation • the system meets the expectations of the customer • Systems should not be tested as a single, monolithic unit. • A three-stage testing process Software processes

  38. The testing process Software processes

  39. Stages in the testing process • Component (or unit) testing • Individual components are tested independently; • Components may be functions or objects or coherent groupings of these entities. • System testing • Testing of the system as a whole. Testing of emergent properties is particularly important. • Acceptance testing • Testing with customer data to check that the system meets the customer’s needs. Software processes

  40. 4.3.3 Software validation • Component development and testing are interleaved • An economically sensible approach • Programmers make up their own test data and test the code as it is developed. • Alpha testing • Sometimes called acceptance testing • The system developer and the client agree that the delivered system is an acceptable implementation • Beta testing • Delivering a system to a number of potential customers Software processes

  41. Testing phases Software processes

  42. System evolution • It makes more sense to see development and maintenance as a continuum. Software processes

  43. Contents 4.1 Software process models 4.2 Process iteration 4.3 Process activities 4.4 The Rational Unified Process 4.5 Computer-Aided Software Engineering 4.6 Exercises Software processes

  44. Rational Unified Process • Rational Unified Process (RUP) • A modern process model that derived from work on the UML and associated process • OMG’s Unified Modeling Language Software processes

  45. Rational Unified Process • Be described from three perspectives • A dynamic perspective • The phases of the model over time • A static perspective • The process activities that are enacted • A practice perspective • Suggest good practices Software processes

  46. Phases in the RUP(1/4) • Four discrete phases • Focus on business • Not technical concerns like the waterfall model Software processes

  47. Phases in the RUP(2/4) • Inception • Goal • Establish a business case for the system • Identify external entities (people and systems) and define their interactions • Elaboration • Goals • Develop an understanding of the problem domain • Establish an architectural framework for the system • Develop the project plan • Identify key project risks Software processes

  48. Phases in the RUP(3/4) • Construction • Be concerned with system design, programming and testing • Parts are developed in parallel and integrated • Transition • From the development community to the user community • Work in a real environment Software processes

  49. Phases in the RUP(4/4) • Iterations are supported in two ways • Each phase may be enacted in an interactive way • The whole set of phases may also be enacted incrementally Software processes

  50. Static view of the RUP (1/2) • Activities (called workflows) during the development process • Six core workflows • Three core supporting workflows • Be oriented around associated UML models Software processes

More Related