다양한 기록

테스트 주도 개발: 테스트 주도가 되는 개발 방식테스트 코드를 먼저 개발한 후에 애플리케이션 코드를 개발하는 방식TDD는 테스트 방식이 아닌 프로그램 개발 방식이며 TDD의 목적은 단순한 코드를 얻는 것단순한 코드란 문제에 대한 가장 간단한 해결책을 제공하는 동시에 깨끗한 코드  TDD 규칙- 실패하는 테스트를 통과하는 코드를 작성하는 것을 제외하고는 먼저 절대 제품 코드를 작성하지 않는다- 테스트 코드를 작성할 때 실패할 만큼만 작성- 테스트를 통과할 만큼만 제품 코드를 작성한다 실패하는 테스트 => 현재의 애플리케이션 코드가 충분히 구현되지 않았거나 오류가 있는 의미애플리케이션 코드에 기능을 추가하기 전에 실패하는 테스트 코드를 작성 ex. 계산기1@Testpublic void testAdd(){ ..

일반적인 소프트웨어 테스트 목적- 소프트웨어 내에 존재하는 오류 발견- 소프트웨어 요구사항에 충족하는지 확인- 소프트웨어 출시 이후 발생할 수 있는 결함을 예방 소프트웨어 테스트의 부가적 목적- 소프트웨어 품질에 대한 자신감 획득과 정보 확인- 비즈니스 리스크를 감소시킬 수 있도록 정보에 근거한 조언 제공- 개발 프로세스 점검 및 이유 제공- 시스템과 소프트웨어가 적절히 동작함을 확인 블랙 박스 테스팅 (Black Box Testing)정의- 프로그램을 블랙박스로 취급, 내부 구조를 참조하지 않고 주어진 입력에 요구되는 결과가 나오는가를 시험- 프로그램과 외부와의 인터페이스에 대하여 시험이 이루어짐- 프로그램의 기능에 초점, 주어진 입력값들의 조합에 의해 요구되는 결과가 나오는가를 점검- 설계 명세서 또..

개발하는, 또는 개발된 소프트웨어가 제대로 동작하고 있는지 검증하는 단계코드속에 에러가 있음을 증명하는 것이 목적코드를 육안으로 읽거나, 실제 데이터를 주고 실행하면서 테스팅완벽한 테스팅은 불가능테스팅의 두가지 형태- 실행 기반 테스팅 (동적 테스팅) : 프로그램에 데이터를 적용해서 실행- 비실행 기반 테스팅 (정적 테스팅) : 문서를 육안으로 검사 V&V검증(Verification) : 과정 및 프로세스에 중점 (Is it right?)- 각 개발 단계에서 정확하게 수행됐는지를 결정하는 프로세스- 요구사항 명세대로 개발이 이루어지는 지를 검사확인(Validation) : 최종 제품에 중점 (Is it correct)- 최종 프로덕트가 그것의 요구사항을 모두 만족하는지를 결정하는 프로세스실수(Mistak..

Development + Operation 등장 배경- 소프트웨어가 단순 비즈니스를 지원한 기능을 넘어 새로운 비즈니스를 창출하거나 기존 비즈니스를 주도하는 핵심으로 성장- 기존의 SW 개발 방식과 운영(배포) 방식으로는 소비자가 원하는 서비스 신속히 제공 불가 기존 개발 체계 및 문제- 개발 팀은 개발, QA는 테스팅하고 운영팀에 이관 (별도의 팀)- 그 뒤 운영팀이 배포 및 관리 운영 시 개발팀 관여 안함 - 서비스에서 문제 생기면 서로 떠넘기기기존 문제 해결 방식- 문제 발견 단계(누가 해결?)- 책임 회피 단계- 갈등 단계- 조정 단계(팀장의 역할 중요)- 이제서야 문제 해결=> 시간이 오래 걸리고 갈등이 남음 => 이직, 비용 손실, 서비스 저하 기존 개발 팀 관리의 문제- 개발 팀은 프로덕트가..

구현(Implementation)- 상세 설계를 코드로 변환하는 프로세스프로덕트- 프로덕트의 다른 컴포넌트를 동시에 팀이 맡아 구현 경우에 따라서는 코딩과 단위 테스팅을 합하여 구현이라 정의 구현 언어의 선택- 비용-이익 분석을 사용하여 결정- 추정 이익과 추정 비용 간의 차이가 커서 가장 기대가 되는 언어가 적합 1세대 언어- 이진수 기계어 코드2세대 언어- 어셈블리어3세대 언어- 한 문장은 5~10개의 어셈블리어- 포트란, 코볼부터 C, C++4세대 언어- 내가 원하는 것이 이거다 하면 알아서.. SQL5세대 언어- 그냥 툴, 드래그 앤 드랍 * 4세대 언어- 30 ~ 50개의 기계 코드 명령어와 동등- 비절차적 언어 자기문서화 코딩- 다른 프로그래머와 품질 보증 활동을 하는 SQA 그룹, 또 많은 ..

- 분석된 요구사항 명세서를 참조하여 개발자가 실제적으로 개발할 수 있는 문서를 작성하는 과정- 설계 목표를 설정하고 아키텍처안을 만든 후 최적의 설계- 시스템 구조에 대한 설계, 모듈 설계, 자료에 대한 설계, 사용자 인터페이스 설계, 통신 방법에 대한 설계 등- 설계 작업의 결과는 명세서로 작성되며 이 명세서는 프로그래밍을 위한 도면 역할 설계의 두 단계Architectural Design (구조 설계, 초벌 설계, 상위 설계, 개략 설계)- 시스템의 전체적인 구조(아키텍처)를 파악Detailed Design (모듈 설계, 상세 설계, 하위 설계)- 각 모듈별로 구체적인 알고리즘 레벨까지 정의개략 설계- 초벌 설계, 구조 설계, 아키텍처 설계 등으로도 불림- 개발할 시스템의 모듈들끼리의 구조를 보여줌..

다양한 Task와 방법들을 통하여 고객의 요구사항들을 이해요구사항 엔지니어링은 설계와 구축을 이어주는 기반 Requirement Engineering Tasks- Elicitation (추출)- Elaboration (정제)- Negotiation (조정)- Specification (정의)- Validation (검증)- Requirement management (관리) : 변화 관리 1. Elicitation (추출)모든 stakeholder로부터 요구사항을 도출- 문제들* 범위(Domain)의 문제>> 불명확하거나 불필요한 기술적 세부 사항들* 이해의 문제>> 컴퓨팅 환경의 제약 조건과 성능에 대한 미진한 이해, 문제 영역 전반에 걸친 이해 부족, 명확한 것으로 판단되는 정보 생략에 따른 이해 부족..

CMM (Capability Maturity Mode)목표:조직에서 사용중인 소프트웨어 프로세스에 있는 현재 결점에 집중해서조직이 해당 프로세스를 개선할 수 있는 방법을 알려줌SEI(Software Engineering Institute)가 설립되어 관리 종류:SW-CMM : 소프트웨어 관리P-CMM : 인적 자원 관리SE-CMM : 시스템 엔지니어링IPD-CMM : 통합 프로덕트 개발SA-CMM : 소프트웨어 획득 CMMI (Capability Maturity Model Integration)- 다섯개의 기존 모델을 통합CMM의 정의- 소프트웨어 프로세스를 정의, 구현, 측정, 제어 및 개선하는 동안에 소프트웨어 조직의 프로세스 발전 단계를 기술- 소프트웨어 프로세스 개선 전략을 수립하는데 지침서로 활..