Dell 의 App 표준화 개발 프로세스에 대해 자세히 설명하기 위해 10 년간의 소프트웨어 애플리케이션 개발 경험을 기반으로 소프트웨어를 구축하고자 합니다.
업무의 성격에 따라, 우리는 먼저 App 개발을 사전 판매, 판매 중, 애프터의 세 단계로 나누었다. 각 단계는 여러 단계로 구성되며, 점진적으로 진행되며, 최종적으로 프로젝트 개발을 완료합니다.
첫째, 예매
1. 수요 커뮤니케이션
Dell 제품 관리자는 대상 고객에게 프로젝트 요구 사항을 제시할 때 pre-sales 컨설턴트와 함께 고객과 의사 소통합니다. 어떤 고객들은 보통 자신의 요구를 크게 고려하고 있다. 이때 Dell 의 전문 제품 관리자가 프로젝트의 구체적인 요구 사항과 기능 목록을 정리하여 고객이 아직 고려하지 않았거나 실현할 수 있는 요구 사항을 분석할 수 있도록 지원해야 합니다.
2. 프로젝트 타당성 분석
고객과 제품 관리자 모두 프로젝트의 기능 특성, 사용자 불만 사항, 업계 요구 사항 및 사용자에게 제공되는 서비스 내용을 명확하게 이해하고, 각 시점, 특히 고객 불만 사항에 대한 상세한 조사 및 분석을 수행해야 합니다. 개발된 앱에 많은 문제점이 있다면 개발이 성공해도 오래가지 못할 것이다. 모든 App 의 최종 성공은 사용자 기반이기 때문입니다.
(프로젝트 솔루션 희망)
3. 기능 프로세스 빗질
(1) 분류 아키텍처
건물을 완성하는 과정은 집을 짓고 기초를 놓는 것과 같다. 제품 관리자는 제품의 전체 기능 아키텍처를 빗질하고, 핵심 콘텐츠를 빗질하며, 제품의 기반을 구축하고, 고객이 향후 이를 바탕으로 보다 편리하고 확장 가능하도록 합니다.
(2) 기능 목록
다음으로 제품 관리자는 각 모듈의 세부 사항과 특정 기능 (예: "등록" 이 사용하는 등록 방법, SMS 인증 코드 또는 제 3 자 등록) 과 같은 보다 자세한 기능 목록을 작성합니다. 이 부분은 네가 가공물을 인테리어하는 것과 같으니, 우선 문과 창문 추가, 수력 개조 등을 고려해야 한다.
(3) 빗질 과정
제품 관리자는 고객의 요구에 따라 제품의 핵심 업무를 정리하고 고객이 기존 프로세스를 인터넷에서 운영할 수 있는지 여부를 미리 고려하도록 돕습니다. 예를 들어, 전통적인 산업에서 인터넷으로 전환하는 기업 고객의 경우, 제품 관리자는 모바일 인터넷의 전문적인 관점에서 고객이 프로세스를 정리하고 최적화할 수 있도록 지원합니다.
(프로젝트의 기능 목록 희망)
4. 맞춤형 구현 계획
요구 사항 문서가 확인되면 사전 영업 컨설턴트는 고객 요구 사항에 따라 프로젝트 팀의 인력 배치, 시간 노드 배치, 기술 시나리오 등을 포함한 일련의 App 개발 시나리오 및 견적 목록을 맞춤형으로 구성합니다. 고객이 확인하면 정식 계약을 시작할 수 있다.
둘째, 판매.
1. 제품 디자인
(1) 프로토타입 설계 및 검토
제품 관리자가 요구 사항 문서에 따라 기능의 구조 레이아웃, 각 페이지의 디자인, 인터페이스 상호 작용 논리의 디자인 등을 포함한 고화질 프로토타입을 설계할 수 있기를 바랍니다. 하이파이 프로토타입은 요구 사항 문서를 보다 직관적인 소프트웨어 데모 버전으로 변환하여 더 많은 세부 사항을 확인하고, 프로젝트 개발의 효과를 보장하며, 의사 소통이 원활하지 않거나 부적절한 의사 소통으로 인한 분쟁을 방지합니다.
(프로젝트의 하이파이 원형 희망)
(2)UI 설계 및 검토
프로토타입 설계가 확정되면 UI 디자이너는 제품 및 프로토타입의 위치에 따라 UI 인터페이스 렌더링도를 설계합니다. 이는 프로토타입을 기반으로 색상을 추가하는 것과 같습니다. 제품의 전체 스타일, 기능 시각화, 대화형 설계, 조판 레이아웃을 결정하여 고객이 App 의 프로토타입을 보다 직관적으로 볼 수 있도록 합니다. 복원도가 높아서 사용자에게 더 높은 경험을 제공할 수 있습니다. 완전한 App 는 사용자의 시선을 사로잡는 아이디어가 필요합니다. 이를 위해서는 제품 관리자와 UI 디자이너가 창의적인 기획에 대한 독창적인 아이디어를 가지고 있어야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언)
(3) 수요에 대한 상세한 설명
제품 관리자는 프로젝트 관리자와 요구 사항 및 원형 차트의 UI 다이어그램을 연결하여 고객의 자세한 요구 사항, 기능 섹션 및 점프 페이지를 설명합니다. 프로젝트 관리자는 이러한 요구 사항과 그림을 엔지니어가 더 쉽게 이해할 수 있는 언어로 번역할 수 있도록 요구 사항을 구체화해야 합니다. 그런 다음 프로젝트 팀은 프로토타입 UI 그림으로 기술 회의를 열어 프로젝트 요구 사항을 통일적으로 설명합니다.
(4) 기술 표준 개발
프로젝트 관리자는 전체 프로젝트의 요구 사항을 파악한 후 기본 개발 또는 혼합 개발, Java 또는 PHP, 타사 선택 등 확장 가능하고 지속 가능한 기술 프레임워크 시나리오를 제공합니다.
2. 민첩한 개발
(1) 반복 개발 계획
프로젝트 팀은 공식적으로 프로젝트 개발에 들어가기 전에 프로젝트 자체를 평가하고 R&D 주기, 테스트 시간, 출시 전 시간에 대한 예비 판단을 내립니다. 그런 다음 프로젝트 기능을 분해하여 프로젝트 요구 사항을 4-5 개의 노드로 나눕니다. 예를 들어 1 -9 번은 첫 번째 기능 모듈이고 10-15 번은 두 번째 기능 모듈입니다.
(2) 노드 연구 개발
프로젝트 팀은 수요 분석에 따라 정리된 기능 데이터 처리 상황을 분석하고, 합리적인 데이터베이스 테이블 구조를 구축하고, 데이터 알고리즘을 최적화하고, 데이터 처리 효율성을 높이고, 사후 응용 과정에서 데이터의 보안, 정확성, 안정성 및 적시성을 보장합니다.
전체 App 프로젝트는 일반적으로 다음 모듈로 구성됩니다.
① 서버쪽: 인터페이스 프로토콜 문서 작성, 서버 환경 구축 (국내 일반 아리운 서버, 해외 일반 아마존), 데이터베이스 설계, API 인터페이스 작성, 비즈니스 기능 및 인터페이스 패키징, 백그라운드 개발 관리
②App 측: UI 설계도 개발 인터페이스에 따르면 UI 개발이 완료된 후 서버 인터페이스를 도킹하고, 서버 인터페이스를 통해 데이터를 얻고, 기능 논리 코드를 작성합니다.
③ 웹 관리측: 프런트 엔드의 비즈니스 논리에 따라 백그라운드에는 해당 기능이 있으며 기능 논리 코드를 작성해야 합니다.
프로젝트의 R&D 단계에서 프로젝트 관리자는 핵심 기술 연구, 프로세스 지원 및 진행 상황 추적, 프로젝트 팀은 매주 고객에게 개발 진행 상황을 보고하여 고객이 소프트웨어를 신청할 수 있도록 지원합니다.
(3) 단위 테스트
이전 개발 과정에서 엔지니어는 처음부터 끝까지 모든 App 기능을 개발한 다음 시스템 테스트를 수행하면 한 버그를 수정해도 다른 곳에 새 버그가 생기고, 새 기능을 확장하여 이전 코드의 버그를 일으키는 등의 문제가 발생하기 쉽습니다. 이때 단위 테스트가 필요합니다.
간단히 말해서, 단위 테스트는 한 엔지니어가 노드 개발을 하고, 테스트 엔지니어가 한 노드를 테스트함으로써 오래된 비즈니스 논리가 손상되었는지 명확하게 알 수 있으며, 매우 낮은 수준의 오류를 쉽게 제거할 수 있습니다. 회귀 오류의 가능성과 디버깅 시간을 크게 줄이고 코드 품질을 향상시킵니다.
(4) 시스템 테스트
App 기능 개발이 완료되면 테스터는 전체 프로젝트에 대해 시스템 테스트를 수행합니다. 프로젝트 테스트 디버깅을 완료하는 가장 중요한 부분은 문제 관리, 각 버그의 진행 상황 및 상태 추적, 할당 대상, 우선 순위, 복구 상태 등입니다. , 품질 보증으로 문제 처리를 완료합니다.
App 컨텐츠 테스트, App 성능 테스트, App 기능 테스트, App 시각화 테스트, 디버깅 및 복구 버그를 포함한 제품 지향 플랫폼 다중 모델 동기화 테스트. 테스트를 통과한 후 버그가 없는지 확인한 후 고객과 소통하고 검수를 시작한 후 고객이 다시 테스트를 진행하여 수정 의견을 제시했다.
3. 온라인 배송
(1) 사용자 경험 테스트
20 18 년, 모바일 인터넷 업계 최초의' 기능 테스트 오류 서비스에서 운영 실습 서비스' 인 새로운' 혁신적인 인재 게시물' 을 구축하고자 합니다.
사용자 체험관은 사용자 체험을 테스트하고, 사용자 체험, 제품, 가용성, 안값, App 디자인 복원도 등 여러 차원에서 체험식 테스트를 실시하고, 실제 사전 시드 데이터를 백그라운드로 업로드하여 전체 App 의 콘텐츠를 가득 채우고 상호 작용하는 것을 목표로 하고 있습니다. 사용자 경험 테스트는 프로젝트 자체의 사용자 커뮤니티와 운영 논리를 통해 고객이 전체 App 를 만드는 데 도움을 줍니다.
(2) 온라인 배포
코드 개발 테스트가 완료되면 온라인 후기 단계로 들어갑니다.
1 공식 서버 배포: 데이터베이스 및 백그라운드 시스템을 공식 서버에 배포하고 공식 온라인 데이터를 app 시스템 배경에 입력합니다.
(2) 소프트웨어 저작권, 애플리케이션 설명, App 인터페이스 스크린샷, 패키지 버전 등과 같은 선반 관련 자료를 준비합니다.
(3) 시장에 App 출시: App 포트 선택에 따라 iOS 또는 안드로이드 애플리케이션 시장 출시.
① 안드로이드: 관련된 응용 시장이 더 많습니다. 주류 시장에는 텐센트 앱스토어, 휴대폰 바이두 조수, 360 휴대폰 조수, 9 1 휴대폰 조수가 있습니다. 고객 속성 및 트래픽은 애플리케이션 시장마다 다르며 고객 요구 사항 및 프로젝트 실제 상황에 따라 선택해야 합니다. 일반적으로 1-2 일 (영업일 기준) 이내에 승인 및 온라인 상태가 가능합니다.
②iOS: App Store 에 게시한 후 제출 후 보통 5 일 (영업일 기준) 정도 걸려야 선반을 승인할 수 있습니다. App Store 감사는 최신 출시 요구 사항 충족 여부, 가상 통화 포함 여부, 최신 환경 지원 여부 등 여러 가지 문제로 인해 감사 통과 여부가 결정됩니다.
하지만 이런 상황이 발생할 수 있습니다. 예를 들어 App 에 세 가지 문제가 있어 실패하는 경우, App Store 는 그 중 한 가지 문제만 발견하면 통과하지 않고, 세 가지 문제를 모두 찾아내지 않고 왜 거절했는지 알려주기 때문에 경험이 없다면 몇 달이 걸릴 가능성이 높습니다.
③ 애플릿을 위챗 위챗 공식 계정에 발표한다. 애플릿을 위챗 팀에 제출하여 심사를 해야 한다. 보통 1-2 일 (영업일 기준) 이내에 온라인 상태로 만들 수 있습니다.
(3) 소스 코드 제공
APP 의 개발 및 테스트가 온라인 상태가 되면 최종 수락 및 인도가 필요합니다. 즉, 계약 약정에 따라 소스 코드, 설명 문서, 운영 문서 등과 같은 모든 관련 자료를 고객에게 전달해야 합니다.
다음을 포함하지만 이에 국한되지는 않습니다.
① 모든 프런트엔드 및 백엔드 프로젝트에 대한 최신 소스 코드 (주석 포함)
② 데이터베이스 설계 문서
③API 설계 문서
④ 모든 개발자 계정 정보.
⑤ 테스트 문서
⑥ 프로토 타입 디자인 초안
⑦UI 디자인 초안
⑧ 프로젝트 관련 문서 및 기타 정보.
(4) 프로젝트 운영 교육
소스 코드를 전달할 때 프로젝트 관리자가 쿠폰 발행 방법, 드라이브 확인 방법, 사용자 등록 확인 방법 등 프로젝트의 모든 기능과 운영에 대한 교육을 고객에게 제공하기를 바랍니다. 또한 브랜드 디자이너와 뉴미디어 운영자에게 고객의 요구에 따라 온라인 포스터 및 뉴미디어 운영 프로그램을 디자인하도록 요청합니다.
셋째, 판매 후
1. 조기 유지 관리
일반 앱은 개발 후 유지 보수가 필요합니다. 상대적으로 안정된 단계에 이르렀더라도 휴대전화 시스템이 업그레이드되거나 장기간 사용됨에 따라 작은 문제나 숨겨진 버그가 생길 수 있다.
클럽이 고객에게 3 개월의 유지 보수 기간을 무료로 제공하기를 바랍니다. 한 프로젝트가 본격적으로 운영에 투입된 지 3 개월 정도 되었을 때 전반적인 운영 모델과 일부 기능상의 결함이 분명해졌다. 다음으로 app 를 계속 운영하려면 기능 모듈을 반복적으로 개발하고 최적화해야 합니다.
이 기간 동안 고객의 질문에 답하고, 소프트웨어 사용 및 업로드 내용, 수정 프로그램 버그 및 비상 사태 후 긴급 유지 관리를 안내합니다.
2. 사용자 정의 업데이트
App 가 시장에 출시되면 사용자와 시장 자체의 피드백을 받아 운영 전략을 수정하거나 조정하는 방법을 알 수 있습니다. 현재 시스템 기능이 프로젝트 요구사항을 충족하지 못할 경우 새 버전 기능의 반복 문제, 즉 project 2.0 개발을 계획해야 합니다.
고객의 맞춤형 업데이트, 즉 수요 커뮤니케이션, 타당성 분석, 기능 프로세스 빗질, 맞춤형 구현 시나리오 등 App 개발 초기 단계에서 수행한 "사전 판매" 작업을 계속하고자 합니다.
반복 시나리오는 일반적으로 다음 두 가지 사항을 기준으로 합니다.
① 불완전한 버그
예를 들어, 온라인 App 가 실행 중에 발견한 일부 버그 또는 일부 논리 오류는 이러한 논리 오류와 기능 버그를 수정하려면 App 를 반복해야 합니다.
②App 데이터 분석
데이터는 매우 중요한 척도입니다. 자원, 사용자 활성화율, 전환율, 유지율, 사용자가 다른 기능을 사용하는 비율, App 각 부분의 손실 등을 분석하여 App 경험에 큰 영향을 미치는 지표를 찾아 자체 기능 설계의 장단점을 분석하여 기능 버전 반복을 수행합니다.
3. 반복 개발
마찬가지로, 프로젝트가 반복적으로 개발되면 제품 설계, 민첩한 개발, 온라인 배송 등 모든 제품 수명 주기를 포함하여' 중간 판매' 의 전 과정을 다시 한 번 거치게 됩니다.
4. 프로젝트 유지 보수 반환 방문
일정 기간 동안 프로젝트를 운영한 후 (무료 유지 보수 기간 종료), 고객에게 다시 방문하여 운영 상황을 문의하고자 합니다. 물론, 후속 고객이 운영 및 유지 보수 지원을 계속 제공해야 하는 경우 App 운영 과정에서 우리가 시대와 보조를 맞추고 업데이트를 유지 관리해야 App 가 지속적으로 새로워질 수 있기 때문에 매우 기쁩니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 운영, 유지 관리, 유지 관리, 유지 관리, 유지 관리)
5. 뉴미디어 운영
앱이 성공적으로 온라인 상태가 되면 기업의 운영 홍보를 통해 사용자 수를 늘리고 장기적으로 운영할 수 있다. 운영보급 방식은 여러 가지가 있고, 오프라인 보급, 광고, 뉴미디어 운영보급 등이 있다.
친밀한 희망은 10 년의 경험과 시장 현황에 따라 비교적 저렴한 비용으로 새로운 미디어를 홍보하도록 고객을 추천한다.
위의 App 개발 프로세스의 관점에서 볼 때 각 프로젝트 개발은 위의 3 단계, 22 단계를 거쳐야합니다. 이는 실제로 더 높은 수준의 프로젝트 품질을 달성 할 수있는 완전한 파이프 라인입니다. 그런데 어떻게 프로세스의 원활함을 보장할 수 있을까요? 프로젝트 구성원의 생산성을 극대화하려면 어떻게 해야 합니까? 이것은 개발 회사의 전문성과 프로젝트 구성원의 계획 능력을 시험해야 한다.
앞서 언급했듯이 App 개발 시간도 App 개발 가격에 영향을 미치기 때문에 App 의 표준 개발 프로세스를 이해해야 합니다.
App 소프트웨어를 개발하거나 보다 자세한 개발 프로세스, 개발 계획, 견적 등에 대해 알고 싶다면 왕희 소프트웨어에 문의해 주시기 바랍니다. 전문 사전 영업 컨설턴트와 제품 관리자가 App 에 대한 자세한 답변을 드릴 것입니다.