ox.Solution.Development
Architecture
Architecture
Analysis, Requirements Development & Modeling
There’s a Reason It’s Called Architecture

Everyone has their heroes and around these parts, it doesn’t get much bigger than Steve McConnell, a true master craftsman. He wrote the bible of software project management, Rapid Development, and in it he gives the following analogy: If you want to build a dog house and you go into the backyard with a hammer, some nails and some wood, you will likely be successful at building a dog house. But if you want to build a skyscraper, you’re going to need some blueprints.

The reason software projects have a reputation for going off the rails is because the analysis and design phase is too often cut short or skipped all together. Just as knowing how to build a dog house is not the same as being an architect, knowing how to write code is not the same as knowing how to build stable, reliable software.

As much as we love to hack code, we are analysts and architects at heart. We bring experience outside of software — such as accounting and business management — to the table so we understand business needs, cash flow constraints and expectation management.

We take a mature and sober approach to software that is driven by a strong requirements development process and thorough modeling.

The Unified Modeling Language (UML)

Although we code in C#, TypeScript, JavaScript, HTML, (S)CSS and too many other technologies to mention, the development language that gets the most of our focus emphasis is the Unified Modeling Language (UML). UML is a set of standards for modeling not only software systems, but the business domains and requirements that those systems are built to facilitate.

Use Case and Business Process Modeling

Generally, we begin with Use Case Modeling in which we define the user roles of a system and all of the different tasks that those people are going to need to perform in it. That gives a sense of scope to a project and serves as a touchstone to the rest of the design so that we make sure that the system can provide each piece of required functionality.

From there, we model the business processes and rules that lie within the domain of the proposed system. We cannot automate what we don’t know. This phase of the process tends to be far more useful to clients than they expect because it becomes an opportunity for them to see their existing processes with more clarity. This often leads to changes in the processes themselves as the stakeholders have more clarity. This is why we should never begin writing code until we’ve gotten through this phase.

System Models

Once these dynamic aspects are modeled, we are then able to start modeling the logical structural aspects of the system and identify what data will be needed as inputs and outputs, what the user interfaces will require and what interrogabilities will be needed with other systems.

After going through the required iterations of these modeling steps, we are able to do the coding and testing very quickly and efficiently because the system and expected results are so well defined.