소프트웨어 테스트의 목적• 잠재적 오류와 결함의 발견• 요구사항의 준수 여부(기능/비기능) 확인• 소프트웨어 신뢰성 등 품질 확인 오류를 발견하기 위한 활동으로, 테스팅이 오류가 없음을 확인시켜 주지는 않음 테스팅의 원칙 - 개발자가 자신의 프로그램을 직접 테스팅하지 않음 - 테스팅의 목적은 결함이 존재함을 밝히는 것 - 완벽한 테스팅은 불가능 - 개발 초기에 테스팅 시작 살충제 패러독스동일한 테스트를 반복하면 새로운 결함을 찾기 어려워, 테스트 케이스를 주기적으로 개선해야 한다. 테스트에 대한 시각검증: 개발 단계의 산출물이 설정된 조건을 만족하는 지 평가 (소프트웨어 프로세스가 잘 진행되는 지 평가)확인: 요구사항들을 만족하는 지 평가 테스트의 목적회복 테스트: 고의적 실패 유도보안 테스트: 불법..

1. 위험 관리 위험 관리 절차 1. 위험 식별(일반적인 프로젝트 위험 리스트 + 이전 유사 프로젝트 위험 리스트)=> 브레인 스토밍, 조사, 인터뷰=> (현재 프로젝트 위험 리스트: 분야, 위험 요소, 원인) 2. 위험 계량화식별된 위험 요소들은 발생 확률과 영향도에 따라 구분 (상, 중, 하) 3. 위험 우선순위 선정우선순위를 설정하여 대응책을 만들고 위험을 관리 4. 위험 관리 계획위험 관리 계획에는 위험을 언제, 어떠한 방법으로 관리할 것인가에 대한 내용 등이 포함 5. 위험 해결위험은 어느 시점에나 문제로 발생할 수 있으므로, 위험 관리는 프로젝트 초반부터 프로젝트 종료 시까지 수행해야하고주기 별로 식별된 위험 요소에 대한 평가가 수행되어야 함 6. 결과 측정 및 문서화대응 방안에 ..

소프트웨어 설계요구사항 명세서를 토대로 소프트웨어의 뼈대를 이루는 구조를 정의해 구현의 기반을 만드는 것요구사항 명세서는 What 관점, 설계는 How 관점 상위 설계 (=아키텍쳐 설계) - 구성 모듈들의 관계로 표현되는 시스템 전체 구조 - 시스템 구조도, 외부 피일 및 DB 설계(ERD), 인터페이스 설계하위 설계 (=모듈 설계) - 모듈의 내부 구조, 동적 행위등을 결정 - 모듈 설계, 알고리즘 설계등 포함 좋은 설계: 모듈이 독립적이어야 하고, 모듈 간의 결합이 낮게 설계되어야함 프로세스 지항 설계: 처리 절차를 중심으로 설계 (기능, 데이터 분리) 객체 지향 설계: 객체 요소를 중심으로 설계 (기능, 데이터 객체 단위로 뭉쳐짐) 설계 원리 (1) 추상화필요 정보만 추출하여 강조하고, 관련 없..

구조적 분석은 DFD를 이용하여 기능 중심으로 요구사항을 분석객체지향 분석에서는 유스케이스 다이어그램을 이용하여 사용자 상호작용 중심으로 요구사항을 분석정보공학 분석에서는 ER 다이어그램을 이용하여 정보 중심으로 요구사항을 분석 유스케이스 기반 분석 프로세스 - 유즈케이스 방법론 ⊂ UML(표준 모델링 언어) - 시스템이 어떻게 사용될 지에 대해, 표준화된 문법으로 표현, 규칙이 단순하여 쉽게 이해 가능 시스템 구축 시 UML의 역할 - 텍스트로 적기에는 애매한 부분을 직관적으로 표현 가능 모델링 방법론 부치 방법론 (4+1 뷰) - 시스템을 여러 개의 뷰로 분석하여 모델링럼바의 OMT - 시스템을 기술하기 위하여 3가지 모델을 사용 - 객체 모델: 정적 구조 (클래스, 객체) - 기능 모델: 데이터..

요구사항 : 문제의 해결을 위하여 시스템이 가져야 하는 기능 또는 제약조건- 고객이 직접 요구한 사항 - 고객 마음 속에 내포된 사항 - 요구하지 않았더라도 당연히 제공될 것이라고 생각되는 사항 요구사항 분석의 중요성 - 참여자들로 하여금 개발되는 소프트웨어 제품을 전체적으로 파악하게 함으로써 의사소통 시간을 절약 - 상세한 요구사항 있어야 규모 산정이 가능하고, 이를 기반으로 계획을 세울 수 있음 요구사항의 분류 - 기능적 요구사항 (Functional Requirements): 소프트웨어가 가져야 하는 기능적 속성 (ex. 파일 저장 기능, 편집 기능, 보기 기능) target SW specific, 사용자로부터 얻어낼 수 있다 - 비기능적 요구사항 (Non-Functional Re..

프로젝트 계획서참여자 모두가 프로젝트를 진행하면서 참조하는 프로젝트의 중심이 되는 문서 프로젝트 관리자는 - 프로젝트 태스크 파악 - 각 태스크를 수행하기 위해 필요한 노력 예측 - 인적 및 기타 자원을 각 태스크에 할당 - 일정 계획 수립프로젝트 참여자의 검토를 거처 합의 하에 채택 프로젝트 진행 과정의 주기적 통제의 기본프로젝트 계획서가 현실적으로 작성되어 전체 프로젝트 진행사항 파악이 용이해야 함 국제 표준 - IEEE 1058.1 규모 산정 : 프로젝트 수행에 필요한 규모(Size), 공수(Effort), 비용(Cost) 등을 정량적으로 예측하는 것 - 경험적 방법 : 프로젝트의 노력과 시간을 경험적 전문가들이 예측하는 방식 (가장 정확), 예: 델파이 기법(Delphi) - 크기 중심 방법 :..

프로젝트 - 특정 기간 내, 특정 목적을 위해 하는 일련의 행위 - 일상 생활과는 구분되는 유일한 제품이나 서비스를 만들기 위해 수행되어야 할 일시적인 행동 프로젝트의 성공 vs 실패 (1) 어떤 프로젝트가 성공? - 실현 가능한 구체적 계획 - 명확한 기술 사항 - 원활하고 체계적인 의사소통 - 효과적인 팀워크 - 정교한 비용 및 일정 제어 - 신속한 의사결정 (2) 어떤 프로젝트가 실패? - 프로젝트의 수행에 필요한 지식이 없거나, - 프로젝트를 효과적으로 수행하고자 하는 의지가 없어서 프로젝트의 성공 요소 : 일정(Time), 비용(Cost), 품질(Quality) 국내 프로젝트의 현실 - 명확하지 않은 요구사항과 잦은 변경 - 프로세스와 방법론의 부재로 일정 지연 및 비용 초과 - 열약한 개발..

Software - 원하는 기능과 성능을 제공하는 프로그램 - 프로그램의 사용과 동작을 설명한 문서들 소프트웨어의 특징 : 비가시성, 비마모성, 요구사항의 변경과 주변 환경의 변화에 따라 계속 수정되고 진화소프트웨어의 위기 : 소프트웨어 수요 증가에 비해 공급 및 개발의 어려움 소프트웨어 공학 정의 : 소프트웨어의 개발, 운용, 유지보수 및 폐기에 대한 체계적인 접근방법목표 : 소프트웨어 개발이 체계적이고 공학적인 방법으로 이루어져서, 제한된 비용과 기간 내에 고객이 원하는 품질 높은 소프트웨어를 개발 고객의 요구 → 요구사항 분석 → 설계 → 구현 → 테스팅 → S/W 제품 소프트웨어 공학의 영역들 개발 방법론 : 시스템 개발을 어떠한 방법으로 진행할 것인가를 다루는 분야요구공학..