NASA의 소프트웨어 공학 연구소 (SEL: Software Engineering Laboratory) 에서 “Recommended Approach to Software Development” 를 통하여 소프트웨어 개발 성공요소를 4가지 핵심요소, 9가지 해야 할 일, 8가지 해서는 안될 일로 정리하였다.
복잡한
임베디드 소프트웨어를 주로 개발하는 조직에서 정리한 자료이지만 대부분 우리의 소프트웨어 프로젝트에 그대로 활용이 가능한 내용이다. 문제의 본질은 새로운 것보다는 제대로 이해하고 실행하느냐 여부이다. 새로운
것에 대한 환상과 신기루를 쫓지 말고, 기본에 충실하면서 말보다는 실행하는 것이 프로젝트 성공의 지름길이다.
소프트웨어 개발 성공을 위한 핵심 (keys to
software development success)
1.
환경을 이해한다.
ü 프로젝트나 조직의 방법론을
정의하고 테일러링 하기 전에, 문제의 본질, 인력의 한계
및 역량, 소프트웨어, 하드웨어를 결정한다.
ü 공수, 규모, 개발 일정, 소스코드
증가, 소프트웨어 변경 및 오류 그리고 컴퓨터 사용량 등 지표를 수집한다.
프로젝트에서 방법론을 테일러링할
때 업무 (domain), 투입인력, 적용 기술, 공수, 규모 등을 이해하지 못한 상태에서 방법론 전문가가 테일러링하고
있지 않는지? 그렇다면 방법론을 제대로 테일러링할 수 있는 것인가? 프로젝트의
테일러링하여 작성한 프로젝트 계획은 현실성이 부족할 수 밖에 없다.
2.
프로세스를 환경과 맞춘다.
ü 프로젝트 계획을 수립하거나
표준 방법론을 정의할 경우 투입 인력, 환경 그리고 업무 영역에 대한 이해를 바탕으로 소프트웨어 프로세스를
선택하고 테일러링한다.
ü 표준이나 절차를 강제화할
의도가 없거나 강제화할 수 없으면 계획에 포함시키지 말아라.
ü 데이터 수집, 분석, 리포팅은 개발 방법론의 핵심이다.
3.
프로세스를 지속적으로 개선한다.
ü 개선 대상을 선정하고, 새로운 기법 또는 프로세스를 적용하고, 결과를 측정한다.
ü 각각의 변경이 상호 영향을
미치지 않도록 많은 것을 한번에 변경하지 않는다.
ü 모든 변경이 개선을 가져오지는
않는다. 시도해보고 필요할 때는 물러서라.
4.
지나치게 새로운 기술을 사용하지
마라.
ü 표준에 대한 사소한 개선은
조직간에 쉽게 공유할 수 있으나, 중요한 개선은 주의하여야 한다.
ü 다른 경우에 성공하였다고
기술을 선정하고 시도하지 마라. 기술 도입에 따른 위험은 개별 환경에 따라 다르다.
프로젝트 성공을 위해 해야 할 9가지 (nine DOs for project success)
1.
소프트웨어 개발 계획을 수립하고
계획에 따라 수행한다.
ü 비전, 조직, 방법론, 견적, 주요 마일스톤, 진척도 측정을 위한 기준 등.
ü 매 단계 말에 지속적으로
점검하고 보완한다.
2.
프로젝트 팀원의 역량을 강화한다.
ü 명확한 작업 할당, 적절한 권한 부여, 프로젝트 목적과 제약사항 공유, 방법론과 표준 제공 그리고 미준수 표준에 대한 이유 설명 등.
3.
관료화를 최소화 한다.
ü 관리, 회의 및 문서 작성 최소화
4.
요구사항 베이스라인을 정의하고, 요구사항 변경을 관리한다.
ü 요구사항을 기능하면 조기에
안정화한다.
ü 확정되지 않은 요구사항에
대한 상세 목록을 관리하고, 우선순위를 부여하여 관리한다. 담당자를
선정하여 적시 해결을 위하여 진척도를 관리한다.
ü 요구사항 변경에 따른 비용과
일정 영향을 견적하고, 문서화한다.
ü 상세설계가 끝나기 전에 모든
요구사항 이슈를 해결한다.
5.
주기적으로 프로젝트 진척도를
점검하고, 필요하면 계획을 변경한다.
ü 계획 대비 그리고 과거 유사한
프로젝트 대비 진척도를 주기적으로 점검한다.
ü 일정이 많이 지연되었으면, 계획을 다시 수립한다.
ü 프로젝트 목적과 제약사항에
따라 인력, 일정, 범위를 조정한다. 필요할 경우 개발 범위를 줄이는 것을 주저하지 마라.
ü 비현실적으로 낙관하지 마라.
6.
시스템 규모, 인월 (man month), 일정을 주기적으로 재견적한다.
ü 프로젝트를 진행하면서 요구사항이
상세화 되고 변경됨에 따라 규모와 규모에 따른 프로젝트 복잡성이 구체화되고, 개발팀 구성도 바뀐다.
ü 이전 견적과 계획을 무리하게
지키려 하지 말고, 새롭고 구체화된 정보를 확보하는 매 단계 말에 재견적을 통하여 계획을 조정한다.
ü 개발팀이 시스템 규모를 너무
적게 또는 생산성을 너무 높게 견적했다고 해서 잘못된 것은 아니다.
ü 문제는 견적의 정확성을 주기적으로
점검하지 않고 프로젝트의 진척도에 따라 견적을 조정하지 않는 것이다.
ü 범위, 규모, 일정은 월 단위로 재견적하는 것을 원칙으로 한다.
7.
단계별 마일스톤을 정의하고, 관리한다.
ü 단계가 끝나기 몇 주전에
다음 단계에 대한 준비를 하여, 프로젝트 구성원이 무난하게 다음 단계로 진입하게 한다.
8.
팀 워크를 제고한다.
ü 프로젝트는 다양한 조직, 회사로부터 참여한 인원으로 구성된다. 프로젝트 구성원간 공통사항을
최대화하고, 차이점을 최소화한다.
ü 각 개인과 팀의 역할을 프로젝트
차원에서 명확히 한다. 교차 교육과 합동 미팅을 활성화 한다.
ü 모든 구성원이 동일한 규칙을
따르게 한다.
ü 팀을 망치는 어느 개인도
성공하지 못하고, 팀의 성공에 기여하는 어떠한 개인도 실패하지 않는다.
9.
소수의 고참 (senior) 만으로 프로젝트를 시작한다.
ü 프로젝트를 이끌어 갈 소수의
경험을 가진 고참과 함께 프로젝트를 시작한다.
ü 나머지 팀원이 참여하기 전에
프로젝트 추진 방안, 우선순위, 조직, 일정 등 프로젝트 계획을 수립한다.
프로젝트 성공을 위해 해서는 안될 8가지 (eight DON'Ts for project success)
1.
팀원이 체계적이지 않은 방법으로
일하게 하지 마라.
ü 소프트웨어 개발은 저비용으로
신뢰할 수 있고, 고품질의 소프트웨어를 개발하는 예술이 아니므로, 정의된
원칙, 방법, 프랙티스, 기법을
체계적으로 적용한다.
ü 사용하는 방법론을 이해하고
어떻게 적용할지를 알고 있는지 확인한다.
ü 필요한 방법과 기법에 대한
교육을 실시한다.
2.
비 현실적인 목표를 세우지
마라.
ü 비현실적인 목표는 세우지
않는 것 보다 못하다. 마찬가지로 프로젝트 팀원에게 불가능한 약속을 하게 하는 것은 바람직하지 않다. 이러한 행동은 프로젝트 사기를 저하시킨다.
ü 합리적이고 도전적인 목표와
일정을 가진 팀과 함께 일한다. 하나의 성공은 다른 성공을 가져 오고,
프로젝트 초기에 구체적이고 달성 가능한 목표 설정은 계속적인 성공을 담보한다.
3.
영향을 평가하고, 변경위원회의 승인을 얻지 않고 변경하지 마라.
ü 프로젝트에서 감내할 수 있더라도
모든 요구사항 변경에 대하여 비용과 일정을 견적한다. 사소한 변경도 전체 기간 동안에 누적 관리한다.
ü 예산과 일정에 따라 우선순위를
설정하고, 변경 요청자와 대안을 검토한다.
4.
요구되지 않는 것을 개발하지
마라.
ü 개발자는 종종 추가적인 작은
기능 또는 변경이 주관적으로 시스템을 좋게 만든다고 여긴다. 이러한 사소한 변경이 축적되면 일정 지연을
가져 올 수 있고, 승인된 설계를 벗어나서 요구사항을 만족시키지 못할 수도 있다.
5.
프로젝트 초기에 너무 많은
인력을 투입하지 마라.
ü 개발자가 일할 준비가 됐을
때 투입한다. 초기에 프로젝트 방향성을 결정하고, 조직을
구성하는 것은 고참이 적임자이다.
ü 팀의 전문성을 정확히 알기가
쉽지 않지만 프로젝트를 잘 진행할 수 있는 적임자를 확보한다.
6.
프로젝트 진행 중 지연을
나중에 만회할 수 있다고 가정하지 마라.
ü 관리자와 지나치게 낙관적인
개발자는 단계 후반부에 더 생산적일 것이라고 가정하는 경향이 있다.
ü 프로세스가 더 순차적으로
진되는 개발 후반부 단계에서는 팀 생산성은 눈에 뛰게 높아지지 않는다.
ü 마찬가지로 뒤늦게 설계하거나
코딩한 부분이 시스템의 다른 부분보다 낮은 통합을 필요로 한다고 가정하면 안 된다. 개발자의 작업 품질이
초기보다 더 높아지지는 않는다.
7.
비용 절감 또는 일정 단축을
위해 표준을 완화하지 마라.
ü 산출물의 품질을 낮추면 생명주기
후반부에 더 많은 재작업을 초래한다.
ü 그리고 개발팀에 품질보다는
납기가 더 중요하다는 잘 못된 신호를 보낸다.
8.
많은 문서가 성공을 보장한다고
생각하지 마라.
ü 매 단계를 시작하기 위해
필요한 공식적인 문서는 없다.
댓글 없음:
댓글 쓰기