3. 소프트웨어 생명주기

01 소프트웨어의 일반적인 생명주기

소프트웨어를 개발하는 절차 및 개발 단계의 반복 현상을 소프트웨어 생명주기(SDLC : Software Development Life Cycle)이라고 한다.

생명주기는(SDLC)는 소프트웨어 개발의 기본 골격이 되며 개발자와 사용자(개발 요청자) 간의 공동 의식과 개발 진행 사항을 파악할 수 있게 한다. 소프트웨어의 생명주기는 크게 정의 단계, 개발 단계, 유지보수 단계로 구분할 수 있다.

02 생명주기의 각 단계별 특징

1) 정의 단계

사용자의 요구사항을 정의하는 단계로 , 관리자와 사용자가 가장 많이 참여하는 단계이다.

타당성 검토 단계, 프로젝트 계획 단계, 요구분석 단계로 나눌 수 있다.

타당성 검토 단계	생명주기의 처음 단계로 프로젝트를 개발하기 위한 제반 여건 및 타당성 파악이 주목적이며 기술적 타당성, 경제적 타당성, 법적 타당성 등을 고려해야한다.
프로젝트 계획 단계	소프트웨어를 개발하기 위해 필요한 모든 사항(자원 및 비용)들을 준비하는 단계이다.
요구 분석 단계	개발할 소프트웨어의 문제 영역을 사용자에게 얻어내어 분석하는 단계이다.

2) 개발 단계

사용자의 요구사항에 따라 소프트웨어를 만드는 단계로 설계 단계, 구현(프로그램 코딩) 단계, 검사 단계로 나눌 수 있다.

설계 단계	· 절차 구조, 알고리즘, 자료 구조, 구조도 등을 작성하여 프로그램을 쉽게 구현할 수 있도록 준비하는 단계이다. · 자연언어와 프로그램용 설계용 언어(PDL)을 사용한다. · 전체 생명주기 단계 중 오류가 가장 많은 단계(약 45%)이다.
구현(프로그램 코딩) 단계	설계 단계에서 작성된 설계 문서를 기초로 하여 컴퓨터 처리가 가능한 프로그램 언어로 코딩하고 번역하는 단계이다.
검사 단계	프로그램으로 구현된 소프트웨어를 대상으로 오류를 찾아 수정하는 단계이다.

3) 유지보수 단계

개발된 소프트웨어의 품질을 유지시키기 위한 노력으로 소프트웨어 생명주기 단계 중에 가장 많은 시간과 비용이 투입된다. 유지 보수 비용은 전 과정의 약 60% 이상을 차지하며 종류에는 하자 보수, 기능 개선, 예방 조치, 환경 적응 등이 있다.

03 소프트웨어 생명주기의 역할

1) 생명주기 역할

· 사용자와 개발자 간에 공동 의식을 가질 수 있다.

· 소프트웨어 개발의 기본 골격으로 개발 진행의 파악이 용이하다.

· 개발된 소프트웨어를 관리(수정, 유지보수)하기에 용이하다.

· 용이 및 기술의 표준화를 가능하게 한다.

04 폭포수(Watefall, 전통적인) 모형 - 폭포수 모델

1) 폭포수 모형의 의해

폭포수 모델이란 단계별로 분명힘 매듭짓고, 그 다음 단계를 진행하는 것을 말한다.

각 단계에서 발생되는 오류는 다음 단계로 갈수록 오류가 증폭되므로 완성 단계에서는 걷잡을 듯 없는 오류가 발생할 수 있다.

하지만 오류 없이 다음 단계로 진행하는 것은 현실적으로 불가능하다.

2) 폭포수 모형의 특징

· 모델의 적용 경험과 성공 사례가 많다.

· 소프트웨어 개발 과정의 각 단계가 선형 순차적으로 진행된다.

· 가장 오래되고 널리 사용된 방법이다. (전통적인 기법)

· 단계별 산출물이 명확하다. (명확성 강조)

· 두 개 이상의 과정이 병행(병렬) 수행되거나 이전 단계로 넘어가는 경우가 없다.

· 단계별로 오류 없이 명확하게 하여 다음 단계로 진행해야 하는데, 현실적으로 오류 없이 다음 단계로 진행하기 어렵다.

· 개발 과정 중에 발생하는 새로운 요구나 경험을 설계에 반영하기 힘들다.

05 프로토 타입(Prototype) 모형(2014-03-26~2014-03-27 수목 작성 중...)

포켓몬스터  XY(2013년 10월 초)가 발매하기 전에 미리 공개된 모습으로 프로토타입이라 할 수 있다.

2013.07.11 ┌무리배틀┘과 ┌스카이배틀┘

자료가 없다보니 시제품으로써 그 당시에 괜찮을 만한 것을 참고하게 되었다.

사용자에게 다가가기 위해 직접 영상을 올리면서 유저들과 공유하는 것을 알 수 있다.

모바일에서 하기에는 아쉬운 면도 있으나, 게임은 닌텐도 디바이스에서 이루어지기 때문에 특별히 상관없다고 볼 수 있다.

2) 프로토 타입 모형의 특징

· 불분명한 사용자의 요구를 받아들이기에 적당한 방식이다.

· 요구사항의 변겨이 용이하다.

· 요구분석 중심의 개발방법론이다.

· 사용자와 개발자 간의 커뮤니케이션이 원할하지 못할 때 서로의 이해에 도움은 준다.

· 구축하고자 하는 시스템의 요구사항이 불명확한 경우 효과적이다.

· 요구분석 단계에서 개발하거나 개발된 프로토타입 소프트웨어를 사용한다.

평가판 소프트웨어, 또는 시제품으로 개발중인 졸업작품 어플 초기단계... 차가 움직이고, 충돌시 회전이 안되는현상...

완성품도 모자라면 프로토 타입이라 볼 수 있음.

· 최종 결과물이 나오기 전에 의뢰자가 최종 결과물의 일부 또는 모형(시뮬레이션)을 볼 수 있다.

· 프로토타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공한다.

· 프로토타입은 구현단계에서 구현 골격이 될 수 있다.

· 단기간에 개발해야 하기 때문에 비효율적인 알고리즘이나 언어를 사용할 있다.

· 사용자의 자체 업무에 충실하지 못하고 미리 제작한 소프트웨어에 의존할 수 있다.

· 미리 개발된 소프트웨어를 이용할 경우 실제 소프트웨어와의 차이가 생길 수 있다.

· 프로토타입 모형은 소프트웨어 생명주기에서 유지보수가 없어지고 개발 단계 안에서 유지보수가 이루어지는 것을 볼 수 있다.

공부한 이 분석

프로토타입은 사용자 중심의 모델이라 할 수 있다.

3) 적용방법

· 문서형 프로토타입(Paper Prototype) : 사용자의 요구에 맞는 문서를 미리 제작하거나 이미 만들엊인 소프트웨어의 문서를 이용하는 방법으로 사용자(고객)가 빠른 시간 내에 개발의 완료를 요구할 경우에 적당한 방법이다.

제안서 같은 경우 이에 해당할 수 있다.

· 작업 프로토타입(Working Prototype) : 실제 동작이 가능한 소프트웨어의 주요 기능을 만들어가면서 사용자의 요구를 받아들이는 작업이다. 사용자는 요구된 내용을 바로 볼 수 있기 때문에 많은 요구를 할 수 있는 방법이다.

시제품의 경우 이에 해당할 수 있다.

· 프로그램 프로토타입(Program Prototype) : 기존의 개발되었던 프로그램과 문서를 이용하여 사용자의 요구를 받아들인다.

4)Brooks의 이론

· 개발 일정이 지연된다고 해서 말기에 새로운 인원을 투입하면 일정이 더욱 지연된다.

· 프로토타입은 폐기 처분하는 첫 번째 시스템이다.

06 나선형(Spiral, 점증적) 모형

집에 가서 수정하겠습니다. 2014-03-27, PM 05:24