Waterfall Life Cycle: Waterfall life cycle is the most familiar and classic life cycle model. It is sometimes referred to as the classic life cycle or the linear sequential model. It the simplest type of life cycle and very easy to use and understand. In the waterfall life cycle, each phase needs to be completed before the next phase can start. Each phase is separate and does there’s no overlapping.
Implementation & Unit Testing
Integration & System Testing
Operation & Maintenance
Requirement Analysis: Requirements are collected from end-user consultations and then analyzed. A requirement Specification Document is created which guides the next phases of the model.
System Design: System design is prepared by studying the requirements specification from the 1st phase. The hardware requirements are specified in this stage and a picture of the overall system architecture is produced.
Implementation & Unit Testing: In this phase, the work is divided in small units; actual coding starts. Testing makes sure that the software successfully meets the required specification; and that any errors are identified.
Integration & System Testing: All units are integrated and tested to ensure that the system meets the requirements. At the end of this stage, the software is delivered to the customer.
Operation & Maintenance: This is the longest phase in the model. The software is updated in this phase to correct any errors, make the software more efficient and to meet the changing needs of the customers.
It is a linear sequential model
Very easy & simple to implement; therefore well suited for small projects
It is also cheaper
Minimal amount of resources are required to implement this model
Testing is done after each phase to ensure the project is on the right path
Easily manageable because model is rigid; each phase has certain deliverables & a review process after a phase is over, which makes understanding of the designing procedure simpler.
High risk & uncertainty.
Not suited for long projects where the requirements may change.
The working software is only produced late during the life cycle.
It is difficult to estimate the cost and time for each stage.
No back tracking possible; if an error occurred in the earlier stages of the cycle, it can’t be corrected for that batch.
V-Shaped Model: The V-Shaped Model is very similar to the Waterfall model life cycle, but testing is done upfront instead of later in the life cycle like in Waterfall model. Like Waterfall model, V-Shaped Model is also a sequential cycle and a new phase is only started after the completion of the previous phase. Each development stage is matched with its respective testing stage; Requirements ƒ System Testing, High-Level Design ƒ Integration Testing, Low-Level Design ƒ Unit Testing. V-Shaped model is very useful for systems which require high reliability.
Requirements: Commences the life cycle; system test plan is created.
High-Level Design: Focuses on design & system architecture; integration tests are created.
Low-Level Design: Software components are designed & unit tests are created.
Implementation: Coding takes place in this phase.
It’s easy to use; but not as easy as the waterfall model.
More chance of success than the waterfall model due to the early testings.
Project moves quickly to the implementation stage.
Useful for small projects; considering the requirements are easily understood & known upfront.
Bugs in the final stage are very costly to fix.
Total development time of v-shaped model is more than the waterfall model.
Does not contain any risk analysis activities
Throwaway Prototyping model: Very useful in situations the user’s needs and requirements are not clear. The main objective of this model is to validate or drive the system requirements. This model is developed to reduce the requirement risks. This prototype is developed and then delivered to the user for experiments and then it is discarded, hence ‘throw away’ prototype; and it should not be considered as a final system.
Requirement risks are fewer
If delivered model does not meet the user’s needs, then it can be discarded and new models can be developed.
Can be undocumented
Developers may be push to deliver the throw away prototype as the final system, which is not recommended.
System structure may be degraded due to the changes made during the software development process.
Evolutionary Prototyping model: In evolutionary prototyping, the initial prototype is developed and it is then refined through number of stages to final stage. The main objective is to deliver the working system to the user. Verification is not possible because there is no specification.
System development involves the user
Working system is delivered fast
A more useful system can be delivered
Time required to complete project is unknown.
May have problems; Management, Maintenance and Verification problems.
Incremental model: The incremental model is similar to the Waterfall life cycle model, but there are multiple development cycles here, which makes it a ‘multi-waterfall’ cycle. It has an iterative approach (repeating), and each iteration passes through each of the phases. A working version of software can be produced during the first iteration, which means a functioning software is available early in the cycle.
1st Increment delivery
2nd Increment delivery
nth Increment delivery
Working Software can be developed quickly & early during the life cycle.
Its less costly to change requirements therefore; Flexible.
Easier to test and fix errors
End-users get to see working software early in the software development life cycle.
The total development cost is higher
Well defined project planning is required to distribute the work properly.
Spiral Model: Also known as ‘Spiral lifecycle model’. This model combines the features of the waterfall model and the prototyping model. The Spiral Model is most commonly used in large, complicated and expensive projects; and constant review is needed to stay on target. The main area in which Spiral model is used is Game development due to the constantly changing goals & size of the large project.
1. Determine Objectives, Alternatives, Constraints
2. Evaluate alternatives.
Identify, and resolve risks.
3. Development & Tests
4. Plan next Phases
Important issues can be discovered earlier, which makes estimation of budget & schedule more realistic & reliable.
Good amount of risk analysis
Really good for large projects
Software can be conceived early in the life cycle.
Flexible & allows for multiple iterations.
Not suitable for smaller projects
Success of the project depends on the risk analysis
Requires knowledgeable staff; for risk analysis.
2. Identification of the Functions and Purpose of a Systems Life Cycle.
The systems life cycle is a series of well-defined phases in the development of systems. It is very important that a project should meet the required specification, should be within budget and delivered on time. Large system developments can take a long time to be developed and can be very costly too; therefore most organisations use the systems life cycle (stages) to develop systems because it saves time & isn’t as costly.
1. Feasibility study
Different solutions are examined in this stage. First step of this stage is to discover the funds available and then compare with the benefits of the company, in view of their requirements because sometimes in order to arrive at final decision a trade-off (give and take) has to be accepted e.g. less functionality for less cash.
There are three different options that a company could choose:
Company does not change anything
No interference to the business. Least cost
System remains outdated. Less efficient
Company updates half of the system
Least efficient parts are redesigned to improve performance while best parts of the system are not changed
Moderate, light training for staff
High, New equipments, Upgraded Software, Training for staff.
80% improved (over the old system)
2. Investigation and Analysis
First step of this stage is to investigate the old system and problem it is causing.
There are different ways to find out the problems:
Questionnaires and Interviews
Observing people using the old system
Following the information from the point it enters the system till the point of output.
Taking the cause of the problem
These steps should lead toward the true cause of the problem
The next part is to analyze how the existing system works how information is handled and how people interact with it.
To Analyze, different methods are used e.g.
This shows the dealings between different systems in the company or outside. System diagram shows how they interact and what depends on what and so on.
Data Flow Diagram
This shows the movement through the system, how the system deals with the information, how information flows through the system, how dose it connect and disconnect and what the outputs are.
This shows how people interact with the system for example an employee makes a claim, first it will go to manager who will counter-sign the claim it will then go to account manager who authorizes payment and so on.
This stage defines the system in greater detail and the best way to start this stage is to write down exact details of the new system e.g.
The data Inputs
The data Outputs
Documents that are printed out
Procedure of the data that flows through the system
The structure of any files that store data
How information is accessed
And so on
The testing procedure comes after the system has been built. In my opinion it is really useful to build a test procedure before starting to build a system because, if you know how the system will be tested, it will lead you towards a better design.
Prototype is something that allows you to build a program without having to worry about the details, it is to confirm that design is likely to work. The master document created in this stage is called System Requirement Document.
This stage takes the design forward and put it into practice and this stage take place when the client has agree on what needs to be done (Requirement Specification) and the Analyst has clearly described what needs to be done(System Requirement Document).
There are several terms involved in this stage so it is reasonable to break down the System Requirement Document into sections that each can develop.
At this stage following things may take place:
The software developers write code
The hardware people develop equipment
The testing team develops test plans
The user-testing groups follow the test plans and check the system works as expected
Now the system is developed and tested and it is working correctly and doing what client wanted.
The key events in this stage are:
Data conversion: Data stored on the old system are now converted into the correct format for the new system.
System Change Over: switch off the old system and turn on the new system, which is not as simple as it sound.
Run the old and new system in parallel for a time
Customer does not care what your IT system is made up of, they are only concerned about their order. One method is to run the old system along the new one, then in the quiet time the new system store the old system data and is then fully loaded and ready to go.
Training is the vital part of this stage, staff training must take place.
Staff needs to be shown how to use the new system
How to access help when they run into difficulties
Member of a development team should be available on call
A user manual should be available for staff
The new system is running smoothly and it will need to be looked after so maintenance stage takes care of the following that can take place:
Problems are cleared as they occur
Tweaks to the system are applied to improve performance
The system has to be moved due to office movement
Data is backed up and kept safe
Equipment are replace as required
Basically this stage never ends until the new system becomes old and is then switch with new system.
3. Undertake a User Needs Analysis (UNA) for your system.
SYSTEM USED: CINEMA BOOKING SYSTEM
UNA is the first stage in the system development process. UNA in system developing includes task that is demanded by the user for new or different system. Requirements must be actionable, measurable, and testable and must be related to user needs.
The best way to undertake UNA in my view is to have a workshop with the users who will use the new system. This will give me one clear idea of what the new system must do. When working on developing the new system I’ll have a better idea of what users wants from the new system, keeping every user’s requirements in mind.
So I’ll set up a workshop, in which I’ll ask users what they want from the new system. I will document their requirements as I go along. Basically I’ll ask different questions from the users and then the users themselves will work out what kind of a new system they want.
Questions that I’ll ask users:
What the new system should do?
Do you want it to be networked with other computers?
How long the information needs to be saved?
Should staff login when using the system?
Anything needs to be printing?
What information needs to be print out?
Payment procedure/ types of cards?
Inputs, process and outputs
Internet booking/ serial number only for internet booking
This is how I’ll design the system, keeping in view the users requirements. It will be an advanced system which will be quite reliable and it will be easy for the users to use this system.
Serial number only for Internet booking
Name of the movie
Movie ticket for customer
Information saved in the system
This program is supposed to save the information of the customer and print out a movie ticket containing the required information.
Print out of the ticket
Payment after discount
System will show this information on the Ticket.
4. Produce a Systems Context Diagram for your system.
Calculate discount if applied and check for seats in theatre
Saved in server for 3 days and is access able by any member of staff
Checks the Ticket
Check movie and time
Update Movie Data
Delete Old Data
Updates the system
This Diagram explains the program I am building for the Cinema. Circles in the diagram mean the first thing is done by Administrator, User/ Staff and the customer.
Administrator must update the system by inserting new movies and deleting old movies.
User/ Staff is the person who can access the system by login in and takes the details (info given) of the customer. User/ Staff then enter the details (input filled) in the system.
News System will process the input and process it, calculate discount if applied and check for seats available in theatre. It’ll then give two outputs Data Saved and Ticket.
Data Saved meaning the data will be saved in a server for three days and is access able by any member for staff but the saved data cannot be changed after the Ticket is printed out.
Ticket will be printed out and is going to be checked by the staff. Staff will give the ticket to the customer.
5. Produce a Level 1 Current Physical Data Flow Diagram for your system.
D1 User/ Staff/ counter
Deposits and Withdrawals
Process customer data
Customer details/ data
Details are checked
Ticket handed to the customer
In this Physical Data flow diagram customer, who is outside data, goes to the counter to purchase a ticket for the movie. Counter/ staff take his query and process it, system then stores the data and process a ticket, which is given to the customer.
6. Produce a Level 1 Required Logical DFD for your system.
Updates the System
Customer details/ data
Input customer detail/ data
Calculates discounts & Theatre No.
Store’s in a server
Ticket details are checked by user/ staff
Source of Data
In this Diagram Admin is updating the data for the system and user is taking the detail/ data of the customer and entering it in the system to process a Ticket for customer.
7. Decompose one of the processes to a Level 2 Required Logical Data Flow Diagram for your system.
Updates the System
Adding new movie data
Deleting old movie data
Stores admin new data
Stores customer data
Movie is suitable for customer (age)
Store data in server
Auto deletes 3 days old customer data
Access to old data
In this Diagram Admin is updating the data for the system and system is processing customer details against admin updated data and it is then stored in a server for three days.
8. Construct a Logical Data Structure for the system you are producing.
Customer will seek staff on counter for any enquiry or to purchase a movie ticket
Provide service to customer
Staff will take customer details from customer for a movie ticket
To process a Ticket, staff will have to enter customer details in the system for a movie ticket
Ticket is handed to the customer after staff checks for any errors
9. With the aid of your Logical Data Structure, produce an Entity/Event Matrix for your database system.
Purchasing a ticket for a movie
Solve the issue
Enter customer details in the system
Staff (checks it)
Customer (takes ticket)
10. Describe the ‘Required Physical Data Model’.
Customer details/ data
Update new movie data
Delete old movie data
handle customer details
Updates the System
Input customer detail/ data
Customer internet serial no.
Name of the movie
Stores admin updated data
Access to old data
Check for any errors on the ticket
Movie is suitable for the customer (age)
Stored in server
Auto delete 3 days old data
Admin updates the system and solve problems
Staff handles the customers and input the customers details in the system
System processes the data and check for availabilities
Data is stored for 3 days
Ticket is issued for customer as a receipt
Cite This Work
To export a reference to this article please select a referencing style below: