Description Of Waterfall Model Information Technology Essay
✅ Paper Type: Free Essay | ✅ Subject: Information Technology |
✅ Wordcount: 3448 words | ✅ Published: 1st Jan 2015 |
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.
Get Help With Your Essay
If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service
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
Cite This Work
To export a reference to this article please select a referencing stye below:
Related Services
View allDMCA / Removal Request
If you are the original writer of this essay and no longer wish to have your work published on UKEssays.com then please: