- 요구사항 분석의 개요
: 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구 사항을 이해하고 문서화하는 활동
-요구사항 분석 작업
1. 문제인식
: 사용자와의 면담, 설문 조사 및 협조, 각종 문서 검토등을 통하여 사용자의 요구사항 찾기
2. 평가와 종합
: 추출된 요구사항에 대한 정보를 평가하고 여러가지 해결책을 종합한다
3. 모델 제작
: 평가와 종합을 바탕으로 자료와 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해하기 쉽도록 모델로 작성한다
4. 문서화와 검토
: 요구사항 분석 명세서 작성, 소프트웨어 기능, 성능, 제약 조건등에 대하여 기술 검토
- 요구사항 분석의 여러움
1. 대화 장벽
: 사용자와 개발자의 지식 배경의 다양화, 영어 불일치 등으로 의사 소통 곤란
2. 시스템의 복잡도
: 소프트웨어 체계화를 위해 새로운 개념이 필요하지고, 시스템 규모와 대상이 광범위해짐에 따라 난이도 증가에 대한 소프트웨어의 복잡화
3. 요구의 변경
: 사용자 생각의 부정확성, 생각의 반복된 변경
4. 요구 명세화의 어려움
: 중복 현상, 애매모호함, 시험의 어려움, 과거의 다른 현재 상황등의 내포에 따라 요구 명세서 작성이 어려움
- 구조적 분석 기법
: 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec), 개체 관계도(ERD),
상태 전이도(STD), 제어 명세서 등
2. 구조적 분석 도구
1. 자료 흐름도(DFD; Data Flow Diagram) - 버블차트
: 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
: 시스템안의 프로세스, 자료 저장소 사이엥 자료의 흐름을 나타내는 그래프로 자료 흐름과 기능을 모델화하는 데 적합
- 자료 흐름도 구성 요소 표기법
2. 자료 사전(DD; Data Dictionary)
: 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이며, 이처럼 데이터를 설명하는 데이터를 데이터의 데이터 또는 메타 데이터(Meta Data)라고 한다.
3. 소단위 명세서(Mini-Spec) - 프로세스 명세서
: 세분화된 자료 흐름도에서 최하위 단계 버블(프로세스)의 처리 절차를 기술한 것으로 프로세스 명세서라고도 한다. 자료 흐름도를 지원하기 위해 작성
4. 개체 관계도(ERD; Entity Relationship Diagram)
: 시스템에서 처리되는 개체와 개체의 구성과 속성, 개체 간의 관계를 표현하여 자료를 모델화 하는데 사용
- 개체(Entity): 소프트웨어에 의해 인식되는 여러 종류의 자료
- 속성(Attribute): 개체에 관련된 특성
- 관계(Relationship): 개체 간에 존재하는 상호작용
5. 상태 전이도(STD; State Transition Diagram)
: 시스템에 어떤 일이 발생할 경우 시스템의 상태와 상태 간의 전이를 모델화 한 것으로,
: 상태 전이도를 통해 개발자는 시스템의 행위를 정의할 수 있다
: 상태 전이도에서 사각형은 시스템의 상태를, 화살표는 상태 전이를 나타낸다
3. 요구사항 분석 CASE와 HIPO
1. 요구사항 분석을 위한 CASE(자동화 도구)
: 요구사항을 자동으로 분석하고, 요구 사항 분석 명세서를 기술하도록 개발된 도구 의미
- 종류
: SADT, SREM, PSL/PSA, TAGS, EPOS
2. HIPO(Hierarchy Input Process Output)
: 시스템의 분석 및 설계를 문서화할 때 사용되는 기법으로 시스템 실행 과정인 입력, 처리, 출력 기능을 나타낸다
: 체계적인 문서 관리가 가능하고, 기호, 도표 등을 사용하므로 보기 쉽고 이해 쉽다
: 기능과 자료의 의존 관계를 동시에 표현할 수 있다. 변경, 유지 보수가 용이
: 기본 시스템 모델은 입력, 처리, 출력으로 구성
- HIPO의 종류
1. 가시적 도표(Visual Table of Contents) - 도식 목차
: 시스템의 전체적인 기능과 흐름을 보여주는 계층 구조도
2. 총체적 도표(Overview Diagram) - 총괄 도표, 개요 도표
: 프로그램을 구성하는 기능을 기술한 것, 입력, 처리, 출력을 기술
3. 세부적 도표(Detail Diagram) - 상세 도표
: 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술
4. 설계
- 구조적 설계 기법
: 구조적 분석 기법의 결과물인 자료 흐름도 등으로 부터 소프트웨어의 기능(자료 구조)와 프로그램 구조, 묘듈을 설계하기 위한 전략, 평가 지침 및 문서화 도구를 제공하는 체계화된 기법
: 자료 흐름도(DFD), 자료 사전(DD), 개체 관계도(ERD), 소단위 명세서(Mini-Spec)등이 준비된 이후에 설계한다
- 설계의 개요
: 요구사할 분석 단계의 산출물인 요구사항 분석 명세서의 기능이 실현되도록 알고리즘과 그 알고리즘에 의해 처리될 자료 구조를 문서화하는 것
1. 데이터 설계
: 요구사항 분석 단계에서 생성된 정보를 소프트웨어를 구현하는 데 필요한 자료 구조를
문서화하는 것
2. 구조(아키텍처) 설계
: 소프트웨어를 구성하는 모듈 간의 관계와 프로그램 구조를 정의하는 것
3. 인터페이스 설계
: 소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는지를 기술
4. 절차(프로시저) 설계
: 모듈이 수행할 기능을 절차적 기술로 바꾸는 것
- 설계의 기본 원리
1. 모듈화(Modularity)
: 소프트웨어를 모듈 단위로 나누는 것
: 확장성, 융통성, 경제성 등이 향상
2. 추상화(Abstraction, 개념화)
: 전체적이고 포괄적인 개념을 설계한 후 세분화하여 구체화시켜 나가는 설계 방법
: 기능 추상화, 제어 추상화, 자료 추상화
3. 단계적 정제(Stepwise Refinement)
: 하향식 설계 전략, 문제를 상위의 중요 개념으로 부터 하위의 개념으로 구체화시키는 분할기법, 추상화의 반복에 의해 세분화된다
4. 정보 은닉(Information Hiding)
: 한 모듈 내부에 포함된 절차와 자료들이 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
: 수정, 시험, 유지보수 용이
5. 프로그램 구조(Program Structure)
: 모듈의 계층적 구성을 나타내는 것, 제어 계층 구조라고도 한다. 트리구조의 다이어그램으로 표기
- 공유도(Fan-In) : 어떤 모듈을 제어(호출)하는 모듈의 수 - 위
- 제어도(Fan-Out) : 어떤 모듈에 의해 제어되는 모듈의 수 - 아래
- 깊이(Depth), 넓이(Width), 주종적 모듈(위), 종속적 모듈(아래)
- 바람직한 설계의 특징
: 독립적인 기능적 특성을 가진 요소로 구성되어야 함
: 모듈 구조, 즉 특정 기능 또는 부기능을 수행하는 논리적 요소들로 분리되는 구조를 가짐
: 요소(모듈)간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 함
: 자료와 프로시저에 대한 분명하고 분리된 표현을 포함해야 함
: 모듈간의 외부 게체 간의 연결 복잡성을 줄이는 인터페이스를 가져야 함
: 요구사항 분석에서 얻어진 정보를 이용하여 반복적인 방법으로 이루어져야 함
: 요구사항을 모두 구현해야 하고, 유지보수가 용이해야 함
: 적당한 모듈의 크기를 유지하고, 모듈 간의 상관성(결합도)는 낮추고, 응집도는 높인다
: 전체적이고 포괄적인 개념을 설계한 후 차례대로 세분화하여 구체화시켜 나간다
5. 모듈과 모듈화
- 모듈화
: 소프트웨어를 각 기능별로 분할하는 것을 의미, 각 기능별로 분할 한 것을 모듈이라고 함
- 모듈의 기능적 독립성
: 소프트웨어를 구성하는 각 모듈의 기능이 독립됨을 의미
: 모듈화, 추상화, 정보은닉의 부산물이다
: 기능적으로 독립된 모듈은 특정 기능을 수행하고, 다른 모듈과의 간단한 인터페이스만을 가지므로 개발이 쉽고 재사용이 가능
: 독립성이 높은 모듈일수록 수정하더라도 다른 묘듈에게 영향을 미치지 않으므로, 오류가 발생하더라도 쉽게 발견할 수 있고, 해결할 수 있다
: 모듈의 독립성은 결합도와 응집도에 의해 측정되며, 독립성을 높이려면 모듈의 결합도를 약하게 하고 응집도를 강하게 하며 모듈의 크기를 작게 만들어야 한다.
- 결합도(Coupling)
: 결합도는 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미
: 자료결합도 -> 스템프결합도 -> 제어결합도 -> 외부결합도 -> 공통결합도 -> 내용결합도
결합도 약함 ---------------------------------------------------------------------> 결합도 강함
* 결합도가 강해질수록 독립성은 낮아짐
- 자료 결합도(Data Coupling)
: 모듈 간의 내용을 전혀 알 필요가 없는 상태로서 한 모듈의 내용을 변경하더라도 다른 모듈에는 전혀 영향을 미치지 않는 가장 바람직한 결합도
- 스템프 결합도(Stamp Coupling)
: 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도, 자료 구조의 어떠한 변화는 그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않는 모듈에까지도 영향을 미치게 된다
- 제어 결합도(Control Coupling)
: 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어요소를 전달하는 결합도
- 외부 결합도(External Coupling)
: 외부로 선언한 데이터를 다른 모듈에서 참조할 때의 결합도
- 공통 결합도(Common Coupling)
: 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
- 내용 결합도(Content Coupling)
: 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도
- 응집도(Cohesion)
: 정보 은닉 개념을 확장한 것으로 모듈 안의 요소들이 서로 관련되어 있는 정도
: 즉, 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미
: 기능적응집도 -> 순차적응집도 -> 교환적응집도 -> 절차적응집도 -> 시간적응집도->
논리적응집도 -> 우연적응집도
- 기능적 응집도(Functional Cohesion)
: 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
- 순차적 응집도(Sequential Cohesion)
: 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력데이터로 사용할 경우 응집도
- 교환적 응집도(Communication Cohesion)
: 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성요소들이 그 기능을 순차적으로 수행할 경우의 응집도
- 절차적 응집도(Procedural Cohesion)
: 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
- 시간적 응집도(Temporal Cohesion)
: 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
- 논리적 응집도(Logical Cohesion)
: 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
- 우연적 응집도(Coincidental Cohesion)
: 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도
- 효과적인 모듈화 설계방안
: 결합도는 줄이고 응집도는 높여서 모듈의 독립성을 높인다
: 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지시킨다
: 복잡도와 중복성을 줄이고 일관성을 유지시킨다
: 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안 된다
: 유지보수가 용이해야 한다
: 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해한다
: 하나의 입구와 하나의 출구를 갖도록 해야한다
: 인덱스 번호나 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스를 설계해야 한다
6. 설계 방법
1. 자료 설계
: 설계의 첫 번째 작업으로, 요구사항 분석에서 생성된 여러 모델들을 소프트웨어를 구현하는 데 필요한 자료 구조로 변환하는 것
2. 구조 설계
: 프로그램의 구조를 개발하고, 소프트웨어 구성 요소들 간의 관계를 정의하는 것
- 구조적 설계 절차 - 나옴
: 정보 흐름의 유형설정 -> 흐름의 경계를 표시 -> 자료 흐름도를 프로그램 구조로 사상 -> 제어 계층을 분해시켜서 정의 -> 경험적 방법으로 구체화
- DFD(자료 흐름도)를 프로그램 구조로 사상시키는 방법
: 요구사항 분석에서 작성한 DFD를 프로그램 구조로 사상시키는 방법
: 변환 분해 접근법, 거래 분해 접근법
- 구조 도표(Structure Chart, 설계 구조도)
: 소프트웨어 기능을 몇 개의 고유 기능으로 분할하여 블랙 박스로 나타내고 블랙 박스 간의 인터페이스를 계층 구조로 표현한 것
3. 인터페이스 설계
: 소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는지를 기술하는 과정,
소프트웨어와 모듈 사이, 소프트웨어와 정보 생산자, 소비자 사이, 사용자 사이의 인터페이스 설계로 나눌 수 있다
- 사용자 인터페이스 설계 시 오류 메시지나 경고에 관한 지침
: 메세지 내용은 이해하기 쉬워야 한다
: 오류 회복을 위한 구체적인 설명이 제공되어야 한다
: 소리나 색 등을 이용하여 듣거나 보기 쉽도록 의미를 전달해야 한다
: 오류로 인해 발생될 수 있는 부정적인 내용은 절대 사용해서는 안된다
- 절차(프로시저) 설계
: 데이터 설계, 아키텍처 설계, 인터페이스 설계가 이루어진 후 수행되는 설계 작업으로 모듈이 수행할 기능을 절차적 기술로 바꾸는 것
**그래픽 설계 표기법 - 흐름도, N-S차트가 있다 ( 순차, 선택, 반복)
- 흐름도(FlowChart)
: 박스는 처리 단계, 다이아몬드는 논리조건, 화살표는 제어 흐름을 나타낸다
: 순차, 선택, 반복를 나타내줄 수 있다
- N-S차트(Nassi-Schneiderman Chart)
: 논리의 기술에 중점을 둔 도형을 이용한 표현 방법으로 박스 다이어그램, Chapin Chart라고도 한다
: 순차, 선택 및 다중 선택, 반복 등의 제어 논리 구조를 표현
- 프로그램 설계 언어(PDL; Program Design Language)
: 설계 언어를 이용하여 구조적 프로그래밍의 제어 구조를 기술 하는 것
: 현재 프로그래밍 언어와 유사한 서술적 표현에 의하여 프로그램, 설계, 시스템의 검토에 사용하고, 문서화 기법으로도 사용된다
7. 구현
: 구현 단계는 설계 단계에서 생성된 설계 명세서를 컴퓨터가 알 수 있는 모습으로 변환하는 과정, 프로그래밍 또는 코딩단계라고 한다.
- 프로그래밍 언어
1세대 언어: 기계어, 어셈블리어와 같은 저급언어
2세대 언어: FORTRAN, ALGOL, COBOL, BASIC
3세대 언어: 범용 언어, 인공지능용 언어, 객체지향형 언어, 실시간 시스템언어 등
4세대 언어: 비절차적 언어, 자연언어, 사용자 중심 언어, 프로토 타입 언어, 질의어
- 프로그래밍 언어 선정 기준
: 친밀감, 프로그램 구조, 언어의 능력, 프로그램 길이, 이식성, 처리의 효율성, 과거의 개발 실적, 대상 업무의 성격 등
- 코딩 스타일 = 코딩의 표준화
: 코딩 방법의 일관성을 유지하고 좋은 코딩을 위해 제시된 표준을 코딩 스타일이라고 함
: 프로그램 논리를 명확하게 작성, 지나치게 기교를 부리지 않는다.
: 수식은 간결하고 직접적으로 표현, 임시 변수의 사용은 금지
: 혼동을 초래하는 변수명은 사용하지 말고, 일관성 있는 변수명을 사용
- 구조적 프로그래밍
: 순차(Sequence), 선택(Selection), 반복(lteration)
: 순차, 선택, 반복을 사용하면 프로그램의 복잡도가 줄어들고, 유지보수가 용이
: 분기(GOTO)없이 프로그래밍하여 읽고, 테스트하기 쉽다
: 오류 없는 프로그램 구성으로 품질을 향상시킴
8. 검사 기법(Test)
: 소프트웨어 품질 보증 활동의 하나로, 소프트웨어에 대한 요구사항의 만족도 및 예상 결과와 실제 결과의 차이점을 여러 방법을 사용하여 검사하고 평가하는 일련의 과정을 의미
- 검사 기법
: 최소한의 시간과 노력으로 대부분의 오류를 찾아내기 위해 검사 사례(Test Case)를 설계
: 화이트박스 테스트, 블랙박스 테스트
<1. 화이트박스 테스트>
: 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 검사하여 검사 사례를 설계하는 방법
: 설계된 절차에 초점을 둔 구조적 테스트로, 프로시저 설계의 제어 구조를 사용하여 검사 사례를 설계
: 제어 구조에 따라 선택, 반복, 등 분기점 부분들을 수행함으로써 논리적 경로를 제어
: 기초 경로 검사, 제어 구조 검사 등
1) 기초 경로 검사 (Basic Path Testing)
: TomMcCabe가 제안 한 것으로 대표적인 화이트 박스 테스트 기법
: 검사 사례 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주고, 이 측정 결과는 실행 경로의 기초를 정의하는데 지침으로 사용
- 기초 경로 검사 절차
1. 설계나 원시 코드를 기초로 하여 흐름도를 작성
2. 흐름도의 논리적 복잡도를 측정
3. 독립 경로들의 기초 집합을 결정
4. 기초 집합의 각 경로를 실행시키는 검사 사례를 선정
* 제어 흐름도 = 제어 흐름을 표현하기 위해 사용되는 그래프
: 노드(원) = 절차적 명령문을 나타낸다
: 화살표 = 제어의 흐름
: 영역 = 화살표와 노드로 둘러싸인 구역, 외부 구역도 하나의 영역으로 포함
* 순환 복잡도 = 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도로, 제어 흐름도 이론에 기초를 둔다
: 제어 흐름도 G에서 순환 복잡도 V(G)는 다음과 같은 방법으로 계산
-> 순환 복잡도는 제어의 흐름도의 영역 수와 일치하므로 영역 수를 계산
-> V(G) = E - N + 2 (E: 화살표 수, N: 노드의 수)
2) 제어 구조 검사
1. 조건 검사(Condition Testing)
: 모듈 내에 있는 논리적 조건을 검사하는 검사 사례 설계 기법
2. 루프 검사(Loop Testing)
: 반복구조에 초점을 마추어 실시하는 검사 사례 설계 기법
3. 데이터 흐름 검사(Data Flow Testing)
: 변수의 정의와 사용 위치에 초점을 맞춰 실시하는 검사 사례 설계 기법
<2. 블랙박스 테스트> - 기능검사
: 소프트웨어가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동하는지 입증하는 검사
: 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용되며 테스트 과정 후반부에 적용
1. 동치 분할 검사(Equivalence Partitioning Testing) - 동등 분할 기법
: 입력 자료에 초점을 맞춰 검사 사례를 만들고 검사하는 방법
2. 경계값 분석(Boundary Value Analysis)
: 동치 분할 검사를 보완하기 위한 검사, 입력 조건의 경계값을 검사 사례로 선정하여 검사
3. 원인-효과 그래프 검사(Cause-Effect Graphing Testing)
: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성 높은 검사 사례를 선정하여 검사하는 기법
4. 오류 예측 검사(Fault Based Testing) = Mutation Testing
: 과거의 경험이나 확인자의 감각으로 검사, 보충적 검사 기법
5. 비교 검사(Comparison Testing)
: 여러 버전의 프로그램에 동일한 검사 자료를 제공하여 동일한 결과가 출력되는지 검사
9. 검사 전략
- 검사 단계 순서: 단위검사 -> 통합검사 -> 검증검사 -> 시스템검사
1. 단위(코드) 검사(Unit Test)
: 프로그램의 기본 단위인 모듈(코드) 수준에서 시작
: 화이트 박스 테스트 기법을 사용
2. 통합(설계) 검사(Integration Test)
: 단위 검사 후 모듈을 결합하여 전체 시스템에 대해 검사
: 비점진적 통합 방식, 점진적 통합방식
1) 비점진적 통합방식 - 빅뱅 통합 검사
: 단계적으로 통합하는 절차없이 모든 모듈이 미리 결합되어 프로그램 전체를 검하는 방법
2) 점진적 통합방식 - 하향식, 상향식, 혼합식 통합 방식
: 모듈 단위로 단계적으로 통합하면서 검사하는 방법
2-1) 하향식 통합 검사(Top Down Integration Test)
: 상의 묘듈에서 하위 묘듈 방향으로 통합하면서 검사
- 절차
: 주요 제어 모듈을 드라이버로 사용하고, 주요 제어 모듈의 종속 모듈들은 스터브로 대체
: 깊이 우선 또는 넓이 우선등의 통합 방식에 따라 종속 스터브(Stub)들이 실제 모듈로 교체
: 모듈이 통합될 때 마다 검사를 실시
: 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 심사를 실시
* 스터브(Stub) - 시험용 모듈
2-2) 상향식 통합 검사(Bottom Up Integration Test)
: 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사
- 절차
: 하위 모듈들을 클러스터(Cluster)로 결합
: 검사 사례 입, 출력을 조정하기 위해 드라이버를 작성
: 클러스터를 검사
: 드라이버를 제거하고, 클러스터는 프로그램 구조의 상위로 이동하여 결합
* 클러스터(Cluster) - 종속 모듈의 그룹
2-3) 혼합식 통합 검사 - 샌드위치식 통합 검사 방법
: 하위 수준에서는 상향식 통합, 상위수준에서는 하향식 통합을 사용
3. 검증(요구사항) 검사
: 사용자의 요구사항을 충족시키는가를 검사
1. 형상검사
: 소프트웨어 구성 요소, 목록, 유지보수를 지원하기 위해 필요한 모든 사항들이 제대로 표현되었는지 검사하는 기법
2. 알파검사
: 개발자의 장소에서 사용자가 개발자 앞에서 행사하는 검사기법, 통제된 장소(환경변화x)
3. 베타검사
: 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 검사 기법
: 실 업무를 가지고 사용자가 직접 시험하는 것
4. 시스템 검사
: 개발된 소프트웨어가 컴퓨터 시스템에서 완벽하게 수행되는지를 검사
1. 복구검사
: 올바르게 복구 되는지를 확인하는 검사
2. 보안검사
: 부적당한 침투로부터 시스템을 보호할 수 있는지를 확인하는 검사
3. 강도검사
: 비 정상적인 양, 빈도 등의 자원을 요구하는 환경에서 실행시키는 검사
4. 성능검사
: 소프트웨어의 실행 시간을 검사, 전체적인 검사
5. 디버깅(Debugging)
: 오류를 찾은 후 그 오류를 수정하는 과정
: 성공적인 테스킹의 결과로 발생
: 심리적인 요소 때문에 수행 힘듬
: 체계적인 접근 제안됨
10. 유지보수(Maintenance)
: 개발된 소프트웨어의 품질을 항상 최상의 상태로 유지하기 위한 것
: 소프트웨어 개발 단계중 가장 많은 노력과 비용이 투입되는 단계
: 유지보수의 활동의 목적은 소프트웨어의 수명을 연장시키기 위함
- 유지보수 과정
: 유지 보수 요구 -> 현 시스템에 대한 이해 -> 수정 및 시험 순으로 반복해서 일어남
- 유지보수의 비용
: 유지 보수 단계에서 필요한 비용은 소프트웨어 개발 비용중 약 70%를 차지
: 분석, 평가, 설계 변경, 코딩 등의 생산적인 활동과 프로그램과 자료 구조의 이해, 인터페이스의 특성 파악, 성능 측정 등의 실험 활동에 따라 달라질 수 있다
: 일반적으로 BL방법에 의해 산정
- 유지보수의 부작용
1. 코딩 부작용
: 코딩 내용의 변경으로 인해 발생
2. 자료 부작용
: 자료나 자료구조의 변경으로 인해 발생
3. 문서화 부작용
: 자료 코드에 대한 변경이 설계 문서나 사용자가 사용하는 메뉴얼에 적용되지 않은 경우
- 외계인 코드(Alien Code)
: 아주 오래 전에 개발되어 유지보수 작업이 매우 어려운 프로그램을 의미
: 일반적으로 15년 이전에 개발된 프로그램을 의미
- 방지 방법
: 문서화 철저
댓글 없음:
댓글 쓰기