Software Plan
MedITrak
Visual Design Technologies
September 24, 2003
Prepared by: Kenneth Abbatiello
Peter Kitz, Team Leader
Ryan Krisolosky
Ryan Newsome
Anthony Puglisi
Brett Rhymestine
MedITrak
Software Plan
Table of Contents
System Definition:
Section 1.1:
Problem Definition 1
Section 1.2: System
Justification 1
Section 1.3: Goal
for Project 1
Section
1.4: Constraints
on the Project/System 2
Section 1.5: Functions
to be provided 2
Section 1.6: User
Characteristics 3
Section 1.7: Development
and Maintenance 3
Section 1.8: System
Requirements 3
Section 1.9: System Acceptance Criteria 3
Section 1.10: Sources
of Information 3
Project Plan:
Section 2.1: Life-cycle
model 4
Section 2.2: Organizational
Structure 5
Section 2.3: Preliminary
Staffing and Resources Requirements 6
Section 2.4: Preliminary
Development Schedule 6
Section 2.5: Project
Monitoring and Control Mechanisms 6
Section 2.6: Tools
and Techniques to be used 6
Section 2.7: Programming
Languages 6
Section 2.8: Testing
Requirements 6
Section 2.9: Supporting
Documents Required 7
Section 2.10: Manner
of Demonstration and Delivery 7
Section 2.11: Sources
of Information 7
Appendix:
Gantt Charts.............................................................................................................8
Team
Resumes.......................................................................................................10
Glossary.................................................................................................................16
1.1: Problem Definition
The ease and
efficiency of electronically transmitting data from one location to another has
put companies to work switching from normal file organization. Dr. LaRow, the Health Professions Advisor, is
in charge of helping Science students apply and gain admission to Medical
School. The lengthy profiles for each student in their
four years here at Siena make the amount of paperwork tremendous. Files such as
test scores, letters, activity sheets, and other documents, make it difficult
to maintain the student’s personal portfolio. Dr. LaRow has requested for the development of an electronic
organization database system to help organize the massive amounts of documents
these pre-med students need to maintain.
1.2: System Justification
The main purpose of our software is to help Dr. LaRow keep track of each student’s progress throughout their four years preparing for entry into medical school. An electronic database will save both the student, and the professor, a great deal of time and energy. All files will either be entered by the student or electronically scanned. The system will also allow Dr. LaRow to view all accounts and make changes as he sees fit, in order to help the student make important future/career decisions. The dual accessibility will allow for greater student/teacher communication and progress.
1.3: Goals for Project
The goal of our project is to develop a highly efficient database to
help Dr. LaRow keep track of each student’s progress towards his/her entry into
Medical School. This system will help each user and the administrator keep the
files organized, and easily accessible. All paperwork not entered in by the
student will be electronically scanned and stored into the system. Our goal is
to create a program that will save both the students and the professor time,
energy, and plenty of stress.
Our goal as a team is to acquire crucial knowledge in the field of
Software Engineering. We are now in the “finishing school” of Computer Science,
and we hope to gain the essential experience needed to advance in the
technology job market. We will develop a better understanding of all models,
principles, and practices used by computer scientists in the working
environment. We will also gain valuable teamwork abilities, which are mandatory
to excel in the future.
1.4: Constraints on the Project/System
The system is going to have dual access control. It is obvious that all
people not involved into the student progression towards Medical School will
not have any kind of access. Other than that the constraints are as follows:
-
Student
Access à can only access his/her individual
accounts. They can change what is available to them only. They cannot access
any other accounts, or make changes to files forbidden by the professor
(administrator).
-
Professor(Administrator)
Access à can access all accounts and make any
changes thought to be necessary. He/She can also add his/her own confidential
files to any account which cannot be accessed by any other user.
1.5:
Functions to be provided
(Hardware and Software)
- The main function of this software is for a database to store information about health professions students at Siena College. The database will keep records of all the information concerning the students. The people who are inputting this information are students moving on to medical school. The software will allow students to input information concerning their GPA (grade point average), recommendations from teachers, personal information, along with other incites to which medical schools they are interested in.
- Dr. LaRow, Health Professions Advisor and Team Manager, will be able to have access to this database. He will be able to see everyone’s personal information, while at the same time, be able to change, insert, or delete that information.
- Students will have access for adding new information concerning schools, accept/reject information, adding references, personal information, and other actions concerning school work.
- This could possibly be an online software package which would be accessed via a network of computers. This would allow access from many computers on the Siena network. However, it might also be on a two computer network.
- Health Professions majors, starting with their freshman year, will use this software in keeping their records up to date throughout their four years at Siena College. By their junior year they are to have three letters of recommendation, personal information, and checklists for future plans.
- Only students of the Health Professions majors will be able to sign on using their Siena College logins. This will provide a security service which will help prevent wrong information to be entered by incorrect personal.
1.6:
User Characteristics
There will two types of users accessing this software. First, Dr. LaRow will be monitoring this software and all the information provided by the students. This is his way of accessing the records of students when it is time to apply to medical school. Second, the Siena College students who are Health Professions majors only will be using this software. The students will be checking their information and entering new information on a regular basis. They are the only two types of users which will have access to this software.
1.7: Development and Maintenance
This software will be developed and maintained on the computers in the Software Engineering Lab. Users of the software will be able to make changes with the information of the software through the computers with the software, or possibly through the internet. The platform will be decided at a later date.
1.8 : System Requirements
The most important system feature is
maintaining constant security over the database. We will
create Usernames and Passwords for those who will be using this system. This allows each user to access and edit
only their personal information. The
software managers will be able to view and access all the records. Convenience, organization, and a user-friendly
environment are all important aspects of this software.
1.9: System Acceptance Criteria
This multi-user database system will allow user
and managers in the following way:
(1)
The program will have Dual Access:
a)
Student
Users will be allowed to edit and update their individual accounts
b) Professor or software
manager has access to edit and update all accounts.
(2) Each individual account
should contain files needed to register for medical school.
(3) Software manager will be
able to add confidential files to each User Account, that only the software
manager will be able to access.
1.10: Sources of Information
The majority of the information used for this
section of the project resulted from meeting with our client Dr. LaRow. Other sources of information include Dr.
Lederman’s class lectures, the software engineering class textbook Software Engineering: A Practitioner’s Approach, 5th Edition (2002) by Roger
S. Pressman, previous Software Engineering teams’ projects and our team
member’s previous experiences.
2.1:
Life-cycle model: Linear
Sequential (Classic Waterfall) Model
Visual Design Technologies will be using the linear sequential model also know as the water fall model, in the design of the MedITrak. This model calls for the completion of each phase of the project before moving on to the next phase. This will allow us to ensure that nothing is being overlooked and that each step is completed properly. This will also allow you to see our progress at each step. This approach will ensure that your fished program will meet your needs. See graph below.
The
Linear Sequential Model
Project
Definition
Define the problem that needs to be solved.
Requirements
Specification
In this step we gather information from the client. We determine what the client wants in their program. When this process is finished we have the program requirements.
Preliminary
Design
Translates requirements into representation of software that can be assessed for quality before codeing begins.
Detailed
Desigin
After the preliminary design is accepted it is translated in to machine readable code.
Acceptance
Test
The finshed software is delivered to the client and is tested to make sure it meets their requirments.
2.2: Organizational Structure
Visual Design Technologies is encompassed of the following associates:
Name E-mail Address Phone
Number
Kenneth Abbatiello kenneth.abbatiello@students.siena.edu (518) 782-5937
Peter Kitz peter.kitz@students.siena.edu (518) 782-6141
Ryan Krisolofsky ryan.krisolofsky@students.siena.edu (860) 918-5429
Ryan Newsome ryan.newsome@students.siena.edu (845) 492-1317
Anthony Puglisi afpj@aol.com (518)
857-2012
Brett Rhymestine brett.rhymestine@students.siena.edu (518) 782-6068
Visual Design Technologies is structured as
follows for the MedITrak:
Kenneth Abbatiello – Webmaster and Librarian
Peter Kitz – Team Leader and Systems Administrator
Ryan Krisolofsky – Blackboard
Engineer
Ryan Newsome – Assistant
Webmaster
Anthony Puglisi – Software
Analyst
Brett Rhymestine –
Design Expert
The team structure of Visual Design Technologies is controlled
decentralized. All decisions will ultimately
come from the defined leader but individual team members will be considered in
all decisions. Each position in the
team will act as secondary leaders specialized in there own area and will
report with the defined leader on all decisions.
The work assignments for each member are as follows:
Team Leader – Organize meeting and interviews;
guide the team to their goals during the semester.
Systems Administrator – Manage the systems that will be
used by the team.
Webmaster –
Creates and maintains the project website.
Assistant Webmaster – Will assist the Webmaster in
maintaining the project website.
Librarian –
Keeps of all documents at team meetings or client meetings.
Software Analysis – Learns and manages the software
that will be used during the duration of the project.
Design Expert
– Focuses on the Design and layout of the project.
Database Administrator – Maintains the database that the
team will be creating.
2.3: Preliminary Staffing and Resources Requirements
The software resources we will need to complete
this project will be Microsoft Access, database software, Macromedia
Fireworks
and Dreamweaver, a web page editor. The
hardware resources we will be using are the computer systems, printers, and
scanner local in the software engineering lab and Roger Bacon computer
lab. Our client, Dr.LaRow, is our primary resource
as well as Dr.Lederman our Software Engineering professor.
2.4: Preliminary Development Schedule
Please refer to the preliminary development schedule, or Gantt chart on page 8.
2.5: Project Monitoring and Control Mechanisms
Our team plans to meet with Dr. LaRow twice a week during the planning and development stages of the project. We will also meet as a team at least once a week outside of class to discuss and plan the development process. We will assess our client’s responses to our presentations of the Project Definition / Project Plan and Software Requirements Specifications and Preliminary Design, to determine if our development process will meet the client’s needs. If it is found that the project is not meeting the needs of our client, necessary corrections will be made.
2.6: Tools and Techniques to be Used
Computers with Microsoft Project, Microsoft Access, Macromedia
Dreamweaver, and Macromedia Fireworks will be used. Microsoft Project will be
used to detail the ongoing progress of the software development. Also, we will
be utilizing the Blackboard Courseware for the majority of the project
development.
2.7: Programming Languages
In order to develop our client’s information system, we will use SQL along with tools included in Microsoft Access. To create the Visual Design Technologies web site, languages such as HTML and JavaScript will be used.
2.8: Testing Requirements
As it is
developed, our system will be thoroughly tested. All testing will be conducted by our team members and Dr. LaRow.
2.9: Supporting Documents Required
Supporting documentation that will be provided to our client includes:
1) The Project Definition / Project Plan – This document is due to the client on September 22, 2003.
2) The Software Requirements Specifications – This document is due to the client October 29, 2003.
3) The Preliminary Design – This document is due to the client on November 24, 2003.
2.10: Manner of Demonstration and Delivery
During the planning and development process, a number of in-class presentations will be given. The purpose of these presentations will be to explain the progress of our project as well as the accomplishments of our team. Our client, Dr. LaRow, will be present at these presentations to make sure that the project’s progress is satisfactory. Dates of in-class presentations and delivery of client documents are as follows:
1) Project Definition / Project Plan – September 22, 2003
2) Project Definition / Project Plan Presentation – September 24, 2003
3) Software Requirements Specifications Document – October 29, 2003
4) Software Requirements Specifications Presentation – October 31, 2003
5) Preliminary Design Document – November 24, 2003
6) Preliminary Design Presentation – December 3, 2003
2.11: Sources of Information
The primary source of
information for the planning phase of this project is our meetings with our
client, Dr. LaRow. Other
information has been gathered from Dr. Lederman’s class lectures, the textbook Software
Engineering: A Practioner’s Approach, 5th Edition (2002) by Roger S.
Pressman, all previous Software Engineering team’s projects, as well as our own
experiences.