|Layer Number||ISO Layer||Functional Description|
|7||Application||services and programs|
|6||Presentation||translation across networks|
|5||Session||setting up and ending connections|
|3||Network||find other networks|
|2||Data-Link||media access and links inside a
|1||Physical||wiring, bit transmission, sending and receiving network signals|
The author explains that this approach begins with questions
about what the users will do on this network. We want to know, as layer
7 suggests, what applications
will run on this network. We also want to know who will use those applications and what the goals are for their usage. Although
the author has not really explained either approach yet, she allows
that we could us a bottom-up approach (which she calls "connect the
dots") if our user's applications and goals are well known.
The top-down approach should seem familiar to you if you have taken classes about structured approaches to creating applications or computer systems.
An introduction to a structured approach appears on page 5:
The creation of a logical model before the physical model supports the concept of starting at a high level and working into the details after you define the big picture.
The text continues its background material with a discussion of the Systems Development Life Cycle model. This model can be used to create a new system or to revise an old one. It s a cycle because it is meant to be repeated any time a change is needed or desired.
The author tells us on page 6 that there are four phases in the design part of the life cycle version she favors. She shows six phases in the graphic on page 7, which include two phases for implementation and monitoring. Those phases are not included in the discussion in this chapter.
The four phases in the design portion of the cycle (top to bottom, clockwise) are discussed briefly:
The text also presents a Cisco version of a network life cycle which condenses the logical and physical design steps above into one step. This may cause the reader to wonder whether each phase of such a project is the same length or importance as the other phases. The Cisco version separates the Test and Optimize phase in the model above into two separate phases. It also adds an eventual Retirement phase, placed in the center of their cycle wheel because it could happen at any time. All computer hardware and software will eventually need replacement, and that need may arise no matter what phase of a cycle we happen to be using at the time
This section is very much like what you should have seen in a System Development class. The text makes a point of discussing this phase as gathering business goals. If you are working with a client you have known for years, you may know their business already. If this is a new client, you should follow the advice in the text to research the client's business, especially by talking to and observing the client's staff as they work. It is also important to know something about the organization of the client's company for two reasons.
If you understand why the network addition or change is necessary to the client, you will have a way to judge whether the project is successful. Learn what the customer needs, what the customer wants, and how success will be measured from the customer's point of view.
Some of these ideas appear in the list of common business goals on pages 13 and 14.
This part of the text discusses measuring the size of a project. It advises you to ask the customer about all the requirements, but be aware that it is unlikely that the customer is well versed in network design needs, so they often will not be the best judge of what the project needs or how long it will take to finish it.
The text suggests we start a scope analysis with the OSI model. The model itself does not discuss network projects, but we can examine the project request in terms of which layers the project will touch. To do this, you will have to keep a high altitude view of the project, since every network transmission from any application will pass through all seven layers of the model. The text is a bit more helpful with a list of terms on pages 15 and 16 that can be guidelines for the extent of a project:
The text takes another point of view as its next premise: that networks exist for applications. Some applications can run on a network or not, but some require a network to offer any value to the customer. If you are having trouble deciding if an application is a network application, remember a definition of a network. Networking can be defined with five features:
Each of the words in bold or in a color in the list above represents a separate component in the definition. When users are sharing data, printers, or cable runs, there is a network involved. The text offers a long list of application types on pages 17 and 18. It is not a complete list, and it probably never can be complete. Some of these types can work as standalone installations, that is, you don't have to have a network to run them. When you survey a customer about their applications, keep this in mind. Don't just ask about their network applications. Ask about every application that uses a network service or resource. The list should be longer when you ask this way.
When using the survey form
on page 16, you should also make sure to note the applications that are
used to manage the network
itself, or to manage devices that are part of the network. They
probably fit the smaller list of types on page 18. Note that there is a
wider version of the survey tool on page 54. This version asks for more
details about each application.
At the end of this short section, the text examines another column on the survey tool: criticality. It would be pointless to ask users to put a value in this column until you explain what the word "critical" means, and how to score their applications. The ranking on page 18 seems a bit vague to me. It only offers three choices:
If you don't see the problem, try substituting the word "dead" for the word "critical". Are the first and second choices actually different? How can I tell whether an application belongs in the first category or the second? Doesn't there seem to be a wider gap between the second and third choices than between the first and second choices?
Critical is not a word that works well with adjectives.
Instead of this approach, it might be better to take a time related approach. If this
application stopped working, how long could you wait for it to be functional again? How long could it be down before it affects
This is not only more granular, it is a question the users and
managers may be able to answer in a way that will allow you to tabulate
and compare those answers. Don't be surprised that different users will
have different priorities.
The last major topic concerns finding and dealing with the
things about the project that you cannot change. That's what a constraint is: something you have to
accept, work around, or make a feature in the project. There will be
constraints on most projects that will affect your plans, so you should
know about them as soon as possible. And I would recommend reciting the
serenity prayer to yourself, whether you have a religious faith or not.
If that doesn't do it for you, remember a quote from Robert Heinlein: "Never try to teach a pig to
sing. It wastes your time, and it annoys the pig." He wasn't talking
The text offers some advice about things to watch for. The first discussion is about the internal policies and politics of the customer's organization.
The second major discussion is about money and staff. These are related concepts, which you know if you are familiar with the idea that a project can be fast, cheap, or good, but you can only have two out of three. Notice that there is no point in the figure on the right where all three colors overlap. (Listen to the testimony of Lucas Martell. Yes, an animation project is an IT project.)
The text points out that a project that requires new hardware may also require licenses for software. The hardware may also have an ongoing expense for maintenance, whether done by your own staff of by a service provider. If you are adding new staff as part of the design, there will be payroll for the staff, and often training expenses for them.
The third discussion is about scheduling
the project. The date the project is due to be be completed is
important, but the text reminds us to schedule milestone events along the way. The
purpose of a milestone is to celebrate
the completion of something, often a major part of a project.
Milestones also exist to tell us whether we are or are not on schedule to meet that
end date. If we reach a milestone later than we should, we should
consider changing the due date or changing what we are doing that is
The text recommends that we consider using standard tools to analyze the flow of our projects. We should update the customer about problems as they arise and renegotiate the schedule as needed.
The chapter ends with a checklist that summarizes the
information you should gather about a project before you can be sure
you will be able to complete it. There is a similar list at the end of
chapter 2, but we will start the first assignment for the
class with elements from Chapter 1.
Week 1 Assignment: Chapter 1