 |
|
◎ CTO : Chief Technical Officer. CTO는 기술자의 경력으로는 최고봉이다. 기술의 달인이라고 보면 된다. 국내 소프트웨어 회사에서 가장 잘못 이해되고 있는 용어이기도 하다. 국내 대부분의 회사에서 CTO는 엔지니어링 관리자에 가깝다.
◎ 프로젝트 관리자 (PM) : 소프트웨어 프로젝트의 모든 관리 업무를 책임지는 사람이다. 외부 팀과 인터페이스를 담당하고 의견을 조율한다. 내부의 개발팀을 외부의 폭풍으로부터 보호하는 역할도 한다.
◎ 프로젝트 리더 (PL) : 프로젝트 리더는 소프트웨어 프로젝트의 기술 분야를 책임지는 사람이다. 주된 업무는 설계와 구현이지만, 상황에 따라서는 요구 분석도 담당한다. 소프트웨어 프로젝트는 프로젝트 관리자의 책임이지만, 소프트웨어 자체는 프로젝트 리더의 작품이다.
◎ 매트릭스 조직 : 매트릭스 조직은 기능조직과 프로젝트 전담 조직의 특성을 혼합한 형태이다.
◎ Agile방법론 : 비즈니스 환경 및 소프트웨어 개발환경 등 주위변화를 빠르게 수용하고 능동적으로 대응하기 위해 탄생한 여러 가지 경량의 방법론을 통칭하는 말이다.
◎ 동료리뷰 : 동료리뷰는 가장 정착시키기 힘들면서 가장 효과가 큰 개발문화이다. 동료리뷰는 부정적인 의미를 갖는 '검토'보다 '의논'이라고 하는 것이 더 의미가 가깝다.
◎ 프로젝트관리자는 소프트웨어 프로젝트의 모든 관리 업무를 책임지는 사람이다. 외부 팀과 인터페이스를 담당하고 의견을 조율한다. 내부의 개발팀의 외부의 폭풍으로부터 보호하는 역할도 한다. 개발자가 외부와 자주 직접 대면을 하면 생산성이 급격히 떨어질 수 있다.
◎ 프로젝트리더는 소프트웨어 프로젝트의 기술 분야를 책임지는 사람이다. 주된 업무는 설계와 구현이지만, 상황에 따라서는 요구분석도 담당한다. 소프트웨어 프로젝트는 프로젝트관리자의 책임이지만, 소프트웨어 자체는 프로젝트리더의 작품이다.
◎ 테스터 팀을 QA팀이라고 부르고 테스터를 QA엔지니어라고 부르는 경우도 있다. QA는 프로젝트 전 과정에 걸쳐서 문서, 절차, 산출물에 대해 중간 과정을 점검하고 사후 검사를 실시하여 제품의 품질을 보장하는 모든 일련의 활동을 말한다.
테스터의 역할과 책임에는 다음과 같은 것들이 있다.
- 테스트 계획 수립 책임
- 테스트 케이스 작성에 대한 책임
- 테스트 실시
- 소프트웨어의 결함을 찾을 책임
◎ 빌드와 릴리즈는 흔히 그 전문성을 인식하지 못하고 있는 영역이지만, 대단히 전문적인 기술을 요하는 부분이며, 외부에서 표준 솔루션을 가져다가 회사에 그대로 사용할 수도 없는 부분이다. 각각의 회사에서 직접 연구하고 발전시켜야 할 부분이라는 얘기다.
소프트웨어 회사 초기에는 특정 개발자가 빌드와 릴리즈 업무를 겸할 수 있지만, 회사가 어느 정도 커지면 빌드와 릴리즈 업무를 분리하여 전문화해야 한다. 빌드와 릴리즈 업무를 전문화해야 개발 생산성이 높아진다고 생각해야 한다.
◎ 매트릭스 조직은 기능조직과 프로젝트 전담조직의 특성을 혼합한 형태이다. 약한 매트릭스 조직은 그 중에서도 기능조직의 특징을 많이 보이며, 프로젝트관리자가 단순한 조율자의 역할을 수행한다. 강한 매트릭스 조직은 프로젝트 전담 조직의 특성을 많이 띠며, 상당한 권한과 역할을 수행하는 프로젝트 전담 관리자가 배정된다. 중간 매트릭스 조직은 그 중간쯤에 해당한다.
◎ 많은 개발자들이 개발 방법론이나 프로세스에 대해 부정적으로 생각한다. 개발에 너무 많은 제약을 가함으로써 개발자의 창의성을 제약한다고 생각하기 때문이다. 꼭 틀린 생각이라고 볼 수만은 없다. 일반적인 경우, 초기에는 아무런 프로세스없이 주먹구구식으로 프로젝트를 진행하다가 갑작스럽게 융통성이 없는 프로세스를 도입하게 되는데, 이런 경우 과도한 절차에 의해서 프로젝트가 비효율적으로 흐르기 일쑤다. 경험이 많은 전문가의 가이드 없이 이론적으로 방법론이나 프로세스를 도입해서 바로 효과를 보기란 사실상 기적에 가깝다. 이런 나쁜 경험 때문에 프로세스에 대해 오해를 하게 된다. 그만큼 처음부터 효율적으로 적용하기가 어려운 것이 방법론과 프로세스다.
◎ 구조적 방법론은 정형화된 분석 절차에 따라 사용자의 요구 사항을 파악하여 문서화하는 체계적인 분석 이론에 바탕을 두고 있다. 1950년대에는 구조적이지 못한 무원칙의 개발 방식으로 개발자의 사고, 능력에 따라 개발되었으며 로직 구성 또한 개발자 중심이었다. 이에 따라서 개발 생산성 저하와 유지 보수의 어려움 등 문제점이 발생했으며 결국 소프트웨어의 위기를 불러왔다. 1960년대에는 GOTO문을 쓰지 말고 구조적으로 프로그래밍하자는 주장이 대두됨으로써 분석과 설계도 구조적으로 하자는 의견이 확대되었고 구조적 방법론의 틀이 완성되었다. 구조적 방법론에서는 프로그램의 로직을 중심으로 분석하고 도형중심의 분석도구를 이용한다.
◎ 객체지향 방법론은 이전의 방법론들이 실세계에 반영이 어렵고, 소프트웨어가 점점 대형화되고 복잡해져서 이를 해결하기 위하여 대두된 객체지향 기술을 적용한 것이다. 객체지향 기술을 요구분석 및 설계에 확대 적용하고, 객체를 중심으로 프로그래밍 구조를 단순화한다. 객체지향은 복잡한 매커니즘의 현실세계를 인간이 이해하는 방식으로 시스템에 적용한다. 객체지향 방법론은 모든 기본 단위를 데이터 중심에서 객체로 바꿨다. 객체들간의 상호작용은 메시지를 통해서만 이루어진다.
◎ 개발자의 노력의 결과는 수많은 사람들의 미래와 관련되어 있다. 따라서 개발자는 장기적인 관점으로 보는 일을 소홀히 해서는 안된다. 개발자가 단기적으로만 행동한다고 해도 금방 드러나지는 않는다. 그래서 그런 마음가짐을 갖는 것은 개발자의 윤리이기도 하다. 개발자가 이를 지키는 것은 개발자의 역량이기도 하다. 단기적인 이슈에 치이게 되면 자칫 장기적인 관점을 잃기 쉬운데, 장기적인 관점을 갖는 것은 꾸준한 경험과 훈련이 필요한 일이니 부단히 노력해야 한다.
구현 단계 이끌기
ㅇ 프로젝트의 업무 정의
기본 설계와 설계의 무결성에 대한 책임
구현 일정 산정을 주도
구조적 방법론
요구사항
'테스트 관련 서적' 카테고리의 다른 글
| 소프트웨어 테스트 실무 가이드 - 단위간 상호 연동 검증 (0) | 2018.09.18 |
|---|---|
| 소프트웨어 개발의 모든 것 - SRS, 폭포수 모델 (0) | 2018.09.17 |
| 소프트웨어 개발의 모든 것 - 기반시스템 (0) | 2018.09.15 |
| 소프트웨어 개발과 테스트 - 통합테스트 (0) | 2018.09.14 |
| 소프트웨어 개발과 테스트 - 결함 관리 (0) | 2018.09.13 |
