Transcript shanejohn - University of Alaska, Anchorage

CS 495: Internship Project
By Shane Ursani & John Vicente
Interned with University of Alaska
Anchorage
Company Overview
University of Alaska Anchorage is
an educational facility which
“inspires learning, and advances
and disseminates knowledge
through teaching, research, and
public service”.
Hired as Software Developers
Faculty Workload Data Management System
 Every year, UAA faculty
members and department chairs
are required to fill out two forms
as required by their UAA
contracts.
 First form is the Workload form.
 Faculty members propose to the
university about which courses
they are going to be teaching,
which research they plan to
complete, and any community
service they are required to
accomplish.
Faculty Workload Data Management System
(cont’d)
 The second form is the Activity
Report form.
 Faculty members report the actual
teaching, research, and/or
community service they completed
in contrast to what they proposed
in the Workload form.
These forms are currently completed
with pen
and paper.
Project Proposed
• In the Spring 2002 semester, a
CIOS group made a proposal to
eliminate the current method
the Workload and Activity
Report forms are filled out
with.
Objective: The project
proposed the system be
transitioned to an electronic
database driven web
application.
Prototype Created
• The CIOS group produced a
Relational Database along with
ASP pages for the web application.
• The prototype was approved, but
the application had its own flaws.
– Every unique visit to the workload and
activity report website required a 700KB+
download.
– Non-user friendly workload form input
scheme.
– Difficult GUI usability.
– Did not have the ability to create new
courses.
– No adjunct handling capability.
Project Overview
• Hired to re-implement the Faculty
Workload Data Management System and
correct the prior group’s flaws.
• Provided with the CIOS group’s research.
• Re-used the pre-approved relational
database model. The database tables were
stored on Microsoft SQL Server.
– Due to request by the customer, the
database was modified slightly to work
within the constraints of the requests.
(i.e. adjuncts, auto-update)
Project Overview (cont’d)
• Did not reuse the prior group’s
existing code.
– Unfamiliarity with ASP and
JavaScript
– Preference to learn the .NET
Framework.
• Nature of our specifications
differed from the prior group from
the people we contacted during the
semester.
Meetings
• Had weekly meetings and informal
discussions with Dr. Kenrick Mock to
discuss the progress of the project.
• Had a meeting with Barbara Tullis, the
project sponsor for any additional
functionality that was needed.
• Had a meeting with the dean of CAS
College for features the dean desired.
• Had a meeting with the financial
affairs office.
System Architecture
L=c*+c*aabb+c*ab
Database Tables
Course
C
Workload_component
Component_item
A
A
Research_Product
B
B
Research_Proposal
Research_Collaborator
Microsoft SQL Server
A
Valid-Request
Server
B
Response
Client-side webform
C
Error-Handling
Research_Funding
Project Design
System Flow Chart
Authentication
INDIVIDUAL’S HOMEPAGE
LOGIN PAGE
Load Individual Employees necessary info
FACULTY
Load faculty request forms
EDIT/VIEW/NEW
UNIT
SELECTION
STATISTICAL INFORMATION
CHAIR
DEAN
Load chair request forms
VIEW
DEPARTMENT
FACULTY
SUBMITTALS
APPROVE
FORM
(optional) STATISTICAL QUERIES
WEB FORM
Load dean request forms
VIEW COLLEGE
FACULTY
SUBMITTALS
APPROVE
DEPARTMENT
FORM
Programming Languages
• The project called for the use of
server pages constructed with some
technology.
• We chose to develop ASP pages
using Microsoft’s .NET framework.
• For the scripting language, we
chose to use C# because of its
exceptional speed along with its
built-in database controls.
Phased Lifecycle Model
Incremental development
• Avoids big bang implementation.
• Assumes all requirements are already known.
Software Process
• Describe the problem.
• Describe the solution.
• Verify
– does the solution solve the stated
problem?
• Validate
– did we solve the right problem?
Project Development
• The project was not be
implemented in a Object-Oriented
fashion due to the nature of web
programming.
• Event-based and modular
decomposition was performed.
– many places where code was re-used
– many generic functions were created.
Project Challenges
• New languages to learn: ASP.NET
and C#.
– Many ways to perform one task.
• No ASP.NET & C# guru available for
consulting with.
– Dr. Mock helped us out with his
knowledge, got stuck with problems
i.e. data grid column hiding, disabling
text boxes from doing auto post back.
Project Challenges (cont’d)
• The Workload form had to be reimplemented five times.
– 1st Revision: Two data grids on a
single page. One keeping track of
the total units, other holding a
list of components added.
– 2nd Revision: Two data grids like
before. A button available to
redirect a user to a separate page
to add a single component.
Percent of component field autocalculate feature was
implemented.
Project Challenges (cont’d)
– 3rd Revision: Unlike before, when a
new component was added, the user
remained on the same page until all
components were added. No data
grid available until you returned to
the previous page.
– 4th Revision: Everything was back
on one page. 6 data grids available.
One for total units, other five for
each component. Percent of
component was implemented in a
different way.
– 5th Revision: Same layout, but a
different method for workload
units input.
Project Challenges (cont’d)
• Lack of SRS document
– Clients continually changing
their mind about functionality
and look, etc.
– Lack of understanding the
client’s needs resulted in huge
setbacks.
Testing Technique
• The goal of testing is to show a
program has met its specifications.
• Black Box Testing: A software
testing technique whereby the
internal workings of the item being
tested are not known by the tester.
– For example, in a black box test on a
software design the tester only knows
the inputs and what the expected
outcomes should be and not how the
program arrives at those outputs.
Inspections
• There were periodical intragroup code inspections.
– Inspections are more costeffective than testing because
they can be applied early in the
development cycle. Errors
sometimes are not caught until
someone else looks at the code.
Verification and Validation
• Verification: evaluating whether a
system is correctly built.
– You want to check if it fulfilled the
given requirements.
• Validation: evaluating whether the
right system is built.
– You want to check if it fulfills the
user’s needs. This is where the
miscommunications with client
occurred. Lack of SRS. User needs
constantly change.
Conclusion
• Received real-life experience in
software development by
working for a real client.
Trying to fully understand the
customer’s needs for the
system.
• Learned that creating a good
system design is important
rather than just ‘hacking
away’.
Conclusion (cont’d)
• Realized the significance of
having a SRS document
created, read and agreed upon
by both the developers and
the clients.
– Different clients wanted different
functionality, no one person to say
what should be available, what
shouldn’t.
• Software engineering is still an
immature discipline.
– No lifecycle model is perfect.