KR20130058348A - 자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법 - Google Patents

자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법 Download PDF

Info

Publication number
KR20130058348A
KR20130058348A KR1020110124307A KR20110124307A KR20130058348A KR 20130058348 A KR20130058348 A KR 20130058348A KR 1020110124307 A KR1020110124307 A KR 1020110124307A KR 20110124307 A KR20110124307 A KR 20110124307A KR 20130058348 A KR20130058348 A KR 20130058348A
Authority
KR
South Korea
Prior art keywords
requirement
requirements
work flow
activity
simulator
Prior art date
Application number
KR1020110124307A
Other languages
English (en)
Other versions
KR101508496B1 (ko
Inventor
박수용
박수진
인호
김능회
Original Assignee
서강대학교산학협력단
고려대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 서강대학교산학협력단, 고려대학교 산학협력단 filed Critical 서강대학교산학협력단
Priority to KR20110124307A priority Critical patent/KR101508496B1/ko
Publication of KR20130058348A publication Critical patent/KR20130058348A/ko
Application granted granted Critical
Publication of KR101508496B1 publication Critical patent/KR101508496B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0633Workflow analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • General Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Software Systems (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Primary Health Care (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Human Computer Interaction (AREA)
  • Stored Programmes (AREA)

Abstract

본 발명은 자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법에 관한 것으로, 본 발명의 일 실시예에 따른 시뮬레이터가 요구사항을 관리하는 방법은, 도메인(domain)별로 요구사항에 따라 검증된 일련의 자산(asset)을 저장하고, 새로운 소프트웨어 개발에 따른 요구사항을 고려하여 자산 중에서 사용자에 의해 선택된 요구사항 및 관련 자산을 독출하여 시각적인 작업 플로우(flow)로 표시하고 사용자의 선택에 의해 작업 플로우 내의 작업 요소인 액티비티(activity)에 대해 추가, 삭제, 변경 중 어느 하나를 수행하여 새로운 소프트웨어 개발에 대한 요구사항을 생성하고, 생성된 요구사항별로 입력, 연산 및 출력에 따른 속성 데이터를 입력받아 작업 플로우의 비용을 산출하고, 산출된 비용을 고려하여 작업 플로우의 개별 액티비티에 대한 선택을 사용자로부터 입력받고 입력에 따라 조정된 작업 플로우를 생성하며, 조정된 작업 플로우를 새로운 자산으로서 저장한다.

Description

자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법{Asset based requirements simulator and requirements management method thereof}
본 발명은 요구사항을 관리하는 시뮬레이터 및 그 관리 방법에 관한 것으로, 특히 새로운 소프트웨어 개발을 위해 최종 사용자(end user)로부터 요구사항을 수집하고 수집된 요구사항을 이미 구축된 자산을 재사용하여 새로운 자산을 생성하는 자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법, 그리고 그 방법을 기록한 기록매체에 관한 것이다.
전통적으로 소프트웨어의 개발 환경은 개발의 주체가 전문적인 교육을 받은 개발자들의 영역이었다. 전문 개발자들에게 의해 소프트웨어 개발을 위한 요구사항(requirement)이 수집되고, 이러한 요구사항들은 개발 환경과 개발 수단의 제약들을 고려하여 적절히 가감되거나 조정된다. 이러한 과정을 통해 개발 환경과 시스템의 다양한 제약에 최적화되어 제작된 소프트웨어는 개발자 친화적일 수밖에 없다.
최근 이러한 소프트웨어 개발 환경은 종래와는 달리 소프트웨어 및 시스템과는 무관한 최종 사용자에 의해 이루어지거나 주도되는 환경으로 옮겨지고 있다. 일반적으로 최종 사용자란 컴퓨터 시스템과 관련된 직업 활동을 하지 않아, 컴퓨터 기술이 아닌 다른 분야(예를 들어, 해당 컴퓨터 기술을 이용하여 다른 생산/경제 활동을 하는 분야가 될 수 있다.)에 관한 전문적인 지식을 가진 사람들을 말한다. 이들은 비록 컴퓨터 기술에 관한 전문성을 갖추고 있지는 않지만, 실제 소프트웨어 개발 현장에서 소프트웨어 산출물(artifact)을 만들고 변경하게끔 하는 주체이며, 중요한 재무 결정이나 업무 처리 플로우 등을 결정하는 역할을 담당한다. 이러한 개발 환경의 변화는 소프트웨어 개발을 위한 요구 수렴이 최종 사용자에게 의해 수행됨으로써 일반 사용자의 요구(needs)가 왜곡없이 소프트웨어 및 시스템에 반영될 수 있다는 장점을 갖는다. 이하에서 소개되는 비특허문헌은 이러한 최종 사용자에 의한 소프트웨어 개발 방법에 대해 기술하고 있다.
그러나, 이러한 최종 사용자 친화적인 소프트웨어 개발 방법론은 소프트웨어 비전문가에 의해 제안되었다는 특성으로 인해 또 다른 문제점들이 등장하게 되었다. 따라서, 소프트웨어 공학 내지 요구 공학의 관점에서 최종 사용자들에 의한 요구사항이 충실히 반영되면서도 이로 인한 부작용이 나타나지 않는 개발 방법론과 이를 관리하기 위한 개발 도구가 요구되고 있다.
M. Burnett et al., "End-User Software Engineering with Assertions in the Spreadsheet Paradigm," Proc. 25th Int'l Conf. Software Eng. (ICSE '03), pp. 93-103, 2003.
본 발명이 해결하고자 하는 기술적 과제는 최종 사용자로부터 수집된 요구사항에 기초하여 개발된 소프트웨어에 있어서 최종적인 개발 산출물의 품질이 보장되기 어렵다는 문제점을 해결하고, 이로 인해 해당 개발 산출물에서 잠재적인 소프트웨어의 결함이 지속적으로 나타날 수 있다는 한계를 극복하며, 궁극적으로는 소프트웨어 개발 과정에서 소모되는 요구사항 수렴 및 분석에 필요한 시간이 지연되는 것을 방지하고자 한다.
상기 기술적 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 요구사항 시뮬레이터(simulator)가 소프트웨어 개발을 위한 요구사항(requirement)을 관리하는 방법은, 상기 시뮬레이터가 도메인(domain)별로 요구사항에 따라 검증된 일련의 자산(asset)을 저장하는 단계; 상기 시뮬레이터가 새로운 소프트웨어 개발에 따른 요구사항을 고려하여 상기 저장된 자산 중에서 사용자에 의해 선택된 요구사항 및 관련 자산을 독출하여 시각적인 작업 플로우(flow)로 표시하고, 상기 사용자의 선택에 의해 상기 시뮬레이터가 상기 표시된 작업 플로우 내의 작업 요소인 액티비티(activity)에 대해 추가, 삭제, 변경 중 어느 하나를 수행하여 상기 새로운 소프트웨어 개발에 대한 요구사항을 생성하는 단계; 상기 시뮬레이터가 상기 생성된 요구사항별로 입력, 연산 및 출력에 따른 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출하는 단계; 상기 시뮬레이터가 상기 산출된 비용을 고려하여 상기 작업 플로우의 개별 액티비티에 대한 선택을 상기 사용자로부터 입력받고, 상기 입력에 따라 조정된 작업 플로우를 생성하는 단계; 및 상기 시뮬레이터가 상기 조정된 작업 플로우를 새로운 자산으로서 저장하는 단계;를 포함한다.
상기된 요구사항을 관리하는 방법에서, 상기 액티비티는 하나 이상의 입력과 연산에 따른 출력을 가지며, 상기 사용자는 상기 시각적인 작업 플로우 상에서 GUI(graphical user interface)를 이용하여 상기 액티비티에 대한 입력과 출력을 통합적으로 설정한다. 또한, 상기 액티비티는, 상기 액티비티의 수행에 관한 GUI 폼(form) 디자인 및 상기 액티비티에 대한 입력과 출력이 연계되고, 상기 액티비티의 기능이 의미론적으로 유사한 그룹별로 저장된다.
나아가, 상기된 요구사항을 관리하는 방법에서, 상기 작업 플로우의 비용을 산출하는 단계는, 상기 생성된 요구사항별로 상기 액티비티의 데이터에 관한 속성 데이터 및 트랜잭션(transaction)에 관한 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출한다.
또한, 상기된 요구사항을 관리하는 방법에서, 상기 조정된 작업 플로우를 생성하는 단계는, 사용자 관점의 기능 단위에 대응하는 개별 액티비티를 미리 설정된 기준에 따라 정렬하는 단계; 및 상기 정렬된 순서에 따라 상기 산출된 비용을 누적하여 예산을 충족시킬 수 있도록 상기 개별 액티비티의 속성을 조정하는 단계;를 포함한다.
상기된 요구사항을 관리하는 방법은, 상기 저장된 새로운 자산에 따라 구현된 소프트웨어를 소정 테스트를 통해 검증하는 단계; 및 상기 검증 결과 오류가 발견되지 않은 경우, 상기 저장된 작업 플로우를 상기 도메인의 한 유형으로 등록하여 재사용 가능한 자산으로 변경하는 단계;를 더 포함한다.
한편, 이하에서는 상기 기재된 요구사항을 관리하는 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공한다.
상기 기술적 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 소프트웨어 개발을 위한 요구사항을 관리하는 장치는, 도메인별로 요구사항에 따라 검증된 일련의 자산을 저장하는 저장부; 사용자의 입력 및 선택을 수신하고, 상기 요구사항 및 상기 자산에 기초하여 생성된 영상을 영상 표시 수단에 전달하는 입출력부; 및 새로운 소프트웨어 개발에 따른 요구사항을 고려하여 상기 저장부에 저장된 자산 중에서 사용자에 의해 선택된 요구사항 및 관련 자산을 독출하여 시각적인 작업 플로우로 표시하고, 상기 사용자의 선택에 의해 상기 표시된 작업 플로우 내의 작업 요소인 액티비티에 대해 추가, 삭제, 변경 중 어느 하나를 수행하여 상기 새로운 소프트웨어 개발에 대한 요구사항을 생성하는 처리부;를 포함하고, 상기 처리부는, 상기 생성된 요구사항별로 입력, 연산 및 출력에 따른 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출하고, 상기 산출된 비용을 고려하여 상기 작업 플로우의 개별 액티비티에 대한 선택을 상기 사용자로부터 입력받고, 상기 입력에 따라 조정된 작업 플로우를 생성하며, 상기 조정된 작업 플로우를 새로운 자산으로서 상기 저장부에 저장한다.
상기된 요구사항을 관리하는 장치에서, 상기 액티비티는 하나 이상의 입력과 연산에 따른 출력을 가지며, 상기 사용자는 상기 시각적인 작업 플로우 상에서 GUI를 이용하여 상기 액티비티에 대한 입력과 출력을 통합적으로 설정한다. 또한, 상기된 요구사항을 관리하는 장치에서, 상기 액티비티는, 상기 액티비티의 수행에 관한 GUI 폼 디자인 및 상기 액티비티에 대한 입력과 출력이 연계되고, 상기 액티비티의 기능이 의미론적으로 유사한 그룹별로 상기 저장부에 저장된다.
나아가, 상기된 요구사항을 관리하는 장치에서, 상기 처리부는, 상기 생성된 요구사항별로 상기 액티비티의 데이터에 관한 속성 데이터 및 트랜잭션에 관한 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출하고, 상기 데이터에 관한 속성 데이터는, 내부 논리 파일 및 외부 연계 인터페이스 파일이며, 상기 트랜잭션에 관한 속성 데이터는, 외부 입력, 외부 출력 및 외부 질의의 횟수이다.
또한, 상기된 요구사항을 관리하는 장치에서, 상기 처리부는, 사용자 관점의 기능 단위에 대응하는 개별 액티비티를 미리 설정된 기준에 따라 정렬하고, 상기 정렬된 순서에 따라 상기 산출된 비용을 누적하여 예산을 충족시킬 수 있도록 상기 개별 액티비티의 속성을 조정함으로써 상기 조정된 작업 플로우를 생성한다.
상기된 요구사항을 관리하는 장치에서, 상기 저장된 새로운 자산에 따라 구현된 소프트웨어를 소정 테스트를 통해 검증한 후, 상기 검증 결과 오류가 발견되지 않은 경우, 상기 처리부는 상기 저장된 작업 플로우를 상기 도메인의 한 유형으로 등록하여 재사용 가능한 자산으로 변경하여 상기 저장부에 저장한다.
본 발명의 실시예들은 검증된 자산으로부터 독출된 요구사항 및 관련 자산을 조정하여 새로운 요구사항이 반영된 작업 플로우를 생성함으로써 최종 사용자에 의해 유도된 개발 산출물의 품질을 보장하고, 해당 개발 산출물에서 나타날 수 있는 소프트웨어적인 결함을 차단할 수 있으며, 새롭게 생성된 작업 플로우가 검증된 경우에 한해 도메인(domain)의 새로운 유형으로 자산을 등록함으로써 요구사항 수렴 및 분석에 필요한 시간을 감소시켜 전체 소프트웨어 개발 과정의 생산성을 향상시킬 수 있다.
도 1은 본 발명의 일 실시예에 따른 요구사항 시뮬레이터(simulator)를 이용하여 소프트웨어를 개발하는 전 과정(lifecycle)을 설명하기 위한 도면이다.
도 2는 본 발명의 일 실시예에 따른 요구사항 시뮬레이터에서 채택하고 있는 요구사항 자산의 구조를 도시한 도면이다.
도 3은 본 발명의 일 실시예에 따른 요구사항 시뮬레이터가 소프트웨어 개발을 위한 요구사항을 관리하는 방법을 도시한 흐름도이다.
도 4a 내지 도 4d는 본 발명의 일 실시예에 따른 요구사항 관리 방법에서, 기 저장된 자산으로부터 독출된 요구사항 및 관련 자산을 이용하여 새로운 소프트웨어 개발에 대한 요구사항을 생성하는 과정 및 그에 따른 UI를 예시한 도면이다.
도 5는 본 발명의 일 실시예에 따른 요구사항 관리 방법에서, 요구사항별로 속성 데이터를 입력받아 작업 플로우의 비용을 산출하는 과정 및 그에 따른 UI를 예시한 도면이다.
도 6a 및 도 6b는 본 발명의 일 실시예에 따른 요구사항 관리 방법에서, 개별 액티비티를 수정하여 새로운 요구사항에 따라 조정된 작업 플로우를 생성하는 과정 및 그에 따른 UI를 예시한 도면이다.
도 7은 본 발명의 일 실시예에 따른 요구사항 관리 방법에서, 새로운 작업 플로우에 대한 검증 결과 오류가 발견되지 않은 경우, 해당 작업 플로우를 도메인(domain)의 유형으로 등록하는 과정 및 그에 따른 UI를 예시한 도면이다.
도 8은 본 발명의 일 실시예에 따라 소프트웨어 개발을 위한 요구사항을 관리하는 장치를 도시한 블록도이다.
본 발명의 실시예들을 설명하기에 앞서 본 발명의 실시예들이 구현되는 환경에 대해 간략히 소개하고, 실시예들이 구현되는 환경에서 발생하고 있는 구현상의 문제점을 제시하고자 한다.
앞서 소개한 바와 같이 최종 사용자들은 전문적으로 훈련된 프로그래머가 아니기 때문에, 이들의 결정 또는 직접적인 작업 결과에 따라 개발된 소프트웨어 개발 산출물은 그 품질을 신뢰하기 어렵다는 문제점이 발견되었다. 이를 해결하기 위해 최근 전체적인 소프트웨어 개발 주기/과정(lifecycle)에 걸쳐 최종 사용자들의 활동을 지원하고 훈련을 돕는 방법이 연구되고 있으나, 이들은 대부분 최종 사용자가 작성한 소프트웨어의 품질을 검증하기 위한 검사 기술에 집중되어 있다는 점에서 사후적인 조치에 불과하다는 지적이 존재한다.
구축된 소프트웨어 시스템의 품질을 보장하기 위해서는 시스템적으로 보장될 수 있는 검증 기술이 활용되어야 하나, 이와 더불어 소프트웨어 시스템에 대한 양질의 신뢰도를 보장하기 위해서는 정확하고 효율적인 요구사항 분석이 요구된다. 이와 관련하여, 최종 사용자가 주도하는 프로그램 개발 작업에서 요구사항의 출처(source) 역시 프로그래머 자신이라는 점에서 명시적으로 요구사항을 추출하거나 명세하는 단계를 생략한 채 소프트웨어의 개발이 진행되는 현상이 발견되었다. 그러나, 개발하고자 하는 소프트웨어의 품질에 대한 허용되는 범위에 대한 정의조차 내려지지 않은 상태 하에서 소프트웨어를 개발하고, 이러한 소프트웨어를 다시 검사한다는 것은 목적없이 진행되는 작업이라고 볼 수 있다. 따라서, 이하에서 제안되는 본 발명의 실시예들은 소프트웨어 개발 주기의 첫 번째 단계인 요구사항 분석 단계에서 소프트웨어 엔지니어링에 대한 별도의 훈련을 받지 않는 최종 사용자들에게 친화적인 형태의 요구사항 수집 도구 및 그에 대한 UI(user interface)를 제공하고자 한다. 이와 더불어 동일한 도메인(domain)에 대해 이미 분석되고 검증된 요구사항들을 최종 사용자가 향후 재사용할 수 있도록 하는 자산 관리 시스템을 제안하고자 한다.
이하에서 제안하는 요구사항 추출 및 관리 기술의 설명하기에 앞서, 본 기술의 바람직한 적용 대상을 소개하면 다음과 같다. 첫째, 본 기술을 실제 소프트웨어 개발에 실현하는 주체는 도메인 전문가(domain expert)들이다. 이러한 전문가 그룹은 소프트웨어 시스템의 도메인 지식을 보유하고 있는 직업 종사자를 의미하며, 특정 요구사항에 따른 시스템 반영 여부를 결정하는 능동적인 역할자들이다. 둘째, 도메인 전문가들이 직접 요구사항을 추출하고 관리해 나가는 기법의 효율성을 얻고자, 본 발명의 실시예들이 적용될 소프트웨어 시스템은 사용자와의 상호작용(interaction)이 직관적인 GUI(graphic user interface)를 기반으로 이루어지며, 비지니스 플로우(business flow)가 시스템 구현의 중요한 요소로 작용하는 성격을 갖는다.
특히, 본 발명의 실시예들은 이상과 같은 환경 하에서 도메인 전문가의 역할을 크게 자산 공급자(asset provider)와 자산 소비자(asset consumer)로 구분하고 있다. 자산 공급자는 이미 소프트웨어 시스템으로 구현되어 검증 결과 그 품질에 결함이 없는 요구사항 자산들을 구조화하여 공통된 자산 저장소(storage)에 저장하는 역할을 담당한다. 자산 소비자는 시스템 개발 초기에 동일한 소프트웨어 도메인의 범주에 속하는 요구사항 자산을 공통된 자산 저장소로부터 검색하여, 본인이 구축하고자 하는 소프트웨어의 요구사항으로 수정, 변경하는 역할을 담당한다. 즉, 본 발명의 실시예들은 공통된 요구사항 자산 저장소에 관련 자산을 저장하고, 다시 이로부터 필요로 하는 자산을 검색하여 시스템 개발 초기의 요구사항 집합으로 재사용할 수 있는 메카니즘을 구현함으로써 품질이 검증된 자산을 재사용하여 최종 사용자 주도의 소프트웨어 개발의 문제점 중 하나로 지적되었던 품질 저하 문제를 해결함과 동시에 요구사항 수집 단계에서 소모되는 시간과 비용을 최소화하고자 한다.
이하에서 기술될 본 발명의 실시예들은 이상에서 기술한 소프트웨어 개발 환경과 그에 따른 구현상의 문제점에 대한 인식으로부터 안출된 것으로서, GUI에 기반하여 요구사항을 통제, 운영, 공유하는 요구사항 시뮬레이터(simulator) 내지 관리 도구에 해당한다. 이를 위해 요구사항 시뮬레이터는 그 관리를 위해 작업 플로우를 시각적으로 표시하고, 조정된 작업 플로우와 요구사항 분석 결과를 애니메이션을 통해 사용자에게 제공하고, 관련 도메인별로 그룹화하여 자산을 관리하는 기능을 포함한다.
이하에서는 첨부된 도면을 참조하여 본 발명의 실시예들을 보다 구체적으로 설명한다.
도 1은 본 발명의 일 실시예에 따른 요구사항 시뮬레이터(simulator)(100)를 이용하여 소프트웨어를 개발하는 전 과정(lifecycle)을 설명하기 위한 도면이다. 요구사항 시뮬레이터(100)는 최종 사용자의 관점을 가지고 있는 도메인 전문가들이 최대한 자유롭게 소프트웨어 개발을 위한 초기 요구사항을 식별해 가면서도, 동시에 그들이 작성하는 요구사항 수집 결과의 품질뿐만 아니라, 최종 개발 산출물의 품질을 제어할 수 있는 관리 시스템을 의미한다. 또한, 이러한 요구사항 시뮬레이터는 최종 사용자가 직관적으로 사용할 수 있도록 시각화 도구를 제공함으로써 최종 사용자(도메인 전문가)로 하여금 부지불식간에 요구사항 수집 단계에서 필요로 하는 기술을 학습할 수 있어야 한다.
이러한 조건을 만족시키기 위하여, 도 1은 요구사항 재사용(reuse)를 기반으로 하는 소프트웨어 개발 주기(lifecycle)을 제안하고 있다. 도 1에서 요구사항 시뮬레이터(100)는 2 가지 서로 다른 역할(role)을 정의하고 있다.
첫 번째는 요구사항 시뮬레이터(100)에 이미 저장되어 있는 도메인별 요구사항 관련 자산을 활용하여 새롭게 개발하고자 하는 소프트웨어에 적정하게 커스터마이즈(customize)함으로써 새로운 버전의 요구사항 자산을 생성해내는 '요구사항 자산 소비자'로서의 역할이다. 요구사항 자산 소비자는 동일한 조직 내에서 이미 선행 개발을 통해 검증되었거나, 또는 타조직에서 개발하여 검증 과정을 거친 소프트웨어의 요구사항 자산들이 탑재되어 있는 도메인별 저장소를 검색한다. 110 단계를 통해 사용자는 현재 개발하고자 하는 소프트웨어 동일한 도메인에 속하는 식별하여 요구사항 시뮬레이터(100) 상에서 표시하면서 기존의 요구사항 자산의 내용을 숙지한다. 120 단계에서 관련된 도메인 전문가는 요구사항 시뮬레이터(100)가 제공하는 GUI 기반의 요구사항 애니메이션 기능을 활용하여, 서로간의 충분한 의사소통 과정을 거친 후, 소프트웨어 품질을 극대화할 수 있는 요구사항 집합을 선택하기 위해 요구사항 협상을 수행한다. 이 때, 요구사항 협상의 단위응 기능적인 요구사항의 경우에는 시나리오들의 저장소 역할을 하는 유스 케이스(use case)로 설정되는 것이 바람직하며, 본 발명의 실시예들에서는 비지니스 어플리케이션을 대상으로 하는 유스 케이스별 기능 포인트(function point)를 산정하는 방식을 활용할 수 있다. 130 단계에서는 협상 과정을 통해 필터링된 요구사항에 대해서는 각 요구사항과 관련된 GUI 폼(form)과 해당 요구사항 구현을 위해 필요로 하는 데이터 정보 등을 면밀히 검토하여 필요한 부분은 포함시키고, 불필요한 부분은 제외시키며, 필요에 따라 새로운 요구사항을 추가적으로 식별하는 등의 조정 작업이 이루어진다. 이를 통해 개발하고자 하는 소프트웨어를 위한 조정된 요구사항 자산을 정의하여, 프로젝트(project) 수준의 저장소에 저장하게 된다.
두 번째는 요구사항 시뮬레이터(100)에 새롭게 추가된 요구사항 자산 내지 작업 플로우를 검증하여 재사용 가능한 자산으로서 도메인 수준의 저장소에 등록하는 '요구사항 자산 공급자'로서의 역할이다. 앞서 130 단계를 통해 정의된 새로운 요구사항 자산은 140 단계를 통해 구현 과정을 거쳐 소프트웨어 제품에 반영된다. 그 후, 150 단계를 통해 검증을 거치게 되면, 구현된 소프트웨어 내에 오류가 존재하는지 여부가 판별된다. 이러한 검증 과정을 통해 오류가 더 이상 발견되지 않으면 향후 재사용 가능한 요구사항 자산으로써 분류되고, 160 단계에서 공용 저장소의 도메인 수준에 등록되게 된다.
도 1을 통해 각각 역할의 관점에서 2 개의 주체를 '요구사항 자산 소비자'와 '요구사항 자산 공급자'로 구분하여 설명하였으나, 양자는 실질적으로 동일한 주체에 의해 수행될 수 있으며, 기술된 일련의 순서에 따라 소프트웨어 개발 주기를 반복적으로 순환할 수 있다.
도 2는 본 발명의 일 실시예에 따른 요구사항 시뮬레이터에서 채택하고 있는 요구사항 자산의 구조를 도시한 도면이다. 도 1을 통해 간략하게 소개한 바와 같이 요구사항 시뮬레이터(100)는 선행 개발되거나 혹은 자산 공급자가 제공하는 요구사항 관련 자산들을 도메인 수준 저장소를 통해 관리한다. 이 때, 저장소에 탑재되어 관리되는 요구사항 자산은 도 2와 같은 구조를 가질 수 있다.
요구사항 자산의 구성 요소를 살펴보면, 최상위 레벨의 요구사항으로 비지니스 목표(210)이 있다. 시스템 개발 목적에 해당되는 요구사항으로서 비지니스 목표(210)가 설정되면, 개발을 통해 달성하고자 하는 품질 속성별로 시스템의 허용 가능한 범위를 규정하는 비기능적 목표(non-functional goal)(220)가 설정된다. 다음 단계로, 시스템이 사용자에게 제공하는 서비스에 해당하는 기능적 목표(230)를 정의한다. 정의되는 모든 기능적 목표(230)는 생성 근거에 해당하는 비지니스 목표(210)를 명시해야 한다. 또한, 앞서 기술된 비기능적 목표(220)의 달성과 관련이 있는 기능적 목표(230)일 경우에는 양자간의 연관관계에 대해서도 명시하도록 한다. 하나의 기능적 목표(230)는 다수 개의 상호작용 시나리오(240)로 객체화될 수 있다.
이제, 각각의 상호작용 시나리오는 하나 이상의 액티비티(activity)(250)로 구현된다. 액티비티(250)는 시스템의 행동을 나타내는 최소 단위이자, 시스템을 사용하여 사용자가 수행하는 작업의 최소 단위에 해당하는 요구사항이다. 각 액티비티(250)의 수행과 관련된 GUI 폼(280)의 이미지, 그리고 액티비티(250) 수행을 위해 필요로 하는 입력/출력 아이템(260)과의 관계를 함께 연계하여 관리함으로써 본 발명의 실시예들에 따른 요구사항 시뮬레이터(200) 내에서 제공하는 GUI 기반의 요구사항 애니메이션 기능을 지원할 수 있다. 각 액티비티(250)와 관련된 데이터 아이템(260)들은 각각이 낱개로 관리되는 것이 아니라, 의미론적으로 유사한 그룹 단위로 관리되는데 이를 데이터 그룹(270) 내지 데이터 집합이라고 명명하였다. 데이터 그룹(270)과 데이터 아이템(260)은 개발이 진행되면서 데이터베이스 디자인을 수행할 경우 테이블(table)과 필드(field)의 설계를 위한 기초 자료로서 활용될 수 있다.
도 3은 본 발명의 일 실시예에 따른 요구사항 시뮬레이터가 소프트웨어 개발을 위한 요구사항을 관리하는 방법을 도시한 흐름도로서, 다음과 같은 단계들을 포함한다.
310 단계에서, 요구사항 시뮬레이터는 도메인(domain)별로 요구사항에 따라 검증된 일련의 자산(asset)을 저장한다. 이러한 과정은 새로운 소프트웨어 개발을 위한 요구사항 수렴 단계 이전에 미리 수행되어 있으며, 검증된 자산은 요구사항 시뮬레이터의 데이터베이스에 점진적으로 누적, 적재되어 간다.
320 단계에서, 요구사항 시뮬레이터는 새로운 소프트웨어 개발에 따른 요구사항을 고려하여 310 단계를 통해 저장된 자산 중에서 사용자에 의해 선택된 요구사항 및 관련 자산을 독출하여 시각적인 작업 플로우(flow)로 표시하고, 상기 사용자의 선택에 의해 상기 시뮬레이터가 상기 표시된 작업 플로우 내의 작업 요소인 액티비티(activity)에 대해 추가, 삭제, 변경 중 어느 하나를 수행하여 상기 새로운 소프트웨어 개발에 대한 요구사항을 생성한다.
여기서, 액티비티는 하나 이상의 입력과 연산에 따른 출력을 가지며, 상기 사용자는 상기 시각적인 작업 플로우 상에서 GUI(graphical user interface)를 이용하여 상기 액티비티에 대한 입력과 출력을 통합적으로 설정하는 것이 바람직하다. 보다 구체적으로, 액티비티는, 상기 액티비티의 수행에 관한 GUI 폼(form) 디자인 및 상기 액티비티에 대한 입력과 출력이 연계되고, 상기 액티비티의 기능이 의미론적으로 유사한 그룹별로 저장되는 것이 바람직하다. 즉, 도 2를 통해 소개한 바와 같이 본 발명의 실시예들이 채택하고 있는 요구사항 시뮬레이터는 액티비티, 데이터 아이템(데이터 그룹 내에 포함된다.) 및 GUI 폼을 통합하여 관리하며, 사용자와의 상호작용을 통해 이들을 유기적으로 조율할 수 있다. 따라서, 최종 사용자는 비록 소프트웨어 개발에 대한 전문적이 지식이 없더라도, 하나의 관리 도구 및 화면을 통해 시각적으로 인지한 일련의 요구사항 자산의 구조를 인지할 수 있고, 이러한 사용자의 인지에 기반하여 화면 상에 표시된 작업 플로우 상에서 필요한 조정과 요구사항 수렴을 수행할 수 있다.
또한, 새로운 소프트웨어 개발에 대한 요구사항을 생성하는 단계는, 사용자 관점의 기능 단위인 유스 케이스(use case)별로 입력, 수행 동작 및 출력을 고려하여 상기 액티비티를 처리할 수 있다. 앞서 간략하게 소개한 바와 같이 기능적 요구사항의 경우, 이러한 유스 케이스는 시나리오들의 수용체(container) 역할을 함으로써 유스 케이스별로 기능 포인트를 산정하여 요구사항 협상을 진행할 수 있다.
330 단계에서, 요구사항 시뮬레이터는 320 단계를 통해 생성된 요구사항별로 입력, 연산 및 출력에 따른 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출한다. 이 과정에서 요구사항 시뮬레이터는 생성된 요구사항별로 액티비티의 데이터 및 트랜잭션(transaction)에 관한 속성 데이터에 기초하여 작업 플로우 내의 개별 액티비티의 비용 및 전체 비용을 산출할 수 있다. 이러한 데이터 및 트랜잭션에 관한 속성은 소프트웨어 개발에 소모되는 비용을 산출할 수 있는 객관적이고 정량적인 지표 중에서 선택되는 것이 바람직하다.
340 단계에서, 요구사항 시뮬레이터는 330 단계를 통해 산출된 비용을 고려하여 상기 작업 플로우의 개별 액티비티에 대한 선택을 상기 사용자로부터 입력받고, 상기 입력에 따라 조정된 작업 플로우를 생성한다. 이제, 요구사항 시뮬레이터는 요구사항 협상 결과에 기초하여 새롭게 조정된 작업 플로우를 생성하게 된다. 본 발명의 실시예들은 이미 검증이 완료된 요구사항 자산을 재사용하여 새로운 요구사항을 빠르게 생성하는 방법을 제안하고 있으며, 본 340 단계에서는 재사용 결과로 새롭게 조정된 요구사항에 기초하여 작업 플로우를 생성하게 된다.
350 단계에서, 요구사항 시뮬레이터는 340 단계를 통해 조정된 작업 플로우를 새로운 자산으로서 저장한다. 이 과정을 통해 요구사항 시뮬레이터는 조정된 작업 플로우를 요구사항 시뮬레이터의 저장소에 새로운 자산으로서 저장하게 된다. 그러나, 이 과정의 자산 저장은 아직 도메인 수준의 저장은 아니다. 왜냐하면, 본 발명의 실시예들에서 도메인 수준으로 관리되는 자산은 반드시 사후 검증이 완료된 자산이어야 하기 때문이다. 이러한 관리 체계를 통해 본 실시예들에 따른 요구사항 시뮬레이터는 적어도 도메인 수준의 기 구축 요구사항 자산에 대해서는 작업 플로우에 대한 무결성을 보장하게 된다.
이상의 과정을 통해 요구사항 시뮬레이터는 새로운 소프트웨어 개발을 위한 요구사항을 수렴하여 자산을 생성하였다. 이하에서는 이렇게 생성된 자산이 어떻게 요구사항 시뮬레이터를 통해 재사용될 수 있도록 관리되는지 그 방법을 소개하도록 한다.
360 단계에서, 요구사항 시뮬레이터는 350 단계를 통해 저장된 새로운 자산에 따라 구현된 소프트웨어를 테스트를 통해 검증한다. 이러한 테스트는 본 발명이 구현되는 환경 내지 실시 태양에 따라 다양한 검증 기법을 활용하여 구현될 수 있으며, 검증 그 자체는 본 발명의 본질을 흐릴 우려가 있는 바, 여기서는 구체적인 설명을 생략한다.
370 단계에서, 요구사항 시뮬레이터는 360 단계를 통한 검증 결과 오류가 발견되지 않은 경우, 350 단계를 통해 저장된 작업 플로우를 상기 도메인의 한 유형으로 등록하여 재사용 가능한 자산으로 변경한다. 즉, 본 단계에 이르러서야 비로소 새롭게 추가된 요구사항 자산은 도메인 수준의 자산으로서 편입되게 된다. 따라서, 본 370 단계를 거쳐 도메인 수준의 자산으로 등록된 요구사항 자산은 이후 새로운 소프트웨어 개발 프로젝트가 진행될 경우, 320 단계의 자산 검색의 결과로서 화면상에 표시될 수 있다. 즉, 자산 재사용의 대상이 될 수 있다. 반면, 360 단계 내지 370 단계의 검증에 실패한 자산의 경우에는 여전히 도메인 수준의 자산으로서 등록되지 않게 되고, 320 단계의 검색 과정에서도 검색 결과로서 나타나지 않게 된다.
이상에서 소개한 일련의 과정은 소프트웨어 개발을 위한 요구사항을 관리하는 요구사항 시뮬레이터에 의해 수행된다. 이 때, 이러한 요구사항 시뮬레이터는 적어도 하나의 프로세서(processor)를 구비한다. 또한, 일련의 연산을 수행하는 과정에서 데이터를 임시로 적재하는 메모리(memory) 내지 각각의 하드웨어를 제어하는 컨트롤러(controller)가 활용될 수도 있다. 물론, 이상의 하드웨어들을 제어하기 위한 프로그램 코드로 구현된 소프트웨어가 부가될 수 있음은 당연하다. 따라서, 본 발명의 실시예들이 속하는 기술 분야에서 본 발명의 실시예들이 구현되는 환경의 특성을 이해하는 통상의 기술자들은 이상의 요구사항 시뮬레이터가 물리적인 하드웨어와 이를 제어하는 소프트웨어의 결합으로서 구현될 수 있음을 알 수 있다.
이하에서는 본 발명의 실시예들을 직접 구현한 요구사항 시뮬레이터의 동작 화면들을 예시하여 각각의 수행 과정을 보다 구체적으로 설명하도록 한다.
도 4a 내지 도 4d는 본 발명의 일 실시예에 따른 요구사항 관리 방법에서, 기 저장된 자산으로부터 독출된 요구사항 및 관련 자산을 이용하여 새로운 소프트웨어 개발에 대한 요구사항을 생성하는 과정 및 그에 따른 UI를 예시한 도면으로서, 도 3의 310 단계 및 320 단계에 대응한다.
요구사항 시뮬레이터는 기 저장된 자산 중에 사용자에 의해 선택된 요구사항 자산을 독출하여 화면 상에 시각적인 형태로 표시한다. 즉, 사용자(도메인 전문가가 될 수 있다.)는 요구사항 시뮬레이터가 관리하는 공용 저장소(검증된 요구사항 자산이 관리되는 데이터베이스가 될 수 있다.) 내에 저장되어 있는 동일한 도메인에 속하면서 이미 선행 개발된 소프트웨어의 요구사항 관련 자산들을 하나씩 검토해 나가면서, 현재 개발 대상이 되는 새로운 소프트웨어 개발에 재사용이 가능한 요구사항 자산들을 선별하는 작업을 수행한다. 도 4a는 요구사항 시뮬레이터에서 정의한 반복 시나리오 상의 액티비티의 수행 순서를 시각적으로 표시하는 비지니스 플로우 다이어그램을 도시하고 있다. 이제, 사용자는 'Modify a biz. plan' 항목(410)을 선택하여 액티비티를 수정하고자 한다.
도 4b에서는, 도 4a를 통해 비지니스 플로우 다이어그램으로 보여준 'Register a Biz. Plan' 상호작용 시나리오에 대한 액티비티 리스트를 보여주고 있다. 본 화면에서 상호작용 시나리오에 대한 액티비티를 추가, 삭제 및 변경할 수 있다. 도 4b에는 마지막 항목(420)에 추가된 액티비티를 새롭게 정의하고 있는 것을 볼 수 있다.
도 4c에서는, 이상에서 보여준 'Register a Biz. Plan' 상호작용 시나리오에서 'Modify a biz. plan'의 액티비티 정보를 보여주고 있다. 해당 액티비티는 속성으로서, 입력값(430)과 출력값(440)을 구체적으로 정의한다. 우선 입력값으로는 'business ID', 'name' 및 'year'를 정의하고 있으며, 이들 입력값을 전달받아 'biz. plan' 수정 작업을 수행한 후, 출력값으로 'business category' 및 'content'를 생성할 수 있음을 알 수 있다.
한편, 본 화면을 통해 액티비티의 입력 및 출력에 관한 속성뿐만 아니라 그 UI 디자인까지도 일괄하여 관리할 수 있다. 이제 이러한 UI 디자인을 관리하는 버튼(450)을 선택해보자.
도 4d는 도 4c의 UI 디자인 관리 버튼(450)의 선택에 따라 표시되는 화면을 예시한 것으로, 이상에서 보여준 'Register a Biz. Plan' 상호작용 시나리오의 'Modify a biz. plan' 액티비티에 대한 UI 폼(form)을 보여주고 있다. 본 화면은 추후 비지니스 플로우 다이어그램에 따라 시뮬레이션된다. 이러한 UI 폼은 최종 사용자에 의해 자유롭게 등록, 수정될 수 있으며, 정의된 입력값 및 출력값에 대응하는 것이 바람직하다.
이상의 과정을 통해 요구사항 시뮬레이터는 요구사항에 기반한 액티비티를 중심으로 새로운 작업 단위를 정의하고, 각각의 UI 및 관련 데이터 아이템들을 통합적으로 관리할 수 있다.
도 5는 본 발명의 일 실시예에 따른 요구사항 관리 방법에서, 요구사항별로 속성 데이터를 입력받아 작업 플로우의 비용을 산출하는 과정 및 그에 따른 UI를 예시한 도면으로서, 앞서 설명한 도 3의 330 단계에 대응한다.
도 5에서는 요구사항을 협상하고 우선순위(520)를 결정하여 최종적인 프로젝트 비용을 산출하게 된다. 이를 위해, 요구사항 시뮬레이터는 시나리오의 수행 과정에서 필요한 데이터 기능(예를 들어, 내부 논리 파일 및 외부 연계 인터페이스 파일이 될 수 있다.)과 트랜잭션 기능(예를 들어, 외부 입력, 외 출력 및 외부 질의/조회 횟수가 될 수 있다.)에 관한 파라미터(parameter)에 해당 프로젝트의 특성 데이터를 입력하여 프로젝트 비용을 산정한다. 그리고 비용을 기준으로 요구사항 협상을 수행한다. 즉, 요구사항 협상이란, 소프트웨어 구축 결과 최종 사용자에게 가장 유용할 수 있는 요구사항 그룹을 구성하는 요구사항들을 선택하는 일련의 과정이라고 할 수 있다.
도 5에서 요구사항 시뮬레이터는 각 시나리오별 기능 포인트 값을 기준으로 내림차순으로 시나리오의 명칭과 각각의 기능 포인트의 값을 표시한다. 도메인 전문가는 이를 토대로 책정된 예산의 한계에 적합한 요구사항 그룹을 확정하게 된다. 도 5에는 앞서 도 4a 내지 도 4d를 통해 살펴보았던 'Register a Biz. Plan' 상호작용 시나리오가 구현하는 'Plan Administration'이라는 기능적 목표가 개발 대상(510)으로 포함되었음을 확인할 수 있다.
도 6a 및 도 6b는 본 발명의 일 실시예에 따른 요구사항 관리 방법에서, 개별 액티비티를 수정하여 새로운 요구사항에 따라 조정된 작업 플로우를 생성하는 과정 및 그에 따른 UI를 예시한 도면으로서, 앞서 설명한 도 3의 340 단계에 대응한다. 즉, 이러한 조정된 작업 플로우를 생성하는 과정은, 사용자 관점의 기능 단위에 대응하는 개별 액티비티를 미리 설정된 기준에 따라 정렬하고, 상기 정렬된 순서에 따라 상기 산출된 비용을 누적하여 예산을 충족시킬 수 있도록 상기 개별 액티비티의 속성을 조정함으로서 이루어진다.
도 6a는 이상에서 보여준 'Register a Biz. Plan' 상호작용 시나리오의 액티비티 리스트에서 'Present biz. plans' 액티비티(610)가 추가된 것을 보여주고 있다. 본 단계 이후부터는 기존 요구사항에서 재사용/추출을 끝내고 리뷰 작업이 수행된다. 이상의 과정을 거쳐 조정되거나 또는 완전히 새롭게 생성된 사항에 대해서는 각 사항에 대한 타당성을 판단하여 최종적으로 요구사항의 내용을 확정하게 된다.
도 6b는 이상에서 보여준 'Present biz. plans' 액티비티(620)가 추가된 'Register a Biz. Plan' 상호작용 시나리오의 비지니스 플로우 다이어그램을 보여주고 있다. 모든 요구사항들에 대해 이러한 리뷰 작업이 완료되면, 확정된 요구사항들은 앞서 도 3을 통해 소개한 소프트웨어의 구현과 검증의 과정을 거치게 된다.
이러한 구현과 검증 결과 새로운 자산으로부터 오류가 발견되지 않은 경우, 상기 저장된 작업 플로우를 상기 도메인의 한 유형으로 등록하여 재사용 가능한 자산으로 변경하게 된다.
도 7은 본 발명의 일 실시예에 따른 요구사항 관리 방법에서, 새로운 작업 플로우에 대한 검증 결과 오류가 발견되지 않은 경우, 해당 작업 플로우를 도메인(domain)의 유형으로 등록하는 과정 및 그에 따른 UI를 예시한 도면으로서, 좌측의 화면은 검증 전의 화면이며, 우측의 화면은 검증 후 새로운 작업 플로우가 도메인 수준으로 등록된 화면에 해당한다. 최초에 좌측의 화면에서 'Biz Plan'(710)은 도메인(720) 수준에 이르지 못하고 프로젝트 수준에 머물러 있음을 알 수 있다. 즉, 소프트웨어로서 구현된 요구사항들 중, 검증 과정을 통해 오류가 발견되지 않은 요구사항 자산의 경우에 한해 향후 이어지는 새로운 개발에서 재사용 가능하다고 판단하게 된다. 이 경우, 도 7에 예시된 바와 같이 프로젝트별 공간(710)에서 도메인별 공간(730)으로 저장소를 옮겨 등록되었음을 확인할 수 있다.
도 8은 본 발명의 일 실시예에 따라 소프트웨어 개발을 위한 요구사항을 관리하는 장치(요구사항 시뮬레이터)(800)를 도시한 블록도로서, 각각의 구성 요소들은 앞서 설명한 도 3의 일련의 수행 과정에 대응한다. 따라서, 여기서는 설명의 중복을 피하기 위해 장치적 특성에 기초하여 그 개요만을 약술하도록 한다.
저장부(20)는 도메인별로 요구사항에 따라 검증된 일련의 자산을 저장한다.
입출력부(10)는 사용자(850)의 입력 및 선택을 수신하고, 상기 요구사항 및 상기 자산에 기초하여 생성된 영상을 영상 표시 수단(40)에 전달한다. 사용자(850)는 영상 표시 수단(40)을 통해 시각적으로 표시되는 영상을 인지함으로써 요구사항 자산을 직관적으로 제어할 수 있게 된다.
처리부(30)는 새로운 소프트웨어 개발에 따른 요구사항을 고려하여 상기 저장부에 저장된 자산 중에서 사용자에 의해 선택된 요구사항 및 관련 자산을 독출하여 시각적인 작업 플로우로 표시하고, 상기 사용자의 선택에 의해 상기 표시된 작업 플로우 내의 작업 요소인 액티비티에 대해 추가, 삭제, 변경 중 어느 하나를 수행하여 상기 새로운 소프트웨어 개발에 대한 요구사항을 생성한다. 그런 다음, 처리부(30)는, 상기 생성된 요구사항별로 입력, 연산 및 출력에 따른 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출하고, 상기 산출된 비용을 고려하여 상기 작업 플로우의 개별 액티비티에 대한 선택을 상기 사용자로부터 입력받고, 상기 입력에 따라 조정된 작업 플로우를 생성하며, 상기 조정된 작업 플로우를 새로운 자산으로서 상기 저장부에 저장한다.
여기서, 상기 액티비티는 하나 이상의 입력과 연산에 따른 출력을 가지며, 상기 사용자는 상기 시각적인 작업 플로우 상에서 GUI를 이용하여 상기 액티비티에 대한 입력과 출력을 통합적으로 설정하게 된다. 또한, 상기 액티비티는, 상기 액티비티의 수행에 관한 GUI 폼 디자인 및 상기 액티비티에 대한 입력과 출력이 연계되고, 상기 액티비티의 기능이 의미론적으로 유사한 그룹별로 상기 저장부에 저장되는 것이 바람직하다. 나아가, 구현의 관점에서 상기 처리부(30)는, 사용자 관점의 기능 단위인 유스 케이스별로 입력, 수행 동작 및 출력을 고려하여 상기 액티비티를 처리하는 것이 바람직하다.
요구사항 협상의 관점에서 처리부(30)는, 상기 생성된 요구사항별로 상기 액티비티의 데이터에 관한 속성 데이터 및 트랜잭션에 관한 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출한다. 이 때, 상기 데이터에 관한 속성 데이터는, 내부 논리 파일 및 외부 연계 인터페이스 파일이며, 상기 트랜잭션에 관한 속성 데이터는, 외부 입력, 외부 출력 및 외부 질의의 횟수를 활용할 수 있다.
조정된 요구사항을 생성하는 관점에서 처리부(30)는, 사용자 관점의 기능 단위에 대응하는 개별 액티비티를 미리 설정된 기준에 따라 정렬하고, 상기 정렬된 순서에 따라 상기 산출된 비용을 누적하여 예산을 충족시킬 수 있도록 상기 개별 액티비티의 속성을 조정함으로써 상기 조정된 작업 플로우를 생성한다.
이러한 처리부(30)는 적어도 하나의 프로세서를 구비하며, 필요에 따라서는 이상의 연산을 수행하기 위한 작업 공간으로서 메모리를 구비할 수 있을 뿐만 아니라, 이러한 하드웨어를 제어하고 연산을 수행하는 일련의 명령어 집합으로 구성된 소프트웨어 코드를 포함할 수 있다.
나아가, 저장된 새로운 자산에 따라 구현된 소프트웨어를 소정 테스트를 통해 검증한 후, 상기 검증 결과 오류가 발견되지 않은 경우, 상기 처리부(30)는 상기 저장된 작업 플로우를 상기 도메인의 한 유형으로 등록하여 재사용 가능한 자산으로 변경하여 상기 저장부에 저장하게 된다.
상기된 본 발명의 실시예들에 따르면, 검증된 자산으로부터 독출된 요구사항 및 관련 자산을 조정하여 새로운 요구사항이 반영된 작업 플로우를 생성함으로써 최종 사용자에 의해 유도된 개발 산출물의 품질을 보장하고, 해당 개발 산출물에서 나타날 수 있는 소프트웨어적인 결함을 차단할 수 있으며, 새롭게 생성된 작업 플로우가 검증된 경우에 한해 도메인(domain)의 새로운 유형으로 자산을 등록함으로써 요구사항 수렴 및 분석에 필요한 시간을 감소시켜 전체 소프트웨어 개발 과정의 생산성을 향상시킬 수 있다.
한편, 본 발명의 실시예들은 컴퓨터로 읽을 수 있는 기록 매체에 컴퓨터가 읽을 수 있는 코드로 구현하는 것이 가능하다. 이 때, 컴퓨터가 읽을 수 있는 기록 매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다.
컴퓨터가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현하는 것을 포함한다. 또한, 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고 본 발명을 구현하기 위한 기능적인(functional) 프로그램, 코드 및 코드 세그먼트들은 본 발명이 속하는 기술 분야의 프로그래머들에 의하여 용이하게 추론될 수 있다.
이상에서 본 발명에 대하여 그 다양한 실시예들을 중심으로 살펴보았다. 본 발명에 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.
100 : 요구사항 시뮬레이터
200 : 요구사항 자산 (데이터베이스)
800 : 요구사항 시뮬레이터 850 : 최종 사용자(end-user)
10 : 입출력부 20 : 저장부
30 : 처리부 40 : 영상 표시 수단

Claims (17)

  1. 적어도 하나의 프로세서(processor)를 구비하는 요구사항 시뮬레이터(simulator)가 소프트웨어 개발을 위한 요구사항(requirement)을 관리하는 방법에 있어서,
    상기 시뮬레이터가 도메인(domain)별로 요구사항에 따라 검증된 일련의 자산(asset)을 저장하는 단계;
    상기 시뮬레이터가 새로운 소프트웨어 개발에 따른 요구사항을 고려하여 상기 저장된 자산 중에서 사용자에 의해 선택된 요구사항 및 관련 자산을 독출하여 시각적인 작업 플로우(flow)로 표시하고, 상기 사용자의 선택에 의해 상기 시뮬레이터가 상기 표시된 작업 플로우 내의 작업 요소인 액티비티(activity)에 대해 추가, 삭제, 변경 중 어느 하나를 수행하여 상기 새로운 소프트웨어 개발에 대한 요구사항을 생성하는 단계;
    상기 시뮬레이터가 상기 생성된 요구사항별로 입력, 연산 및 출력에 따른 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출하는 단계;
    상기 시뮬레이터가 상기 산출된 비용을 고려하여 상기 작업 플로우의 개별 액티비티에 대한 선택을 상기 사용자로부터 입력받고, 상기 입력에 따라 조정된 작업 플로우를 생성하는 단계; 및
    상기 시뮬레이터가 상기 조정된 작업 플로우를 새로운 자산으로서 저장하는 단계;를 포함하는 방법.
  2. 제 1 항에 있어서,
    상기 액티비티는 하나 이상의 입력과 연산에 따른 출력을 가지며,
    상기 사용자는 상기 시각적인 작업 플로우 상에서 GUI(graphical user interface)를 이용하여 상기 액티비티에 대한 입력과 출력을 통합적으로 설정하는 것을 특징으로 하는 방법.
  3. 제 2 항에 있어서,
    상기 액티비티는,
    상기 액티비티의 수행에 관한 GUI 폼(form) 디자인 및 상기 액티비티에 대한 입력과 출력이 연계되고,
    상기 액티비티의 기능이 의미론적으로 유사한 그룹별로 저장되는 것을 특징으로 하는 방법.
  4. 제 1 항에 있어서,
    상기 새로운 소프트웨어 개발에 대한 요구사항을 생성하는 단계는,
    사용자 관점의 기능 단위인 유스 케이스(use case)별로 입력, 수행 동작 및 출력을 고려하여 상기 액티비티를 처리하는 것을 특징으로 하는 방법.
  5. 제 1 항에 있어서,
    상기 작업 플로우의 비용을 산출하는 단계는,
    상기 생성된 요구사항별로 상기 액티비티의 데이터에 관한 속성 데이터 및 트랜잭션(transaction)에 관한 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출하는 것을 특징으로 하는 방법.
  6. 제 5 항에 있어서,
    상기 데이터에 관한 속성 데이터는, 내부 논리 파일 및 외부 연계 인터페이스(interface) 파일이고,
    상기 트랜잭션에 관한 속성 데이터는, 외부 입력, 외부 출력 및 외부 질의의 횟수인 것을 특징으로 하는 방법.
  7. 제 1 항에 있어서,
    상기 조정된 작업 플로우를 생성하는 단계는,
    사용자 관점의 기능 단위에 대응하는 개별 액티비티를 미리 설정된 기준에 따라 정렬하는 단계; 및
    상기 정렬된 순서에 따라 상기 산출된 비용을 누적하여 예산을 충족시킬 수 있도록 상기 개별 액티비티의 속성을 조정하는 단계;를 포함하는 방법.
  8. 제 1 항에 있어서,
    상기 저장된 새로운 자산에 따라 구현된 소프트웨어를 소정 테스트를 통해 검증하는 단계;를 더 포함하는 방법.
  9. 제 8 항에 있어서,
    상기 검증 결과 오류가 발견되지 않은 경우, 상기 저장된 작업 플로우를 상기 도메인의 한 유형으로 등록하여 재사용 가능한 자산으로 변경하는 단계;를 더 포함하는 방법.
  10. 제 1 항 내지 제 9 항 중에 어느 한 항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
  11. 소프트웨어 개발을 위한 요구사항을 관리하는 장치에 있어서,
    도메인별로 요구사항에 따라 검증된 일련의 자산을 저장하는 저장부;
    사용자의 입력 및 선택을 수신하고, 상기 요구사항 및 상기 자산에 기초하여 생성된 영상을 영상 표시 수단에 전달하는 입출력부; 및
    새로운 소프트웨어 개발에 따른 요구사항을 고려하여 상기 저장부에 저장된 자산 중에서 사용자에 의해 선택된 요구사항 및 관련 자산을 독출하여 시각적인 작업 플로우로 표시하고, 상기 사용자의 선택에 의해 상기 표시된 작업 플로우 내의 작업 요소인 액티비티에 대해 추가, 삭제, 변경 중 어느 하나를 수행하여 상기 새로운 소프트웨어 개발에 대한 요구사항을 생성하는 처리부;를 포함하고,
    상기 처리부는,
    상기 생성된 요구사항별로 입력, 연산 및 출력에 따른 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출하고,
    상기 산출된 비용을 고려하여 상기 작업 플로우의 개별 액티비티에 대한 선택을 상기 사용자로부터 입력받고, 상기 입력에 따라 조정된 작업 플로우를 생성하며,
    상기 조정된 작업 플로우를 새로운 자산으로서 상기 저장부에 저장하는 것을 특징으로 하는 장치.
  12. 제 11 항에 있어서,
    상기 액티비티는 하나 이상의 입력과 연산에 따른 출력을 가지며,
    상기 사용자는 상기 시각적인 작업 플로우 상에서 GUI를 이용하여 상기 액티비티에 대한 입력과 출력을 통합적으로 설정하는 것을 특징으로 하는 장치.
  13. 제 12 항에 있어서,
    상기 액티비티는,
    상기 액티비티의 수행에 관한 GUI 폼 디자인 및 상기 액티비티에 대한 입력과 출력이 연계되고,
    상기 액티비티의 기능이 의미론적으로 유사한 그룹별로 상기 저장부에 저장되는 것을 특징으로 하는 장치.
  14. 제 11 항에 있어서,
    상기 처리부는,
    사용자 관점의 기능 단위인 유스 케이스별로 입력, 수행 동작 및 출력을 고려하여 상기 액티비티를 처리하는 것을 특징으로 하는 장치.
  15. 제 11 항에 있어서,
    상기 처리부는,
    상기 생성된 요구사항별로 상기 액티비티의 데이터에 관한 속성 데이터 및 트랜잭션에 관한 속성 데이터를 입력받아 상기 작업 플로우의 비용을 산출하고,
    상기 데이터에 관한 속성 데이터는, 내부 논리 파일 및 외부 연계 인터페이스 파일이며,
    상기 트랜잭션에 관한 속성 데이터는, 외부 입력, 외부 출력 및 외부 질의의 횟수인 것을 특징으로 하는 장치.
  16. 제 11 항에 있어서,
    상기 처리부는,
    사용자 관점의 기능 단위에 대응하는 개별 액티비티를 미리 설정된 기준에 따라 정렬하고,
    상기 정렬된 순서에 따라 상기 산출된 비용을 누적하여 예산을 충족시킬 수 있도록 상기 개별 액티비티의 속성을 조정함으로써 상기 조정된 작업 플로우를 생성하는 것을 특징으로 하는 장치.
  17. 제 11 항에 있어서,
    상기 저장된 새로운 자산에 따라 구현된 소프트웨어를 소정 테스트를 통해 검증한 후, 상기 검증 결과 오류가 발견되지 않은 경우,
    상기 처리부는 상기 저장된 작업 플로우를 상기 도메인의 한 유형으로 등록하여 재사용 가능한 자산으로 변경하여 상기 저장부에 저장하는 것을 특징으로 하는 장치.
KR20110124307A 2011-11-25 2011-11-25 자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법 KR101508496B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR20110124307A KR101508496B1 (ko) 2011-11-25 2011-11-25 자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR20110124307A KR101508496B1 (ko) 2011-11-25 2011-11-25 자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법

Publications (2)

Publication Number Publication Date
KR20130058348A true KR20130058348A (ko) 2013-06-04
KR101508496B1 KR101508496B1 (ko) 2015-04-10

Family

ID=48857643

Family Applications (1)

Application Number Title Priority Date Filing Date
KR20110124307A KR101508496B1 (ko) 2011-11-25 2011-11-25 자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법

Country Status (1)

Country Link
KR (1) KR101508496B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190081109A (ko) * 2017-12-29 2019-07-09 (주)씽크포비엘 사용성 확보를 위한 후속작업 시뮬레이션 방법 및 장치
KR102095863B1 (ko) * 2018-10-31 2020-04-02 (주)아이엠티 범용api와 gui기반의 통합개발환경(ide)을 제공하는 실시간 시뮬레이션 시스템 및 그 제어방법

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100784783B1 (ko) * 2004-12-07 2007-12-14 한국전자통신연구원 정량적인 프로세스 관리를 위한 임베디드 시스템 개발 방법론 지원 시스템
US8849691B2 (en) * 2005-12-29 2014-09-30 Microsoft Corporation Modeling user input and interaction in workflow based applications

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190081109A (ko) * 2017-12-29 2019-07-09 (주)씽크포비엘 사용성 확보를 위한 후속작업 시뮬레이션 방법 및 장치
KR102095863B1 (ko) * 2018-10-31 2020-04-02 (주)아이엠티 범용api와 gui기반의 통합개발환경(ide)을 제공하는 실시간 시뮬레이션 시스템 및 그 제어방법

Also Published As

Publication number Publication date
KR101508496B1 (ko) 2015-04-10

Similar Documents

Publication Publication Date Title
Tripathi Learning Robotic Process Automation: Create Software robots and automate business processes with the leading RPA tool–UiPath
US8225288B2 (en) Model-based testing using branches, decisions, and options
US8196113B2 (en) Realtime creation of datasets in model based testing
Pillat et al. BPMNt: A BPMN extension for specifying software process tailoring
JP2020522779A (ja) ルールを編集、シミュレート、バージョン制御、及びビジネスプロセス管理する統合システム
Kouhestani et al. IFC-based process mining for design authoring
US10380526B2 (en) System and method for providing a process player for use with a business process design environment
Romero et al. Splemma: a generic framework for controlled-evolution of software product lines
Imran et al. Software sustainability: a systematic literature review and comprehensive analysis
Choudhary et al. A business process re-engineering approach to transform business process simulation to BPMN model
Rokis et al. Exploring Low-Code Development: A Comprehensive Literature Review
US20180039921A1 (en) Generating domain-specific process studios
KR20130058348A (ko) 자산 기반의 요구사항 시뮬레이터 및 요구사항 관리 방법
Tarhan et al. A proposal on requirements for cosmic FSM automation from source code
Ghabach Supporting Clone-and-Own in software product line
Winkler et al. Model-driven framework for business continuity management
US20080195453A1 (en) Organisational Representational System
Atar Hands-On Test Management with JIRA: End-to-end test management with Zephyr, synapseRT, and Jenkins in JIRA
do Nascimento et al. A method for rewriting legacy systems using business process management technology
Grambow Context-aware process management for the software engineering domain
Bogado et al. DEVS-based methodological framework for multi-quality attribute evaluation using software architectures
Rodríguez et al. Model‐based assisted migration of oracle forms applications: The overall process in an industrial setting
Νούσιας Business process and decision automation: end-to-end deployment with a BPMN and DMN-based workflow engine
Virtanen Literature review of test automation models in Agile testing
Khadka Revisiting Legacy Software System Modernization

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
X091 Application refused [patent]
AMND Amendment
E90F Notification of reason for final refusal
AMND Amendment
X701 Decision to grant (after re-examination)
FPAY Annual fee payment

Payment date: 20180108

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20190211

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20200128

Year of fee payment: 6