요구사항 도출 이해당사자들의 업무 지원을 위해 신규 시스템을 활용하는 방식을 이해하는 것 요구사항을 알아내기 위해 소프트웨어 엔지니어는 이해당사자들과 함께 일함 예 ) 응용 도메인, 업무 활동, 이해당사자들이 원하는 시스템 기능, 필요한 기능, 하드웨어 제약 등 요구사항 도출이 어려운 이유 애매하고 비현실적인 요구사항 아주 일반적인 용어로만 표현 타당하고 그른 것을 잘 모름 도메인 경험이 전제된 상태에서의 요구사항 요구사항을 전문용어를 사용해서 표현 → 경험 없는 요구사항 엔지니어는 이해 못 함 여러 명의 이해당사자들의 서로 다른 요구사항 → 요구사항 엔지니어는 요구사항에 대한 모든 잠재적 출처를 찾고 공통점과 상충점을 찾아내야 함 정치적 요소가 시스템 요구사항에 영향을 줄 수 있음 권력을 얻기 위해 관..

요구공학 프로세스에 대한 나선형 뷰 관련 활동들이 나선 형태의 반복 프로세스들로 구성 각 활동에 소요한 시간과 노력의 양은 특성에 따라 달라짐 요구사항 도출 및 분석 시스템 요구사항을 얻어내는 프로세스 기존 시스템 관찰, 업무 분석, 잠재적 사용 자 및 구매자와 토의 하나 이상의 시스템 모델과 프로토타입을 만들기도 함 → 명세할 시스템 이해에 도움 요구사항 명세화 요구사항을 담은 문서 작성 두 가지 유형의 요구사항이 포함될 수 있음 사용자 요구사항 : 시스템 요구사항에 대한 추상적인 문장들(고객과 시스템 최종 사용자용) 시스템 요구사항 : 제공할 기능에 대한 상세한 설명 포함 요구사항 검증 요구사항에 대한 현실성, 일관성, 완전성을 검사 요구사항 문서상의 오류를 발견하고 수정하여 문제를 바로잡아야 함 요..

요구사항과 요구공학 요구사항 한 시스템이 제공해야 하는 서비스들과 그 서비들의 동작에 관한 제약을 기술한 것 특정 목적을 제공하는 시스템에 대한 고객의 요구 반영 요구사항이라는 용어를 일관성 있게 사용하진 않음 사용자 요구사항 : 단순 시스템이 제공해야 하는 서비스에 대한 추상적 서술 및 시스템 제약사항 시스템 요구사항 : 시스템 기능에 대한 상세하고 정형화된 정의 요구사항 용어 정의 차이가 발생하는 이유 한 회사가 소프트웨어 개발 프로젝트에 대한 계약을 허용하려고 한다. 계약을 위해선 요구사항을 작성해야만 비용을 협상하고, 설루션을 제공해 줄 수 있다. 그렇기 때문에 회사 측에서는 요구사항을 작성해야만 한다. 그런데 회사 측에서는 아직 사전 정의된(구체적인) 요구들이 없기 때문에 회사에서는 매우 추상적..

대규모 시스템에 애자일 접근법 사용 대규모 시스템은 개발에 오랜 시간이 걸려서 몇 가지 문제점이 발생할 수 있다. 애자일 개발은 약식으로 진행 → 큰 기업에서는 계약 사항을 정하기 위한 법적 방식과는 안 맞음 애자일 기법은 소프트웨어 유지보수보다 소프트웨어 개발 때가 적합 → 큰 기업엣 발생하는 소프트웨어 비용은 대부분 기존 소프트웨어 시스템의 유지 보수 비용임 애자일 기법은 소규모이며 같은 장소에서 일하는 팀을 대상으로 고안 → 요즘 소프트웨어 개발은 전 세계에 분산된 팀에서 이뤄지는 경우가 많음 계약 관련 이슈 애자일 기법 사용 시 발생하는 주요 문제 소프트웨어 개발과 관련된 계약 (고객이 시스템 개발을 위해 외부 조직을 활용하는 경우) 소프트웨어 요구사항 문서(고객과 공급자 사이에 발생하는 계약의 ..

애자일 프로젝트 관리 소프트웨어가 계획된 예산 내에서 기한 내에 개발되어 배포되도록 하는 것 → 소프트웨어 관리자들의 주요 업무 계획 주도 접근법에서의 관리자들의 역할 애자일 개발은 팀이 사용할 수 있는 시간과 자원을 최대한 잘 이용하도록 애자일 기법을 관리 점증적 개발 및 애자일 방법에 사용되는 방식에 맞게 조정된 접근 방식 필요 스크럼 애자일 프로젝트를 조직화하기 위한 프레임워크를 제공, 진행 중인 내용에 대한 외부 가시화 제공하는 기법 조직에게 애자일 프레임워크를 제공하는데 초점(특정 개발 방법 강요 x) 스크럼 단계 1. 개요 계획 단계: 프로젝트의 일반적인 목표 설정 및 소프트웨어 구조 디자인 2. 일련의 스프린트 사이클들: 각 사이클은 시스템의 증가분을 개발 3. 프로젝트 종료 단계: 필수 문..

테스트 우선 철학 점증적 개발 방식 시스템 테스트를 위해 사용할 수 있는 시스템 명세가 없음 매우 비공식적인 방식으로 테스팅 프로세스 진행(계획 주도 테스팅 대비) 테스트 우선 개발 방법 테스트를 개발 프로세스의 중심에 둠 모든 테스트를 성공하기 전엔 개발을 진행 못함 XP에서 수행하는 테스팅의 주요 특징 테스트 우선 개발 시나리오를 가지는 점증적 테스트 개발 테스트 개발 및 검증에서 사용자 참여 테스트 자동화 프레임 워크 사용 테스트 주도 개발법(Test Driven Development) 테스트 우선 철학이 발전하여 일반화된 기법 코드 작성 전에 테스트 먼저 작성 코드를 작성하면서 테스트 실행 가능 개발 과정에서 문제점을 찾을 수 있음 테스트는 프로그램과 같이 작성되어야 함 ← 자동으로 테스트를 실행..

애자일 기법 등장 배경 예전엔 계획 주도 접근법이 주로 사용됨(1980년대 ~ 1990년대 초) 더 좋은 소프트웨어를 만들기 위해서 대규모의 소프트웨어 제작을 위한 방식이자 그런 시스템을 개발했던 공학단체로부터 비롯됨 예 ) 현대식 항공기 제어 시스템 - 초기 명세부터 배포까지 10년은 족히 걸림 계획, 설계 및 문서화에 오버헤드가 많이 발생 → 애자일 기법 등장 이유 무거운 접근법에 대한 불만 때문에 애자일 기법 등장(1990년대 말) 개발팀이 설계와 문서작업보다 소프트웨어 개발 자체에 더 집중 요구사항이 자주 변경되는 어플 개발할 때 적합한 방식 유용한 소프트웨어를 빠르게 만들 수 있도록 고안(신속한 소프트웨어 개발) 신속한 소프트웨어 개발의 필요성 비즈니스 시스템에서 가장 중요한 요구사항 ← 새로운..

소프트웨어 프로세스 모델 일반적인 소프트웨어 프로세스 모델 폭포수 모델 기본적인 프로세스 활동으로 명세화, 개발, 검증, 진화 거침 개별적인 프로세스 단계로 모델을 나타냄 점증적 개발 명세화, 개발 및 검증 활동이 서로 중첩되는 접근법 연속적인 버전을 통해 시스템 개발(각각의 버전은 이전버전에 기능 추가) 통합 및 환경 설정(재사용 지향 소프트웨어 공학) 재사용 가능한 컴포넌트나 시스템의 사용가능 여부에 의존하는 접근법 사용할 컴포넌트들을 조합하고 하나의 시스템으로 통합하는데 중점 폭포수 모델( = 소프트웨어 생명 주기) 대규모 군사 시스템 개발에 사용했던 공학 프로세스 모델 기반 계획 주도 프로세스의 한 종료 → 개발 시작 전 모든 활동에 대한 일정 계획 필요 각 단계는 기본적인 소프트웨어 개발 활동을..