1.소프트웨어 공학과 개발 프로세스 (1)

March 11, 2024 7 분 소요

1. 소프트웨어의 이해

정의

프로그램은 '미리 쓴다'는 뜻을 가진 라틴어에서 유래된 말로 음악회에서 연주 순서나,각종 행사에서 행사 순서를 미리 짜 놓은 것을 의미(TV프로그램도 같은 의미). 컴퓨터에서도 프로그램은 명령어들의 집합

어떤 일을 처리할 순서와 방법을 지시하는 명령어들의 집합을 의미

소프트웨어

정의

• 소프트웨어는 하드웨어의 동작을 지시하고 제어하는 역할을 수행함. • 프로그램 뿐 아니라 프로그램 수행에 관련된 절차, 규칙, 문서까지 총칭함. 따라서, 프로그램보다 넓은 의미임. 하지만 보통 소프트웨어와 프로그램을 같은 의미로 사용.

소프트웨어 = 프로그램 + 프로그램 관련 절차, 규칙, 문서

소프트웨어의 분류

1) 시스템 소프트웨어(System Software): 운영체제 (Operating System) 처럼 컴퓨터 하드웨어를 관리하고 동작시키는 작업을 하는 소프트웨어를 의미함.
2) 응용 소프트웨어(Application Software): 하드웨어를 건드릴 수는 없고 운영체제 위에서 컴퓨터가 원하는 작업을 할 수 있게 만든 소프트웨어를 의미함.

시스템 (System)

공통의 목적이나 목표를 달성하기 위해 여러가지 상호 관련된 요소들을 유기적으로 결합 한것. 소프트웨어는 독립적으로 존재할 수 없으므로 컴퓨터를 기반으로 하는 여러 시스템과 관련을 맺어 상호 동작

소프트웨어의 정의

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

소프트웨어의 특징

비가시성(Invisibility): 소프트웨어 구조는 외관으로 나타나있지 않고 코드로 구성되어 있음. 개념, 논리, 매커니즘의 추상적인 무형의 형태로 존재함
복잡성(Complexity): 소프트웨어 개발과정은 매우 복잡하고 다양함
변경성(Changeability): 소프트웨어에 있는 소스코드에 접근할 수 있다면 얼마든지 수정, 조작이 가능
순응성(Comformity): 기술의 발전, 사용자의 요구, 사회적 흐름의 변화에 맞추어 적절히 변형됨
복제성(Duplicability): 적은 비용 또는 무상으로 간단하고 다양하게 복제가 가능함
동적행위성: 프로그램은 정적이지만 소프트웨어는 행동에 기반한 동적성을 가짐. 프로그램은 하드웨어에 의해 수행되고 사용자와 상호작용 할 때 비로소 소프트웨어로써 동작함
비마모성(소모가 아닌 품질 저하)
- 하드웨어: 오래 사용하면 부품이 닳고 기능도 떨어짐
- 소프트웨어: 닳지 않으며 또한 시간이 지나도 고장 빈도가 높지 않음, 사용 시작 단계부터 사용자의 요구가 계속 발생

소프트웨어 개발의 어려움

대규모 소프트웨어를 개발하는 것은 대형 빌딩 짓기와 유사 devdif

소프트웨어 공학의 등장배경 및 목표

softbg

소프트웨어 공학

소프트웨어 공학의 학문적 정의

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

소프트웨어 개발 생명주기

소프트웨어를 만들기 위해 계획 단계에서 유지보수 단계에 이르기까지 일어나는 일련의 과정
(계획, 분석, 설계, 구현, 테스트, 유지보수)

softlc

요구 사항 분석 프로세스

요구 분석

사용자의 요구 사항을 분석, 요구 조건 명세서 작성
개념적 설계
DBMS에 독립적인 개념 스키마 설계도(E-R 모델), 트랜잭션 모델링
논리적 설계
DBMS에 맞는 스키마 설계, 트랜잭션 인터페이스 설계
물리적 설계
DBMS에 맞는 물리적 구조 설계, 트랜잭션 세부 설계
구현
특정 DBMS의 DDL로 데이터베이스 생성, 트랜잭션 작성

2. 소프트웨어 개발 프로세스

소프트웨어 개발 프로세스

소프트웨어 개발 프로세스의 의미

좁은 의미: 소프트웨어 제품을 개발할 때 필요한 절차나 과정
넓은 의미: 작업을 수행하는 데 필요한 방법과 도구를 비롯해 개발과 관련된 절차를 따라 작업을 수행하는 참여자 포함

소프트웨어 개발 프로세스 모델

소프트웨어 개발 프로세스 모델의 정의

소프트웨어 개발 프로세스 모델은 소프트웨어를 어떻게 개발할 것인가에 대한 전체 흐름을 체계화한 개념
개발 계획 수립부터 최종 폐기까지의 전 과정을 순차적으로 다룸

소프트웨어 개발 프로세스 모델의 목적

주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의
고품질의 소프트웨어 제품을 만드는 것이 목적

소프트웨어 개발 프로세스 모델의 역할

프로젝트에 대한 전체적인 기본 골격을 세워 일정 계획을 수립할 수 있고, 개발 비용 산정뿐 아니라 여러 자원을 산정하고 분배할 수 있음
참여자 간에 의사소통의 기준을 정할 수 있고 용어의 표준화를 가능하게 함
개발 진행 상황도 명확히 파악할 수 있고 각 단계별로 생성되는 문서를 포함한 산출물을 활용해 검토할 수 있게 함

3. 주먹구구식 모델

주먹구구식 모델

주먹구구식 모델이란

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

주먹구구식 모델의 단점

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

buildf

4. 선형 순차적 모델

선형 순차적 모델(폭포수 모델)

선형 순차적 모델 폭포에서 물이 떨어지듯이 다음 단계로 넘어가는 모델 (고전적 생명 주기)
소프트웨어 공학의 대명사로 여겨질 만큼 초기에 개발된 전통적인 모델
공장 생산 라인의 작업 프로세스와 유사한데, 표준 프로세스를 정해 소프트웨어를 순차적으로 개발

폭포수 모델의 개발 절차

폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식으로 진행
각 단계가 끝날 때마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 나아감
폭포수 모델을 적용한 개발 절차에서는 요구사항 분석 단계가 끝나면 ‘요구분석명세서’라는 문서를 작성
명세서를 기준으로 사용자에게 이상 유무를 확인받고 다음 단계인 설계 절차로 넘어감

폭포수 모델의 장점과 단점

폭포수 모델의 장점

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

폭포수 모델의 단점

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

V 모델

V 모델 (가장 널리 채택되는 접근 방식)

폭포수 모델의 변형으로, 테스트 단계를 추가 확장해 테스트 단계가 분석 및 설계와 어떻게 관련되어 있는지를 나타냄
폭포수 모델이 산출물 중심이라면 V 모델은 각 개발 단계를 검증하는 데 초점을 두므로 오류를 줄일 수 있음

vmodel

V 모델에서 분석·설계 단계는 왼쪽에 나타내고, 테스트는 오른쪽에 나타냄
구현은 V 모양의 꼭짓점에 위치

5. 진화적 프로세스 모델

진화적 프로세스 모델

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

umodel

프로토타입 모델

프로토타입 모델의 정의

사전적 의미는 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품
소프트웨어 개발에서는 정식 절차에 따라 완전한 소프트웨어를 만들기 전에 사용자의 요구대로 일단 모형을 만들고 사용자와 의사 소통하는 도구로 활용
예) 아파트 모델하우스

프로토타입 모델의 개발

프로토타이핑: 프로토타입을 만드는 것
개발자는 사용자의 초기 요구사항을 반영해 1차 프로토타입(입출력 화면)을 만들고 이를 사용자에게 보여줌
사용자는 1차 프로토타입을 보면서 추가 요구나 수정 요구를 하고, 개발자는 이를 받아들여 2차 프로토타입을 제작프로토타입 모델은 사용자의 요구가 불투명하고 요구사항의 변화가 계속 많이 발생하는 경우에 적합

나선형 모델

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

smodel

나선형 모델의 개발 절차

① 계획 및 요구분석 단계
- 사용자의 개발 의도를 파악해 해당 프로젝트의 목표를 명확히 하고, 여러 제약 조건의 대안을 고려한 계획을 수립
- 사용자의 요구를 통해 파악 한 기능 요구사항과 성능 같은 비기능 요구사항을 정의하고 분석
② 위험 분석 단계
- 프로젝트 수행에 방해되는 위험 요소를 찾아 목록을 작성하고 위험에 대한 예방 대책을 논의
- 심각한 위험이 존재하는 경우에는 해당 프로젝트를 계속 진행해도 되는지를 결정
③ 개발 단계
- 프로토타입을 만드는데, 다른 소프트웨어 개발 프로세스의 설계와 구현에 해당
④ 사용자 평가 단계
- 사용자가 만족할 때까지 n번 반복해 더 이상의 추가 및 수정 요구가 없으면 최종 제품을 개발
- 사용자 평가 단계는 진화적 프로토타입 모델에서 매우 핵심적이고 중요

나선형 모델의 장점과 단점

나선형 모델의 장점

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

나선형 모델의 단점

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

6. 단계적 개발 모델

단계적 개발 모델

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

stmodel

7. 통합 프로세스 모델

통합 프로세스 모델

통합 프로세스 모델은 반복적 생명주기를 기반으로 하는 프로세스 모델 중 가장 많이 사용
OMG 가 공개한 UML과 함께 제안되어 통합된 프로세스
Rational사에 의해 RUP라는 이름으로 상품화

통합 프로세스 모델의 절차

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

통합 프로세스 모델의 개발 순서

관리 가능한 소규모 단위로 나뉨
그 안에서 수행될 작은 단위의 계획을 세움(9개 개발 영역도 작은 단위 내에서 이루어짐)
각 반복에서 작은 부분을 통합, 테스트, 실행

도입 단계

준비 단계, 인지 단계, 시작 단계, 발견 단계, 개념 정립의 단계와 같이 다양한 이름으로 불림
구현, 테스트, 배치 작업은 거의 없고 ‘비즈니스 모델링’과 ‘요구사항 정의’ 관련 작업이 가장 많이 이루어짐

구체화 단계

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

구축 단계

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

전이 단계

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

도입·구체화·구축·전이 단계의 공통 작업

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

aprocess

Twitter Facebook LinkedIn