In my last post, I suggested approaching a project using modeling to plan our path forward. Modeling could be thought of as a way of looking at the “big picture”, allowing us to more fully wrap our minds around what we need to do. When used most effectively, it also provides us with a natural layout of scope and related tasks. Our model could be a representation of our entire project, but we may also choose to model only certain aspects of a project, especially those which pose a greater risk than others.
We can choose to model using methods we are already familiar with, such as flow charting or pseudo code; or we can use tools specifically designed for the job. One tool we can use in modeling is the UML (Unified Modeling Language). The UML provides a standard syntax to represent aspects of our system. This standard syntax is designed to be user-friendly, and can be effectively used to coordinate and document project requirements with both technical and non-technical stakeholders.
Regardless of the method we choose to model our project, the important thing we want to remember is that we want modeling to simplify our work flow. Our intention is that, by modeling first, our time will be spent more efficiently.
It’s tempting to dive into a new project and begin drawing, writing software, making test fixtures, and other activities because they are some of the more exciting and fun aspects of our work. But often, charging headlong into the implementation phase of a project before giving thought to the larger picture results in a less-than-ideal outcome: sloppy code, rework, delays and more. We’re in a time where we are asked to do more with less, and still produce top quality results. While it might seem like we can’t afford the time to do some initial planning and general design, doing so could allow us to work more smoothly, predictably and effectively. We might even finish our project early and under budget.
Even if we, as engineers and project managers, understand the benefit of planning our strategy before moving to project execution, others involved in the project may not. We deal with the technical as a normal part of our lives, and we understand our methods and jargon. When doing the up-front work of defining and specifying scope, others may feel more comfortable discussing things less technically, perhaps even more abstractly. Many methods exist for expressing and representing tasks and goals in a non-technical, non-industry-specific manner; modeling is one example.
Modeling can be accomplished in various ways. The intent is to create a visual representation of the project requirements and associated processes. Different aspects of a project could be represented in multiple, but distinct, ways to fully convey the functional requirements. If desired, project modeling could be further extended to define more specifics of implementation. Regardless of how much we use modeling, any amount can help streamline the project execution.
Thanks for spending time with us.