EMIS 7307 Chapter 2 How important is

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

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. 2

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 3 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 4

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. 5

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

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 7 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. 8

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. 9

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! 10

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

EMIS 7307 12

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

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

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 4 th level! 15

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! 16

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. 17

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. 18

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. 19

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. 20

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. 21

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