Last year I shared with you Layer 1 of planning a holiday feast using a systems approach. We defined our requirements, considers concerns, identified risks, and even started thinking about our architecture at a high level.
Let’s quickly review. Here’s what my requirements looked like:
After considering concerns and risks, we ended up with one more requirement:
I promised last year that in another holiday post we would model the cooking functions, allocate it to the architecture of my system, and handle the ingredients as resources. So, let’s get started!
As I approach my system behavior, I’m faced with a critical question, which is the fidelity of the model. We modeled some components last time around. If I selected those well (which I didn’t) I’d let the integrated root functions of each of those components compose my high level behavior, each performing in parallel.
That’s nice, but not helpful. It would provide me with a view that showed what each of my major components is cooking at a given time. Instead, I ask myself why I’m modeling this in the first place. It’s a fun sample for a blog post, but more importantly, I’d like to use this model to actually cook next week! Therefore, I need to model this from the perspective of seeing what happens when.
First, I need to use it to plan. As I examine my recipes, how can I deconflict cooking day? Really, who wants to slave all day in the kitchen? Instead, I’ll prepare in advance the pies and the cranberries as both keep beautifully for a day or two in the refrigerator.
Notice that I used a parallel branch to indicate that all of these things are happening concurrently. That doesn’t necessarily mean that I’ll start the turkey brining, cook the pies, and prepare the cranberries all at once. I could get fancy and model the start times and the durations. If I were a less experienced cook, I might need that level of modeling.
Notice an alternative approach I used for cooking on the big day represented by the second parallel branch. I simply used node alignment to give a sense of the order in which I need to begin each task. Just because I have this awesomely powerful tool that can literally model the entire behavior of aircraft carrier doesn’t mean I have to use it to its full extent. Using it to its full capability wouldn’t be smart here. It would cost me time and money and create a model too complex for me to use for its intended purpose.
I realize I’m suggesting an engineer not use every cool tool available to them. Restraint is possible, I assure you.
Now that I have a sense of what I need to do, we need to consider who will do them, my Human components. Upon review, we can see that we don’t have much conflict above. One person could conceivably do all of the tasks shown above, and I likely will. I’ll probably ask my sweet daughter to contribute to the meal on an appropriate level for her by tasking her with the sweet potatoes.
Here we see the process again, this time with the performer of the functions properly allocated and shown at the bottom of the node. I’m leveraging Icon Templates here. If you aren’t sure how to use those and you’re a Vitech software user on maintenance, check out vitechcorp.com/mysupport for screencasts.
Finally, we’ll consider resources. My original vision for this model considered the ingredients to be resources. While they are consumed, it would be overkill here. I’m going to check my recipes, make a list, and buy all the groceries at once. If I were in a restaurant situation, I might need to model the ingredients this way. (For an example of this reference our Fast Food sample model where we use burgers as a resource.)
Instead, I’m going to model my kitchen tools as resources. I could just as easily consider them to be Components. I’m choosing to model them as resources mostly because I want to see them represented in this view and the EFFBD will display this nicely. I want to account for them so that I see when they are in use to ensure that they are ready (read: clean) and are not being attempted to be used twice at once.
I modeled the oven, turkey roaster, microwave, and can opener as Components last year. I’ll transform them to Resources by dragging them from the element list to the Project Pane and dropping them on the Resource class.
Here we see the resources in the view represented by rounded rectangles with a double outline. I can quickly see that I’ll need two 9×13 pans.
To round out my model, I should probably document my recipes. I’ve created Document elements for each and linked the online recipes as appropriate and pasted my own recipes in the description field.
I think I’m ready to cook!
