Software development is a lot more than just writing lines of code.

You need to think about project management, prototyping, database design, software architecture, framework usage and a whole host of other factors. In this article you will learn one approach to developing software applications from start to finish.

This approach has been used successfully to develop hundreds of applications by a software development company that has been around since 1991.

Different Ways to Start a Project

There are many methods that developers used when they first approach a new project. Some of the more common approaches are:

• Start with a database design
• Start coding
• Create use cases

There are problems with starting a project using each of these approaches. First, if you start with a database design but you have not even defined all of the screens and reports, how do you know you have all of the data elements? In addition, users can not tell from looking at a database design if the application will meet their needs in the end. Secondly, if you just start coding you are going to end up with a lot of re-writing of code. As the old saying goes; “if you fail to plan, you plan to fail”. It is very difficult to just start coding an application and have it be successful without a lot of re-writing of code. Thirdly, use cases only describe a process; the user needs more information to determine if that process will capture all of the data that they require.

At our company we have been successful using usage summaries, prototyping, use cases, and specification writing in an iterative process that involves the user in each step. Let’s take a look at each of these steps that can help lead you to being successful in your development process.

Usage Summaries

In your first meetings with users you gather information about what it is they are trying to accomplish. You write down the information gathered in a descriptive narrative, in bullet points, and maybe even diagrams, to describe the major goals of the system. Each summary will describe a task to be performed and may range from two to thirty pages depending on the size of each task. Each summary should accomplish the following:

1. Understand what the user is trying to accomplish.
2. Provide the scope of the project.
3. Help you prototype a screen(s) for the described task.

As you continue on with the prototyping and specification writing, you may need to refer back to the usage summaries to ensure that what you are doing is still in-scope. Each summary will also help you come up with some basic screen designs and the inputs required on those screens to accomplish the task described in the summary. How many of these summaries do you need? That depends on the size of the project. It can be anywhere from a few to a hundred depending on the system.

Prototyping

As you develop each of these usage summaries you should start to get an idea of the screens you need to create. As the old saying goes; “A picture is worth a thousand words”. Showing a screen to a user is much more powerful than showing them a diagram with just a bunch of field names on it. Each screen that you prototype should directly support a usage summary that you created earlier.

When you start showing screens to users, they get more involved in the software development process. Users can help you with screens, but I have rarely met a user that can help with database design or coding. Think about the fabulous tools that we have today such as VS.NET that allows us to put together screens quickly and easily. When you layout a screen the user can actually interact with they will find missing elements, or maybe whole new screens that they did not think about during the summary phase.

Prototyping means creating ALL of the screens for the project. You don’t just layout a few; you need to layout every single screen. You will be surprised at how many things you will miss if you do not layout all of the screens. Even the simple maintenance screens should be prototyped up front.

Prototyping Reports

You need to prototype all of the reports as well. Laying out reports is important as it allows users to see what will come out of their system. Many times you will find that once you layout a report and the user says “I need this field on this report”, that you realize that you forgot to allow a place for that field on an input screen. Prototyping reports also helps drive the database design phase of your development effort.

Keep in Front of the Users

As you develop each screen/report, or a group of related screens/reports, you need to constantly show them to your users. Don’t let even a week go by without getting feedback on your prototyped screens. It is important that you have face-to-face time with your users going over each screen and ensure that they are playing with the prototype. This constant interaction with your users will allow you to capture all of the requirements for the application.

Getting Data into the Screens

Users will do better with prototypes if there is some data in list boxes, combo boxes, and grids. Using .NET it is very easy to create this data without having to create a database. The answer is to use XML files. You can quickly create XML files using VS.NET or any other XML editing tool. For example, you might create a customer XML file that you can use to populate a GridView control on an ASPX page. Listing 1 shows a sample customer XML file.

Now that you have some XML you can load that into a GridView control on an ASPX page with just a little code as shown in Listing 2.

This is not a lot of code for you to write, yet helps the user see what the real data will look like in the system. XML files can also be used as the source of data for reports. Using XML for reports allows the user to see the report layout quickly without you having to create a database, write code to connect to the database, etc. It is all about saving time during the prototype phase, but also accurately capturing the user requirements at the same time.

Data Migration / Integration

Don’t forget to prototype data migration if you need it for your new application. For example, you might need to bring over data from an old system you are replacing, or you might need to import or export data to another system. These data inputs and outputs should be laid out in such a way that you can describe all of the data coming in and going out. Mapping data inputs and outputs will help you with your database design when you start that design.

Use Cases

As you develop the screen and report prototypes you will also write more descriptive and detailed use cases. A use case is a description of how data flows through the system to get some final end-state. For example, a use case might describe the detailed stops of how to enroll a new student in a class and take their payment. This one use case might mean that the user has to visit three different screens to accomplish this task.

As you develop each screen (or set of related screens) you write a use case to describe how the data flows through those screens. Use cases help users understand how the application will meet their needs. While developing the use case with the user, they might find that they forgot some important step. This new step might lead to the development of another screen, the addition of fields on existing screens, or new reports. Either way, it is better to find this out up front, and not after you already coded something, or you have already developed the database design.

Specifications

As you are creating the prototype screens you will also want to capture the “business rules” about each field on each screen. Business rules are such items as;

• What fields are required.
• The data type of each field (ie. integer, decimal, date, string, etc.)
• The maximum number of characters that can be input by a user.
• The relationship between fields on a screen.

Each of these business rules need to be documented for each field on each screen and report. The programmer who eventually codes the screen or report will need each of these pieces of information when they are programming that screen or report.

In Figure 1 you see an example of a two different screen shots taken from an actual prototype document. You will create screen shots from your prototype and place them into your specification document. In Figure 2, you see a table that goes immediately below those screens shots. This table describes each field on the screen and the associated business rules that go with those fields. The specification is what is given to the programmer so they can code the application.

Repeat, Repeat, Repeat

All of the above steps you will perform over and over again until you and your users are satisfied that the prototype and specification will meet their business need. Frequent meetings with the users are key during this up-front prototyping and specification writing phase of the project. You need to ensure that the user is using the prototype and reviewing the specification and business rules. By constantly refining the prototype and specifications document you ensure that when you start to build the application the coding will meet the business need.

Knowing When to Stop

The usage summaries that you initially developed are your means to provide functional scope. As you continue to prototype, write additional use cases, and write specifications you refer back to the use case summaries to determine if you are out-of-scope. There will be times when the user wishes to add some items, and it is up to you to remind them that what they initially outlined in the summary is not what they are now asking for. By reminding them what is in the usage summaries you will keep the project on track and avoid scope creep. If the user still wishes to add the additional functionality, that is fine, you just need to remind them that the additional features will take extra time and budget.

Database Design

Once you have all of your screens, reports and data migration prototyped you are now ready to start designing your database. The reason the database design is done last is because you now have all of your screens, reports and data migration layed out, which means you have every single data element identified. Each data element can now be normalized into a good database structure.

What’s Next?

After you have developed the usage summaries, the use cases, the prototype, the specification document and the database design, you are now ready to start building the application. You decide on the schedule, the budget for the application who will be the project manager, who will program the application, who will design the test cases, etc. Of course, all this management of the project is another whole topic all together and is worthy of another article.

Summary

Having a good software development lifecycle (SDLC) process in place is paramount to delivering software projects on-time and on-budget. Following a process and having template documents in place for usage summaries, use cases, and specification documents will make your job much easier as you develop each project. Use an iterative approach to development that keeps you and the project constantly in front of the user and allows the user to give you feedback often. Defining your application elements up front, prior to coding, will ensure that your software projects are successful.