Part 1 in Lucas Moser’s Four Part Series.
Extended life spans of custom software mean that production deployment is no longer the end all be all for development. In the series to follow we will explore the concept of modeling and how it affects multiple aspects of the software development life cycle.
An application will likely have several iterations of feature enhancements, framework upgrades, and bug fixes by the time you finally scrap it for something new. A significant portion of overall cost of ownership for custom software is incurred during this maintenance phase. Therefore a primary focus of new application development should address decisions that can be made prior to the initial release that will help drive value for the entire lifespan of this application.
Modeling is a seldom addressed aspect of software engineering that has great potential to add long term value. Whether it enables automated production of iPhone covers or provides a 3D video gaming experience, the core goal of software remains the same: to model and extend certain aspects of the physical world. All software applications have models and the quality of those applications tend to follow the quality of models upon which they were built.
Requirements are what we would like the system to do. The model is how we would like the system to do it.
So what do we really mean when we’re talking about requirements? And how does it relate to our topic of modeling? Requirements are what we would like the system to do. The model is how we would like the system to do it. Consider a fictitious application that is responsible for project management. Requirements dictate that a project has a status of Open when it is created and Closed when it is finished. These requirements sound simple. The developer simply sets the code that handles project creation to the status of Open, and the code that handles completion of the project to the status of Closed. The solution is tested and declared a success. In this scenario, six weeks after the application has been “released into the wild”, the application owners determine that they would like to add more status configurations. First, they would like to add a status of On-Hold if the project manager is on vacation. Second, if the project is over budget, the status should be updated to Over-Budget. A new developer enters the project and has an easy solution for these: he will simply go to the screen where projects are updated and add new check boxes to designate a project as On-Hold or Over-Budget.
Here, as with any application, requirements will continue to change after development is complete. This is a tractable problem commonly addressed with Agile methodologies. The greater concern here is how these requirements were implemented sporadically. A user, stakeholder, or developer must traverse several application screens or code files across multiple systems to fully understand or communicate status-changing behavior. Once they understand the behavior, the team must decide what to do with illogical statuses such as Closed/On-Hold (which is a literal permutation of the implementation described above).
In the case of this application, new statuses would be cheaper to implement if a model for managing statuses was already in place. A Finite State Machine is a simple and cohesive solution for status changes based on events. By proactively declaring and committing to a model (such as a FSM), applications can become more maintainable, extendable, and self-documenting.
In this series, we will be discussing different aspects of software modeling, what that means to business analysts and managers, and how developers leverage models to develop better applications.