소프트웨어 공학 정리

* 브룩스 법칙

 - 프로젝트 진행 중에 새로운 인력을 투입할 경우 적응 기간과 부작용으로 인해 일정을 지연시키고 혼란을 가져온다.

 

* Validation(검증) 기법

 1. 형상 검사(구성 검토, 감사) 

    가. 소프트웨어 구성 요소, 목록, 유지보수를 지원하기 위해 필요한 모든 사항들이 제대로 표현되었는지를 검사

 2. 알파 검사

    가. 개발자의 장소에서 사용자가 개발자 앞에서 행하는 검사 기법

    나. 통제된 환경에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 기록함

 3. 베타 검사

    가. 선정된 최종 사용자가 여러 명의 사용자 앞에서 수행하는 검사 기법

    나. 사용자가 직접 시험하는 것으로, 개발자에 의해 제어되지 않은 상태에서 검사가 행해짐, 오류 주기적인 보고

 

* 유지보수

 1. Corrective(수정 보수)

    - 시스템을 운영하면서 검사 단계에서 발견하지 못한 잠재적인 오류를 찾아 수정하는 활동

 2. Adaptive(적응 보수)

    - 수명 기간 중 운영체제나 컴파일러와 같은 환경 변화를 소프트웨어에 반영하기 위해 수행하는 활동

 3. Perfective(완전화 보수)

    - 새로운 기능을 추가, 성능을 개선시키기 위한 활동

    - 유지보수 활동 중 가장 큰 업무 및 비용을 차지하는 활동

 4. Preventive(예방 보수)

    - 장래의 유지보수성 또는 신뢰성을 개선하거나 오류 발생에 대비하여 미리 예방 수단을 강구해두는 활동

 5. Alien Code(외계인 코드)

    - 15년 전 또는 그전에 개발되어서 유지보수 작업이 매우 어려운 프로그램을 의미

 6. 소프트웨어 비용 중 유지보수 비용이 가장 많다.

 

* Reverse Engineering(역공학)

 - 기존 소프트웨어를 분석하여 소프트웨어 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를

   재발견하거나  다시 만들어내는 작업

 - 기존 소프트웨어의 구성 요소와 그 관계를 파악하여 설계도를 추출

 - 가장 간단하고 오래된 형태는 재문서화 이다.

 - 일반적인 개발 단계와는 반대 방향으로 기존 코드를 복구하는 방법

 - 원시 코드로부터 설계 정보 추출 및 절차 설계 표현, 프로그램과 데이터 구조 정보 추출

 - 결과에서 분석 및 설계 정보를 역으로 추출

 

* Analysis(분석)

 - 소프트웨어 재공학 활동 중 기본 소프트웨어의 명세서를 확인하여 소프트웨어 동작을 이해하고 재공학 대상을 선정

 

*Migration(이전)

 - 소프트웨어 재공학 활동 중 기존 소프트웨어 시스템을 새로운 기술 또는 하드웨어 환경에서 사용할 수 있도록 변환

 

* Restructuring(재구성, 재구조)

 - 상대적으로 같은 추상적 수준에서 하나의 표현을 다른 표현 형태로 바꾸는 것, Reengineering과는 다르다.

 

*Encapsulation(캡슐화)

 - 자료 부분과 연산 부분 등 정보처리에 필요한 기능을 한 테두리로 묶는 것, private, protect 

 

* 오퍼레이션(연산) = 메소드

 - 클래스 내의 객체에 의한 함수이거나 변형이다.

 - 객체지향 기법에서는 메소드와 오퍼레이션을 동일시한다.

 

* 화이트 박스 테스트

 1. 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 검사하여 검사 사례를 설계하는 방법

 2. 설계된 절차에 초점을 둔 구조적 테스트로, 프로시저 설계의 제어 구조를 사용하여 검사 사례를 설계하며, 

    테스트 과정의 초기에 적용된다.

 3. 모듈 안의 작동을 직접 관찰할 수 있다.

 4. 원시 코드의 모든 문장을 한 번 이상 수행함으로써 수행된다.

 5. 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 제어한다.

 6. 각 조건에서 참과 거짓의 모든 논리적 결정이 적어도 한 번 이상 실행된다.

 7. 종류

    가. Basic Path Testing(기초 경로 검사)

         - 대표적인 화이트박스 테스트 기법

         - 검사 사례 설계자가 절차적 설계의 논리적 복잡성을 측정, 실행 경로의 기초를 정의하는데 지침으로 쓰임

    나. Condition Testing(조건 검사)

         - 모듈 내의 논리적 조건을 검사

    다. Loop Testing(루프 검사)

         - 반복 구조에 초점을 맞춰 실시하는 검사

    라. Data Flow Testing(데이터 흐름 검사)

         - 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 검사

 8. 논리 흐름도, 루프 구조, 순환 복잡도 등의 오류를 찾아낼 수 있다.

 

* 블랙 박스 테스트(기능 검사)

 1. 소프트웨어 인터페이스에서 실시되는 검사로, 각 기능이 완전히 작동되는 것을 입증하는 검사

 2. 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 

    행위나 성능 오류, 초기화의 종료 오류 등을 발견하기 위해 사용되며 테스트 과정의 후반부에 적용

 3. 소프트웨어 산물의 각 기능별로 적절한 정보 영역을 정하여 적합한 입력에 대한 출력의 정확성을 점검

 4. 종류

    가. 동치 분할 검사(Equivalence Partotopming Testion)

         - 입력 자료에 초점을 맞춰 검사 사례를 만들고 검사

    나. 경곗값 분석(Boundary Value Analysis)

         - 입력 조건에 경곗값을 검사

    다. 원인-효과-그래프 검사(Cause - effect graphing testion)

         - 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성이 높은 검사 사례 선정

    라. 오류 예측 검사(Error Guseesing)

         - 과거의 경험이나 확인자의 감각으로 검사하는 기법

    마. 비교 검사(Comparison Testing)

         - 여러 버전의 프로그램에 동일한 검사 자료를 제공하여 동일한 결과가 출력되는지 검사

 5. 자료 구조를 찾아낼 수 있다.

 

* 럼바우의 분석 기법

 1. 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법

 2. 분석 활동은 객체 모델링, 동적 모델링, 기능 모델링 순으로 이루어진다.

    가. 객체 모델링 - 정보 모델링, 객체들 간의 관계를 규정

    나. 동적 모델링 - 상태도(상태 다이어그램)를 이용하여 시간의 흐름에 따른 객체들 사이의 제어 흐름, 상호 작용,

                           동작  순서 등을 표현

    다. 기능 모델링 - 자료 흐름도(DFD)를 이용 다수의 프로세스들 간의 흐름을 중심으로 처리 과정을 표현

                         - 입출력 결정 -> 자료 흐름도 작성 -> 기능의 내용 상세히 기술 -> 제약 사항을 결정하고 최소화

 

* 자료 흐름도(DFD)

 - 구성 요소 : Process(프로세스), Data Flow(자료 흐름), Data Store(자료 저장소), Terminator(단말)

 - 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법

 - 버블 차트라고도 한다.

 - 구조적 분석 기법에 이용된다.

 - 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화

 - 자료는 처리를 거쳐 변환될 때마다 새로운 이름이 부여된다.

 - 자료의 흐름 및 변환 과정과 기능을 도형으로 표현한 것

 - 처리는 입력 자료가 발생하면 기능을 수행한 후 출력 자료를 산출한다.

 - Level(단계) 0의 자료 흐름도를 배경도라 하는데, 이 배경도를 통해 전체 시스템의 범위를 표현

 - 각각의 프로세스에 대하여 개별적인 상세화 및 계층화가 가능하다.

 - 자료흐름도의 최하위 처리는 소단위 명세서를 갖는다

 - 기호

   1. 단말은 사각형

   2. 프로세스는 동그라미

   3. 자료 흐름은 화살표

   4. 자료 저장소는 =

 

 

* FTR(정형 기술 검토) 지침 사항

 1. 제품의 검토에만 집중

 2. 의제를 제한하여 진행

 3. 논쟁과 반박을 제한

 4. 문제 영역을 명확히 표현

 5. 해결책이나 개선책에 대해서는 논하지 마라

 6. 참가자의 수를 제한하고 사전 준비를 강요

 7. 검토될 확률이 있는 각 제품에 대한 체크리스트를 개발

 8. 자원과 시간 일정을 할당하라

 9. 모든 검토자들을 위해 의미 있는 훈련을 행하라

 10. 검토자들은 사전에 작성한 메모들을 공유하라

 11. 검토의 과정과 결과를 재검토하라

 

* Cohesion(응집도)

 - 처리 요소들 간의 기능적 연관도를 나타냄, 내부 요소는 명령어, 명령어의 모임, 호출문 작업 코드 수행

 - 기능적(Functional) 응집도 > 순차적(Sequential) 응집도 > 교환적(Communication) 응집도 >

   절차적(Procedural) 응집도 > 시간적(Temporal) 응집도 > 논리적(Logical) 응집도 > 우연적(Coincidental) 응집도

   기순교절시논우

 

*Coupling(결합도)

 1. 모듈 간에 상호 의존하는 정도를 나타냄

 2. 독립적인 모듈이 되기 위해선 각 모듈 간의 결합도가 약해야 하며 의존하는 모듈이 적어야 한다.

 3. 내용(Content) 결합도 > 공통(Common) 결합도 > 외부(External) 결합도 > 제어(Control) 결합도 >

     스탬프(자료구조) 결합도 > 자료(Data) 결합도

 - 자료 결합도 : 자료 요소로만 구성

 - 스탬프 결합도 : 자료 구조가 전달될 때

   내공외제스자

 

* CASE

 1. 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용

    소프트웨어 도구를 사용하여 자동화하는 것이다.

 2. 소프트웨어, 하드웨어, 데이터베이스, 테스트 등을 통합하여 소프트웨어를 개발하는 환경을 조성

 3. 소프트웨어 생명 주기의 전체 단계를 연결해 주고 자동화해 주는 통합된 도구를 제공하는 기술

 4. 소프트웨어 개발 도구와 방법론이 결합된 것으로 정형화된 구조 및 방법을 소프트웨어 개발에 적용하여

    생산성 향상을 구현하는 공학 기법

 5. 소프트웨어 개발의 모든 단계에 걸쳐 일관된 방법론을 지원한다.

 6. 주요 기능 

    가. 소프트웨어 생명주기 전 단계의 연결

    나. 다양한 소프트웨어 개발 모형 지원

    다. 그래픽 지원

 7. 이점

    가. 소프트웨어 개발 기간 단축 및 비용 절감

    나. 품질 향상, 유지보수 용이, 생산성 향상, 재사용성 향상, 개발 주기의 표준화, 개발 기법의 실용화, 문서화 용이

    다. 오류 수정이 쉽다.

 8. 분류

    가. UpperCASE : 전반부 사용 

    나. LowerCase : 하반부 사용

    다. IntergrateCase : 전체 과정

 

* PERT

 1. 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크

 2. 각 작업별로 낙관적인 경우, 가능성이 있는 경우, 비관적인 경우로 나누어 각 단계별 종료 시기를 결정하는 방법

 3. 노드와 간선으로 구성되며, 원 노드에는 작업을, 간선에는 낙관치, 기대치, 비관치를 표시

 4. 작업에 대한 경계 시간, 작업 간의 상호 관련성, 작업의 결정 경로를 확인할 수 있음

 

* CPM(Critical Path Method)

 1. 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는 데 사용하는 기법

 2. 노드와 간선으로 구성된 네트워크로 노드에는 작업을 간선은 작업 사이의 전후 의존관계를 나타냄

 3. 원형 노드는 각 작업을 의미하며 각 작업의 이름과 소요 기간을 표시하고, 박스 노드는 이정표를 의미하며 

    박스 노드 위에는 예상 완료 시간을 표시

 4. 한 이정표에서 다른 이정표에 도달하려면 이전의 작업이 모두 완료되어야 함

 5. 프로젝트 내에서 각 작업이 수행되는 시간과 각 작업 사이의 관계를 파악할 수 있음

 6. 경영층의 과학적인 의사 결정을 지원하며 효과적인 프로젝트의 통제를 가능하게 해 줌

 

* Configuration Management(형상 관리)

 1. 소프트웨어에서 일어나는 수정이나 변경을 알아내고 제어하는 것을 의미한다.

 2. 소프트웨어 개발의 전체 비용을 줄이고 개발 과정의 여러 방해 요인이 최소화되도록 보장하는 것이 목적

 3. 형상관리에서 중요한 기술 중의 하나는 버전 제어 기술이다.

 

* 객체 지향 설계 단계

 - 문제 정의 -> 요구 명세화 -> 객체 연산자 정의 -> 객체 인터페이스 결정 -> 객체 구현

 

* 자료 사전

 1. = : is composed of (~로 구성되어 있다)

 2. + : and(그리고), 자료의 연결

 3. ( ) : optional(생략 가능한 자료)

 4. [ | ] : or(또는)

 5. { } : Iteration of(반복)

 6. * * : comment(주석)

 

* 소프트웨어 품질 목표

 1. Correctness(정확성)

 2. Reliability(신뢰성)

 3. Effciency(효율성) -> 제품의 일정한 성능과, 자원 소요량의 관계, 요구되는 기능을 수행하기 위한 소요량

 4. Integrity(무결성)

 5. Usability(사용 용이성)

 6. Maintainablity(유지보수성)

 7. Flexibility(유연성)

 8. Testability(시험 역량)

 9. Portability(이식성)

 10. Resuability(재사용성)

 11. Interoperability(상호운용성)

 

* 소프트웨어 생명 주기 모형

 1. WaterFall Modex(폭포수 모형)

  - 개발 과정의 앞 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형

  - 가장 오래되고 가장 폭넓게 사용된 전통적인 모형

  - 타당성 검토 -> 계획 -> 요구 분석 -> 구현 -> 시험 -> 유지보수

 2. Prototype Model(프로토타입 모형)

  - 시제품을 만들어 최종 결과물을 예측하는 모형

  - 유지보수 단계가 없어지고 개발 단계 안에서 유지보수가 이루어진다.

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

 3. Spiral Model(나선형 모형)

  - 프로토와 폭포수의 장점에 위험 분석 기능을 추가한 모형

  - 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 최종 소프트웨어 개발

  - 계획(Planning) -> 위험 분석(Risk Analysis) -> 개발(Engineering) -> 고객 평가(Evaluation)

  - 가장 현실적이고 대규모 시스템에 적합

 

* 객체지향 분석

 1. Rumbaugh(럼바우) 방법 : 가장 일반적으로 사용되는 방법, 객체 모델, 동적 모델, 기능 모델

 2. Booch(부치) 방법 : 미시적, 거시적 모두 사용하는 분석 방법

 3. Jacobson 방법 : Use Case를 강조하여 사용하는 분석 방법

 4. Coad와 Yourdon 방법 : E-R다이어그램 사용

 5. Wirfs-Brock 방법 : 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행

 

* 객체지향 설계 및 분석 단계

 1. 분석 설계 및 구현 단계들 사이에 의미적 갭이 거의 없다

 2. 구현 단계에서는 정의된 클래스들에 대해 특정 언어를 이용하여 1:1로 정의한다.

 

* 위험 모니터링 -> 위험 요소 징후들에 대하여 계속적으로 인지하는 것

 

*소프트웨어에 대한 인터페이스

 - 소프트웨어에 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어

 - 기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어

 - 순차적 연산에 의해 소프트웨어를 실행하는 절차

 

* 소프트웨어 재공학은 예방 유지보수 측면에서 소프트웨어 위기를 해결하려고 하는 방법이다.

 

*Encapsulation(캡슐화)

 - 자료 부분과 연산 부분 등 정보처리에 필요한 기능을 한 테두리로 묶는 것

 

* 소프트웨어 개발 영역(범위) 결정

 - 기능, 성능, 제약 조건, 인터페이스, 신뢰도

 

* 소프트웨어 개발 비용을 산정할 때 생산된 문서와 관리 비용은 들어가지 않는다.

 

* 소프트웨어 문서 표준화가 되었을 때 개발 인력이 감소 하진 않는다.

 

* OMA 레퍼런스 모델의 구성 요소

 - Object Service, Common Facilities, Domain Interface, Aplication Interface

 

* Pareto의 법칙

 - 상위 20% 사람들이 전체 부의 80%를 가지고 있다. 80:20 법칙

 

* Gantt Chart(간트 차트)

 - 프로젝트의 각 작업들이 언제 시작하고 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 일정표

 - 시간선(Time-Line) 차트라고도 한다

 - 중간 목표 미달성 시 이유와 기간을 예측할 수 있게 한다.

 - 사용자와의 문제점이나 예산의 초과 지출 등도 관리할 수 있게 한다.

 - 자원 배치와 인원 계획에 유용하게 사용된다

 - 다양한 형태로 변경하여 사용할 수 있다.

 - 작업 경로는 표시할 수 없으며, 계획의 변화에 대한 적응성이 약하다.

 - 각 일정은 막대로 표시, 수평 막대의 길이는 각 작업의 기간을 나타낸다.

 - 이정표, 작업 일정, 작업 기간, 산출물로 구성되어 있다.

 - 각 작업들의 시작점과 종료점을 파악할 수 있다.

 - 프로젝트의 진도 관리를 수행할 수 있다.

 

* 상향식 통합 검사(Bottom - Up)

 - 검사를 위해 드라이버를 생성

 - 하위 모듈들을 클러스터로 결합

 - 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사

 - 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.

 - 인터페이스가 이미 성립되어 있어야만 기능 추가가 가능하다.

 - 과정 : 낮은 수준의 모듈들을 Cluster로 결합 -> Driver라는 제어 프로그램의 작성 -> Cluster 검사 -> Driver를 제거

            Cluster를 상위로 결합

 

* 하향식 통합 검사(Top-Down)

 - 깊이 우선 통합법 또는 넓이 우선 통합법에 따라 Stub를 실제 모듈로 대치한다.

 - 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다.

 - 레벨이 낮은 데이터 구조의 세부 사항은 설계 초기 단계에서 필요하다.

 - 상위층에서 검사 사례(Test Case)를 쓰기 어렵다.

 - 검사 초기에 시스템 구조를 사용자에게 보여줄 수 있다.

 

* Stub

 - 하향식 통합 테스트 수행을 위해 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈

 

* Driver

 - 검사 사례에 대한 자료를 입력받고 검사를 위해 받은 자료를 모듈로 넘기며 관련된 결과를 출력하는 제어 프로그램

 - 주요 제어 모듈이 있어야 프로그램 동작

 - 상향식 통합 검사에서는 하위 모듈에서 상위 모듈로 통합 검사 되므로 클러스터를 시험하기 위한 제어 프로그램 필요

 

* Cyclomatic Complexity(순환 복잡도)

 - 내부 영역 + 외부 영역

 

* Unit Testing에서는 Class Testing이 사용된다.

 

* Mini-Spec : 세분화된 자료 흐름도에서 최하위 단계 프로세스의 처리 절차를 설명

 

* 설계 품질

 - 설계는 모듈적이어야 한다.

 - 설계는 자료와 프로시저에 대해 분명하고 분리된 표현을 포함해야 한다.

 - 소프트웨어 요소들 간의 효과적 제어를 위해 설계에서 계층적 조직이 제시되어야 한다.

 - 좋은 설계는 독립적인 기능적 특성을 가진 요소로 구성되어야 한다.

 

* COCOMO

 - Boehm이 제안한 것으로 원시 프로그램의 규모(LOC)에 의한 비용 산정 기법

 - 개발할 소프트웨어의 규모를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여

   비용을 산정한다.

 - 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용되고 있다.

 - 개발 유형

   1. 조직형(Organic Mode)

       - 기관 내부에서 개발된 중 소규모의 소프트웨어

       - 일괄 자료 처리나 과학 기술 계산용, 비즈니스 자료 처리용으로 5만 라인 이하의 소프트웨어를 개발하는 유형

       - 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합

   2. 반분리형(Semi-Detached Mode)

       - 조직형과 내장형의 중간형으로 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 라인

         이하의 소프트웨어를 개발

       - 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합

   3. 내장형(Embedded Mode)

       - 초대형 규모의 트랜잭션 처리 시스템이나 운영체제 등의 30만 라인 이상의 소프트웨어를 개발하는 유형

       - 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합

 

* N-S차트

 - 논리의 기술에 중점을 둔 도형을 이용한 표현 방법(박스 다이어그램, Chapin Chart)

 - 순차 구조, 반복 구조, 선택 구조, 다중 선택 구조 등을 표현한다.

  -GOTO나 화살표를 사용하지 않으며, 선택과 반복 구조를 시각적으로 표현

 - 조건이 복잡되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합

 - 이해하기 쉽고, 코드 변환이 용이하다.

 - 읽기는 쉽지만 작성하기가 어려우며 임의로 제어를 전이하는 것이 불가능하다.

 

* Component

 - 소프트웨어 재사용과 관련하여 객체들의 모임, 대규모 재사용 단위로 정의되는 것

 

* Fan-In & Fan-Out

 - Fan-In : 어떤 모듈을 제어하는 상위 모듈의 수, 들어오는 화살표

 - Fan-Out : 어떤 모듈 F에 의해 제어되는 수, 나가는 화살표

 

* 소프트웨어 프로젝트의 특징

 - 한시성, 유일성, 점진성

 

* Putnam 모형을 기초로 해서 만든 자동화 추정 도구는 SLIM이다.

 

*  소프트웨어 비용 추정 모형(Extimation Models)

 - COCOMO, Putnam, Fuction-Point 등이 있다.

 

* CORBA에서 인터페이스 정의 언어는 IDL이다.

 

* HIPO

 - 하향식 소프트웨어 개발을 위한 문서화 도구

 - 구조도, 개요 도표 집합, 상세 도표 집합으로 구성

 - 기능과 자료의 의존 관계를 동시에 표현

 - 보기 쉽고 이해하기 쉽다.

 - 종류

    - 가시적 도표 : 시스템의 전체적인 기능과 흐름을 보여주는 Tree(계층) 구조도

    - 총체적 도표 : 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공

    - 세부적 도표 : 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술

 

* 객체지향 모형에서 기능 모형의 설계 순서

 - 입 출력 결정 -> 자료 흐름도 작성 -> 기능을 상세히 기술 -> 제약 사항 결정 및 최소화

 

* FeedBack

 - 출력된 결과가 예정된 목표를 만족하지 못할 경우 목표 달성을 위해 반복 처리하는 것