단편적으로 정리 - 소프트웨어 공학

- SDLC = software development life cycle = 소프트웨어 개발 수명 주기 : 시스템을 개발하는 과정을 뜻한다.

1. 폭포수 모델 

- 단계적, 체계적, 순차적으로 개발하기. 검토하고 검증하고 테스트가 완료되어야 다음 단계를 수행할 수 있다.

2. 프로토타입 모델

- 견본을 만들어 최종 결과를 예측하는 방법.

- 요구 수집 -> 빠른 설계 -> 프로토타입 제출 -> 평가 -> 조정 -> 구현

3. 나선형 모델

- 나선을 돌 듯 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것

- 따라서 개발 중의 위험을 최대한으로 관리하고 최소화시키는데 목적을 둔다.

- 가장 현실적이고 대구모 시스템에 적합하지만, 위험이 발견되지 않으면 문제가 발생할 수 있다.

- 계획 -> 위험 분석 -> 개발 -> 평가

- HIPO = hierarchical input process output : 인풋-프로세스-아웃풋 으로 이뤄진 모듈을 계층적으로 나타낸 도표, 시스템을 분석, 설계, 문서화함

+ 가시적 도표  = 도식목차 = visual table of contents : 시스템의 전반적인 흐름을 나타내는 트리형태의 도표

+ 총체적 도표 = 개요 도표 = overview diagram : 프로그램의 기능을 기술, 입력-프로세스-아웃풋의 과정이 한눈에 들어온다

+ 세부적 도표 = 상세 도표 = detail diagram : 총체적 도표를 엄청 자세하게 기술했다.

- 하향식 소프트웨어 개발 = top-down

- 큰 그림먼저 그리기. 블랙박스들로 구성해놓고, 나중에 상세하게 설계한다. 아래 모듈을 대신 할 시험용 모듈(=stub)이 필요하다.

- 상향식 소프트웨어 개발 = bottom-up

- 작은 그림들 더해나가기. 기존 서비스들을 통합해서 써먹는데 사용될법한 기법.

- stub은 필요없다. 낮은 수준의 모듈들을 합쳐(=cluster) 제어 프로그램(=driver)으로 테스트 하면서 진행한다.

- 소프트웨어 테스트 전략

- 검사 기법

1. 화이트박스 : 기초 경로 검사, 루프 검사

2. 블랙박스 

2-1) 동치분할 검사 : 입력 데이터를 맞게 들어오는거 반, 틀리게 들어오는거 섞어서 구성하고 테스트하기

2-2) 경계값 분석 : 정입력과 오입력의 경계선 근처의 데이터들이 오류 발생 가능성이 가장 높으므로 경계값들로 테스트하기

2-3) 원인 효과 그래프 검사 : 입력 데이터들 간의 관계에서 어떤 결과가 나오는지를 자알 분석한다.

2-4) 오류 예측 검사 : 감으로 이러면 터지지 않을까? 테스트 하기.

2-5) 비교 검사 : 여러 버전의 프로그램들에 동일한 입력을 넣어 같은 결과가 나오는지 비교한다.

- 검사 과정

1. 단위 검사 = 코드 검사 = 화이트박스 

2. 통합 검사 : 단위 검사를 마친 모듈들을 합치는 과정. 모듈간에 인터페이스를 검사한다.

- 하향식 : 아래 모듈은 아직 검사안했기 때문에, 아래 모듈들을 대체할 임시모듈 (그루터기 = 스터브 = stub)이 필요하다.

- 상향식 : 하위 모듈부터 합치면서 검사한다.

3. 검증 검사 = 요구사항 검사 = 정당성 검사 : 의뢰인의 요구사항과 소프트웨어가 일치하는지 검사한다.

4. 시스템 검사 : 프로그램 외의 다른 부가요소들을 마지막으로 검사.

- 객체지향 분석

1. 럼바우의 소프트웨어 분석 기법 = OMT = object modeling technique : 소프트웨어의 구성 요소를 그래픽적으로 모델링하기.

1-1. 객체 모델링 : 분석에 사용할 객체를 정의하고, 객체간의 관계를 정함

1-2. 동적 모델링 : 상태도, 전이도 그리기

1-3. 기능 모델링 : 프로세스들 사이에서 자료들이 어떻게 처리되는지 과정을 표현, 자료 흐름도(DFD)

2. Booch 기법

- 미시적 프개발 프로세스와 거시적 프로세스를 모두 사용하는 분석 방식

3. Jacobson

- use case를 강조한대

4. Coad & Yourdon

- E-R 다이어그램 사용

- 소프트웨어 비용 산정 기법

1. LOC = line of code : 각 기능의 원시 코드 라인수로 비용을 산정한다 예측치 = ( 낙관치 + 4*기대치 + 비관치 ) / 6

- 노력 = 개빌 기간 * 투입인원

- 비용 = 노력 * 비용(월급)

- 개발 기간 = 노력 / 투입인원

- 생산성 = LOC / 노력 = 개발한 라인수 / ( 개발자 수 * 기간 )

2. COCOMO = constructive cost model

2-1) 프로젝트 분류 유형 = mode

- 조직형 = organic : 기관 내부용 소중규모의 소프트웨어, 사무 처리용, 업무용, 과학 기술 계산용

- 내장형 = embeded : 초대형 규모, 미사일 유도 시스템, 실시간 처리 시스템

- 반분리형 = semi-detached : 조직형과 내장형의 가운데, 컴파일러 인터프리터같은 유틸리티 개발용

2-2) 비용 산정 유형

- 기본형 : 소프트웨어 크기와, 프로젝트 유형으로만 비용을 산정

- 중간형 : 기본 유형에, 제품 특성, 컴퓨터 특성, 개발자 특성등의 요인이 추가

- 발전형 : 중간형을 보완해서, 개발 공정별로 자세하고 정확하게 노력을 산출하여 비용을 산정함.

3. putnam 모델

- 전 생명 주기 동안 노력의 분포를 상정하는 모델

- 이 모델로 개발된 자동화 추정 도구 = SLIM

4. 기능 점수( = FP )로 비용 추산하기

- 이 모델로 개발된 자동화 추정 도구 = ESTIMAC

- 프로젝트 일정 계획과 관련해서

- 브룩스의 법칙 : 프로젝트 중간에 새로운 인력 투입시 부작용으로 일정이 오히려 지연된다는 카더라

- 일정 계획 방법

- PERT / CPM = project evalution & review technique : 그래프로 일정 관리

- CPM network = critical path method : 노드는 작업이고, 간선은 작업간의 의존관계를 나타낸다.

- 가장 긴 경로가 크리티컬한 경로다. 이 경로상의 어떤 노드라도 늦어지면 전체 프로젝트가 늦어지므로 관리자의 관심이 필요하다.

- 유지 보수

- 유지 보수의 종류

1. 완전한 보수 : 현재 수행중인 기능 수정, 새로운 기능 추가, 전반적인 기능 개선

2. 적응적 보수 : 하드웨어나 운영체제 변경에 따른 환경변화에 적응하는 개선

3. 예방적 보수 : 미리 겁먹고 보수하기. 미래를 예방하는 수단을 강구한다.

4. 수정적 보수 = corrective : 프로그램 오류를 수정한다. 검사 단계에서 살아남은 잠재적인 오류들을 전부 수정한다.

- 바람직한 설계의 척도

- 결합도 = coupling : 모듈간에 상호 의존하는 정도

1. data coupling : 모듈간에 인터페이스가 자료 요소(매개 변수, 인수)로만 구성될 때 <

2. stamp coupling : 모듈간에 인터페이스가 배열, 레코드등의 자료구조로 구성될 때 <

3. control coupling : 어떤 모듈이 다른 모듈의 내부적 흐름을 제어하는 경우(switch, tag, flag) <

4. external coupling : 한 모듈이 외부선언한 데이터를 다른 모듈에서 참조할 때 <

5. common coupling : 공유되는 공통 데이터 영역을 여러 모듈들이 접근 <

6. content coupling : 한 모듈이 다른 모듈의 내부 기능과 내부 자료를 직접 접근할 수 있을 때

- 응집도 = cohension : 한 모듈 안의 요소들이 서로 관련되어 있는 정도. 독립적인 모듈은 응집도가 강하다.

1. 우연적 = coincidential : 모두 상관없을 정도

2. 논리적 = logical : 유사한 성격이거나 특정 형태로만 하나의 모듈이 생성될 정도

3. 시간적 = temporal : 특정 시간에 처리되는 기능들이 하나의 모듈이 될 때

4. 절차적 = procedural : 모듈의 구성요소들이 모듈의 기능들을 순차적으로 수행할 때

5. 통신적 = communicational : 동일한 입력과 출력을 사용하지만 다른 기능을 수행하는 요소들로 모듈이 이루어짐

6. 순차적 = sequential : 모듈 내에서 한 출력이 다음엔 입력으로 쓰일 때

7. 기능적 = functional : 모듈 내 모든 기능 요소들이 단일 문제와 연관되어 수행할 정도!

- ERM = entity - relation modeling = 개체 관계 모델링 : 개체들과 개체들이 어떻게 연관됐는지를 나타내는 관계로 모델링

- ER diagram : 개체-관계 다이어그램, 모델링의 결과.

- NS chart : 플로우 차트와 같은 일을 한다.

- 화살표가 없다. 입구와 출구가 하나씩이다. (순차, 반복, 선택)만으로 모든 논리를 표현한다. 네모박스로 다 표현한다!

- FP = function point = 기능점수 : 소프트웨어의 기능 갯수를 기준으로 소프트웨어의 규모를 측정하는 방법. 내부평가 + 외부평가

- 자료 흐름도 = 자료 흐름 그래프 = 버블 차트 = DFD

-  요구사항을 분석할 때 자료의 흐름 과 변화, 기능을 도형으로 기술하는 방법

- 자료 사전 = data dictionary = DD : 자료 흐름도의 자료를 설명하는 것.

= : is composed of

[ ] :  choose only one of

|   : or

+ : and

{ }: iteration of (밑에 n은 n번 이상 반복, 위에 n은 최대 n번 반복, 밑에 m 위에 n은 m에서 n번 반복

(): optional

**:comment

- CASE = computer aided software engineering : SDLC를 도와주는 컴퓨터 자원, 쏘공의 여러 작업들을 컴퓨터로 자동화하였다.

- 정보저장소 : 처음에는 사람이 다 관리했지만, 요즘엔 디비로 정보저장소를 만들고 관리할 수 있다.

- FTR = formal technical review = 정형 기술검토 : 무슨 위원회처럼 소프트웨어를 평가하는 자리. 참가인원이 제한되고 제품검토에 집중한다.

- CORBA = common object request broker architecture = 공통 객체 요구 매개자 구조

- 프로그램내 객체 간의 메소드 호출에 대한 지침

- 소프트웨어 위험의 특성 = 불확실성, 손실가능