꿈꾸는자의 생각의 파편들... :: 'SA' 태그의 글 목록 (8 Page)

달력

08

« 2018/08 »

  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  

아키텍트의 역할 정의

아키텍트는 개발 프로젝트에서 초기에 기술적인 부분에 대하여 의사결정을 진행한다. 또한 프로젝트가 진행될 수 있도록 기술적인 이슈들을 해결한다. 아키텍트가 프로젝트의 각 phase마다 해결하는 문제는 다음과 같다.

표 Ⅱ-1. 프로젝트의 각 phase마다 아키텍트가 수행하는 역할

단계

아키텍트가 수행하는 역할

  • Inception 
  • Architecture prototyping
  • Make/buy trade-offs
  • Primary scenario definition
  • Archtecture evaluation
  • CASE tool, 개발 툴 등 각종 툴 사용 방안
  • 설계 문서 템플릿 결정
  • 설계자와 개발자의 작업 규칙 결정
  • Elaboration 
  • Architecture baselining
  • Primary scenario demonstration
  • Make/buy trade-off baselining
  • Construction 
  • Architecture maintenance
  • Multiple-component issue resolution
  • Performance tuning
  • Quality improvements 
  • Transition 
  • Architecture maintenance
  • Multiple-component issue resolution
  • Performance tuning
  • Quality improvements 

개발 프로젝트에서 아키텍트가 하는 역할은 다음과 같다.

아키텍트는 아키텍처를 만들고 컴포넌트와 컴포넌트 사이의 관계를 파악하고 인터페이스를 설계해야 한다. 프로젝트 관리자는 아키텍트가 아키텍처 문서를 생산하도록 관리해야 한다.

프로젝트에서는 아키텍처에 대한 일차 문서가 만들어지면 아키텍처 팀이 해체되고 각 subsystem에 대한 개발 리더로서 역할을 할 경우가 많다. 이 경우 시스템 전체를 보고 아키텍처를 upgrade하는 역할이 없어진다. 아키텍처가 일차 완성된 후에도 아키텍처는 자주 수정된다. 개발자들은 아키텍처 팀이 만든 문서를 받아들이지 않고 새로운 요구사항이 들어오면 아키텍처의 본래 목적에서 벗어난 방식으로 나름대로 개발하려 한다. 따라서 아키텍처 팀은 프로젝트 끝까지 해체되지 않고 아키텍처에 대한 수정 및 업그레이드에 대한 책임을 져야 한다.

또한 아키텍트는 개발자들이 아키텍처를 이해하도록 도와야 하고 아키텍처 밑에 숨은 결정 사항을 설명해야 한다. 즉 아키텍트는 개발자들에게는 컨설턴트로서 리더로서의 역할을 해야 한다.

이를 정리하면 다음과 같이 정리될 수 있다.

  1. 비즈니스 케이스 생성
    1. 비용과 기존 시스템과의 인터페이스 여부 설정
    2. 시스템의 한계 상황 설정
    3. 비즈니스 목표 설정
  2. 요구사항 분석
    1. 아키텍쳐는 이해관계자들의 요구사항을 어떻게 반영할것이냐는 점이다.
    2. 기존 시스템을 어떻게 분석할 것인가?
    3. 프로토타입은 어느 수준까지? 어떻게?
    4. 품질요구사항에 따르는 아키텍쳐의 기준은 어떻게?
  3. 아키텍쳐 구축
    1. 새로운 아키텍쳐를 만들것인가?
    2. 기존 아키텍쳐를 선택할 것인가?
Posted by 꿈꾸는자의 생각의파편들

다른 아키텍처와의 관계

소프트웨어 아키텍처는 Enterprise Architecture에 포함된 business architecture, data architecture, Technical Architecture등을 참고하여 상세화 한다.

그림 Ⅱ-3. 소프트웨어 아키텍처와 다른 아키텍처와의 관련성

다른 아키텍처는 소프트웨어 아키텍처가 작성되기 전에 완성되어 있으며 소프트웨어 아키텍처의 입력으로 받아들인다. 그러나 소프트웨어 아키텍처가 작성되면 다른 아키텍처의 변경이 불가피하며 소프트웨어 아키텍트는 다른 아키텍처도 변경해야 한다. 소프트웨어 아키텍처 문서에는 다른 아키텍처도 참고 자료로 포함해야 한다.

그림 Ⅱ-4. 아키텍처 팀이 받아들이는 입력물과 생산하는 출력물

  • IT Architecture

기업의 IT 자산을 사용하고 수정하고, 구축하고 획듣하ㅡㄴ데 필요한 원칙, 가이드라인,

  • Business architecture

업무 프로세스, 조직, 전략

  • Data Architecture

조직의 논리적, 물리적 데이터 구조

  • Technical Architecture

어플리케이션이 배포되는 것을 지원하는 소프트웨어(미들웨어) 대한 아키텍처

  • reference architecture

특정 도메인에 대한 아키텍처를 지칭한다.

  • enterprise architecture

소프트웨어 아키텍처, 데이터 아키텍처, 테크니컬 아키텍처, 비즈니스 아키텍처를 포함한다.

  • Application architecture

Application architecture 기업에서 사용되는 특정 시스템에 대한 소프트웨어 아키텍처이다.

  • System architecture

구축할 시스템에 대한 아키텍처, software architecture system architecture subset이다. System architecture software hardware 구성된다.

Posted by 꿈꾸는자의 생각의파편들

소프트웨어 아키텍처에 포함되지 않는 것

소프트웨어 아키텍처는 하드웨어, 네트워크, 물리적인 시스템에 대한 아키텍처를 포함하지 않는다. 따라서 소프트웨어 아키텍처 설계서는 시스템 안에 포함된 소프트웨어 만을 보여주며 시스템은 컨텍스트로서만 표현된다. 예를 들어 하드웨어 모델명, 하드웨어 구성, 라우터, 랜카드에 대한 정보는 소프트웨어 아키텍처에 포함되지 않는다.

이를 그린다는 것은 그 것에 종속된다는 의미이므로 '추상화'하려면 해당 정보가 표시되면 안된다는 것이다.

세부적인 구현 사항은 소프트웨어 아키텍처에 포함되지 않는다. 예를 들어 컴파일러 옵티마이제이션, DLL을 shared로 할 것인지, static으로 할 것인가는 소프트웨어 아키텍처에 포함되지 않는다.

이는 별도의 의사결정과정과 후반부에서 처리한다.

Posted by 꿈꾸는자의 생각의파편들

소프트웨어 아키텍처의 특징

소프트웨어 아키텍처의 특징은 다음과 같다.

첫째, 소프트웨어 아키텍처는 시스템에 대한 추상화이다. 따라서 지엽적인 정보는 포함하지 않는다. 큰 그림만을 가지고 있는다.

둘째, 소프트웨어 아키텍처는 한가지 다이어그램으로는 결정되지 않으며 여러 관점의 다이어그램으로 이루어진다.

각각의 세부적인 것이 아니라, 건축물의 투시도와 같으며, 옷 디자이너의 스케치와 유사한 성격을 가진다.

소프트웨어 아키텍처의 역할

소프트웨어 아키텍처가 시스템 개발에서 담당하는 역할은 다음과 같다고 볼 수 있다.

첫째, 관련 당사자들 사이의 의사 소통의 수단이다.

둘째, 개발 프로젝트 초기 단계에서 의사결정 도구이다. 아키텍처는 품질 요소를 결정하며 프로젝트 조직에 영향을 끼친다.

셋째, 시스템의 전체 구조를 결정한다.

넷째, 개발 프로젝트의 조직을 결정하는데 참고할 수 있다.

다섯째, 시스템이 가져야 할 품질 요소를 결정한다. 따라서 아키텍처를 통해 시스템이 어떤 품질을 가질 것인지 예측할 수 있다.

여섯째, 아키텍처를 통해 시스템 개발자들에게 어떤 교육을 시킬 것이지 결정할 수 있다.

일곱째, 소프트웨어의 변경 사항을 어떻게 관리할 것인지를 알려준다.

상당한 역할이지 않은가? 이를 도식화 하면 다음과 같은 그림이 만들어진다.

그림 Ⅱ-2. 소프트웨어 아키텍처가 시스템 구축 시 하는 역할

그림 Ⅱ-2는 소프트웨어 아키텍처가 시스템 구축 시 담당하는 역할을 보여준다.

기능적, 비기능적 요구사항은 소프트웨어 아키텍처를 설계하는데 입력 산출물로 작용한다. 소프트웨어 아키텍처가 결정되면 설계패턴과, 설계 가이드라인을 사용하여 소프트웨어를 설계할 수 있다. 또한 소프트웨어 아키텍처가 결정되면 코드 작성시 코드 표준, 코드 가이드라인을 제공할 수 있다. 또한 소프트웨어 아키텍처는 소프트웨어를 시스템에 배포 시에 가이드라인을 제공한다.

이를 반복에 의해서 구조적으로 안정적인 소프트웨어 아키텍쳐를 구성할 수 있다.

Posted by 꿈꾸는자의 생각의파편들

소프트웨어 아키텍처의 구성요소에 대해서 상세하게 살표보면 다음과 같은 구성 요소로 이루어짐을 알 수 있다.

  • 시스템의 구성요소와 구성 요소 사이의 연결 관계
  • 시스템의 설계와 진화를 통제하는 원칙과 가이드라인
  • 시스템 구성 요소들의 collaboration ( 성과 )
  • 시스템이 어떻게 확장되고 수정될 것인가에 대한 결정
  • 시스템의 구성 요소들이 가지고 있는 기술

다음 그림은 소프트웨어 아키텍처의 구성요소를 보여준다.

그림 Ⅱ-1. 소프트웨어 아키텍처 산출물

그림 Ⅱ-1를 보면 소프트웨어 아키텍처는 세가지로 구분된다.

Meta-Architecture는 아키텍처를 설계하기 위한 일반적인 지침이다. Meta-Architecture는 소프트웨어 아키텍처가 무엇인지 결정하고 아키텍처를 설계하기 위한 일반적인 의사 결정 트리와 아키텍트의 역할에 대한 정의, 아키텍처 문서에 대한 템플릿으로 구성된다.

소프트웨어 아키텍처는 네 가지 View인 module view, component&connector view, allocation view, code view로 구성된다. 또한 아키텍처 설계의 결과로 컨텍스트 다이어그램, 컴포넌트 명세, 인터페이스 명세가 도출되어야 한다.

View에 대해서는 사람마다 정의하는 방법이 다양하므로 이에 대한 논란은 나중에 하도록 하고, 먼저 그냥 서술해보자. 이 View는 사람들마다 서술하는 방법, 기술하는 방법, 다이어그램의 형태, 박스/라인/인터페이스/컴포넌트의 수준과 깊이/의미등이 다 다르다.

다만, View의 선정 기준과 기술할 때 주의점만 살펴보면된다.

건축물을 설계할때의 조감도 및 설계도, 세부 설계도, 투시도 등등의 형태와 동일하다고 보면 된다, 필요 수준까지만 각자 알아서 그리면 되는 것이다.

일반적인 view는 3가지이다. Allocation View, Component & Connector View, Module View라 이야기하지만 저는 Code view를 하나 더 구분해야 한다고 본다. 너무 상세한 설명은 나중에 거론하기로 하고 하여간 4개의 View가 있다고 보자.

이 부분은 적어도 1개 이상에 대해서 기술하고 몇 개가 적절한 가는 개발자들의 역량과 도메인에 대한 이해, 이전 프로젝트의 경험 및 주요 이슈 사항등의 요소에 의해서 좌우되어진다.

다만, 시스템의 큰 기능, 품질 속성 ( 가용성, 변경성, 보안성, 성능 )의 판단 근거가 되어야 하며, 주요 모둘의 기능이 내/외부와 어떤 연관성을 가지는지 보여야 하고, 시스템의 규모와 범위를 파악할 수 있으면 된다.

또한, 위와 같은 아키텍쳐 기술 정의서를 구축할 때에 타당한 근거를 서술할 수 있으면 된다.

다만, 이 View를 UML 1.x영역에서는 표현하기 힘들었다. 너무 기술에 종속적인 패턴의 설계 혹은 컴포넌트의 배치 레벨에서의 작성이 주였기 떄문이다. UML 2.0울 구성할때에 OMG에서 카네기 멜론 SEI의 아키텍쳐 정의를 상당부분 도입하여서 이 부분들에 대한 기술이 이젠 수월해진 편이다.

OMG는 재미있는 기관이다. 좌우당간…

가이드라인과 정책은 소프트웨어 아키텍처를 결정한 후 아키텍처를 기반으로 프로젝트를 진행하기 위한 가이드라인과 정책을 말한다. 아키텍트는 설계, 코딩, 배포, 통합, 테스트, 툴, 유지보수, 시스템 확장, 시스템 운영에 대한 가이드라인과 정책을 마련해야 한다. 정말 포괄적인 개발정책 부분을 모두 서술하고 결정한다는 것이다.

소프트웨어 아키텍처는 시스템 개발의 여러 구성요소와 관련을 갖는다. 프로젝트 조직, 프로젝트 스케줄, 형상 관리 계획은 소프트웨어 아키텍처에 근거하여 결정된다. 소프트웨어 아키텍처를 설계하는 데는 프로토타입, 프레임워크, 유틸리티 프로그램 등이 영향을 끼친다.

Posted by 꿈꾸는자의 생각의파편들

소프트웨어 아키텍처의 정의

가장 먼저 다른 사람들의 소프트웨어 아키텍쳐에 대한 정의에 대해서 알아보고 이 곳에서 사용할 소프트웨어 아키텍쳐의 정의에 대해서 알아보도록 한다.

아직도 소프트웨어 아키텍쳐에 대한 '정의'는 무수히 많은 곳에서 정의되고 정답자체가 아직은 모호한 분야라고 할 수 있으므로, 각자 머릿속에 그 '정의'를 선택하거나 정의할 수 있고, 그 부분들에 대해서 생각해 봐야 한다.

소프트웨어 아키텍처의 정의들

  • 고전적인 정의

 

  • ANSI/IEEE Std 1471-2000정의

 

  • Bass, Clements, Kazman 정의

소프트웨어 아키텍처는 시스템의 구조, 시스템의 구조들에 대한 구조이다.

 

  • Dewayne E. Perry, Alexander L. Wolf 정의

소프트웨어 아키텍처는 특별한 형태를 가진 아키텍처 구성 요소들의 집합이다. 아키텍처 구성 요소는 세가지로 구분된다. 프로세스 구성 요소, 데이터 구성 요소, 연결 구성 요소로 구분된다.

  • Galarn and Perry 정의

소프트웨어 아키텍처는 프로그램이나 시스템의 구성 요소들 사이의 구조, 관계, 설계와 시스템 업그레이드를 통제하는 지침과 원칙이다.

  • Booch 정의

소프트웨어 아키텍처는 소프트웨어의 구조에 대한 중요한 의사 결정의 집합이다. 의사 결정에는 소프트웨어 구성 요소에 대한 선택, 인터페이스에 대한 선택, 구성 요소들 사이의 상호작용, 서브시스템을 구성하기 위한 구성 요소와 상호작용의 결합으로 이루어진다.

  • Myron Ahn 정의

소프트웨어 아키텍처는 모듈, 프로세스, 데이터, 이들의 구조, 구성 요소들 사이의 관계, 구성 요소와 관계들이 어떻게 확장되고 수정될 있는지, 사용하는 기술은 무엇 인지로 이루어져 있으며 소프트웨어 아키텍처를 통해 시스템의 유연성과 성능을 판단 있고 시스템을 어떻게 구현하고 수정할 있는지를 판단할 있다.

위의 같은 다양한 정의가 존재하므로 자신만의 정의를 만들거나 선택해보라, 실제적으로 이 개념들은 하고자하는 프로젝트에 따라 다르게 존재할 수 있다.

소프트웨어 아키텍처에 대한 정의

위의 정의들을 요약하여 소프트웨어 아키텍처를 다음과 같이 정의하여 보자..

소프트웨어 아키텍처는 시스템의 핵심 구성 요소와 구성 요소들 사이의 연결 관계로 이루지므로. 핵심 구성 요소는 시스템이 가지고 있는 모듈, 모듈 사이의 연결, 시스템의 변경, 진화하기 위한 기술적인 원칙, 모듈들 사이의 상호작용, 시스템이 동작하기 위한 기술을 모두 포함하는 것으로 정의한다.

소프트웨어 아키텍처는 구현할 시스템에 대한 top-down view이며 시스템에 대한 기술적인 명세서이며 공학적인 청사진이다.

기본적인 개념은 MDA에서 취하고 있는 방향과 유사하다.

Posted by 꿈꾸는자의 생각의파편들

소프트웨어 아키텍처 란?

본격적인 소프트웨어 아키텍쳐의 개념에 대해서 알아보도록 하자.

그렇다면, 소프트웨어 아키텍쳐란 무엇이며, 아키텍트란 누구이며, 그의 역할과, 소프트웨어 아키텍쳐를 통하여 개발 프로세스와 어떤 영향을 가지며, 소프트웨어 아키텍쳐와 다른 아키텍쳐가 어떤 관계를 가지는가에 대해서 알아봐야 한다.

이 곳에서는 실제 CBD나 개발방법론에 대해서 서술하지는 않는다. 다음 강의 때에 CBD와 연관성이 있는 부분에 대해서 서술해볼 것이다.

이 그림은 실제 CBD로 개발되어지는 개발 프로세스에서 산출물과 개발흐름에 대해서 포괄적으로 서술되어진 그림이다.

이러한 CBD의 전체적인 산출물 구조는 다음과 같다.

이 곳에서는 소프트웨어 아키텍쳐가 중요하므로 전반적인 프로세스에 대해서는 서술하지 않도록 한다. 다만, 참고적으로 살펴보기 바란다.

Posted by 꿈꾸는자의 생각의파편들

본 강좌의 목적

본 강좌의 목적은 다음과 같다.

첫째, 아키텍트가 프로젝트 시작 시점에서 투입되어 무엇을 하는지 시나리오를 작성할 수 있게 하며

둘째, 소프트웨어 아키텍처가 개발 프로젝트에 정착될 수 있도록 하고

셋째, 아키텍트의 역할에 대해서 정의를 하며

넷째, 아키텍트와 프로젝트의 구성 요소 사이의 관계에 대해서 이해를 한다.

다섯째, 소프트웨어 아키텍처가 포함된 개발 프로젝트의 프로세스는 무엇인가에 대해서 알아보고

여섯째, 아키텍트가 프로젝트에서 결정해야 할 항목은 무엇인가에 대해서 고민하는 것이다.

Posted by 꿈꾸는자의 생각의파편들

소프트웨어 아키텍처를 도입하면서 달성되는 목표

소프트웨어 아키텍처를 도입함으로써 다음과 같은 목표를 달성할 수 있도록 한다. 그 목표는 크게 다음의 세가지로 들 수 있다.

첫째, 견고하고 안정적이며 고품질의 시스템을 구축할 수 있다.

둘째, 시스템 구축 시 발생하는 문제들을 초기 단계에서 해결할 수 있다.

셋째, 아키텍트의 역할을 명확히 정의하여 20%의 고급 인력으로 80%의 프로젝트 인원을 리딩할 수 있다.

아키텍트는 비용과 목표에 대해서 가장 많은 고민을 하여야 한다. 최고의 개발자들로만 구성하여도 프로젝트는 실패할 수 있다. 튼튼하고 품질 좋고 나중에 문제 발생하지 않고, 비용이 적게든다면 최선이지 않은가?

그림 Ⅰ- 1. 아키텍처 적용 시 장점

그림 Ⅰ- 1은 소프트웨어 아키텍처 도입 시 시스템 개발 프로젝트에서 어떤 도움을 받을 수 있는지를 보여준다.

첫째, 소프트웨어 아키텍처 도입 시 아키텍처의 품질을 평가하여 비합리적인 의사 결정이 합리적인 의사 결정으로 변경된다.

둘째, 과거의 경험을 답습하거나 과거의 사례에서 배우지 못했던 것에서 소프트웨어 아키텍처를 재사용함으로써 과거 프로젝트의 성공과 실패 사례를 배우는 것으로 변경된다.

셋째, 프로젝트의 복잡성을 아키텍처를 통해 관리하는 것이 가능해진다.

넷째, 프로젝트 마무리 시점에서 발생하는 문제들을 아키텍처를 도입하여 프로젝트 초기에 해결할 수 있다.

다섯째, 설계자가 단순히 요구사항을 개발자에게 전달하는 것을 아키텍처를 통해 설계자가 요구사항 분석뿐 아니라 기술적인 문제도 모델링 할 수 있게 하며 개발자는 더욱 효율적으로 시스템을 구현하는 것이 가능하다.

Posted by 꿈꾸는자의 생각의파편들

이 문서는 제가 운영하는 SA까페에있는 내용을 정리하여 블로그에 재오픈하는 내용입니다. 몇가지 내용을 첨삭하여서 올리는 내용으로 많은 분들이 읽으시고 참조하신다면 저도 즐겁고 보는 분들도 즐거울듯 합니다.

요즘들어 아키텍트나 SA에 대해서 많이 이야기가 되고 있는데... 그 전반적인 것에 대해서 한번 정리하고 가능하면 쉽게 설명하려고 애썼는데...  문서나 강좌를 해보니... 많이 어렵습니다. ~.~

그래도... 많은 분들이 보셨으면 해서.. 다시 한번 정리합니다. ~.~
 


소프트웨어 아키텍처 Part 1

I
     
시작
배경

문서에는 소프트웨어 아키텍쳐에 대한 전반적인 소개자료와 기초개념에 대해서 설명하고 있다.

먼저, 소프트웨어 무엇인가에 대해서 다시한번 생각해보자.

여러가지 설명과 이해가 다르겠지만, 보편적인 부분만 설명한다면.

소프트웨어란 사용자가 원하는 서비스를 제공하기 위하여 정보기술을 활용하여 정보서비스를 구축하는 이라고 규정지을 있다.

   소프트웨어개발에 있어서 수많은 시간이 흘러왔으며, 그 작업을 하기 위한 다양한 방법론들과 시도들이 진행되어왔었다. 더더군다나,
소프트웨어 개발시의 가장 큰변화는, 과거의 1 중심인 프로그래머가 혼자 모든 것을 다하던 시대에서 설계자와 코더가 나뉘어지고, 다시, 시대의 흐름이나 서비스중심의 구조적인 설계를 하는 아키텍트의 시대에 까지 많은 변화와 발전이 있었다는 점이다.

여기서는 소프트웨어 아키텍처의 중요성이 부각된 이유를 설명하고 소프트웨어 아키텍처를 도입함으로써 어떤 목표가 달성될 것인가에 대해서 알아본다.

소프트웨어 아키텍쳐란 다음의 두가지가 가장 중요하다.

하나.   중요한 부분만 다루어야 한다.

둘.   아키텍트의 역할이 중요하다.

아키텍트는 소프트웨어를 개발할 때에 중요한 재료들을 다루어야 한다. 그것은 비용, 적용기술, 조직의 역량, 기능, 목표, 시스템의 복잡도에 대해서 아키텍트의 중요한 판단을 통하여 시스템을 구상하고 추상화하는 방법이다.

이것이 바로 소프트웨어아키텍쳐이다.

! 그렇다면.. 현실은 어떠한가?

1.1 프로젝트의 일반적인 경향

첫째, 기술적인 결정을 내릴 비합리적인 결정을 내리는 경우가 많다.

대부분 기술적인 결정은 경험에 의해 이루어지는 경우가 많다. 그러나 경험적인 해결책이 현재 진행 중인 프로젝트에서 부적절한 경우 또한 대다수인 경우가 많다. 실제로 경험적인 결정만으로는 프로젝트에서 적용할 기술에 어떤 위험이 따르는지 판단하기 어렵다.

하지만, 보통 프로젝트의 경우 경험이 많은 개발자들을 중심으로 PM PL 구성되어 지고 이들중에 PL들선에서 이러한 문제들을 해결하기 위한 미팅이나 회의가 많이 발생한다.

또한 기술적인 결정을 내릴 비용과 프로젝트 적합성을 따지지 않고 도입하는 경우가 많다. 경우 프로젝트의 기간을 줄이고 품질을 높이기 위해 도입된 기술이 오히려 프로젝트를 지연시키고 시스템의 품질을 떨어뜨린다.

기술적인 의사 결정이 프로젝트 중간에 흔들려서 프로젝트가 지연되는 경우가 종종 발생한다. 이것은 선택된 기술이 프로젝트에서 최적의 선택인지 고민하지 않았기 때문이다.

사용자의 요구사항에 기초하지 않은 의사 결정은 막연한 결과를 만들고 기술적인 의사 결정이 올바른 것인지 프로젝트 후에도 판단하기 어렵다.

의사 결정을 하기 위해 많은 시간을 소요하지만 합리적인 결정을 내리지 못할 때가 많다.

실제 영업적인 이유로 인하여 이와 같은 경우가 발생하는 경우도 다반사이다.

둘째, 새로운 프로젝트에서 과거의 경험을 답습하는 경우가 많다.

프로젝트는 전혀 새로운 환경 일때가 많고 프로젝트의 성격에 따라 최적의 선택을 해야 한다. 기술을 어떻게 선택할 것인지에 대한 정형화된 프로세스가 없으며 기술은 계속 변한다. 따라서 과거의 프로젝트 성공에 대한 경험으로 현재의 문제를 해결할 없다. 이점을 간과하는 경우가 많다.

따라서 많은 기술을 조합하여 현재 프로젝트를 위한 최적의 해결책을 찾아야 한다. 해결책은 사용자의 요구사항에서 논리적으로 도출된 것이어야 하며, 설명가능한 방식이어야 한다.

셋째, 과거의 프로젝트에서 배우지 못한다.

이것은 두번째 경우와 정반대의 경우이다. 과거의 프로젝트의 성공과 실패에서 원인 분석을 하지 못하면 성공한 이유도 실패한 이유도 없다.

프로젝트에서 대부분의 문제는 고객과 개발팀간의 커뮤니케이션 부재 때문에 발생한다. 또한 프로젝트의 범위 관리도 문제가 되며, 사용자의 요구사항을 어떻게 도출하고 관리할 것인가도 문제가 된다.

기술적으로는 시스템의 복잡성이 문제가 된다. 시스템의 복잡성은 개발자의 능력의 한계를 뛰어넘는 것으로 시스템을 복잡성을 줄이고 효율적으로 시스템을 구축하는 방안을 찾아야 한다. 기술적인 복잡성을 줄이고 합리적인 의사결정을 내리기 위해서는 기술적인 의사 결정을 초기에 내리고 적합한지 계속 테스트해야 한다.

또한 초기에 어떻게 프로젝트 조직을 구성할 것인가도 프로젝트 성공에 많은 영향을 끼친다. 역할 분담이 명확하지 않아서 책임 소재를 따지는데 많은 문제가 발생한다. 조직 구성도 프로젝트의 성격과 기술 Set 따라 달라진다. 프로젝트 팀원들이 도메인을 알고 사용하는 기술에 익숙한 경우와 프로젝트 팀원들이 도메인을 모르고 사용하는 기술도 모를 경우는 조직 구성이 달라져야 한다.

대부분 설계자가 요구사항을 정리하는 외에는 역할을 하지 못한다. 설계자가 어떤 일을 해야 하며 개발자에게는 무엇을 주어야 하는 지도 결정해야 한다.

1.1 국내 프로젝트의 경향

첫째, 신기술을 도입하여 무조건 쓰는 경우가 많다. J2EE 프로젝트의 성격에 맞는지, CBD 프로젝트의 성격에 맞는지 고민하여 프로젝트를 위한 최적의 선택을 경우가 많지 않으며 신기술에 대한 막연한 기대를 가지고 프로젝트를 시작한다.

둘째, 프로젝트의 복잡성이 증가되고 관리되지 않으면 어느 순간 통제할 상황에 빠진다. 경우 개발자들이 자체적으로 communication 통해 해결하는 경우가 많다.

셋째, 프로젝트 초기에 드러나지 않았던 문제들이 프로젝트 마무리 시점에서 드러나는 경우가 많다. 많은 오류가 프로젝트 마무리 시점에서 발생한다.

넷째, 설계자가 역할을 못하는 경우가 많음. 단순히 사용자의 요구사항을 정리하여 개발자에게 전달하는 역할만을 .

다섯째, CASE 툴의 사용이 개발 생산성 향상에 도움이 되지 않음. 개발자들이 시스템을 구축하기 위해 미리 준비되어야 많은 사항들을 개발자 스스로 만들어 가는 경우가 많다. 시스템 환경 셋팅, 테스트, 각종 사용 기법, utility 공통 코드, 코딩 표준 등을 개발자 스스로 결정한다.

여섯째, 몇몇 능력 있는 개발자들의 도움을 받아 프로젝트가 진행된다. (결과적으로 프로젝트에서 누군가는 아키텍트의 역할을 ) 그러나 능력 있는 개발자가 자신의 능력을 발휘하는 시점은 프로젝트의 문제가 발생하는 시점에서 이루어지고 개발자의 능력만으로 해결할 없을 정도로 이미 문제가 심각해진 경우가 많다. ( 프로젝트 초기 의사 결정에 이런 사람들을 참여시키지 않는가?) 프로젝트 팀원들이 프로젝트 관리자에게 의사결정을 요구하지만 기술적인 문제는 프로젝트 관리자가 의사결정을 내릴 없으며 몇몇 사람들의 의견을 구하거나 의사결정이 이루어지지 않은 프로젝트가 진행되는 경우도 있다.

일곱째, 요구사항에 대한 관리가 이루어지지 않는다. 요구사항이 시스템에 얼마 정도의 영향을 미칠 것인지, 아키텍처에는 얼마 정도의 영향을 미칠 것인지 판단하지 못함.

그렇다면 위와 같은 프로젝트의 경우에는 어떻할것인가?

프로젝트를 포기하는 것도 하나의 방법일 있다. 혹은, 제약사항을 머릿속에 두고 그와 같은 아키텍쳐를 그려낼 있는 방법을 도출하는 것도 방법이다.

어떤 프로젝트이던 최고의 방법은 없다. 최선의 방법만 존재할 . 실제 프로젝트에서는 최고의 비용, 최고의 기간, 최고의 프로그래머와 일하는 것이 아니기 때문이다.

이러한 것들을 해결하기 위하여 무수히 많은 것들이 존재하지만, 이곳에서는 이러한 문제들의 구조를 파악하고 소프트웨어를 제작하기 위한 소프트웨어 아키텍쳐에 대해서 서술해보자.

그리고. 아주 보통 간과하고 넘어가는 경우가 많은데. 다음의 예를 하나 살펴보자.

사용자들이 요구하는 아주 비기능적인 요소들이 있다.

동일 조회업무 화면을 여러 보이게 해주세요

.. 이러한 요구조건을 어떻게 해결해야 하는가? 생각보다 복잡하고 미묘한 문제들이 걸려있다. 어떤 부분인지 살펴보자.

일단, 어떤 사람이 개발한 업무화면이 ‘N’ 동작한다라는 것은 업무화면에서 여러 동작시키는 매커니즘을 활용하는 방법도 있을것이고, 해당 프레임워크를 제공할 수도 있을 것이고, 아니면, 웹과 마찬가지로 세션을 유지하지 않는 방법을 고려할 수도 있다.

사용자의 기능하나에 의하여 구조적인 모습이 전혀 엉뚱한 모습으로 변할 있다.

이러한 요구조건들이 품질요구사항으로 변하고 실제 소프트웨어의 아키텍쳐와 프레임워크, 솔루션의 도입, 개발자들의 가이드라인, 컴포넌트의 구성방식, 유지보수 방법등에 많은 영향을 주게된다.

부분을 간과하고 넘어간 경우를 살펴보자.

업무 분석을 하고 설계, 개발, 단위테스트, 통합테스트, 배포까지 무난하게 넘어갔다고 보자. 그런데, 실제 사용자가 요구한 것은 전체 업무의 형태를 위와 같이 N 동작하게 해달라 요구사항이었다고 나중에 밝혀졌다고 보자.

설계자는 요구조건에 맞는 프레임워크가 아니었다고 이야기 것이고, 개발자는 세션을 유지하는 C/S 프로그램으로 만들어 놨고, 공통 함수로 처리되는 방식으로 빠르게 개발할 것만 고려하고 플밍이 되었다고 보자.

과연 누구의 잘못인가?

이것이야 말로 아키텍트가 초기에 소프트웨어 아키텍쳐를 잘못설계한 케이스이다.

처음부터 이러한 상황을 고려하여 동작 가능한 구조로 만들어 주었다면, 문제가 발생하지 않았을 것이다.

개발자가 컴포넌트 개발도 할줄 모르는 공통함수개념과 화면별 단위 프로그램밖에 만들줄 모르는 개발자였다면, 해당 개발자들이 해당 요구조건을 모르고 코딩을 해도 실제 수행시에 아무 문제 없도록 시스템 메커니즘을 구현하였어야 했다.

해결방법은 아주 많은 방법들이 있다.


 


1  프로젝트의 현실

현재 일반적으로 SI이든 소규모개발사이던, 대형개발사이든 다음과 같은 문제들이 존재할 있다. 다만, 이러한 문제들이 도출되지 않는 조직에 계시다면 정말 행복한 사람이다.

이곳에서는 소규모 프로젝트라기 보다는 대규모 프로젝트인 경우에 한정을 지어서 생각해보도록 하겠다. 각각의 사례들은 규모에 따라 형태를 달리하는 경우가 많다.

프로젝트 A : EJB 기반으로한 EAI 제품 개발, 개발기간 3, 투입인원 4개팀 26

프로젝트 B : 패키지관련 모바일 솔루션 개발, 개발기간 6개월 투입인원 5

프로젝트 C : 온라인 게임개발, 개발기간 2 투입인원 12 ( 디자이너 제외 )

프로젝트 D : 공공기반 프로젝트, 개발기간 3 투입인원 연인원 60, 최대 130

프로젝트의 성공여부는 어디에 달려있는것일까?
   
누가 성공여부를 결정하는가?
   
과연 프로젝트는 어떻게 진행되는 것이 맞는가?

과연 방법론의 사용여부는 어디까지이며?
  
산출물의 작성기준은 어디까지인가?

소프트웨어아키텍트는 이러한 것들을 하나의 관점으로 바라 있도록 한다.

예를 들어본 프로젝트들을 살펴보면 프로젝트 A B 패키지 개발이고 실제 소프트웨어의 성향이나 목표에 대한 부분을 결정하는 것은 최고 경영자층과 CTO레벨에서 결정하는 내용이므로 오늘 설명할 내용에서 약간 벗어난다고 있다.

그리고, 프로젝트 C 경우에는 일반 고객들을 상대로 하는 프로젝트이기 때문에 해당 프로젝트도 일단, 범위에서는 제외한다. 프로젝트 A,B,C 대한 경험으로 별도의 각각 예제를 따로 준비중이고 아마도, 차후에 해당 내용을 발표할 듯 하다.

일단, 프로젝트 D 기준으로 한다. 사용자들이 정해져 있고 보통 SI라고 불리우는 사업인 경우이므로 이에 대해서 기술한다.

프로젝트 D 특징을 기술하면 다음과 같다.

하나.프레임워크나 솔루션이 투입되어 일정한 공수로 개발자들이 투입되어 개발한다.

둘.    기존에 정보시스템이 있거나 대체, 혹은 신규 개발하는 형태이다.

셋.    고객이나 사용자들이 일반사용자들에 가까우므로 IT관련 정보기술에 어둡다.

넷.    고급개발자들을 극소수로 밖에 사용할 없으며, 초급개발자들을 주로 사용하게 된다.

다섯.기간이나 비용등이 영업의 힘으로 결정되는 경우가 다반사이며, 생각보다 제약사항들이 많다.

여섯.고객의 요구조건을 어떻게 관리하고 품질의 영역이 불명확한 경우가 많다.

이러한 프로젝트들을 기준으로 세부적인 내용을 기술한다. 강의에서 이야기하는 프로젝트 이러한 부분들을 중심으로 기술한다.

Posted by 꿈꾸는자의 생각의파편들