1 / 34

SE Process Steps and Requirements Allocation

This chapter discusses the steps involved in the system engineering process and the allocation of requirements to specific specifications. It also introduces different types of specifications and their significance in system development.

riding
Download Presentation

SE Process Steps and Requirements Allocation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. EMIS 7307 Problem definition Consumer need Feasibility System operational requirements Maintenance and support concepts Determine/prioritize TPMs Functional analysis Requirements allocation System synthesis Design integration T&E Production Operational use Retirement Chapter 3 From Chapter 2 we had these “steps” in the SE process:

  2. EMIS 7307 Chapter 3 From SE Fundamentals

  3. EMIS 7307 Chapter 3 • Notice how the steps on previous slide map into Fig 3.1 and Fig 1.12. • In Fig 3.2 the MIL-STD-490 terms are used. • Type A, B etc. • Names aren’t important the ideas of flowdown and increasing design detail are! • We’ll use the “490” terminology but understand the meaning behind the type.

  4. EMIS 7307 Chapter 3 • Type A (system spec) - usually only 1. • Technical, performance, operational and support characteristics of the system as whole. • Feasibility,operational requirements, functional analysis products go here. • Defines subsystems. • Has a Section 4!

  5. EMIS 7307 Chapter 3 • Type B (development spec) - usually several. • Technical, performance, operational and support characteristics of specific subsystems. • Performance, effectiveness, and support characteristics are included. • Defines assemblies or CSCIs. • Has a Section 4!

  6. EMIS 7307 Chapter 3 • Type C (product spec) - usually many. • Design details. • Hardware separate from software. • Has a Section 4! • Type D and E • Specific process and material requirements.

  7. EMIS 7307 Chapter 3 From SE Fundamentals

  8. EMIS 7307 Chapter 3 • The requirement allocation process selects assignments of specific allocated requirements to specific specifications. • See Fig 3.3 for an example of a spec “tree”. • Order of precedence is important!

  9. EMIS 7307 Chapter 3 From SE Fundamentals

  10. EMIS 7307 Chapter 3 From SE Fundamentals

  11. EMIS 7307 Chapter 3 • See Fig 3.4. • Type A, • TPMs usually here. • These are the typically used sections. • The essence is the important part but, using this format is comfortable within DOD. • Types B, C etc are typically laid-out the same. • Next page from SEF Guide.

  12. EMIS 7307 Chapter 3 From SE Fundamentals

  13. EMIS 7307 Chapter 3 From SE Fundamentals

  14. EMIS 7307 software development reliability maintainability human factors safety security producibility logistics disposability quality environmental value/cost Chapter 3 Blanchard selects 12 design disciplines for further discussion because they have been historically inadequately integrated into system developments and mainstream design effort. They are: We’ll discuss them briefly, be sure to be aware of the existence of them all and the type of engineering they accomplish!

  15. EMIS 7307 Chapter 3 • Software engineering things to know: • Same processes and flow in the system engineering of software as hardware. • Software engineers may have their own special names but they are equivalent. • Testing subroutines, subprograms and integration into programs flows in a similar fashion as hardware.

  16. EMIS 7307 Chapter 3 • Software engineering things to know: • Verification can include evaluating the consequences of every data path regardless of it’s use likelihood. • Stress testing explores the limits of i/o, throughput and processing. • Software QC deals with subjects like - were the standards followed? • Following three charts are examples of software development methodologies...

  17. EMIS 7307 Structured Analysis, Structured Design User Requirements Analysis User Requirements Specifications Software Requirements Specification System/Broad Design Logical Design Program/Detailed Design Physical Design Implementation/Coding Program Testing: Units Program Testing: System Program Use Software Maintenance

  18. EMIS 7307 Requirements Analysis Design 1 Implement 1 Design 2 Implement 2 Design 3 Implement 3 Test Planning Certification 1 Certification 2 Certification 3

  19. EMIS 7307 Effort Implementation Detailed Design Broad Design Software requirements Requirements analysis Time Object Oriented Design Basic Classes Specific Classes I disagree with the author’s note 12 page 127. Objects are determined by the functional flowdown.

  20. EMIS 7307 Chapter 3 • Reliability Engineering things to know: • Probability based. • Item is considered reliable if the mission of the device is accomplished. • Implies a component may fail it’s mission while the system may not fail it’s mission and vice versa • R, MTBF and  are important parameters. • R= e-t where t = operating time and = average failure rate. • e-t represents the probability of zero failures in t.

  21. EMIS 7307 Chapter 3 • Reliability Engineering things to know: • Look at the typical failure curves in Fig 3.8. • What’s the difference between a software failure and a hardware failure? • Note the effects of redundancy on reliability in Fig 3.11. • In Fig 3.14 items 1-5 are for SE’s, and 17-20 for testers (also SE’s).

  22. EMIS 7307 Chapter 3 • Reliability Engineering things to know: • Importance of FRACAS! • Suggest an automated problem identification and notification system! • Anyone who suspects a problem documents it and then it gets dispositioned (i.e. reviewed and actions assigned to correct as required). • Let’s look at the reliability qualification testing paragraph page 142, para7 • Notice the synergism that can/should occur • Results in time and $ savings

  23. EMIS 7307 Chapter 3 • Maintainability Engineering things to know: • Maintainability is the ability of an item to be maintained. • Maintenance is the action to restore or retain a specified operating condition. • See the time relationships in Fig 3.17. • A log-normal distribution is typical of maintenance times. See Fig 3.18.

  24. EMIS 7307 Chapter 3 • Maintainability Engineering things to know: • See Fig 3.19. How many were false alarms? • Availability is the factor of interest to your customer. • A = MTBM/(MTBM + MDT) • If one has or anticipates low A what’s the fix? • Lots of units, Lots of spares, Lots of maintenance personnel, Lots of $$$$! • Maintainability demonstrations are valuable but extremely expensive (See page 156) • Look for alternative ways to get the data.

  25. EMIS 7307 Chapter 3 • Human factors engineering things to know: • Human as a part of the system! • Called ergonomics, considers: • Size (page 159). • Senses. • Physiological factors. • Psychological factors. • Interface called MMI. • This interface requires as much or more definition as machine to machine. This can be a big time consumer.

  26. EMIS 7307 Chapter 3 • Human factors engineering things to know: • Mockups and simulators likely required during design. • Human subjects typical of end user (I.Q., training, etc.) needed as test subjects during design. • See Fig 3.26 for tasks especially #15- testing.

  27. EMIS 7307 Chapter 3 • Safety engineering things to know: • This is not about conducting a test safely. • This is about designing a system to minimize human and hardware/software exposure to unsafe conditions. • When a hazard can’t be eliminated then safety engineering determines a safe (acceptable risk) way to deal with it.

  28. EMIS 7307 Chapter 3 • Safety engineering things to know: • Notice how many of the “ilities” come together synergistically (integrated by the SEMP) to support safety. • Paragraph 1 section 3.4.5 page 167.

  29. EMIS 7307 Chapter 3 • Security engineering things to know: • Prevents planned introduction of faults/failures. • Similar to preventing inadvertent faults by careless operators… except for intent. • Includes encryption techniques and devices. • Virus detectors and physical access barriers are examples.

  30. EMIS 7307 critical materials critical processes proprietary items special production tooling unrealistic tolerances special test systems highly skilled personnel production/procurement lead times Chapter 3 • Producibility engineering things to know: • Objective is to convert the results of R&D efforts into something that can be produced outside the lab. • Minimize the following:

  31. EMIS 7307 Chapter 3 • Logistics engineering things to know: • Figure 3.32 is a good summary of the elements of logistics. • Figure 3.33 shows when engineering can influence the design to reduce risk and costs. • Logistics is an area with tremendous lifetime costs ! • OT&E is the typical place for evaluation of the logistics “stream”.

  32. EMIS 7307 Chapter 3 • Quality engineering things to know: • QC and QA are after the fact i.e. checking the final product. • TQM and QFD are from the beginning. • Emphasis on the following: • Customer satisfaction – no satisfaction – no quality. • Continuous improvement. • Variability minimization (6 sigma). • Everyone (not just an inspector) involved.

  33. EMIS 7307 Chapter 3 • Environmental engineering things to know: • Ecological, political and social factors. • Affects test choices e.g.: • Bombing range in Puerto Rico. • Sonar test impact on whales. • Use and retirement issues. • Lithium batteries in airplanes. • Nuclear “leftovers” like old submarine reactors -where do you dispose of them?

  34. EMIS 7307 Chapter 3 • Value/Cost engineering things to know: • See top of page 188 for examples of “figures of merit”. • From a functional flow diagram, estimate the costs of the various functions from beginning to end. • Lots of models exist. • Appendix B provides details and examples. • LCC analysis may justify expensive testing.

More Related