Unit 1 Slides - University of Rhode Island Slides.pdf · Project 1.A temporary endeavor undertaken to cre ate a unique product or service. (PMI 2008) 2. A project is a formal enterprise

1

System1. A group of interacting, interrelated, or interdependent elements forming a complex

whole.2. A functionally related group of elements.3. An organized set of interrelated ideas or principles.4. A social, economic, or political organizational form.5. A naturally occurring group of objects or phenomena: the solar system.6. Any process that converts inputs to outputs7. A system is normally composed of hardware, software, and human elements, all of

which interoperate efficiently for the overall system to be effective. Project

1.A temporary endeavor undertaken to create a unique product or service. (PMI 2008)2. A project is a formal enterprise that addresses the matter of designing and

developing the various systems.3. A project is typically defined as a collaborative enterprise, frequently involving

research or design, that is carefully planned to achieve a particular aim.4. A planned set of interrelated tasks to be executed over a fixed period and within

certain cost and other limitations.

2

◦ Job View - Systems Engineering is what a person with the titled position of 'Systems Engineer‘ does and has as his/her job description, responsibility and/or role.

◦ Organizational View - Systems Engineering is what an organization unit named “Systems Engineering” does and has as its responsibility and/or role.

◦ Problem-Solving View - Systems Engineering is a way of thinking about any complex technical problem.

◦ Multidisciplinary View* - Systems Engineering is a multidisciplinary approach that defines the total technical effort needed to realize system products and sustain their life cycle services.

3

International Council on Systems Engineering (INCOSE) :

Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

Operations, Cost & Schedule, Performance, Training & Support, Test, Disposal, Manufacturing

Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

http://www.incose.org/practice/whatissystemseng.aspx

4

DSMC: Systems Engineering is an interdisciplinary engineering management process to evolve and verifyan integrated, life cycle-balanced set of system solutions that satisfy customer needs.

Eisner: Systems Engineering is an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near-optimal manner, the full range of requirements for the system.

5

Wikipedia - Systems engineering is an interdisciplinary field of engineering focusing on how complex engineering projects should be designed and managedover their life cycles. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more difficult when dealing with large, complex projects. Systems engineering deals with work-processes and tools to manage risks on such projects, and it overlaps with both technical and human-centered disciplines such as control engineering, industrial engineering, organizational studies, and project management.

6

DOD: Systems engineering involves design and managementof a total system which includes hardware and software, as well as other system life-cycle elements. The systems engineering process is a structured, disciplined, and documented technical effort through which systems products and processes are simultaneously denned, developed, and integrated. Systems engineering is most effective implemented as part of an overall integrated product and process development effort using multidisciplinary teamwork.

7

NASA: A robust approach to the design, creation, and operation of systems by emphasizing:

◦ Identification and quantification of goals◦ Creation of alternatives◦ Design of trade studies◦ Selection of the best design◦ Verification that it is built correctly◦ Post-assessment of the design against the goals.

8

SIMILAR1. State the problem. Stating the problem is the most important systems

engineering task. It entails identifying customers, understanding customer needs, establishing the need for change, discovering requirements and defining system functions.

2. Investigate alternatives. Alternatives are investigated and evaluated based on performance, cost and risk.

3. Model the system. Running models clarifies requirements, reveals bottlenecks and fragmented activities, reduces cost and exposes duplication of efforts.

4. Integrate. Integration means designing interfaces and bringing system elements together so they work as a whole. This requires extensive communication and coordination.

5. Launch the system. Launching the system means running the system and producing outputs -- making the system do what it was intended to do.

6. Assess performance. Performance is assessed using evaluation criteria, technical performance measures and measures -- measurement is the key. If you cannot measure it, you cannot control it. If you cannot control it, you cannot improve it.

7. Re-evaluation. Re-evaluation should be a continual and iterative process with many parallel loops.

9

http://www.sie.arizona.edu/sysengr/whatis/whatis.html

1. State the problem. The problem statement starts with a description of the top-level function that the system must perform or the deficiency that must be ameliorated.

◦ Understand customer needs - Customers seldom know what they want or need. Systems Engineers must enter the customer's environment and find out how the customer will use the system. We must exceed, not merely meet, customer expectations.

◦ Discover system requirements - There are two types of system requirements: mandatory and tradeoff.

◦ Verify and validate requirements - Each requirement should be verified by logical argument, inspection, modeling, simulation, analysis, test or demonstration.

10


2. Investigate alternatives. Alternative designs are evaluated based on performance, cost, schedule and risk criteria.

◦ Define quantitative measures - Evaluation criteria, technical performance measures and measures are all used to quantify system performance.

Performance and cost criteria show how well the system satisfies its requirements.

Technical performance measures (TPM's) are used to track the progress of design and manufacturing..

Measures are often related to the process, not the product. Therefore, they do not always relate to specific system requirements.

11


3. Model the system. Models will be developed for most alternative designs. The model for the preferred alternative will be expanded and used to help manage the system throughout its entire life cycle.

◦ Design the system◦ Create sequence diagrams◦ Define system architecture◦ Functional analysis◦ Sensitivity analyses◦ Assess and manage risk◦ Reliability analysis

12


4. Integrate system components. Integration means bringing things together so they work as a whole. System integration means bringing subsystems together to produce the desired result and ensure that the subsystems will interact to satisfy the customer's needs.

◦ Design and manage interfaces - Interfaces between subsystems and interfaces between the main system and the external world must be designed. Subsystems should be defined along natural boundaries

13


5. Launch the system. Launching the system means doing what the system was intended to do, e.g. running the system and producing outputs.

◦ Configuration management - Configuration management ensures that any changes in requirements, design or implementation are controlled, carefully identified, and accurately recorded.

◦ Project management - Project management is the planning, organizing, directing, and controlling of company resources to meet specific goals and objectives within time, within cost and at the desired performance.

◦ Documentation - All of these Systems Engineering activities must be documented in a common repository, often called the Engineering Notebook.

◦ Lead teams - Complex systems cannot be designed by one person. Consequently engineers work on Integrated Product Development Teams (IPDTs). These teams are interdisciplinary with members from Business, Engineering, Manufacturing, Testing, etc.

14


6. Assess performance. During the operation and maintenance phase of the system life cycle the performance of the system must be measured.

◦ Prescribe tests- Early in the system life cycle Systems Engineering should describe the tests that will be used to prove compliance of the final system with its requirements.

◦ Conduct reviews - Systems Engineering should ensure that the appropriate reviews are conducted and documented.

◦ Total system test - The system that is finally built must be tested to see (1) that it satisfies the mandatory requirements, and (2) how well it satisfies the tradeoff requirements.

15


7. Re-evaluation. Re-evaluation means observing outputs and using this information to modify the system inputs, the product or the process. Re-evaluation should be a continual process with many parallel loops. Everyone should continually re-evaluate the system looking for ways to improve quality. Tools used in this process include basic systems engineering, and the quality engineering techniques presented by, for example, Deming and Taguchi.

16


Type I error – Prob (rejecting a hypothesis | the hypothesis is true)

Type II error – Prob (fail to reject a hypothesis | the hypothesis is false)

Error Model - usually an error model is constructed that:a. Identifies all primary error sources, as well as their likely magnitudes.b. Establishes mathematical relationships between these error sources.

Three Error Scenarios -a. An overall system error probability of about 32 percent (plus and minus

one-sigma designation)b. An overall system error probability of about 5 percent (plus and minus

two-sigma designation)c. An overall system error probability of about 0.27 percent (plus and minus

three-sigma designation)

17

Essentials of Project and Systems Engineering Management, 3rd Edition, Eisner, Wiley 2008

Problems occur in system engineering impacting cost, schedule and performance.

Reasons for problems:◦ Inadequate articulation of requirements Usually poor articulation or too early in project to define

◦ Poor Planning Relying on the best performers when plan is laid out. Continual update

◦ Inadequate technical skills and continuity Reliance or difficulty in getting personnel needed (demand by

other projects)◦ Lack of Teamwork* I believe this is the ‘root of all evil’

18


Reasons for problems (cont’d):◦ Poor communication and coordination◦ Insufficient Monitoring of Progress◦ Inferior Corporate support◦ Use and reliance on immature technologies◦ Inadequate technical assessments◦ Unstable product designs◦ Early entry into production◦ Undisciplined software development◦ Lack of disciplined systems engineering

19


As identified by 2003 NDIA task group, the top five systems engineering issues were deemed to be the following (please note that these are not listed in any priority):

Lack of awareness of the importance, value, timing, accountability, and organizational structure of SE on programs

Adequate, qualified resources are generally not available within Government and industry for allocation on major programs

Insufficient SE tools and environments to effectively execute SE on programs

Requirements definition, development and management is not applied consistently and effectively

Poor initial program formulation

20

http://www.aticourses.com/sampler/TopFiveSystemsEngineeringIssues_In_DefenseIndustry.pdf

Lack of awareness of the importance, value, timing, accountability, and organizational structure of SE on programs

Recommendation

Increase awareness of SE importance within acquisition formulation and decision processes early and consistently over major milestones, and recognize SE authority and responsibility in the ACAT IC/D* process present during the acquisition formulation and decision processes, with similar efforts at lower program levels.

Emphasize the following points:· SE is NOT an option. It is an essential ingredient on all programs and must

have adequate funding.· PMs are accountable and responsible for SE implementation across entire life

cycle

*ACAT I programs are Major Defense Acquisition Programs (MDAPs). The "D" refers to the Defense Acquisition Board (DAB), which advises the USD(AT&L) at major decision points. ACAT IC for which the MDA is the DoD Component Head or, if delegated, the DoD Component Acquisition Executive (CAE). The "C" refers to Component

21


Adequate, qualified resources are generally not available within Government and industry for allocation on major programs

Recommendation

Establish a program and process for incentivizing career systems engineerpositions within the Government.

The following points should also be addressed:· Require the SEMP to identify the process and qualification requirements for all key

personnel proposed for the contract· Work with major universities to require an introductory course in systems engineering in

all undergraduate and graduate level engineering and technical management degree programs.

· Require that program managers receive systems engineering training so they understand the significance that SE plays in assuring program success

· Ensure that DAU SE level 2 and 3 courses address, as a minimum, training on the SE tools processes and documents as defined in SAF AQ memo dated January 06, 2003, "Incentivizing Contractors for Better Systems Engineering“.

22


Insufficient SE tools and environments to effectively execute SE on programs

RecommendationResearch and identify SE tools for system architecture design and development, and encourage use thereof.

The following points should also be addressed:· There is need for development of a system architecture framework

for particular system in accordance with FEW [federal enterprise architecture / CBA-component based architecture, the DoD-directed Zachman framework, and C4ISR three-schema architecture]

· Efforts should identify all of the program-applicable domains (government, primes and major subcontractors) and environments required for a structured hierarchical decomposition of a weapon or IT system

23


Requirements definition, development and management is not applied consistently and effectively

Recommendation

Synchronize directives used by the acquisition and requirementscommunity to ensure a disciplined and consistent requirements definition and development approach.

The following points provide additional information on this recommendation:· The education process, both formal and informal, for Government Program Managers and

contractors should be sufficient that they mutually understand the necessity of a comprehensive architectural approach and systems engineering focus in applying the complete and managed requirements process on programs

· OSD (open source definition) should link requirements definition, development and management into the program life cycle through defined practice and guidance

· Emphasize process maturity related to requirements for both acquisition and development communities by adoption of maturity models such as CMMIÒ (Capability Maturity Model Integration)

· Involve potential contractors in the requirements definition process early in the acquisition cycle

24


Poor initial program formulationRecommendationEmphasize the use of architecture development and systems engineering practice in the initial program formulation phase including the use of realistic estimates for cost and schedule, risk identification, and clearly defining requirements. Even if the program does not include all life cycle phases, consideration of supportability needs to be included from the outset.The following points should also be addressed:· Modify the current acquisition approach to encourage more candid communication of program cost,

schedule and risk between Government and Industry· Encourage that initial engineering go beyond the superficial, either through pre-acquisition activities

and funded studies and analysis so that initial program formulation accurately predicts schedule, cost and risk

· Ensure that unrealistic or incompatible cost, schedule, and performance baselines are clearly identified as a risk, so that the situation can be effectively managed.

· Emphasize investigation of the implications of initial requirements statements, not only on design but also on supportability.

· Encourage early and strong government/industry SEIT (system engineering integration and test) or OIPT (Overarching Integrated Product Team) activity prior to formation and chartering of specific IPTs.

· Emphasize process maturity in contractor communities, applicable to all phases of a program, by adoption of maturity models such as CMMI (Capability Maturity Model Integration)

25


Summary Recommendation

· Increase awareness of SE importance within acquisition formulation and decision processes early and consistently over major milestones, and recognize SE authority and responsibility in the ACAT IC/D process present during the acquisition formulation and decision processes, with similar efforts at lower program levels.

· Establish a program and process for incentivizing career systems engineer positions within the Government.

· Research and identify SE tools for system architecture design and development, and encourage use thereof.

· Synchronize directives used by the acquisition and requirements community to ensure a disciplined and consistent requirements definition and development approach.

· Emphasize the use of systems engineering practice in the initial program formulation phase including the use of realistic estimates for cost and schedule, risk identification, and clearly defining requirements. Even if the program does not include all life cycle phases, consideration of supportability needs to be included from the outset.

26


They provide a baseline of the 'what's' and 'why's'. This provides a basis for assessing and improving an organization's policies and procedures.

They are used by developers to:◦ Establish and standardize internal processes (baseline)◦ Direct usage by suppliers and subcontractors◦ Assess internal and external capabilities◦ Develop system engineering technical plans◦ Promote effective communication and standard vocabulary◦ Consistent set of practices.

They are used by acquirers to:◦ Understand the developer’s system engineering activities◦ Determine and assess developers capabilities

They are used by entire countries to:◦ Provide an industry segment with a set of national practices.

27

MIL-STD-499 – (1969) Was developed by US Air Force to provide for the development of complex systems like nuclear powered ships, reactors, weapons, etc. Used primarily for government oversight or management of acquisition contract. Focused on development cycle of product.

MIL-STD-499A (1974) Follow on to MIL-STD-499 and was active until 1994. More detail in detailed design and analysis of product (Section 5).

MIL-STD-499B (1992 never released) Entry to system engineering process.

EIA-632 (1999) – Almost identical to 499B. Good mix of breath of scope and design detail. Joint document of INCOSE and EIA. Electronic Industry Alliance

IEEE 1220 (1999) – Contained detailed processes than previous standards, but small in breadth of scope (life cycle)

ISO 15288 (2002) – International standard with large breadth but much less detail. No detail of methods or processes. Updates to this standard include software system development. Now a IEEE standard.

28

29

The “systems approach,” at times difficult to define and execute, is basically a recognition that all the elements of a system must interoperate harmoniously, which, in turn, requires a systematic and repeatable process for designing, developing, and operating the system.

1. Follow a systematic and repeatable process.2. Emphasize interoperability and harmonious system

operations.3. Provide a cost-effective solution to the customer’s

problem.4. Assure the consideration of alternatives.5. Use iterations as a means of refinement and convergence.6. Satisfy all user and customer requirements.7. Create a robust system.

30


31Essentials of Project and Systems Engineering Management, 3rd Edition, Eisner, Wiley 2008

1. Requirements: Should be formal agreements and change process with customer. Usually developed by developer.

2. Project Plan: Fundamental plan of project with agreement of developer and customer. Sometimes merged with System Engineering Plan (SEP).

3. Functional Design of Alternatives: At functional level (see Ulrich), alternatives for hardware, software, and human interface are developed with cost (life-cycle), schedule, and performance (meeting requirements).

4. Analysis of Alternatives (AOA): Functional design alternatives are compared and developer and customer agree on the attributes of each.

5. Evaluation Criteria: Formal evaluation criteria of Functional Designs that should include risk is developed.

6. Preferred System Architecture: Decision on optimal system architecture based on the evaluation criteria outcomes.

7. Satisfies Requirement?: Ensure that each requirement is met or agreement to change requirements.

8. Subsystem Design: The system architecture functionally allocated hardware, software, and human elements. Sub-systems will be identified as configuration items (CI) or similar for understanding of layers of requirements. Steps 8-12 are iterated for more levels if needed.

32


9. Analysis of Alternatives: Similar to the architecture AOA, each sub-system goes through similar process of determining the proper sub-system. Make vs. buy, including COTS (commercial off-the-shelf) decisions are made here.

10. Trade-Off Studies: Study of alternatives to optimize the sub-system design based on meeting requirements.

11. Preferred Subsystem Designs: Identification of design that meets requirements. Several iterations may be necessary. Proto-typing of high-risk aspects of design is crucial.

12. Satisfies Requirements? Formal check of meeting requirements. Returning to top-level requirements may be needed.

13. Subsystems/Builds: Each subsystem goes through a formal design and development process.

14. Subsystem/Build Integration: Each level is integrated as a system or sub-system. Test plans are developed and used to ensure integration is understood. Many alternatives are possible for integration from simple bench test to integration on an eventual end-product.

33


15. System Test and Evaluation (T&E): End-to-end test of the full system. Sometimes conducted by an outside organization.

16. Cost-Effective Physical System: If previous steps are done correctly and managed well, a cost effective system is developed.

34


35

36

Everyone but… Project Management and Chief Engineer are crucial. Project Manager/Controller◦ Establish, confirm, and maintain the cost/budget/schedule◦ Continuous tracking of technical performance, risk mitigation,

and action plans for critical issues◦ Administrative based on type of organization (cover later) and

involvement of other controller type functions (reports, trends, etc)

Chief Engineer◦ Overall technical approach◦ Evaluate all alternatives and arrives at preferred architecture◦ Implement and oversee system and software engineering process◦ Technical lead and reviewer of designs

Resource owner (people and equipment/facilities)

37

The following news video is a report by “Nightline”, highlighting the process of “Engineering Design”, featuring IDEO, an International Design and Innovation Consulting Firm:

https://www.youtube.com/watch?v=M66ZU2PCIcM

39

W. Edwards Deming

Taught engineering, physics in the 1920s, finished PhD in 1928

American statistician, professor, author, lecturer, and consultant

Improved production in the U.S. during World War II and in Japan after the war

Pioneer – use of statistical analysis to achieve better industrial quality control –‘quality movement’

Sent to Japan after WWII to work on the census

Deming’s Quality Philosophy and Management Strategy

40

Deming was asked by JUSE (Japanese Union of Scientists and Engineers) to lecture on statistical quality control to management

Japanese adopted many aspects of Deming’s management philosophy

Deming stressed “continual never-ending improvement”

Deming lectured widely in North America during the 1980s;

Offered 14 points to business management from his book “Out of the Crisis” in 1986

41

41

http://www.ative.dk/media/1786/reboot%202009%20-%20out%20of%20the%20crisis.pdf

42


43

http://www.ative.dk/media/1786/reboot%202009%20-%20out%20of%20the%20crisis.pdfDr. Deming’s Interview

44


45


46


47


48


49


50


51


52


53


54


55


56


57


58


Documents

Unit 1 Slides - University of Rhode Island Slides.pdf · Project 1.A temporary endeavor undertaken to cre ate a unique product or service. (PMI 2008) 2. A project is a formal enterprise