Date post: | 21-Dec-2015 |
Category: |
Documents |
View: | 216 times |
Download: | 0 times |
Outline
• Project summary• Architecture• Performance budgets• Design considerations:
– maintainability, reliability, simplicity
• Human interface• Test plan summary and design for testability• Complexity• Updated function points, QFD, ICED-T, and
COCOMO cost estimate• Gantt chart
Project Summary
• The product provides a user friendly, efficient interface for students to create and modify class schedules and study plans.
• MOV:– Course scheduling and registration time eliminated by an
average of 20 minutes per student per semester
• Requirements:– Visual schedule creation and editing– Schedule suggestion– Schedule comparison view– Study plan designer– Monitor closed courses
Architecture Introduction
• The system is an ASP.NET web application that allows students to create and edit schedules for upcoming semesters, and study plans. It offers fast data transfers without web page refreshes, an easy to use interface, and compatibility with many browsers and environments. The system is reusable, requiring only small modifications for new customers (typically, other universities).
• The basic architecture is “thin-server”, “fat-client”– Centralized server allows users to work from anywhere– Server is a simple data repository, without business logic.
This reduces server load, by making each client browser do its own computations.
Evolution of Client Architecture
– Standalone Java application– Standalone C++/GTK+ application
• At this point, misunderstanding with customer is realized.
– Java applet– ASP.NET web application– ASP.NET web application with Javascript
communication for data transfers
Logical View
HTML Communication Data-heavy Communication Path (Javascript)
Customer-Specific Implementation
External Systems (Customer-Provided)
Preferences
Schedule Load, Save, Import, Export
Schedule Editor
Course Search and Filter
Conflict Detector
Custom Time Blocks
Schedule Suggestion
Account Management
Schedule Management
Course Data
ASP.NET (Pre-existing framework)
Main Datastore
Login Validation, Session Creation Data Loader Service
Login and Authorization (Stevens-hosted)
Periodic export of schedule data
Ser
ver
Clie
nt
Course Status Notifier Service
Study Plan Editor
Study Plan Management
Study Plan Load, Save, Import, Export
Schedule Comparison View
Reu
sab
le
COH: 20CPL: 28/20 = 1.4
Overall Process View
Login Process
Page Loading Process
Data Transfer Process
Data Loader Process
Course Status Notifier Process
In the following slides, we will examine each process in detail.
COH: 5CPL: 2/5 = 0.4
Process: Login
Stevens log-in web site
(external)
Login Validation,
Session Creation
(1) Token identifying logged-in user is passed to Scheduler Pro
(2) Continue with page requests from logged-in user
Process: Page Loading
Client Web Browser
Server
(1) Send HTTP request for page
(3) Return page through HTTP
(2) Perform ASP.NET server-side processing, if necessary
Process: Data Transfer
Client Web Browser
Server
(1) Open an XMLHttpRequest connection, send request
(4) Return data packaged as Javascript code Main Datastore
(2) Access requested data
(3) Return result
Process: Data Loader
Data Loader Service
File Lock
(1) Wait for file lock to be removed
Periodic export of schedule
data
(2) Read file
Main Datastore (3) Update local data
Stevens Data Updater Service
(external)
(A) Wait for file lock to be removed
(B) Lock file, update file, release lock
Process: Course Status Notifier
Course Status Notifier Service
(1) Check status of all courses being monitoredMain Datastore
(2) Send email notification to any user for whom courses have opened
Development View
Server Processing Classes (C#)
Domain-Specific Classes (C#)
ASP.NET Framework
Course, ScheduleBlock, Section, Meeting, Term, ScheduleSetting, Student, ScheduleCustomBlock, Audit, StudyPlan, etc.
Data Loader Service (C#)
Client ASP Pages (C#)
- Account Management- Schedule Management- Study Plan Management- Course Data- Login Validation
- Schedule Editor- Study Plan Editor- Schedule Comparison View- Preferences- Help Pages
Course Status Notifier Service (C#)
Javascript Files
Import
Hardware, Operating System
- Schedule L.S.I.E.- Study Plan L.S.I.E.- Course Search and Filter- Conflict Detector- Custom Time Blocks- Schedule Suggestion
COH: 7CPL: 4/7 = 0.6
Physical View
Server
Contains:- The deployed ASP.NET project- SQL Server database- Data Loader and Couse Status Notifier running as Windows Services
Software required:- .NET Framework v1.1- IIS version 5.1- SQL Server 2000- Windows 2000, XP Pro, or Server 2003
Recommended Specifications:- Pentium4 2GHz or equivalent- 1GB memory- 50GB storage
Availability:- 7am to 4:45am daily, service and backups during offtime
Scalability:- To scale up:
- Upgrade to better hardware- Use multiple web servers- Place DB on separate server
Client
Software required:- Any of these browsers:
- MS Internet Explorer 5.0+- Mozilla Firefox 1.0+- Apple Safari 1.2+
- Any OS that runs one of these browsers
Recommended Specifications:- Pentium2 200MHz or equivalent- 128MB memory- 20MB storage- Minimum resolution of 800x600 with 8-bit color
InternetCustomer’s Internal Network
Contains:The user login system and course data
Optionally, the server and client machines can also be located inside this network
COH: 2CPL: 2/2 = 1
Example Scenario
Server
Schedule Management
Course Data
ASP.NET
Client Browser
Login and Authorization
(Stevens-hosted)
Login Validation, Session Creation
1
2
3
4 5
Schedule Editor6
Course Search and Filter7
8
Main Datastore
9 10
11
13 14
Schedule Load, Save, Import, Export
16
17
1) Client browser accesses Stevens Login page2) Client is authenticated, and a token indicating client’s identity is passed3) Session is created in ASP.NET4) Client requests the Schedule Editor page5) Server returns the Schedule Editor page6) User selects “Create new schedule for Fall 05” option7) The courses for Fall 05 are requested8) Request is routed through JS Comm. Path to server’s Course Data module9) The Course Data module, through ASP.NET, requests the Fall 05 data from main datastore
10) The Fall 05 data is returned to the Course Data module11) The Fall 05 data is returned through the JS Comm. Path to client12) User filters data by “CS Dept courses, not with Prof. Bloom”13) User drags over desired courses to schedule14) User selects “Save schedule” option15) The schedule is sent to the Sched. Load/Save/Imp/Exp module for saving16) The schedule is sent to Sched. Mgmt. module through JS Comm. Path17) The schedule is saved to the main datastore
12
15
Performance
• Considerations:– The heaviest use of the system will be during the two
weeks before registration begins.– The system will be used the least from the add/drop
deadline of one semester until the time that course information for the following semester is released.
– There are 3500 students at Stevens– Students take an average of 6 courses per semester– There are about 1200 different course sections during a
fall or spring semester at Stevens– The size of the course data export file is about 200KB.
Performance
Client• The response time of the server to a client request
should not exceed 10 seconds• Interaction within the client that does not involve
data transfers should not stall for more than 1 second
Server• The server should handle up to 200 simultaneous
users with no performance degradation• The Data Loader module should not take longer
than 10 minutes to complete• The Course Status Notifier module should not take
longer than 10 minutes to complete
Design for Maintainability
• The “thin server” simplifies maintenance.
• Central location of all data simplifies maintenance on it, such as changing formats.
• High reusability: New customers need only change the Login and Data Loader modules to use the system.
• Modular design of ASP pages and Javascript code
• Integrated user documentation
• Detailed code documentation
Design for Reliability
• The stated availability allows for daily backups, service, and reboots of the system
• Connections to server are minimized, reducing overall activity on the server
• Parnas reliability checklist:– Failures in communication, secondary storage,
memory, or any hardware that may interrupt a transaction:
• The SQL Server DBMS will not commit incomplete transactions. User will be notified of the error, and will have to redo the transaction.
– Operator error:• All user errors can easily be fixed by the user
Design for Simplicity
• The choice to do a web-based client application over a desktop application simplifies coding of presentation layer:– Easier to create user interface in HTML than by
using desktop application GUI frameworks
• Other alternatives, such as using GTK+ or Java, would require more training of team members than for our web-based client
• User interface follows the existing Scheduler program used by many students, reducing the learning curve
Human Interface
• The user interface will
– Be as similar to the existing Scheduler program as possible
– Follow web interface usability standards
Usability Study Results
Source: http://psychology.wichita.edu/optimalweb/position.htm
Internal Links Internal Links (useful for menu features)(useful for menu features)
Internal Search Engine Internal Search Engine (useful for course search)(useful for course search)
Back to Home link Back to Home link
Help ButtonHelp Button Login/RegisterLogin/Register
Test Plan
• We will begin testing when our first increment nears completion
• Test cases for all versions
• Naïve users with a range of experience with scheduling programs
Test Plan
Testing Requirements• IE 5.0+, Firefox 1.0+, Safari 1.2+ on user’s computer• Our development and testing server
– .NET– IIS– SQL Server– Windows Server 2003
Test Plan
• Regression Testing– All old features will still be used heavily by users
• Stress Testing– Many naïve users accessing at the same time– Simulate usage close to registration dates
Test Plan
• Compatibility testing– Test in all browsers– Use IE’s error reporting– Use Firefox’s Javascript console
• Cross-platform testing– Test on Windows, Mac, Unix
Design for Testability
• Easy, web based interface• New features are added separately in different versions so all can be tested thoroughly• Data loading and schedule modification can be tested separately
Sample Test Case
Course Conflicts – Input
• User wants to add 2 courses which coincide• Finds courses from list via search, adds both• Program will confirm that conflicting class should be added
Sample Test Case
Course Conflicts – Output
• User must then be able to clearly view information on both courses• Must be able to tell that they are conflicting courses• Must be able to remove either one of them without affecting the other
Complexity
• We have measured complexity by:– Calculation of coupling/cohesion for each
architecture view– Amount of function point reduction– Complexity charts for server, client, and overall
product
Complexity: Coupling/Cohesion
• As shown in each architecture view, coupling and cohesion was calculated for each view. – Logical view, Process view:
• Cohesion: Number of modules• Coupling: Number of one-way arrows / number of
modules
– Development view:• Cohesion: Number of packages• Coupling: Number of “uses” occurrences between two
packages
– Physical view:• Cohesion: 2 (server, client)• Coupling: 2 (communication in both directions)
Complexity Chart - Server
• Project Type: online transaction
• Problem Domain: 1
• Architecture Complexity: 2
• Logic Design – Data: 2
• Logic Design – Code: 2• Total Score: 7• Complexity = (7/18) * 5 = 1.94
Complexity Chart - Client
• Project Type: online transaction
• Problem Domain: 2
• Architecture Complexity: 3
• Logic Design – Data: 2
• Logic Design – Code: 3• Total Score: 10• Complexity = (10/18) * 5 = 2.78
Complexity Chart - Overall
• Project Type: online transaction
• Problem Domain: 2
• Architecture Complexity: 3
• Logic Design – Data: 2
• Logic Design – Code: 3• Total Score: 10• Complexity = (10/18) * 5 = 2.78
Function Points
Function Low Average High Total
Outputs 0 3 0 15
Inquiries 2 1 0 10
Inputs 4 3 0 24
Internal Files 2 2 0 34
External Interfaces
0 2 0 17
Total UFP 100
AFP 104
QFD
Customer Goals/Program
Features
Class Filter Allocate non-class time
Persist information
between sessions
Authenticate against Pipeline
Make scheduling
classes easier
8 3 6 2
Make scheduling a
semester easier
7 9 8 2
Scheduling information in
one place
1 1 5 7
Total 16 13 19 11
Scale: 1 to 10 (weak to strong)
ICED-T
Version Used Intuitive Consistent Efficient Durable Thoughtful
Paper 3 2 2 2 3
Excel 3 2 3 3 3
Rob Evans Scheduler
3 4 4 3 4
Scheduler Pro
4 4 5 4 5
Scale:1- Worst I’ve ever seen2- Worse than average3- About the same as other applications I’ve used4- Better than average5- The best I’ve ever seen
COCOMO
• Organic project: small group developing in known environment
• Javascript has an average of 42 lines of code per function point
• ~ 4300 lines code
• COCOMO says that’s 11.2 “staff” months of work
• Our usage of XMLHTTPRequest and HTML/ASP.NET will likely result in less LOC, so the above is an overestimate