Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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.