그들은 올바른 것을 씁니다.

120톤의 우주 왕복선은 거의 4백만 파운드의 로켓 연료로 둘러싸여 있고 유독 가스를 내뿜고 중력을 거스르는 것을 참을성이 없어 보이는 동안 온보드 컴퓨터가 명령을 내립니다.

그들은 올바른 것을 씁니다.

T-마이너스 31초에 적절한 항목이 시작됩니다.

120톤의 우주 왕복선은 거의 4백만 파운드의 로켓 연료로 둘러싸여 있고 유독 가스를 내뿜고 중력을 거스르는 것을 참을성이 없어 보이는 동안 온보드 컴퓨터가 명령을 내립니다. 동일한 소프트웨어를 실행하는 4개의 동일한 기계가 수천 개의 센서에서 정보를 가져오고 수백 밀리초의 결정을 내리고 모든 결정에 투표하고 초당 250번 서로 확인합니다. 다른 소프트웨어가 있는 다섯 번째 컴퓨터는 나머지 네 대가 오작동할 경우 제어를 위해 대기합니다.



T-마이너스 6.6초에서 압력, 펌프 및 온도가 공칭이면 컴퓨터는 셔틀 주 엔진에 불을 붙이라고 명령합니다. 발사대에서 배가 흔들리고 볼트로만 지면에 고정된 배가 연소실로 들어갑니다. 주 엔진이 100만 파운드의 추력에 도달하면 배기 가스가 파란색 다이아몬드 불꽃으로 조여집니다.

찰스 피시맨이 참여한 작품 더보기

그리고 나서 T-마이너스 0초에 컴퓨터가 엔진이 제대로 작동하고 있다고 만족하면 고체 로켓 부스터에 불을 붙이라는 명령을 내립니다. 1초 이내에 660만 파운드의 추력을 달성합니다. 그리고 바로 그 순간에 컴퓨터가 폭발을 명령하고 450만 파운드의 우주선이 발사대에서 장엄하게 들어 올려집니다.



하드웨어 성능의 멋진 디스플레이입니다. 그러나 인간이 버튼을 눌러 그것을 가능하게 하지 않으며, 우주비행사 기수도 우주선을 궤도에 안착시키기 위해 조이스틱을 누르지 않습니다.



올바른 것은 소프트웨어입니다. 소프트웨어는 주 엔진 짐벌에 명령을 내리고 셔틀이 타워를 청소한 직후에 극적인 배꼽 롤을 실행합니다. 소프트웨어는 우주선이 너무 빨리 가속되지 않도록 엔진을 조절합니다. 그것은 셔틀이 어디에 있는지 추적하고, 고체 로켓 부스터를 떨어뜨리도록 명령하고, 약간의 코스 수정을 가하고, 약 10분 후에 셔틀을 100마일 이상의 궤도로 안내합니다. 소프트웨어가 우주에서 셔틀의 위치에 만족하면 주 엔진을 끄도록 명령합니다. 무중력 상태가 시작되고 모든 것이 부유하기 시작합니다.

그러나 소프트웨어가 얼마나 많은 작업을 하느냐가 소프트웨어를 주목하게 만드는 것은 아닙니다. 놀라운 것은 소프트웨어가 얼마나 잘 작동하는지입니다. 이 소프트웨어는 충돌하지 않습니다. 다시 부팅할 필요가 없습니다. 이 소프트웨어는 버그가 없습니다. 그것은 인간이 성취한 것만큼 완벽합니다. 다음 통계를 고려하십시오. 프로그램의 마지막 세 가지 버전 - 각 420,000행에는 각각 하나의 오류가 있었습니다. 이 소프트웨어의 마지막 11개 버전에는 총 17개의 오류가 있습니다. 동등한 복잡성의 상용 프로그램에는 5,000개의 오류가 있습니다.

이 소프트웨어는 휴스턴 남동쪽 텍사스 클리어 레이크에 있는 존슨 우주 센터 건너편에 있는 익명의 사무실 건물에 거주하는 260명의 남녀가 작업한 것입니다. 그들은 Lockheed Martin Corps 우주 임무 시스템 사업부의 한 지점인 온보드 셔틀 그룹에서 일하며 그들의 기량은 세계적으로 유명합니다. 연방 정부 SEI(Software Engineering Institute)는 작업 방식의 정교함과 신뢰성을 측정합니다. 사실, SEI는 부분적으로는 온보드 셔틀 그룹이 작업을 수행하는 것을 지켜본 결과 표준을 기반으로 했습니다.



이 그룹은 소프트웨어를 잘 작성해야 하기 때문에 소프트웨어를 잘 작성합니다. 우주선이 발사될 때마다 그들의 소프트웨어는 40억 달러의 장비, 6명의 우주 비행사의 삶, 국가의 꿈을 제어합니다. 우주에서 가장 작은 오류라도 엄청난 결과를 초래할 수 있습니다. 궤도를 도는 우주 왕복선은 시속 17,500마일로 이동합니다. 2/3초의 타이밍 문제를 일으키는 버그는 우주 왕복선을 코스에서 3마일이나 벗어납니다.

NASA는 소프트웨어가 얼마나 좋은지 알고 있습니다. 매 비행 전에 온보드 셔틀 그룹의 수석 기술 관리자인 Ted Keller는 플로리다로 날아가 소프트웨어가 셔틀을 위험에 빠뜨리지 않을 것임을 증명하는 문서에 서명합니다. 켈러가 갈 수 없다면 공식 승계선에 따라 누가 대신 서명할 수 있는지 결정됩니다.

지난 22년 동안 우주 비행 소프트웨어를 개발한 Bill Pate는 [/url]그룹이 위험을 이해하고 있다고 말합니다. 소프트웨어가 완벽하지 않으면 회의에 참석하는 사람들 중 일부가 죽을 수도 있습니다.

소프트웨어가 전부입니다. (역시 짜증난다.)



인간 기술의 역사에서 소프트웨어만큼 빠르게 필수적인 것은 없습니다.

국제 통화 시스템과 주요 발전소에서 믹서기와 전자레인지에 이르기까지 거의 모든 것이 소프트웨어에서 실행됩니다. 사무실 건물에서는 엘리베이터, 조명, 물, 에어컨이 모두 소프트웨어로 제어됩니다. 자동차에서는 변속기, 점화 시기, 에어백, 도어록까지 소프트웨어로 제어됩니다. 대부분의 도시에서 신호등도 마찬가지입니다. 엽서보다 복잡한 거의 모든 서면 커뮤니케이션은 소프트웨어에 의존합니다. 모든 전화 통화와 모든 야간 소포 배달에 필요합니다.

소프트웨어가 전부입니다. 그것은 또한 짜증난다.

스티브 잡스 넥스트(Steve Jobs NeXT) 컴퓨터용 소프트웨어를 작성했으며 조지 메이슨 대학교(George Mason University) 교수인 브래드 콕스는 수메르 이전 문명과 같다고 말합니다. 우리가 소프트웨어를 구축하는 방식은 수렵-채집 단계에 있습니다.

소프트웨어 엔지니어이자 아이다호 대학의 컴퓨터 과학 교수인 John Munson은 그다지 관대하지 않습니다. 동굴 예술, 그는 말합니다. 원시적입니다. 우리는 컴퓨터 과학을 가르친다고 합니다. 여기에는 과학이 전혀 없습니다.

소프트웨어는 산업화 이후의 세계에 동력을 제공할 수 있지만 소프트웨어의 생성은 산업화 이전의 무역으로 남아 있습니다. SEI의 연구에 따르면 소프트웨어 조직의 거의 70%가 SEI의 정교함의 처음 두 수준인 혼돈과 혼돈보다 약간 나은 수준에 갇혀 있습니다. 상황이 너무 심각하여 Microsoft와 같은 회사의 일부 소프트웨어 개척자가 소프트웨어 제작 기술을 가르치기 위해 헤어졌습니다(Drop and Code me Twenty! 참조).

SEI 기술의 선임 멤버인 Mark Paulk는 소프트웨어의 성공이 소프트웨어의 약점을 더욱 극적으로 만든다고 말합니다. 우리는 엄청나게 복잡하고 강력한 소프트웨어 제품을 개발했습니다. 우리는 그것에 크게 의존하고 있다고 Paulk는 말합니다. 그러나 모든 사람들은 모든 결함과 함께 소프트웨어가 얼마나 나쁜지 불평합니다. 결함이 5,000개 있는 차를 산다면 매우 속상할 것입니다.

이 소프트웨어 늪에서 온보드 셔틀 그룹은 예외로 두드러집니다. 10년 전만 해도 셔틀 그룹은 세계적인 수준으로 여겨졌습니다. 그 이후로 자체 오류율을 90%까지 줄였습니다.

이렇게 좋기 위해서는 온보드 셔틀 그룹이 매우 달라야 합니다. 대중의 상상력을 사로잡은 밤새도록 피자와 롤러 하키 소프트웨어 코더와 정반대입니다. 이렇게 하려면 온보드 셔틀 그룹이 매우 평범해야 하며 집중되고 훈련되고 체계적으로 관리되는 창의적인 기업과 구별할 수 없습니다.

사실, 이 그룹은 프로그래머, 특히 일반적으로 생산자에게 동등하게 적용되는 일련의 교과서 수업을 제공합니다. 그들이 구축한 문화와 그들이 완성한 프로세스를 살펴보면 소프트웨어가 약속을 실현하려면 소프트웨어 작성이 어떤 것이 되어야 하는지, 거의 모든 팀 기반 작업이 성능을 향상시켜 거의 완벽한 결과를 달성할 수 있는지 보여줍니다. .

성인용 소프트웨어

오늘도 배송 지옥은 계속되었습니다. 갈고, 갈고, 갈고. 우리는 결코 해내지 못할 것입니다. 내가 이미 말했습니까? 왜 우리는 항상 배송 일정을 과소평가합니까? 난 그냥 이해가 안 돼요. 오전 9시 30분; 저녁 11시 30분에 도미노에서 나옵니다. 그리고 다이어트 콜라 3개.

아니요, 온보드 셔틀 그룹이 아닙니다. 더글라스 쿠플랜드(Douglas Coupland)의 마이크로서프(Microserf)의 작품으로, 소프트웨어 속도가 빠른 레인에서의 삶에 대한 실제와 같은 허구적 설명입니다. 그리고 그것은 소프트웨어 개발 세계의 지배적인 이미지입니다. X세대는 티셔츠와 산만한 외모를 자랑하며 너무 짧은 시간에 너무 많은 영웅적인 코드를 짜내는 것입니다. 롤러블레이드와 산악 자전거가 구석에 박혀 있습니다. 회의실에 버려진 피자 상자와 스타벅스 컵; Smashing Pumpkins, Alanis Morrisette and the Fugees의 결투 곡. 그 세계는 Sun Microsystems, Microsoft 및 Netscape의 이야기로 유명하고 낭만적이며 피할 수 없는 곳이 되었습니다.

은행이 동전에 지불하는 것

온보드 셔틀 그룹의 이야기가 아닙니다. 그들의 숙소는 사무직 보행자에 대한 연구입니다. 가장 눈에 띄는 것은 평범한 외모다. 가끔 나오는 셔틀 기념품 외에는 작은 회사나 정부 기관의 사무실에 있을 수 있습니다. 모든 사람은 자신만의 작은 사무실을 가지고 있으며 사무실에는 책상, PC 및 희소한 개인 유물이 있습니다. 사람들은 적당히 단정한 옷을 입고 출근합니다. 단정하지만 화려하지도, 확실히 지저분하지도 않습니다.

엄밀히 말하면 8시 5분의 장소입니다. 늦은 밤이 있지만 예외입니다. 프로그래머는 강렬하지만 키가 낮습니다. 그들 중 많은 사람들이 IBM(1994년까지 셔틀 그룹을 소유)을 위해 또는 셔틀 소프트웨어에 직접 수년간 일했습니다. 그들은 배우자와 자녀가 있는 성인이며 놀라운 소프트웨어 프로그램을 넘어선 삶을 살고 있습니다.

2050년에 살기 좋은 곳

그것이 문화입니다. 온보드 셔틀 그룹은 성인용 소프트웨어를 생산하고, 그들이 하는 방식은 성인이 되는 것입니다. 그것은 섹시하지 않을 수도 있고 코딩 자기 여행이 아닐 수도 있습니다. 그러나 이것은 소프트웨어의 미래입니다. 다음 단계를 밟을 준비가 되었을 때(충분히 좋은 소프트웨어 대신 완벽한 소프트웨어를 작성해야 할 때) 이제 성장할 때입니다.

그룹의 수석 기술 관리자인 48세의 Ted Keller는 작은 사립 고등학교의 교장처럼 생겼습니다. 소프트웨어가 모든 기능과 함께 제시간에 제공되도록 하는 것이 Keller의 임무입니다. 그는 몸집이 작고 대머리에 약간 사나우며 내성적이어서 우주 비행사라면 누구나 안심할 수 있는 자질입니다. 그는 부드럽고 괴짜 같은 유머 감각을 가지고 있으며 외부인이 아니라 군중에 대해 잘 알고 있습니다.

그것은 소프트웨어 그룹의 구성원과 NASA의 구성원 간의 회의에서 나옵니다. 22명과 오버헤드 프로젝터로 꽉 찬 작은 회의실에서 열립니다. 방 뒤에서 켈러가 몇 번이고 코드 전달 속도나 일부 사양의 세부 사항에 대해 험담을 하고, 방은 웃음으로 환해진다.

그렇지 않으면 한 시간 동안 진행되는 회의가 문화에 대한 간략한 창으로 냉정하고 드러납니다. 한 가지 예로, 회의실에 있는 22명 중 12명이 여성이며 대부분이 고위 관리자 또는 고위 기술 직원입니다. 안정성과 전문성을 갖춘 온보드 셔틀 그룹은 특히 여성 프로그래머에게 매력적으로 보입니다.

다른 사람에게는 순서, 세부 사항 및 체계적인 반복 연습입니다. 회의는 NASA의 고전적인 공연으로, 몇 주 후에 거의 동일한 회의를 위한 리허설입니다. 그것은 엄청난 양의 데이터와 보기(소프트웨어의 진행 상황과 상태를 한 줄씩 설명하는 그래프)를 살펴보는 것으로 구성됩니다. Keller의 이따금 제쳐두고, 어조는 비즈니스와 거의 형식적인 견해입니다. 읽을 수 있는 한 빨리 지나가는 그래프, 흐릿한 두문자어, 그래프 및 차트.

여기서 진행되는 것은 그룹 완벽을 위한 드라이브를 정의하는 일종의 너트와 볼트 작업입니다. 셔틀 그룹의 문화에는 슈퍼스타 프로그래머가 없습니다. 소프트웨어 개발에 대한 전체 접근 방식은 의도적으로 특정 사람에게 의존하지 않도록 설계되었습니다.

이 문제에서 더 많은 것


  • 셔틀이 왼손잡이인 이유
  • 그는 아이디어를 회사로 전환합니다 – Net Speed
  • 드롭 앤 코드 미 스물
  • 성공 뒤에 오는 것은 무엇입니까?
  • 마케팅의 바이러스

그리고 문화는 창의성, 개별 코딩 번성 및 밤새도록 소프트웨어 세계의 특징인 스타일에 똑같이 편협하지 않습니다. 사람들은 이 과정이 창의성을 억누르지 않느냐고 묻습니다. 매뉴얼에 명시된 대로 정확하게 수행해야 하며 누군가 어깨 너머로 지켜보고 있다고 Keller는 말합니다. 대답은 그렇습니다. 그 과정이 창의성을 억누릅니다.

그것이 바로 요점입니다. 우주선을 비행하는 소프트웨어 코드를 통해 프리랜서로 일하는 사람들을 가질 수는 없습니다. 그런 다음 사람들의 생명이 우주선에 의존하기 때문에 궤도에 오르면 패치를 시도해야 합니다. 휴스턴은 문제가 있습니다. 좋은 영화를 만들 수 있습니다. 소프트웨어를 작성하는 방법이 아닙니다. 사람들은 소프트웨어를 변경하는 것이 아니라 프로세스를 변경하는 데 창의성을 쏟아야 한다고 Keller는 말합니다.

그룹 관행의 엄격한 제한은 로큰롤 소프트웨어 세계의 사이렌 노래를 저항하기 어렵게 만들 수 있습니다. Quinn Larson(34세)은 지난 1월 아이다호주 보이시에 있는 Micron Technology에서 일하기 위해 떠나 Microns 메모리 칩 제조를 자동화할 때 셔틀 소프트웨어에 대해 7년 동안 일했습니다.

Micron에서 Larson은 완성된 칩 웨이퍼를 올바른 크기로 절단하는 톱을 자동화하는 작업을 받았습니다. 프로그램을 망치면 귀중한 웨이퍼를 파괴합니다.

무엇을 할지 결정하는 것은 나에게 달려 있다고 Larson은 말합니다. 회의도 없었고 기록 보관도 없었습니다. 그에게는 자유가 있었다. 진짜 킥이었다. 그러나 Larson의 사고 방식에 따르면 문화는 올바른 것에 초점을 맞추지 않았습니다. 속도가 가장 중요하다고 그는 말합니다. 엔지니어들은 이것이 우리의 최우선 과제이며 가능한 한 빨리 얻어야 한다고 말합니다. 그러나 Larson이 얻은 인상은 엔지니어들이 완성된 소프트웨어가 실제로 얼마나 잘 작동하는지에 대해 그다지 걱정하지 않는 것 같다는 것이었습니다. 기본적으로 그들은 빠른 소프트웨어를 원했습니다.

Larson은 8월 중순에 셔틀 그룹에서 다시 시작했습니다. 그는 Clear Lake로 돌아온 첫날에 이곳 사람들이 가장 수준이 높은 사람들이라고 말했습니다.

프로세스입니다

그들은 어떻게 올바른 것을 작성합니까?

정답은 바로 프로세스입니다. 그룹의 가장 중요한 창조물은 그들이 작성하는 완벽한 소프트웨어가 아니라 완벽한 소프트웨어를 작성하기 위해 그들이 발명한 프로세스입니다.

정상적인 생활을 하고, 실제로 만나는 기한을 정하고, 예산을 유지하고, 약속한 대로 소프트웨어를 제공할 수 있도록 하는 프로세스입니다. 휴스턴 남동부 교외의 평평한 평야에 있는 이 코더들이 소프트웨어 세계의 다른 모든 사람들이 여전히 찾고 있다는 것을 알고 있는 것을 정의하는 프로세스입니다. 일관되고 지속적으로 개선되는 품질을 생산하는 방법을 찾고 있는 창의적인 기업을 위한 템플릿을 제공하는 프로세스입니다.

이 과정은 네 가지 간단한 명제로 줄일 수 있습니다.

1. 제품은 제품에 대한 계획만큼만 좋습니다.온보드 셔틀 그룹에서 소프트웨어 작성 프로세스의 약 3분의 1이 누군가가 한 줄의 코드를 작성하기 전에 발생합니다. NASA와 Lockheed Martin 그룹은 새 코드가 수행해야 하는 모든 작업에 대해 가장 세세한 부분에 동의합니다. 그리고 일반적으로 청사진에서 볼 수 있는 종류의 특이성과 정확성을 바탕으로 그 이해를 종이에 담았습니다. 사양의 어떤 것도 양측의 합의와 이해 없이는 변경되지 않습니다. 그리고 변경 사항을 자세히 설명하는 사양 없이 코드 한 줄을 변경하는 코더는 없습니다. 프로그램의 1.5% 또는 6,366줄의 코드를 포함하는 변경인 위성 위치 확인 위성으로 셔틀이 탐색할 수 있도록 소프트웨어를 업그레이드하십시오. 한 가지 변경 사항에 대한 사양은 전화번호부보다 두꺼운 2,500페이지입니다. 현재 프로그램의 사양은 30권을 채우고 40,000페이지를 실행합니다.

NASA의 소프트웨어 프로젝트를 관리하는 William R. Pruett은 요구 사항이 거의 의사 코드라고 말합니다. 이 조건과 상황을 감안할 때 꼭 이렇게 해야 한다, 이렇게 해야 한다.

아이다호 대학의 존 먼슨은 이 세심한 설계 과정만으로도 셔틀 조직을 수업에 넣을 수 있다고 말합니다. 대부분의 조직은 소프트웨어가 청사진과 같이 세부적으로 수행해야 하는 작업을 계획하지 않고 큰 프로젝트에도 착수합니다. 따라서 코더가 이미 프로그램 작성을 시작한 후 고객은 바쁘게 디자인을 변경하고 있습니다. 그 결과 코드가 설계되는 동안에도 지속적으로 변경되고 오류에 감염되는 혼란스럽고 비용이 많이 드는 프로그래밍이 됩니다.

대부분의 사람들은 프로세스의 잘못된 끝에 돈을 쓰기로 선택한다고 Munson은 말합니다. 최신 소프트웨어 환경에서 소프트웨어 비용의 80%는 소프트웨어가 처음 작성된 후 소비됩니다. 셔틀에서는 처음부터 제대로 해냅니다. 그리고 그들은 청사진을 변경하지 않고 소프트웨어를 변경하지 않습니다. 그렇기 때문에 그들의 소프트웨어는 완벽합니다.

2. 최고의 팀워크는 건전한 경쟁입니다.소프트웨어 그룹에는 하위 그룹과 하위 문화가 있습니다. 그러나 다른 조직에서 분열적인 사무실 정치가 될 수 있는 것은 실제로 프로세스의 중요한 부분입니다.

중앙 그룹은 두 개의 핵심 팀으로 나뉩니다. 코더(앉아서 코드를 작성하는 사람)와 검증자(코드에서 결함을 찾으려고 노력하는 사람)입니다. 두 복장은 서로 다른 보스에게 보고하고 반대 행군 명령에 따라 작동합니다. 개발 그룹은 완전히 오류가 없는 코드를 제공해야 하므로 테스터가 결함을 전혀 찾지 못할 정도로 완벽합니다. 테스트 그룹은 가능한 한 많은 결함을 드러내는 비행 시나리오와 시뮬레이션을 통해 코드를 파헤쳐야 합니다. 결과는 Tom Peterson이 우호적 적대 관계라고 부르는 것입니다.

얼마나 자주 공부 휴식을 취해야

그들은 누가 오류를 찾을 것인지 경쟁하고 있다고 Keller는 말합니다. 때때로 그들은 고양이와 개처럼 싸웁니다. 개발자는 자신의 모든 오류를 포착하기를 원합니다. 검증자들은 화를 내며 '야, 포기해! 소프트웨어를 테스트하는 데 우리의 시간을 빼앗고 있습니다!'

개발자들은 신중하게 조정된 세션에서 코드에 대한 공식적인 자체 검사를 시작했습니다. 엄격한 교정 읽기는 테스터를 혼란스럽게 할 것입니다. 검증자는 테스트를 시작하기도 전에 발견된 일부 오류에 대해 인정받을 자격이 있다고 주장합니다. 검증 그룹의 관점에서 고위 관리자인 Pat McLellan은 독립적인 검증 그룹이 없으면 개발자가 더 느슨한 경향이 있다는 것을 알고 있다고 말합니다. 우리 그룹의 존재만으로도 더 조심스러워집니다.

이 우호적인 경쟁의 결과: 이제 셔틀 그룹은 공식 테스트가 시작되기 전에 오류의 85%를 발견하고 프로그램이 NASA에 전달되기 전에 99.9%를 찾습니다.

3. 데이터베이스는 소프트웨어 기반입니다.소프트웨어가 있습니다. 그리고 소프트웨어 아래에 데이터베이스가 있습니다. 두 개의 거대한 데이터베이스는 포괄적인 면에서 백과사전적입니다.

하나는 코드 자체의 히스토리입니다. 모든 라인에 주석이 달려 있어 변경될 때마다, 왜 변경되었는지, 언제 변경되었는지, 변경 목적이 무엇인지, 변경 사항을 자세히 설명하는 사양 문서가 무엇인지 보여줍니다. 프로그램에 발생하는 모든 것은 마스터 히스토리에 기록됩니다. 모든 코드 라인의 계보(있는 그대로의 이유)는 모든 사람이 즉시 사용할 수 있습니다.

다른 데이터베이스인 오류 데이터베이스는 온보드 셔틀 그룹이 작업을 수행하는 방식에 대한 일종의 기념비입니다. 여기에는 거의 20년 전으로 거슬러 올라가 소프트웨어를 작성하거나 작업하는 동안 발생한 모든 단일 오류가 기록됩니다. 이러한 모든 오류에 대해 데이터베이스는 오류가 발견된 시간을 기록합니다. 어떤 명령 세트가 오류를 나타냈는지; 누가 그것을 발견했는지; 그것이 발견되었을 때 어떤 활동이 진행 중이었는지 - 테스트, 훈련 또는 비행. 오류가 프로그램에 어떻게 도입되었는지 추적합니다. 오류를 포착하기 위해 모든 단계에서 설정한 필터를 어떻게 지나쳐 오류가 발생했는지 — 설계 중에 포착되지 않은 이유는 무엇입니까? 개발 검사 중? 확인 중? 마지막으로 데이터베이스는 오류가 수정된 방법과 유사한 오류가 동일한 구멍을 통과했는지 여부를 기록합니다.

이 그룹은 작업 방식에 대해 축적된 데이터가 너무 많아서 코드 작성 프로세스를 모델링하는 소프트웨어 프로그램을 작성했습니다. 날씨를 예측하는 컴퓨터 모델과 마찬가지로 코딩 모델은 그룹이 소프트웨어의 새 버전을 작성할 때 얼마나 많은 오류를 범해야 하는지 예측합니다. 실제와 같이 코더와 테스터가 오류를 너무 적게 찾으면 모든 사람이 현실과 예측이 일치할 때까지 프로세스를 수행합니다.

선임 관리자인 Patti Thornton은 '우리는 어떤 것도 포기하지 않습니다. 우리는 정반대로 모든 것이 우리를 괴롭히도록 내버려둡니다.

4. 실수만 고치지 말고 처음부터 실수를 허용한 것을 고치십시오.

이 프로세스는 너무 광범위하여 오류에 대한 책임이 있습니다. 소프트웨어에 결함이 있는 경우 작성 방식에 문제가 있고 수정할 수 있는 부분이 있어야 합니다. 계획 단계에서 발견되지 않은 오류는 최소한 몇 가지 검사를 통과했습니다. 왜요? 검사 과정에 문제가 있습니까? 질문을 체크리스트에 추가해야 합니까?

중요한 것은 그룹이 오류에 대해 사람들을 비난하는 것을 피한다는 것입니다. 프로세스는 책임을 가정합니다. 그리고 오류가 발생한 이유와 방법을 알아내기 위해 분석되는 프로세스입니다. 동시에 책임은 팀 개념입니다. 아무도 코드를 작성하거나 검사하는 데 단독 책임이 없습니다. 기술 직원의 선임 멤버인 Marjorie Seiter는 실수를 해도 처벌을 받지 않는다고 말합니다. 내가 실수하고 다른 사람들이 내 작업을 검토한다면 나는 혼자가 아닙니다. 나는 이것에 대해 비난받지 않습니다.

Ted Keller는 셔틀 원격 조작기 암과 관련된 접근 방식의 결과에 대한 예를 제공합니다. Keller는 우주 비행사가 팔을 조작하고 탑재량을 처리할 수 있도록 하는 승무원 훈련용 소프트웨어를 제공했다고 말합니다. 팔은 특정 지점에 도달하면 단순히 움직임을 멈췄습니다.

프로그래밍 오류로 인해 소프트웨어가 혼동되었습니다. 원격 암의 손목이 완전한 360도 회전에 가까워짐에 따라 잘못된 계산으로 인해 소프트웨어에서 암이 완전히 회전하지 않았다고 생각하게 되었습니다. 문제는 일반적인 수학 문제에 대한 답을 반올림하는 것과 관련이 있었지만 다른 문제의 연속성을 드러냈습니다.

이것이 중요하지는 않지만 Keller는 다시 돌아가서 다른 코드 행에 정확히 같은 종류의 문제가 있는 것이 무엇인지 물었습니다. 그들은 코드에서 이러한 상황을 8개 찾았고 그 중 7개에서는 반올림 기능이 문제가 되지 않았습니다. 그 중 하나는 고이득 안테나 포인팅 루틴과 관련이 있다고 Keller는 말합니다. 메인 안테나입니다. 이 문제가 발생했다면 중요한 시점에 지상과의 통신이 중단되었을 수 있습니다. 훨씬 더 심각합니다.

프로세스가 작동하는 방식은 소프트웨어의 오류만 찾는 것이 아닙니다. 프로세스는 프로세스에서 오류를 찾습니다.

그냥 소프트웨어 문제

B-2 폭격기는 첫 비행을 하지 않았지만 소프트웨어 문제였습니다. 새로운 덴버 공항은 수하물 처리 시스템이 제대로 작동하지 않아 개장이 몇 개월 늦었고 예산이 수백만 달러 초과되었습니다. 하지만 그것은 단지 소프트웨어 문제였습니다. 올 봄, 유럽 우주국(European Space Agency)의 새로운 Ariane 5 로켓은 약간의 소프트웨어 문제로 첫 발사에서 폭발했습니다. IRS에서 National Weather Service에 이르기까지 연방 정부의 주요 기관은 종종 단순한 소프트웨어 문제로 인해 몇 년이 지연되고 예산보다 수억 달러가 초과된 프로젝트로 어려움을 겪고 있습니다. 소프트웨어는 점점 더 보편화되고 더 중요해지고 있지만, 점점 더 안정적이지는 않는 것 같습니다.

나머지 세계가 기본 사항에 어려움을 겪으면서 온보드 셔틀 그룹은 완벽한 소프트웨어에 더욱 가까워졌습니다. 분명히 그들은 소프트웨어 세계의 나머지 부분에 비해 많은 이점을 가지고 있습니다. 그들은 하나의 제품을 가지고 있습니다. 하나의 우주선을 비행하는 하나의 프로그램입니다. 그들은 자신의 소프트웨어를 친밀하게 이해하고 있으며 항상 그것에 더 익숙해집니다. 이 그룹에는 똑똑한 고객이 한 명 있습니다. 그리고 돈이 중요한 제약은 아닙니다. 그룹의 연간 예산 3,500만 달러는 NASA 파이의 사소한 부분이지만 라인당 달러 기준으로 보면 그룹을 미국에서 가장 비싼 소프트웨어 조직 중 하나로 만듭니다.

그리고 그것이 요점입니다. 셔틀 프로세스가 너무 극단적이고 완벽을 향한 추진력이 너무 집중되어 가차 없는 실행을 달성하는 데 필요한 것이 무엇인지 보여줍니다. 셔틀 그룹이 하는 가장 중요한 일은 사전에 신중하게 소프트웨어를 계획하고, 설계가 완료될 때까지 코드를 작성하지 않으며, 청사진을 지원하지 않고는 변경하지 않고, 코드를 완전히 정확하게 기록하는 것은 비용이 많이 들지 않습니다. 그 과정은 로켓 과학도 아니다. 소프트웨어 엔지니어링을 제외한 거의 모든 엔지니어링 분야의 표준 관행입니다.

회의실 벽에 붙여진 온보드 셔틀 그룹의 비공식 슬로건은 프로세스에 계속 집중하는 것의 본질을 포착합니다. 더 빨리 뒤처질수록 더 많은 시간을 따라잡아야 합니다.

Charles Fishman(fish@nando.net)은 노스캐롤라이나 주 롤리에 거주하는 작가입니다.