3 Tools & Techniques for an Effective Software Development Process
One of the most interesting things about working at Simbex is hearing about new product concepts from our clients and then digging-in to understand what they need to make their ideas come alive. The product concepts that come our way often require developing and integrating many different components – electrical hardware, mechanical enclosures, algorithms, user interfaces, etc. Typically, clients can easily describe the overall features, functionality and physical properties of a device. However, it can be a challenge to describe the attributes of the software that make a device come alive for an end-user and behave in a way that meets everyone’s expectations. While there are industry guidelines and best practices that we follow, the almost infinite flexibility of software means that there are countless ways in which the software design can be implemented.
As a senior software engineer, I collaborate with our clients so they can see their system from the software perspective and guide them through important design decisions without bogging down in the technical minutiae of the implementation. This means teasing out important business rules and workflows and presenting the client with a set of options that fit their schedule, budget and all the while delivering quality applications that meet their expectations. Over the years, our team has integrated some concise pre-development techniques for bridging the gap between a concept and implementation. This blog post summarizes three simple but effective techniques to align expectations with clients early in the development process.
1. Identify Core Components and Relationships Through Good Architecture
To borrow a phrase from computer scientist Ralph Johnson, the software architecture is a “shared understanding” of the system design. A software architecture document may sound highly specialized, but a well-written architecture document has content that is accessible and usable for everyone involved in the system development. And while there is no one definition or way to document software architecture, at the very least the software architecture document describes a software’s interfaces and puts the software into a larger context of the environment in which it is operating. For some clients, this may be the first time they think about their system from this perspective.
The software architecture document is often the first place where we start nailing down the specific technology choices for the software. Defining and clarifying these decisions early is important because it sets the expectations for our clients about what their system can and cannot do in the future. It also minimizes the risk of scope creepage and the risk of having the client invest in features they do not really need.
Above are some simple but effective techniques we use when developing software for clients. The information generated from these techniques are accessible to everyone involved in the development process, regardless of their background. By knowing how to quickly and efficiently align everyone’s expectations early in the development process and establishing a common understanding we can deliver a wide range of software applications to a diverse portfolio of clients.
For example, the simple diagram on the right focuses on the external interfaces of the software applications opens a host of questions: Should that USB connection allow for data transfer if the wireless connection fails? Where are the cybersecurity vulnerabilities? Do we need encryption?
2. Document Comprehensive Use Cases to Map Features and Functionality
A Use Case is a description of the actions an end-user takes to achieve a specific goal. Explicitly describing how a certain feature or functionality is used is a powerful, non-technical method for aligning a client and developer. Working through a use case lays bare everyone’s (often unspoken) assumptions about end-users’ characteristics, behaviors, and workflows using common non-technical language. Developers gain a clearer understanding of the end-user and clients often face questions or scenarios that were not considered in their initial system concept. As a bonus, once Use Cases are established it is an easy and natural progression to turn the information into user interface wireframes or mockups so that clients can start getting a real feel for what the end-users will experience.
Use Cases can be presented in many forms. Unified Modeling Language (UML) Use Case diagrams are a very traditional, graphical shorthand technique for documenting Use Cases. However, their accessibility is limited due to the use of specialized symbols.
Additionally, they can be overwhelming for more complex scenarios. As an alternative, we have put Use Cases into a tabular form such as the one shown below. This is easy to read format accessible not only to the client but everyone on the project who has a stake in understanding how the system is going to behave. Clients can review and discuss these Use Cases on their own without a decoder ring.
| Use Case Name | A short descriptive name of the Use Case |
| Actor(s) | Short descriptions of the end user(s) involved in the Use Case |
| Brief | A few sentences describing what the Use Case is describing. It can be helpful to include the trigger(s) that start the Use Case and the trigger(s) that bring the Use Case to an end. |
| Pre-Conditions | Basic conditions for the Use Case such as “system is powered on and initialized” |
| Standard Flow | A description of what the Actor (end user) does to access or use the functionality being described by the Use Case. The descriptions should include information such as the type of feedback the Actor gets in response to their actions. |
| Alternative Flow | A description of how the system behaves when not everything goes to plan. There may be multiple Alternative Flows to the Standard Flow. |
In the template above note the use of “Alternative Cases”. These are just as important to document as the normal use case. Systems and users never do exactly what they are supposed to do 100% of the time. It is important to consider scenarios such as: What happens when power is lost? How about when a user enters the wrong password? When a device cannot connect to the Internet?
3. Develop Flow Diagrams and Mockups to Help Visualize the Product
Flow diagrams are a great tool for helping a client see more of the behind the scenes action and logic of the software under development so you can get their input on critical workflows and decision points within the software. While flow diagrams and use cases have some similarities, flow diagrams tend to focus on the flow of data through your system and can more easily show parallel processes if needed.
Here’s an example of how we used flow diagrams with one of our clients. In the initialization sequence of the system we were developing, one of several external events could cause the system to stop and require user input. We needed to cover all of these external events but at the same time, we knew that we should not overwhelm the end-user with different messages and options for each event. Rather than bombarding the client with a bunch of “what if” questions, we came up with a series of flow diagrams showing how the system’s initialization logic covered all of the eventualities that could cause the process to fail while routing everything through a couple of generic UI messages and options. Once this client saw this and realized that we understood and could cover all their concerns, they were able to quickly make the decisions about how they wanted the system to behave in these situations.
Conclusion
Above are some simple but effective techniques we use when developing software for clients. The information generated from these techniques are accessible to everyone involved in the development process, regardless of their background. By knowing how to quickly and efficiently align everyone’s expectations early in the development process and establishing a common understanding we can deliver a wide range of software applications to a diverse portfolio of clients.
