Project Summary

Client: Carley Foundry

Project Description: To rebuild an existing piece of software known as QA Display for Carley Foundry.  The system tracks build instructions for tens of thousands of parts that Carley Foundry builds on behalf of their clients.  Our task is to develop a completely new piece of software that will replace their existing software, add some functionality, and give it an improved design/interface.  The Carley staff would also like to re-categorize the organization of their processes and departments as we build this new software.  Thus, after redeveloping the software, the client will set up additional processes and departments as they see fit and we’ll then import data from the existing system that they want to keep, per their specific instructions.

Introduction:
Carley Foundry is a traditional foundry company that makes metal items, generally ones that are parts of machinery for their clients. They have engineers, sales staff, and production people. There are roughly 70 employees and their customers are mostly businesses that are manufacturers.  They help their clients produce custom items made of different metals. To make these metal items, they develop, create and store instructions for each individual part they make.  Instructions for each part have several different stages and each stage requires its own set of instructions.  Each stage of the part creating is considered a department within their facility.  Right now, all those instructions are stored in a piece of software called QA Display.

The major problem with their current software called QA display is that they have run out of user licenses and cannot purchase more because the software is no longer supported. In addition to being able to add additional users, they’d love to have a bit more functionality in their system and also reorganize their existing departments and processes during the development of the new software (as it’s very hard to change this organization in QA Display).

Since QA Display stores part information and instructions for how to make that part for each department at Carley Foundry, Carley engineers need to be able to create new parts, new processes and new instructions for each part in each department.   Please note that while all processes are organized by department, not all parts require all processes or all departments.

There are a few levels of system users: Production people need to be able to view and print out the instructions when they are needed.  However, administrators and engineers need to be able to edit and manage that part information, the revisions made in the system, system users, departments, process instructions for each part, basic customer information, revisions of part instructions, and more.

Besides rebuilding the software, Carley Foundry would like us to help them reorganize their categories (also known as departments) of their existing processes.  To accomplish that, we should plan to build and release a Beta system to them that has only the name of each new department, sub department and process they want  (most recent organization is in http://www.test.frontierwebdev.com/carleymenu/CarleyFoundry_NewCategories_2011-07-04_v01_A.xlsx) without any data collection fields set up for each process. Once the new system is up, Carley staff will provide us instructions to import the old data in the QA Display system into the new system.  This last step will be be estimated separately after the new system is built.

Goals for the project:
1) Build a usable piece of software that tracks instructions for all parts that Carley Foundry produces
2) Be sure that that software is not limited the use of that software by current licensing restrictions
3) Improve the user interface and experience so the software is easy-to-use and works well on touch screen monitors.
4) Facilitate the reorganization of the categories of departments and processes that are currently set up in QA Display
5) Add new features that make the software easy to work with.
6) Facilitate the approval process for revisions to parts

Budget approach:
150+ hours

The client is open to idea of seeing multiple proposals as it seems the most difficult part of this build will be the method which will allow data layouts to be modified for each process by the client. They may be open to using a third party software tool in combination with our solution if it is cost effective for them. 

Notes:
The program we develop for them will be hosted by them internally. The software will be built for client-owned hosting on a Linux environment. Task 14053 has information about the hosting environment.

By default, the system will be in view only mode and this mode is meant for the production people at Carley who are accessing the system to view instructions for how to make any part in the system.  The system will have different options that will only show to users who are logged in and have permissions to see those features.

Mockups are schematic and can be changed if the development team has an improved or more efficient way for implementing something.

Planned sitemap

· System Dashboard (mockup 1000) – This mockup represents the dashboard of a logged-in administrator with all site privileges.  Note that if no user was logged in, the dashboard would only show a list of recent items and clients that were accessed. There would be no Approval/Notifications section and the main menu links for “Manage”, “Reports”, “Approvals”, “Admin Options”, “Modify Profile” and “Log Out” would not be options. Also, where “Log Out” currently shows, there would be a button for “Log In”.

o The section for Recent Items Parts and Processes would always show the three most recent processes for a part which have been accessed. These are just quick links so the user can return easily to whatever they were working on recently. Clicking on the item would bring the user to the specific process that was accessed last for that specific part such as the page represented at 22c-Part1-EngSpecs.jpg.

o The section for Recent Items Customers would always show the three most recent customers that have been accessed. These are just quick links so the user can return easily to whatever they were working on recently. Clicking on a customer name here would bring the user to a page like 50-ManageCustomers.jpg where there would be the option to edit customer information or view a link to all the parts for that customer.  (For users without the ability to edit, clicking a customer name would show just the list of parts for that customer.)

· Dashboard/Recent Items (mockup 02) – This mockup represents the dropdown menu that should show on mouseover of this button.  The first link to system Dashboard would go to the page like mockup 1000. The other items in the menu would be the three most recent processes accessed and the three most recent customers accessed and clicking on those items would work the same as described above in the system dashboard section.

· Search Tool (mockup 1100) – The search tool is the most important and most often used part of the system.  The search should be an auto-fill and each search would show all matching part numbers, matching departments or processes and matching customers. 

o If the clicks “enter” on the keyboard for a specific part number, the system would take the user to whatever the most recent department and process was visited on that machine.  The most recent department and process for a part is visually represented by the grey box with white writing for each part.  In case it is the first time the system gets used, it can be assumed that the user be taken to the general specs page for that part.  (The reason for this is because users of one computer usually work on parts within their specific department or process.  E.g., employee Joe spends his entire working day green sand blasting different parts, so his recent history will always be of the “green sand blasting” page of those parts and this will help him navigate back to what he was looking at earlier in the day.) Clicking a process would take the user to that specific process page for that part, e.g. if “routing” was selected for part 82231-170-front end cover it’d show the information in 22b-Part1-EngRoutingInfo.jpg.

o Note that all products will have general specs, but will only have information for some of the possible processes. For each part, one the processes used by that part would be listed as sub options for that part number, clicking on any of those processes would take the user directly to those instructions for that part. (Shown in 22b-Part1-EngRoutingInfo.jpg)

o Clicking on a department or sub department name would list all the processes or sub departments within whatever is clicked on.  Clicking on a process would show a list of all parts that require the use of that process. (Shown in 20-BrowseProcessLandingPage.jpg)

o Clicking on a customer would go to a page like 50-ManageCustomers.jpg where if they were an admin they could chose to edit customer information or see a list of all parts in the system for that customer.

· Search Results Page (mockup 10) – This is a search results page if the user clicks enter without selecting an item from whatever they searched.

· Process Results Page (mockup 20) – This would show to a user who clicks on a certain process so the user could see all parts that use that process. The page should use pagination.

· Department Landing Page (mockup 23) – This page would show to a user who clicks on a department name when searching for parts, it would list all the sub departments and processes.

· Departments & Processes Button (mockup 04) – The Departments & Processes button would show a list of all the departments and processes that are set up by the admin.  This mockup shows an outdated list of departments and processes and the newest list is at http://www.test.frontierwebdev.com/carleymenu/CarleyFoundry_NewCategories_2011-07-04_v01_A.xlsx -- Note that in case processes belong to a sub-department, they would be shown as tertiary menu options on mouseover.  Clicking any process will take to the user to a page that would show all parts in the system that have instructions for that process as shown in mockup 20-BrowseProcessLandingPage.jpg

· General Specs For A Part (mockup 2000) – This is the page that shows the basic information about a part.  Note that the spec drawing link would use the operating system of the computer to open that folder.  Also, the left column would show all departments and then for each department clicked, the accordion would show the specific processes that apply to that part..  If a department or process is not required for that part, that department or process would not shown in the left column.

· Print Button For A Part (mockup 2010) – This would allow the user to print out all processes related to the selected part, all processes within the active department for the selected part, or just the active process for the selected part.

· Manage Parts (mockup 40) – This page should use pagination and list all parts. Often, users will get to this page as a part search result.

· Editing general specs for a part (mockup 41) - All parts must have a part#, a description, and they must be assigned to a client. Administrators can also add a main image, weight information, and alloy-temper information. Administrators can assign a path to a local directory.  The status of the product can be fixed process, tracked, or untracked.  When a new part is set up, the status will be automatically set to Untracked, and the engineers will choose what processes will be used for that part by checking the checkbox for each process they think will be needed.  (Note, that the needed processes for a part can be changed at anytime by a user with the appropriate permission.) 

o The product status cannot be changed to fixed process until data has been entered for that part in each of the processes that are checked on this page.  It would be great to have some visual notification which tells an administrator which of the checked departments has been saved with data and which ones have not.

o If the status of a part is untracked, all additions and changes will be saved by the system under a revision titled PP1.  In case the user changes the status to Tracked, then each new revision will be saved as PP[#] where the # ascends by one for each revision. 

o If the status of the part gets changed to fixed status, the revision will be titled v1 and each revision made will move the version up by one.  Also, any changes made to any part that has a status of “fixed process”, the following message should be shown to the user and the user must click yes to continue:
“ The process you are editing is a Fixed Process – customer approval may be necessary. Have the correct procedures been followed to allow a change to this Fixed Process? See the Quality Department for any questions.”

o Notice the “Add New Duplicate Part” button, this button would make a copy of all the part information and ask the client to enter a new part number.  That new part would have a status of untracked and a version of PP1 until the user changes the status to tracked or fixed process for that new part.

o The revision history would save all product information in the state it was when any revision became outdated.  Thus, administrators could easily go back and see the outdated processes of this part. Only administrators with the option to add and edit parts would be allowed to viewing old process instructions for parts. Also, when viewing old instructions, it will be good to have a large visual indicator of some kind which says the part information they are looking at is outdated.

· View Mode for All Processes of a part (all mockup 22’s) – these mockups represent examples of the “view mode” for processes for an example part.  These mockups are all outdated because the list of departments and processes has changed since this project started and because Carley Foundry has decided to redesign the layout for each process.  These mockups should only be used for general understanding about the system.

· Administrative Option for part data entry (mockup 22b) - Once a part has be created, administrators will perform all the data entry for each product.  When a product has a status of untracked, administrators can save changes without approval.  If the status of the product is tracked or fixed process, then they must be shown different administrative options if they would like to submit changes for a particular part:

o Version numbers go up 1 whole number at a time, so it is very often that revisions are submitted in groups. Thus 4 or 5 of the processes would change for a part when it goes from version 2 to version 3.  For that reason, there is an option for “Save these changes for my view only and do not yet submit them for revision approval”. If a user does this and is still making more changes for that part, no other system administrator can propose or save any other changes for that part until the changes are submitted and approved as a new version or discarded permanently by the person saving changes in their own view.

o If the part is locked for revisions because another user is making the revisions, the system should be able to show what user has the part locked as only that user or the super administrator would be able to discard the pending changes so that other new revisions could be initiated.

· Image Only Processes (mockups 3000 and 3010) – some processes can be set up as “Image Only Processes” and these processes would allow users to add images and captions which will be viewable as demonstrated in these mockups. Image only processes are set up and edited differently than all other types of processes. There will be more information about this topic in the edit processes section below.

· Manage Button (mockup 05) – The manage button would only show to logged in users with the appropriate permissions.  Each option in this menu has its own mockup which gives more details about the envisioned functionality.

· Edit Departments and Processes (mockup 30) – This page is the hierarchy view of all processes as they are divided up into categories and sub categories.  Note that users with the appropriate permissions can reorder the departments, sub departments and processes as well as edit or delete existing items and reordering existing items as well. It should be noted that no process can be deleted unless no part in the system is using that process.  (A deletion will be extremely rare, but it is needed in case of any major reorganization of the processes in the future).

· Edit Department (mockup 31) – departments are simple text fields.

· Edit Sub Department (mockup 32) – sub departments are text only fields that are assigned to a main department.

· Reorder Sub-departments/processes (mockup 33) – this shows how processes and sub departments can be reordered within a top level department.

· Edit Process (mockups 34, 34b & 34c)) – This area of the system is the most complex and we are relying on your feedback as developers to devise the most reasonable way to allow processes to be edited.  Andrew Wilk gave consultation on this layout and the end goal of this area is to allow administrators to set up the fields should be available for each process.  Administrators would be able to design a page layout for each process and assign different fields and label types.  Note that the client would set up a special kind of process for image/videos so that those process pages can show as many images as possible for that part (see mockup 3000).  Also, we should have an image field option where the administrator setting up the process can specify where and how that image/video field should show in the layout of the process. 

· Reorder Departments (mockup 35) –this shows how the top level departments would be reorderd.

· Manage Customers (mockup 50) – manage customers would list all customers with pagination. Users can click on the number of parts that the customer has in the system to see all those parts or they can edit basic customer information.

· Edit Customer Information (mockup 51) – Detailed customer information is tracked in a different system, so the only information that this system will store about a customer is their name and customer number.

· Reports Button (mockup 06) – This area would only show to logged in users with the appropriate permissions.  Each option in this menu has its own mockup which gives more details about the envisioned functionality.

· Recent Reports (mockup 60) – This page would use pagination to show all reports that were run by the system so that they can be easily re-run by the system.

· Create New Report (mockup 61) – This section would allow the user to customize whatever report they want about whatever data in the system that they want. We are open to implementation ideas from the UA developers as this has the potential to be a very complex portion of the system.  Right now, the vision is as follows:

o The first step is to ask the user to select the desired criteria for the report, they would be able to choose customer information or part information and then an operator and then 1 or more values to their criteria. They would be allowed to enter as many pieces of criteria that they wanted. These would be the rows of the report.

o The next step would be to choose what columns they would like to have shown in their report. They could select entire processes or each process field individually.  The first two columns in the report would always be customer name and customer number and the next columns in the report would always be whatever the columns the user specifies for the report.  All reports would be downloaded as .csv files.

· Administrative Options Button (mockup 07) – The manage button would only show to logged in users with the appropriate permissions.  Each option in this menu has its own mockup which gives more details about the envisioned functionality.

· System Settings (mockup 70) – This is a blank page and the UA staff should use their discretion to put in any needed variables for the site into this section.

· Manage System Users & Permissions (mockup 71) – This page would list all administrative users of the system. 

· Edit User Profile & Permissions (mockup 72) – This section would allow users to be set up with different permissions in the system to do more than just access the system in “view only” mode. In case any of these permissions should be labeled or grouped differently to make system development easier, please be sure to share that recommendation with the AT.

o Add new parts and mark part revisions to existing parts would allow the user to make proposals for edits to information about any part in the system.  Thus, they can lock a part to make edits and they would be allowed to discard part data information that proposed. In mockup 22b, they would have the abilities to make edits, but not to make and approve them in one step.

o Add new departments would allow the user to reorder sub departments and process and add new departments and sub departments as well.

o Add new processes would allow the user to add new processes and edit the data layout of any existing process.

o Add new clients would allow the user to add new clients or change information about any existing clients.

o View Reports would allow the user to see and run the reports shown in mockup 60.

o Add new reports would allow the user to add new reports or change existing reports.

o Approve Revisions would allow that user to approve revision requests submitted by other users and release new versions of any product.

o Edit system users would allow that user to edit or set up new system users with administrative privileges

o Edit system settings would allow the user access to the system settings page.

· Modify Profile Page (mockup 73) – For users without the ability to manage other users, they would be allowed to change their basic information and site log in on this page.

· Approval Notices (mockup 80) – For users with the permission to approve changes, they would see a list with pagination of all changes that have been submitted for approval or the history of what’s been approved. 

· Approval Notice Detail (mockup 81) – The approval detail page would show all the information about the part that had information changed in one or more of its processes.  The user reviewing the changes would be able to see any notes written in by the user who made the changes. Each process change needs to be approved indivudally by clicking the corresponding checkmark before the “approve” button would be available to click. Clicking on the comparison link would allow the user to see the previous version of the changed information, next to the new information, before making an approval.

o The other option in the approval decision dropdown besides approve should be: “denied”.  When a denial is submitted, the system will send an automatic email to the user who made the change stating that it was denied, along with the note about why it was denied. The bottom of that email should say: “If changes still need to be made, please resubmit them for approval according to the notes above.”

· Compare View of changes (mockup 81b) – this would allow users to easily compare and old version of information next to the proposed changes to the information, along with the notes about the revision.