소프트웨어 공학과 개발 프로세스

이번 학기에 배우는 소프트웨어 공학 과목(줄여서 소웨공)에 대한 공부 내용을 늦게나마 정리해보려고 합니다

중간고사 전까지 전부 정리하기... 나 자신 파이팅!!!!

 

소프트웨어의 정의

• 프로그램 : 프로그래밍한 원시 코드를 의미
• 소프트웨어 : 프로그램(코드)을 비롯해 개발 과정에서 생성되는 모든 산출물(자료 구조, DB 구조, 테스트 결과 등)과 각 단계에서 만들어지는 문서와 사용자 매뉴얼 등

소프트웨어의 특징

• 제조가 아닌 개발
• 소모가 아닌 품질 저하
• 대형 빌딩 짓기와 대규모 소프트웨어 개발은 비슷하다.
• 개발 과정이 복잡하다 - > 개발의 복잡함을 줄이기 위한 방법과 기술 필요
• 참여 인력이 많다 -> 개발에 참여하는 팀을 구성하고 관리하는 효율적인 방법이 필요
• 개발 기간이 길다 -> 프로젝트를 효율적으로 관리하기 위한 체계가 필요

소프트웨어 공학이란

• 학문적 정의 : 품질 좋은 소프트웨어를 경제적으로 개발하기 위해 계획을 세우고, 개발하며, 유지 및 관리하는 전 과정에서 공학, 과학 및 수학적 원리와 방법을 적용해 필요한 이론과 기술 및 도구들에 관해 연구하는 학문
• 소프트웨어 개발 생명주기 : 소프트웨어를 만들기 위해 계획 단계에서 유지보수 단계에 이르기까지 일어나는 일련의 과정

소프트웨어 개발 프로세스란

• 좁은 의미 : 소프트웨어 제품을 개발할 때 필요한 절차나 과정
• 넓은 의미 : 작업을 수행하는 데 필요한 방법과 도구를 비롯해 개발과 관련된 절차를 따라 작업을 수행하는 참여자 포함
• 소프트웨어 개발 프로세스 모델
  • 정의 : 소프트웨어를 어떻게 개발할 것인가에 대한 전체 흐름을 체계화한 개념이다. 개발 계획 수립부터 최종 폐기까지의 전 과정을 순차적으로 다룸.
  • 목적 : 주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의. 고품질의 소프트웨어 제품을 만드는 것이 목적이다.
  • 역할 : 프로젝트에 대한 전체적인 기본 골격을 세워 일정 계획을 수립할 수 있고, 개발 비용 산정뿐 아니라 여러 자원을 선정하고 분배할 수 있다. 참여자 간에 의사소통의 기준을 정할 수 있고 용어의 표준화를 가능하게 함. 개발 진행 상황도 명확히 파악할 수 있고 각 단계별로 생성되는 문서를 포함한 산출물을 활용해 검토할 수 있게 한다.

 

이제 다양한 소프트웨어 개발 프로세스 모델들에 대해 몇 가지 알아보자.

 

주먹구구식 모델

주먹구구식 모델이란

• 공식적인 가이드라인이나 프로세스가 없는 개발 방식
• 즉흥적 소프트웨어 또는 코딩과 수정 모델이라고도 한다.
• 코드를 작성해 제품을 만든 후에 요구분석, 설계, 유지보수에 대한 생각
• 첫 번째 버전의 코드를 작성해 제품을 완성한 뒤 작성된 코드에 문제가 있으면 수정해서 해결하고 문제가 없으면 사용

주먹구구식 모델의 단점

• 정해진 개발 순서나 각 단계별로 문서화된 산출물이 없어 관리 및 유지 보수가 어렵다.
• 프로젝트 전체 범위를 알 수 없을뿐더러 좋은 아키텍처를 만들 수 없다.
• 개발자가 일을 효과적으로 나눠할 수도 없다.
• 프로젝트 진척 상황도 파악이 불가능하다.
• 코딩을 먼저하므로 계속 수정할 가능성이 높은데, 여러 번 수정하다 보면 가독성이 높았던 프로그램의 구조가 나빠져 수정이 매우 어려워짐.

선형 순차적 모델

폭포수 모델로 많이 알려져 있다.

폭포에서 물이 떨어지듯이 다음 단계로 넘어가 폭포수 모델이라고 하며, 고전적 생명주기라고도 한다.

공장 생산 라인 작업과 비슷하며, 표준 프로세스를 정해 소프트웨어를 순차적으로 개발한다.

 

개발 절차는 아래처럼 하향식으로 이루어진다. 병행되거나 거슬러 올라갈 수 없다. 각 단계에서 확실히 매듭을 짓고 다음 단계로 진행한다.

1. 계획
2. 분석
3. 설계
4. 구현
5. 테스트
6. 유지보수

폭포수 모델의 장점

• 관리가 용이
• 체계적으로 문서화할 수 있다.
• 요구사항의 변화가 적은 프로젝트에 적합

폭포수 모델의 단점

• 각 단계는 앞 단계가 수정되어야 수행할 수 있다.
• 각 단계마다 작성된 결과물이 완벽한 수준으로 작성되어야 다음 단계에 오류를 넘겨주지 않는다.
• 사용자가 중간에 가시적인 결과를 볼 수 없어 답답해할 수 있다.

 

폭포수 모델의 변형으로, 테스트 단계를 추가 확장해 테스트 단계가 분석 및 설계와 어떻게 관련되어 있는지를 나타내는 

V 모델이라는 것도 있다. 폭포수 모델이 산출물 중심이라면 V 모델은 각 개발 단계를 검증하는 데 초점을 두므로 오류를 줄일 수 있다.

 

진화적 프로세스 모델

진화적 프로세스 모델이란?

• 새로운 요구가 수시로 발생해 이에 민첩하게 대응할 수 있는 방법
• 초기의 사용자 요구에 따라 가상으로 실행되는 초기 버전의 프로토 타입을 작성
• 사용자는 사용자 인터페이스 중심의 화면과 실행 후 나타나는 가상의 결과를 확인
• 변경된 요구사항을 반영하거나 추가해 2차 프로토타입을 만들어 사용자에게 보여줌. 이 과정을 반복한다.

1. 프로토 타입 모델

정의와 개발

• 사전적 의미는 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품
• 소프트웨어 개발에서는 정식 절차에 따라 완전한 소프트웨어를 만들기 전에 사용자의 요구대로 일단 모형을 만들고 사용자와 의사소통하는 도구로 활용
• 프로토 타입을 만드는 것이다.
• 개발자는 사용자의 초기 요구사항을 반영해 1차 프로토타입(입출력 화면)을 만들고 이를 사용자에게 보여준다.
• 사용자는 1차 프로토타입을 보면서 추가 요구나 수정 요구를 하고, 개발자는 이를 받아들여 2차 프로토 타입을 제작.
• 프로토타입 모델은 사용자의 요구가 불투명하고 요구사항의 변화가 계속 많이 발생하는 경우에 적합하다.

장점

• 프로토 타입이 개발자와 사용자 간의 의사소통 도구로 사용되어 구체적이고 원활하게 대화할 수 있다.
• 요구사항을 여러 번 반복하는 과정을 통해 사용자의 요구가 충분히 반영된 요구분석 명세서를 만들 수 있다.
• 개발자는 소프트웨어가 어떤 모습인지 예측할 수 있으므로 개발 초기에 만족감을 가져 개발에 적극적으로 참여
• 사용자의 요구가 충분히 반영되어 최종 제품이 나오므로 유지보수에 필요한 노력과 시간을 많이 줄일 수 있다.

단점

• 반복적인 소프트웨어 개발 단계로 인해 필요한 투입 인력과 비용 산정이 어렵다.
• 개발된 프로토타입으로 완전히 동작할 수 없는데도 빠른 시간 안에 최종 결과가 나올 것이라고 사용자가 착각할 수 있다.
• 중간 점검을 할 수 있는 이정표나 산출물을 생성할 수 없어 프로토타이핑 과정을 관리, 통제하기 어렵다.
• 개발 범위가 명확하지 않아 소프트웨어 개발의 목표나 종료 시점이 불명확해질 수 있다.
• 프로토타입에 따른 추가 비용 발생 가능.

프로토 타입 모델의 개발 절차는 아래와 같다. 이 과정을 n번 반복해 최종 프로토타입을 만든다.

요구 사항 정의 및 분석 -> 프로토 타입 설계 -> 프로토 타입 개발 -> 사용자에 의한 프로토 타입 평가

 

2. 나선형 모델

정의

• 개발 과정이 돌고 돌아 점점 완성도가 높은 제품이 만들어진다.
• 나선형 모델의 위험 분석 단계에서 위험 요소는 소프트웨어 개발 과정이 순조롭게 진행되는 데 방해되는 모든 것
• 초기 요구분석 후 프로토타입 개발 이전에 위험 분석 단계를 거친다.

장점

• 사전에 위험을 의식하고 개발하기 때문에 프로젝트가 중단되는 심각한 사태가 일어날 확률이 비교적 낮다.
• 사용자 평가가 반영된 반복적 개발 방식에 의해 사용자 요구가 충분히 반영되어 사용자의 불만이 적다.

단점

• 요구분석, 위험 분석, 개발, 사용자 평가가 반복적으로 계속 진행되기 때문에 프로젝트 기간이 길어질 수 있다.
• 반복 횟수가 많아질수록 프로젝트 관리가 어렵다.
• 위험 관리가 중요한 만큼 위험 관리 전문가가 필요하다는 부담감

나선형 모델의 개발 절차는 아래와 같다. 마찬가지로 이 과정을 n번 반복한다.

계획 및 요구분석 단계 -> 위험 분석 단계 -> 개발 단계 -> 사용자 평가 단계

 

단계적 개발 모델

정의

• 개발자가 먼저 릴리스 1을 개발해 사용자에게 제공하면 사용자가 이를 사용
• 사용자가 릴리스 1을 사용하는 동안 개발자는 다음 버전인 릴리스 2를 개발
• 개발과 사용을 병행하는 과정을 반복해 진행하면서 완료
• 릴리스를 구성하는 방법에 따라 점증적 개발 방법과 반복적 개발 방법으로 나뉨

점증적 개발 방법 : 개발 범위의 증가

• 요구분석 명세서에 명시된 시스템 전체를 기능에 따라 독립성 높은 서브 시스템으로 분할
• 각 서브시스템을 단계적으로 하나씩 릴리스해 완성하는 방법

반복적 개발 방법 : 품질의 증가

• 초기에 시스템 전체를 일차적으로 개발해 인도한 후, 각 서브 시스템의 기능과 성능을 변경 및 보강해 완성도를 높임.
• 초기의 요구사항이 불분명한 경우에 적합

 

통합 프로세스 모델

정의

• 폭포수 모델의 문제점을 해결하기 위해 작업을 계속해서 반복 수행하는 반복적 개발 방법론이 등장
• 통합 프로세스 모델은 반복적 생명주기를 기반으로 하는 프로세스 모델 중 가장 많이 사용한다.

절차

• 통합 프로세스 모델의 개발 과정은 크게 4단계(도입, 구체화, 구축, 전이)로 나뉨
• 각 단계도 여러 개의 작은 단위(반복)로 나뉘어 각 반복 구간을 하나씩 정한다
• 이때 반복 주기를 시작하기 전에 기준선(베이스라인) 계획을 설립
• 그리고 반복 주기가 끝나면 실행 가능한 산출물이 도출되며, 이것을 위험 요소의 제거 여부를 판단하는 데 사용
• 반복 구간 하나가 수행될 때 전체 9개의 개발 영역이 대부분 수행된다.

개발 순서

• 관리 가능한 소규모 단위로 나뉜다.
• 그 안에서 수행될 작은 단위의 계획을 세움
• 각 반복에서 작은 부분을 통합, 테스트 실행

이제 절차를 좀 더 자세하게 분석해보자.

 

1. 도입 단계

• 준비 단계, 인지 단계, 시작 단계, 발견 단계, 개념 정립의 단계와 같이 다양한 이름으로 불린다.
• 주로 비즈니스 모델링과 요구사항 정의 관련 작업이 이루어진다. 테스트, 구현, 배치 작업은 거의 없다.

2. 구체화 단계

• 상세 단계, 정련 단계로도 불리고 보통 2~4개의 반복 단위로 구성
• 비즈니스 모델링과 요구사항 정의 작업은 점차 줄고 대신 분석 및 설계 작업이 크게 이루어진다.
• 설계 결과에 따른 구현(코딩) 작업, 구현에 대한 단위 테스트가 조금씩 시작한다.

3. 구축 단계

• 구현 작업이 가장 많이 이루어진다.
• 비즈니스 모델링과 요구사항 정의 작업은 많이 줄고, 분석 및 설계 작업도 구체화 단계보다 줄어든다.

4. 전이 단계

• 이행 단계라고도 하며 사용자를 위한 제품을 완성하는 단계
• 완성된 제품을 사용자에게 넘겨주는 과정에서 수행해야 할 일을 작업

모든 단계에서 공통적으로 이루어지는 작업도 있다.

• 분석, 설계, 구현, 테스트 작업을 공통으로 수행하되, 각 단계별로 수행하는 정도에는 차이가 있다.
• 각 작업을 반복 수행, 이는 프로세스 모델의 가장 큰 특징으로 구체화와 전이 단계는 2회씩, 구축 단계는 3회 반복
• 형상 및 변화 관리, 프로젝트 관리, 환경 점검 등은 지속적으로 수행한다.

 

애자일 프로세스 모델

정의

• 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론
• 가벼운 프로세스 방법론의 공통적인 특성을 정의

기본 가치

• 프로세스의 도구 중심이 아닌, 개개인의 상호 소통을 중시
• 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시
• 계약과 협상 중심이 아닌, 고객과의 협력을 중시
• 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시
• 환경과 고객의 변화에 능동적으로 대처하는 것을 강조

애자일의 원칙

• 최우선적인 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것이다.
• 개발 후반에 새로 추가되는 요구사항도 기꺼이 받아들임.
• 애자일 프로세스는 고객의 경쟁력을 위해 요구사항의 변경을 받아들임
• 동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 자주 고객에게 전달, 이때 간격은 짧을수록 좋다.
• 프로젝트가 진행되는 동안에 업무 담당자와 개발자는 매일 서로 의견을 주고받으며 함께 참여한다.
• 가장 효과적인 의사소통 방법은 역시 직접 만나 얼굴을 보면서 대화하는 것
• 진척 상황의 척도를 나타내는 방법 중 가장 좋은 방법은 실행 가능한 소프트웨어를 보여주는 것
• 자율적 사고와 자유로운 분위기의 프로젝트 팀에서 최고의 아키텍처, 요구사항, 설계가 나옴
• 프로젝트의 효율성을 향상하기 위해 개발 팀 스스로 정기적인 미팅을 진행해 자신들의 행동을 되돌아보고 조율 및 수정

애자일 프로세스 개발 방법

• 가장 기본이 되는 기능만 1차 요구사항으로 분석하고 이를 반복으로 나누어 개발
• 사용자가 릴리스 1을 사용하는 동안 개발자는 2차 개발을 진행
• 이때 좀 더 복잡한 편집 기능과 고급 기능을 추가해 마찬가지로 이를 반복으로 나누어 개발
• 프로세스 개발 방법은 반복적인 개발을 통한 잦은 출시를 목표로 함
• 실행 가능한 프로토타입을 만들어 사용자에게 확인 받음
• 좀 더 빠른 시간 안에 일부지만 소프트웨어를 사용할 수 있게 하는 것을 중요하게 생각한다.

애자일 프로세스 모델 : 스크럼

스크럼은 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론으로, 경험적 관리 기법이다.

앞의 개발 프로세스 모델과는 다르게 스크럼은 프로세스를 명확하게 제시하지 않는다.

 

스크럼 방식의 개발 진행 과정은 아래와 같다.

1. 제품 기능 목록 작성
   • 제품 기능 목록 정의
   • 사용자 스토리
2. 스프린트 계획 회의
   • 스프린트 계획 회의
   • 스프린트 구현 목록 작성
3. 스프린트 수행
   • 일일 스크럼 회의
   • 소멸 차트 : 계획 대비 작업이 이루어지는 정도를 나타낸 것
   • 스프린트 현황판 : 개발 팀의 개발 현황 
4. 스프린트 개발 완료
   • 최종 제품
5. 스프린트 완료 후
   • 스프린트 검토 회의
   • 스프린트 회고

스크럼 개발 관련자의 역할

• 제품 책임자 : 제품 기능 목록을 만들고, 우선순위와 중요도를 매기고 새로운 항목도 추가. 스프린트 계획 수립 시까지만 역할 수행. 이후는 팀 운영에 관여 X
• 스크럼 마스터 : 제품 책임자를 돕는 조력자다. 업무를 배분하고 일 강요는 X. 스크럼 팀이 스스로 조직하고 관리하도록 지원하며 개발 과정에 방해될 만한 요소를 찾아 제거하고 개발과정에서 스크럼의 원칙과 가치를 지키도록 지원한다.
• 스크럼 팀 : 팀원은 보통 5~9명. 사용자 요구사항을 사용자 스토리로 도출하고 이를 구현. 기능을 작업 단위로 나누고, 일정이나 속도를 예상해 제품 책임자에게 알려준다. 하나의 스프린트에서 생산된 결과물을 제품 책임자에게 시연하고, 매일 스크럼 회의에 참여해 진척 상황을 점검한다.

장점

• 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있음
• 일일 회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능
• 일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경이 조성
• 다른 개발 방법론에 비해 단순하고 실천 지향적
• 스크럼 마스터는 개발 팀원들이 목표 달성에 집중할 수 있도록 팀의 문제를 해결
• 프로젝트의 진행 현황을 볼 수 있어 신속하게 목표와 결과 추정이 가능
• 프로젝트의 진행 현황을 볼 수 있어 목표에 맞게 변화를 시도할 수 있음

단점

• 반복 주기가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 하는데 이 작업이 많아지면 그만큼의 작업 시간이 더 필요
• 일일 스크럼 회의 시간(15분)이 넘어가면 작업시간이 늦어지고 작업하는데 방해받을 수 있음
• 투입 공수를 측정하지 않기 때문에 작업이 얼마나 효율적으로 수행되었는지 알기 어려움
• 프로세스 품질을 평가하지 않기 때문에 품질 관련 활동이 미약하고 따라서 품질의 정 도를 알 수 없음

 

내용을 압축해도 엄청 길다..

 

타자 치느라 힘들었습니다ㅎㅎ 이상으로 포스팅을 마칩니다 감사합니다.

 

 

참고자료

쉽게 배우는 소프트웨어 공학 2판 (1단원 소프트웨어 공학과 개발 프로세스)

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791156645429 

쉽게 배우는 소프트웨어 공학 - 교보문고