Your SlideShare is downloading. ×
0
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
software Engineering process
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

software Engineering process

613

Published on

intoroduction to software Engineering

intoroduction to software Engineering

Published in: Engineering, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
613
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
44
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Chapter 4 Part-2 Software Processes
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Process activities • 1- Software specification • 2- Software design and implementation • 3- Software validation • 4- Software evolution
  • 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. 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. 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. 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. 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. 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. 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. The debugging process Locate error Design error repair Repair error Re-test program
  • 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. The stages of testing process Sub-system testing Module testing Unit testing System testing Acceptance testing Component testing Integration testing User testing
  • 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. 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. 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. System evolution Assess existing systems Define system requirements Propose system changes Modify systems New system Existing systems
  • 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. 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. 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. 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. 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. 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. 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. 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. 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

×