Computer Application Development Process

By Thomas Eklund

Contents

- Overview of Computer Application Development Stages
- Analysis Stage
- Production Stage
- Delivery Stage
- Users Requirements Statement

Overview of Computer Application Development Stages

Years ago I worked in a more predictive, less flexible manner than I do now. This article, which I wrote around 2003, reflects that predictive approach.

Below is a very simplified version of the computer application development stages. The project's nature determines the actual workflow, which in many instances is much more iterative than this article suggests. Nevertheless, these subsections do provide a good general description of the application development approach that I use.

In broad terms, I divide the development process into three main stages: Analysis, Production, and Delivery.

Each of these main stages contains several sub-stages. All the sub-stages together form the complete development process. Each stage results in a specific decision or a product that is an integral part of the overall development process, or both. Below is a list of stages and the sub-stages that they usually contain, and a brief description of the stages and sub-stages.

• Analysis Stage
• Initial Interview Process
• Contract Development Process
• Production Stage
• Application Development and Coding Process (may be repeated)
• Testing with the Users (may be repeated)
• Delivery Stage
• Implementation Process
• Acceptance Process
• User Training
• Review and Maintenance Process

In most instances project developer and the customer should interact during all the three stages.

During the Analysis Stage first users needs are explored and a decision is made whether or not it is likely that there is a match between what the customer needs and wants and the developer can offer. If a potential for such a match exists, users are interviewed in order to specify the needs and wants, features and benefits, cost structure and timetable.

Based on this information I put together Users Requirements Statement, which is a detailed written description of the work that will be performed. This document specifies in writing the objectives and everything that the application must do, the development deadlines, and the relevant cost structure. Having all of this in writing provides a clear understanding of what needs to be achieved, and helps to minimize any misunderstandings.

Until both the developer and the customer have signed Users Requirements Statement, both parties are free to change their mind about working together.

During the Production Stage application development and testing-related sub-stages may be repeated. However, extra time for this is built into the project development plan and Users Requirements Statement. The objective is to produce a fully functional application that is convenient to use and meets the descriptions specified in Users Requirements Statement. We can always create next, upgraded version of the application later. Our project development objective is to deliver the currently agreed on application to the users so that it functions well, and to do so without any cost or other resource overruns.

The Delivery Stage's objective is to make sure that the application has been installed for all the users, is as free of bugs of any kind as possible, and that all the users are sufficiently trained in the application usage.

Top

Analysis Stage

Initial Interview Process

During the Analysis Stage first I conduct a preliminary exploration of the users needs and wants so that we can decide whether or not it is likely that there is a match between the customer's needs and wants, and what I can offer. If a potential for such a match exists, and the customer is interested in obtaining my services, we will negotiate agreement's details. Based on these negotiations both sides decide whether or not they want to work together on the application's development.

Contract Development Process

If both sides decide that they do want to work together on the application's development, applicable documents are signed (for example, a Work Order). This step also signifies customer's agreement to cover the necessary expenses as defined in the contracts that are signed.

Next a comprehensive document is put together that describes the application and its functionality, development cost structure and timetable. I call this document Users Requirements Statement.

This process is somewhat complex, and usually starts with any legacy applications and/or currently handled work processes analysis, and proceeds with different type of users needs and wants analysis.

One relatively simple, yet very applicable way to explain the relevant processes from the technical perspective is to say that the information that is being collected from the users can be divided into subject matters (like, for example, companies and people), characteristics of these subject matters (like, for example, name and address), and workflow that describes, how and in what sequence the users deal with the subject matters.

Based on the users needs analysis, subject matters become tables and the characteristics of these subject matters become table fields. Workflow related aspects are used for deciding what kinds of user interfaces are needed - for example, what forms, reports and their elements are needed and how the forms should be linked and accessible.

If interested, see the Subject Matters and Workflow Role in Application Development subsection for more information on how the subject matters and workflow affect application's development.

As needed and acceptable to the customer, an application can be developed in versions, so that every version is fully usable, and every subsequent version provides a more advanced set of tools and features.

The users may know only some of the things that they need in the new application. In order to create a coherent workflow based application, the project developer may need to fill in the missing pieces, so that the end result is a description of a usable database application.

Further, it usually so happens that different users present and have different points of view. These viewpoints have to be consolidated and merged into an application's description that should be reviewed and approved.

Users Requirements Statement is needed for specifying in writing the objectives and everything that the application must do, the development deadlines, and the relevant cost structure. Briefly, having all of this in writing provides a clear understanding of what needs to be achieved, and helps to minimize any misunderstandings. Such comprehensive written description also helps to minimize the possibility that some development aspects will be overlooked, which may lead to disagreements once the application is ready for delivery.

Putting together Users Requirements Statement requires effort and time, but having this document saves even more effort and time during the development process, because it functions as a roadmap, specifying and clarifying what needs to be done, and by when something needs to be done.

So, Users Requirements Statement serves both customers and developers interests.

Until Users Requirements Statement has been completed, project developer cannot estimate reasonably accurately the labor, time and other resource needs that are needed for the completion of the project.

One of the first things that people always want to know is how long the development process will take. At the onset of the project only limited information about the project's requirements is available, so, only a rough guess can be made. The information that is put together in the first stage, Analysis Stage, allows making more informed decisions about the total development time needed. For most projects user interviewing and business and database analysis reveal requirements that could not have been taken into consideration initially. So, for most projects the total development time cannot be reliably estimated before getting together all the needed information. Similarly, the timeframe for the second stage, Production Stage, and for the third and final stage, Delivery Stage, could vary as a range from the best case scenario to the worst case scenario. The Production Stage often involves unexpected nuances that may be rather time consuming. As is pointed out below, the Delivery Stage's length also depends on several variables.

All of this can and should be taken into consideration when project planning is done.

Network configurations that may affect the application and application usage related differences in the users hardware and software configurations should also be identified.

What To Watch Out For

Analysis Stage is often the most demanding and difficult project development stage, because it is easy to make mistakes during this stage. To put it differently, often it is more difficult to foresee and estimate everything that needs to be done, than it is to actually do it.

Unless the project developer is familiar with all the technologies in question, he or she must find the right IT people to work with and ask them the right questions, and often do so repeatedly.

Further, the project developer must ensure that he or she can interview as many future database application users as possible, or, if the user group is large, ensure that there is a good user representative group in place that consists of people who are both very knowledgeable about the data usage processes, users needs and wants, and are very interested in making sure that the application will actually be developed and put to use.

Even if the number of people who will use the database application in the future is small, it is better to have a group of people representing the users rather than just one person in that role. Having only one person as user representative is risky, because incorrectly selected person can cause a lot of harm to the project.

Further, the project developer must make sure that the customer's management actually supports the project in every way needed.

The project developer must also make sure that the qualifications and personal characteristics of the programmers and other people who will work on the project match sufficiently well the project's needs.

This is all much easier said than done, but it is doable.

Top

Production Stage

Application Development and Coding Process (may be repeated)

The project development team members must do what's needed for meeting the descriptions that are written down in Users Requirements Statement.

The Application Development and Coding Process and the Testing with the Users Process that are described below may have to be repeated until all the requirements specified in Users Requirements Statement have been met.

Well documented application requirements help to minimize the number of development and user testing cycles that are needed.

Project developer should also take notes in preparation for the application's next, upgraded version.

The project planning process that I use builds into the development process certain time reserves. Project developer (or project manager) must ensure that these reserves are used only when doing so is really necessary.

Testing with the Users (may be repeated)

As much as possible, different user should test the application. Project developer should make sure, that he or she has the necessary resources available for handling all the feedback.

The new application should meet the users needs effectively enough. What can make a big difference in this area, is the project developer's ability to do usability testing - for example, observe how the people in the user group work with the application and the problems they encounter. Based on these observations the project developer must identify the tasks and objectives that have to be met so that application's usage problems are being worked out.

It is even better, if the project developer can actually work with the application so that he or she performs real life tasks that the application users have to perform. This works the best when it is done during the Testing with the Users process, that is, after the application's initial version has been developed. Working with the application (and with other application users) for several hours at the time can provide important insight into what should be changed or which additional features are needed so that the end result is a fully and conveniently usable database application.

Smaller changes and additional features can be handled by using the time reserves that were built into Users Requirements Statement and the development process during the Analysis Stage. New and additional features should be left for the application's next, updated version, unless a different agreement is negotiated with the customer.

What To Watch Out For

Project developer should ensure that the user representative group members and the customer's management members stay committed to the application, its development related planned resource needs and its usage in the production environment.

Every application development feature and functionality that is described in Users Requirements Statement deserves enough attention, and every step of the way different features should be completed on time. Otherwise, problems start building on each other.

During project planning the project should be divided into milestones and the milestones into smaller, clearly identified steps and tasks, so that the needed steps and tasks are identified sequentially.

During project management process project developer should use this information so, that the people working on the project have enough autonomy and flexibility for handling the needed tasks. So, project developer should not micromanage, but should stay consistently informed about the progress and the challenges.

If needed, project developer should use the additional or backup resources that were identified during the project planning stage. Project developer should be cautious about allocating time and other resources for development of new and additional features, unless the customer requests them. If a currently handled step meets Users Requirements Statement's description, move on.

If the application's functionality is being put in place the way it was planned, and the customer wants to add features to the application's current version or make changes to the current version, and we have time and other resources available for doing so, then lets implement the changes, recording them in Users Requirements Statement as well. (Users Requirements Statement's new version should be signed every time when the changes are being made.) However, nothing is free - the programmers and other people involved in the project want to get paid, and if the customer wants additional work to be done, the customer should also cover the additional cost the request generates.

This approach is both in the customer's and in the service provider's best interest, because there is no such thing as a perfect software product. People can always imagine something better than they have. So, any product can be imagined as being better than it currently is. This is a very important point to keep in mind. Reality can never measure up to what people's imagination can create. At a certain point the extra time put into the additional improvements simply does not justify the results that are generated. So, the customer can and should make the informed decisions about when the additional expenses are justified. We can always develop the next version of the current application. Lets get the current version done the way it was planned for, so that it is fully usable and convenient to use, then we have time to discuss the next version.

Top

Delivery Stage

Implementation Process

In this Stage the application is installed as needed and all the users are asked to test it.

Delivery stage can be quite long if

• bugs or other kind of development mistakes have to be ironed out, or
• application's components identified in Users Requirements Statement have not been completed or do not function as described.

My policy is to correct the development mistakes, including the bugs that are found after the completion of the development process, free of charge during the designated testing time. Similarly, if I forget to do something that I agreed to do as part of Users Requirements Statement, I will gladly do that work for free as soon as I can and is convenient for the customer.

However, there is a time limit (usually 30 days) during which the customer should test the application. After that time period, any work that needs to be done, including ironing out bugs, will be billed separately.

Acceptance Process

After the application has been implemented, the customer's representative(s) and myself test the application and make sure that all the features listed in Users Requirements Statement are working as described. Thereafter customer's representative(s) and this company's representative(s) sign Users Requirements Statement, indicating that the work described there has been completed.

User Training

User training is a very important part of the overall application development process. Users who have not been trained are less productive and less satisfied with the application.

User training is billed as additional work performed at the hourly rate identified in Users Requirements Statement.

Review and Maintenance Process

I would like to review periodically application usage progress and any issues that arise from using it.

We can also put in place a maintenance plan that is customized for the customer's needs.

What To Watch Out For

Very little or no training may lead to user resentment of the new application. At least some of the people working for the customer should become fully familiar with the new application (preferably already during the development process). Arrangements should be made so that these people can provide answers to the users questions.

Top

Users Requirements Statement

Users Requirements Statement specifies the work that will be performed, completion deadlines, cost structure and additional terms. Every part of Users Requirements Statement describes the application or the development process from a different angle and every part of it, including input/output model, is just a written description of either certain aspect of the application or the development process.

For the optimum outcome, the project development stages and steps can and should be modified in accordance with the project's nature. Similarly, Users Requirements Statement's parts can be modified, so that it is in accordance with the project's nature.

Depending on the project's nature, a Users Requirements Statement may specify either all or most of the following application development aspects:

• Definitions - explanation of terms used.
• Application's Purpose and Description - description of what the application is about and what it has to accomplish and description of all the application's parts as they relate to subject matters and workflow elements
• Subject Matters and Workflow Elements - information entities that the application will track and their characteristics, and parts of the application that will be used for that purpose (forms and reports) and these parts' characteristics
• Input/Output Model - specifies what information will be entered and what results should be displayed
• Business Rules - specifications and limitations that apply to input/output model
• Additional Development - information about possible additional development or additional services provided
• Cost Structure - agreement on pricing and billing structure and how much and when will be paid for the work performed
• Timetable - description of project-related mutually acceptable time frame
• Additional information pertaining to application's development process - contact information, agreement's acceptance information and additional terms

I put Users Requirements Statement together during the application development Analysis Stage's Contract Development Process sub-stage, after gathering sufficient information for this purpose. Users Requirements Statement will also form a contract between the customer and myself.

Even if the application is simple, I prefer to use a written document that specifies the work that will be performed and the development process' details, and is signed by both the customer and myself before and after the application production process. Signing this document before the application production process indicates that we have agreed on what needs to be delivered. Signing this document after the application production process indicates that I have delivered precisely what we did agree to do.

This approach increases efficiency by helping to verify that all the necessary elements have been developed and that all the elements that were developed do indeed belong into the project. It also helps to minimize the probability of having misunderstandings or disagreements between the developer and the customer about the application after it has been built.

After testing and usage the application users may find additional features that should be added to the application, and modifications and changes that should be made. Minor modifications can often be handled without cost overruns.

If the modifications are not so minor and additional cost is acceptable to the customer, any additional features, modifications and changes needed can be added to the application's current version. Otherwise, any additional features, modifications and changes can be added to the application's next, updated version. That is, applications can, and often should be, developed in versions, so that each version is fully usable, but builds on the previous work. In such case each version should have its own Users Requirements Statement.

I do a very thorough and detailed users needs and wants analysis and verify the results with the users before I start building the application. This approach helps to minimize the need for making changes to an already signed Users Requirements Statement. If changes need to be made, Users Requirements Statement's new version should be signed again by the customer's representatives and myself.

You can download an example of a Users Requirements Statement as a PDF file from here. If you are an application developer and would like to use this file as a template for creating your own similar document, feel free to do so.

Legal Disclaimer: Please note that, depending on the nature of the contract and your location, you may need to consult with an attorney for putting together your own contract, just like you would need to do so for putting together any other type of legal document. You will be solely responsible for your usage of this or any other material or information obtained from this website.