1 / 36

Software process

Software process. Topics covered. Review the previous lecture Software Process RUP- Rational Unified Process. Review. Abstract representation of a process Framework of a process and hide the details of a specific activity Software process models Waterfall model

brant
Download Presentation

Software process

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 process

  2. Topics covered • Review the previous lecture • Software Process • RUP- Rational Unified Process

  3. Review • Abstract representation of a process • Framework of a process and hide the details of a specific activity • Software process models • Waterfall model • Evolutionary development • Exploratory development • Thro-away prototyping • Component-based engineering • Based on COTS • Process iteration • Incremental delivery • Spiral development

  4. Process activities • There are four basic process activities: • Software specification • Software design and implementation • Software validation • Software evolution

  5. Software specification or requirement Engineering • The process of establishing what services are required and the constraints on the system’s operation and development. • This process leads to the production of a requirements document( specification of the system). • Requirements engineering process • Feasibility study; • Requirements elicitation and analysis; • Requirements specification; • Requirements validation.

  6. The requirements engineering process

  7. Feasibility study • is not used to solve the problem but is use to determine weather • the proposed system will be cost effect • if it can be developed with the existing budgetary • The result from this study is to inform the decision of whether or not to go ahead within the constrain • The report should be cheep and quick

  8. Requirements elicitation and analysis • Discover the requirements from • Existing system • Discussion with user • Task analysis • You may use • System relative model • Prototypes

  9. Requirements specification • In this process is about translating information gathered during the system analysis into into two documents • user or customer document includes abstract statements of the system requirements • Software developer documents includes more detailed description of the functionality to be provided.

  10. Requirements validation • In this process, you are going to check if the requirements are • Real • Consistent • Complete All these process is going to continue during definition and specification.

  11. Software design and implementation • The process of converting the system specification into an executable system. • Software design • Description of the structure of the software to be implemented, the data which is part of the system, interface between system component, and algorithm that realises the specification; • For example: library system • the design will be through of a number of versions. For each time you are going to add details and constrains with backtracking to correct the error in the earlier design. • The design process may involve developing several models of the system at different levels of abstraction.

  12. Software design and implementation • Implementation • Translate this structure into an executable program; • The activities of design and implementation are closely related and may be interleaved.

  13. The software design process

  14. Design process activities • Input to design process • The software interface with other software system • OS, DB, other application program • For example: weather system ( real time system)- input comes from outside DB and application program to feed weather system to retrieve suitable and correct output display • Requirement specification is a description of the functionality the software that must provide

  15. Design process activities • Design activities • Architectural design • Identify the overall structure includes • Sub-system if you used incremental development • Their relationship • How they are distributed • Interface design • Interfaces between components if you use sub-system. The interface specification should must unambiguous to implement them correctly. • Component design • Take each component and design how it will operate; simple statement of expected functionality to be implemented • Data structure design • design database structure and how these are to be presented • It can be existing database or create a new database

  16. Design process activities • Output from design process • Set of design outputs • In OO approach, the output mostly be diagrams and in may cases automatically generate code • In agile method, the output may be represented in the code of program. • Possible models • Object model; • Sequence model; • State transition model; • Structural model; • Data-flow model.

  17. Programming and debugging • Programming is translating a design into a program • There in no general programing process that is usually followed • You may use software development tools (CASE TOOLS) to generate a skeleton program from a design. • You may start from well understood components then move less-understood components or versa vice. • Code the interfaces between these components • debugging is removing errors from that program. • Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.

  18. Programming and debugging • Defect testing and debugging are different processes. • Testing establishes the existence of defects. • Debugging is concerned with locating and correcting these defects. • Testing may involve tracing the program code manually  required new test cases to localize the problem; Or • You may use debugging tools to trace the code and find where are the errors.

  19. The debugging process

  20. 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 customer. • It is check list processing at each stage of the software process • 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.

  21. The testing process

  22. Testing stages • 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.

  23. If an incremental approach to development is used, each increment should be tested as it is developed, • Alpha vs. beta test • Acceptance testing is sometimes called alpha testing. Custom systems are developed for a single client. • When a system is to be marketed as a software product, a testing process called beta testing • Beta testing involves delivering a system to a number of potential customers who agree to use that system

  24. 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 demarcation(limit) between development and evolution (maintenance), this is increasingly irrelevant as fewer and fewer systems are completely new.

  25. System evolution

  26. The Rational Unified Process • A modern process model derived from the work on the UML -an object oriented modeling language - and associated process. • Takes the advantages of three generic processes • Good practice in specification and requirements • Support prototyping and incremental delivery • Normally described from 3 perspectives • A dynamic perspective that shows phases over time; • A static perspective that shows process activities; • A practice perspective that suggests good practice of software development.

  27. 1-RUP phase model(dynamic view)

  28. RUP phases • Identify four discrete phases in software processes ( related to business point of view ) • Phases are • Inception • Establish the business case for the system. • You should identify all external entities (people and systems) that will interact with the system and define these interactions. • Elaboration • Develop an understanding of the problem domain and the system. • establish an architectural framework for the system, develop the project plan and identify key project risks Design use case, an architectural description and development design.

  29. RUP phases • Construction • System design, programming and testing. • Developed in parallel an integrated • system sequence, state machine, and class diagram are design •  software system and their documentation to be ready to deliver to the user. • Transition • Deploy the system in its operating environment. • move the system from software development community to user community •  you should have a documented software system that is working correctly in its operational environment.

  30. 2- Static view • RUP focuses on the activities that take place during the development process • It is called workflows in the RUP description. • There are six core process workflows identified in the process and three core supporting workflows.

  31. Static workflows

  32. 3- RUP good practice • Develop software iteratively based on customer priority • Manage requirements by keep tracking of user changes to their requirements. • Use component-based architectures; system architecture based on component • Visually model software; use graphical UML models to present static and dynamic views of the software.

  33. RUP good practice • Verify software quality;Ensure that the software meets the organizational quality standards. • Control changes to software; Manage changes to the software using a change management system and configuration management procedures and tools

  34. Key points • Software processes are the activities involved in producing and evolving a software system. • Software process models are abstract representations of these processes. • General activities are specification, design and implementation, validation and evolution. • Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering. • Iterative process models describe the software process as a cycle of activities.

  35. 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. • The Rational Unified Process is a generic process model that separates activities from phases. • CASE technology supports software process activities.

More Related