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