라디컬에드워드 X세대

기술 진영에서

인지적 견해 : 소프트웨어 설계를 보는 다른 시각

• 소프트웨어 설계란 무엇인가.?
  • 설계는 머리속, 두뇌 안에서 일어는 무언가이며 이는 빛보다 빠른 속력으로 일어난다.
  • 대부분의 전문가들도 설계(머리속의 무언가)에 대해서 명확하게 이해하고 정확하게 강의할 수 있는 사람은 없다.
• 실증 연구 결과
  • 설계의 외적인 표현에 연연해 하지 말고 사고의 흐름(머리속에서 어떻게 굴러 가는지)에 초점을 맞춰야 한다. 설계의 비밀은 마음 속에 있다.
  • ‘프로그래머에 대한 실증 연구‘라고 불리우는 연구 분야에서 ‘프로토콜 분석‘이라는 기법을 이용해서 설계자들이 하는 일을 이론적으로 체계화 하고자 했는대 밝혀낸 사실이 그닥~~
  • 아무튼 그들은 설계가 다음 활동을 포함한다고 밝혔다.
    • 문제 이해
    • 문제를 목표와 목적으로 나누기
    • 문제 해결을 위한 계획을 선택하고 세우기
    • 계획을 따르기
    • 제품과 절차를 숙고하기
  • 저자는 위의 것들을 대부분 별 도움이 안되는 정보라 판단하지만 문제 해결을 위한 계획을 선택하고 세우기의 항목을 콕 찝어서 더 파고 들고자 함
• 설계의 본질
  • 결론적으로 설계의 본질은 신속한 모델링과 시뮬레이션이다. 그리고 설계의 핵심 요소는 해결책을 제안하고 실패를 허용하는 능력이다!
  • 설계에 미숙한 사람들을 대상으로 실험해본 결과
    • 모델이 아니라 설계의 표현에 치중
    • 시뮬레이션을 수행하지도 못했으며 불충분한 설계안을 내놓고 더 이상 진전하지 못함
  • 이러한 결론은 저자가 가장 좋아하는 사고 방식 중 하느는 실패가 성공적인 설계의 핵심 요소라는 생각
  • 따라서 성공하려면 실패하는 능력과 실패를 극복하는 능력이 필수적이다.
  • 찰스 시모니 : “프로그래밍의 첫번째 단계는 상상이다. 일어날 일을 마음 속으로 명확히 구체화 한다. 이와 같은 초기 단계에서 나는 연필과 종이를 사용한다. 진짜 그림은 마음속에 있기 때문에.. 그저 끄적일 뿐이다.”
  • 개리 킬달 : “어느 순간 (설계가) 폭발적으로 떠올라서 머리 속에 모두 들어 있다.. 머리 속에 온갖 생각이 들어있어서 종이에 옮기지 못한다. 마음속으로 계속 고치기 때문이다.”
  • 빌게이즈 : “프로그램이 어떻게 돌아갈지 마음 속으로 시뮬레이션 해야 한다... 무언가를 만들때... 그리고 마음속에 모델을 담고 있어야 한다. 이건 꽤나 고독한 작업이다.”
• 기타 연구 결과
  • “설계자들이 무(無)에서 시작하는 경우는 거의 없다.” 즉 시뮬레이션을 시작하는 첫 번째 개괄적인 모델은 앞서 유사한 문제에 사용했던 해결책에서 가져 온다는 뜻이다.
  • 1980년대 이후 설계는 팀 업무로 변화했다.
  • 팀설계는 개별 설계의 공유 형태라는 사실
    • 팀은 서로가 공유하는 정신적인 모델을 만든다.
    • 팀 구성원은 각자 혹은 다같이 공유 모델을 놓고 시뮬레이션을 수행한다.
    • 팀은 시뮬레이션을 평가하고 다음 단계 모델을 준비한다.
  • 팀 설계와 개별 설계가 다른면
    • 설계 과정에서의 충돌. 이는 회피하기보다는 적절히 관리해야 한다.
    • 설계 과정에서 의소소통 기술이 매우 중요해 진다.
    • 아무도 책임 지려는 사람이 없어서 사안이 ‘구렁이 담넘어 가듯’ 사라지기도 한다.
  • 낙타는 위원회가 설계한 경주마
• 앞으로 나갈 방향
  • 설계 교육 : 단순히 방법론이나 표현법 몇 가지를 가르치는 일만으로 충분하지 않다. 설계를 정신적인 과정으로 보는 새로운 개념을 토대로 한 기반틀 안에서 방법론과 표현법을 가르쳐야 한다.
  • 설계 수행 : 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실이 설계의 핵심이라는 사실을 이해해야 한다. (죄책감 없는 설계 방식)
  • 설계 관리 : 관리자는 의사소통 활성화와 문제 해결에 신경 써서 설계에 기여해야 한다.
  • 인지적 설계 절차...

소프트웨어 오류에 대한 단상

• 저자는 소프트웨어 오류를 돋보기 삼아서 소프트웨어 공학 프로세스와 소프트웨어 공학 제품을 집중적으로 들여다보고 몇가지 생각을 전하고자 한다.
• 생각 1. 기존의 소프트웨어 오류 제거 기술로 찾지 못하는 오류가 존재한다.
  • 이는 프로세스에 대한 생각이다.
  • 기존에 알려진 소프트웨어 오류 제거 프로세스는 (1) 검토, (2) 테스트, (3) 증명으로 분류
  • 현재 소프트웨어 오류 문제를 모두 해결하는 단일 프로세스는 존재하지 않는다.
• 생각 2. 결코 찾지 못하는 소프트웨어 오류가 존재한다.
  • 이건 제품에 대한 생각이다.
  • 중요한것은 사람 목숨이나 돈이 걸린 시스템에서 사용하는 소프트웨어는 소프트웨어 오류에 대비하여 오류 제거와는 또 다른 준비를 해야 한다.
  • 결함 포용 소프트웨어(fault tolerant software)
• 생각 3. 소프트웨어 오류 발견자가 모두 동급은 아니다.
  • 이는 프로세스를 사용하여 제품을 제작하는 사람에 대한 생각이다.
  • 소프트웨어 오류 제거에서 가장 중요한 요소는 제품의 특성이나 프로세스의 특성이 아니라 올바른 사람의 선택이다.
• 생각 4. 모든 소프트웨어 오류가 동급이 아니다.
  • 이는 앞서 언급한 모든 생각을 정리하는 생각이다.
  • 어떤 오류는 다른 오류보다 훨씬 더 나쁘다.
    • 1) 모든 오류 제거 프로세스에도 불구하고 소프트웨어에 남아 있는 오류
    • 2) 시스템을 불안정하게 만들거나 값비싼 대가를 치르게 만드는 오류
  • 결론은 “오류 제거와 결함 포용은 모든 최악의 오류, 즉 시스템을 불안정하게 만드는 오류에 집중해야 한다.”
• 정리하자면
  • 오류를 해결해주는 단일 프로세스는 없다. 하지만 프로세스가 부족하다는 의미는 아니다.
    • 검토, 테스트, 증명 프로세스
    • 요구사항 테스트와 구조적 테스트
    • 통계적 테스트와 안정성 테스트
    • 단위 테스트, 통합 테스트, 시스템 테스트
    • 수만은 도구와 기술
    • 단순히 우리가 아는 어떤 프로세스보다 큰 문제
  • 생명이나 돈이 걸린 시스템의 소프트웨어는 오류에 대비해서 오류 제거를 넘어서는 주의가 필요하다.
  • 그리고 인력의 선택..
  • 오류 제거와 결함 표용은 최악의 오류에 대비해야 한다.

소프트웨어 오류 제거에 대한 실험적 관점

• 오류 제거에 효율적인 방법을 찾는것은 상당히 어렵다.
  • 그 이유로 첫번째가 객과적이고 사실적인 자료의 부족
  • 그러한 자료를 찾고자 하는 연구자들의 직무유기(^^)
• 테스트에 관한 실험이 있었다.
  • 지금 우리가 추구하는 방향은 열심히 테스트 하고 또 테스트 하고 그리고 또다시 테스트 한다.
  • 실험은 테스트 보다는 검토를 강조해야 한다고 제안한다.
    • 설계 검토, 코드 검토, 테스트 검토
• 실험 결과
  • 마이어와 마실리/셀비는 ‘기능적 테스트’,‘구조적 테스트’,‘코드 검토를 각각 비교 했다.
    • 결론은 코드 읽기가 기능적 테스트 혹은 구조적 테스트 보다 훨씬 낫다는 증거를 확보
    • 개수 측면 보다 비용 측면에서 훨씬 경제적
  • 콜로펠로/우드필드는 대규모 실시간 소프트웨어 프로젝트에서 얻은 자료를 기반으로 설계 검토, 코드 검토, 일반적으로 테스트라 부르르 행위를 비교 분석 했다.
    • 설계 검토와 코드 검토가 테스트 보다 낫다는 사실을 발견
    • 비용 측면 보다 개수 측면이 훨씬 경제적
  • 정리하자만 아래와 같다.
    • 효율성(개수측면) : 마이어(같음), 바셀/셀비(코드읽기-기능적테스트-구조적테스트), 콜로펠로/우드필드(코드 읽기-설계 검토-테스트)
    • 비용 효율 : 마이어(코드 검토-가장비쌈), 바셀/셀비(코드 읽기-가장 덜 비쌈), 콜로펠로/우드필드(설계 검토-코드 검토-테스트)
  • 저자의 제안
    • 1. 반드시 검토를 수행하여 테스트를 보완한다.
    • 2. 기능적 테스트를 강조화되 구조적 테스트도 수행해야 한다.
    • 3. 설계 검토와 코드 검토를 모두 수행해야 한다.
• 몇가지 짚고 넘어갈 사항
  • 기능적 테스트 : 프로그램의 요구사항 명세서를 기반으로 테스트 범위를 결정한다.
  • 구조적 테스트 : 프로그램의 내부적인 동작 방식에 맞게 테스트 케이스를 만든다.
  • 코드 검토 : 정적 작업으로 참여자들은 소스 코드를 살펴 오류를 찾는다.

다양한 테스트 종류

• 테스트의 종류
  • 목표 주도 테스트
    • 요구사항 주도 테스트
    • 구조 주도 테스트
    • 통계 주도 테스트
    • 위험 주도 테스트
  • 단계 주도 테스트
    • 단위 테스트
    • 통합 테스트
    • 시스템 테스트
• 요구 사항 주도 테스트
  • 단위 테스트 : 테스트 중인 구성 요소의 요구사항을 테스트
  • 통합 테스트 : 요구 사항 명세서에 담긴 소프트웨어 요구 사항을 모두 테스트 한다.
  • 시스템 테스트 : 새로운 환경에서 통합 테스트를 반복
• 구조 주도 테스트
  • 단위 테스트 : 소프트웨어의 최하위 구조, 즉 논리적 분기를 모두 테스트 한다.
  • 통합 테스트 : 모든 단위를 테스트
  • 시스템 테스트 : 시스템의 모든 구성 요소를 구성 요소가 한두개 뿐인 통합된 소프트웨어로 테스트
• 통계 주도 테스트 : 통합 테스트나 시스템 테스트 단계에서 의미가 있다.
• 위험 주도 테스트 : 시스템의 중요도에 따라 어느 단계에서 수행해도 좋지만 대체로 시스템 테스트 단계에서 가장 의미가 있다.
• 테스트 지금까지 그랬듯이 앞으로도 절대 사라지지 않을것이며 올바로만 수행한다면, 정확하고 철저한 테스트가 가능하다.

소프트웨어 품질과 소프트웨어 유지보수 사이의 관계

• 소프트웨어 품질이란 무엇일까? -> 속성의 집합으로 답변하면 다음과 같은 속성을 지녀야 한다.
  • 신뢰성(reliability)
  • 효율성(efficiency)
  • 인강 공학(human engineering)
  • 이해 용이성(understandability)
  • 수정 용이성(modifiability)
  • 테스트 용이성(testability)
  • 이식성(portability)
• 소프트웨어 유지보수란 무엇일까.? 사용자가 만족하도록 소프트웨어 기능을 유지하는 작업이다.
• 흥미롭게도 품질 속성 7가지중 대부분이 유지보수 핵심 개념과 직간접적으로 관련된다.
• 직접적 관련 : 이해 용이성, 수정 용이성
• 소프트웨어 품질 보증팀을 구성하는 핵심 인력은 궁극적으로 해당 제품의 유지보수를 담당하게될 당사자여야 한다고 제안함

소프트웨어 유지보스는 해결책이지 골치거리가 아니다.

• 유지보수를 골칫거리로 바라보는 전통적인 시각에서는 유지보수의 주요 목표가 비용 감소라고 말한다.
• 저자는 날못된 논지라고 생각 한다. 유지보수를 골칫거리가 아니라 해결책이라는 관점에서 보면, 우리가 진정 바라는 바는 더 많은 유지보수이지 더 적은 유지보수가 아니라는 사실이 금방 드러난다.
• 유지보스는 최소 비용이 아니라 최대 효율에 중점을 두어야 한다.
• 유지보수란?
  • 지적으로 복잡하다 (유지보수 담당자에게 극심한 제약이 가해지는 가운데에서도 창조력 발휘가 필요한 작업이다.)
  • 기술적으로 어렵다. (담당자는 개념, 설계, 코드를 동시에 다룰 줄 알아야 한다.)
  • 불공평 하다.(담당자는 항상 무언가 부족하다. 예를 들면 우수한 유지보수 문서가 없다)
  • 성공이 없다.(담당자는 항상 문제가 있는 사람들을 만난다)
  • 지저분 하다.(담당자는 세세한 구현까지 지저분한 수준에서 일해야 한다)
  • 과거에 산다.(분명 코드는 누군가 구현에 능숙해지기 전에 작성했다)
  • 부수적이다. (“긁어 부스럼 만들지 말자“라는 좌우명을 따른다.)
• 해결 방안
  • 간단하다. 최고의 인재를 최고의 대우로 유지보수 업무에 투입하라

단일 지점 제어(Single-point control)

• 단일 지점 제어는 여러곳에서 해야할 일을 한곳에서 해결한 수 필요한 곳에서 참조하는 방법이다.(DRY:Don’t Repeat Yourself)
• 예
  • 라이브러리 모듈과 같은 프로그램 모듈
  • 명명된 상수
  • 자료 선언
  • 표 주도 코드
  • 데이터베이스
• 그래서 저자는 단일 지점 제어를 기본 원리로 제안한다고 합니다.

사용자 편의성 – 유행어 인가, 도약인가?

• 사용자를 고려한다란 무슨 뜻일까.? – 소프트웨어 공학자들이 사용자 입장에서보고 사용자 관점에서 인터페이스를 개발한다는 말이다.
• 성공적인 사용자 인터페이스를 제공하려는 소프트웨어 개발자는 개발 시간을 1.5배에서 심지어 2배까지 예상해야 한다.
• 분야가 전문화 되어 있으므로 인터페이스 설계는 물론 인간공학 전문가를 참여 시켜야 할지 모른다.