Adriatico's Blog

You will need a few tools for your work. I have provided them on the CD that comes with this book. Please resist any temptation to use tools from elsewhere. They will be excellent when you have gained confidence and fluency with programming. However, their complexity will overwhelm you while you are struggling to learn to program. It is enough to try to do something new without also trying to do it in an unnecessarily complicated environment.
You also need something to manage these tools with rather than having to remember every detail for yourself. Programmers use things called IDEs (Integrated Development Environments), which are rather like carpenters’ workbenches. Those that come with commercial compilers, or even the free ones that are used by experienced programmers, have a multitude of options that will simply get in your way and lead to confusion. (No differences here, then; professional work environments are rarely suited to the newcomer.)
So I have chosen a very simple IDE written and maintained by Al Stevens. He calls it Quincy and it provides just what we want: enough to work with but no frills to get in the way. If you have followed the instructions for installing the software you will have installed Quincy somewhere on your system (perhaps on the C drive, but possibly somewhere else; I have my copy on my E drive). You should have an icon of a cat’s face on your desktop. Click (or double-click, depending on how your system is set up) on it to open Quincy.

There are some things that you need to do every time you prepare to write a new program. I am going to walk you through them this time with images from my screen to help you. Until you get used to it, come back to this section each time you start a new program and follow through these steps.

• Create a new project Select ‘‘Project’’ by double-clicking on it (or click and select ‘‘OK’’). Type ‘‘my first program’’ (get into the habit of giving descriptive names to projects and other files) in the Target name box. Use the browse button to find the sub-directory. You should find that in the directory called ‘‘tutorial’’ on the drive where you installed the tools from the CD. When you have found it, left click the OK button in the browse dialog box. Check that the ‘‘Type of Build’’ selected is ‘‘Console application’’.
• Set the project options Select the ‘‘tools’’ menu and choose options. You should see the image at the top of the next page. Make sure that the boxes have been selected as in this image. Then use the browse button beside the Includes box to find the sub-directory called ‘‘fgw headers’’. That should be one of the other sub-directories in the same place. Click OK in the browse dialog and then click OK in the Options dialog box.
• Get the special libraries Much of the programming you will be doing relies on two special files. Do not worry about exactly what they are; they contain resources that one of the programming tools will need. You have to find these two files and include them in the project. Click on the Project menu and select ‘‘Insert Files’’. You should then use the drop down menu in the dialog box to find the fgw headers sub-directory. You should then see something like this (the exact file list may be different, but the two important files fgwlib.a and libgdi32.a should be there. (If they are not in the sub-directory, your installation from the CD is faulty. Copy the contents of the fgw headers directory on the CD to tutorial\fgw headers.)
• Save the project Go to the File menu in Quincy and save the project.

System Boundaries Identification
Let’s establish the scenario. We have been called by a local car dealer to submit a proposal about a new information system. The stated goal is to produce reports about car sales and to help track the car inventory. Reports are, of course, an output of the future system. The idea hidden behind reports could be to improve sales, to understand delivery delays, or to find out why some cars disappear. The data structure itself is probably not really important in the users’ opinion, but we know that this structure matters to the developers who produce the required output.
It’s important to first look at the project scope, before starting to work on the details of the system. Does the project cover:

• The complete enterprise

• Just one administrative area

• Multiple administrative areas

• One function of the enterprise

When preparing a data model, the biggest challenge is probably to draw a line, to clearly state where to stop. This is challenging for various reasons:

• Our user might have only a vague idea of what they want, of the benefits they expect from the new system

• Conflicting interests might exist between our future users; some of them might want to prioritize issues in a different way from others, maybe because they are involved with the tedious tasks that the new system promises to eliminate

• We might be tempted to improve enterprise-wide information flow beyond the scope of this particular project

It’s not an easy task to balance user-perceived goals with the needs of the organization as a whole.

Modular Development
It is generally admitted that breaking a problem or task into smaller parts helps us to focus on more manageable units and, in the long run, permits us to achieve a better solution, and a complete solution. Having smaller segments means that defining each part’s purpose is simpler and that the testing process is easier – as a smaller segment contains less details. This is why, when establishing the system boundaries, we should think in terms of developing by modules. In our case study, a simple way of dividing into modules would be the following:

• Module 1: car sales

• Module 2: car inventory

Model Flexibility
Another point not directly related to our user but to us as developers is: can the data model be built to be flexible and more general? This way, it could be applied to other car dealers, always keeping in mind contract issues between the developer and the user. (Who will own the work?) Should the data structure be developed with other sales domains in mind? For instance, this could lead to a table named goods instead of cars. Maybe this kind of generalization can help, maybe not, because data elements description must always remain clear.

Document Gathering
This step can be done before the interviews. The goal is to gather documents about this organization and start designing our questions for the interviews. Of course, a data model for car sales has some things in common with other sales systems, but there is a special culture about cars. Another set of documents will be collected during the interviews while we learn about the forms used by the interviewees.

General Reading
Here are some reading suggestions:

• Enterprise annual report

• Corporate goals statement

• President’s speech

• Publicity material

• Bulletin board

Forms
The forms, which represent paperwork between the enterprise and external partners, or between internal departments, should be scrutinized. They can reveal a massive amount of data, even if further analysis shows unused, imprecise, or redundant data. Many organizations suffer from the form disease –a tendency to use too many paper or screen forms and to produce too complex forms. Nonetheless, if we are able to look at the forms currently used to convey information about the car inventory or car sales, for example, a purchase order from the car dealer to the manufacturer, we might find on these forms essential data about the purchase that will be useful to complete our data collection.

Existing Computerized Systems
The car dealer has already started sales operations a number of years ago. To support these sales, they were probably using some kind of computerized system, even if this could have been only a spreadsheet. This pre-existing system surely contains interesting data elements. We should try to have a look at this existing information system, if one exists, and if we are allowed to. Regarding the data structuring process itself, we can learn about some data elements that are not seen on the paper forms. Also, this can help when the time comes to implement a new system by easing transition and training.

Interviews
The goal for conducting interviews is to learn about the vocabulary pertaining to the studied system. This is about data structures, but the information gathered during the interviews can surely help in subsequent activities of the system’s development like coding, testing, and refinements.

Finding the Right Users
The suggested approach would be to contact the best person for the questions about the new system. Sometimes, the person in charge insists that he/she is the best person, it might be true, or not. This can become delicate, especially if we finally meet someone who knows better, even if this is during an informal meeting.
Thinking about the following issues can help to find the best candidates:

• Who wants this system built?

• Who will profit from it?

• Which users would be most cooperative?

Perceptions
During the interviews, we will meet different kinds of users. Some of these will be very knowledgeable about the processes involved with the car dealer’s activities, for example, meeting with a potential customer, inviting them for a test drive, and ordering a car. Some other users will only know a part of the whole process, their knowledge scope is limited. Due to the varying scope, we will hear different perceptions about the same subject.

Asking the Right Questions
There are various ways to consider which questions are relevant and which will enable us to gather significant data elements.

Existing Information Systems
Is there an existing information system: manual or computerized? What will happen with this existing system? Either we export relevant data from this existing system to feed the new one, to completely do away with the old system, or we keep the existing system – temporarily or permanently.

Chronological Events
Who orders a car for the show room and why; how is the order made – phone, fax, email, website; can a car in the showroom be sold to a customer?

Sources and Destinations
Here we question about information, money, bills, goods, and services. For example, what is the source of a car? What’s its destination? Is the buyer of a car always an individual, or can it be another company?

Urgency
Thinking about the current way in which you deal with information, which problems do you consider the most urgent to solve?

Avoid Focusing on Reports and Screens
An approach too centered on the (perceived) needs of the users may lead to gaps in the data structure, because each user does not necessarily have an accurate vision of all their needs or all the needs of other users. It’s quite rare in an enterprise to find someone who grasps the whole data picture, with the complex inter-departmental interactions that frequently occur.