일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- UNIX
- FreeBSD
- getopts
- newSQL
- Windows via c/c++
- 구조와 원리
- Programming
- TiDB
- Preprocessor
- 약어
- 전처리기
- DBMS
- 포인터
- OS 커널
- UNIX Internals
- TiKV
- Golang
- bash
- Symbol
- 한빛미디어
- 포인터변수
- kernel
- DBMS 개발
- 긴옵션
- 커널
- SQLite
- 함수포인터
- 컴퓨터 강좌
- Pointer
- go
- Today
- Total
목록개발자 이야기/Software Engineering (7)
sonumb
Prelude: 누가 내 테스트를 옮겼을까? 요즘 테스트 추세로는 대개 유닛테스트가 기본이지만, 리그레션 테스트는 선택적인 듯한 느낌이다. 이유가 여러 가지 있겠지만, 리그레션 테스트를 위한 구축/유지하는 비용이 막대하다. 테스트 정책 수립 테스트 프레임워크 구축 테스트 전용 인터프리터 개발 및 유지 보수 테스트 케이스 유지 보수 위의 두 가지만 하더라도, 테스트 전략을 위한 전문가와 프레임워크 구축을 위한 개발자가 필요하다. 더군다나, 테스트 대상에 따라서 테스트 프레임워크를 따로 구축해야 하는 가능성이 매우 높다. (범용성이 떨어짐..) . 큰 비용... 그러나 장기적인 관점에서 바라본다면, 그리 큰 비용은 아닐 것이다. (error가 defect가 되는 순간 그 댓가는... 생각만해도 끔찍하다.) ..
1. Architecture의 4+1 관점 "+ 1 view"는 사용자의 관점(view)이며, "4 view"는 소프트웨어 개발 입장(구현 및 배포)의 view 이다. 일반적인 소프트웨어 개발 프로세스는 아래와 같다. 요구사항수집 Scenario View(User View): 요구사항 분석이후, 사용자 관점에서 본 소프트웨어 use case 혹은 use scenario이다. 설계 사전설계(개념설계) Logical view: 요구사항명세서+사용시나리오를 통해 큰 그림과 각 세부 모듈을 선언 및 설계한다.(단, 상세한 내용은 정의 하지 않는다) Process View: 로지컬 뷰에서 선언된 세부 모듈들이 어떻게 상호작용하는지 설계한다.(유즈케이스 혹은 사용시나리오로가 근거이며, 세세한 정의는 하지 않는다.)..
목차 1. 문제상황 및 요구사항 1.1. 문제상황 1.2. 요구사항 2. 설계 2.1. 전체 구조 2.2. 쉘 스크립트 구현 2.2.1. 함수 목록 및 설명 2.2.2. 함수 명세 3. 구현 3.1. 코드 4. 테스트 4.1. 예제: 트랜잭션 제어 4.1.1. 코드 4.1.2. 실행 및 결과 1. 문제상황 및 요구사항 1.1. 문제상황 여러 클라이언트가 각자의 SQL을 실행하는 테스트가 있다고 가정하자. 이때, 각 클라이언트의 SQL 실행 순서를 제어해야 하는 경우가 있다. 예를 들어, Client 1 Client 2 1 create test database & test table 'tbl' 2 transaction start; 3 transaction start; 4 insert into tbl val..
소프트웨어 설계 문서 속성 가치 발행 번호 프로젝트 제목 팀 이름 이름 날짜 ℹ️ 설계 단계는 두단계로 나뉜다. 개념 설계 (conceptual design) (혹은 사전설계:preliminary design) 상세 설계 (detailed design) 각 단계별 내용과 산출물은 아래와 같이 정의될 수 있다. 개념 설계 시스템의 구조 설계 기능을 분해하여 모듈 구조 (모듈 자체의 기능, I/O 설계) 모듈이름 모듈형 인터페이스 오류메시지 사용하는 파일 호출하는 모듈 기능설명 모듈 간의 관계를 정립(모듈 인터페이스) 자료설계(데이터베이스 설계) 결과 시스템 구조도(Structure Chart) 외부 파일 및 DB 설계도(레코드 레이아웃, ERD) 상세 설계 모듈 내부 설계 모듈별로 아래 내용을 기술 자료구..
메타 데이터의 끝으로 건너뛰기메타 데이터의 시작으로 이동Software Design Document속성값Issue Number Project Title Team Name Name Date 목차1. INTRODUCTION1.1. Purpose1.2. Scope1.3. Overview1.4. Reference Material1.5. Definitions and Acronyms2. SYSTEM OVERVIEW3. SYSTEM ARCHITECTURE3.1. Architectural Design3.2. Decomposition Description3.3. Design Rationale4. DATA DESIGN4.1. Data Description4.2. Data Dictionary5. COMPONENT DESIG..
메타 데이터의 끝으로 건너뛰기메타 데이터의 시작으로 이동Software Design에 관한 내용들을 정리한다.목차1. Software Design 개요2. Hierarchy2.1. 개념 설계2.2. 상세설계3. Template1. Software Design 개요설계라는 말은 사실 건축 용어이다.컴퓨터 공학자들이 정교하면서도 견고한 소프트웨어를 만들기 위해 건축 공정의 개념을 빌려 쓴 것이라고 볼 수 있다.건물을 지을 때 건축물의 품질을 유지하기 위하여,청사진, 설계도, 일정표, 예산 등등 여러 요소들(입력물)이 필요하며,입력물을 어떻게 배치하고 이용할 것인가에 관한 공정과이런 입력물에 따른 산출물 등도 요구 된다.소프트웨어 작성 과정을 건물을 짓는 과정과 비슷하다. 즉 소프트웨어 개발은 개발과정의 입력..
메타 데이터의 끝으로 건너뛰기메타 데이터의 시작으로 이동This is a sample of Requirements Specification.목차Requirements Specification1. Executive Summary1.1. Project Overview1.2. Purpose and Scope of this Specification2. Product/Service Description2.1. Product Context2.2. User Characteristics2.3. Assumptions2.4. Constraints2.5. Dependencies3. Requirements3.1. Functional Requirements3.2. User Interface Requirements3.3. Usa..