7장 소프트웨어 공학과 IPT 7.1 소프트웨어 공학 7.2 소프트웨어 개발 주기 7.3 IPT 기법 7.4 HIPO 기법 7.5 모듈 설계
7.1 소프트웨어 공학[1] 소프트웨어 공학의 배경 소프트웨어 위기(Software Crisis) : 소프트웨어 개발 과정에서 비용, 성능, 신뢰성, 개발 기간과 관련된 많은 문제가 발생하는 현상 하드웨어의 발전 속도에 비해서 소프트웨어 개발 속도가 현저히 늦음으로 인해 발생되는 현상 소프트웨어 개발 계획에서 수립한 개발 비용을 초과하거나 개발 기간이 지연되는 현상 소프트웨어 생산성이 저조하여 개발 기간과 비용이 많이 드는 현상 개발된 하드웨어의 개발비보다 기존의 소프트웨어 유지보수비가 더 많이 드는 상황에 서 소프트웨어 품질이 신뢰하지 못할 정도로 미흡한 현상 하드웨어의 개발비보다 기존의 소프트웨어의 개발비가 훨씬 많이 드는 현상 새로운 소프트웨어 개발비보다 기존의 소프트웨어 유지보수비가 더 많이 드는 현상
7.1 소프트웨어 공학[2] 소프트웨어 공학의 정의 Fritz Bauer : “신뢰성 있고 실제 기계에 효과적으로 작동하는 소프트웨어를 경제적으로 얻기 위해서 올바른 공학적인 원리들을 체계화 시키고 이용하는 것” IEEE : “소프트웨어의 개발 운용과 유지 보수에 체계적이고, 숙달되고, 수량화된 접근법을 적용하는 것” 도구 방법 절차 소프트웨어 품질 및 개발 생산성 향상
7.1 소프트웨어 공학[3] 소프트웨어 공학의 원리 추상화의 원리(Principle of Abstraction) : 주어진 문제를 해결하는 데 있어서 간략하고 일반적인 형태로 나타내기 위해서 특별한 실재 에 묶여진 개념들을 분리하는 것 정형화의 원리(Principle of Formality) : 주어진 문제를 해결하는데 있어서 엄격하고 공학적인 접근 방법을 적용하는 것 분할 및 정복의 원리(Divide and Conquer Concept) : 어려운 문제 를 해결하는데 있어서 이해하기 쉽고, 해결하기 쉽게 하기 위해서 여러 개의 작고 독립적인 것들로 나누는 것 계층적 순서의 개념(Hierarchical Ordering Concept) : 주어진 문 제의 구성 요소들을 나무 구조와 같은 계층적 구조로 조직하여 이 해성을 향상시키는 것
7.1 소프트웨어 공학[4] 소프트웨어 공학의 원리 정보 은폐의 원리(Principle of Information Hiding) : 기능적인 분해 과정을 유 도하는 것으로서 복잡성을 제어하기 위해서 모듈화시키고, 모듈 사이의 인터페 이스를 간단하게 유지하는 것 지역성의 원리(Principle of Localization) : 논리적으로 관계가 있는 항목들을 실제적으로 인접하게 배치하는 것으로서 배열, 레코드, 서브루틴 및 프로시저 들이 해당됨 개념적 통일의 원리(Principle of Conceptual Integrity) : 시스템 형태의 일치성 과 하나의 설계 계획 또는 하나의 시스템 구조를 따르는 것으로 하나로 통일된 시스템 구조를 만들어 내는 것 완전성의 원리(Principle of Completeness) : 사용자의 모든 요구 사항을 만족 하는가를 조사하는 것으로 사용자의 요구사항에서 빠진 사항이 없는가를 조사 하여 모든 것이 포함되어 있다는 것 논리적 독립성의 원리(Principle of Logical Independence) : 시스템 분석과 설 계를 할 때, 논리적 기능에 중점을 두면서 물리적 구현과는 독립시킨다는 것
7.2 소프트웨어 개발 주기[1] 소프트웨어 개발 주기의 목표 고전적 수명주기(Classic Life Cycle) 시스템 개발에서 수행해야 할 활동들을 정의하기 위해서 동일한 조직 내에 있는 여러 프로젝트간의 일관성을 유지 하기 위해서 프로젝트의 계속 진행 또는 중단을 결정하는 관리 통제를 위한 체크 포인트(Check Point)를 제공하기 위해서 고전적 수명주기(Classic Life Cycle) 구조적 수명주기(Structured Life Cycle) 프로토타이핑 모델(Prototyping Model) 나선형 모델(Spiral Model) 4세대 기법(Forth-generation Techniques)
7.2 소프트웨어 개발 주기[2] 단계적 수명 주기(Phased Life Cycle)
7.2 소프트웨어 개발 주기[3] 폭포수 모델(Waterfall Model) 특징 개발 단계가 서로 독립적이며, 단계들 간의 연계성 부족 상향식 구현 방식
7.2 소프트웨어 개발 주기[4] 구조적 수명 주기 특징 하향식 구현 방식 개발 단계가 서로 독립적이나, 개발 단계들 간의 연계성 중시 하향식 구현방식 하향식 구현 방식 최상위 모듈을 먼저 코딩한 후, 하위의 계층으로 내려 가면서 모듈을 코딩하며, 동시에 개발된 부분을 통합하여 테스트 까지 수행하는 점진적 구현(Incremental Implementation)방식을 채택
7.2 소프트웨어 개발 주기[4] 구조적 수명 주기
7.2 소프트웨어 개발 주기[5] 프로토타이핑 모델 개략적인 시스템을 빨리 구축하고 사용자의 요구 사항이 완전히 파악될 때까지 개선을 계속한 후, 완전히 파악되었을 때 고전적 수명주기에 의하여 새로 개발하던가, 프로토타입을 개선하여 최종적인 소프트웨어 제품을 완성하자는 기법
프로토타이핑 모델 정제 사용자 인터페이스를 중점적으로 개발하여 사용자의 요구사항을 빨리 파악할 수 있는 장점은 있으나, 근본적인 시간 및 비용절감은 불가. 따라서 다른 수명주기의 보완정도로 활용됨
7.2 소프트웨어 개발 주기[6] 나선형 모델 계획화(Planning) : 목표, 방법, 제약 조건 결정 위험분석(Risk Analysis) : 위험요소의 분석및 해결방안 제시 공학화(Engineering) : 개발 방법 선택 및 검증 사용자 평가(User Evaluation) : 개발 결과에 대한 사용자 평가 폭포수 모델과 프로토타이핑 모델의 장점에 위험 분석(risk analysis)을 추가 시스템을 개발하면서 생기는 위험 관리, 최소화 폭포수 모델과 프로토타이핑 모델보다 복잡하여 프로젝트 관리가 어려움 비용이 많이 들고 시간이 오래 걸리는 큰 시스템 구축 - 현실적 접근 방법 [예] 초고속 정보통신망 개발, 큰 국책사업, 대형사업
나선형 모델 단계 계획화(planning) 사용자의 요구사항을 파악, 프로젝트 계획 수립 성능, 기능 및 시스템의 목표 규명 시스템의 목표와 제약 조건에 대한 차선책 평가 및 검토 위험원인 규명 위험 분석(risk analysis) 초기 요구사항을 기초로 위험 요소 분석 - 해결 방안 검토 위험 요소 평가 - 프로젝트의 계속 여부 결정 공학화(engineering) 시제품(개발 모델) 결정 – 적용 모델결정 시제품 개발하거나 최종 제품을 개발하는 과정 고객 평가(user evaluation) 프로토타입의 사용자 평가 -시스템을 평가및 수정요구 개발 결과는 시뮬레이션 모델, 프로토타입 또는 실제 시스템 고객의 평가에 따라 다음 산출물이 계획
7.2 소프트웨어 개발 주기[6] 나선형 모델
7.2 소프트웨어 개발 주기[7] 제4세대 기법 데이터베이스 질의에 대한 비절차적인 언어, 보고서 생성, 자료조작, 스크린 상호 작용과 정의, 코드 생성, 고급 수준의 그래픽 처리 능력, 스프레드 처리 능력 등의 소프트웨어 개발 환경의 도구들을 적용하는 기법
7.3 IPT 기법[1] 기술적인 측면을 지원하는 도구 IPT 기법은 IBM에서 제안한 “향상된 프로그래밍 기법”으로 이해하기 쉽고, 개발 및 유지보수의 측면에서 경제적이며, 효율적인 프로그램을 개발하기 위한 기법 복합 설계(Composite Design) 구조적 코딩(Structured Coding) 하향식 프로그래밍(Top Down Programming) HIPO(Hierarchy plus Input Process Output) 프로그램 기술 언어(Programming Description Language) 나시-슈나이더만 차트(Nassi-Schneiderman Chart)
7.3 IPT 기법[2] 복합 설계 시스템에 대한 상세 설계의 초기 단계에서 프로그램의 구조를 설계하기 위한 방식으로 “구조적 설계(Structured Design)” 또는 “기능 설계(Functional Design)” 라고도 함
7.3 IPT 기법[3] 구조적 코딩 어떠한 논리의 프로그램이라도 3가지 구조, 즉 순차 구조, 선택 구조, 반복 구조를 사용하여 코딩하는 기법 하나의 프로그램은 하나의 입구(Entry)와 하나의 출구(Exit)만을 가지도록 한다. 프로그램의 크기를 가능한 작게한다. IF, FOR 명령문의 범위를 들여쓰기(Indentation)로 명확히 한다.
7.3 IPT 기법[4] 하향식 프로그래밍 프로그램의 코딩과 테스트를 프로그램 구조의 상위 모듈로부터 하위 모듈로 순차적으로 진행시키는 기법
7.3 IPT 기법[5] HIPO 기법 도형 목차, 총괄 도표, 상세 도표를 이용한 설계 도구와 문서화 도구임
7.3 IPT 기법[6] 프로그램 기술 언어 HIPO와 코딩의 교량적인 역할로서 기능을 하향식으로 상세화할 때 사용되는 도구이며, 의사 코드(Pseudo Code)라고도 함 처리해야 할 레코드가 있는 동안 다음 처리를 반복한다. 다음 레코드를 읽는다. 정상적인 레코드일 때 해당 레코드를 처리한다. 비정상적인 레코드일 때 오류 메시지를 인쇄한다. 레코드 카운터에 1을 더한다. 종료
7.3 IPT 기법[7] Nassi-Schneiderman chart(나씨-슈나이더만 차트) 구조적 프로그래밍 방법에 사용되는 논리 표현 기법의 도표 HIPO - 기능 표현 중심 나씨-슈나이더만 차트 - 논리 표현 목적 순서도로 치환 가능 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별 구조적 코딩(structured coding)이 쉽다. 제어구조는 연속, 선택, 반복 [규칙] 도표는 사각형 - 표현에 따라 넓은 사각형, 긴 사각형 도표의 제어 흐름 - 위에서 아래로, 반복 구조는 제외 수평으로 그어진 줄은 모두 평행이 되어야 한다.
7.3 IPT 기법[7] N-S 차트 논리 표현을 중심으로 하는 기법으로 흐름도(Flowchart)로 변환 가능하며, 구조적 코딩에 매우 유용함
과제 다음의 문제를 해결하기 위한 프로그램 설계를 Flowchart(흐름도), N-S Chart, PDL(Program Description Language) 로 작성하시오. 학번, 이름, 국어, 영어, 수학 의 구조로 이루어 진 레코드를 50개 읽고 국어, 영어, 수학의 반평 균과 세과목을 합한 평균값을 구하고 각과목 및 세과목의 합의 최고 점수와 최소 점수를 구하시 오.
7.3 IPT 기법[8] 관리적인 측면을 지원하는 도구 책임 프로그래머 팀 소프트웨어의 품질과 개발 생산성을 향상시키기 위한목적으로 한 개발 조직
7.3 IPT 기법[9] 관리적인 측면을 지원하는 도구 구조적 검토회(Structured Walk-through) : 시스템 개발 과정에서 산 출된 시스템 명세서, 설계 결과, 프로그램 코드 등을 각각의 여러 사람 이 검토함으로써 산출물 내에 포함되어 있는 오류를 조기에 발견하는 방법 인스팩션(Inspection) : 발견된 오류를 문서화할 뿐만 아니라 이것을 관리용 데이터로 사용함 개발 지원 라이브러리(Development Support Library) : 개발 환경을 정비함으로써 관리를 용이하게 하고, 그 결과로써 품질과 생산성의 향 상을 얻고자 하는 기법
7.4 HIPO 기법[1] HIPO의 개요 : 개념 및 종류 시스템에 대하여 “입력(Input)-처리(Process)-출력(Output)”의 관계를 체계적으로 정립하고, 계층적으로 기능을 분할하여 분석함으로써 추상적인 개념으로부터 구체적이고, 정형화된 형태로 문서화하거나 시스템을 설계하는 기법 개요 설계 패키지 : 시스템 설계의 보조 수단으로서 시스템 기능의 개 요를 기술하는 것 상세 설계 패키지 : 개요 설계가 완성된 후, 이를 토대로 하여 다시 상 세 설계를 하는 것 문서화 및 유비보수 패키지 : 시스템에 대한 정정, 변경, 추가를 위해 사용되며, 상세 설계의 대응이 가능함
7.4 HIPO 기법[2] HIPO의 구성 도형 목차(Visual Table of Contents) : 시스템의 전 체적인 구성을 계층구조 도표로 나타낸 것 총괄 도표(Overview Diagram) : 시스템 또는 프로그 램의 개괄적인 사항을 입력, 처리, 출력의 관계로 도형 목차에 나타난 전체적인 기능을 하나의 도표로 나타낸 것 상세 도표(Detailed Diagram) : 보다 많은 양의 정보 에 대한 처리 내용을 상세하게 기술한 것
7.5 모듈 설계[1] 모듈의 외부 설계 모듈 명칭(Module Name) : 다른 모듈이 해당 모듈을 호출하는데 사용됨 기능(Function) : 해당 모듈이 수행할 기능을 요약된 문장으로 기술함 파라미터 리스트(Parameter List) : 해당 모듈과 다른 모듈 사이에 정보를 주고받는 파라미터의 개수나 순서들을 정확하게 정의함 입력/출력(Input/Output) : 파라미터 리스트에 나타나 있는 변수들을 입력 과 출력으로 구분하여 양식, 크기, 속성, 단위, 타당성의 식별 조건 등의 측 면에서 상세하게 기술함 외부 효과(External Effect) : 해당 모듈이 수행된 결과로 인해서 시스템이 나 여타의 모듈들에 미치는 영향이나 효과를 간략하게 기술함
7.5 모듈 설계[2] 모듈의 논리 설계 논리의 작성 : 모듈의 기능을 수행하는데 필요한 처리 절차와 내용을 상세하게 설계하는 단계 - 기법 : 프로그램 기술 언어(PDL), N-S 차트, 구조적 코딩 등 데이터의 정의 : 해당 모듈과 관련을 가지고 있는 데이 터를 정확히 파악하기 위해서는 해당 모듈과 관련을 가 지고 있는 인터페이스를 정의하고, 모듈 내부에서 사용 되는 데이터를 정의하는 것
7.5 모듈 설계[3] 모듈화의 특징 : 주의사항 적절한 크기로 작성하여야 함(Module Size) 모듈의 내용이 다른 곳에 적용 가능하도록 표준화하여야 함 (Reusability) 모듈간의 기능적 결합도는 적게 함(Module Coupling의 최소화) 모듈내의 구성 요소들끼리는 응집도는 크게 함 (Module Cohesion의 최대화) 자료의 추상화와 정보 은폐의 개념을 도입하여야 함 보기 좋고, 이해하기 쉽게 작성하여야 함
모듈(module)의 독립성 모듈의 독립성을 높이기 위한 방법 중요성 - 기능 구분, 인터페이스 간단, 개발이 쉽다. 기능적 독립성 - 모듈이 하나의 기능만을 수행하고 다른 모듈과의 상호 작용을 억제 모듈이 요구하는 부가 기능 - 접속관계를 갖도록 설계 하면 가능 독립적 모듈 - 설계와 코드 수정으로 발생되는 부수적 결과 한정, 오류 감소, 재사용모 듈이 가능하여 유지보수와 시험 용이 모듈의 독립성 - 프로그램의 복잡성 감소, 프로그램의 신뢰성을 높이며, 유지보수를 쉽게 한다. 모듈의 독립성을 높이기 위한 방법 각각의 모듈 내부에서 명령들간의 연관성이 최대가 되도록 하는 것 모듈간의 관련성이 최소가 되도록 하는 것 모듈 분할 같은 모듈 내의 명령 - 밀접한 관련 다른 모듈간의 명령 - 상호 관련성 배제 모듈 응집도 - 각 모듈 내에서의 명령들간의 연관성을 나타내는 개념 모듈 결합도 - 모듈간의 관련성을 표현하는 개념 모듈의 독립성 - 모듈 응집도를 최대로, 모듈 결합도를 최소로 하는 것
모듈 응집도(module cohesion) 단일 모듈 내에 있는 활동이 다른 활동에 연관되어 있는가를 평가 모듈 구성요소 - 명령어, 호출문 그리고 이들의 모임을 의미 모듈의 응집도 - 구성 요소들이 어떤 순서로 모듈 내부에 나타나고, 순 서가 어떤 기준에 의해 정해졌는가에 따라 표현 모듈 내에서의 명령들간의 연관성의 척도 모듈 결합도(module coupling) 모듈간의 상호의존도(관련성)의 척도 모듈을 독립적으로 생성 - 결합도를 최소화, 모듈간의 낮은 결합도 독립적인 모듈, 분할된 모듈 - 불필요한 모듈간의 관련성을 제거하여 모듈간에 필요한 관계의 수를 감소
7.5 모듈 설계[4] 모듈의 논리 설계 도구 분류 표기법 시스템의 총괄적인 구조 잭슨 다이어그램(Jackson Diagram) 시스템 구조 및 프로그램 구조의 표현 HIPO 도표, 액션 다이어그램(Action Diagram), HOS 도표 프로그램 모듈의 상세한 논리 구조 의사 결정도(Decision Tree), 의사 결정표(Decision Table) 특수목적 자료 구조 워니어 다이어그램, 잭슨 다이어그램, 개체 다이어그램, E-R 다이어그램 실시간 시스템 상태 전이도(State Transition Diagram) 성능 키비에트 도표 용량 거래 매드릭스 객체 지향 객체 다이어그램