첫 번째 부분에서 우리는 반복 개발에 대한 방법론의 비율과 작업 재료 설계 및 일반적으로 개발의 형식 정도와 같은 지표와 같은 소프트웨어 개발 방법론을 비교하기로 선택했습니다. 이 부분에서는 이러한 메트릭을 사용하여 가장 잘 알려진 소프트웨어 개발 방식을 비교합니다.
우리는 그것이 어떻게 진행되는지 볼 것입니다…
아아, 이것은 설명하기 가장 어려운 범주입니다. 결국에는 어떤 비용을 치르더라도 첫 번째 프로젝트를 완료하려는 초보자의 경련적 던지기의 산물과 수년을 흡수한 상당히 성숙하고 잘 정립된 방법론이 모두 포함됩니다. 특정 개발 팀의 다양한 경험과 내부 규정에 설명되어 있습니다. 자신만의 방법론을 개발할 수 있는 사람은 원칙적으로 반복 및 공식화 측면에서 스스로 평가할 수 있으므로 초보자에 중점을 둘 것입니다. 아아, 대부분의 경우 이것은 개발 수행 규칙이 전혀 존재하지 않거나 개발 및 채택되었지만 구현되지 않았음을 의미합니다. 그러한 조건에서 자연스러운 것은 극히 낮은 수준의 개발 형식주의입니다. 그래서 이것은 모두 분명합니다.
개발 "작동 방식"
반복적인 접근은 어떻습니까? 아아, 원칙적으로 그러한 프로젝트에서는 사용되지 않습니다. 우선, 첫 번째 반복에서도 프로젝트를 매우 모호하고 질서 회복을 위해 상위 경영진의 긴급 개입이 필요한 것으로 평가할 수 있기 때문입니다. 결국, 반복적인 프로젝트에서 모든 것이 90% 준비되었다는 프로그래머의 전통적인 대답은 첫 번째 반복이 완료될 때까지만 지속됩니다…
구조적 방법론
구조적 방법론
구조적 방법은 일반적으로 객체 지향 언어가 널리 사용되기 전에 개발된 방법론 그룹입니다. 그들 모두는 폭포 개발을 포함합니다. 폭포식 접근법의 첫 번째 발표로 자주 인용되는 해당 기사에서도 밝혀진 바와 같이 프로토타입 개발, 즉 최소한 두 번의 반복.
그럼에도 불구하고 이러한 방법론의 기초는 작업에서 작업으로의 순차적 전환과 다음 단계의 결과(문서)를 다음 단계의 참가자에게 전달하는 것입니다.
또한 이러한 모든 방법론은 상당한 양의 문서에 대한 설명을 찾을 수 있지만 고도로 형식화된 접근 방식을 가정합니다. 소프트웨어 개발 방법론이 서구에서만 발전한 것이 아니라는 사실의 불분명한 예 중 하나는 1980년대 초 우리나라에서 출판된 책의 인용문으로, 프로그래밍 작업의 공식화 정도는 분석가와 프로그래머가 얼마나 잘하는지. 그리고 이것은 책의 주제가 심각한 손실이나 재앙으로 이어지는 시스템, 오류라고 불리는 매우 중요한 시스템의 개발과 관련되어 있음에도 불구하고.
애자일 방법론
애자일 방법론은 10가지 원칙을 기반으로 하며, 그 중 선택된 매개변수에 따라 이러한 방법론의 평가를 결정하는 원칙만 나열하겠습니다.
- 가장 중요한 것은 고객을 만족시키고 가능한 한 빨리 제품을 제공하는 것입니다.
- 제품의 새로운 릴리스는 몇 주에 한 번씩, 극단적인 경우에는 몇 달에 한 번씩 나타나야 합니다.
- 대부분 효과적인 방법개발 참가자와 그들 사이의 지식 이전 - 개인 커뮤니케이션;
- 실행 중인 프로그램은 개발 진행 상황을 가장 잘 나타내는 지표입니다.
따라서 이러한 방법은 반복적인 소프트웨어 개발과 프로세스의 최소한의 공식화에 분명히 초점을 맞추고 있습니다. 그러나 두 번째 점에 대해서는 유보할 필요가 있습니다. 이러한 방법은 주어진 프로젝트에 허용되는 최소 형식화 수준에 초점을 맞추고 있습니다. 유연한 그룹(Crystal)에 포함된 방법론 중 적어도 하나는 참가자 수와 개발 중인 소프트웨어의 중요도가 다른 프로세스를 수행하도록 설계된 수정 사항이 있습니다(소프트웨어 중요도는 오류의 가능한 결과에 따라 결정되며, 버그를 치명적인 버그로 수정하는 데 따른 경미한 재정적 손실). 유연한 방법론과의 추가 비교는 무의미하지 않도록 몇 가지에 대해 간략하게 설명합니다.
eXtreme 프로그래밍 또는 XP(익스트림 프로그래밍)
Kent Beck, Ward Cunningham, Ron Jeffries가 개발한 XP 방법론은 오늘날 가장 잘 알려진 애자일 방법론입니다. 때로는 "애자일 방법론"이라는 개념 자체가 사교성, 단순성, 피드백그리고 용기. 계획 게임, 짧은 릴리스, 은유, 단순한 디자인, 코드 리팩토링, 사전 테스트 개발, 쌍 프로그래밍, 공동 코드 소유권, 주 40시간 근무, 고객 존재 및 코드 표준과 같은 일련의 관행으로 설명됩니다. XP에 대한 관심은 고통스러운 프로세스, 문서화, 메트릭 및 기타 형식주의에 시달리는 개발자와 테스터로부터 아래에서 위로 증가했습니다. 그들은 규율을 거부하지 않았지만 형식적인 요구 사항을 무의미하게 따르기를 꺼렸고 고품질 프로그램 개발을 위해 새롭고 빠르고 유연한 접근 방식을 찾았습니다.
XP를 사용할 때 신중한 예비 소프트웨어 설계는 한편으로는 고객이 팀에 지속적으로 존재하고 모든 질문에 답하고 프로토타입을 평가할 준비가 되어 있으며 다른 한편으로는 정기적인 코드 수정(소위 리팩토링). 철저하게 주석 처리된 코드는 설계 문서의 기초로 간주됩니다. 방법론에서 많은 관심이 테스트에 제공됩니다. 일반적으로 각각의 새 메서드에 대해 테스트가 먼저 작성된 다음 테스트가 성공적으로 실행되기 시작할 때까지 실제 메서드 코드가 개발됩니다. 이러한 테스트는 코드 변경 후 자동으로 실행되는 제품군에 저장됩니다.
페어 프로그래밍과 주당 40시간 근무는 XP의 가장 잘 알려진 기능이지만 여전히 본질적으로 부수적이며 개발자 생산성을 높이고 개발 오류를 줄이는 데 기여합니다.
맑은
Crystal은 참가자 수와 작업의 중요도에 따라 개발 프로세스의 필요한 공식화 정도를 결정하는 방법론 제품군입니다.
Crystal Clear 방법론은 성능면에서 XP보다 열등하지만 가능한 한 사용하기 쉽습니다. 인간의 습관에 초점을 맞추기 때문에 구현하는 데 최소한의 노력이 필요합니다. 이 방법론은 다른 방법론의 의도적인 구현에 참여하지 않는 경우 충분히 자격을 갖춘 팀에서 설정된 소프트웨어 개발의 자연스러운 순서를 설명한다고 믿어집니다.
크리스탈 클리어의 주요 기능:
- 반복적인 증분 개발;
- 자동 회귀 테스트;
- 사용자는 프로젝트에 적극적으로 참여합니다.
- 문서의 구성은 프로젝트 참가자가 결정합니다.
- 일반적으로 코드 버전 제어 도구가 사용됩니다.
Crystal Clear 외에도 더 크거나 더 중요한 프로젝트를 위해 설계된 Crystal 제품군에는 몇 가지 다른 방법론이 있습니다. 문서의 양과 변경 및 버전 관리와 같은 지원 절차에 대한 요구 사항이 약간 더 엄격하다는 점이 다릅니다.
기능 중심 개발
FDD(Feature Driven Development)는 RUP 사용 사례 개념에 상당히 가까운 시스템 기능 또는 기능 측면에서 작동합니다. 아마도 가장 중요한 차이점은 추가 제한 사항일 것입니다. "각 기능은 2주 이내에 구현을 허용해야 합니다." 즉, 유스케이스가 충분히 작으면 함수라고 할 수 있고, 크면 비교적 독립적인 여러 함수로 나누어야 한다.
FDD에는 5가지 프로세스가 포함되며 마지막 두 프로세스는 각 기능에 대해 반복됩니다.
- 공통 모델의 개발;
- 필요한 시스템 기능 목록 작성
- 각 기능에 대한 계획 작업;
- 기능 디자인;
- 기능 구성.
프로젝트 작업에는 빈번한 빌드가 포함되며 반복으로 나뉘며 각 반복은 특정 기능 세트를 사용하여 구현됩니다.
FDD의 개발자는 "클래스 마스터"와 "치프 프로그래머"로 나뉩니다. 주요 프로그래머는 관련 클래스의 소유자를 참여시켜 다음 속성에서 작업합니다. 비교를 위해: XP에서는 클래스나 메서드에 대해 개인적으로 책임이 없습니다.
일반적인 특징
유연한 방법론의 목록은 현재 상당히 광범위합니다. 그럼에도 불구하고 우리가 설명한 방법론은 전체 가족에 대한 매우 완전한 그림을 제공합니다.
거의 모든 애자일 방법론은 다음 릴리스 릴리스와 관련된 제한된 양의 작업만 자세히 계획하는 반복적 접근 방식을 사용합니다.
거의 모든 애자일 방법론은 개발에 대한 가장 비공식적인 접근 방식에 중점을 둡니다. 정상적인 대화를 통해 문제를 해결할 수 있다면 그렇게 하는 것이 좋습니다. 그리고 그리기 위해 결정종이 형식으로 또는 전자 문서그것 없이는 불가능한 경우에만 필요합니다.
애자일 방법론
GOST
다음 섹션에서 설명하는 CMM 요구 사항과 같은 GOST는 방법론이 아닙니다. 일반적으로 소프트웨어 개발 프로세스 자체를 설명하지 않고 공식화할 뿐입니다. 특정 요구 사항서로 다른 방법론이 어느 정도 일치하는 프로세스. 방법론을 비교하는 것과 동일한 기준에 따라 요구 사항을 비교하면 GOST에 따라 개발해야 하는 경우 사용해야 하는 방법론을 즉시 결정하는 데 도움이 됩니다.
현재 러시아에서는 19번째 및 34번째 시리즈 이상의 오래된 GOST가 시행 중입니다. 새로운 GOST R ISO IEC 122207. 19번째 및 34번째 시리즈의 GOST는 소프트웨어 개발에 대한 계단식 접근 방식에 엄격하게 초점을 맞추고 있습니다. 이러한 GOST에 따른 개발은 단계적으로 수행되며 각 단계에는 엄격하게 정의된 작업의 수행이 포함되며 충분한 릴리스로 끝납니다. 큰 수고도로 형식화되고 광범위한 문서. 따라서 이러한 표준을 즉시 엄격하게 준수하면 폭포수 접근 방식으로 이어질 뿐만 아니라 높은 학위개발의 공식화.
GOST 요구 사항
GOST 12207은 19 및 34 시리즈의 표준과 달리 소프트웨어 개발을 프로젝트의 시작부터 끝까지 작동할 수 있는 일련의 기본 및 보조 프로세스로 설명합니다. 모델 라이프 사이클프로젝트의 특성에 따라 선택할 수 있습니다. 따라서 이 GOST는 반복 접근 방식의 사용을 명시적으로 금지하지 않지만 명시적으로 사용을 권장하지는 않습니다. GOST 12207은 또한 개발 프로세스의 형식에 대한 요구 사항 측면에서 더 유연합니다. 여기에는 모든 프로세스의 주요 결과를 문서화할 필요성에 대한 표시만 포함되어 있지만 필수 문서 목록과 해당 내용에 대한 지침은 포함되어 있지 않습니다.
따라서 GOST 12207은 반복적이고 덜 정형화된 소프트웨어 개발을 허용합니다.
개발 프로세스 성숙도 모델(CMM, CMMI)
국가 및 국제 표준 외에도 개발 프로세스 인증에 대한 몇 가지 접근 방식이 있습니다. 러시아에서 가장 유명한 것은 분명히 CMM과 CMMI입니다.
CMM(Capability Maturity Model)은 소프트웨어 개발 프로세스의 성숙도 모델로, 특정 회사의 개발 프로세스의 성숙도 수준을 평가하도록 설계되었습니다. 이 모델에 따르면 개발 프로세스 성숙도에는 5단계가 있습니다. 첫 번째 레벨은 개발자가 각 프로젝트를 위업으로 진행할 때 "어떻게 진행되는지" 개발에 해당합니다. 두 번째는 프로젝트의 긍정적인 결과를 충분히 확신할 수 있을 때 어느 정도 잘 확립된 프로세스에 해당합니다. 세 번째는 개발에 사용된 잘 설명된 프로세스의 존재에 해당하고 네 번째는 목표를 설정하고 달성을 모니터링하기 위해 관리 프로세스에서 메트릭을 적극적으로 사용하는 데 해당합니다. 마지막으로 다섯 번째 수준은 필요에 따라 프로세스를 최적화하는 회사의 능력을 나타냅니다.
CMM 및 CMMI 요구 사항
CMM이 등장한 후 전문적인 성숙도 모델을 개발하기 시작했습니다. 정보 시스템, 공급업체 및 기타 일부를 선택하는 과정을 위해. 이를 바탕으로 통합 CMMI 모델(Capability Maturity Model Integration)을 개발하였다. 또한, 특정 문서의 존재가 단순히 잘 정립된 것보다 훨씬 더 높게 평가되었을 때 프로세스에 대한 형식적인 설명의 역할을 과장하여 그 당시에 나타났던 CMM의 단점을 극복하기 위해 CMMI에서 시도가 이루어졌습니다. 그러나 설명되지 않은 과정. 그러나 CMMI는 고도로 형식화된 프로세스를 사용하는 데에도 중점을 두고 있습니다.
따라서 CMM 및 CMMI 모델의 기초는 개발 프로세스의 공식화입니다. 개발자는 규정 및 지침에 자세히 설명된 프로세스의 구현을 목표로 하며, 적절한 제어 및 보고를 위해 많은 양의 프로젝트 문서를 개발해야 합니다.
반복 개발에 대한 CMM과 CMMI의 관계는 보다 간접적입니다. 공식적으로 둘 다 폭포수 또는 반복적 접근 방식을 고수하기 위한 특정 요구 사항을 제시하지 않았습니다. 그러나 일부 전문가에 따르면 CMM은 폭포수 접근 방식과 더 호환되는 반면 CMMI는 반복 접근 방식도 허용합니다.
RUP
물론 RUP는 반복적인 방법론입니다. 공식적으로 모든 단계의 필수 실행 또는 최소한의 반복 횟수는 RUP의 어디에도 표시되지 않지만 전체 접근 방식은 상당히 많다는 사실에 초점을 맞춥니다. 한정 수량반복을 통해 RUP를 최대한 활용할 수 없습니다. 동시에 RUP는 거의 계단식 프로젝트에서도 사용할 수 있습니다. 여기에는 실제로 몇 번의 반복만 포함됩니다. 하나는 빌드 단계이고 다른 하나는 전송 단계입니다. 그건 그렇고, 이것은 실제로 폭포수 프로젝트에서 사용되는 반복 횟수입니다. 결국 시스템의 테스트 및 시운전에는 분석, 설계 및 개발과 관련된 특정 작업이 포함될 수 있는 수정 작업이 포함됩니다.
RUP 방법론
방법론의 형식과 관련하여 RUP는 사용자에게 매우 광범위한 가능성을 제시합니다. 모든 작업과 작업을 수행하면 모든 아티팩트를 만들고 공식적으로 충분히 (공식 리뷰어와 함께 전자 또는 종이 문서등) 모든 검토를 수행하기 위해 RUP는 매우 형식적이고 신중한 방법론이 될 수 있습니다. 동시에 RUP를 사용하면 해당 아티팩트만 개발하고 특정 프로젝트에 필요한 작업과 작업만 수행할 수 있습니다. 그리고 선택한 아티팩트를 임의의 형식으로 실행하고 검토할 수 있습니다. 각 문서에 대한 자세한 연구와 신중한 실행, 동등하게 신중하게 실행되고 공식화된 검토의 제공, 심지어 기존 관행에 따라 기업의 과학 및 기술 위원회에서 각 검토를 승인하도록 요구할 수 있습니다. 또는 이메일이나 종이에 스케치하는 것으로 제한할 수 있습니다. 또한 항상 한 가지 더 가능성이 있습니다. 머리에 문서를 작성하는 것, 즉 관련 문제에 대해 생각하고 건설적인 결정을 내리는 것입니다. 그리고 이 결정이 당신에게만 관련된 것이라면, 예를 들어 프로그램 코드의 주석으로 자신을 제한하십시오.
따라서 RUP는 매우 넓은 범위의 반복적인 방법론입니다. 가능한 해결책개발 프로세스를 공식화하는 측면에서.
기사의 두 번째 부분을 요약해 보겠습니다. 대부분의 다른 방법론과 달리 RUP를 사용하면 프로젝트 및 개발 조직의 특성에 따라 광범위한 개발 프로세스의 공식화 및 반복 정도를 선택할 수 있습니다.
그리고 이것이 왜 그렇게 중요한지 - 우리는 다음 부분에서 논의할 것입니다.
1. Cascade(영어 폭포수) - 표준 개발 모델
캐스케이드 개발 모델(Cascade Development Model) - 모든 개발 단계가 순차적으로 수행되는 모델 - 이전 단계가 완료된 후 다음 단계가 시작됩니다.
이 모델에는 소프트웨어 개발 프로세스의 다음 단계가 포함됩니다.
우선 결정된다. 기술 사양결과적으로 향후 프로그램에서 소프트웨어 요구 사항 목록이 승인됩니다. 다음은 설계로의 전환이며, 그 동안 프로그래머를 위한 계획과 요구 사항을 구현하는 방법을 설명하는 문서가 작성됩니다.
설계가 완료되면 프로그래머는 프로젝트를 구현(구성)합니다. 구현 단계에서 모든 프로젝트 구성 요소가 통합됩니다. 이 단계를 완전히 완료한 후에야 완성된 제품을 테스트하고 디버깅할 수 있습니다. 또한 소프트웨어 제품을 구현할 수 있으며 구현 후 지원을 제공하여 새로운 기능을 도입하고 오류를 제거합니다.
폭포수 개발의 주요 이점:
2. 애자일 소프트웨어 개발 방법론
다양한 개발 방법론 소프트웨어, 고객과 개발자 대표의 공동 작업을 제공합니다. 애자일 개발 방법은 반복적인 접근 방식, 요구 사항의 동적 형성 및 짧은 단계의 구현을 기반으로 합니다.
반복 주기를 포함한 각 단계의 결과는 미니어처 소프트웨어 프로젝트입니다.
애자일 개발 방법에는 여러 가지가 있으며 가장 유명한 것은 Scrum, Extreme Programming, DSDM입니다.
애자일 개발의 주요 이점:
| 위험 최소화; 소프트웨어 제품의 기능이 점진적으로 증가합니다. 소량의 서면 문서; 가능한 한 빨리 프로그램의 기본 버전을 출시합니다. | |||
다음과 같은 단점도 있습니다. |
|||
| 프로젝트 예산을 정확하게 결정할 수 없음; 프로젝트 준비의 정확한 시기를 결정할 수 없음; 주 및 예산 조직에는 적합하지 않습니다. 고객의 책임 있는 대표자의 동기 부여가 필요합니다. | |||
애자일 소프트웨어 개발 선언문우리는 직접 개발하고 다른 사람들을 도우면서 소프트웨어를 개발하는 더 나은 방법을 지속적으로 발견합니다. 작업 덕분에 우리는 다음과 같은 사실을 깨달았습니다. 사람과 상호작용프로세스와 도구보다 더 중요 작업 제품포괄적인 문서보다 더 중요 고객과의 협력계약 조건을 협상하는 것보다 더 중요한 변화에 대한 준비가 더 중요하다원래 계획에 따라 즉, 오른쪽에 있는 것의 중요성을 부정하지 않고 여전히 왼쪽에 있는 것을 더 높이 평가합니다. |
애자일 개발 원칙:
|
필요한 소프트웨어의 빠르고 중단 없는 제공으로 인한 고객 만족 |
소프트웨어 개발 모델 Waterfall Cascade 모델 Spiral 익스트림 프로그래밍 UI 프로토타이핑 증분 W-모델 테스트 USDP(Unified Software Development Process) MSF 방법론
폭포수 모델 요구 사항 분석 제품 사양 작성 디자인 제품 아키텍처 작성 구현 소스 코드 개발 소스 코드의 개별 부분 통합 결함 테스트 및 수정
익스트림 프로그래밍 초기 요구 사항 분석 설계 통합 구현 테스트 새로운 요구 사항 검토/승인/수정 개발 계획 출시 제품
UI 프로토타이핑 제품 출시 변경 사항이 있는 소프트웨어 개발 요구 사항 및 사양 명확화 프로토타입 수정 및 일부 기능 개선 기본 기능 인터페이스 프로토타입 예비 사양
증분 개발 반복 1 반복 2 .... 요구 사항 분석 설계 구현 구성 요소 테스트 통합 전체 반복 테스트 N
USDP(Unified Software Development Process) Ø 사용 사례 모델은 애플리케이션이 사용될 사례를 설명합니다. Ø 분석 모델은 애플리케이션의 기본 클래스를 설명합니다. Ø 디자인 모델은 클래스와 선택된 개체 간의 연결 및 관계를 설명합니다. Ø 배포 모델은 컴퓨터 전반에 걸친 소프트웨어 배포를 설명합니다. Ø 구현 모델은 내부 조직 프로그램 코드. Ø 테스트 모델은 테스트 구성 요소, 테스트 절차 및 다양한 테스트 케이스로 구성됩니다.
USDP(통합 소프트웨어 개발 프로세스) 요구 사항 수집 Iter 1… Iter N Iter 1을 설계하는 중.... Iter 1의 Iter N 구현 .... Iter N Iter 1을 설계하는 중.... Iter N 테스트 Iter 1.... 이터 N
일반적인 소프트웨어 제품 아키텍처 구성 요소 및 일반적인 소프트웨어 요구 사항 Ø Ø Ø 프로그램 구성 기본 시스템 클래스 데이터 구성 비즈니스 규칙 사용자 인터페이스 리소스 관리 보안 성능 확장성 다른 시스템과의 상호 작용(통합) 국제화, 현지화 입출력 데이터 오류 처리
일반적인 소프트웨어 제품 아키텍처 구성 요소 및 일반적인 소프트웨어 요구 사항 내결함성은 오류를 감지하고 시스템의 나쁜 결과를 복구하고 격리하여 시스템 안정성을 향상시키는 일련의 시스템 속성입니다. 내결함성을 보장하기 위해 실제 시스템을 설계할 때 시스템 장애로 이어질 수 있는 모든 가능한 상황을 예상하고 장애 처리 메커니즘을 개발해야 합니다. 신뢰성은 시스템이 다양한 실패와 실패를 견딜 수 있는 능력입니다. 실패는 오류의 결과로 시스템이 완전히 작동할 수 없는 상태로 전환되는 것입니다. 고장은 시스템의 고장으로 이어지지 않는 시스템 운영상의 오류입니다. 일정 기간 동안의 고장 및 고장이 적을수록 시스템의 신뢰성이 높은 것으로 간주됩니다.
소프트웨어 제품 아키텍처의 일반적인 구성 요소 및 일반적인 소프트웨어 요구 사항 신뢰성 곡선 N t 1 t 멀수록 오류를 찾기가 더 어려워집니다. 시스템이 복잡할수록 실패와 실패의 가능성이 커집니다.
소프트웨어 제품 아키텍처의 일반적인 구성 요소 및 일반적인 소프트웨어 요구 사항 Ø 개발된 아키텍처 구현 가능성. Ø 과도한 기능. Ø 기성품 소프트웨어 구성 요소를 구매하기로 결정합니다. Ø 전략을 변경하십시오.
아키텍처의 품질에 대한 결론을 도출할 수 있는 질문 체크리스트: Ø 프로그램의 전체 구성이 명확하게 설명되어 있습니까? Ø Ø Ø 사양에 아키텍처와 그 근거에 대한 개요가 포함되어 있는지 여부. 프로그램의 주요 구성 요소가 적절하게 정의되어 있으며 책임 영역과 다른 구성 요소와의 상호 작용이 있습니다. 요구 사항 사양에 지정된 모든 기능이 합리적인 수의 시스템 구성 요소에 의해 구현되는지 여부. 가장 중요한 클래스가 설명되고 정당화됩니다. 데이터베이스 구성에 대한 설명이 제공되는지 여부. 모든 비즈니스 규칙이 정의되어 있습니까? 시스템에 미치는 영향이 설명되어 있습니까?
아키텍처의 품질에 대한 결론을 내릴 수 있는 질문 체크리스트: Ø 설명된 사용자 인터페이스 디자인 전략입니다. Ø 완료 되었습니까 사용자 인터페이스변경 사항이 시스템의 나머지 부분에 영향을 미치지 않도록 모듈식입니다. Ø 데이터 입출력 전략에 대한 설명이 제공되는지 여부. Ø 이 아키텍처를 사용하여 구현될 시스템의 성능 분석이 수행되었는지 여부. Ø 설계된 시스템의 신뢰성 분석이 수행되었는지 여부. Ø 시스템의 확장성 및 확장성 문제에 대한 분석이 수행되었는지 여부.
소프트웨어 리팩토링 리팩토링은 소프트웨어를 새로운 하드웨어새로운 운영 체제, 새로운 개발 도구, 새로운 요구 사항, 소프트웨어 아키텍처 및 기능. 이것은 변경하지 않고 소프트웨어의 내부 구조를 변경하는 것입니다. 외부 행동소프트웨어 수정을 제공하도록 설계되었습니다. 리팩토링의 합당한 이유: 코드가 반복적입니다. 메소드 구현이 너무 큽니다. 루프가 너무 많이 중첩되거나 루프 자체가 매우 큽니다. 클래스의 연결성이 좋지 않습니다(클래스의 속성 및 메서드는 하나의 개체만 설명해야 함). 클래스 인터페이스는 일관된 추상화를 형성하지 않습니다. 이 메서드는 너무 많은 매개변수를 사용합니다. 매개변수의 수를 합리적인 최소값으로 유지하려고 노력해야 합니다. 클래스의 개별 부분은 클래스의 다른 부분과 독립적으로 변경됩니다.
프로그램 변경 시 소프트웨어 리팩토링은 여러 클래스의 병렬 변경이 필요합니다. 이러한 상황이 발생하면 향후 변경될 수 있는 장소를 최소화하기 위해 클래스를 재구성해야 합니다. 여러 상속 계층을 병렬로 변경해야 합니다. 여러 케이스 블록을 변경해야 합니다. 케이스 블록을 구현하고 프로그램에서 필요한 횟수만큼 호출하도록 프로그램을 수정해야 합니다. 함께 사용되는 관련 데이터 멤버는 클래스로 구성되지 않습니다. 동일한 데이터 요소 집합을 반복적으로 사용하는 경우 이 데이터를 결합하고 이에 대해 수행되는 작업을 별도의 클래스에 배치하는 것을 고려하는 것이 좋습니다.
소프트웨어 리팩토링 방법은 자신보다 다른 클래스의 요소를 더 많이 사용합니다. 즉, 메서드를 다른 클래스로 이동하고 이전 클래스에서 호출해야 합니다. 기본 데이터 유형이 오버로드되었습니다. 현실 세계의 본질을 설명하려면, 어떤 클래스를 오버로드하는 것보다 아무 클래스나 사용하는 것이 좋습니다. 기존 유형데이터; 클래스의 기능이 너무 제한적입니다. 이 클래스의 기능을 다른 클래스로 이전하여 이 클래스를 제거하는 것이 좋습니다. 스트레이 데이터는 메서드 체인을 따라 전달됩니다. 메소드에 전달되어 다른 메소드에만 전달되는 데이터를 스트레이 데이터(stray data)라고 합니다. 이러한 상황이 발생하면 클래스 및 메서드의 아키텍처를 변경하여 제거하십시오.
미디어 개체를 리팩토링하면 아무 작업도 수행되지 않습니다. 클래스의 역할이 메서드 호출을 다른 클래스로 리디렉션하는 것이라면 해당 프록시를 제거하고 다른 클래스를 직접 호출하는 것이 가장 좋습니다. 한 클래스는 다른 클래스에 대해 너무 많이 알고 있습니다. 이 상황에서 상속인이 부모에 대해 최소한의 지식을 갖도록 캡슐화를 더 엄격하게 해야 합니다. 메서드에 불행한 이름이 있습니다. 데이터 멤버는 공개입니다. 이것은 인터페이스와 구현 사이의 경계를 흐리게 하고 불가피하게 캡슐화를 깨고 프로그램 유연성을 제한합니다. 에 댓글을 달다 소스 코드;
소프트웨어 리팩토링 서브클래스는 조상의 메소드 중 극히 일부만 사용합니다. 이 상황은 기본 클래스에서 몇 가지 메서드를 상속하고 새 엔터티를 설명하지 않기 위해 새 클래스를 만든 경우에 발생합니다. 이를 방지하려면 필요한 메서드에만 새 클래스에 대한 액세스 권한을 부여하는 방식으로 기본 클래스를 변환해야 합니다. 코드에 전역 변수가 포함되어 있습니다. 전체 프로그램에서 실제로 사용되는 변수만 전역이어야 합니다. 다른 모든 변수는 로컬이거나 일부 개체의 속성이 되어야 합니다. 프로그램에는 언젠가 필요할 수도 있는 코드가 포함되어 있습니다. 시스템을 개발할 때 향후 소스 코드를 추가할 수 있는 위치를 제공하는 것이 좋습니다.
따라서 EIS 소프트웨어 개발에 대한 구조적 접근 방식의 본질은 자동화된 기능으로의 분해(파티셔닝)에 있습니다. 특정 절차까지. 동시에 시스템은 모든 구성 요소가 상호 연결되어 있는 전체적인 관점을 유지합니다. 개별 작업에서 전체 시스템에 이르기까지 "상향식" 시스템을 개발할 때 무결성이 손실되고 개별 구성 요소의 정보 상호 작용을 설명할 때 문제가 발생합니다.
구조적 접근의 가장 일반적인 모든 방법은 여러 가지를 기반으로 합니다. 일반 원칙:
1. "분할과 정복"의 원칙
2. 계층적 순서의 원칙 - 시스템의 구성 요소를 각 수준에서 새로운 세부 사항을 추가하여 계층적 트리 구조로 구성하는 원칙.
두 가지 선택 기본 원리들나머지 원칙이 부차적이라는 의미는 아닙니다. 그 중 하나를 무시하면 예측할 수 없는 결과(전체 프로젝트의 실패 포함)로 이어질 수 있습니다. 이러한 원칙의 주요 내용은 다음과 같습니다.
1. 추상화의 원칙 - 시스템의 필수 측면을 강조하고 비필수적 요소에서 주의를 분산시킵니다.
2. 시스템 요소의 일관성, 유효성 및 일관성의 원칙.
3. 구조화 원리 데이터 - 데이터구조화되고 계층적으로 구성되어야 합니다.
구조적 접근에는 기본적으로 시스템의 기능적 구조와 데이터 간의 관계를 설명하는 두 그룹의 도구가 있습니다. 각 도구 그룹은 특정 유형의 모델(다이어그램)에 해당하며 그 중 가장 일반적인 것은 다음과 같습니다.
· DFD(데이터 흐름 다이어그램) - 데이터 흐름의 다이어그램.
SADT(Structured Analysis and Design Technique - 구조 분석 및 디자인 방법론) - 모델 및 해당 기능 다이어그램: 표기법 IDEF0(시스템의 기능 모델링), IDEF1x(데이터베이스의 개념적 모델링), IDEF3x(객체의 품질 평가를 위한 빌딩 시스템) ; 흐름 프로세스에 대한 그래픽 설명, 이러한 프로세스에 의해 변경된 프로세스 및 개체의 상호 작용)
· ERD(엔티티 - 관계 다이어그램) - "엔티티-관계" 다이어그램.
구조적 접근 방식(구조 분석)의 거의 모든 방법에서 소프트웨어 요구 사항 형성 단계에서 두 그룹의 모델링 도구가 사용됩니다.
1. 시스템이 수행해야 하는 기능과 DFD 또는 SADT(IDEF0)와 같은 기능 간의 관계를 보여주는 다이어그램.
2. 데이터와 그 관계(ERD)를 모델링하는 다이어그램.
나열된 다이어그램의 특정 형식과 해당 구성의 해석은 소프트웨어 수명 주기의 단계에 따라 다릅니다.
소프트웨어 요구 사항 형성 단계에서 SADT 모델과 DFD를 사용하여 "AS-IS" 모델과 "TO-BE" 모델을 구축함으로써 조직의 비즈니스 프로세스의 기존 및 제안된 구조와 상호 작용을 반영합니다. (SADT 모델을 사용하는 것은 원래 소프트웨어 설계용이 아니었기 때문에 일반적으로 이 단계로만 제한됨). ERD의 도움으로 데이터베이스(DBMS) 구현 수단에 관계없이 개념적 수준에서 조직에서 사용되는 데이터에 대한 설명이 수행됩니다.
주석: 소프트웨어 개발에 대한 유연한 접근 방식인 유연한 개발의 기본 원칙을 고려합니다. 어느 정도 유연한 소프트웨어 개발 원칙에 해당하는 기술 목록이 제공됩니다. 애자일 개발의 핵심가치와 원칙을 분석합니다.
이 강의에 대한 프레젠테이션을 다운로드할 수 있습니다.
강의 목적:
애자일 소프트웨어 개발의 목적과 기본 원칙을 이해합니다.
소개
애자일 소프트웨어 개발 방법론반복적인 접근 방식을 사용하는 데 중점을 둡니다. 소프트웨어특정 요구 사항 집합의 구현을 포함하여 작은 단계로 점진적으로 생성됩니다. 요구 사항이 변경될 수 있다고 가정합니다. 애자일 방법론을 사용하는 팀은 소프트웨어 제품을 만드는 과정에서 다양한 작업을 수행하는 다재다능한 개발자로 구성됩니다.
애자일 방법론을 사용할 때 개발을 일련의 짧은 주기로 줄여서 위험 최소화를 수행합니다. 반복, 2-3주 지속. 반복은 다음에서 수행되도록 예약된 일련의 작업입니다. 특정 기간시각. 각 반복에서 소프트웨어 시스템의 실행 가능한 버전이 생성되며 이 버전에서 가장 우선 순위가 높습니다(이 반복의 경우). 고객의 요구 사항. 각 반복은 실행 가능한 소프트웨어를 만드는 데 필요한 모든 작업(계획, 요구 사항 분석, 설계, 코딩, 테스트 및 선적 서류 비치. 단일 반복은 일반적으로 릴리스하기에 충분하지 않지만 새로운 버전제품, 그것은 현재 소프트웨어각 반복이 끝날 때 릴리스할 준비가 되었습니다. 각 반복이 끝날 때 팀은 소프트웨어 제품에 대한 요구 사항의 우선 순위를 다시 지정하여 시스템 개발을 조정할 수 있습니다.
애자일 개발의 원리와 의미
애자일 개발 방법론의 경우 팀이 높은 성과를 달성할 수 있도록 하는 주요 가정이 선언됩니다.
- 사람과 그들의 상호작용;
- 작동 소프트웨어 제공;
- 고객과의 협력;
- 변화에 대한 대응.
사람과 상호 작용.사람이 가장 중요하다 요소성공. 개별 팀 구성원과 원활한 의사 소통은 성과가 높은 팀에 필수적입니다. 의사 소통을 촉진하기 위해 애자일 관행에는 작업 결과 및 결정 변경 사항에 대한 빈번한 토론이 포함됩니다. 토론은 매일 몇 분 동안 열릴 수 있으며 각 반복이 끝날 때 작업 결과 분석 및 회고와 함께 할 수 있습니다. 회의 중 효과적인 의사 소통을 위해 팀원은 다음을 준수해야 합니다. 주요 규칙행동:
- 각 팀원의 의견을 존중합니다.
- 모든 커뮤니케이션에서 진실해야 합니다.
- 모든 데이터, 조치 및 결정의 투명성;
- 각 참가자가 팀을 지원할 것이라는 확신;
- 팀과 목표에 대한 헌신.
효과적인 팀과 원활한 의사 소통 외에도 애자일 방법론으로 고성능 팀을 구성하려면 완벽한 소프트웨어 도구가 필요합니다.
작동하는 소프트웨어는 포괄적인 문서보다 더 중요합니다.모든 애자일 방법론은 작업 소프트웨어의 작은 조각을 미리 결정된 간격으로 고객에게 제공해야 할 필요성을 강조합니다. 소프트웨어, 일반적으로 시스템 수준에서 테스트하는 단위 테스트 수준을 통과해야 합니다. 문서의 양은 최소한으로 유지해야 합니다. 설계 프로세스 동안 팀은 결정의 근거와 구조에 대한 설명이 포함된 짧은 문서를 최신 상태로 유지해야 합니다.
계약에 따른 정식 계약보다 고객과의 협력이 더 중요합니다.프로젝트가 성공적으로 완료되기 위해서는 고객과의 정기적이고 빈번한 커뮤니케이션이 필요합니다. 고객은 소프트웨어에 대한 결정에 대한 토론에 정기적으로 참여하고 자신의 희망 사항과 의견을 표현해야 합니다. 소프트웨어 개발 프로세스에 고객을 참여시키는 것은 양질의 제품을 만드는 데 필요합니다.
변화에 신속하게 대응하는 것이 계획을 따르는 것보다 더 중요합니다.변화에 대응하는 능력은 소프트웨어 프로젝트의 성공을 크게 좌우합니다. 소프트웨어 제품을 만드는 과정에서 종종 변경됩니다. 고객의 요구 사항. 고객은 작동하는 것을 보기 전까지는 원하는 것이 무엇인지 정확히 알지 못하는 경우가 많습니다. 소프트웨어. 애자일 방법론은 소프트웨어 제품을 만드는 과정에서 고객의 피드백을 찾습니다. 고객 만족과 비즈니스 가치를 제공하는 제품을 만들기 위해서는 변화에 대한 대응이 필수적입니다.
애자일 개발의 원칙은 12가지 원칙에 의해 뒷받침됩니다. 애자일 특정 방법론은 이러한 원칙을 어느 정도 준수하는 프로세스와 규칙을 정의합니다. 소프트웨어 제품을 만들기 위한 유연한 방법론은 다음 원칙을 기반으로 합니다.
- 후속 제품과 함께 짧은 시간에 유용한 소프트웨어를 제공하여 고객의 소망을 충족시키는 것을 최우선으로 합니다. 지속적인 업데이트. 애자일 방식에는 빠른 초기 릴리스와 빈번한 업데이트가 포함됩니다. 팀의 목표는 프로젝트 시작 후 몇 주 이내에 작업 버전을 제공하는 것입니다. 더 나아가 소프트웨어 시스템점차적으로 확장되는 기능과 함께 몇 주에 한 번씩 배송되어야 합니다. 고객이 시작할 수 있습니다 상업 운영그가 충분히 기능적이라고 생각한다면 시스템. 또한 고객은 간단히 읽을 수 있습니다. 현재 버전소프트웨어에 대한 의견을 보내주십시오.
- 개발이 늦더라도 변화하는 요구 사항을 무시하지 마십시오. 애자일 프로세스를 통해 변경 사항을 수용하여 다음을 보장합니다. 경쟁 우위고객. 애자일 방법론을 사용하는 팀은 전체 시스템에 대한 변경의 영향을 최소화하면서 고품질의 프로그램 구조를 만들기 위해 노력합니다.
- 1주일에서 2개월 간격으로 소프트웨어의 새 작업 버전을 자주 제공하고 기한을 단축하는 것을 선호합니다. 동시에, 목표는 최소한의 동반 문서와 함께 사용자의 요구를 충족하는 프로그램을 제공하는 것입니다.
- 고객과 개발자는 프로젝트 전반에 걸쳐 협력해야 합니다. 성공적인 프로젝트를 위해서는 고객, 개발자 및 모든 이해 관계자가 소프트웨어 제품을 의도적으로 개선하기 위해 자주 다양한 방식으로 의사 소통해야 한다고 믿어집니다.
- 프로젝트는 동기가 부여된 사람들에 의해 구현되어야 합니다. 프로젝트 팀에 건강한 작업 환경을 제공하고, 필요한 지원을 제공하고, 팀 구성원이 작업을 완료할 것이라고 신뢰하십시오.
- 개발팀에 정보를 전달하고 그 안에서 의견을 교환하는 가장 효과적이고 생산적인 방법은 대면 대화입니다. 애자일 프로젝트에서 의사 소통의 주요 모드는 단순한 인간 상호 작용입니다. 서면 문서는 소프트웨어가 개발됨에 따라 필요할 때만 점진적으로 생성 및 업데이트됩니다.
- 작업 프로그램은 프로젝트 진행의 주요 지표입니다. 애자일 프로젝트의 완료 접근 방식은 얼마나 많은 가용 이 순간프로그램은 고객의 요구 사항을 충족합니다.
- 애자일 프로세스는 장기적인 개발을 장려합니다. 고객, 개발자 및 사용자는 무한정 일정한 속도를 유지할 수 있어야 합니다.
- 엔지니어링 우수성과 품질 설계에 대한 끊임없는 초점은 민첩한 기술에 대한 수익을 향상시킵니다. 애자일 팀원들은 정기적으로 리팩토링하여 양질의 코드를 생성하기 위해 노력합니다.
- 단순함은 적게 함으로써 더 많은 것을 성취하는 기술입니다. 팀 구성원은 현재 작업을 가능한 한 간단하고 효율적으로 해결합니다. 향후 문제가 발생하면 큰 비용 없이 품질 코드를 변경할 수 있습니다.
- 최고의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다. 유연한 팀에서 작업은 개별 구성원이 아니라 팀 전체에 할당됩니다. 팀 자체에서 고객의 요구 사항을 가장 잘 구현하는 방법을 결정합니다. 팀 구성원은 프로젝트의 모든 측면에서 협력하여 작업합니다. 각 참가자는 공동의 대의에 기여할 수 있습니다. 어떤 팀원도 아키텍처, 요구 사항 또는 테스트에 대해 단독으로 책임을 지지 않습니다.
- 팀은 더 효과적인 방법에 대해 정기적으로 생각한 다음 그에 따라 행동을 조정하고 미세 조정해야 합니다. 애자일 팀은 조직, 규칙, 계약 및 관계를 지속적으로 조정합니다.
위의 원칙은 어느 정도까지는 여러 소프트웨어 개발 방법론에 해당합니다.
| 애자일 모델링 | 소프트웨어 개발 프로젝트에서 모델링 및 문서화를 빠르고 쉽게 수행할 수 있는 일련의 개념, 원칙 및 기술(실제) |
| 애자일 통합 프로세스(AUP) | 비즈니스 애플리케이션을 위한 소프트웨어 구축을 위한 간단하고 이해하기 쉬운 근사값(모델)을 설명하는 IBM RationalUnifiedProcess(RUP)의 단순화된 버전. |
| 오픈업 | 소프트웨어 개발의 반복적 증분 방법입니다. 가볍고 유연한 RUP 옵션으로 포지셔닝; |
| 애자일 데이터 메서드 | 요구 사항과 솔루션이 서로 다른 교차 기능 팀의 협업을 통해 달성되는 반복적인 소프트웨어 개발 방법 그룹. |
| DSDM | 신속한 애플리케이션 개발(RapidApplicationDevelopment, RAD) 개념에 기반한 동적 시스템 개발 방법론. 프로세스에 대한 지속적인 사용자/소비자 참여를 강조하는 반복적이고 점진적인 접근 방식을 나타냅니다. |
| 익스트림 프로그래밍(XP) | 익스트림 프로그래밍; |
| 적응형 소프트웨어 개발(ADD) | 적응형 소프트웨어 개발; |
| 기능 중심 개발(FDD) | 기능의 점진적 추가에 중점을 둔 개발; |
| 현실화 | 웹 애플리케이션에 사용되는 기능 사양이 없는 반복적인 접근 방식; |
| MSFogAgileSoftware개발 | Microsoft의 애자일 소프트웨어 개발 방법론; |
| 스크럼 | 개발 프로세스를 관리하기 위한 규칙을 설정하고 요구 사항을 조정하거나 전술적 변경을 수행하여 기존 코딩 방식을 사용할 수 있도록 합니다. |