DEVTOME.COM HOSTING COSTS HAVE BEGUN TO EXCEED 115$ MONTHLY. THE ADMINISTRATION IS NO LONGER ABLE TO HANDLE THE COST WITHOUT ASSISTANCE DUE TO THE RISING COST. THIS HAS BEEN OCCURRING FOR ALMOST A YEAR, BUT WE HAVE BEEN HANDLING IT FROM OUR OWN POCKETS. HOWEVER, WITH LITERALLY NO DONATIONS FOR THE PAST 2+ YEARS IT HAS DEPLETED THE BUDGET IN SHORT ORDER WITH THE INCREASE IN ACTIVITY ON THE SITE IN THE PAST 6 MONTHS. OUR CPU USAGE HAS BECOME TOO HIGH TO REMAIN ON A REASONABLE COSTING PLAN THAT WE COULD MAINTAIN. IF YOU WOULD LIKE TO SUPPORT THE DEVTOME PROJECT AND KEEP THE SITE UP/ALIVE PLEASE DONATE (EVEN IF ITS A SATOSHI) TO OUR DEVCOIN 1M4PCuMXvpWX6LHPkBEf3LJ2z1boZv4EQa OR OUR BTC WALLET 16eqEcqfw4zHUh2znvMcmRzGVwCn7CJLxR TO ALLOW US TO AFFORD THE HOSTING.

THE DEVCOIN AND DEVTOME PROJECTS ARE BOTH VERY IMPORTANT TO THE COMMUNITY. PLEASE CONTRIBUTE TO ITS FURTHER SUCCESS FOR ANOTHER 5 OR MORE YEARS!

Designing a system

By the time the analyst gets to the Design stage they will

  • Understand the business and operations in detail.
  • Understand the problem area in detail.
  • Have agreed with the customer what they want the new system to do.
  • Have outlined the solution.

They now need to go ahead and design the detail of the solution to the problem. Many of those things done as part of the Systems Analysis stage of the project life cycle will be done again in this stage, but this time for the proposed system. What the Analyst should be trying to do is provide the best solution that meets the Requirements Specification. In the Analysis stage, they will have outlined a proposed solution that will really help a company solve a problem. They won't simply be trying to convert a paper-based system into a computerised one. They will be trying to make the whole process more efficient, for example, by automating tasks, by adding facilities that currently are not part of the system and using features in any new technology. The areas that need to be considered are:

1.Written descriptions. 
2.Diagrammatic representations. 
3.Data dictionary. 
4.Input design. 
5.Output design. 
6.Program specification. 

When the Design stage is complete, it should be possible to give all of the design documentation to any programmer or builder of systems and they should be able to construct the system from those documents alone! This statement is important. It tells you the amount of detail that is needed and the clarity of communication that is required by the documentation.

Written descriptions

A good starting point for the design stage is for the Analyst is to write out in the future tense how the proposed system will work. They should try to picture people using the system and describe what they are doing. They should describe each task a user needs to perform and how it is carried out. They need to paint very clear pictures with their descriptions so that they are understood by anyone who needs to refer to them.

Diagrammatic representations

Once they have described the system in writing, they should then produce diagrammatic representations of the design. This will involve producing Dataflow Diagrams and Structure Diagrams of the proposed system. These were described earlier. It is useful to know that there are other diagrams that could be used here as well as the ones already mentioned. Although we will save the detail about these and how they are used for later chapters, we will briefly mention them.

  • Entity-Relationship diagrams. These diagrams summarise how records in a database are to be organised into tables and how the tables are related.
  • Entity Life Histories. These diagrams summarise what happens to a particular record in a database. For example, they will show that at some point a new record is created, and it gets amended, and it gets removed completely from the system.
  • Normalisation. This is a technique that helps produce an efficient database design.

Diagrams generally are good because:

1.They summarise information. 
2.They clarify complex systems. 
3.They can be used by teams to discuss a system in meetings. 
4.They may be used to help explain certain things to customers. 
5.They will become part of the Technical Document, to help people make modifications to the system in the future. 

Data dictionary

A data dictionary needs to be produced for the new system. This may well involve simply copying parts of the data dictionary produced for the old system to the new data dictionary and then adding any additional items that are required. The data dictionary was discussed in detail in the previous section.

Input design

When designing the way that data will get from the outside world into any computer system, some questions need to be asked. These include:

  • Will the data be collected first on paper forms, for example and then put in, or will the data be entered in directly?
  • In what form will the data be in if it is entered in automatically? For example, will it be coded up in a bar code, or using MICR, or using OCR, or in some other way?
  • What hardware exists, or will exist, to get the data into the computer? Will there be keyboards, a graphics tablet, touch-screens, microphones for voice recognition, for example?
  • What skills will the operators have? Do any disabilities need to be taken into account, for example?
  • What kind of interface will be appropriate for the system? For example, is a command line interface appropriate, or a menu-driven interface, or a different type of interface appropriate?

Output design

When designing the way that data will get from the computer system into the outside world, similar questions to the design of input methods need to be asked. Who are the users, what are their skills, do they have any special needs, where will the output come out, where will it be used and what will be done with it? The key question to remember here is, 'Who needs what information from the system, when and in what form?' There are a number of output techniques that could be considered.

  • Audio could be used to signal alarms in noisy, busy factories or to signal a break-in in a house.
  • Key information on a VDU could be colour-coded or a different font size or style used.
  • Important information could flash.
  • Pictures could be used to represent or reinforce information.
  • Graphs can be used to display information such as temperature trends over a period of time in a chemical factory.
  • Printouts could be used so that information can be transferred from the computer to a warehouse where it is needed to collect goods, for example.
  • Plotters can be used to provide large accurate drawings in an engineering design department.
  • Dot matrix printers can be used to provide physical copies of key documents.

Program specification

Solutions may require some programming. Part of the design documentation, therefore, needs to describe the functions that any code will perform. These can be described by•Writing a description of each function in detail.

  • Writing pseudo-code for each function.
  • Producing diagrams such as a flow chart or a Jackson diagram.

The specification will also identify the language to use and program libraries needed along with the routines within them.


Business | Systems


QR Code
QR Code design_specification (generated for current page)
 

Advertise with Anonymous Ads