[KOSTA] 실용적 SW 아키텍처 설계 1

실용적 SW 아키텍처 설계 1

05/14 ~ 05/15  김영온

아키텍처는 문제의 헤결해 주는 해결책을 제시하는 것이다.

아키텍처는 기술적인 문제 해결을 제시하는 것이다.

아키텍처의 의사 결정에 따라 설계와 코딩을 한다.

아키텍처에서 표준을 잘 잡았으면 프로젝트가 잘 진행될 것이다.

SW 아키텍처는 기존의 분석 설계 등에서 나온 것을 정리한 것이다.

아키텍처는 구조를 잡는 것이 메인 작업이다.

* 과정의 목적

* SW 아키텍처의 역할

  1. 

* AA + BA = Information Archtecture

* SW 아키텍처를 정리한 곳은 마이크로소프트이다.

* Reference Book

- 소프트웨어 아키텍처 이론과 실제

- 소프트웨어 아키텍처 문서화

- 소프트웨어 설계

* What is software architecture?

* Software architure

* Case study in software architure

* Software architecture 주요 이슈와 관심사

  - software Architure

  - 운영 환경 - OS, DBMS, WS/WAS, EAI/ESB, Storage,....

  - 개발 환경 - IDE, Modeling Tools, Other Tools(Testing Static Analysis, Build, Configuration, ...)

  - 프로세스 - 표준, 템플릿, 가이드

* Wrap-up

아키텍처 영향 주기 (AIC - Architure Influence Cycle)

소프츠웨어 아키텍처는 설계를 위하여 아키텍처를 구축하고 목표시스템 또는 어플리케이션을 구축하고 관리하는 것을 포함한다.

* SW 아키텍처 수립의 주요 활동

<-- 분석 작업 -->

1. 시스템 타당성 수림

2. 중요한 아키테거 요구사항 이해

<-- 의사 결정 -->

3. 아키텍처 생성 또는 선택

4. 아키텍처 문서화와 의사소통

5. 아키텍처 분석 또는 평가

<-- 설계 코딩 테스트 -->

6. 아키텍처 기반 시스템 구축과 테스트

7. 아키텍처에 따라 구축되었는지 확인

SW 아키텍처는 프로젝트 전체를 이끌어 가야 한다.

가장 이상적인 것은 PM이 SW아키텍처를 하는 것이 바람직하다.

* 케이스 스터디 : FCAPS 시스템

* 새로운 시스템에 대한 설계 개념 설정 로드맵

1. 초기의 전체적인 시스템 구조 설정

   - 참조 아키텍처

   - 전개 패턴(티어)

   - 외부 개발 컴포넌트

2. 주요 기능을 지원하기 위한 구조 파악

   - 아키텍처 패턴(도메인 개첵/컴포넌트)

   - 외부 개발 컴포넌트(프레임워크)

3. 나머지 동인 전부를 만족시키기 위하여 이전에 생성한 구조를 정련

   - 전술

* 전체 시스템에 대한 USE 케이스를 1장으로 작성

* 품질 속성 시나리오

* 제약 사항

* 아키텍처 관심사 : 기술적인 사항

* 설계 프로세스

ADD Step 1: 투입물을 검토한다.

ADD Step 3: 정련할 시스템의 하나 이상의 요소를 선택한다.

ADD Step 4: 선정 동인을 만족하는 하나 이상의 설계 관심사를 선택한다.

  - 참조 아케텍처

* 조별 토의 및 공유

아키텍처는 설계 및 코딩을 쉽게 할 수 있도록 구조를 잡아주는 것이다.

* 소프트웨어 개발의 분석, 설계, 개발, 운영 등의 전체적인 관리를 하고 싶다.

* 개발 단계에서는 아키텍처가 적용되었으나 운용단계에서 아키텍처가 관여되지 않아 시스템이 관리가 안되고 비대해 진다.

* 품질 관리 목적으로 아키텍처를 운영하는 것과 실제 개발자가 준수하지 않는 사이의 간격이 크다.

  - 정해진 것은 반드시 지키도록 해야하고, 지켜지지 않는 것은 검토해야 한다.

  - 지켜지지 않는 이유는 표준이나 프로세스가 잘 못 만들어진 경우가 많다.

  - 만든 사람도 무엇인지 잘 모른다.

  - SW 아키텍처가 개발자들이 이용할 수 있도록 구조화 되었는가가 중요하다.

* Biz.에서 S/W에 대한 요구 사항

* 고 품질(High Quality) - 고객이 원하는 업무를 잘 만들어 주는 것

* 짧은 납기 (Quick Delivery)

* 낮은 개발과 유지보수 비용 (Low Development and maintenance cost)

* 그런데 요구사항은

  - 불분명하고

  - 끊임없이 변하고

  - 너무 많고

* Market agility

  - Agile/Kanban --> DevOps(CD, MSA) --> Design thinking/Lean startup

* Mass customization - Reuse (프로젝트를 재활용하는 것)

  - Platform/Software Product Line Engineering

* S/W 품질 현황

* 프로젝트 재작업 비용 40 ~ 50% (Sarry Boehm)

  - 재작업 비용 중 요구사항 결함 비율 : 70~85%

  - 프로젝트 비용 중 요구사항 재작업 비율 : 28~42.5%

* 재작업 비용 44.7% (NIPA SW 공학백서 2014)

  - 내부 실패 26.1%, 외부 실패 18.6%

* 기능 사용 현황

  - 종종 사용 : 20%

  - 드물게 사용 : 30%

  - 거의 사용안함 : 50%

* 국내 금융회사 화면 사용 현황 - 2e 컨설팅

  - 자주 사용 35.8%, 19.7% 거의 사용 안함, 사용 안함 44.5%

* SW 생산성 향상 도구 - Which one is first?

* 빠르게 일한다(work fast)

  - 도구(tool)

  - 환경(environment)

* 현명하게 일한다(work smart)

  - 프로세스(process)

  - 방법(methon)

* 작업회피(task avoidance)

  - 재사용(reuse)

  - 단순화(simplicity)

  - 객체(object)

* 분석 설계를 잘하는 것은

  - 불필요한 것을 제외시킨다

  - 기존 것 중에서 재사용할 수 있는 것을 잘 활용한다

* 도구를 잘 쓰려면 프로세스를 잘 정리해야 한다.

* 검증되고 적용가능한 프로세스

* 프로세스를 내재화한 엔지니어

* 프로세스가 반영된 도구

  --> SW 아키텍트의 역할

* 표준 프로세스를 안지키면 범법자이다.

* 단순 반복 작업은 자동화한다.

* 아키텍처 방법

  - 프로세스 정립

  - 교육

  - 도구 설정

* 핵심 SW 경제학 레버리지 포인트

1. 구축할 SW의 량을 줄인다

   - 프로젝트 범위 내에서

     --> 막노동자도 범위를 벗어나면 추가 비용을 요구한다.

   - 사용할 것만

     --> 업무를 잘 알아야 한다. 고객의 의견을 일단 들어주고 추후에 필요성이 있는가를 재협의한다.

   - 중복없이

     --> 담당자들이 함께 참여

<-- 여기서 부터 아키텍처가 하는 일이다. 이전 것은 이미 정리가 되어 있어야 한다 -->

   - 재사용(reuse)

2. 재작업을 줄인다.

   - 검증된 프로세스 (표준, 가이드, 템플릿 포함) 확보

   - 전문가 역량 개발

<-- 제대로 된 회사는 여기까지가 이미 준비되어 있다 -->

   - 팀 빌딩

   - 예방적인 검토(인스펙션) - 모든 구성원의 능동적 참여

3. 자동화를 통하여 잔여 작업의 노동 집중을 줄인다.

   - 표준을 반영하여 내재화된 도구 사용

1. SW 프로세스

* 방법론 (methodology)

* Methodologies = Paradigm + Process Models

* Paradigm can be

  - Information Engineering (1990 ~ )

    - Structured (1970 ~ )

  - Object-Oriented (1990 ~ )

    - CBD (1990 ~ )

    - Aspect-Oriented, SOA, SW Product Lines, ....

* Process Models can be

  - Waterfall

  - Spiral

    - Prototyping

    - RAD

    - Iterative & Incremental, ...

    - Agile (Scrum, XP, SAFe, ....)

    - DevOps

    - Lean Thinking/Kanban/Toyoda Production System

* 아키텍처는 불확실한 상황을 빠르게 확인하여 제거하고 프로젝트가 빨리 진행되게 하는 것이다.

* 애자일 (agile)

* 90년대 후반 ASD, Crystal, XP, Feature Driven Development, Scrum 같은 애자일 방법 등장

* 애자일 방법은 소규모 프로젝트, 매우 숙달된 개발자, 급변하는 요구사항 그리고 혼란에서 성장하는

  문화에 매우 적합하다.

  3~4단 고수들이 진행할 때 적합하다.

  고객의 요구사항이 자주 바뀌면 애자일로 가야 한다.

* 시스템이나 고객 등의 모든 것을 잘알면 폭포수로 진행한다.

  무엇 하나라도 불확실하면 애자일로 간다.

* 그러나 기존에 만들어 놓은 것을 제대로 따라가는 경우가 매우 드물다.

  대신에 자신만의 고유한 꼼수(?)를 사용한다.

* XP는 고객 협업, 짧은 개발 기간, 단순한 설계, pair programming,

  refactoring(뭔가 불확실한 것이 있으면 코딩부터 해보라),

  continuous integration, TDD(타스크를 1~2일 단위로 세분화해서 진행한다.)가 주요 요소이다.

* SCRUM as Process Framework

  - Lightweight : 가볍다

  - 이해하기가 쉽다

  - 마스터하기가 어렵다

  - Self-organizing : 개발팀원은 자발적으로 구성한다, 책임을 져라

  - Cross-functional : 

* 데일리 미팅은 꼭 한다.

  팀원들간의 업무 공유를 위함이다.

  시간은 15분을 넘지 않는다.

  PL : 9시 정도

  PM : 13시 정도

* 애자일은 벤처회사나 제품을 만드는 회사에서 주로 사용한다.

  메인은 고수가 주도해야 한다.

* 데이터 모델링

  - 정규화를 제대로 해야 한다.

* 객체 모델링

2. 프로젝트 Lessons Learned

* H/W, S/W Platform 확정

* 인프라 영역 및 기술지원 인력

* 어플리케이션 아키텍처 범위

* S/W 아키텍처는 온라인 프로그램을 포함하여, 화면 스타일, 화면 스크립트, 배치 처리 프로그램,

  Unix Shell 프로그램, SQL 등 모든 프로그래밍 요소를 포함한다.

  - 어플리케이션의 규모가 커지면 서버의 분산, 채널 통합과 어플리케이션 통합, 데이터 복제

    솔루션의 적용이 필요하다.

  - 기업 업무용 어플리케이션 개발 프로젝트는 서버 분산, 데이터 구조 및 복제, 다양한 솔루션의

    통합이 주요한 아키텍처 이슈이다.

* 기술 검증

  검증되지 않은 기술과 업무는 반드시 개념검증 (PoC

* 아키텍처 고려 사항

  - 원칙적으로 로직은 어플리케이션 서버에만 구현한다.

    - 화면, DB, MCI, EAI 서버에 로직을 두지 않는다.

  - 시스템 간에 데이터를 직접 공유하지 않는다.

  - 데이터 복제 시 기준정보를 관리한다.

  - 보안에 대한 요구사항은 별도 영역으로 분석 단계부터 관리한다.

  - 어플리케이션 실행 로그 관리 대상을 명확히 하여 설계한다.

  - 서버에서 사용하는 트랜젝션 layout은 전사 차원에서 표준화한다.(표준 전문)

  - 프로그램 실행에 따라 사용하는 메시지는 정상 처리에 관련된 단순 메시지와 결함, 장애 등

    비정상 처리를 나타내는 오류 메시지로 구분하여 메시지 코드를 설계한다.

* 어플리케이션과 데이터베이스는 상호 밀접한 관계를 가지고 있다.

   - 논리 데이터 모델의 품질이 전체 시스템 품질의 중요한 요소이다.

   - 데이터 모델을 어플리케이션과 독립해서 개발하는 것은 가능하지 않다.

* 정규화 기법을 적용하여 논리 모델을 작성한다.

  - 논리 모델을 제대로 작성하지 않으면 좋은 AA를 개발할 수 없다.

  - 필요한 비 정규화는 설계단계에서 물리 모델 작성 시 실시한다.

* As-Is 데이터에 대한 이해를 바탕으로 To-be 데이터 모델을 개발한다.

  - As-is 데이터를 고려하지 않은 To-be 데이터는 나중에 데이터 이행을 어렵게 하고,

    어플리케이션의 추가 개발과 변경을 발생시킨다.

* 프레임워크란?

  - 프레임워크는 어플리케이션 개발에 필요한 라이브러리임

    - Java 환경에서는 Spring, Structs, Play, JQuery 등이 사용되고 있음

    - 적용기술을 일관된 방법으로 쉽게 사용할 수 있게 지원

* 국내 프레임워크 현황

  - SI사가 90년대 말부터 자체 프레임워크를 만들어 사용하다가 은행업무에 특화된 해외

    프레임워크의 기능을 벤치마킹하여 진화하였음

    - Open 소스인 이클립스에 다양한 도구를 plug-in 하면서 IDE로 포지셔닝

    - 프레임워크는 어플리케이션을 표준화하고, 일관되게 작성하는 기반을 제공하였으나,

      도메인 기능 추가에 대한 혼선으로 F/W의 포지션이 변하였음

* 공통 기능 구현

  - 어플리케이션 개발에 필요한 다양한 공통 기능을 포함하고 있다.

    - 회사마다 선호에 따라 프레임워크의 공통

* 아키텍트는?

  - 환상에서 벗어나라. 개발에 도움되지 않는 아키텍처는 죄악이다.

    - 개발에 필요한 아케텍처, 표준, 템플릿, 가이드를 만드는 것이다.

    - 검증되지 않은 이론은 입밖에 꺼내지 말고, 반드시 검증하라.

    - 적용사례가 없으면 반드시 검증을 실시한다.

  - 기술, 어플리케이션, 데이터 3가지 관점에서 통합한다.

  - 어플리케이션 개발과 운영 환경을 제공하고, 어플리케이션 유형별 구조와 함께

    개발과 운영에 필요한 단계별 표준, 가이드, 템플릿을 개발한다.

    - 완벽한 표준, 가이드, 템플릿은 존재하지 않는다.

    - 가이드와 교육 교재는 구체적인 샘플과 함께 만든다.

    -교육, 기술지원, 모니터링에 집중하고, 문제가 있으면 바로 보완한다.

  - 매 단계 말에 다음 단계의 표준과 가이드에 대한 교육을 실시하고, 산출물 작성에 대한

    지원과 가이드에 따라 산출물을 작성하고 있는지 모니터링 작업을 주도한다.

* What is Software acrhitecture?

* 설계 목적

* 시작하기 전에, 왜 설계하는지 분명히 알아야 한다.

* 설계 목적이 무엇을 어떻게 설계할 것인지를 결정한다.

* 설계 목적(예)

  - 프로젝트 제안의 일부(예, 사전 영업)

  - 탐구적 프로토타입 개발의 일부

  - 개발 중: 신규 개발, 리팩토링, 개선(refresh), ....

* 설계와 분석

* 설계는

  아키텍처 생성을 위하여 결정하는 것이다.

  - 어떠한 결정이

    바람직한 시스템 품질을 성공적으로 해결하

* 분석은

  사용할 아키텍처가 올바른 것이라는 것을 보증한다.

* 시스템은

* 아키텍처 동인

* 아키텍처 동인은

  아키텍처를 구성하는

  - 설계 목적

  - 품질 속성 요구사항

  - 주요 기능 요구사항

  - 아키텍처 관심사

  - 제약사항

  으로 이루어진다.

  이것은 비즈니스 목표에 따른다(driven).

  사업목적에 맞지 않는 것을 하면 배가 산으로 간다.

* S/W 아키텍처

* 적정 아키텍처 작업 비율

  - 적정한 수준의 아키텍처를 투자하면 전체 공수를 효율적으로 줄일 수 있다.

* 사업 context에서의 아키텍처

* 조직의 사업 환겨에 SW 아키텍처의 존재가 어떻게 영향을 미치는가?

  - 아키텍처와 사업 목표

  - 아키텍처와 개발 조직

  - 어떤 사업 목표는 아키텍처에 영향을 미치는 품질 속성 요구사항을

* 기술 context에서 아키텍처

  - 적용하는 기술이 SW 아키텍처에 어떻게 영향을 미치는가?

    - 아키텍처는 품질 속성 달성을 가능하게 하거나, 방해 한다.

  - 아키텍처와 기술 환경

    - 클라우드 컴퓨팅

    - 빅 데이터

    - SOA

    - 그리드 컴퓨팅

    - AOP

    - Social Networking

    - 모바일 웹

    - 패턴과 스타일

* 프로젝트 생명주기 context 에서의 아키텍처

  - SW 아키텍처가 어떻게 SW 개발 생명 주기의 다른 단계에 연결되는가?

    - 요구사항, SW 아키텍처, 설계, 구축, 테스팅

  - 4가지 주요한 SW 개발 프로세스

    - 폭포수 Waterfall

    - 반복적 Iterative (나선형)

    - 애자일 Agile (나선형)

    - 모델 주도 개발 (MDD - model-driven developerment)

* SW 아키텍처 활동

  1. 시스템 타당성 수립

  2. 중요한 아키텍처 요구사항 이해

  3. 아키텍처 생성 또는 선택

  4. 아키텍처 문서화 ***

* 전문 역량 context 에서 아키텍처

* 설계 다이어그램은 A4 1장 안에 표현될 수 있도록 구성한다.

  이렇게 하기 위해서 Package 다이어그램을 사용한다.

* 다이어그램은 필요한 것만 표현한다.

  개발자가 다이어그램을 이해하고 개발할 수 있도록 구성한다.

<-->