I. 위험 평가
소프트웨어 프로젝트 위험은 전체 프로젝트 주기에 관련된 비용 예산, 개발 진행, 기술적 어려움, 경제적 타당성, 안전 관리 및 이러한 문제가 프로젝트에 미치는 영향입니다. 프로젝트의 위험은 실현가능성에 반비례하며, 실현가능성이 높을수록 위험은 낮아진다. 소프트웨어 프로젝트의 타당성은 경제적 타당성, 비즈니스 타당성, 기술적 타당성 및 법적 타당성의 네 가지 측면으로 나눌 수 있습니다. 소프트웨어 프로젝트 위험은 제품 규모 위험, 수요 위험, 관련성 위험, 관리 위험 및 보안 위험의 여섯 가지 측면으로 나뉩니다.
1 ..? 제품 규모 위험
프로젝트의 위험은 제품의 규모에 비례한다. 일반 제품 규모가 클수록 문제가 더욱 두드러진다. 특히 제품 규모를 추정하는 방법, 재사용 가능한 소프트웨어의 수, 수요 변화의 수 등은 모두 제품 위험과 밀접한 관련이 있습니다.
(1)? 제품의 규모를 가늠하는 방법
(2)? 제품 규모 추정의 신뢰성
(3)? 제품 크기와 이전 평균 제품 크기의 편차
(4)? 제품의 사용자 수입니다
(5)? 재사용 소프트웨어는 얼마나 됩니까?
(6)? 제품 수요가 얼마나 달라졌나요?
2.? 수요 위험
많은 프로젝트가 수요를 결정할 때 약간의 불확실성에 직면해 있다. 이러한 불확실성은 프로젝트 초기에 용인되어 프로젝트 진행 과정에서 해결되지 않을 때 프로젝트의 성공에 큰 위협이 될 수 있습니다. 수요와 관련된 위험 요소를 통제하지 않으면 잘못된 제품을 생산하거나 예상 제품을 망가뜨릴 가능성이 높다. 각 상황은 제품에 치명적일 수 있습니다. 이러한 위험 요소는 다음과 같습니다.
(1)? 제품에 대한 명확한 이해가 부족하다
(2)? 제품 수요에 대한 인식이 부족하다
(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)? 비상 계획 수립, 각 개발 계획은 돌발 상황과 미지의 위험에 대비한 비상 계획을 하나 이상 세워야 한다.
둘째, 비용 예산
1 ..? 원가 예산 모델
(1)? 하향식 예산 방법
하향식 사전 접근 방식은 주로 중간 및 상위 프로젝트 관리자의 관리 경험을 바탕으로 프로젝트의 전체 비용을 구성하는 서브 프로젝트 비용을 추정하고 이러한 판단과 추정 결과를 하위 관리자에게 전달하는 것입니다. 이를 바탕으로 이 수준의 경영진은 프로젝트를 구성하는 하위 태스크 및 서브 프로젝트를 추정한 후 최저 수준에 도달할 때까지 비용 견적을 다음 레벨로 계속 전달합니다.
이 예산 방법을 사용하면 상위 관리자가 경험 기반 원가 추정을 기준으로 하위 계층으로 분할할 때 하위 계층이 상위 추정치가 해당 태스크를 수행하기에 충분하지 않다고 생각하는 경우가 발생할 수 있습니다. 이때 하층 인원은 자신의 진실한 견해를 표현하지 않을 수도 있고, 이성적으로 상층 경영진과 토론하지 않아 더욱 합리적인 예산 분배 방안을 도출할 수도 있다. 실제로 이들은 고위 경영진이 문제를 발견하고 바로잡을 때까지 묵묵히 기다릴 수밖에 없어 프로젝트에 많은 문제를 가져오는 경우가 많다.
하향식은 프로젝트 개시 초기에 실제 비용과의 차이가 30% ~ 70% 사이인 경우에 더 적합하다.
Scrum 은 하향식 비용 예산 접근 방식을 채택하여 비용을 즉시 정확하게 확정하지는 않지만 향후 제품 요구 사항에 대한 고객의 변화를 최대한 수용할 것입니다.
(2)? 상향식 예산 방법
상향식 접근 방식을 사용하려면 WBS (작업 분할 구조) 를 사용하여 프로젝트의 모든 작업 작업에 대한 시간과 예산을 자세히 검토해야 합니다. 초기 예산은 리소스 (팀 구성원의 근무 시간, 하드웨어 구성), 프로젝트 관리자, 적절한 간접비 (예: 교육비, 관리비, 예상치 못한 비용 등) 에 대한 것입니다. ) 및 프로젝트가 달성해야 할 이익 목표, 총 프로젝트 예산 형성. 상향식 예산 접근 방식은 관련된 모든 작업을 종합적으로 고려해야 하며 프로젝트의 초기와 중기에 더 적합합니다. 준비 단계에서 프로젝트 비용을 추정할 수 있으며 실제 비용과의 차이는 5% 에서 10% 사이입니다.
주: WBS
WBS 는 제출 항목의 분해입니다. 제출 목록에서 각 제출에 대해 수행해야 할 활동을 식별할 수 있습니다. Scrum 은 WBS 를 더욱 구체화하고 반복을 하나 이상의 작업 패키지로 분할한 다음 작업 패키지를 작은 개발 작업으로 나눕니다 (일반 개발 작업의 개발 주기는 15 근무 시간 이내).
2.? 프로젝트 지출 결정
총 원가 예산은 다음과 같은 원가 예산 방법과 함께 종합적으로 계산된 개발 원가입니다.
(1)? 제로 기준 예산
원가 예산 초기에는 0 기반 계산 원칙을 채택해야 하며, 전년도 총원가에 20% 를 더한 것처럼 프로젝트 원가를 대략적으로 계산할 수 없습니다.
(2)? 소프트웨어 및 하드웨어 비용, 프로젝트 비용
프로젝트 비용은 서버 (RAM 하드 디스크 CPU NIC 카드 RAID 클러스터) 비용, 유지 관리 비용, 기계실 임대, 광섬유 통신 비용, 소프트웨어 비용 등과 유사한 비용입니다.
비용을 계산할 때 하드 드라이브를 조립하는 데 필요한 시간, 기술자의 질, 제품 공급업체가 품질을 보장할 수 있는지 여부, 관리에 추가 관리 인력이 필요한지 여부 등 여러 가지 요소를 고려해야 합니다.
(3)? 소프트웨어 라이센스 비용
(4)? 아웃소싱 비용
동영상, 문자메시지, 이동통신 서비스, 포털 등 서브 프로젝트를 사용할 때. , 아웃소싱을 고려하고 개발 비용을 절감할 수 있습니다.
(5)? 인적 자원 비용
인적 자원 비용을 계산할 때 생산성이 가장 높고 가장 낮은 평균 효율을 추정하여 인적 자원의 평균 비용을 계산해야 합니다.
(6)? 수리비
셋째, 고객 커뮤니케이션 프로세스
고객 커뮤니케이션의 관점에서 볼 때, 소프트웨어 프로젝트는 수요 식별, 시나리오 사용자 정의, 프로젝트 구현, 프로젝트 종료의 네 가지 단계로 나눌 수 있으며, 각 단계마다 서로 다른 커뮤니케이션 초점이 있습니다.
1 ..? 수요 식별 단계
(1)? 문자통신
수요 인식 전, 설문 조사, 프로토타입 전시, 인터페이스 전시, 논리 처리 전시, 표준화된 문서 템플릿 등을 통해 포괄적이고 다각적인 분석을 수행해야 합니다. , 고객 답변을 기대하기 위해 언제든지 고객에게 모호한 피드백을 제공합니다. 또한 문서화된 방식으로 수요 분석서를 작성하여 고객에게 수요 분석서를 검토하여 고객의 실제 기대와 매우 일치하는 결과를 얻을 수 있도록 합니다.
(2)? 비즈니스 논리 커뮤니케이션
비즈니스 커뮤니케이션에서는 고객의 업계 언어를 이해하여 비즈니스 분석 프로세스를 추진하고 애플리케이션 요구 사항과 개발 간의 격차를 해소해야 합니다. 커뮤니케이션 프로세스는 스케치 또는 시각화 정보화를 촉진하여 다양한 수준의 기업 사용자에게 가장 적합한 운영 인터페이스를 제공합니다. 다각적 사고, 중점 수요 파악, 특히 고객 리더십이 주목하는 혁신적이고 실용적인 수요.
(3)? 수요 변화의 표준화 된 관리
수요 변경은 소프트웨어 개발 프로젝트에서 이해할 수 있지만, 끊임없는 수요 변화의 위험을 피하기 위해 표준화된 방식으로 관리해야 합니다. 수요 변경은 통합 책임자가 제출해야 하며 사용자 수요 검토 팀장의 승인을 받아야 합니다. 수요 변경은 수시로 제출하는 것이 아니라 정기적으로 제출해야 한다. 개발자는 고객이 요구 사항 변경의 실제 상황과 개발자가 지불하는 비용을 이해할 수 있도록 자세한 텍스트 기록을 작성해야 합니다.
2.? 시나리오 사용자 정의 단계
이 단계에서 프로젝트의 주요 임무는 이전 기간의 명확한 요구 사항, 양 당사자의 자원, 프로젝트 초기, 구현 시간 약속, 프로젝트 비용 제한 등을 기준으로 고객 * * * 과 (와) 운영 가능한 프로젝트 계획을 수립하는 것입니다. 이 단계부터 고객은 프로젝트 관리에 전면적으로 참여하여 프로젝트 구현의 구체적인 방안과 위험 회피를 쌍방의 이익에서 고려할 것입니다.
3.? 프로젝트 구현 단계
이 단계에서 소프트웨어 프로젝트 팀은 고객과 함께 프로젝트 구현을 이끌어야 합니다. 또한 프로젝트 팀은 실시간으로 고객 만족도를 평가하고 지속적인 개선을 통해 고객 만족도를 높여야 합니다. 또한 고객에게 필요한 교육을 받고 필요한 경우 프로젝트 제품을 검사하도록 요청해야 합니다. 고객의 요구가 변화하기 전에, 프로젝트의 모든 측면과 변화의 영향을 충분히 이해하고 수요 변화를 줄일 수 있도록 적극적으로 고객과 의사 소통해야 합니다. 고객의 요구가 변화할 경우, 우리는 고객과 함께 변화로 인한 비용, 진도, 품질의 변화를 해결해야 합니다.
4.? 단계를 마치다
이 단계는 주로 프로젝트 성과 이전, 시스템이 유지 보수 직원에게 전달되어 고객이 비즈니스 목표를 달성하고 다양한 금액을 결제할 수 있도록 돕는 단계입니다. 이러한 작업을 완료한 후에는 프로젝트를 평가하고, 프로젝트 결과를 검토하고, 프로젝트 경험을 요약해야 합니다.
5.? Pre-sales 담당자 참고 사항
제품 지향 프로젝트가 개발 성과로 간주될 때 관련 영업 담당자는 제품 홍보에 대한 과도한 공약이 있어서는 안 된다는 점에 유의해야 합니다. 약속이 너무 많으면 후속 프로젝트 실행에 어려움이 생길 수 있다. 일단 약속이 이행되지 않으면 고객 만족도도 낮아져 향후 협력에 영향을 미칠 수 있다. 추가적인 약속이 있는 경우 구현 프로젝트 관리자가 프로젝트 팀 멤버에게 알고 전달할 수 있도록 텍스트로 기록해야 합니다.
참고: 소프트웨어 프로젝트에서 다음 네 가지 고객 역할을 정의해야 합니다.
A.? 최종 사용자 부서와 사용자를 명확하게 하고, 기존의 작업 방법을 이해하고, 프로젝트의 목표 프레임워크를 알리고, 프로젝트가 해결해야 할 어려움을 알고 있지만, 반드시 전부는 아니어야 프로젝트의 범위를 더 잘 제어할 수 있다.
B.? 수요의 개시자를 명확히 하기 위해, 그 또는 그들은 최종 고객층을 대표할 수 있어야 한다. 이러한 제품 수요를 제시하는 고객은 기술, 업무 능력 및 권한을 갖추어야 하며, 최종 고객 팀의 의지와 생각을 진정으로 대표할 수 있어야 하며, IT 기반을 가지고, IT 언어로 문제와 수요를 설명하고, 쌍방 간의 소통과 협력을 용이하게 하고, 모호함을 피하는 것이 가장 좋다.
C.? 수요 확인을 하는 중급 지도자는 반드시 방향을 잡아야 한다. 소프트웨어 개발 프로젝트는 실제 생산 또는 관리 문제를 해결하기 위한 것이며, 시스템 건설의 구체적인 실현을 이끌기 위한 것이다. 확인이 필요한 고객 리더로서 고위 경영진의 시스템 구축 중점과 방향뿐만 아니라 구체적인 업무 및 생산 관리 관행도 숙지해야 합니다. 그렇다면, 기업 소프트웨어 개발 프로젝트의 원활한 진행에 특별한 역할을 할 것이다.
D.? 누가 완제품에 대해 평론을 할 것인지, 누가 받아들일 것인지를 분명히 해야 한다. 프로젝트 검수 고리는 프로젝트의 마무리 고리이다. 프로젝트를 받아들이는 사람이 프로젝트의 초기 수요 목표를 이해하지 못하면 태도와 제품의 실제 사용 효과에서 수용에 부정적인 영향을 미칠 수 있어 제품을 제공하는 기업의 프로젝트 폐쇄에 불리하다. 실천 총결산에 따르면 수요와 확인측이 프로젝트 검수 작업을 잘 하면 프로젝트의 원활한 완성을 촉진하고 지연을 피할 수 있다.
넷째, 수요 분석
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 형식
1. 소개? 2 시스템 개요 (프로젝트 배경, 시스템 목표, 핵심 비즈니스 프로세스) 3. 용어 설명? 4. 시스템 구조 (아키텍처 맵, 기능 맵)
5. 주요 기능 및 비즈니스 로직 (요점) 6. 인터페이스 요구 사항 (내부 및 외부 인터페이스) 7. 전체 네트워크 설계 (토폴로지 네트워크, 호스트, 네트워크)
8. 운영 환경 (Linux, Windows, IIS, WebLogic, Tomcat, OLAP, OLTP, JDK 8.0,. 넷프레임워크 4.0 등. ) 을 참조하십시오
다섯째, 객체 지향 프로그래밍 (약간)
1 ..? 설계원리
(1)? SRP 단일 책임 체인
각 반은 한 가지 일만 해야 한다.
(2)? OCP 개폐 및 셧다운 원리
소프트웨어 엔티티 (클래스, 모듈, 함수 등). ) 는 확장 가능해야 하지만 수정할 수는 없습니다.
(3)? LSP 교체 지침
하위 클래스는 기본 유형을 대체할 수 있어야 합니다.
(4)? 기울기 관련 반전 원리
상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되지만 둘 다 인터페이스와 추상 클래스에 의존해야 합니다. 추상화는 세부 사항에 의존해서는 안 되고, 세부 사항은 오브젝트에 의존해야 한다.
(5)? ISP 인터페이스 격리 원칙
우리는 고객에게 사용하지 않는 인터페이스에 의존하도록 강요하는 대신 뚱뚱한 인터페이스를 분리해야 한다.
2.? UML 모델링 구현
(1)? 비즈니스 객체 추출
(2)? SRS, CRC 등을 기반으로 한 유스 케이스 모델링
(3)? 업무 순서도를 실현하다
(4)? 클래스 다이어그램을 작성하여 유스 케이스 다이어그램을 기반으로 객체 간의 연관을 설정합니다.
(5)? 활동 다이어그램을 그려 공동 작업 다이어그램과 상태 다이어그램을 구현합니다.
자동사 발전관리.
1 ..? 프로젝트 계획 작성
(1)? 전체 아키텍처를 설계합니다
시스템 구현 요구에 따라 적절하고 성숙한 프레임워크 구조를 채택하다.
(2)? 확장성 제어
과도한 확장은 시스템의 복잡성을 증가시키고 개발 시간을 연장합니다. 확장성이 너무 낮으면 시스템의 2 차 개발 및 유지 관리에 직접적인 영향을 미칠 수 있습니다. 제어 시스템의 확장성은 개발 효율성을 높이고 시스템 유지 관리의 어려움을 줄일 수 있습니다.
(3)? 기반 시설을 구축하다
하드웨어 및 소프트웨어와 같은 인프라 배포에 필요한 시간과 비용을 합리적으로 할당 (예: 서버 주문 및 설치, 광섬유 액세스, 소프트웨어 플랫폼 주문).
(4)? 개발 임무를 나누다
WBS (작업 분할 구조) 를 사용하여 결과물을 분류하고 구분합니다. 각 프로젝트는 여러 단계로 나눌 수 있으며 각 단계는 WBS 에서 가장 작은 결과물인 여러 작업 패키지로 나눌 수 있습니다. 마지막으로 작업 패키지에서 몇 가지 개발 작업 목록을 분리합니다.
(5)? 배포 및 개발 진행 상황
프로젝트는 진도에 따라 여러 개발 단계로 나누어야 하며, 각 단계의 개발 주기는 일반적으로 30~60 일 (영업일 기준) 이내이다. 이 단계에서는 고객과의 컨설팅 회의를 열고, 제품 로드맵을 개발하고, 개발 과정에서 고객을 적극적으로 참여시키고 피드백을 제공해야 합니다. 그런 다음 개발의 난이도, 의존성, 중요성 등에 따라 해당 기간의 개발 작업을 여러 반복 주기로 나눕니다.
Scrum 애자일 소프트웨어 개발 원칙에서 각 반복 작업은 여러 개발 작업 목록으로 세분화되고, 개발 작업은 팀 구성원에게 할당되며, 개발 시간은 15 근무 시간 이내로 제어해야 합니다. 개발 시간이 15 근무 시간을 초과하면 개발 임무를 다시 구체화하는 것을 고려해야 한다. 개발 임무 제안은 강제로 지정하는 것이 아니라 팀 멤버가 직접 선택해야 합니다.
(5)? 테스트 항목 결과
각 작업 패키지는 프로젝트 품질을 향상시키기 위해 테스트 작업을 동시에 배포해야 합니다. 버그가 있는 작업 패키지는 테스터가 문자로 기록하고 개발자가 제때에 수정할 수 있도록 개발자에게 오류를 표시해야 합니다.
2.? 개발 팀 관리
(1)? 팀을 하나 세우다
작업 태스크 및 프로젝트 시간 전제 조건에 따라 팀을 구성하고 팀 역할에 따라 인력을 지정합니다. 일반 팀 구성원 수는 8 에서 12 사이로 제어해야 한다. 팀 수가 15 를 초과할 때는 팀을 별도의 두 팀으로 나누어 각각 다른 개발 임무를 담당하는 것을 고려해야 한다.
(2)? 개발 임무를 할당하다
각 반복 주기 (일반적으로 15~30 영업일) 동안 각 작업 패키지는 여러 개발 작업으로 더 세분화되고, 재개발 작업은 팀 구성원에게 할당되며, 개발 시간은 15 근무 시간 내에 제어됩니다. 개발 작업의 개발 시간이 15 근무 시간을 초과하면 작업 재테셀레이션을 고려해야 합니다. 개발 임무는 각 팀 멤버에게 자유롭게 할당해야 합니다.
(3)? 개발 진도를 감독하다
반복 전 회의를 열어 팀 구성원에게 개발 진도와 프로세스를 알리고 개발 임무를 원하는 방식으로 배정할 수 있도록 합니다. 이 기간 동안 Microsoft Project 와 같은 도구를 사용하여 개발 프로세스의 진행 상황을 기록할 수 있습니다. 각 작업 패키지 개발이 완료되면 기능 테스트를 수행해야 하며 테스트 결과는 문자로 기록해야 합니다.
매일 15 분 상무회를 열어 팀원들에게 어제 완성한 개발 임무, 당일 해야 할 임무, 개발 과정에서 발생하는 문제를 설명하게 한다. 그리고 주말마다 정기회의를 열어 전체 과정을 설명한다.
반복이 끝나면 스프린트 회의를 열고, 프로젝트 진행 상황을 요약하고, 작업을 완료하고, 반복 중에 발생한 문제를 검토하고, 다음 반복을 준비합니다.
(4)? 시스템 테스트
완료된 각 작업 패키지를 적시에 테스트하여 시스템의 품질과 성능을 보장합니다. 테스트 결과를 텍스트로 기록하고 테스트 결과를 성과 임금 소득과 연계하여 실제 데이터를 사용하여 팀 구성원의 성과 수익을 계산합니다.
(5)? 발전 중에 직면한 문제를 해결하다
개발자를 위한 사전 교육을 실시하고, 업무 능력에 따라 임무를 분배하고, 팀 구성원의 발전을 지도한다. 문제가 발생하면 당일 상무회에서 즉시 제기해야 하고, 발생한 문제는 15 근무 시간 내에 해결해야 문제가 더 확대되는 것을 막을 수 있다.
3.? 제품의 품질을 감독하다
(1)? 품질은 검토가 아닌 계획, 설계가 필요합니다. 제품 설립의 초기 단계에서는 품질 보증 (QA) 부서와 협의하여 공식 문서로 적절한 품질 정책 및 표준을 결정해야 합니다.
(2)? 개발 과정에서 TDD (테스트 중심 개발) 모델을 사용하여 개발 품질을 향상시킵니다. 테스터는 버그를 텍스트로 기록하고 개발자와 함께 뛰어난 결함을 개발자에게 시연하여 수정 효율성을 높여야 합니다.
(3)? 반복이 끝날 때마다 제품 효과 데모를 통해 고객, 사용자, 고위 경영진의 피드백을 수집합니다. 팀 내에서 검토 회의를 열고, 테스트 결과를 분석하고, 제품 성능을 이해하고, 다음 반복에 필요한 개선을 위한 계획을 수립합니다.
4.? 프로젝트 계획 수정
(1)? 제품 식별 단계에서 제품 기능 및 개발 프로세스는 파일로 기록되어야 합니다. 개발 계획을 수정해야 하는 경우 고객과 논의하여 계획 변경이 프로젝트 진행에 미치는 영향을 고객에게 알려야 합니다.
(2)? 프로젝트 계획의 수정은 통일책임자가 제출하고 사용자 요구 검토 팀장의 승인을 받아야 한다. 수요 변경은 수시로 제출하는 것이 아니라 정기적으로 제출해야 한다.
(3)? 프로그램 변경에 대한 자세한 텍스트 기록을 작성하여 수요 변경의 실제 상황과 개발자가 지불한 비용을 고객에게 알립니다.
일곱. 제품 배송
1 ..? 프로젝트의 사후 감사
프로젝트 개발이 최종 완료되면 개발자에게는 일을 내려놓는 부담으로 간주 될 수 있지만 프로젝트 관리자에게는 종종 중요한 순간입니다. 초기 위험 평가, 비용 예산, 수요 분석, 소프트웨어 설계는 프로젝트를 이 순간으로 유도하기 위한 것으로, 이때 모든 시선이 프로젝트 관리자에게 집중된다. 너는 많은 자질구레한 일이 몇 시간 안에 완성될 것이라는 것을 발견할 수 있을 것이다. 이 순간, 프로젝트 매니저는 마지막 일을 마이크로프로젝트로 간주하기 위해 깨어 있고 냉정해야 한다. 프로젝트 결과, 프로젝트 팀의 효율성, 결과물의 가치를 분석하여 감사 결과를 프로젝트 관리 경험 요약의 일부로 삼습니다.
2.? 품질 평가
프로젝트를 전달하기 전에 품질 검토를 위해 관련 품질 보증 (QA) 부서에 프로젝트를 제출하고 일반적인 사용자에게 제품의 품질을 느끼도록 요청해야 합니다.
3.? 프로젝트의 최종 납품
일반적으로 프로젝트 제공 계약은 비공식적인 검수와 정식 검수로 나뉘어 프로젝트 초기에 체결됩니다. 일반 프로젝트가 완료되면 먼저 비공식 검수를 진행하여 고객이 프로젝트의 품질을 체험하고 피드백을 줄 수 있도록 합니다. 마지막으로, 정식 제품 검수는 고객이 제품 품질을 확인한 후 서면 합의로 진행될 것입니다.
4.? 프로젝트에 대한 최종 보고서
프로젝트가 끝나면 프로젝트의 기록으로 간주될 수 있는 프로젝트에 대한 최종 보고서를 작성해야 하지만, 보고서에는 프로젝트의 모든 측면이 포함될 필요는 없습니다. 일반 최종 보고서에는 다음 측면이 포함되어야합니다.
(1)? 프로젝트를 처음 도입했을 때의 초기 프로젝트 뷰입니다.
(2)? 프로젝트의 가치 평가 및 지원 정보
(3)? 프로젝트 범위
(4)? 프로젝트 개발 프로세스 및 WBS
(5)? 프로젝트 회의록
(6)? 항목 변경 보고서 및 변경 사유입니다.
(7)? 프로젝트 관련 커뮤니케이션 프로세스 파일
(8)? 프로젝트 감사 보고서 및 고객 수락 보고서
(9)? 프로젝트 멤버의 성과 보고서
(10) 프로젝트의 최종 결과