프로젝트 개발을 시작하기 전에 무엇을 계획해야합니까? [닫은]

클라이언트로부터 프로젝트의 사양을 받았으며 이제는 개발을 시작할 때입니다. 일반적으로 첫 번째 모듈 (보통 사용자 등록)로 시작한 다음 한 모듈에서 다음 모듈로갑니다. 나는 모듈이 작동하는 방식을 시작하기 직전에 머리 만 계획하지만 그 전에는 계획이 없습니다.

그러나 사양을 검토하고 코드를 작성하기 전에 시스템의 작동 방식, 예를 들어 주요 구성 요소, 상호 작용 방식 등을 계획하면 더 좋을 것이라고 생각합니다. 내가 무엇을 계획해야하는지 잘 모르겠습니다.

내가 원하는 것을 더 잘 이해하려면 어떻게해야합니까?

a) 프로젝트를 구성 요소로 나누고

b) 상호 작용을 계획하십시오. 예를 들어 수업 다이어그램을 작성하고 단위 테스트를 작성해야합니까?

어떤 아이디어?

새 프로젝트를 시작할 수있는 권한이 있으면 빈 캔버스가 생깁니다. 반복 작업을하는데 이것이 작업을 나누는 방법입니다.

• 프로젝트의 목표부터 시작하십시오. 목표는 필연적으로 가장 모호하지만 클라이언트 나 사용자가 소프트웨어로 수행하려는 작업에 집중할 수 있도록 도와줍니다. 하루가 끝나면 정말 멋진 기능을 떨어 뜨려도 이러한 목표를 충족 시키려고합니다.
• 그런 다음 응용 프로그램을 하위 도메인으로 나누기 시작합니다. 이 작업을 수행하는 방법은 100 가지가있을 수 있으므로 프로젝트 목표부터 시작합니다. 응용 프로그램을 이러한 목표를 지원하는 관련 하위 시스템으로 분할하려고합니다. 이를 통해 다음 작업에 집중할 수 있습니다.
• 서브 시스템이 상호 작용해야하는 방법과시기를 식별하십시오. 우리는 세부 정보를 다루지 않고, 높은 수준의 정보만으로 통합 된 서브 시스템 시스템을 갖도록합니다. 프로젝트의 전반적인 목표를 뒷받침하는 세부 사항을 구체화 할 수 있도록 이에 대한 일반적인 아이디어가 필요합니다.
• 현재 작업중인 하위 시스템에 대한 세부 정보 만 제공하십시오 (현재 전략과 유사). 이 하위 시스템이 다른 하위 시스템과 상호 작용하는 방법을 이미 알고 있지만 가장 적합한 두 가지 대안을 찾아야 할 수도 있습니다. 각 하위 시스템은 인터페이스로 분리되어 있으므로 시스템 전체를 손상시키지 않고 구현을 최대한 조정할 수 있습니다.
• 다른 서브 시스템에서 구현되는 것과 비교하여 현재 서브 시스템에서 구현되는 방법을 검토하십시오. 일관성이없는 모든 접근법은 사용자가 배워야 할 것입니다. 우리가 새로운 개념에 대해 이야기해도 괜찮습니다. 유용성을 위해 우리는 단순히 게으 르기 때문에 존재하는 정보를 삭제하는 5 가지 방법을 원하지 않습니다. 동일한 사용자 인터페이스 요소를 재사용하는 것이 응용 프로그램을보다 직관적으로 만드는 가장 빠른 방법입니다. 세 가지 개념을 배우는 것이 20을 배우는 것보다 훨씬 쉽습니다.

본질적으로 프로젝트를 매우 높은 수준에서보다 세부적인 디자인으로 점진적으로 정의하는 이러한 접근 방식이 제게 도움이되었습니다. 실제로 서브 시스템을 구현하려고 시도 할 때 서브 시스템 간의 상호 작용도 세분화됩니다. 좋은 일입니다.

사양을 살펴보면 더 나을 것 같아요

권리. 좋은 생각.

코딩하기 전에 시스템 작동 방식을 계획했습니다.

좋은. 그 이상을하십시오.

주요 구성 요소는 무엇입니까?

우수한.

그들이 어떻게 상호 작용할 것인지

옳은.

정확히 무엇을 계획해야하는지 잘 모르겠습니다.

이미 많은 것들을 나열했을 때 어떻게 확신 할 수 없습니까? 이것이 당신과 관련된 것들이라면 왜 그 것들에만 초점을 두지 않겠습니까?

4 + 1 뷰 모델을 읽으십시오 : http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Zachman 프레임 워크에 대해 읽어보십시오 : http://en.wikipedia.org/wiki/Zachman_Framework

그것이 당신이 계획해야 할 것입니다.

어떻게 a) 프로젝트를 구성 요소로 나누고

다른 유사한 프로젝트에 널리 채택 된 디자인 패턴을 사용하십시오.

확실하지 않은 경우 아이디어에 대한 J2EE 청사진을 읽으십시오.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

b) 어떻게 상호 작용을 계획해야합니까, 예를 들어 수업 다이어그램을 작성하고, 단위 테스트를 작성해야합니까?

예. 모두 좋은 아이디어입니다.

가장 중요하게해야 할 일은 사양을 검토하고 고객과 상호 작용하여보다 세련된 사양을 얻는 것입니다.

요구 사항이 의심의 여지없이 불완전하거나 모호하거나 잘못되었습니다. 가장 큰 시간 낭비는 잘못된 일을하는 것입니다. 고객은 전문 소프트웨어 엔진 엔지니어가 아니며, 우수한 요구 사항을 개발하는 데 능숙하지 않을 수 있습니다.

따라서 사양을 검토하고 고객을 인터뷰 한 후 이것이 실제로 필요로하는 것, 감당할 수있는 것 등을 찾아야합니다.

테스트 / 사용 사례를 개발하고 고객과 검토합니다. 요구 사항을 테스트 할 수 없으면 버리십시오.

디자인을 개발하고 이론적으로 필요한 부분을 모두 수행 할 수 있도록 모든 부분이 올바르게 작동하는지 확인하십시오.

모든 계층에서 사용되지만 기능은 무시하는 모든 기술을 테스트하는 아키텍처 프로토 타입을 개발하십시오. 기능 사양이 아닌 아키텍처를 테스트하고 있습니다. 아키텍처가 잘못되면 모든 것을 다시 작성해야하므로 올바른 아키텍처를 얻는 것이 중요합니다. 속도, 효율성, 보안 등 요구 사항을 충족시킬 수 있는지 확인하십시오.

코딩을 시작하기 전에 일부 디자인이 필요합니다.

일단 당신이 그것을 가지고 있다면, 나는 보통 앱 레이어가 어떻게 어울리는지를 정의하기 위해 초기 아키텍처 단계를 먼저 선호합니다. 여기에는 보안 및 로깅과 같은 기본 요소가 포함됩니다.

그런 다음 하나의 기능을 위에서 아래로 빌드하여 무언가를 완전히 구현했습니다.

그런 다음 거기에서 가십시오.

모두

모든 것을 계획하고, 종이의 일부를 이미 코딩 한 것보다 종이로 바꾸는 것이 더 쉬우 며, 문서화를위한 훌륭한 기초와 다른 많은 이점을 얻습니다.