Procurement Phase and Systems Design - Procurement Phase - Software Design In this lecture you will learn more about the design phases in the systems development methodology: configuration, procurement, and design and integration phases.

What is Systems Design ? Systems design is the specification of a detailed computer-based solution. It is also called physical design. The purpose of the systems design phase is to create a blueprint that will satisfy all requirements for the system. Relative to the information building blocks, systems design addresses People, Data, Interfaces, Processes, and Geography from the system designer's perspective. Often, technology is in place, or specified by a predefined technology architecture (perhaps from systems planning). In other cases, the analyst must select or supplement the technology. In all cases, systems design builds on the knowledge derived from systems planning and systems analysis. Most of us place too restrictive definition on the process of design. We envision ourselves drawing blueprints of the computer-based systems to be programmed and developed by ourselves or our own programmers. Thus, we design inputs, outputs, files, databases, and other computer components. Recruiters of computer-educated graduates refer to this restrictive definition as the ``not-invented-here syndrome.'' In reality, many companies purchase more software than they write in-house. That shouldn't surprise you. Why reinvent the wheel? Many systems are sufficiently generic that computer vendors have written adequate -- but rarely, if ever, perfect -- software packages that can be bought and possibly modified to fulfill end-user requirements. 3

Hardware and Software Acquisition (Procurement Phase) Research technical criteria (if necessary) Solicit proposals and/or quotes from vendors (a letter) Evaluate vendor proposals and a congratulation letter Example of Procurement Phase Deliverables I. List of top three vendors (Technical Requirements) a. Hardware such as workstation, memory, backup units, printer, etc. b. Software such as operating system, application development tool. II. Solicit vendor proposals (a letter) III. Analysis of vendor proposals (refer to the Vendor Proposal Analysis) IV. Congratulation memorandum (a letter) to the best vendor

Design and Integration Phase Analyze and Distribute Processes Analyze and Distribute Data Design Files and Database(s) Design Computer Outputs and Inputs Design User Interfaces Present and Review Design Before the analyst can design computer files and/or databases for the target system, the analyst must perform some additional analysis and address distribution issues of the data. If you recall, a data model of the target system already exists. That model was created during systems analysis as a tool for communicating and documenting the data requirements for the target system. However, that data model does not usually represent a good file or database design. In fact, it may contain structural characteristics that may lead to numerous problems. In addition, in those cases where the systems data is to be shared by different sites this activity will make decisions on how that data is to be distributed amongst the locations. This activity is omitted from many designs. However, for on-line systems, the development of interface (the dialogue between the end-user and the computer) design specifications from interface design requirements may well be the most critical design activity. Too many on-line systems are difficult to learn and use because they exhibit poor human engineering. Essentially, you are trying to anticipate every little error or keystroke that an end-user might make -- no matter how improbable. Furthermore, you are trying to make it easy for the end-user to understand what the screen is displaying at any given time.

Strategies For Software Design Modern Structured Design Prototyping JAD RAD Object-Oriented Design (OOD) Design a program as a top-down hierarchy of modules. A module is a group of instructions – a paragraph, block, subprogram, or subroutine. The top-down structure of these modules is developed according to various design rules and guidelines. (Thus, merely drawing a hierarchy or structure chart for a program is not structured design). Structured design is considered process technique because it’s emphasis is on the PROCESSES in an information system – specifically, software processes. Traditionally, physical design has been a paper-and-pencil process. Analysts drew pictures that depicted the layout or structure of outputs, inputs, and files and the flow of dialogue and procedures. This is a time-consuming process that is prone to considerable error and omissions. Frequently, the resulting paper specifications did not prove themselves adequate, complete, or accurate until programming started. There are disadvantages or pitfalls to using the prototyping approach. Prototyping is not without disadvantages. Most of these can be summed up in one statement: Prototyping encourages ill-advised shortcuts through the life cycle. Fortunately, the pitfalls can all be avoided through proper discipline.

Modern Structured Design Structured design seeks to factor a program into the top-down hierarchy of modules. The software model derived from structured design is called a structure chart. Structured design is performed during systems design. Structured design does not address all aspects of design – for instance, structured design will not help you design databases or files. The structure chart is derived by studying the flow of data through the program.

Representing Design Specifications Structure Charts Shows how an information system is organized in hierarchical modules Shows how parts of a system are related to one another Shows breakdown of a system into programs and internal structures of programs written in third and fourth generation languages Structure Charts Module A self-contained component of a system, defined by a function One single coordinating module at the root of structure chart Single point of entry and exit Communicate with each other by passing parameters Data couple A diagrammatic representation of the data exchanged between two modules in a structure chart Flag A diagrammatic representation of a message passed between two modules Special Symbols Diamond Only one subordinate will be called Curved Line Subordinates are called repeatedly until terminating condition is met Predefined modules Hat Subordinate module is important logically but code is contained in superior module

Figure 9.2 The End Product of Structured Design There are several conventions on how to draw structure charts. The above example is one of them. The structure chart will be presented in later classes.

Highly Cohesive and Loosely Coupled Modules should be highly cohesive; that is, each module should accomplish one and only one function. Modules should be loosely coupled; in other words, modules should be minimally dependent on one another. Structured design seeks to factor a program into the top-down hierarchy of modules that have the following properties: Modules should be highly cohesive; that is, each module should accomplish one and only one function. This makes the modules reusable in future programs. Modules should be loosely coupled; in other words, modules should be minimally dependent on one another. This minimizes the effect that future changes in one module will have on other modules. There is a “trade-off” for these two characteristics; If you want the processes to be more cohesive, you divide the processes into more smaller pieces so that each module would perform a simple task; then it increases the dependencies between modules = more coupling. If you want the processes to be independent, then you combine processes / modules to be self-complete without couplings; then you increase the complexity of the module, hence not cohesive. The major key word here is the balance, with acceptable levels of both cohesion and coupling.