본문 바로가기

전공/소프트웨어공학

 (10)
Defect testing Defect testing - 프로그램에 있는 결함들을 발견하는게 목표 - 성공적인 결함 테스트는 프로그램이 비정상적인 방식으로 동작하게 하는 것 - 테스트는 결함의 부재가 아닌 결함의 존재를 보이는 것 Bloack-box tesing - 프로그램을 black-box로 생각하고 테스팅을 수행 - 내부 구조를 신경쓰지 않고 입력 값에 대한 출력값만 테스팅 White testing = Structural testing - 프로그램 구조에 따라 테스트 케이스들을 유도. - 입력 값에 대한 프로그램 내부의 모든 결과를 시험 해보는 것 Path tesing - 프로그램에 있는 모든 경로가 적어도 한 번은 실행되도록 테스트 케이스들의 집합을 구성 cyclomatic complexity - 모든 제어 문장들을 시험하..
소프트웨어 감사(inspections) 소프트웨어 감사(inspections) - 모순(anmalies)과 결함을 발견할 목적으로 소스 표현을 검사 - 시스템 실행 필요 X, 구현 전에 사용 가능 - 시스템의 어떠한 표현(requirments, design, test data 등)에도 적용 가능 - 오류 발견에 매우 효과적 inspection and testing - 서로 대립하는게 아닌 보완적인 관계 - 양쪽 다 V&V프로세스 중에 사용됨 - 감사는 명세서와 일치하는지 알아볼 수 있으나, 고객의 실제 요구사항에 일치하는지, 성능과 사용성과 같은 비기능적 요구사항을 검사하는 등은 할 수 없음 Program inspection - 문서 검토를 위한 정형화된 접근법 - 결함 수정이 아닌 검출에 중점을 둠 - 결함들은 논리적 오류, 잘못된 상황, ..
검증과 확인(V & V = Verification and Validation) 검증과 확인(V & V = Verification and Validation) - 소프트웨어 시스템이 사용자의 요구를 만족한다는 것을 보증하는 것. Validation(확인) - 사용자 요구사항을 전부 만듬. Verification(검증) - 사용자가 요구한 시스템 요구사항까지 모두 만족. 명세서와 일치해야함 V&V process의 목적 1. 시스템의 결함(defects) 발견 2. 실제 운용 환경에서 시스템이 사용 가능한지의 여부에 대한 평가 static(정적) and dynamic(동적) verification static verification - 소프트웨어의 감사(inspections) 문제들을 발견하기 위해 시스템에 대한 정적 분석을 수행 dynamic verification - 소프트웨어의 동..
설계 개념과 원리 분석과 설계 Analysis = 분석. 요구사항을 분석. 전달한다는 의미 Design = 디자인. 설계도 or 모델을 그림으로 표현하는 것 설계 원리 - 설계 프로세스는 Tunnel vision이 아니어야한다. Tunnel vision : 좁은 시야. 설계 요구사항 파트에서 전체 구조를 보지못하고 일부분만 보는 것. - 설계 와 코딩은 다르다. - 실제 구현이 가능해야한다. - 분석 모델로 추적이 가능해야한다. - 기존에 있던 것을 재발명하면 안된다. - 변경 수용이 가능해야한다. 용어 정리 abstraction(추상화) - 데이터, 프로시저, 컨트롤 등 refinement - 모든 추상화에 대해 상세한 내용을들을 기술함 modularity - 데이터와 함수의 구획화architecture - 소프트웨어의..
시스템 모델 시스템 모델(System model) : 요구사항을 분석 중인 시스템에 대한 추상화된 표현 시스템 모델링(System modeling) : 분석가가 시스템의 기능을 이해하는 것을 도와주며 모델은 고객과 정보를 교환하기 위해 사용. 시스템 표현의 여러 관점 1. External perspective : 시스템의 볌위 또는 환경을 보여줌 2. Behavioral perspective : 시스템의 행동을 보여줌 3. Structural perspective : 시스템 구조 or 데이터 구조를 보여줌 Context model : 시스템의 범위를 설명하기 위해 사용. 환경에서 시스템 위치를 다른 시스템들, 프로세스들과 함께 보여줌 : Context - 상황. 전체적인 그림. 전반적인 구조. 추상화된 표현 Data..
요구 공학 프로세스 요구공학 프로세스 : 어플리케이션 도메인, 개발자, 조직에 따라 다르지만 공통적인 부분이 있음 : 요구사항 유도(elicitation), 분석(analysis), 확인(validation), 관리(management) 가능성 분석 : 제안된 시스템이 할 만한 가치가 있나? : 조직의 목적에 기여 가능? 현재 시스템과 통합되나? 현재 기술과 예산으로 개발이 가능한가? 유도 및 분석 : 요구사항 유도 or 발견이라 불린 : 직원과 고객이 함께 만듬. 도메인, 서비스, 제한사항 등을 찾음. : 최종 사용자, 개발자, 관리자, 공학자, 도메인 전문가, 마케팅 관계자 => Stakeholder : Stakeholder는 자기 분야 외에는 잘 모름, 뭘 원하는지 모름, 의견 차이가 있을 수 있음. : 조직 or 정..
요구 사항과 설계 요구사항이란? : 시스템이 무엇을 하는지 언급하는 것. 그것의 동작 및 구현에 대한 제한 사항을 정의 : 기능적 요구사항 - 시스템이 제공할 서비스 : 비기능적 요구사항 - 개발되는 시스템 또는 개발 프로세스에 대한 제한 사항 : 사용자 요구사항 - 시스템이 무엇을 수행해야하는가? 에 대한 고수준의 문장 설계란? : 시스템이 그것을 어떻게 하는지 설명하는 것 실제로는 둘이 잘 분리 되지 않음. 왜? : 시스템 구조가 요구 사항 구조화를 위해 설계 될 수 있음 : 시스템은 설계 요구사항을 생성하는 다른 시스템들과 상호 운영 가능 : 특정한 설계 방법 사용이 도메인 요구사항이 될 수 있음 자연언어 명세화의 문제점 1. 모호성(Ambiguity) : 요구사항의 작성자와 독자가 같은 문구를 동일한 방식으로 해석..
소프트웨어 요구사항 요구 공학(Requirements engineering) : 고객이 시스템으로부터 필요로 하는 기능들, 그리고 시스템이 동작하고 개발되는 것에 대한 제한사항을 설정하는 과정 : 요구사항은 요구 공학 프로세스 동안 생성되는 시스템 기능 및 제한사항에 대한 설명 요구사항이란? : 시스템의 기능 또는 제약 조건에 대한 고수준의 추상적 문장으로부터 상세한 수학적인 기능 명세서까지 포함 : 계약을 위한 시도(제안) or 계약서 자체(상세하게) 의 목적으로 사용됨 요구사항 종류 1. 사용자 요구사항 - vaild : 시스템이 제공하는 기능과 제약 조건에 대해 자연 언어 + 다이어그램으로 작성, 고객을 위해 작성됨 : 해당 영역에 기술적 지식이 없는 사람이 이해할 수 있도록 적어줘야함 자연 언어의 문재점 : 명확성의..

티스토리툴바