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