■ 유지보수의 유형
- 수정(Corrective) 보수 = 수리 · 교정 · 정정 · 하자 보수 : 시스템을 운영하면서 검사 단계에서 발견하지 못한 오류를 찾아 수정하는 활동
- 적응(Adaptive) 보수 = 환경 적응, 조정 보수 : 소프트웨어의 수명 기간 중에 발생하는 환경의 변화(하드웨어, 운영체제 등)를 기존의 소프트웨어에 반영하기 위하여 수행하는 활동
- 완전화(Perfective) 보수 = 기능 개선, 기능 보수 : 소프트웨어의 본래 기능에 새로운 기능을 추가하거나 성능을 개선하기 위해 소프트웨어를 확장시키는 활동으로, 유지보수 활동 중 가장큰 업무 및 비용을 차지하는 활동임
- 예방(Preventive) 보수 : 미래에 유지보수를 용이하게 하거나 기능을 향상시키기 위해 소프트웨어를 변경하는 활동
■ 화이트 박스 테스트
- 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 검사하여 검사 사례를 설계하는 방법이다.
- 설계된 절차에 초점을 둔 구조적 테스트로, 프로시저(절차) 설계의 제어 구조를 사용하여 검사 사례를 설계하며, 테스트 과정의 초기에 적용된다.
- 모듈 안의 작동을 직접 관찰한다.
- 원시 코드(모듈)의 모든 문장을 한 번 이상 수행함으로써 수행된다.
- 프로그램 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어한다.
- 각 조건에서의 참과 거짓의 모든 논리적 결정이 적어도 한 번 이상 실행된다.
- 종류 : 기초 경로 검사, 제어 구조 검사(조건 검사, 루프 검사, 데이터 흐름 검사) 등
■ 블랙 박스 테스트
- 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 검사로서, 기능 검사라고도 한다.
- 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용되며 테스트 과정의 후반부에 적용된다.
- 소프트웨어 산물의 각 기능별로 적절한 정보 영역(입 · 출력)을 정하여 적합한 입력에 대한 출력의 정확성을 점검한다.
- 종류 : 동치 분할 검사, 경계값 분석, 원인-효과 그래프 검사, 오류 예측 검사, 비교 검사 등
■ 블랙 박스 기법
- 동치 분할 검사(Equivalence Partitioning Testing) : 입력 자료에 초점을 맞춰 검사 사례를 만들고 검사하는 방법으로 동등 분할 기법이라고도 함
- 경계값 분석(Boundary Value Analysis) : 입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법
- 원인-효과 그래프 검사(Cause-effect graphing testing) : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성 높은 검사 사례를 선정하여 검사하는 기법
- 오류 예측 검사(Fault based testing) = Multation Testing : 과거의 경험이나 확인자의 감각으로 검사하는 기법
- 비교 검사(Comparison Testing) : 여러 버전의 프로그램에 동일한 검사 자료를 제공하여 동일한 결과가 출력되는지 검사하는 기법
■ (객체지향 기법에서) 캡슐화의 특징
- 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것이다.
- 캡슐화된 객체의 세부 내용이 외부에 은폐(정보 은닉)되어, 변경이 발생할 때 오류의 파급 효과가 적다.
- 캡슐화된 객체들은 재사용이 용이하다.
- 객체들 간에 메시지를 주고 받을 때 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고, 객체간의 결합도는 낮아진다.
■ 럼바우(Rumbaugh)의 분석 기법
- 객체 모델링(Object Modeling)
- 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것이다.
- 분석 활동의 세 가지 모델 중 가장 중요하며 선행되어야할 모델링이다. - 동적 모델링(Dynamic Modeling)
- 상태 다이어그램(상태도)을 이용하여 시간의 흐름에 따른 객체들 사이의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링이다.
- 동적 모델링에서는 객체나 클래스의 상태, 사건을 중심으로 다룬다. - 기능 모델링(Functional Modeling)
- 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링이다.
- 어떤 데이터를 입력하여 어떤 결과를 구할 것인지를 표현하는 것이다.
■ 월별(Person-Month) 생산성
생산성 = 원시 코드 라인 수 / 노력
노력 = 투입 인원 X 개발 기간(월단위)
문제) 두 명의 개발자가 5개월에 걸쳐 10000 라인의 코드를 개발하였을 때, 월별(Person-Month) 생산성 측정을 위한 계산 방식
답) 10000 / (5X2)
■ 소프트웨어의 생명 주기 모형
- 폭포수(Waterfall) 모델 : 폭포에서 한 번 떨어진 물은 거슬러 올라갈 수 없듯이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하며 이전 단계로 넘어갈 수 없는 방식
- 프로토타입 모델(Prototype Model, 원형 모형) : 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형
- 나선형 모형 : 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
- RAD 모델 : 소프트웨어의 구성 요소를 사용하여 매우 빠르게 선형 순차적 모델을 적용시킴으로써 빠른 개발 주기를 가지는 점진적 소프트웨어 개발 방식
■ 응집도(Cohesion)
- 정보 은닉 개념을 확장한 것으로 모듈 안의 요소들이 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미한다.
- 독립적인 모듈이 되기 위해서는 각 모듈의 응집도가 강해야 한다.
- 응집도의 종류(강함 > 약함) : 기능적 응집도 > 순차적 응집도 > 교환(통신)적 응집도 > 절차적 응집도 > 시간적 응집도 > 논리적 응집도 > 우연적 응집도
- 기능적 응집도(Functional Cohesion) : 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
- 순차적 응집도(Sequential Cohesion) : 모듈 내의 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
- 교환(통신)적 응집도(Communication Cohesion) : 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
- 절차적 응집도(Procedural Cohesion) : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
- 시간적 응집도(Temporal Cohesion) : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
- 논리적 응집도(Logical Cohesion) : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
- 우연적 응집도(Coincidental Cohesion) : 모듈 내부의 각 구성 요소들이 서로 관련없는 요소로만 구성된 경우의 응집도
■ 소프트웨어 품질목표
- 정확성 (Correctness) : 사용자의 요구 기능을 충족시키는 정도
- 신뢰성 (Reliability) : 정확하고 일관된 결과를 얻기 위해 요구된 기능을 오류 없이 수행하는 정도
- 효율성 (Efficiency) : 요구되는 기능을 수행하기 위해 필요한 자원의 소요 정도
- 무결성 (Integrity) : 허용되지 않는 사용이나 자료의 변경을 제어하는 정도
- 용이성 (Usability) : 사용에 필요한 노력을 최소화하고 쉽게 사용할 수 있는 정도
- 유지보수성 (Maintainbility) : 변경 및 오류 사항의 수정에 대한 노력을 최소화하는 정도
- 유연성 (Flexibility) : 변경 및 오류 사항의 수정에 대한 노력을 최소화하는 정도
- 시험 역량 (Testability) : 의도된 기능을 수행하도록 보장하기 위해 프로그램을 시험할 수 있는 정도
- 이식성 (Portability) : 다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
- 상호 운용성 (Interoperability) : 다른 소프트웨어와 정보를 교환할 수 있는 정도
■ 자료 흐름도(DFD, Date Flow Diagram)의 구성 요소
- 프로세스 (Process) : 자료를 변환시키는 시스템의 한 부분(처리 과정)을 나타내며, 처리, 기능, 변환, 버블이라고도 함
원이나 둥근 사각형으로 표시하고 그 안에 프로세스 이름을 기입함
- 자료 흐름 (Data Flow) : 자료의 이동(흐름)을 나타내며, 화살표 위에 자료의 이름을 기입함
- 자료 저장소 (Data Store) : 시스템에서의 자료 저장소(파일, 데이터베이스)를 나타내며, 평행선 안에 자료 저장소 이름을 기입함
- 단말 (Terminator) : 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받으며 (정보의 생산자와 소비자), 사각형 안에 이름을 기입함
■ 객체 지향 기법에서 사용되는 용어
- 캡슐화(Encapsulation) : 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것
- 정보 은닉(Information Hiding) : 캡슐화에서 가장 중요한 개념으로, 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것
- 추상화(Abstraction) : 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화하는 것, 즉 모델화하는 것
- 상속성(Ingeritance) : 이미 정의된 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스가 물려받는 것
- 다형성(Polymorphism) : 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메세지에 대해 각 객체(클래스)가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
■ OMA(Object Management Architecture) 레퍼런스 모델의 구성요소
- 객체 요구 매개자(ORB)
- 객체 서비스(Object Service)
- 공통 기능(Common Facilities)
- 도메인 인터페이스(Domain Interface)
■ 프로젝트 관리를 위한 3P (3대 요소)
- 사람(People) : 프로젝트 관리에서 가장 기본이 되는 인적 자원
- 문제(Problem) : 사용자 입장에서 문제를 분석하여 인식함
- 프로세스(Process) : 소프트웨어 개발에 필요한 전체적인 작업 계획
■ CASE
▷ CASE 의 개념
- 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것이다.
- 소프트웨어 생명 주기의 전체 단계를 연결해 주고 자동화해 주는 통합된 도구를 제공해 주는 기술이다.
- 소프트웨어 개발 도구와 방법론이 결합된 것으로, 정형화된 구조 및 방법(메커니즘)을 소프트웨어 개발에 적용하여 생산성 향상을 구현하는 공학 기법이다.
- 소프트웨거 개발의 모든 단계에 걸쳐 일관된 방법론을 제공하는 자동화 도구(CASE Tool) 들을 지원하고, 개발자들은 이 도구를 사용하여 소프트웨어 개발의 표준화를 지향하며, 자동화의 이점을 얻을 수 있게 해준다.
▷ CASE 사용의 이점
- 소프트웨어 개발 기간을 단축하고 개발 비용을 절감할 수 있다.
- 자동화된 기법을 통해 소프트웨어 품질이 향상된다.
- 소프트웨어의 유지보수를 간편하게 수행할 수 있다.
- 소프트웨어의 생산성이 향상되고 생산, 운용 활동을 효과적으로 관리 · 통제할 수 있다.
- 품질과 일관성을 효과적으로 제어할 수 있다.
- 소프트웨어 개발의 모든 단계에 걸친 표준을 확립할 수 있다.
■ HIPO 의 종류
- 가시적 도표(도식 목차) : 시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree) 구조도
- 총체적 도표(총괄 도표, 개요 도표) : 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표
- 세부적 도표(상세 도표) : 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표
'IT License' 카테고리의 다른 글
[운전면허필기] 합격 후기 (0) | 2019.03.10 |
---|---|
정보처리기사 필기대비 공부노트 (1_데이터베이스) (0) | 2018.04.13 |
정보처리기사 필기대비 공부노트 (3_운영체제) (0) | 2018.04.12 |
정보처리기사 필기대비 공부노트 (2_전자계산기 구조) (0) | 2018.04.11 |
스키마의 정의 (Schema Definition) (0) | 2018.01.03 |
댓글