Final Project Proposal
CS-80--Senior Seminar
Fall '01

Ned Bingham

December 10, 2001

Good Software Engineering surrounds us daily¹. 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 effeciently. 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 as three-fold [4, p15]:

1. Analysis
2. Design
3. Implementation

Actually, when many people think of programming, they think just of the 3rd step, and it never crosses their minds to think that you actually have to think about what you are going to do. But to our ``trained eyes'' we know that there is actually much more going on. We know that there is no real concrete method for going through the development process. As a matter of fact, some of us may not even develop one project the same way as we develop the next. However, there are most definitely several steps that we all take when developing a piece of code (whether or not we do them consciously). These steps would most likely be characterized as such [4, p16]:

1. Requirements Determination
2. Requirements Specification
3. Architectural Design
4. Detailed Design
5. Implementation
6. Integration
7. Maintenance

Now, I'm most definitely not saying that this is the one and only solution to the development process (I myself combine many of the related steps above). This listing is solely to demonstrate on of the many ways in which you could break up the development process for a program/project. For my purposes I have broken up the design process into 3 basic steps:

1. Requirements Analysis
2. Program Design
3. Implementation

Also 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. Code problems can always be changed, but the underlying design can't always be changed.

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 helpful, but rather they tend to get in the way and defeat their purpose. Through my reading and research, I have determined some of the more important steps or phases of Requirements Analysis:

• Problem Definition

  Determining the actual problem that you are faced with. As in the bridge building analogy that I gave above, if you don't know precisely what it is you are going to be doing, then you could end up doing the wrong thing. You need to make sure that you know what exactly it is that your program/project is supposed to do so that you can create the correct program.

• Conceptual Analysis

  Examining the project to determine if its possible to complete. Can you actually do this program/project? Some projects end up dying due to the sheer fact that it is not possible to even complete them. Make sure that your goal is well defined (previous step) and make sure that it is actually possible to complete the project. This evolves both responsible scheduling and planning at the beginning to make sure that you have the time yourself to accomplish the goal successfully within the time allotted.

• Requirements Determination

  What are the requirements of the program? What features do the consumers/administrators want in the problem? What is a ``Requirement?'' Well a requirement could be simply stated as ``a statement of a system service or constraint.'' [4, p16] What is it that the user wants the program to do, or not to do? This is the stage where you first get into determining the features that you will be including into the program. This is also where you find out where you need to restrict the functionality. Whether that be via user identification, or sheer omission from the program. This is not really the point where you refine the list and therefore you will be creating more of a ``wish list'' from the users. You also should use this time to find out if your user-base too believes that there is a problem that needs solving. If your users don't feel they have a problem, then your solution (the program) will have no effect and thereby be useless.

• Requirements Specification

  Defining the inter-relationships between the various requirements and the user(s). This phase is the last part of my process of Requirements Analysis. This step contains a good part of the design of the program, since it determines how the various features interact and how the users interact with the program. Traditionally, this step involves modeling the problem and potential solution in UML (Unified Markup Language). This allows you at the programmer to track, via an object oriented model, the path of data and the actions taken based upon a given data-set. When it is not possible to take an object-oriented approach, it is possible to take more of a structured approach which is much more function-centric vs. data-centric [4, p24-25].

It is these steps upon which I am focusing on for this project.

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 due to 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.

My goal is 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. This may or may not include premade solutions for part or all of the package, which will be determined during the research and Requirements Analysis stages.

Bibliography

1

Christopher John Date.
An introduction to database systems.
Addison-Wesley, 7th edition, October 1999.

2

Dick Hamlet and Joe Maybee.
The Engineering of Software.
Addison-Wesley, Boston, 2001.
Technical Foundations for the Individual.

3

IEEE Computer Society, New York.
Guide for Developing System Requirements Specifications, 1998.

4

Leszek A. Maciaszek.
Requirements Analysis and System Design.
Addison-Wesley, Harlow, 2001.
Developing Informatoin Systems with UML.

5

Steve McConnell.
Code Complete.
Microsoft Press, Washington, 1993.
A Practical Handbook of Sofware Construction.

6

PostgreSQL, http://www.postgresql.org/idocs/.
PostgreSQL Interactive Documentation, 2001.

7

Larry Wall et al.
Programming Perl.
O'Reilly, 3rd edition, July 2000.

About this document ...

Final Project Proposal
CS-80--Senior Seminar
Fall '01

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-proposal

The translation was initiated by Ned Bingham on 2001-12-10

Footnotes

... daily¹

and so does bad Software Engeneering for that matter