데모는 무엇을 입증하는지 먼저 밝힌다
데모의 첫 문장은 과제 목적과 실행 범위다. '종이/CPU 합성 기록에서 frame/나이·결과 관문을 검증한다'와 '실제 장비에서 물체를 옮겼다'는 다른 주장이다. 화면이나 영상이 보인다는 사실만으로 모델/로봇이 실제 실행되었다고 볼 수 없다. 입력/버전·관측/명령/결과 ID와 수행한 단계, 예상/관측·미시험을 연결해 보여야 한다.
좋은 결과만 편집한 영상보다 정상 한 사례와 거부/미상·실패 한 사례를 같은 규칙으로 설명하는 것이 판단에 도움이 된다. M32.05의 T2 잘못된 frame·T3 나이 경계와 T6 최종 결과 없음 같은 입력을 고르고, 어떤 요구/원본/판정을 보여 주는지 설명할 수 있다. 이 경우는 합성 기록의 해석 데모이며 실제 로봇 작업 성공을 시연한 것이 아니다.
3분 설명을 예로 들면 목적/범위 30초, 구성/입출력·버전 45초, 정상/거부의 계산/근거 45초, 실패/미상·한계 30초, 검토/개선 30초로 총 180초다. 이 시간표는 발표 설계 예이고 분량을 맞추기 위해 중요한 실패/근거를 숨기지 않는다. 실시간 도구가 없으면 주어진 표/계산으로 설명하고 실제 장비를 작동했다고 말하지 않는다.
설계 선택에는 대안과 비용의 근거가 있다
'최신 모델이라 선택했다'보다 요구에 맞는 이유/대안·비용과 검증 범위를 적는다. 예를 들어 최신 관측 슬롯은 이 과제에서 오래된 영상의 계산을 줄이기 위한 선택이지만 중간 프레임이 필요한 추적/시간창 정책과 원본 기록·순차 delta 명령에는 같은 정책을 적용하지 않는다고 설명한다. 어떤 입력 의미/주기·나이/버전에서 판단했는지가 근거다.
관측 나이 80 ms 경계를 고른 경우에는 이번 합성 과제의 요구라는 출처와 경계/만료 사례의 결과를 보여 준다. 그 값이 실제 모든 장치에서 충분히 안전하다고 주장하지 않는다. 실제 요구를 바꾸려면 과업/장치의 추가 근거와 변경/재검증을 제시해야 한다. 수치가 불리하다고 임계값을 바꾸고 같은 평가라고 부르지 않는다.
기하·정책·큐/필터·감독의 선택도 비슷하다. 가정/예측과 실제 관측을 나누고 대안에서 무엇이 달라질지, 아직 비교하지 않은 것은 무엇인지 적는다. 비교 실험을 하지 않았다면 '더 좋다' 대신 검증할 가설로 남긴다. 독자가 같은 버전/입력에서 판정을 따라갈 수 있도록 설명한다.
루브릭과 필수 관문을 사전에 고정한다
루브릭은 평가 항목별로 어떤 근거가 어느 수준인지 정한 기준이다. 아래 교육용 점수 s는 0~4다. 0은 근거 없음/모순, 1은 설명만 있고 핵심 근거 부족, 2는 기본 사례/한계를 연결, 3은 정상/경계·원본/판정을 연결, 4는 변형/실패와 수정/재검증까지 추적한 수준으로 정한다. 항목별 실제 요구에 맞는 예를 평가 전에 합의한다.
| 항목 | 비중 w(점) | 합성 최초 점수 s |
|---|---|---|
| 요구/인터페이스의 명료성 | 20 | 3 |
| 방법/계산·설계 근거 | 25 | 4 |
| 증거/재현 가능성 | 20 | 2 |
| 실패/감독·미상 처리 | 20 | 1 |
| 설명/한계·범위의 정직성 | 15 | 4 |
비중 합은 100점이고 항목 점수는 4점 만점이므로 총점은 Σ(w×s/4)다. 이 표는 15+25+10+5+15=70점이다. 사전 통과 규칙을 '총점 70점 이상, 모든 항목 최소 2점, 해결되지 않은 차단 결함 없음'으로 정했다고 하자. 총점은 경계에 도달했지만 실패/감독 항목이 1점이므로 보완이다. 강한 발표/계산 점수로 중요한 부족을 지우지 않는다.
차단 결함은 이 과제의 완료 주장을 막는 모순/근거 누락이다. 예를 들어 합성 기록을 실물 성공으로 보고하거나, 최종 결과가 없는 T6을 완료라고 쓰는 문제가 남아 있으면 점수 합이 높아도 닫지 않는다. 이 이름은 교육용 평가 분류이며 실제 장비/안전 표준의 위험 등급이 아니다. 과제 문서의 통과와 실제 장비 운전/안전·프로젝트 합격 범위를 별도로 적는다.
동료 검토는 사람보다 산출물의 근거를 살핀다
NASA Software Engineering Handbook의 peer review 설명은 준비·결함 기록/수정·후속 확인을 다룬다. 여기서는 읽기 자료/기준·질문/결함과 수정 후 확인을 연결하는 원칙을 적용한다. 이 작은 활동을 NASA 절차 준수라고 선언하지 않는다.
검토 자료는 고정한 원고/패키지 버전과 요구·인터페이스, 입력/계산·기대/주어진 결과, 원본·실패/미상과 루브릭이다. 검토자는 전체 흐름과 표본 계산을 따라가고 전제/누락·반례를 기록한다. 작성자가 자기 검토한 사실과 다른 사람이 읽기 검토한 사실, 검토자가 독립 환경에서 코드를 재실행/장비 시험한 사실은 다르다. 실제 하지 않은 검토/실행을 독립 검증이라고 쓰지 않는다.
의견은 '잘 작동한다'보다 '요구 R4/사례 T6의 최종 결과가 없는데 리포트가 완료로 표시되어 모순이다. 미상으로 유지하고 정상 terminal/실패·누락 변형을 재확인해야 한다'처럼 위치/입력·기대/현재·영향과 필요한 확인을 적는다. 원인 코드를 보지 않았다면 '상태 전이 구현 결함 가능성'처럼 가설을 구분한다. 동의/반려·수정/미해결의 처리 이유도 기록한다.
수정은 새 근거와 재평가로 닫는다
개선 계획 I1을 R4/T6의 완료 오보고 수정, I2를 원본/버전·계산 연결 보강으로 잡아 보자. 각 항목에 담당 역할/기한·변경 대상, 필요한 입력/예상 결과, 재검증/완료 조건과 의존성을 둔다. I1은 T6 미상 유지와 정상/실패/취소·중복/누락 변형을, I2는 요약 숫자를 원본 ID/식/환경으로 따라가 재계산할 수 있는지를 확인한다. 실제로 하지 않은 확인은 계획/미완료로 표시한다.
새 파일이 저장되었다고 결함이 닫히는 것은 아니다. 고정 버전/차이·실행 환경과 재검증 결과/원본을 남기고 기존 통과 사례에도 새로운 모순이 없는지 확인한다. 요구/임계값이 바뀌었으면 영향받는 사례/평가 범위도 갱신한다. 이전 실패 기록을 지우거나 새 검토에 옛 버전의 승인 표시를 그대로 붙이지 않는다.
가상 재평가에서 증거 항목이 2→3, 실패/감독이 1→3으로 개선되었다고 주면 점수는 15+25+15+15+15=85다. 모든 항목이 2 이상이지만 아직 차단 결함이 남았는지도 별도로 확인한다. '수정 후 85점'이라는 숫자는 이 가상 평가의 입력이며 실제 동료 검토나 실물 실증이 수행되었다는 뜻이 아니다. 완료 선언은 해당 버전/범위·근거와 남은 미시험을 포함한다.
기존 6.8 포트폴리오 패키징과 6.6 평가 설계를 연결해 발표·리포트·검토/개선을 한 근거 흐름으로 묶자. 장비 없는 캡스톤의 교재/설계 활동을 마쳤더라도 실제 프로젝트 심사/장비 결과의 범위는 별도다. 다음 단계는 미해결 가설/필요 자료와 검증 조건을 구체적으로 남기는 것으로 마무리한다.
선택 과제·공통 산출물/기본 평가 안내 열기: 세 과제 중 하나를 선택하고 M32.05/.06에 연결한다. 장비 없는 기본 기준과 선택 실물 확장 기준을 구분한다.