1부 논쟁의 전장


David Parnas

paper: (1985) Software aspects of strategic defense systems

“우리는 소프트웨어 신뢰성을 보장하는 방법을 알지 못한다.”

그렇다면 소프트웨어 시스템이 명세를 만족하는지 여부를 수학적으로 증명하는 정확성 증명은 어떠한가?

“거대한 소프트웨어에서 아주 작은 부분이라도 확실하게 정확성을 증명하기란 불가능하다고 생각한다. 설령 그런 증명이 있다 하더라도 어떻게 해석할지 모른다”

“하드웨어와 입력 데이터에 알지 못하는 오류가 존재하는 상황에서 프로그램의 정확성을 입증할 수 있는 기술은 없다”

소프트웨어 생산성을 비약적으로 향상시킬 계기는 무엇일까?

언어나 도구가 아니다.

자동 프로그래밍 방법론도 아니다.

소프트웨어 정형검증도 아니다.

인공지능도 아니다.

Brooks

no silver bullet

극적인 생산성 향상 방법

1. 차라리 개발하지 말고 구매해라.(명언이군 ㅎㅎ)

2. 점진적으로 소프트웨어를 제작하라

3. 뛰어난 소프트웨어 설계는 뛰어난 설계자로부터 나온다(격하게 공감. 하수 1000명이 있어봤자 초고수 1명을 당해내지 못한다.) 창의적인 소프트웨어 인재를 고용하고 양성하라. 브룩스는 인재 양성 방법으로

  • (가장 숙련된 사람이 반드시 최고는 아니라는 사실을 염두에 두고) 가능한 이른 시기에 최고 설계자를 가려내기
  • 최고 기대주에게 경력 조언자 붙이기
  • 개인별로 경력 개발 계획과 경력 파일을 만들어서 관리하기
  • 상호 소통을 통해 서로 자극이 되는 만남의 기회를 제공하기

모든 인적자원에 대해 career에 대한 경력관리를 해야 하는데 그것을 하려면 내가 블로그에서 자주 언급했던 그 “tech-tree”가 어떻게 되는지를 알아야 한다. 수비수가 되면서 공격수가 되고 싶어하는 바보같은 짓은 하지 말아야 한다. 예전에 비해서 그러한 경력 설계에 대한 그림이 보다 선명해졌다. 앞으로 계속 좋아질 것이라 생각함..

가장 뛰어나고 명석한 두뇌들이 내놓은 보고서

“향후 10년동안 소프트웨어 생산성, 안정성, 적시성을 10배이상 향상시킬 기술적 발전은 눈씻고 찾아봐도 없다”

“업계 실무에서 최고수준과 평균 수준이 이렇게 차이가 나는 분야는 거이 없다”

“진짜 문제는 기술이 아니다. 오늘날 정말로 심각한 문제는 관리다.”

관리다.

관리다.

관리다.

….

관리 못하는 관리자가 많다는 말로 들린다.

  • 시스템분석에 관하여 보고서는 소프트웨어 개발에서 요구사항 정의가 가장 어려운 부분이라고 지적한다.

위험관리

1. 프로젝트에서 최고 위험 10가지를 식별

2. 각 위험별로 대처방안을 세운다.

3. 매달 최고 위험 목록, 대처방안, 점수 수정

4. 월간 프로젝트 검토 회의에서 위험 상태를 점검

5. 적절한 조치를 취한다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중