Case Study: BCS, Part 1

The BSC solution centers on an upgrade to the enrollment system. Currently, BSC has an IBM AS/400 that maintains class schedules and enrollments with an old PL/1 program. (PL/1 classes are no longer offered in the curriculum at BSC.) Enrollments are currently done by registrars sitting at mainframe terminals, handling students one at a time. This time-consuming and labor-intensive system has motivated the college to search out a more updated solution. BSC wants a new graphical user interface (GUI) to replace the character-based screens in its current application. It also wants to allow students to register themselves, and it wants to move the database to a server, eventually retiring the mainframe.

Because the college teaches classes in SQL Server and C#, it has graduate assistants fluent in those areas who will be responsible for maintaining the system after it is built. The professors have requested that the system be simple to maintain because new graduate assistants rotate through each year.

Three primary users for the new solution are anticipated: professors, registrars, and students. There are 10 registrars, 150 professors, and around 10,000 students. The students will use the system by reviewing course schedules online from any of the 40 computer "kiosks" placed strategically around the campus or from any Internet-capable PC. These kiosks are nothing more than a Windows PC running a Web application in a captive environment; students using them cannot navigate to other Web sites or "escape" out to the Windows OS. This captive environment keeps the machines available for course enrollment activities. After the enrollment period is over, the machines are "unlocked" and available for general Internet use.

Registrars have the ability to place students in classes, even if the class shows up on the system as "full." They also set up course schedules initially.

Professors usually just review their course prerequisites and syllabi, but they can also allow students into a class, even if they have not met the prerequisites.

After reviewing the course schedules, students submit their requests via the same Web interface. The college staff has indicated that responses must be returned to the user within 10 seconds.

A simple ID/password system is required to log in. The course administrator and registrars will be directly connected to the system through a more powerful, secure Windows-based application.

BSC is expecting at least 6,000 students to take advantage of the new online registration system. Registrars can average eight student enrollments per hour. The registrars are paid $20 per hour, so the college is hoping the system will pay for itself in three years (six semesters). Because of low enrollments for the summer semester, BSC has decided to base all its calculations on two semesters per year. As is true at most colleges, cost is an issue.

A short development cycle is also part of the college's requirement. The new system should be up in time for fall enrollments, just four months away.

Between enrollment periods, the system will see minimal use. However, during the enrollment period (which usually lasts three weeks), the system needs to be up from 6:00 a.m. to midnight every day.

Envisioning the Solution

First, you want to look for the high-level requirements, problems, and risks and jot them down on your scratch pad.

Problems are usually indicated when interviewees talk about what is wrong with the current system or why they are requesting a new system. Although the BSC case study doesn't include any interviews, the rest of the book (and the exam itself) uses the interview format to communicate information.

Risks are factors that, from your own experience, seem as though they might cause issues down the road.

The sample notes in the following figures are for illustrative purposes and are probably more robust and comprehensive than what you would do during an actual exam. The intent is to show what information you might include in your notes. The figures are not meant to be a firm guideline on what you should capture in a single use case reading.

In the case of BSC, your "Envisioning" notes might look something like Figure 12.1 after you have finished reading the case study.

Figure 12.1. Notes focused on envisioning the solution for the BSC enrollment system.

Requirements (Business, User, Operational)

After you have a general idea what the system should do, you need to collect more detailed requirements. This process is not all that different from the notes on scope that you took in the Envisioning Phase. Like a sculptor working on a statue, you start by taking large, rough cuts at the stone. As the statue begins to take shape, your cuts become finer and finer, until you are making just minor, smoothing adjustments.

The requirement-gathering phase is another time when taking notes, drawing diagrams, or making lists as you read the case study can help. You should read the case study for any hints of business goals that need to be addressed, regulatory obligations, or business flows that need to be adhered to. In the BSC case study, the registration flow and rights of the various users are the areas to focus on. You might record the following in your notes:

• Students can enroll onsite or at home.

• Registrars can do anything except waive course prerequisites for students who fail to meet them.

• Professors can set prerequisites, enter syllabi, and waive prerequisites.

You might notice that these notes focus heavily on nouns, verbs, and adjectives. When building requirements, nouns help you understand the existing system (such as "AS/400"), the scope of the new system ("enrollment system"), and the roles involved ("professor," "student"). Phrases such as "simplest" and "lowest cost" are also helpful in defining business issues when reading a case study and when designing a system in the real world. The verbs help you identify items such as availability requirements (for example, "up 24 hours a day"). You should also watch for verbs such as "submit" and "review" to give you clues.

Developing Specifications

This is the first stage that gets a developer's instincts into high gear. Here you begin to translate high-level business requirements into technical specifications. In this stage, you select technologies (C#, J#, unmanaged C++, or Visual Basic .NET) and determine an approach to exception-handling and other internal services that don't translate directly to business or scope goals, but that do correspond to a smooth and maintainable solution architecture.

At BSC, many of the choices are made for you. It is stated explicitly that you will use SQL Server and C#. Some exam case studies are just as explicit. It's like a jigsaw puzzle strewn out on the table. Every piece you need is there; you just need to find the pieces and put them together correctly. It seems unlikely you will be asked to choose between C# and Visual Basic .NET on the exam, but if you are, the answer will be embedded in the case study somewhere. What languages are current staff members already familiar with? If they know VB6, then Visual Basic .NET will be the likely choice. If they know Java or VC++, then C# is probably the right answer. Old arguments about which language is best, such as "faster time to market" or "more object-oriented," no longer have teeth in the .NET world.

Watch for mismatches between different versions of software in the exam case study. For example, if SQL Server 6 or Access 97 is the current version, but the case study calls for Unicode or native XML support, that clues you in to a database server upgrade being part of the mix.

Conceptual Design

Conceptual design is new to .NET. It is a step between the nontechnical case study and the logical database schema. Here, you take sentences representing rules and relationships and attempt to create Object Role Modeling (ORM) models.

As discussed in Chapter 6, "Creating the Conceptual Design," ORM enables you to speak in terms that the user representative can understand, which makes verifying the database schema easier. You can assume that Social Security numbers will be the table's primary key (and you might be wrong), or you can ask the user whether the sentence "Each student will be identified uniquely by an ID number that is not his or her Social Security number" is accurate. It keeps the dialogue between designers and architects at a more detailed level and helps prevent surprises down the line.

There isn't enough information in the BSC case study to help you design a conceptual data model, however, so you need to revisit BSC and gather some additional information from the business experts who are helping design the system.