 |
Ned Bingham
December 10, 2001
Good Software Engineering surrounds us daily1. As we work, play, travel and communicate we are using, at some level, someone else's software. For a select few of us, this software is not just someone else's software; Its ours. As Software Developers, some of us have the luxury of knowing what goes on behind the scenes while writing a program. We know how to fine tune the various parts of the process, allowing for the time taken by one or more steps to be dramatically shortened or even completely eliminated. It is this knowledge that allows us to produce good software efficiently. In many cases, it is our planning during the development stages of our code that produce the ``flawless'' programs that exist today and upon which we all rely. To the lay-person, these steps may appear three-fold [4, p15]:For the majority of my project I have been (and will continue to) focus on the Requirements Analysis stage of the development. My reason for this is I feel that it is one of the, if not the, most crucial steps which determines whether or not a project will fail or succeed. For example, if the designers/builders of a bridge started building it not knowing that there were going to be heavy 18 wheeler trucks going across, but instead planned for the load of pedestrians, what would happen when the trucks started crossing? Or even more plausible, what if they found out half way through construction? What type of costs would be associated with correcting the oversight? In both cases the oversight would have caused major costs and failures. This analogy can be placed directly upon software construction. If you are tasked with building a program for which you were given no specifications, if you failed to do proper research into what the program/utility was supposed to do, you'd be in huge amounts of trouble fairly quickly. As McConnell [5, p26] points out that the longer it takes you to find a problem that exists in your design, the more it will cost you to fix it when you do find it. This is why without a good and exhaustive Requirements Analysis to find the problems in your design, your project is going to fail or not live up to what it is supposed to. Bugs in the implementation, due to programmer error4, can always be changed. What becomes more and more inefficient to change are bugs/problems that may be in the underlying design which may cause the entire project to be scratched and redone.
So right about now, you might be asking yourself ``OK, So what's actually involved in proper Requirements Analysis?'' Well, there are many different steps which are involved in the process of Requirements Analysis. Many authors have produced check-lists [5, p33] which can be used to by the programmer to determine if he/she has gone through all of the ``necessary steps.'' The main problem with check-lists is not that they are not all that helpful, but rather they tend to get in the way and defeat their purpose. The way that people tend to use check-lists is to look at the first thing on the list, do it, check it off, and then go on to the next. This hinders creativity and adaptation. Because of this, there is no fixed method for going about Requirements Analysis. The best way that one can describe how to do Requirements Analysis is to explain what it is.
So, what am I doing for this aforementioned project? Here at Earlham College, there is a fairly extensive Ethernet Local Area Network (LAN). This network supports the computer infrastructure that is used by Faculty, Staff and Students for education, college business and entertainment. Spanning all of the campus buildings, it provides full time Internet connections to any machine connected to the network. Presently, in order to obtain access to the network, you must register your computer with Earlham Computing Services (ECS). This registration involves the configuration of both the Dynamic Host Configuration Protocol (DHCP) Server & Domain Name Server (DNS) along with some management of the network ports around campus. Currently this process is managed and executed by one or two individuals. This means that for every computer that arrives on campus that needs Internet/network access, these individuals must personally manipulate the configurations of the respective services. During the ``crunch-times'' of the year, this means dedicating almost one full day (if not more) to doing this re-configuration. Initially, when the number of computers on campus requiring network access was few, this method was acceptable due to the low overhead. However, the increased number of networked computers on campus, along with the number of new computers arriving weekly, has made this current system extremely inefficient with respect to man-hours required to make changes/additions. When confronted with the opportunity to replace the current system with one that increases automation and has the potential for spreading the work-load across more than one or two people, the Network and Systems Managers here were enthusiastic and optimistic. So, my goal has been to create a Network Management tool which allows for configurable complex heterogeneous network configurations and allows more automated addition (and removal) of machines from the network.
The method by which I chose to proceed involves a series of meetings with the Network & System Administrators here at Earlham, interspersed with periods of ``reflection'' and thought which allow me and those involved to think about and discuss the requirements requested. The advantage and purpose of this ``reflection'' period is to allow for ideas to stew and simmer until they are exactly what is desired by the people involved. This then leads into structurally modeling the interactions between the various parts of my program and the users, eventually leading up to the creation of structural models of the actual program and most if not all of its working components. After I have this schematic built on paper, it is time to start with the implementation of the program into pseudo-code and then program code. Before this step, I will have not touched a single piece of code for this program. The intent is to model everything in a suitable modeling language. For this project, I will strive to use UML. My plan includes continuing to meet with the Network & System Administrators here so as to prevent any mis-understanding about the actual inner workings of the program. There isn't a fixed schedule for this stage since it tends to spread over a fairly large time period and therefore meetings will occur whenever they are needed. Once the code is written and running, we begin the debugging and testing stage. This is where we determine where the problems in the program are and work out any major bottle necks. Hopefully, assuming that the design is proper and has no problems, we will not find anything so large at this stage that it can't be fixed quickly. Finally, after having been tested (and satisfactorily passed), the tool will be ready for final integration into the current system. This is the methodology5 by which I am compleeting this project.
Sofar, I've made it to the Program Modeling stage of my methodology. I have been able to create all of the UML diagrams to depict all of the interactions and the actions taken by the actors in my system. The next step, as I say above, is to start producing actuall code to do what I've designed. Due to time constrainst and my mortal shell, I will not be able to start that part by the completion of this paper. My current plans are, however, to begin coding sometime next month (January 2002)
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.47)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html project-paper
The translation was initiated by Ned Bingham on 2001-12-10