Senior Capstone - Systems Operations Manual

1
Executive Overview
The CISB 471 team is working on a project that spans multiple departments at Mesa
State College. Each department is a different aspect to the entire project. The four aspects to the
project are: the Business Department web pages, the Mesa State College bookstore, the
Financial Aid Office, and the Business Department Survey Assessment. All departments require
the use of the new web template for Mesa State College. Mr. Steven Huntley, Mesa State's
Webmaster, has provided an initial version of a web template for our use.
The Business Department is requesting a redesign of all web pages associated with their
department in anticipation of the need to conform to the new campus template. Dr. Morgan
Bridge, department head, is working with the team in redesigning the web pages.
The Mesa State College bookstore has an online campus shop. This website is very
difficult to update and maintain, and has not been updated recently. Ms. Tracy Brodrick,
bookstore manager, would like the site to be more usable with regards to navigation,
maintenance, and more complete with regards to inventory items.
The Financial Aid Office is responsible for tracking scholarship and student information.
Ms. Shanon Hawkins coordinates all of the necessary steps for the process of awarding student
scholarships. The current system is manual and thus difficult to use. She is in need of an easier
to use system to track the progress of awarding each scholarship.
The Business Department is continually assessing the quality of their department.
Currently, Mr. Fred User, the survey administrator, is using WebCT, Excel, Access, and SPSS to
gather and analyze data. He is in need of an easier to use system that will allow both on and off
campus respondents to take surveys.

2
Systems Development Life Cycle
The CISB 471 team utilized the Systems Development Life Cycle (SDLC) Approach.
The SDLC is a systematic approach to problem solving and is composed of several phases, each
comprising multiple steps. The SDLC is iterative across phases. Rather than following the
SDLC from start to finish, project development requires constant revisiting of each phase.
(Satzinger, Jackson, & Burd, 2004, p. 37)
The two key features in the first phase of the SDLC are its focus on the business as a
whole and its focus on stored data. Information engineering concentrates first on describing the
enterprise and its environment in terms of strategies, plans, goals, objectives, and organizational
structure. Then the requirements for IT infrastructure and information-processing applications
are defined. The focus on stored data comes from the assumption that business data are an
organizational resource. Internal and external data needs are assumed to drive processing
requirements.
The second phase describes the processing the processing requirements of each business
area in the company as well as understanding the interrelationships among processes. A look at
Figure 1. Systems Development Life Cycle

3
the current system further defines the initial problem and the possible solutions. Graphic
modeling is used extensively to describe the current system and the proposed systems.
The third phase of the SDLC develops the detailed design of business processes. The
stress is placed on user input to process design and to process model validation.
The fourth phase is system construction. Process models and prototypes developed in the
previous phase are used as a blueprint for the construction. Procedural programming languages
and relational databases can be used. However, the current shift is utilizing object-oriented
environments.
The last phase is system maintenance. The expectation for most business systems is that
the system will last for years. The support phase entails upgrades, enhancements, as well as
making minor adjustments and assisting users of the new system.
The SDLC is an effective methodology because it takes into account information
engineering and structured system development. Additionally when combined with the
enlightened approach, the SDLC can be cost effective to a business.
Enlightened Approach
The enlightened approach requires that more time be spent in the beginning phases of the
SDLC than the end. This approach “should result in a higher level of quality both in the project
and in the resulting system.” (Carpenter & Schniederjans, 1994, p. 202) This is due to the
extensive amount of analysis and design that is completed initially. Additionally, the
enlightened approach results in less maintenance for the new system. “If the system is in
operation for a sufficiently long period of time, the savings accrued by minimizing the system
and program maintenance will more than justify the cost of the additional time required to use

4
proper methodologies.” (Carpenter & Schniederjans, 1994, p. 202) The figure below depicts the
relationship between the enlightened and unenlightened approaches.
Figure 2. Stereotypical Relationship Between Enlightened and Unenlightened
Approaches to the Information Systems Development Life Cycle
(Carpenter & Schniederjans, 1994 , p. 202)
This report is the system documentation manual provided to management. The report is
outlined in a manner following the SDLC. Additional material relating the various phases of the
project to theoretical material learned in our Information systems’ theories and practices course
is at the end of the report.

6
Description
The planning phase began with the team evaluating the information provided by Dr.
Carpenter. Once the team was familiar with the information, and conversations with the clients
began, the team identified the scope of the project, conducted a feasibility study, and developed a
schedule plan. To document the scope of the project, a specific statement was created called:
Statement: Problem Description, Scope and Objectives. In describing the feasibility of the
project two statements were created:
• Statement of the project’s economic, organizational/cultural, technical, schedule,
and resource feasibility
• Statement of the system’s technical, performance, usability, reliability, and
security requirements
The first statement is to assess the project’s overall feasibility in the specific areas while
the second statement is to determine the specific system feasibility.
The schedule was determined by creating Gantt and Program Evaluation and Review
Technique (PERT) charts. The Gantt chart is a document that represents a timeline for the
project. Each phase contains certain jobs that need to be completed, when they need done, and
what needs to be completed before beginning the next task. Some tasks can be done
simultaneously, while some rely upon the completion of others. Additionally, the Gantt chart
shows who is working on each task. The Gantt chart clarifies the project by allowing the team to
view every task as it relates to the rest of the project.
The employment of a Gantt chart can help track resource use and acts as a convenient
tool to provide updates to the team. If a team member is unsure what they are working on, it is
possible to look at the Gantt chart and have a good idea of the project’s progress.

7
Microsoft Project generates both the Gantt and PERT charts from the same input sheet.
While the Gantt chart is used to track the overall project, the PERT chart allows for tracking each
of the individual tasks required to complete each phase. The critical path is then generated
showing what tasks must be completed in order to continue on to the next phase.
For this project the boxes represent tasks, the order in which it must be accomplished
relative to other tasks and the person(s) assigned to complete it. It also includes the expected
duration of each. As they are in process, the box receives a single line marked through it to
represent that the task is partially done. If the task has been completed then the entire box
receives two lines in cross pattern much like an X to indicate it has been completed.
The red line indicates the critical path through the separate tasks. The critical path helps
to determine what activities must be done before related activities can be started. This visual
representation provides the project members with a way to gauge what has and has not been done
during each phase.
The following pages contain the statements for the planning phase, followed by screen
shots of the Gantt chart.

8
Statement: Problem Description, Scope and Objectives
Problem Description
The project includes various departments at Mesa State College that need improved
efficiency and usability. Specifically, the current web pages associated with each department are
inefficient and difficult to navigate. Additionally, Mr. Huntley has introduced a new design to
the Mesa State website over the last few months. These changes need to be implemented across
all departments. These changes will improve efficiency to the website through the use of a menu
system and a consistent look and feel to each page. The use of a template will decrease the
resources needed to maintain the web pages.
The specific processes associated within the fours specific departments need
improvement. By designing and implementing better user interfaces and databases where
appropriate, these processes can be streamlined.
The following depicts a specific problem description for each aspect of the project.
Aspect: Business Department Website
The Mesa State Business Department’s web pages are currently not consistent with each
other. In addition, there is a need to make the web pages more easily navigational to
increase usability. The web pages also must conform to the new campus template.
Aspect: Bookstore
The Mesa State College Bookstore has an online campus shop. The online campus shop
website is difficult to navigate, update, and maintain. Currently the site does not have the
look, feel, and flow of a traditional e-commerce website. While the system does involve
an inventory database to track products, this database is not supporting the online website
which creates complications to the process of adding and deleting products to the pages
because all the product information requires hard coding.
Aspect: Scholarship
The current scholarship system has many issues. The actual system is a paper system
which is not user-friendly and is difficult to manage. The current system is ineffective to
support the needs of the organization.

9
Aspect: Business Department Assessment Survey Site
The Business Department at Mesa State College is collecting data as part of an
assessment process. Fred User developed a departmental evaluation system to track
students, alumni and employers, as well as students’ evaluation of the quality of
education obtained from Mesa State College. The current system uses a combination of
electronic and paper media to acquire information that compiles later into usable reports.
Currently the procedure involves a paper survey followed by an electronic survey. The
system is too labor intensive. The current electronic survey portion is using WebCT,
which does not allow for off-campus interaction, a limiting factor for additional surveys
Mr. User intends to undertake.
Scope
This project will utilize the new web template to fit with the new look and feel of the
Mesa State College’s website. Implementation of a database will occur in all aspects of the
project, except for the Business Department web pages. The Business Department web pages
will be redesigned for functionality. Web-based user interfaces will be designed and
implemented for the bookstore, work-study, and business department assessment survey site
aspects of the project.
The following depicts a specific scope for each aspect of the project.
The current website's reorganization requires the new campus template. This new
template will change the look and feel of the current website and the use of a menu will
increase navigation. The new pages will promote the most important information about
the department to the forefront. We will be using the information on the current web
pages to create the new web pages.
Aspect: Bookstore
The current online website requires reorganization to fit the new campus template, and
redesign of the pages to increase usability. Additionally, a new database and user
interface will be created for the process of adding and deleting products from the website.
Aspect: Scholarship
A new scholarship database will be designed and implemented to meet the needs of the
financial aid office and streamline the process required to manage student scholarship
data. Additionally, the database will be designed to be compatible for the future needs of
an online web interface for students to apply for scholarships and for faculty to assess
students’ applications.

10
The new system will be web based allowing for both on and off campus interaction. All
web pages will conform to the new campus template. The new system will include an
administrator portion for the creation of survey and extraction of data. The system will
require a database to store all respondent information. This database will also store
questions and answers to assist the administrator in creating flexible surveys.
Objectives
The primary objective for the project is to increase usability. This includes
increasing the efficiency in maintaining the corresponding web based user interface for each
aspect of the project, as well as utilizing databases when appropriate. The other objective is to
modify all web pages to the new template, which will increase functionality and navigation.
The following depicts specific objectives for each aspect of the project.
• Each individual web page within the Business Department will have a consistent flow
increasing usability.
• Each individual web page within the Business Department will have more related
pictures.
• Student organizations added to the menu options as well as their corresponding web
pages.
• All of the offered business degrees will be on the menu.
Aspect: Bookstore
• The website will be more aesthetically pleasing and will have a look and feel of a
traditional ecommerce site.
• The website will have a menu system to increase user navigation and be user-friendly.
• The normalized database will have flexibility to accommodate future needs.
• The user interface will reduce the time needed to display or delete products from not only
the database, but also the website.
Aspect: Scholarship
• A database will be used to store and track student and scholarship data.
• The database will have some built in query functions to assist financial aid office in
tracking student and scholarship data.

11
• The system will be web based for on and off-campus access.
• The system will be user-friendly.
• The system will reduce processing time for the administrator and provide flexibility in
creating surveys.
• The system will ensure user confidentiality and data security.
• The database will track respondents for future assessment purposes.
• The normalized database will also be used in the creation of the surveys.
• The system will be flexible to accommodate future needs.
• The system will utilize data validation to ensure that respondent’s information added into
the database is accurate and is the correct data types required.

12
Statement: Project’s Economic, Organizational/Cultural, Technical, Schedule, and
Resource Feasibility
Economic Feasibility
The costs associated in creating the web pages will be costs normally incremented within
the Mesa State budget. Development costs would include training users on how to work with
the user interfaces, and how to manage their databases. After completion of the project,
continuation costs include routine maintenance of the web pages, help desk technician staff
salaries, and training of any new employees maintaining the system. The benefits, or cost
decreases, will be in the areas automation of manual services for the work-study and bookstore
web sites. There is also paperwork reduction created consequent to electronic data storage. A
more in depth cost/benefit analysis will show dollar amounts to each of these areas. Free labor
for the analysis, design, and implementation of the project is provided by the CISB471 students.
Organizational/Cultural Feasibility
The organization and culture of Mesa State College is that of dynamic proportions.
There is a changing norm in the culture, due to upper-level management changes in recent years.
The new culture consists of more centralized control methods that have created the resistance.
Standardization is one of the policies in enactment across campus, which has validated the need
for our project. Upon completion of the project, some job responsibilities and new work
procedures will change. In order to make these changes feasible, training and proper
documentation of each web site is the key to overcoming the dynamic culture.

13
Technical Feasibility
The system must run on the current Mesa State College servers. The websites must be
created and maintained in Dreamweaver. The databases must be compatible with the websites
and the user-interfaces through Cold Fusion. The databases will be created with Microsoft
Access and the all systems must run on a standard office personal computer.
Schedule Feasibility
The project is scheduled by using a Gantt/PERT chart, which defines each integral part of
analyzing, designing, and implementing the best alternative for Mesa State College. The
timeframe of completing the project for presentation to the clients is by May 3, 2007.
Completing the design of the project is scheduled for no later than March 22, 2007. Manual
documentation and user documentation is scheduled for completion by May 3, 2007. This
schedule gives the team focus points to complete the project efficiently and completely, utilizing
an enlightened approach to time management.
Resource Feasibility
The CISB 471 team is utilizing the strength of each consultant. Each member is working
diligently on various aspects of the project to maximize our personnel resources. The following
table reflects each member’s assignments to the specific aspects of the project.
Project Aspect Team Members Assigned
Business Department Website All Members
Business Department Assessment Survey Site Bill Jackson, Scott Brett
Online Campus Shop Jenny Hummel, Telicia Chaffin
Scholarship Ian Oyama, Kevin Kempton

19
Statement: System’s Technical, Performance, Usability, Reliability, and Security
Requirements
Technical Requirements
The system must run on the current Mesa State College servers. The websites must be
created and maintained in Dreamweaver. The databases must be compatible with the websites
and the user-interfaces through Cold Fusion. The databases will be created with Microsoft
Access and the all systems must run on a standard office personal computer.
Performance Requirements
The system must respond to user requests as quickly possible. The databases must be
efficient using effective design. The user interfaces should meet user expectations with regards
to ease of use and streamlining of processes.
Specific performance requirements for each aspect of the project:
The Business Department web pages should be accessible at all times. The use of the
template will increase the ease of updating the pages as well as decrease the time needed
to update the pages.
Aspect: Bookstore
The online campus shop needs to be user-friendly with respect to navigation. The site
should function as a traditional e-commerce site.
Aspect: Scholarship
The database will streamline the process of tracking student and scholarship data.
Data entry validation and confirmation will ensure the quality of data collected. The user
will have easy-to-use survey building and administration tools.

20
Usability Requirements
The system must be user-friendly. The web pages should be easy to navigate and the
databases easy to maintain. The use of the template will increase the ease of updating the pages
as well as decrease the time needed for said updates. The user-interface should streamline the
processes of maintaining the website. The system will be accompanied with a user manual to
assist users in using and maintaining their systems. The web pages have a help page to assist
online users. Privacy disclosures should be available online where appropriate.
Reliability Requirements
The system will be as reliable as the campus network will allow. Frequent backups of the
database and web pages help enable reliability through Mesa State's backup servers. The
databases should be backed up both on and off the server, to account for power surges and
system crashes.
Security Requirements
The system will be as secure as all systems managed my Mesa State College’s IT
Department. Controls will be in place to ensure that the websites maintained by authorized
users. The system will have general and application controls. The application controls will
assist the user to ensure only valid information is added to the databases in the correct data types
required. Adequate firewalls and other security measures will be in place to assure proper
confidentiality. All users will require usernames and passwords to participate in the Business
Department Assessment Survey Site.

22
Description
The goal in the analysis phase is to understand and document in detail the business needs
and the processing requirements of the new system. Our meetings with the clients allowed us to
see the inadequacies of the current systems. This understanding helped to develop and analyze
the business needs and processing requirements. As we progressed, we compiled a list of what
seemed to be the most important requirements for each aspect and verified that list with the
clients and our Statement of Problem Description, Scope and Objectives. It is important to
compare our requirements with this statement to verify the requirements are within the scope.
In addition to discovering the processing requirements, the team also uncovered project
constraints. These constraints are discussed later. The final step in the analysis phase is took
look at all possible alternatives and to have the client select one. To assist the client in the
selection process, metrics are used to measure the alternatives against each other in various areas
such as automation and functional requirements. The alternatives for the project are discussed in
detail at the end of this phase.
The team utilized various diagrams to map both the current system and needed system.
Both the traditional and object oriented approaches were followed. In looking specifically at the
Business Department web pages, there is no need to use diagrams because there is no system.
Traditional Approach
The traditional approach includes many variations based on techniques used to develop
information systems with structured and modular programming. This approach is often referred
to as structured system development. The traditional approach uses the following diagrams for
the analysis phase:

23
• Data Flow Diagram
• Entity-Relationship Diagram
Object-Oriented Approach
The object-oriented approach includes a collection of interacting objects that work together
to accomplish tasks. The system consists of objects as opposed to data entities or files. The
object–oriented approach uses the following diagrams for the analysis phase:
• Class Diagram
• Use Case Diagram
In an effort to increase the readability of the diagrams, a color scheme was used. The color
yellow is used throughout the diagrams is to show the people involved with the system. The
color blue represents the processes of the systems. The red boundary lines reflect the system
boundary for each aspect. Specifically, which processes the team will be implementing and
which processes fall outside the scope. For the scholarship aspect, an additional green system
boundary was used to show the ultimate system that the team designed in addition to the
database, or intermediate system that was implemented. While it is not common to include
system boundary lines in every diagram, these particular diagrams contain the boundaries to
increase readability.
The following pages outline general descriptions for each diagram, explanatory narratives for
each aspect and corresponding diagrams.
Data Flow Diagram
The Data Flow Diagram is the key graphical model in the traditional approach. The data
flow diagram shows inputs and outputs, processes, and storage, and how they all operate
collectively resulting in how the data flows from each process. The diagram helps the developer
show the user what their understanding of the current system is and then allows the developer to

24
create a new data flow diagram that depicts the proposed system. The new diagrams can be a
useful tool in showing the user what the new system will do, how data will flow, and graphically
show where the changes to the current system are being made.
The context diagram describes the most abstract view of a system. The entire system is
represented as one process. Diagram 0 summarizes an entire system or subsystem in greater
detail than the context diagram. Any diagrams in addition to the context and diagram 0 simply
break down the processes into further detail. The figure below shows the symbols and their
corresponding meaning. (Note: A process can also be represented by a circle.)
Figure 3. Data flow diagram symbols
Development Life Cycle

25
Aspect: Bookstore
The first set of diagrams is for the current system and the second set is for the needed
system. The entire system for the bookstore is shown in the context diagram and
represents the website needed for customers to place orders and a product database to
store the product information that maintains the site.
In looking at the current system, specifically Diagram 0, two databases exist: Just Add
Commerce (JAC), which supports the shopping cart software on the current website, and
the Booklog Inventory, which tracks all inventory both online and in-store. Notice that
neither database is able to store product information that can dynamically support the
online campus shop.
The needed system adds a third database to meet the requirement of an easily updatable
website. Additionally, the client wanted the functionality of having customers being
added to a mailing list. These two processes are in our system boundary.
ManagerCustomer Online Order
Processing
System
Order
Confirmation Order request
Order report
Context Diagram
Current System

26
Customer
Diagram 0
Current System
1
Manager
2
5
4
3
Credit Card
Company
Process
Order
Print
Order
Report
Ship
Order
Verify
Credit
Card
Update
Inventory
JAC Database
Booklog Inventory
order
confirmation
customer and order
information
order report
order request
customer and order
information
customer and order
information
customer and order
information
product
Product
information
Product
information
payment information
approval or rejection

27
Customer
Diagram 1 – Process Order
Current System
1.1
1.2
1.3
Look up
Product
Availability
Place
Order
Enter
Payment
Information
JAC Database
Item inquiry
confirmation
customer and order
information
customer and order
information
customer and order
information

28
Manger
Diagram 3 – Verify Credit Card
Current System
3.1
3.2
Process
Credit Card
Approve
Order
Customer and
payment
information
approval
customer and order
information
credit card number
Credit Card
Company
payment information
3.4
Call
Customer
3.3
Cancel
Order
Customer
rejection
verified credit card
number
customer and order
information
customer and order
information
verified credit
card number

29
*Note: The additional function of the manager being able to manage the website.
ManagerCustomer Online Order
Processing
System
Order
Confirmation
Order request
Order report
Context Diagram
Needed System
Manage Website

30
Customer
Diagram 0
Needed System
1
Manager
3
6
5
4
Credit Card
Company
Process
Order
Print
Order
Report
Ship
Order
Verify
Credit
Card
Update
Inventory
JAC Database
Booklog Inventory
order
confirmation
customer and order
information
order report
order reqest
customer and order
information
customer and order
information
customer and order
information
product
Product
information
Product
information
Product Database
7
Manage
Website
product information
Potential
Customer2
Add to E-
mailing List
payment information
email information
product
information
email information
email information

31
Customer
Needed System
1.1
1.2
1.3
Look up
Product
Availability
Place
Order
Enter
Payment
Information
JAC Database
Item inquiry
confirmation
customer and order
information
customer and order
information
customer and order
information

32
Manger
Diagram 4 – Verify Credit Card
Needed System
4.1
4.2
Process
Credit Card
Approve
Order
Customer and
payment
information
approval
customer and order
information
credit card number
Credit Card
Company
payment information
4.4
Call
Customer
4.3
Cancel
Order
Customer
rejection
verified credit card
number
customer and order
information
customer and order
information
verified credit
card number

33
Manager
Diagram 7 – Maintain Product Database
Needed System
7.1
7.2
7.3
Add or
Remove
Product
Update
Product
Information
Maintain
Website
Product Database
product
information
product
information
website
product information
product
information
product information
product
information

34
Adjustments and Variations in the SDLC Application
As mentioned previously, the last step in the analysis phase is to assist the client in
selecting the best alternative to solve their problem. The details of this selection process are
described at the end of this phase; however, it is important to mention that in order to properly
document the alternative that was selected, additional diagrams may be necessary.
Some of the alternatives selected simply expanded the scope or system boundary to
include more features. Other alternatives used different software approaches and therefore
require different data requirements or types. To adjust the diagrams to the alternative selected,
supplementary diagrams were created and labeled Needed System (adjusted). Explanations
relating to the adjustments are included within each aspect.
In addition, the Bookstore aspect adds a different dimension to the SDLC in that after
reaching an alternative solution, the original preferred design was aborted and the direction of
the project changed. The Financial Aid aspect adds the dimension wherein the analysis and
logical design are broader than the physical design and implementation.
Aspect: Bookstore
The initial alternative for the bookstore was a student prototype. However, one of the
project constraints, which are described later, is the policy that prohibits the use of
student-made programs on the Mesa State College network. This influenced the team to
look at third-party software as a possible alternative. The client selected Yahoo!
Business. Yahoo! Business has an integrated shopping cart feature which replaced the
JAC database and included the Print Order Report process into our scope. The adjusted
diagrams are as follows.

35
Customer
Diagram 0
Needed System (adjusted)
1
Manager
3
6
5
4
Credit Card
Company
Process
Order
Print
Order
Report
Ship
Order
Verify
Credit
Card
Update
Inventory
Booklog Inventory
order
confirmation
customer and order
information
order report
order reqest
customer and order
information
customer and order
information
customer and order
information
product
Product
information
Product
information
Yahoo! Business
Database
7
Manage
Website
product information
Potential
Customer2
Add to E-
mailing List
payment information
email information
product
information
email information
email information

36
Customer
1.1
1.2
1.3
Look up
Product
Availability
Place
Order
Enter
Payment
Information
Yahoo! Business
Database
Item inquiry
confirmation
customer and order
information
customer and order
information
customer and order
information

37
Manager
Diagram 7 – Maintain Product Database
7.1
7.2
7.3
Add or
Remove
Product
Update
Product
Information
Maintain
Website
Yahoo! Business
Database
product
information
product
information
website
product information
product
information
product information
product
information

38
Aspect: Scholarship
Current System
The Financial Aid Office currently has an abundant amount of data flowing within and
between numerous external agents. The main people involved with the scholarship
application data are the Financial Aid Office, department heads or committees, the MSC
Foundation, and students submitting the applications. The context diagram illustrates all
of the essential data flows within these agents in order to make scholarships available to
students that need them. This diagram is illustrated throughout the entire development of
the ultimate system and intermediate system designs to enforce these critical data flows.
Diagram 0 illustrates the overall flow of data in more detail. The system boundary line
defines the scope of the system we are working with and designing. This boundary
illustrates the processes or events taking place currently that the Financial Aid Office
facilitates for the scholarship application process. There currently is no electronic way of
storing application information or sending information out to the proper department
heads/committees. Outside of the project boundary is the issuance of scholarship funds
by the MSC Foundation and the creation of the scholarship itself.
Diagram 2 illustrates the process a student goes through to apply for a scholarship. The
student looks on the Mesa State College Financial Aid web site to find the scholarship
they want to apply. They then printout the application and complete the required
information on the application. The application is then turned in to the Financial Aid
Office. In addition, an accompanied essay is turned in with the student’s application.
Diagram 3 illustrates the process of getting the application off to the proper committee or
department head for award. The Financial Aid Office sorts the applications by
scholarship and turns all application information over to the committee or department
head.
Diagram 5 illustrates the process of creating the award letter that is sent to the awarded
student. The Financial Aid office gets mailing addresses for both the student and the
donor of the scholarship funds, while then creating the letter and sending it via mail.
Diagram 8illustrates the process of maintaining the scholarship awardees after funding is
sent to the students. Mesa State’s student database, Banner, is accessed to run a report
that includes information about the students (credit hours, awarded amounts, name, etc.)
sorted by scholarships. Then, the report is manually updated every few days to monitor
the updates to the student information.

39
Financial Aid Office Student
Committee
Scholarship Application
System
Thank You Letter
Scholarship
Applications
Scholarship
Applications
Scholarship
Report(s)
Award Letter
Foundation
Funding
Award Letter
Funding
Thank You Letter
Context Diagram
Current System

40
*Note: We only implemented Process 8. However, we designed for Processes two through six.
Financial Aid Office
Student
2
Submit
Application
Applications
3
Distribute
Applications
Committee
Committee File
Scholarship
Files
5
Send Award
Letter
Award Letter
Funds
FoundationFunds
8
Manage
Scholarship
Reports
Reports
Scholarship List
Banner
Database
Student Information
Donor File
Donor Information
Committee List
Donor
Funds
Business Office
Funds
4
Send
Awarded
Scholarship
Application
1
Create
Scholarship
Donor Information
Scholarship List
Award Letter
Funds
Committee List
Student Information
7
Send
Scholarship
Funds
Thank You Letter 6
Send Thank
You Letter
Thank You letter
Thank You letter
Diagram 0
Current System

41
Student
2.1
Looks for
Scholarship
2.2
Prints
Application
2.3
Fills Out
Application
Scholarship File
Scholarship List
Applications
2.4
Submits Essay
with Application
Essay FileScholarship Essay
Diagram 2 – Submit Application
Current System

42
Committee
Applications
Committee File
3.1
Collect
Applications Scholarship Application
3.2
Sort Applications
by Scholarship
3.3
Get Committee
Information
3.4
Send to
Committee
Committee List
Diagram 3 – Distribute Applications
Current System

43
Donor File
Banner
Database
5.1
Get Donor
Information
5.2
Get Student
Information
5.3
Draft Award
Letter
5.4
Mail Award
Letter
Student
Award
Award Letter
Award Letter
Student InformationDonor Information
Diagram 5 – Send Award Letter
Current System

44
Scholarship File
Banner
Database
8.1
Create
scholarship
Report
Scholarship Information
Student Information
8.2
Manually
Update Reports
Report
Student Information
Report
Diagram 8 – Manage Scholarship Reports
Current System

45
Ultimate System
The ultimate system design has similar data flows at the context diagram and Diagram
0. However, the sub-processes change to show the implementation of a database and
automated interface with the external agents.
Diagram 2 depicts the student inputting their information into the database, and getting
scholarships available to them based from that information. This also illustrates that the
student’s application and essay are inputted into the database, along with their
personalized password.
Diagram 3 illustrates the committee or department heads interface with the database. The
committee enters their committee ID, the scholarship application information is retrieved
from the database. The committee then directly updates the award information in the
database.
Diagram 4 illustrates the creation of the award letter. Information about the student and
donor is retrieved from the database. The information is viewed to create the document in
another program. The database is also updated to show that the award letter has been sent
to the student.
Diagram 7 illustrates the Financial Aid Office processes of updating student scholarship
information. The database updates application status, student award status, and fund
allocation status. A report is created by accessing the database and the banner database to
input student credit hours and scholarship award amounts.

46
Student
2
Submit
Application
Student Application (via Web)
Scholarship Application (via Web)
3
Award
Scholarship
Committee
Scholarship Applications
4
Send Award
Letter
Award Letter
Funds
Foundation
Funds
7
Manage
Scholarships
Report
Scholarship List
Banner
Database
Student Information
Donor Information
Donor
Funds
Business Office Funds
1
Create
ScholarshipDonor Information (via Web)
Scholarship List (via Web)
Award Letter
Funds
Committee List (via Web)
Student Information
6
Send
Scholarship
Funds
Thank You Letter
5
Send Thank
You Letter
Thank You letter
Thank You letter
Scholarship
Database
Scholarship Award (via Web)
Award Letter
Diagram 0
Ultimate System
Award Letter

47
Student
2.1
Fill out student
information
2.2
Get Available
Scholarships
2.3
Get Application
Scholarship ApplicationScholarship List
Student Information
2.4
Submit Application
Student Application
2.5
Submit Essay
Essay
Diagram 2 – Submit Application
Ultimate System
Scholarship
Database

48
Committee
3.1
Get Committee
Applications Scholarship Application
Committee ID
3.2
Award
Scholarships
Diagram 3 – Award Scholarships
Ultimate System
Scholarship
Database

49
4.1
Get
Awarded
Application
4.2
Get Student
Information 4.3
Draft Award
Letter
4.4
Mail Award
Letter
Student
Award Letter
Award LetterStudent Information
Student Application
4.3
Get Donor
Information
Donor Information Award Letter Status
Scholarship Database
Diagram 4 – Send Award Letter
Ultimate System

50
7.1
Update
Application
Status
7.5
Create Report
Scholarship
Database
Report
7.4
Get Student
Information
Credit Hours
Application Information
7.3
Update
Allocation
Information
Fund Information
7.2
Update Award
Status
Banner
Database
Credit hours
Award Information
Diagram 7 – Manage Scholarships
Ultimate System

51
Intermediate System
At the context level, the intermediate system only maintains the data flow between the
Financial Aid Office and the system. The only process that is maintained is the status of
the application and the student information. All the data is inputted by the Financial Aid
Office into the database.
Diagram 0 is the same as the ultimate system Diagram 0. The only difference is the
system boundary is around the Manage Scholarships process.
Diagram 7 illustrates the flow of student, scholarship, and application status data. The
Financial Aid Office inputs scholarship information, student information, and a student’s
application status. A report is also generated to update and view student credit hours and
scholarship award amounts from the Banner database. The scholarship information of
student name and student ID is retrieved from the system database.
Student
2
Submit
Application
Student Application (via Web)
Scholarship Application (via Web)
3
Award
Scholarship
Committee
Scholarship Applications
4
Send Award
Letter
Award Letter
Funds
FoundationFunds
7
Manage
Scholarships
Report
Scholarship List
Banner
Database
Student Information
Donor Information
Donor
Funds
Business Office Funds
1
Create
ScholarshipDonor Information (via Web)
Scholarship List (via Web)
Funds
Committee List (via Web)
Student Information
6
Send
Scholarship
Funds
Thank You Letter 5
Send Thank
You Letter
Thank You letter
Thank You letter
Scholarship
Database
Scholarship Award (via Web)
Award Letter
Award Letter
Diagram 0
Intermediate System

52
7.2
Update
Application
Status
7.6
Create Report
Scholarship
Database
Report
Report
7.5
Check
Student
Status
Application Information
7.4
Update
Funding
Information
Fund Information
7.3
Update Award
Status
Banner
Database
Credit hours
Award Information
7.1
Input Student
Application
Information
Credit Hours
Student Information
Report
7.7
Update
Report
Diagram 7 – Manage Scholarships
Intermediate System

53
Current System
The context diagram current system is the overall view. The administrator provides the
respondent a paper survey that is returned after the respondent inputs the data through
WebCT. WebCT is a web-based system that is available to students registered in specific
courses. WebCT is the system in current system.
Diagram 0 is a breakdown of the context diagram. Here the administrator creates the
survey questions and enters them into the WebCT data store. The WebCT data store is
then used to construct the survey and is uploaded to WebCT via the WebCT manager. A
paper copy of the constructed survey is then provided to the respondents by the
administrator prior to the respondent taking the online survey. Once the respondent
completes the survey on WebCT the hard copy is returned to the administrator and is
stored in a filing cabinet. The un-validated data exported from WebCT is then stored in
an Excel spreadsheet. The survey data is then reviewed and errors corrected by the
administrator. The uncalculated data is then passed to SPSS for further analysis. The
remaining transformed data is then stored in an Access database. The calculated data
from SPSS and the transformed data from Access is used to generate reports.
Diagram 5 illustrates a break down of process 5 in diagram 0. The un-validated data is
extracted from the Excel spreadsheet where the administrator corrects errors such as
misspelled or incorrect input. The information is again stored in the Excel spreadsheet
where the validated data is sent to SPSS for calculation and Access for storage.
Input Survey
Through
WebCT
Administrator
RespondentPaper Survey
Survey
Report
Paper Survey
Context Diagram
Current System

54
Respondent
3
Input Survey
Through
WebCT
4
Export Data
Administrator
Paper Survey
Paper Survey
Electronic Survey Answers
Completed Respondents
Excel Survey
Data
Unvalidated Survey Data
5
Validation and
Transformation
SPSS Survey
Data
Access
Survey Data
6
Create
Reports
Survey Data
Uncalculated Data
Transformed Data
Calculated Data
Validated Data
Reports
Survey Hardcopy
Paper Survey
2
Web CT
Setup
Course-Survey
WebCT Guy
Course
1
Create Survey
Questions
WebCT
Paper Questions
Questions
Stored Questions
Diagram 0
Current System

55
Excel Survey
Data
5.1
Validate Data
(Reduced)
5.2
Transform
Data
5.3
Export Data to
SPSS
SPSS Survey
Data
Access
Survey Data
Fully Validated Data
Unvalidated Data
Validated Data
Transformed Data
Validated Data
Uncalculated Data
Diagram 5
Current System

56
Needed System
The Data Flow diagram of the needed system depicts the way the new system will handle
the data from the new survey system. The context diagram is the overall view of the
needed system. The Administrator loads the survey information onto the Business
Assessment Survey System website where the respondent takes the survey and a report is
provided to the administrator.
Diagram 0 shows the administrator generates questions and then stores them in a question
database. Process three allows the administrator to select the questions for the survey and
then inputs that survey into the website. Respondents log into the website and provide
login information such as name and email address. A login user name and password is
then provided to the respondent which is then used to login to the survey site, this is
stored in a Username/Password database. Once logged in the respondent then answers
the questions input by the administrator. Once a respondent completes the survey a
notification is sent to the administrator so respondents can be tracked. The data collected
through the survey is then stored and exported to an Excel workbook where the
administrator validates and transforms the data for further processing while the hard copy
of the survey is then stored for future access. The survey data is then validated and
transformed sending the uncalculated data to SPSS for further analysis and the
transformed data to an Access database. The stored data is then used to generate the
reports required. The line around several of the processes provides a guide as to the focus
of this project.
Diagram1 explains the question Generation process. The administrator generates new
questions defining the answer type as either closed or open. Each question is then stored
in the question database.
Diagram 2 defines the respondent user name and password login process. The respondent
inputs the required login information such as name and email address. The system then
generates a user name and password, stores the username and password and then sends
that user name and password to the respondent who uses the information to login for the
survey.
Diagram 3 describes the process of selecting questions for the survey and then
determining the order of the questions in the survey. When the Administrator constructs
a new survey the questions are extracted from a question database and stored in the
survey data store. The administrator then selects the order of the questions to be seen on
the survey.
In diagram 4 the user name and password validation procedure is used to access the login
information. Once logged in the respondent answers the questions and the questions are
stored.

57
Diagram 5 addresses the data validation procedure. The stored respondent answers are
validated and copied to an excel spreadsheet for future use. Diagram 6 of the needed data
flow diagram explains the data manipulation that occurs after the data has been collected.
From the Excel survey data storage the data is validated and transformed into usable
information. Numeric data is then transferred to SPSS for further processing while string
data is collected in the Access Survey database for future use.
Structured english is included with each specific process within the needed system.
Business
Assessment
Survey
System
Administrator Respondent
Survey
Survey
Report
Context Diagram
Needed System

58
Respondent
4
Input Survey
Through Web
Site
5
Export Data
Administrator
Questions
3
Create Survey
Survey Answers
Created
Survey
Stored
Questions
Questions
Electronic Survey Answers
Completed Respondents
Excel Survey
Data
Semi-validated Survey Data
6
Validation and
Transformation
SPSS Survey
Data
Access
Survey Data
7
Create
Reports
Survey Data
Uncalculated Data
Transformed Data
Calculated Data
Validated Data
Reports
Survey Hardcopy
2
Generate
Login
Information
Username/
Password
Login Information
Username/Password
Login Information
Login Information
Respondent
Answers
1
Generate
Questions
Questions w/ Answer Type
Diagram 0
Needed System

59
Administrator
1.1
Input New
Question
1.2
Define
Answer Type
1.3
Define
Answer
Questions
Questions
Question
Open Ended Answer
Close Ended Answer
Defined Question
and Answer
Diagram 1 – Generate Questions
Needed System
Process 1.1 – Input New Question
Ask if administrator would like to create any new questions
If administrator wants to add a question then
Ask for question text
Copy question text to Questions record
Else
Do nothing
Endif
Process 1.2 – Define Answer Type
If administrator adds a question then
Ask for selection of answer type
Query database for possible answer types
Copy question answer type to Questions record
Else
Do nothing
Endif
Process 1.3 – Define Answer
If answer type is close ended then
Ask administrator for number of answer options
Ask for answer information for first selection
While more answer selections do
Update answer selection with answer information
Endwhile
Endif

60
Respondent
2.1
Input Login
Information
2.2
Generate
Username
and Password
Name and
Requested Password
Username and
Password
Username/
Password
Diagram 2 – Generate Login Information
Needed System
Process 2.1 – Input Login Information
Ask respondent for requested username
Ask respondent for requested password
Ask respondent to confirm requested password
Process 2.2 – Generate Username and Password
If username is unique then
Copy username and password to username/password record
Else
Generate random username
Copy username and password to username/password record
Endif
Send username and password back to respondent

61
Administrator
3.1
Select
Questions for
Survey Survey
Questions
3.2
Determine
Question
Order
New Survey
Request
Available
Questions
Not Ordered
Survey
Question Order Request
Ordered
Survey
Not Ordered
Survey
Diagram 3 – Create Survey
Needed System
Process 3.1 – Select Questions for Survey
Ask if administrator would like to create any new surveys
If administrator want to add a survey then
Ask for survey name
Ask for question information for first question
While more questions do
Update survey with question information
Endwhile
Else
Do nothing
Process 3.2 – Determine Question Order
Ask if administrator wants to order the questions in the survey
If administrator wants to order questions then
Ask for first question placement
Update survey with question order
Endwhile
Else
Do nothing

62
Respondent
4.2
Take Survey
4.1
Username
and Password
Verification
Username/
Password
Login
Respondent
Answers
Survey
Answers
Survey
Survey Answers
Diagram 4 – Input Survey through Website
Needed System
Process 4.1 – Username and Password Validation
Ask respondent for username and password
Check for correspondence with username/password record
If respondents username and password match the record then
Go to take survey
Else
Send respondent “invalid username or password” message
Process 4.2 – Take Survey
Ask if respondent would like to begin survey
If respondent would like to begin a survey then
Go to survey selection
Ask respondent which survey he would like to take
While more surveys do
Update survey with respondent answers
Endwhile
Go to first survey question
Update survey with respondent answers
Endwhile
End Survey
Else
Do nothing
Endif

63
Respondent
Answers
Excel
Spreadsheet
5.1
Validate Data
5.2
Copy to
Spreadsheet
Validated
Answers
Validated
Answers
Diagram 5 -Export Data
Needed System
Process 5.1 – Validate Data
Collect all respondent answers
Validate answer information for first answer
Copy answer to respondent answers record
While more answers do
Validate answer information for answer
Copy answer to respondent answers record
Endwhile
Process 5.2 - Copy to Spreadsheet
Collect all validated respondent answers
Copy answers to Excel spreadsheet
Save with survey and respondent information

64
Excel Survey
Data
6.1
Validate Data
(Reduced)
6.2
Transform
Data
6.3
Export Data to
SPSS
SPSS Survey
Data
Access
Survey Data
Fully Validated Data
Semi-validated Data
Validated Data
Transformed Data
Validated Data
Uncalculated Data
Diagram 6 – Validation and Transformation
Needed System

65
Adjustments
The original student prototype was to include Process 1- Generate Questions. However,
after the alternative that Mr. User selected, this process was no longer in the scope and
this in effect “renumbered” the processes. This alternative also resulted in the need for a
comma delimited file and HTML code. Diagram three and five reflect these changes.
Administrator
3.1
Select
Questions
for Survey
Survey
(HTML PAGE)
Questions
3.2
Determine
Question
Order
New Survey
Request
Available
Questions
Not Ordered
Survey
Question Order Request
Ordered
Survey
Not Ordered
Survey
Diagram 3 – Create Survey

66
Respondent
Answers
Comma
Delimited File
5.1
Validate Data
5.2
Copy to
Spreadsheet
Validated
Answers
Validated
Answers
Diagram 5 -Export Data

67
Entity Relationship Diagram
The database is one of the most important components of any system. Databases are used
to store structured data. A relational database is the best option to capture and store needed data.
An entity relationship diagram (ERD) is a conceptual data model that shows the data storage
requirements of the system. The requirements include the data entities or things data is being
stored about, the attributes of the entities, and the relationships between the entities.
Understanding what the system stores data about is extremely important to understanding the
system’s requirements. Entities are represented by rectangles. Associate entities, used in many-
to-many relationships, have diamonds on the rectangles. Relationships are shown with the lines
between entities. Cardinality defines the numeric relationships between occurrences of the
entities on either end of the relationship line.
The figure below shows the cardinality symbols and their corresponding meaning.
Figure 4. Crow’s Foot Symbols
(Rob & Coronel, 2007, p. 118)
The following depicts a specific narrative for each aspect of the project followed by the
accompanying entity-relationship diagrams.

68
Aspect: Bookstore
The first ERD represents the current system and the second one is for the needed system.
The empty entities are there to demonstrate the relationship between those entities and
the entities that we will be using in our system.
In looking at the current system, two databases exist: Just Add Commerce (JAC), which
supports the shopping cart software on the current website, and the Booklog Inventory,
which tracks all inventory both online and in-store. . Notice that neither database is able
to store product information that can dynamically support the online campus shop.
The needed system adds a third database called PRODUCT to meet the requirements of
an easily updatable website. Additionally, the client wanted the functionality of having
customers being added to a mailing list. This requires an additional table to store emails.
The adjusted diagram simply has Yahoo! Business as the name for the third database
instead of PRODUCT because in our implementation we used Yahoo! Business to create
the system. The JAC database has also been removed because the Yahoo! Business
database supports the functionality of the shopping cart feature.
ORDER
JAC_DATABASE
PK itemNumber
itemPrice
description
VENDOR
ORDER_LINE
PK,FK3 itemNumber
BOOKLOG_INVENTORY
PK itemNumber
color
size
price
description
CUSTOMER
Current System

69
ORDER_LINE
PK,FK4 SKU
PK,FK3 itemNumber
ORDER
JAC_DATABASE
PK itemNumber
itemPrice
description
VENDOR
BOOKLOG_INVENTORY
PK itemNumber
color
size
price
description
PRODUCT
PK SKU
itemPrice
description
picture
color
size
CUSTOMER
POTENTIAL_CUSTOMER
PK email
Needed System

70
ORDER_LINE
PK,FK3 SKU
PK,FK2 itemNumber
ORDER
VENDOR
BOOKLOG_INVENTORY
PK itemNumber
color
size
price
description
YAHOO! BUSINESS DATABASE
PK SKU
itemPrice
description
picture
color
size
CUSTOMER
POTENTIAL_CUSTOMER
PK email

71
Aspect: Scholarship
Current System
All the entities listed are objects involved with the overall process of a scholarship being
awarded and funded. The entities that have attributes listed are entities that currently
hold information for the system. The cloud represents Ms. Hawkins, who relates to the
applications to the scholarships. There are also many subtypes of applications used,
which are represented as ‘n’ types.
Ultimate System
The ultimate system incorporates a new entity called student scholarship application,
which replaces Ms. Hawkins in the system. In addition, the application entity is reduced
down to generalized application attributes to eliminate multiple application types.
Intermediate system
The intermediate system is similar to the ultimate system except that no information is
needed to be stored about the donor. This is because the sub scope only includes the
management of scholarships.

72
STUDENT
PK studentID
studentLNAME
studentFNAME
studentCREDITHRS
studentMAJOR
studentGPA
APPLICATION
PK applicationID
studentLNAME
studentFNAME
applicationTYPE
SCHOLARSHIP
PK scholarshipID
scholarshipNAME
scholarshipAMOUNT
committeeDEPARTMENT
committeeMAJOR
DONOR
FOUNDATION_OFFICEBUSINESS_OFFICE
THANK_YOU
applicationTYPE
TYPE_1 TYPE_2 TYPE_3 TYPE_4
APPLICATION_SCHOLARSHIP
FK2 scholarshipID
FK1 applicationID
studentNAME
alternateID
alternateNAME
sendtoCOMMITTEE (date)
committeeOKAYED (date)
thankYOU (date)
oktoALLOCATE (date)
fundsALLOCATED (date)
FK3 studentID
..... TYPE_N
Ms.
Hawkins
Current System
..... TYPE_N

73
STUDENT
PK studentID
studentLNAME
studentFNAME
studentCREDITHRS
studentMAJOR
studentGPA
APPLICATION
PK applicationID
studentLNAME
studentFNAME
studentLOCALADDRESS
studentPERMANENTADDRESS
studentMAJOR
studentGPA
studentDOB
usCITIZEN
coRESIDENT
studentCLASSIFICATION
extraCURRICULAR
SCHOLARSHIP
PK scholarshipID
scholarshipNAME
scholarshipAMOUNT
committeeDEPARTMENT
committeeMAJOR
DONOR
PK donorID
donorNAME
donorADDRESS
STUDENT_SCHOLARSHIP_APPLICATION
PK,FK2 scholarshipID
PK,FK3 studentID
FK1 applicationID
studentNAME
alternateID
alternateNAME
sendtoCommittee (date)
thankYOU (date)
oktoALLOCATE (date)
Ultimate System

74
STUDENT
PK studentID
studentLNAME
studentFNAME
studentCREDITHRS
studentMAJOR
studentGPA
APPLICATION
PK applicationID
studentLNAME
studentFNAME
applicationTYPE
SCHOLARSHIP
PK scholarshipID
scholarshipNAME
scholarshipAMOUNT
committeeID
DONOR
FOUNDATION_OFFICE
BUSINESS_OFFICE
THANK_YOU
TYPE_1 TYPE_2 TYPE_3 TYPE_4
FK1 applicationID
FK2 scholarshipID
FK3 studentID
studentNAME
alternateID
alternateNAME
sendtoCOMMITTEE (date)
thankYOU (date)
oktoALLOCATE (date)
..... TYPE_N
Intermediate System

75
Note: There is no current system database; therefore, no diagram.
Normalized ERD
The normalized Entity Relations Diagram Consists of 11 entities. Those entities are
Respondent, Student, Employer, Alumni, Respondent_Answer, Survey,
Survey_Question_Answer, Question, Answer_Set, Closed_Ended questions and
Open_Ended questions. Within each entity are entity attributes.
The Respondent entity includes a respondent ID, first name, last name, gender and
respondent type. Respondent types include: Student containing the respondent ID, 700
numbers and the expected date of graduation. The Employer entity contains the
respondent ID and business name. The last respondent type Alumni includes year
graduated and current employer. The Respondent_Answer entity contains the
RespondentAnswerID, date taken, respondent ID, question ID, answer ID,
Respondentanswer, IPaddress and SurveyID. The Survey entity contains the SurveyID,
SurveyName, administrator, Datecreated. The Survey_Question_Answer entity includes
SurveyID, answered and questioned. The Question entity includes the questioned and
Questiontext. The Answer_Set contains the answered and AnswerType. Close_Ended
entity contains the answered and options A-n. The Open_Ended entity contains the
answered and the answer field length.
The respondent can be one or many types including student, alumni and/or employers.
The respondent entity has a one to many relationship with the Respondent_Answer
entity. The Respndent_Answer entity has a one to many relationship with the Survey
entity where a survey can have many answers. The Survey entity has a one to many
relation with the associative entity Survey_Question_Answer. The Question entity has a
one to many relation with the Survey_Question_Answer entity. The Answer_Set entity
also has a one to many relation with the Survey_Question_Answer entity. The
Closed_Ended answer entity and the Open_Ended question entity can have non or many
relations.

76
RESPONDENT
PK respondentID
firstName
lastName
gender
respondentType
SURVEY
PK surveyID
surveyName
administrator
dateCreated
SURVEY_QUESTION_ANSWER
PK,FK1 surveyID
PK,FK2 answerID
PK,FK3 questionID
ANSWER_SET
PK answerID
answerType
QUESTION
PK questionID
questionText
CLOSE_ENDED
PK,FK1 answerID
numberOfResponses
optionA
optionB
optionC
optionD
optionE
optionF
optionG
optionH
optionI
optionJ
optionK
optionL
optionM
optionN
optionO
optionP
optionQ
optionR
optionS
optionT
optionU
optionV
optionW
optionX
optionY
optionZ
OPEN_ENDED
PK,FK1 answerID
fieldLength
STUDENT
PK,FK1 respondentID
700number
expectedGradDate
ALUMNI
PK,FK1 respondentID
yearGraduated
currentEmployer
EMPLOYER
PK,FK1 respondentID
businessName
RESPONDENT_ANSWER
PK respondentAnswerID
PK dateTaken
FK1 respondentID
FK2 questionID
FK2 answerID
respondentAnswer
ipAddress
FK2 surveyID
Needed System
Normalized Version

77
Denormalized ERD
In certain situations it is necessary to de-normalize a data structure in order to make it user
friendly, the survey site was one of those situations. Specifically, denormalization can result in
higher efficiency within the system. The De-normalized Entity Relations Diagram Consists of
six entities. Those entities are Respondent, Student, Employer, Alumni, Respondent_Answer and
Survey. Within each entity are entity attributes. The information contained in this section is the
system specifications for each entity and attribute used to construct the system.
The Respondent entity includes a respondent ID, first name, last name, gender and respondent
type. Respondent types include: Student containing the respondent ID, 700 numbers and the
expected date of graduation. The Employer entity contains the respondent ID and business name.
The last respondent type Alumni includes year graduated and current employer. The
Respondent_Answer entity contains the RespondentAnswerID, date taken, respondent ID,
question ID, answer ID, Respondentanswer, IPaddress and SurveyID. The Survey entity contains
the SurveyID, surveyName, administrator, date created, Question_ID and Answer_ID.
For the de-normalized survey system the respondent can be one or many types including student,
alumni and/or employers. The respondent entity has a one to many relationship with the
Respondent_Answer entity. The Respndent_Answer entity has a one to many relationship with
the Survey entity where a survey can have many answers.
RESPONDENT
PK respondentID
firstName
lastName
gender
respondentType
SURVEY(HTML)
headingInformation
question1
answers
question2
answers
questionN
answers
STUDENT
PK,FK1 respondentID
700number
expectedGradDate
ALUMNI
PK,FK1 respondentID
yearGraduated
currentEmployer
EMPLOYER
PK,FK1 respondentID
businessName
RESPONDENT_ANSWER (Excel File)
PK dateTaken
respondentID
respondentAnswer
ipAddress
RESPONDENT_ANSWER (Access File)
PK dateTaken
respondentID
respondentAnswer
ipAddress
RESPONDENT_ANSWER (Comma delimited file)
PK dateTaken
FK1 respondentID
respondentAnswer
ipAddress
Needed System
De-normalized Version

78
Class Diagram
This is the first diagram that we introduce within the object-oriented approach. A class
diagram is a type of static structure diagram that describes the structure of a system by showing
the system's classes, their attributes, and the relationships between the classes. A class diagram
contains the same entities as the entity-relationship diagram, but they are called objects. Objects
differ from entities in that not only do they store information, but they also do the actual
processing in the system. The processing done, or the behavior of the object, is possible because
objects have methods as well as attributes. Objects are also further classified to reflect
similarities and differences between objects (classes) using generalization/specialization
hierarchy. Additionally, cardinality (called multiplicity in the object-oriented approach) is shown
differently on the diagram.
Multiplicity Meaning
0..1 No instances, or one instance (optional, may)
1 Exactly one instance
0..* Zero or more instances
1..* One or more instances (at least one)
Table 1. Multiplicity Symbols
The look of the object-oriented class diagram is similar to the ERD; however the design
diagrams look substantially different between both approaches because of the object behavior
characteristic. The explanatory narratives for the class diagram are equivalent to the entity
relationship diagrams. Hence, there are no specific narratives with these diagrams.

84
-studentID
-studentLNAME
-studentFNAME
-studentCREDITHRS
-studentMAJOR
-studentGPA
STUDENT
THANK YOU
-scholarshipID
-scholarshipNAME
-scholarshipAMOUNT
-committeeDEPARTMENT
-committeeMAJOR
SCHOLARSHIP
DONOR
FOUNDATIONBUSINESS OFFICE
-applicationID
-scholarshipID
-studentID
-studentNAME
-alternateID
-alternateNAME
-sendtoCOMMITTEE (date)
-committeeOKAYED (date)
-thankYOU (date)
-oktoALLOCATE (date)
-fundsALLOCATED (date)
Class Diagram
Intermediate System
-applicationID
-studentLNAME
-studentFNAME
-applicationTYPE
APPLICATION
1 0..*
1 0..*
0..* 1
0..*
1
0..*
1
1 1
1
0..*
1
0..*
0..*
1
TYPE_NTYPE_1 TYPE_2 TYPE_4TYPE_3 ......

85
+addNew()
+delete()
+change()
-respondentID
-firstName
-lastName
-gender
-respondentType
RESPONDENT
+addNew()
+delete()
+change()
+orderQuestions()
-surveyID
-surveyName
-administrator
-dateCreated
SURVEY
+addNew()
+delete()
+change()
-questionID
-questionText
QUESTION
+addNew()
+change()
+delete()
+connectToQuestion()
-answerID
-answerType
ANSWER_SET
0...*
0...*
0...*
0...*
1
0...*
-surveyID
-answerID
-questionID
SURVEY_QUESTION_ANSWER
-respondendAnswerID
-dateTaken
-respondentID
-questionID
-answerID
-respondentAnswer
-ipAddress
-surveyID
RESPONDENT_ANSWER
-respondentID
-700Number
-expectedGradDate
STUDENT
-respondentID
-businessID
EMPLOYER
-respondentID
-yearGraduated
-currentEmployer
AlUMNI
-answerID
-numberOfResponses
-optionA
-optionB
-optionC
-optionD
-optionE
-optionF
-optionG
-optionH
-optionI
-optionJ
-optionK
-optionL
-optionM
-optionN
-optionO
-optionP
-optionQ
-optionR
-optionS
-optionT
-optionU
-optionV
-optionX
-optionY
-optionZ
CLOSE_ENDED
-answerID
-fieldLength
OPEN_ENDED
Class Diagram
Needed System
Normalized Version

86
+addNew()
+delete()
+change()
-respondentID
-firstName
-lastName
-gender
-respondentType
RESPONDENT
-headingInformation
-question1
-answers
-question2
-answers
-questionN
-answers
SURVEY
0...*
0...*
-respondendAnswerID
-dateTaken
-respondentID
-respondentAnswer
-ipAddress
RESPONDENT_ANSWER (Excel File)
-respondentID
-700Number
-expectedGradDate
STUDENT
-respondentID
-businessID
EMPLOYER
-respondentID
-yearGraduated
-currentEmployer
AlUMNI
-respondendAnswerID
-dateTaken
-respondentID
-respondentAnswer
-ipAddress
RESPONDENT_ANSWER (Access File)
-respondendAnswerID
-dateTaken
-respondentID
-respondentAnswer
-ipAddress
RESPONDENT_ANSWER (Comma Delimited File)
Class Diagram
Needed System
Denormalized Version

87
Use Case Diagram
A use case diagram is a sub class of behavioral diagrams. A use case is an activity or
process that the system carries out, usually in response to a request by the user or actor. A use
case diagram documents activities of the system and who is allowed to be involved in the
process. Use cases are represented by ovals and the actors (users of the system) are represented
by stick figures. The boxes define the boundaries of each subsystem of the entire system.
Interaction among actors can be part of the assumptions used in the use case. In one form of
interaction, a given use case may include another. The first use case often depends on the
outcome of the included use case. The notation is a dashed arrow from the including to the
included use case, with the label "«include»". In another form of interaction, a given use case,
(the extension) may extend another. This relationship indicates that the behavior of the extension
use case may be inserted in the extended use case under some conditions. The notation is a
dashed arrow from the extension to the extended use case, with the label «extend».
Note that for the use case diagram, both the people involved with the system, and the
processes of the system are yellow – this change is to improve the readability of the diagram and
to better illustrate that the subsystems of each system with the blue.
The bookstore and business department assessment survey site both utilized the use case
diagram as a tool. However, the scholarship aspect, used the activity diagram which is described
later, as their object-oriented diagram.
The following depicts a specific narrative for each aspect of the project followed by the
accompanying use case diagrams.

88
Aspect: Bookstore
The first use case diagram is for the current system and the second diagram is for the
needed system. The entire system is broken down into subsystems. These are the
different systems that are necessary to complete the overall task of processing an order.
In the first diagram, the manager of the bookstore is able to participate in every process
and uses every subsystem that is necessary to fulfill an order. On the other hand the
customer is only able to participate in four of the processes, the main area of
concentration being in the Order-entry subsystem. However, the customer does have the
option to return a product, which is located within the Order-fulfillment subsystem.
In the second diagram, the manager has the same involvement with the previous
processes, but now has a few additional processes, located within the Inventory and
Website Maintenance subsystem. The customer’s involvement is the exact same, but
there is now a potential customer. The potential customer does not have to be involved in
any of the processes needed to place an order, but can just add to the e-mailing list
available on the website.

90
Activity Diagram
The other way to document a use case scenario is with an activity diagram. This diagram
documents the workflow of the business processes, specifically how the data travels between
users of the system. The purpose of this diagram is the same as the use case diagram – to
document the processes of the system and flow of data – however, if there are more users of the
system, with data passing between them, the activity diagram is a more effective tool to
document the processes and data flow than the use case diagram. The elongated rectangles
represent each user (actor) of the system. The ovals represent specific processes within the
system. The connecting lines illustrate the flow of data between processes.
Aspect: Scholarship
Current System
The current system diagram depicts all the users and players involved with a student
scholarship applications. This diagram shows the basic needed activities to maintain and
track scholarships over the approval process and allocation process. Note that the
computer system is labeled non-existent. In the ultimate and intermediate system
diagrams, the computer system and database system are introduced to take the place of
manual tracking of the scholarships.
Ultimate System
The ultimate system diagram integrates the web and database into the activities taking
place during the scholarship management process. Note that additional activities taking
place include storing the information of each process to the database and Ms. Hawkins
updating any changes to the data in the database.
Intermediate System
The intermediate system diagram includes all the activities from the ultimate system.
The activities highlighted in red indicate the activities within the scope of the system.

91
COMPUTER SYSTEM
(NON-EXISTENT)
BUSINESS
OFFICE
FOUNDATIONCOMMITTEEMS. HAWKINS
(MANUAL
TRACKING)
STUDENT
Fill Out Application
Verify Student Info Correct
Select Student
Select Alternate Student
Create Letter
Send Thank You Letter
Call Foundation
Transfer Funds
Allocate Funds
Verify Allocation
Print Report (Anytime)
Activity Diagram
Current System

92
WEB AND DATABASE BUSINESS
OFFICE
FOUNDATIONCOMMITTEEMS. HAWKINSSTUDENT
Fill Out Web Application
Update Student Info
Select Student
Update Student Info
Update Student Info
Transfer Funds
Allocate FundsUpdate Student Info
Display Web Applications
Store Information
Store Information
Store Information
Store Information
Review Student Information
Store Information
Store Information
Activity Diagram
Ultimate System

93
OFFLINE DATABASE BUSINESS
OFFICE
FOUNDATIONCOMMITTEEMS. HAWKINSSTUDENT
Fill Out Application
Update Student Info
Select Student
Update Student Info
Update Student Info
Transfer Funds
Allocate Funds
Update Student Info
Store Information
Store Information
Store Information
Store Information
Send Student Application
Call Foundation
Activity Diagram
Intermediate System

94
In the current system, the survey administrator generates a paper survey to be given to all
survey participants. The administrator and professor then disperse the paper surveys to
the respondents. The administrator requests the WebCT administrator generate the
electronic survey from the paper survey provided by the administrator. The respondents
then fill out the paper survey and enter the information into the WebCT survey system.
The system administrator then extracts the information fro WebCT and validates the data.
The validated data is then used to generate reports. Note that the respondents are only
students, as WebCT allows only Mesa State students on the system.
In the needed system, the survey administrator disperses the sign up information to the
professors, alumni and employers. The Professor disperses the sign up information and
website URL to the students in the selected classes. The students, alumni and employers
then get their login name and passwords from the web site via return email. The
Administrator generates the survey to be used and loads it to the web site. The students,
alumni and employers then take the survey which is forwarded to the administrator for
validation and compilation into report form. Note that the alumni and employers are not
included in the respondent group.

96
Web-based Survey Subsystem
Registration Subsystem
Disperse sign up
URL
Get login ID and
password
Professor
Take electronic
survey
Generate
electronic survey
«uses»
«uses»
Disperse student
sign up info
«uses»
«uses»
«uses»
Use Case Diagram
Needed System
Report Subsystem
Validate survey
data
Generate reports
Survey Administrator
«uses»
«uses»
«uses»
«extends»
Student
«uses»
«uses»
Disperse sign up
via email
«uses»
Employer/Alumni
«uses»
«uses»
«uses»

97
Project Constraints
During the course of several meetings with our clients, certain constraints became
apparent. A constraint is something that limits the ability or success of the new system.
Constraints ranging from budgets, bottlenecks, and organizational policy inherently forced the
direction of the project. Initially, there was no budget for the bookstore and assessment survey
aspects. This constraint limited many choices for the system creations. There was also some
technical difficulty in the functionality of the Houston Hall lab and the Dreamweaver web
templates. These bottlenecks slowed the overall progress of the project. Additionally, we were
informed that Mesa State College has policy that prohibits the use of student-made programs on
their servers and campus wide network. Should this policy ever change, more systems with
higher functionality at minimal costs could be designed and implemented for this organization.
In an effort to address the policy, the clients agreed to provide additional monetary resources.
This led the team to look at different alternatives that originally were not thought of. The change
in budget decisions shifted the direction of the project, specifically how the systems would be
implemented. In place of student-made programs, the use of the third-party software was looked
at as a possibility.

98
Alternatives
The last step in the analysis phase is to look at all possible alternatives for the project.
Specifically, each aspect was thoroughly evaluated; looking at all requirements and constraints to
determine alternatives and then one alternative must be recommended to the client. However,
the client has the final decision in deciding which alternative to implement. The alternatives are
established with a basis of environmental and implementation considerations. Each alternative is
considered viable if it falls within the scope of the project and fulfills the system requirements.
To document the alternatives for the project, two statements were created:
• Statement of the alternatives for requirements
• Statement of environmental considerations
The following pages contain the two statements concluding the analysis phase section of this
report.

99
Statement of the Alternatives for Requirements
One common problem with development projects is scope creep. As the name implies,
the development team may receive requests to add new system functions after the requirements
have been defined and decisions finalized. One way to help control this problem is formalizing
the process to identify, categorize, and prioritize the functions that will be included within the
new system so that everyone agrees to and signs off on system functions. The level of
automation describes the support the system will provide each function. To determine functions
necessary to evaluate alternatives, the events of the system for each aspect were given priorities.
Events were established through interviews with the clients. Each event is given a specific
priority based on need, mandatory or important, and by the level of automation, from low-end to
high-end. Tables showing this information for each aspect are at the end of this phase.
These functions are also used when considering other areas that affect implementation
alternatives. The three areas to take into account are:
• General requirements
• Functional requirements
• Technical requirements
General requirements include considerations that are important but not directly associated
with the computer system itself. The first major component of general requirements is the
feasibility assessment, which was discussed earlier in the report. Each of the implementation
alternatives under consideration must meet the requirements for cost, technology, operations, and
schedule defined in the feasibility analysis.
Functional requirements represent the functions that must be included within the system
and are the same functions that are identified, categorized, and prioritized in the first set of
considerations.

100
Technical requirements can be system constraints such as which platform the system
must run on. However, technical requirements also include items such as its method of
operation, its utility, as well as characteristics that affect the maintainability and usability of the
system.
Generally, a matrix is developed to show the weighted factors and scores for each
requirement group. The client, system users, and project team should all have input in
establishing the weighting factors. Consideration must be given not only to the relative
importance of each criterion within each area, but also the balance among all areas. The ratings
must reflect the desires of the client. The matrix is an excellent tool to assist the client in
selecting the best alternative.
The following pages contain two tables for each aspect. The first table outlines each
aspect’s prioritized system functions and associated levels of automation. Functions with the red
font indicate functions that have been implemented into the system. The second table outlines
the matrix for general, functional, and technical requirements for each alternative within each
aspect.

101
Aspect: Bookstore
Functions Priority
Low-End
Automation Medium Automation
High-End
Automation
Working
website Mandatory Data Entry Real-time
Automatic from
activity
Update web
pages Mandatory Data Entry Real-time
Automatic from
activity
Create special
promotions Important Data Entry Real-time
Recommendations
based on sales
history
Initiate a
promotion e-
mailing Important Data Entry
On-line view and real-
time
Automatic from
activity
Maintain Online
Inventory Important Data Entry Real-time
Automatic from
activity
Create sales
summaries Important Print on request
time
Data visualization
tools
Create order
summaries Mandatory Print on request
time
Data visualization
tools
Create
shipment
summaries Important Print on request
time
Data visualization
tools
There were four alternatives that were presented to Ms. Tracy Brodrick. First Status Quo or no
change to the system. Second, Just Add Commerce (JAC), which is the shopping cart software
that is currently in use. This alternative would be to include additional features from JAC to
meet other system requirements. The third alternative would be to purchase a third party web
software package – Yahoo! Business. The last alternative presented was a student prototype - a
MS database with form views to input product data, and a web template in Dreamweaver for
product pages. Please refer to the matrix to see the side-by-side comparison of alternatives.

102
Requirements
Status
Quo Just Add Commerce
Yahoo!
Business Student Prototype
General
Expected Value of
Benefits 1 3 5 0
Developmental Cost 5 1 1 5
Length of time until
deployment 5 5 5 0
Requirements for
internal expertise 1 3 4 2
Performance record
of the provider ? 4 5 ?
Level of technical
support provided 1 3 5 1
Warranties and
support services
provided 1 3 5 1
Total General 14 22 30 9
Functional
Working website 4 5 5 0
Update web pages 1 4 5 0
Create special
promotions 1 4 4 0
Initiate a promotion
e-mailing 0 ? ? 0
Maintain Online
Inventory 0 5 5 0
Create sales
summaries 0 5 5 0
Create order
summaries 0 5 5 0
Create shipment
summaries 0 ? ? 0
Total Functional 6 28 29 0
Technical
Robustness 2 4 5 3
Programming errors 0 5 5 1
Quality of Code 2 4 5 2
Easy installation 2 5 5 0
Flexbility 0 4 5 3
Structure 2 4 5 3
User-friendliness 1 3 4 3
Total Technical 9 29 34 15
Grand Total 29 79 93 24

103
Aspect: Scholarship
Functions Priority
Low-End
Automation
Medium
Automation
High-End
Automation
Get available
scholarships Important Search listings
Real-time. Web
update
Filter per student
inputs
Submit application Mandatory
Employee data
entry
Real-time. Web
interface with
database
Promote similar
scholarships
Sort applications Important
Employee Query
database Real-time sort.
Automatic sort
when submitted
Distribute
applications to
committees Mandatory
Employee mail
sorted applications
Web-interface with
Committee
Prompt to send
applications
Award scholarship Important Database update
Web-interface with
Committee
Automatic
Notification
Create award letter Important Print on request
Template with
data inputs
Automatic
generation
Update thank you
letter submittal Important
Employee data
update
Real-time update.
Web interface with
student Real-time. Web site
Send award
information to MSC
Foundation Important
Employee Email on
request Real-time update
Automatic update
when Thank you
Letter updated
Create scholarship
report Mandatory Print on request
On-line view.
Real-time Visualization tools
Update scholarship
report Important Data search Real-time update
Automatic on
activity
There were four alternatives that were presented to Ms. Shanon Hawkins. First Status Quo or no
change to the system. Second, a student prototype, or a student-made program created in MS
Access. The third alternative would be to purchase a software package. The last alternative
presented was to purchase a web office system that is completely integrated to track scholarship
information. Please refer to the matrix to see the side-by-side comparison of alternatives.

104
Requirements Status Quo
Student
Prototype
Purchase
Software
Package
Purchase Web
Office System
General
Availability for experienced
staff 12 12 12 9
Low development costs 25 25 10 10
Benefit values 4 16 12 16
Time until deployment 25 20 15 15
Resource impacts 12 16 16 16
Training level 0 20 12 12
Functional
Get available scholarships 12 16 12 16
Submit application 15 20 20 20
Sort applications 12 20 20 20
Distribute applications to
committees 12 20 12 12
Award scholarship 12 20 12 12
Create award letter 12 16 16 16
Update thank you letter
submittal 12 20 16 16
Send award information to
MSC Foundation 10 20 15 15
Create scholarship report 15 25 20 20
Update scholarship report 15 25 20 20
Technical
Programming Errors 20 20 25 25
Code Quality 15 20 25 25
Documentation 12 20 20 20
Installation Ease 16 16 20 20
Flexibility 16 20 8 12
User-Friendliness 10 25 20 25
Total Overall 294 432 358 372

105
Functions Priority Low End Automation Medium Automation
High End
Automation
Registration Mandatory Fill in Paper version
Automated Web
process Returns
Name and Password
Returns Login
Information
Login Mandatory Through WebCT Through Website
Returns Login
Record to
Administrator
Create Survey Important Manual process Semi-automated
Stores Questions
and Answers
Input Survey Important WebCT
Upload to server
HTML Upload CSS
Data Validation Mandatory Manual Semi-Manual Somewhat Manual
Export Data Mandatory From WebCT
Comma Delimitated
File
Data Dump to Data
Base
Create Report Required Manual Construction
Semi-manual
procedure
Automated Report
Generation
File Survey Important Required Can Be Eliminated
Would Be
Eliminated
There were four alternatives that were presented to Fred User. First, Status Quo or no change to
the system. Second, Survey Monkey, a proprietary survey system that stores data on a third-
party server. Third, a client-supplied server where Mr. Fred User would obtain his own server
and the survey system created would be a student-made program. Finally, the online server
alternative where Mr. Fred User would use an off-campus service provider and the survey
system created would be a student-made program. Please refer to the matrix to see the side-by-
side comparison of alternatives.

106
Requirements
Status
Quo Survey Monkey
Client Supplied
Server Online Server
General
Developmental Cost 5 10 15 20
Deployment Time 4 8 12 16
Organizational
Impact 4 16 20 20
Availability of
experienced staff 3 3 9 12
User Computer
Iteracy Level 3 6 9 9
Expected Time
Savings 5 20 20 20
Functional
Registration 4 5 10 12
Login 5 10 10 10
Create Survey 5 10 12 12
Input Survey 3 10 10 12
Data Validation 3 8 10 10
Export Data 10 10 11 12
Create Report 8 8 10 12
File Survey 15 15 15 15
Technical
Robustness 2 4 5 5
Input Errors 0 5 5 5
Quality of Code 2 4 5 2
Easy installation 2 5 5 3
Flexbility 0 4 5 3
Structure 2 4 5 3
User-friendliness 1 3 4 3
Grand Total 86 168 207 216

107
Statement of Environmental Considerations
One of the main considerations when developing a new system is the application
environment in which the system is deployed and operated. This environment consists of the
configuration of computer hardware, system software, and networks. Items to consider when
selecting an environment are:
• “Compatibility with system requirements.
• Compatibility among hardware and system software.
• Required interfaces to external systems.
• Conformity with the IT strategic plan and architecture plans.
• Cost and schedule.”
Moreover, the development environment and tools must also be considered. Generally, the
environment determines the development environment and tools. For example, some companies
might have a preferred language for system development.
The Current Environment
As mentioned previously, the current environment at Mesa State College prevents the
ability for student-made programs to be on the network server. This limits the environmental
alternatives that are available. Additionally, the technical skills of the system users, as well as
their familiarity with complex software are minimal.
The Proposed Environment
It is proposed that automating and increasing the level of technology within the
environment, will best meet the scope of increased usability. Specifically, the use of Internet
technology should be utilized in the bookstore and business department assessment survey site
aspect; and the use of database software should be utilized in the scholarship aspect.

108
The table below illustrates environmental alternatives that could be used for each aspect
along with a description for each aspect.
Alternative Description
1. Use web-hosted
database, using third
party server
Bookstore – Web hosted database with permissions by authorized
user. Use a web interface separately to manage web pages, being
linked to a web-hosted database.
Scholarship - Web hosted database with permissions by authorized
users. Use a web interface separately to manage the scholarship
applications submission, being linked to web-hosted database.
Business Department Assessment Survey Site - Web hosted database
with permissions by authorized users. Use a web interface
separately to creation of surveys and taking of surveys.
2. All functionality done
on web-based
applications
Bookstore - Utilize web-based applications to manage web pages and
product database.
Scholarship - Utilize web-based applications for both scholarship
application submittal and internal scholarship award processes.
Create specific interfaces with specific users (Committees, Financial
Aide Office, Students, MSC Foundation)
Business Department Assessment Survey Site - Utilize web-based
application for both creating surveys and taking surveys.
3. Locally managed
database with manual
entry for all processes
Bookstore – create MS database with form views to input product
data. Create a web template in Dreamweaver for product pages.
Manually update product pages through ColdFusion to maintain
website.
Scholarship - intermediate system - create MS Access database with
form views to input data and create reports.
Business Department Assessment Survey Site – create MS database
with form views to create surveys. Create web templates in
Dreamweaver for survey pages. Manually update survey pages
through ColdFusion to maintain website.

109
Aspect: Business Department Survey Site
The webhost alternative matrix was created to help the client make the best decision
concerning what server provider should be selected to host mesa state college’s survey
site. The top three choices were presented to the client, each host offered the needed
functionality for proper site construction.
Here StartLogic was less adaptable than competitor’s webhostforlife or netfirms
business. Netfirms business package included all required functionality for a single price,
while webhostforlife required the client to purchase additional functionality. The client
selected Netfirms business as their webhost.
Web Host Selection
Criteria
Weight
(5=High,
1=Low) WebHost4Life.com Startlogic.com
Netfirms.com
Business Status Quo
Raw Extended Raw Extended Raw Extended Raw Extended
Development Cost 5 4 20 2 10 4 20 1 5
Deployment time 4 3 12 3 12 4 16 1 4
ASP 4 4 16 4 16 4 16 1 4
Data base 3 3 9 3 9 3 9 1 3
Price 3 4 12 3 9 3 9 1 3
Functionality 5 4 20 2 10 4 20 1 5
Design Software 4 3 5
Totals 89 66 90 24
^ Cold Fusion
*SQL **Access ***Mysql
* ** WebHost4Life.com 6.95 +
*** ^ startlogic.com 5.95 +
* ** *** ^ Netfirms
Business 14.95
The table below outlines the alternatives that were selected for each aspect.
Aspect Alternative Selected
Bookstore Yahoo! Business
Scholarship Student Prototype
Business Department Assessment Survey Site Online Server

111
Description
The goal of the design phase is to “define, organize, and structure the components of the
final solution system that will serve as the blueprint for construction.” (Satzinger, Jackson, &
Burd, 2004, p. 318) The design is based on the proposed system, the requirements defined, and
decisions made during the analysis phase. Like the analysis phase, the design phase is also a
model-building activity. Low-level design entails developing the detailed algorithms and data
structures that are required for software development. High-level design consists of developing
an architectural structure for software components, databases, the user interface, and the
operating environment. The traditional approach uses the following diagrams for the design
phase:
• System Flowchart
• Structure Chart (and accompanying pseudo code)
• Dependency Diagram ( and accompanying Relational Database Schema)
The object-oriented approach uses the following diagram for the design phase:
• Package Diagram
Regardless of the approach used, development of the user-interfaces and system security and
controls are also designed in this phase. It is important to keep in the mind that the SDLC is an
iterative process. Therefore, any additional discovery in the design phase requires modification
to the analysis phase documentation. The following pages outline specific descriptions for the
diagrams as well as explanatory narratives for each aspect.

112
System Flowchart
The system flowchart demonstrates the various computer programs, automated and
manual processes, and databases that make up a complete system. Processes are grouped into
programs and the system flowchart shows the flow of data between programs and storage. A
system flowchart graphically describes the organization of the subsystems into automated and
manual components. Flowlines represent the sequences of processes, and other symbols
represent the inputs and outputs to a process. System flowcharts can also be used to identify key
control points in a system’s internal control structure. The system flowchart is one of the most
often used tool or technique. The figure below illustrates the symbols and their corresponding
meaning.
Figure 5. System Flowchart Symbols

Senior Capstone - Systems Operations Manual

Senior Capstone - Systems Operations Manual

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Senior Capstone - Systems Operations Manual

Similar to Senior Capstone - Systems Operations Manual (20)

Recently uploaded

Recently uploaded (20)

Senior Capstone - Systems Operations Manual