Home Blog

객체지향 분석설계의 주요 산출물

laniakea
-
0

이전 글에서 객체지향 분석설계(OOAD-Object Oriented Analysis and Design)의 개요와 그 의의에 대해 간단히 정리해보았다.
이번 글에서는 OOAD의 주요 산출물을 간결하게 정리하고자 한다.
각 산출물들은 따로따로 노는 것이 아니라, 유기적으로 연결되어야 하며, 논리적이며, 모순이 없어야 한다.
예를 들어, Use Case Diagram에는 표현되어있지만 Domain Diagram에는 빠져있다던가, Sequence Diagram에는 들어있지만 Requirements에는 빠져있다던가 ..
이런 내용 누락과 모순이 발생하게 되면, 결국 설계에 빈틈이 생기게 되고, 요구사항이 누락되게 된다.

Requirements(FR/NFR) :
기능적 요구사항(Functional Requirements), 비 기능적 요구사항(Non Functional Requirements) 를 테이블 형식으로 적는다.
이 요구사항들은 각각 FR-Use case, NFR-QA로 연결된다.

Use Case Diagram :
Use case들이 정리된 뒤, 각 Use case의 Actor와 System 중 어떤 모듈과 상호작용을 하는지를 UML로 표현한다.
Actor는 Use case의 이해관계자에 해당하며, 둘 이상이 될 수 있다.

Fully Dressed-up Form :
Use case들을 도출한 뒤, Use case들의 세부 명세를 작성한다.
Use case의 범위와 Actor, 이해관계자와 Pre condition, Basic Flow, Alternative Flow, Include/Exclude Relationship, 기타 등등 … Use case들에 대해 모두 작성한다.

Domain Model :
Use case들과 FDF(Fully Dressed-up Form) 산출물을 통해, 해당 시스템의 도메인(Domain)을 정의한다.
Use case에서 등장한 개념들과 관계들이 보통 도메인 대상이 될 수 있으며, Use case에서 서술된 술어나 형용사 등이 각 도메인의 Property나 각 도메인 간 관계로 표현될 수 있다.
이 단계까지는 Implements Specific한 내용을 담지 않도록 주의한다. (DBMS를 뭘로 쓸 것인가, 프레임워크를 뭘 도입할 것인가 등)
최대한 현실 세계의 문제를 해결하기 위해, 시스템의 도메인을 Use case의 세계에 매핑되도록 작성하는 것이 중요하다.
도메인은 표로 정리하고, UML을 이용하여 다이어그램으로도 같이 표현해주면 도움이 된다.

System Sequence Diagram :
각 Use case 안에서, Actor와 System이 어떻게 상호작용을 하는지 나타내는 다이어그램이다.
Use case diagram, Domain diagram과 마찬가지로 표준 UML로 그려진다.
세부 도메인들은 System에 가려져있으며, 보통 System Sequence Diagram을 도출하는 것 까지가 객체지향 분석(OOA-Object Oriented Analysis)에 해당한다.

Sequence Diagram :
Sequence Diagram부터는 객체지향 분석 디자인(OOD-Object Oriented Design)의 산출물로 간주된다.
SSD(System Sequence Diagram)에서 블랙박스로 감추어진 System을 정의한 Domain 간 상호작용으로 표현한다.
UCD(Use Case Diagram), DD(Domain Diagram), SSD와 마찬가지로, 표준 UML을 활용하여 작성한다.

Class Diagram :
SD(Sequence Diagram)을 정의한 뒤, Domain에 해당하는 모듈들을 class level로 도출한다.
역시 표준 UML로 작성하며, 각 class간 관계를 드러낸다.
Class Diagram의 Notation은 Direction, Association, Aggregation, Composition, Inheritance 등이 있는데..
이 부분은 Domain들이 어떻게 유기적으로 관계를 맺는지에 따라 취사선택하면 된다.
CD의 Notation에 대해서는 따로 다룰 수 있는 기회가 있으면 좋겠다.

Traceability :
각 산출물 간 추적이 가능하도록 주기를 매겨두는 것 이라고 생각하면 좋을것 같다.
별도의 양식이나 규칙은 없고, 팀 내부에서 산출물 간 추적이 가능하도록 식별자를 붙여두면 좋을 것이다.
예를 들면, Requirements는 R-03, Use case는 U-03, Domain은 D-03, … 이런식으로 말이다.

Glossary :
요구사항과 도메인 내 모르는 용어나 개념들을 정리하기 위한 사전 역할을 한다.
팀원들이 읽고 잘 소통할 수 있도록, 팀원들이 잘 아는 단어 및 용어로 기술한다.

이렇게 매우 간단하게 OOAD에서 다루는 산출물을 정리해보았다.
현업에서도 OOAD 활동을 게을리해서 막판에 피눈물을 흘리는 경우들이 많았던 것 같아서 ..
강의안을 보는 내내 반성하게 되었다.

요구공학과 OOAD를 FM대로 수행하기는 어려울 수 있지만, 핵심 가치들을 잃어버리지 않도록..
정신을 잘 차려야겠다.

객체지향 분석설계란 무엇인가?

laniakea
-
0

학부생 시절에 C++, Java 등 언어의 수업을 들으면서 객체지향 패러다임 이라는 것을 처음으로 배우게 되었다.
어떤 책인지 정확히 기억은 안나는데, 객체지향 패러다임에 대해 다음과 같이 적혀있었던 것이 기억난다.
모든것은 객체이며 객체들은 자신의 상태를 가지고 있고, 메시지를 주고받으며 계(界)와 객체간 상호작용한다.
그 때에는 이 말이 무슨 말인지도 잘 몰랐다.
그냥 클래스 몇개 만들고, new 연산자로 객체를 만들고 대충 사용하면 된다고 생각했었다.
개발밥을 좀 먹다 보니, 단순히 코드를 작성하는것을 넘어, 소프트웨어나 시스템을 설계하는데 있어 객체지향적 사고를 한다는 것이 얼마나 중요한 것인지 깨닫게 되었다. (객체지향 언어나 프레임워크를 사용하지 않는다 하더라도 말이다.)

앞서 요구사항 구체화(Requirements Specification) 단계에서 수집된 요구사항들이 구현을 위한 중요한 기반 산출물로 가공된다고 언급한 바 있다.
객체지향 분석설계(OOAD-Object Oriented Analysis and Design)는 정리된 요구사항을 바탕으로, 도메인 개념과 객체 책임, 협력 구조를 분석하고 설계 모델로 구체화하는 과정이다.

OOAD는 바로 이 개발에 착수 가능한 상태를 위해 실제로 산출물 내 요구사항을 분석하고, 개발을 위한 설계를 진행하는 단계라고 볼 수 있을 것이다.

요구사항 잘 수집하면 된 것 아닌가. 무슨 또 분석을 하며, 설계를 하느냐고 .. 설계는 산출물 나올 때 같이 하면 되는것 아닌가? 라는 생각이 들 수 있다.
사실, 간단한 토이 프로젝트 수준의 앱을 만들거나, 학부생이 받는 학기 말 프로그래밍 언어 과제로 나오는 정도 수준의 과제라면 일견 맞는 말이다.

하지만, 현실세계의 문제는 굉장히 복잡하고 미묘해서, 요구사항이 계속해서 추가되거나 변경되는 바람에, 애써 분석한 요구사항이 무용지물이 되는 경우도 부지기수이다.
요구사항 분석과 설계가 튼튼하지 않으면, 결국 상황에 따라 이리저리 흔들리고 치이다가 기술 부채를 양산하여 나중에 큰 대가를 치르거나, 심각한 경우 일정을 제대로 맞추지 못해 납기 지연이 발생할 수 있다.
한마디로 요약하자면, 요구공학은 건물의 설계도를 그리는 행위이고, OOAD는 설계도를 시공 가능한 구조도/상세도면으로 바꾸는 작업이라 할 수 있겠다.

OOAD는 반복적(iterative), 점증적(incremental), 추적성(tracebility) 중심으로 흘러간다.
즉, OOAD는 산출물을 1회 뽑아내고 돌격 앞으로! 가 아닌, 2회 이상 산출물 작성 활동을 수행함으로써 변경에 강한 구조를 도출한다. 결론적으로 OOI(Object Oriented Implement)를 통해 실제 요구사항에 걸맞는 소프트웨어를 구현하는데 목적과 의의가 있다.

OOAD를 교안에서 공부하면서 느꼈던 정의와 필요성, 그리고 요구공학과의 상관관계에 대해서 정리해보았다.
다음 글에서는 OOAD의 산출물이 무엇인지, 요구공학의 산출물과 어떻게 이어지는지 탐구해보고자 한다.

요구공학 프로세스

laniakea
-
0

이전 글에서 요구공학이 무엇인지, 왜 중요한지를 짤막하게 정리해보았다.
이번 글에서는 요구공학에서 다루는 프로세스들에 대해서 짤막하게 얘기해보고자 한다.

요구공학의 프로세스 (Requirements Process)
요구공학의 공통 프로세스는 다음의 5가지이다.
시험을 치거나 할 것은 아니니, 달달 외울 필요는 없을것 같고 …
어차피 이 업을 계속 한다면, 자연스럽게 진행하게 될 프로세스이니 가볍게 읽어보면 좋을 것 같다.

1. 요구사항 도출하기(Requirements Elicitation) :
말 그대로 요구사항을 도출한다. 고객이 진정 원하는 소프트웨어가 무엇인지를 알기 위해, 무엇을 물어봐야할지를 생각해보는 단계이다.
문제 영역의 경계(Boundary)를 정의하고, 문제의 맥락을 이해한다. 문제와 관련된 이해관계자(Stakeholders)가 누구인지, 이해관계자들은 어떤 것을 원하고 어떤 것을 원하지 않는지. 목표는 무엇인지. 발생할 수 있는 시나리오와 제약사항. 타당성과 리스크를 확인한다.
한마디로, 요구사항에 필요한 모든 것을 끌어내고 수집하는 단계이다.
각 문제의 이해관계자들은 서로 모순되거나 상충되는 요구사항이나 서로 제로섬, 트레이드오프 관계의 요구사항을 요청하기도 한다.
예를 들면, “앱을 실행하자마자 번개처럼 UI를 매우 빠르게 띄울 수 있도록 해달라.”, “그런데 VE(원가절감 ^^)를 해야하니, 디바이스의 메모리와 CPU 성능은 쓰레기에요. 하지만 번개처럼 UI를 매우 빠르게 띄워주세요.” 같은 요구사항을 들 수 있겠다.
이 단계에서는 요구사항에 대한 재료를 도출하기 시작하며, 아래와 같은 초기 산출물 초안이 나온다.

  • Use case
  • Project Background
  • Stakeholder List
  • Business Goal List
  • System Context Diagram
  • System Feature List
  • Assumptions
  • Raw-QAS

2. 요구사항 분석하기(Requirements Analysis) :
요구사항들을 분석하여 분류하고 정리, 우선순위를 세운다.
수많은 요구사항들을 하나하나 분석하여 기능적 요구사항(FR)인지 비 기능적 요구사항(NFR)인지 구별하고, 어떤 요구사항이 핵심인지, 어떤 요구사항이 더 중요하고 덜 중요한지, 요구사항 간 연관관계는 무엇인지, 요구사항이 중복되거나 모순되는 지점이 있는지 등을 정리하는 단계이다.
기능적 요구사항(FR)쪽에서는 Use case를 정제하고, 경계들을 다듬는다.
비 기능적 요구사항(NFR)쪽에서는 QAW(Quality Attributes Workshop), 또는 간소화 버전인 mini-QAW 활동을 통해 Raw-QAS를 정제하고, 중요도와 난이도 바탕으로 우선순위를 정한다.
이 단계에서는 보통 아래와 같은 산출물들이 나온다고 볼 수 있겠다.

  • 정제된 Use case
    • Basic flow
    • Alternative flow
    • Include / Extend relationship
  • QAS (Raw-QAS의 정제된 버전)
  • Quality Attribute Tree / Utility Tree

3. 요구사항 구체화 (Requirements Specification) :
정리한 요구사항들을 문서화하는 단계이다.
이 단계부턴 다른 사람이나 외주업체가 보더라도, 해당 산출물들을 통해 실제로 개발과 검증이 가능한 설계가 나올 수 있는 수준이 되어야 한다. (OOAD 단계에서 구체적인 설계 산출물이 나온다.)
Elicitation, Analysis 단계를 거치며 나온 요구사항들을 문장이나 표, 다이어그램 등으로 정리하여 문서를 작성한다.
즉, 이 단계의 산출물은 앞 단계에서 도출하고 정리한 요구사항 재료들을, 다른 사람이 읽어도 바로 개발과 검증이 가능하도록 문서와 다이어그램 형태로 고정한 것들이다.

  • 시스템의 범위와 맥락을 정리하는 산출물
    • Project Background
    • Stakeholder List
    • Business Goal List
    • System Context Diagram
    • System Feature List
    • Assumptions
  • FR을 명세하는 산출물
    • Use Case Diagram
    • Use Case Scenarios
    • System Sequence Diagram
  • NFR을 명세하는 산출물
    • QA Scenario List
    • QAS (Quality Attribute Scenario)

4. 요구사항 검증하기 (Requirements Validation) :
작성한 요구사항을 점검하는 단계이다.
단순 오탈자 점검을 넘어서서, 각 요구사항들이 빠지거나 모순점 없이 작성이 잘 되었는지? 를 확인한다.
주로 확인하는 내용은 아래와 같다.
한마디로, “적은 문서가 말이 되는지 ?” 를 리뷰하는 단계다.

  • 빠진 요구사항은 없는지 ?
  • 서로 충돌하거나 모순되는 요구사항은 없는지 ?
  • 문장이 모호하지 않은지 ?
  • 정량화가 필요한 요구사항은 수치가 명확하게 기술되었는지 ?
  • 실제로 구현이 가능한지 ?
  • 테스트가 가능한지 ?
  • Actor / Use cases / QA / Feature 간 연결이 부자연스러운 곳은 없는지 ?

5. 요구사항 관리하기 (Requirements Management) :
요구사항을 관리하는 단계이다.
요구사항이 한 번 확정된 이후에는 변경되지 않으면 좋겠지만, 현실에서는 자주 바뀐다.
그렇기 때문에, 요구사항이 변하더라도 유연하게 대처해야 하는데, 주로 이런 항목들이 해당 단계에서 포함된다.

  • 요구사항 변경 이력 관리
  • 버전 관리
  • 추적성 (Traceability)
  • 영향도 분석
  • 요구사항 우선순위 관리
  • 산출물 간 연결 유지

찬찬히 살펴보면 당연한 내용들이 많은데..
막상 실전에서 적용해보려고 하면 번거롭고, 작성해야하는 문서들이 적지 않은 편이다.
책상머리에선 모든 것을 할 수 있는 것처럼 느껴지지만, 늘 시간은 모자라고 요구사항은 넘쳐난다.
그럼에도 결국 가장 중요한 것은, 고객의 요구사항을 정확하게 파악하는 일이라 생각한다.
요구공학을 형식주의로 내려치기하는 것도, 종교처럼 맹신하는 태도도 경계해야 하지 않을까 싶다.

산출물들에 대한 설명을 적자니, 글이 지나치게 길어질 것 같아 공부하면서 큰 꼭지만 작성하였다.
기회가 된다면 요구공학의 각 프로세스에서 다루는 산출물들을 좀 더 자세히 들여다보고 싶다.

요구공학이란 무엇인가?

laniakea
-
0

학부생 시절 소프트웨어 공학 과목에서 겉 핥기식으로나마 배웠던 것이 엊그제 일 같은데.
나이 들고 회사에서 교육받으려고 하니 정말 어렵게 느껴진다.
이참에 소프트웨어 아키텍트로서 역량도 키우고, 배운 내용을 정리할 겸 짤막하게 글을 남기려고 한다.

요구공학(Requirements Engineering)은 무엇인가 ?
요구공학은 소프트웨어 집약적 시스템의 목적과 사용 맥락을 식별하고, 커뮤니케이션하는 활동의 집합이다.

… 강의안에 적혀있는 설명이었는데 잘 모르겠다.
우선, 요구공학 이라는 단어의 맥락을 한번 살펴보고 싶다.
네이버 사전의 정의에 따르면, 요구의 정의는 아래와 같다.


받아야 할 것을 청하는 일. 그것이 요구이다.
즉, 고객은 자신이 받아야 할 것(소프트웨어)를 요구하고, 그 요구를 공학적인 프로세스로 추상화하는 일을 요구공학이라고 할 수 있을 것이다.

고객이 원하는 소프트웨어를 설계하고 구현하기 위해, 무엇을 해야할까?
우선, 고객이 가지고 있는 문제가 무엇인지 파악하고, 그 문제를 해결하기 위해 어떤 기능이 필요한지를 명세해야 할 것이다.
단순히 요구사항만 잘 받아적으면 될까 ?
개발자는 보통 자신이 몸 담고 있는 도메인 지식에만 정통한 경우들이 많다.
이해관계자들은 소프트웨어 개발자와 같은 도메인을 공유하고 있을 수도 있지만, 보통은 도메인이 완전히 다른 경우들이 많다.
그리고, 보통 이해관계자들 또한 본인이 원하는것이 정확히 무엇인지 알지 못하는 경우가 많다.
다들 이런 그림 한번 본 적 있지 않은가 ?

바보같다고 생각할지 모르겠지만, 본인의 삶을 잘 돌아보면 알 것이다.
본인도 그런 애매모호한 스탠스를 취하며 살아왔을 수 있다는 것을. (나 역시 내가 진정으로 원하는것이 무엇인지 잘 모르고 선택하거나 행동했던 적이 적지 않았던 것 같다.)
이런 이해관계자들로부터 그들이 원하는 것을 도출하고 정리하기 위해서는 커뮤니케이션 스킬이 필수이고, 늘 열린 마음으로 다른 도메인에 대해 배우고 수용할 준비가 되어있어야 한다.
문서를 예쁘고 맛깔나게 쓰는것도 중요하지만, 결국 사람의 문제를 정확히 정의하고 그것을 주어진 환경과 제약 안에서 해결하고 맞춰나가는 역량이 더 중요하고, 이를 달성하기 위한 과목이 요구공학이다.

현업에선 제품 기획이나 고객사 요구, 실제 운영하는 조직의 요구, 보안 요구, 갑자기 들어올 수 있는 추가기능에 대한 요구, … 물 밀듯이 뒤섞여 들어오기 마련이다.
대충 고객이 뭘 원하는지 물어본 뒤, 주먹구구식으로 대충 설계해서 구현하게 된다면 나중에 큰 재앙을 맞이하게 될 것이다. (그런 경험 많지 않은가?)

이런 재앙을 피하기 위해선, 실제 업무에 착수 전 요구공학에서 중요하게 다루는 고객의 요구사항을 수집하고 분석하는 일에 꽤나 힘을 써야한다.
이 활동이 지루하고 현학적으로 느껴지더라도, 제대로 해두면 나중에 설계를 헤집어 엎거나 프로젝트를 부러트리는 일이 줄어들 것이다.
교안에선 전체 프로젝트의 5~10% 정도 투자하는것을 추천하고 있다.
거 내가 해봐서 아는데~ 지금 거기에 쏟을 시간 따윈 없어!
어이 김씨! 헛소리 하지 말고 와서 코딩이나 해!
라고 윽박지르는 내부 이해관계자들이 있을 수 있다.
하지만 요구공학이 수반되지 않은 설계는 필연적으로 기술부채(Technical debt)를 지게 될 것이고, 그 이자는 해가 지나면 지날수록 매우 무거워진다.

고객이 뭘 원하는지 확실히 알기 위해, 기능 요구사항(Functional Requirements), 비 기능 요구사항(Non Functional Requirements)을 정확히 구분해야 한다.
기능 요구사항: 실제 문제를 해결할 수 있는 기능을 뜻한다. 예를 들면, “전화 앱에서 상대방의 전화번호를 누른 뒤, 통화 버튼을 눌러 상대방에게 전화를 걸 수 있는 기능” 을 기능 요구사항이라 부를 수 있을 것이다.
비 기능 요구사항: 기능 요구사항의 품질을 만족하기 위한 정량적, 정성적인 제약조건을 뜻한다. 예를 들면, “전화 앱에서 전화번호를 입력 후, 통화 버튼을 누르면 0.1초 이내에 전화를 걸 수 있도록 해야한다.” 를 비 기능 요구사항이라 부를 수 있을 것이다.

좋은 요구사항은 추상적이면 안 되며, 완전하고 일관되고, 가능하면 측정 가능해야 한다.
요구공학 활동을 하다 보면, 산출물들이 제법 나오는데, 이 산출물 간 빠진 부분들이 있거나 모순된다면 올바른 요구공학 활동을 진행한 것이 아니라고 할 수 있다.
이런 상태로 프로젝트를 진행하게 되면 결국 고객이 원하는 소프트웨어를 만들지 못하게 된다.

요구사항 분석을 제대로 하지 못한 채 프로젝트를 진행하게 되면, 요구사항 오류 수정 비용은 눈덩이처럼 불어나게 된다.
예를 들면, “로그인 기능이 있어야 한다.” 정도만 대충 잡고 개발에 들어가면 나중에 SSO, 2FA, 다중 인증, 소셜 로그인, 로그인 실패 시 잠금 정책 등등 … 여러가지 기능적, 비기능적 요구사항들이 붙게 되면서 처음 (대충)했던 설계가 부서지게 된다.
한 번 해야할 일을 두번 세번 네번 하다가 프로젝트는 부러지고 결국 심신이 지쳐 회사와 개발을 그만두게 될 수도 있단 것이다.

나름대로 강의안을 보며 공부했던 요구공학의 정의와 중요성에 대해 주저리 주저리 떠들어보았다.
다음 포스트에선 요구공학에서 다루는 주요 프로세스들을 한번 더 세부적으로 파악하고, 여유가 된다면 각 산출물들을 정리해보고자 한다.