An Application Development Methodology for the Lone Eagle Software Developer

One specification has been given -- create a software application that will be used by a handful of people, say 3 to 6 end users, which will support some functionality within the small office environment. Your job, and your job alone, is to design and develop a GUI-based (graphical user interface), interactive software application. Note the "your job alone" in the last sentence. You are a Lone Eagle, a solo programming team, and you "wear many hats". You are an analyst -- a requirements gatherer, designer, coder, tester and documentor. You will likely play trainer to the end users, and perhaps maintain the application once it goes into production. And you thought you were just a programmer!

The Lone Eagle generally works on projects that fall into the executive information systems (EIS), decision support system (DSS), or operational areas of automation. A one-person project rarely produces a "mission-critical" system in which life or limb, or the business itself, is dependent upon! Nevertheless, the investment of time and money into development of an application that benefits the business validates the assumption that the application is truly worthwhile and important. The analysis, design and development of these projects are beyond the capabilities of most end users, so they do not fall into the "end user computing" bucket of applications development. On the other hand, such projects do not typically warrant the involvement or control of the traditional management information systems (MIS) shop.

You may or may not have been sufficiently prepared for your Lone Eagle status. Traditional computer science curriculums are geared toward team-based, large-scale system development. They strive to maintain balance between a breadth of study of the computer science discipline and the practical application of those principles. The bottom line objective is to produce good programmers. The theory and practicum embedded in a computer science curriculum is in essence meant to challenge a student to develop a "logical mind". This is only one necessity for the Lone Eagle.

Herein lies a big problem for the Lone Eagle. You learned how to write programs, not how to create products. A product (versus a program) entails the whole "package" : design and rationale documents, screens, reports, source code, training materials, and on-line or paper-based help facilities. It is more than a handful of diskettes with zipped-up files that are the "system". If you are familiar at all with the traditional models of the software development life cycle (SDLC) such as the waterfall or the spiral model, you find them inappropriate for a one-person project that must be completed within 3 or 4 months. However, rapid application development (RAD), a popular prototyping technique, is fast emerging as a viable SDLC process model for interactive software development. It is ideally suited for tight scheduled, 4GL-based (fourth generation language) projects where software requirements are vague and undocumented. In close proximity to and coordinate with the end users, the application developer produces a working prototype that evolves into a full-scale software application through an iterative "design-code-evaluate" methodology.

The application will most likely use a database to hold the pertinent business information. Its functions will include data creation, storage, retrieval and display via screens and reports to its end users. You should also use a PC-based 4GL such as Visual Basic, Delphi, FoxPro or Powerbuilder. These development environments allow you to quickly construct a working prototype of the application. The user interface portion of the application (the screens and reports) will be a significant part of your effort. A screen painter or forms builder capability allows the developer to create and design graphical user screens within a matter of minutes. User controls such as push buttons, scrolling text boxes, file list boxes, check boxes, etc. can be pasted onto and easily moved around within the screen until the developer is satisfied with the look of the screen. Another 4GL capability is the report writer which allows the developer to easily create the layout format of a paper- or screen-based report. The capability to quickly generate and modify screen and report layouts allows end users to iteratively review the evolving "prototype" application and provide feedback to the Lone Eagle until these application input/output mechanisms meet their needs. End users and system owners (those paying the tab for the development work) like to have something they can "see" and evaluate. It represents tangible progress and gives them a sense of ownership, and nurtures a cooperative team approach as co-designers with the developer.

The application doesn't have to be completed and polished before it is put in the hands of the end users for "real work". Buttons and menu selections can act as placeholders for features not yet implemented (stub coding). An example would be an application with fully functional input screens that allow the end user to add records to a database, but there is no mechanism for generating printed reports. In this way, the application can be put into production quicker, with the added benefit of end user feedback based on actual (not preconceived) software interaction.

Creating useful software products entails more than just writing programs. Unfortunately, there is no "cookbook" method for learning how to develop quality software products. As a whole, the software development industry is still in its infancy and the perceived success of an application relies heavily on the skill of the developer. Like the architect who must know more than just mathematics to create attractive, useful buildings, the Lone Eagle must know more than just coding to create attractive, useful software applications.

The ability to jump right into the 4GL development environment and create screens and reports is certainly very appealing. The problem is that the developer may not spend adequate time scoping out "the rest of the picture". Metaphorically speaking, the Lone Eagle must "do the research before writing the paper". Jumping right into a "solution" for a vague "problem" can lead to a tunnel vision approach. The first solution (prototype) that the end users and system owners seem to like may rule out other, perhaps better solutions to the software engineering "problem".

So what is a Lone Eagle to do? Following is a bare-bones process model that presents a "get down & do it" approach to the development of interactive application software.

Up-Front Activities

Once "given" your project assignment, don't start coding yet! It's natural for the software developer to immediately start creating a mental diagram of the user screens, reports and algorithms that exemplify the application domain. Other activities should occur and assessments made prior to any keyboard pounding and mouse clicking! Concentrate on defining what the "problems" are, not how you are going to "solve" them.

Understand the Perspective of the End Users

End users come in all shapes and sizes, with respect to computer familiarity and usage, cultural background, learning styles, education, and on-the-job experience. They will be using the software that is to be developed and typically don't care to know the technical details about it. Don't assume that they do, or make them have to "think like a programmer" to understand the project under development.

First, sit down with the end users, one at a time, and ask them to describe their work tasks in which your software may ultimately play a role. With paper and pencil, draw a box for each "activity" they describe and label it as such. Connect the boxes together with arrows to illustrate the sequence of activities performed for each task. Don't be concerned if the diagrams seem messy at first. Prompt each end user with questions about who (i.e. business colleagues, other departments, outside-the-company people) they receive information from or give information to, and the reason for the information exchange. Knowing what the end user does, who they interact with, and why, is invaluable information for "scoping out" the business environment in which your software application will play a vital role. After talking with all the end users, redraw your information/activity flow diagrams by hand or use a software package to do so. Don't waste time making them fancy; simple diagrams are less distracting and easier to understand.

Now that you know what the end users typically do in their day-to-day operations, play the "what if" game to find out what they do if something out of the ordinary happens. Using your diagrams as a cue, encourage the end user to describe situations in which the sequence of activities they routinely perform is interrupted. Then have them describe what they do to get back on track. This type of "exception handling" will provide you with further insight about the nature of their business, as well as the design of the underlying algorithms of your software! Incorporate these new task activities in your diagrams.

So far you've concentrated on finding out about the overall business process model of the end users. The next step is to find out about the specific data that the end users handles on a regular basis, and the relationships of the data elements to other data and the business tasks. Pertinent data elements can be found in paper-based, manually completed or machine generated forms and/or reports, word processing and spreadsheet documents, and any databases that are already in use by the end users. Obtain sample copies (at least two of each, preferably more) of each type of form, report or document. If there are any relational databases in use, obtain a copy of the database schema, which lists the database tables, database fields, and field properties. Inquire if there is a Data Dictionary for the database(s). Organize all of these documents and label them according to where and how they are "used" by the end users.

Analyze the "Problem"

At this point you should be getting a good handle on the business domain in which you are working. Take some time to analyze and reflect upon what you've learned about the end users, their tasks, and the business data so far.

Assuming that you have a project deadline date to meet, you must decide what are the requirements for the application. Focus on what the application should do, not how you're going to implement it. There are basically three types of requirements: must-have, like-to-have, and nice-to-have. The must-have requirements define what functions your application must perform in order to solve the basic problem at hand. An example is, "will generate a report that lists customers, in alphabetical order by last name, who have not placed an order within the last 90 days". The like-to-have requirements define features or enhancements that add value to the application in some respect. An example is, "will create a text file that contains names, addresses and phone numbers of non-active customers that can be used by a mail merge program". The nice-to-have requirements are those features that really go beyond the scope of the application, but nevertheless are desired by at least one of the end users. An example is, "will create a text file that contains names, addresses and phone numbers of non-active customers, and automatically e-mailed to every account executive".

Do not expect to have a list of requirements handed to you. You must derive the requirements from the end users, the system owners and supports, and from your own acquired knowledge of the business domain. On a single sheet of paper, create a list that contains the three types of requirements for the application. Delineate them by listing the must-haves first, the like-to-haves second, and the nice-to-haves at the bottom.

Present this list to your end users and system owners for clarification and comments.

Figure Out a Good Solution

By now your head is swimming with ideas about what your application will look like and what it must do. Of course your end users want you to implement every feature on your "requirements list". And you've assured them that you will, if you have the time! The important thing to remember is that the must-have requirements will be addressed first, and the application will work well, before adding the "bells & whistles" functionality.

Figuring out a good solution does not imply the optimal solution. The Lone Eagle is rarely provided the time, money or resources for the optimal solution (if there is such a thing). The goal is to design and develop a robust application that is reliable and useful to the end users. The application may be your "baby", but it's just another tool for the end users to use to do their job. The KISS principle (Keep It Simple, Silly) applies here.

The Development Process

The actual code-writing process cycles through three activities in the rapid application development environment as the prototype evolves into a full-scale application:

Design, Implement, Evaluate

The Design activity is essentially a mental activity when you think about how you're going to do what needs to be done in the near term. Of course, good software design principles should always be used. The architecture of your software should be based on the concepts of loosely coupled, highly cohesive modules of program code. These concepts were undoubtedly part of your computer science education. It would behoove you to refresh your memory on these important concepts. The design of your application, in terms of program flow and control, can greatly impact the maintainability and expandability of your application. Long, monolithic programs are a sign of amateur programmers. Create simple block diagrams that illustrate the functional components of your application, and revise them as needed.

The Implement activity is a physical activity. Writing code, creating GUI objects, trying to make the code "do" and "act" the way you assumed it would when you designed it just moments ago! Self-document the code by including remarks/comments that provide rationale or explanation for each code routine.

The Evaluate activity is both a mental and physical activity, sometimes done together with an end user when you are ready for feedback. Sometimes, all you can do is draw the conclusion that you can't Implement the code the way you Designed it. And the cycle begins again.

You must stay aware of your "time schedule" while iterating through each cycle for each functional component of the application. Time must be allocated for testing and debugging as each component is developed and integrated into the application.

Project Closure

As the project completion date draws near, and after careful planning and realistic expectations, the prototype has evolved into a robust application that, at a minimum, satisfies the must-have requirements previously defined. End users have provided input to the application's design all along, and system owners have been periodically briefed on its progress and perhaps were given a "demo" or two. At some point in time, the code should be "frozen" so that you may get on with other activities as you finish up this project.

There is the matter of installing the "production" application on the end user's computers and then testing it fully in its operational environment to rule out unexpected errors. Also provide any hands-on training or write users manuals/guides, and make two complete backups of all code and electronic design documents (one for you, one for the "customer").

Deliverables

Deliverables include those things you hand over to the system owner at the end of the project, which may not be explicitly specified. It is up to you, the Lone Eagle, to define the contents and assemble a simple, yet professional-looking application package. The package should contain all diagrams or documents you created, a printout of all of the program code, screen shots of all user screens, output report samples, database schemas and data dictionaries, etc. Some 4GL environments provide a facility to produce source code documentation and other interesting diagrams. The package can be simply bound in a 3-ring binder and sectioned with "tabs" made from post-it notes. The "project notebook" can be easily updated as needed once the application goes into operation.

Software Maintenance

You may be assigned to maintain the application once it's put into operation. If so, and you know this before the end of the project, pretend that you are NOT going to be the maintainer. Otherwise, the temptation to slack off your schedule is great, and you miss the opportunity to experience the "project complete" feeling of closure on a job well done.

Self-Assessment

Every project is a learning experience. After you wrap up the project, spend some time reflecting on what you did, how you did it, and what you will do different in the next project. Learn from your mistakes. Keep track of how much time you spent in each development activity so that you can manage your time even better during the next project. Swallow your ego and ask your end users where there are weaknesses in your application. Then soar on to the next project.