Douglas' Space

1. 들어가면서 Ai기반 시스템은 단순히 지금의 딥러닝을 기반으로는 한계가 존재하기 때문에 인간 및 세상의 배경지식을 포함한 Contextual Knoledge Model을 포함하는 것으로 발전할 것으로 예상된다고 하였습니다. 이러한 관점에서는 딥러닝모델을 포함하여 도메인의 지식을 표현하는 지식표현이 매우 중요합니다. 이 두가지를 모두 고려하여 시스템을 분석하는 것은 기능적 및 비기능적 요구사항을 정의하는 것과 데이터 모델을 분석하고 정의하는 것의 확장 개념이라고 할 수 있습니다. 특별히 Ai기반 시스템의 분석이라고 해서 특별히 방법론적으로 달라지는 것은 없으며 추가적으로 고려할 사항이 증가하는 것이라고 할 수 있습니다. 2. ANN (Artificial Neural Net) 모델의 기능적 요구사항 분석..

1. 들어가면서 비기능적 요구사항은 품질 요구사항과 제약사항이라고 하였습니다. 따라서 비기능적 요구사항을 식별하기 위한 참조모델로서 시스템과/소프트웨어의 품질과 관련한 표준인 ISO/IEC 25000 시리즈의 품질모델을 기반으로 비기능 요구사항을 식별할 수 있습니다. ISO/IEC 25000 시리즈를 SQUARE(System and Software Quality Requirements and Evaluation)라고 하며, 크게 아래와 같이 5개의 시리즈로 구성되어 있으나 이글에서는 Quality Model Division에서 제시하는 품질모델에 대해 설명하고자 합니다. (AI를 위한 시스템을 위해 ISO/IEC 25059에서 25010에 대한 확장판을 정의하고 있습니다.) 2. Quality Model..

1. 들어가면서 요구사항은 크게 기능적 요구사항(functional requirements)과 비기능 요구사항(Non-functional requirements)으로 크게 나눌 수 있다고 하였습니다. 지금까지는 주로 기능적 요구사항과 관련된 요구사항을 모델링하는 방법에 대해 설명을 드렸고, 이 글은 비기능적 요구사항에 대해 설명하고자 합니다. 기능적 요구사항과 비기능적 요구사항을 구분하기 어려운 경우가 많으나, 그 이름을 조금 생각해 보면 쉽게 구분이 될 수 있습니다. 모델링 관점에서 기능적 요구사항은 어떤 입력을 받아 처리를 하고 출력하는 입출력 관계로 모델링이 가능한 것이 기능적 요구사항입니다. 입출력관계와 같은 모델링이 어렵다면 보통은 비기능적 요구사항입니다. 비기능적 요구사항을 조금 더 이해하기 ..

1. 들어가면서 모든 open system은 외부와의 인터렉션을 수행하는 것이 본질적인 성질입니다. 따라서 그 기능을 수행하기 위해서는 외부의 인터페이스를 잘 유지해야 합니다. 모든 software system은 자극으로 데이터를 외부로 입력을 받고, 이를 변환하여 반응으로 데이터를 출력합니다. 이렇게 입출력되는 데이터가 정의가 되어야 시스템의 완전한 기능 모델이 정의된다고 볼 수 있습니다. 바꿔 말하며 software system의 이러한 데이터는 매우 중요한 요소이며, 데이터의 분석 및 정의는 시스템 분석의 가장 중요한 부분이라고 생각할 수 있습니다. 2. Interface Types 지난번 context model에서 살펴본 것 같이 software system은 크게 2가지의 유형의 actor와 ..

1. 들어가면서 방법론의 장점은 어떤 패턴을 제공하므로써 개발하고자 하는 시스템에 이 패턴들을 적용하므로써 쉽게 시스템을 개발할 수 있도록 도와주는 역할을 할 수 있습니다. 그리고 더 나아가 패턴을 통해 기존의 분석하거나 설계한 내용의 문제점을 발견하게 하여 품질 좋은 시스템을 개발하는 가이드라인을 제시해 주기도 합니다. 이러한 패턴은 분석, 설계 단계에서 모두 활용이 가능하며 이러한 패턴들을 잘 발견하고 이를 적용하는 노력이 매우 중요합니다. 이 패턴을 찾고 이를 적용하는 것이 Know-how라고 이야기할 수 있습니다. 이번 글에서는 기능모델인 유스케이스의 패턴에 대해 설명하고자 합니다. 2. State Update Pattern 시스템의 기능 중 가장 기본적인 패턴은 시스템에서 유지해야할 데이타, 즉..

1. 들어가면서 시스템의 요구사항은 크게 functional requirements와 non-functional requirments로 구분할 수 있다고 말씀드렸습니다. 이번 글에서 기술할 functional model은 요구사항중 functional requirements를 분석하여 이를 모델링한 결과를 표현하는 모델입니다. software system의 관점에서는 가장 기본적이고 필수적인 요구사항이라고 할 수 있습니다. 그런데 기능이란 무엇일까요? 시스템이 수행할 일이라고 바꾸어 이야기할 수 있을 것 같습니다. 따라서 시스템이 수행하는 일들이 무엇이고 이 일의 단위와 구조를 어떻게 잘 표현할 것인가가 functional model의 품질을 좌우한다고 할 수 있습니다. UML에서는 이러한 일의 단위를 ..

1. 들어가면서 여러분의 손목에 이 스마트 워치가 있으신가요? 스마트워치는 사람들에게 최초의 웨어러블 컴퓨터로서의 역할을 하고 있죠. 그런데 어느 날 밤 자고 있는데 카톡이 와서 붕붕 울린다면? 신경질이 날 수 있을 것입니다. 제가 처음 L사의 스마트워치를 사용할 때 경험했던 이야기입니다. 그런데 옆에 이런 이야기를 듣던 A사 스마트워치를 차고 있던 사람이 자랑하더라구요. 그 스마트워치는 밤에는 카톡이 와도 울리지 않는다고. 이게 무슨 의미일까요? 이럴 때 우리는 이 놈 똑똑한데 이야기하죠. 사실 이 놈이 똑똑한게 아니라 UX관점에서 다양하게 잘 구분하여 상태를 관리하고 상태에 따라 다르게 작동하게 개발한 똑똑한 개발자 덕분일 것입니다. 이렇게 시스템의 상태와 모드를 잘 분석하고 반영하는 것이 시스템의 ..

1. 들어가면서 아래 보시는 그림은 무엇을 의미하는 것일까요? 네 맞습니다. 요구사항의 중요성을 이야기하는 그림입니다. 직관적으로는 시스템 개발 단계에서 발생한 결함을 해결하는 비용이 개발 단계 뒤로 갈수록 기하급수적으로 늘어난다는 것을 알려주는 도표입니다. 다른 말로 이야기하면 요구사항의 결함은 개발단계를 진행할 수록 시스템 개발에 엄청난 비용을 지불하게 된다고 할 수 있습니다. 마치 눈덩이가 점점 커지는 것을 연상할 수 있습니다. 또 반대의 의미로는 요구사항의 결함을 조기에 발견할 수록 시스템의 품질과 개발생산성을 제고할 수 있다는 것으로 해석할 수 있습니다. 요구사항의 결함이란 지난번 말씀드린 요구사항명세서가 가져야할 완전성, 일관성, 정확성, 테스트용이성을 만족하지 못하는 경우일 것입니다. 시스템..