software Engineering process


Published on

intoroduction to software Engineering

Published in: Engineering, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

software Engineering process

  1. 1. Chapter 4 Part-2 Software Processes
  2. 2. In Ch4 Lec 5 – Part 1 we discuss: 1- Generic software process model a. waterfall model b. evolutionary model c. Formal systems d. reuse- based component model In Ch4 Lec 5 – Part 2 we discuss: 2- Iterative process model a. Incremental development (delivery) b. Spiral development 3- software process 4- CASE tools
  3. 3. Process iteration • process iteration where earlier stages are reworked in response to change request is always part of the process for large systems • The iteration process models that have been designed to support process iteration?? – 1- Incremental development (delivery) – 2- Spiral development
  4. 4. 1- Incremental delivery • It is an in between approach which combines the advantages of waterfall and evolutionary models. • Rather than deliver the system as a single delivery, the software specification, design and implementation is broken down into increments with each increment delivering part of the required functionality.
  5. 5. Incremental delivery • User requirements are prioritized 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
  6. 6. Incremental development Validate increment Develop system increment Design system architecture Integrate increment Validate system Define outline requirements Assign requirements to increments System incomplete Final system
  7. 7. Incremental delivery advantages • Customer can gain value from the system 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 • it is useful when staffing is unavailable for a complete implementation.
  8. 8. Advice: when you encounter a difficult deadline that cannot be changed, the incremental model is a good one to consider. Increments should be relatively small and each increment should deliver some system functionality. So it is difficult to map the customer’s requirement with the right size of the increment. A recent evolution of this increment approach called extreme programming (XP).
  9. 9. Extreme programming (XP)- a new evolution of incremental approach. • New approach based on the development and delivery of very small increments of functionality • Relies on user involvement in the development team (planning) and pair programming (Coding)
  10. 10. 2- Spiral development • Process is represented as a spiral rather than as a sequence of activities with backtracking from one activity to another. • Each loop in the spiral represents a phase in the software process. • The inner loop might be connected to feasibility, next loop with requirements definitions and so on. • Risks are explicitly assessed and resolved throughout the process
  11. 11. Spiral model of the software process Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integration testAcceptance testService Develop, verify next-level product Evaluate alternatives identify, resolve risks Determine objectives alternatives and constraints Plan next phase Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW
  12. 12. Spiral model loop sectors • Objective setting – Specific objectives for the phase are identified – constraints on the process and the product are identified, also project risks are identified. • Risk analysis (assessment) and reduction – Risks are assessed and activities put in place to reduce the key risks – Example: if there is a risk that the requirements are inappropriate, a prototype system may be developed.
  13. 13. Spiral model loop sectors • Development and validation (engineering) – A development model for the system is chosen which can be any of the generic models – Example: if user interface risk are dominant , an appropriate development model might be evolutionary prototyping • Planning – The project is reviewed and the next phase of the spiral is planned
  14. 14. Spiral model • The main different between the Spiral model and other Software process model: is the explicit recognition of the risk (something that can be go wrong)
  15. 15. Process activities • 1- Software specification • 2- Software design and implementation • 3- Software validation • 4- Software evolution
  16. 16. 1- Software specification (RE) • It is the process of establishing what services are required from the system and the constraints on the system’s operation and development
  17. 17. 1- Software specification (RE) • Software specification or Requirements Engineering process phases: – Feasibility study (is the proposed system cost-effective, is it within the budget constraints) – Requirements elicitation and analysis, this may involve observation of existing system, task analysis, and may need to development of system model an prototype. – Requirements specification, translate info gathered to set of requirements (document), it include: User requirement and system requirements (more detail) – Requirements validation, realism, consistency and completeness.
  18. 18. The Requirements Engineering process Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility report System models User and system requirements Requirements document
  19. 19. 2- Software design and implementation • The process of converting the system specification into an executable system • Software design, is a description of the structure of the software, the data, the interfaces, and algorithms. • Implementation, translate this structure into an executable program • The activities of design and implementation are closely related and may be inter-leaved
  20. 20. Design process activities (phases) • Architectural design, the sub systems making the system and their relationship are identified. • Abstract specification, for each sub system, an abstract specification of its services and constraints is produced. • Interface design, for each sub system, its interfaces with others is designed. • Component design: services are allocated to the component and the interfaces for this component is designed • Data structure design: the data structure used in this system are designed in detail. • Algorithm design: the Algorithm used in this system are designed in detail.
  21. 21. The software design process Architectural design Abstract specification Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Requirements specification Design activities Design products
  22. 22. Programming and debugging ( Implementation) • Translating a design into a program and removing errors from that program • Programming is a personal activity - there is no generic programming process • Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process • The debugging process are consisted of locate errors, design error repair, repair errors, and re-test program.
  23. 23. The debugging process Locate error Design error repair Repair error Re-test program
  24. 24. 3- Software validation • Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system’s customer • System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system
  25. 25. The stages of testing process Sub-system testing Module testing Unit testing System testing Acceptance testing Component testing Integration testing User testing
  26. 26. Testing Process stages • Unit(Component) testing, individual components are tested to insure that it is work correctly • Module testing, related collections of dependent components are tested • Sub-system testing, modules are integrated into sub-systems and tested. The focus here should be on interface testing
  27. 27. Testing Process stages, cont… • System testing, testing of the system as a whole. integrate the component then make testing * to find the errors result from integration and interface problems for this component. This test is used * to validate the system to meet the functional and non-functional requirement and * to check the emergent properties. • Acceptance testing, testing with customer data to check that it is acceptable. System is tested using a real data supplied by the user. This test reveals requirement problems and if the system performance is not acceptable.
  28. 28. 4- Software evolution • Software is inherently flexible and can change. • As requirements change through changing business circumstances, the software that supports the business must also evolve and change • Although there has been a split between development and evolution (maintenance) . • Software maintenance cost is several times the development cost.
  29. 29. System evolution Assess existing systems Define system requirements Propose system changes Modify systems New system Existing systems
  30. 30. Computer-aided software engineering (CASE) • CASE is software to support requirement, design, software development and evolution processes. • Activity automation- can be used by CASE: – Graphical editors used for system model development – Data dictionary that holds information about entities and relations of design. Used to understand design. – Graphical User Interface builder used for user interface construction – Debuggers to support program fault finding – Automated translators to generate new versions of a program from old one. (ex COBOL)
  31. 31. CASE technology • Case technology has led to significant improvements in the software process and saving in the cost of software process. • CASE is available for most routine activities of software process. • The improvement from the use of CASE are limited by two factors: – Software engineering requires creative thought- (Artificial intelligent technology ) - this is not easily automatable. – Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these
  32. 32. CASE Tool classification Classification helps us understand the different types of CASE tools and their support for process activities: • Functional perspective, tools are classified according to their specific function • Process perspective, tools are classified according to process activities that are supported • Integration perspective, tools are classified according to how they are organised into integrated units that provide support for process activity.
  33. 33. Functional tool classification Tool type Examples Planning tools PERT tools, estimation tools, spreadsheets Editing tools Text editors, diagram editors, word processors Change management tools Requirements traceability tools, change control systems Configuration management tools Version management systems, system building tools Prototyping tools Very high-level languages, user interface generators Method-support tools Design editors, data dictionaries, code generators Language-processing tools Compilers, interpreters Program analysis tools Cross reference generators, static analysers, dynamic analysers Testing tools Test data generators, file comparators Debugging tools Interactive debugging systems Documentation tools Page layout programs, image editors Re-engineering tools Cross-reference systems, program re- structuring systems
  34. 34. Activity-based classification Reengineering tools Testing tools Debugging tools Program analysis tools Language-processing tools Method support tools Prototyping tools Configuration management tools Change management tools Documentation tools Editing tools Planning tools Specification Design Implementation Verification and Validation
  35. 35. CASE Classification Categories: • Tools: support individual process activity such as design consistency checking, text editing. • Workbenches: support a set of related process phases and activities such as specification or design. Normally include a number of integrated tools. • Environments: support all or most part of an entire software process activities. Normally include several integrated workbenches
  36. 36. Tools, workbenches, environments Single-method workbenches General-purpose workbenches Multi-method workbenches Language-specific workbenches Programming Testing Analysis and design Integrated environments Process-centred environments File comparators CompilersEditors EnvironmentsWorkbenchesTools CASE technology
  37. 37. Key points • Software processes are the activities involved in producing and evolving a software system. They are represented in a software process model • General activities are specification, design, implementation, validation and evolution • Generic process models describe the organization of software processes such as waterfall, evolutionary and reuse-component. • Iterative process models describe the software process as a cycle of activities. Such as incremental delivery and spiral model. The main advantage of iteration process model is to avoid the commitment to specification and design.
  38. 38. Key points • Requirements engineering is the process of developing a software specification • Design and implementation processes transform the specification to an executable program • Validation involves checking that the system meets to its specification and user needs • Evolution is concerned with modifying the system after it is in use • CASE technology supports software process activities