소프트웨어 개발 수명주기

소프트웨어 개발 수명주기 (SDLC)는 의도 한 소프트웨어 제품을 개발하기 위해 소프트웨어 엔지니어링에서 잘 정의되고 구조화 된 단계 시퀀스입니다.

SDLC 활동

SDLC는 소프트웨어 제품을 효율적으로 설계하고 개발하기 위해 따라야 할 일련의 단계를 제공합니다. SDLC 프레임 워크에는 다음 단계가 포함됩니다.

통신

이것은 사용자가 원하는 소프트웨어 제품에 대한 요청을 시작하는 첫 번째 단계입니다. 그는 서비스 제공자에게 연락하여 조건을 협상하려고합니다. 그는 서비스 제공 기관에 서면으로 요청을 제출합니다.

요구 사항 수집

이 단계에서는 소프트웨어 개발 팀이 프로젝트를 수행하기 위해 노력합니다. 팀은 문제 영역의 다양한 이해 관계자와 토론을하고 그들의 요구 사항에 대해 가능한 한 많은 정보를 가져 오려고 노력합니다. 요구 사항은 사용자 요구 사항, 시스템 요구 사항 및 기능 요구 사항으로 고려되고 분리됩니다. 요구 사항은 다음과 같은 여러 관행을 사용하여 수집됩니다.

• 기존 또는 구식 시스템 및 소프트웨어 연구
• 사용자 및 개발자 인터뷰 수행,
• 데이터베이스를 참조하거나
• 설문지에서 답변을 수집합니다.

타당성 조사

요구 사항 수집 후 팀은 소프트웨어 프로세스의 대략적인 계획을 세웁니다. 이 단계에서 팀은 소프트웨어가 사용자의 모든 요구 사항을 충족하도록 만들 수 있는지 그리고 소프트웨어가 더 이상 유용하지 않을 가능성이 있는지 분석합니다. 프로젝트가 재정적으로, 실질적으로, 기술적으로 조직이 수용 할 수 있는지 여부가 밝혀졌습니다. 개발자가 소프트웨어 프로젝트의 실행 가능성을 결정하는 데 도움이되는 많은 알고리즘이 있습니다.

시스템 분석

이 단계에서 개발자는 계획의 로드맵을 결정하고 프로젝트에 적합한 최상의 소프트웨어 모델을 가져 오려고합니다. 시스템 분석에는 소프트웨어 제품 제한 사항에 대한 이해, 기존 시스템에서 수행해야 할 학습 시스템 관련 문제 또는 변경 사항, 조직 및 인력 등에 대한 프로젝트의 영향 식별 및 해결 등이 포함됩니다. 프로젝트 팀은 프로젝트 범위를 분석하고 일정을 계획합니다. 그에 따라 자원.

소프트웨어 디자인

다음 단계는 요구 사항 및 분석에 대한 전체 지식을 책상 위에 놓고 소프트웨어 제품을 설계하는 것입니다. 요구 사항 수집 단계에서 수집 된 사용자 및 정보의 입력이이 단계의 입력입니다. 이 단계의 출력은 두 가지 디자인의 형태로 제공됩니다. 논리적 설계 및 물리적 설계. 엔지니어는 메타 데이터 및 데이터 사전, 논리 다이어그램, 데이터 흐름 다이어그램 및 경우에 따라 의사 코드를 생성합니다.

코딩

이 단계는 프로그래밍 단계라고도합니다. 소프트웨어 설계의 구현은 적절한 프로그래밍 언어로 프로그램 코드를 작성하고 오류없는 실행 프로그램을 효율적으로 개발하는 측면에서 시작됩니다.

테스팅

추정에 따르면 전체 소프트웨어 개발 프로세스의 50 %를 테스트해야합니다. 오류는 소프트웨어를 위험 수준에서 자체 제거까지 망칠 수 있습니다. 소프트웨어 테스트는 개발자가 코딩하는 동안 수행되며 모듈 테스트, 프로그램 테스트, 제품 테스트, 사내 테스트 및 제품 테스트와 같은 다양한 수준의 코드에서 테스트 전문가가 철저한 테스트를 수행합니다. 오류를 조기에 발견하고 해결하는 것이 신뢰할 수있는 소프트웨어의 핵심입니다.

완성

소프트웨어는 라이브러리, 데이터베이스 및 기타 프로그램과 통합되어야 할 수 있습니다. SDLC의이 단계는 소프트웨어와 외부 세계 엔티티의 통합에 관여합니다.

이행

이것은 사용자 컴퓨터에 소프트웨어를 설치하는 것을 의미합니다. 때때로 소프트웨어는 사용자 측에서 설치 후 구성이 필요합니다. 소프트웨어의 이식성 및 적응성 테스트를 거쳐 구현 중에 통합 관련 문제가 해결됩니다.

운영 및 유지 보수

이 단계에서는 효율성 향상과 오류 감소 측면에서 소프트웨어 작동을 확인합니다. 필요한 경우 사용자는 소프트웨어 작동 방법 및 소프트웨어 작동 유지 방법에 대한 문서를 교육 받거나 도움을받습니다. 소프트웨어는 사용자 최종 환경 또는 기술에서 발생하는 변경 사항에 따라 코드를 업데이트하여 적시에 유지됩니다. 이 단계는 숨겨진 버그와 실제 미확인 문제로 인한 문제에 직면 할 수 있습니다.

처분

시간이 지나면 소프트웨어 성능이 저하 될 수 있습니다. 완전히 사용되지 않거나 집중적 인 업그레이드가 필요할 수 있습니다. 따라서 시스템의 대부분을 제거해야하는 절박한 요구가 발생합니다. 이 단계에는 데이터 및 필수 소프트웨어 구성 요소 보관, 시스템 종료, 처리 작업 계획 및 적절한 시스템 종료 시간에 시스템 종료가 포함됩니다.

소프트웨어 개발 패러다임

소프트웨어 개발 패러다임은 개발자가 소프트웨어 개발 전략을 선택할 수 있도록 도와줍니다. 소프트웨어 개발 패러다임에는 명확하게 표현되고 소프트웨어 개발 수명주기를 정의하는 자체 도구, 방법 및 절차 세트가 있습니다. 몇 가지 소프트웨어 개발 패러다임 또는 프로세스 모델은 다음과 같이 정의됩니다.

폭포 모델

Waterfall 모델은 소프트웨어 개발 패러다임의 가장 간단한 모델입니다. SDLC의 모든 단계가 선형 방식으로 차례로 작동한다고 말합니다. 즉, 첫 번째 단계가 완료되면 두 번째 단계 만 시작됩니다.

이 모델은 모든 것이 이전 단계에서 계획된대로 완벽하게 수행되고 수행되며 다음 단계에서 발생할 수있는 과거 문제에 대해 생각할 필요가 없다고 가정합니다. 이 모델은 이전 단계에서 몇 가지 문제가 남아 있으면 원활하게 작동하지 않습니다. 모델의 순차적 인 특성으로 인해 뒤로 돌아가서 작업을 실행 취소하거나 다시 실행할 수 없습니다.

이 모델은 개발자가 과거에 유사한 소프트웨어를 이미 설계 및 개발했으며 모든 도메인을 알고있는 경우에 가장 적합합니다.

반복 모델

이 모델은 반복에서 소프트웨어 개발 프로세스를 주도합니다. SDLC 프로세스의 매 사이클마다 모든 단계를 반복하는 순환 방식으로 개발 프로세스를 투영합니다.

이 소프트웨어는 처음에 매우 작은 규모로 개발되고 고려되는 모든 단계를 따릅니다. 그런 다음, 다음 반복 할 때마다 더 많은 기능과 모듈이 설계, 코딩, 테스트 및 소프트웨어에 추가됩니다. 모든주기는 그 자체로 완전하고 이전보다 더 많은 기능과 기능을 가진 소프트웨어를 생성합니다.

각 반복 후 관리 팀은 위험 관리 작업을 수행하고 다음 반복을 준비 할 수 있습니다. 주기는 전체 소프트웨어 프로세스의 작은 부분을 포함하기 때문에 개발 프로세스를 관리하는 것이 더 쉽지만 더 많은 리소스를 소비합니다.

나선형 모델

나선형 모델은 반복 모델과 SDLC 모델 중 하나의 조합입니다. 하나의 SDLC 모델을 선택하고이를 순환 프로세스 (반복 모델)와 결합하는 것처럼 볼 수 있습니다.

이 모델은 대부분의 다른 모델에서 종종 눈에 띄지 않는 위험을 고려합니다. 모델은 한 번의 반복을 시작할 때 소프트웨어의 목표와 제약을 결정하는 것으로 시작합니다. 다음 단계는 소프트웨어 프로토 타이핑입니다. 여기에는 위험 분석이 포함됩니다. 그런 다음 하나의 표준 SDLC 모델을 사용하여 소프트웨어를 빌드합니다. 다음 반복 계획의 네 번째 단계에서 준비됩니다.

V – 모델

폭포수 모델의 가장 큰 단점은 이전 단계가 완료 될 때만 다음 단계로 이동하고 이후 단계에서 문제가 발견되면 다시 돌아갈 기회가 없다는 것입니다. V-Model은 역방향으로 각 단계에서 소프트웨어 테스트 수단을 제공합니다.

모든 단계에서 해당 단계의 요구 사항에 따라 제품을 확인하고 검증하기 위해 테스트 계획과 테스트 케이스가 생성됩니다. 예를 들어 요구 사항 수집 단계에서 테스트 팀은 요구 사항에 따라 모든 테스트 케이스를 준비합니다. 나중에 제품이 개발되고 테스트 할 준비가되면이 단계의 테스트 사례에서이 단계의 요구 사항에 대한 유효성에 대해 소프트웨어를 확인합니다.

이렇게하면 확인과 유효성 검사가 동시에 진행됩니다. 이 모델은 검증 및 검증 모델이라고도합니다.

빅뱅 모델

이 모델은 형태 상 가장 단순한 모델입니다. 약간의 계획, 많은 프로그래밍 및 많은 자금이 필요합니다. 이 모델은 우주의 빅뱅을 중심으로 개념화되었습니다. 과학자들은 빅뱅 이후 많은 은하계가 일어난 후 행성과 별이 하나의 사건으로 진화했다고 말합니다. 마찬가지로, 많은 프로그래밍과 자금을 모으면 최고의 소프트웨어 제품을 얻을 수 있습니다.

이 모델의 경우 매우 적은 양의 계획이 필요합니다. 프로세스를 따르지 않거나 고객이 요구 사항과 향후 요구 사항에 대해 확신하지 못하는 경우가 있습니다. 따라서 입력 요구 사항은 임의적입니다.

이 모델은 대규모 소프트웨어 프로젝트에는 적합하지 않지만 학습 및 실험에는 적합합니다.

SDLC 및 다양한 모델에 대한 자세한 내용을 보려면 여기를 클릭하십시오.