Object oriented system development life cycle

1. Object oriented system development life cycle

2. Software Development Process Software development can be viewed as a process. Development is a process of change, refinement, transformation or addition to existing product. Each process can be divided into small, interacting Sub-processes. must be defined in such a way that each activity be performed as independently as possible from other sub-processes.

3. Each sub-process must have the following • Description in terms of how it works • Specification of input required for the process • Specification of the output to be produced • Software development process can be viewed as a series of transformations, where the output of one transformation becomes the input of the subsequent transformation.

5. Transformation 1 (Analysis) translates user’s need into system’s requirements & responsibilities. how they use system can give insight into requirements, Transformation 2 (Design) begins with problem statement, ends with detailed design that can be transformed into operational system. includes development activity, definition on how to build software, its development, its testing. Also includes design descriptions, programs and testing material. Transformation 3 (Implementation) refines detailed design into system deployment that will satisfy users needs. represents how to embed software product within its operational environment

6. Example of Software Development Process

7. Why Waterfall Model Fails Assumes requirements are known before design begins. Assumes requirements remain static over development cycle. Assumes sufficient design knowledge to build product. Problem , if environment changes.

8. Building High Quality Software High Quality Products • Must meet user's need and expectations. • This should be attained with • minimal or no defects • Concentrate on improving the products (or services) prior to delivery rather than correcting after delivery. To achieve high quality software, we need to be able to answer the following questions. • How do we determine when the system is ready for use? • Is it an operational system that satisfies user's needs? • Is it correct and operating as we thought it should? • Does it pass an evaluation process?

9. Four Quality Measures (By Blum) • Correspondence: measures how well the delivered system matches the needs of the operational environment as described in the original requirements statement. • Validation : Am I building the right product? • Correctness : measures the consistency of the product requirements with respect to design specification. • Verification : exercise of determining correctness. Am I building the product right?

11. Object-Oriented Systems Development: Use-Case Driven Approach • Object-Oriented software development life cycle (SDLC) consists of three macro processes. • Object-Oriented Analysis • Object-Oriented Design • Object-Oriented Implementation

12. OOSDLC • Object-Oriented systems development includes the following activities. • Object-Oriented Analysis – Use Case Driven • Object-Oriented Design • Prototyping • Component Based Development • Incremental Testing

13. Object-Oriented Analysis – Use Case Driven • Concerned with determining the systems requirements and identifying classes and their relationships to other classes in the problem domain. • User need -> System needs -> objects & classes • Scenario's can be used to help analysts understand requirements. • Jacobson's concept of use-case can be used to describe the user-computer system interaction.

14. Object-Oriented Analysis – Use Case Driven • Use Case, is a name for a scenario to describe the user–computer system interaction. • To understand system requirements need to identify • who are the actors ? • How do they use system ? • Use case model represents the user's view of the system or user's needs. • Developing use cases is iterative. • Documentation must also be carried out. It should be as short as possible.

15. 80-20 rule • 80% work can be done with 20% documentation • 20% easily accessible, 80% available to few who needs to know • good modeling implies good documentation

16. Object-Oriented Design • Goal is to design the classes identified during the analysis phase and the user interface. • Additional objects and classes that support implementation of the requirements are also identified and defined. • First, build the object model based on objects and their relationships, then iterate and refine the model: • Design and refine classes • Design and refine methods • Design and refine structures • Design and refine associations

17. Guidelines to use OO Design • Reuse rather than build a new class. • Design a large no. of simple classes rather than a small no. of complex classes. • Fully understand what you have proposed. If possible, go back & refine the classes.

18. Prototyping • A prototype is a version of a software product developed in the early stages of the product's life cycle for specific, experimental purpose. Categories of Prototype • Horizontal Prototype • Is a simulation of the interface but contains no functionality. • Advantages: • Quick to implement. • Provides a good overall feel of the system. • Allows users to evaluate the interface on the basis of their normal, expected perception of the system. • Vertical Prototype • Is a subset of the system features with complete functionality. • Advantages • Few implemented functions can be tested in greater depth.

19. The prototype can be reviewed by end users and management members. Purpose of review • To demonstrate that the prototype has been developed according to the specification and that the final specification is appropriate. • To collect information about errors or other problems in the system. • To give management and everyone connected with the project the glimpse of what the technology can provide.

20. Implementation Move from custom development to assembly from prefabricated components. Can produce large markets, low cost, high quality products. Moving value & differentiation gained by rapid customization to targeted customers.

21. Software component Functional units of programs, building block offering collection of reusable services. Can request service form another component or deliver its own services on request. Delivery of services is independent, components work together to accomplish task. Components may depend on one another without interfering with each other. Each component is unaware of context/inner workings of other components.

22. Implementation: Component Based Development • Industrialized approach to system development, move form custom development to assembly of pre-built, pre-tested, reusable software components that operate with each other. Idea of CBD: • Application development improved significantly if applications assembled quickly from prefabricated software components. • Increasingly large collection of interpretable software components could be made available to developers in both general & specialist catalogs.

23. Incremental Testing After each phase carry out the testing process to detect bugs if any. This reduces the overall time and cost.

24. Reusability • Major benefit of OO system development. • For objects to be reusable, much effort must be spent in designing itself. • Effectively evaluate existing software components for reuse • Has my problem been solved ? • Has my problem been partially solved ? • What has been done before to solve problem similar to this one ? Benefits • Increased reliability. • Reduced time and cost for development • Improved consistency

25. Reuse Strategy Information hiding. Conformance to naming standards. Creation & administration of an object repository. Encouragement by strategic management of reuse as opposed to constant redevelopment. Establish target for percentage of the objects in the project to be reused.