You are on page 1of 16

TASK 1 Task1.

1
Stages of Different Life Cycle Models

When we are developing a system we follow a life cycle model in order to do the things better with a good quality, many companies use a unique life cycle model for their systems. But sometimes according to the situation they have to change the life cycles and choose a one which will be more suitable for that proposed system. So there are six main life cycle models we follow in this field. They are,

1. 2. 3. 4. 5. 6.

The General model Waterfall Life Cycle Model Prototype Life Cycle Model V-Shape Life Cycle Model Spiral Life Cycle Model

Incremental Model

1. The General Model


Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below: General Life Cycle Model

(Figure 1.1.1 General Model)

Each phase produces deliverables required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that is driven by the design. Testing verifies the deliverable of the implementation phase against requirements.

Requirements:
Business requirements are gathered in this phase. This phase is the main focus of the project managers and stake holders. Meetings with managers, stake holders and users are held in order to determine the requirements. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work. The overall result is the system as a whole and how it performs, not how it is actually going to do it.

Design:
The software system design is produced from the results of the requirements phase. Architects have the ball in their court during this phase and this is the phase in which their focus lies. This is where the details on how the system will work are produced. Architecture, including hardware, software, communication, software design (UML is produced here) are all part of the deliverables of a design phase.

Implementation:
Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. For a developer, this is the main focus of the life cycle because this is where the code is produced. Implementation my overlap with both the design and testing phases. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase.

Testing:
During testing, the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. Unit tests and system/acceptance tests are done during this phase. Unit tests act on a specific component of the system, while system tests act on the system as a whole. So in a nutshell, that is a very basic overview of the general software development life cycle model. Now lets delve into some of the traditional and widely used variations.

2. Waterfall Model
This is the most common and classic of life cycle models, also referred to as a linearsequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model. Waterfall model are: Requirement Specifications phase, Software Design, Implementation and Testing & Maintenance. Waterfall Life Cycle Model

(Figure 1.1.2 Waterfall Lifecycle Model)

Above briefly we got to know about the waterfall life cycle model structure. Now we will see how each and every stage effects the life cycle and what are those stages suppose to do when designing a system.

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.

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.

Implementation & Unit Testing: On receiving system design documents, the work is 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.

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.

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.

3. Prototype Life Cycle Model


A Prototype model is a system development method which directly involved with the client and built, tested, then reworked as necessary until an acceptable system comes out according to the clients need.

(Figure 1.1.3 Prototype Life Cycle Model)

Requirement Gathering: In this stage the analyst will go to the company and talk with the clients to identify the problems. After having a small discussion the analyst will list down (Written) the entire problems list he realized regarding the company. Then he will ask the client how the system must be designed if she/he (Client) has a predefined plan about it. If the customer tells the analyst how the system should look like and what are the additional features to be made the analyst will mark them all. After that the analyst will explain the client how the system will be designed giving a choice to the client to select with multiple solutions. Quick Design: Plan the System the analyst is going to design using either Hardcopy or Softcopy by using the information he has gathered in the previous step. Building Prototype: In this step we are creating the system exactly as it is in the Quick Designed system using preferred software. We are not adding additional features though it will look good but if it is out of design. Customer Evaluation: After creating the software we have to show that to the client and get the comments and ask whether clients want more additions to the system.

Refining Prototype: If the Client has NO additions we can finalize the product. But if the Client has more additions we have to verify those new updates and think how the system must change, and apply the suitable validations and have to design it and follow the life cycle. Engineer Product: After customizing the system as exactly the client wants we can get the final product output and give that to the client with maintenance tips etc.

4. V-Shaped Model
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. The low-level design phase is where the actual software are designed, and unit tests are created in this phase as well. components

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

V-Shaped Life Cycle Model

(Figure 1.1.4 V-Shape Life Cycle Model)

Requirements analysis: In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the users. 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 document called the user requirements document is generated. System Design: Systems design is the phase where 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.

Architecture Design: The phase of the design of computer architecture and software architecture can also be referred to 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, technology details etc. The integration testing design is carried out in this phase.

Module Design: The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly.

Unit Testing: In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer.

Integration Testing: In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.

System Testing: System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.

User Acceptance Testing: Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.

5. Spiral Model
The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral. In the spiral model, the angular component represents progress, and the radius of the spiral represents cost. Spiral Life Cycle Model

(Figure 1.1.5 Spiral Life Cycle Model)

Determine Objectives: 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. Identify and Resolve Risks: A preliminary design is created for the new system. This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements. Development and Test: 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. Plan the next Iteration: A second prototype is evolved by a fourfold procedure, evaluating the first prototype in terms of its strengths, weaknesses, and risks and defining the requirements of the second prototype and planning and designing the second prototype and constructing and testing the second prototype.

6. Incremental Model
The incremental model is an intuitive approach to the waterfall model. Multiple development cycles take place here, making the life cycle a multi-waterfall cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases. A working version of software is produced during the first iteration, so you have working software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iteration.

Incremental Life Cycle Model

(Figure 1.1.6 Incremental Life Cycle Model)

TASK 1.2

Comparing Different Life Cycle Models

Here I will be describing the advantages and disadvantages as well with the different life cycle models by pairs. So we can get an idea how to select the life cycle model for the proposed system. Earlier we have listed down all the information for each life cycle model we have mentioned and now Im not going to give brief information about for those are mainly consider the four life cycle models. The comparisons only will be given. Now we will see the Advantages of different life cycle models. Waterfall Model Advantages Simple and easy to use. Easy to manage due to the rigidity of the model each phase has specific deliverables and a review process. Prototype Model Advantages Prototyping can improve the quality of requirements and specifications provided to developers. 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 final product is more likely to satisfy the users desire for look, feel and performance. V-Shape Model Advantages Simple and easy to use. Each phase has specific deliverables. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. Works well for small projects where requirements are easily understood. Spiral Model Advantages Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. It is more able to cope with the (nearly inevitable) changes that software development generally entails. Software is produced early in the software life cycle.

Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood.

(Table 1.2.1 Life Cycles Models Comparison Advantages)

Above we have compared the Advantages the different life cycle models are giving. So now we will see what the disadvantages are. Because as same as advantages the client must know risks there can be using the life cycle models. They have been listed below.

Waterfall Model Disadvantages Adjusting scope during the life cycle can kill a project No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Poor model for complex and object-oriented projects. Poor model for long and ongoing projects. Poor model where requirements are at a moderate to high risk of changing.

Prototype Model Disadvantages Contract may be awarded without rigorous evaluation of Prototype Identifying nonfunctional elements difficult to document Incomplete application may cause application not to be used as the full system was designed Incomplete or inadequate problem analysis Client may be unknowledgeable

V-Shape Model Disadvantages Very rigid, like the waterfall model. Little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, so no early prototypes of the software are produced. Model doesnt provide a clear path for problems found during testing phases.

Spiral Model Disadvantages Can be a costly model to use. Risk analysis requires highly specific expertise. Projects success is highly dependent on the risk analysis phase. Doesnt work well for smaller projects.

(Table 1.2.2 - Life Cycles Models Comparison Disadvantages) So as you saw above I have listed down all the advantages and disadvantages the life cycle models will give us and from the comparison you can get an idea which model is more suitable for the KINGSTON HOTEL. Without waterfall model we can use any life cycle model from these three, Prototype, V-shape and spiral. But I recommend Prototype Life Cycle Model to be used for KINGSTON HOTEL. Next I will tell you why I have used this life cycle model for designing the system for the KINGSTON HOTEL.

TASK 1.3
Justifying the Life Cycle Model for KINGSTON HOTEL
As I said earlier for further designing and implementation for the system we have to select a life cycle model for the Kingston Hotel. So I have selected Prototype Life Cycle Model. So now we will see the reasons. Reasons to use the Prototype Life Cycle Model We simply take what features must be included to the system according to the clients likeness and design it using the latest technology. And another thing is we always try to give a Bug less system to the client in order to use it even the hotel is upgraded. So we are visiting the clients hotel and take ideas how the data must be flow inside the hotel and how we should store the data to deal very easily. So this hotel has a large wall chart in front of the reception, a leaflet and a card for each guest or regular guest, so it is currently dealing with some customers. So we must go to the hotel or invite the managers to get the currently stored details. And the management of KINGSTON wants to make their hotel automated using latest technology and it will be really good if we can get the directors view ideas to improve the system. So from the quick design step we can make a quick hardcopy or softcopy to show the client and modify if they want. We suggest the customer identification and customer attraction tricks with these suggestions. If the client likes it we can just cut them out and continue with selected options rather getting spoiled after designing all options and remove them if the client doesnt like it. The other good thing in this Life cycle model is we are stick in to the plan. We are suggesting all the preferred modifications in the quick design and the programmers can continue their work without any interference. All the additions are been added with the system analysts approval and confirmations by the customer. So finally there will be a good output with a combination of customer satisfaction and as well powered with latest technology. The other good thing in Prototype is we are showing the client the system their going to use before finishing it and give it to them. So at the last step even if they have any changes they can say it to us and it will be changed. So the system will be designed very user friendly combined with all their ideas.

The other thing is other life cycle models will be so expensive (Without Waterfall) and the company has to spend money for that also. But prototype is affordable, and it will give good results too. Not like other life cycles this will directly involve the people who are going to use the System. So hereby I think my selection of Prototype is a very good decision.

Reasons for Not Using the other Life Cycle Models


Waterfall Life Cycle Model The major weakness of the Waterfall Model is that after project requirements are gathered in the first phase, there is no formal way to make changes to the project as requirements change or more information becomes available to the project team. Because requirements almost always change during long development cycles, often the product that is implemented at the end of the process is obsolete as it goes into production. The Waterfall Model is a poor choice for software development projects where requirements are not well-known or understood by the development team.It might not a good model for complex projects or projects that take more than a few months to complete. And the hotel is already using currently. So according to the waterfall model they are gathering requirements once and dont even come to meet the client till its going to finish. So there will be collisions with missing data, and customer satisfaction will go down because they are not even getting client ideas to develop it. So at last they will make a failure system which no one will like to use and there will be waste of money and effort. V-Shape Life Cycle Model This life cycle model is a bit same as the waterfall model because in all steps it is using the As I have told earlier we always think about the clients profits so we dont like to waste their money only for a life cycle model even they have lots of stuff to do with it. And usually with the complexity this life cycle model takes more time and need more information in order to take the whole advantages. Otherwise it will be a waste of money.

And there are several other reasons I am listing down for not using this life cycle model. They are,

Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during non-development phase activities May be hard to define objective, verifiable milestones that indicate readiness to Proceed through the next iteration.

Because of these affections I decided not to use the Spiral Model for the system we are designing to the KINGSTON HOTEL. Waterfall model structure and though it is good to use it will take much more time in investigation and it will affect the system by delaying the process. As you know the hotel is doing their business even on the time the system is being designed. So time to time disturbing the client gathering the information will interrupt their work and the client will be dissatisfied. Thought the client can afford the payments for the V-shape model it will be a waste and the results also will not be satisfactory. And there are several weaknesses the V-shape to be cancelled. They are, Very inflexible, like the waterfall model. Little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, so no early prototypes of the software are produced. Model doesn't provide a clear path for problems found during testing phases. Because of these affections I decided not to use the V-shape Model for the system we are designing to the KINGSTON HOTEL.

Spiral Life Cycle Model Spiral Life cycle model is the mostly used life cycle model in nowadays system designing. There are no doubts we can surely work with this for the KINGSTON HOTEL. But this life cycle model need experts in risk assessments and programmers. So the whole model will cost lot after been finished. Though this hotel handles three departments still its too small to apply this kind of life cycle to it.

You might also like