Continuing with following a project methodology to create a model of an x-ray machine, I am working on the Planning phase.
“The Planning Process Group consists of those processes performed to establish the total scope of the effort, define and refine objectives, and develop the course of action required to attain those objectives.” – A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition
- A generic x-ray machine loosely based on such cool looking examples as Toshiba’s Infinix.
- A modular design including:
- Patient bench
- C-arm with image intensifier and x-ray tube
- Ceiling mount for C-arm
- Floor mount for C-arm
- Medical monitors
- Control Panel
- Modules can move correctly
- C-arm can move up and down bench
- C-arm can rotate around bench
- C-arm can be raised and lowered
- C-arm can be moved sideways
- A clean professional set of textures that match photographs
Here is a rough diagram.
I haven’t put the ceiling and floor mounts in the diagram. Doh!
The benefits of this modular approach is that each module can also be used by itself by the person who buys and uses them. From what I can tell the control panel usually sits on the bench, but I suspect some people may want to make a scene without it. Also, by having it separate the user can place it on either side of the bench as desired, or even at the foot of the bench.
- Create a folder of reference materials (pictures, technical manuals, etc). These can got mostly from the internet.
- Establish a self-documenting nomenclature for the naming of elements in the design (i.e. give every element an obvious name that tells the user the purpose)
- Create a design document for each module. This will be a diagram that shows the size, appearance and placement of various elements.
- Create modules. Order of creation:
- Bench (probably easiest element)
- Control panel
- C-arm ceiling mount
- C-arm floor mount
- Test each module across different rendering applications
- Check off model against the requirements of sites such as TurboSquid and Renderosity.
NOTE: For newbies to this sort of stuff, the naming of elements is pretty important. It’s like naming fields in a database. They name to be obvious. So for example, just say that I make a set of different textures for the control panel so that the user can pick from 3 or 4 looks, it would be good if the control panel had a name like “control_panel” so that the different texture files might be named “control_panel_red”, “control_panel_white” and so on. We can then easily match related files together in a way that is meaningful.
I must admit that I still lack a detailed schedule. I need to think this through as I spend a bit more time studying each of the modules and the elements that comprise them. So yes, I’ll aim to get the design documents in place by next weekend.
Thanks for reading this, especially those for whom this is gobble-gook.
PS: yes, I know that there are a lot of people out there who simply go ahead a model stuff without any of this, but I am also trying to demonstrate my project methodology knowledge for any potential employers.