1. Introduction. 1.1 Purpose of this document

Transcription

1 1. Introduction 1.1 Purpose of this document This is the Software Design Specification for Timeless Solutions EW^2 solution. This document will outline the software design and specification of our workflow task management system in addition to system architecture, system components, and software requirements as agreed upon by the customer and the project team. 1.2 Scope of the development project This will be called EW^2, a website that will manage tasks determined by TAA and completed by independent proctors for a set amount of money. This website will handle the tasks and the users. 1.3 Definitions, acronyms, and abbreviations TAA - The American Academy EW2 - Education With an Elastic Workforce Drupal - Content Management System PHP - A server scripting language used by Drupal MySQL - The database that will be used for this project Apache - A web service Task - Unit of work for which TAA offers payment 1.4 References Overview of document This document will contain specifics about the design of our software. It is a high level explanation of how the project will function, and which components will be developed to help it do so. This document will also serve to explain the technologies used to develop the website, as well as the user's interaction with various features.

2 2. System architecture description 2.1 Overview of modules / components Core UI and our custom theme - The UI will be handled completed through the Drupal Core UI. The modifications we will make will be through a custom theme module. Database Handler The Drupal module "Views" will act as the link between our MySQL database and our application in Drupal. Views creates tables, does queries, stores information and alters data all by itself. We will incorporate this powerful open source module to keep manage our data. Data Processing All data processing is done within the Drupal framework. Security Sessions, authentication, encryption, password protection (and hashing), auto logout will all be done with Drupal. These are built in features of the CMS. User Modules Allows a user to log into a website with secure credentials Determines their credentials which will allow for a smarter search heuristic for the projects displayed on the screen Keeps track of user web activity on the site Search Modules Uses an AJAX component (web service) that will handle dynamic searching of workflow modules to be displayed to the user Links the user and the workflow together Workflow Modules Handles all tasks and projects Highly customizable States can be Available, In Progress, In Review and Finished Project Modules

3 A unit of work that TAA needs to have completed 2.2 Structure and relationship 2.3 User interface issues Proctor/Teacher: When the user first logs into the site, they will be presented with a few suggestions of tasks they may like to try, which is based on their previously accepted tasks. Below that will be a list of tasks or projects listed in order of which was posted the most recently. There will be a search bar where the user can search the tasks. After searching, the recommended tasks will move to the bottom of the screen and the search results will appear on top. On every user page, there will be left and right columns with additional information that may be useful to the user. The menus on the right will include a link to take them to a shopping cart of their selected tasks, as well as a brief summary of what tasks are in the cart at the time. Additionally, the bar on the right will provide the user with any notifications of payment received, as well as a link to see information about those payments. The menus on the left will assist in searching the tasks, by filtering results much like many shopping websites do. The table of tasks will give some summary information, such as the task name, how much the task is worth, and deadlines or limits, if any. Each task is click able, which will take you to a new page with the rest of the task's information.

4 The information the task presents depends on the information specified when the task was created. A task will include space for (although depending on the task, it may be blank): 1. Description 2. Type of task (weather it is paid to the best submission or to everyone who completes the task satisfactorily) 3. Due date 4. Limit of how many people can complete the task 5. Limit of how many times a single person can complete the task 6. etc "etc" is in case TAA wants more criteria, ideally they can extend it. After browsing to the cart, the user can decide to commit to complete the tasks, or save tasks for later if they don't want to commit yet. After committing to complete some tasks, the user's right menus will now include an option to work on tasks. The option will take them to a screen listing the tasks they have accepted, and when they click on a task, they can see the description again. There they will be given options to upload documents as attachments to complete the task. If a workflow was created in addition to documents, they will be prompted through it. Worflows vary depending on the task, but typically most tasks will be attaching the finished work and submitting it for evaluation. The bar on the right will also allow the user to navigate to a summary of tasks pending evaluation. TAA Employee/Admin: Upon logging in, the administrator will be presented with a list of tasks which need to be approved or rejected for having been completed by the users. There will be the typical administrative menus available through Drupal, as well as an option to create a new task for a user. The administrator will be able to add users through the Drupal's integrated user administrator menu. If the administrator clicks on a completed task, they will be presented with the task's information, as well as any attachments for having completed the task. They can review the results and click a button to accept or reject the work. After selecting the option to create a new task, the administrator will be taken to a screen with the same spaces as the task screen on a user's individual task's page, only the page will have fields for the administrator to edit instead. If the administrator wants to add fields to tasks, they can use the Content Type option on their menu, which is a feature integrated with drupal. In addition to creating a task with default fields, the administrator can also add a workflow to the task, by giving a series of steps and prompts. To do this, the administrator can click a button labeled "Add step" and with each new step he will be able to add task criteria such as a description of what he wants done. The administrator, on any of these task completion screens, can attach a document for the user to download. This may include further instructions, a contract to be signed and returned, or an example or template of what they are looking for.

5 3. Detailed description of components This will be completed in SDSv Reuse and relationships to other products Role in Product Design Existing Drupal Modules are to be used whenever possible Modules that are close to what we need will be "tweaked" using module "hooks." This is Drupal's modular ability to affect different modules through method overloading. Product Implementation and Reasons for Changes As we discover better modules, our project's goals may change to accommodate. Different modules will require different enhancements If we discover there is no suitable module for a particular need, we will need to implement one from scratch ourselves. Thrown Out Reusable Information Modules which are too difficult to use for our tasks will be discarded. 5.0 Design decisions and trade offs The requirement of using Drupal to design the website made many of the design decisions for us. Leveraging the strengths of Drupal require the use of preexisting modules instead of creating custom modules. Mechanical Turk was considered as a method of tracking tasks any paying employees, however Mechanical Turk failed to offer user API which was needed for the teachers to accept the tasks. Because of this Mechanical Turk was abandoned and Drupal will be used instead to manage tasks. 6.0 Pseudo code for components The following is an example of some code used for writing "hooks" in drupal. This is how we can tweak a module's functionality: /** * php Drupal code example * This demonstrates how to remove unwanted content created * by another module. */ function modulename_link_alter(&$links, $node) { if ($links->type == "contenttype") { $links->linktype = array(); // empties the links. }

6 } It is still fairly early in the development process to give a large amount of pseudo code for components and modules that may have Drupal alternatives already. The following are ideas for some custom modules if needed: Workflow(class) This class will control the Project class for access with different settings and customization, such as specific pay procedures. Project(class) This will be a very low level implementation of our Project/Task idea. Basically a project can be a task, but a task is the lowest level. This will be controlled by Workflow. Search(class) This will be the glue that keeps the User and Workflow communicating. There will be AJAX implementations to allow for fast searching while also presenting the data in a pleasing way to the user. 7.0 Appendices (if any)