COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part Two - The Details Behind The Problem

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

Welcome to the 2nd part of this series. I'd like to start by doing a summary of what we talked about in the first part to get you situated. The first thing we did is define our problem (project) which is a financial version of Autocad™ we named FinanceCAD. We also looked at all the complete development cycle and the steps the entail. Next we described the different types of software engineering methods we had at our disposal to go about describing the problem at hand. Finally we started describing the project briefly and elaborated the right set of software engineering tools we'll be using to define the problem at the analysis phase of the development cycle.

In this second part of the series, we'll take it from where we stopped in the first part, we'll take the problem one step closer to it's solution by explaining everything that would happen in the analysis phase and see what documents are produced from that step.

WHAT HAPPENS NEXT:

Indeed, we can actually talk about what happens next because we now covered what happens first. So then, what does happen next? Do we jump right into the software engineering tool and get busy? The answer has to be no, for more than one reason. The main reason however is that you need to know what you'll be elaborating when you do use that tool. Going live into the modelling tool and starting to get everything into shape is like using the AdHoc software engineering method. You go in without a clear idea of what it is exactly that you are modelling so you model and create documentation after which is the backwards approach to software Engineering. At this point there are still things that need to be figured out before you can start the official modeling technique.

The Analysis Phase is defined by the documents that are needed. Indeed, Analysis means that you are at an unknown or unsure phase of the development. When you start this phase you don't even know if the solution you'll be proposing will be accepted or not and if you won't need to refine your analysis even more than you will be. Starting the modelling phase right away would be a waste of valuable resources at such an early stage. Therefore, let's detail the analysis phase documents so that we can create them. There are essentially 3 documents that should be produced here. These are:

• The Preliminary Analysis Document:
  this is the shortest of the 3 documents. The preliminary Analysis Document is created in order for you to present the problem, or the project in this case in the way you see and understand it. You might have talked abit about the project to a few potential users of the application to be, you might have done research to find out what Autocad™ really is, get details on the features offered by the program as well as it's limitations. You might have played with the program to reproduce to get a feel of how things work, how things are presented to the user how to get to the functionality the user could want to accomplish and so on. Once the research is done you start to write what you've discovered about the project. What you believe (at this early a stage of analysis) would/could be needed to create the project. However this is an early stage and you shouldn't go into to many details here as far as what language you'll use, what software engineering tools you'll be using and other specific details such as cost of the project. These will need to be supplied but they are presented in the Solution Proposal Document typically. This first document is typically presented to administration in order to get the green light to really get started the project. Hence create the Detailed Analysis Document Explained below.


• The Detailed Analysis Document:
  In a typical situation where you start with a manual process and attempt to automate it with a software solution. This document explains the flow of information between the different parts of the manual process. A good way to go about collecting information for this document is to talk to the users first. Many times, in a manual process, people at different steps of the process might carry notes with them, custom list of things depending on the job they are assigned to do. You have to think in a 3 step process at every step of the manual process. the steps are:
  
  
  • What information is needed prior to executing this step of the process?
    This is where the "Flow Of Information" comes into place. you can use tools that allow you to draw Data-Flow Diagrams to help illustrate the flow of information in a given process. Typically, for a process to go smoothly throughout it's many substeps, clear information is needed to travel through the process, something in different forms, and arrive at the end of the process with the right results.If you cannot define this clearly enough in one set of (Input, Work, Output) you might want to consider breaking the step into substeps. In a typical example, employees, before creating a shipment might need to know what exactly a customer is buying (an invoice typically). You'll find that in all types of manual processes, there is usually always somekind of information needed to perform a step in the process. Sometimes it's one document that travels as is throughout the steps, sometimes that documents gets transformed into another with specific information needed for the next step of the process. In our case, the input needed might be what kind of house to create the design for, for example.
  
  
  • Does the process change or perform work on the information it requires?
    You have your required information, the next logical thing to explain is what exactly your are doing with that information. You have an invoice for example, you are in shipment, you'd usually gather the products of the invoice and get them ready for shipping, if something is missing you'll notify someone so they can decide what to do about the missing items, etc etc. In another situation, you might want to take that same invoice in order to call the customer (if you're in the sales department for example) and ask them what to do if an item is missing. No matter what the situation, there 's work to be done with the information you needed or the information is irrelevant to the process and should be discarded right away. In our project's case this could be, as an example, the designing of the house based on the description of the house we received from the customer.
  
  
  • Does the process produce an output that is needed at the end of the step for the next step?
    Still staying in our typical example, when you have an invoice, you gathered the products of the invoice, what output could be produced? How about a packing slip so the customer can verify what they ordered (with their invoice) compared to what they received (the packing slip) to make sure everything is in order and that nothing is missing. This is in a typical scenario of course, there are definitaly changes depending on the specific manual process to automate. In our case, this would typically be the designed house with the list of materials and costs.
  Once you have asked all the questions and decide that you have all the information you need to explain the process (or project in our case) in all it's infinite details, you can go about the creation of the detailed analysis document which consists of taking all this information and presenting it in a chronological and organized manner. you can selected the type of organization you'll need for the detailed analysis as they may vary depending on the type of process you are automating. The best way to go, usually, is to take the manual process, detail it as detailed as what you have accumulated required inputs, work and desired output. Starting from the beginning of the process, the first steps and working your way towards the end of the process explaining how the information travels from step to step, what each step does with the information it needs or how each step affect a central piece of information and what it needs to create for an output before the process can go to the following step. It is at this phase that you can start using the software engineering tool you selected if not for anything, to organize all the information you'll be collecting into functional groups or entities (in our case). Another thing you'll need to consider when selecting the software engineering tool to use is how far into the development process that tool will take you. Some tools won't take you very far in the development cycle as they are design to document more than cenceptualize a problem. Others can take you all the way to the conceptualization phase and even beyond in some cases. For our sake we'll be using UML since it does take us right down to the conceptualization phase easily.


• The Solutions Proposal Document:
  Sometimes there can be only one way to solve a problem. Other times there are several ways to solve a problem. Part of the analysis, especially towards the end is to define all the possible solutions to the problem (since we have all the details of how the problem or process currently works) and analysis what the pros and cons are for each of those solutions (you can determine the pros and cons yourself or with the help of management and/or the users depending on the process. When you have weeded out the the best solution you mught want to include the 2nd and 3rd of those solutions explaining the different impact each of these solution has as far as time lines and costs are concerned. This is, in essence, what the solution proposal document is for. To give management (in most cases since they will be the ones to accept the solution or not and give you the go ahead to it's realization) so that they can, in a very informed fashion, with the help of the detailed analysis, decide upon creating the solution, maybe bringing a few changes to the proposed solution, and make the ultimate decision to create the solution or not. Remember that as a consultant and the "specialist" of this project, you need to make sure that there is no existing solutions to your problem already available somewhere that might save your company time and money. In our case we're developing a commercial product that will be sold so there is no existing solution unless you could buy the rights to using the Autocad™ source code directly. in the example we talked about above, there are hundreds of billing software available that also produce a packing slip so maybe one of those could fit the needs perfectly and it's your responsibility to inform your boss that it exists and how well it does answer the needs of the problem at hand.

As you can see, there's alot of work involved in the analysis. But when you think of everything that this work will bring to our project, it's very easy to see why this phase should not be overlooked and infact, investing the right time needed to accomplish this phase completely and successfully will help us a great deal in the rest of the development cycle. For the sake of FinanceCAD, we don't need the preliminary analysis since we already got the go ahead to produce the software right in our original email from the boss. So then, let's go about detailing what we can for our detailed analysis document.

Just remember that in the solution proposal document is where you should mention any kind of time related or cost related constraints. These constraints should be made clear, usually in their own seperate and independant sections. These constraint will greatly affect what happens in the rest of the development cycle so they should be made known as early as possible. Such things that they could affect are, for example, the number of employees you might need to assign to the project to assure that the project is done within the time constraint. Likewise, to fit in a cost constraint, you might want to try to get the most oart of the project done by programmers of lesser experience (and salary) when the tasks are routine and repetetive. This will help fit the project within a predetermined budget. This is why it's important to consider these contraints this early in the development cycle.

APPLYING THE THEORY:

Looking at what we've learned so far in this second part, let's put this into practice. The following is a definatly more detailed explanation of FinanceCAD. Although this description will be detailed, you have to remember that the description, at this phase shouldn't contain specific programming concerns or issues but rather should server the purpose of describing FinanceCAD in all it's steps it makes available to the user in order to accomplish a complete task which is to produce a design and a list of materials, quantities and prices.

---

APPLICATION DESCRIPTION:

FinanceCAD will be an industrial design application that will allow the user to create house plans according to local design standards. The main goal of the design section of FinanceCAD is to offer a set of commands that the user can either type in using some sort of command prompt or select from a menu depending on his or her background. The application will need to fully support the mouse and the keyboard to accomodate how the user would typically work. This application will need to have specific functionality while and after the design of a house or part of a house is completed to allow to attach materials to the design and calculate prices. Because of the fast changing prices of many construction materials, FinanceCAD will need to allow to change the current prices whenever the user notices a change in the current prices. The design mode will need to work with design layers so that Items can be added to the different layers based on the user's discretion or some set of rules, this will allow for a design firm to establish design standards that their employees will be able to follow easily. Here are the major features of the application categorized in functional groups.

DESIGN MODE FEATURES:

Design mode features are features that are available to the user while he or she are in the process of creating a design. The design mode is the central part of FinanceCAD as in this section is where all other parts of the application can be accessed from. This would typically mean that the user would setup a new design or load an existing one as a first step. Then the rest of the feature would be available.

• The unit of measure and the scale of a design could be set at the beginning of the design and/or changed anytime throughout the design and have all measurements recalculated according to the new scale and/or unit of measure.
  
• Allow the direct design of parts of a house or the whole house using primitive geometric shapes such as circles, ellipses, arcs, squares, rectangles, triangles, and other basic geometric shapes.
  
• Each item added to a design (simple shape or complex built shape) can have a specific color scheme. This can be either set as the design is built or in a general fashion from a screen to allow to build color standards for all designs.
  
• Should allow to "script" commands to build specific more complex shapes and give it a name for future reference. This way, enormous time will be saved as typical components can be directly loaded instead of created each and every time.
  
• Each shape or complex shapes should have the ability to have a material applied to it's design thus allow for length calculations and ultimately prices as well.
  
• the system should allow for both mouse and keyboard input as some users are used to using the mouse while other may be keyboard driven in their operations.
  
• Assuming the design of a complete house, bricks, insulation, wood frames, electricity, plumbing and other categories of components such as these should be put on different layers, as needed, for the sake of clarity of the pricing report.
  
• standard symbols should be provided to the user for items that need to be according to some specific local or global standard that must be applied to designs that use these standards.
  
• The user should have some means of creating custom, often used shapes and symbols. For example, in an interior design firm, furniture of all types could be designed and simply inserted into new designs recalculation Units of Measures and Scales according to the scale and unit of measure of the design itself. The time gain of such a feature would be tremendous.
  

DATABASE FEATURES:

Database features are needed as many designers could have the need to work on the same design for whichever given reason. Hence Some database features are in order to allow for two users to work on a project in a very safe environment.

• Through the use of a design table, design files could be made locked by a user so that when a 2nd user opens the same design, he is warned that the other user has locked the design. This would make the design opened for read only purposes and could not be saved under the same name.
  
• Database query feature could be used to allow for flexible search criteria to be applied to a query and return valid designs for the applied query only.
  
• In the corporate world, not many things happen without a customer somewhere in there, so a list of customer to which design can be assigned to would prove a valuable feature for obvious reasons.
  
• Each design should have an optional field to give itself the need to be approved prior to allowing to print the design and send it to the customer. Many firms work this way and they have good reasons to work this way.
  
• The material and items pricing list should be independant since in most cases they are treated independantly and typical purchased from different suppliers as well.
  
• When a design request is created in the database system, the option to directly assign the design to a designer should be made available. This option could be changed at will should the need to change the designer occur.
  
• The designers should have the ability to add notes and work progress to a given design in such a way to give feedback on where the design currently stands.
  
• Once a design is given the status of closed or completed, it shouldn't be allowed to be changed unless mamagement or an appointed employee makes the design available for editing once again.
  

NETWORK FEATURES:

In most firms today, a network is present and used at the firm's best advantage. FinanceCAD should not be an exception to this. In a typical network setup, all employees have access to their user space on the main server as well as a shared drive or folder where anyone can have access (good to communicate files between users). Typically designs are file driven as in each design is saved under it's own filename. The database that works around the design file need to be centralized so that management can oversee production of the design from any given location on the network. Therefore, the following network features and considerations are required.

• The database will be centralized on the server at a location decided upon by the management.
  
• FinanceCAD will need to connect the user to the central database with the user's name and password.
  
• In the case of network failure, the user will be able to work locally with his own copy of the database.
  
• Database synchronization methods will need to be in place so that the central database can be update with new information as soon as the network is made available to the application.
  
• The detection of the network presence and the database presence on the network should be invisible to the user unless the application cannot connect to the network or find the database where it should be located.
  
• The principal of semaphores should be applied to allow a control of network traffic from the users to the central database.
  
• If a firm works by confirming or approving designs before printing can occur, the verifier should be notified (by email or other means) that a given design is ready for verification.
  

REPORTING AND PRINTING FEATURES:

Indeed, because of the nature of FinanceCAD, there is a definate set of features that are mandatory for the proper usage of the printers available to the users. These features are there to allow flexibility to the user when printing a design and it's report as well as save time (and consequently money) by not needing to wait for a printer if it's not currently available. These features are:

• A typical firm will have printers for reporting and plotters for design printing, this should be configurable from FinanceCAD.
  
• Different parts of a complete design and pricing report should be selectable to be included in the final printing as not all the parts may be required to be printed.
  
• Because of the different modes a printer can be set to via software, each printing session should start by resetting the printer to it's default settings so that there is no mode conflicts.
  
• The ability to select one or more design and reports to be printed should be available to create print jobs that could get printed overnight to save time.
  
• The ability to change the prices used in a cost report should be allowed at the design level or at the general level. This means prices could be changed just for the given design, or changed for all the designs as a new pricing list standard.
  
• Although printers and plotters to be used can be set globally or specifically for a design, the option to change which printer or plotter to be used should always be made available (in case of printer failure for example).
  
• The user should have the ability to create himself or herself custom reports on the fly to help them in the design process whenever the need is felt.
  

COMPATIBILITY FEATURES:

In todays world, it seems that if an application of any kind is to be made successful, it will need to be made to work with a broad variety of other applications that can help the user in his or her many tasks. For example, if a design is created for a client, but that client doesn't have the software and would like to see the design in the software they use, then an export could/should be made available to allow the customer to see the given design. As such, here are the major compatibility features that would be required.

• Although are native file format will be proprietary to FinanceCAD itself, imports and exports to all "popular" design software file formats should be provided for added flexibility. these format should atleast include Autocad™ and Key Software's 3D Home Designer which is what is currently being used inhouse.
  
• Databases and tables should be exportable to standard comma seperated format for usage in the customer's other applications needed for their own purposes.
  
• Reports should be exportable to Excel format, Lotus, Quattro Pro, All popular Word Processor table formats and PDF.
  

OPERATING SYSTEM FEATURES AND ISSUES:

The selected target operating system for FinanceCAD will be Windows XP. However, many design firms work with PowerPCs computers and others with the Linux operating system. Each of these work differently and are based on different sets of standards. Likewise, there is the strong possibility of porting FinanceCAD to those other operating systems. Because of these, the following features should be considered:

• Wherever possible in the development phase, we'll need to avoid creating operating system dependencies if at all possible, this will minimize the work involved when porting FinanceCAD to the other targetted operating system.
  
• The use of a higher level, multi-platform GUI library is strongly recommended. There are 3 highly recommended choices, the are the Qt library, the GTK library and wxWindows, all capable of creating similar GUIs for different platform in a very independant and self sufficient way.
  
• The local space for the database will need to be set globally on a per operating system as linux, for example, won't allow access to some parts of the harddrive unless the user is logged in as administrator which is usually and typically not the case in a typical linux system scenario.
  
• When saving a design, because of the text command nature of the file format, the user will need to be able to select the text file standard to be used when saving. Carriage Return plus Line Feed for Window based systems and just Carriage Return for Linux based systems at the end of each line.
  

SYNOPSIS OF THIS ANALYSIS:

As you can see, this analysis is, as promised, more complete than the brief description I gave you in the first part of this series. It is not quite complete for a detailed analysis but I didn't want to bore you to death with a 200 page book to read. It's important that you take note that this analysis does cover alot of bases. It does give a good overview of things you might need to consider in your own projects when determining what the application can or should do. This is how this analysis should be taken. You'll find that in most projects of any considerable sizes you will probably find yourself covering the features and feature categories I've described here so you might want to take this list as a "check list" of things to watch out for, and things that will need answers in your analysis process. Everything but some of the reporting features listed here can apply to any type of development project so I think it's a good example even if it's not as detailed as it should be, it should still prove to be a great list to build the detailed analysis with.

In our case here, because we are creating a software based on another software, there are many questions that don't really need to be asked in this scenario. However in the case where you are automating a manual process of any kind, The sample analysis above should still give you a pretty complete list of things that you'll need to consider and elaborate on.

THE CONCLUSIVE WORD:

And this concludes the second part of this series. We've covered alot of ground so far and there's still alot to be done in the rest of this series. In the next part of the series, we'll conver everything there is to know about the conceptualization phase in all it's glory and details so to speak. this way you'll know what to expect at that phase too which is the purpose of this series to prepare you in the case such a big project is assigned to you so you don't loose your nerves and your last meal in the process. Happy reading, and see you then.

Remember that I am always open for suggestions on everything that I write, if you have ideas and suggestions about this series, drop me an email and let me know about it so we can make sure that you get the best documents and techniques that you can get.

MystikShadows
Stéphane Richard
srichard@adaworld.com