\documentclass{article} \usepackage{ulem} \usepackage{graphicx} \usepackage{hyperref} \pagestyle{headings} \begin{document} \part{Workflow Module} Rough-cut task list for getting a minimal workflow module running for work order use: \textbf{Task} & \textbf{Estimate} & \textbf{User/Status} \\ \hline Create workflow application module, skeleton & 1.0 & NOT DONE \\ \hline Create SQL scripts, add to lib/Driver.php, lib/Driver/sql.php for listing/updating/deleting work items & 2.0 & NOT DONE \\ \hline Write or port workflow classes to PEAR or Horde & 8.0 & NOT DONE \\ \hline Implement XPDL load of workflow objects & 4.0 & NOT DONE \\ \hline Implement WorkItem::evaluateExpression() (only need strings, numbers, work item properties, and "==" operator to start) & 2.0 & NOT DONE \\ \hline Implement user's work queue screen & 2.0 & NOT DONE \\ \hline Implement driver-based application call mechanism & 1.0 & NOT DONE \\ \hline Implement templatized e-mail send "application" & 3.0 & NOT DONE \\ \hline Implement create ticket "application" & 2.0 & NOT DONE \\ \hline Implement ulaform entry/update "application" & 3.0 & NOT DONE \\ \hline Implement e-mail decision "application" & 2.0 & NOT DONE \\ \hline Implement work item history logging mechanism & 2.0 & NOT DONE \\ \hline \textbf{Total} & 32.0 & \\ \hline
\section{Workflow versus project management} \subsection{Project Management} In project management tools, the project is represented by a directed graph of dependant tasks. There are no cycles or decision logic in a PERT chart, and necessarily so because project management requires finding the length of the timewise longest dependency path (the critical path) and resolving resource contention, and both of these would be extremely difficult if not impossible if we could not determine the project path ahead of time. In project management, therefore, lots of effort is expended up front in the planning phase to remove these decision points. During the course of a project, a change requires refactoring the dependency graph (the PERT chart), which will affect the critical path and the project deadline. It can also cause reallocation of resources. \subsection{Workflow} In workflow, workitems contain a number of steps. Workflow is built like a state machine, and has built in decision logic. A work item can cycle (e.g. do step A, then do step B, then check if passes Q.C., if not, go back to step B), has decision logic (if some test passes, do A, otherwise do B). In this model, we cannot predict the path. \subsection{Goals} \begin{itemize} \item I would like to be able to apply the Wiki:TheoryOfConstraints to the management of both workflow and projects \item I would like unified resource management, or at least coopeartive resource management between projects and workflow. \item I would like to be able to have workflow items as project tasks. \end{itemize} \subsection{Problems} \begin{itemize} \item Resource management is difficult with workitems because the resources required by a workitem may not be predictable until the workitem is running. \item Estimating the time a workitem will run is difficult because it may have a cycle. \end{itemize} \subsection{Possible Solutions} \begin{itemize} \item Workflow definition would constrain the time a workitem can run (to counter cycles) \item Scheduler would make sure all resources which might be required for a workitem are available (costly). \item Scheduler could predict based on past performance (error-prone) \item User could hint at which cases are more likely.
Project/SimpleWorkflowApplicationSuePorter \end{itemize} \section{Resources} \begin{itemize} \item PEAR Workflow project \item Word doc on a workflow engine for Kewl. Lots of nice references. \end{itemize} \end{document}