중화사전망 - 자전 검색 - 휴대폰 프로젝트 관리 프로세스
휴대폰 프로젝트 관리 프로세스
1 개요
휴대폰 프로젝트의 해당 프로젝트 관리 사양, 휴대폰 프로젝트 개발, 프로세스 제어 및 시스템 분석
2 프로젝트 프로세스 제어
2. 1 시장 조사 및 프로젝트 포지셔닝
2.1..1? 사용자 요구사항 수집 (사용자 요구사항 수집 및 분석 섹션 참조)
휴대전화 프로젝트에서는 플래너가 사용자를 대신해 수요를 제시하고 소통은 비교적 편리하지만 수요 변경량은 상대적으로 늘었다.
소프트웨어의 경우 사용자의 일상 업무에서 비교적 번거롭고 반복적인 단계를 고려하고 달성 가능한 사용자 요구 사항 및 사용 편의성에 대한 연구를 정리 및 문서화합니다.
2. 1.2? 프로젝트 책임자 지정
프로젝트 개발, 자금 관리, 인력 관리, 일정 관리 및 품질 관리를 담당하는 프로젝트 총괄 관리자를 지정합니다. 프로젝트 책임자는 문제를 미리 발견하고 해결할 수 있는 능력을 갖추어야 하며, 프로젝트 내에서 모든 사람의 능력을 단결하고 발휘하며, 진도 계획과 통제를 잘 하고, 프로젝트 품질을 엄격하게 통제하고 평가해야 한다.
2. 1.3? 필요한 부서를 합리적으로 설정하고 책임자를 지정하다.
휴대전화 프로젝트에서는 부서에 대한 구분 요구가 상대적으로 적지만 각 코너에 해당 담당자를 지정해야 합니다.
2. 1.4? 마케팅 계획을 세우다
광고 및 홍보를 미리 설계하고 프로젝트 특성 및 잠재 사용자를 위한 마케팅 계획을 수립합니다.
대형 행사, 다른 관련 업체들과의 협력 행사, 온라인 포럼, 미디어 홍보 등을 통해 행사를 조직할 수 있다. 구체적인 채택 방식은 투입, 효과, 활동 규모를 상세히 분석한 후 결정해야 한다.
제품의 특성과 장점에 따라 적절한 홍보 방안을 개발하고 사용자의 특성에 따라 적절한 홍보 형식을 개발하다.
마케팅 부분에 관해서는, 모바일 및 노키아가 공동으로 개최하는 모바일 프로그램 대회를 차이나 모바일 체험한 적이 있기 때문에 운영 방식과 부서에 대해 어느 정도 알고 있기 때문에, 필요에 따라 어느 한 쪽을 마케팅 파트너로 선택할 수 있습니다.
게다가, 대학 캠퍼스는 비용이 매우 낮은 활동 기지이며, 동시에 우리는 우수한 인재를 찾아 양성할 수 있다. 적절한 신제품 연구, 게임 개발 대회, 게임 대회를 개최하는 것은 매우 희망적이다.
위의 모든 양식은 기존 자금과 마케팅 요구에 따라 조합될 수 있으며 더 나은 마케팅 효과를 위해 동시에 시작할 수 있습니다. 또한 개발 형식과 시간은 프로젝트의 필요에 따라 조정할 수 있습니다.
2.2 기술 방향 연구 및 결정, 경쟁 업체 데이터 수집
2.2. 1? 사용할 플랫폼, 언어 및 도구를 결정합니다.
현재의 신기술 및 개발 언어, 프로젝트 관리 도구 및 버전 품질 관리 도구를 연구하고, 다양한 언어와 도구의 장단점을 비교하고, 이를 대조표에 정리 및 기록하여 프로젝트 특성, 인력 및 요구 사항에 따라 적절한 개발 도구 및 관리 도구를 선택합니다.
언어 대조표를 개발하다
사용 된 데이터베이스 비교 (안정성은 주로 주류 데이터베이스 응용 프로그램을 고려): 휴대 전화 데이터베이스는 일반 데이터베이스와 다르며 저장 용량이 크지 않으므로 일반적으로 rms 를 사용합니다.
프로젝트 관리 및 품질 관리 도구 비교 (결합 가능)
코드 및 버전 제어 도구: 현재 CVS 또는 ClearCase 를 사용하고 있으며, 상세한 프로젝트 시스템을 저렴한 비용으로 구축해야 하는 경우 CVS 를 버전 제어로 사용하고 Bugzilla 를 테스트 제어 도구로 추가하는 것이 좋습니다. 자금이 허용될 경우 IBM 의 ClearCase 및 ClearQuest 를 사용하여 전체 프로젝트 제어 관리 시스템을 구축하는 것이 좋습니다. 권장 프로젝트는 프로젝트 계획 및 일정 분할에 사용됩니다.
기존 프로젝트 또는 개발 중인 회사의 경우 기존 리소스와 코드를 통합할 때 변경 사항을 최소화하고 현지 상황에 따라 사양 및 품질 관리 시스템을 설정하여 현재 개발 모델에 적응한 사람들이 가능한 한 빨리 새로운 건전한 개발 시스템에 적응하고 변경으로 인한 문제를 최소화할 수 있도록 해야 합니다.
모바일 게임 개발의 특징에 따라 프로젝트가 네트워크 기능을 지원하는지 독립 실행형 게임을 지원하는지 확인해야 합니다. 네트워크의 경우 bluetooth 또는 WAP 기능을 지원하는 것으로 나뉩니다. 독립 실행형 게임의 경우 이미지, 작업 및 스토리지를 계층화하고 사용 가능한 리소스를 정리해야 합니다.
2.2.2? 조직 가용 자원
이용 가능한 모든 자원을 이용하여 개발 진도를 높이고, 이용 가능한 자원과 코드를 정리하고, 관련 * * * 소스 코드와 자원을 찾습니다. 기존의 모든 자원을 정리하고 사용 가능한 부분을 찾아내면 개발 효율성을 효과적으로 향상시킬 수 있을 뿐만 아니라 유용한 경험을 얻을 수 있다.
예를 들어, 모듈 데이터베이스 관리, 복잡한 알고리즘의 기존 엔진을 추가하고 언제든지 사용할 수 있도록 모듈을 패키지화합니다. 개발 과정에서 가능한 한 기존 모듈을 사용하여 비용을 절감하고 오류 발생을 줄입니다.
2.2.3? 상응하는 규범과 기준을 연구하다.
현재 분야에서 사용할 수 있는 국제 및 국내 규범과 표준을 연구하고 해당 규범을 정리하고 번역합니다. 가능한 한 제품을 좀 더 일반적인 규격에 맞추면 향후 제품 홍보 및 제품 업그레이드에도 도움이 됩니다.
2.2.4? 경쟁사 정보 비교
이 분야의 다른 경쟁사의 제품을 수집하고 장점과 특징을 요약합니다. 자신의 상황을 감안하면 비용을 인식하고, 기능점을 선택하고, 자신의 특색을 추가해야 한다. 모든 비교 데이터를 정리하고 프로젝트 문서에 기록할 사람을 지정해야 합니다. 이는 마케팅, 기능 포인트 설계 및 마케팅에 대한 참고 역할을 합니다.
2.2.5? 프로젝트 정보 기록
이 정보를 바탕으로 프로젝트에 사용되는 주요 기술, 플랫폼, 개발 도구 및 프로젝트 관리 도구를 논의 및 문서화하고 경쟁업체와의 비교 데이터 및 관련 사양을 문서화합니다.
2.3 개발 이정표를 개발하고 개발자를 준비하십시오.
2.3. 1? 개발 모드 선택
공사 기간, 자금 등의 수요에 따라 합리적인 개발 모델을 선택하다.
개발 모듈, 기능 포인트 및 구현 주기를 개발합니다.
2.3.2? 개발자를 배정하다
필요에 따라 개발자를 배정하고, 프로젝트에 필요한 총 인원과 각 부서가 프로젝트에 지정한 인원을 기록하고, 각 사람의 작업량과 일정을 추정합니다. 각 개인에 대해 적절한 프로젝트 교육을 실시하여 프로젝트에 참여하는 모든 사람들이 프로젝트에 대해 어느 정도 이해하고 각 부서 직원의 프로젝트에 대한 조언과 의견을 수집할 수 있도록 합니다.
2.3.3? 프로젝트 진행 추적 팀 PTT 구성
프로젝트 핵심 통제팀은 개발부, 디자인부, 테스트부, 미술부의 뛰어난 기술을 갖춘 프로젝트 관리자가 임명한다. 참가자의 최소 30% 를 포함하여 프로젝트 관리자는 가용성 연구원 한 명을 임명하여 프로젝트의 모든 단계에서 사용자 편의성을 평가하고 수정해야 합니다. 핵심 팀에 참여하는 사람은 프로젝트의 핵심 프로그래머, 핵심 디자이너, 핵심 테스터 및 아티스트입니다.
프로젝트 핵심 통제 팀의 주요 기능은 언제든지 프로젝트 진행 상황을 모니터링하고, 각 부서에서 프로젝트 진행 상황을 파악하고, 위험을 예측 및 회피하고, 프로젝트 지연 메커니즘을 처리하고, 프로젝트 이정표를 제어하고, 기술 토론과 교육을 관리하고, 프로젝트의 모든 문제와 협상하는 것입니다.
2.3.4? 가용성 (사용자 친화적) 연구원 지정
가용성 연구원 한 명을 지명하여 시장에서 동종 제품의 장단점을 연구하고, 각 단계의 가용성 검사를 제어하고, 적절한 개선 의견과 건의를 제출하여 제품의 가용성을 확보한다. 그것은 어느 정도의 열정과 창의력, 사용자의 요구에 익숙한 사람들이 사용자의 관점에서 문제를 고려해야 한다. PTT 팀에 참여해야 하는 pre-sales, 제품 설계 또는 개발 부서의 직원이 될 수 있습니다.
2.4 사용자 요구 사항 수집 및 분석
2.4. 1? 사용자 요구사항 수집
SRS 템플리트를 사용하여 수요 출처 표시, 각 수요 표시, 업무 사양 기록, 수요 추적 매트릭스 생성, 수요 문서 검토, 수요에 따른 테스트 케이스 작성, 사용 설명서 작성, 자격 기준 결정 등의 작업을 수행합니다.
1. 시스템과 시스템 외부 도면요소 간의 경계와 인터페이스를 정의하는 간단한 모형인 시스템 연관 다이어그램을 그립니다. 또한 인터페이스를 통한 정보 흐름을 설명합니다.
2. 사용자 인터페이스 프로토타입을 생성하고 개발자 또는 사용자가 수요를 결정할 수 없을 때 사용자 인터페이스 프로토타입을 개발합니다. 사용자는 원형을 평가하여 프로젝트 참여자들이 서로 해결해야 할 문제를 더 잘 이해할 수 있게 됩니다. 요구 사항 문서와 프로토타입 간의 모든 충돌을 찾습니다.
3. 수요의 실현 가능성을 분석하고, 허용된 비용 및 성능 요구 사항에 따라 각 요구 사항을 실현할 수 있는 가능성을 분석하고, 다른 요구 사항과의 충돌, 외부 요인에 대한 의존성, 기술적 장애 등 각 요구 사항 달성과 관련된 위험을 명확히 합니다.
4. 수요의 우선순위를 정하고 분석 방법을 적용하여 사용 사례, 제품 특성 또는 개별 수요의 우선순위를 결정합니다. 우선 순위에 따라 제품 버전에 포함될 기능 또는 요구 사항을 결정합니다. 요구 사항 변경이 허용되면 각 변경 사항이 특정 버전에 추가됩니다. 요구 사항 변경 을 참고하십시오.
5. 수요를 모델링하기 위해 수요의 그래픽 분석 모델은 소프트웨어 수요 사양 설명에 대한 훌륭한 보완 설명입니다. 그들은 부정확하고 일관되지 않고, 누락되고, 중복되는 수요를 찾는 데 도움이 되는 다양한 정보와 관계를 제공할 수 있다. 이러한 모델에는 데이터 흐름 차트, 엔티티 관계 차트, 상태 전환 차트, 대화 상자 차트, 객체 클래스 및 상호 작용 차트가 포함됩니다.
6. 개발자가 통합 데이터 정의를 사용할 수 있도록 시스템에서 사용되는 모든 데이터 항목과 구조의 정의인 데이터 사전을 생성합니다. 요구 사항 단계에서 데이터 사전은 최소한 고객 데이터 항목을 정의하여 고객과 개발 팀이 일관된 정의와 용어를 사용하도록 해야 합니다. 분석 및 설계 도구에는 일반적으로 데이터 사전 구성 요소가 포함됩니다.
7. 품질 기능 확장 (QFD) 사용은 제품 특성과 속성을 고객에 대한 중요성과 연관시키는 고급 시스템 기술입니다. 이 기술은 고객의 가장 관심 있는 기능을 식별할 수 있는 분석 방법을 제공합니다. QFD 는 수요를 세 가지 범주로 나눕니다. 예상 수요, 즉 고객이 언급하지 않을 수도 있지만, 부족한 경우 만족하지 못할 것입니다. 일반 요구 사항 흥분된 수요는 고객에게 놀라움을 가져다 주지만, 실현되지 않으면 책망을 받지 않는다. (윌리엄 셰익스피어, 템페스트, 희망명언)
2.4.2? 수요 변화 통제
수요 변경은 모든 품목 중 가장 일반적이고 비싼 부분이므로 모든 CMM2 이상 버전에는 수요 변경에 대한 자세한 요구사항이 있습니다.
요구 사항 변경을 처리할 때 세부 변경 요구 사항, 프로젝트 핵심 팀 토론 및 의사 결정 후 변경해야 하는 요구 사항의 시간 또는 자본 비용에 대해 사용자와 논의합니다. 합의가 이루어지면 설계 부서는 세부 사양에서 전체 설계를 수행하고 가능한 모듈 변경 사항을 조사합니다. 개발 부서는 설계에 따라 적절히 변경합니다. 모든 변경 사항은 기능 테스트, 통합 테스트에서 시스템 테스트에 이르는 종합적인 테스트가 필요합니다.
각 요구 사항 변경은 프로젝트에 상세하게 기록되고 추적되어야 하며, 마지막으로 프로젝트 요약 섹션에서 변경 통계를 수행해야 합니다.
2.4.3? 사양을 생성합니다
설계, 개발 및 테스트에 대한 참조를 제공하고 최종 사용자 설명서 및 기타 터미널 문서를 추출하는 프로젝트의 가장 완벽한 사양을 생성합니다. PTT 팀은 설계 시나리오를 검토 및 식별하고 문서화합니다. 이후 설계 파일을 변경하는 경우 PTT 팀에서 논의 및 결정하고 수정 이유, 수정 날짜, 수정 등 정보를 상세히 기록해야 합니다.
상세 사양에는 구현해야 하는 모든 사용자 요구 사항 기능점, 인력 할당, 예정된 완료 시간, 작업량, 위험 평가 및 마일스톤 설정이 포함되어야 합니다. 각 기능점에 대해 한 명의 책임자가 매주 진도가 예정된 목표에 도달했는지 점검해야 한다. 기능 요구 사항이 적절하게 변경되었는지 여부는 요구 사항 변경 관리 섹션에 설명되어 있습니다.
2.5 개요 설계 및 프로토타입 설계
아이콘 및 사용자 인터페이스를 설계합니다.
전체 설계를 수행하고, 제품 프로토타입을 제작하고 (예술가와 디자인 부서의 참여로 개발 부서의 도움을 받아), 사용자에게 제공하고, 순환 개선을 위해 사용자 피드백을 수집합니다.
2.6 데이터 구조, 스토리지 설계
기존 엔터프라이즈 설계 데이터 구조에 대한 자세한 사양 요구 사항을 활용합니다. 가능한 한 데이터 구조를 단순화하고, 합리적인 논리적 연계를 실현하며, 복잡성을 줄입니다. 데이터 저장 구조는 실제 상황에 따라 작성되어야 합니다.
2.7 기능 상세 설계
개발 부서에서 완성한 상세한 설계에는 기능점에 대한 자세한 이해, 알고리즘 설계, 데이터 구조 설계 및 상세한 기능 흐름도가 포함됩니다. 모든 섹션은 개발 사양 및 문서 사양의 요구 사항을 엄격하게 충족해야 합니다. 통합 문서 사양에 따라 알고리즘 설계, 프로세스 설계 및 데이터 구조 설계를 포함한 상세한 설계 문서를 작성합니다.
품질 관리 부서는 상세 설계를 검토 및 수정하고 PTT 팀은 상세 설계를 검토합니다. 확인 후 문서를 상세히 설계하며 변경이 있을 경우 PTT 팀에서 논의하고 결정해야 합니다. 상세한 설계 문서는 프로그램 품질을 검사하기 위한 테스트 및 품질 관리의 기초로 사용됩니다.
2.8 기능 구현 및 기능 테스트
자세한 설계 및 코드 작성 사양에 따라 코드 작성 작업을 완료하여 각 요구 사항에 설명된 기능 포인트를 구현합니다.
각 기능 포인트를 테스트합니다.
모든 코드의 사용 편의성, 알고리즘 복잡성 및 사양을 확인하십시오.
코드 문서 컴파일을 완료합니다.
사용자 설명을 작성합니다.
프로젝트 개선 팀은 개발 프로세스를 감독하고 지속적으로 개선합니다.
2.9 통합 테스트 및 시스템 테스트
테스트 부서에서 수행한 통합 및 시스템 테스트는 테스트 환경에서 수행해야 합니다. 관련 기능 포인트를 디버깅, 테스트 및 수정합니다.
시스템 통합, 시스템의 하드웨어, 소프트웨어 및 스트레스 테스트, 플랫폼 및 소프트웨어 버전이 다른 클라이언트 테스트
오류 제어 도구를 사용하여 오류를 기록하고 수정합니다.
사용자 환경을 시뮬레이션하여 전체 프로세스 테스트를 수행하고 일부 사용자 또는 잠재 사용자를 베타 버전 테스트에 초대합니다.
발생한 오류를 분류하고 기록하며 매주 모든 오류를 추적합니다. 우선 순위가 높으면 회의를 임시로 구성하여 논의하고 처리할 수 있습니다. 프로젝트 관리 또는 개발 책임자는 모든 오류를 책임지는 사람을 지정해야 하며, 코드 오류율이 일정 비율보다 낮은지 확인하기 위해 언제든지 닫히지 않은 오류를 추적해야 합니다. 제품 생산의 오류율을 엄격히 제한하다.
2. 10 제품 관련 홍보 및 제품 제공
제품 기능 및 프로젝트 시작 시 제정된 계획에 따라 제품 홍보 및 제품 설명을 수행합니다.
관련 제품 특허 및 인쇄 제품을 발표하다.
제품을 사용자에게 전달하다.
2. 1 1 회귀 테스트 및 프로젝트 요약
회귀 테스트, 반복 테스트 및 관련 제품 업그레이드를 수행합니다.
프로젝트를 요약하고, 프로젝트에서 재사용 가능한 모든 리소스와 경험을 기록하고, 프로젝트 진행에 영향을 미치는 이벤트와 원인을 분석 및 집계하며, 향후 프로젝트에 대한 경험을 기록하고 제공합니다.
2. 12 기술 교육 및 교류
프로젝트 과정에서 각 부서, 모듈 간의 충분한 소통과 교류를 실현하기 위해 가장 꺼리는 것은 메시지 폐쇄와 폐업이다. 의사 소통 부족은 의심 할 여지없이 건전한 프로젝트의 잠재적 위험입니다.
프로젝트 책임자는 실제 상황에 따라 기술자를 배정하여 기술 교육을 실시해야 하며, 각 부서의 기술 알고리즘의 어려움, 프로세스 설계, 인터페이스 설계 등에 대해 다른 부서의 인원은 실제 상황에 따라 질문을 할 것이다. 프로젝트 초기에는 전체 프로세스가 주요 교육 주제였습니다. 프로젝트가 진행됨에 따라 미술 디자인, 모듈 구분, 데이터 구조 설계, 알고리즘 구현, 품질 관리 등의 주제를 점진적으로 도입하여 프로젝트의 각 부서에서 전체 프로젝트의 프로세스와 기술 구현을 더 잘 이해할 수 있도록 합니다.
강사의 성과 기록은 평가와 연결되어 모든 사람의 참여 열정을 높인다. 훈련에서 중요한 역할을 하는 사람들에게 칭찬을 하다.
프로젝트 관리자는 프로젝트 과정에서 다리 역할을 하고 각 부서의 직원들과 수시로 소통해야 한다. 그들은 프로젝트의 일상적인 진전을 파악해야 할 뿐만 아니라 상황에 따라 위험을 예측하고 피해야 한다.