1. RAD( Rapid application development ) Model RAD is a linear sequential development process model that emphasis an extremely short development cycle. Rapid development is achieved by using a component based construction approach. The RAD model is useful if requirements are well understood and project scope is constrained (controlled ).

2. Phases of RAD Model Business Modeling The information flow among business functions is modeled in a way that answers the following questions 1. What information drive the business? 2. What information is generated? 3. Who generates it? 4. Where does the information go? 5. Who processes it?

3. Data Modeling The above model is refined into a set of data objects that are needed to support the business. The attributes of each object are identified and relationships b/w these objects are defined Process Modeling The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, deleting, modifying or retrieving a data object

4. Application Generation I n RAD usually 4 th generation techniques are used rather than conventional techniques The RAD process works to reuse existing program components ( when possible ) or create reusable components ( when necessary ) For the construction of s/w CASE tools are used Testing and Turnover Testing cost is reduced as we use reuse components which are already tested so testing cost is reduced New components must be tested and all interfaces must be fully exercised

5. Team #1 team # 2Team #3 Business Data process application Testing &turnover Business Data process application Testing &turnover Business Data process application Testing &turnover

6. Drawbacks of RAD For large but scaleable projects, RAD requires sufficient resources to create the right number of RAD teams RAD requires developers and customers who are committed to the rapid fire activities necessary to complete the system in a much abbreviated time frame. If commitment is lacking from either constituency, RAD projects will fail

7. RAD is not appropriate when technical risk are high If a system can not be properly modularized, building the components necessary for RAD will be problematic

8. Evolutionary Development Model Closely related to the code-and-fix style adopted by many students for solving programming assignments... Code an initial rough guess at what the customer wants, along with some initial documentation Get them to critique (analyze ) it Go back and revise the code and documentation keep repeating the cycle until everyone is satisfied

9. Advantages not all the requirements need be known up front high risk issues (new technologies, experimental designs, unclear requirements) can be addressed early interim versions allow early and effective customer feedback and effectively demonstrate functionality even if time or money runs out, some operational capability is provided by the existing version

10. Disadvantages cost, time, and resource estimation is difficult, and progress is difficult to measure, cannot be successful without user involvement and cooperation, there is a risk of never-ending evolution

11. The evolutionary approach is probably most applicable when requirements are not well defined or understood, or are likely to undergo significant changes new or unproven technologies are being introduced, system capabilities need to be demonstrated for evaluation by users, there are various (diverse) user groups with potentially conflicting needs

12. Incremental Model This approach is often used to maintain greater managerial control over a product while still providing the customer with some functionality in a short time frame. The idea is to choose a minimum subset of the requirements, and apply a waterfall (or similar) model to implement this subset. Once the process for the first subset is well underway, you begin planning a new version - based on the original - which incorporates more of the desired features. When the new version is well underway you begin planning a subsequent version, etc.

13. This style is very popular in the development of software for general public consumption. It has the following advantages compared to either the pure waterfall model or the pure evolutionary model there is a reduced chance of schedule slips, requirements changes, and acceptance problems (due to the fact that you are only operating on a subset of the requirements at any given time) there is a relatively short time-to-market for the initial version, it is more manageable than a pure evolutionary model,

14. it allows developers to defer the development of poorly understood requirements until later releases, by which time those requirements should be clearer customer feedback on the original release allows improvements for later releases, improving customer satisfaction, subsequent versions can be regularly released with new functionality add new functionality and address concerns found with earlier versions.

15. The main disadvantages with this method are most requirements must be known - at least generally, since the initial design must be such that all the requirements can eventually be addressed it is slower to get the "full featured" version delivered, it can be difficult to maintain backward compatibility with earlier versions of the product configuration control (managing the different product versions and documentation, and changes to each) becomes more complex and adds increased overhead to the project

16. This incremental approach is probably most appropriate when the project is similar to projects which have previously been completed successfully most requirements are stable and well understood the project duration is more than one year, or the customer needs interim (temporary ) releases

17. Risk based OR Spiral Model Assessment of management Risks at regular stages in the project and the initiation of Actions to counteract them It accommodate other models as and when required depending upon the goals; Prototyping for uncertain requirements, Waterfall for documents, Formal transformation for safety critical system

18. Major activities in Spiral model There are four major activities, each represented by a quadrant Planning – determine objectives, alternatives and constraints Risk Analysis – evaluate Alternatives, identify and resolve risks Engineering – Develop verify ‘next level’ product Customer evaluation – Assess engineering results and plan for the next phase

19. Outer the Spiral, more complete would be the model of the system, and more development activity In engineering phase More realistic approach for large scale systems Evolutionary approach provide better comprehension to developer and customer to identify and resolve the risks at respective levels Technical risks considered and resolved before they become problematic

20. Problems New, not well tested and widely used as waterfall or prototyping Risk assessment expertise required to control evolutionary approach – hard to find or justify for large systems Lack of confidence to apply it for large systems

21. Fourth Generation Techniques Features of 4 th generation techniques are Database query Report generation Data manipulation Screen interaction Code generation Graphics

22. Steps involved in 4GL model are Requirement gathering Design strategy For smaller scale s/w applications, it is possible to directly move from requirement gathering step to implementation step using non-procedural 4 th generation language, but for large projects design phase is crucial to avid poor quality,poor maintainability. Implementation using 4GL Product

23. Requirement analysis (RA) RA is the process of discovering, refinement, modeling and specification in a s/w project RA provides the s/w designer with a representation of information and function that can be translated to data, architectural and procedural design S/w specification, a formal document that specify the functional and performance requirements of the s/w

24. Objective of RA Specify s/w function and performance Indicate s/w interfaces with other system elements Establish design constraints that the s/w must meet

25. Analysis tasks There are five major analysis tasks Problem recognition Evaluation and synthesis Modeling Specification Review

26. Problem Recognition Goal of analyst here is recognition of basic problem of elements as perceived by user and customer Understand s/w in system context Define s/w scope Analyst will also need to establish the contact with management and technical staff of the customer

27. Evaluation and synthesis Analyst must now evaluate the flow and content of information Define and elaborate all s/w functions Understand s/w behavior in the context of events that affect the system Establish system interface characteristics Uncover design constraints Throughout this step, the emphasis is on what must be done, not how it will be done This step will continue until both the analyst and customer feels confident that s/w can be adequately specified for subsequent development steps

28. Modeling The analyst will than create models of the system that will enable better understanding of data and control flow The models describe the data and control flow, functional processing and information content Models serve a number of important role Help in understanding the information, function and behavior of the system Makes RA task easier and more systematic Become the focal point for review Becomes the foundation for design

29. Specification The specification is a representation of s/w that can be reviewed and approved by the customer Specification is the means of translating the ideas in the minds of the clients(the input), into formal documents (the output of requirement). Specification is developed as a joint effort b/w the developer and customer

30. Review Review of analysis document Review should first be conducted at a macroscopic level Review is conducted by customer and developer Review results I modifications to Functions Performance Information representation Constraints Validation criteria

31. Specification Principles Principles has been developed by Balzer and Goldman in order to help the development of specification 1. Separate functionality from implementation A specification is a description of what you want(I.e you specify), as opposed to how it is realized (implementation). 2. A specification must encompass the system of which the s/w is component System is made up of components Specification must be made in context of entire system and interaction b/w its parts 3. A specification must encompass the environment in which the system operates The environment in which the system operates and how it interacts with must be specified

32. 4. A specification must be a cognitive model Basically, it means that the specification must describe a system as perceived by its user community 5. A specification must be operational The specification must be complete and formal enough such that it can satisfy an implementation of some arbitrary test cases 6. A specification must be tolerant of incompleteness and augmentable The specification must be robust enough to undergo changes,expansions

33. 7. A specification must be localized and loosely coupled Localized means to affect one piece only Loosely coupled means that parts can be added or removed easily The specification must be such that its content and structure should be able to accommodate dynamic changes