기록공간

요구사항 확인 기법 요구사항 확인 기법은 요구사항 개발 과정을 거쳐 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법이다. 요구사항에 자원이 배정되기 전에 문제 파악을 위한 검증을 수행해야 한다. 요구사항 확인 기법에는 요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트 등이 있다. 요구사항 검토(Requirement Reviews) 요구사항 검토는 문서화된 요구사항을 훑어보면서 확인하는 것으로 가장 일반적인 요구사항 검증 방법이다. 요구사항 검토자들은 요구사항 검토를 통해 명확하지 않은 내용은 없는지, 가정이 잘못되지는 않았는지, 정해놓은 기준을 벗어나지는 않는지 등을 찾아낸다. 요구사항 검토자 그룹을 구성할 때는 구성 방법이 중요하다. 예를 들어 고객 중심 프로젝터에 대한 검토자 그룹에는 고객..

요구사항 분석 기법 요구사항 분석 기법은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법이다. 요구사항 분석 기법에는 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석 등이 있다. 요구사항 분류(Requirement Classification) 요구사항을 명확히 확인할 수 있도록 다음과 같은 기준으로 분류한다. 기능 요구사항과 비기능 요구사항으로 분류한다. 하나 이상의 상위 요구사항에서 유도된 것인지 또는 이해관계자나 다른 원천으로부터 직접 발생한 것인지 분류한다. 개발할 제품에 관한 것인지 개발 과정(프로세스)에 관한 것인지 분류한다. 우선순위에 따라 분류한다. 소프트웨어에 미치는 영향의 범위에 따라 분류한다. 소프트웨어 생명 주기 동안에..

요구사항의 개념 및 특징 요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타낸다. 요구사항은 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다. 요구사항은 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다. 요구사항이 제대로 정의되어야만 이를 토대로 이후 과정의 목표와 계획을 수립할 수 있다. 요구사항의 유형 요구사항은 일반적으로 기술하는 내용에 따라 기능 요구사항과 비기능 요구사항으로 구분하며, 기술 관점과 대상의 범위에 따라 시스템 요구사항과 사용자 요구사항으로 나눈다. 기능 요구사항(Functional requirem..

개발 기술 환경의 정의 개발하고자 하는 소프트웨어와 관련된 운영체제(Operation System), 데이터베이스 관리 시스템(Database Management System), 미들웨어(Middle Ware, 운영체제와 프로그램 사이에서 운영체제가 제공하는 기능 외 추가적인 기능을 제공하는 소프트웨어) 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스 사용 시 주의해야 할 내용을 제시한다. 운영체제(OS, Operation System) 운영체제는 컴퓨터 시스템의 자원들을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어이다. 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종으로, 다른 응용 프로그램이 유용..

현행 시스템 파악 절차 새로 개발하려는 시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템의 구성과 제공 기능, 시스템 간의 전달 정보 사용되는 기술 요소, 소프트웨어, 하드웨어, 그리고 네트워크의 구성 등을 파악한다. 시스템 구성 파악 현행 시스템의 구성은 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술한다. -> 조직 내에 있는 모든 정보 시스템의 현황을 파악할 수 있도록 각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요 기능들을 명시한다. 시스템 기능 파악 현행 시스템의 기능은 단위 업무 시스템이 현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시한다. 시스템 인터페이스 파악 현행 시스템의 인터페이스에는 단위 업무 시스템..

XP(eXtreme Programming) XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법이다. XP는 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다. 릴리즈(요구사항이 적용된 부분적 기능이 완료된 제품을 제공)의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성(대상을 확인할 수 있는 정도)을 높인다. 릴리즈 테스트마다 고객을 직접 참여시킴으로써 요구한 기능이 제대로 작동하는지 고객이 직접 확인할 수 있다. 비교적 소규모 인원의 개발 프로젝트에 효율적이다. XP의 5가지 핵심 가치 : 의사소통(Communication), 단순성(Si..

개요 스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형을 말한다. 스크럼은 이처럼 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어이다. 스크럼은 팀원 스스로가 스크럼 팀을 구성(self-organizing) 해야 하며, 개발 작업에 관한 모든 것을 스스로 해결(cross-functional)할 수 있어야 한다. 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성된다. 제품 책임자(PO : Product Owner) 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당한다. 이해관계자들의 의견을 종합하여 제품에 대한 요..

소프트웨어 생명 주기(Software Life Cycle) 소프트웨어 생명 주기는 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다. 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동 그리고 활동의 결과에 대한 산출물로 표현한다. 소프트웨어 수명주기라고도 한다. 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형이라고 하며, 소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임이라고도 한다. 개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수도 있고, 개별적인 모형을 사용할 수도 있다. 일반적으로 사용되는 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입..