Software Development Process

The concept underlying a software development process is simple but effective: document what works and what does not work for development projects. That way, success can be repeated by following what worked in prior projects, and prior mistakes can be avoided.

There are many different software development processes that can be used when developing an application. In this book we'll introduce three software development processes, the Waterfall and Iterative processes (an iterative process will be used to develop our case study application), and the Microsoft Solutions Framework (MSF).

• The Waterfall method was the earliest organized software development process. It arranges the stages of a software development process into a cascading, linear process that never revisits a stage once it is completed.
• The Iterative processes (there are many of them) were developed after, in virtue of its lack of flexibility, the Waterfall process proved unable to provide a solution to the problems of software reliability and cost. They also emphasize moving from one stage of a project to another. However, they allow for revisiting a previous stage of the process, when knowledge acquired in a later stage makes the output of the earlier stage obsolete or incomplete.
• MSF is based on Microsoft's experience in building enterprise level applications using an n-tier logical application model, an iterative methodology and a structured graphical modeling language called Unified Modeling Language (UML).

We'll discuss software development processes in Chapter 2, and UML in Chapter 7.

Business Requirements and Analysis

Whatever software development process we use, the most important part of the process is to understand the business requirements. A software business builds software for profit. It usually sells the finished product and hopes to make money. Other businesses must find another way to recover the costs of building software or having it built for them.

Business requirements describe the fundamental reasons why a customer wants to invest money to build a software solution. These requirements are specific to each business, and are not related to any functional requirements the software might have (like being able to hold vast amounts of data). They may include goals like reducing time spent, or increasing efficiency, for processes such as tracking order information, shipments, or cash flow. These goals lead to a vision statement for the software, which is the first part of the iterative design process.

Determining and analyzing business requirements for the software is crucial to the success of the software and its ability to perform the tasks for which it's designed. We will investigate the process of determining and analyzing business requirements for an application in Chapter 6.

Modeling the Software

There are many ways to model the software for a development project. One traditional way that you may be familiar with is the flow chart. A flow chart can be created at a high level, indicating the flow of the application from tier to tier, and among the modules and objects within a tier. Flow charts can also model the flow of execution within a module or object.

However, flow charts are really more suited to non-object-oriented, procedural code than to the object-oriented or stateless code we need to use for our application. Flow charts are best suited to modeling linear flow of program execution, because they can only indicate transitions of state or stateless behavior awkwardly at best, or to modeling complex algorithms. They are still used, but often at a level of modeling the behavior of methods or properties rather than modeling application or component behavior.

The modeling approach we'll take in this book is a leading object-oriented analysis and design notation, the Unified Modeling Language (UML). We'll look at how to model a distributed application using UML in Chapter 7.

Now we've got a handle on some of the underlying concepts we're basing the application development on, let's start to get practical and look at how these ideas can be physically realized. We're going to be developing an application for use on Windows operating systems using Visual Basic as our programming language, and thus the products we're going to be using are all from Microsoft. Indeed Microsoft makes it very easy for us to develop 3-tier applications.