제안서 프로세스
1️⃣ 정보 수집, 분석 및 가설 설정
2️⃣ 요구사항 정리
3️⃣ 인터뷰 및 가설 검증
Economics, Management, IT
✔️프로세스 그룹
1. 시작(Initiating)
2. 계획(Planning)
3. 실행(Executing)
4. 모니터링/통제(Monitoring and Controlling)
5. 종료(Closing)
✔️지식 영역
1. 프로젝트 통합관리(Integration)
2. 프로젝트 범위관리(Scope)
3. 프로젝트 시간 관리(Schedule)
4. 프로젝트 비용관리(Cost)
5. 프로젝트 품질관리(Quality)
6. 프로젝트 자원관리(Resource)
7. 프로젝트 의사소통 관리(Communication)
8. 프로젝트 위험관리(Risk)
9. 프로젝트 조달관리(Procurement)
10. 프로젝트 이해관계자 관리(Stakeholder)
✔️ 프로젝트 관리 과정 그룹 및 지식 영역
✔️ 프로젝트 성과
♾️ Agile 방법론
: 기존의 예측적 방법론들과는 달리 반복적, 적응적인 접근 방식을 강조한 것으로 이는 빠른 변화와 불확실성이 많은 프로젝트에 적합하다는 평이며 Scrum, Kan ban, Extreme Programming 등이 대표적인데 다음과 같은 특징이 있다.
– 반복 주기: 프로젝트를 여러 개 짧은 주기로 나누어 진행, 각 주기는 실행, 검토, 조정 등의 단계 포함
– 고객 중심: 고객 요구사항을 최우선으로 요구사항이 변경될 수 있는 가능성을 열고 유연하게 대응
– 자기조직화 팀: 팀원들 간 협력으로 문제를 해결하고 프로젝트 목표를 달성하기 위해 자력으로 조직화
– 반복적 검토와 개선: 각 반복 주기의 끝에서 프로젝트 결과물 검토, 필요한 개선 반영
– 유연성/적응성: 프로젝트 특성 및 요구사항에 따라 최적의 접근 방식 선택, 높은 프로젝트 성공률 확보
– 통합적 관리: Agile과 예측적 방법론 통합, 프로젝트를 효율적으로 관리하고 이해관계자들과의 의사소통 개선
– 자원 활용 최적화: 각 프로젝트에 가장 부합하는 방법론 선택, 자원의 효율화 추구
: 프로젝트의 목표와 요구 사항을 분석하고 이해한다. 이를 위해 이해당사자들과의 의사소통, 현장 조사, 문서 검토 등을 수행하여 요구 사항을 명확히 이해하고 프로젝트의 고유한 요소를 파악한다.
✅ 방법론 선택
: 요구 사항 분석을 토대로 조정이 필요한 영역을 파악하고 이에 따른 방법론을 선택한다. 이는 기준이 되는 표준 방법론에서 일부 요소를 선택하거나 다른 방법론을 조합할 수도 있다.
✅ 프로세스 조정
: 방법론을 조직과 프로젝트에 맞게 조정한다. 이 과정에는 수명주기 단계 추가 또는 제거, 프로세스 세부 조정, 가이드라인과 절차 수정 등이 포함될 수 있다.
✅ 도구와 기술 선택
: 조정된 방법론에 맞는 도구와 기술을 선택한다. 프로젝트에 필요한 특정 기능을 구현하기 위해 특정 개발 도구나 프레임워크를 도입할 수도 있다. 어느 하나를 끝까지 고수할 필요는 없다.
✅ 팀 구성원 역할 및 책임 조정
: 조정된 방법론에 따라 팀 구성원의 역할과 책임을 조정한다. 팀 구성원은 방법론에 맞게 업무를 수행해야 하고 원활한 의사소통과 협업을 진행해야 한다. 팀원들의 역량과 역할에 따라 재조정 또는 새로운 역할을 부여할 수 있다.
✅ 프로젝트 관리 및 모니터링
: Tailoring 된 방법론으로 프로젝트를 관리, 모니터링한다. 이는 일정 관리, 리스크 관리, 품질 관리, 의사소통 관리 등을 포함으로써 프로젝트 진척 상황을 주기적으로 검토하고 필요한 조정을 수행하여 프로젝트 목표 달성을 보장한다.
✅ 지속적 개선
: 고유한 사업적 요구 사항과 제약 조건을 가진 조직은 Tailoring으로 인하여 조직 내 체계를 활성화하고 조직에 맞는 색깔을 찾아 입힐 수 있다. 이에 따라 살아 움직이는 조직으로 보다 유연한 관리가 가능하다.
✔️ 자원 최적화
: 프로젝트 규모와 복잡성에 따라 초기 계획을 지속 관리하고 필요한 자원과 비용을 효과적으로 조절할 수 있다. 즉, 불필요한 자원의 집행을 사전에 확인, 관리할 수 있는 역량을 갖추어 비용과 시간을 절감할 수 있다.
✔️ 프로젝트 성공
PMO의 여러 형태와 유무를 떠나 중요한 한 가지는 일정, 비용, 품질, 위험 등의 측면에서 프로젝트 관리를 개선함에 그 역할과 책임이 있다. PMO는 업무를 전략적 목표에 맞추는 데 있어 이해당사자들의 참여와 협업, 인재 개발, 프로젝트 투자 가치 실현 등 많은 역할을 수행한다.
🚩 계획 활동, 위험 관리, 프로젝트 성과 추적 및 활동을 위한 프로젝트 지원 서비스를 제공한다. 이러한 서비스는 프로젝트에 대한 보다 직접적인 관리를 유지하고 지원을 원하는 독립적이거나 다양한 사업 단위가 있는 조직에서 활용한다.
🚩 평면적이고 고객 중심적인 접근 방식을 갖춘 조직에는 ACoE(Agile Center of Excellence) 이나 VDO(Value Delivery Office) 형태의 조직을 제언할 수 있다. 이들은 관리 감독 기능이 아닌 지원 멘토링 중심의 역할을 수행한다.
🚩 성과 지향 역량 확보
프로젝트 관리 기능을 전문적으로 육성한다. 이를 통해 내외부 조직의 여러 이해당사자에 대한 평가를 진행하며 품질의 결과를 신속하고 효과적으로 생성하기 위해 프로젝트의 고유한 특징들을 바탕으로 성과가 더 나올 수 있도록 한다.
🚩 지속적 개선과 변경 관리
정기적인 프로젝트 결과를 공유한다. 이로써 프로젝트에서 얻은 귀중한 지식을 전파하며 참여한 팀원들에 대한 깊이 있는 학습 및 공유 활동으로 역량을 개선한다. 또한 세심한 변경 관리로 프로세스 업데이트, 기능 향상 및 프로젝트 관리를 지원하는 새로운 기술과의 연계를 구축하고 유지한다.
기업환경은 큰 불확실성, 빠른 변화, 더 치열해진 경쟁 구도, 더 많은 권한을 가진 고객으로 조직이 점점 더 복잡해지는 환경에서 기업가치를 창출해야 하는 어려움에 직면해 있다. 이는 수행되고 있거나 계획된 모든 프로젝트에 많은 영향을 끼치며 PMO를 통한 환경개척과 성공적 프로젝트를 위한 차별화된 변화를 원한다. 그에 따라 PMO도 변화를 해야 한다.
🚩 중요 동기 집중
프로젝트 동기는 조직과 프로젝트의 미래, 이해당사자와의 관계 및 역량에 상당한 영향을 미칠 수 있다. 이에 PMO는 그 역할이 관리 감독에서 의사소통을 조율하는 것으로 바뀌고 있다. 이러한 변화는 중요한 전략적 대응에 영향을 미칠 수 있는 프로젝트 성과, 위협 및 기회에 대한 정확한 통찰력을 제공하고 새로운 문제에 대한 명확성과 진로 수정을 촉진하고 사업적 결과를 최대한 실현한다.
🚩 효과적 프로세스 구축
PMO는 낭비적인 단계를 추가하거나 가치 창출 프로세스를 무시하지 않고도 효과적인 의사소통과 협업, 지속적인 개선을 가능하게 하는 충분한 프로세스 및 관행 규칙을 설정하여 조직의 역량을 적절하게 조정한다. 여기에는 퍼실리테이터 중심의 조직화가 필요하고 명확한 R&R을 수행하도록 적극 지원한다.
🚩 핵심 인재 역량
재능 있는 팀원을 모집하고 유지하는 데 보다 적극적인 역할을 수행한다. 인력은 프로젝트를 성공으로 이끄는 가장 중요한 요소 중 하나로 프로젝트 및 조직 전체에서 기술, 전략, 관리 및 리더십 기술을 개발하고 육성한다. 이렇게 길러진 인력은 핵심 인재가 되고 인력풀에서 중장기적으로 관리하고 자산화한다.
🚩 변화 장려
조직의 경쟁 차별화 요소로서 조직의 성과 및 변화 관리에 대한 지원을 부족하지 않게 한다. 이는 모든 구성원에 대한 효과적인 동기부여이자 조직이 살아 움직일 수 있는 근간을 제시하고 그 맨 앞에 PMO가 서 있다. 이를 위해 다양한 이벤트와 정량적, 정성적 활동을 통해 관리 프로세스를 유기적으로 연계한다.
소프트웨어 개발에 있어 요구분석 단계는 중요하고도 어려운 단계이다. 많은 정보가 수집되어야 하며 의사소통의 어려움도 극복해야 하는 숙제 중 하나다. 이러한 작업을 증명하기 위한 방법은 매우 다양하다. 그중 프로세스 사이의 데이터 흐름을 파악하여 요구사항과 시스템을 파악하는 방법으로 구조적 분석이 있다. 구조적 분석(Structural Analysis)은 시스템의 기능적 요구사항을 구조화하고 조직화하는 단계이다. 이를 통해 요구사항 간의 관련성과 의존성을 이해하고 분해된 요구 모듈 간 관계를 분석하여 시스템의 구조를 설계할 수 있다. 구조적 분석은 데이터 흐름 다이어그램(DFD), 상태 전이 다이어그램, 클래스 다이어그램 등의 모델링 기법을 활용하여 수행된다. 전통적 방법으로서 이 단계에서는 요구사항이 어떻게 상호작용하고 구성되는지를 시각화하여 파악한다.
소프트웨어 개발 프로젝트 초기 단계부터 요구사항을 명확하게 이해하고 효과적으로 관리할 수 있는 구조적 분석은 궁극적으로 프로젝트의 성공 확률을 높일 수 있다. 이 방법은 크게 다음과 같은 단계로 수행되고 여기에 쓰이는 도구도 확인한다.
구조적 분석의 세부적인 과정은 크게 4단계로 나눠볼 수 있다.
시스템에 대한 요구사항을 수집하고 구조화 및 문서화한다. 이 요구사항은 고객, 사용자, 도메인 전문가 등과의 인터뷰, 설문조사, 관찰 등 다양한 방법으로 얻을 수 있으며 최종적으로 기능적 요구사항(시스템이 수행해야 하는 작업)과 비기능적 요구사항(성능, 안전성, 보안 등)으로 구분될 수 있다. 이 과정을 통해 모호한 내용을 명확히 하고 요구사항 간의 관련성과 의존성을 파악, 중복되거나 충돌하는 요구사항을 논리적 블록으로 그룹화, 해결한다.
명세화된 요구사항을 기반으로 소프트웨어의 핵심 문제를 파악하고 분석할 수 있는 구조로 정리한다. 이때 데이터 흐름도(DFD), 자료사전, 프로세스 명세 등의 도구를 활용한다.
– 주요 프로세스 식별: 수집된 요구사항을 기반으로 시스템 내의 주요 기능적 프로세스 식별하며 DFD로 표현 (시스템의 입력, 출력, 처리 과정 포함)
– 데이터 흐름 식별: 프로세스 간에 주고받는 데이터(정보) 흐름 식별
– 데이터 저장소 식별: 시스템 내 사용되는 데이터 저장소를 식별하는데 이는 데이터의 정의, 속성, 구조 등을 포함하고 이를 데이터 요소 간의 관계와 종속성을 파악
분석된 요구사항이 사용자의 기대와 일치하는지 검증하여 문제가 없는지 확인하는 단계로 사용자와 지속적인 의사소통으로 유스케이스 테스트나 프로토타입 방식을 사용하여 실제 사용자의 반응을 수집할 수 있다. 특히 요구사항과 부합하며 일관성 있는 모델을 구축하는 것이 중요한데 이 결과를 바탕으로 소프트웨어의 전체적인 아키텍처를 설계할 수 있다. 특히 모듈화, 계층화, 컴포넌트 구조 등을 고려하여 시스템 구조를 결정한다.
– 0레벨 DFD 작성: 주요 프로세스, 데이터 흐름, 데이터 저장소 등을 기반으로 0레벨 DFD를 작성하며 이 다이어그램은 시스템의 전체 구조를 보여주고 각 프로세스와 데이터 흐름의 관계를 가시화
– 상세화: 0레벨 DFD를 기반으로 더 상세한 1레벨 DFD를 작성하여 프로세스를 세분화하고 데이터 흐름을 더욱 구체적으로 표현
– 유효성 검사: 작성한 DFD를 검토, 논리적 오류나 모순점이 있는지 확인
작성한 DFD를 문서화하여 요구사항 명세서나 설계 문서에 포함한다. 이에 개발팀 간 의사소통을 원활하게 하고 시스템 구조를 이해하는 데 도움을 준다. 요구사항이 변경되거나 갱신이 되면 요구사항 관리를 통해 변경된 요구사항에 따른 작업의 우선순위를 조정하고 추적 관리한다. 이 문서들은 개발 및 테스트 과정에서 참고 자료로 활용한다. 다시 말해 문서화와 의사소통의 중요성은 각기 다음과 같다.
“소프트웨어가 소수의 탁월한 능력을 갖춘 프로그래머에 의해 만들어지던 규모를 넘어서면서 소프트웨어 개발의 성패는 그 집단의 소프트웨어공학에 대한 숙달 정도에 크게 좌우된다.”
소프트웨어 공학의 첫 등장은 1968년 NATO가 지원한 한 콘퍼런스에서 시작되어 꽤 오랜 시간이 흘렀다. 이는 컴퓨터 소프트웨어 개발, 운영, 및 유지 보수에 관련된 체계적이고 표준화된 접근법에 대한 연구와 적용 기술로 이해된다. 이를 통해 고품질의 소프트웨어를 생산하고 시간과 비용을 최소화하며 고객과 사용자 요구사항을 충족하는 것이다.
그 결과물들은 공학적 원칙과 가이드라인으로 신뢰성, 확장성, 효율성, 보안성 및 사용성의 향상을 기대한다. 그래서 생명체와 같은 생명주기를 바탕으로 여러 기법, 도구 및 방법론이 고안되고 쓰이고 있다. 하지만 학문적 공학의 위치는 실제 현장에서 일하는 개발자들에게는 다소 생경하다. 이는 급변하는 IT 환경, 수요 대비 공급을 원활히 할 수 없는 교육적 생태계, 개발인력에 대한 대우 및 여러 편견 등으로 눈앞에 급한 불만 끄면 된다는 식의 대응에만 몰두한 결과이다.
현실은 현장에서 체득되는 지식도 있지만 학문적 고찰을 통한 지식과 지혜가 없이는 원하는 성과를 만들어낼 수 없다. 이는 수많은 무기를 지니고는 있으나 정작 아무런 전략, 전술도 세우지 않고 무작정 전장에 나서는 장수와 다를 바가 없다. 이제 개발자들은 모두 다시금 소프트웨어 공학을 찬찬히 살펴봐야 할 이유가 여기에 있다.
무엇을 시작하든 제일 중요한 것은 “용어”를 제대로 알고 이해하는 것이다. 같은 용어라도 장소와 시간, 쓰임새 및 사람에 따라 모두 다를 수 있기 때문에 가장 먼저 다뤄야 할 용어를 정의하고 눈높이를 맞춰야 한다.
✔️ 프로그램
: 프로그래밍 언어로 작성된 source code (정적)
✔️ 소프트웨어
: 프로그램(source code)과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체, 즉 산출물, 사용자 매뉴얼 등 모든 것을 포함한 것 (동적)
✔️ 시스템
: 필요한 기능을 실현하기 위해 관련 요소들을 어떠한 법칙에 따라 조합한 집합체
시스템은 모든 것은 포괄하며 소프트웨어도 시스템 내에서 다른 요소들과 상호 동작하는 하나의 시스템으로 볼 수 있다. 이러한 시스템의 기능과 성능이 잘 발휘되려면 시스템을 구성하는 모든 요소, 서브 시스템이 잘 작동되어야 한다. 즉, 제대로 만들어져야 하는데 소프트웨어의 경우 눈에 보이지 않는 비가시성과 복잡성을 모두 가지고 있다.
물리적인 하드웨어는 눈부시게 발전하면서 구체적인 성과들을 보여주는데 소프트웨어는 그렇지 못하다. 그러다 보니 소프트웨어를 등한시하게 되었으나 하드웨어를 작동시키는 것이 소프트웨어임을, 그 수요가 하드웨어 못지않게 폭발하면서 수많은 수요를 따라가지 못하게 되었고 여기서 소프트웨어 위기라는 것이 발생한다.
이러한 위기는 소프트웨어가 가지는 비가시성과 복잡성을 포함한 또 다른 특징이 있는데 첫 번째. 소프트웨어는 제조가 아닌 개발이라는 것이다. 제조와 개발이 비슷해 보이지만 가장 큰 차이는 제조는 능력별 결과물의 차이가 거의 없지만 개발은 개인의 능력이 매우 중요시되고 그 능력에 따라 결과물의 차이가 크게 난다는 것이다. 둘째. 소프트웨어는 소모되는 것이 아니라 품질이 떨어진다는 것이다. 소프트웨어는 소모성 상품이 아니다. 다만 계속 사용됨으로써 지속적인 사용자의 요구사항을 반영해야 하는데 이것이 여러 사유로 원활하지 않다면 품질은 자연히 떨어지게 되는 것이다. 셋째. 소프트웨어 관리 기술이 전체가 아닌 일부만 사용된다. 즉 개발 프로젝트에서 활용하는 관리지식체계(PMBOK)가 있는데 이를 필요한 부분만 일부 적용함으로써 그 효과를 제대로 보지 못하는 것이다.
✔️ 소프트웨어 위기
: 소프트웨어 생산성에 대한 심각한 인식
소프트웨어 위기는 생산성 외에도 많은 문제점을 가지고 있었다. 소프트웨어 개발 프로젝트는 예산을 초과하기 일쑤이고 개발일정의 지연도 반복되었다. 중요한 소프트웨어 개발에 필요한 개발자는 각자 가지고 있는 역량의 편차로 그 결과물의 수준을 예측 할 수가 없었으며 이는 결국 품질문제로 비화되었다. 다른 공산품과 달리 불량품에 대한 관리나 품질보증에 대한 정량적 개념이 부족했고 고객은 인도된 결과물을 신뢰할 수 없었다. 이러한 상황에서 문제를 재인식하고 타계하고자 하는 노력으로 공학적 접근이 대두되었다.
✔️ 공학
: 기술적 문제를 발견하고 기술적 해결책을 제시하는 학문으로 과학적이고 잘 조직된 지식을 현실적인 문제해결에 체계적으로 적용하는 것
공학의 특성은 자연과학하고 다르며 여러 제약사항이 있는데 우선 기간이 정해져 있고 예산도 정해져 있다는 것이다. 이러한 조건 하에서는 결국 최종적으로 기간을 얼마나 단축하고 보다 적은 비용으로 가능할 수 있는가에 대한 과학적 해법을 마련하는 것이다. 이 관점에서 소프트웨어를 개발하는 과정에서, 공학에서 쓰이고 있는 원리들을 적용하여 개발을 해보겠다는 것이 소프트웨어 공학이라고 볼 수 있다. 보다 효율적인 개발을 통한 생산성을 높이고 품질 좋은 소프트웨어를 제작하려는 것이 소프트웨어 공학의 취지이자 목적이다.
✔️ 소프트웨어 공학
: 소프트웨어 개발에 필요한 이론이나 기술, 도구들에 관하여 연구하는 학문
다시 말해 소프트웨어 공학은 “품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞춰 제대로 개발하는 것”을 말한다. 이러한 품질과 생산성 두마리 토끼를 모두 잡아야 하는 소프트웨어 공학은 방법, 도구, 프로세스 및 페러다임을 가지고 있다. 이는 소프트웨어 개발을 위해 생명주기를 통한 단계별 방법들을 연구하고 효율성과 효과성을 획득하기 위한 적절한 도구의 사용, 사용자 요구사항에 맞게 개발하기 위한 절차와 단계들, 그리고 상황에 맞게 적용가능하고 유연한 철학이 그것이다.
✔️ 방법: 어떤 결과를 생성하기 위해서 적용하는 기법과 절차
✔️ 도구: 더 좋은 방법으로 작업하기 위한 기기 또는 자동화된 시스템
✔️ 프로세스: 도구와 기법을 사용하여 작업하는 순서
✔️ 패러다임: 개발 스타일
이러한 4가지 요소를 바탕으로 소프트웨어는 유기체와 같은 생명주기를 갖는데 이는 계획 단계, 분석 단계, 설계 단계, 구현, 테스트, 유지 보수하는 과정으로 소프트웨어 개발 과정에서의 생산성을 향상시키고 품질 좋은 소프트웨어를 생산하여 고객을 만족시키려고 하는 최종적인 목표에 방점을 찍는다. 생명주기 내 각 단계는 일련의 활동을 포함하며 전체 소프트웨어 프로젝트에 대한 계획과 관리를 수행하고 개발 과정의 체계적인 구조화와 일정 관리를 지원한다.
✔️ 소프트웨어 생명주기(Software Development Life Cycle)
: 소프트웨어 제품 개발에서 시작하여 최종 사용자에게 배포되고, 유지 보수 및 폐기될 때까지의 전 과정으로 일반적인 작업단계는 다음과 같다.
– 요구분석: 고객과 사용자의 요구와 기대를 조사하여 프로젝트 목표를 정의
– 설계: 소프트웨어 기능, 구조, 데이터 흐름, 인터페이스 등을 결정
– 구현(개발): 설계 문서를 토대로 소프트웨어 코드 작성
– 테스트: 생길 수 있는 오류와 결함을 찾아내고 수정
– 배포: 개발된 소프트웨어를 최종 사용자에게 전달, 설치하여 사용할 수 있도록 함
– 유지보수: 소프트웨어가 효율적으로 동작하도록 지속적으로 업데이트하고 개선
– 폐기: 소프트웨어 수명이 끝난 경우, 안전하게 제거하고 관련 데이터와 자원을 처리
※ SWEBOK(Software Engineering Body of Knowledge)
: ISO/IEC 국제 표준화 기구와 IEEE(Institute of Electrical and Electronics Engineers)가 승인, 지원하고 전 세계 소프트웨어 전문가들이 협력하여 개발한 소프트웨어 공학 관련 전문 지식의 체계적 모음으로 소프트웨어 공학자들이 필요로 하는 기본 원칙, 개념, 기술 및 실천 방법을 포괄한다. 여기서 다루는 다양한 주제와 영역은 SDLC의 여러 단계에 지침을 제공하고 이는 소프트웨어 개발 및 관리의 범위와 효율성을 높이는 데 도움이 되며 소프트웨어 개발자에게 필요한 기술, 능력 및 전문적 역량을 개발하는 데 중요한 역할을 한다.
※ PMBOK(Project Management Body of Knowledge)
: 프로젝트관리협회(PMI:Project Management Institute)에서 개발한, 프로젝트 관리에 관한 전문 지식의 체계적 모음으로 ‘프로젝트관리지식체계’라고 하며 PM과 팀원들이 프로젝트를 계획, 실행, 통제하고 성과를 평가하는 데 필요한 일련의 표준 및 가이드라인을 제공한다. 이를 통해 프로젝트를 실천하면 프로젝트의 성공 가능성을 높이고 리스크를 최소화하는 데 도움을 준다.