COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part One - The Project Begins

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

When you program a small game or a small utility size application, most of us just sit down and create the progam. All in all that's not all that bad of an idea for that size project. However, what if you were sitting at your desk at work, your boss send you an email that says "I need a program that allows to create accurate charts and diagrams, floor layouts, plan and estimate the cost of building a house from the grounds up and that gets determined as I create the plan of the house. In essence he wants a financial version of the now well known Autocad™ Application. He already knows what he wants. he doesn't want something that will interface with Autocad™ either he wants his own custom 100% original software product.

Now, how big do think this kind of a project would be? How long do you think it would take you to create something like this? Most importantly what are you going to do to make sure that this projects succeeds? For one thing, it's definitaly not something you can just sit at your computer and start coding, it's simply too big a project, it needs detailed analysis, probably some good engineering. Basically you cannot create this type of application without some degree of preparations and documentations.

This series of articles will help cover all this. We will start with the paper (or the email in this example) and work our way right down to the actual development of the application. We will be looking at what methods and tools are available to you every step of the way as well as the basis of how to choose the right tool for the task at hand. We'll be looking at cost and time issues too because in the business world, time is money and in the case of software developers, time is costs to the business that hired or contracted us. By the end of this series you should be well equipped to start, and finish, pretty much any size project.

WHAT HAPPENS FIRST:

Indeed here the question is not what happens next, but what happens first. While sipping your morning coffee, getting an email like this one won't exactly help you digest that coffee properly. In many cases like our example above, interfacing with Autocad™ would be intelligent, but for the sake of this series, let's say your boss wants to make a better version of the software and get into competition with Autocad™ so there's no way you can interface to, or borrow anything from that software to help shorten your time, you are on your own and it's time to get things started.

So here you, you have your work cut out for you to say the least, you've been basically put in high performance mode by your boss who relies on you to get the job done (that's why he's paying you the big bucks after all). So what do you first? Best thing to do is take a step back, and see what you can use to do this job. First thing to realize is that there will be many things to do to get from point A to point B here, many documents to write, and of course plenty of planning and organization. But lets take things one step at a time, this is an article after all, not a deadline so we have time here to take things slow and easy. The first thing is to review the software development cycle. It's broken down into 5 categories and they are:

• The Analysis:
  This first step is where you take the time to gather the information you will need to get things started, usually it involves meetings with the potential users to gather the user requirements. I've been to a place where the users wrote their own requirements in a standard document format. It allowed them to really detail what they wanted and how they wanted things to work. In other cases you need to ask questions if you want to get answers. At this stage, you will be creating a preliminary analysis, a detailed analysis, and a solution proposal as well. All these will be covered later in this first of the series.


• Software Conceptualization And Design:
  You have your detailed analysis at hand, the proposed solution has been accepted, you are now read to begin the project. Does your project need database capability, if so, what capacity, which database, elaborate the table structures from the detailed analysis that you built in the Analysis phase. does it require special hardware requirements, which operating system will you be developing this for. There are many software engineering methods available to help answer these questions, and more. we'll see what they are later in this document.


• Software Development And Implementation:
  This where the actual programming begins. In the two steps above you would usually have time to determine which programming language you'll be using and can start developing the application itself. This entails screen designs and the programming of these designs. Typically the scren designs can be defined with the help of the screen layout, the navigational specifications and the functional specifications. We will cover those elsewhere in this series but the names might already be ringing a bell in your head right now.


• Testing And Debugging:
  Ah yes, the dreaded testing and debugging phase. feared by many among us. This phase in unevitable. However, there are tools to help us out here too. There are different types of problems that can occur and each should be treated differently. Alot of this phase depends on how the first 3 phases of the project went. With good planning, and good software design methods, many of the bugs can be eliminated at an early stage. However there will always be a testing and debugging phase nonetheless.


• Installation And Integration:
  There are always nightmares about what will happen when you install the application on the user's machine. Time and time again I've installed a program on the user's machine only to find that the machine couldn't boot anymore because of the program I installed. This is a grey region as it's called because it can influence what the user thinks of the application and you. With the right tools and preparations you can ease yourself of this useless stress quite easily just by taking the right precautions. We'll see what I mean elsewhere in this series as well.

THE ANALYSIS:

You still have that email ringing in your head, and you want to start the analysis as soon as possible so things can get started as soon as possible too. You are probably also starting to think about the programming phase too because you're a programmer and you want to start coding right away. Like I mentionned above, this type of practice is good for small projects, but virtually useless in a project this size. You'll just shoot yourself in the foot and the less analysis and preparations you have, the bigger the gun. There are many software analysis tools, each with their own special use that you can use to your advantage. The best thing to do is to enumerate them here so you know what they are and where they are commonly used. I'll also show some known forms of these methods here too. They are categorized in 6 categories. These are:

• The AdHoc or Improvised Methods:
  This methods consists of no particular methods per se. Everything is done almost seemingly backwards where code is created so testing can begin, design is created based on the code created and everything is seemingly burried in documentation. You can clearly see that this method cannot be used in this project of ours.


• Functional Decomposition And Structured Methods:
  This entails the methods that are based on functional decomposition and stepwise refinement; the breaking down of complex systems into single-function tasks and subtasks. These were the first of the analysis methods to be developed. The analysis (data flows) tended to concentrate on the business flow (which was generally manual in the beginning). The data was simple (integers, float/real, and characters were the only data types to worry about) but the processing (the work being done with or on the data) would typically get very complex. Some extensions were added later specifically for real time embedded systems and concurrent processing. A few examples of these methods are: CSD (Composite Structured Design), CORE (COntroled Requirements Expression), DARTS (Design Approach for Real-Time Systems), DCDS (Distributed Computing Design Systems) and SADT (Structured Analysis and Design Technique).


• Data-Structured Methods:
  These are methods which are based on the decomposition of complex data. Used usually for systems that tend to be mostly databases and the modification of how that data was presented to the user. Data-Structured methods evolved pretty early in the history of software engineering and basically overlapped the Functional Decomposition methods. Depending on the project at hand engineers usually used one or the other of these two methods. This techniques tend to start with the desired output and work backwards to the desired input. Data-Structured methods were prefered by developers of Management Information Systems, where the data is more complex than the processing on the data. A few examples of these are: DSSD (Data Structure System Design), JSP (Jackson Structured Programming) and LCP (Logical Construction of Programs).


• Modelling Methods:
  These techniques treat all system functions as parallel processes as in they could all theoretically happen at the same time. They were first developed for controlling trains, elevators, and other controlling devices. Originally, the techniques created a concurrent conceptual model, which then had to be converted into a sequential implementation model (to simulate concurrency) because of the available computer technology at the time as computers became able to multitask and computer languages began to support concurrent processes like Ada tasking models this methods could be used more and more often. there's two well known examples of the Data-Structured Methods which are: JSD (Jackson System Development) and PAMELA (with the PAMELA II to follow shortly after).


• Formal (Mathematical) Methods:
  As you might have guessed, these techniques build on the early math foundations of computer science. Mathematical proofs are used as a form of verification of the system. Because of this, they are frequently used on safety critical or security critical systems such as nuclear power plants, life support system and national security systems). Although mathematical in it's roots, these techniques don't only rely on mathematics, they offer a wide range of analysis tools that allow you to do your job the right way. Examples of these techniques include: CSP (Communicating Sequential Processes), HDM (Hierarchical Development Method), HOS (High Order Software), RAISE (Rigorous Approach to Industrial Software Engineering) and SARA (Structured ARchitect's Apprentice) to name a few.


• Object Oriented Methods:
  These Techniques tend to go about describing a solution to a programming project in a very different but somewhat more familiar fashion. Everything in the process is an object entity. each object has properties (that describe the objects) and methods (that define what the object can do). Objects also have relationships to other other objects in a hierarchical fashion. There are many different types of Object Oriented Methods, some more renouned than others. Here's a few examples of these methods: HOOD (Herarchical Object Oriented Development), OMT (Object Modeling Technique), OPEN (Object oriented Process, Environment and Notation) and of course UML (Unified Modeling Language).

One of these 6 categories will offer you the best tool for the project at hand. Ultimately all these server the same purpose and that is to help you define the problem as well as defining the solution. So before you decide on which methods to use, you need to think about what you are being asked for and when you have them, take a good look at the user requirements. In a very general fashion, the user requirements, in our case, are defined by the program we are modeling our project upon. The user's manual from the Autocad™ software package should tell us everything we need to know except the financial side that we'd be adding as an extra feature. You're not always that lucky however. Even today, there are still many need for software that hasn't been created yet and in that case, you have no choice but to do it step by step, sit down with the users, ask many questions to get their version of the story so to speak. once you have the user's list of requirements, then you can go about using these 6 categories of methods to define what the solution can be. In some cases it gets more complicated as management might decide that some user requirements might not apply to the project, so it's more meetings, with management and with the users to arrive to a compromise between what the users want and what management thinks the users need.

To decide on which of the 5 last categories (as we already ruled out the first listed, the AdHoc methods) we simply need to ask ourselves the right questions. More than likely, the answers to those question will give you a really good outlook on which method is best suited for the project at hand. that can change from project to project of course depending on those answers. Note also that when I say "when you describe the project" that can mean when you talk about it to others and/or when you are thinking about the project to yourself as well. So then here's a list of questions that could get asked to get our answer:

• What Is The Common Denominator Of The Project:
  A denominator, in this context, is merely trying to find what the smallest unit of description that can be isolated from the rest. when I describe the many features of the application software to be, do I talk in objects or entities, in functions or actions to take, in expected results or do I usually describe concepts more than actual physical concrete steps. Do I describe the project as modules (parts of the whole picture) or do I push the description more towards the bigger picture? When you get to the smaller steps, what type of description do you use to explain them?


• What are the Sub Items Of The Common Denominator:
  The combination of this question and the previous one will guide you alot. For example, if we would talk about entities being the common denominator as in, when you talk about each general concept of the project you usually describe the as something you can describe and something that can do things. Then chances are Object Oriented Methods would be the way to go. If the common denominator is more of an expected result with an idea on how to get that result, then functional decomposition might be the direction we should be taking. However at this question in particular, you might still be talking about a module to module basis where each module would have a set of specific procedures and functions. The next question can clear that up for you.


• Is There A Relation Between Each Common Denominator:
  This is what splits the methods one step further. If each module tends to work in an independant way and you don't foresee any module needing to communicate directly to any other module or being dependant on another module for any reason then perhaps you are not talking Object Oriented after all. In this case a Data Structured or Modeling Method might be better suited for the task. If however you always endup talking about how each module can be composed of other modules, or each module are part of another "bigger" module. Then Object Oriented Methods would be the direction to take.

And that's it, these three questions are usually enough to bring you project towards one of the 6 software engineering methods described above with a good degree of certainty. Just to be sure though it's always good to start writing about the project to be first. Start elaborating some details about the application to see if your answers to these questions stay consistent. With today's word processing software, you can allow yourself to start writing and rearranging later as needed so let's go ahead and start writing about our project. It's always a good idea to see if we can name our project too. Since we were asked to make a financial version of Autocad™ itself. Let's call it FinanceCAD. Throughout the rest of this series, I will be refering to our project by the name FinanceCAD.

DETAILING THE NEEDS:

With all this baggage of knowledge in our head, let's start describing FinanceCAD in a very general fashion and from that description we are going to see which method we should be using and why.

FinanceCAD is an Industrial Computer Aided Design (CAD) software application. The goal of this project is to reproduce the functionality of an existing software, Autocad™ in the features it will be offering the user plus allow to give the user an accurate list of materials, material quantities and the cost to build/create the design should the design be taking to the realization phase at some point in time. As such, it should have a given list of abilities (features) to make available to the user in some way, shape or form. As a general list of feature, it should allow the following:

• To allow the user to specify the scale of measurements to use in the design.
• To draw the generally known basic shapes such as circles, lines, rectangles, triangles and others.
• Allow to calculate the length (in the selected scale and in the realistic scale) of any parts of the design being worked on.
• Allow to define what materials are to be used on each part of the design, the standard length and width the material comes in and the price that material currently cost to purchase.
• All this should be accessible easily and quickly regardless of where, in the application, the users currently finds themselves.
• A printout of the design, and optionally, the list of materials and costs should be available at any time.

Let's just stop right here for now and start analyzing what we've written so far. The description itself is pretty clear so far. Already we are talking about relationships (indirectly) between the different parts of the application. We are also talking about Entities. With these few lines of text we can already see which way the project is going. We are talking about an area where the user can create their designs, an independant list of shapes that the user can choose from to draw their designs. we are already talking about each of those shapes having the ability to assign a material to itself with the goal to use the length of the shape, with the material to create a cost for creating that shape based on it's length at the desired scale. We are also talking about the design arean having the ability to represent itself accuratly on a list of scales in relation to the actual scale the design should be created for. Already there is alot that tells us that we will be using an Object Oriented Method of somekind to analyze this project.

We've established all this from that small description we've written. You can think of this small description as quite unofficial however, you might have created this description in a notepad maybe after asking a few questions or even researching a few things on the internet. However, even at this very early stage, you already know which tool you'll need to get the job started. So there's no need to look any further.

IN CONCLUSION:

And this brings are first part of this series on Professsional/commercial Application development to an end. There's alot to digest in this first section so I hope you got yourself a big cup of coffee before you started reading this. In the next section we will be starting the Analysis of the project in much more detail working our way through the different documents you would typically need at the analysis phase of a project (described above) along with maybe other useful documents you can carry throughout the analysis phase. See you then.

MystikShadows
Stéphane Richard
srichard@adaworld.com