The report of the Virginia Tech Review Panel came out yesterday. It is 247 pages long and contains 93 specific recommendations. I would summarize my take-away like this:

• Do not let the existence of a procedure, policy, or even a law — no matter how well intentioned — be an excuse to not use your brain.

To apply that to IT folks:

• Do not build systems that prevent people from using their brains.

I am trying to phrase things positively, because they are easier to understand, so let me turn that around:

• IT people should build systems that enable and encourage people to use their brains.

——–

The other day, Kevin Morooney made an interesting blog post. I thought it contained a few useful nuggets. Kevin is talking about a podcast where Jon Udell speaks with Greg Elin, chief architect with the Sunlight Foundation:

The notion of agile development, not just as a software development methodology but also as a project management methodology was brought up again and again. I know there are folks in ITS and all over Penn State who are talking about and have embraced both concepts. We’re having lots of discussion about project management in ITS right now — I highly recommend a listen from that perspective too.

That was enough to get me interested.

I gave the podcast a listen and thought this passage was really relevent. In their discussion about development within the Sunlight Foundation, John and Greg are talking about a concept they call bootstrapping in regards to giving the public access to data:

Jon Udell There was always the notion that we would put this stuff out there, but we never really expected anyone would be interested or would want to do anything with it. And, you know, this notion that you can kind of bootstrap this process of getting people engaged with the data. At which point it actually creates a demand. People start to see the stuff — be able to work with it — and then, now we realize that we really did want public to mean something a little more.

Greg Elin John? You can come here and do my job. I mean, I think that’s an excellent articulation of it.

I think that, you know, the Internet also teaches us that you have to bootstrap things. You don’t want to. The big technology projects that fail are the projects where you have a long list of requirements and people are going to work for many years, or you have a very detailed [specification] of what the future is going to be like. And you know, those are the projects that they’re outdated before they launch. Whereas the Internet, where the approach of rough and ready consensus — let’s define the minimal amount of protocol that we need to standardize communication and let everybody have a go at it — and let it iterate really rapidly.

So now, I am interested. I do not want to manage the projects that fail. I want to learn more about agile development, which I had written off as just another fad. It turns out that a set of principles embodies the philosophy of agile development. I will paraphrase a few of them:

• Satisfy the customer through early and continuous delivery of valuable products and services

• Deliver working products and services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

• Continuous attention to technical excellence and good design enhances agility

• Simplicity — the art of maximizing the amount of work not done — is essential

• Working products and services are the primary measure of progress

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

My first reaction (not invented here) was, “Sure. That’s all well and good for you software types, but try that when you have to select a new router platform before you can even begin.” But I gave it a little more thought and realized that — perhaps by accident — we were actually already applying these principles.

Take the ITS Firewall Service as an example. When we initially developed the service, we had a specific application in mind. For that application, we made design assumptions — perfectly valid ones when taken in context — and we developed a service that satisfied that application. It turns out that those same assumptions make it less than suitable for many other applications.

Instead of starting over from scratch, we have been making a series of small changes that each contributes to a more useful service.

• In March, we made a private fiber rate exception. This allowed units to affordably collapse networks in multiple buildings — fed from a common hub — behind a single firewall.

• In May, we made a change to the policy on installation and maintenance of local area networks that added the option for full or hub-only maintenance networks behind a customer maintained firewall, giving units the options to provide their own firewall without losing TNS maintenance.

• In July, we made pricing changes to make the firewalls themselves more affordable.

• Now, we are working on a multi-port firewall service that will allow units to take advantage of more of the capabilities of the TNS maintained firewall.

These are all small steps. Each one designed to make the service more attractive to more people. Early and continuous delivery of valuable products and services. Working products and services, delivered frequently, from a couple of weeks to a couple of months. Well designed and technically excellent. Each kept simple. Showing progress with working products and services.

Wait a moment! We are agile!

If we had compiled a list of all the requirements for the perfect firewall service (we did) and waited until we had the perfect service before making anything available (we didn’t) then all of the people who have benefited from these changes would still be waiting. The project would have failed because it would have been outdated before we finished.

Of course, any time you pick one thing from a list as the thing you are going to do next, someone is going to be frustrated that you have not chosen the thing that they wanted. Perhaps that is where reflecting on how to become more effective comes into play.

——–

Points to be Addressed in a Proposal for a New Service:

1. Why is the proposed service believed to apply to the case at hand (what is the purpose for wanting to add the service, what are the user issues, what deficiency is thought to exist)?

   High-level authorities within Penn State have recently made strategic changes to the network firewall philosophy, dramatically increasing the demand for the ITS Firewall Service. In addition, changes to the Private Fiber policy have changed some of the design assumptions of the existing service, since departments can now collapse multiple buildings and subnets to a single physical backbone connection point. Coincidentally, the devices providing the existing service provide multiple interfaces. ITS could modify the existing firewall service to support these existing interfaces to create a new service that maps well onto these new conditions.

2. Would this service apply or be beneficial to others at UP?

   Yes. This service would apply anywhere multiple networks home to a single physical location. Many colleges and campuses already have this network topology or will shortly with private fiber requests.

3. Would this service apply to all University locations?

   This service applies to any University location served by a 100M or 1000M Ethernet Integrated backbone connection from the PSU core.

4. What are the benefits to this service over existing offerings, or does this service provide something completely new (from a global perspective, not a single case perspective)?

   Under the existing service, the firewall is a two-port device with one interface connecting to the router and the other connecting to the local area network. A unit could place an aggregation device — a switch — in front of the firewall to combine separate local networks, but they would share a single set of firewall rules. Units desiring separate firewall rule sets for each network would require multiple firewalls. This approach consumes more University resources, both from the standpoint of the cost of the firewalls themselves and the router interfaces they use.

   Under a modified service, the firewall is a multi-port device. While one interface still provides the router connection, the others would all be available for use on the local area network with the ability to apply a separate firewall rule set to each. The University would save by not needing multiple firewall devices and by using only a single router interface.

5. From a strategic standpoint, what are the long-term benefits/drawbacks of providing the service?

   The firewall devices can support a multi-port configuration. They provide more throughput in that configuration than with a two-port configuration. However, they do not provide as much throughput as multiple standalone firewalls would. Even if this were not the case, the multi-port configuration is naturally limited by using a single router interface, as opposed to multiple router interfaces with multiple standalone firewalls.

   On the other hand, the multi-port configuration would reduce the routers processing load for any traffic between the local area networks. By definition, these devices tie together networks within an organization. As such, it is likely that much of the traffic would remain within the local networks. This traffic would not be rate limited by the router interface. The organization might see improved performance while reducing the load on the core routers.

   In addition, when used in this configuration, the firewall can only support eight subnets per interface.

6. Can the service be provided by another University group or by an outside third party?

   Any organization within Penn State is free to implement their networks in any way they desire. However, in order to have TNS maintain a network behind a firewall, the network must use the ITS Firewall Service. ITS has recently added an option to the TNS local area network Installation and Maintenance policy. The new option has made TNS support available for the LAN behind a customer’s firewall if specific criteria are met.

7. What options does the user/customer have if TNS does not provide the service?

   The customer could use an aggregation switch behind the firewall but this would not provide any firewall capability between the networks. The customer could purchase multiple firewalls which increases cost significantly. The customer could procure a multi-port firewall from another vendor. However, TNS will not provide maintenance for a network behind a customer provided firewall since it violates the concept of “contiguous maintenance.” ITS has recently added an option to the TNS local area network Installation and Maintenance policy. The new option has made TNS support available for the LAN behind a customer’s firewall if specific criteria are met.

8. What are the proposed one time, recurring and usage rates for the service, and how do they compare to other available options (assuming there are any)?

   Assuming only the existing interfaces on the firewall, the existing price structure could apply.

9. What are the operational support issues — do spares need to be carried and how many are suggested, does it use proprietary equipment, what are the delivery (lead) time issues?

   Assuming only the existing interfaces on the firewall, no additional firewall spares would be required.

10. What are the training issues for operations, ITS user training staff and user training

    Very little additional operational training would be necessary as the existing ITS Firewall Service components would be used. We would have to educate users on the additional level of complexity involved with multi-port interconnections. That is, they need to be concerned about firewall rules between ports, as well as between the local are network and the backbone.

    Because of these added rule complexities, we do not believe it is feasible to provide an equivalent of our “Basic Firewall Service.” We believe that any customer asking for the multi-port firewall service would have to get the “Custom Firewall Service” where they define the rules.

11. What are the start-up costs (including operational support and training costs) for TNS

    Startup costs would be minimal. We could start assuming that only the existing firewall interfaces would be available. If customer demand for additional interface types and numbers was sufficient, we could consider adding them in the future.

12. What are the technical issues — will technology changes make the service unnecessary in the future, is it a mature technology or prototype, has it been proven (tested) to work in the applications suggested (and what was the process for testing), what are the expectations regarding reliability, can it be applied to the existing infrastructure, etc.?

    This enhancement to the ITS Firewall Service will use the existing hardware and software which we have been using for the last four-plus years. Although ITS has not used the equipment in this way, most non-PSU deployments use the devices with multiple ports. NP&I will conduct testing of each firewall offering chosen for this service to determine expected throughput for various configurations.

13. Will new equipment be required?

    We would be willing to offer this service on any firewall we have deployed that has additional ports available. Some of the smaller, early devices only had one extra port. The remainder had two extra ports.

    • If applicable, what exactly is the proposed equipment (manufacturer and model numbers)?

      Current offerings are:

      • Nokia IP560 Base System (Large Firewall)

      • Nokia IP390 Base System (Medium Firewall)

      • Nokia IP260 Base System (Small Firewall)

    • If applicable, what is the expected life cycle of the equipment (is it stable or will it require frequent change-outs until the technology stabilizes)?

      There has been rapid evolution in the hardware platform to date. However, the vendor made these changes to bring their manufacturing processes in line with Europe’s green manufacturing laws. We believe the product line should be more stable from now on.

14. What is the projected start date for this service?

    The only efforts I believe are required to place the new service into production are:

    • Document test results showing actual performance of the existing hardware in the proposed configuration

    • Create the internal ITS pre-announcement

    • Inform TLT Training Services

    • Review TNS workflows

    • Determine rates and billing procedures — although, I would recommend the existing structure

    • Deploy an “Operational Trial.”

    • Announce the new service

    Of these, the length of the Operational Trial will largely determine when the service will be generally available. We believe this service could be offered within 90 days.

——–

Points to be Addressed in a Proposal for a New Service:

1. Why is the proposed service believed to apply to the case at hand (what is the purpose for wanting to add the service, what are the user issues, what deficiency is thought to exist)?

   The Classroom and Lab Computing (CLC) group within Teaching and Learning with Technology (TLT) has a requirement to periodically re-image all of the classroom and lab computers. So that this does not interfere with the operation of the classrooms and labs, CLC performs this operation while the students are away during session break. As the university has moved to increase the utilization of its on campus facilities, it has continued to shorten the time when there are no students on campus. Currently, the time is short enough that the gigabit link provided by the Integrated Backbone (IB) to the CLC central servers does not have the capacity to transfer the amount of data needed in the time available.

   While we do provide a 10 Gigabit Ethernet service that provides more capacity, the technology involved would require a prohibitively expensive wholesale infrastructure replacement for CLC in order to solve a problem that only occurs for about a week a few times a year.

   By providing a backbone service that uses IEEE 802.3ad Link Aggregation Control Protocol (LACP) we can bind together either two or three standard gigabit interfaces into a single logical channel providing additional capacity using the existing CLC infrastructure.

2. Would this service apply or be beneficial to others at UP?

   This service would be beneficial to any organization within Penn State with bandwidth requirements that exceed 1 Gbps but do not merit the cost of a ten-fold increase.

3. Would this service apply to all University locations?

   This service would apply to all University locations where we currently provide gigabit Ethernet backbone service. We will not provide this service for connections to the redundant router.

4. What are the benefits to this service over existing offerings, or does this service provide something completely new (from a global perspective, not a single case perspective)?

   This service provides an incremental bandwidth improvement over the existing choices of 1 Gbps or 10 Gbps. The technology required to support 10 Gigabit Ethernet is relatively new and expensive. The technology required to support link aggregation is well established and is likely already available in the currently deployed infrastructure.

5. From a strategic standpoint, what are the long-term benefits/drawbacks of providing the service?

   The strategic benefits of providing this service are mainly in the area of improved resource utilization. At first it might seem that this proposal would consume additional router interfaces. On closer inspection we would find that any customer in this situation probably already has multiple backbone interfaces in an effort to distribute the load of their application, typically with reduced efficiency. Binding those interfaces using LACP allows us to get greater application efficiency using the same physical resources.

   The situation is reversed when moving the customer to 10 Gigabit Ethernet. Currently, router blades supporting 10 Gigabit Ethernet are expensive and low density. Each one consumes a chassis slot that could be used for other, higher density applications. While the 10 Gigabit Ethernet service is valuable for those that have a genuine need, we should preserve the scarce resource for them, and not use it for applications that only occasionally need more than one gigabit.

6. Can the service be provided by another University group or by an outside third party?

   Only TNS can provide this service since it involves the method for connecting to the Integrated Backbone.

7. What options does the user/customer have if TNS does not provide the service?

   They can impact the use of their service, or they can undertake to re-architect their infrastructure and find corresponding budget resources.

8. What are the proposed one time, recurring and usage rates for the service, and how do they compare to other available options (assuming there are any)?

   A customer that currently has the Gigabit Ethernet Integrated Backbone Service pays a one-time fee of $1,000 and no monthly fee.

   If their bandwidth requirements exceed one gigabit, they can upgrade to our 5 Gigabit Ethernet Integrated Backbone Service — using a 10-gigabit physical Ethernet that we throttle to 5 gigabits. In this case, the customer pays TNS a one-time fee of $6,000 and a monthly fee of $375.

   There are also infrastructure costs involved, as equipment to support 10-gigabit Ethernet is relatively new. In the case of CLC, they currently use HP 2848 switches to terminate the backbones in question. The equivalent switch with 10-gigabit capability is the HP 3500yl-48. The CDW cost for this switch, equipped to accept 10-gigabit Ethernet is $8,718.98.

   So, in this example, the cost difference for CLC to move from an existing gigabit to a new 5-gigabit service is on the order of $15,000 one-time and $375 per month.

   On the other hand, using LACP, the existing switches can already accept additional gigabit Ethernet connections bound to form a single backbone connection. No more hardware is necessary than if the customer had simply purchased a second backbone connection — either for the customer or TNS.

   IPv4 space is actually conserved over simply buying a second backbone connection, since in the LACP case we only assign one subnet and the protocol takes care of distributing the traffic between the links.

   There may be an argument that the Network Operations Center may need training in order to respond to customer issues regarding LACP backbone connections, simply because they are different. However, the LACP protocol is well established and provides a level of resiliency not available with a single connection.

   We would propose $1,000 per backbone router interface one-time, and $75 for equipment certification (performed by the customer with TNS supervision), plus $50 per month to cover the need for ongoing TNS training for the NOC and test engineers (see 10, below).

9. What are the operational support issues — do spares need to be carried and how many are suggested, does it use proprietary equipment, what are the delivery (lead) time issues?

   No spares are required as no new, unique, or proprietary equipment forms a part of this service.

10. What are the training issues for operations, ITS user training staff and user training

    The NOC will need training in order to properly diagnose customer issues. Within MRTG, each physical interface appears, as it normally would. In addition, a new virtual interface representing all of the traffic on the bound interfaces appears.

    Also, since this service requires more customer involvement in terms of configuration required beyond the service demark, we would suggest a “certification lab” be established where a customer could bring their device in order to ensure interoperability and proper configuration of their device before installation. This would consist of a few interfaces on a test router with canned interface configurations and equivalent test data and expected results on the network data generator/analyzer (SmartBits) along with a written procedure to follow. The customer would be expected to perform the certification under the supervision of TNS personnel. Training for those supervising would be necessary.

11. What are the start-up costs (including operational support and training costs) for TNS

    NSG and NOC training as well as the creation of the certification lab and training of its support personnel are necessary at start-up.

12. What are the technical issues — will technology changes make the service unnecessary in the future, is it a mature technology or prototype, has it been proven (tested) to work in the applications suggested (and what was the process for testing), what are the expectations regarding reliability, can it be applied to the existing infrastructure, etc.?

    This service requires additional configuration capability on the part of the customer. The requirement for the customer to pass equipment certification addresses this.

    Eventually, gigabit Ethernet interfaces will fall out of fashion, replaced by ubiquitous 10 Gigabit Ethernet and TNS will end support for the service. Before we reach that point, we will encounter customers who need an incremental improvement over the 10 Gigabit service and we will extend this one to use the new technology.

    There will be a need for this service as long as our customers are using Ethernet and some of them require incremental increases in bandwidth rather than exponential ones.

    TNS already has undertaken to convert from SONET to WAN Ethernet from our inter-campus network provider in part because it offers smaller bandwidth increments that offer more attractive pricing.

    LACP is a mature technology. It was defined in the IEEE 802.3 Ethernet standard as IEEE 802.3ad in March 2000. TNS has experience with similar technology that provided 2 Gigabit trunks for the core network at Penn State and for combining multiple T1 circuits for off campus facilities.

    Once properly configured, this service should be more resilient than alternative methods, since the remaining link continues to carry all traffic should the other link fail.

    This service will work well with the existing infrastructure.

13. Will new equipment be required?

    No new equipment is required.

    • If applicable, what exactly is the proposed equipment (manufacturer and model numbers)?

      N/A.

    • If applicable, what is the expected life cycle of the equipment (is it stable or will it require frequent change-outs until the technology stabilizes)?

      N/A.

14. What is the projected start date for this service?

    In order to satisfy the needs of the trial customer, we would like to have the trial in place by August 2, 2007.

——–

Here in TNS, we have a procedure for proposing new services that involves answering a set of questions and submitting them to the unit Directors for their consideration. It is a useful exercise because it makes you really think about what you are doing. Phil Coolick got the idea to post them to our blogs and I thought that seemed like a good idea, so I’ll be putting up some for stuff we are working on shortly. Feel free to comment.

——–

I mentioned in the last TCP/IP Meeting that we have started to look for replacements for our aging Ethernet switches for the TNS LAN Service. We sent out a Request for Information (RFI) asking what devices could satisfy the following requirements. We sent the RFI to the nine vendors that Gartner placed in the Magic Quadrant for Campus LAN, which is an interesting read. They are (alphabetically):

• 3Com Corporation
• Alcatel-Lucent
• Cisco Systems
• Enterasys Networks
• Extreme Networks
• Force10 Networks
• Foundry Networks
• Hewlett-Packard
• Nortel Networks

Here is the text of the RFI as we sent it out.

Background

The purpose of this document is to outline the requirements of new devices to replace our existing Basic Ethernet Switch family. Currently there are many such devices spread across our Statewide Campus Network in the form of HP ProCurve 4000M (J4121A) and 3Com 4400 and 4900 family devices (3C17203, 3C17204, 3C17205, 3C17210, 3C17700, and 3C17701).

Currently, the Basic Ethernet Switch provides 10/100 and 100/1000 copper user ports and connects the Penn State Integrated Backbone via 100BASE-FX or 1000BASE-LX. We aggregate switches within a telecommunications room using 100BASE-TX or 1000BASE-T to provide the required number of user ports. We also connect switches between telecommunications rooms within a building using 100BASE-FX or 1000BASE-LX.

Taking into account potential future growth, upgrades in services, and the need for additional user bandwidth, the new Basic Ethernet Switch must meet the following listed requirements.

The general requirements below apply to all applications for the Basic Ethernet Switch. Afterwards, specific application requirements are given for specific applications of the switch.

General Requirements

Availability and Suitability

• AS1. Currently shipping to customers
• AS2. All of the following features currently available in shipping product
• AS3. Does not require the use of proprietary mechanisms, where an IEEE, IETF, or Internet RFC standards based mechanism is currently available

Configuration and Management

• CM1. Stores configuration settings in non-volatile memory
• CM2. Allows transfer of configuration settings to another device
• CM3. Can use ASCII file to transfer the configuration settings
• CM4. Can reload an edited ASCII configuration file to make configuration changes
• CM5. Manageable locally using console access
• CM6. Manageable remotely using SSHv2, SNMP, or HTTPS
• CM7. Provides configurable security methods for all management methods
• CM9. Provides an interface for SNMP management, version 2c or higher
• CM10. Uses standard MIB, or proprietary MIB is provided
• CM11. Allows configuration of all settings without using proprietary software
• CM12. Provides mechanism to upgrade firmware
• CM13. Uses IGMP to control multicast traffic

Monitoring

• MN1. Generates SNMP traps
• MN2. Generate syslog messages
• MN3. Date and time stamps syslog messages
• MN4. Uses either NTP or SNTP to set and maintain time
• MN5. Supports network monitoring via RMON
• MN6. Can mirror a port to another
• MN7. Propagates framing errors to the mirror port
• MN8. Mirrors port traffic at line rate
• MN9. Differentiates between mirror port inflows and outflows
• MN10. Alerts the monitoring port or log record if mirror packets are dropped

Security

• SC1. Does not forward unicast packets not destined for an individual port
• SC2. Does not forward packets to a port before learning the MAC address of the attached device
• SC3. Can remotely disable and enable individual ports
• SC4. Can continue to operate when ports are placed in the loopback condition (pin 1 to pin 3 and pin 2 to pin 6)
• SC5. Does not degrade to hub operation under ARP flood

Other Standards

• OS1. Supports IEEE 802.1Q VLANs
• OS2. Supports at least 8 VLANs per port
• OS3. Supports IEEE 802.1AB Link Layer Discovery Protocol

Interface Options and Specifications

• IO1. Passes IPv4 unicast packets at full line rate
• IO2. Passes IPv4 multicast packets at full line rate
• IO3. Passes IPv6 unicast packets at full line rate
• IO4. Passes IPv6 multicast packets at full line rate
• IO5. Passes frames as small as 64 bytes at full line rate
• IO6. Passes all frames without loss
• IO7. Supports STP
• IO6. Ports auto-negotiate
• IO7. Individual ports settable to 10 Mbps half duplex
• IO8. Individual ports settable to 100 Mbps full duplex
• IO9. Individual ports settable to 1000 Mbps full duplex
• IO10. Provides a backplane that is non-blocking at full port capacity and with port-level interconnects running at full line rate.
• IO11. Passes jumbo frames as large as 9200 bytes at full line rate

Physical Characteristics

• PC1. A 19” rack-mountable version is available
• PC2. Port connectors provided on the front panel

Environmental

• EN1. Operates in temperatures between 32 and 120°F 104°F
• EN2. Operates in humidity up to 90% non-condensing humidity

Failure Rates

• FR1. Has an MTBF no less than 100,000 hours

Specific Application Requirements

Administrative Edge Switch

The Administrative Edge switch provides network connectivity for trusted users. These networks may also support associated file servers, printers, or other network devices.

• AE1. Provides at least 32 10/100/1000BASE-T ports
• AE2. Provides at least 2 100BASE-FX ports
• AE3. Provides at least 2 1000BASE-LX ports

Administrative Aggregation Switch

The Administrative Aggregation switch is used to aggregate Administrative Edge switches within or between telecommunication rooms.

• AA1. Provides at least 6 100BASE-FX ports
• AA2. Provides at least 6 1000BASE-LX ports
• AA3. Provides at least 1 10GBASE-LR port

VoIP Edge Switch

The VoIP Edge Switch provides network connectivity for VoIP handsets on our dedicated VoIP network.

• VE1. Provides at least 24 10/100BASE-T ports
• VE2. Provides at least 2 100BASE-FX ports
• VE3. Provides at least 2 1000BASE-LX ports
• VE4. Blocks forwarding of Cisco Discovery Protocol (CDP) packets
• VE5. Provides both IEEE 802.3af and Cisco Inline Power (CIP) to each port based on the requirements of the detected media endpoint
• VE6. Allows an endpoint MAC address to be associated with each port such that only traffic from that device is accepted
• VE7. Supports TIA-1057 Link Layer Discovery Protocol for Media Endpoint Devices

VoIP Aggregation Switch

The VoIP Aggregation Switch is used to aggregate VoIP Edge networks between buildings.

• VA1. Provides at least 16 100BASE-FX ports
• VA2. Provides at least 16 1000BASE-LX ports

VCoIP Edge Switch

The VCoIP Edge Switch provides network connectivity for videoconferencing devices connected to our dedicated VCoIP network.

• VC1. Provides at least 4 100BASE-TX ports
• VC2. Provides at least 1 1000BASE-LX port

Residence Hall Edge Switch

The Residence Hall Edge Switch provides network connectivity to students in residence halls.

• RE1. Provides at least 32 10/100BASE-T ports
• RE2. Allows an endpoint MAC address to be associated with each port such that only traffic from that device is accepted
• RE3. Allows an endpoint IP address to be associated with each port such that only traffic from that device is accepted
• RE4. Provides at least 1 100BASE-FX port
• RE5. Provides at least 1 1000BASE-LX port

Wireless Edge Switch

The Wireless Edge Switch provides network connectivity for wireless access point devices on our dedicated wireless network.

• WE1. Provides at least 24 100BASE-TX ports
• WE2. Provides at least 1 100BASE-FX port
• WE3. Provides at least 1 1000BASE-LX port
• WE4. Provides IEEE 802.3af power

Labels: rfi

——–

Freelance Switch has a list of what it calls 14 Essential Tips for Meeting a Deadline. While I would say that most of them are obvious, most people still do not follow them. Here are the steps, the article has more detail for each:

1. Care about deadlines.

2. Keep a list of projects & deadlines.

3. Communicate a clear deadline.

4. Work in a cushion.

5. Have a clear outcome.

6. Break down the project.

7. Focus on the first step.

8. Block off adequate time.

9. Have a start and complete date for each step.

10. Communicate with each step.

11. Don’t overcommit.

12. Learn from mistakes.

13. Stay up late.

14. Negotiate and meet a second deadline.

——–

What is a system? A system is an interdependent group of people, objects, or procedures constituted to achieve a defined objective or some operational role by performing specified functions.¹

What is a requirement? A requirement is something a system must do. It is a condition or capability a user needs in order to solve a problem or achieve an objective.

What is system requirement specification? It is a process that produces a set of requirements that, when realized, will satisfy an expressed need. It provides a description of what a system’s customers expect it to do for them. It is a way of converting raw customer requirements into well-formed and organized ones. It is a method to provide a “black-box” description of what a system should do, in terms of its interactions or interfaces with its external environment.

What does the environment of a system include? A system’s environment includes all of the things that influence the system. These fall into categories like:

• Political
• Market
• Industry Standards
• Internal Policies
• Cultural
• Organizational
• Physical

Does system requirements specification show how to build the system? No. System requirement specification does not result in a set of instructions. We use it to ensure communication between the technical community and agreement on what the system must do to achieve its goals. During design and development, we use it to determine the requirements of the various parts we determine the system must have. We use it to develop test plans. We use it to verify the system operation when we believe we are done.

References

1. Software Engineering Standards Committee of the IEEE Computer Society, ‘IEEE Guide for Developing System Requirements Specifications’, IEEE Std 1233 (1998) <http://ieeexplore.ieee.org/iel4/5982/16016/00741940.pdf> [accessed Tuesday, August 23, 2007] ↩

Labels: pm

——–

——–

Operational Concept Development is one of the earliest steps of system development. Whether it is a new system, or an existing one that you are thinking of modifying, there are certain things that you need to know before you get too far. In fact, the simple act of asking the questions can sometimes solve the problem. So sit down, talk with your customer, and talk about the system — “it” — until you can say you know the answers to these questions.¹

A picture is worth a thousand words, and while it might take many words to answer these questions, it really might only take a few words and a some well drawn pictures.

It is good for you to know the answers to these questions, but if you write them down, you can share them with others and refer back to them as the project progresses.

1. What is it called? We need to be able to talk about the system. We work on a lot of systems. In order to know that we are talking about this one, we need a unique, memorable name.

2. What is its purpose? This is the proverbial 10,000-foot view. We are really looking for an elevator statement here.

3. What documentation about it exists? If the customer has already given the subject some thought, you owe it to them to do your homework and not waste their time regurgitating information that already exists.

4. What is its history? If the system is new, how did the idea for it arise? If it already exists, why do we have the system? When did we get it? Has it changed before? If so, why did it change before? Is the system ingrained in the culture or politics of some organization?

5. Who are the stakeholders? Identify the developers, operators, maintainers, managers, payers, users, and so on.

6. Where is it? Or, if it is a new system, where do we want it to be?

7. What are the characteristics of its operational environment? The circumstances, objects, and conditions surrounding it. Technical, political, commercial, cultural, organizational, and physical influences as well as standards and policies that govern what a system must do or how it will do it. Identify facilities, equipment, hardware, software, personnel, and procedures used with it. Be as detailed as necessary to give an understanding of the numbers, versions, capacity, and so on, of the operational environment.

8. What are its external interfaces? It must get inputs from somewhere and provide outputs to somewhere. What are they and what do they look like?

9. What functional capabilities does it have? What can you do with it?

10. What performance capabilities does it have? Speed, throughput, volume, frequency, and so on.

11. When is it used? Describe the scenarios under which a user would decide to use the system.

12. What procedures are involved in making it work? Even an autonomous system interacts with people at some point. Procedures involve interacting with people. What are they?

13. What are its major components? If it is a new system, you will want to take the answer to this question with a grain of salt. It may be convenient for the customer to explain their concept as the interaction of certain parts, but ultimately what is important is whether the system does what it should, not whether it has certain components inside. Leave defining the internal behavior — the interaction of the components — of a new system should until design time.

14. How do its components interconnect? As with the major components, for a new system, this is only a communications aid.

15. How is it supported? Some systems are vendor supported, dedicated staff supports others, and some have no support at all. Unsupported systems are actually user supported, since they are the ones that have to make it work when it breaks. The system support model will place constraints on your implementation.

16. What has happened that we want to change it? Whether it is a new system or an existing one, some trigger event resulted in the identification of the need for the system or the change. What was that trigger?

17. What changes do we want to make to it? For an existing system, you have just gotten an idea of what it encompasses. At this point, you picture either a working system or a broken one. If it is broken, you are going to talk about changing it. If it is working, you are going to talk about adding to it.

18. Which changes to it are essential? Any time you talk with the customer you should let them fully express themselves about what they are thinking. However, you need to be clear on which things are essential and which are not.

19. Which changes to it are desirable? Just below essential changes are ones that are desirable.

20. What is the priority ranking of the changes to it that are desirable? If there is more than one desirable change, you will need to know which is higher priority so you will know where to concentrate your efforts.

21. Which changes to it are optional? Ranking below desirable changes are optional changes.

22. What is the priority ranking of the changes to it that are optional? If there is more than one optional change, you will need to know which is higher priority so you will know where to concentrate your efforts.

23. What changes to it have already been considered and dismissed and why were they dismissed? In order to understand how to move ahead it is sometimes helpful to understand the logic behind what the customer may have already looked at and decided not to do.

24. What assumed constraints are involved in the changes to it? If the customer is aware of preexisting constraints — performance, physical, political, cultural, schedule — you had best know what they are up front.

25. How do the answers to questions 7–15 change because of the changes to it? Assuming the system already exists, whatever changes you make to the system itself may have an impact outside the system in terms of new external interfaces, new support mechanisms, and so on.

26. How do the changes to it address the reason, given in answer to question 16, for wanting the changes? This is a sanity check. If you get this far and you cannot explain how the suggested changes address the identified need then you need to have a serious chat with your customer. Better to have that chat now than after months of development and dollars spent on a system that does not address the need.

27. What disadvantages or limitations does it have after the change? Now that you have a sanity check, this gives you a reality check. All systems are limited. It is best to understand those limitations going in, rather than being surprised by them at then end.

References

1. Software Engineering Standards Committee of the IEEE Computer Society, ‘IEEE Guide for Information Technology — System Definition — Concept of Operations (ConOps) Document’, IEEE Std 1362 (1998) <http://ieeexplore.ieee.org/iel4/6166/16486/00761853.pdf> [accessed Tuesday, August 21, 2007] ↩

Labels: pm

——–