일반적으로 회사에서 소프트웨어를 개발할 때 프로젝트 개발 작업은 기본 및 사용자 정의라는 두 가지 병렬 방식으로 수행됩니다. 어떤 회사이든 더 나은 품질의 제품을 생산하기 위해서는 성숙한 제품 개발 프로세스 시스템을 따라야 합니다. 따라서 프로젝트가 많은 경우 기준 제품이 사용자의 일반적인 요구 사항을 최대한 많이 수집하고 사용자 정의 프로젝트 진행에 대한 기술 지원을 제공하며 많은 수를 줄일 수 있도록 사용자 정의 전 기준선과 마일스톤을 합리적으로 배열해야 합니다. 사용자 정의 프로젝트의 코드 변경으로 인해 새 모듈을 추가해야 합니다. 또한 제품 개발 프로세스 시스템도 비즈니스의 실제 시간 요구 사항에 따라 변경되어야 합니다. 폭포수 방식이나 애자일 방식을 고수하지 말고 모든 것을 자신에게 맞는 방식으로 관리해야 합니다. 신발이 자신의 발에 맞는지 아닌지는 발만이 알 수 있습니다.
여기에서는 기본 제품 개발 프로세스를 프로세스 설명의 기초로 사용합니다. 아래에 설명된 각 단계에 대해 프로젝트 실행 전에 각 단계의 목표를 명확하게 정의하고, 계획을 지정하고, 적시에 의사소통하고, 모든 회원이 프로젝트에 대해 일관되게 이해하고 있는지 확인하세요.
프로젝트 시작 회의의 목적은 제품 개발 프로젝트의 목표를 명확히 하는 것입니다. 목표와 계획은 서로를 보완하며, 계획의 효과는 목표 달성에 영향을 미칩니다. 따라서 목표를 실행할 때 자신의 실행 계획과 목표를 보다 효과적으로 달성할 수 있는 방법에 대해 명확하게 생각하십시오. 이는 모든 사람이 세부적으로 명확히 해야 할 질문입니다. 그렇지 않으면 불명확하거나 너무 높은 목표가 실제 성과에 영향을 미치게 됩니다. 프로젝트.
프로젝트 시작 회의에서는 프로젝트 목표, 단계 구분, 조직 구조, 관리 프로세스 및 기타 주요 사항을 설명해야 합니다. 그리고 이러한 내용을 팀이 이해할 수 있도록 고정된 형식과 샘플 텍스트를 사용하여 PPT로 작성하는 것이 좋습니다. 또는 회사가 표준을 공동으로 준수할 수 있는 경우) 모두가 합의에 도달해야 합니다. 핵심 역할을 선임하기 위해서는 관련 리더와 주요 프로젝트 이해관계자의 의견을 사전에 청취하는 것도 필요합니다.
소프트웨어 개발을 시작하기 전에 비용과 얻은 가치의 비교, 즉 ROI(투자 수익률)를 결정해야 합니다. 소프트웨어의 생존을 지원하려면 자원을 배치해야 합니다. 이는 요구사항에 대한 가장 원시적인 설명입니다.
사용자 요구와 제품 요구가 모두 필요한 이유는 무엇입니까?
둘 사이에는 차이가 있기 때문에 사용자 요구 사항은 사용자가 제시하며 일반적으로 기술은 설명되지 않고 제품 목표만 설명됩니다. 제품 요구사항은 사용자 요구를 변형한 기술 구현 요구사항으로, 사용자가 제안한 제품 목표를 세분화하고, 각 특정 기능 포인트를 요약한 후, 각 기능 포인트를 다양한 운영 프로세스로 세분화하는 것이 필요합니다.
사용자의 요구와 제품의 요구는 차이가 나기 쉽습니다. 왜냐하면 모든 사람이 요구를 이야기하지만 출발점이 다르기 때문에 양측의 관심사와 사고 방식이 다를 수 있기 때문입니다. 사용자는 시스템이 비즈니스 프로세스를 어떻게 지원하는지에 초점을 맞춰야 하며, 그 이면의 요구는 "비즈니스 목표 달성"입니다. 기술 직원은 합리적인 기술 솔루션에 중점을 두고 있으며, 그 뒤에 있는 요구 사항은 "워크로드", "구현 난이도" 및 "시스템 성능"입니다.
제품 관리자나 프로젝트 요구사항 제안자가 이 프로젝트를 원하는 이유가 무엇인지 파악해야 합니까? 이는 가장 필수적인 비즈니스 요구 사항입니다. 수요 분석에 의해 결정된 비즈니스 요구는 모두 비즈니스 요구에서 파생되며 비즈니스 요구를 충족해야 합니다.
제품 요구 사항에는 일반적으로 제품 요구 사항 사양 및 제품 요구 사항 매트릭스가 포함됩니다. 제품 요구 사항 매트릭스에는 일반적으로 하위 시스템, 기능 세트 및 실행 단위의 구조에 따라 모든 기능 요구 사항이 나열됩니다. 각 열은 각 기능의 작업 단계와 각 단계의 작업 부하에 해당합니다.
제품 요구사항이 작성된 후에는 검토가 필요합니다. 요구 사항 검토 회의에서 세부적인 제품 및 기술 검토 요구 사항이 완료됩니까? 제품 기능에 대한 일반적인 시나리오는 무엇입니까? 폐쇄 루프를 형성하고 있습니까? 특이한 시나리오는 무엇입니까? 사려깊은가?
요구사항 검토 후 개발 및 테스트 리더는 각각 기술 솔루션과 테스트 사례를 작성합니다.
기술 계획 검토, 개발 리더는 다른 시스템 담당자를 모아 논의합니다. 기술 계획에는 비즈니스 흐름도와 시퀀스 다이어그램이 있어야 합니다 비즈니스 흐름도는 비즈니스에 대한 개발 이해를 정리하는 것입니다. 그리고 그것이 일관된 요구를 충족하는지 여부. 시퀀스 다이어그램은 이 요구 사항과 관련된 시스템 상호 작용을 분류하는 것입니다. 기술 계획을 검토하고 승인한 후 작업량과 배송 시간을 확정하고 제품에 피드백합니다.
설계 단계의 목표는 주로 개발할 시스템의 아키텍처를 분석 및 설계하고 시스템 아키텍처의 기준을 확립하여 후속 구현 작업을 위한 안정적인 기반을 제공하는 것입니다.
설계 단계에는 시스템 아키텍처의 출력이 포함됩니다. 좋은 시스템 아키텍처 설계는 인간이 비즈니스 논리를 분류하고 핵심 요구 사항을 파악하고, 안정적이고 확장 가능한 비즈니스 시스템을 설계하고, 비즈니스 개발 주기 및 개발 비용을 평가하고, 효과적으로 위험을 방지하는 데 도움이 될 수 있습니다. . 예를 들어 집을 지을 때 건축 도면이 있어야만 건축 기간을 계산할 수 있습니다.
전체 설계는 전체 시스템의 프레임워크 설계로 매우 중요하며 일반적인 상황에서는 생략할 수 없습니다. (기본 프로젝트가 설계되었으므로 전체 설계는 유지 관리 프로젝트에만 생략 가능) 디자인 먼저. 디자인의 첫 번째 단계이며, 말보다 카트를 먼저 두는 것은 절대 허용되지 않으며, 코딩을 먼저 한 다음 디자인하는 것은 허용되지 않습니다. 이것이 소프트웨어 개발에서 두 번째로 큰 문제점입니다(첫 번째는 불분명합니다.) 요구 사항 및 요구 사항의 임의 변경!) .
전체 디자인은 세 단계로 나뉩니다:
1단계: 초기 디자인. 주어진 데이터 흐름도의 검토 및 개선을 바탕으로 초기 모듈 구조 다이어그램으로 변환됩니다.
두 번째 단계: 세련된 디자인. 모듈의 "높은 응집력과 낮은 결합" 원칙에 따라 초기 모듈 구조 다이어그램을 개선하고 각 모듈의 글로벌 데이터 구조와 인터페이스를 설계했습니다.
세 번째 단계: 설계 검토 단계, 처음 두 단계에서 얻은 상위 수준의 소프트웨어 구조를 검토하고 필요한 경우 소프트웨어 구조를 일부 개선해야 할 수도 있습니다.
모듈 나누기, 작업 할당, 호출 관계 정의에 중점을 둡니다. 이 단계에서는 모듈 간의 인터페이스와 매개변수 전송을 매우 상세하고 명확하게 해야 하며, 후속 설계에서 혼란이나 오해를 피하기 위해 엄격한 데이터 사전을 작성해야 합니다. 개요 디자인은 일반적으로 한 번에 완료되지 않고 반복적인 구조 조정이 필요합니다. 일반적인 조정은 중복된 기능이 있는 모듈을 병합하거나 재사용할 수 있는 모듈로 분해하는 것입니다. 개요 설계 단계에서는 재사용 가능한 모듈을 최대한 추출하고 합리적인 구조 시스템을 구축하며 후속 링크의 작업량을 절약해야 합니다.
개요 디자인 문서의 가장 중요한 부분은 계층적 데이터 흐름 다이어그램, 구조 다이어그램, 데이터 사전 및 해당 텍스트 설명입니다. 개요 설계 문서를 기반으로 각 모듈의 세부 설계를 병렬적으로 수행할 수 있습니다. 상세 설계상세 설계 단계는 개요 설계 단계의 분해를 바탕으로 각 모듈 내의 알고리즘과 프로세스를 설계하고, 각 모듈에서 완성되는 기능에 대한 구체적인 설명을 제공하고, 기능 설명을 정확한 구조. 변환 과정에 대한 설명. 이 세부 설계 단계에서는 병렬 설계를 위해 각 모듈을 다른 사람들에게 할당할 수 있습니다. 디자이너의 작업 개체는 개요 디자인에 의해 할당된 로컬 작업과 외부 인터페이스를 기반으로 모듈의 알고리즘, 프로세스, 상태 전환 등을 디자인하고 표현합니다.
여기서 주의할 점은 구조적 조정(서브모듈 분해 등)이 필요하다고 판단되는 경우에는 개략 설계 단계로 돌아가 조정 내용을 개략 설계 문서에 반영해야 한다는 점입니다. 인사 없이는 그 자리에서 해결할 수 없습니다. 세부 설계 문서에서 가장 중요한 부분은 모듈 흐름도, 상태 차트, 로컬 변수 및 해당 텍스트 설명 등입니다. 하나의 모듈은 세부 설계 문서에 해당합니다. 소프트웨어 구조 다이어그램은 일반적으로 개요 설계 단계에서 얻습니다. 세부 설계 단계에서 일반적으로 사용되는 설명 방법에는 흐름도, N-S 다이어그램, PAD 다이어그램, 의사 코드 등이 있습니다. 세부 설계의 목적은 특정 모듈의 내부 처리 흐름, 개발 방법 및 코딩 기술을 설명하는 것입니다. 일반적으로 세부 디자인은
프로젝트 소개, 모듈 설명(각 모듈의 내부 프로세스, 기능, 로직, 소비 및 해결되지 않은 문제를 구체적으로 설명), 인터페이스 디자인(내부 인터페이스 및 외부 인터페이스 포함), 데이터 구조 설계(물리적 구조 및 논리적 구조 포함), 특수 처리 및 기타 부분. 소프트웨어의 세부 설계는 궁극적으로 소프트웨어 시스템 각 부분의 특정 설계 방법, 논리 및 기능에 대한 서면 설명입니다. 이런 식으로 구현 과정에서 코더는 원칙적으로 이에 따라 엄격하게 코드를 구현할 수 있습니다. 코드 작성
코드 작성 시 다음 원칙을 따를 수 있습니다: 먼저 핵심 모듈의 스트레스 테스트를 하세요: 많은 프로그래머들은 작업을 마친 다음 성능 테스트를 하기 전에 온라인에 접속할 때까지 기다립니다. 큰 두통. 물론 나중에 온라인에 올라올 때 성능 테스트도 하겠지만, 아직 초기 단계에서는 매우 중요하다고 생각합니다. 물론 이를 잘하려면 비즈니스에 대한 이해가 필요하며 비즈니스 압박이 어디에 있는지, 비즈니스 요청의 초점이 어디에 있는지 알아야 합니다. 제품 관리자가 설명하지 않으면 명확하게 질문해야 합니다. . 프로세스를 제어할 수 있는지 확인하세요: 코드가 실행될 때 중간 출력이 유지되어야 합니다. 예를 들어 100,000개의 로그가 처리될 때마다 처리된 로그 항목 수와 현재 상태를 기록하는 상태 로그가 작성됩니다. 실행 시간. Log more: 제가 작성한 코드가 별로 만족스럽지 못한 경우가 많습니다. 예를 들어 특정 처리 효율성이 충분히 최적화되지 않았거나 특정 처리 방법이 충분히 간결하지 않거나 확장성이 상대적으로 낮습니다. , 그리고 코드가 매우 정신적으로 작성되었습니다. 그러나 이것이 출시 초기 단계의 초점이 아니라는 점을 고려하여 짧은 시간 내에 가장 합리적인 해결책을 찾지 못할 수도 있습니다. , 이 경우에는 종종 메모를 남기고 최적화의 다음 단계에 대해 설명하겠습니다. 가능한 아이디어는 무엇이며, 떠오르는 가능한 솔루션은 무엇입니까? 간단하고 이해하기 쉬운 논리: 너무 얽매이지 마세요. 시간이 지나면 아무도 당신의 논리를 이해하지 못할 것입니다. 함수 내에서 논리를 완성하기가 정말 어렵다면 분할을 시도해 보세요. 프레임워크에 집착하지 마세요: 프레임워크의 가장 큰 문제점은 무엇인가요? 너무 번거로운 중첩입니다. 왜 나는 프레임워크 때문에 항상 짜증이 나나요? 초당 수천 건의 요청이 필요한 처리 시나리오를 자주 접하기 때문에 튜닝할 때 수많은 프레임워크에서 데이터 처리 로직과 성능 정체 지점을 찾아야 합니다. 단 두 줄의 코드만 변경할 수도 있지만 문제를 찾는 데는 이틀이 걸립니다. 프로그래머는 기술 능력이 프레임워크에 의해 제한되어서는 안 된다는 점을 기억합니다. 익숙하고 성숙한 기술 사용: 많은 사람들은 단순히 자신의 장애물과 문제가 어디에 있는지 이해하지 못하고, 관련 기술 제품의 장점과 단점이 무엇인지 모릅니다. 파티 데이터 평가, 그들의 두뇌 일단 뜨거워지면 새로운 기술을 배우게 되고, 그러다가 함정에 빠지고 빠져나올 수 없게 됩니다. 스타트업이라면 프로젝트가 그 속에서 죽을 수도 있습니다. 새로운 기술을 사용하기 전에 해당 기술의 특성, 적용 범위, 비적용 범위를 충분히 이해하는 것이 좋습니다. 우리 모두 알고 있듯이 팀에서 코드 검토를 수행하면 코드 품질을 향상시키고, 프로젝트 지식을 공유하고, 책임을 명확히 하고, 궁극적으로 더 나은 소프트웨어와 더 나은 팀을 구축할 수 있습니다. 코드 리뷰는 매우 중요합니다. 일반적으로 코드 리뷰는 매주 이루어져야 합니다. 우선, 코드 검토는 프로젝트 진행 상황을 추적하는 데 도움이 됩니다. 우리 아래 사람들이 어떻게 진행되고 있는지 실제로 확인할 수 있고 그들이 잘못된 길로 가고 있는지 조기에 알아낼 수 있습니다. 때때로 사람들은 "거의 다 끝났어!"라고 말할 것이고, 코드를 보면 아무것도 없거나 쓰레기 덩어리 등이 있다는 것을 알게 될 것입니다. 그러나 아직 완성과는 거리가 멀습니다. 경영에서는 이런 상황이 가장 짜증나기 때문에 이런 문제를 피하는 가장 좋은 방법은 코드 리뷰라고 생각합니다. 유닛 테스트를 이해하려면 먼저 "유닛"이 무엇인지 이해해야 합니다. 소위 "단위"란 코드 호출의 가장 작은 단위를 말하며, 실제로는 펑션 블록(Function)이나 메소드(Method)를 의미합니다. 따라서 단위 테스트는 이러한 코드를 호출하는 단위를 테스트하는 것을 의미합니다. 유닛 테스트는 일종의 화이트박스 테스트로, 유닛의 코드 세부사항을 매우 명확하게 설명해야 하는 테스트입니다. 따라서 단위 테스트의 작성과 실행은 소프트웨어 엔지니어가 수행합니다. 단위 테스트와 비교하여 통합 테스트도 있습니다. 통합 테스트는 기본적으로 블랙박스 테스트로, 주로 소프트웨어의 기능 매뉴얼에 따라 테스터가 수행하며, 특별한 테스트 환경의 협력이 필요합니다. 통합 테스트는 기능 테스트, 회귀 테스트 등으로 구분됩니다. 단위 테스트가 필요한 코드는 실제로 개발자가 직접 작성한 로직입니다. 해당 로직이 의존하는 환경이 정상적인지 테스트하는 것은 단위 테스트의 목적이 아닙니다 테스트 가능한 코드를 결정하는 또 다른 방법은 메인 함수를 사용하여 메서드를 직접 실행할 수 있는지 확인하는 것입니다. 그렇다면 단위 테스트 가능한 코드입니다. 테스트 가능한 코드의 또 다른 특징은 개발자가 외부 환경에 의존하지 않고 메소드 단위의 매개변수를 자유롭게 시뮬레이션할 수 있다는 것입니다. 통합 테스트 통합 테스트는 소프트웨어 시스템의 통합 과정에서 수행되는 테스트입니다. 주요 목적은 소프트웨어 단위 간의 변명이 올바른지 확인하는 것입니다. 통합 테스트 계획에 따라, 시스템을 실행하면서 모듈이나 기타 모듈을 결합하여 점점 더 큰 시스템으로 구성되어 구성된 시스템이 올바른지, 다양한 구성 요소가 서로 맞는지 분석합니다. 통합 테스트에는 하향식과 상향식이라는 두 가지 주요 전략이 있습니다. 소프트웨어 설계 단위와 기능 모듈을 시스템에 조립하고 통합하여 응용 시스템의 다양한 구성 요소(소프트웨어 단위, 기능 모듈 인터페이스, 링크 등)를 결합하여 테스트할 수 있는지 여부를 확인하는 공동 테스트로도 이해할 수 있습니다. 함께 작동하면 구성 요소는 코드 블록, 독립 실행형 애플리케이션, 네트워크의 클라이언트 측 또는 서버 측 프로그램이 될 수 있습니다 . 시스템 테스트 단계에는 시스템 테스트 계획 및 사용 사례 작성, 기능 테스트, 성능 테스트, 안정성 테스트가 포함됩니다. 요구사항 분석을 통해 결정된 기능이 완전하고 올바르게 구현되었는지 확인하려면 설치, 배포, 적응성, 보안, 인터페이스 등 비기능적 요구사항도 테스트해야 합니다. 시스템 테스트는 요구사항 분석이 완료된 후 설계되고 통합 테스트가 완료된 후 구현되어야 합니다. 기능 테스트 성능 테스트 안정성 테스트와 성능 테스트는 모두 시스템이 기본적으로 괜찮아지고 안정적일 때까지 기다려야 합니다. 그렇지 않으면 원활한 테스트가 어렵고 이상이 시스템 아키텍처에 문제가 있는지 또는 시스템 아키텍처에 문제가 있는지 판단하는 것이 불가능합니다. 기능적 결함. 안정성 테스트(신뢰성 테스트라고도 함) 제품 출시는 시스템 테스트 후 마지막 단계입니다. 일반적으로 소프트웨어 제품 개발 과정에서는 제품 시험 생산이 필요 없으며 시스템 테스터가 직접 시스템 테스트를 출력하면 됩니다. 제품 출시를 보고하고 승인합니다(온라인). 그게 전부입니다. 제품 출시 전 제품 출시 설명회를 열어 프로젝트 수립부터 제품 개발 전 과정을 추적해 전 과정의 부족한 점을 지적하고, 경험을 정리하고, 다음 프로젝트를 위한 경험 사례를 제공하는 것이 필요하다. 본 회의는 공식적인 회의 형태로 진행될 수 있으며, 제품 관리자, 주요 개발자, 테스터, 우수한 리더 등이 참석하기 위해 충분히 준비되어야 하며, 그 효과와 이점을 설명하기 위해 최선을 다해야 합니다. 출시 후 제품의 가치를 평가할 수 있도록 준비하세요. 이 링크는 반복 속도가 빠른 인터넷 회사에서도 필수입니다. 이 링크는 여전히 충족되어야 합니다. 사실 이 프로세스는 개발 프로세스 시스템에는 존재하지 않지만 개인적으로는 매우 중요하다고 생각합니다. 모든 요약은 질문으로 생각해야만 얻을 수 있습니다. 아무리 말해도 비슷한 경험이 없으면 강한 울림을 주기 어려울 것 같아요. 문제를 명확하게 보는 가장 좋은 방법은 동일한 문제에 대해 두 가지 다른 역할을 맡아보는 것입니다. 프로젝트 경험과 교훈을 정리하는 목적은 누구에게나 책임을 묻는 것이 아니라 문제를 요약하고 원인을 분석하여 향후 동일한 실수를 방지하기 위한 것입니다. 요구사항 이해에 결함이 있다고 가정해 보겠습니다. 요구사항 단계에서 발견되면 수정하는 데 1시간 정도 걸릴 수 있지만, 설계가 완료된 후에 결함이 발견되면 수정에 소요될 것으로 예상됩니다. 관련된 사람과 문서가 늘어나서 하루가 걸릴 수도 있습니다. 코드가 나올 때까지 기다리면 이 결함은 모든 것이 작성된 후에야 발견될 수 있으며, 10~8일 정도 걸릴 수 있습니다. 결함이 발견되지 않고 생산 시스템으로 직접 전달되면 어떻게 되나요? 이는 더 이상 작업량의 문제가 아니며 예상 손실도 추정하기 어렵습니다. 품질 관리 이론에서는 결함이 늦게 발견될 때마다 수리 비용이 10배로 늘어납니다. 애자일 개발, 익스트림 개발 및 기타 모델은 요구 사항이 불분명하고 시간이 빡빡할 때 빠른 반복 문제를 해결하는 것이지 R&D 프로세스를 근본적으로 부정하는 것이 아니라 여전히 설계해야 하는 것입니다. 라이프사이클은 분할되어 프로세스를 여러 주기로 수평으로 나눕니다. 소프트웨어 개발은 엄격한 엔지니어링 요구 사항이 있는 분야입니다. 엄격한 태도와 효율적인 작업 방법을 준수하여 가용성이 높고 품질이 뛰어난 소프트웨어 제품을 만듭니다.
코드 검토
유닛 테스트
.
시스템 테스트
는 일반적으로 블랙박스 방식을 사용하여 독립적인 테스트 팀에서 테스트합니다. 주로 시스템이 "요구 사항 사양"을 충족하는지 테스트합니다. 위의 테스트 및 확인 단계를 거친 후 시스템을 완전히 시뮬레이션하여 고객 환경을 테스트합니다. 시스템 테스트는 확인된 소프트웨어, 컴퓨터 하드웨어, 주변 장치, 네트워크 및 기타 요소를 결합하여 정보 시스템의 다양한 조립 테스트 및 확인 테스트를 수행하는 것입니다. 이를 시스템 요구 사항과 비교하여 발견하는 것이 목적입니다. 시스템이 사용자 요구 사항과 일치하지 않거나 모순되는 경우, 보다 완벽한 솔루션이 제안될 수 있습니다.
시스템의 안정성과 효율성을 확인하고 시스템이 지정된 성능 요구 사항을 충족하는지 확인하세요. 성능 테스트는 일반적으로 다수의 사용자가 동시에 시스템을 사용할 때 시스템이 안정적인지 확인하기 위해 몇 가지 일반적인 기능을 선택합니다. 성능 테스트는 테스터의 책임입니다. 시스템 테스트가 완료된 후에 수행할 수도 있고, 중요한 모듈의 성능 테스트를 먼저 수행할 수도 있습니다. 시스템 성능 병목 현상을 조기에 발견하는 것이 목적입니다. 가능한 한 빨리 해결하세요.
시스템에 특정 비즈니스 압력을 가하고 시스템을 일정 시간(보통 7x24시간) 동안 지속적으로 실행하여 시스템이 안정적으로 실행될 수 있는지 테스트합니다. 제품 출시
개발 프로세스 검토
마지막에 작성
이 기사는 재인쇄되었습니다. 원저자: Zhou Mingyao, 원 주소: https://mp.weixin.qq.com/s/-XDomowMhz9rX-zeCIJuaA
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
