When a business system development project has been accepted by the client or sponsor, the analysis phase moves into the design phase.
Requirements describe what a system must do. The first step in the design phase is to represent the requirements in a way they can be verified and communicated to business and development staff. The developers must understand the requirements so they can design the solution. Business users must understand the solution to ensure that the proposed solution will satisfy the business needs and justify the project expense.
After requirements have been gathered, documented, and approved, you are ready to decide how to accomplish what is needed. This is done in what is usually called the end result of the analysis phase.
The business systems analyst (BSA) needs to separate the things a client wants from the things a client needs, and identify the things the vendor can actually, within reasonable costs, deliver. Often at this point, the client has to be apprised of those things which are beyond budget and could be put off to an upgrade and those things the client needs to budget in. The BSA must be thoroughly versed in what his/her company can provide and how this has to be conveyed to the design staff clearly. This is the perfect time to use use-case and data flow diagrams before (on the existing system) and after (on the proposed system). This often makes it easier for the client to recognize time and cost savings. Once the negotiations for requirements are complete, the vendor will write up a Requirements Document, which is signed by the company sponsor and the vendor — this becomes the contract between the two; the client agrees to the price, and the vendor agrees to the timeline and deliverables. Another phase of the analysis is of course feasibility. If it can’t be done within a reasonable budget, the vendor eats the cost and goes on to another client. The cost includes not only hardware (new or upgrades) and software, but also labor costs for development, testing, installation and training.
Ask yourself which modeling method would be most effective for you and why. What types of logical and physical modeling methods have you seen before? Have they worked well in those situations, or would another described model work more effectively? Why or why not? Additionally, consider how these models prepare for the development or selection processes that follow.
Now you may turn to designing a system. Many IT professionals try to start this how part of the process before they’ve completed the what part of the process. The problem with this is that many of the whats are overlooked because people jump to how. Using the models to switch from the whats to the hows not only helps make sure nothing is missed along the way, but it also properly prepares for the development processes
One of the easiest ways for people to understand is to create a visual representation – a system model. The logical model depicts what a system is or what a system must do and not how the system will be implemented. Logical models express business requirements and not the technical solution which is called the physical model. For example, a logical model might show that the new system will store student grade point averages. The system will need to store values from 0.00 to 4.00, a student will have some value in that range, and every student starts with 0.00.
The physical model shows what the systems is or does and how the system is physically and technically implemented. It reflects the technology used and the limitation of the technology choice. Using the grade point average as an example, the physical model will show where the data is stored, the database column name, and the data types to be used.
Combined file systems are most often the case for companies of all sorts, since companies usually grow their systems from the originals. Most likely the original file is a master file such as a product file supplied by the main vendor. The product need not be a retail item – it can be parts for a mechanic shop, time tracking software for a casino or consulting company, or even modules for software systems (CASE systems or C++ libraries). The table files involved might be HR information on employees, prices to be charged for resale items, or units built from parts purchased. The table files could also cover sales.
Transaction files are used when a company needs to build OLAP cubes for the marketing department, reviewing sales or processes from different master files. Since these need to be updated regularly (usually daily), they would actually be saved files. Management of these files might include coordinating three master files (the tech support oracle system, the phone system and the help desk records, for instance). Another use of a transaction file would be coordination of action information for marketing – an example would be OLAP cubes generated at 9 AM seven days a week at a casino for the marketing department to evaluate their strategies. This would be done by an automated transaction file.
Work files are usually built into other transaction files. One example might be information for Crystal Reports; report generation is not built into Oracle as it is in Access.
Security files are very important and should be built into any database or other file which is used by a company, especially audit trails. Ask me if you don’t know what an audit trail is. I would place backups under the heading of history files/archiving rather than security, but this is just a question of semantics.
Actually, all of this can be put under the heading of semantics. Do we really care what kind of a file x is? No. But it helps us to see how many kinds of files are actually being used; they are often interrelated or even inter-incorporated.
Economy of scale is very important due to the scale of enterprise systems. Most large companies have what’s called a “smokestack” system – applications built upon legacy applications. Due to the size of the legacy systems it appears more economic simply to add managing systems. However, this eventually becomes too slow or cumbersome; sooner or later most companies have to revamp the whole thing.
A DBA (database administrator) may need to be called in if the proposed system involves management of databases. The person must understand database systems, the business at hand, programming and database management systems. Thanks to middleware like Cold Fusion or Visual Basic, it saves a DBA from having to learn CGI.
Dashboards are used by all kinds of departments and users to keep important information quickly available. Information dashboards are used by management to report information to senior executives. The name came from the car dashboard which informs the driver about the status and operation of his or her vehicle at a glance; dashboards provide useful information at a glance. The role of an information dashboard is to quickly inform users which enables management to make informed decisions. This might be a module to offer in the system design. Some key points to consider when designing a dashboard are to understand the user requirements, placement of data on the dashboard, and how will the data be represented.
To understand the user requirements for dashboards an analyst may ask questions such as what data should be displayed. What is the main in use of the dashboard? How frequently will a user visit the dashboard? What decisions does a user make after visiting the dashboard? Does the dashboard need to alert a user of a particular event?
Further considerations in the design of a dashboard are where will the data be placed. How to arrange the data on a page and not based on the visual presence of the page, but the way that the information flow represents real-life business workflow needs to be included. It must represent the critical action items, show comparison data, or be grouped in a logical manner.
How the data is represented is important based on the type and use of the data. The data can be displayed as a bar chart, pie chart, or line graph. Or it could simply be a menu for selecting more detail or a variety of applications.
Use bar charts when values need to be compared or frequencies are represented. Use a pie chart to represent percentage of distribution. For example, to show what the percentage of claims that are paid in the western region vs. eastern region. Line graphs are best used when representing values and trends over time. This would display if something is increasing, decreasing, or staying the same.
What is a thin client? When there were only mainframes, the terminal had no disk of its own, floppy or hard. Instead, it was simply a monitor and a keyboard.
Networks function differently; instead of one humongous ‘brain’ managing all the information, a network has a server for a brain. This wasn’t possible until personal computers had become successful. The server sends out information calling for a particular node (workstation). Along the lines of the network, each PC picks up the call, and decides if it’s for that node If it is, the node sends back a message saying ‘here I am’ and the server and the node pass information back and forth. If the call is not for that node, the node passes the information on to the next node. So both nodes and server are involved in the passing of information. In order to do this, the node needs an Ethernet card to hook up to the network cabling and some software loaded onto its hard disk to manage the network traffic. For speed, the applications were loaded onto the nodes but they could also be loaded into RAM with limitations. Now, improvements in technology have made it possible to load all the networking software into the network card (or a docking station for laptops). Memory has become cheap, so the monitor can now have huge RAM to hold application information. So there is no more need for a hard disk. Instead of a large tower or box, the node (client) becomes very thin. This type of a network runs what is called client-server software. The nodes are much less expensive than standalone PCs. And the cabling has become very thin and flexible, unlike the bulky cable used for mainframes or even the old Ethernet cable (which looks like the cable for your cable TV).
Some of the factors that will be used to evaluate the design tradeoffs include: reliability, expandability, programmability, maintainability, compatibility, adaptability, availability, development status and cost. The decision at this point may be to choose one of these assets over another, usually for financial concerns.
- Reliability – examines not only the robustness of the hardware, but of software, including load stress
- Expandability – measures the computer system’s ability to conveniently accommodate increased requirements by higher speed or by physical expansion, without the cost of a major redesign.
- Programmability –the ease of programming the computer should be considered early in the design. The degree of software sophistication and the availability of support software should be considered during the design.
- Maintainability – should not be neglected when designing the computer. The tradeoff should consider the use of a degraded mode of operation. The design should provide case of accessibility and should minimize the possibility of damage to other parts during maintenance. If replaced assemblies are to be discarded rather than repaired, maximum cost goals for a replaceable module should be established.
- Compatibility – must be developed between the computer and its interfaces, software, power levels, and, where necessary, ground computers.
- Adaptability – defined as the ability of the system to meet a wide range of functional requirements without requiring physical modification. The design should consider specific features which allow tailoring a basic machine to different situations, such as an adjustable word length through byte organized operations, alterable or unused operation codes, reserved fields within formats, and adjustable speed.
- Availability – the probability that the computer is operating satisfactorily at a given time.
- Development Status and Cost – complex management-related factors which can have significant effects on the design. In estimating cost, the manager should consider the total long-range expenditures as well as initial outlays, and also the cost of potential delays in developing advanced techniques, etc.
In addition to the above qualitative factors, tradeoffs should be determined on the basis of specified quantitative factors, such as precision, speed, capacity, weight, volume, and power.
illustrations courtesy of Microsoft clip art
Copyright 2009: Bonnie-Jean Rohner.