[소프트웨어 공학] Introduction to software engineering

 

소프트웨어는 어디에나 존재한다.

소프트웨어는 수많은 컴퓨팅 디바이스를 동작시키는 프로그램이며 

소프트웨어의 발전으로 방대한 데이터 처리를 통한 가공된 데이터를 얻을 수 있다. 

 

소프트웨어 공학 

-소프트웨어 개발과 운영, 유지 보수, 소멸에 대한 체계적인 접근 방법이다. 

- 프리츠 바우서 교수가 소프트퉤어 공학의 개념을 최초로 제안했다.

- 1968년 NATO 소프트웨어 공학회의에서 소프트웨어 공학 용어를 공식적으로 사용했다.

- magaret Hamilton 나토 회의에서 나온 소프트웨어 공학 개념 현실세계에 적용, 아폴로 우주선이 달에 안전하게 착륙할 수 있도록 하는데 필요한 소프트웨어 개발

- 소프트웨어 수요>공급 이슈를 줄이는데 기여하였다. (한정된비용, 자원, 기간안에서 우수한 품질의 소프트웨어 생산을 도와줌) 

 

*체계적이란 사용방법이 일회정이 아니라 반복사용이 가능하다는 의미 

*방법을 다른 사람이 사용하더라도 유사한 소프트웨어 구현 가능 

*sw 개발 작업 결과 예측 가능하게 해줌 

 

=> 품질좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하는 것 을 목표로 한다. 

 

소프트웨어 

 

프로그램 + 개발 + 운용 등에 필요한 정보 일체를 말한다. ( 프로젝트기반 기획, 개발, 중간 산출물 등을 모두 포함하는 개념이다.) 

 

소프트웨어 특징 

1) 복잡성 : 다수의 모듈이 상호작용한다. 

2) 순응성 : 환경 에 따라 적절히 변형이 가능해야 한다 ( os 에 무관 등 ) 

3) 변경성 : 코드변경이 자유로워야 한다.

4) 비가시성 : 무형의 결과임으로 구조가 드러나지 않는다.

 

소프트웨어 종류 

1) 주문형 소프트웨어 ( 온디멘드) : 특정고객, 기업 요구 만족 위해 제작, si

2) 패키지 소프트웨어 : 패키지화 하여 상업적으로 판매 , 솔루션기업

3) 임베디드 소프트웨어 : 다른시스템에 내장된 소프트웨어 (하드웨어 의존성이 높다. ) 

 

시스템 

필요한 기능을 실현시키기 위해 관련 요소를 조합한 집합체 , 소프트웨어도 컴퓨터 기반으로 하는 여러 시스템과 관계 맺음 

* 소프트웨어 개발  : 시스템 안에 속하는 여러 요소 파악 , 관계 설정 

 

시스템 성질 4가지 

1) 서브시스템 : 6개의 서브시스템으로 구성 

2) 기능적 분할 : 시스템은 작은 규모의 서브시스템으로 분할 가능

3) 시스템 경계 : 시스템과 주변 환경 구분할 수 있는 경계 ( 입출력 만나는 곳 ) 

4) 자동화 경계 : 시스템이 자동화된 부분과 수동 작업 부분을 경계 

 

 

소프트웨어 개발 작업 

명세화 -> 설계 -> 코딩 -> 검증 -> 유지보수 의 과정을 통해 프로그램, 문서 등 다양한 결과물 산출

 

명세화 : 고객과 계약자 간의 소프트웨어 작동방식, 성능요구, 제약사항 정의 , 설계 이전에 요구사항을 규격화 한다. 

설계 : 시스템 명세과 주어진 여건을 고려하여 계획을 구상한다.

코딩 : 구현 

검증 : 코드를 다 읽어보거나 ( 에러 exeption ), 데이터 넣어서 원하는 결과가 나오는지 테스트 한다.

유지보수 : 컴플레인이나 피드백을 받아서 유지보수 한다. 

 

 

소프트웨어 위기 

 

사람이 하는 행위이다 보니 실수가 발생하고 효율적인 설계가 불가하다.

소프트웨어 소유 및 유지비용이 개발비용만큼 높고 요구사항 미 충족, 일정에 차질 등 문제가 일어났고

sw 수요가 급증함에 따라 복잡성이 증가하여 기존 방법으로는 좋은 소프트웨어 구축이 불가능해졌다. 

 

=> 소프트웨어 공학의 필요성이 대두됨 

=> 위와 같은 과정으로 소프트웨어 만들어야 효율적 ! 

=> 계획이나 절차 없는 개발은 코딩과 수정 작업이 반복된다. 

=> 즉흥적인 개발의 문제점극복 ( 개발 지연과 예산초과, 낮은 품질, 유지보수 곤란, 재작업) 

 

 

소프트웨어 공학의 주제 

 

소프트웨어 공학은 크게 3가지 작업으로 구성된다. 

 

단계적 프로세스 

 

코딩에 치중하지 않고 요구분석, 설계 , 코딩, 테스팅 등 정해진 절차를 따라 작업한다.

소프트웨어 위기를 해결하기 위한 핵심 접근이다.

 

비지니스 요구 파악, 검토 -> 요구와 성능 명세화 -> 설계 및 구현 -> 테스팅 -> 목표환경에 설치 

 

-요구분석 : 소프트웨어 시스템이 해결해야 할 문제를 이해 ,사용자 요구 추출,시스템기능,성능, 제약사항 파악 (요구명세서)

-설계 : 요구명세에 기술된 문제의 솔루션 기술, 인터페이스 모듈 등 설계 (설계명세서)

-코딩 : 프로그래밍 (시스템, 유지보수계획)

-테스팅 : 원시코드 분석, 테스트 데이터로 테스팅 (테스팅 결과 보고서) 

 

품질보증 

개발 작업이 잘 수행되었는지 확인하며 개발의 산출물이 요구와 일치하는 품질 수준인지를 검사한다. 

 

검토 : 각 단계 작업이 제시된 절차와 방법에 맞게 진행되었는지 체크

확인 : 개발 완료된 결과물이 품질 수준에 맞에 생산되었는지 검사 

테스팅 : 구현된 소프트웨어 실행하여 예상 결과를 보이는지 확인 

 

 

프로젝트 관리 

개발과 품질 보증 작업을 관리, 감독 => 소프트웨어 시스템이 일정과 예산 내에 인도될 수 있도록 확인 

 

프로젝트 계획 : sw 개발전 수행, 개발의 방향, 방법 일정등을 계획

자원관리 : 인력 , 도구, 등 관리 할당

리스크 관리 : 위험요소 예측, 분석 관리 

프로젝트 수행과 모니터링  : 작업이 계획에 따라 진행되고 있는지 모니터링 

 

연관분야 

컴퓨터 과학과 소프트웨어 공학은 밀접하게 연관되어 있다. 

컴퓨터 과학은 계산효율, 자원공유, 최적화 성능 등을 강조하고 소프트웨어 공학은 기술 외적으로 

요구사상 추출, 사용자 인터페이스 등을 설계한다. 

컴퓨터 과학의 이론과 기술적인 기초가 소프트웨어 공학에 적용되어 더욱더 효율적인 소프트웨어 설계가 가능하다. 

 

 

Process and Methodology 

 

소프트웨어 공학 접근 방법의 핵심은? 프로세스와 방법론의 개념이다. 

 

프로세스와 방법론

 

프로세스 : 어떤 일을하기 위한 특별한 방법으로 단계나 작업으로 구성된다. 소프트웨어 공학에서의 프로세스는 sw 개발하는 공정 방법, 단계이다. 

 

방법론 : 정의된 작업들을 어떤 순서, 방법으로 하는가를 다루는 것이다. 

=> 작업순서에 따라 제시된 방법으로 작업을 수행하면 높은 품질의 소프트웨어 얻을 수 있다. 

=> 이러한 방법론 없이 개발하면 코딩과 수정이 사용자가 만족할 때 까지 반복된다. 

 

* 코딩-> 수정의 문제점 :

  - 사용자 요구와 설계 작업의 중요성을 깨닫지 못하기 때문에 계속 고치게 됨

  - 신중하게 설계하지 않으면 sw 구조 부실해 진다.  

  - 계획이 없어서 작업 목표가 없다. 

  - 체계적인 테스트나 품질보증 활동에 대한 인식이 부재하다. ( 결함 발견 가능성이 크다. ) 

 

프로세스 vs 방법론 

프로세스모델은 작업순서 정하기 위한 전체적 틀을 제공하며 작업단계를 엄격하게 규정하는 것이 아니다. 반면 방법론은 각 작업을 어떤 방식으로 수행할지를 결정한다.

 

-프로세스는 단계적인 작업 틀을 정의 , 방법론은 프로세스의 구체적인 구현

-프로세스는 무엇을 하는지 중점, 방법론은 어떻게 하는지 중점 

-프로세스는 결과물표현 언급 x, 방법론은 결과물 어떻게 표현하는지 표시 (input , output 계획)

 

* 프로세스 모델에서 각 단계에 다라 다른 방법론을 적용할 수 있다. 이 단계를 잘 수행할 수 있는 방법론으로 택하자! 

 

소프트웨어 생명주기 (SDLC) 

 

소프트웨어 프로젝트:  비용, 일정, 품질에 대한 목표를 성취하는것 

소프트웨어 개발 : 여러 작업 절차에 따라 작업절차를 진행하는것. 

 

=> 수행할 작업을 조직화 한 프로세스를 이용하자 

 

소프트웨어 생명주기(소프트웨어 개발 프로세스) : 요구분석 -> 설계 -> 구현 -> 테스팅 -> 유지보수 

 

프로세스 

소프트웨어 프로세스 : 소프트웨어 개발에 대한 기술적 관리적 절차 다룸

 

- 여러 다른 유형의 작업이 소프트웨어 개발을 위해 수행돼야 하는데 이런 작업들이 모여 프로세스를 형성 

- 여러 작업이 다수의 사람들에 의해 수행됨으로 프로세스는 여러 컴포넌트 프로세스(부 프로세스) 로 구성됨

- 개별 컴포넌트 프로세스는 서로 다른 목적을 가지거나, 협력해서 전체 소프트웨어 공학 목적을 만족시키는데 기여 

 

프로세스 명세 : 프로젝트에서 수행해야 하는 작업들과, 수행순서를 정의 (프로세스 수행방식, 입출력에 관한 구체적 정보 포함, 각 단계에서 무엇을 입력하고, 그 결과로 무엇을 출력하는지 설명할 수 있다는 것이지, 결과물의 구체적인 형식, 표현 방식을 방법론처럼 엄격히 정의 x ) 

 

프로세스 모델 : 적합한 프로세스 개발을 위한 가이드라인으로 특정 프로세스에 적용된다. 

 

프로세스 종류 

프로젝트 중심의 프로세스

1) 개발 프로세스 : 프로젝트 수행에서 중심이 되는 프로세스 , 개발작업, 품질보증 작업 포함

2) 프로젝트 관리 프로세스 : 비용, 품질, 기타 목표 맞추기 위한 계획, 제어 작업

 

기타 프로세스 

3) 형상관리 프로세스 : 변경관리 

3) 프로세스 관리 프로세스 : 새로운 기술, 도구 도입이 필요할 때 프로세스 수정및 관리 

 

프로세스 정의 

작업결과와 검증 조건을 명확히 정의 

-프로젝트는 단계로 이루어짐

-각 단계는 프로젝트 목표를 만족시킬 수 있는 정리된 작업으로 정의 

-각 단계에 유입된 결합 찾는데 초점

- 프로세스 결과 : 작업결과

- 최상위 단계는 소수의 프로세스로 나누며 목적이 명확하고 검증 가능한 문서를 생성해야 함. 

 

진입 조건, 출구 조건

- 각 단계가 언제 시작되고 끝내야 하는가 정의

- 집입조건 : 시작하기 위해 만족해야 할 조건

- 출구조건 : 끝내기 위해 만족해야 할 조건 

- 각 단계의 집입조건은 그 전 단계의 종료조건과 같아야함 

 

좋은 프로세스 특성

예측 가능성 

- 프로세스 결과가 프로젝트 완성전에 얼마나 정확하게 예측 가능한지 

ex) 같은 프로세스 사용시 비용예측 가능, 품질예측 가능 

- 예측 가능한 프로세스는 통계적 관리가 가능하다. 

 

테스팅과 유지보수 용이성 

일반적으로 소프트웨어 유지보수에 드는 비용은 개발 비용 초과

=> 전체 비용 줄이려면 개발의 목표가 유지보수 노력을 줄이는 것이 되야한다.

 

변경 용이성

소프트웨어는 여러 이유로 변경이 요구된다. 변경을 쉽게 다룰 수 있어야 (고객의 요구 변경으로 인한 수정 불가피) 

 

결함 제거 용이성

특정 단계에서 발생한 오류는 해당 단계에서 수정돼야 한다. 

 

프로세스 모델 

프로세스 모델

개발 단계를 단순화 하여 표현한 것 

각 모델은 특정 관점에서 나타낸 프로세스 유형 

소프트웨어 개발에 대한 다양한 접근방식 설명 가능

 

=> 어떻게 개발하는게 나을지의 관점에 따라 나뉜다. 

 

1)폭포수 모델

2)프로토타이핑 모델

3)나선형 모델

4)진화적 모델

5)unified Process 모델

6)애자일 프로세스 

 

1) 폭포수 모델

가장 오래되고 널리 사용된 프로세스 모델

항공 방위 소프트웨어 개발 경험으로 습득됨

 

각 단계가 다음단계 시작전에 끝나야 함 

- 각 단계사이에 중복, 상호작용 없음

- 이전 작업으로 돌아가는 재작업 없음

- 각 단계의 결과는 다음단계 시작전에 점검

- 각 단계 종료후 결과물 명확히 정의해야 

 

직능 중심의 프로젝트 조식이 가능

- 각 단계의 작업을 전문으로 하는 팀 구성

- 각 팀이 파이프라인과 같은 형태로 작업 구성 (각 팀이 작업 순차적으로 구성) 

 

크고 복잡하며 오래 지속되는 프로젝트에 적합 

 

계획 : 다음 질문의 대답을 찾는 단계 , 범위정하기, 위험분석 등, 문제 서술서를 결과물로 도출

요구분석 : 도메인(문제영역) 에 집중 ,요구분석서를 결과물로 도출 

설계 : 솔루션에 집중, db ui 등 설계, 시스템 설계서를 결과물로 도출 

구현: 코딩과 단위테스트 협력작업이 필요한경우 설계와 겹치기도 함. 

테스트 : 모듈단위테스트 -> 모듈 통합하면서 시스템단위 테스트 

운영 및 유지보수 

 

V 모델 : 폭포수 모델의 변형

개발 : 요구분석(인수 테스팅) -> 시스템설계(시스템 테스팅) -> 상세설계(통합 테스팅) -> 코딩(단위 테스팅)

 

검증 강화의 관점에서 폭포수 모델 확장 

-> 단위테스팅: 코딩단계에서 작은 모듈이 완성되면 단위테스트 수행하여 확인 

-> 통합 테스팅: 모듈이 잘 결합되어 올바르게 동작하는지 확인

-> 시스템 테스팅 : 전체 시스템이 재대로 동작하는지 확인

-> 인수 테스팅 : 사용자의 요구를 모두 반영하였는지 확인

 

*높은 신뢰성이 요구되는 분야에 적합 

 

장점 

-프로세스단순, 이해좋음(초보자가 쉽게 적용 가능), 각 단계가 명확(진행 상황 관리가 쉬움)  -> 진행상황 관리 쉬움 

 

단점 

-이전 단계의 문제가 발견되지 않고 넘어가는 경우 한계가 있음 

-전체 요구사항이 확정되지 않고 문서화 되지 않는다면 설계작업 진행 불가

-애매한 부분 남았거나 프로세스 진행 과정 변경될 수 있으나 수용 불가

-테스트 작업이 플젝 후반, 시스템이 완성된 후에 시작됨

 

적용

- 개발자가 비슷한 sw 설계와 응용 문제를 미리 아는 겨우

- 요구사항이 명확한 대규모 시스템 장시간 개발

2)프로토타이핑 모델

- 요구사항에 대한 피드백을 받기 위해 시스템을 실험적으로 만들어 사용자에게 보여주고 평가하게 하는 법 -> 시스템 사용과정 보여줄 시나리오나 화면 모형 필요

- 시스템의 작동을 시뮬레이션 하여 사용자 반응 보여줌

- 사용자와 소통하여 요구를 정확히 파악 -> 미반영 요구사항이나 잘못된 이해 방지 

- sw 일부를 구현한 프로톼입은 추구 구현단계에서의 골격코드가 될 수 있음 (일회용과 계속 발전시켜나가는 진화형이 있음) 

- 사용자 요구가 만족되면 목표시스템 구현에 진입

 

* 공동의 참조모델은 사용자와 개발자의 의사소통을 도와주는 매개체이다. 

 

프로토타입 목적

-사용자 요구사항 추출, 확정 (프로토타입 보고 요구 수정 가능) 

- 개발 단계에서 유지보수가 가능

 

장점

-문제점 빠르게 파악 -> 요구사항 반영 , 정확한 기능요구 알 수 있음

-고객 요구사항 충분히 반영 -> 제품만족도 향상

-프로토타입 매개로 의사소통 원활 -> 요구사항 빠르게 수용 가능

 

단점 

-프로토타입 개발에 많은 비용발생

-프로토타입으로 요구가 정리되면간리가 어려움 (중간산출물 정의 난해)

 

적용

- 개발 착수 시점에 요구가 불투명할때

- 실험적으로 실현가능성 알아보고 싶을때

- 혁신적 기술을 사용해 보고 싶을때 

 

3) 나선형 모델

폭포수 모델과 프로토타이핑 모델의 장점에 위험분석을 추가한 모델이다. 각 단계가 끝난 다음 다음 단계로 넘어가며, 반복적인 프로토타이핑을 진행한다. 

 

다음 네가지 단계를 반복 순환하면서 시스템을 확대시켜 나가는 방법

1) 목표, 방법 , 제약 조건 결정

2) 위험 요소 분석 및 해결

3) 개발과 평가

4) 다음 단계의 계획

 

특징

위험을 분석함

sw 개발 프로세스를 risk management 측면으로 접근 (프로젝트 초기 실패 요인과 위험 요소 찾아서 대비하자는 철학) 

 

장점

- 반복적인 개발 통해 소프트웨서 품질을 높일 수 있음

- 시스템을 여러 부분으로 나누어 여러번의 개발주기를 거쳐 점증적으로 시스템 완성 ( 반복 테스트로 강인성 향상 ) 

- 한 사이클에서 추가 못한 기능은 다음 단계에 추가 가능

- 대규모 시스템 개발에 적합

 

단점

- 각 사이클에 대한 관리가 어려움

- 초기 위험분석을 잘못한 경우 프로젝트 성패 요인이 됨

- 성공사례가 많이 알려져 있지 않음 

 

적용

-재정적, 기술적으로 위험부담이 큰 경우

-요구사항이나 아키텍쳐 이해가 어려운 경우

-성능에 문제가 있거나 중심 기술에 문제가 있는 경우 

 

4) 진화적 모델 

진화형 프로토타이핑

- 시스템의 핵심 부분에 대해 기능이 명확하고 개발 효과도 좋은 부분을 우선적으로 개발

- 이를 계속 개선하여 나중에 사용될 시스템으로 진화 시켜 나가는 방법

 

시스템을 여러번의 사이클로 나누어 개발

- 초기에 모든 요구사항 파악하여 확정 불필요

- 개발 도중 요구 추가 , 변경 쉬움 

- 위험도가 높은 새로운 기술 적용 가능

- 개발과 테스트를 반복함으로 위험 축소에 기여 

 

시스템을 발전시키는 두 가지 방법

- 점증적 방법 : 일부 기능만 포함하여 서브시스템 릴리즈

- 진화적 방법 : 시스템 전체 기능을 대상으로 릴리즈 

 

장점

- 몇가지 기능이 부족하더라도 초기에 사용 교육 가능 (해당 과정에서 부족한 점 다음 릴리즈때 향상 가능)

- 새로운 기능을 가진 소프트웨어에 대한 시장 빠르게 형성

- 가동 중인 시스템에서 일어나는 예상치 못했던 문제를 신속, 꾸준하게 수정 가능

- 개발팀이 릴리즈마다 다른 영역에 초점 둘  수 있음

 

단점

- 프로젝트 관리가 복잡해 질 수 있음 소규모 프로젝트에 부적합 

- 반복적인 프로세스로 프로젝트의 끝이 안보일 수 있음 ( 플젝 실패 위험 높아짐, 비용많이 발생, 위험분석위한 인력필요 ) 

- 프로젝트의 진행이 위험 분석에 크게 의존

 

적용

- 요구사항이 명확하지 않거나 자주 변경

- 복잡하거나 대규모 시스템 개발

- 시장 변화에 빠르게 대응해야 하는경우 

 

5) Unified Process 

통합 프로세스 모델은 여러 사이클로 구성

- 각 사이클은 시스템을 출시함으로 종결

- 여러 반복 과정 -> 여러 사이클 통하여 점증적 개발

 

사이클은 네 단계로 구성 

- 도입-> 정련 -> 구축 -> 전환

- 각 단계는 중요한 점검일정으로 종료 

- 관리자가 프로젝트에 대한 중요 결정을 내림

 

각 반복 과정은 일련의 워크플로 작업을 따라 감

- 워크플로 작업 : 요구분석, 설계, 구현, 테스팅 등 

- 그림에서 그래프는 각 단계에 수행되는 워크플로 작업 수준 표시 

- 반복과정 #1 이 개념 적립 단계 

 

특징

- 유스케이스 중심의 프로세스 

- 아키텍쳐 중심의 프로세스 ( 개발 초기에 아키텍쳐와 전체 구조를 확정하고 이를 개발 가이드로 활용 ) 

 

사이클 구성 4 단계 

1) 도입 : 프로젝트의 목표와 범위를 설정하는 단계  , 1-2 회 정도 반복으로 도입단계 진행 , 간단한 유스케이스 모델과 소프트웨어 구조, 프로젝트 계획 작성 

2) 정련 : 시스템의 아키텍쳐와 설계 구체화 , 여러번의 반복과정으로 이루어짐, 대부분의 유스케이스 작성, uml 다이어그램을 활용하여 아키텍쳐 설계

3) 구축 : 실제 코드를 작성하고 시스템 구축, 남아있는 유스케이스 구현-통합 

4) 전환 : 시스템 배포 

 

장점

- 방법론과 프로세스가 잘 문서화 돼있어서 교육받기 좋음

- 고객의 요구변경과 관련된 리스크를 적극적으로 해결

- 통합을 위한 노력과 시간을 줄일 수 있음

- 쉽고 빠르게 코드를 재사용 

 

단점

- 프로세스 너무 복잡, 이해하기 어렵고 적확히 적용하기 어려움

- 소프트웨어 프로젝트 참여자들의 협동, 의사소통에 대한 가이드가 없음

- 조직화 되지 않은 개발로 완전히 알려지지 않은 형태의 소프트웨어 개발로 이어질 수 있음 

 

6) 에자일 프로세스 

프로젝트에 대한 빠른 피드백을 통해 방향을 평가하여 짧은 사이클을 반복 

 

기존 폭포수 모델은 sw의 불확실성에 대처가 어려움 

변경은 바람직하지 않고 계획 중심의 통제가 중요하다는 인식의 문화 였다.

 

개발방식

-2-6주간의 짧은 주기로 개발을 반복하여 부분적인 기능 완성

-이러한 사이클을 통해 실행되는 소프트웨어 개발 -> 단계적으로 시스템 전체 완성 

익스트림 프로그래밍

소규모 , 개발조직이 불확실하고 변경이 많은 요구일때 적합

 

xp 기반 개발원리 

사용자 스토리 

- 긴 요구사항 문서 x 간단한 사용자 스토리 작성

매일 빌드와 통합

- 개발한것 매일 빌드, 통합

테스트 주도 개발

- 코딩전 요구사항 검증하는 테스트 시나리오 작성, 테스트 시나리오 

- 테스트 시나리오 통과 위한 최소한의 코드 작성

- 작성한 코드 리팩토링

- 검증 비용이 크지 않으며 변경에 유연

페어 프로그램

- 두명의 프로그래머가 하나의 컴퓨터 공유하며 한명은 코딩, 한명은 확인 담당하며 개발

스크럼

개발 팀원 모두가 함께 소통하고 협력하여 짧은 주기 반복 -> 소프트웨어 개발

할일을 정하고 여기 우선순위를 부여한다. 

팀과 사용자가 지속적으로 상호작용하여 시스템을 향상시킨다. 

 

scrum 기반 개발 원리 

-짧은 주기 반복하여 출시주기 단축

-각 스프린트는 2-4주 지속

-매일 15분간 스크럼 회의

-스프린트가 끝나면 회고 진행

* 익스트림보다 짧은 주기를 추구한다. 

 

장점

-소프트웨어 빠르게 배포 가능

-항상 최신작업 수행하기 때문에 자원낭비 적음

-문제와 결함 빨리 감지, 수정 가능

-불필요한 문서화에 시간 덜 소모

-비용저렴, 아이디어 실험 테스트 용이 

 

단점

- 문서화 등한시, 신규개발자의 개발속도 높이기 어려움

- 개발자와 고객이 지속적 상호작용 해야함 (더 많은 시간, 에너지) 

- 명확한 끝이 정이안되면 프로젝트 계속됨

 

모델  선택

모델의 선택은 프로젝트의 상황과 요구에 좌우된다. 모델을 잘 선택하면 생산성이 높아지며 경우에 따라서는 최적 효과를 위해 모델의 융합이 이루어 지기도 한다. 

 

모델 별 적합한 sw 프로젝트 

- 일반적인 구축 ( 위험성 낮고 기존사례 많은경우, 한정된 자원) : 폭포수

- 대규모 재구축 ( 향후 변경여지 많음, 요구사항 확정 어려움 ) : 진화적, 나선형

- 임베디드 시스템 (sw 외에 여러요소 고려) : 진화적 

- 프로젝트 타당성 검토 : 프로토타입, 나선형

- 연구형 개발( 지속적 검증 ) : 프로토타입, 나선형

- 소규모(단기간) : 애자일 프로세스 

 

지원 프로세스 

 개발을 적절히 수행하려면 개발 프로세스 외에 또 다른 성격의 프로세스가 필요하다. (지원, umbrella 프로세스) 

개발 과정 중 어느 한 단계에만 필요한 작업이 아니라, 개발 전 과정에 필요하다. 

 

-개발 프로세스 : 프로젝트 수행에서 중심이 되는 프로세스 (개발, 품질보증 작업) 

-프로젝트 관리 프로세스

-형상관리 프로세스

-프로세스 관리 프로세스 : 새로운 기술, 도구의 도입필요성으로 프로세스 수정, 관리 

 

관리 프로세스 

적절한 관리는 소프트웨어 개발을 잘 통합하는데 도움이 된다. 

비용과 품질 목표를 달성하기 위하여 관리하는 모든 작업을 말한다.

 

목적: 선택된 개발 프로세스가 잘 구현되었는지 확인, 목표를 맞추기 위해 각 단계의 작업에 자원을 할당해준다. 

진척 상황을 모니터링하며 필요하면 적절한 조치를 취하는 작업을 해준다. 

 

3가지 주요 작업

계획 : 프로젝트의 목적에 맞는 소프트웨어 개발 계획을 세움 (비용,일정 등 , 가장중요한 작업 모니터링과 제어의 기준이됨) 

모니터링 : 모든 작업이 목적에 부합하며 계획대로 진행되는지 확인 (데이터수집)

제어 및 분석 : 모니터링 통해 확인된 사실 분석, 계획과 차이 조정 ( 제어와 달리 분석은 개발 프로세스 끝난 후에 이루어짐 ) 

 

*모니터링과 제어는 개발 프로세스의 모든 단계를 포함, 가장 긴 시간동안 이뤄짐

 

품질보증 프로세스 

프로세스와 프로덕트에 대한 품질을 관리하고 향상시키는 것을 목적으로 한다. 

 

인스펙션 프로세스 

개발 결과에서 결함을 찾거나 방지하기 위한 노력을 한다. 

정의된 프로세스를 따라 동료 그룹이 작업결과를 감시하는 것 

-전문 기술 인력이 담당

-참석자 역할 정해짐

-문제 자체에 집중

-검토자료기록

 

프로세스 관리 프로세스 

-프로세스의 품질과 생산성의 향상

-각 프로세스의 능률을 측정하여 더 효과적인 프로세스로 교체 , 개선

 

형상관리 프로세스 

 

소프트웨어 프로젝트에서는 변경이 지속적으로 발생하며 이러한 변경은 코드, 데이터, 문서등의 수정으로 이어진다.

개발중에 발생하는 변경을 체계적으로 제어하는 것이 형상관리 프로세스의 일이다. 

 

*아이템의 현재상황과 변경 요청을 기록, 보고 -> 아이템의 완벽성과 정확성을 검증하는 작업

 

개발작업과 독립적인 작업 

- 높은 품질의 sw 프로덕트 위해 필수적

- 형상관리는 어떤 자원 하나라도 빠짐없이 문서의 정확한 버전을 코드와 함께 제공하려는 활동 ( 문서, 코드 , 관련자원, 버전을 관리 )

 

방법론 

 

프로세스 : 개발에 필요한 작업만 명시, 가가 단계의 입력자료-산출물 정함 (그 내용이 어떻게 표현되는지 규정하지 않음) 

 

방법론 : 소프트웨어 프로세스의 각 작업을 어떻게 수행하는가를 정의, 각 단계의 입력자료, 산출물 표현 방법까지 명시한다. sw 보는 관점에 다라 산출물의 표현이 달라진다. 

 

프로세스가 구체적으로 구현된 것 == 방법론

- 프로세스는 하나 이상의 방법론으로 구현 가능

- 방법론은 sw 개발조직이 선택

 

구조적 방법론

실세계의 문제를 처리한다는 관점으로 모델링

 

모델링은 자료흐름도를 사용한다.(데이터흐름도)

복잡한 문제를 다루기 위해 분할과 정복 원리를 적용

-시스템 전체를 하나의 프로세스로 보고 배경도를 그린다. 

-복잡한 프로세스는 더 단순한 프로세스로 분할한다. 

-말단 프로세스까지 반복

-말단 프로세스는 입출력, 자료구조, 알고리즘 명시 

 

즉 구조적 방법론은 자료 흐름도를 구조도로 변경하는 과정이다. 

(데이터 흐름 정의한 다음 거기에 맞춰서 시스템 논리적 구조 설계)

자료흐름도 : 프로세스 사이의 관계는 자료흐름

구조도 : 소프트웨어 모듈간의 관계는 제어흐름 

 

* 프로그램 로직 중심, 그림그려 요구사항 분석, 함수위주, 모듈로 설계 

* 오래사용되어 검증된 방법이다. 이해하기 쉽다. 

* 분석에서 설계과정에 대한 전환이 어렵다. 

 

정보공학 방법론 

정보시스템은 기업의 비지니스와 밀접하게 관련됨

기업 전체의 조망과 데이터 통합의 어려움을 극복하기 위해 제안됨

 

특징

-기업중심 : 비지니스 중심 소프트웨어 개발 

-전략적 시스템 계획 중심 : 개발에 경영층 요구 반영

-데이터중심 : 비지니스 프로세스는 계속 변해도 데이터는 대부분 유지됨, 잦은 변화에 대응하고자 데이터중심 설계 ( 프로세스와 데이터 분리 , 데이터 통합 어려움 극복 )

-분할과 정복 : 비지니스 문제 영역에 분할과 정복 원리 적용( top-down 방식으로 문제영역-> 비지니스 영억 -> 비지니스 시스템 -> 구현시스템 발전) 

-공학적 접근 : 초기단계=분석,설계등 철저히 -> 후속단계: case 도구 (uml) 사용하여 소스코드 자동생성

-사용자의 적극적 참여 : 초기단계= 사용자 참여, 프로토타이핑 도입하여 요구사항 명확화, 개별완료후 사용자 불만 최소화 

 

*자료위주, 엔티티로 설계, 데이터중심을 업무절차 및 환경변화에 유연하다. 

 

객체지향 방법론 

실세계를 객체라는 관점으로 보고 객체 사이의 상호작용을 모델링

자료와 함수를 객체로 묶고 , 객체안의 메세지를 호출하여 원하는 기능을 수행한다. 

 

복잡한 대규모 시스템을 클래스로 모듈화하고 캡슐화함 

모듈화 : sw 시스템을 더 작고 독립적인 모듈로 나눔 (각 모듈 특정기능, 독립적 개발, 테스트)

 

ex) OMT, booch, 유스케이스등 

 

*비지니스를 유스케이스로 분석하고 객체들로 시스템 구성

*클래스위주, 객체로 설계한다.

*실세계와 밀접하며 유지보수 쉬움, 설계-> 코딩으로 전환이 쉽다.