Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/mr-won/software_engineering_finalexam

소프트웨어공학 기말고사 정리입니다.
https://github.com/mr-won/software_engineering_finalexam

cpm criticalpath software-engineering

Last synced: about 2 months ago
JSON representation

소프트웨어공학 기말고사 정리입니다.

Awesome Lists containing this project

README 

        
# Software_Engineering_Finalexam

소프트웨어공학 기말고사 정리입니다.

임계영역(Critical Path)를 구하는 문제 출제

[사이버국가고시센터](https://www.gosi.kr/)

```

시험 : 테스트 커버리지 예상문제, 수정



8장 강의노트 



결함 테스팅은 시스템 동작 중단, 시스템과의 원치 않는 상호작용, 잘못된 계산 및 데이터 손상과 바람직하지 않은 시스템 동작을 막는 것과 관련이 있음.



첫 번째 목표는 검증 테스팅 : 테스트 케이스 집합을 이용하여 시스템이 정확하게 수행되는 것을 예상

두 번째 목표는 결함 테스팅



테스트 케이스 : 테스트를 위한 케이스별 입력과 예상 결과



살충제 패러독스 : 동일한 테스트가 계속적으로 반복될 때 더 이상 새로운 버그를 발견하지 못하는 현상



블랙박스 테스팅 : 입력과 결과 테스트 케이스를 작성



검증(Verifiation) : 제품을 올바르게 만들고 있는가? product right?

소프트웨어가 명세화된 기능적, 비기능적 요구사항을 만족하는지 검사

확인(Validation) : 올바른 제품을 만들고 있는가? right product?

소프트웨어가 고객의 기대를 만족하도록 보장하는 것



V & V (검증과 확인) -> 소프트웨어 시스템이 목적과 일치한다는 신뢰성을 확보



소프트웨어 인스펙션 : 컴퓨터에서 실행시킬 필요가 없는 정적 V&V 기술

장점 : 오류 간의 상호작용에 대해 염려 X, 시스템이 비록 불완전하더라도 추가 비용없이 검사,

프로그램의 결함뿐만 아니라 표준의 준수, 호환성, 유지보수에 대해서도 검토 가능

문서 검토를 위한 정형 기법, 결함의 탐지가 목적



소프트웨어 테스트 : 컴퓨터에서 실행시키는 동적 V&V 기술

명세서와 일치하는지를 점검 가능, 고객의 실제 기대를 만족하는 가는 점검 X

성능, 유용성과 같은 비기능적 특성은 점검X



인스펙션과 테스트 모두 V&V 프로세스 동안 사용됨, 반대 성격의 검증 기술이 아님



개발 테스팅

단위(결함 테스팅) : 메소드, 클래스, 복합 컴포넌트

컴포넌트

시스템 테스팅



자동화된 테스트 컴포넌트 : 설정(테스트 케이스(입력, 예상 출력), 호출(객체, 메서드 호출), 단언 부분(호출 결과를 예상결과와 비교, 참이면 성공, 거짓이면 실패)



테스트 기법(요구사항 명세서에 기반을 둔 블랙박스 테스트와 구현에 기반을 둔 화이트박스 테스트로 구분)



블랙박스 테스트 : 소프트웨어 내부의 로직, 알고리즘을 고려하지 않고 명세서에 기술되어 있는 소프트웨어의 동작을 토대로 실시하는 테스트, 입력데이터를 제공하여 실행결과만을 관측함으로써 오류를 찾는다.

예 : 동등 분할법, 경곗값 분석법, 원인 결과 그래프 기법, 릴리스 테스팅, 기능 테스팅



동등 분할법 : 무효한 입력을 주고 무효한 입력에 대한 반응으로 일어날 예외

같은 범위에 속하는 입력 데이터에 대해 동일한 실행 결과를 얻을 수 있는 것



경곗값 분석 : 경험적으로 많은 오류가 입력 데이터의 경곗값 근처에서 발생하고 있다고 알려져 있으므로 입력데이터로 경곗값과 경곗값으로부터 조금 떨어진 값을 사용



테스트 케이스 설계 지침 : 버퍼 오버플로우가 일어나도록 설계, 같은 입력 또는 일련의 입력을 반복, 유효하지 않은 출력이 생성되도록, 계산 결과가 너무 크거나 작게 만든다.



원인 결과 그래프 : 입출력의 인과간계를 원인 결과 그래프로 표현, 



화이트박스 테스트 : 테스트 케이스를 선정하는 기준이 필요, 프로그램을 커버하는 범위를 커버리지라고 함

모든 경로를 실행하는 것이 목표지만 이를 모두 테스트하는 완전 경로 테스트는 사실상 불가능함

예로 다양한 커버리지 기법, 기본 경로 테스트 기법 등



문장 커버리지 : 프로그램 내의 모든 문장들을 한 번 이상 실행하도록 요구하는 기준

테스트케이스를 결정하는 것이 수월, 분기와 반복과 같은 경우 오류를 못찾을 수도 있음

일반적으로 사용하기에는 미흡한 기준



분기 커버리지 : 결정 커버리지 : 각 결정문의 참과 거짓인 분기를 적오도 한 번 이상 실행하는 기준



조건 커버리지 : 결정 내 존재 하는 각 조건들의 참과 거짓을 한 번 이상 실행하도록 하는 테스트 기법



결정/조건 커버리지 : and, or에 따라 조건을 미리 판단하는 마스크가 발생



다중조건 커버리지의 문제점 : 테스트 케이스의 수가 경로의 수보다 적어지는 루프 구조일 경우의 문제



기본 경로 테스트 : 독립적인 경로 모두를 수행하는 것을 목적으로 하는 구조 테스트



인터페이스 테스팅 지침, 오류 종류

매개변수 : 널 포인터 매개변수를 가지고 테스트

공유 메모리 : 컴포넌트 순서를 바꾸도록 설계 

프로시저 : 호출될 때 컴포넌트가 실패하는 테스트 설계

메시지 전달(스트레스 테스팅)



인터페이스 오류 클래스 : 인터페이스 오용, 오해, 타이밍 오류



시스템 테스팅 : 실제 시스템이 운영될 환경과 가장 가까운 환경으로 구축하고 명세서에 기술된 기능과  성능등이 구현되어 잇는지를 검사, 동작을 확인 - 크게 기능, 성능 테스트로 구분



기능 : 명세서에 기술된 기능을 만족하는가

성능 : 비기능적요구사항을 평가하기 위해 다양한 테스트를 실시

시스템 테스팅 - 통합 테스트 



통합 후 함께 동작하는 컴포넌트들이 바르게 호출되고 적절하게 데이터를 전달하는 지를 검사



하향식 통합 - 시스템의 전체 골격이 먼저 개발되고 컴포넌트들이 추가

상향식 통합 - 네트워크 및 데이터베이스 접근과 같은 공통적인 서비스를 통합하고 나서 기능 컴포넌트들을 추가



하향식 테스트의 장점과 단점을 기술하라. (하위 : 스터브)

프로그램 전체에 영향을 줄 가능성이 높은 상위 모듈 및 인터페이스의 오류를 조기 검출 가능

일부가 완성되지 않아도 프로그램 전체의 개요를 테스트 가능



단점 : 테스트의 초기 단계에서 작업의 분산화가 어렵다.



상향식 테스트의 장점과 단점을 기술하라. (상위 : 드라이버)

장점 : 초기 단계에서 병행적으로 여러 개의 모듈을 테스트 할 수 있다.



단점 : 프로그램 전체에 영향을 줄 가능성이 높은 모듈 및 인터페이스의 오류의 발견이 지연



혼합식 테스트 : 상향식, 하향식 테스트 기법을 혼합하여 각각의 장점을 결합하는 것을 목적으로 하는 테스팅 기법

기본적으로는 하향식으로 통합하고 스터브의 작성이 곤란한 부분이나 하위에 존재하는 중요한 부분에 대해서 상향식으로 모듈을 통합해서 테스트하는 방식



빅뱅 테스트 : 모든 모듈들을 개별적으로 테스트한 후에 각 모듈을 모두 한 번에 통합하는 테스팅

소규모 프로그램이나 프로그램의 일부에 대해서 실시하는 경우가 많음



점증적 통합과 테스팅 : 애자일 방법에서는 새로운 증분을 통합할 때마다 회귀 테스트 진행

회귀 테스팅(regression testing) : 프로그램의 변경으로(증분의 통합으로) 새로운 버그가 생기지 않았는지 점검하기 위해 이전의 테스트를 다시 실행, 비용이 많이 드는 기법이라 자동화도구 JUnit의 지원이 없으면 비실용적이다.



테스트 주도 개발(TDD) : 테스트는 코딩 이전에 작성되고 테스트를 통과해야만 개발이 진행됨

XP와 같은 애자일 기법의 일부로 도입, 그러나 계획 주도 개발에서도 사용될 수 있음



테스트 주도 개발(TDD)의 장점을 서술하라.

코드 커버리지 : 작성하는 모든 코드 세그먼트에 대해서 하나 이상의 테스트가 있게 됨

회귀 테스트 : 회귀 테스트 스위트는 프로그램이 개발됨에 따라 점증적으로 개발

단순화된 디버깅 : 테스트가 실패하면 문제가 있는 것이 분명하므로 디버깅 도구가 불필요

시스템 문서화 : 테스트 자체는 코드가 수행해야 하는 작업을 설명하는 문서 형식



릴리스 테스팅 : 외부에서 사용할 시스템의 특정 릴리스를 테스팅하는 프로세스

시스템이 시스템 공급자에게 확신시키는 목표이므로 오직 시스템 명세서로부터만 유도되는

블랙박스 테스팅 프로세스이며 시스템 테스팅의 한 형태이다.



릴리스 테스팅과 시스템 테스팅의 차이점을 설명하시오.

릴리스 테스팅은 시스템이 요구사항과 일치하고 고객이 사용하기에 충분하다는 것을 보장하는 확인 점검 프로세스(검증 테스팅)에 해당하고

개발팀에 의한 시스템 테스팅은 시스템에 있는 버그를 발견하는 데 집중하는 결함 테스팅이다.



요구사항 기반 테스팅 : 요구사항을 검토하여 테스트를 설계하는 것

시나리오 테스팅 : 전형적인 사용 시나리오를 만들어 이 시나리오를 테스팅 케이스르 개발하는데 사용

기능 테스팅 : 시스템이 명세서를 만족하여 고객의 신뢰를 높이도록 하는 블랙박스 테스팅, 릴리스 테스트라고도 함

성능 테스팅 : 애초에 설계된 이상으로 소프트웨어 시스템에 스트레스를 주는 것을 의미하므로 스트레스 테스팅이라고도 함, 네트워크를 기반으로 한 분산 시스템에서 특히 중요함

사용자 테스팅 : 사용자 혹은 고객은 사용자나 고객이 입력을 제공하고 시스템 테스팅에 관한 조언을 하는 테스팅 프로세스의 한 단계, 알파, 베타, 인수테스팅이 있다.



알파 : 사용자를 특정할 수 없는 경우 개발자가 사용자의 입장이 되어서 수행하는 알파 테스팅

베타 : 잠재적 사용자들 중 일부에게 시험적으로 사용해보도록 하는 베타 테스팅

인수 : 고객이 시스템을 테스트하는 인수 테스트



애자일 기법에서 고객/사용자는 개발 팀의 일원이 되어 시스템의 수용가능성에 대한 의사결정을 담당

테스트는 사용자/고객에 의해 정의된다. 고객/사용자가 이해관계자를 대표할 수 있어야 함



9장 소프트웨어 진화



브라운필드(brownfield) 소프트웨어 개발 : 오염되었거나 개발이 진행되지 않고 유휴지가 되고있는 상황

Hopkins, Jenkins는 소프트웨어 시스템이 다른 소프트웨어에 의존적인 환경에서 개발되고 관리되어야하는 상황을 나타내는 용어를 브라운 필드



변경의 식별과 진화는 시스템 사용 기간 내내 계속됨



개발과 진화의 중요한 차이를 서술하시오.

변경 구현의 첫 번째 단계는 프로그램의 이해 즉 원래의 시스템 개발자는 변경 구현에 책임이 없다.



긴급한 변경 요구가 있을 때는 어떻게 해야 하는가?

긴급한 변경은 소프트웨어 공학 프로세스의 모든 단계를 거치지 않고 구현되어야 함



진화는 빈번한 시스템 릴리스에 기반을 두는 개발 프로세스의 연속이다.



인도(Handover) 문제란 무엇인가?

개발팀이 애자일 기법을 사용했지만 진화팀은 애자일 기법이 익숙하지 않아 계획 기반 접근법을 선호하는 경우

-> 즉 개발팀과 진화팀의 기법 선호 차이를 나타냄



개발팀(애자일기법) 진화팀(계획기반)일 때

진화팀은 자동화된 테스트를 처음부터 시작, 시스템의 코드는 애자일 개발에서 예상하는 대로 리팩토링 수정되지 않을 수 있다.



개발팀(계획기반) 진화팀(애자일기법)일 때

진화팀은 진화를 위한 상세한 문서화를 기대하지만 애자일 프로세스에서는 지원되지 않음



레거시 시스템(Legacy System)

레거시 시스템은 새로운 시스템 개발에는 더 이상 사용되지 않는 언어와 기술에 의존하는 구형 시스템

사회기술적 시스템: 기술적 시스템을 사용하거나 기술적 시스템과 상호작용하는 프로세스와 사람을 포함

-> 조직의 정책과 규칙에 의해 통제됨



레거시 시스템의 계층 : 하드웨어 - 플랫폼 - 응용 - 비즈니스



레거시 시스템의 경우 교체하는 데 비용이 너무 많이 들고 리스크가 너무 크기 때문에 비즈니스에서는 이 시스템을 계속 사용한다. 



레거시 시스템 교체가 위험한 이유를 서술하라.

레거시 시스템은 완전한 명세서가 거의 없다.

비즈니스 프로세스와 레거시 시스템이 서로 밀접하게 얽혀 동작하기 때문이다.

새로운 시스템으로 교체하는 것은 본질적으로 위험이 따른다. 예상치 못한 문제, 즉 개발이

지연되거나 예산을 초과할 수 있기 때문이다.

프로그래밍 스타일에 일관성이 없다.

데이터 오류, 중복 등등



조직(회사)는 레거시 시스템을 진화시키기 위한 전략을 선택해야 한다.

시스템을 완전히 폐기하고 새로운 시스템을 대체할 것인가.

사용중이던 레거시 시스템의 유지보수를 계속할 것인가.

유지보수성을 향상시키기 위해 시스템을 대체하기 보다 변환하는 시스템 재공학을 진행할 것인가.



레거시 시스템의 분류 (품질과 비즈니스에 따른)



낮은 품질, 낮은 비즈니스 가치

-> 이 시스템은 폐기되어야 함



낮은 품질, 높은 비즈니스 가치

-> 유지보수 비용이 높음 -> 재공학되거나 적절한 시스템을 쓸 수 있으면 대체



높은 품질, 낮은 비즈니스 가치

COTS로 대체, 완전히 폐기하거나 유지



높은 품질, 높은 비즈니스 가치

정상적인 시스템 유지보수를 계속하며 계속 운영 결정.



비즈니스 가치 평가는 상이한 관점을 고려해야함 상이한 이해당사자와 인터뷰 및 결과 분석을 통한



비즈니스 가치 평가의 요소(이슈)

시스템 이용 : 가끔 사용하거나 소규모 팀이 사용한다면 비즈니스 가치는 낮다고 볼 수 있다.

지원되는 비즈니스 프로세스 : 비효율적인 비즈니스 프로세스를 이용한다면 가치는 낮다.

시스템 확실성 : 만일 시스템이 믿을 수 없어 비즈니스 고객에게 직접 영향을 주면 가치는 낮다.

시스템 출력 : 시스템의 출력에 비즈니스가 좌우된다면 시스템은 높은 비즈니스 가치를 가진다.



특이하게 시스템 출력에 의해 좌우된다면 높은 비즈니스를 가진다.

시스템 품질 평가

비즈니스 프로세스 평가 : 비즈니스 프로세스가 비즈니스의 현재 목표를 얼마나 잘 지원하는가 ?

환경 평가 : 시스템의 환경에 얼마나 효율적이고 유지하는데 얼마나 많은 비용이 소모되는가?

애플리케이션 평가 : 애플리케이션 소프트웨어의 시스템의 품질은?



비즈니스 프로세스 평가 방법

-> 시스템 이해당사자로부터 답을 찾기 위해 관점 지향 접근법을 이용



관점 지향 접근법 (Viewpoint-Oriented approach)

-> 동일한 기능을 처리하기 위해 상이한 프로세스를 이용하는가 

즉 어떤 시스템을 구현하는 데 있어서 동일한 기능(웹 기반 주문)이 이용된다면 낮은 비즈니스를 가진다고 

판단하는 것이 관점 지향 접근법



시스템 평가

시스템 변경 요구 횟수가 많을 수록 시스템의 품질이 떨어짐

인터페이스의 수가 많을수록 일관성이 없고 중복될 가능성이 있음

이용하는 데이터의 양이 증가할 수록 데이터의 일관성이 떨어지고 오류가 있을 가능성이 높음

오래된 데이터를 정리하는 일은 매우 비용이 많이 들고 시간을 소모하는 프로세스



프로그램 진화 역학



Lehman의 법칙 : 프로그램이 유용한 상태로 유지되려면 지속적으로 변경되어야 한다.

하지만 진화하는 프로그램이 변경됨에 따라 구조가 엉망이 된다.



소프트웨어 유지보수 : 사용자에게 전달된 이후의 소프트웨어 변경 프로세스가 소프트웨어 유지보수

변경은 기존 컴포넌트를 수정하고 시스템에 새로운 컴포넌트를 추가하는 것으로 구현된다.



유지보수의 유형

소프트웨어의 결함을 수리하기 위한 유지보수 -> 수정 유지보수

소프트웨어를 상이한 운영 환경에 적응하기 위한 유지보수 -> 적응 유지보수 

시스템의 기능을 추가하거나 수정하기 위한 유지보수 -> 완전 유지보수

장래의 유지보수성 혹은 신뢰성을 개선하거나 미리 예방 수단을 강구하는 유지보수 -> 예방 유지보수



수정, 적응, 완전, 예방 (비율은 완전 유지보수가 높다, 즉 새로운 기능을 추가하거나 수정하기 위한 유지보수가 제일 많은 비중을 차지 한다.)



유지보수의 비용 : 대개 개발비용보다 크다. 기술적, 비기술적 요인 모두 영향을 받는다.

유지보수를 하면 할수록 추가적인 유지보수를 더욱 어렵게 만든다.

소프트웨어의 노후성에 따라 보수 비용이 높아질 수 있음



복잡도 척도 : 제어구조, 데이터 구조, 객체, 메서드, 모듈의 크기

프로세스 척도 : 수정, 유지보수 요청 횟수, 변경 요구를 구현하는데 걸리는 평균 시간



소프트웨어 재공학 : 레거시 시스템의 일부 혹은 전체를 기능의 변경 없이 재구조화 혹은 재작성



소프트웨어 재공학의 장점을 서술하라.

새로운 소프트웨어를 개발하는 데 발생하는 인력 관리, 명세화 문제 등에서 리스크를 감소시킬 수 있다.

또한 새로운 소프트웨어를 개발하는 비용보다는 재공학 비용이 훨씬 적다.



재공학 프로세스 활동(재공학 안에 역공학이 있음)

소스코드 변환 : 코드를 새로운 언어로 변환

역공학 : 프로그램을 이해하기 위해 분석

프로그램 구조 개선 

프로그램 모듈화

데이터 재공학



리팩토링 : 변경에 따른 프로그램의 품질 저하를 늦추어 프로그램을 개선하는 프로세스

미래의 변경 문제를 예방하는 예방 유지보수로 생각할 수 있음

기능을 추가하기 보다 프로그램의 개선에 초점을 맞추어야 한다.



리팩토링과 재공학의 차이 (적용되는 시기, 상황이 다름, 리팩토링은 프로세스 전반에 걸쳐서, 재공학은 유지보수 이후 거듭된 유지보수 비용 증가를 막기 위함)

재공학은 시스템이 일정 시간 유지보수되고 나서 유지보수 비용이 증가하고 있을 때(유지보수 비용은 유지보수를 거듭할 수록 증가함) 발생한다. 유지보수성이 더 좋은 새로운 시스템으로 만들기 위해 레거시 시스템을 처리하고 재공학하는데 자동화 도구를 사용하는 것을 의미



리팩토링은 개발 및 진화 프로세스 전반에 걸쳐 개선하는 지속적인 프로세스, 유지보수 비용과 유지보수의 어려움을 증가시키는 구조 및 품질의 저하를 방지하기 위함



리팩토링과 재공학 모두 유지보수 비용을 낮추거나 유지보수성이 좋도록 개선하기 위한 방범임은 똑같다.



프로그램 코드의 악취(Bad Smell)의 예는 무엇인가?



중복 코드 : 동일하거나 매우 유사한 코드가 프로그램의 여러 곳에 포함되어 있음

-> 이렇게 중복되는 코드는 하나의 메서드나 함수로 구현하여 호출함으로써 제거



길이가 긴 메서드 : 길이가 너무 긴 메서드는 다수의 짧은 메서드들로 재설계, 분할



Switch (case) 문 : 값의 타입에 의존하는 switch문은 종종 중복을 포함하게 된다.



데이터 군집 : 데이터 항목의 동일한 그룹이 프로그램의 여러 곳에서 반복적으로 나타날 때

-> 모든 데이터를 캡슐화하는 객체로 만들어서 대체한다.



추측에 근거한 일반성 : 개발자들이 앞으로 필요한 경우를 대비하여 프로그램의 일반성을 포함할 때 발생한다.



22장 프로젝트 관리

리스크 분류 기준 : 프로젝트, 제품, 비즈니스 리스크

직원교체, 기술의 변화, 제품의 경쟁



리스크 분석 : 리스크의 발생 가능성과 심각성을 평가

리스크 관리 전략에는 어떤 것이 있는 가?

리스크 회피 전략 : 위험이 발생할 가능성을 줄임

최소화 전략 : 리스크의 영향을 줄임

리스크 비상 계획 : 최악의 경우를 대비해 준비하고, 리스크를 다루는 전략



리스크 감시(monitoring)

리스크들이 발생할 가능성이 증가 또는 감소했는지를 판단하기 위해 정기적으로 평가

리스크의 영향 정도가 변화했는 지에 대해 평가



인간 관리

인간 욕구의 계층 구조 : 생리적, 안전, 사회적 ,명예 욕구 -> 자아 실현 욕구



인간 관리의 방법의 예를 드시오.

개인에 대한 동기를 부여한다.



23장 프로젝트 계획 수립



제안서 계획 수립 단계 : 시스템 가격 설정에 사용될 정보를 제공하는 것

가격 책정에는 인건비, 하드웨어, 소프트웨어 비용 등을 고려하여 소프트웨어 개발 비용을 추정



개발 계획 수립 : 프로그램 일정, 비용 추정 및 리스크를 정기적으로 수정



프로젝트 일정관리 활동 : 프로젝트를 작업으로 나누고 각 작업을 완료하는 데 필요한 시간과 자원을 예측, 작업 종속성을 최소화하여 다른 작업이 완료되기를 기다리는 동안 발생하는 지연을 방지



일정관리 문제 : 지연된 프로젝트에 사람을 추가하는 것은 나중에 소통의 오버헤드 때문에 더 지연되게 만듬

-> Brooks의 법칙



프로젝트 액티비티(활동)

프로젝트 액티비티는 가장 기본적인 계획 수립요소

작업을 완료하기 위한 person-days 또는 person-months로 나타내는 노력 추정치

액티비티가 완료되어야 하는 마감일(deadline)

정의된 종료점



이정표(Milestone)은 프로세스 활동의 종료점

산출물(Deliverables)는 고객에게 전달되는 프로젝트 결과

폭포수 모델은 진척 사항에 관한 이정표의 직접적인 정의를 가능하게 함



임계경로(Critical Path) : 액티비티 네트워크의 가장 긴 경로

임계경로 상의 작업은 지연되면 문제가 발생하지만 T8과 같이 임계 경로 상의 작업이 아니므로 전체 일정에 무영향



바차트(간트 차트) : Slack time(여유 시간) 파란색



A-B-D-F-G-I = 7+5+4+15+12 = 43

A-B-D-H-I = 7+5+4+10 = 26



A-C-D-F-G-I = 7+10+4+15+12 = 48

A-C-D-H-I = 31



A-C-E-F-G-I = 7+10+6+15+12 = 50

A-C-E-H-I = 7+10+6+10 = 33



임계 경로 CPM = 50 (가장 긴 경로)



임계 경로가 중요한 이유 1가지 서술 : CPM 임계 경로를 구하는 방법은 작업의 개발기간을 하나의 숫자로 확정적으로 예측이 가능하다.



애자일 계획 수립 : 이터레이션(짧은 개발 주기의 반복)　: 일일 스크럼



애자일 계획 수립 단계 : 릴리스 계획 수립 : 수개월 앞을 내다보고 시스템 릴리즈에 포함되어야 하는 기능들에 대한 결정들을 함



반복 계획 수립 : 단기 전망을 가지고 시스템의 다음 증분에 대한 계획 수립에 집중



작업 할당 : 작업 계획 수립 단계 동안 개발자들이 스토리를 개발 작업으로 분할



소프트웨어 인도 : 소프트웨어 증분은 각 프로젝트 반복이 끝날 때에 항상 인도됨

증분이 허용된 시간 내에 완료될 수 없으면 작업 범위를 축소

인도 일정은 결코 연장되지 않음



추정 기법 : 소프트웨어 개발 비용(노력, 공수)를 추정할 필요가 잆음

경험에 기반한 기법 : 과거 프로젝트의 경험과 이러한 프로젝트에서 소요된 노력에 기초함

문제점 : 새로운 소프트웨어 프로젝트가 이전 프로젝트와 비슷하지 않을 때, 개발 기술이 빠르게 변화하므로 이러한 기술에 익숙하지 않을 경우, 과거의 경험은 노력 추적에 도움이 되지않고 더 어려워진다.



알고리즘 비용 산정 모델 : 노력은 관리자가 추정하는 제품, 프로젝트, 프로세스 속성의 수학 함수를 이용하여 추정됨



Effort = A *　Size의 B승 * M



A는 상수, Size는 규모 추정치, B는 비경제 반영 지수, M은 제품 프로세스 인간 속성을 반영



CoCoMo 비용 산정 모델 : Bohem에 의해 발표된 알고리즘 모델

규모는 KDSI으로 추정 

공수(Person Month) = a(KDSI)의 b승

프로젝트의 유형에 따라 적용 식이 다름



COCOMO 2는 소프트웨어 개발, 재사용 등에 상이한 접근법을 적용



초기 설계 모델 : PM = A * Size의 B승 * 승수 M(비용 인자)



A=2.94 Size->KLOC(코드규모), 지수항 B(1.1~1.24사이에서 결정), 

M(승수) : 개발자, 비기능적 요구사항, 개발 플랫폼의 친숙성 등을 반영



포스트 아키텍처 모델 : 초기 설계 모델과 동일한 식, 승수가 17개로 더 많음

코드 규모 KLOC의 추정 방식 : 코드의 라인 수(새로운 코드의 라인 수)

지수항 B -> 1.17



25장 형상 관리 



소프트웨어 시스템의 새로운 버전은 다음의 경우에 작성

1. 상이한 기계나 운영체제를 위해

2. 상이한 기능의 제공

3. 특정 사용자 요구사항에 맞추기 위해

형상관리는 진화하는 소프트웨어 시스템과 관련됨

1. 시스템 변경은 팀 단위의 활동

2. 형상 관리는 시스템에 대한 변경에 포함된 비용과 노력을 관리하는 것이 목적임

진화하는 소프트웨어 제품을 관리하기 위한 절차와 표준을 개발하고 적용하는 것을 포함

형상 관리는 더욱 일반적인 품질 경영 프로세스의 일부일 수 있음

형상 관리에 릴리스될 때, 소프트웨어 시스템은 때때로 추가적인 개발의 출발점으로써

기준점(baselines)이라고 부름



추가적인 개발의 출발점 -> 기준점(baseline) 베이스라인



형상관리 표준

형상 관리는 조직 내에 적용되는 표준의 집합에 항상 기초

표준은 항목들이 어떻게 식별되고, 변경이 어떻게 제어되며, 새로운 버전들이 어떻게 관리되는지를 정의

표준은 외부의 형상 관리 표준(예 : 형상관리를 위한 IEEE표준)에 기초할 수 있음

일부 기존의 표준들은 폭포수 프로세스 모델에 기초하므로, 진화적인 개발을 위한 새로운 형상 관리 표준이 필요



빈번한 시스템 구축

프로세스의 초기에 컴포넌트 간의 상호작용을 통해 나오는 문제를 찾기가 더 쉬움

이것은 단위 테스트를 통해 장려됨

발견되고 수정된 문제들을 추적하기 위한 엄격한 변경 관리 프로세스가 요구



형상 관리 활동

형상 식별(Identification) : 형상 관리를 할 항목을 식별하는 것

형상 제어(Control) : 형상에 대한 변경요청이 있을 경우, 변경 여부와 활동을 통제하는 것

형상 상태보고(Status Accounting) : 형상 변경에 대한 내용을 기록하고 보고하는 것

형상 감사(Audit) : 형상 항목이 요구사항에 맞도록 잘 변경되었는지를 확인하는 것



식별(Identification), 제어(Control), 상태보고(Status Accounting), 감사(Audit)



CCB 형상 통제 위원회(Configuration Control Board)



애자일 개발과 CM

하루에도 몇 번씩 컴포넌트와 시스템이 변경되는 애자일 개발은 CM 툴을 사용하지 않고는 불가능

컴포넌트의 최종 버전은 공유 프로젝트 저장소에 보관되며 개발자들은 이를 자신의 작업공간에 복사

개발자들은 코드를 변경한 다음 테스팅을 위해 시스템 구축 도구를 사용하여 자신의 컴퓨터에 새로운 시스템을 생성

일단 변경사항이 만족되면 수정된 구성요소를 프로젝트 리포지토리에 반영



멀티 버전 시스템 

대형 시스템의 경우, 단 하나의 '동작' 버전이 있는 것은 아님

서로 다른 개발 단계에서 시스템의 여러 버전이 항상 존재

상이한 시스템 버전들의 개발에 여러 팀이 관련됨



큰 번호(버전 번호), 작은 번호(릴리스 번호)

개발할 때 수정하는 건 버전번호 -> 사용자에게 릴리즈되는 번호가 다르다.

코드라인과 베이스 라인

코드라인은 소스 코드의 일련의 버전들이고, 나중 버전들은 이전의 버전들로부터 유도됨

일반적으로 코드라인은 시스템의 컴포넌트들에 적용되므로 각 컴포넌트의 상이한 버전들이 존재

베이스라인은 특정 시스템의 정의

따라서 시스템에 포함되는 컴포넌트 버전들을 명시하고 사용된 라이브러리, 설정 파일 등을 명시함

베이스라인은 시스템의 특정 버전에 어떤 컴포넌트들이 포함되어야 하는 지를 정의한 형상 언어를 사용하여 명시될 수 있음

베이스 라인은 완성된 시스템의 특정 버전을 종종 다시 생성해야 하므로 중요

예를 들어, 어떤 고객이 사용하고 있는 시스템에서 오류를 발견하고 신고하면, 수정 작업을 위해 고객에게 인도되었던 시스템 버전을 다시 생성

코드라인이 모여서 베이스라인

베이스라인이 모여서 메인라인



코드라인과 베이스라인 메인라인 그림을 채워넣는 문제 출제



코드라인

A -> A1.1 -> A1.2 -> A1.3 (Codeline A)

B -> B1.1 -> B1.2 -> B1.3 (Codeline B)

C -> C1.1 ->　C1.2 -> C1.3 (Codeline C)



라이브러리나 외부 컴포넌트

L1, L2, Ex1, Ex2



베이스라인은 이런 코드라인과 라이브러리, 외부 컴포넌트들 중에 선택해서 합치면 베이스라인



베이스라인의 묶음을 메인라인



버전 관리

버전 관리는 코드라인과 베이스라인을 관리하는 프로세스다.

버전관리는 소프트웨어 컴포넌트들과 이 컴포넌트들이 사용되는 시스템의

여러 버전들을 추적 관리하는 프로세스

또한 이런 버전들에 대해 여러 개발자들이 수행하는 변경 작업이 서로 방해받지 않도록 하는 것을 포함



버전 관리 시스템

버전 관리(VC) 시스템은 컴포넌트의 여러 버전들을 식별,저장,접근 제어를 함.

현대 버전 관리 시스템의 두가지 유형

중앙집중 시스템 : Subversion

분산 시스템 : Git

버전과 릴리즈를 식별

변경 이력 기록

독립적인 개발

프로젝트 지원

저장소 관리



공용 저장소와 개인 작업공간

컴포넌트를 수정할 때, 개발자는 컴포넌트를 저장소에서 자신의 작업공간으로 복사(check-out)하고, 이 복사본에 대해 작업을 수행

개발자가 변경 작업을 완료하면, 변경된 컴포넌트들을 저장소로 반납(check-in)

여러 사람이 동시에 한 컴포넌트에 대해 작업하면, 각각은 저장소로부터 컴포넌트에 대해 체크아웃해야 함, 만약 어떤 컴포넌트가 체크아웃되었으면, VC 시스템은 해당 컴포넌트의 체크아웃을 원하는 사용자에게 이미 누군가에 의해 체크아웃되었음을 경고



분산 버전 관리

마스터 저장소가 개발팀에 의해 생성되는 코드를 유지하는 서버에 생성

필요한 파일들의 단순한 체크아웃 대신 개발자는 프로젝트 저장소의 사본을 생성하여 자신의 컴퓨터에 설치

개발자는 자신의 컴퓨터에 설치된 개인 저장소에서 필요한 파일 작업을 수행하고, 새로운 버전을 유지

변경이 끝나면 commit을 통해 이 변경이 반영되어 개인이 저장소가 변경, 그 다음 개발자는 이 변경들이 프로젝트 저장소에 반영되도록 push

분산 버전관리의 장점

1. 저장소에 대해 백업 매커니즘을 제공

2. 네트워크 연결이 되지 않는 상황에서도 개발자들은 변경이 반영되도록 할 수 있음

3. 프로젝트 작업 지원 : 개발자들은 자신의 컴퓨터에서 전체 시스템을 컴파일하고 테스트할 수 있으며, 자신이 수행한 변경에 대한 테스트를 할 수 있음



오픈 소스 개발

분산 버전 관리는 오픈 소스 개발에 필수적

개발자들은 자신의 컴퓨터에 있는 개인 저장소뿐만 아니라 공용 서버 저장소도 유지하여, 자신들이 변경한 컴포넌트들의 새 버전들을 서버 저장소로 내보냄(push) 그 다음 언제 이런 변경들을 최종 프로젝트 저장소로 가져올지 pull 결정하는 것은 오픈 시스템의 관리자가 결정

코드라인은 분기되고 합병될 수 있다.



시스템 구축

시스템을 구성하는 소스파일이나 데이터 파일, 라이브러리들을 컴파일하고 링크해서 실행 가능한 하나의 주 시스템을 만드는 것이 시스템 구축이라고 한다.

자동화된 빌드 시스템(컴파일러, 구축 스크립트들)



개발, 구축, 타겟 플랫폼

개발할 때 사용하는 -> 개발 시스템

버전관리 및 빌드서버 -> 구축 시스템

타겟 시스템



지속적인 통합

그림을 보고 무엇을 뜻하는 가? Continueous Integretion : 지속적인 통합 

대표적인 도구로 Jenkins이 있습니다.

개발하다가 변경사항을 반영하고 구축하고 테스트한다음에 새로운 베이스라인으로 반영한다.



소스 코드와 목적 코드의 링킹



자바 파일(.java) 컴파일하면 클래스 파일이 나오는데 이 클래스 파일이

자바 파일이 수정된 자바 파일의 클래스 파일은 아니기 때문에 클래스 파일이

어떤 자바 파일의 클래스 파일인지를 알기 위해서 타임스탬프를 사용할 수 있다.

타임 스탬프(언제 컴파일되었는지)가 맞는 것이 자바 - Time Based identification

자바 - 클래스 파일마다 다른 체크섬을 비교한다. - Cheksum Based identification



변경 관리 프로세스

변경하고 나서 얻는 결과를 예측하고 비용이 많이 들어가는 변경은 줄이고 

어떤 컴포넌트가 변경되었는지를 추적하는 프로세스가 변경 관리 프로세스이다.

Change Request 변경 요청을 하면 변경을 체크하고 변경이 유효하면 변경을 등록,

소프트웨어 수정을 하는 개발 및 테스트 진행하고 변경을 적용한다.

형상관리 위원회 CCB에서 최종적으로 베이스라인에 반영할지를 결정한다.



릴리스 계획에 영향을 미치는 요인들

경쟁 : 대중 시장 소프트웨어인 경우 시장 점유 확보를 위해 릴리스

마케팅 요구 :  마케팅 부서의 요구에 맞춰서 릴리스

플랫폼 변화 : 운영체제 플랫폼의 새로운 버전의 릴리스

시스템의 기술적 변화 : 시스템의 심각한 결함이 보고



```

## 형상 관리

```

소프트웨어 시스템의 새로운 버전은 다음의 경우에 작성

1. 상이한 기계나 운영체제를 위해

2. 상이한 기능의 제공

3. 특정 사용자 요구사항에 맞추기 위해



형상관리는 진화하는 소프트웨어 시스템과 관련됨

1. 시스템 변경은 팀 단위의 활동

2. 형상 관리는 시스템에 대한 변경에 포함된 비용과 노력을 관리하는 것이 목적임



진화하는 소프트웨어 제품을 관리하기 위한 절차와 표준을 개발하고 적용하는 것을 포함

형상 관리는 더욱 일반적인 품질 경영 프로세스의 일부일 수 있음

형상 관리에 릴리스될 때, 소프트웨어 시스템은 때때로 추가적인 개발의 출발점으로써

기준점(baselines)이라고 부름



형상관리 표준



형상 관리는 조직 내에 적용되는 표준의 집합에 항상 기초

표준은 항목들이 어떻게 식별되고, 변경이 어떻게 제어되며, 새로운 버전들이 어떻게 관리되는지를 정의

표준은 외부의 형상 관리 표준(예 : 형상관리를 위한 IEEE표준)에 기초할 수 있음

일부 기존의 표준들은 폭포수 프로세스 모델에 기초하므로, 진화적인 개발을 위한 새로운 형상 관리 표준이 필요

```



## 빈번한 시스템 구축

```

프로세스의 초기에 컴포넌트 간의 상호작용을 통해 나오는 문제를 찾기가 더 쉬움

이것은 단위 테스트를 통해 장려됨

발견되고 수정된 문제들을 추적하기 위한 엄격한 변경 관리 프로세스가 요구

```



## 형상 관리 활동

```

형상 식별(Identification) : 형상 관리를 할 항목을 식별하는 것

형상 제어(Control) : 형상에 대한 변경요청이 있을 경우, 변경 여부와 활동을 통제하는 것

형상 상태보고(Status Accounting) : 형상 변경에 대한 내용을 기록하고 보고하는 것

형상 감사(Audit) : 형상 항목이 요구사항에 맞도록 잘 변경되었는지를 확인하는 것

```



## CCB 형상 통제 위원회(Configuration Control Board)



## 형상 관리(CM)

```

CM이 필요한 이유는 버전에 어떤 변경과 컴포넌트 버전에 포함되었는 지를 놓치기 쉽다.

CM은 상이한 개발자에 의해 수행된 변경을 관리하기 위해 팀 프로젝트에 필수

```



## 애자일 개발과 CM

```

하루에도 몇 번씩 컴포넌트와 시스템이 변경되는 애자일 개발은 CM 툴을 사용하지 않고는 불가능



컴포넌트의 최종 버전은 공유 프로젝트 저장소에 보관되며 개발자들은 이를 자신의 작업공간에 복사



개발자들은 코드를 변경한 다음 테스팅을 위해 시스템 구축 도구를 사용하여 자신의 컴퓨터에 새로운 시스템을 생성



일단 변경사항이 만족되면 수정된 구성요소를 프로젝트 리포지토리에 반

```



## 멀티 버전 시스템

```

대형 시스템의 경우, 단 하나의 '동작' 버전이 있는 것은 아님

서로 다른 개발 단계에서 시스템의 여러 버전이 항상 존재

상이한 시스템 버전들의 개발에 여러 팀이 관련됨

```



## 큰 번호(버전번호) 작은 번호(릴리스 번호)

```

개발할 때 수정하는 건 버전번호 -> 사용자에게 릴리즈되는 번호가 다르다.

```

## 코드라인과 베이스 라인

```

코드라인은 소스 코드의 일련의 버전들이고, 나중 버전들은 이전의 버전들로부터 유도됨



일반적으로 코드라인은 시스템의 컴포넌트들에 적용되므로 각 컴포넌트의 상이한 버전들이 존재



베이스라인은 특정 시스템의 정의



따라서 시스템에 포함되는 컴포넌트 버전들을 명시하고 사용된 라이브러리, 설정 파일 등을 명시함



베이스라인은 시스템의 특정 버전에 어떤 컴포넌트들이 포함되어야 하는 지를 정의한 형상 언어를 사용하여 명시될 수 있음



베이스 라인은 완성된 시스템의 특정 버전을 종종 다시 생성해야 하므로 중요

예를 들어, 어떤 고객이 사용하고 있는 시스템에서 오류를 발견하고 신고하면, 수정 작업을 위해 고객에게 인도되었던 시스템 버전을 다시 생



코드라인이 모여서 베이스라인

베이스라인이 모여서 메인라인

```

## 버전 관리

```

버전 관리는 코드라인과 베이스라인을 관리하는 프로세스다.

버전관리는 소프트웨어 컴포넌트들과 이 컴포넌트들이 사용되는 시스템의

여러 버전들을 추적 관리하는 프로세스

또한 이런 버전들에 대해 여러 개발자들이 수행하는 변경 작업이 서로 방해받지 않도록 하는 것을 포함

```

## 버전 관리 시스템

```

버전 관리(VC) 시스템은 컴포넌트의 여러 버전들을 식별,저장,접근 제어를 함.

현대 버전 관리 시스템의 두가지 유형



중앙집중 시스템 : Subversion

분산 시스템 : Git



버전과 릴리즈를 식별

변경 이력 기록

독립적인 개발

프로젝트 지원

저장소 관리

```

## 공용 저장소와 개인 작업공간

```

컴포넌트를 수정할 때, 개발자는 컴포넌트를 저장소에서 자신의 작업공간으로 복사(check-out)하고, 이 복사본에 대해 작업을 수행

개발자가 변경 작업을 완료하면, 변경된 컴포넌트들을 저장소로 반납(check-in)



여러 사람이 동시에 한 컴포넌트에 대해 작업하면, 각각은 저장소로부터 컴포넌트에 대해 체크아웃해야 함, 만약 어떤 컴포넌트가 체크아웃되었으면, VC 시스템은 해당 컴포넌트의 체크아웃을 원하는 사용자에게 이미 누군가에 의해 체크아웃되었음을 경고

```

## 분산 버전 관리

```

마스터 저장소가 개발팀에 의해 생성되는 코드를 유지하는 서버에 생성

필요한 파일들의 단순한 체크아웃 대신 개발자는 프로젝트 저장소의 사본을 생성하여 자신의 컴퓨터에 설치

개발자는 자신의 컴퓨터에 설치된 개인 저장소에서 필요한 파일 작업을 수행하고, 새로운 버전을 유지

변경이 끝나면 commit을 통해 이 변경이 반영되어 개인이 저장소가 변경, 그 다음 개발자는 이 변경들이 프로젝트 저장소에 반영되도록 push



분산 버전관리의 장점

1. 저장소에 대해 백업 매커니즘을 제공

2. 네트워크 연결이 되지 않는 상황에서도 개발자들은 변경이 반영되도록 할 수 있음

3. 프로젝트 작업 지원 : 개발자들은 자신의 컴퓨터에서 전체 시스템을 컴파일하고 테스트할 수 있으며, 자신이 수행한 변경에 대한 테스트를 할 수 있음

```

## 오픈 소스 개발

```

분산 버전 관리는 오픈 소스 개발에 필수적

개발자들은 자신의 컴퓨터에 있는 개인 저장소뿐만 아니라 공용 서버 저장소도 유지하여, 자신들이 변경한 컴포넌트들의 새 버전들을 서버 저장소로 내보냄(push) 그 다음 언제 이런 변경들을 최종 프로젝트 저장소로 가져올지 pull 결정하는 것은 오픈 시스템의 관리자가 결정



코드라인은 분기되고 합병될 수 있다.

```

## 시스템 구축

```

시스템을 구성하는 소스파일이나 데이터 파일, 라이브러리들을 컴파일하고 링크해서 실행 가능한 하나의 주 시스템을 만드는 것이 시스템 구축이라고 한다.



자동화된 빌드 시스템(컴파일러, 구축 스크립트들)

```

## 개발, 구축, 타겟 플랫폼

```

개발할 때 사용하는 -> 개발 시스템

버전관리 및 빌드서버 -> 구축 시스템

타겟 시스템

```

## 지속적인 통합

```

그림을 보고 무엇을 뜻하는 가? Continueous Integretion : 지속적인 통합 

대표적인 도구로 Jenkins이 있습니다.



개발하다가 변경사항을 반영하고 구축하고 테스트한다음에 새로운 베이스라인으로 반영한다.

```

## 소스 코드와 목적 코드의 링킹

```

자바 파일(.java) 컴파일하면 클래스 파일이 나오는데 이 클래스 파일이

자바 파일이 수정된 자바 파일의 클래스 파일은 아니기 때문에 클래스 파일이

어떤 자바 파일의 클래스 파일인지를 알기 위해서 타임스탬프를 사용할 수 있다.

타임 스탬프(언제 컴파일되었는지)가 맞는 것이 자바 - Time Based identification



자바 - 클래스 파일마다 다른 체크섬을 비교한다. - Cheksum Based identification

```



## 변경 관리 프로세스

```

변경하고 나서 얻는 결과를 예측하고 비용이 많이 들어가는 변경은 줄이고 

어떤 컴포넌트가 변경되었는지를 추적하는 프로세스가 변경 관리 프로세스이다.



Change Request 변경 요청을 하면 변경을 체크하고 변경이 유효하면 변경을 등록,

소프트웨어 수정을 하는 개발 및 테스트 진행하고 변경을 적용한다.



형상관리 위원회 CCB에서 최종적으로 베이스라인에 반영할지를 결정한다.

```

## 릴리스 계획에 영향을 미치는 요인들

```

경쟁 : 대중 시장 소프트웨어인 경우 시장 점유 확보를 위해 릴리스

마케팅 요구 :  마케팅 부서의 요구에 맞춰서 릴리스

플랫폼 변화 : 운영체제 플랫폼의 새로운 버전의 릴리스

시스템의 기술적 변화 : 시스템의 심각한 결함이 보고

```

## 보안성 공학

```

애플리케이션 시스템의 보안을 명세화하고 설계하는 데 초점을 맞추어 보안



사용자 및 허가 관리, 시스템 소프트웨어 배치와 유지보수, 공격 감시, 탐지 및 복구

```

## 보안 위험 관리

```

위험 평가 -> 시스템 획득 결정 이전에 시작하여 개발 프로세스 동안 계속되는 단계적 프로세스이다.



위험 평가의 단계적 프로세스 : 사전 위험 평가, 생명주기 동안의 위험 평가



사전 위험 평가 : 전체 시스템에 관한 보안 요구사항을 유도하는 것

사전 위험 평가의 필수 단계



자산 식별 -> 보호할 필요성이 있는 시스템 자산인가?



생명주기 위험 평가 : 보호되어야 할 필요성이 있는 것에 대한 더욱 상세한 정보를 알게되고

시스템의 취약점에 관해 알게 된다. 시스템 아키텍처와 데이터 구성에 관한 지식을 활용하면서

기술 선택에 관련된 취약점의 예시를 들 수 있다는 것이 사전 위험 평가와의 중요한 차이점이다.

```

## 보안을 위한 설계

```

1. 아키텍처 설계 : 어떤 아키텍처 설계 결정이 시스템의 보안에 영향을 미치는가?

2. 좋은 실무 관행(설계 지침) : 안전한 시스템을 설계할 때 받아들일 만한 좋은 실무 관행은 무엇인가?

3. 배치를 위한 설계 : 시스템이 사용을 위해 배치될 때 어떤 취약점이 있는가?



보안을 유지하는 시스템 아키텍처 설계 시 고려사항

보호 (protection) : 시스템이 어떻게 구성되어야 중요한 자산이 외부 공격에 보호될 수 있는 가?

분산 (distribution) : 시스템 자산이 어떻게 분산되어야 공격의 영향을 최소화할 수 있는 가?



계층 아키텍처 <- 중요한 자산을 낮은 수준에 두고 그 주위에 다양한 보호 계층을 두는 계층아키텍처가 

보안에 적합한 아키텍처이다.



데이터 보호가 중요한 요구사항이라면 서버에 구축된 보호 메커니즘을 가진 클라이언트-서버 아키텍처를 사용한다.



서비스 거부 공격이 주요위험이라면 애플리케이션 시스템을 위한 분산 객체 아키텍처를 사용할 수 있다.



정답 -> 계층, 클라이언터-서버, 분산 객체 아키텍처



계층마다 요구하는 수준의 보호를 두어 계층화된 보호 아키텍처를 둔다.  

애

```

## 시스템 복원성

```

시스템 복원성 : 시스템이 공격을 받았거나, 혹은 공격이나 시스템 장애의 결과로 부분적으로 손상을 입은 후 필수적인 비즈니스 중심 서비스나 임무 중심 서비스를 합법적인 사용자에게 계속적으로

제공하는 능력을 말한다.



가용성을 유지하는 것이 복원성의 핵심이다.

인식, 저항, 복구, 회복



네 단계 프로세스 : 시스템 이해, 중요한 서비스 식별, 공격 모의실험, 생존가능성 분

```

## 소프트웨어 재사용 대상

```

시스템 재사용

애플리케이션 재사

컴포넌트 재사용

객체와 함수 재사용

```

## 소프트웨어 재사용

```

대부분의 공학 분야에서, 다른 시스템에서 이용된 기존의 컴퓨터를 결합하는 방식으로 설계가 이루어짐

소프트웨어 공학은 원점에서 개발하는 것에 초점을 맞추어왔으나 현재는 체계적인 소프트웨어 재사용에 기반을 둔 설계 프로세를 채택하는 것이 필요하다는 인식을 하게 됨

```

## 소프트웨어 재사용 장점

```

소프트웨어를 재사용했을 때 얻는 장점을 서술하라.



가속화 개발

전문가의 효과적인 활용

신뢰성 증가

낮은 개발 비용

프로세스 리스크 감소

표준 준수

```



## 소프트웨어 재사용 문제점

```

컴포넌트 라이브러리의 생성, 유지보수 및 사용

재사용 컴포넌트의 검색, 이해 및 적용

유지보수 비용 증가 : 재사용되는 컴포넌트들은 바이너리코드 즉 소스코드가 없기 때문에 유지보수할 때 어려운 점이 발생한다.

지원 도구의 부족

NIH (not-invented-here) 증후군 : 부분적으로 신뢰와 관계가 있고, 부분적으로 소프트웨어를 처음부터 

작성하는 것은 다른 사의 소프트웨어를 재사용하는 것보다 더 도전적인 것으로 인식된다는 사실과 관계

(내가 개발한 건 믿는데 남이 개발한 건 찝찝하다, 신뢰의 문제가 발생)

```



## MVC 패턴 (Model View Controller)

```

사용자 입력 ->(컨트롤러 상태) -> 모델 수정(모델 상태) <-> 뷰 상태

```



## 프레임워크의 제어 역전(역행)

```

hook 메서드 -> 마우스클릭을 처리하는 메서드

이 메서드는 애플리케이션의 적절한 애플리케이션의 특화클래스를 호출하도록 설계해야 한다.



특화된 애플리케이션 컴포넌트 안에 설정 가능한 애플리케이션 컴포넌트 안에 핵심 컴포넌트

```



## 제품 라인을 위한 기반 시스템의 설정

```

도메인의 핵심, 고유한 컴포넌트 라인을 제품 라인이라고 한다.

제품 라인을 위한 기반 시스템을 설정할 때는 해당 도메인의 공통적인 핵심 컴포넌트를 설정하고

설정가능한 애플리케이션 컴포넌트, 설정 x 특화된 애플리케이션 컴포넌트

```



## 자원 관리 시스템의 아키텍처

```

자원 관리 시스템의 제품 라인은 다음과 같다.



상호작용 : 사용자 인터페이스

I/O 관리 : 사용자 인증, 자원 관리, 쿼리 관리

자원 관리 

데이터베이스 관리

```

## 제품 인스턴스 개발

```

이해당사자 요구사항 추출 -> 최적의 시스템 인스턴스의 선택 -> 요구사항재조정 or 기존 시스템 적응 -> 신규 시스템 인스턴스 제공

```