Project 2
Student id: b11
To select another student or project, return to the Project Page.
Title: Project 2: Feasibility Study
Author: Seth Bakes
Date:
Revamping MyNEU COOL
Seth Bakes
09 August 2016
Table of Contents
- Executive Summary
- Preliminary Requirements Analysis
- A. Objectives
- B. Rules
- C. Interactions with existing infrastructure
- Success Criteria
- Cost Estimates
- A. Developers
- B. Hardware
- Reporting Outline
- Risk Analysis
- Conclusion
Executive Summary
Northeastern University is well known for our exceptional co-op program. As it stands, we are not representing this program well[i.n.]. The purpose of this project is to create a new web portal to replace the current MyNEU COOL. As student here at Northeastern University I am wholly committed to this project and believe it can be done in a reasonable time frame. Here is why: What we're talking about here is mostly changing the interface and I believe the back end usability is already present, it is just not utilized. There are few limitations to the project with the major limitation being reliable co-op position liaisons and tangible benefits for participants, but this is outside of the feasibility of the application itself, and more related to general improvements. The revamping of our web portal will put a new face on the NEU co-op search process and encourage our students to use the service, in turn yielding more support for our student feedback database and overall improvements to the co-op process on the faculty and student end.
Preliminary requirements analysis
Co-op Search Improvements: The primary objective of this project is to improve the overall quality of the co-op search process. This process is undertaken by the overwhelming majority of students, making this a very visible improvement on the part of the university. The goal is in part to increase user feedback, make the process easier and more intuitive, overall replace and improve what is generally considered a poor service.
Experiential Learning: As students of the University, this project will help provide valuable development experience to multiple students. This includes students from different majors collaborating for a full cross discipline project. This exemplifies Northeastern's experiential learning goals[i.n.], and creates student involvement.
Graphic Identity: The design and implementation of this web portal will uphold Northeastern University's expectations for colors, logos, and branding. The primary colors used will be Northeastern Red (CC0000), Warm Grey 11 (615445), and Black (000000), along with the thematic Northeastern header standard on all digital front end space.
Existing myNEU COOL: This portal will require all of the previous information in the system to work. This includes the current list of jobs, all archived jobs, all student reviews, and all stored student coop history, in whatever format the database uses. This is[i.n.] make transition rather seamless, and allow for users to keep the information they are accustomed too. The goal here is to prevent users from having to relearn a new system, rather they will immediately know how to use it.
Success criteria
User Interactions
- Seamless Transition: Our new web portal must be able to utilize all of the existing MyNEU COOL data. This includes co-op reviews, individual user preferences, and just the list of jobs itself. These aspects of COOL will not be changed, so that users experience no loss of the past functionality.
- Improved Feedback: The web portal will only be considered a success if feedback from students and faculty shows an improved satisfaction. This includes not only improved levels of student feedback within the system (co-op reviews) but also of the overall sentiment towards the service.[i.n.]
- Interactions with existing Systems: [i.n.]This Web Portal must integrate with the existing database models supporting MyNEU COOL. The only back end changes deemed acceptable are those aimed at improving database interactionary tools on the user end. This may include changing the type of database used, but all the data will have to be migrated.
- Improved navigability and New Features: The new MyNEU web Portal will allow for new ways to interact with the co-op database, and make it more straight forward to use the existing filters. On top of adding new filters, the web portal will have a new feedback system.
Cost Estimates
Developers: The project's main cost will be the wage of[i.n.] 5 Northeastern University Students. They will be paid a negotiable group[i.n.] upon beginning the project, and another upon successful implementation and approval of their web portal.
Hardware: The project's implementation may require new or updated hardware. This is yet to be determined, but every effort will be made to use the existing hardware.
Report
Risk Analysis
Conclusion
The project is feasible. All of the students working on it have web development experience and with the provided time frame of three months we are fully confident that this project can be completed, on time. The addition of student feedback throughout the process increases our ability to create the ideal improvements, securing the valuable student approval[i.n.]. We are also provided[i.n.] in-depth views for NEU staff and increasing our availability for feedback.
The only condition is that our time line not be shortened. This time line is already short for a standard web package development, and any attempts to rush the product compromise the result. That being said, the team is confident it can be delivered on time on the condition that new hardware is not needed to host the service. In the event that we need to purchase new hardware the time line may be increased, or we can look into external hosting.
In summary, this project will provide Northeastern University with a valuable student experiential learning program and improve a widely used service. It is no secret that our current co-op database (MyNEU COOL) is antiquated, and student feedback is very low. By developing a replacement web portal and migrating all of the current data, we can improve that service without losing any aspect of the service that students are accustomed too. By minimizing changes to the current system's under workings and instead "re-skinning" it, we can avoid a costly experience, and utilize our current system in the improvement.
Peer review
This is a feasibility report on redoing the myNEU COOL co-op web application. It is a response to student's negative opinions of the current application which is in need of an overhaul. I think that my main issue is the lack of any feasibility section. I see requirements and success criteria, but I don't see anything analyzing the actual feasibility of the project. The feasibility is touched upon in different sections like requirements and success criteria so a main feasibility section may feel redundant to you. Should the elements that make it feasible be explicitly layed out or should the reader be able to infer based on the requirements? We have a page type="fsb" where one could list the different types of feasibility examined and this is what I used. I think that this is one of the most important sections where you can convince readers why it is feasible or not depending on the current financial situation or current technical abilities of the students. A quick fix that I think you could add would be to add a subtitle of Feasibility Report to the title page. Another simple fix: Table of Contents under Cost Estimate says Programmers but the section title is Developers. One thing that I like in your report is how everything seems to be bulleted or within sections rather than in paragraphs. It makes the sections that you are highlighting stand out and your point is clearly conveyed. In the executive summary, you say that as a software student, you're fully committed to the project and think that it could get done in a reasonable time frame. Reading from the outside this kind of seems like there could be some bias in the paper. With yourself being committed to the project, it could seem like you would maybe want to over or under-represent the facts to make it seem like the project is more feasible than it actually is. Perhaps a less personal approach to the paper would make sense. In the reporting section, we may want to ask Kevin to add dates for the different "tmln" elements, as they don't show up on the formatted document. Also, we may want to ask Kevin to allow multiple "reqt_sect" elements in the Success criteria section, as Oxygen is saying your second one isn't valid.
Instructor Note
This looks really nice. Obviously for a genre as extensive as the feasibility report, there is always more you can say/do. For example, how do you know that student sentiment is low? Could you devise a survey for pre- and post-project? Are there exemplary systems at other institutions or in the private sector (thinking of the many job sites) that can provide guidance for functionality? On the whole, though, I think you do a nice job here. I did note above a few moments that could mostly be eliminated through more careful proofreading.