개발자 끄적끄적

- 화이트박스 테스트 케이스 설계 - 프로그램 결함 식별을 목적으로 프로그램 코드로부터 생성 되는 여러 정보(제어흐름정보, 자료흐름정보, 조건등을 이용하여 테스트 케이스를 설계하는 방법 - Statement Testing(문장 테스팅) - Branch Testing(분기 테스팅) - Decision Testing(결정 테스팅) - Condition Testing(조건 테스팅) - Branch Condition Testing(분기 조건 테스팅) - Multiple Condition Testing(다중조건 테스팅) - MC/DC(Modified Condition/Decision Coverage) - 기본 경로 테스트(Basis path test) - 테스트하려는 프로그램 내의 모든 문장들을 '적어도 한번 이..

- 조합 테스팅은 테스트 대상 프로그램의 동등 분할이나 BVA등을 통해 여러 개의 클래스들로 각 입력 인자를 여러 클래스나 값들로 분할하였을 때 이들을 조합하여 테스트 케이스를 구성하는 방식 - 예제 : 입력 x,y,z를 어떻게 조합하여 테스트 케이스를 만들것인가?  1. one-to-one : 3+4+2=9개의 test case   2. minimized : 4개   3. 모든 입력 인자들 : 3*4*2=24 - Each choice 테스팅(=minimized): 각 입력 인자의 분할된 클래스로부터 최소한 하나의 입력 값이 테스트케이스에 포함 - 페어와이즈 테스팅: 각 인자의 값(또는 클래스)과 다른 인자의 값(또는 클래스)를 최소한 한번은 조합하여 테스트 케이스를 구성 - All combinatio..

- 블랙 박스 테스트케이스 설계 - 프로그램 코드의 정보를 이용하지 않고 또는 이용할 수 없을 때 테스트 케이스를 설계하는 방법 - 코드 정보 이외의 명세 정보나 시스템 인터페이스 정보 등을 이용하여 테스트 케이스를 설계하는 방법 - 기능 누락 오류 검출 - 테스트의 기본 - 프로그램의 입력/출력 영역을 몇 개의 동등 클래스(equivalent class)라 불리는 영역으로 분할하여 각 클래스로부터 대표 값을 선택하여 테스트 케이스로 이용 - 동등 클래스는 시스템에 의해 동일하게 처리되고 같은 출려고가 결과를 생산하는 입력 조건 또는 입력 데이터 값들의 모임   - 각 동등 클래스로부터 선정된 입력 값에 의하여 오류가 발견되면 클래스에 속한 다른 값들에 의해서도 동일한 오류가 발견   - 만약 각 동등..

1. Association(연관) - 클래스 간의참조 관계 - A->B는 A가 B를 참조한다는 의미 - ex) class Engine {  }; class Car { public : void setEngine(Engine *newEngine { engine = newEngine; } private : Engine *engine; }; - Car class는 Engine 클래스를 참조하고 있지만 두 클래스 사이에는 연관 관계가 있지만 포함관계는 아니다2. Inheritance(상속) - ex)  class Vehicle{ public: void drive() { ... } }; class Car : public Vehicle{ public: void honk() { ... } }; - Car 클래스는 Ve..

- 소프트웨어가 문제가 생기면? - http://cafe.naver.com/softwarequality/480 - 이스라엘의 텔아비브 대학(Tel Aviv)의 웹 사이트 - 어떻게 해야 하는가? - 소프트웨어가 오작동이 발생할 위험(risk)를 줄여야 한다 - 위험: (발생확률) X (발생했을 때 끼치는 손실) - 소프트웨어 테스팅은 위험에서 발생 확률을 줄이는 작업 - 테스팅 목적 - 결함 발견 - 품질과 잔존 위험(residual risk)에 대한 정보 제공 - 정적 테스팅 - 프로그램 실행을 하지않고 프로그램 코드나 산출물(문서) 결함을 찾는 활동 - IEEE 1024 (리뷰) - 관리 리뷰 (Management Review) - 기술 리뷰 (Technical Review) - 인스펙션 (Inspe..

- 상위수준에서 소프트웨어를 설계하는 기본 틀을 제공 - 아키텍처를 결정할 때 기능보다도 '품질 속성'이 보다 많은 비중을 차지한다   같은 기능을 구현한 두 개의 구조가 다를 수 있는 것은 달성하고자 하는 품질 속성이 다르기 때문이다 - 모든 품질 속성을 만족시키는 아키텍처를 구성하기는 사실상 어렵기 때문에 품질 속성에 우선순위를 두어 아키텍처를 결정한다 - 보안성, 성능과 같은 품질 솏성은 아키텍처 결정에 많은 영향을 준다 - 가장 일반적으로 많이 사용되는 아키텍처 시스템을 여러 계층으로 나누어 설계하여 구현한다 - 계층 아키텍스에서 보통 계층 N은 N+1 계층의 서비스를 제공하는 역할을 수행한다   즉, 계층(Layer)은 보다 상위에 위치한 계층들에게는 서비스를 제공하고,    하위 계층들로부터..

- SOLID 원칙에 따라 좋은 소프트웨어를 만들 수 있다   - 이해하기 쉽다   - 변경 하기 용이(유지보수)   - 새로운 기능에 대해 확장이 용이 - 로버트 마틴이 주창한 다섯 가지 설계원칙   - SRP(단일 책임 원칙, Single Responsibility Principle)   - OCP(개방 폐쇄 원칙, Open Closed Principle)   - LSP(리스코프의 대입 원칙, Liskov Substitution Principle)    - ISP(인터페이스 분리 원칙, Interface Segregation Principle)    - DIP(의존성 역전 원칙, Dependency Inversion Principle) => Design Pattern에 기반 - 단일 책임 원칙 즉,..

- 무엇을 공개하는 것인가? 소스코드를 공개한다는 의미 - 소스코드를 공개한다는 의미는 누구라도 사용할 수 있다는 의미를 내포 - Copyleft(카피레프트)   - 독점적인 의미의 저작권에(카피라이트, copyright)에 반대되는 개념이며,    저작권을 포함한 지식재산권에 기반을 둔 사용 제한이 아니라 정보의 공유를 위한 조치이다   카피레프트를 주장하는 사람들은 보통, 지식과 정보는 소수에게 독점되어서는 안되며, 모든 사람에게 열려 있어야 한다고 주장 - 독점 소프트웨어   - 상용 소프트웨어   - 일반적으로 실행파일만 제공   - 역공학 금지   - 바이너리도 복제, 배포, 수정 불가   - 사용기간 제한 - OSS   - 소스코드 제공   - 소스코드 사용, 복제, 수정, 재배포 허용   ..

- 모듈과 모듈사이에 관계를 어떻게 설계할 것인가 -> 결합도는 낮게 - Minimise coupling, make routins as independent ad possible(low RE) - Low coupling => well-partitioned - No routine should have to worry about the internal details or another Normal(low) - Data(데이터) - Stamp(스탬프) - Control(제어) -------------------------------"Modularity Line" Poor(high) - Common(공통) - Content(내용) - To routines are normally coupled if : - A C..

- 설계의 기본 원칙 : 응집도(=개별모듈)는 높게 결합도(=모듈관의 관계)는 낮게 - Fundamental principle of SD - A large system should be partitioned into mangeable routines&models - Goal - Routines are as independent as possible - Each routine carries out a single problem-ralted function - Mesures - Coupling and Cohesion - Cohesion is the measure of the strength of functional relatedness of elements within a routine - Element? ..

- 순차 다이어그램은 서비스를 제공하기 위한 객체 간의 상호 작용(메시지 송수신)을 모델링한다 - 클래스 다이어그램이 시스템의 정적 구조를 나타내는 대표적인 모델인 반면에 순차 다이어그램은 시스템의 동적 흐름을 나타내는 대표적인 모델이다 - 순차 다이어그램은 목표 서비스를 제공하기 위해 필요한 객체를 정의하고, 객체간의 메시지 송수신 관계를 시간 순서에 따라 정의함으로써 서비스를 제공하는 과정을 묘사하는 모델이다 - 순차 다이어그램에서 객체는 가장 윗부분에 표현이 되고, 왼쪽에서 오른쪽으로 객체들을 나열한다 - [객체명 : 클래스명] 형식을 이용하여 표기하며 이중 어느 한쪽을 생략하여 표기할 수 있다. - 객체는 박스로 표현하며 밑줄은 생략가능하다.(UML2.X버전) - 인스턴스이름 : 클래스명 - [시..

- 문제나 해결책의 정적인 구조 표현 - 클래스와 그들간의 관계 표현 - 건물을 설계할 때도 평면도, 입면도, 투시도, 조감도 등 하나의 건축물을 다양한 관점에서 표현한다 *유스케이스 다이어그램 - 시스템을 블랙박스로 본다. 즉, 내부 구조는 표현하지 않는다 - UML의 클래스 표현 - 세 부분으로 나누어진 박스로 표현 - 가장 윗부분 : 클래스 이름 중간 부분 : 마시막 부분 : 연산 - 접근제어자 - public(+) : 어떤 클래스의 객체에서도 접근 가능 - protected(#) : 이 클래스와 상속 관계에 있는 하위클래스의 객체들만 접근 가능 - package(~) : 동일 패키지에 있는 클래스의 객체들만 접근 가능 - private(-) : 이 클래스로부터 생성되어진 객체들만 접근 가능 - 속..

- 요구사항 분석   - 고객의 문제의 실체를 이해하고 분석하여 분석 모델을 구축   - 설계    - 설계 모델을 통해 고객의 문제를 해결하는 해결책을 표현 - 구현   - 설계 모델을 기반으로 프로그래밍 언어를 통해 소프트웨어(구현 모델) 구축 *분석 모델 : 고객의 요구사항을 모델링 *설계 모델 : 해결책을 모델링 *구현전에 모델링(요구사항분석, 설계 단계 -> 모델링 언어 필요 -> UML(Unified Modeling Language)) - 서로의 해석을 공유해 합의를 이루거나 해석의 타당성을 검토 - 현재 시스템 또는 앞으로 개발할 시스템의 원하는 모습을 가시화 - 시스템을 구축하는 틀 제공 - 대표적인 시스템 모델링 언어   - 제임스 러버 OMT + 야콥슨 OOSE + 부치 OOAD  ..

- 시스템의 일부 측면을 사용자가 경험하게 할 수 있는 도구 - 요구사항에 대한 대화 촉진 - 이해 관계자가 시스템의 요구사항에 대한 공통의 이해 달성 - 요구사항 오류나 누락 식별 - 요구사항 도출/분석/검증 도구로도 사용 - 범위(Scope)에 따른 분류 - 수평적 프로토타입(Horizontal prototype) - 수직적 프로토타입(Vertical prototype) - 충실도(Fidelity)에 따른 분류 - Lo-fi(Low fidelity) 프로토타입 - Hi-fi(High fidelity) 프로토타입 - 수평적 프로토 타입 - 사용자 인터페이스 부분(front-end)만 존재하고 기능 부분(back-end)구현 미비 - 정해진 출력, 오류 처리 미비 - 명확한 요구사항 파악, 요구사항 구체..

- 분석된 요구사항을 명확하고 완전하게 기록하는 것 - 소프트웨어 시스템이 수행하여야 할 모든 기능과 시스템에 관련된 구현상의 제약 조건 및 개발자와 사용자가 합의한 성능에 관한 사항 등을 명세 - 최종 결과물 : 요구사항 명세서(SRS : Software Requirement Specification) *SRS IEE-STD-830 : 소프트웨어 요구사항 명세서 국제 표준 - 무엇을 위해 이 문서를 작성했는지를 설명 - 주의) 제품의 용도를 나열하지 말라 - ex) 이 문서의 목적은 웹 게시 시스템에 대한 자세한 설명을 제공하는 것이다. 이 문서에서 시스템의 목적과 특징, 시스템의 인터페이스, 시스템이 무엇을 할 것인지, 시스템이 작동해야 하는 제약 조건, 그리고 시스템이 외부 자극에 어떻게 반응할것인..

- 도출된 불완전하고 추상적인 요구사항들을 적절한 수준으로 분해하고 정제하는 작업 - 고객과의 상호 작용을 통해 혼동 지점을 명확히 하고 어떤 요구사항이 다른 요구사항보다 더 중요한지 파악 - 명세를 만들기 위한 기반 - 요구 사항 모델링을 통해 요구사항이 보다 구체화되고 가시회되어 시스템에 대한 이해도가 크게 향상시키며 개발에 필요한 정보 제공 - 모델링 - 구조적 분석(자료 흐름도, DFD, Data Flow Diagram) - 유스케이스 분석 모델링(UML 모델링 사용) - 사용자 스토리(애자일 프로젝트) - ERD - State Transition Diagram - Dialogue Map 등 - 각 요구사항이 왜 필요한지가 명확하게 설명되어야 한다 - 제거되어도 시스템 비지니스 목표를 달성하는데 ..

- 소프트웨어 개발을 위한 요구사항 개발을 위한 활동 - 도출(Elicitation) - 인터뷰, 워크숍 등과 같이 요구사항을 찾아내기 위한 모든 관련 활동 - 이해관계자 식별 - 이해관계자로부터 요구사항 도출(수집X) - 분석(Analysis) - 요구사항을 더욱 자세하고 정확하게 이해 - 요구사항 상세화 중복 제거 및 일관성 검사 등 품질평가 - 우선순위 - 모델링 - 명세 - 요구사항을 문서화 - 검증(Validation) - 요구사항이 정확하고 올바르고 빠짐없이 작성 되었는지 확인 - 비지니스 분석가(business analyst)가 이해관계자로부터 목표 시스탬에 바라는 요구는 식별하는 단계 - Scope and status : Project Management - Project Sponsor :..

- 사용자가 가치 제공을 받기 위해 사용자가 시스템을 통해 달성하고자 하는 목표나 수행하는 태스크 - 사용자로부터 비지니스 요구사항을 달성하기 위한 요구사항을 도출 - ex 비즈니스 요구사항 - 사용자 요구사항1 - 사용자 요구사항2 - 사용자 요구사항... - 사용자 요구사항m - ex) 카페테리아 주문 시스템 비즈니스 요구사항(목표) - 음식 낭비비용을 6개월 이내40% 감소 - 운용비용을 12개월 이내에 15%감소 - 평균 업무 집중 시간을 6개월 이내 직원당 15분 증가 사용자 요구사항 - 식자주문 - 메뉴생성 - 급여공제 등록 등 기능적 요구사항 - 고객이 급여공제에 등록되어 있는지 확인 - 고객이 선택한 날짜에 이용가능한 메뉴 표시 - 결제 금액 계산 - 사용자 요구사항을 달성할 수 있도록 개..

- eXtreme Programming(XP) - kanban - 크리스털 패밀리 - Feature-driven development - Adative software development - 익스트림 모델링 - 반복주기 : Spring(1~4 Week) -> 프로젝트의 일정은 고정 - Sprint를 통해서 최종적인 산출물(잠재적으로 출시 가능한 제품) : Increment - Sprint Backlog : Spring 동안에 수행해야하는 일 목록(목표) - Product Backlog : 우선순위에 따라서 해당 Spring 동안 해야할 일을 가져온다 - Sprint Planning Meeting : 해당 Sprint 동안에 해야될 일을 선정하는 것 -> 우선순위가 높은 순서대로 - Daily Scrum..

- 고객이 원하지 않는 제품을 만드는 것이 스타트업의 가장 큰 위험- - 아이디어를 빠르게 제품화 시킨 후 고객의 피드백을 반영하여 지속적으로 제품 개선 - 아이디어를 완벽한 제품으로 구현한 후 시장에 내놓고 고객의 검증을 받는 것이 아니라, 아이디어를 제품화 시키는 과정에서 고객의 피드백을 받아 시장이 원하는 제품을 만들겠다는 전략 1. 아이디어(가설 설정) 2. 만들기(MVP를 통한 가설 검증) 3. 제품 4. 측정 5. 데이터 6. 학습 *MVP(Most Viable Product, 최소기능제품) - 반드시 기능적으로 실제 동작되어야 할 필요는 없다 - 가설을 실험하고 학습하는 것은 일회성이 아닌 지속적인 과정 - 학습한 내용을 바탕으로 완전 새로운 제품으로 방향전환(pivot)가능 - 사용자의 지..