Pros and Cons of Simulation

Pros

There are two big advantages to performing a simulation rather than actually building the design and testing it. The biggest of these advantages is money. Designing, building, testing, redesigning, rebuilding, retesting,... for anything can be an expensive project. Simulations take the building/rebuilding phase out of the loop by using the model already created in the design phase. Most of the time the simulation testing is cheaper and faster than performing the multiple tests of the design each time. Considering the typical university budget cheaper is usually a very good thing. In the case of an electric thruster the test must be run inside of a vacuum tank. Vacuum tanks are very expensive to buy, run, and maintain. One of the main tests of an electric thruster is the lifetime test, which means that the thruster is running pretty much constantly inside of the vacuum tank for 10,000+ hours. This is pouring money down a drain compared to the price of the simulation.

The second biggest advantage of a simulation is the level of detail that you can get from a simulation. A simulation can give you results that are not experimentally measurable with our current level of technology. Results such as surface interactions on an atomic level, flow at the exit of a micro electric thruster, or molecular flow inside of a star are not measurable by any current devices. A simulation can give these results when problems such as it's too small to measure, the probe is too big and is skewing the results, and any instrument would turn to a gas at those temperatures come into the conversation. You can set the simulation to run for as many time steps you desire and at any level of detail you desire the only restrictions are your imagination, your programming skills, and your CPU.



Cons

There are two big disadvantages to performing a simulation as well. The first of these disadvantages is simulation errors. Any incorrect key stroke has the potential to alter the results of the simulation and give you the wrong results. Also usually we are programming using theories of the way things work not laws and theories are not often 100% correct. Provided that you can get your simulation to give you accurate results you must first run a base line to prove that it works. In order for the simulation to be accepted in the general community you have to take experimental results and simulate them. If the two data sets compare, then any simulation you do of your own design will have some credibility.

The other large disadvantage is the fact that it is a simulation. Many people do not consider what they do engineering unless they can see, hear, feel, and taste the project. If you are designing a light saber a typical engineer needs to be able to hold the light saber in their hand in order to consider the project worth his or her time. If you are capable of moving your craft into the virtual world of simulations you are no longer restricted by little things like reality. If you want to design a light saber in the virtual world it is not a problem, but in reality that is another matter all together. The virtual world is difficult to get use to the first time you use it for design, but after that the sky isn't even your limit

Process Flow Chart / System Flow Chart.

A system flowchart is a concrete, physical model that documents, in an easily visualized, graphical form, the system’s discrete physical components (its programs, procedures, files, reports, screens, etc.).

A system flowchart is a valuable presentation aid because it shows how the system’s major components fit together and interact. In effect, it serves as a system roadmap. During the information gathering stage, a system flowchart is an excellent tool for summarizing a great deal of technical information about the existing system. A system flowchart can also be used to map a hardware system.

System flowcharts are valuable as project planning and project management aids. Using the system flowchart as a guide, discrete units of work (such as writing a program or installing a new printer) can be identified, cost estimated, and scheduled. On large projects, the components suggest how the work might be divided into subsystems.

Historically, some analysts used system flowcharts to help develop job control language specifications. For example, IBM’s System/370 job control language requires an EXEC statement for each program and a DD statement for each device or file linked to each program. Consequently, each program symbol on the system flowchart represents an EXEC statement and each file or peripheral device symbol linked to a program by a flowline implies a need for one DD statement. Working backward, preparing a system flowchart from a JCL listing is good way to identify a program’s linkages.

A system flowchart’s symbols represent physical components, and the mere act of drawing one implies a physical decision. Consequently, system flowcharts are poor analysis tools because the appropriate time for making physical decisions is after analysis has been completed.

A system flowchart can be misleading. For example, an on-line storage symbol might represent a diskette, a hard disk, a CD-ROM, or some combination of secondary storage devices. Given such ambiguity, two experts looking at the same flowchart might reasonably envision two different physical systems. Consequently, the analyst’s intent must be clearly documented in an attached set of notes.


Here is a picture of how a system / process flow chart would look like:

For more information please click Here.

ICT Home-Work

Data Flow Diagram [DFD]

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modelling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated.[2] DFDs can also be used for the visualization of data processing (structured design).


A DFD shows what kinds of data will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel

Flow Chart

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem. Process operations are represented in these boxes, and arrows connecting them represent flow of control. Data flows are not typically represented in a flowchart, in contrast with data flow diagrams; rather, they are implied by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.

Article about (DESIGN STAGE) in a Systems Life Cycle

Sorry if the picture is not clear... for more information please click Here

Thank You.

System Life Cycle ( Analysis )

Analysis is the process of examining a system and collecting information about it to know how it works, the way its processed and the what are its outputs, so that it could be decided what kind of computer system shall be used.
As mentioned before,Analysis involves the examining of a system in detail. and to succesfully examine a system, these stages/steps must be followed:
1- Collecting information about how the system works.
2-Establishing its inputs , outputs and processing.
3-Recording information.
4-identifying problems.


The first step in system analysis is collecting information - as mentioned up - and there are 4 methods of collecting information about the system, they are:


1-Examination of Documents: Examining all the documents in a system, this will help the analyst to identify the outputs and inputs of the system and that moment.

2-interviews: interviewing workers and ask them questions about the way the system works , but asking all the workers will take a lot of time,instead, key personnel or representatives of the other workers can be interviewed with, and questions can be changed because interviewing is a flexible method. ( the next question can be asked according to the answer of the worker interviewed )

3-Observation: Watching all the workers do their job and investigating the way each individual work and how workers interact with each other, this will enable the analyst to see the system as a whole.

4-Questionnaires: by making perfectly phrased questions to get the desired kind of information,or a list of answers can be mentioned and the worker will chose the one he wants, the questions are wrote down in a paper and then given to all workers so that they answer according to the questions. The making of the questions may take some time but once the papers are spread among the workers, a lot of information will be given. The problem of this way is that questions cannot be changed according to the answers of the workers, therefor its not a flexible way of gathering information.