소개: 소프트웨어 프로젝트의 관리 프로세스에 대해 관련 담당자에게 학습시킵니다. 다음은 여러분이 읽고 참고할 수 있도록 제가 수집한 소프트웨어 프로젝트 관리 프로세스입니다.
1. 위험 평가
소프트웨어 프로젝트 위험은 비용 예산, 개발 진행 상황, 기술적 어려움, 경제적 타당성, 안전 관리 및 전체 프로젝트 주기에 관련된 문제 및 기타 측면을 의미합니다. 프로젝트에 미치는 영향. 프로젝트의 위험은 실현 가능성에 반비례합니다. 실현 가능성이 높을수록 위험은 낮아집니다. 소프트웨어 프로젝트의 타당성은 경제성, 사업적 타당성, 기술적 타당성, 법적 타당성 등 4가지 측면으로 나누어진다. 소프트웨어 프로젝트 위험은 제품 규모 위험, 요구 위험, 상관 관계 위험, 관리 위험, 보안 위험의 6가지 측면으로 나뉩니다.
1 ?제품 규모 위험
위험은 정비례합니다. 일반적으로 제품의 규모가 클수록 문제가 더 두드러집니다. 특히, 제품 규모 추정 방법, 재사용 소프트웨어 양, 수요 변화량 등의 요소는 제품 리스크와 밀접한 관련이 있습니다.
(1) 제품 규모 추정 방법
p>
(2 )? 제품 크기 추정에 대한 신뢰도
(3) 이전 제품 크기 평균과의 편차
(4) 사용자 수 제품
(5) ? 재사용되는 소프트웨어의 양
(6) 제품 요구 사항의 변경 정도
2. 요구 사항 위험
많은 프로젝트에서 요구 사항을 결정하고 있습니다. 우리는 항상 불확실성에 직면해 있습니다. 이러한 불확실성이 프로젝트 초기에 용인되고 프로젝트가 진행되면서 해결되지 않으면 이러한 문제는 프로젝트 성공에 큰 위협이 될 것입니다. 요구 사항과 관련된 위험 요소를 제어하지 않으면 잘못된 제품을 생산하거나 의도한 제품을 제대로 구축하지 못할 위험이 높습니다. 각 상황은 제품에 치명적일 수 있습니다. 이러한 위험 요소는 다음과 같습니다.
(1) 제품에 대한 명확한 이해 부족
(2) 제품에 대한 수요 인식 부족
p>
(3) ?수요 분석 과정에 고객 참여 부족
(4) ?우선 수요 없음
(5) ?불확실성으로 인해 수요가 새로운 것으로 이어짐 시장
(6) ?지속적으로 변화하는 수요
(7) ?효과적인 수요 변화 관리 프로세스 부족
(8) ?올바른 수요 변화 관련성 부족 분석 등
3. 관련성 위험
많은 위험은 프로젝트의 외부 환경이나 요인의 상관관계로 인해 발생합니다. 외부 관련 위험을 통제하기 위해 완화 전략에는 보조 리소스 또는 공동 작업 리소스에서 필요한 구성 요소를 확보하고 외부 환경과 관련된 잠재적인 문제를 감지하기 위한 가능한 계획이 포함되어야 합니다.
(1) 고객 공급 품목 또는 정보
(2) 구성원 상호 작용 또는 그룹 간 의존성
(3) 내부 또는 외부 하청업체 관계
(4) ?숙련된 인력의 가용성
(5) ?프로젝트 재사용성
4. ?기술적 위험
소프트웨어 기술의 급속한 발전과 숙련된 직원의 부족은 프로젝트 팀이 성공에 영향을 미칠 수 있음을 의미합니다. 기술적인 이유로 인해 프로젝트가 중단되었습니다. 교육, 컨설턴트 채용, 프로젝트 팀에 적합한 인재 채용 등 위험 영역을 해결하려면 초기에 위험을 식별하고 적절한 예방 조치를 취하는 것이 중요합니다.
기술과 관련하여 주로 다음과 같은 위험 요소가 있습니다.
(1) 교육 부족
(2) 방법, 도구 및 기술에 대한 이해 부족
( 3) ?응용분야 경험 부족
(4) ?신기술 적용 및 개발방법에 익숙하지 않음
5. ?리스크 관리
관리 문제로 인해 많은 프로젝트의 성공이 제한되지만 모든 관리 활동이 위험 관리 계획에 포함되지는 않는다는 사실에 놀라지 마십시오. 대부분의 프로젝트에서 프로젝트 관리자는 프로젝트 위험 관리 계획을 작성하는 사람인 경우가 많습니다. 그들은 자신의 실수를 스스로 감지할 수 없다는 선천적 결함을 갖고 있습니다. 따라서 프로젝트 성공이 더욱 어려워집니다. 이러한 까다로운 문제가 정면으로 해결되지 않으면 프로젝트 중 어느 단계에서 프로젝트 자체에 영향을 미칠 가능성이 높습니다. 프로젝트 추적 프로세스를 정의하고 프로젝트 역할과 책임을 명확히 하면 다음과 같은 위험 요소를 처리할 수 있습니다.
(1) ? 계획 및 작업 정의가 부족함
(2) ? 실제 프로젝트 현황을 파악하지 못함
(3) ?프로젝트 소유자와 의사결정권자를 구분할 수 없음
(4) ?비현실적인 약속
(5 ) ? 직원과의 완전한 의사소통 부족
6. ?보안 위험
소프트웨어 제품 자체는 창의적인 제품이므로 제품 자체의 핵심 기술에 대한 기밀을 유지하는 것이 매우 중요합니다. 그러나 소프트웨어에 대한 우리의 보안 인식은 항상 상대적으로 약했습니다. 소프트웨어 제품 개발은 주로 기술 자체에 중점을 두고 특허 보호를 무시합니다. 소프트웨어 업계에서 기술인력의 유출은 매우 흔한 현상으로, 기술인력의 상실과 변화로 인해 제품 및 신기술의 유출로 이어져 당사의 소프트웨어 제품이 다른 회사에 의해 도난당할 가능성이 높습니다. 실패를 계획하는 것. 더욱이, 현재 소프트웨어의 지적재산권을 식별하기 위한 명확한 업계 표준이 없으며 이는 우리 소프트웨어 프로젝트에 잠재적인 위험이기도 합니다.
7. ?위험을 방지하는 방법
(1) ?개발자를 유도하면 수요의 무결성을 보장하고 수요가 고객의 실제 기대와 매우 일치하도록 만들 수 있습니다. 그런 다음 누락으로 인한 손실이 소프트웨어 시스템의 후속 단계에서 점차 증폭되는 것을 방지하기 위해 중요한 문서 "사용자 요구 사항"을 서면으로 작성하십시오.
(2) 프로젝트 개발에 있어 더 큰 결정은 고객의 참여로 이루어져야 합니다. 이 프로젝트에서는 프로젝트 개발 중에 프로젝트 감독이 수행됩니다.
(3) 요구사항 변경은 통합 담당자가 제안하고 사용자 요구 검토 리더의 승인을 받아야 하며, 개발자는 이를 유지해야 합니다. 상세한 기록을 통해 고객이 수요 변화의 실제 상황을 이해할 수 있습니다.
(4) ?제어 시스템의 복잡성과 지나치게 단순한 시스템 구조는 사용자의 사용률을 크게 떨어뜨리고 소프트웨어 수명을 너무 짧게 만드는 원인이 됩니다. 반대로, 소프트웨어 구조가 너무 유연하고 다재다능하면 필연적으로 소프트웨어 구현의 어려움이 증가하고 시스템의 복잡성이 증가하여 구현 및 테스트 단계에서 위험이 초래됩니다. 시스템 복잡성을 적절하게 제어하면 개발 위험을 줄이는 데 도움이 됩니다.
(5) 소프트웨어 엔지니어링 관점에서 소프트웨어 유지 관리 비용은 전체 비용의 약 55~70%를 차지합니다. 시스템이 클수록 비용도 높아집니다. 시스템 유지 관리 가능성을 무시하는 것은 대규모 소프트웨어 시스템의 가장 큰 위험입니다. 소프트웨어의 오랜 운영 기간 동안 비즈니스 규칙은 확실히 계속 발전할 것입니다. 이 문제를 해결하는 과학적인 방법은 소프트웨어 시스템을 지속적으로 업그레이드하고 유지 관리 가능성을 보장하면서 시스템을 점진적으로 확장하는 것입니다.
(6) ? 비상 계획을 수립하십시오. 각 개발 계획은 긴급 상황 및 예측할 수 없는 위험에 대처하기 위해 최소한 하나의 비상 계획을 수립해야 합니다.
II. 비용 예산
1. 비용 예산 방법
(1) 하향식 예산 방법
하향식 예산 방법 사전계획 방법은 주로 상위 및 중간 프로젝트 관리자의 관리 경험을 바탕으로 판단하고, 프로젝트의 전체 비용을 구성하는 하위 프로젝트 비용을 추정하고, 이러한 판단 및 추정 결과를 하위 프로젝트에 전달합니다. 이를 바탕으로 이 수준의 관리자는 프로젝트를 구성하는 하위 작업 및 하위 프로젝트의 비용을 추정한 다음 가장 낮은 수준으로 전달될 때까지 비용 추정을 다음 단계로 계속 전달합니다.
이러한 예산 방식을 사용하면 상위 관리자가 자신의 경험을 바탕으로 추정한 비용을 하위 계층으로 분해할 때 하위 직원이 상위 관리자의 추정치가 그렇지 않다고 생각하는 상황이 발생할 수 있습니다. 해당 작업을 완료하기에 충분하지 않습니다. 이때, 하급 인사들이 반드시 자신의 의견을 표출할 수 없을 수도 있고, 보다 합리적인 예산 배분 계획을 도출하기 위해 반드시 상급 관리자들과 합리적인 논의를 하지 않을 수도 있습니다. 실제로는 상위 관리자가 스스로 문제를 발견하고 수정하기를 조용히 기다릴 수밖에 없어 프로젝트에 많은 문제가 발생하는 경우가 많습니다.
프로젝트 시작 초기 단계에는 Top-down이 더 적합하며, 실제 비용과의 차이는 30~70 정도입니다.
스크럼은 비용을 즉각적이고 정확하게 결정하는 것이 아니라 미래 제품에 대한 고객 요구 사항의 변화를 최대한 수용하기 위해 하향식 비용 예산 책정 방법을 사용합니다.
(2)? 상향식 예산 책정 방법
상향식 방법은 WBS(Work Breakdown Structure, 작업 분할 구조)를 사용하여 모든 작업 작업의 시간을 추정해야 합니다. 프로젝트의 예산을 주의 깊게 검토하세요. 처음에는 예산이 자원(팀 구성원의 작업 시간, 하드웨어 구성)을 기반으로 결정되고 프로젝트 관리자는 적절한 간접비(예: 교육 비용, 간접비, 우발 사항 등)와 프로젝트의 달성 목표를 추가합니다. 이익 목표는 프로젝트의 총 예산을 구성합니다. 상향식 예산 편성 방법은 관련된 모든 작업을 종합적으로 고려해야 하며 프로젝트의 초기 및 중기 단계에 더 적합하며 프로젝트 비용의 5~10% 차이를 추정할 수 있습니다. 진정한 비용.
참고: WBS
WBS는 제출된 결과를 기준으로 프로젝트를 분해한 것으로, 제출된 각 결과에 대해 수행해야 하는 활동을 확인할 수 있습니다. 단호한. 스크럼은 WBS를 더욱 구체화하고 반복을 하나 이상의 작업 패키지로 분해한 다음 작업 패키지를 작은 개발 작업으로 분해합니다(일반 개발 작업의 개발 주기는 근무 시간 15시간 이내입니다).
2. 프로젝트 지출 결정
전체 비용 예산은 다음과 같은 여러 비용 예산 방법을 결합하여 종합적으로 계산한 개발 비용입니다.
(1) 제로 베이스 예산
사업비 편성 초기에는 전년도 전체 비용에 20을 더해 사업비를 계산하는 등의 대략적인 방식이 아닌 제로 베이스 계산 원리를 사용해야 한다.
(2)?소프트웨어 및 하드웨어 비용, 품목 비용
품목 비용은 서버(RAM 하드 디스크 CPU NIC 카드 RAID 클러스터) 비용, 유지 관리 비용, 컴퓨터실 등을 의미합니다. 렌탈, 광섬유 통신비, 소프트웨어 비용 등 비용
비용을 계산할 때 하드 드라이브를 조립하는 데 걸리는 시간, 필요한 기술 인력의 품질, 제품 공급 업체가 품질 보증을 제공할 수 있는지 여부, 추가 관리 인력이 있는지 여부를 고려해야합니다. 관리를 위해 필요합니다.
(3) 소프트웨어 라이선스 비용
(4) 아웃소싱 비용
유사 서비스 이용 시: 영상, SMS, 이동통신 서비스, 포털 서브 대기 시 - 프로젝트의 경우 개발 비용 절감을 위해 아웃소싱을 고려할 수 있습니다.
(5) ?인적자원 비용
인적자원 비용을 계산할 때 업무 효율성의 최고 및 최저의 평균 효율성을 추정하여 평균 인적 자원 비용을 계산해야 합니다.
(6)? 유지관리 비용
3. 고객 커뮤니케이션 프로세스
고객 커뮤니케이션의 관점에서 소프트웨어 프로젝트는 다음과 같이 나눌 수 있습니다. 요구 사항 다양한 단계: 식별, 계획 사용자 정의, 프로젝트 구현 및 프로젝트 완료. 각 단계에는 서로 다른 커뮤니케이션 우선순위가 있습니다.
1. ?요구사항 파악 단계
(1) ?텍스트 커뮤니케이션
수요 파악 초기에는 설문지, 프로토타입 전시, 인터페이스 디스플레이, 로직 처리 디스플레이, 표준화된 문서 템플릿 등을 통해 종합적이고 다각적인 분석을 수행하고, 고객의 답변을 예상하여 언제든지 고객에게 모호한 부분을 피드백합니다. 그리고 텍스트 기록 형식으로 요구 분석 문서를 작성하고 고객이 요구 분석 문서를 검토하여 요구 분석 및 고객의 실제 기대와 매우 일치하는 결과를 얻도록 요구합니다.
(2) ?비즈니스 로직 커뮤니케이션
비즈니스 커뮤니케이션을 수행할 때 고객의 업계 언어를 이해하여 비즈니스 분석 프로세스를 촉진하고 애플리케이션 요구 사항과 개발 간의 격차를 해소해야 합니다. 커뮤니케이션 프로세스는 스케치나 시각적 정보의 형태로 제시되며 다양한 수준의 비즈니스 사용자에게 가장 적합한 운영 인터페이스를 제공합니다. 다양한 관점에서 문제를 생각하고 핵심 요구 사항, 특히 고객 리더가 우려하는 혁신적이고 실용적인 요구 사항에 집중하세요.
(3) ?표준화된 수요변화 관리
요구사항 변화는 소프트웨어 개발 프로젝트에서는 이해할 수 있지만, 수요변화는 발생을 피하기 위해 표준화된 방식으로 관리되어야 한다. 끝없는 변화의 위험 요구 사항에. 요구사항 변경은 통합 담당자가 제안하고 사용자 요구사항 검토 리더의 승인을 받아야 합니다. 요구사항 변경은 수시로 제안하기보다는 정기적으로 제안해야 하며, 개발자는 고객이 수요 변경의 실제 상황과 개발자가 지불한 비용을 이해할 수 있도록 자세한 텍스트 기록을 유지해야 합니다.
2. ?제안 맞춤화 단계
이 단계에서 프로젝트의 주요 임무는 고객과 협력하여 명확한 요구 사항, 양측의 리소스 및 프로젝트 시작부터 실행 시간 합의, 프로젝트 비용 한도 등을 바탕으로 실행 가능한 프로젝트 계획을 수립합니다. 이 단계부터 우리는 프로젝트 관리에 전적으로 참여하고 프로젝트 실행을 위한 구체적인 계획과 위험 회피를 고려합니다. 양 당사자의 상호 이익을 위해.
3. ? 프로젝트 구현 단계
이 단계에서는 소프트웨어 프로젝트 팀이 고객과 함께 프로젝트 구현을 주도해야 합니다. 동시에 프로젝트 팀은 고객 만족도를 실시간으로 평가하고 지속적인 개선을 통해 고객 만족도를 향상시켜야 합니다. 또한 고객은 필요한 교육에 참여하고 필요한 경우 프로젝트 제품을 점검해야 합니다. 고객 수요의 변화가 발생하기 전에 고객과 적극적으로 소통하여 고객이 프로젝트의 모든 측면과 변화의 영향을 완전히 이해할 수 있도록 하여 수요 변화를 줄여야 합니다. 고객 요구가 변하면 고객과 협력하여 변경으로 인한 비용, 일정, 품질 변화를 해결해야 합니다.
4. ?종료 단계
이 단계에서는 주로 프로젝트 결과를 전달하고 유지 관리 담당자에게 시스템을 전달하여 고객의 비즈니스 목표 달성 및 각종 대금 결제를 지원합니다. 이러한 작업을 완료한 후에는 프로젝트 평가를 수행하여 프로젝트 결과를 검토하고 프로젝트 경험을 요약해야 합니다.
5. 사전 영업 담당자의 주의 사항
제품 유형의 프로젝트를 개발 결과로 사용할 경우 관련 영업 담당자는 주의해야 합니다. 제품을 홍보할 때 지나친 약속을 해서는 안 됩니다. 지나치게 약속하면 후속 프로젝트 수행에 어려움을 겪을 수 있으며, 약속이 이행되지 않으면 고객 만족도가 낮아지고 향후 협력에도 영향을 미칠 수 있습니다. 추가 약속이 있는 경우 텍스트 형식으로 기록해야 하며 구현 프로젝트 관리자에게 이를 알리고 프로젝트 팀원에게 전달해야 합니다.
참고: 소프트웨어 프로젝트에서는 다음 네 가지 고객 역할을 명확히 해야 합니다.
A. 최종 사용 부서와 사용자를 명확히 하고 기존 작업 방식을 이해하며 그들에게 프로젝트의 목표 프레임워크를 알려주고 프로젝트가 해결해야 할 어려움이 무엇인지 알려주십시오. 단, 전부는 아니지만 프로젝트 범위를 더 잘 제어할 수 있습니다.
B. ? 요구사항을 제안하는 사람이 명확해야 하며, 최종 고객군을 대표할 수 있어야 합니다. 제품 요구 사항을 제안하는 고객은 특정 기술, 비즈니스 능력 및 권한을 갖추고 있어야 하며 최종 고객 팀의 희망과 아이디어를 진정으로 표현할 수 있어야 하며 IT 기반을 갖추고 문제와 요구 사항을 IT 언어로 설명할 수 있는 것이 가장 좋습니다. 두 당사자 간의 의사소통을 촉진하고 모호함을 피하십시오.
C. ? 요구사항 확인을 담당하는 중간 리더를 파악하고 방향을 파악해야 합니다. 소프트웨어 개발 프로젝트는 실제 생산 또는 관리 문제를 해결하는 동시에 리더십 시스템 구축의 구체적인 구현이기도 합니다. 요구 사항을 확인하는 고객 리더는 고위 리더의 시스템 구축의 핵심 사항과 방향을 이해할 뿐만 아니라 특정 비즈니스 및 생산 관리 관행. 그런 고객 리더가 파악하고 의사결정을 한다면 기업용 소프트웨어 개발 프로젝트가 원활하게 진행되는 데 큰 역할을 하게 될 것입니다.
D. ? 완성된 제품에 대해 누가 논평할 것인지, 누가 이를 받아들일 것인지 명확하게 하십시오. 프로젝트 승인 링크는 프로젝트의 최종 단계입니다. 승인을 승인한 사람이 프로젝트의 초기 수요 목표를 이해하지 못하면 제품에 대한 태도 및 실제 사용 측면에서 승인에 부정적인 영향을 미치게 되며, 그리고 프로젝트를 종료하는 것은 제품을 제공하는 회사에 매우 해로울 것입니다. 실제 요약에 따르면 프로젝트 승인 작업은 수요 제안자와 확인자가 수행하므로 프로젝트의 원활한 완료를 촉진하고 지연을 피할 수 있습니다.
IV. 요구사항 분석
1. 요구사항 분석 프로세스
요구사항 프로세스는 수요 개발과 수요 관리의 두 부분으로 구성됩니다.
(1) ?요구사항 개발은 개발 초기 단계의 관리로, 객실과의 커뮤니케이션 프로세스는 요구사항 획득, 요구사항 분석, 요구사항 작성 및 요구사항 검증의 4단계로 나눌 수 있습니다.
(2) 요구사항 관리: 소프트웨어 프로젝트 개발 프로세스 중에 요구사항 계약을 제어하고 유지하는 활동입니다. 포함 사항: 변경 제어, 버전 제어, 요구 사항 추적, 요구 사항 상태 추적.
2. ?요구사항 수준
요구사항 수준에는 비즈니스 요구사항, 사용자 요구사항, 기능적 요구사항, 비기능적 요구사항의 네 가지 측면이 포함됩니다.
3. 요구사항 개발 단계의 핵심 사항
(1) 비즈니스 객체 추출
비즈니스 객체는 시스템에서 사용하는 실제 객체를 말합니다. 공급망 관리(SCM이라고도 하는 공급망 관리) 비즈니스 개체에는 주로 생산 도매업체, 소매업체, 배달 제공업체 및 여러 수준의 고객이 포함됩니다.
(2) 비즈니스 프로세스 추출
비즈니스 로직을 이해하는 과정에서 개발된 소프트웨어 모듈의 각 기능을 나열하고 각 작업 프로세스를 자세히 설명하며, 비즈니스는 논리적으로 심층적으로 분석되어야 합니다.
(3) ?성능 요구 사항
분석 초기 단계에서는 저장 용량 제한, 실행 시간 제한 등 개발된 소프트웨어의 기술적 성능 지표에 주의를 기울여야 합니다. , 보안 및 기밀 유지 등
(4) ?환경 요구 사항
환경 요구 사항은 소프트웨어 플랫폼이 실행되는 환경의 요구 사항을 의미합니다. 예를 들어 하드웨어: 기계 모델, 외부 장비, 데이터 통신 인터페이스; 소프트웨어 : 운영 체제, 네트워크 소프트웨어, 데이터베이스 관리 시스템을 포함한 시스템 소프트웨어 사용 측면: 사용 부서가 시스템 및 운영자의 기술 수준 측면에서 갖추어야 할 조건.
(5) 신뢰성 요구 사항
개발된 소프트웨어가 실행된 후 실패할 확률은 실제 운영 환경을 기반으로 해야 합니다. 중요한 소프트웨어나 작동 실패로 인해 심각한 결과를 초래할 수 있는 소프트웨어의 경우 더 높은 신뢰성 요구 사항이 제시되어야 합니다.
(6) ?보안 및 기밀 유지 요구 사항
수요 분석 시 이와 관련하여 적절한 조항이 있어야 하며 개발된 소프트웨어에 사용할 수 있도록 특수 설계가 제공되어야 합니다. 작동 중에는 보안 및 기밀 유지가 보장됩니다.
(7) ?사용자 인터페이스 요구 사항
사용자 인터페이스에 대한 요구 사항을 자세히 지정합니다.
(8) ? 리소스 사용 요구 사항
런타임 및 개발 중에 개발된 소프트웨어에 필요한 다양한 리소스입니다.
(9) ?소프트웨어 비용 소비 및 개발 일정 요구 사항
소프트웨어 프로젝트가 승인된 후 계약에 따라 소프트웨어 개발 진행 요구 사항 및 각 단계의 비용 개발관리의 기반으로 필요합니다.
(10) 개발 목표 요구 사항
향후 시스템이 달성할 수 있는 목표를 미리 예측하여 시스템에 필요한 추가 및 수정을 더 쉽게 할 수 있습니다.
4. 요구사항 분석 작업
요구사항 분석의 주요 작업은 현재 시스템의 논리 모델을 활용하여 대상 시스템의 논리 모델을 도출하는 것입니다. 프로세스는 다음과 같습니다.
(1) 시스템에 대한 포괄적인 요구 사항(기능, 성능, 운영, 확장 요구 사항)을 결정합니다.
(2) 제품 요구 사항 문서(PRD)를 개발합니다.
(3) ?시스템의 데이터 요구사항 분석(개념 모델, 데이터 사전, 정규화)
(4) ?타겟 시스템의 상세한 논리 모델 내보내기(데이터 흐름) 다이어그램, 데이터 사전, 주요 기능 설명)
(5) 프로토타입 시스템 개발
(6) PRD에서 소프트웨어 요구사항 사양(SRS) 추출 및 준비
참고: SRS 형식
1. 소개? 2 시스템 개요(프로젝트 배경, 시스템 목표, 핵심 비즈니스 프로세스) 3. 용어 설명 4. 시스템 구조(아키텍처 다이어그램, 기능 다이어그램)
5. 주요 기능 및 비즈니스 로직(핵심 포인트) 6. 인터페이스 요구사항(내부, 외부 인터페이스) 7. 전체 네트워크 설계(토폴로지 네트워크, 호스트, 네트워킹)
8. 운영 환경(Linux) , Windows, IIS, WebLogic, Tomcat, OLAP, OLTP, JDK 8.0, .NET Framework 4.0 등)
5. 객체지향 프로그래밍(생략)
1. ? 디자인 원칙
(1) ? SRP 단일 책임 체인
각 클래스는 한 가지 작업만 담당해야 합니다.
(2) ?OCP 열기 및 닫기 원칙
소프트웨어 엔터티(클래스, 모듈, 기능 등)는 확장 가능해야 하지만 수정할 수는 없습니다.
(3) ?LSP 대체 원칙
하위 클래스는 기본 유형을 대체할 수 있어야 합니다.
(4) ?DIP 종속성 반전 원칙
상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되며, 둘 다 인터페이스와 추상 클래스에 의존해야 합니다. 추상화는 세부사항에 의존해서는 안 되며, 세부사항은 객체에 의존해야 합니다.
(5) ?ISP 인터페이스 격리 원칙
고객은 사용되지 않는 인터페이스에 의존하도록 강요해서는 안 되지만, 뚱뚱한 인터페이스는 분리되어야 합니다.
2. ? UML 모델링 구현
(1) ? 비즈니스 객체 추출
(2) ? SRS, CRC 등을 기반으로 한 사용 사례 모델링 구현 .
p>
(3) ?비즈니스 시퀀스 다이어그램 구현
(4) ?클래스 다이어그램을 설정하고 유스 케이스 다이어그램을 기반으로 객체 간 연관 설정
(5) ?활동 다이어그램, 구현 협업 다이어그램, 상태 차트 그리기
개발 관리
1. (1) 전체 아키텍처 설계
시스템 구현 요구 사항에 따라 적절하고 성숙한 프레임워크 구조를 채택합니다.
(2) ?확장성 제어
과도한 확장은 시스템의 복잡성을 증가시키고 개발 시간을 연장시킵니다. 너무 낮은 확장은 시스템의 2차 성능에 직접적인 영향을 미칩니다. 그리고 유지 보수.
제어 시스템의 확장성은 개발 효율성을 향상시키고 시스템 유지 관리의 어려움을 줄일 수 있습니다.
(3) 인프라 구축
소프트웨어, 하드웨어 및 기타 인프라(예: 서버 주문 및 설치, 광섬유 액세스, 소프트웨어 플랫폼 주문) 배포에 필요한 시간과 비용을 합리적으로 할당합니다. ).
(4) ?개발 작업을 나눕니다.
WBS(Work Breakdown Structure)를 사용하여 결과물을 분류하고 나눕니다. 각 프로젝트는 여러 단계로 나눌 수 있으며, 각 단계는 여러 작업 패키지(작업 패키지)로 나눌 수 있습니다. 작업 패키지는 WBS에서 가장 작은 결과물입니다.
(5) ?배포 개발 진행
프로젝트는 진행 상황에 따라 여러 개발 단계로 나누어야 합니다. 각 단계의 개발 주기는 일반적으로 영업일 기준 30~60일 이내입니다. 이 단계에서는 제품 로드맵 개발을 위해 고객과의 협의 회의를 개최해야 하며, 개발 과정에서 고객이 적극적으로 참여하고 피드백을 제공하도록 유도해야 합니다. 그런 다음 이 기간 내의 개발 작업은 개발 난이도, 종속성, 중요성 및 기타 조건을 기반으로 여러 반복 주기로 나뉩니다.
스크럼 애자일 소프트웨어 개발 원칙에서는 각 반복 작업을 여러 개발 작업 목록으로 더 세분화해야 하며, 재개발 작업은 팀원 각자의 책임에 따라 할당되어야 하며, 개발 시간은 몇 시간 내에 15개 작업으로 제어됩니다. 개발 시간이 15시간을 초과하는 경우 개발 작업을 세분화하는 것을 고려해야 합니다. 개발 작업 제안은 강제 할당을 사용하는 대신 팀 구성원이 독립적으로 선택해야 합니다.
(5) 테스트 프로젝트 결과
각 작업 패키지는 프로젝트 품질을 향상시키기 위해 테스트 작업을 동시에 배포해야 합니다. 버그가 있는 작업 패키지는 테스터가 텍스트 형식으로 기록하여 개발자에게 오류가 있는 위치를 보여주고 개발자가 적시에 수정할 수 있도록 해야 합니다.
2. ?개발팀 관리
(1) ?팀 구성
업무 과제 및 프로젝트 시간의 전제 조건에 따라 팀을 구성하고 할당합니다. 팀 책임에 따라 인원을 배정하며, 일반적인 팀 규모는 8~12명 사이로 조절되어야 합니다. 팀 규모가 15명을 초과하는 경우 팀을 서로 다른 개발 작업을 담당하는 두 개의 독립적인 팀으로 분할하는 것을 고려해야 합니다.
(2) ?개발 작업 할당
각 반복 주기(보통 영업일 기준 15~30일)에서 각 작업 패키지는 여러 개발 작업과 재개발 작업으로 더욱 세분화되어야 합니다. 각 팀원에게 배정되며, 개발시간은 근무시간 15시간 이내로 조절되어야 합니다. 개발 작업의 개발 시간이 15시간을 초과하는 경우 작업 세분화를 고려해야 합니다. 개발 작업은 자유롭게 선택한 방식으로 각 팀 구성원에게 할당되어야 합니다.
(3) ?개발 진행 상황 감독
iteration 초기에 회의를 개최하여 팀원들이 개발 진행 상황과 프로세스를 이해하고 개발 작업을 방식으로 할당합니다. 그들 자신의 선택으로. 이 기간 동안 Microsoft Project와 같은 도구를 사용하여 개발 프로세스의 진행 상황을 기록할 수 있습니다. 각 작업 패키지가 개발된 후에는 기능 테스트를 수행하고 테스트 결과를 텍스트로 기록해야 합니다.
매일 15분간 스탠드업 미팅을 진행해 팀원들이 어제 완료한 개발 업무와 그날 해야 할 업무, 개발 과정에서 겪게 되는 문제점을 설명한다. 그리고 매주 주말마다 정기회의를 열어 전체적인 진행상황을 설명합니다.
반복이 끝나면 스프린트 회의가 개최되어 프로젝트 진행 상황, 은행이 완료한 작업을 요약하고 반복 주기 동안 직면한 문제를 검토하며 다음 반복을 준비합니다.
(4) 시스템 테스트
완료된 각 작업 패키지에 대해 적시에 테스트를 수행하여 시스템 품질과 성능을 보장합니다. 테스트 결과를 텍스트로 기록하고, 테스트 결과를 성과급 소득과 연계하고, 실제 데이터를 바탕으로 팀원의 성과 소득을 계산합니다.
(5) 개발 중 발생한 문제를 해결합니다.
개발자에게 조기 교육을 제공하고 업무 능력에 따라 적절하게 작업을 할당하며 팀원의 개발을 지도합니다. 문제가 발생하면 당일 스탠드업 회의에서 즉시 제기해야 하며, 발생한 문제는 근무 시간 15시간 이내에 해결하여 문제가 더 이상 확대되지 않도록 해야 합니다.
3. 제품 품질 감독
(1) 품질에는 검토보다는 계획과 설계가 필요합니다. 제품 생성 초기 단계에서는 품질 보증(QA) 부서와 협의하여 적절한 품질 정책 및 표준을 결정하고 공식적으로 문서화해야 합니다.
(2) ?개발 프로세스 중에 TDD(테스트 중심 개발) 모델을 사용하여 개발 품질을 향상시킵니다. 테스터는 버그를 텍스트로 기록하고 개발자와 협력하여 개발자에게 뛰어난 결함을 보여줌으로써 수정 효율성을 높여야 합니다.
(3) ? 각 반복이 끝날 때마다 제품 효과 시연을 수행하여 고객, 사용자 및 고위 리더로부터 피드백을 수집합니다. 테스트 결과를 분석하고, 제품 성능을 이해하고, 다음 반복에 필요한 개선을 계획하기 위해 팀 내에서 검토 회의를 개최합니다.
4. ?프로젝트 계획 수정
(1) ?제품 요구 식별 단계에서는 개발 계획 시 제품 기능 및 개발 프로세스를 문서 형식으로 기록해야 합니다. 수정이 필요한 경우 고객과 논의하여 계획 수정이 프로젝트 진행에 미치는 영향을 이해할 수 있도록 해야 합니다.
(2) 프로젝트 계획 수정은 통합 책임자가 제안하고 사용자 요구 사항을 검토하는 리더의 승인을 받아야 합니까? 요구 사항 변경은 언제든지 제안하는 것이 아니라 정기적으로 제안해야 합니다.
(3) ? 계획된 변경 사항은 고객이 수요 변화의 실제 상황과 개발자가 지불한 비용을 이해할 수 있도록 상세한 텍스트로 기록되어야 합니다.
7. 제품 배송
1. 프로젝트 사후 검토
프로젝트 개발이 최종적으로 완료되면 개발자에게는 안도감이라 할 수 있다. 업무 부담을 덜기 위한 것이지만, 프로젝트 관리자에게 있어 이는 프로젝트에서 매우 중요한 순간인 경우가 많습니다. 초기 위험 평가, 비용 예산, 수요 분석 및 소프트웨어 설계는 모두 모든 시선이 프로젝트 관리자에게 쏠리는 이 순간까지 프로젝트를 안내하기 위한 것입니다. 많은 양의 사소한 작업이 몇 시간 내에 완료될 수 있습니다. 이 순간 프로젝트 관리자는 깨어 있고 침착해야 하며 최종 작업을 마이크로 프로젝트로 처리해야 합니다. 프로젝트 결과, 프로젝트 팀의 효율성, 결과물의 가치를 분석하기 위해 프로젝트에 대한 상세한 사후 검토를 수행합니다. 검토 결과는 프로젝트 관리 경험 요약의 일부로 사용될 수 있습니다.
2. 품질 검토
프로젝트 납품 전에 프로젝트는 품질 검토를 위해 관련 "품질 보증"(QA) 부서에 인계되어야 하며, 일반 사용자는 다음과 같이 초대되어야 합니다. 제품의 품질을 경험해보세요.
3. ?최종 프로젝트 납품
일반적인 상황에서는 프로젝트 초기 단계에서 프로젝트 납품 계약이 체결됩니다. 프로젝트 납품 방법은 비공식으로 구분됩니다. 수용과 공식적인 수용. 일반적으로 프로젝트가 완료된 후 고객이 프로젝트 품질을 경험하고 피드백을 제공할 수 있도록 비공식 승인이 먼저 수행됩니다. 마지막으로 고객이 제품 품질을 확인한 후 공식 제품 승인이 수행됩니다. 서면 계약의 형태.
4. ?프로젝트 최종 보고서
프로젝트가 끝나면 프로젝트 최종 보고서가 작성되어야 합니다. , 그러나 보고서에는 반드시 프로젝트의 모든 측면이 포함되는 것은 아닙니다.
일반적으로 최종 보고서에는 다음 측면이 포함되어야 합니다.
(1) ?프로젝트가 처음 도입되었을 때의 초기 프로젝트 보기
(2) ?프로젝트에 대한 가치 평가 및 지원 정보
p>
(3) ?프로젝트 범위
(4) ?프로젝트 개발 프로세스 및 WBS
(5) ?프로젝트 회의록
(6) ? 프로젝트 변경 사항 및 변경 사유를 보고합니다.
(7) 프로젝트와 관련된 의사소통 과정 문서
(8) ? 감사 보고서 및 고객 승인 보고서
(9) ?프로젝트 구성원의 성과 보고서
(10) 프로젝트 최종 결과