Description Of Waterfall Model Information Technology Essay

The software methodology that is probably going to be used during the development of the project is the Waterfall Model. Its strong points lie in the fact that it is sequential, so there would be no confusion on the steps and the processes are straight down–no need to worry about so many conditions while working on a project. Additionally, this type of model tends to pack up on so much documentation. Therefore, such tends to be useful for future code revisions and reference.

This model assumes the requirements to remain static during the life of the project, so there is little or no chance of incorporating new changes to the software once work begins. If changes are tried to be incorporated it leads to more confusion and further delays. The waterfall model is a sequential software development process. Following are the phases of waterfall model.

Conception

Initiation

Analysis

Design

Construction 

Testing and Maintenance

Description of Waterfall model [W1]

The waterfall model, as described above, offers numerous advantages for software developers. First, the staged development cycle enforces discipline: every phase has a defined start and end point, and progress can be conclusively identified (through the use of milestones) by both vendor and client. The emphasis on requirements and design before writing a single line of code ensures minimal wastage of time and effort and reduces the risk of schedule slippage, or of customer expectations not being met. Getting the requirements and design out of the way first also improves quality, so it’s much easier to catch and correct possible flaws at the design stage than at the testing stage, after all the components have been integrated and tracking down specific errors is more complex. Finally, because the first two phases end in the production of a formal specification, the waterfall model can aid efficient knowledge transfer when team members are dispersed in different locations.

Selection of the appropriate methodology: –

For selecting the appropriate methodology a comparative analysis was done between various kinds of models i.e. Waterfall Model, Spiral Model and RAD to determine the best model for the proposed system.

Table 3.0: Comparison of different Models

How waterfall model will be useful in development of “Smart Whistle blower” software?

Based upon the comparison chart the developer critically evaluates the waterfall model with contrast to the development of the system “Smart Whistle Blower”

First of all as the project that we will be doing is an academic project and not a highly financial project so less risk is involved. Waterfall model is suitable for such type of projects because in other models like spiral there is risk analysis in every step that will be complex and even expensive.

Secondly since the waterfall model follows simple and sequential software development methodology so it will be help full for the developer to complete each step with perfection and then move on to the next step.

The modular approach in waterfall model is also one of the very important factor for which it has been selected. Here the designing of the interface will be finished first and then coding will be started. So, implementation phase will only be started when the designing is completed. This will be helpful because the developer will be able to know the system well enough to how to proceed with the coding part by looking at the interface designs.

Another important factor for which waterfall model is selected for this type of software development because as it is a Network Monitoring and Management Software development so there may be some modules that can be dependent on a module that has to be developed first. For example while remote access of client PC, the software must have a module to first detect the PC and only after that further functionality involving on that client PC can be performed. So Waterfall model provides a modular testing approach, like each module will undergo testing phase before it has been finished. This will further help in interoperability issues and also integration of one module with another.

Finally the requirements of this project demand high- quality fully functional software. So waterfall model is most suitable for this type of short-span project of one year because it follows simple software development methodology in which Progress of system is measurable and pre-defined strict sign-off of requirements is carried out before starting of any module.

3.2 Module Wise Development Plan

Gantt chart

3.3 Evaluation and Test Plan

In order to deliver a fully functional, a highly acceptance error-free system, the system shall involve a tremendous amount of evaluation or testing which needs to be done by various people (such as the person that the developer is planning to interview) throughout the system development. Clearly, a good testing should follow a few important principles and it should be carefully planned. The main testing procedures which will be performed during the development of the proposed system will be based on the phases of the Waterfall Methodology. In this methodology the design phase is followed by the implementation phase. Right from this point of development the Testing procedures starts. The procedures of testing during the consecutive phases of Waterfall model are:

Unit Testing

As software testing process, first the testing shall commence by undergoing unit testing for each modules that will pose a difficulty in understanding the logic. Unit testing ensures each module and function works properly. Basically, the system developer itself will be tester to perform the unit testing. Following are the features under which white box test will be performed.

Intrusion Detection And Alarm

Notification or SMS Module.

Administrator functionality module

LAN wire disconnected notification

Basically, the black-box testing approach treats the system as black box or close box whereby the system tester will only know the formal inputs and projected results. Therefore, the system tester does not require to having detailed functional knowledge about the system and as well as how the program actually arrives at those results. In fact, the system tester tests the system based on the functional specification those we given to him / her.

Black Box testing will be performed on the following features:

Intrusion Detection And Alarm

Notification or SMS Module.

Administrator functionality module

LAN wire disconnected notification

Tester: Developer

Number Of testers: 1

Integration Testing

Different modules which will be working together will need to be integrated and tested to check their output. A bottom up approach will be followed to organize the tests. Integration testing will be done on

Intrusion Detection And Alarm

Notification or SMS Module.

Administrator functionality module

LAN wire disconnected notification

Tester: Developer, network administrator

Number of testers: 2

System Testing Next testing then shall proceed towards system testing where the software will be subjected to compatibility, security and performance testing.

Tester: Developer, Network Administrator

Number Of testers: 2-3

COMPATIBILY TESTING: Compatibility testing will be the last step. This type of testing is necessary to check whether software is compatible with all the operating systems. This testing will help to notify compatibility issues.

Core Functionality

Type of Testing

Intrusion Detection and Alarm module

Black Box Testing, Integration Testing,

Network Monitoring & Surveillance module

Black Box Testing, Unit testing

Administrator terminal module

Black Box Testing, System Testing Integration Testing

Enhanced Functionality

Type of Testing

Chat and Mobile Notification Module

Black Box Testing, Unit Testing

Web module for remote access

Black box testing, Integration Testing, System Testing

Special Functionality

Type of testing

View Live Client Screen or Screen shots of Client Screen

Black Box Testing

Install/ Uninstall User Programs

Black Box Testing

USER ACCEPTANCE TESTING: User acceptance testing will be done to ensure that all the users will be able to access all the information according to their needs efficiently and precisely.

This testing is the most important part of testing as it gives an overview of the acceptance of this system in market.

At last, the final level of the system testing will be the benchmark testing or so-called alpha testing where the functional requirements would be evaluated to know whether the system is acceptable by a potential end-user. The tester itself will be presented with real data used, not simulated data to examine the inputs and outputs of the system and as well as commenting the user’s friendliness of the system. This can be done with questionnaires given to users that test the system. Some of the questions are:-

Do you find any difficulty of using the system or is the system ease to use?

Does the system meet your requirement?

The entire user’s feedback or the comment given by the tester will be well-documented for further enhancement of the system.

Test Case -1

Project Name

Smart Whistle Blower

Test ID

001

Testing Module

Login authorization

Testing method

Unit testing

Date

Feb 2011

Name of tester

Boris Borkakoty

Description of Module

Verifies a User

Pre condition

Page must be connected to database/file

No.

Actual Input

Expected Result

Actual Result

Status

(Pass/Fail)

Error

Correction Measure

1

Enter the correct username and password

Message (” login successful”) and redirects to next page

2

Enter wrong username and password

Message(“Login Failed!! “) and redirects back to the login page

Test Case -2

Project Name

Smart Whistle Blower

Test ID

002

Testing Module

Detection of machines in the network

Testing method

Black Box testing

Date

Feb 2011

Name of tester

Boris Borkakoty

Description of Module

Detect machines in the network

Pre condition

LAN wire must be connected to the machine

No.

Actual Input

Expected Result

Actual Result

Status

(Pass/Fail)

Error

Correction Measure

1

Press the search machine button

Message (“machines detected”) and listed

Test Case 3

Project Name

Smart Whistle Blower

Test ID

003

Testing Module

LAN wire connectivity

Testing method

Unit Testing

Date

Feb 2011

Name of tester

Boris Borkakoty

Description of Module

Check whether the system is connected to LAN

Pre condition

A LAN wire must be there to carry out this test

No.

Actual Input

Expected Result

Actual Result

Status

(Pass/Fail)

Error

Correction Measure

1

Remove LAN wire

Message (” Particular system has gone out of network”) and the client machine must get log off with its password change

2

Manipulate IP Address

Message (” Particular system has gone out of network”) and the client machine must get log off

Test Case 4

Project Name

Smart Whistle Blower

Test ID

004

Testing Module

Intrusion Detection and Alarm

Testing method

Unit & Integration Testing

Date

Feb 2011

Name of tester

Boris Borkakoty

Description of Module

Checks when a storage device is mounted in client PC

Pre condition

A LAN wire must be there to carry out this test

No.

Actual Input

Expected Result

Actual Result

Status

(Pass/Fail)

Error

Correction Measure

1

Insert storage device in the port available

To admin terminal Message (” Particular user has inserted device in his system”)

2

Insert storage device in the client PC when admin not available in his terminal

SMS alert to Admin cell-phone “The particular user has inserted a storage device in his system”

Test Case 5

Project Name

Smart Whistle Blower

Test ID

005

Testing Module

Web-Login for remote access

Testing method

Unit & Integration Testing

Date

Feb 2011

Name of tester

Boris Borkakoty

Description of Module

Whether the user is able to login from his mobile phone

Pre condition

WLAN or internet must be present at the point of login

No.

Actual Input

Expected Result

Actual Result

Status

(Pass/Fail)

Error

Correction Measure

1

Open Web Browser. Provide Login Details

Message (“Login Successful”) and redirects to the server application.

2.

Provide incorrect login

Message (” Login unsuccessful”) and redirects to same page

Test Case 6

Project Name

Smart Whistle Blower

Test ID

006

Testing Module

Administrative terminal module

Testing method

Unit & Integration Testing

Date

Feb 2011

Name of tester

Boris Borkakoty

Description of Module

Check various feature of the administrative terminal

Pre condition

Must be connected to the client machine

No.

Actual Input

Expected Result

Actual Result

Status

(Pass/Fail)

Error

Correction Measure

1

View Process

Message (“Command successful”) and listing of process

2.

Kill process

Message (” the process killed”) and redirects to view process page

3.

Log off and change password

System logged off and the password is changed

4.

Restart

The machines restarted

5.

Shutdown

The machines are shut down

Test Case 7

Project Name

Smart Whistle Blower

Test ID

007

Testing Module

Enhanced & special feature module

Testing method

Unit & Integration Testing

Date

Feb 2011

Name of tester

Boris Borkakoty

Description of Module

Check various feature of the enhanced functionality

Pre condition

Must be connected to the client machine

No.

Actual Input

Expected Result

Actual Result

Status

(Pass/Fail)

Error

Correction Measure

1

Chat notification

Chat message activated and received

2.

View live or print screen of client machines

Client machine print screen received

3.4 Evaluation on success criteria

The proposed criteria are minimal in number as well as in performance standards. To evaluate on how successful this project is, these criteria are considered:

User Requirements

All the user requirements should be clearly defined, and then only the project will become successful.

Evaluator: Supervisor and end user

Research and Analysis

The research and analysis should be done very carefully done so that all the information presented in the project cab be verified and should be accurate. If the research will not be good, all the effort of making the system will go in vain.

Evaluator: Evaluator

Functionality of the system

All the functionality of the system should be well edged out at the last so that all the functions work well during the presentation. If any function is not developed properly then the project will be a failure.

Evaluator: Supervisor and end user

Usability & HCI (Human Computer Interaction) Evaluation: System usability will be evaluated here. Is it comfortable for users or network administrator to use the system? Are they easily able to communicate with the system? Is each and every module performing the desired functionality? Answer of these questions will tell the usability of system. “YES” answers means system passed usability principles.

Evaluator: Supervisor, Supervisee and End users

Project management

The project has to be managed well so that all the aspects of the project development are carried well.

Evaluator: Supervisor

Testing

After developing the system, the job is not over. System testing should be done in order to check whether the system is free from errors and bugs or not. After the testing one can say that the system is fully functional.

Evaluator: Developer

Documentation

The documentation has to be done in such a way that anyone who reads it understands it as well. It is the documentation only which is the explanation of your system. The entire documentation standard should be carefully followed.

Evaluator: Supervisor

3.5 Work Breakdown Structure

Total Duration 34 weeks

Planning(Estimated time: 4 weeks)

Pre-proposal (Duration: 1 week)

Identify Project

Prepare abstract PPF

Prepare draft proposal.

Finalize project title.

Project specification (Duration: 3 weeks)

Identify project task

Identify project scope

Identify Resources

Identify techniques to be learn

Select methodology

Prepare PSF

Prepare Research plan

Prepare Design plan

Prepare Development Plan

Prepare Test Plan

Prepare WBS

Prepare Gantt chart

Analysis & Design (Estimated Time: 15 weeks)

System Research (Duration: 2 weeks)

Perform primary research (Questionnaire and Observation)

Academic Research

Research on the functional areas of the project

Review of Literature

Categorize project modules

System Analysis and Design (Duration: 9 weeks)

Analyze user requirement

Analysis Use case model

Draft Use case specification

Content Analysis

Interaction Analysis

Functional Analysis

Configuration Analysis

Analysis Class diagram

Analysis Sequence diagram

Architectural Design

Navigational Design

Story Boarding

Prototype Design

Technical Learning (Duration: 4 week)

Finalize programming languages

Learn the basics for the usage in the project

Identify third party tool and work on it

Implementation (Estimated time: 10 weeks)

Core Functionality Modules (Duration: 3 week)

Analyze the module

Code the module

Perform unit testing on the module

Document the module

Enhanced Functionality Module (Duration: 4 week)

Analyze the module

Code the module

Perform unit testing on the module

Document the module

Special Functionality Module (Duration: 2 weeks)

Analyze the module

Code the module

Perform unit testing on the module

Document the module

Integrate all the modules (Duration: 1 week)

Testing &Documentation (Estimated time: 5 weeks)

Testing (Duration: 3 weeks)

Perform integration testing

Perform system testing

Perform system integration testing

Perform user acceptance testing

Documentation (Duration: 2 weeks)

Develop User Manual

Compile system documentation