소프트웨어 공학 (Chapter 01 ~ Chapter 02)

[ 1. An Introduction to Software Engineering ]

 

[ Software Engineering ]

- 소프트웨어는 전문적이고 비용적으로 효율적인 소프트웨어 개발을 위한 이론, 방법론, 도구론들과 관련되어 있음
- 대부분, 더 많은 시스템들은 컨트롤된 소프트웨어임
- 선진국들은 소프트웨어에 의존함
- 소프트웨어 코스트들은 자주 컴퓨터 시스템 비용을 지배함
- 소프트웨어를 유지하는 비용이 개발하는 비용보다 많이듦

 

[ 소프트웨어 제품의 종류 ]

- Generic Software : 이를 사고 싶은 어떤 사용자들에게든 팔림, 소프트웨어 명세서는 소프트웨어 개발자로부가 소유함

- Custom Software : 특정 소비자들의 니즈를 충족시키기위해 해당 소비자들에게만 판매되는 소프트웨어, 소프트웨어 명세서는  소프트웨어를 위한 소비자들이 가짐

 

[ 좋은 소프트웨어 4요소 ]

- 유지성 (Maintainability)

- 신뢰성 (Dependability)

- 효율성 (Efficiency)

- 민감성 (Acceptability)

 

[ 소프트웨어 엔지니어링 ] 

- 소프트웨어 엔지니어링은 초기 시스템 사양부터 배포 후 유지 관리까지 소프트웨어 생산의 모든 측면을 다루는 엔지니어링 분야로 설명

- 엔지니어링 분야 : 재정적 제약들과 조직적 제약들을 고려하여 문제를 해결하기 위해 적절한 이론과 방법론들을 사용하는것

- 소프트웨어 생산의 모든 관점들 : 기술적인 개발과정뿐만 아니라 프로젝트 관리와 소프트웨어 생산을 지원하는 도구 개발이다

 

 

 

[ 소프트웨어 공학에서의 기능들 ]

- 소프트웨어 사양 : 요구공학, 소비자와 엔지니어들은 소프트웨어의 동작들을 설계하고 제약을 줌

- 소프트웨어 개발 : 소프트웨어는 디자인되고, 프로그래밍된다, Continuous Test and Integration Platform ( CTIP ), 디자인과 실행을 세부화시킨 구조물 디자인

- 소프트웨어 검증 : 소프트웨어는 소비자의 요구들이 무엇인지를 확실하게 검증함, Varification & Validation (V&V). Testing

 (SDLC임 ppt의 SLDC는오타)
 

 

[ Web-based systems ]

- Complex and Distributed System
- Software Reuse
- Incremental and Agile Development
- Service-oriented System
- Rich Interface




[ 2. Software Development Process ]

[ Software Process ]

- 소프트웨어 프로세스는 소프트웨어 시스템을 개발하는데에 필요한 구조화된 활동들의 집합이며, 아래 구성들을 대부분을 가지고 있음

- Specification : 시스템이 무엇을 해야하는지 정의함
- Design and implementation : 시스템을 구성하고 구현함
- Validaton : 소비자들이 원하는 것이 무엇인지 확인
- Evolution: 변화하는 소비자들의 니즈들에 따라 시스템을 발전시켜나감

- 소프트웨어 프로세스 모델은 다양한 관점에서 표현된 프로세스의 추상적인 표현임

- Waterfall
- Incremental
- Evolutionary
- Spiral
- Component Based Development (CBD)
- Iterative - Agile
- Iterative - Rational Unified Process (RUP)

 

 

[ Software Process Model ]

- 고급 엔지니어들이 소프트웨어를 체계적으로 엔지니어링을 하는데 필요한 활동, 작업, 이정표, 작업 제품들의 집합을 정의함

- 누가 무엇을 하는지, 언제 이것을 할지, 어떻게 특정 목표를 이룰 지를 정의함 ( Software Development Lif e Cycle - SDLC)


소프트웨어 개발 생명 주기 (SDLC, Software Development Life Cycle)

- 위에서 정리한 waterfall model을 포함한 7개 모델들

 

 

[ Waterfall Model ]

- 1960년에 개발됨
- 소프트웨어 개발에 대한 체계적이고 일련적인 접근들을 제안
- 별개의 구분된 단계들이 존재
- 유연하게 여러 단계를 분할하지 않아 특정 단계가 완료되면 바뀐 고객의 요구사항을 수용하기 어려움

- Waterfall Model은 요구사항이 프로젝트 초기에 고정되고 확립된 상태에서 효과적임
- Waterfall Model은 직선적인 방법으로 작업이 완료될 수 있을 때 효과적임
- Waterfall Model은 여러방면으로 단계별로 진행되는 대규모 프로젝트 개발에 효과적임

- Waterfall Model은 프로젝트의 Requirement가 잘 이해되고, 개발 과정의 전체적인 틀이 크게 변경될 것 같지 않는 경우에만 적합함

[ Incremental and Evolutionary Model ]

- 여러 개의 증분이나 소프트웨어의 일부가 병렬적으로 개발되며, 각 단계는 독립적으로 개발되었다가 나중에 통합됨

- 이러한 방법들이 여러 번의 반복을 거쳐 최종 버전이 진화적으로 제공됨

- 유용한 소프트웨어의 개발과 배포를 고객에게 더 빠르게 제공할 수 있음
 
- 여러 증분이 동시에 개발되기에 프로세스가 덜 시각적이며, 문서화가 어려움

- 시스템 구조가 새로운 증분들이 추가됨에 따라 저하될 수 있음

- 규칙적인 변화들은 이 시스템의 구조를 붕괴하는 경향이 있으며,  추가된 변경사항을 포함하는 것은 점점 더 어려워지고 비용이 많이듦

 

[ The Spiral Model ]

- 위험성 분석과 반복적 개발이 더해진 Waterfall Model의 원형 버전임

- 목표, 제약조건 등을 결정 -> 위험 분석 -> 구현 및 테스트 -> 평가 및 계획 의 과정들을 계속해서 반복함

 

- 오리지널 버전은 리스크 어널리시스 먼저 함 (스파이럴 모델)

 

[ Component Based Development (CBD) ]

- 소프트웨어 재사용에 기반함 ( Commercial Off The Shelf, COTS를 사용 )

상용화된 기성품 ---> (Commercial Off The Shelf, COTS)

- 재사용 요소들은 새로운 요구사항에 맞게 동작 및 기능하도록 구성가능해야 함

- 재사용은 지금 개념적으로 많은 유형의 사업 시스템을 구축하는데에 있어 가장 기본적인 접근 방식임 


재사용되는 컴포넌트들의 종류 -> COTS, Web Service, Package와 같은 객체 컬렉션

- 요구사항 명시 --> 소프트웨어 식별 -> 요구 사항 개선 -> 애플리케이션 시스템 구성, 구성요소 선별 -> 시스템 통합의 단계를 거침

- 처음부터 개발하는 소프트웨어가 줄어들기에 관련된 비용과 위험성이 줄어들며, 기존 구성요소를 재사용하기에 개발 시간도 단축됨

- 기존 소프트웨어를 활용하기 위해 특정 요구사항에 대해 타협이 필요할 수 있으며, 재사용된 시스템 구성요소들을 발전시키는 것에 대한 제어를 잃어버림

 

[ Agile - Iterative ]

-Agile Development는  빠른 프로토타입 제작과 빠른 개발 경험을 강조하는 방법론들을 포괄하는 용어임
(eXtreme Programming- XP , Test First Development - TFD가 대표적인 예시)

- 원형적임 ( 순환형 사이클)
- 증분적임 ( 한번에 제품을 전달하지 못함)
- 사용자 참여적임


- Agile 원칙은 아래 4개가 있음
- 개인과의 상호작용 > 프로세스와 도구
- 작동하는 소프트웨어 > 포괄적인 문서
- 고객 협력 > 계약 협상
- 변화에 대응 > 계획 이행

 

 

[ Rational Unified Process (RUP) ]

- 반복적임 (점진적이고 진화적) : 3~4주 동안의 작은 Waterfall Cycle을 반복
- 위험 중심, 고객 중심, 아키텍쳐 중심
- 사용 사례 중심

- 위험 중심과 클라이언트 중심의 반복적인 계획의 결합을 추구함

 

[ Waterfall vs Iterative ]

Waterfall은 미리 결정된 계획이고,  프로젝트 진행이 선형적이기에 유연성이 없음, 성공은 초기계획으로 측정됨, 요구사항이 초기에 고정되어 있는 프로젝트에 적합

iterative는 유연하며 계획이 증분적으로 수행하기에 변화하는 고객의 요구들을 반영하기 쉬움, 요구사항이 다양한 프로젝트에 적함

- 프로세스 개발에 옳고 틀림은 없음, 대부분의 소프트웨어는 Waterfall과 Agile을 합쳐 사용함

 

[ Process Activities ]

- 기본적으로 소프트웨어 사양, 개발, 검증, 발전등의 4단계 활동들로 구성되며, 각각 다양한 개발 프로세스에서 다르게 구성됨

 

 

[ Requirements Engineering Process ]

Requirements Engineering은 어떤 서비스를 만들고 시스템 동작과 개발을 위해 어떤 제약조건을 둘지 정하는 과정이다

What Service -> 기능적 요구사항 (Functional Requirements, FR)
Constrains -> 비기능적 요구사항 (Non Functional Requirements, NFR)

Requirement Engineering 프로세스 단계

- 요구 사항 추출 및 분석 : 이해관계자가 시스템에서 
필요로 하는 것이 무엇인지 이해하는 것

- 요구 사항 사양 : 요구사항에 대해 디테일하게 정의하는 것, 요구사항에 대한 자세한 문서가 작성됨

- 요구 사항 검증 : 요구사항에 대한 타당성을 확인하는 것

 

 

[ Software Design and Implementation ]

Software design : 사양을 구현하는 소프트웨어 구조를 설계
Implementation : 이 구조를 실현가능한 프로그램으로 바꾸는 것

 

 

[ Design Activities ]

- Architectural Design : 시스템의 전체 구조, 주요 구성 요소 (하위 시스템 또는 모듈), 이들의 관계 및 배포 방법을 식별
(ex - Architecture Description (AD) 

- Interface Design : 시스템 구성 요소 간의 인터페이스 정의

- Component Selection and Design : 재사용 가능한 구성 요소를 검색, 재사용이 불가한 경우 직접설계

- Database Design : 시스템 데이터 구조와 이러한 구조가 데이터베이스에 표현되는 방식을 설계

 

 

 

[ Implementation Activities ]

- 소프트웨어는 프로그램을 개발하거나 응용시스템을 구성하는 것으로부터 구현됨

– 프로그래밍 (Programming) : 표준 프로세스가 없는 개별 활동, 깔끔한 코드 + 리팩토링 + 단위 테스트

- 디버깅 (Debugging) : 프로그램 오류를 찾아내고 해당 오류를 수정하는 활동 (Testing은 결함을 찾아내는 활동만 가리키므로 다름)

- 설계 및 구현은 대부분의 소프트웨어 시스템 유형에 대해 인터리브된 활동입니다

 

[ Software Validation ]

- Verification and Validation (V&V)는 시스템이 사양을 준수하고 있는지와 시스템 고객의 요구사항을 잘 충족시키고 있는지를 보여주는 것임 (코드 검사와 시스템 테스트 등이 포함됨)

 

[ Software Testing ]

- 소프트웨어 테스팅 단계는 아래와 같음

- 컴포넌트 테스팅 : 단위 테스팅과 모듈 테스팅이 있음, 개별 컴포넌트들은 독립적으로 테스팅됨, 컴포넌트들은 함수나 객체나 엔티티의 일관된 그룹등일 수 있음

- 시스템 테스팅 : 시스템 전체를 테스팅함, 긴급속성에 대한 테스팅은 특히나 더 중요함

- 승인 테스팅 : 고객 데이터를 테스트하여 시스템이 고객의 요구 사항을 충족하는지 확인하는 검증 활동임

 

 

[ Software Evolution ]

- 비즈니스 환경에이 바뀜에 따라 변경되는 요구사항에 맞춰 소프트웨어도 진화하고 변경되야함
- 소프트웨어는 본질적으로 유연하고 변경될 수 있어야 함
- 유지보수 (Maintenance Maturity Model, S3M 모델)

 

 

[ Software Improvement - Process Improvement ]

- 기존 프로세스를 이해하고 이러한 프로세스를 변경하여 제품 품질을 높이거나 비용 및 개발 시간을 단축시킴


소프트웨어 품질을 향상하고 비용을 절감하는 방법

- CMMI와 같은 프로세스 성숙도 정도를 측정하여 체계적인 소프트웨어 개발 프로세스에 대한 좋은 기술 과 유지 관례를 반영

- 프로세스 분석 (Process analysis) : 현재 프로세스를 평가하고 프로세스 약점과 병목 현상을 식별, 프로세스를 설명하는 프로세스 모델을 개발할 수도 있음

- 프로세스 변경 (Process change) : 확인된 프로세스 약점 중 일부를 해결하기 위해 프로세스를 변경하고, 변경 효과에 대한 데이터를 수집을 재개

- 프로세스 측정 (Process measurement) : 소프트웨어 프로세스 또는 제품의 하나 이상의 속성을 측정하고, 프로세스 개선이 효과적인지 결정하는 기준을 만듦

 

 

 

 

[ Software Improvement - Process Measurement ]

- 가능하다면 정량적 공정 데이터를 수집해야 함
- 그러나 조직에는 명확하게 정의된 프로세스 기준이 없는 경우가 많음
- 무엇을 측정해야 할지 모르기 때문에 매우 어려움
- 조직의 목표는 프로세스 개선하는 것이여야 함

- 프로세스 지표의 예는 아래와 같음
- 프로세스 활동이 완료되는 데 소요되는 시간
- 프로세스 또는 활동에 필요한 리소스
- 특정 이벤트의 발생 횟수

 

 

 

[ Capability Maturity Model Integrated, CMMI ]

- 카네기 멜론 대학교(CMU)의 소프트웨어 엔지니어링 연구소(SEI)에서 Capability Maturity Model Integration (CMMI )를 개발함

1단계) 초기 (Initail) : 본질적으로 통제되지 않음

2단계) 반복성 (Repeatable) : 제품 관리 절차를 정의하고 사용됨

3단계) 정의 (Defined) : 프로세스 관리 절차와 전략이 정의되고 사용됨

4단계) 관리 (Managed) : 품질 관리 전략이 정의되고 사용됨

5단계) 최적화 (Optimizing) : 프로세스 개선 전략이 정의되고 사용됨

 

 

[ SW Development Methodology ]

Software Development = 소프트웨어를 활용해 컴퓨터에서 발생하는 문제 해결


문제에 대한 자연어 설명 -> 해결책에 대한 프로그래밍 언어을 정하여 프로그램을 설계 및 구현 -> 컴퓨터 시스템에서 프로그램 실행 

 

 

 

[ Procedural Programming ] 

- 절차 지향적 프로그래밍으로, 절차에 따라 구성되는 프로그래밍

- 특정 문제를 해결하기 위한 단계별 지침인 알고리즘을 개발하는 데 중점을 둠 (제어 중심)

-데이터를 구조화된 형식으로 보관하도록 설계된 구조를 사용하여 데이터를 구성 (데이터 중심)

 

 

 

[ Structured Analysis and Structured Design, SASD ]

- 구조적분석 개발방법론 (Structured Analysis and Structured Design, SASD)

- 절차적 프로그램에 사용되는 고전적인 소프트웨어 개발 접근 방식

- Top-Down Divied and Conquer 방식을 사용하여 크고 복잡한 문제를 관리하고 해결하기 쉬운 더 작은 하위 문제로 나누는 것을 포함 (계층적 접근 방식은 시스템 복잡성을 관리하는 데 도움이 됨)

- Data Flow Diagram (DFD)를 사용하여 시스템 내의 데이터 흐름을 표현

 

 

[ Object-Oriented Programming ]

- 객체 지향적 프로그래밍으로, 프로그램은 객체로 구성됨

- 객체들의 Coummunication을 통해 시스템 기능 제공

- Object : data와 operation으로 구성

- Object communication : 객체는 자신의 데이터로 다른 객체의 작업을 호출함

- 명시적인 데이터 흐름은 없고, 객체 간 통신 순서만 있음

 

 

 

[ Object-Oriented Analysis and Design, OOAD ]

- 객체지향 개발방법론 (Object-Oriented Analysis and Design, OOAD)

- 요구 사항을 확인하고 도메인 모델을 만들어 적절한 클래스에 메서드를 추가하고 요구 사항을 충족하기 위해 개체 간의 메시징을 정의함

- 객체지향 분석 (Object-Oriented Analysis, OOA) : Domain Model을 발견하고, 요구사항을 식별함 (사용 사례 모델)

- 객체지향 설계 (Object-Oriented Design, OOD) : 소프트웨어 객체를 정의하고, 요구 사항을 충족하기 위해 객체들이 어떻게 협력할지를 정의함

- 다양한 개발 프로세스 모델이 가능 (Waterfall , RUP)