Category Archives: 소프트웨어 공학의 사실과 오해

소프트웨어 개발 성과와 개인의 엔지니어의 역량과의 상관관계


소프트웨어 공학의 사실과 오해

Fact 02. (사람) ‘개인차’에 관한 연구에 따르면, 최상의 프로그래머는 최악의 프로그래머보다 28배 더 뛰어나다. 여기에 비례해서 이들에게 임금을 28배 주는 것이 아니라면, 이들은 소프트웨어 분야에서 가장 값싸고 훌륭한 자원이다.

(개인적 의견) 하루빨리 메이저 리그식의 연봉제가 필요하다…..고 생각한다…모두 계약직으로..ㅎ
참고: 궁극의 코드 카타

이 주제에 대해서는 오래된 참고문헌이 많다.

– 우리의 연구에서 가장 중요한 실질적 발견은 프로그래머 실무 능력의 현저한 개인차다(Sackman 1968). Sackman은 생산성 차이가 28배까지 달라질 수 있다는 것을 발견했다.

– 한 그룹 내에서도 프로그래머간의 능력차가 10배이상 날 수 있다(Scwartz 1968)

– 개인간에 5배 정도의 생산성 차이는 흔한 것이다. (Boehm 1975)

– 개인에 따라 성과는 엄청난 차이가 난다. 가령 두 사람은 단지 1개의 오류를 찾았지만 (1인당 0.5개), 다섯사람은 7개의 오류를 찾았다. (1인당 1.4개). 초급 프로그래머들에 대한 이런 차이는 잘 알려져 있었지만, 경험이 많은 사람들 사이에서도 그 차이가 크다는 것은 약간 놀라운 일이다.(Myers 1978)

Fact 03. (사람) 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 늦어진다.

직관적으로 생각하면,프로젝트 일정이 지연될 때 일정을 따라잡기 위해 투입인원을 늘려야 할 것 같다. 이번 사실은 이 직관이 틀렸다는 것을 말한다. 문제는 프로젝트에 인원이 투입되면 그들이 제 속도로 일하도록 하는데 많은 시간이 필요하다는 것이다. 새로운 인원은 생산성을 제대로 내기까지 많은 것을 배워야 한다. 그러나 더 중요한 것은 그들이 배워야 하는 것은 주로 프로젝트 팀 내의 다른 사람으로부터 얻어야 한다는 것이다. 그 결과 새로운 팀 멤버는 프로젝트에 뭔가를 기여하는데 매우 느릴 뿐 아니라 충분한 생산성을 내가 전까지는 기존 프로젝트 팀의 시간과 주의를 뺏는 요인이 된다.

게다가, 프로젝트에 사람이 많을 수록 커뮤니케이션은 더욱 복잡해진다. 따라서 프로젝트가 지연될 때 인력을 투입하면 프로젝트는 더 늦어지는 경향이 있다.

만약 애플리케이션 도메인에 대해 잘 알고 있다면 괜찮지 않을까?

McConnel(1999)에서 그는 (1) 이 사실을 무시하는 것은 실제로 흔한 일이며, (2) 이 사실은 쉽게 인지하고 피할 수 있는 제한된 상황에서만 유효하다는 점을 지적했다. 그러나 이 기본적인 사실에 반대하는 사람은 많지 않고, 지체된 프로젝트에 인원을 추가 투입할 경우 매우 신중해야 한다. 사실 어떤 프로젝트건(해당 프로젝트가 지체됐든 아니든 간에) 인원의 추가 투입에는 신중해야 한다. 관리자가 프로젝트 진행을 좀 더 빠르게 하고 싶을 때는 특히 이런 유혹을 많이 받는데, 이는 매우 위험하다.

McConnel, Steve 1999, “Brooks’ Law Replaced”

Fact 04. (사람) 작업환경은 생산성과 품질에 지대한 영향을 미친다.

소프트웨어 프로젝트에서는 가능한 최고의 사람들로 팀을 구성하고, 적절한 방법론을 적용하려 하고, 상당히 높은 수준의 SEI CMM 레벨에 해당하는 프로세스를 확립하여 가능한 빠르게 진행하려는 경향이 있다. 문제는 여기에 뭔가 중요한 것이 빠져 있다는 것이다. 바로 작업환경이다. 분석가가 분석을 하고, 설계자가 설계를 하고, 프로그래머가 프로그래밍을 하고, 테스터가 테스트를 할 때, 작업환경은 매우 중요하다.

간단히 말하자면, 소프트웨어 작업은 사고 집약적이므로, 작업환경은 생각을 촉진하는 곳이어야 한다. 사람이 붐벼서(의도적이든 그렇지 않든) 자꾸 방해를 받는다면 거의 일을 진행할 수 없게 된다.

얼마나 심할까? 이 문제를 집중적으로 다룬 책이 있다. 피플웨어(DeMacro and Lister 1999)는 상당한 분량을 할애하여 작업환경이 어떻게 어떤식으로 영향을 미치는지 설명한다. 이 책에서 저자들은 작업환경이 업무 효율에 얼마나 영향을 미치는지에 대한 조사결과를 설명한다. 그들은 프로젝트 팀 구성원을 모아서 상위 25%에 속하는 그룹과 하위 25%에 속하는 그룹으로 나누었다.(상위 25%에 속하는 그룹은 하위 25%에 속하는 그룹보다 업무 효율이 2.6배 뛰어났다) 그리고 각 그룹에 속한 사람들의 작업 환경을 조사했다. 상위 그룹에 속하는 사람들은 1.7배 넓은 공간에서 일했다. 상위 그룹 사람들은 작업 환경이 충분히 조용하다고 대답한 비율이 하위 그룹 사람들보다 2배 높았고, 개인적인 공간이라고 대단한 비율은 3배 이상 높았으며, 전화를 다른 곳으로 돌리거나 꺼 놓을 수 있다고 대답한 비율은 각각 4배와 5배 이상 많았다. 상위 그룹 사람들은 작업 중 다른 사람에 의해 불필요한 방해를 받는 비율이 하위 그룹의 절반에 불과했다.

Advertisements

소프트웨어 공학의 사실과 오해 – overview


소프트웨어 공학의 사실과 오해 overview

*사람(people)

  • 정말 중요한 것은 사람이다.
  • 어떤 사람은 다른 사람보다 놀라울 정도로 뛰어나다.
  • 많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다.

* 도구와 기술(결국은 보통 경영진이 선택하는)

  • 과대광고는 득보다 해가 된다.
  • 새로운 접근 방법으로 전환하면, 처음에는 효율이 향상되기보다 저하된다.
  • 최신의 도구나 기술이 실제로 사용되는 경우는 드물다.

*추정(estimation)

  • 우리의 추정은 부정확한 경우가 많다.
  • 추정 작업을 위한 프로세스 또한 형편없다
  • 이런 허술한 추정 목표를 달성하는데 실패한 것과, 이보다 훨씬 중요한 프로젝트의 실패를 동일시 한다.
  • 추정을 사이에 두고 경영진과 기술자 사이에 단절이 존재한다.

*재사용(reuse)

  • 우리는 오랫동안 재사용을 해왔다.
  • 최근 재사용은 거의 진전을 이루지 못했다
  • 일부 사람들은 재사용에 지나치게 큰 기대를 한다.

*복잡성(complexity)

  • 소프트웨어 구축의 많은 문제는 복잡성에 기인한다.
  • 복잡성은 매우 빠르게 증가한다.
  • 이 복잡성을 극복하기 위해서는 매우 뛰어난 사람들이 필요하다.

소프트웨어 재사용


출처: 소프트웨어 공학의 사실과 오해

Fact 16. (재사용) 모든 사람들이 대규모 재사용을 중요하고 바람직한 것이라 생각하지만, 거의 대부분의 문제가 해결되지 않은 채 남아있다.

출처

– IEEE Standard 1517, “Standard for Information Technology” 재사용 가능 컴포넌트 촉진 수단으로서 공학학회인 IEEE가 만들어낸 표준

– McClure, Carma 2001, “Software Reuse – A Standard Based Guide” IEEE 표준 적용 가이드

– Reifer, Donald J 1997, “Practice Software Reuse”

– Tracz 1995, “Confessions of a Used program salesman”

Fact 17. (재사용) 대규모 재사용은 서로 관련 있는 시스템 사이에서 가장 잘 적용되고 따라서 도메인 종속적이다. 이는 대규모 재사용의 잠재적 적용성을 축소시킨다.

여러 애플리케이션 도메인에서 사용될 수 있는 컴포넌트를 찾는 것은 거의 불가능할지 모르지만, 하나의 도메인 안에서라면 그 가능성은 상당히 높아진다. SEL의 항공 역학 도메인에서의 소프트웨어 구축 경험은 그 가능성을 특히 잘 보여주는 사례다.

-Bosch, Jan 2000. Design and Use of software architecture

-Jazayeri, Mehdi, 2000 “Software architecture for product families”

Fact 18. (재사용) 재사용에 대한 두 가지 ‘3의 법칙’이 있다. (1) 재사용 가능 컴포넌트를 만드는 것은 단일 목적의 컴포넌트를 만드는 것보다 세 배는 어렵다. (2) 컴포넌트는 재사용 라이브러리로 인정할 만큼 일반적이라 생각하기 전에 서로 다른 세 가지 애플리케이션에 적용해봐야 한다.

Fact 19. (재사용) 재사용된 코드를 수정할 경우에는 특히 오류를 범하기 쉽다. 만약 컴포넌트의 20~25%이상을 수정하고자 한다면 차라리 처음부터 다시 작성하는 것이 더 효율적/효과적이다.

여기서 가장 중요한 사실은 소프트웨어 오류와 소프트웨어 비용 추정에 대한 연구조사에서 밝혀졌다. NASA-Goddard의 SEL은 기존 코드를 수정하는 것이 새로운 버전을 새로 작성하는 것보다 비용 효율이 높은지에 대해 정밀 조사를 수행했다(McGarry et al. 1984, Thomas 1997) 그들이 알아낸 사실은 아주 명쾌하고 인상적이었다. 소프트웨어 시스템을 20~25% 또는 그 이상 수정해야 한다면 처음부터 다시 새로운 제품을 구축하는 것이 비용도 적게 들고 작업도 쉽다는 것이다. 사실, 그 퍼센트가 아주 낮다는 것은 놀라운 일이다.

– McGarry 1984, “An approach to Software Cost Estimation” NASA Software Engineering Laboratory, SEL-83-001

– Thomas 1997, “An anlaysis of Errors in a Reuse-Oriented Development Environment”