1 / 22

Chapter 2

Chapter 2. How important is determining (or creating) the need first? Defining the problem is the hardest part. Consider the alternative. What happens? Answers the question, What function(s) must this system perform? Answers the most basic test planning questions too!

ofira
Télécharger la présentation

Chapter 2

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 Chapter 2 • How important is determining (or creating) the need first? • Defining the problem is the hardest part. • Consider the alternative. What happens? • Answers the question, What function(s) must this system perform? • Answers the most basic test planning questions too! • Fig 2.1 “waterfall”, are there elements of this that must be sequential versus concurrent?

  2. EMIS 7307 Chapter 2 • Feasibility analysis. • Determines the technology to be used. • Determines need for applied research. • Big decisions are made here! • Lead by Systems Engineers but details executed by specialists.

  3. EMIS 7307 Chapter 2 • Operational requirements. • Figure them out and declare your first baseline! • What, when, where, about the system. • Operational deployment. • Mission scenario. • Critical performance parameters. • Utilization requirements. • Effectiveness requirements (often the only bastion of SE in a company, but still ignored). • Lifetime. • Environment- don’t forget shipping and storage!

  4. EMIS 7307 Chapter 2 • What’s the effect of the chosen maintenance approach on integration? • What’s the effect of the chosen maintenance approach on test? • Glance at Figures 2.5 and 2.6

  5. EMIS 7307 Chapter 2 • How does one determine appropriate technical performance measures (TPM)? • Fundamental to many other important issues. • Must be verifiable.- • Not: “should do’s” but “must do’s”. • It’s known how well. (What if you don’t know?) • Traceability is essential for both integration and testing. Not limited to TPMs. • See examples Figure 2.10.

  6. EMIS 7307 Chapter 2 • If you have never seen a so called house of quality (HOQ) see Figures 2.8 and 2.9. • Regardless the technique, here’s what’s important. • Customer requirements are determined and prioritized. Why important? • Alternative approaches are determined and traded-off. Why important? • Requirement flowdown to more detailed levels is formal i.e. not ad hoc. Why important?

  7. EMIS 7307 Chapter 2 • Fig 2.10 is a good start but what is missing? • Functional analysis: • “Putting meat on the TPMs” • What has to be done and how well should it be done. • Not how to do it! • Think through each use or action the system will perform. • Usually subsystems are built around major functions. • This is only an initial look at interfaces, but it is essential to successful integration.

  8. EMIS 7307 Chapter 2 • What’s a functional flow diagram(FFD)? • The interconnects are clues for possible: • Places to establish formal interfaces. • Logical division of labor between groups/companies. • Applications of FFDs. • Start input/output definitions. • Must be well understood to help decide on preferred approach. • Start resource identification. • Let’s walk-thru Figures 2.15 and 2.16.

  9. EMIS 7307 Chapter 2 • Using FFD consider COTS - Pros? Cons? • Part of make/buy decision includes off the shelf vs new build (Fig 2.18). • Use of open architecture - Pros? Cons? • Using FFDs can facilitate later design evolution even after deployment. • Well defined FFDs can alleviate or lessen the trial by error aspects of eventual integration (Fig 2.19 a mini integration plan). • Poorly defined functional interfaces lead to need for rework and redesign.

  10. EMIS 7307 Chapter 2 • See page 77 for examples of FFD uses. • Note the flow in Figure 2.20. • Produces a common though very preliminary baseline. • Without this the design engineers make their own assumptions and do what they do best.… but without a common vision it won’t integrate!

  11. EMIS 7307 Chapter 2 • Partitioning (allocation) is next. (i.e. where do you place the functions in a possible design). • Define subsystems, assemblies, subassemblies. • How does one decide where to place a function? • Define software development packages. (CSCIs) Which functions are HW? SW? • Individual packages should be as independent as possible: • Minimize interface complexity at the expense of internal complexity. • Pros?/Cons?

  12. EMIS 7307

  13. EMIS 7307 Chapter 2 • Any problem with Fig 2.21? • Too high a level breakout of HW vs SW? • Allocation of the requirements to the “level required to provide a meaningful input to design”. • Where is this level? Theoretically and practically? • How does A vs. B vs.C level specification enter this issue? • Where does SE end and design engineering begin?

  14. EMIS 7307 Chapter 2 • How formal and structured should requirement flow down be? Ever heard of SREM or DOORS? • Do customer stated requirements ever make it to the design, i.e. “C” spec? When? • What’s the difference in specificity in new design vs. COTS?

  15. EMIS 7307 Chapter 2 • System synthesis, analysis and design optimization: • Synthesis is design. (So does this mean that SE’s are not involved?) • Synthesis produces trial combinations of functions hypothetically placed into various components. • Figure 2.25 is the typical order of importance. Note that design is at the 4th level!

  16. EMIS 7307 Chapter 2 • Alternatives are subject to analysis/ evaluation to determine meeting TPMs. See Fig 2.26. • Analysis includes modeling e.g. Fig 2.27. • The modeling of the interrelationships is essential to successful integration!

  17. EMIS 7307 Chapter 2 • Design Integration • See Figure 2.29. • Best accomplished by having a team that represents each of the perspecti (an IPT!). • Requirements. • Design skills (EE, ME, CS etc). • Specialty engineering. • Testers.

  18. EMIS 7307 Chapter 2 • Design integration is facilitated by: • Co-location or VTC. • Shared databases both management info and design info accessed via internet-like structure. • Strong SE management. • Totally open communication. • Strong CM.

  19. EMIS 7307 Chapter 2 • T&E is accomplished at all levels of integration not just at the end. • Purpose is to give the decision maker facts upon which to make decisions (risk reduction). • Decision maker can be a lowly design engineer all the way to the President.

  20. EMIS 7307 Chapter 2 • Figure 2.32 is very useful but not the only way various verifications are delineated. • Type 2 and 3 are often for the customers i.e. leading to sell-off. • The DAU handbook will provide much more information later in the course.

  21. EMIS 7307 Chapter 2 • The cost associated with verification is high. • However compared to the cost of not testing it’s trivial. See handout with estimates of the impact of insufficient software testing. • The value of the test and the limiting of it’s cost is best accomplished by good planning. • The TEMP and ITTs will be discussed much more, later in the semester.

  22. EMIS 7307 Chapter 2 • Figure 2.33 is a good overall depiction of the test/modification interrelationships. • What’s the SE role in production, operations and retirement?

More Related