Software Engineering Body of Knowledge (v3) (2014) (811503), страница 82
Текст из файла (страница 82)
An iconic model is a visually equivalent but incomplete 2-dimensionalor 3-dimensional representation—for example,maps, globes, or built-to-scale models of structures such as bridges or highways. An iconicmodel actually resembles the artifact modeled.In contrast, an analogic model is a functionallyequivalent but incomplete representation. Thatis, the model behaves like the physical artifacteven though it may not physically resemble it.Examples of analogic models include a miniatureairplane for wind tunnel testing or a computersimulation of a manufacturing process.Finally, a symbolic model is a higher level ofabstraction, where the model is represented usingsymbols such as equations. The model capturesthe relevant aspects of the process or system insymbolic form.
The symbols can then be used toincrease the engineer’s understanding of the finalsystem. An example is an equation such as F =Ma. Such mathematical models can be used todescribe and predict properties or behavior of thefinal system or product.5.2. SimulationAll simulation models are a specification of reality. A central issue in simulation is to abstractand specify an appropriate simplification ofreality. Developing this abstraction is of vitalimportance, as misspecification of the abstraction would invalidate the results of the simulationexercise.
Simulation can be used for a variety oftesting purposes.Simulation is classified based on the type ofsystem under study. Thus, simulation can be eithercontinuous or discrete. In the context of softwareengineering, the emphasis will be primarily ondiscrete simulation. Discrete simulations maymodel event scheduling or process interaction.The main components in such a model includeentities, activities and events, resources, the stateof the system, a simulation clock, and a randomnumber generator. Output is generated by thesimulation and must be analyzed.An important problem in the development of adiscrete simulation is that of initialization.
Beforea simulation can be run, the initial values of allthe state variables must be provided. As the simulation designer may not know what initial valuesare appropriate for the state variables, these values might be chosen somewhat arbitrarily. Forinstance, it might be decided that a queue shouldbe initialized as empty and idle. Such a choice ofinitial condition can have a significant but unrecognized impact on the outcome of the simulation.5.3. PrototypingConstructing a prototype of a system is anotherabstraction process.
In this case, an initial versionof the system is constructed, often while the system is being designed. This helps the designersdetermine the feasibility of their design.There are many uses for a prototype, including the elicitation of requirements, the design andrefinement of a user interface to the system, validation of functional requirements, and so on. Theobjectives and purposes for building the prototype will determine its construction and the levelof abstraction used.The role of prototyping is somewhat differentbetween physical systems and software.
Withphysical systems, the prototype may actuallybe the first fully functional version of a systemor it may be a model of the system. In softwareengineering, prototypes are also an abstractmodel of part of the software but are usually notconstructed with all of the architectural, performance, and other quality characteristics expectedin the finished product. In either case, prototypeconstruction must have a clear purpose and beplanned, monitored, and controlled—it is a technique to study a specific problem within a limitedcontext [6*, c2s8].In conclusion, modeling, simulation, and prototyping are powerful techniques for studying thebehavior of a system from a given perspective.All can be used to perform designed experimentsto study various aspects of the system. However, these are abstractions and, as such, may notmodel all attributes of interest.15-12 SWEBOK® Guide V3.06. Standards[5*, c9s3.2] [13*, c1s2]Moore states that astandard can be; (a) an object or measureof comparison that defines or representsthe magnitude of a unit; (b) a characterization that establishes allowable tolerancesfor categories of items; and (c) a degree orlevel of required excellence or attainment.Standards are definitional in nature, established either to further understanding andinteraction or to acknowledge observed (ordesired) norms of exhibited characteristicsor behavior.
[13*, p8]Standards provide requirements, specifications, guidelines, or characteristics that must beobserved by engineers so that the products, processes, and materials have acceptable levels ofquality. The qualities that various standards provide may be those of safety, reliability, or otherproduct characteristics. Standards are consideredcritical to engineers and engineers are expected tobe familiar with and to use the appropriate standards in their discipline.Compliance or conformance to a standard letsan organization say to the public that they (ortheir products) meet the requirements stated inthat standard. Thus, standards divide organizations or their products into those that conform tothe standard and those that do not. For a standardto be useful, conformance with the standard mustadd value—real or perceived—to the product,process, or effort.Apart from the organizational goals, standardsare used for a number of other purposes suchas protecting the buyer, protecting the business,and better defining the methods and proceduresto be followed by the practice.
Standards alsoprovide users with a common terminology andexpectations.There are many internationally recognizedstandards-making organizations including theInternational Telecommunications Union (ITU),the International Electrotechnical Commission(IEC), IEEE, and the International Organizationfor Standardization (ISO). In addition, there areregional and governmentally recognized organizations that generate standards for that region orcountry.
For example, in the United States, thereare over 300 organizations that develop standards. These include organizations such as theAmerican National Standards Institute (ANSI),the American Society for Testing and Materials(ASTM), the Society of Automotive Engineers(SAE), and Underwriters Laboratories, Inc. (UL),as well as the US government. For more detailon standards used in software engineering, seeAppendix B on standards.There is a set of commonly used principlesbehind standards. Standards makers attempt tohave consensus around their decisions. There isusually an openness within the community ofinterest so that once a standard has been set, thereis a good chance that it will be widely accepted.Most standards organizations have well-definedprocesses for their efforts and adhere to thoseprocesses carefully.
Engineers must be aware ofthe existing standards but must also update theirunderstanding of the standards as those standardschange over time.In many engineering endeavors, knowing andunderstanding the applicable standards is criticaland the law may even require use of particularstandards. In these cases, the standards often represent minimal requirements that must be met bythe endeavor and thus are an element in the constraints imposed on any design effort. The engineer must review all current standards related toa given endeavor and determine which must bemet. Their designs must then incorporate any andall constraints imposed by the applicable standard. Standards important to software engineersare discussed in more detail in an appendix specifically on this subject.7. Root Cause Analysis[4*, c5, c3s7, c9s8] [5*, c9s3, c9s4, c9s5][13*, c13s3.4.5]Root cause analysis (RCA) is a process designedto investigate and identify why and how anundesirable event has happened.
Root causesare underlying causes. The investigator shouldattempt to identify specific underlying causes ofthe event that has occurred. The primary objectiveEngineering Foundations 15-13of RCA is to prevent recurrence of the undesirable event. Thus, the more specific the investigator can be about why an event occurred, the easierit will be to prevent recurrence. A common wayto identify specific underlying cause(s) is to ask aseries of why questions.7.1. Techniques for Conducting Root CauseAnalysis[4*, c5] [5*, c3]There are many approaches used for both qualitycontrol and root cause analysis.
The first step inany root cause analysis effort is to identify the realproblem. Techniques such as statement-restatement, why-why diagrams, the revision method,present state and desired state diagrams, and thefresh-eye approach are used to identify and refinethe real problem that needs to be addressed.Once the real problem has been identified, thenwork can begin to determine the cause of theproblem. Ishikawa is known for the seven toolsfor quality control that he promoted.
Some ofthose tools are helpful in identifying the causesfor a given problem. Those tools are check sheetsor checklists, Pareto diagrams, histograms, runcharts, scatter diagrams, control charts, andfishbone or cause-and-effect diagrams. Morerecently, other approaches for quality improvement and root cause analysis have emerged. Someexamples of these newer methods are affinity diagrams, relations diagrams, tree diagrams, matrixcharts, matrix data analysis charts, process decision program charts, and arrow diagrams. A fewof these techniques are briefly described below.A fishbone or cause-and-effect diagram is away to visualize the various factors that affectsome characteristic. The main line in the diagramrepresents the problem and the connecting linesrepresent the factors that led to or influenced theproblem.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
