Software design, is the step in the software development process prior to construction. It is the step where you think about what you are going to build, what tools or prebuilt components you need, what components you need to build, and how it all fits together. The amount of time spent on the design of the software depends on the complexity of the software. You would spend some time and money designing a new home but not much time or money designing a tree house for the kids. Same with software. You may not spend much time designing the application to track the names and handicaps for your bowling league, but you will want to take the time to do a careful design of your company's order entry/inventory/invoicing system.

The next obvious question is then "how does one do software design"? The first step is a software design methodology.

Well, if you are developing a one-form application, you may not need a methodology. But very few applications are that simple. Most applications have many forms, lots of data, significant amounts of processing, and tons of business rules. And these components are not independent; they must all work together.

A methodology ensures we logically think through the things we need to consider when designing an application: from forming a team to collecting requirements to designing the components to laying out the user interface to organizing the data to defining development, testing and distribution strategies. It helps us to develop a plan.

So the primary answer to the above question is that we need a methodology to manage the complexity of software design and development.

The best way to define a methodology is to think logically through the steps needed to design an application. Write all of the steps down. Start from the definition of the project and include everything you need to do including: getting funding, defining a team, detailing the requirements, understanding the business objects, designing the user-interface, and so on.

InStep Technologies uses a methodology called GUIDS. This methodology provides an object-oriented approach to software design and can be used with any languages, technologies, or modeling tools.

You're working on the design phase of a professional-quality application. You're interviewing users, documenting object definitions, and drawing object models. Your boss walks in and asks "Why aren't you coding?" Well, maybe not in those exact words, but it's clear that the boss is not happy with your apparent lack of progress on the application.

Here are several answers to that question. Use any or all that seem appropriate!

1. Because I need to understand what I'm building before I build it. Using this answer requires that you explain the purpose of design. Feel free to use the building metaphor presented in the column.
2. Because I don't want to recode the application. Explain that you'd rather think through the application first and then write the code to prevent the need to rewrite a lot of code later. This answer is best used if your boss has experienced projects that required rework due to unforeseen circumstances. Then you can add, "Remember how much code we had to rewrite during the XYZ project?"
3. Because we want the application done quickly, and I need to divide it into logical units so the team can work on it effectively. This satisfies two of the boss's concerns. First, it makes it clear that you're aware of the tight deadline on the project. Second, it identifies how you are helping to make the team more effective.
4. Because we need to work more closely with the users on this one. This answer works well if your boss has experienced a project with unhappy users. You can then say, "Remember how unhappy the users were when they received the ABC application?" You can really add substance to this answer if you can get one of the users you're working with to mention to your boss how great it is to be involved this early on in the project.
5. Because we want to be a state-of-the-art development group. This answer appeals to the boss's ego. State-of-the-art today means object-oriented. Object-oriented design requires that the objects are identified before the application is built. It's as simple as that.
6. Because we want to have reusable components to leverage in future projects. This works well with the prior answer. The key to productivity is leveraging reusable components. It requires forethought to define which components you can develop so other applications can use them.
7. I am coding. This works well if your boss is not interested in hearing about a design step. For this answer to work appropriately, you should keep the VB IDE open and minimized while you're working on the design. When you see the boss coming, bring up the IDE. Be sure that a code window with a lot of intense code is on top. Just running the Application Wizard will generate some nice looking code for this purpose.

With these reusable answers, you're always ready to answer the question, "Why no code?"-From my sidebar to the Programming With Class column in the Visual Basic Programmer's Journal, March 1998.

The GUIDS methodology is a pragmatic approach for the design of an application. Each letter in the word GUIDS represents one of the steps in the design process.

G - Goal-Centered design. This step involves understanding the goals of the application. Then taking those goals, defining the basic "things" involved with the application and how these "things" work together. These are the business objects and the scenarios (or stories). This step results in a clear understanding of the project and a definition of the business objects and scenarios.

U - User-Interface design. This step involves converting the scenarios into features in a user-interface. The focus here is on defining a user-interface that is centered around the user's goals. Like an emergency room has the most needed tools within reach and less used or more dangerous tools hidden within cabinets, so too with a user interface. The most needed features should be easily available on toolbars and less used or more dangerous features should be tucked away in menus. This step results in a user-interface design document.

I - Implementation-Centered design. This is the most difficult step because it is here that the architecture and internals of the application are defined. Should the app use Win Forms, Web Forms, Web services, remoting, Enterprise Services, etc? How many components should be defined and where should each reside? The results of this step is the application architecture and a definition of the components required in the application.

D - Data design. Notice that the data design is *not* first! Many of us learned to design software by first designing the database. We learned how to do entity modeling and normalization. This is a good technique for designing a database, but not for designing the application. Hence, this step is here, but not until after the other parts of the design are complete.

S - Strategies for construction. This is the last step in the design and it encompasses all of the other steps that should be performed before the development process begins. This includes the definition of coding standards, naming conventions, quality control procedures, documentation, and so on.

For a more detailed discussion of each step of the GUIDS methodology with a complete example, see "Doing Objects in Microsoft Visual Basic 6.0" by Deborah Kurata.

To download a sample GUIDS design document, click here.

• Don't forget the user. To ensure that the application meets the needs of the users, they must be involved in this step of the process. Even if you're familiar with the business, you must get the key users or subject matter experts involved in the design process. However, the user interface itself is not the design.
• Don't worry about implementation. Given any problem, developers like to think about how to code a solution. At this point in the design, that is irrelevant. Again, the goal of this step is to fully understand the requirements in order to ensure the resulting application meets the needs of the users.
• Don't confuse the object model with a data model. As you develop the object model, you define the data elements associated with the objects. However, you are not developing a data model. As you know, a good data model requires a lot of information about the data, how it is related, and how it should be normalized. This information is not relevant at this point in the process when you are simply understanding the requirements of the application. You develop the data model later in the design process, after you are clear on the users' requirements.
• The object model is not the design. In the first point, I stated that the user-interface design is not the design. The previous point states that the data model is not the design. Now, I'm telling you that the object model is not the design. The design is the set of all these things.-From my sidebar to the Programming With Class column in the Visual Basic Programmer's Journal, March 1998.