Y.P.

Sreedevi

Y.P.Sreedevi

ASSIGNMENT-2

Q. Explain the purpose and various phases of the systems development life cycle (SDLC)
SDLC stands for Software Development Life cycle. To manage the various phases of software development and to enable programmers, testers and users to work together on complex and big projects; various software development life cycles have been created. The most common used software models are: Waterfall. Spiral. Prototyping. The oldest and the most commonly used of these software models is the waterfall model. It describes a development method that is both linear and sequential. The major stages included in this model are as follows Requirement Analysis. Specification. Coding. Verification and validation. Implementation/installation. Maintenance and support. Waterfall model should not be used when rapid development is required. For this purpose spiral model has been introduced which is more risk reduction oriented. The various phases of spiral model are as follows 1. Identify objectives and constraints. 2. Identify risks and ways to and resolve them. 3. Evaluate the various alternatives. 4. develop and verify various alternatives. 5. Plan the next iteration. 6. Decide an approach for the next iteration. This a very complex software model and should be followed by a knowledgeable management. Prototyping using incremental approach in all the phases of software development such as requirement gathering etc. these are then analyzed by the end user, their response results in next iteration

Y.P.Sreedevi

Q. Explain the differences between a model, a tool, a technique, and a methodology Model: A software process model is an abstract description of a piece of software. The software itself is an actual program (or set of programs) which can run on your computer. Method and methodology Methodology can properly refer to the theoretical analysis of the methods appropriate to a field of study or to the body of methods and principles particular to a branch of knowledge. It is a collection of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods; For example, "Since students were not available to complete the survey about academic success, we changed our methodology and gathered data from instructors instead". In this instance the methodology (gathering data via surveys, and the assumption that this produces accurate results) did not change, but the method (asking teachers instead of students) did. On other hand, Method implies a detailed, logically ordered plan. It is process by which a task is completed; a routine. It is the study of a specific field of inquiry employed by or proper to particular discipline or art. The procedures and techniques are characteristic of a particular discipline or field of knowledge. It is Means or manner of procedure, especially a regular and systematic way of accomplishing something: A simple method for making a pie crust; mediation as a method of solving disputes. It is also known as a systematic procedure, technique or orderly arrangement of parts or steps to accomplish an end. The transformation of method into methodology is something to strive for in the process of becoming an aware systems practitioner. Tool: Tool: Something used in the performance of an operation; an instrument to do some kind of work, among other things, A device, used to perform or facilitate manual or mechanical or mental benefit in accomplishing a task. Most tools use some form of simple machine, or a combination of them, such as a diagram. Technique: Technique: The systematic procedure by which a complex or scientific task is accomplished by skillful, ability and detailed method of executing procedures to accomplish a desired result. Also it is method of performance of manipulation in any art; such as drawing a diagram in a prescribed manner. For example, spray diagram for particular case study. I regard this as a tool. With practice it becomes a technique Anonymous

Q. Explain the differences between Waterfall SDLC and RUP SDLC The waterfall lifecycle goes through a series of phases 1. 2. 3. 4. 5. requirements (system requirements, then software requirements) requirements analysis software design coding and unit testing integration

Y.P.Sreedevi 6. system test 7. operations There is minimal feedback from one phase to another. Also, there is often only a small set of artifacts (also called "work products," which can include documents, models, or code) that is produced in each phase, validated at the end of the phase, and then used as input for the next phase. These artifacts are considered complete, almost frozen, and revisited only to fix a major issue. A Waterfall Lifecycle Of paramount importance for certain projects is the issue of freezing the requirements specifications (together with some high-level design) in a contractual arrangement very early in the lifecycle, prior to engaging in more thorough design and implementation work. This is the case when an organization has to bid a firm, fixed price for a project. In the iterative lifecycle model, artifacts are in some ways "grown" or "refined," from one cycle of the spiral to another. They are not thrown away or frozen, but rather expanded. The early iterations produce a very small system, which gradually expands over a series of iterations to become the complete system. Feedback takes place from one iteration to the next.

An Iterative Development Lifecycle The Rational Unified Process The RUP offers two major components to a software development organization: 1. A flexible, iterative lifecycle that must be tailored by the project manager to the exact project circumstances. 2. A set of recipes: techniques, templates, "job" descriptions, and tools that will guide the software developers in their daily work. The iterative lifecycle is of importance mostly for the project manager in setting up the project plan. The two major components of the RUP the lifecycle and the "how to" or guidance are not completely tied together. If you wish, you can adopt the RUP lifecycle and some of the techniques, or you can adopt most of the techniques but not the lifecycle.

Y.P.Sreedevi

Iterative Lifecycle: Iterations, Builds, and Phases

The objectives of the iteration are defined, and the iteration is planned. Requirements are further refined and analyzed. The design is expanded. Code is written, then tested. The (partial) system is then integrated and tested (note that this may occur over several builds, which are like mini-iterations inside the iteration). The iteration is assessed, and lessons learned are folded into the plan for the next iteration.

What characterizes an iteration is that at the end there is a release internal or external of the software product, which is used to objectively assess the outcome of the iteration, and therefore the progress of the project. In an iterative lifecycle, you have a succession of such iterations, each ending in a partially implemented product. In practice, iterations will vary slightly in focus and content across the iterative lifecycle: Early iterations focus primarily on exploring ideas, consolidating requirements, putting the architecture in place, and getting feedback from stakeholder(s), whereas later iterations focus on making the software product complete and robust. Therefore, the iterative lifecycle of the RUP is partitioned in a different set of phases than the waterfall lifecycle. These new phases cannot be named after a type of activity (such as "design"), since these activities will be repeated, or a kind of artifact (such as "requirement"), since the artifacts will be evolving over several iterations and phases. The phases of the RUP are organized and named primarily for what is achieved. 1. Inception phase: Scope the project, define the business case. 2. Elaboration phase: Refine the requirements, establish an architecture, mitigate the most technical risk. 3. Construction phase: Complete the system up to a point where it can be deployed in limited context ("beta version"). 4. Transition phase: Finish the product and reach product final release. Each phase has zero, one, or more iterations, but generally at least one. The RUP has guidelines and heuristics on how to define phases, iterations, number and duration of iterations, and iteration objectives. "typical" RUP lifecycle, with 1+2+3+2 = 8 iterations.

Y.P.Sreedevi

In the Inception phase (or stage):

Develop the Vision, the Business Case. Develop a Project Plan. Compile a Software Development Plan. Schedule and assign work. Develop the requirements (use case, nonfunctional requirements).

Optionally, you can add activities from the business modeling discipline to feed into the requirements work. In the Elaboration phase:

Further refine the requirements. Design the architecture. Design each subsystem. Design the tests.

In the Construction phase:

Implement the various components and test them. Integrate each subsystem. Test the subsystems. Integrate the systems. Test the overall system, for different classes of test. Plan the deployment. Develop collateral (user documentation, and so on). Release the system.

Y.P.Sreedevi

In the Transition phase:

Fix whatever needs to be fixed. Repeat the activities in the Construction phase.

So, in a sense, the planning and scheduling job is easier here than for the full iterative case. You do not have to worry about iteration planning, end of iteration reviews and assessment, and rescheduling the same activity multiple times across several iterations. In a tailored combination of waterfall and RUP, a handful of project management activities and guidelines are merged. Some artifacts specific to iteration disappear. Most supporting activities of the RUP are not affected: You will still use configuration and change management, as well as project monitoring. While running (enacting) this WUP (or single-iteration RUP), the team members following guidance of the RUP will hardly notice a difference, since each artifact or activity is not described in terms of a given iteration. Only a handful of activities in project management explicitly mention iterations: iteration review and iteration plan, for example. And if there is the occasional instruction to "do X in the next iteration," the team can simply remember that it is "as if" they were in the last iteration of the Construction phase. (They are, in fact.)

In aligning the waterfall lifecycle with the RUP, it seems that we have thrown away the RUP number one best practice: Develop iteratively. What is happening with the other best practices? Develop Software Iteratively We may have limited the concept of formal iterations, but we can keep some of the underlying principles to mitigate risks. In particular, start performing regular builds (weekly, daily, depending on the size of the team) as early as you can, to stay on top of events, provide something concrete with which to start the testing effort, and provide feedback to everyone involved. Don't wait until very late in the development process to start integrating. Dedicate some staff to drive the regular build process. Also, as noted above, develop some prototypes early, while elaborating the requirements, such as user-interface prototypes. Manage Requirements You may have finalized them very early, but you still need to trace them to the design and the tests, to refine or clarify them, and to manage the scope when things get tough. Use Component-based Architectures It is hard to develop and validate a new architecture; many projects either just use an existing architecture from another project or acquire one externally.

Y.P.Sreedevi

Visually Model Software There is nothing specific to iterative development in using the Unified Modeling Language (UML) to document your design. Continuously Verify Software Quality You may have a test phase late in the waterfall lifecycle, but this should not stop you from starting test planning and development, and executing a growing set of tests on partial builds as early as you possibly can. Control Changes to Software Change control is not specific to iterative development. Although artifacts are not modified as frequently in the waterfall approach, you need a consistent strategy and tools to keep track of artifacts. Align the Team Structure to the Product Architecture To the original six best practices, I will add this one about organization. One of the mistakes I've seen in "waterfall strongholds" is that they often align the teams with the waterfall phases (that is, the RUP disciplines). As you can see in Figure 9, they have:

A requirements team, which throws the finished Requirements Specs over the wall to A design team, which, when "done," throws a complete and reviewed design to A programming team, which, after unit testing, throws the code to An integration team and a testing team which will take all the blame for being late to deliver.

The RUP iterative lifecycle and the waterfall lifecycle are not incompatible approaches, and an organization can adopt the practices of the RUP within a waterfall lifecycle. The RUP activities, artifacts, and roles apply to both iterative and waterfall project processes. A true "hard-nosed" waterfall lifecycle introduces a number of risks to software projects, risks that could be mitigated by adopting an iterative lifecycle. There are halfway solutions for the adoption of an iterative lifecycle in which the internal process differs from the external and visible process. Such

Y.P.Sreedevi approaches help adopting organizations improve their internal development processes while keeping the customers and external stakeholders happy. Although it is possible to use the RUP in a purely waterfall approach, some words of warning should be given: "You never get it right first time"; "Requirements will change"; and "Give people a chance to learn." A waterfall approach ignores these factors and assumes that it is possible to get everything right the first time. Practitioners accept that this is not the case and therefore often describe their project as waterfall, but within it provide for a number of iterations (beta programs, phase two, prototyping, and so on). With the advent of software development, software is required to be both higher quality and delivered faster. These two opposing forces, coupled with the inherent complexity of an "esolution," require improved ways of working. Often these improved processes cannot be adopted instantly, and thus less bold solutions are required in the interim. The RUP provides a solid framework for a sensible adoption process. It allows an organization to implement certain aspects of the process in a controlled manner, and at a pace that is appropriate. Combined with that flexibility is a set of standards. These standards help ensure consistency consistency that is crucial to successful enterprise process adoption. Let me leave you with these parting thoughts:

The RUP is a very flexible process framework that can be customized to a wide variety of situations. The waterfall lifecycle is never really fully waterfall, especially when there are risks and unknowns to address. To help map RUP process guidance, the waterfall lifecycle can be seen as a very simplified iterative lifecycle with only one or two iterations. With a bit of creative thinking, a moderately iterative approach can be made to "appear" as a waterfall framework, if that is the externally imposed development approach.

Q. Summarize the activities associated with the planning phase in the SDLC Phase-I Planning

. Involves establishing a high-level plan of the intended project and determining project
goals

. Primary planning activities include

1. Identify and select the system for development 2. Assess project feasibility 3. Develop the project plan
Identify and Select the System for Development

Y.P.Sreedevi

Organizations use different forms of evaluation criteria to determine which systems to develop Critical success factor (CSF) a factor that is critical to an organizations success

Assess Project Feasibility Feasibility study determines if the proposed solution is feasible and achievable from a financial, technical, and organizational standpoint Different types of feasibility studies Economic feasibility study Operational feasibility study Technical feasibility study Schedule feasibility study Legal and contractual feasibility study

Develop the Project Plan Developing the project plan is a difficult and important activity

Y.P.Sreedevi
The project plan is the guiding force behind on-time delivery of a complete and successful system Continuous updating of the project plan must be performed during every subsequent phase during the SDLC

Summarize the activities associated with the analysis phase in the SDLC

PHASE 2: ANALYSIS Analysis phase involves analyzing end-user business requirements and refining project goals into defined functions and operations of the intended system Primary analysis activities include: 1. Gather business requirements 2. Create process diagrams 3. Perform a buy vs. build analysis Gather Business Requirements Business requirements the detailed set of business requests that the system must meet in order to be successful Different ways to gather business requirements Joint application development (JAD) session where employees meet to define or review the business requirements for the system Interviews Questionnaires Observations Review business documents

The system users review the requirements definition document and determine if they will signoff on the business requirements Requirements definition document contains the final set of business requirements, prioritized in order of business importance

Y.P.Sreedevi
Sign-off the system users actual signatures indicating they approve all of the business requirements

Create Process Diagrams Process modeling graphically representing the processes that capture, manipulate, store, and distribute information between a system and its environment Common process modeling diagrams include Data flow diagram (DFD) illustrates the movement of information between external entities and the processes and data stores within the system Computer-aided software engineering (CASE) tools automate systems analysis, design, and development

Perform a Buy vs. Build Analysis An organization faces two primary choices when deciding to develop an information system 1. Buy the information system from a vendor Commercial off-the shelf (COTS) software package or solution that is purchased to support one or more business functions and information systems SCM, CRM, and ERP solutions are typically COTS

2. Build the information system itself Organizations must consider the following when making a buy vs. build decision: 1. Are there any currently available products that fit the needs? 2. Are there features that are not available and important enough to warrant the expense of in-house development? 3. Can the organization customize or modify an existing COTS to fit its needs? 4. Is there a justification to purchase or develop based on the acquisition cost? Three key factors an organization should also consider when contemplating the buy vs. build decision 1. Time to market 2. Availability of corporate resources 3. Corporate core competencies

Y.P.Sreedevi
Q. Summarize the activities associated with the Design phase in the SDLC PHASE 3: DESIGN Design phase involves describing the desired features and operations of the system including screen layouts, business rules, process diagrams, pseudo code, and other documentation Primary design activities include: 1. Design the IT infrastructure 2. Design system models Design the IT Infrastructure Sample IT infrastructure

Design System Models Modeling the activity of drawing a graphical representation of a design Different modeling types include: Graphical user interface (GUI) GUI screen design Data model

Y.P.Sreedevi
Entity relationship diagram (ERD)

Design System Models Sample entity relationship diagram (ERD)

Q. Summarize the activities associated with the development phase in the SDLC PHASE 4: DEVELOPMENT Development phase involves taking all of the detailed design documents from the design phase and transforming them into the actual system Primary development activities include: 1. Develop the IT infrastructure 2. Develop the database and programs Development 1: Develop the IT Infrastructure 1. The platform upon which the system will operate must be built prior to building the actual system 2. In the development phase, the organization purchases and implements the required equipment to support the IT infrastructure Development 2: Develop the database and programs 1. Once the IT infrastructure is built, the organization can begin to create the database and write the programs required for the system 2. IT specialists perform the majority of the tasks associated with the development phase

Q. What are the phases in SDLC?

Various phases of SDLC are to be pursued in order to gain a better view of how a project could be handled. The phases of SDLC include requirements gathering and analysis, system designing, development, testing, operations and maintenance. Requirements gathering and analysis: Under this phase, the project's goal is determined and the functions are brought to focus. Gathering of information and analysis of the user's requirement is also done in this phase. System design: A sample structure of the entire project is created in this phase and all necessary data are gathered.

Y.P.Sreedevi Development: Coding of the whole project is done in this phase. Codes are easily generated if proper design is performed in the previous stage. According to the needs of the application, programming language is selected. System testing: After the generation of codes, testing of all the modules is performed. All modules are integrated together and proper testing tools are selected for error checking. Operations and maintenance: Under the final stage of SDLC, the developed software is given to the users. Maintenance is necessary after the development of a successful project. It is obvious that changes occur once the project is handed over to the end user. The developers must develop the project in such a way that it is adaptable to those changes. The main operation of the software must not be affected by those changes. It is necessary for the client to be aware of all the phases of SDLC so that they can get to know about the status of the project under proposal. The client must also be aware of various operations performed under various stages. This would enable them to handle the project with ease. This also helps them to collect good quality products. Only when the clients are aware of the stages of SDLC, they can sort out the problems that arise while using the product. This would thus produce a good quality product.

(OR)

Various phases of SDLC are to be pursued in order to gain a better view of how a project could be handled. The phases of SDLC include requirements gathering and analysis, system designing, development, testing, operations and maintenance. Requirements gathering and analysis: Under this phase, the project's goal is determined and the functions are brought to focus. Gathering of information and analysis of the user's requirement is also done in this phase. System design: A sample structure of the entire project is created in this phase and all necessary data are gathered. Development: Coding of the whole project is done in this phase. Codes are easily generated if proper design is performed in the previous stage. According to the needs of the application, programming language is selected. System testing: After the generation of codes, testing of all the modules is performed. All modules are integrated together and proper testing tools are selected for error checking. Operations and maintenance: Under the final stage of SDLC, the developed software is given to the users. Maintenance is necessary after the development of a successful project. It is obvious

Y.P.Sreedevi that changes occur once the project is handed over to the end user. The developers must develop the project in such a way that it is adaptable to those changes. The main operation of the software must not be affected by those changes. It is necessary for the client to be aware of all the phases of SDLC so that they can get to know about the status of the project under proposal. The client must also be aware of various operations performed under various stages. This would enable them to handle the project with ease. This also helps them to collect good quality products. Only when the clients are aware of the stages of SDLC, they can sort out the problems that arise while using the product. This would thus produce a good quality product.

Q. Describe the two overall approaches used to develop information systems: the traditional method and the object-oriented method Traditional Predictive Approach to the SDLC Project planning initiate, ensure feasibility, plan schedule, obtain approval for project Analysis understand business needs and processing requirements Design define solution system based on requirements and analysis decisions Implementation construct, test, train users, and install new system

Y.P.Sreedevi
Support keep system running and improve Information

System Development Phases Object-Oriented Approach Completely different approach to information systems Views information system as collection of interacting objects that work together to accomplish tasks Objects things in computer system that can respond to messages Conceptually, no processes, programs, data entities, or files are defined just objects OO languages: Java, C++, C# .NET, VB .NET

Q. What is a RAD model?

Rapid application development

Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive preplanning generally allows software to be written much faster, and makes it easier to change requirements. Rapid application development is a software development methodology that involves methods like iterative development and software prototyping. In rapid application development, structured techniques and prototyping are especially used to define users' requirements and to design the final system. The development process starts with the development of preliminary data models and business process models using structured techniques. In the next stage, requirements are verified using prototyping, eventually to refine the data and process models. These stages are

Y.P.Sreedevi repeated iteratively; further development results in "a combined business requirements and technical design statement to be used for constructing new systems". RAD approaches may entail compromises in functionality and performance in exchange for enabling faster development and facilitating application maintenance. Rapid application development was a response to non-agile processes developed in the 1970s and 1980s, such as the Structured Systems Analysis and Design Method and other Waterfall models. One problem with previous methodologies was that applications took so long to build that requirements had changed before the system was complete, resulting in inadequate or even unusable systems. Another problem was the assumption that a methodical requirements analysis phase alone would identify all the critical requirements. Ample evidence[citation needed] attests to the fact that this is seldom the case, even for projects with highly experienced professionals at all levels. Although most RAD methodologies foster software re-use, small team structure and distributed system development, most RAD practitioners recognize that, ultimately, no one rapid methodology can provide an order of magnitude improvement over any other development methodology. All types of RAD have the potential for providing a good framework for faster product development with improved software quality, but successful implementation and benefits often hinge on project type, schedule, software release cycle and corporate culture. It may also be of interest that some of the largest software vendors such as Microsoft and IBM do not extensively use RAD in the development of their flagship products and for the most part, they still primarily rely on traditional waterfall methodologies with some degree of spiraling. Since rapid application development is an iterative and incremental process, it can lead to a succession of prototypes that never culminate in a satisfactory production application. Such failures may be avoided if the application development tools are robust, flexible, and put to proper use. This is addressed in methods such as the 2080 Development method or other postagile variant (OR)
Rapid Application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle (anywhere from 60-90 days). The RAD model is a high-speed adaptation of the linear sequential model / Waterfall model. The RAD approach encompasses the following phases:

Business Modeling
The information flow among business functions is modeled in a way that answers the following questions: What information drives the business processes? What information is generated?

Y.P.Sreedevi

Who generates it? Where does the information flow? Who processes it?

Data Modeling
The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics called attributes of each objects are identified and the relationships between the objects are then defined.

Process Modeling
The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement the business functions. Processing descriptions are created for adding, modifying, deleting or retrieving a data object.

Application generation
RAD assumes the use of fourth generation techniques. Rather than creating software using conventional third generation programming languages, RAD process works to use the automated tools to facilitate the construction of the software.

Testing and turnover

Since the RAD processes emphasize reuse, many of the program components have already been tested. This saves time, money and the overall time to test an application also reduces considerably.

What are Disadvantages of Prototype Model?

Producer might produce a system inadequate for overall organization needs * User can get too involved whereas the program can not be to a high standard * Structure of system can be damaged since many changes could be made * Producer might get too attached to it (might cause legal involvement){{Verify source|date=April 2007}} * Not suitable for large applications

Y.P.Sreedevi * Over long periods, can cause loss in consumer interest and subsequent cancellation due to a lack of a market (for commercial products) * Insuffuient analysis *Expense of implementing prototyping *Excessive development time of the prototype Q. What is difference between iterative model and waterfall model?

Waterfall Development
1. Waterfall Development is another name for the more traditional approach to software development. 2. Its called waterfall as this type of development is often planned using a Gantt chart you complete one phase (e.g. planning) before moving on to the next phase (e.g. development). 3. In Waterfall approaches, you will rarely aim to re-visit a phase once its completed. As such, you better get whatever youre doing right the first time! 4. This approach is highly risky, often more costly and generally less efficient than more Agile approaches. The main issues with this approach include:

You dont realize any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development) You leave the testing until the end, which means youre leaving issue discovery until late in the day You dont seek approval from the stakeholders until late in the day their requirements might have changed Youre heavily reliant upon a plan, which you can/will often follow to the detriment of the end result Youre heavily reliant upon a project manager driving the way the power of one

Iterative Development
This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches. The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features. The most commonly occurring issue in this type of scenario (in my experience) is bottle necking. For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing. Another common symptom of this type of approach is over-

Y.P.Sreedevi commitment. Its really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way. Youre more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) this doesnt work as the phases are not separate, theyre totally intertwined. For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases. Its also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment you dont benefit from early-warning-signs as you dont find out whether youre on track until the end of the sprint. Q. What is the difference between iterative model and prototype model? Iterative model: In this u can come back to previous phases, and make the changes accordingly. In this we reviewed a final output product at the end of the SDLC. Prototype Model: Here, we received Prototypes of the product, before the final release. We release 4-5 Prototypes with some differences b/w them, and take client opinion, and modifies the final Product, as per client suggestions.

Q. What is meant by Waterfall Model? The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and Theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

Y.P.Sreedevi

Q. What is spiral model? The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. 1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. 2. A preliminary design is created for the new system. 3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. 4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype. 5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. 6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. 7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. 8. The final system is constructed, based on the refined prototype. 9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Q. What are advantages and disadvantages of Prototype Model? Advantages:

Reduced time and costs: Prototyping can improve the quality of requirements and specifications pro Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in

Y.P.Sreedevi
development, the early determination of what the user really wants can result in faster and less expensive software. vided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software. Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications. The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said. Since users know the problem domain better than anyone on the development team does, increased interaction can result in final product that has greater tangible and intangible quality. The final product is more likely to satisfy the users desire for look, feel and performance.

Dis-Advantages: Insufficient analysis: The focus on a limited prototype can distract developers from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain. Further, since a prototype is limited in functionality it may not scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if developers are too focused on building a prototype as a model. User confusion of prototype and finished system: Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. (They are, for example, often unaware of the effort needed to add error-checking and security features which a prototype may not have.) This can lead them to expect the prototype to accurately model the performance of the final system when this is not the intent of the developers. Users can also become attached to features that were included in a prototype for consideration and then removed from the specification for a final system. If users are able to require all proposed features be included in the final system this can lead to conflict. Developer misunderstanding of user objectives: Developers may assume that users share their objectives (e.g. to deliver core functionality on time and within budget), without understanding wider commercial issues. For example, user representatives attending Enterprise software (e.g. PeopleSoft) events may have seen demonstrations of "transaction auditing" (where changes are logged and displayed in a difference grid view) without being told that this feature demands additional coding and often requires more hardware to handle extra database accesses. Users might believe they can demand auditing on every field, whereas developers might think this is feature creep because they have made assumptions about the extent of user requirements. If the solution provider has committed delivery before the user requirements were reviewed, developers are between a rock and a hard place, particularly if user management derives some advantage from their failure to implement requirements. Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture. (This may suggest that throwaway prototyping, rather than evolutionary prototyping, should be used.)

Y.P.Sreedevi

Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. When the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype. Users can become stuck in debates over details of the prototype, holding up the development team and delaying the final product.
Expense of implementing prototyping: the startup costs for building a development team focused on prototyping may be high. Many companies have development methodologies in place, and changing them can mean retraining, retooling, or both. Many companies tend to just jump into the prototyping without bothering to retrain their workers as much as they should. Q. What are the methods available for SDLC Project Management?

Water fall method, Fountain, Build and Fix, Spiral, Incremental, Synchronize & Stabilize and Rapid Prototyping.

Q. Which models does Spiral SDLC model combine? The Spiral SDLC is also called as Spiral lifecycle model. It combines the features of Waterfall and the Prototyping model.

----