P r o j e c t
1
Elaboration Phase
Sachit Gupta, Noah Levin Fundamentals of Systems Development November 4th, 2008
Executive Summary Iteration Plans Overview Highest Priority Use Cases Three Iterations
E l a b o r a t i o n P h a se
Table of Contents
3 4-7 5 6 7
Project Vision Introduction Stakeholders User Summary and Environment Needs and Opportunities Product Features Interviews
8-20 9 10 11 12 13, 14 15-20
Functional Requirements Use Case Model Survey User Flow Model Use Case Diagram Use Cases Fully Dressed Use Cases
21-35 22 23 24 25-28 29-35
Supplementary Specifications
36-38
System Models Domain Model Design Model Data Model
39-42 40 41 42
Project Management Time Accounting Problem Analysis
43-45 44 45
Appendix Interview Notes Scratch Work
46-57 47-55 56, 57
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
2
International Conference Review System We have been asked to help improve the process of uploading and reviewing documents for submission into an international research conference, hosted yearly by the research office of a renowned university. This research office has decided to develop an International Conference review system (ICRS) to help manage the paper reviews and to solve a lot of the problems they’ve been having with their current system implementation of unorganized emails and messaging between the primary actors involved in the conference.The problems faced by the ICRS as the number of people registering for their conference is growing, have begun to overwhelm their staff. These problems, however, can be easily reduced in scope if not eliminated through the use of a properly implemented information system. In the inception phase, we combined detailed technical analyses of business processes and stakeholders with input from interviews and created a broad template for the ultimate creation and implementation of the ICRS. This document, the elaboration phase, contains a more thorough analysis of the major risks and requirements for the system. Our fully revised system plan, utilizing a relational database coupled with a secure yet easy to use web interface, is designed to facilitate the implementation of a system that not only eases the burden on the staff and users working with the ICRS, but also makes oversight over the entire process a much easier endeavor. The agile Unified Process approach helped us flesh out a detailed analysis of the project requirements and the steps we would need to incorporate in our development phase. By focussing on simplicity, user requirements and stakeholder input, we were able to determine process-critical features which formed the framework for our system design. We used timeboxed iteration phases over a period of three weeks to refine and expand our project vision, which allowed us to plan the core architecture of the ICRS. In doing so, we revised our overall schedule and allocation of resources to accomidate the expansion of our system. Finally, we determined that the project is certainly feasible as long as we prioritize high risk business tasks (i.e. insuring accurate and efficient paper revisions).
E L ABORATIO N P h a se
Executive Summary
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
3
Iteration Plans
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
4
Timeline and Planning We established a plan for the first three iterations, which contain no overlaps within fixed time constraints of one week each. This time planning was done at the very beginning of the elaboration plan and allowed us to identify a clear focus moving forward. Below lists the time and man hour approximations for each iteration. It is worth mentioning that we did these iterations with only the resources that we had: two people and two respective initial documents. For the most part we completed all of our objectives for each iteration. The next two pages shows our major findings during the iterations, and the work we completed is evident throughout this report. If we had more people in the assignment, we would have distributed workers to complete software architecture models and use case prototypes – artifacts that are not present in this document due to lack of experience in the field. Regardless, we feel we are ready for the final elaboration phase.
October
November
Iteration 1
Iteration 2
Iteration 3
1 Week
1 Week
Highest Priority UCs
Revising / Solidifying
This work will require approximately 4 people to be handled at maximum efficiency.
We believe that around 6 people could handle this job if appropriate work distribution is identified.
I t e r a t i o n P l a ns
Overview
1 Week Secondary Functionality / Completion This section only needs the 2 workers that had done previous work in the inception phase.
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
5
We listed the use cases in order of priority to the International Conference Review System. We used several different factors when considering the order of priority for the use cases. Dependencies between use cases also made this listing particularly difficult because they made us assign high priorities to functionalities that may seem to be unimportant at a quick glance (i.e. authentication fails is rated higher than check paper status). These ratings were used when determining which use cases should be identified during each iteration phase.
A-Level Use Cases 1. Create Account 2. Review Paper 3. Submit Paper 4. Assign Reviewers 5. Read Review 6. Authenticate User 7. Authentication Fails 8. Download Paper 9. Receive Paper Assignment 10. Send Error Notification 11. Submit Late Review 12. Update Conference Information 13. Verify Paper Submission: 14. Check Paper Status 15. Check status
B-Level Use Cases 16. Authorize Publishing 17. Assign scores online 18. Appeal Decision 19. Set initial conference parameters 20. Request Assignment Change 21. Request Extension 22. Request Publication Notification 23. Get Web Interface Failure Notification 24. Handle Database Failure 25. Track Workflow Metrics 26. Notify Failed Submission 27. Handles fraudulent paper notification 28. Monitor System 29. Cancel Conference 30. Execute conference reports 31. Review Error Reports
I t e r a t i o n P l a ns
Highest Priority Use Cases
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
6
Iteration 1 Goal: The objective of the first iteration was to: 1. Compare our phase 1 reports 2. Outline list of use cases and product features What we did: For this iteration, we compared our phase 1 reports and outlined key differences between our reports. We also created a comprehensive list of product features and use cases that we would implement over the course of the project. We worked on the following uses cases: Submit Paper, Review Paper and Assign Reviewer. In the long run we achieved all of our goals
Iteration 2 Goal: The objective of the second iteration was to: 1. Create a refined project vision. 2. Review and refine architecturally significant use cases. What we did: For this iteration, we created a refined project vision to meet the phase 1 milestone evaluation. Besides that, we worked on the following use cases: View Conference Information and Check Paper Status. Essentially, we completed all of our objectives for this phase with almost no time to spare.
Iteration 3 Goal: The objective of the third iteration was to finish the project. This included: 1. Finalizing the use cases and fully dressed use cases 2. Polishing the domain, design, and data models What we did: For this iteration, we created a refined project vision to meet the phase 1 milestone evaluation. Besides that, we worked on the following use cases: Authorize Publishing and Create Account. We also worked on the three models and identified additional supplementary specs. We completed everything that we expected with room to spare, which is why we were able to perform a thorough revision of the document. This iteration was successful due to prior planning and exemplary cooperation.
I t e r a t i o n P l a ns
Three Iterations
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
7
Project Vision
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
8
Introduction The purpose of this document is to collect, analyze, and define high-level needs and features of the International Conference Review System (ICRS). It focuses on the capabilities needed by the stakeholders and the target users, and why these needs exist. The details of how the ICRS fulfills these needs are detailed in the use-case and supplementary specifications. It is important to note that this document has been revised several times to include a merger of two project visions. The result is a comprehensive list focusing on
Problem Statement The review system currently in place is based around storing and sending papers via e-mail, and incorporates no content management processes. This system suffers from problems with misplaced documents, overheads and delays due to emailing documents back and forth, lack of a comprehensive search functionality and tedious inter-departmental communication. Authors, reviewers, committee members, managerial staff and even employees in other departments are currently affected by the limitations of the existing system. A solution to this would be to implement a centralized document management system which maintains a document library, user database and automates a great deal of the workflow process involved in submitting and reviewing documents.
Positioning The new International Conference Review System (ICRS) is a system that will help manage the professional paper review process (involving aspects of the processes surrounding the submission, review, and acceptance related decisions) in an environment where an increased number of submissions are anticipated. This system aims to decrease the amount of time used to review each paper while reducing the mistakes associated with the paper review process (such as omissions and self-reviews). The centralized ICRS system is built with these primary goals over a scalable, secure framework that can be easily adapted and modified extensively to meet the demands of individual stakeholders. Unlike the previous ICRS, our product aims to satisfy the needs of the International Conference by relying on a relational database linked to an effective and secure web interface rather than relying on the comparatively insecure and unorganized system of individual email submissions.
+ The problem is an inefficient/insecure and error prone ICRS. + It affects the perceived integrity of the CoR and the Authors. + The impact of which is the decreased confidence in the CoR and an unnecessarily long review process. + A successful solution would be to set up a secure ICRS system using a relational database and a clean and efficient web interface that highlights most common tasks.
Project vision
Introduction
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
9
Stakeholders HR Department: Personnel responsible for interacting with authors and troubleshooting problems. Their responsibility is to gather feedback about the system from users and to communicate system details to all users after implementation. Research Office: As a whole, the office would like to see fewer problems with conflicts of interest and incomplete reviews (when only one review is submitted per paper instead of the required two). The office also generally wants to hold a review process that is as swift and fair as possible without compromising on quality. Their primary responsibility is to facilitate a successful review process. Event Planners: Personnel responsible for organizing and conducting the actual conference. They organize actual events based on results from ICRS system University: The University as a whole has a great stake in the success of the ICRS and the research conference as a whole as their reputation as a “renowned” university is on the line. If the conference is found to have a review process that is corrupted with conflicts of interest or other instances of tomfoolery then the reputation of the University could be hurt – and the number of people applying to its PhD programs and even funding could be lowered. This would certainly cause great harm to the University and is a scenario that the University certainly wants to strive to avoid. Marketing Department: Personnel responsible for promoting the conference. Their responsibility is to Promotes the system to potential authors Non-author spectators at the conference: The spectators of the conference that have not submitted an entry to the conference are stakeholders in that they have an expectation that the papers that have been accepted are truly top-notch papers – thus these stakeholders expect that the selection process has not been corrupted in any way. System Creators: The creators of the system want to see the system perform at or above the level it was intended to perform at and perform all of its intended duties in the most efficient manner possible. They also want the system administrator to be able to maintain the system with as little hassle as possible. Sponsors: Individuals or companies who financially support the conference. Their primary responsibility is to provide funding.
Project vision
Stakeholders
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
10
User Summary Research Chairperson: As the Research Chairperson, this person would be particularly concerned about conflicts of interest, as he/she chooses the members of the Committee of Reviewers and holds the ultimate responsibility of maintaining the integrity of the review process. Responsibilities: Ensures the integrity of the review process is maintained while overseeing the successful completion of the review by selecting the members of the research committee. Makes final decisions regarding special scenarios such as any appeals. Retains some administrator rights. Committee of Reviewers: The Committee of Reviewers primary need is to have access to the papers that they have been assigned to review while being able to submit their final scores electronically. Great care must be taken to ensure that reviewers do not receive their own papers and that each paper is reviewed twice by two distinct impartial reviewers. The reviewers will submit their findings into the system, which will average the two scores given for each paper and reveal the final score. Responsibilities: Review the papers to which they have been assigned in a given time frame impartially and submit their scores. Authors: Authors primarily need to have access to a simple to use yet effective and secure interface with which to interact and submit their papers. Authors also would like to have quick, easy and secure access to the status of their papers while the submission and review process is still underway. Responsibilities: Submit their papers to the Committee of Reviewers and wait for the final decision. Webmaster(s) and/or Administrator(s): As someone involved with the day to day maintenance of the overall ICRS, the administrator(s) would like to work with a database that is logically structured as well as a front end that is easily maintained and even changed as future needs arise. Responsibilities: Ensure that information about the conference is available on the web. Ensure that the ICRS system is properly maintained and functioning. Admin: Top level admin who monitors and updates the system. Responsibilities:Monitors system health, manages permissions for all system users, updates conference information that no one else can fix.
User Environment The vast majority of the users using the ICRS are either Committee Members or authors submitting their publications. The number of people involved in the ICRS will vary depending on the size of the conference in general and the amount of submissions the users have expressed their belief that the particular conference in question will likely continue to increase in size. The length of a given task cycle would be chosen by the Committee and the Committee Chairperson. This could change based on the will of the Chairperson and/or the Committee as a whole. The authors could theoretically be submitting their papers from anywhere as the web interface can be accessed via any standard web browser. The Committee Members, including the Chairperson of the Committee, will likely be reviewing papers and/ or interacting with the system in an office setting at the university but could also interact with the web interface via any web browser.
Project vision
User Summary / Environment
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
11
Summary of Key Stakeholders / User Needs The stakeholders and users often have overlapping needs for the ICRS. For one, they all have the primary goal of fostering a successful and fair review process where worthy papers are accepted into the conference. The consequences of a failed review process is highly destructive for all participants: The authors may not get their papers accepted, which they part a lot of hard work and time into, the reviewers may not get the papers they reviewed, which they placed effort into reading and criticizing, the University may receive bad publicity and poor attendance to the conference, the Chairperson may lose his/her job, and the Administrator becomes less credible and also can lose his/her job. Below is a brief summary of the current problems and unmet needs at a high-level along with possible opportunities for improvement in the new ICRS system. Details will be ironed out after the inception phase is completed. Problems / Unmet Needs + Submissions and reviews are all email based - Slow, Painful, Easy to lose track + No database of papers - Unpublished (not public to download - Disorganized, no historical records + Errors in assigning / reviewing papers + Difficulty handling heavy flow of submissions
Opportunities + Speed up review process - Assigning Reviewers, Submitting papers, Reviewing Papers, Publishing + Stay Organized & Fix potential mistakes + Flexibility for future improvements / changes - Allow for more applicants + Keep process well documented, easy to follow
NEED
PRIORITY
CURRENT SOLUTION
PROPOSED SOLUTION
Reliable document submission system, that maintains records of past user submissions
High
E-Mailing papers to a specified address
Efficiently distribute documents to multiple users based on a workflow process Reliable, efficient, searchable document library Ensure the confidentiality of submitted academic papers Monitoring system that allows actors to track the status of submitted documents in the workflow
High
E-Mailing papers to the appropriate user
Online submission system that simplifies the procedure and automatically initiates the appropriate workflow Fully developed CMS to automate the workflow process
High
Static Storage in file/ folder systems
High
Medium
Project vision
Needs / Opportunities
Dynamic database to index all submitted documents E-Mailing documents to Automated system that an authorized account elivates user permissions as needed User can contact a con- The workflow process ference representative will constantly update who will investigate into the status of all papers the matter. within the system, which can be relayed.
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
12
Product Features Based on our discoveries about the project requirements and goals, we have outlined a list of highlevel product features to meet the needs of all stakeholders and users. The list is not meant to be highly technical, rather it was created so that all potential stakeholders can review it, understand it, and possibly improve upon this list in the future. We may tack on product features as a result of feedback.
Authors Paper Submissions: Authors within the system can submit their academic papers via a web interface for review. The submissions system automatically generates a checklist for the author to ensure that his paper complies with the conference requirements. The system can also implement a deadline for submissions. Paper Revisions: Authors who have submitted a draft of their paper may submit a revised draft before the deadline via the website. The author is presented with a separate revision checklist and can update some or all of the documents in the original submission. The system can optionally notify any prescreeners and reviewers who may have been assigned the original draft. Document Tracking: Once the author submits the document, he can log in to the system and check the status of his report as it passes through the workflow – prescreening, review, accepted etc. Review Appeals: If an author is unsatisfied with his review, he can appeal to the committee for reevaluation by filling out a detailed online form. A major concern is that simplifying the appeal process will encourage more users to appeal for re-evaluations which leads to greater administrative overheads.
Reviewers Download Assignments: Reviewers can log in to the system and view a list of assigned papers, which they can download to their computer along with appropriate review forms and guidelines. Appeal Paper Assignments: Provides functionality wherein reviewers can appeal a paper that they have been assigned on approved grounds like conflict of interests, emergency cases etc. Online Score Reports: Reviewers can fill out online score reports which use a numeric rubric scale to grade different criteria and then the system can automatically aggregate scores from multiple reviewers and determines if the paper is accepted. This simplifies the scoring process considerably, but may not be applicable for all types of papers. Copyright Infringement Analysis: Built-in tool for checking copyright infringements. This is to ensure that paper’s with stolen content are not accepted.
Committee Chair Publishes Papers Online: The system can automatically publish papers online once they have been approved by the assigned reviewers. Alternatively, it can wait for approval from the committee chair before publishing the documents.
Project vision
Product Features
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
13
Supports Reviewer Monitoring: The committee chair can view a list of all reviewers in the system, their assignments, due dates, reports and other such information that lets them better decide which reviewers can be assigned incoming papers. They can also reassign reviewers. They essentially receive general oversight and override authority throughout the ICRS.
Shared Features Personal Profiles: May contain an index of previously submitted papers for authors, reviews for reviewers, or approved papers for committee chairs. It will also contain a short biography to know who the person is and what their background might be. This may help the research office appoint conference chairs and help committee reviewers authenticate authors. User FAQ: Helps answer common questions and difficulties of the system for all users. Supports Database Archiving: Database archiving lets the system move old records out of the main database and back them up in separate location. This can be done routinely, and helps improve the overall performance of the database. Enforces Document Standardization: The acceptable document types (e.g. pdf, doc, docx) can be specified for each individual conference, and all user submissions will have to conform to these requirements. This ensures that the submissions will be compatible with the system and with other users’ computers as well. Notification System: The notification process allows the system or high level users to send out notifications such as emails or messages within the system to a defined group of users. This simplifies the communication link between top level management such as the review committee and individual authors. Community forum: Location for all users to come and view suggestions on paper format to help improve their chances of being accepted. This may also be a place for general suggestions to improve the quality of the review system. This serves as a catch-call for what isn’t covered in the user FAQ. Process Instructions: One set of instructions will be for the author and one for the reviewer. These instructions may serve as a walk-thru for users as they begin the process of submitting and/or reviewing papers can be viewable by all parties involved. Double-blind Workflow: As part of standard procedure, the user must strip all personally identifiable information from submitted documents to avoid conflict of interests with reviewers. The system also enforces the double blind workflow by masking the origins of the document to the reviewers. Mobile Support: Crafting the front end and database such that users can find updates and perform common tasks via mobile devices with internet connection.
Project vision
Product Features
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
14
We developed the following interview questions with the objective of addressing all areas of uncertainty in a proposed ICRS system and to understand how the potential users and stakeholders would interact with such a system. Assuming the ICRS does not actually exist, we phrased the questions in such a way that any faculty member could easily relate to and understand: the general process of reviewing a series of paper submissions. 1. Describe your most recent experience reviewing a paper. How did you judge its quality? Did you read it thoroughly or skim it to get major ideas? 2. In your opinion, what would be a realistic number of papers to review per week if you needed to analyze the papers thoroughly? 3. How many people do you believe it takes to accurately judge a paper’s acceptance into a prestigious research conference? 4. How often do disputes arise between faculty members when coming to a consensus on grading a paper? 5. What tasks do you find most time consuming when reviewing papers? Are you ever late in grading papers? 6. How easy/difficult would it be to organize the distribution of grading papers among faculty for acceptance into a conference? 7. If you could assign papers to different faculty members for review, how would you delegate the different topics? What criteria would you use? 8. Have you had any negative experiences with the automation1 of everyday processes while teaching? If so, what were they? 9. How often do you seek the assistance of other faculty members when trying to assess a letter grade to a paper? 10. If there was a system that was used to manage the paper review process (involving submission, review, and acceptance decisions) for an international research conference, what features would you like to see? What difficulties would you expect to encounter?2
1
The use of computers to speed up a process by automatically iterating part of a system. When explaining this, we used the example of a teacher using blackboard to send mail to students or post an assignment. 2
This question is used as somewhat of a ‘catch-call’; although we generally wanted to avoid asking direct questions, we figured it couldn’t hurt to see their thoughts on a proposed system at the end of the interview.
Project vision
Interview Questions
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
15
Introduction We interviewed two faculty members who have requested to remain anonymous. One was a female graduate professor in the psychology department and the other a female undergraduate professor in the chemistry department. Each interview lasted approximately 40 minutes. Our goal was to discover the pain points of a paper review process or moments where the interviewees may have had difficulties interacting with either a similar system.
Results 1. Describe your most recent experience reviewing a paper. How did you judge its quality? Did you read it thoroughly or skim it to get major ideas? One of the interviewees said when reviewing material, she focused more on portions she was interested in and skimmed other portions. The other said she paid equal attention to everything because of the small amount of papers she had to review. 2. In your opinion, what would be a realistic number of papers to review per week if you needed to analyze the papers thoroughly? The range of an adequate papers to grade per week fell around 3-5 papers per week. This number will be interesting to look at when it comes to the type of assignments the ICRS will make from paper to reviewer. 3. How many people do you believe it takes to accurately judge a paper’s acceptance into a prestigious research conference? The interviewees both mentioned that 3 would be a good number of reviewers per paper because it would allow for a majority and might help settle disputes better. It seems that having 3 reviewers might also reduce the hassle of having the chairperson step in moderate a judgement. 4. How often do disputes arise between faculty members when coming to a consensus on grading a paper? The Chemistry professor mentioned that she does not often consult with other professors when grading because her peers can be overly opinionated. The Psychology professor mentioned that in depth discussions become necessary for thesis papers, and disputes arise mostly due to apposing research backgrounds. 5. What tasks do you find most time consuming when reviewing papers? Are you ever late in grading papers? Both professors have never submitted a late paper, though they both mentioned they can get hung up on a part and ask to consult the author on a specific point before coming to a final decision on the grade.
Project Vision
Interview Summary
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
16
6. How easy/difficult would it be to organize the distribution of grading papers among faculty for acceptance into a conference? They both mentioned the possibility of reviewers receiving papers with a conflict of interest. However, while one mentioned that “most people are professionals about things” and the other was more skeptical and mentioned that only in an ideal world would everyone enjoy their assigned papers. 7. If you could assign papers to different faculty members for review, how would you delegate the different topics? What criteria would you use? Both mentioned that papers should be sent to people based on expertise and research background. One expressed a concern of being cautious of disinterest and disagreements in the delegation. 8. Have you had any negative experiences with the automation1 of everyday processes while teaching? If so, what were they? One mentioned the frustration of lecture hall electronic interfaces that control the computers and projector, while the other expressed a strong dislike for blackboard. 9. How often do you seek the assistance of other faculty members when trying to assess a letter grade to a paper? There was a conflict between the two interviewees opinions. One said she typically discusses thoughts on her subject matter rather than specific papers, and the other mentioned she enjoys conferring with others but mostly her husband. 10. If there was a system that was used to manage the paper review process (involving submission, review, and acceptance decisions) for an international research conference, what features would you like to see? What difficulties would you expect to encounter? Both professors were primarily concerned with the ease-of-use factor, explaining that they don’t have time to learn new software. One also mentioned a copyright infringement checker built in would be nice.
Additional Thoughts We used this information as a way to extract features from users that have not had experience with back-end system design. For example, we found that teachers are very enthusiastic about their subject matters, so a community forum would be a great feature to the system to allow them to share their experiences with others. Our notes on these interviews can be found in the appendix.
Project Vision
Interview Summary
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
17
While the first set of questions targeted teachers with less familiarity of an ICRS, this list of questions is more aimed towards faculty with experience in system design. The answers given for these questions lead more toward precise use cases rather than having to extract use cases from concepts as we did in the first set. The difference can be summarized as theoretical vs. practical (the first is more from an HCI perspective and the second is more IS). We believe the balance of these two models leads to a more thorough system design. 1. What are the major drawbacks of the current system of document management? 2. Do you feel that a centralized CMS like the ICRS will alleviate some of these problems? Do you think it will give rise to new problems? 3. Keeping the current business process in mind, do you think it can easily be adapted to work in an online framework or will major process changes be more beneficial? 4. From a technical viewpoint, what major migration issues do you see arising from replacing the existing system with the proposed one? 5. From a people/HR perspective, do you feel there will be any difficulty in adopting the ICRS? 6. As a potential author, what security and confidentiality concerns would you like to see addressed in this system? 7. As a potential reviewer, would you suggest any changes in the current system of evaluation? 8. In terms of academic discourse, do system feature requirements vary significantly? 9. In terms of tracking and managing content, what features do you think will significantly help system users? e.g. submission dates, author contact info etc. 10. With the new system, should appeals for reviews be allowed? If yes, how do you think it should be integrated? 11. Do you think there are any special cases in the process that we need to account for? e.g. Reviewers refusing to review a paper owing to conflict of interest 12. Are there any other non-essential features that if implemented would add a great deal of value to the system?
Project vision
Interview Questions (2 Set) nd
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
18
Introduction We interviewed two faculty members from the IS department: Professor Heimann and Professor Quesenberry. We also interviewed Frank Mellage, VP of Product Development for a company called MyWebChalk – a system that facilitates effective communication between teachers, parents, and administrators to schools and colleges (similar to blackboard). Each interview lasted approximately 40 minutes. Our goal was to discover key tips and strategies for developing a committee review system from professionals with experience in systems design and development.
Results 1. What are the major drawbacks of the current system of document management? We found that most people agreed that a major risk is system integrity. If the system failed for some reason, which its sounds like it often did, the consequences were pretty drastic. Another drawback mentioned was the slow turnover rate due to inefficient distributions. 2. Do you feel that a centralized CMS like the ICRS will alleviate some of these problems? Do you think it will give rise to new problems? The general consensus was that a centralized system will alleviate most high-risk errors. Of course, there was also talk of new unanticipated problems, but interestingly enough most people viewed these problems as quickly fixable with iterative development. 3. Keeping the current business process in mind, do you think it can easily be adapted to work in an online framework or will major process changes be more beneficial? The concept of social networking and contribution was raised by Frank Mellage, and is something we initially overlooked. Essentially, allowing some source of collaboration over a forum-like interface could allow for the wisdom of crowds effect to take place, but this would be mainly if certain papers needed extensive reviews or second opinions. 4. From a technical viewpoint, what major migration issues do you see arising from replacing the existing system with the proposed one? Unanimously, our interviewees commented on the difficulties of transferring old information into the new database. 5. From a people/HR perspective, do you feel there will be any difficulty in adopting the ICRS? Professor Heimann made an interesting point that word of mouth of a successful system along with proof of time performance increase and cost reduction will remove most difficulties. 6. As a potential author, what security and confidentiality concerns would you like to see addressed in this system? Mostly the potential concern for having papers unfairly judged or distributed outweighed security issues from the system.
Project Vision
Interview Summary (2 Set) nd
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
19
7. As a potential reviewer, would you suggest any changes in the current system of evaluation? One of the useful suggestions from the interviewees was that of that electronic alerts to remain aware of conference news and adjustments. It is important to note here that most suggestions were already covered by just including a database. 8. In terms of academic discourse, do system feature requirements vary significantly? Generally we found that the requirements should not vary enough to require a fundamental adjustment to the system design. 9. In terms of tracking and managing content, what features do you think will significantly help system users? e.g. submission dates, author contact info etc. Most interviewees suggested the implementation of automatic updates. 10. With the new system, should appeals for reviews be allowed? If yes, how do you think it should be integrated? The majority agreed that appeals should be permitted. One of the three, however, suggested that the system should allocate proper reviewers to avoid the scenario to begin with. We side with the other two because you can never guarantee a perfect distribution of reviews. 11. Do you think there are any special cases in the process that we need to account for? e.g. Reviewers refusing to review a paper owing to conflict of interest Frank Mellage presented the idea that the system must indicate red flags when reviewers are assigned indicating a possible conflict. Mellage continued to explain that this situation can be handled in multiple ways including immediate redistribution, and proper conditional statements to prevent initial occurrences. 12. Are there any other non-essential features that if implemented would add a great deal of value to the system? Insight was given on adding features like conference information, announcements, schedules, and more could all be made available in a database. The possibility of mobile access was brought up by Professor Quesenberry because of its appeal to the modern business world.
Additional Thoughts Many of the interviewees ranted about features they thought would be most useful, which wasted a lot of interview time. However, we also were able to learn the consequence of poor system design and the high cost of user frustration, which ultimately helped us recognize the need to slow down and constantly evaluate progress. Our notes on these interviews can be found in the appendix.
Project Vision
Interview Summary (2 Set) nd
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
20
Functional Requirements
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
21
Introduction This Use Case Model Survey is a brief description, at a high level, of the functionality of the ICRS system.
System Level Actors Administrator: Extends User. The administrator is generally concerned with the upkeep of the system including database management and front-end support. The administrator has general knowledge of the technology, but does not necessarily have expertise of the process of the International Research Conference. Author: Extends User. Authors primarily need to submit their papers by interacting with the simple yet effective and secure interface of the ICRS system. Authors would like to have quick, easy and secure access to the status of their papers during the submission and review process. Committee Chair: Extends User. (Figure out if extends reviewer) The Committee Chair carries out managerial administrative functions and shares the concerns of the research office as a whole. The Committee Chair would be particularly concerned about conflicts of interest, as he/she chooses the members of the Committee of Reviewers and holds the ultimate responsibility of maintaining the integrity of the review process. Reviewer: Extends User. The Committee of Reviewers primarily need to have access to the papers that they have been assigned to review while being able to submit their final scores electronically. User: Any external entity that interacts with the ICRS. The user represents the base case for which all stem level actors build upon.
System Level Use Cases / Diagram Immediately following this page is a diagram that contains all of the actors listed above and shows their interactions with the information system at hand. This diagram was created to help understand the process of the ICRS at a high-level, and to help visualize each of the use cases. When creating the use cases, we were very cautious of possible overlaps. We made sure that each use case was unique rather then being simply extensions of one primary use case. Lastly, the exceptions for the detailed scenarios do not repeat each other. That is, the process of changing a password is the same for both the author and reviewer so we didn’t waste time repeating this. We also chose to list two exceptions for each that we felt were important. Note: The Use Case Diagram does not show all of the use cases as there were too many to fit. Instead, the most important (high risk) cases are shown.
F un c t i o n a l Requ i r emen t s
Use Case Model Survey
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
22
A
A A
A
up
pe pa
rs
s paper
s ck
tatu
Authors Anyone who submits a paper to the conference
load
ch e
e
A
ex ch an g
A
at
a
s
Database Index of all of the submissions
d
bug fixes
s
de l eg at es
p
up loa
o rt
ICRS Web Interface Site where user logins are created and place to upload, access, and modify information
e ap
Administor Oversees technical issues of the system
ds w vie re
oversees and m onito rs a ll a cti vi
ty
M
r ts r ep o l is ica hn t ec
su
R C
es
chooses committee
Chairperson In charge of facilitating a successful review process
F un c t i o n a l Requ i r emen t s
User Flow Model
R
R A
R R
R
A
Reviewers Can also be authors, but cannot review their own submission
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
23
International Conference Review System
System boundary U Authenticate User
<< extend >> unrecognized us er
Authentication Failed
User View Conference Information
<< inc lud e> >
>> ude incl <<
<< ext unf end air >> rev iew Check Status of Review
A
Handle Database Failure
C
Verify Paper Submission
Notify Failed Submission
M
Admin
Update Conference Info
Send Error Notification
Appeal Decision
Review Error Reports
Committee Chair
Authors Submit Paper
Request Extension
Upload Review
<< ex ten bia d> se > dr ev iew
F un c t i o n a l Requ i r emen t s
Use Case Diagram
Submission Flagged
<< include >>
Receives Paper Assignment
Read Reviews >> clude << in
Reviewers
Download Paper
d >> xten n << e issio subm late
R
Authorizes Publishing
View Submissions Requests Assignment Change
Assign Reviewers
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
24
Appeal Decision An author checks paper status and under special circumstances, feels that his or her paper should be reconsidered though the committeeâ&#x20AC;&#x2122;s decision has been rendered. Author sends request to committee outlining why his or her submission should be reconsidered. System then sends request for appeal to the committee.
Assign Reviewers Committee chair authenticates into the ICRS. Committee chair downloads paper from the database and verifies paper submission. Committee chair views profiles of individual reviewers and makes selection of review committee for the submitted paper. System uploads assignment information to the database and notifies all the relevant actors.
Assign scores online The reviewer authenticates into the ICRS and accesses the assigned paper. Reviewer completes his/ her review and accesses the review page from the web interface. Reviewer assigns scores for the paper and the review is saved in the database.
Authentication Fails If a user tries to access the system (authenticate user) using the wrong username or password, it leads to a failed authentication. We may also specify a maximum number of times a user is allowed to attempt logging into the system.
Authenticate User Any user can request entry to the system. To access system features, they user must prove they are who they say they are.
Authorize Publishing Committee Chair authenticates into the ICRS. Committee Chair reviews accepted papers to make sure no inappropriate/incomplete papers have been accepted. Committee chair approves publishing of accepted papers and system sends publishing information to the relevant actors.
Cancel Conference Administrator may have to cancel the conference due to weather or scheduling conflicts. Administrator authenticates into the ICRS and accesses the information about all conferences. Administrator selects particular conference and cancels it. ICRS notifies all the relevant actors.
Change User Permissions Administrator authenticates into the ICRS. Administrator gets information about user roles from the database. Administrator makes changes as necessary and new information is uploaded back to the database.
F un c t i o n a l Requ i r emen t s
Use Cases
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
25
Check Paper Status The author authenticates into the ICRS. Author selects ‘Check Status’ for their paper submission. Author observes the current status of his/her paper to his/her satisfaction.
Check status Committee chair authenticates into the ICRS. Committee chair views index of all papers. Committee chair looks for potential problems with submissions or reviews and notifies relevant actors.
Create Account The user accesses the registration page on the website and enters information such as name, address, and other personal information. The user may also need to indicate other information as defined by the committee chair. The information is then saved to the database.
Download Paper Administrator or committee chair or reviewer authenticate into ICRS. They access index of submitted papers and click on ‘Download’ to download the paper.
Execute conference reports Committee chair authenticates into the ICRS. Committee chair selects information to be included in the report. Database processes the request and returns the relevant report.
Get Web Interface Failure Notification Any user identifies a fatal flaw with the web interface. The user authenticates into the ICRS and sends error notification. The system sends the notification to the administrator and administrator makes decision about resolving the issue.
Handle Database Failure Administrator is notified of/identifies a catastrophic failure with the database. The administrator notifies the committee chair. The administrator attempts to further diagnose the issue until the best possible resolution has been reached. The administrator consults with the committee chair and the resolution is implemented.
Handles fraudulent paper notification Committee chair authenticates into the ICRS. Committee chair receives email from reviewer. Committee chair discovers author has committed copyright infringement. Committee chair notifies author/reviewer and requests a meeting. Committee chair makes appropriate decision as to legal ramifications.
Monitor System Administrator authenticates into the ICRS. Administrator looks up information about system health and usage logs to ensure system functionality.
F un c t i o n a l Requ i r emen t s
Use Cases
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
26
Notify Failed Submission An author has tried and failed to submit a paper to the system after authenticating. The author selects the “report submission issues” option from the web interface and sends error notification.
Read Review Committee Chair or Administrator view submissions. Committee chair or administrator clicks on ‘View Reviews’ to access index of all reviews for a particular paper. Committee chair or author downloads the review to read it.
Receive Paper Assignment Reviewer authenticates into the ICRS system. Reviewer clicks on ‘View Assignment’ to access list of papers he has been assigned to review.
Request Assignment Change Reviewer receives paper assignment. Reviewer recognizes any reason that he/she feels that he/ she should not review a particular submission. The reviewer sends a request to the committee chair outlining his/her reasons for requesting an alternate paper assignment. System sends the appeal to the committee chair for consideration.
Request Extension An author or a reviewer, under special circumstances, feels that his or her paper or review should be considered though the deadline for submission has passed. The author or reviewer sends a request to the committee chair outlining why his or her submission should be reviewed despite the deadline. Committee Chair makes decision and the system notifies author or reviewer of the chair’s decision.
Request Publication Notification In the case that a paper a reviewer evaluated is accepted, he may want to get the publication information. Reviewer authenticates into the ICRS. Reviewer accesses index of accepted papers and selects a particular paper. Database accesses the publishing information and displays it to the reviewer.
Review Error Reports Any user sends error notification. Administrator receives error report and responds to it making suggestions as necessary.
Review Paper The reviewer authenticates into the ICRS. Reviewer downloads paper. Reviewer completes his/her review of the paper and uploads the review to the system indicating the score of the paper.
Send Error Notification Any user interacting with the system recognizes an error while interaction with the system. The user enters an error report and system sends the report to administrator.
F un c t i o n a l Requ i r emen t s
Use Cases
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
27
Set initial conference parameters Committee chair or Administrator authenticates into the ICRS. Committee chair initializes conference set-up wizard and is assigned a system administrator. Administrator works with committee chair to determine conference requirements. Committee chair fills out conference wizard accordingly. Committee chair uploads database of contact information for all committee members and potential authors. System sends notifications to all the relevant actors.
Submit Late Review The reviewer completes review of a paper several days after completion date. Reviewer authenticates into the ICRS. Reviewer submits review. Reviewer receives email notification that the review is flagged as late and takes note that the review may not be accepted.
Submit Paper The author authenticates into the ICRS. Author uploads a submission. System adds the submission to the database. Database notifies author and committee chair about submission.
Track Workflow Metrics Committee chair authenticates into the ICRS. Committee chair accesses tracking page and selects the type of metrics he wants to track. Database processes his or her request and displays the relevant information.
Update Conference Information Administrator or Committee Chair authenticates into the ICRS system. Administrator/Committee Chair gets information about a particular conference from the database. Administrator/Committee Chair makes changes as necessary and new information is uploaded back to the database.
Verify Paper Submission Committee Chair authenticates into the ICRS. Committee chair accesses paper and submission requirements and makes sure the submission satisfies the requirements. Committee Chair logs final decision into the database.
View Conference Information The user accesses the conference page to get information about the conference such as deadlines and location. The information is then accessed from the database and displayed to the user.
View Submissions Committee chair or Administrator authenticate into ICRS. Committee chair/administrator view index of submissions and download paper.
F un c t i o n a l Requ i r emen t s
Use Cases
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
28
Review Paper Scope: ICRS System Level: user goal Primary Actor: Reviewer
Preconditions Reviewer has created an account and has received paper assignment.
Postconditions Reviewer has submitted his/her findings and the author has been sent the proper notification.
Basic Flow of Events 1. Reviewer authenticates into the ICRS system (Authenticate user). 2. Reviewer downloads paper. 3. Reviewer completes his/her review of the paper. 4. Reviewer uploads his/her review score for the paper into the database.
Alternate Flow of Events Alternative 1: Reviewer forgets password In step 1, 1a. Reviewer forgets the password. 1b. Reviewer uses the password-reset feature to reset his/her password. 1c. Reviewer authenticates using the randomly generated password. 1d. Reviewer changes his password and uses new password to authenticate into the ICRS system. Processing returns to step 2. Alternative 2: Database Failure In step 1, 1a. Reviewer observes a SQL error upon authentication. The error recommends contacting an administrator. 1b. Reviewer sends error notification. 1c. Administrator notifies the committee of the error and posts a notice on the web front-end interface. 1d. Administrator resolves the database error and system functionality is restored. 1e. Administrator restores the front-end to its normal state. 1f. Administrator sends notification to reviewers that the ICRS system is now functional. Processing returns to step 1.
F un c t i o n a l Requ i r emen t s
Fully Dressed Use Case 1
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
29
Assign Reviewers Scope: ICRS System Level: user goal Primary Actor: Committee Chair
Preconditions Author has submitted the paper for review according to the submission guidelines outlined in the web interface.
Postconditions Database stores reviewer information and the system notifies the selected reviewers.
Basic Flow of Events 1. Committee chair authenticates into ICRS (Authenticate user). 2. Committee chair downloads paper. 3. Committee chair verifies paper submission 4. Committee chair views profiles of individual reviewers. 5. Committee chair selects 2 or more reviewers. 6. System uploads assignment information to the database. 7. System sends notification to the reviewers.
Alternate Flow of Events Alternative 1: Submitted paper doesn’t meet submission requirements. In step 3, 3a. Committee chair recognizes that the submitted paper doesn’t meet the submission requirements. 3b. Committee chair emails author outlining why the paper wasn’t approved. 3c. Author receives feedback and fixes the paper accordingly. 3d. Author submits paper again. Processing returns to step 3.
F un c t i o n a l Requ i r emen t s
Fully Dressed Use Case 2
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
30
Submit Paper Scope: ICRS System Level: User goal Primary Actor: Author Preconditions 1. Author has written a paper that generally meets the requirements of a typical submission. 2. Author has interacted with a computer before and understands basic interaction principles.
Postconditions Author receives notification confirming submission to the database.
Basic Flow of Events 1. Author authenticates into ICRS (Authenticate user). 2. Author selects conference. 3. Author uploads a submission. 4. System adds submission to the database. 5. Database stores the paper and sends a notification to the author and committee chair.
Alternate Flow of Events Alternative 1: Improper File Size/Type of Submission In step 3, 3a. Author receives error of improper file size (database can only handle so much) or improper file type (doc or pdf only). 3b. Author is directed to information or FAQ on how to submit a proper file. 3c. Author adjusts the file. Processing returns to step 3.
F un c t i o n a l Requ i r emen t s
Fully Dressed Use Case 3
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
31
View Conference Information Scope: ICRS System Level: User goal Primary Actor: User Preconditions User has authenticated into ICRS.
Postconditions User views conference information.
Basic Flow of Events 1. User starts by specifying the search criteria: conference name, conference topic or location. 2. The system displays a list of related conferences or no results if no conference matches the search criteria.
Alternate Flow of Events User wants to specify search criteria. In step 1, 3a. User clicks on â&#x20AC;&#x2DC;Advanced Searchâ&#x20AC;&#x2122; 3b. User specifies specific search criteria. Processing returns to step 2.
F un c t i o n a l Requ i r emen t s
Fully Dressed Use Case 4
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
32
Check Paper Status Scope: ICRS System Level: User goal Primary Actor: Author Preconditions Author has submitted the paper for review.
Postconditions Author views paper status to his/her satisfaction.
Basic Flow of Events 1. Author authenticates into ICRS (Authenticate user). 2. Author views lists of submitted papers. 3. Author selects a paper to see its status. 4. System accesses database to get paper status. 5. System displays paper status to author.
Alternate Flow of Events Alternative 1: Status is not available. In step 4, 4a. System is unable to get paper status. 4b. System displays â&#x20AC;&#x2DC;Status Unavailableâ&#x20AC;&#x2122; notification. 4c. Author sends error notification. 4d. Administrator reviews error report. Processing returns to step 3.
F un c t i o n a l Requ i r emen t s
Fully Dressed Use Case 5
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
33
Authorize Publishing Scope: ICRS System Level: User goal Primary Actor: User Preconditions Paper has been given favorable reviews by reviewers and accepted for publishing.
Postconditions Paper is published.
Basic Flow of Events 1. Committee chair authenticates into ICRS (Authenticate user). 2. Committee chair views index of accepted papers. 3. Committee chair selects a paper to authorize publishing. 4. Committee chair reviews paper to make sure no inappropriate/incomplete papers have been accepted. 5. Committee chair approves publishing of paper 6. System uploads decision and sends notification to the author.
Alternate Flow of Events Alternative 1: Committee chair finds that inappropriate papers have been accepted. In step 4, 4a. Committee chair finds that paper contains inappropriate/incomplete content. 4b. Committee chair notifies reviewers and authors. 4c. Author fixes paper and sends it back to committee chair. Processing returns to step 4.
F un c t i o n a l Requ i r emen t s
Fully Dressed Use Case 6
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
34
Create Account Scope: ICRS System Level: User goal Primary Actor: User Preconditions User has an Internet connection and can access the ICRS website.
Postconditions User receives notification confirming account creation.
Basic Flow of Events 1. User clicks on ‘Create Account’. 2. User fills out account information. 3. User selects type of account. 4. User clicks ‘Submit’. 5. System verifies user information. 6. System confirms creation of account. 7. System sends notification to the user.
Alternate Flow of Events Alternative 1: User enters invalid information. In step 5, 5a. System displays ‘Invalid Information’ notification. 5b. System displays ‘Create Account’ page with invalid information highlighted. Processing returns to step 2.
F un c t i o n a l Requ i r emen t s
Fully Dressed Use Case 7
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
35
Supplementary Specifications
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
36
Supplementary Specs This paper is designed to outline all specifications of the ICRS that have not been specifically outlined (or those that we feel require significant elaboration as supplementary features) in use cases. There were some features that were initially proposed as a part of the ICRS, but were determined to be medium or low priority tasks, based on the requirements of our stakeholders. These features are outlined in some detail below, along with potential uses.
Chairperson/Administrator Rights Our system is designed to enable the Chairperson to exercise his or her oversight authority over the entire process. The Chairperson will be able to grant exceptions to any set deadline if he/she decides that this is possible. The Chairperson will also be able to set the system to automatically assign reviewers based on a list of parameters while retaining override authority. (Functionality may be added/ removed here in future iterations)
Security The security of the papers is of utmost importance as many may contain proprietary information and/ or potential future patents or copyrights. The protection of the intellectual property of the Authors is a priority and as such the database as well as all systems directly linked to the database will be secured properly. All data exchanges from the database as well as user interaction with the web interface (both during and after authentication) will be secure.
Data Redundancy/Backup Secure and reliable database backups will be kept in order to facilitate a speedy recovery in the event of a natural disaster, power failure or any other event that has the potential to cause catastrophic data loss. An ideally 1:1 database backup will be maintained by the administrator (ideally off-site). This backup database will be equally or more secure than the main database.
Document Conversion The system can support conversions between certain compatible document types, since different actors benefit from using different formats. For instance, submissions may be in DOC, but a reviewer may prefer to receive a PDF which is locked and cannot be accidentally modified unlike a DOC file.
Usage & System Statistics The system can also monitor usage statistics like number of registered users, number of submissions and other relevant data which give an indication of user trends and requirements. System statistics can also be used to monitor how a system is performing, and to troubleshoot various issues. Such statistics let developers get a feel for what the users want and what the users would most benefit from, which could be implemented in a newer product version.
Supplementary Specs
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
37
Reminder Functionality Can automate generate reminders on the notification system for reviewers and registered authors about submission deadlines. This would greatly reduce the monitoring responsibilities of the committee, since they do not need to constantly supervise reviewers. Reminders would be delivered inside the system, as well as externally via email for convenience.
Certificate Creation When an author’s paper becomes entered into the system as a published paper, it would be interesting if a pdf certificate could be generated based on the committee chair’s approval. Additionally, this certificate could be for the committee chair to print out and mail to the authors’ addresses as listed in their user profiles.
User Forum Location for all users to come and view suggestions on paper format to help improve their chances of being accepted. This may also be a place for general suggestions to improve the quality of the review system. This serves as a catch-call for what isn’t covered in the user FAQ.
User Profiles As listed in the product features, it would be beneficial to have a user profile system so that user accounts could be more than just a way to access the system for one conference. Statistics could be tracked as mentioned in the previously, but in more effective ways with status indicators demonstrating efficient users. For example, a user who has been particularly active in the system could have five stars shown next to his/her user profile.
Supplementary Specs
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
38
System Models
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
39
* Author
Reviewer
1
1
submitsPaper
reviewsPaper assigns
1
1..*
Paper
Review
Author Date Length Category Status 1..*
1
2
Average Score [1..5] Description Reviewer
1..*
1 1
approvesPaper
Chairperson 1
addToConference setsUp / modify Conference 1
Domain Model
Title Category Max Papers Accepted Date Due
1
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
40
User Conference
user_id : int password : string firstname : string lastname : string email : string is_author : boolean is_reviewer : boolean is_chair : boolean
Score id : int review_id : int relevance : int writing_quality : int originality : int research_quality : int literature_quality : int
1..*
chairperson_id : int due_date : int max_papers : int
has
Reviewer
Author
Chairperson
id : int user_id : int reviews : Array
id : int user_id : int papers : Array
id : int user_id : int selections : Array
1
1
1
submits
writes
Paper
1..* Review id : int paper_id : int reviewer_id : int score_id : int
contains
contains
1
2
has
1..*
date : dateTime 1 author_id : int pageLength : int is_published : boolean is_accepted : boolean
* Conference Papers threshold : float max_accepted : int accepted : int
1 has
1 Review Description average_score : float comments : string
Design Model
<<interface>> Submission user_id : int date : dateTime
has
1 Paper Description description : string category : string
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
41
Users (user_id, user_id, first_name, last_name, email, username, password, is_author?, is_reviewer?, is_chair?) Authors (author_id, user_id) Administrators (administrator_id, user_id) CommitteeChairs (committee_chair_id, user_id) Reviewers (reviewer_id, user_id) Papers (paper_id, topic, pagelength, format, date, is_submitted?, is_accepted?, is_appealed?, is_ exempted?, is_verified?, is_published?) PaperRegistrations (paper_registrations_id, author_id, paper_id) Review (review_id, paper_id, reviewer_id, score, relevance, writing_quality, originality, research_quality, literature_quality, status) Conferences (conference_id, address_id, name) Address (address_id, address line 1, city, state, zip_code) ConferenceRegistrations (conference_registration_id, user_id, conference_id)
Data Model
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
42
Project Management
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
43
Deliverable One Revision History / Time Accounting We both worked together during each of the meetings listed to ensure an equal work distribution. D ATE T I M E
P U R P O S E
A CCO M P L I S H E D
10/5 7pm - 10pm P2 Discussion
Spent about 3 hours at a whiteboard clarifying tasks and goals and identifying an initial plan.
10/8 10pm - 12am P1 Comparison
Outlined key differences between our approaches in phase 1. Made a list of important discrepancies.
10/10 9am - 11am
Specific Use-case Reviewed and refined architecturally significant use cases; Comparison those containing high risk and high business value.
10/13 5pm - 8pm
Requirements Workshop
10/15 3pm - 5pm Iteration Planning
Documented important software requirements based on previous use case analysis and feedback. Began refined project vision to clarify scope. Identified a consistent iteration plan moving forward to gain useful feedback.
10/17 6pm - 8pm Polished Actors, We carefully analyzed work from phase 1 and agreed upon Use Cases, etc,. final decisions for appropriate naming conventions. This also involved revising fully dressed use cases. 10/18 5pm - 7:30pm
Iteration Phase Revisions
We double-checked our time estimates and project reqs for each of the time-fixed iterations.
10/19 12:30pm - 3pm Initial Domain Modeling
We sat at a whiteboard and drafted a few domain models to understand how they work and to come to conclusions on what is most helpful.
10/21 1pm - 3:30pm Initial UI Discussion
Using the same tactics as we did for storyboards on the 19th, we sat down for a few hours to tackle first drafts of UI prototypes to be used in the next elaboration phase.
10/22 5pm - 6pm Reviewed P1 Gradings
We spent an hour reviewing our respective grades from phase 1 so that we can revise our work and learn from our mistakes.
10/24 4pm - 5:45pm
Data Modeling
We created initial data models from what we learned in 272 and then refined them based on brief feedback.
10/27 7pm - 2am
Detailed Use Cases
Polished and finalized our eight fully dressed use cases based on our prioritized business risk analysis.
10/31 5pm - 6:30pm
Design Modeling
We created artifacts in the design model while using the GRASP patterns to ensure no violations.
11/2
8:30pm - 12am Finalized project
p r o j e c t m a n a gemen t
Time Accounting
Produced finishing touches and modifications.
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
44
Problem Analysis Interview Questions We encountered initial challenges defining the scope of our interview questions and how broad-based they should be. We wanted to make sure that we got the most out of the faculty members’ time as possible. It was definitely a struggle to get them to look deep down and discover their pain points, but we worked together well and were able to push through the barriers by working together.
Use Cases We had initial challenges coming up with a final list of use cases. We needed to have a long discussion about what the use cases should contain, and while we had different opinions initially, we worked through our differences and came to a comprimise that we were both satisfied with. *
Supplemental Specifications We had some initial trouble compiling an accurate list of supplemental specifications. *
Iteration Plans We had a good grasp of UP principles but needed to review Chapter 8 of Larman in order to create realistic and proper iterations. *
Scheduling We both had very rigorous schedules and needed to find times that worked around that. We used email as our primary tool to figure out times, and also periodically called each other when we had spare moments. We hope that future phases are smoother in terms of finding a standard meeting time. This would help us stay more organized in the future.
Potential Future Problems 1. Focusing on core features: the UP process emphasizes the importance of iterative development of the core features before supplementary features are implemented. While we are well aware of this aspect of UP development, potential deviation from this process is cause for concern. 2. Unforeseen delays: Sudden Illness, natural disasters and any number of potential accidents could set back or otherwise compromise the feasibility of the project.
Overall We worked together very well. We were able to figure out eachother’s strengths and weaknesses and work around them accordingly. We are both pleased with the progress so far and look forward to creating a well structured design for this project in the near future.
* - “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development” by Craig Larman served as a helpful guide for these problems
p r o j e c t m a n a gemen t
Problem Analysis
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
45
Appendix
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
46
Interview 1: Psychology Professor
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
47
Interview 1: Psychology Professor (Continued)
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
48
Interview 2: Chemistry Professor
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
49
Interview 3: Professor Quesenberry
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
50
Interview 3: Professor Quesenberry (Continued)
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
51
Interview 4: Professor Heimann
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
52
Interview 4: Professor Heimann (Continued)
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
53
Interview 5 – Frank Mellage, VP of Product Development, MyWebChalk 1. What are the major drawbacks of the current system of document management? To me the major drawback is the lack of system integrity. A person who submits a paper currently could be rejected because the system failed. The submitter has missed an opportunity for recognition and also the benefit of expert review of their ideas. It is critical that this not happen. It will dramatically effect the reputation of the conference. 2. Do you feel that a centralized CMS like the ICRS will alleviate some of these problems? Do you think it will give rise to new problems? I think the centralized system and the associated controls will address most of these problems. I’m sure their will be new unanticipated problems but these should be corrected during a system shakedown period. The current system should operate in parallel with the new system until it is working 100%. 3. Keeping the current business process in mind, do you think it can easily be adapted to work in an online framework or will major process changes be more beneficial? I think it can easily be adapted to an online framework. The one change to the process I would recommend is that reviewers have the opportunity to collaborate if they wish to on the review of a paper. This could be scheduled and the meeting could be done over the web and be integrated with the system. 4. From a technical viewpoint, what major migration issues do you see arising from replacing the existing system with the proposed one? I think the major issue is importing the current information or database to the new system. 5. From a people/HR perspective, do you feel there will be any difficulty in adopting the ICRS? I don’t think so – conference attendees, presenters, etc..expect an automated system today not only one that is web based but one that can be adapted to their lap top or Blackberry type device. 6. As a potential author, what security and confidentiality concerns would you like to see addressed in this system? I would want to be ensured that my paper if selected was protected from unauthorized access. Also if not selected that the fact that it was not selected is kept confidential. Also I would want assurances that all copyright, patents etc..are noted and protected.
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
54
Interview 5 â&#x20AC;&#x201C; Frank Mellage (Continued) 7. As a potential reviewer, would you suggest any changes in the current system of evaluation? Yes -- I would ask that alerts be sent to me electronically to keep me aware of deadlines and other conference news. 8. In terms of academic discourse, do system feature requirements vary significantly? This question did not apply to our interviewee. 9. In terms of tracking and managing content, what features do you think will significantly help ystem users? e.g. submission dates, author contact info etc. All of the above would be beneficial. Automated alerts as indicated above would be a very important feature. 10. With the new system, should appeals for reviews be allowed? If yes, how do you think it should be integrated? With an automated web based system â&#x20AC;&#x201C; it would become practical to implement an appeal process and to have the author and reviewers come together electronically. 11. Do you think there are any special cases in the process that we need to account for? e.g. Reviewers refusing to review a paper owing to conflict of interest With a good reviewer database the system should be able to present red flags when reviewers are assigned indicating a possible conflict. Another reviewer then can be selected if deemed necessary. 12. Are there any other non-essential features that if implemented would add a great deal of value to the system? Yes. Features could be developed to make the conference itself a better experience for attendees. All conference information, announcements, schedules, room locations, times, Birds of a Feather sessions etc..could all be made available in a database. The database should be accessible via the web on a Blackberry type device. It would greatly improve the conference experience and potentially have the added benefit of reducing conference staff.
APPENDIX
Interview Notes
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
55
APPENDIX
Model Scrapwork
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
56
APPENDIX
Polishing Models
Sachit Gupta, Noah Levin Project 1 :: 67-371 :: Fall 2008
57