Object oriented systems development life cycle

1. Object oriented systems development life cycle Software development process that consists of analysis, design, implementation, testing and refinement is to transform users needs into a software solution that satisfies those needs

2. Software development process • System development can be viewed as process. • The process can be divided into small, interacting phases sub-processes . The sub processes must be defined in a such way that are clearly spelled out, to allow each activity to be performed as independently • EACH SUB PROCESS MUST HAVE THE FOLLOWING

3. A description in terms of how it works. • Specification of the input required for the process • Specification of the output to be produced Software process can be viewed as a series of transformations

4. Where the output of one transformation becomes the input of the subsequent transformation. • In the first transformation, we translate the user’s requirement in to system requirements and responsibilities. We produce a software requirement specification (SRS). This is analysis phase.

5. In the second transformation the SRS is translated into a detailed design. • The detailed design should satisfy the user’s requirements and, at the same time , be sufficiently detailed to do the third transformation-produce a deployable product. • This includes equipment, procedures, people • This transformation also include how to embed the software developed within its operational environment-os, dbms, networking systems, etc

6. Problem statements Analysis Trans I What are the uses of the system Trans II Trans III Design Implementation Detail System Software Product

7. Example of software development process • Water Fall Model • Which starts with deciding • What is to be done (what is the problem) • Once the requirements have been determined , we next must decide • How to accomplish them.

8. This is followed by a step in which we do it , whatever ‘it’ has required us to do. • We then must test the result to see if we have satisfied the user’s requirements • Finally , we use what we have done

9. What How Do it Test Use

10. Building high-quality software • To achieve high quality in software we need to be able to answer the following questions • How do we determine when the system is ready for delivery? • Is it how an operational system that satisfies user’s needs? • Is it correct and operating as we thought it should? • Does it pass an evaluation process?

11. There are two basic approaches to system testing • Blum describes a means of system evaluation in terms of four quality measures: • Correspondence • Validation • Correctness • Verification

12. Correspondence measures how well be delivered system matches the needs of the operational environment , as described in the original requirement statements. • Validation is the task of predicting correspondence . True correspondence cannot be determined until the system is in the place.

13. Correctness measures the consistency of the product requirements with respect to the design specification . • Verification is the exercise of determining correctness. However correctness is the always objective.

14. Verification: Am I building the product right? • Validation: Am I building the right product.

15. Validation Verification Needs Requirements Design software Correctness Correspondence

16. Object-oriented systems development : A use case Driven Approach Object-oriented –use case driven Object-oriented design Prototyping Component-based development Incremental testing

17. Object-oriented design • The goal object-oriented design is to design the classes identified during the analysis phase and the user interface. • During this phase , we identify and define additional objects and classes that support implementation of the requirements.

18. Design and refine classes. • Design and refine attributes. • Design and refine methods. • Design and refine structures. • Design and refine associations.

19. Few guidelines • Reuse, rather than build, a new class. know the existing classes. • Design a large number of simple classes, rather than a small number of complex classes. • Design methods. • Evaluate What you have proposed. If possible , go back and refine the classes

20. Prototyping • A prototype is a version of a software product developed in the early stages of the product’s life cycle for specific, experimental purposes. • A prototype enables you to fully understand how easy or difficult it will be to implement some features of the system.

21. Types • A horizontal prototype is a simulation of the interface ( that is, it has the entire user interface that will be in the full-features system.) but contains no functionality. • This has the advantages of being very quick to implement

22. A vertical prototype is a subset of the system features with complete functionality. • The principal advantage of this method is that the few implemented functions can be tested in great depth.

23. Analysis prototype is an support for exploring the problem domain. • This class of prototype is used to inform the user and demonstrate the proof of a concept.

24. A Domain prototype is an support for the incremental development of the ultimate software solution.

25. Component Based Development • CBT is an industrialized approach to the software development process. • Application development moves from custom development to assembly of pre built, pre tested, reusable software components

26. Two basic ideas • The application development can be improved significantly if applications can be assembled quickly from prefabricated software components • Second, an increase large collection of interpretable software components could be made available to developers in both general and specialist catalogs.

27. Software components are the functional units of program, building blocks offering a collection of reusable services

28. Rapid Application development RAD is a set of tools and techniques that can be used to build an application faster than typically possible with traditional methods. The developer should scarifies the quality of the product for a quicker delivery

29. The main objective of RAD is to build a version of an application rapidly to see whether we actually have understood the problem analysis. • RAD involves number of iterations.

30. Incremental testing • If you wait after development to test an application for bugs and performance. • You could be wasting thousands of dollars and hours of time. • Our testing was very complete and good, but it was costing a lot of money and would add months onto a project • The problem was that developers would turn over applications to a quality assurance group for testing only development was competed

31. Reusability • A major benefit of object oriented system development is reusability • Has my problem already been solved? • Has my problem been partially solved? • What has been before to solve a problem similar to this one? • Summary information about existing software components

32. The reuse strategy can be used on the following • Information hiding (encapsulation). • Conformance to naming standards. • Creation and administration of an object repository. • Encouragement by strategic management of reuse as opposed to constant redevelopment. • Establishing targets for a percentage of the objects in the project to be reused.(50 percent of reuse of objects)