SDLC Models

Spiral Model Advantages

1. Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. 2. It is more able to cope with the (nearly inevitable) changes that software development generally entails. 3. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

Application Generation:

Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques.

Software prototyping

a possible activity during software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed.

Performance and capacity prototypes

used to define, demonstrate, and predict how systems will perform under peak loads as well as to demonstrate and evaluate other non-functional aspects of the system (transaction rates, data storage volume, response time, etc.)

RAD (rapid application development) is a concept that products can be developed faster and of higher quality through:

- Gathering requirements using workshops or focus groups - Prototyping and early, reiterative user testing of designs -The re-use of software components - A rigidly paced schedule that defers design improvements to the next product version -Less formality in reviews and other team communication

Spiral Model Disadvantages

1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Risk of not meeting budget or schedule

Disadvantages of Prototyping

1. Insufficient analysis: 2. User confusion of prototype and finished system: 3. Developer attachment to prototype: 4. Excessive development time of the prototype: 5. Expense of implementing prototyping:

RAD Model Advantages and Disadvantages

1. RAD reduces the development time and reusability of components help to speed up development. All functions are modularized so it is easy to work with. 2. For large projects RAD require highly skilled engineers in the team. Both end customer and developer should be committed to complete the system in a much abbreviated time frame. If commitment is lacking RAD will fail. RAD is based on 3. Object Oriented approach and if it is difficult to modularize the project the RAD may not work well

Advantages of Prototyping

1. Reduced time and costs 2. Improved and increased user involvement:

Data Modeling:

The information collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined.

Business Modeling

The information flow among business functions is defined by answering questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on.

Development Methodology

The traditional software development cycle follows a rigid sequence of steps with a formal sign-off at the completion of each. A complete, detailed requirements analysis is done that attempts to capture the system requirements in a Requirements Specification. Users are forced to "sign-off" on the specification before development proceeds to the next step. This is followed by a complete system design and then development and testing.

Operations & Maintenance:

This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

Waterfall Model

Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. The phases in Waterfall model are: Requirement Specifications phase, Software Design, Implementation and Testing & Maintenance. All these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off, so the name "Waterfall Model". All the methods and processes undertaken in Waterfall Model are more visible.

Dynamic systems development method

a framework for delivering business solutions that relies heavily upon prototyping as a core technique, and is itself ISO 9001 approved. It expands upon most understood definitions of a prototype. According to DSDM the prototype may be a diagram, a business process, or even a system placed into production. DSDM prototypes are intended to be incremental, evolving from simple forms into more comprehensive ones.

RAD is a methodology for ____________

compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model.

Review phase

in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed.

Evolutionary Prototyping

(also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be builtWhen developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.

RAD Model Phases

1. Business Modeling 2. Data Modeling 3. Process Modeling 4. Application Generation 5. Testing and Turn over

The process of prototyping involves the following steps

1. Identify basic requirements Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored. 2. Develop Initial Prototype The initial prototype is developed that includes only user interfaces. 3. Review The customers, including end-users, examine the prototype and provide feedback on additions or changes. Revise and Enhancing the Prototype

Verification Phases

1. Requirements analysis 2. System Design 3. Architecture Design 4. Module Design

The steps in the spiral model can be generalized as follows:

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 proto type is evolved by a four fold 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 there fined 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.

Requirement Analysis & Definition:

All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

Iterative Model

An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model. Consider an iterative lifecycle model which consists of repeating the following four phases in sequence: 1. Requirements 2. Design 3. Implementation & Test 4. Review

Integration & System Testing:

As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer.

System & Software Design:

Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model.

The DSDM lifecycle of a prototype is to:

Identify prototype Agree to a plan Create the prototype Review the prototype

Requirements analysis:

In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a documentcalled the user requirements document is generated. The user requirements document will typically describe the system's functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system

Common Errors in Requirements Analysis Problem 3: Customers have unreasonable timelines

It's quite common to hear a customer say something like "it's an emergency job and we need this project completed in X weeks". A common mistake is to agree to such timelines before actually performing a detailed analysis and understanding both of the scope of the project and the resources necessary to execute it. In accepting an unreasonable timeline without discussion, you are, in fact, doing your customer a disservice: it's quite likely that the project will either get delayed (because it wasn't possible to execute it in time) or suffer from quality defects (because it was rushed through without proper inspection). To solve this problem, you should: Convert the software requirements specification into a project plan, detailing tasks and resources needed at each stage and modeling best-case, middle- case and worst-case scenarios. Ensure that the project plan takes account of available resource constraints and keeps sufficient time for testing and quality inspection. Enter into a conversation about deadlines with your customer, using the figures in your draft plan as supporting evidence for your statements. Assuming that your plan is reasonable, it's quite likely that the ensuing negotiation will be both productive and result in a favorable outcome for both

Testing and Turn over:

Many of the programming components have already been tested since RAD emphasis reuse. This reduces overall testing time. But new components must be tested and all interfaces must be fully exercised.

Common Errors in Requirements Analysis Problem 4: Communication gaps exist between customers, engineers and project managers

Often, customers and engineers fail to communicate clearly with each other because they come from different worlds and do not understand technical terms in the same way. This can lead to confusion and severe miscommunication, and an important task of a project manager, especially during the requirements analysis phase, is to ensure that both parties have a precise understanding of the deliverable and the tasks needed to achieve it. To solve this problem, you should: Take notes at every meeting and disseminate these throughout the project team. Be consistent in your use of words. Make yourself a glossary of the terms that you're going to use right at the start, ensure all stakeholders have a copy, and stick to them consistently

Implementation & Unit Testing:

On receiving system design documents,the works divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications.

System Design:

System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures,datastructuresetc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The document for system testing is prepared in this phase.

Bin - Bang Model

The Big- Bang Model is the one in which we put huge amount of matter (people or money) is put together, a lot of energy is expended - often violently - and out comes the perfect software product or it doesn't.The beauty of this model is that it's simple. There is little planning, scheduling, or Formal development process. All the effort is spent developing the software and writing the code. It's and ideal process if the product requirements aren't well understood and the final release date is flexible. It's also important to have flexible customers, too, because they won't know what they're getting until the very end.

Advantages of Waterfall Model

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.

Process Modeling:

The data object 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, modifying, deleting or retrieving a data object.

Incremental Prototyping

The final product is built as separate prototypes. At the end the separate prototypes are being merged in an overall design.

Architecture Design:

This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.

Module Design:

This phase can also be called as low-level design. The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo code - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage.

Common Errors in Requirements Analysis Problem 1: Customers don't (really) know what they want. Possibly the most common problem in the requirements analysis phase is that customers have only a vague idea of what they need, and it's up to you to ask the right questions and perform the analysis necessary to turn this amorphous vision into a formally-documented software requirements specification that can, in turn, be used as the basis for both a project plan and an engineering architecture.

To solve this problem, you should: Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project. Make visible any assumptions that the customer is using, and critically evaluate both the likely end-user benefits and risks of the project. Attempt to write a concrete vision statement for the project, which encompasses both the specific functions or user benefits it provides and the overall business problem it is expected to solve. Get your customer to read, think about and sign off on the completed software requirements specification, to align expectations and ensure that both parties have a clear understanding of the deliverable.

Common Errors in Requirements Analysis Problem 2: Requirements change during the course of the project. The second most common problem with software projects is that the requirements defined in the first phase change as the project progresses. This may occur because as development progresses and prototypes are developed, customers are able to more clearly see problems with the original plan and make necessary course corrections; it may also occur because changes in the external environment require reshaping of the original business problem and hence necessitates a different solution than the one originally proposed. Good project managers are aware of these possibilities and typically already have backup plans in place to deal with these changes.

To solve this problem, you should: Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process. Set milestones for each development phase beyond which certain changes are not permissible -- for example, disallowing major changes once a module reaches 75 percent completion. Ensure that change requests (and approvals) are clearly communicated to all stakeholders, together with their rationale, and that the master project plan is updated accordingly.

Common Errors in Requirements Analysis Problem 5: The development team doesn't understand the politics of the customer's organization The scholars Bolman and Deal suggest that an effective manager is one who views the organization as a "contested arena" and understands the importance of power, conflict, negotiation and coalitions. Such a manager is not only skilled at operational and functional tasks, but he or she also understands the importance offraming agendas for common purposes, building coalitions that are united in their perspective, and persuading resistant managers of the validity of a particular position. These skills are critical when dealing with large projects in large organizations, as information is often fragmented and requirements analysis is hence stymied by problems of trust, internal conflicts of interest and information inefficiencies.

To solve this problem, you should: Review your existing network and identify both the information you need and who is likely to have it. Cultivate allies, build relationships and think systematically about your social capital in the organization. Persuade opponents within your customer's organization by framing issues in a way that is relevant to their own experience. Use initial points of access/leverage to move your agenda forward.

Version I: Prototyping is used as ________-

a requirements technique.

The V-model

a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V- Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

Design phase

a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design.

A prototype

a working model that is functionally equivalent to a component of the product.

The spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to____________

explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

The spiral model, also known as the spiral lifecycle model,

is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.

The disadvantage of waterfall development

it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model.

Throwaway or Rapid Prototyping

refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software.

The iterative lifecycle model can be likened to producing software by ____________

successive approximation.

Requirements phase

the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements. -

Version II: Prototype is used as

the specifications or a major part thereof.

Usability prototypes

used to define, refine, and demonstrate user interface usability, accessibility, look and feel.

Business prototypes

used to design and demonstrates the business processes being automated.

Capability/technique prototypes

used to develop, demonstrate, and evaluate a design approach or concept.

Implementation and Test phase

when the software is coded, integrated and tested.