Sign-up today to join over 5 million learners already on ALISON:

ALISON: Diploma in Project Management


Comments about The design phase - The Design Phase: factors to be considered when designing the input Requirements

The comment must be about:
- Module: The design phase
- Topic: The Design Phase: factors to be considered when designing the input Requirements
Please note: Comments are not reviewed by ALISON Support staff. For technical support, please contact [email protected]

Latest Comments

  • aaa
    Bisheswar Boro India The input design is very vital to the successful creation of computer system.
    2015-04-30 07:04:12

  • aaa
    Ve Yardon United States of America Error free data is so important critical in this Phase.
    2015-04-26 21:04:49

  • aaa
    Rosemary Orji Nigeria why does input requirement come after output requirement?
    2015-04-23 14:04:41

  • aaa
    sunday mbiam Nigeria what data needs to be obtained to produce that output ?
    2015-04-22 13:04:24

  • aaa
    Uba Oguchi Christian Nigeria having past through established what the system needs to produce to meet its goals, the next is to establishing what data needs to be obtained to produce that output. the input design is very vital to the successful creation of computer system. the input must be collected from various sources with a minimal amount of errors, and with the greatest possible speed. there are a lot of techniques that a good programmer will use to ensure that the data they collect is of the best quality possible. They will limit the opportunities for the user to enter the wrong data, and will ensure the user does not have to enter data twice. When designing input, the programmer should put all these in considerations. i. Identify duplicate data ii. Identify methods of reducing input errors iii. Identify data validation checks iv. Input screen/method design
    2015-04-09 14:04:42

  • aaa
    Brian Kuhuni Nigeria gigo
    2015-04-08 13:04:56

  • aaa
    Jahidul Islam Bangladesh what is GIGO ?
    2015-04-07 22:04:19

    • aaa
      Philemon Flahn Johnson Liberia GIGO means garbage in garbage out
      2015-04-15 23:04:02
  • aaa
    Jahidul Islam Bangladesh Having established what the system needs to produce to meet its goals, the next area of interest is establishing what data needs to be obtained to produce that output. The design of the input is vital to the successful creation of a computer system. Put simply, the input must be collected from the various sources with a minimal amount of errors, and with the greatest possible speed. A common term used to describe data entry is GIGO - garbage in, garbage out. This expression highlights the importance of input design to the quality of the program produced. The final output will only be as accurate as the data put into the system - and the quality of that data will be partly determined by the quality of the design of the collection methods. There are a number of techniques that a good programmer will use to ensure that the data they collect is of the best quality possible. They will limit the opportunities for the user to enter the wrong data, and will ensure the user does not have to enter data twice. When designing input, the programmer should: Identify duplicate data - Efficient program design requires that the program only collect and store each data element once. Programmers should analyse the data requirements and identify where data is used more than once and ensure it is collected just once. It is important to do this - while it may be easier to collect data more than once, rather than create highly complex data structures, this approach compromises the integrity of the information produced, as it allows for more input errors and the creation of conflicting outputs.
    2015-04-07 22:04:04

  • aaa
    Bandar Alalwi United States of America what are designing input ?
    2015-04-06 16:04:30

  • aaa
    Bandar Alalwi United States of America requirements need for designing input.
    2015-04-06 16:04:18

  • aaa
    Bander Alalwi United States of America what data needs to be obtained to produce that output ?
    2015-04-04 19:04:38

  • aaa
    Bander Alalwi United States of America what data needs to be obtained to produce that output.
    2015-04-04 19:04:15

  • aaa
    Kolawole Ajibola Nigeria To get over this deficiency a programmer can practice by using the IDE's own debugger as an aide, if it has the ability to step through the code one line at a time. In Visual Studio, for example, this means setting a break point at the beginning of the problem area and stepping through with the 'F11' key, inspecting the value of variables--before and after they change--until you understand what the code is doing. If the target environment doesn't have such a feature, then do your practice-work in one that does. The goal is to reach a point where you no longer need the debugger to be able to follow the flow of code in your head, and where you are patient enough to think about what the code is doing to the state of the program. The reward is the ability to identify redundant and unnecessary code, as well as how to find bugs in existing code without having to re-implement the whole routine from scratch. 2. Poor understanding of the language's programming model Object Oriented Programming is an example of a language model, as is Functional or Declarative programming. They're each significantly different from procedural or imperative programming, just as procedural programming is significantly different from assembly or GOTO- based programming. Then there are languages which follow a major programming model (such as OOP) but introduce their own improvements such as list comprehensions, generics, duck-typing, etc. Symptoms Using whatever syntax is necessary to break out of the model, then writing the remainder of the program in their familiar language's style (OOP) Attempting to call non-static functions or variables in unsubstantiated classes, and having difficulty understanding why it won't compile (OOP) Writing lots of "xxxxx Manager" classes that contain all of the methods for manipulating the fields of objects that have little or no methods of their own (Relational) Treating a relational database as an object store and performing all joins and relation enforcement in client code (Functional) Creating multiple versions of the same algorithm to handle different types or operators, rather than passing high-level functions to a generic implementation (Functional) Manually caching the results of a deterministic function on platforms that do it automatically (such as SQL and Haskell) Using cut-n-paste code from someone else's program to deal with I/O and Nomads (Declarative) Setting individual values in imperative code rather than using data-binding Remedies If your skills deficiency is a product of ineffective teaching or studying, then an alternative teacher is the compiler itself. There is no more effective way of learning a new programming model than starting a new project and committing yourself to use whatever the new constructs are, intelligently or not. You also need to practice explaining the model's features in crude terms of whatever you are familiar with, then recursively building on your new vocabulary until you understand the subtleties as well. For example: Phase 1: "OOP is just records with methods" Phase 2: "OOP methods are just functions running in a mini-program with its own global variables" Phase 3: "The global variables are called fields, some of which are private and invisible from outside the mini-program" Phase 4: "The idea of having private and public elements is to hide implementation details and expose a clean interface, and this is called Encapsulation" Phase 5: "Encapsulation means my business logic doesn't need to be polluted with implementation details" Phase 5 looks the same for all languages, since they are all really trying to get the programmer to the point where he can express the intent of the program without burying it in the specifics of how. Take functional programming as another example: Phase 1: "Functional programming is just doing everything by chaining deterministic functions together" Phase 2: "When the functions are deterministic the compiler can predict when it can cache results or skip evaluation, and even when it's safe to prematurely stop evaluation" Phase 3: "In order to support Lazy and Partial Evaluation, the compiler requires that functions are defined in terms of how to transform a single parameter, sometimes into another function. This is called Currying" Phase 4: "Sometimes the compiler can do the Currying for me" Phase 5: "By letting the compiler figure out the mundane details, I can write programs by describing what I want, rather than how to give it to me" 3. Deficient research skills / Chronically poor knowledge of the platform's features Modern languages and frameworks now come with an awesome breadth and depth of built-in commands and features, with some leading frameworks (Java, .Net, Cocoa) being too large to expect any programmer, even a good one, to learn in anything less than a few years. But a good programmer will search for a built-in function that does what they need before they begin to roll their own, and excellent programmers have the skill to break-down and identify the abstract problems in their task, then search for existing frameworks, patterns, models and languages that can be adapted before they even begin to design the program. Symptoms These are only indicative of the problem if they continue to appear in the programmer's work long after he should have mastered the new platform. Re-inventing or laboring without basic mechanisms that are built-into the language, such as events-and-handlers or regular expressions Re-inventing classes and functions that are built-into the framework (eg: timers, collections, sorting and searching algorithms) * "Roundabout code" that accomplishes in many instructions what could be done with far fewer (eg: rounding a number by converting a decimal into a formatted string, then converting the string back into a decimal) Persistently using old-fashioned techniques even when new techniques are better in those situations (eg: still writes named delegate functions instead of using lambda expressions) Having a stark "comfort zone", and going to extreme lengths to solve complex problems with primitives * - Accidental duplication will also happen, proportionate to the size of the framework, so judge by degree. Someone who hand-rolls a linked list might Know What They Are Doing, but someone who hand-rolls their own Stripy() probably does not. Remedies A programmer can't acquire this kind of knowledge without slowing down, and it's likely that he's been in a rush to get each function working by whatever means necessary. He needs to have the platform's technical reference handy and be able to look through it with minimal effort, which can mean either having a hard copy of it on the desk right next to the keyboard, or having a second monitor dedicated to a browser. To get into the habit initially, he should refactor his old code with the goal of reducing its instruction count by 10:1 or more. 4. Inability to comprehend pointers If you don't understand pointers then there is a very shallow ceiling on the types of programs you can write, as the concept of pointers enables the creation of complex data structures and efficient APIs. Managed languages use references instead of pointers, which are similar but add automatic referencing and prohibit pointer arithmetic to eliminate certain classes of bugs. They are still similar enough, however, that a failure to grasp the concept will be reflected in poor data-structure design and bugs that trace back to the difference between pass-by-value and pass-by-reference in method calls. Symptoms Failure to implement a linked list, or write code that inserts/deletes nodes from linked list or tree without losing data Allocating arbitrarily big arrays for variable-length collections and maintaining a separate collection-size counter, rather than using a dynamic data structure Inability to find or fix bugs caused by mistakenly performing arithmetic on pointers Modifying the referenced values from pointers passed as the parameters to a function, and not expecting it to change the values in the scope outside the function Making a copy of a pointer, changing the referenced value via the copy, then assuming the original pointer still points to the old value Serializing a pointer to the disk or network when it should have been the dereferenced value Sorting an array of pointers by performing the comparison on the pointers themselves
    2015-04-01 14:04:44

  • aaa
    Lee Jones Ireland Duplication and errors can easily fall through the net so the old adage of measure twice and cut once is applicable at this stage. always double check any input as any errors in the information that you input can skew any data in the future.
    2015-03-31 19:03:02

  • aaa
    Saheed Ashimi Nigeria Input requirements is crucial at this stage , and utmost care and diligence must be taken as well because the quality of what goes in in the design of a system will definitely affect the outputs or deliverable expected whether good or bad.
    2015-03-30 17:03:52

  • aaa
    Genaro Ceballos Panama Identify data, methods and controls for design
    2015-03-27 14:03:11

  • aaa
    Moses Sahr Fayiah Sierra Leone the message about this topic was well understood.
    2015-03-21 19:03:23

  • aaa
    Odongo Moses Uganda The Design Phase: factors to be considered when designing the input Requirements. When designing input, the programmer should: Identify duplicate data - Efficient program design requires that the program only collect and store each data element once. Programmers should analyse the data requirements and identify where data is used more than once and ensure it is collected just once. It is important to do this - while it may be easier to collect data more than once, rather than create highly complex data structures, this approach compromises the integrity of the information produced, as it allows for more input errors and the creation of conflicting outputs. Identify methods of reducing input errors - When collecting data, the programmer should make use of as many of the features available to ensure that the data being collected is as free from errors as possible. This can be achieved through the use of features like drop down boxes, radio buttons, check boxes etc. that limit the user to selecting from pre-defined "correct" options. By carefully constructing input screens, it is possible to limit the number of areas the users can enter invalid data. Identify data validation checks - While it is possible to limit the users choices to pre-defined choices, it may not always be possible or practical to do so. An example would be postcodes. While all postcodes are pre-defined, there are so many of them it would not be possible to list them all on a screen, so another method must be employed to make sure the data is accurate. Writing code to check the data is accurate can do this. For example, the postcodes could be checked to see if they fall within the expected range for the state given. While this relies on the user to input correct data, it does reduce the amount of incorrect data the system collects. Input screen/method design - Thought needs to be given to the actual design of the input collection screens or methods. Care needs to be taken to ensure the screens that collect the data are arranged in an attractive and logical manner. If data is to be entered from a form, then the data collection screens should follow the general format of those screens to make data entry easier, and therefore less prone to errors.
    2015-03-17 15:03:10

  • aaa
    Stanley Amaechi Nigeria well understood
    2015-03-16 14:03:12

  • aaa
    Oyetope Oyewunmi Nigeria It is well explained
    2015-03-15 17:03:57

Loading Menu