• 지상 전체적으로 하고 있는 사업은 많이 있음
• 지상 2팀에서는 저궤도 위성의 지상국 시스템 개발을 주로 하고 있음

• IRPE (Image Receiving and Processing Element) or IRPS (Image Receiving and Processing System) 라고 함

• 팀장임

• KARI 와 일을 주로 함
• IRPE 내부의 서브시스템인 수신 담당 수신 서브 시스템과 영상 처리 담당 서브 시스템을 개발하고 있음

• 위성 시스템의 일부에 포함되는 것임
• 위성의 지상국에 대한 요구사항을 기반으로 개발됨

• End User 는 KARI 임
• 위성 운영 및 영상 서비스 등을 할 때, 사용하고 있음
• 아리랑 2호~5호까지 IRPE 가 각각 구현되어 사용하고 있음

• 제안요청서를 통해 요구사항을 전달 받음
  • MAP 과제의 제안 요청서를 띄워서 보여줬음

• 설계/기능/성능/기타 요구사항들이 분류되어 있는 것을 확인했음
  • 요구사항별로 ID 가 부여되어 있는 것을 확인

• 제안요청서 표지에 기록되어 있는 작성 일자가 2017-02 버전임을 확인

• 아직 종료되지 않았음. 현재 구현 단계임

• PDR 은 고객과 PM 의 논의 하에 수행하지 않기로 했음

• 고객의 요청에 따라 PM 이 고객과 논의해서 PDR 을 하지 않기로 했다면 괜찮다고 했음

• CDR 은 2017-09 에 수행했음

처음 만드는 제품을 뭐라고 명칭하나?

보통 시제품이라고 함. 시제 1/2/3/4~ 호기 식으로 부르다가 양산 1/2/~ 호기 식으로 부르는 것이 보통임.

• 우리는 그냥 소프트웨어라고 부름

• 납품 소프트웨어를 EM Software 라고 명명하고 진행하기로 함

• 2017-09 부터 시작했으며 2018-10 종료 예정임

• 한 소프트웨어만 구현해서 전달하면 됨

• 1 Unit 이라고 단위를 붙이면 된다고 함

• 상세사업계획서를 띄워서 마일스톤 보여줬음

• 이것이 실수였음. 제안서를 보여줄걸...

• PM 이 관리하는 문서라서 PM 에게 확인을 해야 함

• 과제의 승인된 문서/자료에 과제 참여자가 모두 접근할 수 없는 것은 문제라고 했음

감사가 요청한 문서를 보여줄 때는 승인된 문서를 보여줘야 함

과제에서 작성된 승인된 문서를 과제 참여자가 확인할 수 없으면 안됨

• 상세사업계획서의 경우, 과제 참여자들이 설계/개발을 위해 참고하는 문서가 아니기 때문에 부적합으로 분류하지는 않았음
• 문서에 대해 승인자가 없다는 것은 말이 되지 않음

• CDR 발표 자료를 띄워서 보여줬음

• 각 항목들 (개요/요구사항 정리/설계 내용) 에 대해 심사관이 훑어봤음

• CDR 회의록을 보여줬음

• ECP 은 별도로 작성하지 않음
• 회의 시에 Action Item 을 할당 받아서 수행함
• 설계 변경 AI 도 ECR 을 작성하지 않고 바로 설계서에 수정을 했음
• 수행 결과는 월별 진도 점검회의를 통해 수행 완료 여부를 고객에게 승인 받음

• 고객의 변경 요청 사항에 대해서는 기존 요구사항 대비 추가된 것인지 확인이 필요함.
• 그로 인해 비용이 더 드는지 안 드는지 확인이 필요함
• AI 가 관리되고 고객의 승인 여부가 확인되면 괜찮음
• 기 승인된 설계 변경에 영향을 끼치는 사항에 대해서는 Class 1/2/3 로 구분해서 관리해야 함
  • 하드웨어 설계서는 위의 사항을 반드시 따라야 하는데, 소프트웨어는 설계서 또한 최종 소프트웨어에 포함되는 개념이기 때문에 이해하고 넘어갔다고 함

• 내부에서 모두 수행함

• MAP 과제의 테스트 코드를 보여줬음
• 기능 요구사항 구현을 위한 구현 작업들을 JIRA 를 통해 관리함
• 각 JIRA 작업들에 해당하는 코드들이 있고 해당 코드들이 정상 동작하는지 테스트 코드를 작성하여 확인을 하고 있음

• Unit Test 라고 명명하며 Unit Test 의 절차서는 존재하지 않음

• FAT (Factory Acceptance Test) / SAT (Site Acceptance Test) 를 수행함

• 요구사항을 모두 만족함을 보여주기 위해 절차서를 작성하여 사내에서 수행하는 것이 FAT 이며 동일한 절차서 Site 에 설치하여 수행하는 것이 SAT 임

• FAT 가 먼저 수행됨

• 아직 수행하지 않았음. 2018-11 수행 예정

• 맞음

• 아직 수행 전이기 때문에 작성하지 않았음

• 작업 전이라 FAT/SAT 시험 절차서가 존재하지 않는 것에 대해서 이해했음

• 맞음. 시험 결과 보고서를 작성하고 고객의 승인을 받음.
• 그 이후에 납품이 이루어짐

• 없음

• 해당 부분에 대해서는 PM 이 알고 있을 것임

• 지상사업부의 2018년 성과 목표를 보여줬음
  • 심사관이 설계/개발에 대한 KPI 가 보이지 않는다고 했음. 또한 Index 가 구체적인지 않다고 했음
• 그래서 지상 2팀의 KPI 를 보여줬음
  • 별 말이 없었음

• 주요성과지표 계획 및 실적표_지상사업부_지상2팀_2018.doc 를 보여주고 상반기 평가 결과에 대해서 설명

• 부문장님이 관리를 할 것임. 현재 여기에서 확인이 불가함

Code Coverage / Line Coverage / Branch Coverage 는 적용하지 않는가?

• 지상에서 적용할 수 있는 지표이기는 하지만 현재 적용하고 있지 않음

• 우주 쪽에서 소프트웨어 개발 KPI 로 해당 내용들을 언급했었던 것으로 보임

• 과제 일정 관리는 PM 이 수행함

• 소프트웨어 및 각종 설계 문서

• 요구사항 분석서 / 인터페이스 설계서 / 화면 설계서 / 데이터 설계서 가 있음

• 모두 납품 문서임

• 아직 승인 전임

• 고객 요구사항에서 본 적이 없음

• 기능 요구사항은 대부분 Demo 로 진행됨
• 설계 요구사항의 경우, Inspection 으로 진행됨

• (김주나) Inspection 은 어떻게 진행되나?
  • 예를 들어 OS 를 Win 10 을 써야 된다는 요구사항이 있으면 Win 10 을 썼는지 고객이 눈으로 확인

• SAT 문서로 갈음되는 것으로 알고 있음

• (김주나) COC 발급을 하는가?
  • PM 이 알고 있는 것으로 알고 있음
• (김주나) 지상 PM 에게 COC 발급을 요청 받은 적이 없음
  • 해당 문서가 COC 인지는 모르겠으나 납품 시, 무언가 주는 것 같음. 잘은 모르겠음

• 없음

• (심사관) 하드웨어와 다르기 때문에 없을 거라는 것에 동의함

• 지상 2팀은 7명이며 사업부는 약 40여명임

• 해당 부분은 PM 들이 알고 있을 것임

• (심사관) 사업부의 일원으로서 / 팀장으로서 알고 있으면 더 좋다고 생각함

• MSTR (Maintenance Support Task Request) 에 의해 관리됨

• 고객이 작성할 수도 있고 고객의 요청에 따라 우리가 작성하기도 함

• 맞음

• (심사관) Advanced Engineering Change 와 같다고 생각함

• KARI 최신 MSTR 을 보여줬음
  • KARI-MSTR-2018-021 Margin At AOS In Sec(K3,K3A,K5)

• 현재 기록된 바에 의하면 원인 분석까지 완료된 상황임