공공 프로젝트(SI) 분석 단계: 분석 단계의 이해와 핵심 산출물, 찐으로 파헤치기! (PM 필독!)

공공 프로젝트(SI) 분석 단계: 분석 단계의 이해와 핵심 산출물, 찐으로 파헤치기! (PM 필독!)

안녕하세요! 여러분의 든든한 수다쟁이 PM입니다! 👋

오늘은 소프트웨어 개발 프로젝트의 성공과 실패를 가르는 가장 중요한 초기 단계 중 하나인 '분석 단계'와 이 단계에서 PM이 반드시 챙겨야 할 '핵심 산출물'에 대해 이야기해보려 합니다. 분석 단계에서 가장 중요한 산출물을 꼽으라면 당연히 '요구사항 정의서' 이지만, 단순히 요구사항 정의서만 중요한 게 아니라는 사실! 🧐 현행 시스템 분석부터 개발 표준, 용어 사전, 그리고 WBS까지! 현직 PM의 경험과 공공 가이드라인을 싹 다 갈아 넣어 찐으로 도움이 되는 꿀팁을 전수해 드릴게요! 이 글을 통해 여러분은 다음 내용을 얻어가실 수 있을 거예요.

• 분석 단계가 왜 중요한지
• 분석 단계에서 PM이 챙겨야 할 핵심 활동들
• 분석 단계의 필수 핵심 산출물 6가지 완벽 해부 (요구사항 정의서부터 용어 사전, WBS까지!)
  • 요구사항 정의서
  • 현행 시스템 분석서 (또는 현황 분석 관련 문서)
  • 과업 대비표
  • 개발 표준 정의서
  • 용어 사전
  • WBS

그럼, 바로 시작해볼까요? 🚀

---

[용어 정리 - 아래의 용어들은 알고 계셔야 합니다!]

• 분석 단계 (Analysis Phase): 소프트웨어 개발 프로젝트에서 시스템이 무엇을 해야 할지, 사용자의 요구사항과 기능을 명확하게 식별하고 정의하는 초기 단계입니다.
• 요구사항 정의서 (Requirements Definition Document, RDD): 사용자의 필요와 목표를 이해하고, 시스템이 수행해야 할 기능 및 비기능적 요구사항을 문서화하는 과정이며, 도출된 모든 요구사항을 구체적이고 상세하게 기술한 공식 문서입니다. 프로젝트의 청사진 역할을 합니다.
• 기능 요구사항 (Functional Requirements): 요구사항 중 시스템이 특정 작업을 수행해야 하는 방식이나, 시스템이 사용자에게 제공해야 하는 기능에 대한 요구사항입니다. (예: 로그인 기능, 데이터 조회 기능)
• 비기능 요구사항 (Non-Functional Requirements): 요구사항 중 시스템의 품질 특성이나 제약사항에 대한 요구사항입니다. (예: 성능, 보안, 사용성, 유지보수성 등)
• 개인정보 보호법: 개인정보의 처리 및 보호에 관한 사항을 규정하여 개인의 자유와 권리를 보호하고, 개인정보의 효율적 활용을 도모하는 법률입니다.
• PMS (Project Management System): 프로젝트의 계획, 실행, 모니터링, 통제 등 전반적인 관리를 지원하는 시스템입니다.
• 과업 대비표: 사업 과업 내용이 각 단계별 산출물에 얼마나 충실히 반영되었는지 비교하고 확인하는 문서입니다.
• 개발 표준 정의서: 소프트웨어 개발 전반에 걸쳐 일관된 품질과 효율성을 확보하고, 보안 취약점을 예방하기 위한 기준과 절차를 명시한 문서입니다.
• 용어 사전: 프로젝트 내에서 사용되는 모든 용어에 대한 명확하고 통일된 정의를 제공하여 혼란을 방지하고 의사소통을 돕는 문서입니다.
• WBS (Work Breakdown Structure): 프로젝트의 전체 작업을 계층적으로 분해하여 관리하기 쉽게 만드는 도구입니다. 프로젝트 목표를 달성하기 위한 모든 작업을 세부적으로 정의하고 조직화하여 효율적인 계획, 실행, 통제 및 관리를 가능하게 합니다.

---

1. 분석 단계, 왜 중요할까요?

소프트웨어 개발은 마치 튼튼하고 멋진 건축물을 짓는 것과 같습니다. 고객의 요구에 맞는 멋진 건축물을 짓기 위해서는 먼저 고객이 생각하는 청사진을 제대로 이해해야 합니다. RFP상의 글자로 된 내용만 가지고는 고객의 상상력을 모두 이해하기 어렵습니다. RFP를 여러 사람이 나누어서 작성한 경우라면 더욱 관련 담당자들과의 인터뷰를 통해 고객의 니즈를 명확하게 듣고 정리하는 단계가 필요합니다.

이 단계는 프로젝트의 목표와 사용자의 필요를 명확히 정의하고, 시스템이 무엇을 해야 할지 꼼꼼하게 식별하는 시기입니다. 만약 여기서 오류가 생기거나, 나중에 "아! 그거 아니고 이거였는데!" 하고 요구사항이 변경되면 어떻게 될까요? 상상만 해도 끔찍한 일이 벌어집니다.

• 💸 비용 폭탄 주의보: 공공정보화사업_단계별_사업관리가이드(2023.2)에서도 강조하듯이, 개발 초기에 발생한 오류는 나중에 고치려면 '수십 배'의 비용 폭탄으로 돌아올 수 있습니다. 실제로 구현 단계에서는 분석/설계 단계 대비 5배, 심지어 제품 출시 후에는 30배까지 추가 비용이 발생할 수 있다고 하니, 지갑 사수를 위해서라도 분석 단계는 꼼꼼해야 합니다!
• 🔒 보안의 첫 단추: 개발 후에 "보안이 엉망인데?"라는 소리를 듣고 싶지 않다면, 바로 이 분석 단계에서부터 보안 요구사항을 빡!세게 정의하고 설계에 반영해야 합니다. 처음부터 튼튼한 보안 설계를 하지 않으면, 나중에 아무리 좋은 보안 솔루션을 갖다 붙여도 밑 빠진 독에 물 붓기가 될 수 있어요! (소프트웨어_개발보안_가이드(2021.12.29)에서도 분석/설계 단계 보안의 중요성을 강조합니다.)

결국 분석 단계는 '미리미리 준비하고, 꼼꼼하게 확인해서, 나중에 터질 문제를 예방하는 PM의 현명한 선제 대응'이라고 할 수 있습니다! 💡

---

2. 분석 단계에서 수행해야 할 주요 활동들 (PM의 체크리스트!)

분석 단계는 단순히 문서를 쓰는 것을 넘어, 다양한 이해관계자들과 소통하고 정보를 정제하는 치열한 과정의 연속입니다. PM이 반드시 챙겨야 할 핵심 활동들을 살펴볼까요?

• 👥 인터뷰 계획 수립 및 실시:
  • 사업단(수행사)은 인터뷰 대상을 선정하고, 어떤 질문을 할지 '인터뷰 계획'을 수립합니다. (마치 형사가 사건의 실마리를 찾듯이!)
  • 운영 관련 부서(발주기관)와 '친밀하지만 날카로운' 인터뷰를 진행하여, 시스템 구현에 필요한 사용자 요구사항을 '숨김없이' 도출해내야 합니다. 이 인터뷰 활동이 바로 우리 프로젝트의 방향을 잡아주는 핵심입니다.
• 🔍 요구사항 분석 및 현행 시스템 분석 (정보의 바다에서 보물찾기!):
  • 인터뷰에서 얻은 정보와 함께, 기존 업무 문서 자료(시스템 기본 계획서, 과업 지시서, 예산 계획서 등)를 '독심술하듯이' 분석합니다. 이 단계에서 흩어진 조각들을 맞춰 시스템의 큰 그림을 그려야 해요.
  • 현행 시스템의 문제점, 개선 방향, 기존 시스템과의 연계/대체 방안을 명확히 파악하는 것이 중요합니다. (기존 데이터 관리 체계, 데이터 구조, 시스템 아키텍처 개요 등을 분석합니다.)
• ✍️ 요구사항 정의서 작성 및 검토 (드디어 청사진 그리기!):
  • 분석된 요구사항들을 바탕으로 '요구사항 정의서'라는 프로젝트의 청사진을 작성합니다. (이때부터 PM의 어깨가 무거워지기 시작하죠...!)
  • 사업단이 작성한 정의서를 운영 관련 부서(발주기관)가 '매의 눈으로' 검토하고, 쌍방 합의를 통해 확정합니다. "이대로 만들면 되는 거죠?" 하고 확인 도장 쾅! 받아야 합니다!
• 📝 수집된 요구사항 관리 (흩어진 보석을 한 곳에!):
  • 프로젝트내에 PMS 가 있다면, 수집된 요구사항들은 '프로젝트 관리 시스템(PMS)'에 빠짐없이 등록하여 체계적으로 관리해야 합니다.
  • 만약 PMS에 기존 사업 요구사항이 있다면, 우리 프로젝트에 맞춰 '상세화'하고 '맵핑'해서 등록하는 센스!
• 🚨 보안 항목 식별 및 개발 표준 정의 (숨어있는 위협 찾기 & 길라잡이 만들기!):
  • 처리 대상 정보와 이를 처리하는 기능에 적용되어야 하는 보안 항목들을 '탐정처럼' 식별합니다. 권한을 가진 사용자만이 안전하게 정보를 수집, 전송, 처리, 보관, 폐기할 수 있도록 하는 것이 목표입니다.
  • 기관 내부 정책자료(개인정보 보호 규정, 정보보안 관련 규정)와 외부 정책자료(개인정보 보호법, 정보통신망법, 금융거래법 등)를 '족보 삼아' 철저하게 검토하여 보안 항목을 놓치지 말아야 합니다.
  • 소프트웨어 개발 방법론 선정, 웹 표준 준수, 소프트웨어 개발 보안(암호화 기준, 오류 처리 등), 공공 데이터베이스 표준, 코딩 스타일 등 **개발 전반에 걸친 '개발 표준 정의서'**를 마련하여 일관된 품질과 보안을 확보해야 합니다.
• 📊 개념/논리/물리 데이터 모델 도출 및 데이터 관리 방안 수립 (데이터의 뼈대 세우기!):
  • 신규 시스템의 경우 개발 방법론과 연계하여 주제 영역, 개념 데이터 모델, 논리 데이터 모델, 물리 데이터 모델을 '설계도 그리듯이' 도출해야 합니다. 데이터의 뼈대가 튼튼해야 시스템이 안정적이죠!
  • 데이터 중복을 최소화하고, 구조적 일관성을 확보하도록 데이터 구조 설계 및 검증 계획을 반영하고, 데이터 이관 및 값 검증 방안, 데이터 품질 관리 체계 수립, 메타데이터 등록 및 현행화 요구 등 종합적인 데이터 관리 방안을 제시해야 합니다.
• 📚 용어 사전 구축 (소통의 혼란 막기!):
  • 프로젝트 내에서 사용되는 모든 용어에 대한 명확하고 통일된 정의를 제공하여 이해관계자 간의 혼란을 방지하고, 정확한 의사소통을 돕기 위한 '용어 사전'을 구축해야 합니다. 표준 용어/단어, 이음동의어, 금칙어, 엔터티 및 속성 설명 등을 포함합니다.
• 🤝 이해관계자 참여 및 합의 (모두가 같은 배를 타야죠!):
  • 개발팀, 사용자, 발주처 등 모든 이해관계자들의 적극적인 참여를 유도하고, 도출된 요구사항과 산출물에 대해 명확한 합의를 이끌어내야 합니다. 이는 나중에 발생할 수 있는 오해와 갈등을 최소화하는 데 필수적입니다.

---

3. 분석 단계의 핵심 산출물 완전 정복 (PM의 무기들!)

소프트웨어 개발 프로젝트의 분석 단계에서는 프로젝트의 성공적인 수행을 위해 다양한 핵심 산출물들이 정의되고 활용됩니다. 이 문서들은 프로젝트의 방향을 정립하고, 잠재적인 문제를 조기에 발견하며, 개발 전 과정의 품질을 보증하는 데 필수적인 역할을 수행합니다. 각 산출물이 상호 유기적으로 연결되어 프로젝트의 투명성과 성공 가능성을 높이는 데 기여합니다.

3.1. 요구사항 정의서 (Requirements Definition Document, RDD)

• 목적: 개발될 시스템이 무엇을 해야 하는지, 어떤 기능을 제공해야 하는지, 그리고 어떤 제약 조건이 있는지 등을 명확하고 상세하게 기술하여 이해관계자 간의 의사소통 기반을 마련하고 향후 개발 및 테스트의 기준이 됩니다.
• 주요 내용:
  • 요구사항명: 도출된 요구사항을 요약하는 명칭을 기입합니다.
  • 구분: 기능 요구사항, 성능 요구사항, 품질 요구사항, 인터페이스 요구사항, 데이터 요구사항, 운영 요구사항, 제약사항 등으로 분류하여 기술합니다.
  • 요구사항 설명: 사용자 요구사항을 구체적이고 상세하게 기술합니다. 기능 요구사항의 경우, 외부 입력, 외부 조회, 외부 출력 등의 트랜잭션 기능과 관련된 입출력 정보 및 데이터 기능을 상세히 포함할 수 있습니다.
  • 요구사항 출처: 요구사항이 제시된 문서의 번호와 문서명을 기록하여 추적성을 확보합니다.
  • 제약사항: 요구사항이 수행되기 위해 필요한 법적 또는 기술적 조건을 기술합니다.
  • 중요도: 해당 요구사항이 전체 시스템 구현에 미치는 중요도를 상, 중, 하 등으로 표시합니다.
  • 검수 기준: 요구사항 구현의 품질을 정량적 또는 정성적으로 측정할 수 있는 기준을 제시합니다.
  • 해결 방안: 요구사항을 구현하기 위한 구체적인 해결 방안을 기재할 수 있습니다.
• 관련 활동 및 주체: 사업단이 요구사항 정의서를 작성하고, 운영 관련 부서에서 이를 검토합니다. 감리 시에도 요구사항 정의서의 과업 내용 반영 여부를 점검합니다.

3.2. 현행 시스템 분석서 (또는 현황 분석 관련 문서)

• 목적: 기존 시스템의 문제점을 파악하고, 개선 방향을 제시하며, 새로운 시스템이 기존 시스템과 어떻게 연계되거나 대체될지 이해하는 기반을 제공합니다. 비록 "현행시스템 분석서"라는 명시적인 문서명은 없지만, 관련 활동과 산출물들이 이를 대체하거나 포함하는 형태로 나타납니다.
• 주요 내용:
  • 데이터 관리체계 현황 분석: 현행 표준, 구조, 값, 연계 등 데이터 핵심 요소의 지속적인 관리를 위한 현황을 분석합니다.
  • 데이터 구조 현황 분석: 기존 시스템의 데이터 구조 현황을 분석하여 개선 방향 및 개선 과제를 도출합니다. 신규 시스템의 경우 생략될 수도 있습니다.
  • 시스템 아키텍처 개요: 응용 소프트웨어와 상호작용하는 환경 및 네트워크를 포함한 시스템 아키텍처에 대한 이해를 바탕으로 합니다.
• 관련 활동 및 주체: 사업단은 인터뷰를 실시하고 요구사항을 분석하여 현행 시스템의 문제점을 파악하는 데 활용합니다.

3.3. WBS (Work Breakdown Structure)

• 목적: 프로젝트의 모든 작업을 계층적으로 구조화하여 가시화하고, 각 작업의 범위, 일정, 책임, 자원 등을 명확히 정의하여 효율적인 계획, 실행, 통제 및 관리를 가능하게 합니다.
• 주요 내용:
  • 프로젝트의 최상위 목표를 시작으로, 주요 단계(Phase) 또는 주요 인도물(Deliverable) 단위로 작업을 분해합니다.
  • 각 단계를 다시 구성 요소(Component) 또는 작업 패키지(Work Package)로 세분화합니다.
  • 가장 하위 레벨의 작업은 개별 담당자가 수행할 수 있는 수준으로 구체화됩니다.
  • 각 작업에 대한 책임, 소요 시간, 필요한 자원, 예상 비용 등을 포함할 수 있습니다.
  • 일반적으로 숫자 또는 영문 알파벳으로 계층 구조를 나타냅니다 (예: 1.0, 1.1, 1.1.1).
• 관련 활동 및 주체: PM, PL, 팀원들이 함께 참여하여 WBS를 작성합니다. 착수단계에서부터 고객으로부터 가장 급하게 요구되는 문서입니다. 프로젝트를 진행하며, 각 단계별로 업무와 일정을 구체화하며 문서를 업데이트 해나가야 합니다. 분석 단계에는 아직 상세화된 계획을 도출할 수 없으므로, 각 단계별 대략적인 일정으로 계획함녀 됩니다. 프로젝트 진행 중 변경사항 발생 시 WBS도 함께 업데이트하여 관리해야 합니다. WBS는 일정 계획(Gantt Chart), 자원 배정, 비용 추정 등의 기초 자료로 활용됩니다.

3.4. 과업 대비표

• 목적: 사업의 과업 내용(RFP)이 제대로 반영되었는지 비교하고 확인하는 도구입니다. 주로 요구 정의 단계(분석 단계) 감리 단계에서 활용되며, 세부 검사 항목별로 적합/부적합 판정을 내리는 데 사용됩니다.
• 주요 내용: 과업 내용(RFP)을 기준으로 제안서와 사업수행계획서에 얼마나 충실하게 반영되었는지에 대한 비교 및 확인 내용을 담습니다.
• 관련 활동 및 주체: 요구 정의 단계(분석 단계) 감리 및 설계 단계 감리 시 사업자가 제출하고 발주자가 확인합니다. 요구사항 정의서와 통합하여 관리할 수 있습니다.

3.5. 개발 표준 정의서

• 목적: 소프트웨어 개발 전반에 걸쳐 일관된 품질과 효율성을 확보하고, 보안 취약점을 사전에 방지하기 위한 기준과 절차를 명시합니다.
• 주요 내용:
  • 소프트웨어 개발 방법론: 프로젝트의 특성에 맞는 방법론(예: 폭포수 모델, 애자일, 프로토타입 모델, 린 개발 등)을 선정하고, 이에 따른 절차, 기법 활용 방안, 제출 산출물의 종류 및 시기 등을 기술합니다.
  • 웹 표준 준수: 웹 브라우저만으로 서비스 구축이 가능하도록 웹 표준 기술 사용 및 품질 관리에 대한 지침을 포함합니다.
  • 소프트웨어 개발 보안: 소프트웨어 보안 약점(취약점)을 제거하고, 보안을 고려하여 기능을 설계 및 구현하는 일련의 보안 활동에 대한 규정을 따릅니다. 여기에는 보안 취약점 진단 및 조치, 암호화 기준, 중요 정보 저장 및 전송 방법, 에러 처리, 세션 통제 등에 대한 설계 및 구현 기준이 포함됩니다.
  • 공공 데이터베이스 표준: 공공기관의 데이터베이스 표준화 지침을 준수하여 데이터 표준화 방향 및 목표, 표준화 대상, 범위, 추진 과제 등을 정의하고 적용합니다. 이는 표준 용어, 도메인, 코드 등의 정의 및 적용 여부를 포함합니다.
  • 코딩 스타일 정의: 소스코드 수준의 안정성 확보를 위해 표준 코딩 스타일을 정의하고 준수합니다.
• 관련 활동 및 주체: 사업단은 SW 개발 방법론 테일러링을 수행하며, 사업자는 개발표준 정의서를 포함한 사업수행계획서를 제출하고 주관기관의 승인을 받아야 합니다.

3.6. 용어 사전

• 목적: 프로젝트에 사용되는 모든 용어에 대한 명확하고 통일된 정의를 제공하여 이해관계자 간의 혼란을 방지하고, 정확한 의사소통을 돕습니다.
• 주요 내용:
  • 주요 용어 정의: 사업 추진과 관련된 핵심 용어들을 선정하고 정의합니다.
  • 표준 용어/단어 정의: 공공데이터베이스 표준화에 따라 표준 용어, 표준 단어, 표준 도메인 등에 대한 정의를 포함합니다. 여기에는 이음동의어(유사한 의미를 가진 단어) 목록 및 금칙어(사용 금지어) 목록 관리도 포함될 수 있습니다.
  • 엔터티 및 속성 설명: 데이터베이스 엔터티 및 속성에 대한 상세 설명을 포함하여 용어의 의미를 명확히 합니다.
• 관련 활동 및 주체: 사업계획서 작성 시 사업 내용의 일부로 용어 정의가 포함됩니다. 행정안전부와 같은 기관은 공통 표준 용어를 제정하고 관리합니다.

---

4. 단계말 검토

각 단계가 완료되면, 산출물에 대한 철저한 점검이 이루어져야 합니다. 산출물은 1차로 각 파트의 PL, 2차로 품질 담당자(QA), 3차로 PM이 검토한 이후에 고객에게 검토 요청을 합니다. 이제부터 요구사항의 변경이 발생하는 모든 것은 비용이 발생하게 되니 각 단계별로 필히 "고객의 승인"을 공식화하는 것이 중요합니다.(물론 고객들은 승인하는 것을 엄청 꺼려 합니다. 승인을 얻어내는 다양한 노하우는 추후에 따로 공개할게요~ ;>)

• ✅ 품질 점검: 품질 담당자(QA)는 품질(보증) 관리 계획에 있는 품질 목표 달성, 측정 지표, 체크리스트 등 점검 기준과 기법을 바탕으로 각 단계 및 작업별 산출물에 대해 점검을 수행해야 합니다.
• 🛠️ 결함 조치: 점검 결과 결함 및 오류가 발견되면, 조치 계획을 수립하고 재점검을 통해 '완벽해질 때까지' 보완해야 합니다.

---

<오늘의 수다쟁이 PM Tip>

자, 여러분! 우리 PM들의 심장을 쫄깃하게 만드는 '분석 단계'는 제안서 쓰고, 기술 협상까지 마친 후에 고객과 업무를 최종적으로 '조정할 수 있는' 마지막 기회랍니다! 🚨 여기서 정신 바짝 차려야 해요!

각각의 요구사항에 대해 고객과 꼼꼼히 인터뷰하고 리스트업 한 다음에는, 여기에 들어갈 '공수' (얼마나 사람이 필요한지), '일정', '범위', 그리고 '비용'을 객관적으로, 그리고 냉정하게 따져봐야 해요. 이걸 대충 넘기면 나중에 큰코다칩니다!

당연히 PM 혼자서 '나 홀로 산정'할 수 있는 부분이 절대 아니겠죠? 😂 각 파트의 PL들, 그리고 본사 담당자들까지 모든 이해관계자들과 똘똘 뭉쳐서 이 비용과 일정을 명확하게 합의하고 계획해야 합니다. 아시죠? 대부분의 프로젝트가 산으로 가는... 아니, 실패하는 프로젝트는 바로 이 시점, 즉 '제대로 된 산정을 하지 못해서' 시작되는 경우가 태반이랍니다! (PM의 눈물 주의보... 😭)

그리고 우리 프로젝트의 또 다른 핵심 무기, WBS(Work Breakdown Structure)! 만약 여러분이 프로젝트 관리 시스템(PMS)을 쓰고 있다면, 그 안에 있는 WBS 기능을 활용하는 게 가장 깔끔하고 좋아요!

만약 별도의 도구가 필요하다면, 물론 JIRA나 Microsoft Project 같은 유료 툴들이 강력하죠. 하지만 '비용의 여유가 없는데 온라인 서비스를 써보고 싶다!' 하시면, redmine에 예쁜 스킨과 유용한 플러그인을 적용해서 써보는 것도 괜찮은 방법이에요. ✨ 다만, 공공기관 프로젝트에서는 아직도 '고객과의 소통'을 위해 '엑셀'을 많이 쓴다는 현실! 특히 매크로가 잘 적용된 엑셀 WBS는 정말 만능이랍니다!

그래서 품질 관리(QA)나 사업 관리(PMO)를 오래 해오신 베테랑 PM님들은 본인만의 '마법 같은 매크로 엑셀 WBS'를 보물처럼 간직하고 계신 경우가 많아요. 🤫

자, 그럼 수다쟁이 PM의 찐 추천템 나갑니다! 저는 바로 아래의 XLGantt를 강력 추천해요! 👍 Microsoft Project 부럽지 않은 강력한 매크로 기능들이 일정 계획부터 관리까지, 모든 것을 '완벽하게' 편리하게 만들어줍니다. 그리고 무엇보다... 감사하게도! 무료! 라구요! 💸 이 정도면 무조건 써봐야죠? 😉

XLGantt - Project Scheduler 바로가기

---

<수다쟁이 PM의 AI 활용 꿀팁!>

각 문서의 초안, 그리고 요구사항 정의서의 "구현(수행)방안" 등 문서와 글쓰기에 약한 수행팀에게는 상당한 난제입니다. 이 때 AI 도구를 '든든한 조력자'로 활용해 보세요!

RFP, 전자정부지원사업 사업관리매뉴얼, 공공정보화사업 단계별 사업관리 가이드, 소프트웨어 개발보안 가이드 같은 두꺼운 PDF 문서들을 싹 다 올려두고 궁금한 점을 질문해 보세요!

• "전자정부표준프레임워크 기반의 개발 표준 정의서를 작성해줘!"
• "RFP 의 SFR-001 에 대해 자세히 설명해주고, 상세구현 방안의 초안을 작성해줘, 그리고, 주의해야 할 점도 알려줘"
• "요구사항 정의서 작성 시 가장 중요한 보안 항목은 무엇인가요?"
• "데이터 표준화와 관련하여 공공기관이 준수해야 할 법규가 있나요?"
• "각 요구사항 유형별로 포함되어야 할 구체적인 내용은 어떤 것들이 있을까요?"
• "개발 표준 정의서 작성 시 고려해야 할 최신 개발 방법론에는 어떤 것들이 있나요?"

AI가 해당 문서들에서 관련 내용을 찾아 요약해주니, 일일이 페이지를 넘겨가며 정보를 찾을 필요가 없습니다. 덕분에 PM은 정보 탐색 시간을 아끼고, 본연의 '분석'과 '의사결정'에 더욱 집중할 수 있게 된답니다! 똑똑한 AI와 함께라면 분석 단계도 거뜬합니다! 🦾

---

[다음 글에서는...]

오늘 우리는 소프트웨어 개발 프로젝트의 핵심 출발점, '분석 단계'와 '요구사항 정의', 그리고 중요한 '핵심 산출물'들의 모든 것을 파헤쳐 봤습니다. 다음 글에서는 드디어! 정의된 요구사항을 바탕으로 시스템의 뼈대와 살을 붙여나가는 '설계 단계'에 대해 심층적으로 다뤄볼 예정입니다. 아키텍처 설계부터 기능 설계, 데이터베이스 설계, 그리고 보안 설계까지! PM이 알아야 할 설계 단계의 모든 꿀팁을 기대해주세요! 😉

 

XLGantt(엑셀간트) | 엑셀 일정관리 (5.0.0 버전) 2022.06.05 릴리즈

 

XLGantt(엑셀간트) | 엑셀 일정관리 (5.0.0 버전) 2022.06.05 릴리즈