MOVING TO DESIGN
Systems design is the process of describing, organizing, and structuring the components of a system at both the architectural level and a detailed level with a view toward constructing the proposed system. Systems design is like a set of blueprints used to build a house. The blueprints are organized by the different components of the house and describe the rooms, the stories, the walls, the windows, the doors, the wiring, the plumbing, and all other details. To understand the various elements of systems design, we must consider two questions: What are the components that require systems design? What are the inputs to and outputs of the design process?
A second important idea underlying systems design is that of the different levels of design. During analysis, we first identified the scope of the problem before we tired to understand all of the other details. We called this step top-down analysis. Analysis, as it was presented, included both top-down activities (for examples, scope first, then details) and bottom-up activities (for examples, DFD fragments first, then the middle-level diagram). The same ideas apply during design will use the term architectural design.
During the activities of the analysis phase, we built documents and models. For traditional analysis, models such as the event table, data flow diagrams, and entity-relationship diagrams were built. For object-oriented analysis, we also used the event table and developed other models such as class diagrams, use case diagrams, and use case descriptions. Regardless of the approach, the input to the design phase activities is the set of documents and models that were built during earlier phases. Design is also a model-building activity.
Designing the application architecture involves specifying in detail how all system activities will actually be carried out. These activities are described during systems analysis in great detail as logical models, without indicating what specific technology would be used. After a specific design alternative is chosen, the detailed computer processing – the physical models – can be designed. A key decision is to define the automation boundary, discussed in chapter eight, which separates the manual work done by people from the automated work done by computers.
No system exists in a vacuum. A new information system will affect many other information systems. Sometimes one system provides information that is later used by another system. Other times systems exchange information continuously as they run. The component that enables systems to share information is the system interface, and each system interface needs to be designed in detail. From the very beginning of systems design, analysts must ensure that all of these systems work together well. Some system interfaces link internal organizational systems, so the analyst may have information available about the other systems.
Designing the database for the system is another key design activity. The data model (a logical model) created during systems analysis is used to create the physical model of the database. Sometimes the database is a collection of traditional computer files. More often, it is a relational database consisting of dozens or even hundreds of tables. Sometimes files and might be used instead of relational databases. Analysts must consider many important technical issues when designing the database. Many of the technical (as supposed to functional) requirements defined during systems analysis concern database performance needs (such as response time).
During the design phase, it is important to continue creating and evaluating prototypes. Prototyping can also be used to confirm design choices about user interfaces, the database, networking architecture, controls, or even programming environments being used. Therefore, when analysts consider all of the design activities, they think about how prototypes might be used to help understand a variety of design decisions. It is also important to recognize that rapid application development (RAD) approaches develop prototypes during design that evolve into the finished system. In those cases, the prototype is the system.
A final design activity involves ensuring that the system has adequate safeguards to protect organizational assets. These safeguards are referred to as system controls. This activity is not listed last because controls have to be or it is less important than the others. On the contrary, it is a crucial activity. It is listed last because it is less important or the controls have to be considered for all other design activities – user interface, system interface, application architecture, database, and network design.
The initiation of design activities is a pivotal point in the development project. The focus changes from discovery to solution development and the whole tenor of the project changes. Coordinating all of the ongoing activities is challenging for even the best project managers because myriad details and tasks must be handled to keep the project on track. Even though analysis for iteration is essentially complete at this point, some analysis tasks remain. Every new system has a multitude of business rules that must be integrated into it missions are calculated, what happens to commissions on merchandise returns, when commissions are paid, how the commission schedule varies to encourage sales of high-margin items and sale items, and so forth.
The fundamental tool to coordinate the various project teams’ activities is the project schedule. As the activities of the design phase begin, the project manager must update the schedule by identifying and estimating all tasks associated with design and implementation, as well as any outstanding tasks associated with ongoing requirements definition. The project schedule usually must be reworked substantially to ensure that the project remains organized. Weekly, and sometimes daily, status meetings are held. If this group includes people at remote locations, teleconferencing support may be required.
As a customer support system project moves forward into design at RMO, the project team has been enhanced with the addition of new team members. Consistent with the earlier discussion, RMO initiated two new subprojects at this time, one for data conversion and one for the system and acceptance test plans. To integrate new people into the team, Barbara Halifax reorganized the structure of the project team. Those who had been on the team through-out the analysis phase are now key players in getting the new team members up to speed.
As design moves forward, the development teams begin to generate a tremendous amount of detailed information about the system. Modules, classes, data fields, data structures, forms, reports, methods, subroutines, and tables are all being defined in substantial detail. The most common and widespread technique to record and track project information is to use a CASE tool. Most CASE tools have a central repository to capture information. A major element in a CASE tool system is the central repository of information.
In chapter eight, you learned that defining the deployment environment is an activity that bridges analysis and design. The deployment environment consists of the hardware, system software, and networking environment in which the system will operate. In this section, we describe common deployment environments in detail, and in the next section we’ll explore related design patterns and architectures for application software. Single-computer architecture is an architecture that employs a single computer system executing all application-related software. A multitier architecture is an architecture that distributes application-related software or processing load across multiple computer systems. A clustered architecture is a group of computers of the same type that share a processing load and act as a single large computer system. A multicomputer architecture is a group of dissimilar computers that share processing load through specialization of function. The term centralized architecture describes deployment of all computer system in a single location.
Centralized architecture is generally used for large-scale processing applications, including both batch and real-time applications. Such applications are common in industries. Any application that has two or three of these characteristics is a viable candidate for implementation on a centralized mainframe. Current trends in conducting e-business have instilled new life into centralized mainframe computing because of the transaction volumes of many business-to-business (B2B) processes. Centralized computer systems are seldom used as the sole hardware platform for an information system. Most systems have some transaction inputs that must be accepted from geo-graphically dispersed locations and processed in real time – for example, a cash withdrawal from an ATM.
A computer network is a set of transmission lines, specialized hardware, and communication protocols that enable communication among different users and computer systems. Computer networks are divided into two classes depending on the distance they span. A local area network (LAN) is typically less than one kilometer long and connects computers within a single building or floor. The term wide area network (WAN) can describe any network over one kilometer, though the term typically implies much greater distances spanning cities, countries, continents, or the entire globe.
The internet is the infrastructure on which the Web is based. In other words, resources of the Web are delivered to users over the internet. An intranet is a private network that uses (usually members of the same organizations or workgroup). An extranet is an intranet that has been extended to include directly related business users outside the organization (such as suppliers, large customers, and strategic partners).
Simple deployment environments, such as a single centralized computer with video display terminals, can be matched to relatively simple application architectures. More complex distributed and multitier hardware and network architectures require more complex software architectures. This section describes common examples of application architectures for distributed and multitier deployment environments and the design issues and decisions associated with each. A server manages one or more information systems resources or provides a well-defined service. A client communicates with a server to request resources or services, and the server responds to those requests. Like earlier forms of client/server architecture, three-layer architecture is inherently flexible. Interactions among the layers are always requests or responses, which makes the layers relatively independent of one another. It doesn’t matter where other layers are implemented or on what type of computer or operating system they execute. The only interlayer dependencies are a common language for requests and responses and a reliable network with sufficient communication capacity.
Client/server and three-layer architecture relies on special programs to enable communication between the various layers. Software that implements this communication interface is usually called middleware. Middleware connects parts of an application and enables requests and data to pass between them. There are various methods to implement the middleware functions. Some common types of middleware include transaction processing monitors, object request brokers (ORBs), and Web service directories. Each type of middleware has its own set of protocols to facilitate communication between the various components of an information system.
The Web is a complex example of client/server architecture. Web sources are managed by server processes that can execute on dedicated server computers or on multipurpose computer systems. Clients are programs that send requests to servers using one or more of the standard Web resource request protocols. Web protocols define valid resource formats and a standard means of requesting resources and services. Any program (not just a Web browser) can use Web protocols. Thus, Weblike capabilities can be embedded in ordinary application programs.
Modern organizations rely on networks to support many different applications. Thus, the majority of new systems must be integrated into existing networks without disrupting existing applications. Network design and management are highly technical tasks, and most organizations have permanent in-house staff, contractors, or consultants to handle network administration. The analyst for a new project begins network design by consulting with the organization’s network administrators to determine whether the existing network can accommodate the new system. In some cases, the existing network capacity is sufficient, and only minimal changes are required such as adding connections for new servers or modifying routing and firewall configuration to enable new application layers to communicate.
Location-related information gathered during analysis may have been documented using location diagrams, activity-location diagrams, and activity-data matrices. During network design, the analyst expands the information content of these documents to include processing locations, communication protocols, middleware, and communication capacity. There are many different ways to describe the network infrastructure for a specific application. The diagram embodies specific assumptions about server locations, which would be decided in consultation with network administrators. The Web/application servers could have been distributed outside an establishment data center, which might have improved system response time and reduced data communication capacity requirements on the private WAN.
The network diagram is also a starting point for specifying protocol and middleware requirements. For example, the private WAN connections must support protocols required to process Microsoft Active Directory logins and queries. If the WAN fails, messages are routed through encrypted (VPN) connections over the Internet, so those connections must support the same protocols as the private WAN.
Data size per access type is an educated guess at this point in the system design because none of the software layers, interlayer communication dialogs, or database has yet been designed. So basically, that was the summary of the chapter moving to design. The points that where tackled where the issues related to managing and coordinating the design phase of SDLC. Explain the major components and levels of design, and describe each design phase activity, and describe common deployment environments and matching application architectures and lastly, develop a simple network diagram and estimate communication capacity requirements.
