1 / 37

T-50 Program Management 경험과 시스템 엔지니어링

T-50 Program Management 경험과 시스템 엔지니어링. 생각을 바꿔야 길이 보입니다 . New Think, New Process, New Tools - A Evolution of System Engineering. 목 차. 1. 시스템 엔지니어링과 사업관리 2. 시스템 엔지니어링과 T/A-50 개발 3. 시스템 엔지니어링과 요구도 관리 4. 결 언 . T-50 개발 동영상. 시스템 엔지니어링과 사업관리. 성공적인 대규모 사업과 S.E 발전. 사업의 성공과 실패

pello
Download Presentation

T-50 Program Management 경험과 시스템 엔지니어링

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. T-50 Program Management 경험과 시스템 엔지니어링 생각을 바꿔야 길이 보입니다. New Think, New Process, New Tools - A Evolution of System Engineering

  2. 목 차 1. 시스템 엔지니어링과 사업관리 2. 시스템 엔지니어링과 T/A-50 개발 3. 시스템 엔지니어링과 요구도 관리 4. 결 언

  3. T-50 개발 동영상

  4. 시스템 엔지니어링과 사업관리

  5. 성공적인 대규모 사업과 S.E 발전 사업의 성공과 실패 체계적 개발관리와 고객의 참여 수준에 따라 결정 삼성 버즈 두바이 비용, 공정, 공기 단축과의 싸움 프로세스, 툴, 요구도, 사례 등으로 구체화 현대 조선

  6. 대규모 획득사업관리와 S.E 대규모 획득사업과 시스템 엔지니어링의 중요성 • 대부분의 사업이 50%에서 100%이상 예산을 초과하고 있으며 일정이 지연되고 있는데, 그러한 사업일수록 팀원 전원이 매주 60시간에서 80시간을 일하고 있는 것은 아이러니.” * Ed Youdan, Surviving a Death March Project • 사업성공/실패를 좌우하는 것은 시스템적 사업관리와 요구도 관리의 문제 • 기술력은 매우 작은 부분 프로젝트 실패요인 불완전한 요구도(Requirements):13.1% 고객참여 부족(User involve): 12.4% 자원 부족(Resources): 10.6% 비현실적 기대(Expectations): 9.9% 경영자관심 부족(Executive): 9.3% 잦은 요구도 및 규격변경: 8.7% 계획 미흡(Planning): 8.1% 프로젝트 성공요인 고객적극참여(User involve): 15.9% 경영자 지원(Management): 13.9% 명료한 요구도(Requirements): 13.0% 적절한 계획(Planning): 9.6% 현실적 기대(Expectations): 8.2% 적은 통제점(Milestones): 7.7% 유능한 참모(Staff): 7.2% * Standish Group(95&96) 및 Scientific American(94) 연구

  7. 사업부서 의사결정 시기와 비용에 미치는 영향 500-1000X 20-100X 3-6X INCOSE System Engineering Handbook V.3 • 사업관리 핵심은 의사결정 ⇒ 시스템엔지니어링 필요성 • T-50 설계초기 대규모 설계변경/개발도구 변경과 영향 - 설계변경 : 기골, 기수, 도체, 주익, 미익, - 개발구도 변경 : ADD, 대한항공

  8. Traditional Design 5 25% 50% 20% Risk SYSTEM DESIGN DETAIL DESIGN PRODUCTION INTEGRATION TEST 15% 20% 30% 10 급격한 Risk 감소 Time Saved Time/ Cost Risk “System Thinking” Design Time 통합사업관리와 통합시험평가 효과 Systems Engineering : IPPD 통합사업관리 그리고 통합시험 설계초기 10% ↑, 설계/제작 시험 35% ↓ 사업관리 / 의사결정 통합관리 핵심대상

  9. 시스템 엔지니어링과 T/A-50 Program Management

  10. ▣ 개발 성공 가능성 의문 : 대부분 가능성 없는 사업으로 인식 외국의 항공기 개발사례 : 일정지연, 비용상승은 상식 삼성항공과 록히드 마틴 ▣ IMF 사태와 개발 위기 1$ : 1800원(780원) 6개월 지연 착수 -> 종료 시기 고정 ▣ T-50인가, A-50인가 ? A-50 소요 미인정, 요구도 미제시 ▣ 업체 개발기술 위주도입(TA 100명 포함) 군의 사업관리 기술과 방법 및 도구(TOOLS) 미도입 : 맨주먹 붉은피 T-50 개발 착수 환경 정말될까?

  11. 살아남기 위한 노력과 S.E 도입 ▣ 남들이 다 안 된다고 할 때: 위임에 위임에 위임 그리고 분산 • 책임분산 : 누구도 책임질 수 없다 ⇒ 아무도 결심하지 않는다 아무도 고민하지 않는다. • 대규모 국책사업 : 단군이래 최대규모(?) 연구개발 • 책임/권한 분산 : 개발관리, 기술관리, 비용관리 삼성항공, 대우, 대한항공 그리고 록히드 마틴 ▣ 살아남기 위한 노력 : 모두 통합하고 내가 결심한다. • 주어진 돈과 기간 내 개발 • 내가 책임진다 ⇒ 내가 관리하고 내가 결심한다. • System Engineering 도입 교육 강화 • - 록히드마틴, 보잉, NTPS, 미공군 : 연수교육, 방문, 관련참고 자료 확보 등

  12. Lesson Learn, Best Practice & Case Study ▣ 사업관리/개발관리 교훈 : F-18, IDF, F-22, JSF 사례 • 누가 아는가? 무엇을 아는가? • 남이 한 것을 교훈으로 하면 실수가 없다. ▣ 설계와 시험 자료 활용 • JAS-39(Horse PWR) • F-18, F-16, T-37(Strake) • F-5, F-4, F-16, IDF(계통) • F-5, F-16, F-18, F-22(비행시험) ▣ Best Practice : AFMC, AFFTC ▣ AFFTC, AFOTEC의 규정, 절차와 Check List 유사항공기 결함 분석 : 한국공군 F-16, 10년간 통계 MIL-HDBK, Guide Book, MIL-Spec’, TEMP사례 등 최대 활용

  13. 요구도 구체화와 Trade-off 의 필요성 ▣ 개발자가 제대로 설계하려면 사용자가 개발 기초자료 작성제시 해야 함. ▣ 요구 성능의 설계화를 위한 요구도 구체화 • ROC ⇒ ORD ⇒ SRD ⇒ Spec’ 초안 단계로 진행 • SORD : System Operational Requirement Document • ASRD : Aircraft System Requirement Document • ASRS : Avionics System Requirement Specification Requirement 관리 도구(Tool) 개발 적용 ⇒ Spec’까지 추적성 보유, TRM 기능 보유 ▣ Trade-off : LRU 선정, 설계/제작 진행 과정의 필수적 요소 • Hard Copy 설계 ⇒ Digital 설계(CATIA), 실물 Mock up 생략 • 주요체계 변경 APU : Air Bottle ⇒ Thermal Battery, LG : 미국, 프랑스 E·J Seat : 미국, 영국

  14. 동시개발과 동시공학, 통합관리와 통합시험, 인간공학 ▣ 동시개발 관리와 동시공학의 필요성 • 항공기체계, 훈련체계, ILS체계 동시개발 • 체계 동시개발, 국내외 동시개발(600여개 회사) ▣ 통합사업 관리와 통합시험단의 필요성 인식 • 사업관리요소 통합 관리 : 비용, 일정, 성능 • 시험자산, 능력, 비용/일정, 인력 등 통합관리 • 정부기관 통합관리 : 항사단 중심 중관단, 국과연, 품관소 • 업체 관리 통합 : 삼성항공 중심 통합 • 통합시험단(CTF) : 시험평가 부서+업체+정부 시험 자원과 능력 의 통합 ▣ 인간공학의 필요성(항공기 특성) • CRT, PVI Test • Man in the Loop : 계통설계/시험(ILS)

  15. 체계안전과 검증 MIL-STD-882 System Safety 검증 설계에 반영 허용한계를 인정해야… 100%는 없음 체계 안전은 반드시 설계에 반영하고 검증해야 함(H/W, S/W System Safety Handbook)

  16. 체계안전과 검증

  17. 현장 관리 업무분산 3개 체계 동시 관리 기술관리, 품질관리, 비용관리 주 개발업무의 분산 3개 회사 분산 개발 개발진행의 조종통제 3개 체계 동시 진행 통합적 사업조직 관리 ▣ 관리하는 IPT와 시행하는 IPT : 둘 다 반드시 필요 ▣ 개발진행에 적합한 현장 개발 및 관리조직 개편 필요 • 5회 현장조직 개편, 적은 인원 다수업무관리 ▣ 시험계획, 검토 시행능력의 제한 : WIPT 필요성 • TPWG, TRB/SRB, FMRT, CTF 관리능력 제고, 갈등 해소

  18. 통합 프로세스와 계획방법 The Integrated Test Process -Planning Method 미 해군 통합시험 계획 사례

  19. 통합시험단 운영과 개념 COMBINED TEST FORCECONCEPT(F-16, T-50 적용사례) • Independent Requirements Definition(상호 독립적 요구도(세부항목 포함) 정의) • Integrated Test Planning(업체/정부 개발시험 또는 개발/운용 시험간 통합 계획) • Common Facilities(시험시설의 공유) • Joint Use Aircraft(업체/정부/군간 항공기 통합 사용) • Combined Aircrews/Maintenance(항공기 승무원/정비요원 통합관리) • Combined Missions(업체개발/정부개발 또는 개발/운용시험의 통합 임무수행) • Common Data Base(통합 자료 관리) • Independent Analysis/ Evaluation(분석/평가는 개발/운용시험간 독립적 수행) • Combined Reporting(결과보고서 통합) Plan Together, Test Once, Share the Data 원칙

  20. 통합시험 세부계획수립 방법 AFMC, Seamless Verification Guide

  21. 시험평가 검증 및 통합 대상 범위 운용시험 개발시험 설계목표(Design Goal) 작전운용요구성능(ROC) 검증 결과 규격서 통상 1.2 ~ 1.5 배 영역 운용 적합성, 효용성 평가 소요군의ROC 항목 운용자 요구서(ORD) 체계요구서(SRD) 운용자 요구서(ORD) 체계요구서(SRD) 통합시험 가능범위 통합계획 대상범위(일정,비용,성능,기술,인프라 포함) 통합 계획대상 : 일정, 비용,성능,기술, 능력 인력, 인프라 등 전 분야 •통합시험 : DT + OT

  22. 운용시험(OT) 통합시험 개발시험(DT) 통합시험 개발시험(DT) 운용시험(OT) 통합 시험 개념의 발전 시험착수 기술시험(DT) 운용시험(OT) 일정 비용 Combined Test 운용성 확인 일정 비용 일정 비용 Integrated Test 조기 운용성 확인 운용성 확인

  23. Cost PV AC CV SV Time EV 사업진행과 성과 관리를 위한 SE적용 ▣ 대규모 사업시 사업관리 프로세스, 도구(TOOLS)적용기준 (상용MiL-Std/HDBK)등의 필요성 인식 • 요구도 관리, 성과 관리, 위험 관리, 시험평가 관리 등 ▣ 사업책임자/현장개발책임자 사업 종합진행, 성과측정 필요 • 다수체계 동시개발 진행 • 계약별도, 관리별도, 규정절차 부적합, 계약자료 미흡 : 여건 미성숙 • TOC, EVMS, WBS 와 CWBS • 계약자 비용자료 보고(CCDR) ▣ 사업 위험도 관리 필요성 인식 • Risk Management 를 위한 Risk 식별 • 개발진행(지상시험 포함), 비행시험 진행 • Risk 관리 도구(Tool) 개발 적용 • 측정방법과 기준, Check List, 교육 및 평가, AEOL 등

  24. 시스템 엔지니어링과 Requirement Management

  25. 요구도 개발과정(Process)과 검증과정 시험평가가 개발과정의 ½에 해당 운용자 시험 ROC 요구도 개발과 검증을 위해 운용개념/아키텍처 / 운용 시나리오가 반드시 필요 체계통합도 개발시험임 Spec’검증완료 통합 시스템 개 발 자 시 험 체계통합 시스템 레벨 설계 Spec’검증 SRR 시스템 Spec’검증 TEST 하부 시스템 레벨 SFR 검증 하부 시스템 Spec’검증 제작 TEST 구성품 레벨 PDR TRR 구성품 Spec’검증 CDR TEST 모든 요구도 완성 검증방법 선정 : 조사, 분석, 시연, 시험요건 정의 검증절차 정의 검증환경 설정 및 조건 정의

  26. 요구도의 변화 *요구도는 못 바꾼다고 ! ! ! 요구도 개발 ORD SRD (SORD) 군 ROC (KPP/COI) INCOSE System Engineering Handbook V.3

  27. 요구도 개발과 검증 상관관계 운용 시험 생산 수락 • ROC(작전운용성능, 기술적/부수적 성능) • 체계 운용 요구서/체계 요구 규격 체계연동/통합시험 O O O 군 요구도 O O O 규격서 검증완료 적용규격 체계 요구사항 ▲▲ ▲ ▲ 체계 시험 ▲ ▲ ▲ ▲ 검증된 규격서 체계규격서(안) 적용규격 하부체계 시험      하부체계 요구사항      검증된 규격서 하부규격서(안) 적용규격 항공전자 체계요구규격서 부품 요구사항 ★ ★ ★ ★ ★ ★ 부품 시험 ★ ★ ★ ★ ★ ★ 검증된 규격서 부품규격서(안) 규격수준 요구까지 발전 부품 규격부터 검증 요구도가 체계규격으로 개발/발전됨을 이해해야

  28. 최대 무게 최소 무게 순항 무게 요구도 개발단계 최대하중, 선회율 고고도 순간하중, 선회율 최대 속도 중고도 지속하중, 선회율 저고도 최소하중, 선회율 Requirement Engineering 속도 최저 속도 요구도 개발 사례/ 경험 보유여부 ? 순항 속도 SORD(운용요구서) ASRS(요구규격 수준) WBS1단계 2단계 3단계 4단계 • • • • A-50 ROC F-16 통상 지상체계 3∼5 단계, 함정 5∼7 단계, 항공기 10∼12 단계 까지 개발 요구도 개발 없이는 체계개발 착수 불가능

  29. Allocated_to_Cockpit AC_PIDS_Link_Verification_Result Spec’ PIDS 검증결과 PIDS 검증결과 Spec’ 군 요구도/규격 검증결과 추적관리(RTM System) • 요구도와 시험계획 / 결과, 결함 Data Base 연계 : 요구도 관리도구 사용 설계, 도면, Data Base 결함(DR) Data Base 군 요구도 Level2_Downed_Aircraft ROC_SORD_ASRD_Link_Verification_Result 검증 결과 군 요구도 PIDS 군 요구도 검증결과 항공기 PIDS 시험 계획/결과 Data Base 입증 불가시 해외판매 불가한 짝퉁 ??? - SRR, SDR, PDR, CDR, TRR, TR 등 개발과정상 설계, 도면, 시험 관련자료 입증토록 해야…

  30. 체계개발회사 요구도 관리 소개 (미 보잉사)

  31. * 관리도구(Tools) 사례 • RCM • TRM • RVM • RM

  32. 결 언

  33. Program Management와 시스템엔지니어링 ▣ 사업성공, 실패는 사용자가 제시하는 설계운용 요구도 관리와 사업관리자 개인의 문제임을 인식해야… * 기술력은 매우 작은 부분 – Standich Group(`95 &`96) 연구 ▣ 복합체계(SoS)+NCW(IT) 체계의 첨단화, 복잡화, 다각화로 더 많은 사업관리 영역 통합 노력을 요구 시스템 엔지니어링이 해결방안 제시 시스템 엔지니어링의 역할 • • SE은 의사소통(Communication)과 의사결정(Decision) 도구 • •체계개발과 검증과정 관리, 추적가능 방법,과정을 안내 • •통합사업관리로 비용, 일정, 성능, 기술목표 도달 가능방안 제공 • • Lesson Learn, Trade-off, CAIV, EVMS 등 다양한 도구 제공 • •사용자 관심집중과 성공적 사업관리 안내

  34. 시스템엔지니어링 필요성 증가 ▣미국 및 유럽의 경우 • 획득사업 추진 시 주요 획득일정 검토와 연계하여 시스템엔지니어링 계획수립 요구 필수 •획득의 전 단계 진행단계별로 시스템 엔지니어링 활동 요구 ▣방위사업청의 경우 •획득사업 추진 시 시스템엔지니어링 적용 권고 •연구개발 전단계에서 시스템 엔지니어링 활동을 규정화 •성공적 연구개발 관리와 무기체계 수출에 대비한 국제적 의사소통의 도구인 시스템 엔지니어링 도입 확대 시스템엔지니어링 적용 요구가 확대되고 시스템 엔지니어의 소요가 대폭 증가

  35. 복합체계의 새로운 도전 System Engineering & TEST( JSF 개발사례 ) SETE 2005 National Conference – November 9. 2005

  36. 미래 복합시스템, 엔터프라이즈 시스템(SoS+NCW) 등은 시스템 엔지니어링의 과학적 방법, 프로세스, 툴에 의거한 시스템 엔지니어링적 사고와 관리가 필수적 System Engineering 소요 증가 감사합니다.

More Related