용's

10.1 White Box Test- Output 결과를 비교할 뿐만 아니라 예상된 방향으로 프로그램이 흘러가는지도 비교 하는 것- Black box test와는 달리 내부적인 구조를 살펴봐야 함- Logic coverage의 기준을 만족 시키기 위한 테스트 케이스들을 설계함 .Statement Coverage(문장 검증 기준).Branch Coverage(분기 검증 기준).Condition Coverage(개별 조건 검사).Compound Condition Coverage(다중 조건 검사).Path Coverage(경로 검사) 10.2 Logic Coverage- 다음과 같은 코드와 Flow Chart를 가지고 각 Coverage들을 살펴보자 - Statement Coverage .가장 단순한 검증기준..

10.1 Testing 종류-Testing에는 여러 종류가 있다..Black Box Test, Functional Test, White Box Test, Structural Test, Gray Box Test - Functional Test(또는 Black Box Test와 같음).안의 코드들을 보지 않고 Requirement대로 입력에 따른 적절한 결과가 나오는지 테스트 - Structural Test(또는 White Box Test와 같음).소프트웨어의 구조나 구현사항(코드)들을 토대로 테스트 케이스가 선택됨.이 경우는 단순한 결과값 뿐만 안이라 내부적인 동작 부분(path)도 살피게 됨 - Black Box Test의 경우, 스펙에 명시되어 있지 않은 부분은 테스팅 할 수 없음- White Box ..

8.1 Software Testing이란- 소프트웨어 테스팅은 무엇인가?.품질에 대한 측정.실제 결과와 예상되는 결과 사이의 차이를 확인하는 것.에러를 발견하는것 - 소프트웨어 테스팅을 왜 하는가?.품질보증(QA)안에 검증(verification) & validation(확인) 부분에 Testing이 포함되어 있음.즉, 검증 분야에서 '실행에 기반을 둔 검증 부분'을 테스팅.Verification(검증): 제대로 만들고 있는가에 대한 답변(Internal Process).Validation(확인): 사용될 수있는 올바른 것인가에 대한 답변(External Process) - 디버깅과의 차이.디버깅(Debugging): 찾아낸 에러를 제거하는 것이 목적.테스팅(Testing): 에어를 찾아내는 것이 목적 ..

7.1 Architecture Design- 왜 아키텍처 설계가 중요한가?.실체(아키텍처)를 두고 얘기하게 됨으로 커뮤니케이션의 기반이 될 수 있음.초기 디자인 결정에 중요한 부분 7.1.1 Architecture Style- 아키텍처 디자인을 할 때 여러가지 양식(style)이 존재하며 각 스타일은 다음과 같은 카테고리를 포함.컴포넌트 집함(데이터베이스, 컴퓨터 모듈들).커넥터의 집함(컴포넌트들 사이의 통신).제약사항(어떻게 컴포넌트가 한 시스템으로 통합될 것인가).의미 모델(semantic model: 설계자를 이해 시킬만한 전체적인 시스템의 특징) - 각 양식(style)에 대해 알아보자. - Data Centered Architecture(데이터 중심 아키텍처).데이터 저장공간을 두고 클라이언트가..

매우 간단하게 요약해보자 7.1 Software Design(소프트웨어 설계)- Software design(소프트웨어 설계)란, 문제의 요구사항들을 소프트웨어 구조들로 변환하는 과정이라고 본다.- 또는, 목표 소프트웨어를 정의하기 위해 기술들이나 원칙들을 적용시키는 과정으로 본다..여기서 원칙이란 여러가지가 있다.tunnel vision에 어려움이 없어야함Analysis model을 재추적 할 수 있어야 함설계는 코딩이 아님Semantic 에러를 최소화 하도록 review되어져야만 함, 기타 등등 - 설계는 명시된 모든 요구사항들을 구현해야만 한다.- 설계는 알아보기 쉬운, 이해하기 쉬운 가이드가 되어야 한다.- 설계는 소프트웨어의 완전한 모양을 제공해야 한다. 7.2 Fundamental Concep..

6.1 Object-Oriented Concepts- 이 세상의 모든 것이 객체(object)라는 사고방식 - 객체지향의 개념을 이해하기 위해서는 분석 모델의 Class 기반의 요소들을 잘 이해해야 한다.- 객체지향의 핵심개념은 다음과 같다.Classes & Objects.Attributes & Operations.Encapsulation(캡슐화) & instantiation.Inheritance 6.1.1 Classes- 객체 지향적인 사고는 Class의 정의와 함께 시작되었다.- 한 객체의 정의에 대하여 속성들(attributes)과 동작들(operations)을 정의함.- 어느 한 객체의 클래스가 한번 정의되면 그 클래스의 특정 인스턴스가 정의될 수 있다.- Class는 Attribute들을 Ope..

5.1 Behavioral Modeling- 행동적 모델은 소프트웨어가 외부 이벤트들이나 자극에 어떻게 반응을 할 것인지를 가리킨다.- 이 모델을 위해 분석가들은 다음과 같은 것들을 수행하여야 한다..모든 use case들을 평가하여 시스템 내에서 일어나는 상호작용들의 순서들을 완벽히 알고 있어야 함.외부 사건들을 확인하고 이 사건들이 특정 오브젝트와 어떻게 연관이 있는지 이해함.각 use case에 대한 시퀀스(sequence)를 만듦.시스템을 위한 상태 다이어그램(state diagram)을 만듦.behavioral model을 리뷰하여 정확성과 일관성을 확인 5.2 State Representation- Behavioral Modeling에서 대표적인 diagram이 state diagram(상태 ..

1) 요구사항 수집에서의 문제점- 고객들의 요구사항들은 대체로 애매한 아이디어들이다.- 개발자는 애매한 요구사항들을 가지고 계속 진행을 하게 된다.- 고객들의 요구사항들은 계속해서 변한다.예) '온라인 서점의 요구사항'에서,"도서 검색과 주문 등이" => 비완성적인 부분(Incompleteness)"고객", "회원" => 불일치(Inconsistency)"카테고리 별 검색도" => 모호함(Ambiguity), 예를 들면 어떤 카테별리 별로 검색할지를 말해야함."효율적으로" => 모호함(Ambiguity), 어떻게 효율적으로 주문할 것인지 언급되야함- 사용자와 개발자 사이에서의 요구사항 오해(Misunderstanding)는 상당한 비용을 초래할 수 있다. => 프로젝트가 진행됨에 따라 자꾸 비용이 커짐으..

3.1 Software Engineering as a Layered Technology - Quality, Process, Methods, Tools의 4가지 계층구조로 Software Engineering이 이루어짐.- 여기서 Process는 Software을 개발하는과정을 말하며 Software Engineering의 토대가 되는 부분임. 3.2 Software Process의 Phases- Process는 Definition(정의), Development(개발), Support(지원, 유지보수)들의 3가지 단계(Phases)를 거침.=> Definition: 무엇을 만들려는 것인지에 집중된 것. Project management나 요구사항 분석등이 주요 과제=> Development: 어떻게 만들것..

2.1 Software Quality1) Software Quality의 정의 - 많은 정의가 있지만, 대체적으로 제품 또는 서비스의 특징들이 요구사항을 얼마나 만족시키고 또 얼마나 적합한지를 나타내는 것.- 사실 Quality는 절대적이지도 않고, 다차원적이며, 제약점도 많고, 판단기준도 독립적이지 않아 어려움이 있음. 2) Software Quality의 분류- 뚜렷하게 나눠지는 것은 아니나, External Quality와 Internal Quality로 나눠짐.External Quality: 시스템의 사용자들에게 보이는 부분의 QualityInternal Quality: 시스템 개발자들의 고려사항 부분의 Quality- 보통 Internal quality를 통해 개발자들이 External Qual..