Course Presentation EEL5881, Fall, 2003

1
Course PresentationEEL5881, Fall, 2003

• Project Network Reliability Tests
• Team Gladiator
• Shuxin Li
• Victor Velez
• Xin Bai

2
Overview

• Current System problems
• Proposed System
• Requirements
• Specification
• Software Project Management Plan
• Software Requirement Specification
• Test Plan

3
Current system problems

• Servers tests are not reliable given a domain at
  any random time.
• The servers are monitored by manual
• Doesnt monitoring nor logging the
• machines available in a domain.
• No statistical analysis is performed.

4
Proposed System

• The ping Network Management tool can
• Monitoring network services status
• telnet, web, ftp, ssh, smtp and pop3
• Every event of network status will be recorded
  and displayed in services detail
• Client can configure the parameters
• CSV logger (comma-separated-value)
• Email notification
• UI notification (User Interface)

5
Operational Scenarios

• User begin to load new server lists.
• User press begin monitor button
• The system will show all monitored servers status
  at services detail
• System will show the statistics chart
• User press stop monitor button
• System will stop monitoring
• User can configure the parameters
• System will keep historic situations of monitored
  servers.

6
Operational Features

• Must Have 
• Allow user import the correct server list file
  (Config.xml)
• The capacity of monitor all possible type of
  servers
• Show all services details
• Show all current faults (server down, bad ping
  package reply..)
• Keep all servers status history
• Show the real-time statistics
• Generate log file
• Would Like to Have
• Ability for user to configure the parameters
• Distinguish the different server status by
  different colorful logo

7
Expected Impacts  

• Automatically monitor different types of servers
• Display the current services detail and faults
  with no delay
• Use statistics chart to help user get visualized
  results
• Allow user to configure the log file and
  notification method
• CVS log
• E-mail Notification
• UI Notification
• Best tool designed for collecting server status
  information. 
• Higher effectiveness
• Friendly user interface design

8
Software Environment

• System Processor
• P2 233Mhz or above
• Operating System
• Windows 2000 or Windows xp
• Other Requirement
• Must have java JDK 1.4
• Programming environment
• Borland Jbuilder 9.0

9
Project Management Plan

• Software Life Cycle process

10
Project Management Plan

• Project Team Organization
• Democratic team organization
• Egoless programming.
• No single leader.
• Shuxin Li, Xin Bai, Victor Velez are in the team.
• All the technique decisions will be discussed and
  finally made democratically.
• Communication will be handled through email and
  scheduled face-to-face meetings when ideas and
  design need to be decided.

11
Project Management Plan

• Quality Assurance
• Non-execution based testing - Walkthroughs (the
  participant driven approach).
• Each team member also act as a QA member, detect
  and record each others faults.
• Risk Management
• Clients resistance to change
• The iterative process inherent in the Waterfall
  model will help us in managing this risk.

12
Deliverables Timetable
13
Software Requirements Specification

• Product Overview
• The software will run under a windows Environment
• The software will be able to monitor
• Web services http and https 
• Email servers POP3, SMTP
• FTP servers
• Telnet or ssh servers
• The software will report
• Real-time Statistic chart
• Services detail and current faults

14
Event Table
15
Use Case Diagram
16
Software Requirements Specification

• Use Case Descriptions
• Load server list - the user import a server list
• Start monitoring - the user will let system begin
  to monitor all required servers
• Stop monitoring - the user will stop monitor all
  required servers
• Configuration - the user will configure three
  parameters
• CSV logger comma-separated-values log file
• Email notification configure the smtp email
  server
• UI notification configure user interface
  notification

17
Software Requirements Specification

• Check statistic result The system will show
  user the statistic chart with X axes represents
  the time while Y axes represents the faults
  detected
• Check history The system will show user the
  overall servers status history including
• Alive
• Dead
• Bad reply

18
Test Plan

• Overall Objectives
• Find as many errors as possible before the user
  of the software finds them
• Ensure good software quality, that is, a robust
  final product
• Make sure that our software adheres very closely
  to the client requirements and specification
  documents

19
Test Cases

• Case 1
• Objective to demonstrate the behavioral sanity
  of the system.
• Description 
• Whether the software is starting properly.
• Whether the Graphical User Interface (GUI) is
  displaying correctly and its feel and look is
  consistent with rest of the application.
• Whether the GUI is displaying the fields
  correctly.
• Whether the software is stopping properly.
• Test Condition We will test it for both
  development environment and test environment
• Expected Results Information is displaying
  properly in the GUI

20
Test Cases

• Case 2
• Objective demonstrate the functional correctness
  of Import the server list module.
• Description  check if a given server list .xml
  file is correct, The system will accept it and
  ready to monitor. If a give server list file is
  incorrect, The system will give an alert asking
  for the right file.
• Test Condition We will test it for development
  environment and test environment
• Expected Results Only correct .xml file will be
  accepted

21
Test Cases

• Case 3
• Objective demonstrate the functional correctness
  of Monitor module.
• Description 
• As soon as correct server list is loaded and user
  has pressed the start monitoring, the software
  can monitor all the servers simultaneously
• Each server status will be displayed and recorded
  at the same time
• Test Condition We will test it for both
  development environment and test environment
• Expected Results Software will distinguish
  different type of servers and be able to monitor
  all servers, showing the servers status

22
Test Cases

• Case 4
• Objective demonstrate the functional correctness
  of Statistic module.
• Description 
• As soon as correct server list is loaded and user
  has pressed the start monitoring, the software
  can draw a real-time fault-detected chart
• Test Condition We will test it for both
  development environment and test environment
• Expected Results Software will draw the
  statistic chart with no delay

23
Test Cases

• Case 5
• Objective prove that the system works as
  integrated unit when all the fixes are complete.
• Description  it demonstrates whether all areas
  of the system interface with each other
  correctly. Also test whether the software has
  error handling behavior for every possible error.
• Test Condition test it for both development
  environment and test environment
• Expected Results The system integrates well and
  execute correct functions. The system passes the
  above functional tests as one integrated system

24
Test Cases

• Case 6
• Objective demonstrate the compatibility of our
  software with other hardware.
• Description 
• We will install our software on other types of
  computers such as with different processors,
  speeds and capabilities
• We will check our software on these computers
• Test Condition We will test it for both
  development environment and test environment
• Expected Results We expect our software to pass
  these tests for different system environments

25
Snap
26
Thank you!