🌚 SW 공학 과목

게시 2023/03/09 업데이트 2024/04/09

By Mascari4615

235 분읽는 시간

Chapter 1 : 서론

전문적 소프트웨어 개발
- 소프트웨어 공학은 무엇인가
소프트웨어 공학 윤리
- 소프트웨어 공학에 영향을 미치는 윤리적 이슈에 대한 간단한 소개
사례 연구
- 책 전반에 걸쳐 사용하는 예제
SW 공학
- @온 세상이 SW다
- 소프트웨어의 특성으로인한 개발의 어려움
  - 무형이기에, 복잡하고, 개발 과정/진행 상황을 이해/파악하기 어렵고, 변경에 많은 비용이 들고, 종류도 많다
  - 종류에 따라 적절한 방법론도 전부 다르다
  - 최종 산출물이 개발 과정에서 확인되지 않음
    - 오류를 발견해야 할 시기를 놓치거나, 오류에 대한 해결책을 못 찾는 경우가 발생
  - 프로젝트의 지연 및 예산 범위 초과로 인한 프로젝트 실패 가능성이 높음
- HW 고장 곡선, SW 실패 곡선, 이상과 현실
SW 비용
- 개발보다 유지보수에 더 많은 비용
- SW 공학은 SW를 비용-효과적으로 (가성비가 좋도록) 개발
SW 장애의 원인
- 시스템 복잡도 증가
- SW 공학 방법론 미사용, 실패

전문적 소프트웨어 개발

많은 사람들이 SW를 만든다.
- ㄱ. 업무 단순화, 실험 데이터 처리, 흥미와 즐거움
- ㄴ. 사업적 목적을 위해 다른 장치들에 포함, 정보 시스템, CAD Computer-Aided Design 시스템
대부분 ㄴ 같이, ‘다른 사용자’ 들을 위해 만든다.
그 SW는 수명이 다할 때까지 유지보수되고 변경된다.
SW 공학은,
- 개별적 프로그래밍보다는, 전문적 SW 개발 지원을 고려한 것
- 프로그램 명세, 설계, 지원을 지원하는 기법을 포함 (개인 SW 개발과 관련 없음)
SW = 컴퓨터 프로그램과 관련된 문서들 (프로그램/코드 뿐만아니라, 라이브러리, 시스템/사용자 문서, 지원 웹 사이트, 환경 설정 데이터 등)
컴퓨터 과학 VS SW 공학 = 이론 VS 응용(사람을 위한?)
시스템 공학 VS SW 공학 = 전체(HW SW 프로세스) VS 일부(프로세스)
전문적 SW VS 아마추어 SW
- @돈을 받느냐 안받느냐
SW 제품
- 일반 Generic 제품
  - 일반 고객, 오픈 마켓
  - 모르는 니즈를 고민
  - 개발자가 제품 명세서 Specification, SW 변경 여부를 관리/결정
- 맞춤식 Customized/Bespoke 제품
  - 특정 고객
  - 주어진 니즈에 맞게
  - 고객이 제품 명세서 Specification, SW 변경 여부를 관리/결정
경계가 희미해지고 있음
- 일반 제품으로 시작해, 특정 고객의 요구사항을 반영하게 되는
전문적 SW에 대하여,
- SW를 개발자와 무관한 사람이 사용하고 변경한다는 점을 염두
- SW 품질 + 비기능적 속성
  - 단순히 무엇을 하는지 뿐만 아니라,
  - 실행 중 동작, SW 구조와 조직 및 관련 문서와도 연관
  - I.E. 사용자 질의에 대한 응답 시간, 코드에 대한 이해도
SW의 응용에 따라, 기대하는 SW의 특성도 다름
I.E. 항공 관제 시스템 = 안전, 게임 = 즉각적
일반화 시키면,
전문적 SW의 필수적 특성
- 수용성 Acceptability
  - 타겟층이 수용할 수 있어야 (설계 목적에 부합하는 사용자 유형)
  - I.E. 사용자가 이해 가능, 쓰기 쉬운, 기타 시스템/도구와 호환
- 확실성 Dependability 과 보안 Security
  - 안전성, 신뢰성, 보안
  - 고장나도 물리적/경제적 피해 야기 X
  - 보안을 통해 악의적 사용자가 시스템에 접근하거나 피해를 주지 않도록
- 효율성 Efficiency
  - 응답성, 처리 시간, 자원 활용, @최적화
  - 메모리, 프로세서 사이클과 같은 시스템 자원 낭비해서 사용 X
- 유지보수성 Maintainability
  - 고객들의 변화하는 요구를 충족시킬 수 있도록 진화하도록
  - 소프트웨어 변경은 필연적 (결함, 환경 변화 적응), 매우 중요
    - I.E. 코로나로 인해, 기존 학교 영상 강의 사이트에 실시간 온라인 강의를 추가
    - I.E. 수강신청이 휴대폰에서도, 그 중에서도 또 여러 기기 기종을 지원하도록
SW 공학
- 시스템 명세화 ~ 요지보수, SW 개발의 모든 관점을 다루는 공학적 학문 분야.
  - 1. SW 모든 측면
      - => 기술 프로세스 뿐만 아니라, 프로젝트 관리, SW 개발 지원 도구, 방법, 이론의 개발 포함
  - 1. 공학적 학문 분야
      - => 유형과 조직적, 재정적 제약에 맞추어 적절한 방법을 적용, 선택적으로, 없어도 해결책을 찾음
SW 공학이 중요한 이유
- 1. 개인/사회가 발전된 SW 시스템에 더욱 의존
    - => 경제적으로 신속하고 안정적이고 신뢰할 수 있는 시스템을 생산할 필요
- 1. 주먹구구식보다 SW 공학 방법과 기술이 비용이 적게 소모 (장기적으로)
    - => 대부분의 시스템에서 발생하는 비용이 유지보수
SW 프로세스 활동 (체계적 접근법)
1. 명세화 Specification
2. 개발 Development
3. 검증 Validation
4. 진화 Evolution
유형에 따라 서로 다른 방시그올 구성하고 상세화 수준도 다르다
- I.E. 비행기 실시간 SW, 개발 시작 전에 요구사항을 완전히 명세
- I.E. 전자 상거래 시스템, 명세화와 개발 동시에 진행하는 것이 일반적
SW에 영향을 미치는 문제 (유형에 따라 다르지만 일반적으로)
- 이질성 Heterogeneity
  - => 서로 다른 컴퓨터, 모바일 기기 호환, 레거시 시스템과 신규 시스템 통합
- 비즈니스와 사회적 변화
  - => 빠르게 바뀌는 비즈니스와 사회적 변화에 맞춰, 빠르게 변경하거나 새로 개발
- 보안과 신뢰
  - => 온 세상이 SW기 때문에, 그만큼 SW를 신뢰할 수 있어야
- 규모
  - => 임베디드, 웨어러블, 인터넷, 클라우드 기반 시스템 등 다양한 규모 SW 개발
SW 공학의 다양성
- 보편적인 SW 공학 기법 없음
- 사용되는 SW 공학 기법, 도구는 개발하는 ‘APP 유형’, 고객의 요구사항, 개발 팀의 배경에 좌우
APP 유형
- 독립형 Stand-Alone App
  - => 업무 App, CAD, 사진 작업, 여행 앱, 생산성 등
- 대화형 Interactive 트랜잭션 Transaction 기반 App
  - => 원격 컴퓨터에서 실행하는, 전자상거래, 웹 브라우저, 전자우편, 클라우드 기반 서비스 등
- 임베디드 제어 시스템
- 오락 시스템
- 모델링 및 시뮬레이션 시스템
- 데이터 수집 및 분석 시스템
- 복합 시스템 Systems of Systems
경계는 모호
각 유형별로 SW가 서로 다른 특성을 가지기 때문에 해상 시스템 별로 특화된 SW 공학 기법을 사용해야 함
그럼에도 불구하고, 모든 유형의 SW 시스템에 적용 가능한 ‘SW 공학의 기본사항’이 있다.
SW 공학의 기본 사항
- 관리되고 이해되는 개발 프로세스를 따라 개발 (뭘 어떻게 언제까지 만드는지 잘 아는 것)
- 모든 유형의 시스템에서 ‘확실성 Dependability과 성능’이 중요
- SW 명세 Specification와 요구사항 (SW가 해야 할 것)을 ‘이해하고 관리’하는 것이 중요
- 적절한 경우에는 새롭게 SW를 만들지 않고 이미 개발되어 있는 SW를 ‘재사용’
Internet SW 공학
- Web은 현재 App을 실행하기 위한 Platform이며 Local System보다는 Web 기반 System을 개발하는 조직이 증가
- Web Service는 Web을 경유하여 App의 기능에 접근할 수 있음
- SaaS, Cloud Computing은 저멀리 Cloud 위에서 실행되는 App의 Service를 제공하는 방법
  - User는 Sw를 구입하는 것이 아니라 사용에 따라 비용을 지불
Web 기반 SW 공학
- Web 기반 SW에서 변화
  - SW 재사용
  - 점증적 애자인 Incremental and Agile 개발
  - Service 지향 SW 공학
  - 다채로운 (풍부한, Rich) Interface
- Web 기반 System은 복잡한 분산 System으로, 역시 ‘SW 공학의 기본 원리’ 가 적용 가능

SW 공학 윤리

@패스

사례 연구

다루는 시스템 유형 및 사례
- 임베디드 시스템 : 인슐린 펌프 제어 시스템
- 정보 시스템 : 환자 정보 시스템
- 센서 기반 데이터 수집 시스템 : 기상 관측기
- 지원 환경 : iLearn(학교용 디지털 학습 환경)

@ 음 그렇구나 @ UML Unified Modeling Language

Chapter 1 정리

SW 공학은 SW 생산의 모든 측면과 관련한 공학적 학문 분야
SW는 단지 하나 또는 여러 프로그램을 뜻하는 것이 아니라, 시스템 사용자, 품질 보증 담당자와 개발자가 필요로 하는 모든 전자 문서를 포함한다. 필수적인 SW 특성으로는 유지보수성, 확실성과 보안성, 효율성 및 수용성이 있다.
SW 프로세스는 SW 개발에 관련한 모든 활동을 포함한다. 명세화, 개발, 검증 및 진화와 같은 고수준의 활동들은 모두 SW 프로세스의 일부에 해당한다
다양한 종류의 시스템이 존재하며, 각각의 시스템은 개발을 위해 적절한 SW 공학 도구와 기법을 필요로 한다. 있다고 하더라도 극소수의 설계와 구현 기법들만 모든 종류의 시스템에 적용이 가능하다.
SW 공학의 기본적 개념은 모든 종류의 SW 시스템에 적용할 수 있다. 이러한 기본 개념에는 체계적인 SW 프로세스, SW 확실성과 보안성, 요구 공학 및 SW 재사용 같은 것들이 있다.
고객을 위해 개발하는 전문적 SW가 단순히 개발하고 인도하는 프로그램이 아닌지 설명하라
일반적 SW 제품 개발과 고객 맞춤식 SW 개발의 가장 중요한 차이점은 무엇인가? 그리고 이러한 차이점이 일반적 SW 제품 사용자에게 실무적으로 의미하는 바는 무엇인가?
SW 시스템을 개발하기 위해 SW 공학 기법과 방법을 사용하는 것이 왜 장기적으로보면 대부분 더 저렴한지 간략히 논의하라
1.1.2 절에서 논의했던 App 유형 중 일부에 대한 지식에 기초하여, 왜 다른 App 유형은 설계와 개발을 위해 특별한 SW 공학 기법이 필요로 하는지 예를 들어 설명하라
프로세스 확실성, 요구 관리 및 재사용에 대한 기본적인 SW 공학 원칙이 왜 모든 종류의 SW 시스템과 관련이 되는지 설명하라

Chapter 2 : 소프트웨어 프로세스

많은 종류의 SW 프로세스
하지만 어떤 형태로든 SW 프로세스 활동을 포함 (명세화, 개발, 검증, 진화)
SW 프로세스의 표현
- 데이터 모델의 정의, 사용자 인터페이스의 설계 등의 활동들과 이러한 활동들의 순서 등에 관한 기술
  - 다음을 포함
    - 프로세스 활동의 산출물인 제품
    - 프로세스에 참여한 사람들의 책임을 나타내는 역할
    - 프로세스 활동을 시작하게 하거나 제품을 생산하는 프로세스 활동 전과 후에 만족되어야 하는 문장인 사전 조건과 사후 조건
개발 주도(기반) 프로세스와 애자일 프로세스
- 계획 주도 프로세스는 모든 프로세스 활동이 사전에 계획되고 이 계획에 따라 프로세스 진행이 측정되는 프로세스
- 애자일 프로세스에서 계획은 점증적이며 변화하는 고객 요구 사항을 반영하도록 프로세스를 변경하는 것이 더 용이
- 실무에서 대부분의 실제 프로세스에는 계획 주도(기반) 접근 방식과 애자일 접근 방식이 모두 포함
- 바른 SW 프로세스와 바르지 않은 SW 프로세스가 존재하는 것은 아님

소프트웨어 개발 모델

SW 프로세스 모델
- SW 프로세스를 단순하게 나타낸 것
- 개별 프로세스 모델은 특정한 관점으로 프로세스를 나타낸 것, 해당 프로세스에 대한 부분적 정보만 다룰 수 있다
- I.E. 프로세스 액티비티 모델, 프로세스의 활동과 순서를 보여주지만, 활동에 관여하는 사람들의 역할은 보여주지 못함
일반적 모델
- SW 개발에 대한 다양한 접근법을 설명할 수 있을 정도의 고수준에서 추상적으로 SW 프로세스를 설명
- Like 일종의 프로세스 프레임워크
- 폭포수 모델 Waterfall model
  - => 계획 주도 프로세스 모델. 각 개발 단계가 뚜렷하게 구분됨.
- 점증적 개발 Incremental Development
  - => 명세화, 설계, 구현, 검증 단계가 중첩됨. 계획 주도 방식이나 애자일 방식이 될 수 있음
- 통합 및 환경설정 Integration And Configuration
  - => 시스템은 기존의 컴포넌트를 통합하여 구성됨. 계획 주도 방식이나 애자일 방식이 될 수 있음.
- 실제로 대부분의 대형 시스템은 이러한 모든 모델의 요소가 통합된 프로세스를 사용하여 개발됨.

폭포수 모델 Waterfall Model (SW 생명 주기 Life Cycle)

요구사항이 처음부터 완벽하고 고정된다는 것이 전제, 한 단계 한 단계 진행
폭포수 모델의 개별적인 활동
- 요구사항 분석 및 정의
  - => 시스템 사용자와의 면담을 통해 시스템의 서비스, 제약 조건과 목표를 설정한다. 설정한 내용은 더 구체화시킨 후 시스템 명세서로 사용한다.
- 시스템/SW 설계
  - => 시스템 설계 프로세스를 통해 요구사항을 HW와 SW 시스템으로 나누어 할당하고, 전체 시스템 아키텍처를 작성한다. SW 설계는 가본적인 SW 시스템 추상화와 이들간의 관계를 파악하고 기술하는 활동을 포함
- 구현 및 단위 테스팅
  - => 이 단계에서 SW 설계는 여러 개의 프로그램이나 프로그램 단위로 실체화된다. 단위 테스팅은 각각의 단위가 주어진 명세를 만족하는지를 검증하는 활동이다.
- 통합과 시스템 테스팅
  - => 개별 프로그램 단위나 프로그램을 통합하고 SW 요구 사항을 만족하는지를 보증하기 위해 전체 시스템을 검사한다. 테스트 후에는 SW 시스템을 고객에게 전달한다.
- 운영과 유지보수 (진화)
  - => 정상적인 경우, 이 활동이 가장 긴 생명 주기 단계이다. 시스템이 설치되고 실제로 사용된다. 유지보수는 생명 주기의 이전 단계에서 발견하지 못했던 오류를 수정하고, 시스템 단위의 구현을 개선하고 새로운 요구사항을 발견함으로써 시스템 서비스를 향상시키는 것을 포함한다.
폭포수 모델의 주요 단점은 프로세스가 진행된 후 변경사항을 수용하기 어려움. 원칙적으로 다음 단계로 이동하기 전에 이전 단계가 완료되어야 함.
원칙적으로는 폭포수 모델에서 각 단계의 결과로 승인된 하나 또는 그 이상의 문서들이 나와야한다. 그리고 이전 단계가 끝나기 전까지는 다음 단계를 시작하지 않는다. (실제로는 중첩되는 경우가 많다)
실제로, SW 프로세스는 단순한 선형 모델일 수가 없고, 한 단계에서 다른 단계로의 피드백을 통해 이루어진다
한 프로세스 단계에서 새로운 정보를 발견하게 되면 필요한 시스템 변경을 반영하기 위해 이전 단계에서 작성한 문서를 수정해야 한다.
- I.E. 너무 많은 비용이 발생하면 삭제시켜야
결과적으로, 더 이상의 변경 사항을 반영하지 않도록 고객과 개발자 모두 너무 일찍 SW 명세서를 확정하는 경우가 발생
- => 원하는 것을 제대로 제공 못하거나, 구현 꼼수로 설계 문제를 덮어, 나쁜 구조의 시스템
실제로, SW는 개발 과정에서 유연하고 변경이 빠르게 가능해야 한다
- => 폭포수 모델은 이런게 어렵다 (일부 시스템 유형에 대해서만 적합)
  - 1. SW와 HW가 연동해야 하는 임베디드 시스템 HW는 유연하지 못하기 때문에, 구현까지 SW 기능에 대한 결정을 미룰 수 없다 = 폭포수가 적합
  - 1. SW 명세와 설계에 대한 광범위한 안전성과 보안 분석이 필요한 중대한 시스템이 필요한 분석을 수행할 수 있도록 명세서와 설계 문서를 완료해야 한다.명세와 설계에서의 안전성 관련 문제는 대부분의 경우 구현 단계에서 수정하느 ㄴ경우 매우 높은 비용이 발생한다.
  - 1. 수많은 파트너사가 새발한 더 큰 공학적 시스템의 일부에 속하는 대규모 SW 시스템 시스템의 HW를 비슷한 모델을 적용하여 개발할 수 있기 때문에, 참여 회사들은 HW와 sW에 대해 공통 모델을 사용하는 것이 수월하다고 생각한다. 또한 많은 회사가 참여하기 때문에 서로 다른 서브 시스템을 독립저긍로 개발하기 위해 완성된 명세서가 필요할 수 있다.
폭포수 모델의 문제점
- 프로젝트를 상이한 단계로 유연성 없이 분할해버리면 고객의 요구사항이 변경되는 경우 대응하기 어려움.
  - 따라서 이 모델은 요구 사항을 잘 이해하고 설계 프로세스 중에 변경이 상당히 제한되는 경우에만 적합
  - 안정적인 요구사항을 가진 비즈니스 시스템은 거의 존재하지 않음
- 폭포수 모델은 시스템이 여러 사이트에서 개발되는 대규모 시스템 엔지니어링 프로젝트에 주로 사용
  - 이러한 상황에서 폭포수 모델의 계획 중심 특성은 작업을 조정하는 데 도움이 됨.
“대부분의 경우 사람은 직접 보여주기 전까지 자신이 무엇을 원하느지 모른다.. 그렇다고 해서 우리가 고객의 의견을 듣지 않는 것은 아니지만 사람들이 비슷한 것조차도 보지 못하느 상황에서 어떤 것을 원하는지를 설명하기란 정말 어렵다”
폭포수 모델의 장단점
- 장점
  - 가장 오래되고 폭넓게 사용되어 사례가 풍부함
  - 순차적인 프로세스이므로 전체 개발 과정이 이해하기 용이함
  - 진행 과정이 개별적으로 세분화되고, 순차적이므로 관리하기 용이함
  - 기술적 위험이 적고 적용 사례에 따른 경험이 많아, 일정 예측이 용이함
  - 산출물에 대한 관리와 적용이 용이함
- 단점
  - 초기에 정확한 요구사항을 유도하고 확정짓기가 어려움
  - 후반부에 개발이 구체화되기 때문에 초기에 중요한 문제점을 발견하기 어려움
  - 사용자 피드백에 의한 반복 단계가 불가능
  - 초기에 사용자의 의견을 반영하기 어려움
  - 초기 단계 강조 시에 구현과 테스트가 지연될 수 있음

점증적 개발 Incremental Development

초기 구현을 개발하고, 사용자와 다른 사람들로부터 피드백을 받아서, 여러 버전(증분)을 거쳐 SW를 진화시킴으로써 요구한 최종 시스템을 개발하는 것. 명세화, 개발과 검증 활동은 분리되었다기보다는 활동 간 빠른 피드백을 가지고 중첩되어 있다.
점증적 접근법은 계획 주도 프로세스나 애자일 방식에서도 쓸 수 있고, 더 일반적으로는 이러한 접근법들을 섞어 쓸 수도 있다.
계획 주도 접근법에서는 시스템의 증가분 Increments 을 사용자의 우선순위별로 미리 찾아서 정리한다, 가장 우선순위가 높은 증분부터 개발
요구사항이 개발 프로세스 과정 동안에 쉽게 바뀌는 시스템 (대부분의 비즈니스 시스템과 SW 제품들)에 대해서는 애자일 개발 방법의 기본적인 사항에 해당하는 점증적 SW 개발이 폭포수 접근법보다 적합
SW 개발이 점증적으로 이루어진다. Like 엔지니어가 문제를 해결하는 방식
- 엔지니어가 처음부터 완벽한 문제 해결을 내놓는 경우는 드물며, 여러 단계를 거쳐서 해결법에 근접하고, 실수를 했다고 판단했을 때에는 다시 돌아가기도 한다
이를 통해(점증적으로) SW 개발하면서 발생하는 변경 사항에 대해 적은 비용으로 쉽게 대처 가능
시스템에 대한 각각의 증가분이나 버전은 고객이 필요로 하는 기능의 일부를 담고 있다.
- 일반적으로 시스템 초기 증가분은 가장 중요하거나 가장 긴급하게 요구되는 기능들을 포함
점증적 개발의 장단점
- 장점
  - 요구사항 변경을 구현하는 비용이 줄어든다
    - 다시 분석하고 작성해야 하는 문서의 양이 폭포수 모델의 경우보다 훨씬 적다
  - 이미 진행된 개발 작업에 대해서는 고객의 피드백을 받기가 더 쉽다
    - 고객은 SW 시연에 대해 의견을 줄 수 있고, 얼마나 많이 구현되었는지 확인할 수 있다.
  - 고객에게 유용한 SW를 빠르게 전달하고 배포하는 것이 가능하다
    - 고객은 폭포수 모델을 사용하는 경우보다 더 일찍 SW가 제공하는 기능을 경험하고 실제 사용할 수 있따
- 단점
  - 프로세스가 보이지 않는다 (가시적이지 못하다)
    - 관리자는 진척도를 확인하기 위해 정기적으로 산출물이 필요하다. 만일 시스템이 빨리 개발되어야 한다면, 시스템의 모든 버전을 반영하는 문서를 작성하는 것은 비용 측면에서 비효율적이다
  - 새로운 증분이 추가되면서 시스템 구조가 훼손되는 경향이 있다.
    - SW를 개선하기 위한 리팩토링에 시간과 비용을 투자ㅎ지 않으면 구조가 망가진다. 새로운 기능을 추가하는 작업은 어렵고 비용이 많이 든다.
  - @서로 다른 팀들이 시스템의 다른 부분을 개발하는 복잡하고 긴 생명주기를 가진 대규모 시스템에서 문제점이 적나라하게 드러난다.
    - 미리 틀(안정적인 프레임워크나 아키텍처, 각 팀의 책임이 명확하게 정의)이 잡혀 있어야 한다.
점증적 개발에서 매번 이루어지는 증가분을 시스템 고객에게 전달할 필요는 없다.

통합과 환경 설정

시스템이 기존의 컴포넌트 혹은 App 시스템 COTS Commercial-Off-The-Shelf 을 통합하여 시스템을 개발하는 SW 재사용에 기반을 둠
재사용되는 요소는 동작과 기능이 사용자의 요구사항에 맞추어 조정됨
현재 재사용은 비즈니스 유형의 시스템을 구축하는데 표준적인 방법
재사용 가능한 SW 유형
- 특정 환경에서 사용할 수 있도록 독립형 Stand-Alone App 시스템 COTS
- .NET 혹은 J2EE, Java Spring Framework와 같이 컴포넌트 프레임워크에 통합할 수 있도록 개발한 컴포넌트나 패키지 객체들의 모임
- 서비스 표준에 따라 개발되고, 인터넷을 통해 원격 실행이 가능한 웹 서비스
재사용 지향 SW 공학
주요 프로세스 단계
- 요구사항 명세화
  - 시스테템에 대한 초기 요구사항을 제안. 이 초기 요구사항은 상세히 작성할 필요는 없지만 필수 요구사항이나 필요한 시스템 기느에 대한 간략한 설명을 담고 있어야 한다.
- SW 발견 및 평가
  - SW 요구사항의 개요가 주어지면, 필요한 기능을 제공하는 컴포넌트 및 시스템을 찾게 된다. 컴포넌트와 시스템 후보를 대상으로 필수 요구사항을 만족하는지, 시스템에 일반적으로 사용하기 적당한지를 평가한다
- 요구사항 정제
  - 이 단계에서는 이미 찾아놓은 재사용 가능한 컴포넌트와 App에 대한 정보를 활용하여 요구사항을 다듬는 작업을 진행한다. 사용할 수 있는 컴포넌트를 반영하여 요구사항을 수정하고, 시스템 명세도 다시 정의한다. 수정을 불가능하다면, 대안을 찾기 위해 컴포넌트 분석 활동을 재개하는 경우도 있다.
- App 시스템 설정
  - 만약 요구사항을 만족하는 COTS App 시스템을 확보할 수 있다면, 이 시스템을 설정하여 새로운 시스템을 만드는 데 사용할 수 있다
- 컴포넌트 수정과 통합
  - 만약 적합한 COTS 시스템이 없다면, 개별적으로 재사용 가능한 컴포넌트를 수정하여 새로운 컴포넌트를 개발하여 시스템 개발에 통합시킬 수 있다.
통합과 환경 설정의 장단점
- 장점
  - 원점에서 개발되는 SW가 줄어들수록 비용과 리스크가 감소
  - 시스템을 빠르게 인도하고 배치할 수 있음
- 단점
  - 요구사항 조정이 필연적이므로 시스템이 사용자의 진정한 요구를 만족하지 못할 수 있음
  - 재사용된 시스템 요소의 진화에 대한 주도권 상실

프로세스 활동

실제 SW 프로세스는 SW 시스템을 명세, 설계, 구현, 테스팅하기 위한 전반적 목표를 가지고 기술적이고 관리적 측면을 가진 공동의 활동들이 서로 중첩되어 진행된다.
명세화, 개발, 검증과 진화라는 네 가지 기본 프로세스 활동은 다른 개발 프로세스 상에서 서로 다른 방식으로 구성된다.
예를 들어, 폭포수 모델에서는 순차적으로 구성하고, 점증적 개발에서는 서로 중첩시킨다.
요구공학 프로세스 (SW 명세화) Requirements Eng
- 시스템을 개발하기 위해 어떤 서비스가 필요한지를 이해하고 정의하며, 시스템의 운영과 개발에 대한 제약사항을 찾아내는 프로세스
- @SW 명세화 또는 요구공학은 시스템을 개발하기 위해 어떤 서비스가 필요한지를 이해하고 정의하며, 시스템의 운영과 개발에 대한 제약사항을 찾아내는 프로세스에 해당한다. 요구공학은 SW 프로세스에서 특히 중요한 단계인데, 이 단계에서의 실수는 시스템 설계와 구현에서의 향후 문제로 이어질 수밖에 없기 때문이다
- @요구공학 프로세스는 이해당사자들의 요구사항을 만족시키는 시스템을 명세하기 위한 요구사항 문서를 통해 합의점을 도출하는 것이 목적이다.
요구공학 프로세스의 주요 활동
1. 요구사항 도출과 분석 : 시스템 이해당사자(Stakeholders)가 시스템에 요구하는 것과 기대하는 것이 무엇인가?
2. 요구사항 명세화 : 요고사항을 상세하게 정의
3. 요구사항 검증 : 요구사항의 타당성을 체크

@타원형 : 액티비티
@사각형 : 산출물

SW 설계 및 구현
- 고객에게 전달하기 위한 실행 가능한 시스템을 개발하는 프로세스
- SW 설계
  - 명세서를 실현하기 위한 SW 구조의 설계
- 구현
  - 이러한 구조를 실행 가능한 프로그램으로 변환
- 설계와 구현 활동들은 밀접하게 관련되어 있고 서로 중첩되기도 함
설계 프로세스의 일반적 모델
- 설계 프로세스 활동은 서로 중첩되면서 상호의존적
- 계속해서 만들어지는 설계에 대한 새로운 정보는 이전 설계에 대한 의사결정에 영향을 주기 때문에 어쩔 수 없이 재설계 작업을 할 수밖에 없다
설계 활동
- 아키텍쳐 설계
  - 시스템의 전체 구조, 주요 컴포넌트 (서브시스템 또는 모듈)들의 관계 및 분산 방식을 식별
- DB 설계
  - 시스템 데이터 구조를 설계하고 이것이 DB에서 어떻게 표현되는지를 설계
- 인터페이스 설계
  - 시스템 컴포넌트 간의 인터페이스를 정의
- 컴포넌트 선택 및 설계
  - 재사용 가능한 컴포넌트를 검색. 적합한 컴포넌트가 없는 경우 새로운 컴포넌트를 설계
시스템 구현
- SW는 프로그램을 개발하거나 App 시스템을 설정하여 구현됨
- 설계와 구현은 대부분의 SW 시스템에서 중첩되는 활동
- 플밍은 표준적인 프로세스가 존재하지 않는 개별적인 활동
- 디버깅은 프로그램 결함을 찾아 이러한 결함을 수정하는 활동
SW 검증 @47p
- 검증(및 확인) V&V Verification And Validation 은 시스템이 주어진 명세를 잘 따르고 있는 것과 고객이 원하는 것을 그대로 반영하고 있다는 것을 보이기 위함
- 체킹 및 리뷰 프로세스 그리고 시스템 테스팅을 포함
- 시스템 테스팅은 시스템이 처리하는 실제 데이터 명세서로부터 유도된 테스트 케이스로 시스템을 실행
- 테스팅은 가장 일반적인 V&V 활동
테스팅 단계
- 컴포넌트 테스팅
  - 개개의 컴포넌트를 독립적으로 테스트
  - 컴포넌트를 함수 혹은 이러한 개체들이 모인 그룹
- 시스템 테스팅
  - 시스템을 전체적으로 테스팅
  - 창발적 속성의 테스팅이 특히 중요
- 고객 테스팅
  - 고객 데이터를 가지고 시스템이 고객의 요구를 만족하는가 체크하는 테스팅
V Model, 계획 주도 SW 프로세스에서의 테스팅 단계
- @ 저번 시험에 다이어그램에 들어갈 것을 물어본 적이 있다
SW 진화
- SW는 본질적으로 유연성이 있어서 변경 가능
- 비즈니스 환경이 변화함에 따라 요구사항이 변경되어, SW가 비즈니스의 진화와 변경을 지원해야 함
- 완전히 새로 만든 SW 시스템은 거의 없기 때문에 개발과 유지보수는 구별되는 것이 아니라 중첩되거나 연속적인 활동
시스템 진화

변경 처리

모든 대규모 SW 프로젝트에서 변경은 피할 수 없음
- 비즈니스 변화는 새롭게 변경된 시스템 요구사항을 귀결됨
- 새로운 기술이 도입되면서 설계나 구현에 대한 새로운 접근이 가능
- 플랫폼이 변경되면 App 변경이 요구됨
변경은 새로운 작업이 필요하므로 변경 비용은 재작업 (요구사항 재분석) 뿐만 아니라 새로운 기능을 구현하는 비용을 포함
재작업 비용을 줄이기 위한 방법
- 변경 예측 Change Anticipation
  - 상당한 재작업이 요구되기 전에 가능한 변경을 예상할 수 있는 활동이 SW 프로세스에 포함
    - 예를 들어 고객에게 시스템의 일부 주요 기능을 보여주기 위해 프로토타입 시스템을 개발
- 변경 허용 Change Tolerance
  - 상대적으로 낮은 비용으로 변경사항을 수용할 수 있도록 프로세스가 설계
    - 이것은 일반적으로 어떤 형태의 점증적 개발을 포함. 제안된 변경사항은 아직 개발되지 앟은 증분 단위로 구현될 수 있음. 이것이 불가능하다면 변경사항을 통합하기 위해 단일 증분 (시스템의 작은 부분)만 변경될 수 있음
요구사항 변경에 대응 @나중에 자세히 더 배움
- 시스템 프로토타이핑
  - 고객의 요구사항과 설계 결정의 타당성을 확인하기 위해 시스템 버전 또는 시스템의 일부를 신속하게 개발. 이 접근 방식은 변경을 예상할 수 있음
- 점증적 인도
  - 고객의 의견 수혐 및 실험을 위해 시스템 증분이 고객에게 전달. 이는 변경 방지와 변경 허용을 모두 지원
SW 프로토타이핑 @나중에 자세히 더 배움
- 프로토타입은 제품의 아이디어를 시연하고, 디자인 선택 사항들을 시도해보고, 문제점과 가능한 해결책을 찾아내기 위해 사용하는 SW 시스템의 초기 버전
- 프로토타입이 사용되는 경우
  - 요구사항 프로세스에서, 프로토타입은 시스템 요구사항 도출과 검증에 ㅅ용
  - 설계 프로세스에서, SW 해결 방안을 탐색하거나 시스템을 위한 UI 개발을 위해 프로토타입을 사용
  - 테스팅 프로세스에서 Back-To-Back 테스트를 실행
프로토타이핑의 장점
- 시스템 유용성 개선
- 사용자의 실제 요구에 부합
- 설계 품질이 개선
- 유지보수성이 개선
- 개발 노력이 감소
프로토타입 개발 프로세스 @52p
프로토타입 개발
- 신속한 프로토타이핑 언어 또는 도구를 기반으로 할 수 있음
- 기능을 생략할 수 있음
  - 프로토타입은 잘 이해되지 않는 제품 영역에 초점을 맞춰야 함
  - 오류 검사 및 복구는 프로토타입에 포함되지 않을 수 있음
  - 안정성 및 보안과 같은 비기능적 요구 사항보다 기능적 요구 사항에 중점을 둠
쓰고 버리는 Throw-Away 프로토타입
- 프로토타입은 생산된 제품의 신뢰할 만한 기초가 아닐 수 있으므로 개발 후 폐기
  - 비기능적 요구 사항을 충족하도록 시스템을 조정하는 것이 불가능할 수 있음
  - 프로토타입은 일반적으로 문서화되지 않음
  - 프로토타입 구조는 일반적으로 급격한 변경 때문에 성능이 저하
  - 프로토타입은 아마도 정상적인 ㅈ직의 품질 표준을 충족하지 못한 가능성이 높음
점증적 인도 @53p
- 시스템을 하나로 인도하는 것이 아니라 개발과 인도를 증분으로 나누어 각 증분이 요구되는 기능의 일부를 담당하도록 함.
- 사용자 요구사항은 우선순위를 정하고 가장 우선순위가 높은 요구사항을 초기의 증분에 포함
- 일단 증분의 개발이 시작되면, 이후 증분에 대해 추가적으로 요구사항을 분석할 수 있지만 현재 증분에 대해서는 요구사항을 변경하지 못함
점증적 개발과 인도
- 점증적 개발
  - 증분으로 시스템을 개발하고 다음 증분의 개발을 진행하기 전에 각 증분을 평가
  - 애자일 방법에 사용되는 일반적인 접근 방식
  - 사용자/고객에 의해 수행되는 평가
- 점증적 인도
  - 최종 사용자가 사용할 증분을 배포
  - SW의 실제적 사용에 대한 보다 현실적인 평가
  - 증분은 대치되는 시스템보다 기능이 적기 때문에 대치되는 시스템을 구현하기 어려움
점증적 인도의 장단점
- 장점
  - 초기의 증분이 이후의 증분에 대한 요구사항을 찾는데 도움이 된다
  - 첫 증분은 고객의 가장 중요한 요구를 충족시키고 즉각 SW를 이용할 수 있다
  - 프로젝트 실패 가능성이 낮아진다
  - 시스템에 반영할 변경 사항을 비교적 쉽게 통합할 수 있다
  - 가장 중요하여 우선 순위가 높은 시스템 서비스를 가장 많이 테스트한다
- 단점
  - 기존 시스템을 신규 시스템으로 대체하려고 할 때 문제가 될 수 있다
  - 모든 증분이 필요로 하는 공통 기능을 찾기 어려울 있다
  - 정부 기관과 같은 대형 조직의 조달방식에서 문제가 될 수 있다

프로세스 개선

많은 SW 기업은 SW 품질 향상, 비용 절감 또는 프로세스를 빠르게 하는 방법으로 SW 프로세스 개선으로 눈을 돌림
프로세스 개선이란 기존 프로세스를 이해하고 이러한 프로세스를 변경하여 제품 품질을 높이거나 비용과 개발 시간을 줄이는 것을 의미
프로세스 개선 방법
- 프로세스 및 프로젝트 관리를 개선하고 우수한 SW 공학 실무 관행을 도입하는 데 중점을 둔 프로세스 성숙도 접근 방식
  - 프로세스 성숙도 수준은 조직의 SW 개발 프로세스에 채택된 우수한 기술 및 관리에 관한 실무 관행의 수준을 반영
- 애자일 기법은 SW 프로세스의 반복 개발 및 오버헤드 감소에 중점을 둠
  - 애자일 기법의 주요 특징은 변화하는 고객의 요구사항에 신속하게 대응
프로세스 개선 사이클
- 변경 → 측정 → 분석 →
프로세스 개선 활동
- 프로세스 측정
  - SW 프로세스 또는 제품의 하나 이상의 속성을 측정. 이러한 측정은 프로세스 개선이 효과적인지 판단하는 데 도움이 되는 기준선을 형성
- 프로세스 분석
  - 현재 프로세스를 평가하고 프로세스의 약점과 병목 현상을 식별. 프로세스를 설명하는 프로세스 모델을 개발할 수 있음
- 프로세스 변경
  - 확인된 일부 프로세스 약점을 해결하기 위해 프로세스 변경이 제안됨. 이러한 변경의 효과에 대한 데이터를 수집하여 사이클이 반복됨
프로세스 측정
- 가능하면 정량적 프로세스 데이터를 수집해야함
  - 그러나 조직에 명확하게 정의된 프로세스 표준이 없는 경우 무엇을 측정해야 할지 모르기 때문에 이는 매우 어려움. 측정이 가능하기 전에 프로세스를 정의해야 할 수도 있음
- 프로세스 개선을 평가하기 위해 프로세스 측정이 필요함
  - 그러나 이것은 측정이 목표라는 것을 의미하지는 않음. 프러세스 개선이 조직의 목표
프로세스 척도
- 프로세스 활동을 완료하는 데 소요된 시간
  - I.E. 작업이나 프로세스를 완료하느데 든 시간이나 노력
- 프로세스나 활동에 필요한 자원
  - I.E. Person-Days 로 측정하는 전체 노력(공수)
- 특정 사건의 발생 횟수
  - I.E. 발견된 결함의 수
역량 성숙도 수준
SEI 역량 성숙도 모델
1. 초기 Initial : 아무 관리가 없음
2. 관리 Repeatable : 제품 관리 절차가 정의되고 사용됨
3. 정의 Defined : 프로세스 관리 절차와 전략이 정의되고 사용됨
4. 관리 Managed : 품질 관리 전략이 정의되고 사용됨
5. 최적화 Optimizing : 프로세스 개선 전략이 정의되고 사용됨
나선형 모델 Spiral Model @36p
- 폭포수 모델과 프로토타이핑 모델의 장점을 수용하고, 위험 분석 Risk Analysis을 추가한 점증적 개발 모델
UP Unified Process @34p
- 도입, 정련, 구축, 전이 4단계
- RUP는 세 가지 관점으로 표현
  - 동적인 관점, 정적인 관점, 실무 관점

Chapter 2 정리

SW 프로세스는 SW 시스템을 제품화하는 것과 관련된 활동들이다. SW 프로세슷 모델은 이러한 프로세스들을 추상적으로 표현한 것이다
일반적인 프로세슷 모델은 SW 프로세스의 구조를 설명한다. 폭포수 모델, 점증적 개발과 재사용 가능한 컴포넌트 환경설정 및 통합이 이러한 일반적 모델에 해당한다
요구공학은 SW 명세를 개발하는 프로세스이다. 명세서는 고객의 시스템 요구를 시스템 개발자들에게 잘 전달하기 위한 용도로 쓰인다
설계 및 구현 프로세스는 요구 명세서를 실행 가능한 SW 시스템으로 바꾸는 것과 관련이 있다
SW검증은 시스템이 주어진 명세를 잘 따르는지와 시스템 사용자의 정확한 요구를 충족하는지를 확인하는 프로세스이다
SW 진화는 새로운 요구를 충족시키기 위해 기존 SW 시스템을 변경할 때 이루어진다. 변경은 지속적으로 이루어지기 때문에, SW가 유용하기 위해서는 진화를 해야만 한다
프로세스는 변경에 대응하는 활동을 포함해야 한다. 이것을 요구 및 설계에 대한 어설픈 의사결정을 피하는 데 도움을 주는 프로토파이핑 단계와도 관련된다. 시스템 전체에 형향을 주기 않은 채 변경 작업을 수해앟 ㄹ수 있도로 반복적인 개발과 인도를 고려해서 프로세스를 구축할 수 있다
프로세스 개선은 SW 품질을 높이고, 개발 비용을 줄이거나 개발 소요 시간을 감소시키기 위해 기존 SW 프로세스를 향상시키는 과정이다. 프로세스 개선은 프로세스 측정, 분석과 관련한 사이클 프로세스이다

Chapter 3 : 소프트웨어 프로세스

신속한(빠른) SW 개발
- 신속한 개발과 Deliver는 현재 소프트웨어 시스템의 가장 중요한 요구사항 중 하나
  - 비즈니스의 요구사항은 빠르게 변화하고 있으므로 고정된 소프트웨어 요구사항을 생성하는 것은 불가능
  - 소프트웨어는 변화하는 비즈니스 요구를 반영하기 위해 신속하게 변경(진화)되어야 함
- 계획 주도 개발 (폭포수 모델)은 안정성 중심 시스템과 같은 유형의 시스템에는 필수적이지만 이러한 비즈니스 요구를 만족할 수 없음
- 1990년대 후반에 등장한 애자일 개발의 목표는 소프트웨어 시스템의 인도 시간을 회기적으로 감소시키는 것
애자일 Agile 개발
- 명세화, 설계, 구현 프로세스가 서로 *중첩
- *코드 작성에 초점을 맞추고 문서 작업은 최소화
- 시스템을 버전이나 증분의 연속으로 구현하고, 이 때 버전의 명세화와 평가에 이해당사자 Stakeholders 가 참여
- 새로운 버전의 평가를 위한 인도는 *자주 이루어짐
- 개발을 지원하기 위한 다양한 도구 (예, 자동화된 테스팅 도구)

@65p P3-1

계획 주도 개발과 애자일 개발
- 계획 주도 개발 (계획 중심 개발)
  - 소프트웨어 공학에 대한 계획 중심 접근 방식은 각 단계에서 미리 계획한 산출물과 함께 별도의 개발 단계에 기초함
  - 반드시 폭포수 모델일 필요는 없는 점증적 개발이 가능
  - 반복은 각 활동 내에서 이루어짐
- 애자일 개발
  - 명세화, 설계, 구현 및 테스팅은 서로 중첩되며, SW 개발 프로세스 중 협상 Negotiation 과정을 통해 개발 프로세스의 산출물을 결정

애자일 기법

애자일 기법
- 1980년대와 1990년대의 소프트웨어 설계 방법에서 설계 및 문서화에 수반되는 오버해드에 대한 불만으로 애자일 기법이 탄생
  - 설계보다는 코드에 집중
  - 소프트웨어 개발에 대한 반복적 접근 방식에 기반
  - 동작하는 소프트웨어를 신속하게 인도하고 빠르게 개선하여 변화하는 요구사항을 충족하도록 의도됨
- 애자일 기법의 목적은 소프트웨어 프로세스의 오버해드를 줄이고(예를 들어 문서화를 제한함으로써) 과도학 재작업 없이 변화하는 요구사항에 신속하게 대응할 수 있음
애자일 선언 @67p
- 프로세스와 도구 < 개인과 상호작용
- 이해하기 좋은 문서 < 작동하는 SW
- 계약 협상 < 고객과의 협업
- 계획을 따르기 < 변화에 대응하기
- 왼쪽도 가치있지만, 오른쪽에 더 많은 가치를
애자일 기법의 원칙 @
- 고객 참여
  - 고객이 개발 프로세스 전반에 밀접하게 관여, 고객의 역할은 새로운 시스템 요구사항을 제공하고 우선순위를 정하며, 반복적으로 개발하는 시스템을 평가
- 변화 수용
  - 변화할 시스템 요구사항을 예측하고, 이러한 변화를 수용할 수 있도록 해당 시스템을 설계
- 점증적 인도
  - 고객이 다음 증가분에 포함해야 할 요구사항을 명세하면서, SW를 점증적으로 개발한다
- 단순성 유지
  - 개발하고 잇는 SW와 개발 프로세스 양쪽에서 단순성에 집중한다. 언제든지, 시스템으로 인한 복잡성을 제거하기 위해 능동적으로 대처한다
- 프로세스가 아닌 사람
  - 개발팀의 기술을 인지하고 잘 활용할 수 잇어야 한다. 팀 구성원이 규정된 프로세스 없이 각자의 업무 방식을 개발할 수 있도록 해야 한다
애자일 기법의 적용
- 소프트웨어 회사가 중소 규모의 제품을 판매할 목적으로 개발하는 경우
  - 현재 사실상 거의 모든 소프트웨어 제품 및 앱이 애자일 기법을 사용하여 개발됨
- 개발 프로세스에 참여하겠다는 고객의 명확한 의사가 있고 소프트웨어에 영향을 미치는 외부당사자나 규제가 거의 없는 조직 내의 맞춤형 시스템 개발

애자일 개발 기법

익스트림 프로그래밍 eXtreme Programming
- 1990년대 후반에 개발된 매우 영향력 있는 애자일 기법으로서, 다양한 애자일 개발 기술이 등장
- 익스트림 프로그래밍 XP은 반복적인 개발에 ‘극단적인’ 접근 방식을 채택
  - 새로운 버전은 하루에 여러 번 제작
  - 증분은 격주마다 고객에게 인도
  - 모든 테스트는 모든 빌드에 대해 실행되어야 하며 빌드는 테스트가 성공적으로 실행되는 경우에만 허용
XP 릴리스 사이클
- 이번 릴리스를 위한 사용자 스토리 선택
- 스토리를 업무로 분해
- 릴리스 계획
- SW 개발/통합/테스트
- SW 릴리스
- 시스템 평가
XP 실무
- 공동 소유권
- 연속적 통합
- 점증적 계획
- 고객의 참여
- 짝 플밍
- 리팩토링
- 단순한 설계
- 소규모 릴리스
XP와 애자일 원칙
- 점증적 개발은 소규모의 빈번한 시스템 릴리스를 통해 지원
- 고객 참여는 고객이 개발팀에 풀타임으로 참여하는 것을 의미
- 짝 플밍, 시스템 코드의 공동 소유, 장기간의 작업을 피하는 프로세스를 통해 프로세스가 아닌 사람을 중시
- 정기적인 시스템 릴리스를 통한 변경 지원
- 상시적인 코드 리팩토링과 간단한 설계를 통해 단순함의 유지
중요한 XP 실무
- XP는 기술적인 측면에 초점을 두고 있어서 대부분의 조직에서 관리 업무와 통합하기가 어려움
- 따라서 애자일 개발은 XP 실무가 사용되지만, 원래 정의한 원칙 모두가 널리 사용되는 것은 아님
- 중요한 실무
  - 명세화를 위한 사용자 스토리
  - 리팩토링
  - 테스트 우선 개발
  - 짝 플밍
사용자 스토리
- XP에서 고객이나 사용자는 XP 팀의 일원으로 요구사항에 대한 의사결정을 담당
- 사용자 요구사항은 사용자 스토리 또는 시나리오로 표현
- 사용자 스토리는 카드에 작성되고 개발팀은 사용자 스토리를 구현 작업으로 세분화하고, 이것이 일정 및 비용 추정의 기초
- 고객은 우선순위 및 일정 추정값에 따라 다음 릴리스에 포함될 스토리를 선택
약 처방 스토리
약 처방에 대한 작업 카드의 예
리팩토링
- SW 공학에서의 기본 지침은 변경은 고려한 설계. 이렇게 하면 생명주기 후반에 비용이 절감되기 대문에 변경을 예측하는 데 시간과 노력을 들일 가치가 있음
- 그러나 XP는 변경을 신뢰성 있게 예측할 수 없기 때문에 변경을 고려한 설계가 가치가 없다고 주장
- 오히려, 변경사항을 구현해야 할 때, 변경을 더 쉽게 하기 위한 지속적인 코드 개선 (리팩토링)을 제안
리팩토링
- 플밍 팀은 가능한 SW 개선을 찾고, 즉각적인 필요가 없는 곳에서도 이러한 개선을 한다
- 이것은 SW의 이해도를 향상시켜 문서화의 필요성을 감소시킨다
- 코드가 잘 짜여 있고 명확하기 대문에 변경하기가 더 쉽다.
- 그러나, 어떤 변경은 아키텍처의 리팩토링을 필요로 하고 이것은 훨씬 더 비용이 많이 소모될 수도 있다.
I.E. 리팩토링의 예
- 중복 코드를 제거하기 위한 클래스 계층 재구성
- 속성과 메서드를 알기 쉽게 정리하고 이름을 변경
- 프로그램 라이브러리에 포함된 메소드에 대한 호출로 인라인 코드 대체
테스트 우선 개발
- 코드를 작성하기 전에 테스트를 먼저 함
- XP 테스팅
  - 테스트 우선 개발
  - 시나리오를 가지고 이루어지는 점증적 테스트 개발
  - 테스트 개발 및 검증에서의 사용자 참여
  - 테스트 자동화 프레임워크 사용
테스트 우선 개발
- 코딩 전에 테스트를 작성하면 구현해야 할 요구사항이 명확해짐
- 테스트는 데이터가 아닌 프로그램으로 작성돼 자동 실행이 가능. 테스트는 프로그램이 정확하게 실행되었는지 확인하는 것을 포함
  - 일반적으로 JUnit과 같은 테스트 프레임워크에 의존
- 새로운 기능이 추가되면 모든 이전 및 새로운 테스트가 자동으로 실행되므로 새로운 기능이 오류를 발생시키지 않았는지 점검
고객의 참여
- 테스트 프로세스에서 고객의 역할은 시스템의 다음 릴리스에서 구현될 스토리에 대한 인수 테스트를 개발하는데 도움을 줌
- 팀의 일원인 고객은 개발이 진행됨에 따라 테스트를 작성. 모든 새로운 코드는 고객이 필요로 하는 것임을 확실히 하기 위한 검증이 실시
- 그러나 고객 역할로 참여하는 사람들은 가용 시간이 제한되어 있기 대문에 개발팀과 함께 풀타임으로 일할 수 없을 수 있고, 요구사항의 제공으로도 충분히 기여했다고 생각할 수 있으므로 테스팅 프로세스에 참여하는 것을 꺼릴 수 있음
복용량 확인을 위한 테스트 케이스
테스트 자동화
- 테스트 자동화랑 작업이 구현되기 전에 테스트가 실행가능한 구성 요소로 기록됨을 의미
  - 테스팅 컴포넌트는 독립적으로 실행되어야 하며, 테스팅할 입력값을 시뮬레이션해야 하며, 결과가 명세서를 만족하였는지 확인. 자동화된 테스트 프레임워크 (I.E. JUnit) 는 실행 가능한 테스트를 쉽게 작성하고 실행을 위한 일련의 테스트를 제출할 수 있도록 하는 시스템
- 테스팅이 자동화됨에 따라 빠르고 쉽게 실행할 수 있는 테스트 세트가 항상 존재
- 시스템에 기능이 추가될 때마다 테스트를 실행할 수 있으며, 새로운 코드가 야기한 문제를 즉시 파악할 수 있음
테스트 우선 개발의 문제점
- 플머들은 테스트보다 플밍을 선호하고 때때로 테스트 작성 시 요령을 부리기도 한다. 예를 들어, 발생할 수 있는 모든 가능한 예외를 확인하지 않는 불완전한 테스트를 작성할 수도 있다.
- 어떤 테스트는 점증적으로 작성하기 매우 어려울 수도 있다. 예를 들어, 복잡한 UI에서는 ‘디스플레이 로직’ 과 화면 간 워크플로우를 구현하는 코드의 단위 테스트를 작성하기가 어려운 경우가 많다.
- 테스트 집합의 완전성을 판단하기 어렵다. 시스템 테스트를 많이 확보하더라도 테스트 집합이 완전한 커버리지를 보장하지 못할 수도 있다.
짝 Pair 플밍
- 짝 플밍은 플머들이 짝을 이루어 함께 코드를 개발하는 것을 포함한다
- 짝 플밍은 코드의 공통 소유권을 발전시키고 팀 전체에 지식을 전달하는 데 도움이 된다
- 코드의 각 행을 2인 이상이 살펴보는 비공식적인 검토 과정으로 수행된다
- 시스템 코드 개선으로 팀 전체가 혜택을 볼 수 있는 만큼 리팩토링을 권장한다.
짝 플밍
- 짝 플밍에서 플머들은 SW를 개발하기 위해 같은 컴퓨터에 함께 앉는다
- 짝은 개발 과정에서 모든 팀원이 서로 작업할 수 있도록 동적으로 생성된다
- 짝 플밍 중에 일어나는 지식의 공유는 팀원들이 팀을 떠날 때 프로젝트에 대한 전반적인 위험을 줄이기 때문에 매우 중요하다
- 짝 플밍이 반드시 비효율적인 것은 아니면, 짝이 함께 작업하는 것이 두 명의 프로그래머가 개별적으로 작업하는 것보다 더 효율적이라는 일부 근거가 있다

애자일 프로젝트 관리

애자일 프로젝트 관리
- SW 프로젝트 관리자의 주된 책임은 SW를 프로젝트 계획 예산 범위 내에서 제때에 인도하도록 관리하는 것이다.
  - 이때 애자일 기법은 비공식적 계획과 프로젝트 통제로 인해 가시화에 대한 비즈니스 요구사항과 충돌
  - 조직에서 어떤 일이 진행되고 있는지를 알아야 하는 큰 회사에서 적합하지 않았음
- 프로젝트 관리에 대한 표준접근법은 계획 중심이다. 관리자들은 어떤 내용이 인도되어야 하는지, 언제 인도되어야 하는지, 누가 프로젝트 산출물 개발에 힘쓸 것인지를 보여주는 프로젝트 계획을 작성한다.
- 애자일 프로젝트 관리에는 다른 접근 방식이 필요하며, 점증적인 개발 및 애자일 기법에 사용되는 관행에 맞게 조정된다.
스크럼 애자일 기법
- 특정 애자일 실무보다는 반복적인 개발 관리에 초점을 맞춘 애자일 기법이다.
- 조직에게 프레임워크를 제공 하는데 초점, 짝 플밍, TDD 같은 특정 개발 방법의 사용을 강요하지 않음 => 쉽게 기존 방식와 통합할 수 있음 => 널리 쓰임
- 3단계
  - 초기 단계는 프로젝트의 일반적인 목표를 설정하고 SW 아키텍처를 설계하는 개요 계획 단계
  - 일련의 스프린트 사이클이 뒤따르며, 각 사이클은 시스템의 증분을 개발
  - 프로젝트 종료 단계는 프로젝트를 마무리하고 시스템 도움말 프레임과 사용자 설명서와 같은 필수적인 문서를 작성하며 프로젝트에서 얻은 교훈을 평가
스크럼 용어 @
스크럼 스프린트 사이클
- 보통 2~4주 정도 고정된 길이
- 계획 수립의 출발점은 프로젝트에서 해야 할 일의 목록인 제품 백로그 Backlog
- 선정 단계에는 고객과 협력하여 스프린트 동안 개발할 제품 백로그에서 특징과 기능을 선택하는 모든 프로젝트 팀이 포함
스프린트 사이클
- 이런한 것들이 합의되면, SW를 개발하기 위한 팀 구성
- 이 단계에서 팀은 고객과 조직으로부터 격리되며, 이른바 ‘스크럼 마스터’를 통해 모든 커뮤니케이션이 이루어짐
- 스크럼 마스터의 역할은 개발팀을 외부의 방해로부터 보호
- 스프린트가 끝나면 수행된 작업을 검토 후 이해관계자게에 제시하고 나서 다음 스프린트 사이클이 시작
스크럼에서의 팀워크
- ‘스크럼 마스터’ 는 매일 회의를 주선하고, 해야 할 일의 밀린 일을 추적하고, 결정을 기록하고, 밀린 일에 대한 진행 상황을 측정하고, 팀 외부의 고객 및 경영진과 의사소통을 하는 관리자
- 모든 팀원이 정보를 공유하는 짧은 일일 회의 (스크럼)에 참석하고, 지난 회의 이후 경과, 발생한 문제, 다음날 계획등을 기술
  - 팀원 모두가 무슨 일이 일어나고 있는지 알고, 문제가 발생하면 단기간의 업무를 다시 기획하여 대처한다는 으미
스크럼의 장단점
- 장점
  - 제품은 관리 가능하고 이해할 수 있는 단위로 분해
  - 불안정한 요구사항은 진행되지 않음
  - 팀 전체가 모든 것에 대한 가시성을 가지고 있고 결과적으로 팀 커뮤니케이션 개선
  - 고객은 증분의 정시 인도를 통해 제품이 어떻게 작동하는지 피드백을 받음
  - 고객과 개발자 간의 신뢰가 구축되고 모두가 프로젝트가 성공할 것으로 기대하는 긍적적인 문화가 조성
짧은 개발 주기 반복을 통한 서비스 조기 출시
이터레이션 기본 프레임 사례
이터레이션
- 이터레이션 계획
- 이터레이션 수행
  - 일일 스크럼 회의
- 이터레이션 검토
협업 도구의 애자일 태스크보드
사용자 스토리 규모 추정
Burn Down Chart 소멸차드 활용
분산 스크럼

애자일 기법의 규모 조정

함께 작업하는 소규모 개발팀의 중소형 프로제트에 애자일 기법이 성공적임이 입증
때때로 이러한 방법의 성공은 모든 사람이 함께 일할 때 가능한 향상된 의사소통 때문
애자일 기법의 확장은 여러 개발 팀이 참여하는 대규모 장기 프로젝트에 대처하기 위해 이러한 방법을 변경하는 것이 포함되며, 개발 팀의 구성원이 다른 장소에서 작업할 수도 있음
스케일 업과 스케일 아웃
- 스케일 업은 소규모 팀이 개발할 수 없는 대형 SW 시스템 개발에 애자일 기업을 사용
- 스케일 아웃은 다년간의 SW 개발 경험을 가진 대규모 조직 전반에 걸쳐 애자일 기법이 어떻게 도입될 수 있는지 우려
- 애자일 기법을 확장할때는 애자일 기본 원리를 유지하는 것이 중요
  - 유연한 계획 수립, 빈번한 시스템 릴리스, 지속적인 통합, 테스트 중심 개발 및 양호한 팀 커뮤니케이션
애자일 기법에서의 실무적 문제
- 애자일 개발의 비공식성은 대기업에서 흔히 사용하는 계약 정의 대한 법적 접근법과 양립할 수 없음
- SW 유지보수보다는 새로운 SW 개발에 애자일 기법이 가장 적합하지만, 대기업의 SW 비용의 대부분은 기존 SW 시스템을 유지보수하는데 소모
- 애자일 기법은 애초에 소규모 공동 배치 팀을 위해 개발되었지만 현재 전 세계에 분산된 팀이 참여하는 SW 개발을 포함
계약에 관한 이슈
- 대부분의 SW 계햑은 고객을 위해 시스템 개발자가 구현해야 할 사항을 규정하는 명세서에 기초
- 그러나 이것은 애자일 개발에서 표준이 된 명세화와 구현의 중첩을 배제
- 기능보다는 개발자가 소모한 시간에 대해 지불하는 계약이 필요
  - 하지만, 이런 계약은 SW의 인도를 보장할 수 없기 때문에 많은 계약 부서에서 위험성이 높은 것으로 간주
애자일 기법과 SW 유지보수
- 대부분의 조직은 새로운 SW 개발보다 기존 SW를 유지 관리하는 데 더 많은 비용을 지출하므로 애자일 기법이 성공하려면 원래 개발은 물론 유지보수도 지원해야 함
- 주요 이슈
  - 공식적인 문서화를 최소화하는 개발 프로세스에서 강조된 바와 같이 애자일 기법을 사용하여 개발된 시스템이 유지보수가 가능한다?
  - 고객 변경 요청에 대응하는 시스템 진화에 애자일 기법을 효과적으로 사용할 수 있는가?
- 원래의 개발팀을 유지할 수 없을 경우 문제가 발생
애자일 유지보수
- 중요한 문제
  - 제품 문서화 결여
  - 개발 프로세스에 참여한 고객의 유지
  - 개발팀의 연속성 유지
- 애자일 개발은 개발 팀이 무엇을 해야 하는지 알고 이해하는 데 좌우
- 장기간 이용되는 시스템의 경우, 원래 개발자들이 항상 근무하는 것이 아니기 때문에 실제적인 문제
애자일과 계획 주도 방법
- 대부분의 프로젝트는 계획중심적이고 애자일 프로세스의 요소를 포함. 균형을 맞추는 것은 다음에 좌우됨
  - 구현으로 변환되기 전에 매우 상세한 명세서와 설계를 갖추는 것이 중요하며, 아마도 계획 주도 접근법을 사용할 필요가 있음
  - 고객에게 SW를 인도하고 고객으로부터 빠른 피드백을 받는 점증적인 인도 전략이 현실적이면, 애자일 기법을 사용하는 것을 고려
  - 개발 중인 시스템의 규모는 얼마나 되는가? 비공식적으로 의사소통이 가능한 소규모 공동 작업팀이 시스템을 개발할 수 잇을 때 애자일 기법이 가장 효과적이지만, 대규모 개발 팀을 필요로 하는 대형 시스템에서는 계획 중심 접근법을 사용
애자일 원칙과 조직의 실무 @
- 고객 참여
- 변화 수용
- 점증적 인도
- 프로세스가 아닌 사람
애자일 개발과 계획 주도 개발에 영향을 주는 요인
- 시스템 : 유형, 수명, 규모, 규제
- 팀 : 기술, 능숙도, 분포
- 조직 : 계약, 문화, 인도
주요 이슈
- 개발하는 시스템 규모
  - 애자일 방법은 비공식적으로 의사소통할 수 있는 상대적으로 작은 공간을 공유하는 팀에서 가장 효과점
- 개발하는 시스템 유형
  - 구현 전에 많은 분석이 필요한 시스템은 이 분석을 수행하기 위해 상당히 상세한 설계가 필요
- 시스템의 예상 수명
  - 수명이 긴 시스템에는 시스템 개발자의 의도를 지원 팀에 전달하기 위한 문서가 필요
- 외부 규제
  - 시스템이 외부 감사를 받아야 하는 경우 시스템 안전성 사례의 일부로 자세한 문서를 작성해야 할 수 잇음
개발팀
- 설계자와 플머의 실력
  - 플머가 단순히 상세 설계를 코드로 변환하는 계획 주도 (기반) 접근 방식보다 애자일 방법이 더 높은 기술 수준을 필요로 한다는 주장이 가끔 제기됨
- 개발팀의 구성
  - 팀이 분산된 경우 설계 문서가 필요할 수 있음
- 활용 가능한 지원 기술
  - 설계 문서를 사용할 수 없는 경우 시각화 및 프로그램 분석을 위한 IDE 지원이 필수적
조직의 이슈
- 전통적인 공학 단체들은 계획 주도 개발을 표준으로 결정
- 상세한 시스템 명세서를 개발하는 것이 표준적인 조직의 관행
- 고객 담당자가 시스템 증분에 대한 피드백을 제공 여부
- 비공식적인 애자일 개발이 상세한 문서화를 하는 조직 문화에 적합 여부
대규모 시스템을 위한 애자일 기법
- 대형 시스템은 보통 서로 다른 팀들의 각각의 시스템을 개발하는 개별적으로 통신하는 시스템의 모임. 이 팀들은 다른 장소, 다른 시간대에서 일하고 있는 경우도 있음
- 대형 시스템은 ‘브라운 필드 시스템’ 으로, 즉 다수의 기존 시스템을 포함하고 상호 작용. 많은 시스템 요구사항이 이러한 상호작용과 관련이 있으므로, 유연성이 있는 점증적 개발이 실제로 도움이 되지 않음
- 시스템을 만들기 위해 여러 시스템을 통합하는 경우, 개발의 상당 부분은 원점에서의 코드 개발보다는 시스템 설정 Configuration에 관련됨
대규모 시스템 개발
- 대형 시스템과 개발 프로세스는 종종 개발 방식을 제한하는 외부 규칙과 규제에 의해 제약을 받음
- 대형 시스템은 조달 및 개발 시간이 길기 때문에, 필연적으로 이직이 수박되므로 개발 기간 동안 시스템을 잘 알고 있는 일관성 있는 팀을 유지하는 것은 어려움
- 대형 시스템은 일반적으로 다양한 이해관계자를 가지므로 이러한 서로 다른 이해관계자 모두를 개발 과정에 참여시키는 것은 사실상 불가능
대규모 프로젝트의 특성 @
IBM의 애자일 스케일링 모델 @
대형 시스템으로 확장
- 요구공학에 대한 완전한 점증적인 접근은 불가능
- 단일 제품 소유자 또는 고객 대표는 있을 수 없음
- 시스템의 코드에만 집중하는 것이 불가능
- 팀 간 의사소통 체계를 설계하고 사용
- 지속적인 통합은 현실적으로 불가능하지만, 빈번한 시스템 구축과 시스템의 정기적인 릴리스를 유지하는 것이 필수적
다중 팀 스크럼
- 역할 복제
  - 각 팀에는 작업 컴포넌트에 대하 제품 소유자와 스크럼 마스터가 있음
- 제품 아키텍트
  - 각 팀은 제품 아키텍트를 선택하고 이들 아키텍트는 전체 시스템 아키텍처를 설계하고 발전시키기 위해 협력
- 릴리스 정렬
  - 각 팀의 제품 릴리스 날짜는 시연 가능하고 완전한 시스템이 생성되도록 조정
- 스크럼의 스크럼
  - 각 팀의 대표가 만나 진행 상황을 논의 하고 수행할 작업을 계획하는 일일 Scrum of Scrum이 있음
조직과 애자일 기법
- 애자일 기법의 형험이 없는 프로젝트 관리자는 새로운 접근방식의 위험을 받아들이기를 꺼릴 수 있음
- 대기업은 종종 모든 프로젝트가 따른 것으로 예상되는 양질의 절차와 표준을 가지고 있으며, 관료주의적인 성격 때문에 이러한 절차들은 애자일 기법과 양립할 수 없을 가능성
- 애자일 기법은 팀 구성원의 기술 수준이 비교적 높을 때 가장 잘 작동하지만, 대형 조직 내에서는 실력과 능력이 다양항 수준에 걸쳐 있는 가능성
- 특히 정동적인 시스템 공학 프로세스를 사용한 오랜 역사를 가진 조직에서는 애자일 기법에 대한 문화적 거부감의 가능성

Chapter 4 : 요구공학

시스템이 제공해야 하는 서비스들과 그 서비스들의 동작에 관한 제약조건이 요구사항
시스템 요구사항은 요구공학 프로세스 중에 생성되는 시스템 서비스와 제약조건에 대한 기술 Descriptions
이런한 서비스와 제약사항을 찾고, 분석하고, 문서화하며 점검하는 프로세스가 요구 공학 RE
요구사항이란?
- 시스템이 제공해야 하는 서비스에 대한 고수준의 추상적 서술 혹은 시스템에 대한 제약사항
- 다음 역할에 필수적
  - 계약 체결의 근거이므로 누구나 동일하게 해석
  - 계약 자체이므로 상세하게 정의
  - 이러한 문장들을 요구사항이라고 부름
요구사항 추상화 Davis @
요구사항 유형
- 사용자 요구사항
  - 시스템이 제공하는 서비스와 시스템이 운영되는 제약 조건에 관한 자연어로 기술된 문장과 다이어그램
  - 고객을 위해 작성
  - 고수준의 추상적 요구사항
- 시스템 요구사항
  - 시스템의 기능, 서비스, 운영제약 조건의 상세한 기술을 설정한 구조적 문서
  - 무엇이 구현되어야 하는지를 정의하므로 고객과 계약자 사이의 계약의 일부가 될 수 있음
사용자 요구사항과 시스템 요구사항 @Mascari4615
다양한 유형의 요구사항에 대한 독자 @Mascari4615
시스템 이해당사자 (이해관계자, Stakeholders)
- 어떤 식으로든 시스템에 영향을 받고 합법적인 이해관계를 가진 사람 또는 조직
- 이해당사자 유형
  - 최종 사용자
  - 시스템 관리자
  - 시스템 소유자
  - 외부 이해당사자
애자일 기법과 요구사항
- 많은 애자일 기법들은 요구사항이 너무 빨리 바뀌기 때문에 상세한 시스템 요구사항을 생성하는 것은 시간 낭비라고 주장
- 따라서 요구사항 문서는 항상 최신 버전이 아님
- 애자일 기법은 대개 점증적인 요구공학을 사용하며 요구사항을 ‘사용자스토리’로 표현
- 이것은 비즈니스 시스템에는 실용적이지만 요구분석이 중요한 (I.E. 중대한 시스템) 시스템이나 여러 팀이 개발하느 시스템의 경우 문제

기능적/비기능적 요구사항

기능적 요구사항
- 시스템이 제공해야 하는 서비스와 시스템이 특정 입력에 대해 어떻게 반응하는지, 그리고 시스템이 특정 상황에서 어떻게 행동해야 하는지에 관한 사항
비기능적 요구사항
- 시스템에서 제공하는 서비스나 기능에 대한 제약. 여기에는 시간적 제약, 개발 프로세스와 표준, 등에서의 제약이 포함
- 개별적인 특성이나 서비스보다는 전체적으로 시스템에 적용되는 것이 일반적
도메인 요구사항
- 운영되는 도메인으로부터 시스템에 가해지는 제약조건
기능적 요구사항
- 시스템의 기능과 서비스를 기술
- SW 유형, 예상되는 사용자, SW가 사용되는 곳의 시스템 유형에 좌우
- 기능적 사용자 요구사항은 시스템이 제공해야 하는 고수준의 문장이지만, 기능적 시스템 요구사항은 시스템 서비스를 상세하게 기술해야 함
요구사항의 부정확성
- 요구사항이 정확하게 기술되지 않을 때 문제가 발생
- 모호한 요구사항은 개발자와 사용자에 의해 상이하게 해석될 수 잇음
- I.E.
  - 적절한 뷰어 Viewer란?
    - 사용자의 의도 : 각각의 상이한 문서 유형을 위한 특정 목적의 뷰어
    - 개발자의 해석 : 문서의 내용을 표시하는 텍스트 뷰어 제공
  - 학부생은 총 10권까지 대출할 수 있다
    - 사용자의 의도 : 한 학기에 10권까지 대출
    - 개발자의 해석 : 졸업 시까지 10권까지 대출
요구사항의 완전성과 일관성
- 원칙적으로, 요구사항은 완전하고 일관성이 있어야 함
- 완전성
  - 요구사항은 필요한 모든 기능을 기술 Descriptions 해야 함
- 일관성
  - 시스템 기능의 기술이 충돌하거나 모순되지 않아야 함
- 실제로는 완전하고 일관성 있는 요구 문서를 생성하기는 불가능
비기능적 요구사항
- 시스템에 의해서 제공되는 특정 기능과 직접 관련이 없는 요구사항으로, 시스템의 특성과 제약 조건을 정의
  - I.E. 신뢰성, 응답 시간, 저장 장치 요구사항, IO장치의 능력, 시스템 표현 등
- 프로세스 요구사항은 특정 CASE 시스템, 프로그래밍 언어 혹은 개발 방법이 될 수도 있음
- 비기능적 요구사항은 기능적 요구사항보다 더욱 중요할 수 있음. 비기능적 요구사항이 만족되지 못하면, 시스템은 쓸모가 없음
비기능적 요구사항의 예 (유형 @)
- 제품 요구사항
  - 성능 요구사항, 신뢰성 요구사항, 사용성 요구사항, …
- 조직 요구사항
  - 환경 요구사항, 운영 요구사항, 개발 요구사항, …
- 외부 요구사항
  - 규제 요구사항, 법률적 요구사항, 윤리적 요구사항, …
비기능적 요구사항 증명
- 증명 가능한 비기능적 요구사항
  - 경험 있는 관리자가 두 시간의 교육 후에 모든 시스템 기능을 사용할 수 있어야 한다.
  - 교육 후에는 경험있는 사용자의 평균 오류의 개수가 하루에 두 개를 넘지 않아야 한다.
비기능적 요구사항 척도
- 속도
- 크기
- 사용 편리성
- 신뢰성
- 견고성
- 이식성
요구사항의 상호작용
- 상이한 비기능적 요구사항 사이의 모순은 복잡한 시스템에서 일반적인
- 신분 확인 요구사항
- 우주선 시스템
  - 무게를 최소화하기 위해 시스템에 개별 칩의 개수를 최소화해야 한다
  - 전력 소비를 줄이기 위해 전력을 적게 쓰는 칩을 사용해야 한다
  - 그러나 전력을 적게 쓰는 칩을 사용한다는 말은 더 많은 칩들이 사용되어야 한다는 의미이다. 이들 중에서 어느 것이 가장 중요한 요구사항인가?

요구공학 프로세스

RE를 위해 사용되는 프로세스는 응용 도메인, 요구사항을 개발하느데 참여하는 사람 및 조직에 매우 광범위하게 좌우됨
그러나, 모든 프로세스에 공통적인 활동은
- 요구사항 도출, 명세화, 검증, 변경(관리)
실무에서는 RE는 이러한 프로세스가 중첩된 반복적인 활동
요구공학 프로세스 나선형 모델 @Mascari4615

요구공학 도출

요구사항 도출과 분석
- 요구사항 추출 혹은 요구사항 발견이라고 부름
- 고객과의 협력을 통해 App 도메인, 시스템이 제공해야 하는 서비스 및 시스템의 운영 제약을 찾음
- 최종 사용자, 관리자, 유지보수에 참여하는 엔지니어, 도메인 전문가, 노조 등을 포함할 수 있고, 이들을 이해당사자 Stakeholders 라고 부름
요구사항 도출이 어려운 이유 @Mascari4615
요구사항 도출과 분석 프로세스 @Mascari4615
요구사항 도출
- SW 엔지니어는 다양한 시스템 이해 당사자들과 협력하여 App 도메인, 시스템이 제공해야 하는 서비스, 필요한 시스템 성능, HW 제약 등을 발견
- 단계
  - 요구사항 발견 및 이해
    - 이해당사자와 상호작용하여 요구사항을 발견. 도메인 요구사항도 이 단계에서 검색
  - 요구사항 분류 및 구성
    - 관련된 요구사항을 그룹화하고 일관된 클러스터로 구성
  - 요구사항 우선순위 설정 및 협상
    - 요구사항의 우선 순위 지정 및 요구 사항 충돌 해결
  - 요구사항 문서화
    - 요구사항은 문서화되어 나선의 다음 라운드에 입력
요구사항 발견
- 필요한 시스템과 기존 시스템에 대한 정보를 수집하고 사용자 요구사항과 시스템 요구사항을 이 정보로부터 추출하는 프로세스
- 관리자부터 외부의 담당 기관에 이르는 시스템 이해관계자와의 상호작용
- 시스템은 보통 다향한 부류의 이해당사자를 가짐
인터뷰
- 공식적 또는 비공식적 인터뷰에서, 요구공학 팀은 그들이 사용할 시스템과 개발될 시스템에 관하여 이해당사자 Stakeholders 에게 질문을 함
- 인터뷰의 유형
  - 미리 주어진 질문에 대해 답을 하는 폐쇄적 인터뷰
  - 미리 정해진 내용이 없는 개방적 인터뷰
- 효과적인 인터뷰
  - 열린 자세로 요구사항에 대한 선입견을 피하고 이해당사자의 말을 기꺼이 경청
  - 인터뷰 대상자가 시작 질문, 요구사항 제안서를 사용하거나 프로토타입 시스템을 함께 사용하여 토론을 진행하도록 유도
인터뷰 실무
- 보통은 폐쇄적 인터뷰와 개방형 인터뷰가 혼재
- 인터뷰는 이해당사자들이 무엇을 하고 그들이 시스템과 어떻게 상호작용할 수 있는지에 대한 전반적인 이해를 얻는 데 유용함
- 인터뷰 진행자는 시스템이 무엇을 해야 하는지에 대한 사전 구성없이 열림 마음을 가질 필요가 있음
- 단순히 무엇을 원하는지 물어보기 보다는 요구사항을 제시함으로써 시스템에 대해 이야기할 수 있도록 유도할 필요가 있음
인터뷰의 문제점
- App 전문가는 요구사항 엔지니어가 이해하기 쉽지 않은 작업 설명하기 위한 전문 용어를 사용할 수 있음
- 인터뷰는 도메인 요구사항을 이해하는 데 좋지 않음
  - 요구사항 엔지니어는 특정 도메인 용어를 이해할 수 없음
  - 어떤 도메인 지식은 너무 익숙해서 표현하기가 어렵거나 설명할 가치가 없다고 생각하기도 함
문화기술적 연구 Ethnography
- 사회과학자는 사람들이 실제로 어떻게 일하는지 관찰하고 분석하는데 상당한 시간을 소비
- 사람들은 자신들의 일을 설명하거나 분명하게 말할 필요가 없음
- 중요한 사회적 및 조직적 요인을 관찰
- 문화기술적 연구는 작업이 단순한 시스템 모델에서 제안하는 것보다 더 풍부하고 더 복잡하다는 것을 보여줌
스토리와 시나리오
- 시나리오와 사용자 스토리는 시스템을 어떻게 사용하는지 보여주는 실제 사례
- 스토리와 시나리오는 시스템을 특정 업무에 사용하는 방법에 대한 설명
- 실무적인 상황을 바탕으로 하기 때문에 이해당사자가 공감할 수 있고, 스토리와 관련하여 자신의 상황에 대해 의견을 제시
교실에서 사진 공유하기 @114p 4.9
시나리오
- 시스템이 어떻게 사용될 수 있는지에 관한 실생활의 예
- 사용자 스토리의 구조화된 형식
- 다음을 포함해야 함
  - 시작 상황 기술
  - 사건의 정상적 흐름 기술
  - 잘못될 수 있는것의 기술
  - 다른 병행 활동의 정보
  - 시나리오 종료시의 상태 기술
KisdTakePics에 사진 업로드하기 @115p 4.10

요구공학 명세화

요구사항 문서에 사용자 및 시스템 요구사항을 기록하는 프로세스
사용자 요구 사항은 기술적 배경이 없는 최종 사용자와 고객이 이해할 수 있어야 함
시스템 요구사항은 보다 상세한 요구사항을 더 많은 기술적 정보를 포함
요구사항은 시스템 개발을 위한 계약의 일부
- 그러므로 가능한 한 완전하게 하는 것이 중요
시스템 요구사항 작성 표기법 p117p 4.11
- 자연어 문장
- 구조적 자연어
- 그래픽 표현
- 수학적 명세
요구사항과 설계
- 원칙적으로 요구사항 What은 시스템이 무엇을 해야 하는지 기술해야 하며 설계 How는 이를 수행하는 방법을 기술
- 실제로는 요구사항과 설계는 분리할 수 없음
  - 시스템 아키텍처는 요구사항을 구조화하도록 설계될 수 있음
  - 시스템은 설계 요구사항을 생성하는 다른 시스템과 상호작용할 수 있음
  - 비기능적 요구사항을 충족하기 위한 특정 아키텍처의 사용은 도메인 요구사항
  - 이것은 규제 요구사항의 결과일 수 있음
자연어 명세서
- 요구사항은 다이어그램과 표로 보충되는 자연어 문장으로 작성
- 표현력이 풍부하고 직관적이며 보편적이기 때문에 요구사항 작성에 이용되며, 이것은 요구사항을 사용자와 고객이 이해할 수 있다느 ㄴ것을 의미
요구사항 작성 가이드라인
- 표준 형식을 만들고 모든 요구사항이 그 형식을 따름
- 필수적인 사항과 바람직한 사항을 구분하기 위해 언어을 일관성 있게 사용
- 요구사항의 중요 부분을 선택하기 위해 텍스트 강조 ㅅ용
- 컴퓨터 전문 용어 사용을 회피
- 왜 요구사항을 포함했는지 설명(이유)을 포함
자연어의 문제점
- 명료성 결여
  - 정밀하게 만들면 문서가 읽기 어렵게 됨
- 요구사항 혼란
  - 기능적 요구사항과 비기능적 요구사항이 뒤섞일 가능성
- 요구사항 융합
  - 몇 가지 서로 다른 요구사항이 함께 표현될 수 있음
인슐린 펌프 SW 시스템의 요구사항 I.E. @118p 4.12
구조적 명세서
- 요구사항 작성자의 자유가 제한되고 요구사항이 표준적인 방법으로 작성되는 요구사항 작성
- 임베디드 제어 시스템에 대한 요구사항과 같은 일부 유형의 요구사항에서는 적합하지만 때때로 비즈니스 시스템 요구사항을 작성하기에는 너무 엄격
표준 서식 기반 명세서
- 기능과 개체에 대한 설명
- 입력과 입력의 출처에 대한 설명
- 출력과 출력의 목적지에 대한 설명
- 계산에 필요한 정보나 시스템에서 필요한 다른 개체들에 대한 정보
- 수행해야 하는 동작에 대한 설명
- 사전 조건과 사후 조건
- 부작용
인슐린 펌프에 대한 요구사항의 구조적 명세서 @4.13
표를 이용한 명세서
- 자연어를 보충하기 위해 사용
- 특히 가능한 여러 가지의 Courses of Action 을 정의할 때 유용
- I.E. 인슐린 펌프 시스템은 혈당 수준의 변화 속도를 기반으로 계산되며 표 명세서는 다양한 시나리오에 대한 인슐린 요구량을 계산하는 방법을 설명
인슐린 펌프에 필요한 계산 명새 @4.14
유스케이스
- 시스템과 상호작용하는 Actor와 상호작용 자체를 식별하는 UML의 시나리오 기반 기술
- 유스케이스 집합은 시스템과의 가능한 모든 상호작용의 기술
- 상세한 표를 이용하여 고수준의 그래픽 모델이 보완될 수 있음
- 유스케이스의 세부 내역은 시스템에서 처리되는 순차적인 사건을 나타내는 시퀀스 다이어그램 Sequence Diagrams 으로 나타냄
Mentcare 시스템에 대한 유스케이스 @4.15
도서 대출 유스케이스
도서관리 시스템 유스케이스
SW 요구사항 문서
- SW 요구사항 무서는 시스템 개발자에게 요구되는 사항에 대한 공식적인 서술
- 사용자 요구사항의 정의와 시스템 요구사항의 명세를 모두 포함
- 설계 문서가 아니므로, 가능하면 시스템이 ‘어떻게’ 해야 하느것이 아니라 ‘무엇’을 해야 하는지를 기술
요구사항 문서의 사용자 @4.16
요구사항 문서의 다양성
- 요구사항 문서의 정보는 사용되는 시스템 유형과 개발접근법에 좌우
- 점증적으로 개발된 시스템은 일반적으로 요구사항 문서에 상세한 내용을 포함하지 않음
- 요구사항 문서 표준 (I.E. IEEE 표쥰) 은 주로 대형 시스템 엔지니어링 프로젝트의 요구사항에 적용
요구사항 문서의 구조 @124p 4.17

요구공학 검증

요구사항이 고객이 정말 원하는 것을 제대로 정의하고 있는지를 점검
요구사항 오류로 인한 비용은 크기 때문에 검증이 매우 중요
- 인도 후에 요구사항 오류를 수정하는 비용은 구현 오류를 수정하는 비용의 100배
요구사항 검증
1. 유효성 : 다양한 요구를 가지는 이해당사자 사이에서 타협점을 찾아야한다.
2. 일관성 : 문서에 있는 요구사항은 서로 상충되지 않아야 한다
3. 완전성 : 요구사항 명세서에는 모든 기능이 정되어야 하고, 사용자가 의도한 제약 조건을모두 포함해야 한다
4. 실현 가능성 : 요구사항이 기존 기술과 예산 및 일정 내에 구현될 수 있어야 한다
5. 검증 가능성 : 요구사항은 문서로 작성하여 검증할 수 있어야 하고, 인도된 최종 시스템이 요구사항과 일치하는지를 검증하는 테스트 계획을 작성해야한다
요구사항 검증 기술
- 요구사항 검토
  - 요구사항의 체계적인 분석
- 프로토타이핑
  - 요구사항을 체크하기 위해 시스템의 실행가능한 모델을 이용
- 테스트 케이스 생성
  - 테스트 가능성을 체크하기 위해 요구사항을 위한 테스트 개발
요구사항 검토 Reviews
- 요구사항 정의가 공식화되는 동안 정기적인 검토를 수행
- 클라이언트와 계약담당자 모두 검토에 참여해야 함
- 검토는 완성된 문서를 가진 공식적 검토 또는 비공식적 검토일 수 있음. 개발자, 고객 및 사용자 간의 원활한 커뮤니케이션은 초기 단계에서 문제를 해결
검토 Review에서 체크할 것
- 증명가능성 Verifiability
  - 요구사항이 실제적으로 테스트 가능한가?
- 이해가능성 Comprehensibility
  - 요구사항이 적절하게 이해되었는가?
- 수정가능성 Adaptability
  - 요구사항이 다른 요구사항에 큰 영향을 끼치지 않고 변경될 수 있는가?

요구사항 변경

요구사항 변경
- 시스템의 비즈니스 및 기술 환경은 설치 후 항상 변경됨
  - 새로운 HW가 도입될 수도 있고, 다른 시스템과 시스템을 연계할 필요가 있을 수 있으며, 비즈니스 우선순위가 변경될 수 있으며 (필요한 시스템 지원이 변경된 결과에 따라), 시스템이 반드시 준수해야 하는 새로운 법률 및 규정이 도입
- 어떤 시스템에 돈을 지불하느 ㄴ사람들과 그 시스템의 사용자들이 동일한 경우는 드뭄
  - 시스템 고객은 조직 및 예산 제약으로 인해 요구사항에 영향을 미치고 이는 최종 사용자 요구사항과 상충될 수 있으먀, 시스템이 목표를 달성하려면 사용자 지원을 위해 새로운 기능을 추가해야 할 수 있음
- 대형 시스템은 대개 다양한 사용자 커뮤니티를 가지며, 많은 사용자들이 서로 상충되거나 모순될 수 있는 요구사항과 우선순위를 가짐
  - 최종 시스템 요구사항은 필연적으로 이들 사이의 절충안이며, 경험상 다양한 이해당사자에게 주어진 지원의 균형이 바뀌어야 할 수도 있음
요구사항 진화
요구사항 관리
- 요구사항 관리는 요구공학 프로세스와 시스템 개발 중에 변화하는 요구사항을 관리하는 프로세스
- 시스템이 개발되고 사용되기 시작한 후 새로운 요구사항이 등장
- 개별 요구사항을 추적하고 종속된 요구사항 간의 연결을 유지하여 요구사항 변경의 영향을 평가할 수 있어야 함. 변경에 대한 제안을 하고 시스템 요구사항과 연결하기 위한 공식적인 프로세스를 수립할 필요가 있음
요구사항 관리 계획 수립
- 요구되는 요구사항 관리 세부사항의 수준을 설정
- 요구사항 관리는 다음을 결정
  - 요구사항 식별
    - 각 요구사항은 다른 요구사항과 상호 참조할 수 있도록 고유하게 식벽
  - 변경 관리 프로세스
    - 변경의 영향과 비용을 평가하는 일련의 활동
  - 추적 가능성 정책
    - 각 요구사항 간의 관계 및 요구사항과 시스템 설계 간의 관계를 저의
  - 도구 지원
    - 전문적인 요구사항 관리 시스템부터 스프레드시트 및 간단한 DB시스템에 이르기까지 사용할 수 있는 도구
요구사항 변경 관리
- 요구사항 변경을 수용할 것인가의 여부를 결정
  - 문제 분석 및 변경 명세
    - 이 단계에서 문제 또는 변경 제안이 유효한지 확인하기 위해 분석됨. 이 분석은 보다 구체적인 교구사항 변경 제안으로 응답하거나 용청을 철화화기로 결정할 수도 있는 변경 요청자에게 피드백
  - 변경 분석 및 비용 산출
    - 제안된 변경의 효과는 추적가능성 정보와 시스템 요구사항에 대한 일반적인 지식을 사용하여 평가됨. 이 분석이 완료되면 요구사항 변경을 진행할지 여부를 결정
  - 변경 구현
    - 요구사항 문서와 필요한 경우 시스템 설계 및 구현이 수정됨. 이상적으로는 변경 사항을 쉽게 구현할 수 있도록 문서를 구성
요구사항 변경 관리

Chapter 5 : 시스템 모델링

시스템 모델링
- 시스템 모델링은 시스템의 추상적 모델을 개발하는 과정이며, 각 모델은 시스템의 다른 뷰나 관점을 제시
- 시스템 모델링은 이제 거의 항상 UML의 표기법을 기반으로 하는 그래픽 표기법을 사용하여 시스템을 표현하는 것을 의미
- 시스템 모델링은 분석가가 시스템의 기능을 이해하는데 도움이 되며, 모델은 고객과의 의사소통에 사용
기존의 시스템과 개발될 시스템
- @기존 시스템의 모델은 요구공학 RE 중에 사용되고, 기존 시스템이 무엇을 하고 있으며 장단점을 논의하기 위한 기초로 사용될 수 있는가를 명확히 하는데 도움을 줌. 이러한 것들은 새로운 @시스템에 대한 요구 사항으로 이어짐
- 새로운 시스템의 모델은 제안된 요구 사항을 요구공학 RE 중에 다른 시스템 이해당사자들 Stakeholders 에게 설명하는 데 도움을 주기 위해 사용됨. 엔지니어는 설계안을 논의하고 구현을 위한 시스템을 문서화하기 위해 이 모델을 사용
시스템 관점
- 시스템의 컨텍스트나 환경을 모델링하는 외부 관점
- 시스템과 환경 사이의 상호 작용을 모델링하는 상호 작용 관점
- 시스템의 구성이나 시스템에 의해 처리되는 데이터의 구조를 모델링하는 구조 관점
- 시스템의 동적인 행동을 모델링하는 동작 관점
모델링과 SW 개발
객체지향 분석과 설계/UML
UML 다이어그램
5장에서 주로 사용되는 UML 다이어그램
- 액티비티 다이어그램
- 유스케이스 다이어그램
- 시퀀스(순차) 다이어그램
- 클래스 다이어그램
- 상태 다이어그램
그래픽 모델을 사용하는 방법
- 기존 또는 제안된 시스템에 대한 토론을 자극하고 초점을 맞춤
  - 불완전하고 잘못된 모델이라도 토론을 지원하는 역할이므로 OK
- 기존 시스템의 문서화
  - 모델은 시스템을 정확하게 나타내야 하지만 완전하지는 않아도 됨
- 시스템 구현에 이용될 수 있는 상세한 시스템 Description
  - 모델은 정확하고 완전해야 함

컨텍스트 모델

시스템이 동작하는 전체 컨텍스트를 설명하는데 사용 - 시스템 경계 밖에 무엇이 있는지 표현
사회적 관계는 시스템 위치 결정에 영향을 미칠 수 있음
아키텍처 모델은 시스템과 다른 시스템과의 관계를 표현

@스테레오 타입

시스템 경계
- 시스템 경계는 시스템 내부에 무엇이 있고 시스템 외부에 무엇이 있는지 정의하기 위해 설정
  - 개발중인 시스템에 사용되거나 의존하는 다른 시스템을 표현
- 시스템 경계의 위치는 시스템 요구사항에 지대한 영향을미침
- 시스템 경계 정의는 정치적 판단
  - 조직의 서로 다른 부분의 영향이나 시스템 경계를 설정하라는 압력에 의해 업무량이 증가/감소할 수 있음
Mentcare 시스템의 컨텍스트
프로세스 관점
- 컨텍스트 모델은 개발 중인 시스템이 그 환경에서 어떻게 사용되는지가 아니라 해당 환경에서의 다른 시스템들을 간단하게 표현
- 프로세스 모델은 개발 중인 시스템이 보다 광범위한 비즈니스 프로세스에서 어떻게 사용되는지를 표현
- UML 액티비티 다이어그램을 사용하여 비즈니스 프로세스 모델을 정의
강제수용 프로세스 모델 (액티비티 다이어그램)

상호 작용 모델

상호 작용 모델
- 사용자 상호작용을 모델링하는 것은 사용자 요구사항을 식별하는 데 도움이 되기 때문에 중요
- 시스템 간 상호 작용 모델링은 발생할 수 있는 커뮤니케이션 문제를 강조
- 컴포넌트 상호작용 모델링은 제안된 시스템 구조가 필요한 시스템 성능과 신뢰성을 제공할 가능성이 있는지 여부를 이해하는데 도움이 됨
- 유스케이스 다이어그램과 시퀸스 다이어그램이 상호작용 모델링에 이용됨
유스케이스 모델링
- 유스케이스는 원래 요구사항 도출 지원을 위해 개발되었고 현재는 UML에 통합됨
- 각 유스케이스는 시스템과의 외부 상호작용을 포함하는 별개의 작업을 나타냄
- 유스케이스의 액터는 사람 또는 다른 시스템
- 유스케이스의 개요는 다이어그램으로 표현하고 보다 상세한 정보는 텍스트 양식을 제공
데이터 전송 유스케이스
- Mentcare 시스템의 유스케이스
데이터 전송 유스케이스의 표 형식 기술
유스케이스 명세서 : 양식
유스케이스 다이어그램
유스케이스 명세서
병원 접수원과 관련된 Mentcare 시스템의 유스케이스
시퀸스 다이어그램 (순차 다이어그램)
- 시퀸스 다이어그램은 UML의 하나로, 액터와 시스템 내의 객체 사이의 상호작용을 모델링하는 데 사용
- 시퀸스 다이어그램은 특정 유스케이스 또는 유스케이스 인스턴스 중에 발생하는 상호작용 순서를 표현
- 포함된 객체와 액터는 다이어그램 상단을 따라 나열되며, 이들로부터 수직으로 점선이 그려짐
- 객체 간의 상호 작용은 주석이 붙은 화살표로 표현
환자 정보 조회의 시퀀스 다이어그램
데이터 전송의 시퀀스 다이어그램

@ 141p 마지막 줄 @ 144p

시퀀스 다이어그램가 클래스의 연산, 시험?

구조 모델

구조 모델
- SW의 구조 모델은 시스템을 구성하는 Component와 Component들의 관계로 시스템을 표현
- 구조 모델은 시스템 설계의 구조를 부여주는 정적 모델 또는 시스템이 실행 중일 때 시스템의 구성을 보여주는 동적 모델
- 시스템 아키텍처를 노의하고 설계할 때 시스템의 구조 모델을 생성
클래스 다이어그램
- 클래스 다이어그램은 시스템의 클래스와 이러한 클래스 간의 연관성을 보여주는 객체 지향 시스템 모델을 개발할 때 사용
- 클래스는 시스템 객체에 대한 일반적인 정의
- 연관 Association 은 클래스들 사이의 어떤 관계가 있음을 나타내는 클래스들 간의 연결 Link
- SW 공학 프로세스의 초기 단계에서 모델을 개발할 때, 객체는 환자/처방전/의사 등과 같은 실세계의 어떤 것을 표현
UML 클래스의 연관
- UML 다이어그램의 각 구성 요소는 소스 코드로 구현될 것
MHC-PMS의 클래스와 연관
Consultation 클래스
일반화 Generalizaion
- 일반화는 우리가 복잡도를 관리하기 위해 사용하는 일상적인 기술
- 우리가 경험하는 모든 개체의 세부적인 특성을 배우기보다는 이러한 개체를 좀 더 일반적인 클래스 (동물, 자동차, 집 등)에 배치하고 이러한 클래스의 특성을 학습
- 이것은 우리가 이러한 클래스의 다른 멤버들이 몇 가지 공통적인 특성을 가지고 있다는 것을 유추할 수 있음. 예를 들어 다람쥐와 쥐는 설치류 클래스 멤버이므로, 설치류의 특성 공유
일반화
- 모델링 시스템에서, 일반화된 범위를 확인하기 위해 시스템 내 클래스를 검토하는 것이 종종 유용. 변경사항이 제안되면 변경사항의 영향을 받는지 확인하기 위해 시스템의 모든 클래스를 볼 필요가 없음
- 자바와 같은 객체 지향 언어에서는 언어에 내장된 클래스 상속 메커니즘을 이용하여 일반화를 구현
- 일반화에서 상위 클래스와 관련된 속성 및 연산도 하위 클래스와 관련됨
- 하위 클래스는 슈퍼 클래스프로부터 속성과 연산을 상속 받고, 하위 클래스는 보다 구체적인 속성과 작업을 추가
일반화 계층 구조
상세 내역이 추가된 일반화 계층 구조
집합 Aggregation 연관 모델
- 집합 연관은 한 클래스가 다른 클래스들로 구성됨
- 집합 연관 모델은 시맨틱 데이터 모델의 Part-of 관계와 유사

동작 모델

동작 모델
- 동작 모델 (행위 모델)은 실행 중인 시스템의 동적 행동의 모델로 시스템이 환경의 자극에 반응할 때 어떤 일이 일어나거나 일어나게 되어 있는가를 표현
- 자극은 두 가지 유형
  - Data 시스템에 의해 처리되어야 하는 일부 데이터가 도착
  - Events 시스템 처리를 트리거하는 일부 이벤트 발생. 이벤트에는 관련 데이터가 있을 수 있지만, 항상 그런 것은 아님.
데이터 주도 모델링
- 많은 비즈니스 시스템은 주로 데이터에 의해 구동되는 데이터 처리 시스템으로, 외부 이벤트 처리가 상대적으로 적은 시스템으로 데이터 입력에 의해 제어됨
- 데이터 주도 모델은 입력 데이터를 처리하고 관련 출력을 생성하느 데 관련된 작업 순서를 표현
- 시스템의 End to End 처리르 보여주기 위해 사용될 수 있기 때문에 요구사항 분석 중에 특히 유용
@DFD는 70 80년대 초에 사용하던 유물, 근데 기사시험에 종종 출제, UML의 액티비티 다이어그램에 해당
@DFD = 액티비티 다이어그램
인슐린 펌프 동작의 액티비티 모델
주문 처리
이벤트 주도 모델링
- 실시간 시스템은 최소한의 데이터 처리를 가진 이벤트 주도 시스템인 경우가 많음
- 이벤트 주도 모델링은 시스템이 외부 및 내부 이벤트에 어떻게 반응하는지 표현
- 시스템이 유햔한 개수의 상태를 가지고 있고 사건 (자극)이 한 상태에서 다른 상태로의 전이를 야기할 수 있다는 가정에 근거
상태 기계 모델
- 이 모델은 외부 및 내부 사건에 반등하는 시스템의 동작을 모델링
- 자극에 대한 시스템의 반응을 보여주므로 종종 실시간 시스템을 모델링하는데 사용
- 상태 기계 모델은 시스템 상태를 노드로, 이벤트는 이들 노드 사이의 아크로 표현하고, 이벤트가 발생하면 시스템은 한 상태에서 다른 상태로 이동
- 상태 차트는 UML의 필수적인 부분이며 상태 기계 모델을 나타내기 위해 사용
마이크로웨이브 오븐의 상태 다이어그램
마이크로웨이브 오븐의 연산
마이크로웨이브 오븐의 상태와 자극
- 표를 이용하여 상태, 이벤트/자극에 대한 설명

모델 주도 아키텍처

@패스

Chapter 6 : 아키텍처 설계

SW 아키텍처
- SW의 골격이 되는 기본구조
- 시스템을 구성하는 서브시스템들을 식별하고, 서브시스템의 제어와 통신을 위한 프레임워크를 설정하는 설계 프로세스가 @아키텍처 설계
- 이러한 설계 프로세스의 산출물이 @SW 아키텍처를 기술한것
아키텍처 설계
- 시스템 설계 프로세스의 첫 번째 단계
- 요구사항 분석 프로세스와 설계 프로세스 사이의 연결을 나타냄
- 특성 명세화 활동과 동시에 진행되는 것이 보통
- 주요 시스템 컴포넌트들과 이들간의 커뮤니케이션을 식별하는 것을 포함
애자일 개발과 아키텍처
- 애자일 프로세스의 초기 단계는 전체 시스템 아키텍처를 선계하는 것이라는 것을 일반적으로 인식함
- 시스템 아키텍처를 리팩토링하는 것은 시스템의 너무 많은 컴포넌트들에 영향을 미치기 때문에 대게 비용이 많이 소모
택배 포장 시스템
아키텍처 추상화
- 소규모의 아키텍처는 개별 프로그램의 아키텍처와 관련이 있음. 이 수준에서는 개별 프로그램이 컴포넌트로 분해되는 방식에 관심을 가짐
- 대규모 아키텍처는 다른 시스템, 프로그램 및 프로그램 컴포넌트를 포함하는 복잡한 전사적 시스템의 아키텍처와 관련됨. 이러한 전사적 시스템은 서로 다른 컴퓨터에 분산되어 있으며, 다른 회사가 소유하고 관리할 수 있음
아키텍처 설계, 문서화의 장점
- Stakeholder 사이의 의사소통
  - 아키텍처는 시스템 Stakeholder 간의 논의의 초점을 이용 가능
- 시스템 분석
  - 시스템이 비기능적 요구사항을 만족할 수 있는지의 여부를 분석하는 것을 의미
- 대규모 재사용
  - 아키텍처는 시스템 간의 재사용 가능
  - 제품 라인 아키텍처가 개발될 수도 있음
아키텍처 표현
- 엔티티와 관계를 보여주는 간단한 ‘비공식’ 블록 다이어그램은 SW 아키텍처를 문서화하는 데 가장 ‘자주’ 사용되는 방법
- 그러나 이 방법은 ‘표현력이 부족’하여 비판되어 왔으먀, 아키텍처에서 ‘엔티티 사이의 관계 유형이나 엔티티의 가시적 특성’을 보여주지 않음
블록 다이어그램
- 매우 추상적 - 컴포넌트 관계의 특성이나 하위 시스템의 가시적 특성을 표현하지 못함
- 그러나, 이해관계자와의 커뮤니케이션 및 프로젝트 계획 수립에 유용
아키텍처 모델의 사용
- 시스템 설계에 대한 논의를 장려하기 위한 방법
  - 시스템의 상위 수준의 아키텍처 뷰는 너무 세부적인 내용으로 복잡하지 않기 때문에 시스템 이해당사자와의 커뮤니케이션 및 프로젝트 계획 수립에 유용. 이해당사자는 이에 관련된 시스템의 추상적 관점을 이해할 수 있음. 세부 사항에 의해 혼동되지 않고 시스템 전체를 논의할 수 있음
- 설계한 아키텍처를 문서화하는 방법
  - 목표는 시스템의 다양한 컴포넌트, 인터페이스 및 연결을 보여주는 완전한 시스템 모델을 생성

아키텍처 설계 결정

아키텍쳐 설계 결정
- 아키텍쳐 설계는 창조적인 프로세스로 개발되는 시스템의 유형, @아키텍트의 배경과 경험, 시스템의 특정 요구사항에 좌우됨
- 그러나 다수의 공통적인 결정이 존재하고, 이러한 결정은 시스템의 비기능적인 특성에 영향을 끼침
아키텍처 설계 결정
아키텍처 재사용
- 동일한 도메인의 시스템은 도메인 개념을 반영하는 유사한 아키텍처를 가짐
- 응용 시스템의 제품 라인 Product Line 이 핵심 아키텍처를 중심으로 구축되고, 특정 고객의 요구사항을 만족하는 변동 부분이 있음
- 시스템 아키텍처는 하나 이상의 아키텍처 패턴 또는 ‘스타일’ 중 하나를 중심으로 설계
  - 아키텍처의 핵심을 파악하여 상이한 방식으로 인스턴스화할 수 있음
아키텍처와 비기능적 요구사항
- 성능 Performance
  - 중요한 연산을 지역화시켜 통신을 최소화. 단위가 큰 컴포넌트를 사용
- 보안성 Security
  - 중요한 자산을 내부 계층에 두는 계층 아키텍처를 사용
- 안전성 Safety
  - 안전성이 중요한 부분을 작은 수의 서브시스템으로 국한시킴
- 가용성 Availability
  - 여분의 컴포넌트와 결함 내성을 위한 메커니즘을 포함
- 유지보수성 Maintainability
  - 단위가 작은 대치 가능한 컴포넌트를 사용

아키텍처 뷰

아키텍처 뷰
- 시스템 아키텍처를 설계하고 문서화할 때 어떤 뷰 views 이나 관점 Perspectives 이 유용한가?
- 아키텍처 모델을 기술하는 데 어떤 표기법이 사용되어야 하는가?
- 각 아키텍처 모델은 시스템에 대한 하나의 뷰 또는 관점만 표현
  - 시스템이 어떻게 모듈로 분해되는지, 런타임 프로세스가 어떻게 상호작용하는지 또는 시스템 컴포넌트가 네트워크 상에서 분산되는 다른 방식을 표현. 설계와 문서에서는 항상 SW 아키텍처에 대한 다중 뷰를 제시할 필요가 있음
아키텍처 뷰
SW의 4+1 뷰 모델
- 논리적 뷰
- 프로세스 뷰
- 개발 뷰
- 물리적 뷰
- 유스케이스나 시나리오를 이용하는 것과 관련 +1
아키텍처 뷰의 표현
- 일부 사람들은 통합 모델링 언어 UML가 시스템 아키텍처를 기술하고 문서화하기 위한 적절한 표기법이라고 주장
- 교재의 저자는 UML이 높은 수준의 시스템 표현에 적합한 추상화를 포함하고 있다고 생각하지 않기 때문에 반대 의견
- 아키텍처 기술 언어 ADL가 개발되었지만, 널리 이용되지 않음

아키텍처 패턴

Architecture Pattern

범용 계층 아키텍처
- APP
- VM
- OS
- HW
범용 계층 아키텍처
- User Interface
- User Interface Management Authentication and Authorization
- Core Business Logic/App Functionality System Utilities
- System Support (OS, DB, ETC.)
iLearn 시스템의 계층 아키텍처
OSI 참조 모델 - 계층 모델
CASE 도구 집합 아키텍처 - 저장소 모델
- 모든 공유 데이터가 중앙의 DB에 보관되어 있는 모든 서브시스템들이 접근할 수 있따. 공유 DB 에기반을 둔 시스템 모델을 저장소 모델이라고 부른다
- 각 서브시스템이 자신의 DB를 유지한다. 데이터는 서브시스템 사이에 메시지를 전달하여 상호 교환된다
저장소 Repository 패턴 @178p 6.10
IDE를 위한 저장소 아키텍처
저장소 아키텍처 장단점
- 장점
  - 공유 저장소는 다량의 데이터를 공유하는 효과적인 방식이다
  - 데이터를 생성하는 서브시스템은 다른 시스템들이 이 데이터를 어떻게 사용하는지에 대해 알 필요가 없다
  - 백업, 보안, 접근 제어, 오류로부터의 복구와 같은 활동들은 중앙 집중화된다
  - 합의된 데이터 모델에 적합한 새로운 도구들을 통합하는 것은 간단하다
- 단점
  - 서브시스템들은 저장소 데이터 모델에 대해 합의를 해야한다
  - 합의된 데이터 모델에 맞춰 다량의 정보가 생성됨에 따라서 진화가 어려울 수도 있다
  - 상이한 서브시스템들은 보안, 복구, 백업 정책에 관해 서로 다른 요구사항을 가질 수도 있다
  - 저장소를 다수의 컴퓨터로 분산시키는 것은 어려울 수 있다.
Client-Server 아키텍처
- 데이터와 프로세싱이 일련의 컴포넌트에 어떻게 분산되는가를 보여주는 분산 시스템 모델
  - 단일 컴퓨터 상에서 구현될 수 있음
- 서비스를 다른 컴포넌트에 제공하는 서버들의 집합
- 서버에 의해 제공되는 서비스를 요청하는 클라이언트들의 집합
- 클라이언트가 서비스에 접근할 수 있게 해주는 네트워크
Client-Server 아키텍처 @180p 6.12
필름 라이브러리를 위한 Client-Server 아키텍처
Client-Server 아키텍처의 장단점
- 장점
  - 분산 아키텍처, 많은 분산 프로세서를가지는 네트워크 시스템을 효과적으로 이용할 수 있따. 새로운 서버를 추가하여 시스템의 나머지와 통합하거나 시스템의 다른 부분에 영향을 주지않고 서버를 투명하게 업그레이드하는 것이 용이하다.
- 단점
  - 새로운 서버의 통합을 위해 기본의 클라이언트와 서버에 대한 변경이 요구될 수 있다. 서버 간에 공유하는 데이터 모델이 존재하지 않아 서브시스템들은 상이한 방식으로 자신들의 데이터를 구성할 수도 있다. 이것은 특정한 데이터 모델이 각 서버별로 설정되어 성능을 최적화할 수도 있다는 것은 의미한다. 물론 만일 XML 기반의 데이터 표현이 이용되면, 하나의 스키마를 다른 스키마로 변환하는것은 비교적 쉬울 수 있다. 그러나 XML은 데이터를 표현하는 비효율적인 방식이므로, 만일 XML이 이용되는 성능문제가 야기될 수 있다.
파이프 필터 아키텍처
- 입력을 처리하여 출력을 생성하는 기능적 변환
- UNIX 셸에서 파이프 필터 Pipe and Filter모델로 부름
- 이 방법의 변형은 매우 일반적. 변환이 순차적이면 데이터 처리 시스템에서 광범위하게 이용되는 일괄처리 모델
- 대화형 시스템에는 적합하지 않음
파이프 필터 아키텍처 181p 6.14
지불 시스템에서 사용되는 파이프 필터 아키텍처의 예
파이프 필터 아키텍처 장단점
- 장점
  - 변환의 재사용을 지원한다
  - 많은 사람들이 자신들의 작업을 입력과 출력 처리 관점에서 생각한다는 점에서 직관적이다
  - 새로운 변환을 첨가하여 시스템을 진화시키는 것이 쉽사
  - 병행 시스템이나 순차 시스템으로 구현하는 것이 간단한다
- 단점
  - 모든 변환에 적용될 수 있는 공통적인 데이터 이동 양식이 필요하다
  - 대화식 시스템은 처리될 데이터의 스트림이 필요하기 때문에 파이프라인 모델을 사용하여 작성하기 어렵다

App 아키텍처

APP 아키텍처
- App 시스템은 비즈니스 혹은 조직의 요구를 만족하기 위해 개발됨
- 비즈니스에서 사용되는 APp 시스템은 공통 부분을 가짐
- 일반 App 아키텍처는 특정 요구사항을 만족하기 위해 설정되고 변환되는 SW 시스템 유형에 관한 아키텍처
APP 아키텍처의 이용
- 아키텍처 설계 프로세스의 출발점
- 설계 체크리스트
- 개발 팀의 업무를 조직하느 방법
- 재사용할 컴포넌트를 평가하는 수단
- App 유형에 관해 대화하는 용어
App 유형
- 데이터 처리 App
- 트랜잭션 처리 App
- 이벤트 처리 시스템
- 언어 처리 시스템
APp 유형 예
- 광범위하게 이용되는 두 가지 유형
- 트랜잭션 처리 시스템
  - 전자상거래 E Commerce 시스템
  - 예약 시스템
- 언어 처리 시스템
  - 컴파일러
  - 인터프리터
트랜잭션 처리 시스템
- DB에 있는 정보에 대한 사용자 요청이라 DB 갱신을 위한 요청을 처리
- 사용자 관점
  - 목표를 만족시키기 위한 작업들의 일관된 순서
  - 런던발 파리행 비행편의 시간 검색
- 일반적으로 사용자가 서비스 요청을 비동기적으로 하는 대화식 시스템
트랜잭션 처리 App의 구조
ATM 시스템의 SW 아키텍처
정보 시스템 아키텍처
- 정보 시스템은 계층 아키텍처로 구성될 수 있는 일반 아키텍처를 가짐
- 일반적으로 DB 트랜잭션을 포함하는 시스템과 상호작용하는 트랜잭션 기반 시스템
- 계층
  - 사용자 인터페이스
  - 사용자 통신
  - 정보 검색
  - 시스템DB
계층화된 정보 시스템 아키텍처
Mentcare 시스템의 아키텍처
웹 기반 정보 시스템
- 정보 및 자원 관리 시스템은 현재 대개 웹 기반 시스템으로 사용자인터페이스가 웹 브라우저를사용하여궇ㄴ
- 예를 들어 전자상거래 시스템은 상품이나 서비스에 대한 전자 주문을 받은 후 고객에게 인도하도록 주선하는 인터넷 기발의 자원 관리 시스템
- 전자상거래 시스템에서 App별 계층은 사용자가 다수의 품목을 별도 트랜잭션에 배치한 다음, 한 번의 트랜잭션으로 모두 결제할 수 있는 ‘쇼칭 카트’를 지원하는 추가적인 기능을 포함
서버의 구현
- 이 시스템들은 종종 다단 클라이언트 서버 아키텍처로 구현
  - 웹 서버는 모든 사용자 상호작용을 책임지고, 사용자 인터페이스는 웹 브라우저를 이용하여 구현
  - App 서버는 정보저장과 검색 요청뿐만 아니라 App에 특화된 처리를 구현하는 책임
  - DB 서버는 정보를 DB로 들어가고 나오게 하고 트랜잭션 관리를 다룸
언어 처리 시스템
- 자연어나 인공 언러를 입력으로 받아 해당언어의 다른 표현을 생성
- 인터프리터를포함할 수 있음
- 문제를 해결하기 위한 알고지름이나 시스템 데이터를 기수랗는 가장 쉬운 방법으로 사용됨
언어 처리 시스템의 아키텍처
컴파일러 구성요소
- 어휘 분석기
- 심벌 테이블
- 구문 분석기
- 구문 트리
- 의미 분석기
- 코드 생성기
언어 처리 시스템의 저장소 아키텍처
파이프 필터 컴파일러 아키텍처
모듈 분할의 평가 기준
- 어떤 모듈이 한 가지 목적을 위한 기능만을 제공하고 있고, 다른 모듈과의 상호작용이 적은 경우, 해당 모듈은 “@기능적 독집성이 높다”. 기능적 독집성이 높은 모듈들로 구성된 SW는 각 모듈들의 기능이 명확하게 분리되어 있고 인터페이스도 분명하게 되어 있으므로 개발이 용이하다. 또한 기능적 독집성이 높은 모듈은 설계의 변경과 프로그램의 수정에 의한 부작용이나 파급효과가 국소화되므로 테스트와 유지보수가 수월하다.
캡슐화 Encapsulation
- 서로 관련성이 많은 데이터들과 이와 관련된 함수들을 한 묶음으로 처리하는 것으로서, 캡슐화된 모듈의 세부 내용이 외부에 은폐되어 변경이 발생해도 오류의 파급효과를 최소화시키는 것이다. 캡슐을 구성하는 내부의 입자들의 구체적인 내용은 몰라도 캡슐 자체의 이름과 기능으로 사용하는 예를 따라서 캡슐로 둘러싼다는 의미에서 캡슐화라고 부른다
정보 은닉 Information Hiding
- 각 모듈들은 다른 모듈에게 인터페이스를 통해 서비스를 제공한다. 인터페이스는 모듈의 외부 명세이며, 해당 모듈의 서비스를 이용하기 위해 알고 있어야 하는 정보이다. David L. Parnas가 제안한 “@정보 은닉” 의 개겸은 인터페이스와 구현을 명확하게 분리하여 모듈의 구현에 대한 상세한 설계 정보는 다른 모듈로부터 은폐되어 참조할 수 없도록 해야 한다는 것이다.
- 캡슐화는 정보 은식을 통해 실현되었으며, 모듈의 프로시져와 모듈 내부의 데이터에 대한 조작에 관한 제약 조건을 규정한 것이다. 모듈 내부에 정의된 변수와 하위 모듈은 외부로부터 은폐되어 직접 액세스할 수 없다. 다른 모듈로부터 액세스하려면 인터페이스로서 정의된 프로시져와 함수를 통해야 한다.
- 장점
  - 모듈의 구현 내용을 살펴보지 않아도 모듈의 인터페이스를 이해하고 있으면 모듈을 이용할 수 있다.
  - 모듈의 구현을 변경하더라도 인터페이스를 변경하지 않는다면, 해당 모듈을 호출하고 있는 모듈은 아무런 영향을 받지않고 그대로 사용할 수 있다. 이것은 프로그램의 변경이 수월하게 되며 요구사항을 향상시킬 수 있다.
DFD Data Flow Diagram (70 80년대 초) → 설계 (구조 설계 → 상세 설계)
응집도와 결합도
- 정보 은닉을위해서는 모듈의 응집도를 높게 하고, 결합도는 낮게 하는 것이 좋다/ SW 설계의 관점에서도 이러한 원칙을 준수하는 것이 바람직하다
응집도 Cohesion
- 한 모듈 내부에 있는 구성 요소들 사이의 기능적 관련성을 평가하는 준이다. 한 모듈 내부의 구성 요소 사이의 기능저깅ㄴ 관련 정도 및 몯류 내부의 응집도를 최대화하는 방향을 설계하는 것이 바람직하다.

약 Bad

우연적 응집도 Coincidental Cohesion
논리적 응집도 Logical Cohesion
시간적 응집도 Temporal Cohesion
절차적 응집도 Procedural Cohesion
통신적 응집도 Communicational Cohesion
순차적 응집도 Sequential Cohesion
기능적 응집도 Functional Cohesion

강 Good

결합도 Coupling

강 Bad

내용 결합도 Content coupling
- 어떤 모듈이 인터페이스를 통하지 않도 다른 모듈이 관리하는 데이터 또는 제어 구조를 직접 이용하여 데이터를 직접 참조, 변경하는 경우의 결합도. 다른 모듈의 내부로 제어가 직접 전달되는 경우.
공통 결합도 Common Coupling
- 공통 데이터 영역에 정의한 데이터를 통해서 정보 교환을 수행하는 모듈들 사이의 결합. 공통 데이터 영역의 데이터 구조 등을 변경한 경우에 이를 참조하고 있는 모든 모듈이 영향을 받는다. 또한 모듈 내부의 데이터를 참조하는 명령과 공통 영역의 데이터를 참조하는 명령은 구별되지 않으므로, 어떤 모듈이 공통 데이터 영역의 데이터를 참조하고 있는지 명시적으로 기술되지 않는다. 따라서 프로그램의 판독을 곤란하게 하고, 공통 데이터 영역을 변경했을 경우에 영향을 받는 모듈을 간과하기 쉽다는 문제점이 있다.
- C 프로그램에서 동일 이름의 전역 변수를 두 개의 모듈에서 초기화하지 않고 선언한 경우 혹은 어느 한쪽 모듈에서만 초기화하여 선언한 경우에는 전역 변수의 실체는 한 개만 생성되어 두 모듈에서 공유하는 경우가 공통 결합도에 해당한다.
외부 결합도 External Coupling
- 외부 변수로 선언한 데이터를 공유하는 모듈들 사이의 결합도. 공통 결합도와 유사하지만, 공유하는 데이터를 외부 선언하므로 공통 결합도에서 지적되었던 문제점은 발생하지 않는다. 필요한 데이터만을 외부 선언하므로 불필요한 데이터까지 공유하는 것이 적어지게 되어 결합도가 낮아진다.
제어 결합도 Control Coupling
- 어떤 모듈이 다른 모듈을 호출하는 경우, 호출되는 모듈의 제어를 지시하는 데이터를 매개변수로 전달하는 모듈들 사이의 결합도.
- 예제 그림에서 모듈 YT는 모듈 HJ의 함수 LOVE를 호출. 이때 함수 LOVE에서는 세 번째 매개변수 flag의 값을 분기조건으로 사용하여 제어 흐름을 변경한다. 따라서 모듈 YT에서는 함수 LOVE의 내부에서의 제어 방식을 고려하여 매개변수 flag의 값을 정해야 한다. 이와 같이 호출하는 모듈은 호출되는 모듈의 내부 논리를 파악하고 있어야 하고, 어떻게 제어하면 좋을지 이해하고 있을 필요가 있다.
스탬프 결합도 Stamp Coupling
- 모듈드 간에 공유 데이터 영역에 없는 데이터로, 배열이나 레코드(구조체) 등의 데이터 구조를 전달하고 받는 모듈들 사이의 결합도
- 예제 그림에서 모듈 YT가 모듈 HJ의 함수 LOVE를 호출할 경우, Present 타입의 구조체를 매개변수로서 전달하고 있다. 이때 함수 LOVE는 구조체의 일부만을 사용하고 있지만, 함수 LOVE를 작성하기 위해서는 Present 타입 구조체의 정의를 모두 알고 있어야 한다.
데이터 결합도 Data Coupling
- 모듈들 사이에 단일 변수를 매개변수로 전달하는 경우 혹은 데이터의 필요한 부분만을 매개변수로 전달하는 방법으로만 정보 교환을 하는 모듈들 사이의 결합도. 만일 단일 변수를 매개변수로 전달하는 경우는 데이터 결합도가 되고, 결합도는 가장 낮다. 또는 호출된 모듈이 구조체 데이터의 일부 요소만을 사용하는 경우도 데이터 결합도에 해당한다.
- 예제 그림에서 함수 LOVE에서 사용한 정수 값과 문자만을 전달한다. 이와 같이 호출된 모듈이 구조체 데이터의 일부 요소만을 사용하는 경우에 그 요소를 기본형 매개변수로 하여 전달하도록 하면, 호출되는 모듈은 호출하는 모듈의 데이터구조에 관한 전체적인 지식을 필요로 하지 않기 때문에 결합도가 낮아진다.

약 Good

팬인, 팬아웃 @765p
계산 예제
계산 결과

Chapter 7 : 설계와 구현

설계 및 구현
- SW 설계 및 구현은 실행 가능한 SW 시스템이 개발되는 SW 공학 프로세스 단계
- SW 설계 및 구현 활동은 서로 중첩됨
  - SW 설계는 고객의 요구사항을 기반으로 SW 컴포넌트들과 이들 간의 관계를 식별하는 창조적인 활동
  - 구현은 설계를 프로그램으로 실현하는 프로세스
빌드 또는 구입
- 다양한 도메인에서 기성품인 Off-The-Shelf Systems COTS을 구매하여 사용자 요구사항에 따라 변환하여 맞추는 것이 가능
  - 예를 들어, 의료 기록 시스템을 구축하기 원하면 병원에서 이미 사용되고 있는 패키지 구매 가능. 이 방법이 전통적인 플밍 언어로 새로운 시스템을 개발하는 것보다 저렴하고 빠름
객체지향 분석 프로세ㅐ스
- 객체지향 개발은 Seamless Transition
70 80년대 초의 구조적 분석 및 설계
- 구조적 분석 및 설계는 뚜렷한 Seam (단계의 구분)을 가짐
- 분석(DFD 데이터 흐름도) - SEAM - 설계(구조도)
- => 정보의 유실 및 왜곡 가능성
객체 지향 분석 및 설계
- 객체지향 분석 및 설계는 Seamless Transition
- 분석 (클래스/순차 다이어그램) - No Seam - 설계 (클래스/순차 다이어그램)
- => 정보의 유실 및 왜곡 가능성 최소화

UML을 이용한 객체 지향 설계

객체 지향 설계 프로세스
- 객체 지향 설계 프로세스에는 다양한 시스템 모델 개발이 포함
- 이러한 모델의 개발과 유지보수를 위해 많은 노력을 필요로하며, 소규모 시스템의 경우 가성비가 낮음
- 그러나, 대규모 시스템에서 설계 모델은 중요한 커뮤니케이션 메커니즘 (개발자들 간 소통, 유조보수 용)
프로세스 단계
- 프로세스를 이용하는 조직에 따라 좌우되는 상이한 객체 지향 설계 프로세스 존재
- 프로세스에서 공통적인 활동
  - 시스템 컨텍스트와 외부와의 상호작용 정의
  - 시스템 아키텍처 정의
  - 주요 시스템 객체 식별
  - 설계 모델 개발
  - 객체 인터페이스 명세화
시스템 컨텍스트와 상호 작용
- 설계 중인 SW와 외부 환경 간의 관계를 이해하는 것은 필요한 시스템 기능을 제공하는 방법과 그 환경과 통신하도록 시스템을 구성하는 방법을 결정하는 데 필수적
- 문맥에 대한 이해는 시스템의 경계를 설정. 시스템 경계를 설정하면 설계 중인 시스템에 어떤 특징을 구현해야 하고 다른 관련 시스템에 어떤 특징이 있는지 판단하는 데 도움이 됨

@ 197 198p

컨텍스트와 상호작용모델
- 시스템 컨텍스트 모델은 개발 중인 시스템의 주변 환경 (배경)에 있는 다른 시스템들을 보여주는 구조 모델
- 상호작용모델은 시스템이 사용될 때 어떻게 자신의 환경과 상호 작용하는지 보여주는 동적 모델
기상 관측소의 시스템 컨텍스트
기상 관측소 유스케이스
유스케이스 기술 - Report Weather
유스케이스 모델 (유스케이스 다이어그램, 유스케이스 명세서)
아키텍처 설계
- 일단 SW 시스템과 시스템 환경 간의 상호작용이 정의되면 이 정보를 시스템 아키텍처 설계를 위한 기반으로 사용
- 시스템을 구성하는 주요 컴포넌트들과 그들 간의 상호작용을 식별. 계층 또는 클라이언트-서버 모델과 같은 아키텍처 패턴을 사용하여 시스템 구조 설계
- 기상 관측소는 공통의 기반구조에 메시지를 전송하여 통신하는 독립적인 서브시스템으로 구성
기상 관측소의 상위 수준 아키텍처
데이터 수집 시스템의 아키텍처
객체 식별
- 객체 식뱔이 객체지향 설계에서 가장 어려운 부분
- 객체 식뱔의 ‘왕도’는 없고 시스템 설계자의 기술, 경험, 도메인 지식에 좌우
- 객체 식별은 반복적인 프로세스. 초기에 숙달될 수 없음.

@ 202p
@ 중요하다

객체를 식별하는 다양한 방법
1. 시스템을 자연 언어로 기술한 설명문에 문법적인 분석을 사용한다. 객체와 속성은 명상며, 연산이나 서비스는 동사이다.
2. 응용 영역에 있는 유형의 개체(사물), 관리자와 같은 역할, 요청과 같은 이벤트, 모임과 같은 상호작용, 사무실과 같은 장소, 기업과 같은 조직의 단위 등을 사용한다.
3. 설계자가 시스템의 전반적인 행동을 먼저 이해하면 행위 접근법을 사용한다. 다양한 행동이 시스템의 여러 부분에 할당되고, 이런 행동을 누가 시작하고 참여하는가에 대해 이해한다. 중요한 역할을 수행하는 참여자를 객체로 식별한다.
4. 시스템 사용에 대한 다양한 시나리오가 식별되고 분석되는 시나리오 중심 기법을 사용한다. 분석 팀은 각 시나리오를 분석하고 필요한 객체, 속성, 연산을 식별하여야 한다. 분석가와 설계자가 객체의 역할을 수행하는 CRC 카드라고 부르는 분석기법은 이런 시나리오 중심 접근법을 지원하는데 효과적이다.
CRC 카드
기상 관측소의 클래스
- 기상 관측소의 클래스 식별은 형태를 가지는 HW에 기반을 둠
  - Ground thermometer, Anemometer, Barometer
    - 시스템 장치와 관련된 ‘HW’ 객체인 App 도메인 객체
  - Weather station
    - 외부 환경과 기상 관측소와의 기본적인 인터페이스. 따라서 유스케이스 모델에서 식별된 상호 작용을 반영
  - Weather Data
    - 장치로부터 수집된 데이터를 캡슐화
기상 관측소의 클래스
클래스 다이어그램
클래스의 접근 제어자
클래스 다이어그램의 요소
- 클래스 다이어그램의 관계
설계 모델
- 객체와 클래스 및 이러한 개체 간의 관계를 나타냄
- 정적 모델
  - 시스템의 정적인 구조를 클래스와 클래스간의 관계로서 묘사한다. 이 단계에서 문서화될 수 있는 중요한 관계는 일반화 관계, 합성 관계 등이다.
- 동적 모델
  - 시스템의 동적인 구조를 묘사하고, 객체 사이의 실행시간 상호작용을 보여준다. 문서화될 수 잇는 상호작용으로는 객체에 의해 만들어지는 서비스 요청의 순서, 시스템의 상태가 상호작용과 관련된 방식 등을 들 수 있다.
기상 관측소의 예
1. 서브시스템 모델
  - 객체들을 논리적으로 그룹화하여 서브시스템으로 보여준다. 서브시스템 모델은 각 서브시스템이 패키지로 표현되는 클래스 다이어그램 형식으로 나타낸다. 서브시스템 모델은 정적 모델이다.
2. 시퀀스 모델
  - 객체 상호작용의 순서를 보여준다. 시퀀스 모델은 UML의 시퀀스 다이어그램 혹은 통신 다이어그램을 사용하여 나타낸다. 시퀀스 모델은 동적 모델이다.
  - @ 번호 X 시퀀스 다이어그램 = 번호 O 통신 다이어그램
3. 상태 기계 모델
  - 개별적인 객체가 이벤트에 응답하여 자신의 상태를 바꾸는 방법을 보여준다. UML에서 상태 기계 모델은 상태 다이어그램으로 표현된다. 상태기계모델은 동적 모델이다.
서브시스템 모델
- 어떻게 설계가 논리적으로 연관된 객체의 그룹으로 구성되는지 표현
- UML에서 패키지를 이용하여. 논리적 모델로 시스템에서 객체들의 실제 구성은 다를 수 있음
시퀀스 모델
- 시퀀스 모델은 객체 상호작용이 일어나는 순서를 표현
  - 객체나 클래스들은 그림 상단에 수평을 나열
  - 시간은 위에서 아래로 수직으로 표현
  - 상호작용은 레이블이 붙은 화살로 표현, 화살표의 유형이 상호작용의 유형을 표현
  - 객체 아래 방향을 늘어진 사각형은 실행 기간을 의미
데이터 수집을 표현하는 시퀀스 다이어그램

@ 206p 시험 X

상태 다이어그램
- 상태 다이어그램은 객체가 서로 다른 서비스 요청에 어떻게 반응하는지, 이러한 요청에 의해 트리거된 상태 전환을 보여주는 데 사용
- 상태 다이어그램은 시스템의 유용한 고수준 모델 또는 객체의 실행 시간 동작
- 일반적으로 시스템의 모든 객체에 대한 상태 다이어그램은 불필요. 왜냐하면 시스템에 있는 많은 객체는 비교적 단순하고 상태모델은 설계에 불필요한 세부사항을 추가
  - @ 단순한 프로젝트의 경우에는 필요 없다, Except 네트워크
상태 다이어그램
기상 관측소 상태 다이어그램
인터페이스 명세
- 객체 인터페이스는 개체와 다른 컴퓨터가 병행하여 설계될 수 있도록 명세화
- 데이터는 인터페이스 명세에 정의되지 않으므로 데이터 표현의 세부 사항을 포함하지 않아야 함
- 객체는 제공된 메소드에 대한 관점인 여러 인터페이스를 가질 수 있음
- UML은 인터페이스 명세를 위해 클래스 다이어그램을 사용하지만 자바도 사용가능
기상 관측소 인터페이스
액티비티 다이어그램
- 시스템 전체의 작업 흐름을 표현하는 동적 모델

중간고사 예상 문제 정리

강의노트 중심으로
SEI 역량 성숙도 모델
- 초기, 관리, 정의, 정량적 관리, 최적화
요구사항 검토 Reviews
- 증명(실제적으로 테스트), 이해(적절학 이해), 추적(출발점이 명백하게 기술), 수정(다른 요구사항 영향없이 변경 가능) 가능성
응집도 (순서?)
- 한 모듈 내부에 있는 구성 요소들 사이의 기능적 관련성을 평가하는 기준
  1. 우연적 응집도 Coincidental Cohesion
  2. 논리적 응집도 Logical Cohesion
  3. 시간적 응집도 Temporal Cohesion
  4. 절차적 응집도 Procedural Cohesion
  5. 통신적 응집도 Communicational Cohesion
  6. 순차적 응집도 Sequential Cohesion
  7. 기능적 응집도 Functional Cohesion
결합도 (순서?)
- 내용 결합도
- 공통 결합도
- 외부 결합도
- 제어 결합도
- 스탬프 결합도
- 데이터 결합도
그림 보여주고 이 아키텍처의 장단점
- 계층 아키텍처
  - 장점
    - 점증적인 개발 지원. 한 계층이 개발됨에 따라, 그 계층의 서비스 일부를 사용자가 이용할 수 있다
    - 변경, 이식 가능하다. 계층의 인터페이스가 변경되지 않는 한, 동등한 다른 계층에 의해 대체될 수 있다.
  - 단점
    - 시스템 구조화가 어려울 수 있다, 상위 수준의 서비스는 그 아래의 서비스에 접근하기 위해 인접 계층을 뚫고 지나가야 할 수도 있다. 이때 여러 수준의 명령어 해석이 필요하기 때문에 성능이 문제가 될 수 있다.
- 저장소
  - 장점
    - 공유 저장소는 다량의 데이터를 공유하는 효과적인 방식
    - 데이터를 생성하는 서브시스템은 ‘다른 시스템들이 이 데이터를 어떻게 사용하는지에 대해 알 필요’가 없다
    - 백업, 보안, 접근 제어, 오류로부터의 복구와 같은 ‘활동들을 중앙 집중화’된다
    - 합의된 데이터 모델에 적합한 새로운 도구들을 통합하는 것은 간단하다
  - 단점
    - 서브시스템들은 ‘저장소 모델에 대해 합의를 해야한다’
    - ‘합의된 데이터 모델에 맞추어 다량의 정보가 생성됨에 따라서 진화가 어려울 수 있다’
    - 상이한 서브시스템들은 보안, 복구, 백업 정책에 관해 ‘서로 다른 요구사항’을 가질 수도 있다
    - ‘저장소를 다수의 컴퓨터로 분산시키는 것은 어려울 수 있다’
- 클라이언트-서버
  - 장점
    - 분산 아키텍처, 많은 분산 프로세서를 가지는 네트워크 시스템을 효과적으로 이용할 수 있다.
    - 새로운 서버를 추가하여 시스템의 나머지와 통합하거나 시스템의 다른 부분에 영향을 주지않고 서버를 투명하게 업그레이드하는 것이 용이하다.
  - 단점
    - 새로운 서버의 통합을 위해 기본의 클라이언트와 서버에 대한 변경이 요구될 수 있다.
    - 서버 간에 공유하는 데이터 모델이 존재하지 않아 서브시스템들은 상이한 방식으로 자신들의 데이터를 구성할 수도 있다. 이것은 특정한 데이터 모델이 각 서버별로 설정되어 성능을 최적화할 수도 있다는 것은 의미한다.
- 파이프 필터
  - 장점
    - 변환의 재사용을 지원한다
    - 많은 사람들이 자신들의 작업을 입력과 출력 처리 관점에서 생각한다는 점에서 직관적이다
    - 새로운 변환을 첨가하여 시스템을 진화시키는 것이 쉽다
    - 병행 시스템이나 순차 시스템으로 구현하는 것이 간단하다
  - 단점
    - 모든 변환에 적용될 수 있는 공통적인 데이터 이동 양식이 필요하다
    - 대화식 시스템은 처리될 데이터의 스트림이 필요하기 때문에 파이프라인 모델을 사용하여 작성하기 어렵다
모델 보여주고 이 모델의 장단점
- 폭포수 모델
  - 장점
    - 가장 오래되고 폭넓게 사용되어 사례가 풍부함
    - 순차적인 프로세스이므로 전체 개발 과정이 이해하기 용이함
    - 진행 과정이 개별적으로 세분화되고, 순차적이므로 관리하기 용이함
    - 기술적 위험이 적고 적용 사례에 따른 경험이 많아, 일정 예측이 용이함
    - 산출물에 대한 관리와 적용이 용이함
  - 단점
    - 초기에 정확한 요구사항을 유도하고 확정짓기가 어려움
    - 후반부에 개발이 구체화되기 때문에 초기에 중요한 문제점을 발견하기 어려움
    - 사용자 피드백에 의한 반복 단계가 불가능
    - 초기에 사용자의 의견을 반영하기 어려움
    - 초기 단계 강조 시에 구현과 테스트가 지연될 수 있음
- 점증적 개발
  - 장점
    - 요구사항 변경을 구현하는 비용이 줄어든다
    - 이미 진행된 개발 작에 대해서는 고객의 피드백을 받기가 더 쉽다
    - 고객에게 유용한 SW를 빠르게 전달하고 배포하는 것이 가능하다
  - 단점
    - 프로세스가 보이지 않는다
    - 새로운 증분이 추가되면서 시스템 구조가 훼손되는 경향이 있다
  - 통합과 환경 설정
    - 장점
      - 원점에서 개발되는 SW가 줄어들수록 비용과 리스크가 감소
      - 시스템을 빠르게 인도하고 배치할 수 있음
    - 단점
      - 요구사항 조정이 필연적이므로 시스템이 사용자의 진정한 요구를 만족하지 못할 수 있음
      - 재사용된 시스템 요소의 진화에 대한 주도권 상실
- 컨텍스트 모델
  - 시스템이 동작하는 전체 컨텍스트 설명
  - 액티비티 다이어그램
- 상호작용 모델
  - 사용자/시스템/컴포넌트 간 상호작용 설명
  - 유스케이스 다이어글램
  - 시퀀스(순차) 다이어그램
- 구조 모델
  - 시스템을 구성ㅇ하는 컴포넌트와 컴포넌트들의 관계로 시스템을 표
  - 클래스 다이어그램
- 동작(행위) 모델
  - 실행중인 시스템의 동적 행동 모델
  - 데이터 주도 모델링
    - DFD, 액티비티 다이어그램
  - 이벤트 주도 모델링
    - 상태다이어그램
- 블록 다이어그램
  - 매우 추상적 - 엔티티 사이의 관계의 유형이나 가시적 특성 표현 못함
  - 간단함, 이해관계자와의 커뮤니케이션 및 프로젝트 계획 수립에 유용

모델의 개선
- 타이밍 다이어그램
- 패키지 다이어그램
- 컴포넌트 다이어그램
- 배치 다이어그램
- 그 외

Design Pattern

Observer 패턴
- ~
- ~
- ~
- ~
설계 문제
- 패턴을 설계에 사용하기 위해서 ~
  - ~
  - ~
  - ~
  - ~
클래스 설계 원칙
- 단일 책임 원칙 SPR
  - 하나의 클래스는 단 하나의 책임(기능)만을 가지도록 설계
- 개방 폐쇄 원칙 OCP
  - 클래스는 확장에
  - ~
  - ~
  - ~
  - ~

구현이슈
- ~

@0501

Chapter 8 소프트웨어 테스팅

개발 테스팅

개발 테스팅의 단계
- Unit Test 단위 테스팅
- 컴포넌트 테스팅
  - 여러 개별 단위가 복합 컴포넌트를 생성하기 위해 통합
  - 컴포넌트 인터페이스를 테스트하는 것에 집중
- 시스템 테스팅
  - 컴포넌트들을 통합하여 시스템 전체로서 테스트
  - 컴포넌트의 상호작용 테스트
  - 독립적인 테스트 팀의 책임
  - 테스트는 시스템 명세서에 기반함
단위 테스팅
- 결함 테스팅 Defect Testing 프로세스
클래스 테스팅
- 클래스의 완전한 테스트 범위
  - 객체와 관련된 모든 오퍼레이션들을 분리한 테스트
  - 객체와 관련된 모든속성들의 설정과 질의
  - 가능한 모든 상태에서 객체의 실행
- 상속은 시험될 정보를 지역화하지 않으므로 클래스 테스트를 더욱 어렵게 만듦

@ 기상 관측소 클래스 (객체) 인터페이스

@0503

Statement 문장 Coverage
- 모든 문장들을 한 번 이상 실행되도록 요구하는 기준
- 오류 찾을 수 없을 때도, 일반적으로 사용하기에는 미흡한 기준
Branch 분기 Coverage
- Decision 결정 Coverage
  - ‘각’ 참/거짓 분기를 1 >= 실행시키는 것이 기준, 즉 모든 분기들이 실행되도록 테스트 케이스 선정
  - 하나의 결정문이 여러 방향의 분기를 갖는다면 분기 커버리지는 모든 분기들을 커버하도록 테스트
- 체크 못하는 부분이 있다..?
Condition 조건 Coverage
- 각 결정에 대한 분기를 커버하는 분기 커버리지에 비해서 결정 내에 존재하는 각 조건들의 참/거짓을 한 번 이상 실행하도록 테스트 케이스를 작성하는 테스트 기법
- 체크 못하는 부분이 있다..?
분기 커버리지는 분기 단위
조건 커버리지는 분기 속에 여러 개 존재할 수 있는 조건 단위
결정/조건 커버리지
- 결정문 ㅐㄴ에 존재하는 각 조건들의 참과 거짓을 모두 커버하고 각 결정문의 참/거짓에 해당하는 모든 분기들이 모두 커버될 수 있도록 충분히 테스트 케이스를 만들어 나가는 기법
- 다중 조건이 포함된 결정문을 단일 조건만으로 구성되도록 변환
- 다른 조건들의 판단 결과에 상관 없이 미리 판단하는 것이 마스크 Short Circuit Evaluation
- 체크 못하는 부분이 있다..?
다중조건 커버리지 Multiple condition
- 조건과 조건 사이의 마스크 현상을 해결하기 위하여 각 결정문 내에 존재하는 조건들의 조합으로 나타날 수 있는 모든 결과를 커버할 수 있도록 테ㅡ트 데이터를 선정하는 기준
- 체크 못하는 부분이 있다..?
체크 못하는 부분이 있네
경로 기준으로 보자
블랙박스 - 명세서만 보고
화이트박스 - 문장/코드 보고 특정 부분 테스트하겟다
문장 전부, 조건 분기, 근데 그래도 테스트 못하는 부분이 있다
그래서 경로 기준으로
Basic Path 기본 경로 테스트
- 컴포넌트나 프로그램의 독립적인 경로 모두를 수행하는 것을 목적으로 하는 구조 테스트로 화이트박스 테스트 기법
- 독립적인 모든 경로가 수행되면, 모든 문장은 적어도 한 번은 모든 조건문들의 참과 거짓인 경우 모두에 대해 테스트
- 프로그램에서 경로의 소는 대개 프로그램의 크기에 비례하기 때문에, 모듈들이 시스템에 통합되면서 구조 테스트를 이용하는 것이 타당하지 않고 단위 테스트 동안 주로 이용
- 루프를 가진 프로그램에서 가능한 경로의 조합의 수는 무한하므로 프로그램의 모든 경로의 조합을 테스트할 수는 없음
- 기본 경로 테스트의 목적은 프로그램의 각 독립적인 경로가 최소한 한 번은 실ㅎ애되도록 보장하는것
사이클로매틱 복잡도의 계산
- 조건문의 수 + 1, (코드도 이 방식을 통해 계산 가능)
- 엣지의 수 - 노드의 수 + 2
- 영역의 수
프로그램의 복잡도의 척도이기도 했음
1, 2, 3, 4, 5, …
…의 의미는 경로 가능성이 무한하다는 것 (반복/중복될 수 있음)
각각의컴포넌트는 테스트를 끝냈고
컴포넌트끼리의 테스트
인터페이스 테스팅
I 오류 유형
- 매개변수 I
- 공유메모리 I
- 프로시저 I
- 메세지 전달 I
I 오류 클래스
- I 오용
- I 오해
- 타이밍 오류
I 테스팅
- I 테스팅 지침
  - 테스트될 코드를 검사하여 각각의 외부 컴포넌트 호출을 식별. 외부 컴포넌트에 전달되는 매개변수 값이 극단에 있ㄴㅡㄴ 테스트 집합으 ㄹ설계
  - I를 통해 포인터가 전달될 때 항상 널 포인터 매개변수를 가지고 I를 테스트
  - 프로시저 I를 통해 컴포넌트가 호출될 때 의도적으로 컴포넌트가 실패하는 테스트 설계
  - 메시지 전달 시스템에서 스트레스 테스팅 사용
  - 공유 메모리를 통해 여러 컴포넌트가 상호 작용하는 경우 컴포넌트가 활성화되는 순서를 바꾸도록 테스트 설계
시스템 테스팅
- 완성된 SW 시스셑ㅁ 저넻의 동작을 확인함으로써 시스템 내부에 존재하는 오류를 찾아냄
- 실제 시스템이 운영될 환경과 가장 가까운 환경으로 테스트 환경을 구축하고 명세서에 기술된 기능과 성능 등이 구현되있는지를 검사
- 시스템 테스트는 크게 기능테스트와 성능 테스트로 구분
  - 기능 테스트에서는 최종적으로 통합된 시스템이 명세서에 기술된 기능을 만족하고 있는지를 검사
  - 성능 테스트에서는 비기능적인 요구사항을 평가하기위해 실시. 성능 테스트의 유형은 스트레스 테스트, 용량, 호환성, 보안, 타이밍, 복구, 사용 편의성 테스트 등

@ 기상 데이터 수집시퀀스 다이어그램

시스템 테스팅 - 통합 테스트
- 통합 테스트의 정의
  - 통합후함께 동작하는이러한 컴포넌트들이 바르게 호출
상향식 하향식 통합 - 기사싷시험

@0508

릴리스 테스팅 : 릴리스를 테스팅 하는 것
릴리스 : 개발자의 손을 떠나 사용자에게 전달되는 SW
릴리스 포인트 : 투수 손에서 공이 때지는 순간

SW 진화 (유지보수)

SW 변경
- SW 변경은 필연적
  - SW가 사용될 때 새로운 요구사항 등장
  - 비즈니스 환경 변화 (경쟁에 의한 것도)
  - 오류 수정
  - SW 시스템에 새로운 장비 추가됨 (새로운 기기)
  - 시스템 성능, 신뢰성 향상
- 모든 조직의 주요 문제 = 기존 SW 시스템의 변경을 구현 & 관리
Evolution의 중요성
- 조직은 자신들의 SW 시스템이 막대한 투자를 했으므롤 SW 시스템은 중요한 비즈니스 자산
- 비즈니스에 이러한 자산의 가치를 유지하기 위해서는 SW 시스템은 변경 및 갱신되어야 함
- 대기업 SW 예산의 대부분은 New SW보다 기존 SW 변경하고 진화하는데 투입
Brownfield SW 개발
개발 및 진화의 나선형 모델 (설계 때도 나선인데)
진화와 서비스 제공
- 진화
  - SW 생명주기 단계에서 운영 중에 새로운 요구사항이 제안되고 시스템에 구현됨에 따라 진화가 됨
- 서비스 제공
  - 이 단계에서 SW는 유용하게 유지되지만,
- 단계적 폐기

진화 프로세스

진화 프로세스
- SW 진화 프로세스는 다음에 좌우됨

@0517

프로젝트 관리

@0522

SW 영상 강의 연습 문제 답 다 나와있는 거, 주관식으로
COCOMO ‘비용 인자의 영향’ 승수 시험문제로
임계 경로 구하는

애자일 계획 수립

@0524

Chapter 25 - 형상 관리
@ Like Github

COCOMO, PM = 비용 측정, 돈이 아니라 노력

COCOMO 81
@ 교재에서는 안다루는데, 기사 시험 같은 곳에 나와서

COCOMO 2
@ 81은 복잡도에 따라 PM 값 다름, 2는 다 똑같은
@ 서브 모델의 이용 @ App 결합 모델, 초기 설계 모델, 재사용 모델, 포스트 아키텍처 모델

학습내용
- 버전 관리
- 시스템 구축
- 변경 관리
- 릴리스 관리
형상 관리
- SW 시스템의 New 버전은 다음 경우에 작성
  - 상이한 기계나 OS를 위해
  - 상이한 기능의 제공
  - 특정 사용자 요구사항을 맞추기 위해
- 형상 관리는 진화하는 SW 시스템과 관련됨
  - 시스템 변경은 팀 단위 활동
  - 형상 관리는 시스템에 대한 변경에 포함된 비용과 노력을 관리하는 것이 목적
- 진화하는 SW 제품을 관리하기 위한 절차와 표준을 개발하는 적용하는 것을 포함
- 형상 관리는 더욱 일반적인 품질 경영 프로세스의 일부일 수 있음
- 형상 관리에 릴리스될 때, SW 시스템은 때때로 추가적인 개발의 출발점으로서 Baselines 기준선이라고 부름
- 형상 관리는 조직 내에 적용되는 표준의 집합에 항상 기초
- 표준은 항목들이 어떻게 식별되고, 변경이 어떻게 제어되며, 새로운 버전들이 어떻게 관리되는지를 정의
- 표준은 외부의 형상 관리 표준 (I.E. 형상 관리를 위한 IEEE)에 기초할 수 있음
- 일부 기존의 표준들은 폭포수 프로세스 모델에 기초하므로, 진화적인 개발을 위한 새로운 형상 관리 표준이 필요
병행 개발과 테스트
- 시스템 컴포넌트에 관한 인도 시간 (즉, 오후 2시)을 설정
- 시스템읭 새로운 버전은 이 컴포넌트를 컴파일하고 링크하여 구축
- 이 새로운 버전은 사전에 정의된 테스트를 이용하여 테스트되도록 인도
- 테스트 중에 발견된 결함은 문서화되고 시스템 개발자에게 반환됨
빈번한 시스템 구축
- 프로세스의 초기에 컴포넌트 간의 상호작용을 통해 나오는 문제를 찾기가 더 쉬움
- 이것은 단위 테스트를 통해 장려됨 - 개발자들은 ‘구축한 것을 파괴시키지’ 말아야 한다는 부담을 가짐
- 발견되고 수정된 문제들을 추적하기 위한 엄격한 변경 관리 프로세스가 요구됨
형상 관리 활동
- 형상 식별
  - ” 관리를 할 항목을 식별하는 것
- ” 제어
  - “에 대한 변경 요청이 있을 경우, 변경 여부와 변경 활동을 통제하는 것
- ” 상태 보고
  - ” 변경에 대한 내용을 기록하고 보고하는 것
- ” 감사
  - ” 항목이 요구사항에 맞도록 잘 변경 되었는지 확인하는 것

@ 교재에는 없다
@ 4가지 ? 오지선다
@ 중요해서 물어보는 게 아님

형상 관리에 대한 역할 및 책임
- 형상 담당자 Configuration Manager
  - 담장자
    - 프로젝트 팀원 중 프로젝트 ~
  - 책임
  - 수행 활동
- 형상 통제 위원회 CCB, Configuration Control Board
  - 책임
  - 담장자
  - 역할
  - 구성
형상 관리
- SW 시스템은 개발 및 사용중에 지속적으로 변경됨
- 형상 관리 CM는변화하는 SW 시스템을 관리하기 위한 정책,

TODO : Version Repository Deploy Releases

Releases 배포 개념의 릴리스, 버전 보다 작은 개념의 릴리스, 여러 의미
버전.릴리스

CM 용어 779P 알아둘 것

코드라인과 베이스라인 30ppt page 가, 나, 다 나눠서 이게 뭐야
Codeline, Baseline, Mainline

Git 리눅스 토발즈

@0531

29일 올렸던 것까지

⭐Computer, 🌚Computer-General