Douglas' Space

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

1. 들어가면서 "program = algorithm + data strucucture"라는 제목의 책을 보신 적이 있으신가요? 프로그램은 결국 데이터를 처리하는 알고리즘, 명령의 집합인 셈이죠. 다시 말해 모든 컴퓨터시스템은 데이터를 입력받아 뭔가를 처리하고 데이터를 외부 출력하는 시스템인 것입니다. 이때 필요에 따라 데이터를 저장하고 관리하기도 합니다. 따라서 데이터는 시스템을 구성하는 매우 중요한 구성요소의 하나라고 할 수 있습니다. data modeling은 시스템의 데이터를 분석하고 설계하는 모든 행위를 말합니다. 따라서 시스템 개발에서 data modeling은 프로그램 개발과 함께 병행되는 중요한 개발축이라고 할 수 있습니다. 소프트웨어 분석과 설계의 한 과정이라고 할 수도 있고, 소프트웨어..

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

1. Development Processes SSDM은 코딩이 수행되는 구현단계를 제외하고 MIL-STD-498에서 정의된 단계 중 분석설계와 관련된 4단계로 개발단계를 정의합니다. 시스템차원에서의 분석 및 설계 단계와, 시스템 설계가 완료된 후 식별된 소프트웨어 형상관리단위인 CSCI별로 분석 및 설계를 진행합니다. 각 단계를 SSRA, SSD, SRA, SD 단계로 약어를 사용하여 지칭합니다. 그리고 전체 개발 단계에 수행되는 데이터 분석 및 설계에 해당하는 data modeling 프로세스가 존재합니다. 따라서 데이터의 경우 개발 전 단계에 걸쳐 모델링을 수행합니다. 이와 유사하게 품질보증 활동으로서 검증 및 확인 활동인 verification과 validation 활동이 수행됩니다. SSD단계에서..

1. 들어가면서 여러분 이 그림이 의미하는 바가 무엇인지 살펴보세요. 이 그림은 요구사항을 파악하여 최종 고객이 원하는 것을 만든다는 것이 매우 어렵다는 것을 설명하는 그림입니다. 밑에 가장 오른쪽에 있는 그림이 정말 사용자가 원했던 것인데, 위의 가장 왼쪽 그림을 보면 사용자 마저도 본인이 원하는 것을 잘 설명 못할 수 있다는 것을 의미하기도 합니다. 또한 요구사항이 잘못 분석이 되거나 요구사항이 잘못 표현되어 있으면 이를 고친다는 것은 엄청 많은 노력이 요구된다는 것을 반증하기도 합니다. 이에 대한 사실은 많은 통계 데이터을 통해서도 알 수 있습니다. 개발에 있어서 요구분석이 40%정도를 차지한다거나, 요구사항으로 인한 에러로 수정을 하는 비용이 단순 코드의 에러으로 수정하는 것보다 엄청난 대가를 지..

1. 들어가면서 아래 2개의 그림이 있는데, 공통점이 뭘까요? 둘다 개집입니다. 이렇게 이야기하면 틀린 답이겠죠. 하나는 진짜 개집이고 하나는 개모양의 집입니다. 두 집을 짓는다고 생각할 때 어느 집을 짓는 것이 어려울 까요? 당연히 오른쪽의 집을 짓는 것이 복잡하겠죠. 왼쪽의 개집은 설계도면도 없이 지을 수 있지만, 오른쪽의 집은 그럴 수가 없겠죠? 오른쪽의 집을 짓기 위해서는 설계도면이 반드시 필요하리라 생각합니다. 그리고 아마 설계하기 전에 집주인이 요구하는 요구사항까지도 잘 듣고 이해해야 할 것입니다. 소프트웨어시스템을 개발할 때도 마찬가지라고 생각합니다. 2. Model의 정의 아파트 개발 전에 우리는 모델하우스를 보고 지워질 아파트를 미리 알 수 있습니다. 시스템을 개발할 때도 이와 마찬가지로..