2 - Iowa State University
Internet Centralized K-12 Homework
Assignment Capability
Final Report
Senior Design May 04-06
Client: Senior Design project Ongo-08
Team Members:
Michael Bravo III Kathryn Lamont
Lauren Marshall Richard Patrick
Faculty Advisors:
Yong Guan Thomas Daniels
REPORT DISCLAIMER NOTICE
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.
May 5, 2004
Table of Contents
List of Figures iii
List of Tables iv
List of Definitions v
1 Introductory Materials 1
1.1 Executive Summary 1
1.2 Acknowledgements 1
1.3 Problem Statement 2
1.4 Operating Environment 2
1.5 Intended User(s) and Intended Uses 2
1.5.1 Intended Users 2
1.5.2 Intended Uses 3
1.6 Assumptions and Limitations 3
1.6.1 Assumptions List 3
1.6.2 Limitations List 4
1.7 Expected End Product and Deliverables 4
2 Project Approach and Results 4
2.1 Functional Requirements 5
2.2 Design Requirements and Constraints 5
2.3 Technical Approach Considerations and Results 6
2.3.1 Server Considerations 6
2.3.2 Server Results 6
2.3.3 Language Considerations 6
2.3.4 Language Results 7
2.3.5 Database Considerations 8
2.3.6 Database Results 8
2.3.7 Technical Approach Results 8
2.4 Detailed Design 8
2.2.1 Login Page 10
2.2.2 Student Side 10
2.2.2 Teacher Side 11
2.2.3 Computer Administrator Side 14
2.2.4 Log Page 19
2.2.5 Database 20
2.5 Implementation Process Description 21
2.6 Testing approach and Results 22
2.7 End Results of the Project 23
3 Resources and Schedules 23
3.1 Resource Requirements 24
3.2 Schedules 26
4 Closing Materials 28
4.1 Project Evaluation 28
4.2 Commercialization 29
4.3 Recommendations for Additional Work 29
4.4 Lessons Learned 30
4.4.1 What Went Well 30
4.4.2 What Did Not Go Well 30
4.4.3 Technical Knowledge Gained 30
4.4.4 Non-technical Knowledge Gained 31
4.4.5 How to Do the Project Differently Next Time 31
4.5 Risk and Risk Management 31
4.5.1 Anticipated Potential Risks and Planned Management 31
4.5.2 Anticipated Risks Encountered and Successful Management Thereof 31
4.5.3 Unanticipated Risks Encountered, Attempts to Manage, and Success Thereof 31
4.5.4 Changes in Risk Management Resulting from Unanticipated Risks Encountered 32
4.6 Project Team Information 32
4.1.1 Client information 32
4.1.2 Faculty Advisor information 33
4.1.3 Student Team information 33
4.7 Closing Summary 33
References 34
Appendix A – Database Table Information 35
Appendix B Test Report 36
List of Figures
Figure 1: Client Server Model 9
Figure 2: Login Page 10
Figure 3: Student Webpage 11
Figure 4: Teacher Add Assignment Page 12
Figure 5: Teacher Edit Assignment Page 13
Figure 6: Administrator Index Page 14
Figure 7: Administrator Add Student/Teacher Page 15
Figure 8: Administrator Remove Student/Teacher Page 16
Figure 9: Administrator Change Password/Permission Page 17
Figure 10: Administrator Add Course Page 18
Figure 11: Administrator Add Student Absence Page 19
Figure 12: Administrator View Log Page 20
Figure 13: Database Layout 21
Figure 14: Original Task Gantt Chart 27
Figure 15: Revised and Actual Task Gantt Chart 27
Figure 16: Deliverables Gantt Chart 28
List of Tables
Table 1: Personnel Effort Requirement 24
Table 2: Revised Personnel Effort Requirement 24
Table 3: Other Required Resources 25
Table 4: Revised Other Resources 25
Table 5: Actual Other Required Resources 25
Table 6: Original Estimated Project Costs 25
Table 7: Revised Estimated Project Costs 26
Table 8: Evaluation of Milestones 29
List of Definitions
Apache – Apache is a UNIX based web server that is open source to the public.
ASP – Active server page is a language used to create dynamic web applications.
Authentication – Authentication is a term used to describe the process by which a user’s identity is verified in the system.
JavaScript – JavaScript is a language used for client side scripting necessary for web applications.
mySQL – mySQL is an open source relational database used for web applications.
Open source – Open source is a term used to describe source code that is free to the public to use, change, and/or modify.
PHP – PHP Hypertext Preprocessor is a scripting language used to create dynamic web pages. It is often used to display database information in a web format.
Server – A server is a computer dedicated to hosting the web pages, databases, and other web applications.
Session management – Session management is a method of controlling usage of an application by limiting access to users that have logged in.
Source tracking tool – A source tracking tool is a software product that allows multiple users to work simultaneously on the same code and merges code changes into one version.
User interface – (UI) A user interface is a graphical display that allows the user to easily interact with the program.
Web application – A web application is a piece of software that runs over the internet and allows transfer of data between multiple computers.
White box testing – White box testing is testing done with knowledge of code. This testing is often done by developers.
XML – EXtensible Markup Language is a language similar to HTML that is used to describe data objects in web pages. It allows them communicate effectively by giving meaning to the data contained in tags.
1 Introductory Materials
This section overviews the project that has been completed. It includes an executive summary, acknowledgements, and a problem statement. It also includes information about the operating environment, the intended uses and users, assumptions, limitations, and the expected end-product.
1.1 Executive Summary
The Internet Centralized K-12 Homework Assignment Capability project was created because of a need to have a way for students that are absent from school to easily obtain missed assignments. A web application with a database was planned, designed, implemented and tested.
The application was designed having three types of users and thus three sides of the application. The application is called assignNET and has a student side, a teacher side, and an administrator side. The project activities consisted of first looking at possible implementation approaches as well as looking at the client’s needs. Since the client has a PHP and mySQL set up on the rest of its software package, a similar setup was chosen for this project. The designing part of the project dealt with determining the specific functionalities that each user needed. For example, administrators must be able to create users, remove users, create classes, remove classes, edit profiles, etc. Teachers must be able to add and edit assignments, while students must be able to view assignments they missed, and it is also necessary for the student to be able to archive old assignments.
Prototyping of specific pages was done using Microsoft FrontPage. During implementation the prototypes served as a guide. Implementation was divided throughout the team with one member focusing on the teacher side, one member focusing on the student side and two members focusing on the administrator side.
Testing was mostly white box testing and testing was done throughout the implementation. The project was successful in creating a web application that would allow students to access missed assignments.
1.2 Acknowledgements
Senior Design Team Ongo-08, K-12 Teaching Application Support and Software, for providing a server, for guidance and for help configuring the server.
Dr. Thomas Daniels, Assistant Professor, Iowa State University, for technical advice and direction.
Dr. Yong Guan, Assistant Professor, Iowa State University, for technical advice and direction.
1.3 Problem Statement
When students are absent from class, whether it is a single absence or an extended absence, they miss important assignments and handouts that put these students behind in class. If a student is unaware of all assignments, especially if this absence is extended, the work can quickly pile up. There is a need for a way for students who have missed classes to access these missed assignments and handouts. This would allow students the chance to stay on schedule. A web-based application with an underlying database would make it simple for students to access these assignments from home.
1.4 Operating Environment
The operating environment for this project is a personal computer (OS X, Windows, Linux). The web application is the teacher's and students’ main working environment. The server is owned and maintained by Ongo-08. The user interface is platform independent.
1.5 Intended User(s) and Intended Uses
This section discusses the intended users and intended uses of the completed project. It discusses assumptions/limitations of the users, and then discusses how the completed project is expected to be used.
1.5.1 Intended Users
The user of the web application is a minimum age of 8. The user has a minimum 3rd grade education level, which means that the user has basic computer skills. Students with physical or mental disabilities that do not allow them to operate basic functions of a computer will require adult supervision or assistance to retrieve the online assignments. Students in grades kindergarten through 2nd grade will require the help of a parent or guardian.
Teachers need an education degree or student teaching experience in their respective teaching field. They need to have computer skills advanced enough to allow them to teach or guide students in how to access the assignments. The teachers also need to be able to enter and edit data from the web page. A help document is provided online to assist the teacher.
Computer administrators need to be adults with experience in configuring and deploying web-based applications. They need to be familiar with the server as well as have basic knowledge about the system operations.
1.5.2 Intended Uses
The web page is intended to be used for the retrieval and posting of assignments. The web page is primarily to be used to retrieve assignments by students that have missed class. Teachers post homework assignments, and they need to be able to post downloadable assignments in .doc, .pdf, .ps, .txt, .html, .gif, or .jpg files. Administrators add and delete classes, students, and teachers from the system. They are responsible for adding student absences to the system. Administrators also maintain and update the system as necessary. Administrators can view the log to see what users have done while online.
[pic] [pic]
1.6 Assumptions and Limitations
This section includes the basic assumptions made for the web application. It also contains a list of limitations of the software and operating environment.
1.6.1 Assumptions List
This is a list of assumptions taken into consideration in the design of the system.
• User is at least 8 years of age.
• User has the equivalent of a 3rd grade level of education.
• Students who do not have a 3rd grade education or are under age 8 will receive help from a qualified person.
• User has basic computer skills, including the ability to use a mouse.
• User has a computer system that is connected to the Internet and has enough memory to run normal web applications.
• Any student with mental or physical disabilities that would affect their use of the application receives help from a qualified person.
• Server is provided.
• Server is secure.
• The development server is the server where the application will be run. If the application is deployed for use by the school, the development server continues to host the application.
• Application is primarily for students who were absent from class.
• Application is designed only for one school district, the Ames Community School district.
• Teacher needs to have an education degree or student teaching experience in his/her respective teaching field.
• Teacher needs to have computer skills that are advanced enough to allow them to teach or guide student in accessing website.
• Teacher needs to be able to enter and delete data from web page.
• Computer administrator has a minimum of a 2 year computer degree and/or relevant computer experience.
• Computer administrator is the only person to add and delete students, teachers and classes from the system.
• Computer administrator is familiar with the server and the system.
• Users have JavaScript enabled on their personal computers.
1.6.2 Limitations List
This is a list of limitations taken into consideration in the design of the system.
• Application shall be developed using open source software.
• Server has been previously configured.
• Text must be simple and concise for a 3rd grade user.
• Hyperlinks must be no more than two levels deep.
• Many users may have slow internet connections.
• Cookies may not be used for session management.
• Development and testing shall be completed in approximately four months.
• Users may not be able to view certain uploaded documents due to the software installed or not installed on individual computers.
1.7 Expected End Product and Deliverables
The expected end product shall be a web-based application including a student/parent interface, a teacher interface, a computer administrator interface, an underlying database, log file, and user help documentation. This software product shall be delivered to the senior design Ongo-08 team in May 2004 to be used as a part of their teaching application software package. It is expected to be used by teachers to post missed homework assignments for students who have been absent from class. It is also to be used by students to access missed homework assignments.
2 Project Approach and Results
This section contains information about the essential components of the project necessary for success. These include such things as requirements and constraints. It also contains information regarding the project implementation, testing, as well as end product results.
2.1 Functional Requirements
This functional requirements section defines the functions that the website will implement.
• Login screen – This interface is used to authenticate a user. There is one login screen for the application.
• No more than two hyperlinks deep – This requirement is intended to ensure easy navigability in the system. All information contained in both the teacher and the student applications is able to be accessed by clicking a maximum of two hyperlinks.
• User authentication – This is used to maintain security of the system and for the individual user. All users need to use a password to login to the system. It also directs user to correct index page.
• Unique user interfaces for students, teachers, and administrators – This allows a teacher to alter the website, and prevent a student from making changes to it. It also allows administrators to add, delete, and edit the students, teachers, and other features of the system.
• Assignment list - The names of the students who missed class are entered into the database by the computer administrator so that a list of assignments can be compiled for the student. This computer administrator could be a secretary in the attendance office who enters in absences. When a student logs on, the student’s classes can be viewed including a list of assignments with due dates and worksheets attached.
• Student assignment confirmation - When a student wishes to archive an assignment, they may check a box next to the assignment that will make it no longer appear in this list but will send it to the archived list.
• Archives list – After a student has chosen to send an assignment to the archived list, they may click a button that retrieve it.
• Assignments - Teachers are able to upload worksheets and other materials to the website so that students can download them. These maybe be .doc, .pdf, .ps, .txt, .html, .gif, or .jpg files.
• Log – A log entry is entered into the database for logins, logouts, adds, removes, and other changes to database.
• Session Management – Verifications are in place on every page to limit usage to only those users that have logged in and have the privileges to view that page.
2.2 Design Requirements and Constraints
This section defines the constraints that are implemented on the website, and what considerations are taken into account.
• Maximum memory – There is a certain amount of memory that is allocated for each user that logs on.
• Maximum database size – The database needs to be cleaned up periodically to ensure that it does not grow too large to handle.
• Maximum time for information availability – After four weeks the assignment will be archived automatically.
2.3 Technical Approach Considerations and Results
This section is broken down into several sections detailing the approaches considered for servers, languages, and database methods.
2.3.1 Server Considerations
The following servers were considered for the project.
Apache
• This is the server that the project’s client (Ongo-08) currently owns. It is already configured with PHP and mySQL capabilities. Using this server means the team does not have administrative privileges.
Virtual Apache Server
• This server is a virtual server set up by the computer support group (CSG) for the Department of Electrical and Computer Engineering. The group would have administrative privileges. It would be necessary to set up most of the server details.
2.3.2 Server Results
Initially the group decided to go with the Apache server that Ongo-08 owned. After many issues with not having administrative privileges and with the possibility that Ongo-08 was going to clean the server, the team decided to have a virtual server created midway through implementation. Some set up was done on the new server, however with the time constraints of the end of the project and with little team knowledge on setting up Apache servers, the team continued using the first server and frequently backed up all data.
2.3.3 Language Considerations
Many various languages were initially considered for this web application.
PHP
Pros
• It is well suited for web development.
• It is easily embedded into HTML.
• It is already installed on the server provided.
• It works well with an Apache server.
• It allows for necessary dynamic needs.
Cons
• Most team members are not familiar with it.
ASP
Pros
• Some of the team is familiar with this language.
• It works great with VB, C++ and C#.
Cons
• ASP is not supported on the server provided.
JavaScript
Pros
• This allows for client side scripting, necessary for web applications that need to use functions like onchange or onclick.
• It works well in many browsers.
Cons
• None of the group is very familiar with this language.
• There is little documentation.
XML
Pros
• It is more versatile than HTML.
• There is no need for an underlying database.
Cons
• None of the group is very familiar with XML, and PHP seemed to be the better (and more convenient) choice.
2.3.4 Language Results
PHP was chosen as the language to use for making the HTML page dynamic. PHP was already set up on the server. It is also the language which the rest of the client’s package is created in. Since the group chose PHP, a period of getting comfortable with the language was necessary. Half way through implementation, the team realized the need for some client side scripting for functionalities like pop-up windows and to populate data when a user selects an item. Thus some JavaScript was also used, assuming that all users would have computers that could run JavaScript.
2.3.5 Database Considerations
MySQL
Pros
• It is fast and easy to customize.
• Code reusability is high.
• There is a lot of helpful documentation on building databases.
• It is very stable.
• The code is open source.
• It interfaces well with PHP.
Microsoft Access
Pros
• It is not too complex.
• It is easy to use.
Cons
• It is too simple for what is necessary for the project.
• It is not currently installed on the server provided.
• It would not interface well with PHP.
2.3.6 Database Results
MySQL was decided to be the main database parsing language. It was already set up on the server chosen and interfaced with PHP.
2.3.7 Technical Approach Results
The project will be developed using PHP, mySQL, and Apache as this is the client's desire. This is the same setup as the software package to which this program will be added. The server is already configured for use of these technologies. JavaScript will be used in addition for necessary client side needs.
2.4 Detailed Design
There are three separate pieces of the web application assignNET—the student side, the teacher side, and the computer administrator side. A diagram of the client server model is included in Figure 1.
[pic]
Figure 1: Client Server Model
2.2.1 Login Page
[pic]
Figure 2: Login Page
The application will have one login screen. This login screen uses session management to log the user in and decide what kind of user they are. The user enters their username and their password to login. This screen then authenticates and directs the user to their main page.
Each page then has a basic session management script that keeps track of who is viewing the page. This prevents users who are not authenticated from accessing the pages. A screenshot of the login page is shown above in Figure 2.
2.2.2 Student Side
The student or parent logs on. This takes the student to a page that contains a drop down menu showing the student’s classes. There, the student chooses which class’s assignments he/she wants to view. Next to each assignment is an option for the student to archive the assignment. This allows the student to mark which assignments he/she has viewed and/or completed. A button at the bottom of the list allows the student to send these checked assignments to the archive list. It also keeps the page from becoming overloaded with assignments. Also, assignments more than four weeks old are archived automatically.
[pic]
Figure 3: Student Webpage
The student is able to reach these archived assignments from a second button under the drop down class list. Pressing that button brings a list at the bottom of the page of all the archived assignments for that class. A screen shot of this is shown in Figure 3 above. The only input the student will have besides login information will be the input from the drop down list and marking assignments to archive.
2.2.2 Teacher Side
The teacher side of the application shares the same login page as both the student side and the administrator side. Login verification directs the teacher to the correct teacher pages. Teachers only have access to two pages. These pages allow the teacher to add new assignments and also to edit existing assignments. The teacher is directed after log in to the Add Assignment Page, shown in Figure 4.
[pic]
Figure 4: Teacher Add Assignment Page
On this page a drop down list allows the teacher to chose which of his/her classes he/she wishes to add an assignment too. The teacher then must associate a date with the assignment. The date defaults to the current date, however the teacher can change this if an assignment is inputted at a later date. The teacher also inputs an assignment name and a description of the assignment. If the teacher chooses, he/she can input up to three files.
[pic]
Figure 5: Teacher Edit Assignment Page
The teacher can also edit assignments already in the database, shown in Figure 5. The teacher chooses the class and correct assignment using drop down lists. Then the assignment description is shown in an editable text area where the teacher can edit the description and then submit the changes to the database.
2.2.3 Computer Administrator Side
When the administrator first logs in he/she is taken to an administrator index page, Figure 6. This page allows the administrator to access all other administrative pages and functionalities. This page also allows the administrator to access the administrative help page.
[pic]
Figure 6: Administrator Index Page
[pic]
Figure 7: Administrator Add Student/Teacher Page
Figure 7 shows the administrator page that handles adding students and teachers to the database. First there are checks to make sure that none of the fields are blank. The only exception is that the middle name field may be blank because there is a possibility of a student or teacher not having a middle name. There is also a check to make sure that the password and verification password are the same. When the administrator has completed filling in the required fields the submit button is pressed. On this action the administrator is taken to another page to confirm that this action is to occur. On confirmation of the action the student or teacher is added to the database, and the administrator is returned to the add student or teacher page.
[pic]
Figure 8: Administrator Remove Student/Teacher Page
Figure 8 shows the administrator page that handles removing a student or teacher. To do this the administrator needs to enter the username of the individual they want to delete and press the “Remove User” button. When the “Remove User” button is pressed the administrator will be taken to another page to confirm that they want to delete this particular user. On return to the remove student or teacher page the user’s ID number is searched for and the entries that have to do with that user ID are removed. The student’s entries will be deleted from the database in the table order of absent, enrollment, archives, password, and userList. This order deletes entries from the tables in an order so that the primary keys that connect all the tables are deleted last.
Figure 9 shows the administrator page that handles the functions of changing a user’s password or permission level. At this page an administrator can be created. Of course the administrator would need to add that user on the add student or teacher page, and then come here and change their permission. To change the password the administrator needs to enter the correct username, and then add the new password twice. The password is added twice to verify the password has been entered correctly.
[pic]
Figure 9: Administrator Change Password/Permission Page
To change a permission level the administrator needs to enter the username, old permission level, and then the new permission level. If anything is entered incorrectly, the administrator is notified at the bottom of the screen. When the submit button is pushed and everything has been entered correctly the administrator is taken to a page to confirm that this action is what the administrator wants to do. When the administrator is returned to the change password or permission level page the database is updated with the changes just made. There is also a help button and logout button. The help button pops up another window with frequently asked question were the administrator can get help with what they are trying to do. The logout button returns the administrator to the login page.
[pic]
Figure 10: Administrator Add Course Page
Figure 10 shows the administrator page that handles adding new courses to the database. To do this, the administrator needs to type in the class name and select the teacher that will instruct the class. In addition, when a new course is added, a new unique directory is set up for that class and a unique integer ID will be given to the course.
[pic]
Figure 11: Administrator Add Student Absence Page
Figure 11 shows the administrator page for adding absences. The administrator
clicks the letter at the top of the page for the absent students last initial. A list of students with that initial will appear with checkboxes next to them. The administrator can then check the boxes next to the absent students and select
the radio button for the date the students are absent.
2.2.4 Log Page
Each time a user logins to the system or logs out an entry will be added to the log database table. Log entries will also be created when a student views assignments and archives assignments. When a teacher creates a new assignment or edits an assignment a log entry will be created. Finally when administrators add students/teachers, remove students/teachers, change passwords or permission, add an absent student, add a class, remove a class, or enroll a student in a class a log entry will be created. These entries can then be viewed on the View Log page, Figure 12, which is accessible only to administrators.
[pic]
Figure 12: Administrator View Log Page
2.2.5 Database
The database design is shown in the following layout chart, Figure 13. It includes the fields in each table. The variables types and information are included in Appendix A.
The database table has references between each table. When deleting data from the table, data is deleted in a specific order to assure that the correct data is deleted and does not cause errors.
Figure 13: Database Layout
The database is set up so that all users (students, teachers, and administrators) are in the same table and are differentiated by their permission level. The password table associates the user to a username and a password. Classes are defined not only by their class name but also by the specific teacher teaching the class. This allows for the same class to be taught by different teachers and thus have different assignments. The class is also associated with a directory where all files associated with that class are stored. Enrollment in a class is created by associating one class with one student. Assignments are associated to the specific class and have a name, a date, a description, information about whether they have been archived, and whether they have files associated with them. An archives table keeps track of what assignments specific students have archived. The log keeps track of what a user does while logged into the system.
2.5 Implementation Process Description
In the first semester, the team prototyped user pages for the project. This allowed for a much easier start to the implementation phase. To start, the pages were divided up among team members according to the system user capabilities (end-user/student, teacher, admin). Then the database tables and touples, groups of data within a table, were planned according to what information was needed for the server and what information was needed for the web pages. The next part was creating GUIs for pages. This was very easy since prototypes were already created. The database tables were then created on the mySQL server. The pages were then uploaded on to the server and into a CVS repository. PHP was then implemented into the pages, giving them a little more functionality. The pages also needed to be set up to connect to the mySQL database so that information from the tables can be displayed on the user pages. After the pages were working, they needed to be tied together so that user groups can access the proper pages and cannot access other pages. A login screen was then implemented to handle this.
One of the problems that occurred was access to pages being available for anyone. The login screen was the index file and redirected the user to the proper page, but from there the user could hard code any address to gain access to any page on the server (if the file name was known). To correct this, more research on session management needed to be done. All of the pages on the server were then updated to look for user authentication. Pages could then only be accessed if the user has the proper user level (student, teacher, admin). Another problem encountered was in the creation of the database. The team did not own the server and thus did not have admin privileges that were necessary to create the database. Contacting on of the administrators and working with him solved this. During implementation, one of the team members was unable to log into the server for a large portion of the phase. The problem was eventually discovered with the help of advisors and fixed after much communication. JavaScript is being used to create pull down menus. File uploading is functional. Also, server management has been completed. Thus when a class and assignment are created, directories associated to them are also created. When a class is deleted, the directories and files are deleted from the server.
2.6 Testing approach and Results
As each piece of the application is developed, basic functionality tests are run. The testing that has occurred so far has been mostly white box testing where the tester is also the primary developer and is very familiar with the code. During implementation, each developer kept track of relevant test cases to run when implementation was complete. To test the applications interaction with the database, test pages have been created that output all the current data in a specific table. The developers are checking to assure that correct data is being inputted into the database.
Testing of database interaction, session management, and output are key to the testing phase. At this point testing has been done primarily on Windows machines. Test reports, Appendix B, were planned to be filled out as extended test cases are run. However, extensive testing on this project was not completed due to time constraints. More testing would be necessary to assure all integration and functionalities are correct.
Examples of areas that have had much testing are items such as dates, database insertions, and correct variable values.
2.7 End Results of the Project
The system can be broken up into three sections: student pages, teacher pages, and administrator (admin) pages. The student pages contain at the very least all the features that were originally desired. Students are welcomed by name after a successful login, assignments are displayed and grouped according to class, and each class in which a student is registered in can be selected at any time. Teacher pages contain all features. Assignments can be added to the database. They are organized according to class and date. The project has a feature using JavaScript pull down menus to detect what the user has inputted. This makes the teacher pages more user-friendly. The administrator pages have complete functionality. Students can be marked as absent, students and teachers can be added, and students and teachers can be removed. Classes can be added, removed and students can be enrolled in a class.
Functional requirements were set for the website. Most of these requirements have been met. A login screen has been created, although only one screen has been made instead of the two different screens that were originally planned. Users have to authenticate themselves using a login name and password. There is a unique user interface for students, teachers and administrators. Any one set of users cannot access the other set of users’ pages. Students can be marked as absent on any given day up to 5 week days in the past.
Log files are completed. Log entries are created for logins, logouts, when a student views an assignment, when a student archives an assignment, when a teacher creates an assignment, when a teacher edits an assignment, when an administrator adds or removes users, when an administrator changes passwords or permissions, when an administrator adds an absent student, when an administrator adds or removes a class, and when an administrator enrolls a student in class.
A constraint that was put on the project was to not allow users to log on to the server from more than one computer or make multiple connections to the server at one time. No security has been added to check this. It has been proven possible to make more that one connection with the same user name from testing as well. Another constraint was allowing users a maximum amount of memory. No modules have been created to deal with this constraint as well. While the functional requirements have been mostly completed, the system does not have much error checking in place. Issues such as hitting the back button and resubmitting of files have no set solutions or prevention methods within the system.
3 Resources and Schedules
This section discusses the original personnel effort estimates as well as revised estimates for the individual team members. It presents the original cost and hours needed to complete the required resources estimates as well as revised estimates. It also discusses the estimated project costs and revised project cost.
3.1 Resource Requirements
The following tables explain the original estimates for the number of hours each student will spend on the project, the cost of the project, and the labor costs of the project. After each of these are revised tables containing the same information. Tasks 1 thru 8 are as follows: problem definition, technology and implementation considerations and selection, end-product design, end-product implementation, end-product testing, end-product documentation, end-product demonstration, and project reporting.
Table 1: Personnel Effort Requirement
| |Task 1 |Task 2 |Task 3 |
|Project Poster w/ printing |12 |0 |$60.00 |
|Help Document w/ printing |11 |0 |$20.00 |
Table 4: Revised Other Resources
|Item |Team Hours |Other Hours |Cost |
|Project Poster w/ printing |12 |0 |$60.80 |
Table 5: Actual Other Required Resources
|Item |Team Hours |Other Hours |Cost |
|Project Poster w/ printing |12 |0 |$60.80 |
Table 6: Original Estimated Project Costs
|Item | |W/O Labor |With Labor |
|Parts | | | |
|a. Poster | |$60.00 |$60.00 |
|b. Help Document | |$20.00 |$20.00 |
| |Subtotal |$80.00 |$80.00 |
|Labor at $10.50 per hour: | | | |
|a. Bravo, Michael III | | |$1848.00 |
|b. Lamont, Kathryn | | |$2005.50 |
|c. Marshall, Lauren | | |$1953.00 |
|d. Patrick, Richard | | | $1890.00 |
| |Subtotal | | $7696.50 |
| |Total | | $7776.50 |
Table 7: Revised Estimated Project Costs
|Item | |W/O Labor |With Labor |
|Parts | | | |
|a. Poster | |$60.80 |$60.80 |
|b. Help Document | |$20.00 |$20.00 |
| |Subtotal |$80.80 |$80.80 |
|Labor at $10.50 per hour: | | | |
|a. Bravo, Michael III | | |$1942.50 |
|b. Lamont, Kathryn | | |$2184.00 |
|c. Marshall, Lauren | | |$1984.50 |
|d. Patrick, Richard | | | $1995.00 |
| |Subtotal |$0.00 | $8106.00 |
| |Total |$80.80 | $8186.80 |
Table 7: Actual Estimated Project Costs
|Item | |W/O Labor |With Labor |
|Parts | | | |
|a. Poster | |$60.80 |$60.80 |
| |Subtotal |$60.80 |$60.80 |
|Labor at $10.50 per hour: | | | |
|a. Bravo, Michael III | | |$1023.75 |
|b. Lamont, Kathryn | | |$1401.75 |
|c. Marshall, Lauren | | |$1354.50 |
|d. Patrick, Richard | | |$1102.50 |
| |Subtotal |$0.00 | $4882.50 |
| |Total |$60.80 | $4943.30 |
3.2 Schedules
This section includes the original Gantt charts from the project plan. It also Revised Gantt charts are included showing added subtasks for the administrator side. The new Gantt charts were generated used project management tools that the team is now using to keep track of progress. Revised and actual task Gantt charts are included. The deliverables chart has not changed between the original and the actual.
[pic]
Figure 14: Original Task Gantt Chart
[pic]
Figure 15: Revised and Actual Task Gantt Chart
Figure 16: Deliverables Gantt Chart
4 Closing Materials
This section contains final evaluations of the project including commercialization, risk management and lessons learned. It also contains vital information about the group members, faculty advisors, and the project clients. A closing summary follows at the very end.
4.1 Project Evaluation
Milestones will be evaluated on the following scale:
• Unsuccessful - The milestone was completed in a fashion that would be considered unsatisfactory and would not be appropriate to deploy in its current state.
• Satisfactory – The milestone has been completed to the minimal requirements. More work is needed.
• Successful – The milestone has been completed and achieved its goal.
• Very Successful – The milestone has been completed and has exceeded its goal.
Each milestone has also been given an importance rating. This importance rating is expressed as a percentage and indicates it importance in respect to the total project. Each milestone also has a status. This status is a percentage of completion. Finally, the overall status is calculated by adding together each milestone’s importance multiplied by its status.
Evaluation of Milestones
| |Importance |Status |Success |
|User Interface |45% |100% |Very Successful |
|Database |20% |100% |Very Successful |
|Log File |2% |100% |Very Successful |
|Help Document |8% |100% |Successful |
|Testing |10% |40% |Satisfactory |
|Reporting |15% |100% |Very Successful |
|OVERALL |100% |94% |Successful |
Table 8: Evaluation of Milestones
The user interface, database, log file, and reporting were all very successful. The effort and final product exceeded project goals. The requirements that were set for them have been fulfilled. The help document was successful as it met the goal of the project. However, more extensive help could be created and be useful to the user. This is why this milestone did not get a very successful rating. Testing received a rating of satisfactory. Due to time constraints, little extensive testing was completed. Thus for this milestone to be successful much more testing would be necessary.
Overall the project has been rated has successful. This is because all but one piece of the project was rated as successful or very successful.
4.2 Commercialization
This project was not designed to be commercialized. It was designed specifically for one school district. However, due to many platform independent features of the project, it could be marketed. Additional cost to reproduce this project would simply be the server, setup, and installing the software package. The selling price would rival that of any other major software database package. The market however would be very small as only one copy would be needed for each school district.
4.3 Recommendations for Additional Work
Further work on the project could include adding the pictorial password for the student side. This security feature was looked into, but was found to be inappropriate at this time. As pictorial authentication technology progresses, this could be added to the assignNET system. This would increase the usability for younger students as well as add a unique aspect to the system. Also another added feature would be to allow users’ full names to be changed. Also, the use of the BACK button after logout should not be possible.
Another recommendation would be commercializing the product. It could easily be implemented in many school districts for a very nominal fee. By selling the product not only would the school districts using it benefit, but the developers would enjoy monetary reward for their efforts.
4.4 Lessons Learned
This section summarizes the lessons learned.
4.4.1 What Went Well
The advisor meetings were extremely helpful. The advisors gave other perspectives and other possibilities to think about the design. The advisors gave good advice when problems and errors occurred. The team meetings were also extremely helpful in that they were used as work sessions. The meetings allowed for time for team members to ask other team members questions. The meetings also allowed for time for a team member to help another team member.
4.4.2 What Did Not Go Well
Some things that did not go so well were the interactions with the database. Not having administrator privileges to the server made it difficult to fix minor problem. An administrator from the client had to set up the usernames and passwords. When coding started CVS was used, but the administrator had to set up a repository. When it was time to create the database and the tables the administrator again had to set up the database before the tables could be created. Not having administrator access to the server slowed and at times halted progress.
4.4.3 Technical Knowledge Gained
This project gave the team members an extended knowledge of HTML and mySQL. The knowledge of HTML was extended by the creating of the individual internet pages needed to complete the project. The mySQL knowledge was extended by the database calls need to communicate the actions done on the page to the database.
Every team member was new to PHP and a large amount of technical knowledge was gained. PHP is used to incorporate the mySQL queries into the HTML code.
4.4.4 Non-technical Knowledge Gained
Teamwork and time management were two skills that were added on and polished. One skill that was learned and added to was inter-teamwork. This project required that the team communicate and work with other teams. The first semester went well and communication between the teams also went well. The second semester the server was taken over by another team. Communication did not go so well with this team, but did improve as the semester went along.
4.4.5 How to Do the Project Differently Next Time
If the project were to be redone the assignNET team would suggest not using the Ongo-08 server. The assignNET team would suggest getting a virtual server from CSG (the Computer Support Group). By doing this the team would be given administrator privileges to the server. It would have increased the efficiency and saved the team valuable time. The assignNET team would suggest starting implementation earlier and getting a better knowledge of PHP. Starting implementation earlier and allowing more time for implementation would really help the project stay on track. Also gaining a good understanding of PHP before starting implementation would save time during the implementation.
4.5 Risk and Risk Management
The following section summarizes the risks encountered by the team and how they were dealt with.
4.5.1 Anticipated Potential Risks and Planned Management
There are a few risks that are associated with this project. One of these risks is the loss of a team member. To avoid this, multiple members of the team will work on every task. Tasks will be shared among team members so if one were to leave the project, there would not be any significant setbacks. Another risk to the project is interpersonal relationships within the team. It is important that all team members communicate with each other in a positive manner. This problem will be avoided by team members treating one another with respect and talking through any problems or disagreements that may arise.
4.5.2 Anticipated Risks Encountered and Successful Management Thereof
No anticipated risks were encountered. The main risks encountered were trouble with the client contact and the lack of accurate documentation. These were both unanticipated risks.
4.5.3 Unanticipated Risks Encountered, Attempts to Manage, and Success Thereof
An unanticipated risk encountered was trouble communicating with and getting action from the client who owned the server used. The team had many problems second semester when needing some administrative privileges on the server. The team found a new contact with in the client team which was prompt and responsive. The new contact quickly fixed the problems and helped with questions.
Another unanticipated risk was the lack of good online documentation about PHP and JavaScript. It was necessary to do much research to find accurate and reliable documentation online. Several key sites were designated as good references and used often.
An unanticipated risk was the potential loss of the team’s server. The team immediately started backing up the repository, the database, and all other data. The team also had another virtual server created so if necessary it could be used.
4.5.4 Changes in Risk Management Resulting from Unanticipated Risks Encountered
The main change to risk management was making sure the team had a responsive and helpful contact on the client team. The first semester’s client team was always prompt and helpful, so it was necessary to find a similar contact in the second semester.
Another change to the risk management was working to find reliable documentation and sharing it with the entire group.
If the project was done again, the team would use the virtual server with administrative privileges the entire project time. This would have eliminated all client contact issues and the possibility of losing the server.
4.6 Project Team Information
This section contains information about the client advisors, the faculty advisors and the student team members for this project.
4.1.1 Client information
The following are the advisors for Senior Design Team Ongo-08.
Name: Dr. John Lamont Prof. Ralph Patterson III
Office Address: 324 Town Engineering 326 Town Engineering
Ames, IA 50011-3230 Ames, IA 50011-3230
Home Address: 1005 Idaho Ave. 1807 24th St.
Ames, IA 50014-3018 Ames, IA 50010-4403
Office Phone Number: 515-294-3600 515-294-2428
Home Phone Number: 515-292-5541 515-232-9933
Fax Number: 515-294-6760 515-294-6760
Email Address: jwlamont@iastate.edu repiii@iastate.edu
4.1.2 Faculty Advisor information
The following are the advisors for this project.
Name: Dr. Thomas Daniels Dr. Yong Guan
Office Address: 3222 Coover 3216 Coover
Ames, IA 50011-3060 Ames, IA 50011-3060
Office Phone Number: 515-294-8375 515-294-8378
Fax Number: 515-294-1152 515-294-3637
Email Address: daniels@iastate.edu yguan@iastate.edu
4.1.3 Student Team information
The following are the student members of this project and the people who will be completing this project.
Name: Michael Bravo III Kathryn Lamont
Major: Computer Engineering Computer Engineering
Home Address: 7230 Willow Lommen 4524 Steinbeck St. #5
Ames, IA 50013 Ames, IA 50014
Home Phone Number: 515-572-0622 515-451-7543
Email Address: mbravo@iastate.edu klamont@iastate.edu
Name: Lauren Marshall Richard Patrick
Major: Computer Engineering Computer Engineering
Home Address: 218 N. Hyland #302 109 N. Wilmoth Ave.
Ames, IA 50014 Ames, IA 50014
Home Phone Number: 641-521-2733 515-292-0454
Email Address: madialle@iastate.edu rpatrick@iastate.edu
4.7 Closing Summary
When a student misses class, it can be a challenge to retrieve the assignments from each individual teacher. The individual assignments must then be compiled into a single list. The solution to this problem is to create a web page that will allow a student to view a list of the assignments from all classes that were missed. The website has been developed to be easily understood and accessed. The teacher will be responsible for maintaining and updating their respective assignments.
References
Techweb Business Technology Network.
Viewed:11/16/03 Copyright 2003
Appendix A – Database Table Information
|Table |Columns |type |NULL? | | |
|password |userID |int |not | | |
| |userName |varchar(10) |not | | |
| |password |varchar(10) |not | | |
|userList |userID |int |not |Primary Key |Auto_Increment |
| |firstName |varchar(20) |not | | |
| |middleName |varchar(20) | | | |
| |lastName |varchar(20) |not | | |
| |permission |tinyint |not | | |
|absent |userID |int |not | | |
| |date |date |not | | |
|class |classID |int |not |Primary Key |Auto_Increment |
| |userID |int |not | | |
| |directory |varchar(255) |not | | |
| |className |varchar(50) |not | | |
|enrollment |classID |int |not | | |
| |userID |int |not | | |
|actionLog |userID |int |not | | |
| |action |varchar(50) |not | | |
| |time |timestamp |not | | |
|assignment |classID |int |not | | |
| |assignID |int |not |Primary Key |Auto_Increment |
| |assignName |varchar(20) |not | | |
| |postDate |date |not | | |
| |autoArch |tinyint(1) |not | | |
| |description |text |not | | |
| |fileFlag |tinyint(1) |not |Default 0 | |
|archives |userID |int |not | | |
| |assignID |int |not | | |
Appendix B Test Report
Test Report
Tester: _____________________________
Date: _________________ Time: _________
Test Run:
Bugs Found:
Suggestions for Correction:
Additional Testing Needed:
-----------------------
enrollment
ClassID UserID
password
UserID userName Password
absent
ClassID UserID
actionLog
userID time Action
ClassList
userID ClassID directory className
Archives
UserID AssignID IndArch Enabled
Assignments
ClassID AssignID Date AutoArch
userList
firstName middleName lastName
userID Permission
Login
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.