Part One - The Project Begins

Written by Stéphane Richard (Mystikshadows)


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.


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:


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:

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:

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.


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:

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.


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.

Stéphane Richard