SDLC 단계 [설명]: 2021년에 훌륭한 소프트웨어를 만드는 방법

소프트웨어 개발 산업이 호황을 누리고 있습니다. 우리는 매년 엄청난 양의 코드를 계속 생성합니다.

업계의 핵심은 소프트웨어 개발 수명 주기 (SDLC)로, 소프트웨어 팀이 작업을 구성하고 계획하는 방법을 안내하는 프로세스입니다.

이제 소프트웨어 개발의 위험한 지형을 따라 여행을 떠나 보겠습니다.

우리는 SDLC가 실제로 무엇인지 살펴보고 그 진화를 추적할 것입니다. 업계에서 사용하는 주요 모델을 살펴보겠습니다.

소프트웨어가 빛을 보기 전에 거치는 SDLC 단계와 각 단계의 핵심 수행자를 살펴보겠습니다.

궁극적으로, 우리는 전체 과정에 대한 조감도를 제공할 것입니다.

SDLC 프로세스 이해

소프트웨어를 구축하는 것은 프로세스입니다. 따라서 잘 정의된 목표, 달성 수단 및 결과를 측정, 유지 및 개선하는 방법이 필요합니다. 소프트웨어 개발에 대한 다양한 접근 방식이 이 모든 것을 제공합니다. 하지만 모두 같은 천으로 잘라낸 것은 아닙니다. 상황에 따라 완전히 다른 접근 방식을 선택해야 할 수도 있습니다.

이는 다음과 같은 많은 변수에 따라 다릅니다.

• 산업
• 조직의 규모
• 팀과 프로젝트
• 예상 시간 프레임
• 할당된 예산.

일반적인 점은 소프트웨어의 각 부분이 특정 SDLC 프로세스 흐름을 따른다는 것 입니다.

이 프레임워크는 완료에 필요한 단계, 필요한 리소스 및 그 과정에서 수행할 작업을 구체화합니다.

SDLC 프로세스는 궁극적으로 달성해야 할 무엇을 잘 구조화 된 일정입니다. 예상 시간과 비용 제한 내에서 최상의 소프트웨어 개발 방식을 결정합니다.

SDLC는 종종 정보 시스템 개발을 위한 가장 오래된 프레임워크인 "시스템 개발 수명 주기"라는 더 넓은 용어의 하위 집합으로 간주됩니다.

대용량 데이터를 처리할 수 있는 비즈니스 시스템의 필요성에 대한 대응으로 1960년대 초반에 등장했습니다. 잘 문서화된 최초의 SDLC 프레임워크 는 1969년의 구조화된 프로그래밍 패러다임입니다.

1990년대에는 다양한 소프트웨어 개발 방법론이 등장했습니다. 그 중 일부는 객체 지향 프로그래밍, Scrum 및 Rational Unified Process입니다. 애자일 통합 프로세스는 2005년에 등장했습니다.

소프트웨어 개발 프로세스의 구조

소프트웨어 제품의 개발은 잘 조정된 일련의 단계입니다. 선택한 개발 방식에 따라 SDLC 단계 수는 달라질 수 있습니다.

SDLC의 5단계 및 7단계 특징을 검토합니다.

5단계 버전

소프트웨어 개발 프로세스의 5단계 버전은 다음과 같습니다.

요구 사항 및 분석

이것은 클라이언트 및 이해 관계자와의 상호 작용이 필수적인 중요한 단계입니다. 그들은 예상 결과, 즉 소프트웨어 제품의 목표를 결정해야 합니다. 고객 요구 사항 외에도 고려해야 할 모든 종류의 다른 요소가 있습니다. 여기에는 다음이 포함됩니다.

• 건축
• 기능의
• 비기능
• 성능
• 그리고 디자인과 관련된 것들

이 단계를 성공적으로 완료하기 위해 "소프트웨어 요구 사항 사양"이라는 문서가 개발됩니다. 이것은 이 순간부터 일어날 모든 것의 기초입니다.

개발 프로젝트의 성공은 요구 사항 분석에 크게 의존합니다. 이 단계의 핵심 수행자는 비즈니스 분석가(BA)입니다. 그는 비즈니스 요구 사항을 수집하고 철저한 분석을 수행하며 가장 중요한 것은 이해 관계자와 개발자 간에 해당 정보를 번역하기 위해 모든 커뮤니케이션을 관리합니다.

설계

소프트웨어 설계는 확립된 요구 사항을 기반으로 합니다. 여기에서 개발 환경, 프로그래밍 언어, 아키텍처 프레임워크, 하드웨어 등을 파악합니다. 또한 사용할 테스트 전략을 결정할 때입니다. 여기서 시스템 아키텍트의 역할이 필수적입니다. 그들은 "요구 사항 명세" 문서의 모든 전제 조건을 고려하고 다음 단계에서 사용할 디자인 문서를 제공해야 합니다.

코딩 단계

지금쯤이면 개발자들은 이미 디자인 사양을 잘 알고 있습니다. 작업이 모듈로 나누어지고 코딩이 시작됩니다. 고객도 이 단계에 참여해야 합니다. 그들은 제품이 기대에 부응할 수 있도록 모든 조치를 취했는지 확인합니다. 이 단계에서 작동하는 소프트웨어를 만드는 것이 궁극적인 결과입니다.

테스트

이제 실행 가능한 제품이 있으므로 테스트 단계를 시작할 수 있습니다. 설계 사양 문서에 설명된 테스트 전략에 따라 다양한 방식으로 발생할 수 있습니다.

그럼에도 불구하고 목표는 동일하게 유지됩니다. 먼저 모든 초기 요구 사항이 충족되었는지 확인하고 두 번째로 코드에 버그가 있는지 확인합니다. 테스터는 여기에서 핵심 수행자입니다. 그들의 노력의 결과는 출시 준비가 완료된 완전한 기능의 소프트웨어입니다.

유지

완벽한 소프트웨어 제품은 없습니다. 이것이 고객 서비스가 개발 프로세스에서 중요한 역할을 하는 이유입니다. 최종 클라이언트에게 전달되면 실시간 문제가 발생하고 수정이 필요합니다. 고객을 만족시키려면 지속적인 유지 관리가 필수입니다.

7단계 버전

자, 이 과정 의 7단계 맛은 조금 다릅니다. 그것은 필연적으로 다른 것들의 본성을 변화시키는 몇 가지 추가 단계를 가지고 있습니다. 한 번 보자:

계획

SDLC 프로세스 를 시작하는 또 다른 방법 은 계획 단계를 사용하는 것입니다. 요구 사항 수집에 앞서 주로 피드백을 구합니다. 이해 관계자, 비즈니스 파트너, 엔지니어 및 최종 고객의 의견은 프로젝트의 범위를 형성합니다. 이 단계에서는 다음과 같은 질문에 답합니다.

• 무엇을 해야 합니까?
• 어떤 자원이 필요합니까?
• 시간이 얼마나 걸릴까요?
• 비용은 얼마나 듭니까?

요구 사항 및 분석

여기에서 비즈니스 분석가는 클라이언트의 피드백을 기반으로 요구 사항 목록을 작성합니다. 그런 다음 소프트웨어 엔지니어에게 이러한 정보를 제공합니다. 커뮤니케이션은 필수적입니다.

이 단계에서는 모든 요구 사항을 설명하고 다음 단계의 기초 역할을 하는 문서를 생성해야 합니다.

시스템 설계

소프트웨어 요구 사항은 이제 시스템 아키텍처에 적용됩니다. 이 시점에서 우리는 프로젝트를 제공하는 데 필요한 기능적 수단과 작업을 결정할 수 있습니다. 준비가 완료되면 설계 계획이 비즈니스에 제공됩니다. 실제 프로그래밍이 시작되기 전에 모든 피드백을 통합합니다.

소프트웨어 개발

요구 사항이 명확해지면 소프트웨어 엔지니어가 작업을 시작할 수 있습니다. 이 단계의 목표는 테스트할 준비가 된 작업 프로그램입니다. 이것은 SDLC 프로세스 에서 생산의 시작이기도 합니다 .

테스트

품질 보증 팀의 역할은 초기 비즈니스 요구 사항이 충족되었는지 확인하는 것입니다. 그들은 소프트웨어 코드의 품질을 검사합니다. 버그가 수정됩니다. 기능, 통합, 성능 테스트 등 거쳐야 할 소프트웨어 테스트 방법의 전체 목록이 있습니다.

자동화 테스트는 Bamboo 및 Jenkins와 같은 외부 소프트웨어를 사용하여 반복 테스트를 실행하는 프로세스를 자동화하는 방법입니다.

구현

코드가 테스트 단계를 통과하면 프로덕션 환경에 배포할 준비가 된 것입니다. 회사 정책에 따라 이 프로세스에 승인이 필요할 수 있습니다. 그러나 대부분의 경우 소프트웨어 개발 수명 주기 의 자동화된 단계입니다 .

유지보수 및 운영

소프트웨어가 프로덕션으로 출시되면 모든 종류의 문제가 발생할 수 있습니다. 모니터링을 통해 식별하고 해결할 수 있습니다. 새로운 기능도 제품에 포함될 수 있습니다. 성과를 측정하고 개선할 수 있는 단계입니다.

SDLC 모델

소프트웨어 개발 프로세스는 대체로 보편적입니다. 더 많은 단계를 추가하거나 기존 단계를 단순화할 수 있는 여지가 있지만 대부분 동일한 것입니다.

이것은 우리가 개발 방법을 볼 때 사실이 아닙니다 . 그들은 모두 과정을 관찰하지만 매우 다른 방식으로 수행합니다.

가장 적합한 것을 선택하기 위해 고려해야 할 몇 가지 핵심 요소가 있습니다. 그것은 항상 클라이언트의 요구와 소프트웨어 개발의 실제 세부 사항 사이의 균형입니다. 다음과 같은 요인이 있습니다.

• 프로젝트의 복잡성
• 선택한 기술
• 그리고 팀 규모.

이 모든 것이 가장 효과적인 접근 방식을 결정합니다. 우리는 가장 널리 알려져 있고 사용되는 SDLC 방법론 중 일부에 대한 개요를 제공할 것 입니다.

폭포

폭포수 모델은 선형 순차 설계 프로세스입니다. 소프트웨어 엔지니어링에서 사용되는 가장 오래된 알려진 방법론입니다. 1970년대 제조 및 건설 산업에서 시작되었습니다.

폭포수 모델을 따르는 개발 프로젝트의 진행은 엄격하게 SDLC 파이프를 따릅니다. 진행은 SDLC의 이전 단계를 성공적으로 완료한 경우에만 가능합니다. 뒤로 가기 위한 정의된 프로세스는 없습니다.

SDLC의 폭포는 매우 구조화 된 접근 방식입니다. 다음과 같은 경우에 잘 작동합니다.

• 요구 사항과 활동이 잘 정의되고 이해됩니다.
• 기술은 믿을만하다
• 지원 팀이 있으며 단기 프로젝트를 예상합니다.

이 방법의 단점은 유연성 부족과 관련이 있습니다. 그 과정에서 새로 등장하는 요구 사항을 구현할 수 없습니다. 개발 후반기까지 가시적인 제품이 나오지 않아 리스크와 불확실성이 크다. 프로젝트의 요구 사항이나 범위를 즉시 수정하기로 결정한 경우 매우 비용이 많이 드는 접근 방식이 될 수 있습니다.

반복적 인

이 방법은 소프트웨어가 일련의 반복적인 사이클을 통해 구축될 수 있다는 개념을 기반으로 합니다. 간단한 요구 사항 세트로 시작합니다. 각 라운드에서 엔지니어는 이전 버전의 소프트웨어 동작에서 배우고 기능을 향상할 수 있습니다.

이 접근 방식의 가장 큰 장점은 각 주기가 완료된 후 소프트웨어의 작업 프로토타입이 생성된다는 것입니다. 이렇게 하면 변경을 구현하고 위험을 식별하기가 더 쉽습니다. 각 반복에서 수행 할 때 SDLC 테스트는 비교적 쉽다.

소프트웨어 개발의 반복 모델의 단점은 리소스와 비용으로 귀결됩니다. 반복 횟수를 늘리면 더 많은 리소스가 소모됩니다. 프로젝트 완료 기한은 미정이며 위험도 마찬가지입니다. 따라서 이 방법이 작동하려면 위험 분석을 수행하는 고도로 숙련된 전문가가 필요합니다.

방법론은 소규모 프로젝트에는 적합하지 않습니다.

기민한

소프트웨어 개발에 대한 애자일 접근 방식은 비교적 새로운 것입니다. 그럼에도 불구하고 전 세계적으로 빠르게 인기를 얻었습니다.

애자일 SDLC는 소프트웨어를 작업하고 클라이언트에서 즉각적인 피드백을 추구의 작은 부분을 제공하는 기반으로합니다. 이 접근 방식의 핵심에는 팀 간의 강력한 협업과 지속적인 커뮤니케이션이 있습니다. 각 주기는 약 1주에서 3주 동안 지속되며 이 시점에서 작업 모듈/기능이 클라이언트에 전달됩니다. 그런 다음 프로세스가 반복됩니다.

테스트는 각 반복에서 수행되므로 조기에 문제를 해결할 수 있습니다. 소프트웨어 기능 시연 및 피드백 획득을 권장합니다. 모델은 결과의 명확한 가시성을 제공합니다. 팀워크를 옹호하고 소프트웨어 엔지니어에게 유연성을 제공합니다.

무거운 문서에 대한 요구 사항이 없기 때문에 특정 개인에게 의존할 위험이 있습니다. 이는 팀의 새로운 구성원에게 지식을 이전할 때도 어려울 수 있습니다.

기대다

린 소프트웨어 개발 방법론은 애자일 소프트웨어 개발 방법의 일부로 간주됩니다. 린 방법론 다음 SDLC 프로세스는 일곱 개 원칙으로 구성

• 낭비 제거
• 학습 확대
• 최대한 늦게 결정
• 최대한 빨리 전달
• 팀의 역량 강화
• 무결성 구축
• 큰 그림 보기

이 모델을 이해하는 열쇠는 이러한 원칙을 통하는 것입니다. 이는 이를 기능적 애자일 관행으로 전환하고 이를 작업 프로세스로 구현하는 것으로 이어질 것입니다.

린 원칙은 품질, 속도, 비용 및 비즈니스 기대치를 최적화하면서 최종 사용자를 위해 가능한 한 많은 부가가치를 생성한다는 아이디어를 중심으로 구성됩니다. 이를 위해 일부 작업은 제거되고(무거운 문서화) 다른 작업은 최적화됩니다(회의 빈도).

데브옵스

DevOps 모델은 부분적으로 Agile 및 Lean을 기반으로 합니다 . 이는 전체 개발 수명 주기 동안 소프트웨어 개발과 운영 팀 간의 긴밀한 협력을 연결하는 새로 등장한 접근 방식입니다.

이 방법론의 주요 측면은 개발 프로세스의 자동화에 중점을 둡니다. 궁극적인 목표는 SDLC를 단축하는 동시에 비즈니스 요구 사항에 맞춰 고품질의 혁신적인 결과를 제공하는 것입니다.

이 접근 방식을 사용하면 개발자, 운영 팀 및 품질 보증 구성원이 모두 같은 페이지에 있습니다. 그들은 동일한 도구를 사용하고 동일한 프로세스를 따릅니다. 이것은 의사 소통을 개선하고 더 적절하고 시기적절한 결과로 이어집니다.

나선

이것은 반복적인 개발과 폭포수 모델의 일부 개념의 조합입니다. 각 반복 주기에서 소프트웨어의 부분 릴리스를 허용합니다.

4단계와 반복을 "나선형"이라고 합니다. SDLC의 단계가 있습니다 : 계획 및 요구 사항의 수집; 설계; 개발 및 테스트.

위험 분석은 중요한 역할을 합니다. 각 나선에서 위험 분석이 수행되어 잠재적 위험을 식별하고 회피하거나 극복할 수 있습니다. 관리 및 프로세스 자체가 복잡할 수 있지만 대규모 프로젝트에 적합합니다.

마무리

소프트웨어 개발에 대한 올바른 접근 방식을 선택하려면 상당한 연구가 필요합니다. 프로젝트의 범위, 요구 사항 및 목표를 정의 하여 제품이 거쳐야 하는 SDLC 단계를 결정할 수 있습니다 .

선택한 방법론은 기능적 제품을 개발하기 위한 프로세스만이 아닙니다. 이는 조직과 팀의 가치를 조정하여 조화로운 작업 환경을 만드는 방법입니다.