I'm not one to post off-topic messages here, but as I've taken part in a lot of questions regarding designs and approaches for other applications and I know the audience here is at least attempting to make use of the same type of framework as I, I can't think of a better place to get some advice for a design I am working on.
The application is intended to automate the change management process for a small group of pseudo-developers. I say pseudo because they are not programming like you & I do but instead 'configure' 3rd party applications that run on manufacturing equipment. To them, each of these is an application and, as such, it has a similar life-cycle. And, while I can apply industry standards to the process, they've insisted that our software adhere to their current process. I'll try to explain as best as I can.
At the start, a new Request will be submitted by someone (can be a user, customer, sales person, even internally, who knows). When submitted, the request is to be reviewed by the "Project Sponsor" - basically the decision maker with the customer who owns the application (via the equipment). They can either accept the request, meaning that it should be pursued further, or reject it as something they aren't interested in seeing done. They can also put it on hold for later decision.
All accepted requests go through a process of requirements gathering and specification documentation (by the application's Project Manager) which is then sent to the Project Sponsor again for review to make sure everything is inline with what they want. At this point, it is assumed (I guess) that the Project Sponsor knows what the requestor wanted because they are never directly consulted again. The document will go through how many ever revisions are necessary to get it right until the Project Sponser gives their approval that it is what they want.
Next, a formal estimate for labor and costs is assembled based on the requirements and specification information. This can be done in-house or the result of a request for estimate from on-shore or off-shore (outside) contractors. The estimate is then submitted to the Project Sponsor again for final approval. If approved, the work is added to the queue for development. While development is ongoing, the status of the "order" is updated to reflect the % complete and any changes in status. When the work is finally released to the customer, the item is closed and assigned a "Released" status.
Throughout this process, we are to provide status feedback on demand to the Project Manager, Project Sponsor and original requestor. Where it gets tricky, and what I am trying to work out, is that this is not a linear process. In other words, there is not a one-to-one relationship between a request, the specifications documentation, an estimate and the eventual change order submitted to whomever performs the work. They can roll-up multiple requests into a single specification document if they are related to the same feature. Likewise, multiple specification documents can be estimated together. And the eventual change order can cover a bunch of all the above. But, we need to be able to carry individual information throughout the chain. So, if the estimate that contains a particular request is approved and work in-progress, then we need the status of that request to show up as "In Progress", and so on.
I think that covers it from a pretty basic level. The problem I am having is trying to decide if I am dealing with one entity or multiple. It seems logical that the original request may be its own object, but I don't know about the rest. I think the answer is probably staring me in the face, I could just use some help jogging it loose. So, any input, thoughts, etc. are greatly appreciated.
Thanks in advance.
That's just it, it has been during the process of specifying the requirements and creating use cases that this block has presented itself. I can easily say this much:
but then what? "A Project Manager creates a new ????" or "A Project Manager edits the request", etc. This is where I have to decide if I'm working with a single object of not.
And, I know that the use cases are supposed to lend themselves to identifying the entities, etc. But I'm having a hard time nailing the use cases down without some idea of the larger picture. Nonetheless, here's what I have in pretty generic terms:
I know there are a few more in there but haven't fleshed them out. What I can't figure out is how to incorporate the many-to-one aspects into the use cases. And I'm spending WAY too much time on this step.
Thanks for the help.
The highest level object here looks like the Project. The project has a couple of child object properties: Manager and Sponsor, as well as several other "non-object" properties. The project also has a child collection: Requests.
There is a project-level Status property and one for each of the Requests. The lowest common denominator request status is the project status (so that the project can't receive approval status until all pending requests are individually approved. The project manager would probably like to see methods like GetPendingRequests to determine why the Project's status is not yet Approved, for example.
Each Request object will need a child collection of Requirements (unless your app will simply use a String Requirements property that contains the file URL for a document that manifests this information). Each Requirement would have properties such as Requestor, Specification Information, Deadline, and EstimatedCost as a minimum. Depending on how much support for designing the solution of each requirement, there might be other properties, as well (such as developers and contractors that will be used to implement the solution and characteristics of the solution that may be common to all of them).
How do you think about the Project in terms of the "players?" Would a Project Sponsor be responsible for requests from multiple Requestors on a Project? Or would the participation of a separate Requestor make this a separate Project altogether? Do you need to be able to branch and merge Projects after their creation?
The approval process is probably nothing but a series of Status changes for each Reqeust. The sequence looks something like:
New - Sponsor must review; Specification Information is presumably complete already - everything else will be a Change Request
SponsorReject - result of review is end of the road for this request
SponsorAccept - result of reivew is a display of interest in the development of an estimate
EstimateAssigned - Project Manager assigns analysis of the Request to a Developer, likely establishing some deadline
ManagerEstimateAccept - Developer submitted it and Manager passed it to Sponsor
ManagerEstimateReject - Manager sent Developer back to drawing board with new deadline
SponsorEstimateAccept - Sponsor approves the estimate, authorizing the work to be done
InDevelopment - Manager assigns implementation of the Request to a Developer/Team
InDevTesting - if you want to track this and there are other players to track
DevComplete - it's ready for acceptance testing by the Sponsor and/or Requestor
ImplementationReject - Sponsor isn't happy with it.
ImplementationAccept - Sponsor IS happy with it... this might be "Closed" if you stop tracking here
SponsorInvoiceDelivered - in case you want to track billing and payment activity and, sure, go crazy and prepare an import file for your accounting system for these transactions,too!
Paid - now it's closed unless you are going to keep track of it in the Maintenance part of the life cycle
You may not like all these names, of course. And some of them seem to beg for comments justifying, for example, rejection. Maybe there needs to be a collection of Status Change Items for each request that provides Request History (and a like one for the Project's Status history that is automatically updated as necessary by changes in its Requests' Status values?). And since we brought up History, what about personnel changes during the life of the Project/Requests? Do you care if the Sponsor changes? (almost surely) Do you care if a Developer changes? (maybe not so much?)
The scope of this one can get out of hand pretty quickly. Be sure it's tight before you over-commit!!!
I think you've got me on the right track now. I'm seeing three entities: Request, Project and Order. A Project will have a RequestCollection and an Order will have a ProjectCollection which will allow the grouping capability required.
We already have a workflow foundation that will drive the application and manage the state changes as things progress but I will have to incorporate the necessary cascades so that all Requests in a Project are updated when the Project's status changes and all Projects are updated when the Order's status changes.
I think beyond that, the rest is either workflow or role-based operations. We will have the specifications and estimate as attributes (properties) of the Project and allow supporting docs to be attached. Revision control will manage traceability and allow us to add/remove Requests from a Project and Projects from an Order. We already allow assignment/reassignment as part of our workflow process. Personnel changes would have to be handled either that way or by redefining which user is the Project Sponser when changed. I don't think that will cause any problem, just change who gives the approval. I will make sure the process definition clearly states that such a change is not a problem.
Yea...I think it is all coming together. But, you are right about the scope! This can get out of hand easily.
Thanks for the input.
Copyright (c) Marimer LLC