1 / 70

Chapter 2

Chapter 2. Software Processes. Objectives. To introduce software process models. To describe a number of generic process models and when they may be used.

arlinebarton
Download Presentation

Chapter 2

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. Chapter 2 Software Processes

  2. Objectives • To introduce software process models. • To describe a number of generic process models and when they may be used. • To outline lower-level process models for (1) requirements engineering, (2) software development, (3) testing, and (4) evolution. • To introduce CASE technology to support software process activities

  3. Topics covered • Software process models • Process iteration • Software specification • Software design and implementation • Software verification & validation • Software evolution • Automated process support

  4. [struhk-cherd] –adjective; having a clearly defined structure or organization. The software process • A process is a structured set of activities required to develop a software system. • Many different software processes, but all involve: • Specification – defining what the system should do; • Design & implementation; • Validation – checking that it does what the customer wants; • Evolution – changing the system in response to changing customer needs. • A process model is an abstract representation of a process. It presents a description of a process from some particular perspective • Models should be as simple as possible, but no simpler. – A. Einstein

  5. [struhk-cherd] –adjective; having a clearly defined structure or organization. The software process • A process is a structured set of activities required to develop a software system. • Many different software processes, but all involve: • Specification – defining what the system should do; • Design & implementation; • Validation – checking that it does what the customer wants; • Evolution – changing the system in response to changing customer needs. • A process model is an abstract representation of a process. It presents a description of a process from some particular perspective • Models should be as simple as possible, but no simpler. – A. Einstein

  6. Plan-driven and agile processes • Plan-driven processes: all of the process activities are planned in advance and progress is measured against this plan. • Agile processes: planning is incremental and it is easier to change the process to reflect changing customer requirements. • In practice, most practical processes include elements of both plan-driven and agile approaches. • There are no right or wrong software processes.

  7. Generic software process models • The Waterfall Model – plan-driven model; separate and distinctphases of specification and development. Traditionally: not iterative. • Incremental Development – specification, development, & validation are interleaved; may be plan-driven or agile. • Reuse-Based Development – e.g., component-based: the system is assembled from existing components; may be plan-driven or agile. • In practice, most large systems are developed using a process that incorporates elements from all of these models. (And, at no additional cost: Boehm’s Spiral Model.)

  8. Waterfall model (W. Royce)

  9. Waterfall model phases • There are separate phases in the waterfall model: • Requirements analysis and definition • System and software design • Implementation and unit testing • Integration and system testing • Operation and maintenance • The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. • In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work.

  10. Waterfall model problems • Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. • Thus, this model is only appropriate when the requirements are well-understood (to begin with). • Few business systems have stable requirements. --------------------------------------------- • In general, the drawback of the waterfall model is thedifficulty of accommodating change after the process is underway.

  11. Incremental development (cont'd)

  12. Incremental development benefits • The cost of accommodating changing customer requirements is reduced - amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. • It is easier to get customer feedback - customers can comment on demonstrations of the software and see how much has been implemented. • More rapid delivery and deployment of useful software to the customer is possible - customers are able to use and gain value from the software earlier than is possible with a waterfall process.

  13. Incremental development problems • Lack of process visibility- managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. • System structure tends to degrade as new increments are added - unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

  14. Reuse-oriented software engineering • Based on systematic (as opposed to serendipitous) reuse - systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Process stages • Component analysis (what’s available?) • Requirements modification (why?) • System design with reuse • Development and integration • Reuse is now the standard approach for building many types of business systems. (cont'd)

  15. Reuse-oriented software engineering (what’s available?) (cont'd)

  16. Types of reusable software components • Web services that are developed according to service standards and which are available for remote invocation. • Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. • Stand-alone software systems (COTS) that are configured for use in a particular environment.

  17. Process activities • Real software processes are interleaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system. • The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence; in incremental development they are interleaved.

  18. Software specification / RE • The process of establishing what services are required and the constraints on the system’s operation and development. • Requirements Engineering (RE) process: • Feasibility (technical and otherwise) study • Requirements elicitation and analysis • Requirements specification (documentation) • Requirements validation (cont'd)

  19. The requirements engineering process

  20. Software design and implementation • The process of producing an executable system based on the specification • Software design – design a software structure that realizes the specification. • Implementation – translate this structure into an executable program. • The activities of specification, design, and implementation are closely related and may be interleaved.

  21. Design activities • Architectural design: identify overall structure of system, principal components (sometimes called sub-systems or modules), their relationships, and how they are distributed. • Interface design: define the interfaces between system components. • Component design: design how each system component will operate. • Database design: design the system data structures and how these are to be represented in a database.

  22. Software verification & validation • Verification and validation (V&V) determines whether or not a system (1) conforms to its specification and (2) meets the requirements of the customer. • Involves checking processes (e.g., inspections/reviews and program (machine-based)testing. • Testing is the most commonly used V&V activity and involves executing program elements with test cases that are derived from specifications and/or program logic.

  23. Testing stages • Development or component 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 ofemergent properties is particularly important. • Acceptance testing • Testing with customer data to check that the system meets the customer’.s needs

  24. Software evolution (maintenance) • Software is inherently flexible and subject to change. • As requirements change through changing business circumstances, the software that supports the business must also evolve and change. • The distinction between development and evolution is increasingly irrelevant as fewer and fewer systems are completely new. (cont'd)

  25. Software evolution (maintenance) e.g., change requests

  26. Coping with change • Change is inevitable in all large software projects. • Business changes lead to new and changed system requirements. • New technologies open up new possibilities for improving implementations. • Changing platforms require application changes. • Change costs include both rework (e.g. re-analyzing requirements) and the cost of implementing new functionality.

  27. Reducing the costs of rework • Change avoidance: process includes activities that can anticipate possible changes before significant rework is required. • For example, a prototype system may be developed to stimulate user/stakeholder abticipation. • Change tolerance: process is designed so that changes can be accommodated at relatively low cost. • Proposed changes may be implemented in increments that have not yet been developed. • Information hiding techniques may be employed.

  28. Software prototyping

  29. What is prototyping? • Aniterative process emphasizing: • Rapid development • Concreteness and Evaluative use (a “real system” is developed and presented to real users for evaluation) • Consideration of alternatives • Feedback • Modification

  30. General Prototyping process What to include & what NOT to include.

  31. Uses of prototypes • Principal use is to help customers and developers better understand system requirements. • Experimentationstimulates anticipation of how a system could be used. • Attempting to use functions together to accomplish some task can easily reveal requirements problems. (Cont’d)

  32. Uses of prototypes (cont’d) • Other potential uses: • Evaluating proposed solutions for feasibility(Experimental Prototyping) • Develop and evaluate UI designs • “Back-to-back” testing • Training users before system delivery • Prototyping is most often undertaken as a risk reduction activity.

  33. Classifying prototypes • By purpose: • Throw-away prototyping – to elicit and validate requirements • Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc. • horizontal vs. vertical (breadth vs. depth) • mockups vs. breadboards (form vs. function) • “Wizard of Oz” prototyping (Turing test reversed)

  34. Throw-away prototyping Elicit/validate REQMTS

  35. Classifying prototypes • By purpose: • Throw-away prototyping – to elicit and validate requirements • Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc. • horizontal vs. vertical (breadth vs. depth) • mockups vs. breadboards (form vs. function) • “Wizard of Oz” prototyping (Turing test reversed)

  36. Classifying prototypes • By purpose: • Throw-away prototyping – to elicit and validate requirements • Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc. • horizontal vs. vertical (breadth vs. depth) • mockups vs. breadboards (form vs. function) • “Wizard of Oz” prototyping (Turing test reversed)

  37. Vertical prototype high FIdelIty Horizontal prototype points of comparable effort Number of features low few many

  38. Classifying prototypes • By purpose: • Throw-away prototyping – to elicit and validate requirements • Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc. • horizontal vs. vertical (breadth vs. depth) • mockups vs. breadboards (form vs. function) • “Wizard of Oz” prototyping (Turing test reversed)

  39. Quin Tech “Self-service check-in and baggage drop-off design” “The design was tested through a full-scale mock-up.”

  40. Electronic circuit on a bread-board (REUK.co.uk) “There is no need to solder anything, and the components can be moved around and the circuit modified thousands of times without damaging parts.”

  41. Classifying prototypes • By purpose: • Throw-away prototyping – to elicit and validate requirements • Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc. • horizontal vs. vertical (breadth vs. depth) • mockups vs. breadboards (form vs. function) • “Wizard of Oz” prototyping (Turing test reversed)

  42. The Wizard of Oz exposed… “The truth is the Wizard was an illusion created by a man hidden behind a curtain.”

  43. Prototyping versus simulation • What’s the difference between prototyping and simulation?

  44. Throw-away prototype delivery ? • Developers may be pressurized to deliver a throw-away prototype as the final system. • This is problematic... • It may be impossible to meet non-functional requirements. • The prototype is almost certainly undocumented. • The system may be poorly structured and therefore difficult to maintain. • Normal organizational quality standards may not have been applied.

  45. No, no, no! I won’t deliver the prototype to you! User Mgmt Developer Air Tank Pressurizing the Developer

  46. Implementation techniques • Various techniques may be used for developing prototypes: • Dynamic high-level languages • Database programming (RAD) • Component and application assembly • These are not mutually exclusive – they are often used together. • Visual programming is also an inherent part of most prototype development systems.

  47. Incremental delivery • Rather than deliver the system as a single unit, the development and delivery is broken down into increments, each of which incorporates part of the required functionality. • User requirements are prioritized and the highest priority requirements are included in early increments. • Once the development of an increment is started, its requirements are “frozen” while requirements for later increments can continue to evolve. (Compromise between Waterfall & Evolutionary development) (cont'd)

  48. Incremental delivery (cont'd)

More Related