집밖은 위험해

테스트 프로세스

1. 테스트 계획

2. 테스트 분석 및 디자인

3. 테스트 케이스 및 시나리오 작성

4. 테스트 수행

5. 테스트 결과 평가 및 보고

6. 결함 추적 및 리뷰

테스트 프로세스 결과물

- 테스트 계획서 : 테스트 목적, 범위, 절차, 수행 계획

- 테스트 케이스 : 요구사항 준수 여부 확인을 위헤 입력값, 실행 조건, 예상 결과 등으로 구성한 명세서

- 테스트 시나리오 : 여러 테스트 케이스 동작 순서 정리한 문서

- 테스트 결과서 : 테스트 결과 보고

테스트 케이스 작성 순서

1. 테스트 계획 검토, 자료 확보

2. 위험 평가, 우선순위 결정

3. 테스트 요구사항 정의

4. 테스트 구조 설계, 방법 결정

5. 테스트 케이스 정의

6. 테스트 케이스 타당성 확인

결함 관리 프로세스

1. 에러 발견

2. 에러 등록

3. 에러 분석

4. 결함 확정

5. 결함 할당

6. .결함 조치

7.  결함 조치 검토

테스트 오라클

- 테스트 결과가 올바른지 정의된 값을 이용하여 확인하는 방법.

- 샘플링 오라클 : 특정 테스트 케이스 입력 값에 대한 기대 결과만 구함

- 추정 오라클 : 특정 테스트 케이스 입력 값에 대한 기대 결과 구하고, 나머지 입력은 추정값 사용.

- 참 오라클 : 모든 테스트 케이스 입력에 대해 기대 결과 제공.

- 일관성 검사 오라클 : 어플리케이션 변경시 테스트 케이스 수행 전후 결과과 일관된지 검사

테스트 자동화

- 테스트 절차를 스크립트 자동화 도구로 수행하는 것

테스트 자동화 도구 유형

- 정적 분석 도구 : 코드 실행없이 분석

- 테스트 실행 도구

- 성능 테스크 도구

- 테스크 통제 도구 : 테스트 계획, 관리, 결함 관리 등 수행

- 테스트 하네스 : 어플리케이션 컴포넌트, 모듈을 테스트하는 환경

개발 단계에 대한 어플리케이션 테스트

1. 단위 테스트

 - 모듈이나 컴포넌트 초점에 맞춰 테스트 ex) 구조기반 테스트, 명세기반 테스트

2. 통합 테스트

 - 모듈을 통합시킨 시스템 완성 중 테스트

3. 시스템 테스트

 - 사용 환경 시스템에서 기능적(블랙박스) 요구사항, 비기능적(화이트박스) 요구사항 충족 여부 확인

4. 인수 테스트

 - 사용자 요구사항 충족 여부 확인

 - 사용자 인스 테스트 : 사용자가 확인

 - 운영상 인수 테스트 : 인수 시 백업/복원, 사용자 관리 등 확인

 - 알파 테스트 : 사용자가 개발자 앞에서 하는 테스트

 - 베타 테스트 : 여러 사용자가 하는 테스트

어플리케이션 테스트

- 테스트 케이스에 따라 요구사항을 만족하는지 검증 vertification, 확인 validation

테스트 구성요소

- 테스트 프로세스 : 정착, 전략, 관리 프로세스

- 테스트 기법 : 분석, 설계, 실행, 자동화 기법

- 테스트 조직 : 관리자, 설계자, 개발자 

- 테스트 문서화 : 계획서, 결과서, 보고서, 결합목록

테스트 원칙

- 결함이 존재함을 밝히는 활동

1. 완벽한 테스트 불가능 : 모든 테스트 케이스를 테스트 할수 없음

2. 결함 집중 : 전체 모듈 중 20%에 80%결함 발생(파레토 법칙)

3. 정황 의존 : 주변 환경, 데이터로 발생

4. 오류 부재 궤변 : 오류가 안생겨도 요구사항 불만족 시 좋은 소프트웨어가 아님

5. 살충제 패러독스 : 동일한 모듈에 동일한 테스트 케이스 시 내성이 생겨 새로운 결함 발견 힘듬 ->테스트 케이스 개선

테스트 종류

1. 테스트 시각에 따른 분류

- 확인 validation 테스트 : 사용자 관점에서 요구사항 충족 확인

- 검증 vertification 테스트 : 개발자 관점에서 명세서 충족 확인

2. 실행 유무에 따른 분류

2.1 정적 테스트

 - 실행 없이 코드나 명세서를 분석하는 테스트, 초기 단계서 결함 발견 가능

 - 워크 스루 : 개발자 작업 내용을 절차대로 검사

 - 인스펙션 : 개발된 결과물 평가

2.2 동적 테스트

 - 실행하여 오류 찾는 테스트

 - 화이트 박스 테스트 : 소스 코드 흐름 테스트. 논리적 복잡성 측정하는 기초 경로 검사와 제어구조 검사

  * 제어 구조 검사 : 조건 검사, 루프 검사, 데이터 흐름 검사

 - 블랙박스 테스트 : 기능 동작 여부 확인. 경계값 분석, 동치 분할 검사, 원인효과 그래프 검사, 오류 예측 검사

  * 동치 분할 검사 : 올바른 입력과 잘못된 입력에 대한 테스트 케이스를 균등하게 사용하는 검사

3. 테스트에 따른 분류

3.1 명세 기반 테스트

 - 명세를 이용해 테스트 케이스 작성

 - 동등 분할 검사, 경계값 분석 검사

3.2 구조 기반 테스트

 - 소프트웨어 논리 흐름에 따라 테스트 케이스 작성

 - 구문 기반, 조건 기반

3.3 경험 기반 테스트

 - 테스터 경험에 의존하는 테스트

 - 체크 리스트, 에러 추정

UML Unified Modeling Language 

- 업무, 어플리케이션, 아키텍처 모델링에 사용하는 모델링 언어로 다양한 언어 코드 생성에 사용

UML 구성

- 사물, 관계, 다이어그램으로 구성

1. 사물 things

1.1 구조사물 structual 

 - UML 모델의 정적인 부분, 개념적/물리적 요소 표현. 클래스 class, 유스캐이스 use case, 컴포넌트 component, 노드

1.2 행동 사물

 - 시스템 행위. 상호작용 interaction, 상태 state

1.3 그룹 사물

 - 개념을 그룹화하는 사물. 패키지 package

1.4 어노테이션 사물

 - 부가적 개념 설명. 노트 note

2. 관계 

2.1 연관 관계 association : 다른 사물과 연관 있음

2.2 집합 관계 aggregation : 전체와 부분간 관계

2.3 포함 관계 coposition : 큰 부분이 소멸시 포함 부분도 함께 소멸됨

2.4 일반화 관계 generalization : 부모/자식 관계로 상속을 나타냄

2.5 실체화 관계 realization : 인터페이스 구현 관계

2.6 의존 관계 dependency : 한사물 변화가 타사물에 영향주는 관계

3. 다이어그램

3.1 구조적 다이어그램

- 클래스 다이어그램 : 비슷한 객체들의 그룹

- 객체 다이어그램 : 객체의 인스턴스 사이 관계

- 컴포넌트 다이어그램 : 소프트웨어 물리적 단위(exe, dll 등)의 구성과 연결상태 표현

- 배치 다이어그램 deployment diagram : 결과물, 프로세서, 하드웨어 등 물리적연결 표현

- 패키지 다이어그램 package diagram : 유스케이스나 클래스 등 모델 요소들을 그룹화한 패키지들의 관계 표현

3.2 행동 다이어그램

- 유스케이스 다이어그램 usecase : 사용자 입장에서 본 시스템

- 시퀀스 다이어그램 sequence : 객체간 메시지 시간 흐름에 따른 표현

- 상태 다이어그램 state : 객체의 상태 변화를 나타냄

- 활동 다이어그램 activity : 유스캐이스 내부나 객체 동작 중 발생활동 표현

- 커뮤니케이션 다이어그램 communication : 객체간 메시지 표현

유스케이스 

- 타원으로 표시하고 안에 유스케이스명 작성

클래스 

- 클래스 : 공통의 속성, 오퍼레이션 및 관계를 갖는 객체들의 집합

1. 클래스 정의

- 클래스 이름은 대문자로 시작, 속성과 오퍼레이션은 소문자로 시작

- 패키지와 함께 표현시 패키지명::클래스이름 -> Dog::Bulldog

2; 속성 정의

- 속성이름:속성타입[=초기값]

- 가시성 visibility : +(public), #(protected), -(private)

- 밑줄 : 해당 클래스에 유일한속성

3. 기능 정의

- 오퍼레이션이름(파라미터 리스트):리턴타입

- visibility name(parameter-list):return-type-expression

4. 가시성 visibility

- +(public) : 외부 클래스에서도 사용 가능

- #(protected) : 하위 클래스와 해당 클래스 내에서만 가능

- -(private) : 해당 클래스에서만 가능

- ~(package, default) : 패키지 내에서만 사용 가능

5. 추상 클래스 abstract class

- 추상메소드가 1개 이상 존재하는 클래스

*이탤릭체로 표기하여 추상 메소드임을 알림

객체 

- 클래스의 인스턴스

- 특정한 속성 값 가짐

- 객체 이름은 밑줄로 표현 ex) 클래스이름:객체이름

협력 collaboration

- 목적 달성하기 위한 일련의 행위

- 타원을 점선 표기, 안에 역활 내용 기입

상태

- 객체 상태를 순서로 명시

- 이벤트에 대한 객체의 반응

액티브 클래스

- 하나 이상의 프로세스나 스레드 같는 객체를 파생하는 클래스 기술

- 클래스 표기와 비슷하지만, 양옆에 세로라인 추가

컴포넌트

- 시스템을 구성하는 물리적인 단위로 독립적인 실행단위 혹은 배포단위

- 배치 컴포넌트 deployment compoenent : dll, exe 같이 실행가능한 구성요소

- 작업 결과물 컴포넌트 word product compoenent : 실행에 쓰이지않으나 개발 작업에 만들어지며, 실행 시스템 생성

  -> ex) 분석/설계 문서, 소스코드 파일, 데이터 파일

- 실행 컴포넌트 executable component : 실행 결과로 생성되는 컴포넌트로 객체, DB레코드, 파일

노드

- 물리적인 요소로 시스템 실행때 존제

- 메모리와 처리능력을 가진 자원

- 육면체로 표현하여 필요시 컴포넌트 표기

데이터 모델 Data model

- 정보들을 나타내기 위해 단순화, 추상화한 모델

- 데이터 모델 요소 : 구조, 연산, 제약조건

- 구조 : 데이터 정적 성질로 엔티티 타입과 이들 간의 관계를 명세

- 연산 : 데이터 동적 성질로 엔티티 인스턴스에 적용가능한 연산에 대한 명세

- 제약 조건 : 데이터 베이스에 저장하는 데이터가 이상이 발생하지않도록(무결) 하기 위해  사용

데이터 모델 구조

- 개체 entity : 구분, 표현하려는 정보 단위

- 속성 attribute : 데이터의 최소 단위로 열에 해당  

- 관계 relation: 개체 간 관계나 속성 간 논리적 연결

데이터 모델 제약조건

- 개체 무결성 제약조건 : 개체의 기본키에 null이 들어가선 안되며 유일해야함 

- 참조 무결성 제약조건 : 외래키는 null이나 타 개체 타입의 기본키를 참조해야함

- 도메인 무결성 제약조건 : 도메인은 범위 내 원자값을 사용해야함

데이터 모델 종류

- 개념적 데이터 모델 : 현실 세계를 반영하여 개념적으로 나타낸 모델로 대표적으로 개체-관계 모델이 있음.

- 논리적 데이터 모델 : 개념적 모델을 DBMS에서 사용하기 위한 논리적 데이터 모델로 변경한 것(파악)

- 물리적 데이터 모델 : DBMS의 특성을 고려하여 구체화한 모델로 물리적인 구조(스키마)와 제약조건 작성(세분화)

개념적 데이터 모델 요소

- 개체 : 구분, 표현하려는 정보 단위

- 개체 타입 : 정보의 형태

- 개체 인스턴스 : 하나의 정보

- 속성 : 데이터의 최소 단위로 열

- 관계 : 개체 타입이나 속성 간 관계

- 카디널리티 cardinality : 개체의 최소, 최대 범위로 대수(옵션)

- 차수 degree : 하나의 관계에 연결된 개체타입 개수

논리적 데이터 모델 요소

- 튜플 : 릴레이션의 행

- 속성 : 릴레이션의 열

- 카디널리티 : 튜플 개수

- 차수 : 속성의 개수

- 릴레이션 인스턴스 : 릴레이션이 가지는 튜플들의 집합

- 릴레이션 스키마 : 릴레이션이 가지는 속성들의 집합

- 릴레이션 = 릴레이션 인스턴스 + 릴레이션 스키마

테이블과 릴레이션의 차이

- 릴레이션 : 개체들을 나타내기위한 추상적인 개념(논리적 데이터 모델)

- 테이블 : 구체적인 표현 방법(물리적 데이터 모델)

키

- 후보키 candidate key : 유일성과 최소성을 가지는 속성 또는 속성 집합

- 슈퍼키 candidate key : 유일성을 가지는 속성 또는 속성 집합

- 기본키 primary key : 후보 키중 릴레이션을 대표하는 속성 또는 속성 집합

- 대체키 : 기본키가 아닌 후보키

- 외래키 foreign key : 타 테이블의 기본키를 참조하는 속성

시스템 모델 system model

- HW/SW 전체적 구조, 구성요소, 모듈, 인터페이스 등 규정하는 작업

- 외부/행위/구조 관점을 대표적으로 모델링하는 방법이 UML Unified Modeling Language

- 외부 관점 : 시스템 배경이나 환경

- 행위 관점 : 시스템 동작

- 구조 관점 : 시스템이나 데이터 아키텍처

시스템 모델 유형

- 데이터 흐름 모델 : 데이터가 어떻게 처리되는지

- 결합 모델 : 개체가 다른 개체와 어떻게 결합되는지

- 아키텍처 : 주로 서브 시스템 표현

- 분류 모델 :  객체들의 공통 특성 표현

- 자극 반응모델 : 이벤트에 대한 시스템 반응

컨텍스트 모델

- 요구사항 수집, 분석 단계서 시스템 범위를 설명하기 위한 모델

* 아키텍처 모델은 시스템과 타 시스템과 관계를 보여줌

시스템 컨텍스트 다이어그램 SCD System Context Diagram

- 시스템 경계를 정의하고, 구성요소 및 외부와의 연동관계 표현

- 시스템과 외부 엔티티, 인터페이스 정의

- 작업은 각 인터페이스와 관련한 기능적 요구사항과 품질 요구사항 정의

요구 공학 requirement engineering

- 요구사항을 분석, 명세화, 유지, 보수까지 모든 공정. 접근

요구공학 공정

1. 요구사항 추출 : 개발하고자하는 시스템에 대한 요구 추출

2. 분석 : 무엇을 구현할것인지 분석

3. 기술 : 분석된 요구사항을 명세화

4. 검증 : 요구사항 명세서 검증 

5. 유지 보수 : 새 요구사항 체계적 관리

요구 사항 requirement

- 시스템 기능. 사용자가 원하는 조건, 능력

요구 분석 명세서 

- 개발 초기에 사용자 요구사항 정리한 문서

요구 분석 과정

1. 사용자 요구 파악 : 면담, 문서 검토

2. 소프트웨어 목표 수립 : 요구사항 평가와 목표 수립

3. 모델링 : 자료와 제어 흐름, 기능 처리, 동작 행위 등 모델 작성

4. 요구 분석 명세서 : SRS Software Requirement Specification.  소프트웨어 기능, 성능, 제약조건 등 명세서 작성

요구사항 분석 방법

1. 구조적 분성 방법

 - 시스셈 기능 중심 구조적 분석. 프로세스 도출, 프로세스간 데이터 흐름 정의

2. 객체 지향 분석

 - 사용자 중심 시나리오 분석. 유스 케이스 모델로 구축

 - 유스케이스 실체화 과정을 통해 추출된 요구사항 분석

요구사항

1. 비기능적 요구사항

- 소프트웨어 성능, 용이성, 신뢰성, 보안 성 등 기능과 관련되지 않은 요구사항으로 개발 과정의 제약사항에 해당

 ex) 데이터 처리용량, 외부시스템과 연결, 보안 관련 준수사항

2. 기능적 요구사항

 - 소프트웨어 기능에 대한 요구사항 

 ex) 비즈니스 요구사항, 사용자 요구사항, 비즈니스 규칙

애자일 개념

- Agile(기민한, 빠르고 낭비없이 만드는 것) 개발을 가능하게 해주는 다양한 방법론 전체 말함

-> 개발 과정에서 변경사항 유연하고 빠르게 대응하는 방법론

- 큰하나를 단계별로 작은 여러개로 나누고, 작은 프로젝트를 하나씩 수행하고 테스트

- 문서 중심 산출물보다 소프트웨어 중심

애자일 특징

- 반복 점진적 개발

- 자기조직화와 교차 기능 팀 활용

- 빠르게 요구사항 반영, 프로토 타입 제작, 피드백 통한 의견 반영

- 다른 SDLC 모델과 다르게 분석과 설계를 크게 강조 안함. 구현단계를 초반에 수행

주요 에자일 방법론 종류

- SCRUM : 30일마다 동작 가능한 제품 제공하는 스프린트 중심

- XP(eXtream Programming) : 고객과 함께 2주 정도 반복 개발. 테스트와 우선개발

- Lean Software Development : 구체적 개발 프로세스 정의 없이 철학적 접근 방식 정의

- FFD(Feature Driven Developement) : 기능 중심 개발. 티처마다 2주 정도 반복 개발실시. UML

개발 방법론

- 소프트웨어 공학 원리를 소프트웨어 개발 생명 주기에 적용 -> 소프트웨어 개발방법론 = 소프트웨어 공학 + 방법론

- 시스템 개발을 위한 작업 활동, 절차, 산출물, 기법 등 정리

- 품질 높이고 납기일 준수하여 만족도를 높이기 위한 개발 방법

개발 방법론 진화 과정

60 : 대용량 계산 수단. 요구사항도 단순. 군분야에서. 기계어 사용. 개발 방법론 x

70 : 고급언어 사용. 요구사항 발생. 민간 영역으로 확대. 폭포수 방법론 탄생

80 : 대중화. 요구사항 복잡화. SDLC 개발 방법론 대두. c언어 사용

90 : 대형 프로젝트 증가. 위험관리, 요구사항 적합성, 생산성 고려. 객체지향언어 활용

00 : 웹 어플리케이션 중심 변화. 자동화 툴 발전

현대 : 고객 요구사항 + 개발자 편의성 고려한 자동화 툴. 계획부터 테스트까지 개발자 혼자 할수있는 시기

개발 방법론 특징

- 개발 단계 정의. 활동, 제품, 검증절차 각 단계 종결 기준 등 상세히 서술

- 방법과 절차 등을 공학적 방법으로 정의

개발 방법론 구성

1. 작업 절차 : 작업 단계 체계. 단계 - 활동 - 작업

2. 작업 방법 : 수행에 대한 구체적인 설명. 절차/작업방법

3. 산출물 : 단계별 산출물 목록 및 양식(설계서), 메뉴얼/설정 방법 등

4. 기법과 도구 : 기법 - 소요 기술(객체지향 모델링 기법), 도구 - 지원 도구 혹은 표준 방법(CASE)

개발 방법론 종류

1. 구조적 방법론

2, 정보공학 방법론

3. 객체지향 방법론

4. 컴포넌트 기반 방법론

1. 구조적 방법론

- 전체 시스템을 기능에 따라 분할하여 개발. 이를 통합하는 분할 방식의 방법론

 ex) 폭포수 모델

- 순차, 선택, 반복으로 프로그램 로직

- 정형화된 분석 절차에 따라 요구사항 파악하고, 도형중심 다이어그램으로 문서화

- 컨트롤 가능한 모듈로 구조화

- 장점 : 일괄 처리 소프트웨어 개발에 적합. 전형적인 접근법

- 단점 : 데이터 정보 은닉 불가. 재사용 보수성 낮음

구조적 방법론 단계별 산출물

1. 계획 : 도메인 분석서, 프로젝트 계획서

2. 분석 : DFD(Data Flow Diagram) - 프로세스들간 데이터 흐름을 표현한 도표

3. 설계 : Structure Chart - 소프트웨어 기능을 계층적으로 표현한 차트, 프로그램 사양서

2. 정보공학 방법론

- 데이터 중심 80년대 자료구조 중심 방법론. 구조적 방법론 극복

 ex) 프로토타입, 정보공학 방법론

- 기업 중심 계획, 데이터 중심 설계, 도형 산출물

- 장점 : 전략적 기회식별 및 방안 제공, 장기적 발전 허용

- 단점 : 장기간 필요, 특정 사업 영역으로부터 독립된 시스템 개발에는 부적합

정보공학 방법론 단계별 산출물

1. 계획 :도메인 분석서, 프로젝트 계획서

2. 분석 : ERD, 기능 차트, 이벤트 모델

3. 설계 단계 : 어플리케이션 구조도, 프로그램 사양서, 테이블 정의서 목록

3. 객체지향 방법론

- 소프트웨어 생명주기에 객체지향 개념 접목해 일관된 모델로 개발

- 객체, 클레스 및 이들과 관계를 식별하여 설계 모델로 변환

객체지향 방법론 원리

1. 업무 요건 정의 : 요구사항 수집 -> 업무요건 정의

2. 객체 지향 분석 : 객체 모델링 -> 동적 모델링 -> 기능 모델링

3. 객체지향 설계 : 시스템 설계 -> 객체 설계 -> 구현

4.테스트/배포 : 테스트 ->패키지 -> 프로젝트 평가

객체지향 방법론 산출물

1. 계획 : 비즈니스 프로세스, 컨셉 모델, 프로젝트 계획서

2. 분석 : 유스케이스 다이어그램, 시퀀스 다이어그램, 클래스 다이어그램

3. 설계 : 시퀀스/클래스/컴포넌트 다이어그램

객체 지향 분석

- 객체 모델링 :시스템 정적 구조. 추상화, 분류화,일반화

- 동적 모델링 : 객체 사이 변화 조사. 상태, 동작

- 기능 모델링 : 입력에 대한 처리 결과 확인

객체지향 설계와 분석

- 시스템 설계 : 시스템 구조를 서브시스템으로 분해. 성능 최적화/자원 분배 방안

- 객체 설계 :상세 내역을 모형으로 개발 상세화. 구체적 자료구조와 알고리즘 구현

- 객체 지향 구현 

4. 컴포넌트 기반 방법론 CBD

- 재사용가능한 컴포넌트 개발, 조합하여 어플리케이션 개발

- 2000년대 컴포넌트 중심 개발 방법론. Agile 방법론

- 객체지향개발방법론 개선, 인터페이스 중시, 컴포넌트 기반 재사용성 중시, 개발시간 단축

컴포넌트 기반 방법론 원리

1. 요구 분석 : 요구사항 분석

2. 분석 : 아키텍처 정의, 유스케이스 모델링

3. 설계 : UI 설계, 컴포넌트 정의/설계, DB, 테스ㅡㅌ 설계

4. 개발 : 코딩, 테스트

5. 구현 : 릴리즈, 교육

컴포넌트 기반 방법론 단계별 산출물

1. 계획 : 비즈니스 프로세스 모델, 프로젝트 모델

2. 분석 : 유스 케이스 다이어그램, 컴포넌트 다이어그램, 재사용 계획서

3. 설계 : 시퀀스 다이어그램, 클래스 다이어그램, 컴포넌트 다이어그램

컴포넌트 기반 방법론 분류

- 요소 컴포넌트 : 최소단위 컴포턴트

- 기능 컴포넌트 : 요소 컴포넌트를 결합하여 하나의 기능 구현

- 서비스 컴포넌트 : 하나의 사용자 서비스 수행하는 컴포넌트

- 어플리케이션 컴포넌트 : 여러 서비스 수행하는 시스템 컴포넌트

소프트웨어 개발 라이프 사이클 SDLC software development life cycle

- 소프트웨어 개발을 주기로 보고 수행하기 위한 프로세스 모델 과정

- 타당성 검토부터 개발, 폐기 전과정을 생명주기로 보고 정의, 단계별 체계화

소프트웨어 위기

1. 원인

- 소프트웨어가 복잡해지니까 잘 관리해서 효율적으로 개발하자

- 소프트웨어 규모 대규모화, 복잡 -> 개발 비용 증가

- 하드웨어 비용에 대해 소프트웨어 가격 증가

- 유지보수 어려움과 개발 정체 현상 

2 증상

- 예산 초과, 일정 지연, 비효율적인 소프트웨어

-> 요구사항 불만족, 관리가 어려운 코드

3. 대응 방안

- 객체 지향 프로그래밍, 캡슈로하

- 구조적 프로그래밍

- 통합 개발환경, 컴포넌트화, 프로토타이핑

- 애자일 개발 프로세스, 버그/이슈 관리 시스템, 버전 관리 시스템

- 디자인 패턴, 가비지 콜렉션, 멀티스레딩

SDLC 특성

- 프로젝트 수행 절차를 이행하기 위한 효과적 도구

- 유형, 관점, 개발 방침, 표준 정책에 따라 다양한 방법 존재

SDLC 기능

- 비용 산정, 개발 계획 수립

- 표준화 지원, 프로젝트 관리 지원

SLDC 장접

- 소프트웨어 개발 과정 통제 가능

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

- 문서화 용이

SDLC 단점

- 사용자 요구사항 변경힘듬

SDLC 프로세스

1. 요구사항 정의

- 요구사항 식별, 상세화

- 프로그램 개발을 위한 사양 작성(아키텍처, 프레임워크, 디자인 패턴)

-> 요구사항 명세화

2. 개발 단계

- 프로그래밍 및 실행 코드 생성

- 테스트 : 다양한 수준 테스트(단위/통합 등)로 검증

3. 지원 단계

- 구축 후 인수 테스트 및 교육

- 유지 보수

- 폐기

SDLC 프로세스 정리

- 정의 단계 : 타당성 검토, 요구사항 분석, 설계

- 개발 단계 : 개발, 테스트

- 지원 단계 : 설치/이행, 유지보수, 폐기

SDLC 모델 유형

1. 폭포수 모델

2. 원형 모델

3. 나선형 모델

4. 반복적 모델

5. RAD 기법 모델

6. 4세대 모델

7. 클린룸 모델

8. V모델

1. 폭포수 모델 waterfall

- 개념 정리서 구현까지 하향식 접근 방법으로 추상화 모델링

- 가장 많이 사용된 전통적 모델

- 소프트웨어 개발을 단계, 순차, 체계적 접근

- 각 단계를 철저히 매듭짓고 다음단계 진행

- 검토 validation 및 검증 vertification, 검사 test에 프로젝트 전반 품질 향상 추구

폭포수 모델 장단점

- 장점 : 복잡성이 낮고 세분화하여 관리 용이, 사례가 풍부하고 이해하기 쉬움

- 단점 : 소프트웨어가 거대화, 요구사항 구체화 힘듬. 단계마다 불필요한 문서 양산. 개발 완료 시점에서 완성 가능

2. 원형 모델 prototyping

- 고객과 원할한 의사소통을 통한 개발 모델

- 사용자 요구사항을 충분히 분석할 목적으로 시스템 핵심적인 기능 먼저 만들어 평가 후 구현하는 점진적 개발방법

=> 사용자 요구 잘 반영, 개발 중에도 유지보수 효과

- 기본적으로 폭포수 모델과 같으나 프로토 타입 과정이 추가. 요구사항 분석 잘못될시 다시 샘플 만듬

프르토타이핑 장단점

- 장점 : 사용자 요구사항 불명확시 사용 용이, 관리자 이해 용이, 제품 추적 시험 가능성 확보

- 단점 : 개발 완료로 착각하기 쉬움, 문서 작성 미흡, 과다한 요구사항 발생

프로토타이핑 프로세스

1. 요구사항 분석

2. 프로토타입 개발 - 핵심적 기능위주

3. 요구 사항 이행 확인

4. 수정 및 보완

5. 고객과 개발자가 함께 평가

3. 나선형 모델 spiral

- 소프트 웨어 기능을 나누어 점진적으로 개발하는 모델

- 개발 중 위험 최소화 하기 위해 나선을 돌면서 개발해나감

-> 리스크 최소화, 점진적 수행, 위험 부담이 큰 대형 시스템 구축에 적합

나선형 모델 장단점

- 장점 : 대규모 시스템에 적합, 위험 감소 유지보수 용이, 반복적 개발 및 테스트로 강인성 향상, 다음 사이클서 기능추가

- 단점 : 관리가 힘들고 개발 시간 장기화, 복잡한 프로세스

나선형 모델 프로세스

1. 목표 설정 planning : 목표/제약조건 설정

2. 위험 분석 risk analysis : 우성 순위 기능 선택

3. 구현 및 테스트 engineering : 선택된 기능 개발

4. 의사소통 및 다음단계 수립 evaluation : 개발 경과 평가, 요구사항 반영 수정

목표

- 소프트웨어 개발과 프로세스 적용 관련 지식을 활용하여 SW 안정성 보장, 품질 평가를 위해 case 도구 및 다양한 기법 학습

공학과 소프트웨어 정의

- 공학 : 과학적 원리 지식 도구 등으로 새로운 제품, 도구 만드는 것

- 소프트웨어 : 프로그램, 개발, 운용, 보수 전체

소프트웨어 공학

- SW 개발, 유지보수 등 생명주가 전방 체계적으로 다루는 학문

=> 좋은 SW 개발, 관리를 위함

소프트웨어 공학의 목적

1. 소프트 개발의 어려움

2. 효율적인 개발을 통한 생산성 향상

3. 고품질 소프트웨어 생산

소프트웨어 공학 구성 요소

1. 원리

2. 기법

3. 도구

4. 언어

소프트웨어 공학 영역

1. 요구공학 requirement engineering

- SW 개발에서 첫 작업

- 목표와 제약사항 확립하여 기능, 성능(user requirements 요구사항) 정의하는 과정

- 다른 시스템과의 인터페이스 등 정의하는 과정

- 비용 조건, 납기 지연, 품질 저하 방지

2. 아키텍처 architecture

- 아키텍처 구성요소와 요소 간의 관계, 시스템 기능, 속성 및 제약사항을 적절히 반영하는 구조를 조직화하여 시스템 전체적인 형태

-> 컴포넌트와 커넥터로 시스템을 분할하여 구조화하는것

3. 개발 방법론 development methodology

- 어떤 방법으로 개발할 것인가

- 구조적 방법론, 객체지양 방법론, 컴포넌트 방법론

- 개발 조직 특성 및 여건에 맞게 조정 및 재정의 될 수 있음

4. 테스팅 testing

- 오류 없는 SW 개발을 위해 수행하는 테스트 작업

- 구성 : 단위 테스팅, 통합 테스팅, 시스템 테스팅

5. 프로세스 process

- 소프트웨어 개발 및 진화에 사용되는 활동, 방법

- 요구되는 인력, 절차, 방법, 도구 들을 통합하는 수단

- 프로세스 정의방법, 관리조직, 관리 기반 구조등에 대해 연구됨

=> 소프트웨어 프로세스 특성을 설명하는 모형, 효과적인 프로세스 실현을 위한 단계적 접근 방법 명시 모델 연구

6. 형상 관리 configuration management

- 소프트웨어 구성요소에 대한 변경 관리 대상인 형상 항목을 식별해서 변경을 통제 기록함

- 형상 식별, 형상 통제, 형상 상태 확인, 형상 검사

7. 품질 quality

- 소프트 웨어 품질은 제품 품질 product quality와 프로세스 품질 process quality로 구분

- 제품 품질 : 제품 자체의 품질

- 프로세스 품질 : 소프트웨어 개발하는 프로세스가 정확하고 우수한지. 좋은 프로세스 품질은 좋은 소프트웨어 생산

- SQA, 제품 검사, 평가 모델, 국제 표준

8. 재사용 reuse

- 코드 재사용

- 응용 분야 지식

- 개발 경험

- 설계 결정

- 시스템 지식

- 요구사항 분석

- 설계, 문서

=> 코딩 단계 이전의 분석 및 설계 단계서 만들어진 산출물을 재사용하려는 노력이 계속됨

9. 프로젝트 관리 project management

- 프로젝트의 일정, 인력 및 예산 등 관리하여 프로젝트를 성공적으로 이끌기 위해 요구됨

- 프로젝트 관리 영역 : 프로젝트 통합, 범위, 일정, 비용, 품질, 인적자원, 의사소통, 위험, 조달관리

10. 정형 기법 formal method

- 수학과 논리학 기반으로 소프트웨어 시스템을 명세하거나 검증하는 기법

- 정형 논리 formal logic, 수리 논리 mathematical logic -> 정형 명세 기법, 수식 사용 -> 체계적으로 시스템 검증

11. 유지 보수 maintenance

- 고객에게 인도된 후에도 개선 목적으로 일부분 수정, 유지보수

- 수정 유지보수 : 오류 수정

- 적응 유지보수 : 새환경에서 적응할수있도록 수행

- 완전 유지보수 : 새 기능 추가, 구조 성능 개선

- 예방 유지 보수 : 잠재적인결함 예방

소프트웨어 분류

1. 관리 소프트웨어

 - 자료를 받아 가공 후 정보 제공

2. 제어 소프트웨어

 - 각종 센서를 이용하거나 기기 동작을 제어하는 소프트웨어

3. 임베디드 소프트웨어

 - 장비나 기기에 내장된 형태의 소프트웨어

소프트웨어 개발 프로세스

- 소프트웨어 제품 개발에 필요한 과정

1. 계획

2. 요구분석

3. 설계

4.. 구현

5. 테스트

6. 유지보수

1. 소프트웨어 개발 개획

- 무엇을 개발할지 결정

- 타당성 분석

- 요구사항 식별하여 시스템 정의서 문서화

- 개발 계획서 작성

2. 요구분석

- 시스템 목표 확립

- 요구사항 발견, 모델링, 명세화 과정

- 만족해야할 기능, 성능, 타 시스템과 인터페이스 규정

=> 요구 사항 분석 명세서 작성

3. 설계

- 제품의 공학적 표현

- 요구사항으로 추적

- 구현 이전에 소프트웨어 뼈대를 정의해 구현 기반 만듬

3.1 상위 설계 high level design

- 아키텍처 설계, 예비 설계, 시스템 수준 소프트웨어 구성, 컴포넌트 간 관계로 구성된 시스템 전체적인 구조

-> 구조 설계, DB 설계, 인터페이스 설계

=> 시스템 구조도, DB 설계도(ERD), 화면 및 출력물 레이아웃

3.2 하위 설계 low level design

- 모듈 설계, 상세 설계

- 각 구성요소들의 내부 구조와 행위 결정

- 구성요소의 제어와 데이터간 연결에 대한 구체적 정의

-> 컴포넌트 설계, 자료구조 설계, 알고리즘 설계

=> 절차 기반, 자료 위주,객체 지향

4. 구현

- 프로그래밍 수행

- 코딩과 디버깅

- 단위 시험 unit test 실시

- 규칙 : 높은 가독성, 간결하고 명확한 코딩

5. 테스트 test

- 소프트 내 오류 발견하여 수정하는 단계

- 테스트 절차

1. 테스트 계획

2. 테스트 케이스 설계

3. 테스트 실행 및 평가

4. 테스트 결과 분석

5. 오류 추적 및 수정

- 결과 분석 : 테스트로 얻은 값과 목표한 값 비교

-> 보고서 작성

6. 유지 보수

- 오류 수정, 환경 변화에 따른 적응, 기능 향상에 따른 요구사항 변경 고려

- 성능 개선, 하자 보수, 새 환경에 대한 이식 및 수정

소프트웨어 프로젝트

- 제품이나 서비스를 만드는데 수행해야하는 행동

- 구성요소 : 목표, 비용, 참여자, 기술, 고객, 기간 등

- 프로세스 : 소프트웨어 제품 구상 -> 제안 요청서 배포 -> 제안서 제출 -> 심사 -> 계약서 작성 -> 프로젝트 시작 및 수행 -> 프로젝트 종료 및 제품 인도

프로젝트 관리

- 프로젝트 요구사항을 만족하기 위해 지식, 기술, 툴을 프로젝트 활동에 적용

1.  프로젝트 통합 관리

 - 변경 관리를 통해 수정된 내용으로 개정된 프로젝트 정함

2. 범위 관리

 - 프로젝트 범위 정의. 검증. 통제

3. 일정 관리

 - 기간 내수행하기 위한 프로세스로. 작업 정의, 작업 순서, 작업 기간 산정, 일정 개발, 일정 통제

4. 비용 관리

 - 예산 안에서 완료하도록 요구되는 프로세스. 자원기획, 비용산정, 비용예산수립, 비용 통제

5. 프로젝트 품질 관리

 - 품질 기획, 품질 보증, 품질 통제

6. 인적 자원 관리

 - 조직 기획, 팀 확보, 팀 개발

7. 위험 관리

 - 위험 관리 기획, 위험 식별, 정성적 위험 분석, 정량적 위험 분석, 위험 대응 기획, 위험 감시 및 통제

8. 의사소통 관리

 - 의사소 소통 기획, 정보 배포, 성과 보고, 성과 정보

9. 프로젝트 조달 관리

 - 조달 기획, 권유 기획, 공급자 유치, 공급자 선정, 계약 관리, 계약 종료