chapter 2 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 2 PowerPoint Presentation
Download Presentation
Chapter 2

Loading in 2 Seconds...

play fullscreen
1 / 22
ofira

Chapter 2 - PowerPoint PPT Presentation

104 Views
Download Presentation
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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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?