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

달력

09

« 2018/09 »

  •  
  •  
  •  
  •  
  •  
  •  
  • 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
  •  
  •  
  •  
  •  
  •  
  •  

프로젝트의 아키텍쳐 가이드라인 초입부분에..

사용자 인터페이스의 설계 원칙과 평가방법에 대하여..

정리한 내용입니다.

 

개발자들에게 한번 읽혔으면.. 하는 기분에... 정리한내용이죠..

별다른 내용은 없구요.. ㅎ.ㅎ

 

 

 

 

 

 

사용자 인터페이스 설계 원칙과 평가방법

 

Version 1.0

 
 

1.  개요

이 문서에서는 사용자 인터페이스를 설계하는 원칙과 평가방법에 대하여 서술한다.

1.1. 사용자 인터페이스 설계 원칙

가. 기본 설계원칙

(1) 이용자와 작업 중심의 설계

(2) 기능성 중심의 설계

(3) 이용자 관점에서 설계

(4) 이용자가 작업 수행을 간단, 명료하게 진행하도록 설계

(5) 배우기 쉬운 인터페이스 설계

(6) 단순 데이터가 아닌 정보를 전달하는 인터페이스 설계

(7) 적절한 피드백을 제공하는 인터페이스 설계

(8) 이용자 테스트를 통한 설계 보완

나. 기준

(1) 인간-컴퓨터 상호작용에 대한 설명

이용자와 상호작용을 하는 컴퓨터 시스템의 설계, 구현 및 평가를 연구하는 분야 ( ACM 1992 )
이 분야에서 연구하는 영역은 이용자-기계간의 협력 작업, 이용자 기계간 커뮤니케이션 구조, 설계 분야와 사회 및 기관과의 상호작용, 학습성, 인터페이스 알고르즘과 프로그래밍, 공학적 측면의 인터페이스 구축, 상세화 과정, 인터페이스 설계와 구현, 설계의 절충적인 요소 등이다. ( Dix et al, 1998 )

다. 주의점

(1) 서투른 설계는 크고 작은 실수를 유발하는데 이러한 크고 작은 부주의에 대처할 수 있는 안정되고 일관성있는 설계를 하여야 한다.

(2) 이용자 인터페이스는 시스템 구축에 있어 마지막 단계에 끼워 넣어지는 부분이 아니라 전체 시스템의 모든 부분과 통합되어 시스템 설계와 구현의 전 단계에 걸쳐 처리되어야 하는 분야이다.

(3) 이용자 인터페이스는 보기 좋은 화면의 구성을 의미하는 것이 아니고 이용자의 요구를 받아들여 요청작업을 수행하는 과정을 지원해야 하며 이용자의 부주의한 실수에 유연하게 대처할 수 있어야 한다.

(4) Shneiderman(1998)이 정의한 이용자 인터페이스 평가의 중요부분

배우는데 걸리는 시간 : 이용자가 작업 수행에 적합한 명령어나 기능을 배우기 위한 시간이 얼마나 필요한가?
작업실행속도 : 벤치마크 작업을 수행하는데 시간이 얼마나 걸리는가?
이용자 실수율 : 벤치마크 작업을 수행하는데 이용자는 얼마나 많은, 그리고 어떤 종류의 실수를 범하는가?
기억력 : 이용자는 한번 이용한 시스템의 이용법을 얼마나 오랫동안 기억할 것인가? 기억력은 배우는데 걸린 시간, 이용 빈도 등과 관련이 있다.
이용자의 주관적인 만족도 : 시스템의 다양한 기능들을 이용하는 것에 대한 이용자의 선호도는 얼마나 되는가? 이 질문에 대한 대답은 인터뷰나 설문조사 등을 통하여 얻어질 수 있다.
모든 인터페이스 설계자들이 위의 다섯가지 범주에 대하여 모두 성공적인 인터페이스를 목표로 삼지만 많은 경우 이들을 절충요소(tradeoffs)들에 직면하게 된다.

 

2.  인간-컴퓨터 상호작용

2.1. 상호작용에 대한 설명

가. 기본설명

(1) 이용자는 개인 이용자, 협력작업을 하는 이용자 그룹 또는 한 조직내의 이용자들을 의미한다. 각각의 이용자는 수행하고자 하는 작업을 가지고 있으며 이용자는 기술적인 요소를 이용하여 자신이 원하는 작업을 실행시키고자 하는 사람을 말한다.

(2) 시스템은 컴퓨터를 비롯하여 비컴퓨터적인요소, 즉 다른 이용자도 포함하는 개념이다.

(3) 상호작용은 이용자와 시스템 사이의 직접적 혹은 간접적인 일체의 커뮤니케이션을 말한다.

(4) 직접적인 커뮤니케이션은 작업 실행 과정에서 일어나는 명령과 피드백을 포함하는 의사 전달 과정을 지칭하며 간접적 커뮤니케이션은 작업의 후면 처리, 혹은 일괄 처리를 의미한다.

(5) 인간-컴퓨터 상호작용을 정리한다면, 이용자가 자신이 원하는 작업을 수행하도록 컴퓨터에게 지시를 내리고 컴퓨터의 반응을 인식하여 대응해 나가는 행위라 할 수 있으며 인터페이스를 위한 고정된 원칙은 존재하지 않는다.

(6) Dix는 인터페이스 설계 기술을 가치로 표현한다면 그 가치의 90%는 무정형의, 그리고 이용자를 대상으로 하여 유도된 것이라고 한다.

(7) 인터페이스는 완벽한 사용자를 대상으로 하면 안된다. 그 이유는 현실의 사용자는 인터페이스 설계자들이 상상하는 이용자들보다 훨씬 덜 완벽한 경우가 대부분이다. 이용자의 능력은 성별, 신체별, 지적인 면에서 개인차가 있고, 심지어 같은 이용자라 하더라도 심신의 건강상태나 피로도에 따라 능력차가 나타날 수 있다.

나. 상호작용에서 컴퓨터에 연관된 제한요소

(1) 컴퓨터가 기능을 수행하는데 속도와 관련된 것으로 빠른 속도의 컴퓨터를 이용하면 이용자가 심리적 부담감 없이 상호작용에 임하게 된다.

(2) 저장에 관련된 문제로 디스크에서 메모리로 데이터를 전달할 때 병목현상 등이 생길 수 있음을 의미하는데 이역시 시스템 속도에 영향을 미치게 된다.

(3) 그래픽 정보와 관련된 것으로 그래픽을 담고 있는 인터페이스의 경우 컴퓨터가 얼마나 빠르게 디스플레이를 하는가가 관련 있다.

(4) 네트워크 용량은 자원이나 파일 공유를 허용하지만 작업실행면에서 효율성이 떨어지는 결과를 가져올 수 있다.

다. 상호작용

(1) 이용자와 시스템 간의 이루어지는 커뮤니케이션이라 정의

(2) Norman(1988)은 상호작용 모델을 실행-평가모델(Execution-evaluation cycle)을 제시.

(3) 시스템의 목적을 이용자가 자신의 목적을 수행하도록 지원하는 것이라고 규정

(4) 실행단계의 4단계

목표수립
의도형성
행위의 순차적 상세화
행위의 실행

(5) 평가단계

결과의 인지
결과의 해석
목표, 의도에 근거하여 결과를 평가

 

(6) 상호작용에서 인터페이스가 이용자에게 문제점을 야기시키는 부분

실행상의 격차(Guifs of execution)
q   이용자가 행하고자 하는 행위와 시스템이 허용하는 행위에 차이가 있는 경우
평가상의 격차(Gulfs of evaluation)
q   이용자가 기대하는 결과가 실제 시스템에 의해 생성되고 보여지는 결과가 다른 경우

 

(7) 이용자 인터페이스 설계 원칙

상호작용의 유형

유형

설명

명령어방식

컴퓨터에 명령문을 직접 입력

장점 : 유연성, 반복적 작업에 유용하게 이용

단점 : 명령어 암기, 작업 지시에 도움이 되는 정보가 없음, 전문성을 갖춘 이용자에게 적합

메뉴방식

기억(Recall)보다 인식(Recognition)에 의존하는 방식

메뉴 아이테의 집합과 명칭이 이용자에게 유용한 암시를 충분히 제공하여야 함

자연언어이용방식

자연언어의 모호성이 혼동을 가져올 수 있음

이용 가능한 영역이 제한되어 있음

질의/응답 및 대화방식

질문과 응답으로 구성된 단계별 상호작용

배우고 이용하기 쉬우나 기능상 제한이 따름

스프레드시트

데이터 입력과 검색에 효과적으로 이용

데이터 값을 자유로이 조작할 수 있으나 유연성 있는 데이터 입력과출력이 요구됨

윔프(WIMP)

윈도우를 이용하는 시스템

Windows, Icons, Menus, Pointer를 말하기도 하고

Windows, Icons, Mice, Pull-down Memus를 지칭하기도 함.

아이콘은 임의로 정한 기호이므로 이용자가 이해하기 어려운 경우가 있음.

포인트와 클릭

하이퍼텍스트 개념과 밀접한 관련이 있음

터치스크린 환경에서 사용될 수 있음

삼차원 공간 이용

공간적인 여유를 제공하고 자연스러운 입체감을 연출할 수 있음

 

(8) Norman의 설계원칙

가시성(Visibility)의 원칙 : 중요한 부분은 눈에 띄어야 하고 그런 부분들의 의미를 바르게 전달 할 수 있어야 한다. 눈에 잘띄도록 배치하여야 하며 각 기능의 의미를 잘 전달하는 표현이나 기호를 사용해야 한다.
대응(mapping)의 원칙 : 대응은 어떤 기능을 통제하는 조절장치와 그 기능을 담당하는 부분이 잘 연결되어 표현되는 것을 의미한다. ( 부분대응과 완전한 대응 )
행동유도성(Affordance)의 원칙 : 아이콘이나 의미는 각각 모양이나 다른 특성에 의해 그것들을 어떻게 이용하는가에 대한 암시를 제공한다는 점. 버튼은 눌러야 한다는 행위등의 지시를 의히한다.
피드백의 원칙: 적절한 피드백의 제공으로 동기부여에 중요한 요소이다. 만약 시스템의 작업수행에 지연이 발생했을 때 이용자가 좌절이나 포기를 하지 않도록 하는데 있어 피드백은 가장 중요한 원칙이다.

 

(9) Dix의 설계원칙

이용자의 작업에 적합해야 한다.
이용하기 쉬워야 하고 이용자의 지식이나 경험 수준에 따라 이용자에 맞는 기능이나 내용이 제공되어야 한다.
작업실행에 대한 피드백이 제공되어야 한다.
정보의 디스플레이가 이용자에게 적당한 형식과 속도로 이루어져야 한다.
인간공학적인 측면을 고려해야 한다.

라. 뒷밧침 계획

(1) 이용자 모델링, 작업분석, 유용성 테스트, 설계과정의 방법이 제공됨

(2) 이용자 요구 모델링, 인지 모델 -> 이용자의 요구나 인식, 정신작용의 측면들을 파악할 수 있고 이용자의 물리적, 사회적, 문화적 환경에 대한 이해가 인터페이스 설계에 유용하다.

(3) 이용자가 수행하는 작업을 이해하고 작업수행을 지원하는 인터페이스 설계를 위하여 작업분해(Task decomposition), 지식기반분석(Knowledge-based analysis), 개체-관계분석(Entityrelationship-based analysis)가 이용된다.

마. 인간공학적인 측면

(1) 인간의 신체적 특징을 바탕으로 한다.

(2) 기능조작을 담당하는 요소들의 배치는 기능성

(3) 작업의 순서, 이용빈도를 고려한다.

(4) 시스템을 이용하는 장소, 이용자 집단의 특성

(5) 이용시의 자세등 물리적 환경에 대한 이해가 필요하다

(6) 이용자의 건강, 색채의 이용도 고려해야 한다.

 

바. Johnson 의 설계 원칙

(1) 질문

이용자와 이용자가 수행하는 작업을 중심으로 한 설계
q  누가 주된 이용자층인가?
q  이용자에게 어떤 기능을 제공하는 시스템을 설계하는가?
q  현재 이용자의 작업 수행 방식의 장점과 단점은 무엇인가?
q  이용자의 기술과 지식 정도는?
q  이용자가 선호하는 작업수행방식은 무엇인가?
기능적인 측면
q  화려한 화면이 아닌 시스템이 제공하는 기능 혹은 역활에 염두에 두는 인터페이스
q  인터페이스의 목적, 구조, 조직 등을 고려한다.
이용자의 관점에서 구축
q  이용자로 하여금 부자연스러운 기능 수행을 요구하지 말아야 한다.
q  임의적인 제한요소들을 제거해야 한다.
q  언어사용은 이용자들이 이해하기 쉬운 단어와 표현을 사용한다.
q  프로그램 코딩에 관련된 전문용어가 이용자에게 노출되지 않도록 한다.

(2) 설계 원칙

이용자와 작업 중심의 설계
기능성 중심의 설계
이용자 관점에서의 설계
이용자가 작업 수행을 간단, 명료하게 진행하도록 설계
q  마법사 기능
q  이용자별 요구사항을 반영하는 커스터마이제이션
q  이용자가 기술적인 측면을 이해할 필요없이 해야 한다.
배우기 쉬운 인터페이스 설계
q  안에서부터 밖으로의 사고(Think inside-out)

m   흔희 실수.. 시스템과 기술적인 면을 이용자에게 요구

q  밖에서부터 안으로의 사고(Think outside-in)
q  바람직한 방법은 이용자게 이해하고 알고 있는 방식을 시스템에 적용시키는 것
q  배우기 쉬운 인터페이스는 일관성 있는 설계를 통하여도 이루어진다.
q  하나의 기능은 하나의 단어와 하나의 아이콘, 버튼으로 이루어져야 한다.
데이터가 아닌 정보를 전달하는 인터페이스 설계
q  시점의 이동순서, 전달되는 정보에 적합한 매체를 사용한다.
적절한 피드백을 제공하는 인터페이스 설계
q  실행의 성공여부와는 별개의 것이다. 명령을 인지하였다는 것과 처리중임을 표시한다.
q  실행시간이 0.1초이상인 경우는 커서의 모양을 변경
q  1초 이상인 경우는 남은 실행 시간을 표시한다.
q  1초 이상의 침묵은 인간이 불편한 상태를 느끼게 한다.
이용자 테스트를 통한 설계 보완
q  미리 문제점을 파악하고 설계에 반영한다.
q  일관성있는 설계
q  배우기 쉬운 인터페이스
q  적절한 반응의 제공

3.  인터페이스 평가방법

3.1. 평가방법 기준

가. 기본 기준

(1) 인터페이스 구성요소 : 버튼, 메뉴, 다이얼로그 박스의 적절한 선택과 올바른 사용

(2) 구성요소의 배치와 외양 : 적절하게 선택, 사용된 구성요소들을 인터페이스에 어떻게 배치하는 가

(3) 인터페이스를 통한 이용자-시스템 상호작용 : 이용자의 주관적인 만족감

(4) 반은 : 피드백의 요소, 작업 수행의 속도를 잘 지워하는가? 간접적인 요소로 어떻게 느끼는가?

나. GUI구성요소와 인터페이스 평가

(1) 다이나믹 메뉴의 경우 사용자가 혼란스러움을 느낄 수 있다

(2) 자신이 원하는 기능이 숨어있을 경우 초보자가 찾지 못하는 경우가 있다.

(3) 중복된 메뉴 아이템으로 하나의 명령어를 두 곳 이상의 메뉴바에 위치하면 혼란 스럽다.

(4) 숨은 기능의 요소를 배제하라.

다. 구성요소의 배치 및 외양 인터페이스 평가

(1) 다이얼로그 기능 통제 버튼과 내용 통제 버튼을 같이 나열하는 방법과 나누어 배치하는 방법

대부분의 이용자가 읽어가는 순서
이용빈도
다른 기능 버튼과의 관련성
이용자가 기대하는 방식
적절한 그룹박스의 이용
올바른 레이블링과 스페이스 사용, 글자 폰트의 크기

라. 상호작용 인터페이스 평가

(1) 어떻게 표현되는가 보다는 어떻게 기능을 수행하는가에 초점을 맞춘다. 이 부분은 숫자적으로는 적지만 이용자에게 미치는 영향은 더크다. 이 상호작용 범주의 실수는 범위가 포괄적이어서 하나의 실수를 수정하기 위해 여러 가지 구성요소의 사용이나 배치 등 다른 범주의 실수를 수정해야 하는 경우가 생기기 때문이다. 또한, 이 실수는 직접적인 원인을 찾기 어렵다.

(2) 시스템 구현의 제한을 노출시키거나 임의적인 제한을 부여한다는 점이다.

 

(3) 화면의 연결에 일관성이 있어야 한다. 이용자로 하여금 혼란을 겪고 방향성을 일도록 함늗렴 안된다.

(4) 적적한 반응제공 인터페이스 평가

이용자의 요구에 대하여 인터페이스가 시스템과 연결하여 얼마나 즉각적이고 충분한 대응을 하는 가와 관련된 것이다.
문자키 입력상태, 포인터의 변환, 마우스 클릭 등 이용자의 모든 행위에 인터페이스는 즉각적인 반응을 나타내어야 한다.
명령 실행이 지연될 경우 커서의 모양 전환 등을 통하여 적절한 정보를 표시해야 한다.
다음 예상명령이 있는 경우 사전처리를 시작해서 명령이 들어왔을 경우에 바로 대응해야 한다.
이용자 실수율을 최소화 해야 한다. 문제는 이러한 이용자 실수율을 최소화하기 위한 인터페이스를 위해서 작업 실행속도는 희생되어야 하는 경우가 많다.
유용성을 보장해야 한다.
어떤 부분이 포착되는가?
이용자 참여 설계(participatory design)방법이 필요하다.
Posted by 꿈꾸는자의 생각의파편들

품질 속성과 프로파일

  • 개념
    • 품질 속성은 관련된 프로파일을 갖는다.
  • 프로파일에 대한 정의

시나리오의 집합으로 시나리오에 대한 중요도를 가지고 있음

  • 프로파일의 종류
    • Usage scenario
    • Hazard scenario
    • Change scenario
  • 프로파일을 명세하는 방법
    • Complete profile
    • Selected profile
  • 프로파일의 목적

소프트웨어 품질 요구사항을 명세하기 위해 필요함.

  • 프로파일 명세 절차
    • 시나리오의 카테고리를 결정함.
    • 카테고리에 대한 시나리오를 정의하고 선택함.
    • 시나리오에 대한 가중치를 부여함.
  • 프로파일 생성 방법

개인이 프로파일을 준비하고 그룹에서 토론을 거쳐 시나리오의 비중을 결정한다.

프로파일에 대한 템플릿

-2. 프로파일 템플릿

NO. 

Category 

시나리오에 대한 설명

비중

S1 

     

S2 

     

S3 

     

S4 

     

ID 

Category 

C1 

 

C2 

 

C3 

 

프로파일의 예

  • Haemodialysis 시스템 유지보수에 대한 프로파일

-3. 유지보수 프로파일

Category 

시나리오에 대한 설명

Market Driven 

S1 섭씨에서 화씨로 온도 측정 단위를 바꾼다.

Hardware 

S2 second concentrate pump와 conductivity sensor를 추가한다.

Safety 

S3 막을 통해 역류가 흐르는 것을 경고한다.

Hardware 

S4 duty-cycle controlled heater를 interfaced heater로 대체한다.

Medical Advances 

S5 역 로그 함수를 사용하여 weight loss curve를 수정한다.

Medical Advances 

S6 fixed flow limit에 대한 경고를 처방에 따라 변경한다.

Medical Advances 

S7 환자 혈압에 대한 센서와 경고를 추가한다.

Hardware 

S8 분당 혈류 계산을 실제 시간당 흐름의 혈류로 계산한다.

Com. And I/O

S9 환자 데이터에 처방 데이터를 넣는 기능을 추가한다.

Algorithm Change 

S10 PI에서 PID로 흐름을 집중시키기 위한 알고리즘을 변경한다.

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

아키텍처 관련 요구사항 파악 절차

  • 아키텍처 설계 절차와 요구사항의 관계

그림 -22. 요구사항과 아키텍처 설계의 관계

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

이 장에서는 아키텍처의 입려물인 요구사항을 정의하는 절차와 산출물에 대해서 살펴본다.

  • 요구사항의 유형

요구사항은 고객의 요구사항인 업무 개선 사항과 제품의 특성, 상세한 요구사항 문서로 나누어진다.

그림 Ⅲ-14. 요구사항의 유형

그림 Ⅲ-15. 요구사항과 테스트의 관계

업무 개선 사항은 고객의 영역이며 고객의 원하는 요구사항을 잘 관리해야 한다. 제품 특성과 요구사항은 개발 프로젝트 팀의 영역이며 업무 개선 사항을 듣고 상세화시켜야 한다.


업무 개선 사항에 대한 정의

AS-IS에서 To-be의 개선사항들에 대해서 정의를 한다.

제품 특성에 대한 정의

그림 Ⅲ-16. 제품 특성에 대한 분류

제폼의 특성은 기능적인 특성, 품질에 대한 특성, 제품의 제약 사항, 시스템에 대한 특성으로 나누어진다.

  • 제품 특성의

그림 Ⅲ-17. 은행 시스템의 특성

위의 그림은 제품 특성의 예를 보여준다. 제품 특성은 간단히 한 줄로 시스템의 특징을 설명할 수 있어야 한다.


요구사항에 대한 설명

이 절에서는 앞절의 요구사항에 대하여 상세하게 설명한다.

  • 요구사항 유형들 사이의 관계

그림 Ⅲ-18. 요구사항 유형들 사이의 관계

  • 요구사항 문서와 요구사항 유형 사이의 관계

그림 Ⅲ-19. 요구사항 유형과 요구사항 문서의 관계

  • 요구사항의 추적성

그림 Ⅲ-20. 요구사항의 추적성

  • 요구사항 관련 문서들 사이의 관계

그림 Ⅲ-21. 요구사항 관련 문서들 사이의 관계

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

아키텍처 관련 산출물의 개요

이 절에서는 방법론의 각 단계별로 필요한 입력 산출물과 출력 산출물을 제시한다.

표 Ⅲ-1. 아키텍처 관련 입출력 산출물

단계

활동

작업

입력 산출물

출력 산출물

비즈니스 요구사항

비즈니스

모델 개발

비즈니스 유즈케이스 모델 개발

 

비즈니스 유즈케이스 모델

업무 규칙

비즈니스 객체 모델 개발

 

비즈니스 객체 모델

요구사항

파악

요구사항 수집 및 기술

업무 규칙

요구사항 정의서

요구사항 추적표

현행 조직 및 시스템 정보 수집

 

현행 운영 정보 분석서

시스템 비전 개발

요구사항 정의서

현행 운영 정보 분석서

시스템 비전 기술서

솔루션

아키텍처

요구사항

정의

유즈케이스 모델 개발

비즈니스 유즈케이스

모델

요구사항 정의서

유즈케이스 모델

클래스 모델 개발

유즈케이스 모델

클래스 모델

UI 프로토타입 수행

유즈케이스 모델

클래스 모델

UI 프로토타입

요구사항 분석

유즈케이스 모델 분석

유즈케이스 모델

클래스 모델

유즈케이스 모델

클래스 모델 분석

유즈케이스 모델

클래스 모델

클래스 모델

동적 모델

UI 흐름 정의

유즈케이스 모델

UI 정의서

아키텍처 설계

아키텍처 관련 요구사항 분석

요구사항 정의서

현행 운영 정보 분석서

업무 규칙

비즈니스 유즈케이스 모델

유즈케이스 모델

클래스 모델

동적 모델

제안서(시스템 구성도)

아키텍처 요구사항 분석서

  • 품질 프로파일
  • 요구사항 정의서
  • (업무규칙, 시스템 제약 사항)
  • 유즈케이스와 품질 관련 표
  • 하드웨어 아키텍처

 

시스템 컨텍스트 정의

하드웨어 아키텍처

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

Component&Connector

View 작성

아키텍처 요구사항 분석서

하드웨어 아키텍처

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

소프트웨어 아키텍처 정의서(추가)

Module View 작성

아키텍처 요구사항 분석서

하드웨어 아키텍처

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

소프트웨어 아키텍처 정의서(추가)

Allocation View 작성

아키텍처 요구사항 분석서

하드웨어 아키텍처

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

소프트웨어 아키텍처 정의서(추가)

Code View 작성

아키텍처 요구사항 분석서

하드웨어 아키텍처

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

소프트웨어 아키텍처 정의서(추가)

아키텍처 평가

아키텍처 평가 준비

작업

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

아키텍처 요구사항 분석서

테스트 시나리오

소프트웨어 아키텍처 평가 절차서

프로토타입

아키텍처 평가

테스트 시나리오

소프트웨어 아키텍처 평가 절차서

프로토타입

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

소프트웨어 아키텍처 평가 결과서

아키텍처 상세화

아키텍처 스타일 적용

아키텍처 설계 가이드라인

소프트웨어 아키텍처 정의서(update)

설계 패턴 작용

의사결정 트리

설계 가이드라인

소프트웨어 아키텍처 정의서(update)

설계 지침 작성

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

의사결정 트리

설계 지침

소프트웨어 아키텍처 정의서(update)

설계지침(update)

코드 지침 작성

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

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

코드 표준

코드 템플릿

코드 샘플

컴포넌트 식별 및 명세

컴포넌트 식별 및 구조화

유즈케이스 모델

클래스 모델

동적 모델

소프트웨어 아키텍처

정의서

컴포넌트 명세서

인터페이스 식별

유즈케이스 모델

클래스 모델

동적 모델

소프트웨어 아키텍처

정의서

컴포넌트 명세서

컴포넌트 상호 작용 분석

유즈케이스 모델

클래스 모델

동적 모델

소프트웨어 아키텍처

정의서

컴포넌트 명세서

컴포넌트 명세 작업

컴포넌트 명세서

컴포넌트 명세서

컴포넌트 조달

컴포넌트 평가 기준

선정

요구사항 정의서

유즈케이스 모델

클래스 모델

동적 모델

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

컴포넌트 평가 기준

컴포넌트 선정 및 구매

컴포넌트 평가 기준

컴포넌트 명세서

재사용 컴포넌트

Posted by 꿈꾸는자의 생각의파편들
  • 요구사항 파악 활동

그림 Ⅲ-5. 요구사항 파악 활동

요구사항 수집 및 기술에서는 기능적 요구사항과 비기능적 요구사항을 파악한다. 비기능적 요구사항은 품질에 대한 요구사항, 시스템 제약 사항을 기술한다.

  • 비즈니스 모델 개발 활동

그림 Ⅲ-6. 비즈니스 모델 개발 활동

비즈니스 모델 개발 활동에서는 기능적 요구사항에 업무규칙을 추가한다.

  • 요구사항 정의 활동

그림 Ⅲ-7. 요구사항 정의 활동

요구사항 정의 활동에서 초기 아키텍처 정의는 삭제되었다.

  • 요구사항 분석

그림 Ⅲ-8. 요구사항 분석 활동

요구사항 분석 단계는 기존의 방법론과 동일하다.

  • 아키텍처 설계 활동

그림 Ⅲ-9. 아키텍처 설계 활동

아키텍처 설계 활동에서는 아키텍처를 모델링 한다.

  • 아키텍처 평가 활동

그림 Ⅲ-10. 아키텍처 평가 활동

아키텍처 평가 활동에서는 작성된 아키텍처 문서를 평가하여 요구사항이나 품질을 만족하는지를 판단한다.

  • 아키텍처 상세화

그림 Ⅲ-11, 아키텍처 상세화 활동

아키텍처 상세화 활동에서는 평가된 결과를 바탕으로 아키텍처를 상세화 하고 상세 설계가 필요한 부분에 대해서는 상세 설계하고 구현까지 진행한다. 또한 설계와 구현을 진행하기 위한 가이드라인과 지침을 작성한다.

  • 컴포넌트 식별 명세

그림 Ⅲ-12. 컴포넌트 식별 및 명세 활동

컴포넌트 식별 및 명세 활동에서는 컴포넌트를 식별하고 컴포넌트와 인터페이스에 대한 명세서를 작성한다.

  • 컴포넌트 조달

그림 Ⅲ-13. 컴포넌트 조달 활동

컴포넌트 조달 활동에서는 식별된 컴포넌트를 바탕으로 유사한 기능을 가진 컴포넌트를 조달한다.

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

이 절에서는 소프트웨어 아키텍처 설계 절차와 CBD 방법론의 관계를 보여준다.

  • CBD 방법론

그림 Ⅲ-3. CBD 방법론

그림 Ⅲ-3는 기존의 CBD 방법론을 보여준다. 기존 방법론에서는 아키텍처 정의 단계가 있었지만 아키텍처를 설계하는 상세한 지침은 마련되어 있지 않았다.

  • 개선된 CBD 방법론

그림 Ⅲ-4. 개선된 CBD 방법론

개선된 CBD 방법론은 기존의 아키텍처 정의 단계를 아키텍처 설계, 아키텍처 평가, 아키텍처 상세화로 세분화 시킨다.

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

반복을 통한 소프트웨어 아키텍처 설계 절차

그림 Ⅲ-2. 반복을 통한 소프트웨어 아키텍처 설계 절차

그림 Ⅲ-2은 소프트웨어 아키텍처가 프로젝트의 각 단계에서 어떻게 작성되는지를 보여준다. Inception 단계에서는 아키텍처 팀을 구성하고 아키텍처에 대한 개략적인 안을 작성한다. Elaboration 초기 단계에서는 핵심 아키텍처를 설계한다. Elaboration 후반부에서는 추가 요구사항을 받아서 아키텍처를 계속 수정한다. Construction 단계에서는 개발 도중 이슈가 발생하면 아키텍처를 보완한다.

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

소프트웨어 아키텍처 설계

본 장에서는 소프트웨어 아키텍처를 설계하는 절차와 기법을 제시한다.

소프트웨어 아키텍처 설계 개요

소프트웨어 아키텍처 설계 절차는 그림 Ⅲ-1과 같다.

그림 Ⅲ-1. 소프트웨어 아키텍처 설계 절차

소프트웨어 아키텍처 중 논리적 아키텍처를 구성하기 위하여 업무도메인을 분할하고, 업무도메인의 서브도메인을 파악하여 이들간의 관련성(interface)를 정의하는 데서 시작한다. 정의된 어플리케이션 아키텍처에 맞게 전 도메인 또는 서브도메인에 대한 아키텍처 구조에 맞게 상세설계 및 구현을 실시한다.


그리고, 소프트웨어 아키텍처 설계는 고객의 요구사항에서부터 출발한다. 고객의 요구사항은 요구사항정의단계에서는 인터뷰를 통한 회의록, 인터뷰시트로 파악되며, 분석설계단계에서는 유즈케이스 설계서를 통하여 구체적으로 파악되게 된다. 이러한 고객의 요구사항을 통하여 소프트웨어 아키텍처에 고려해야 할 요소를 파악하는 기술이 필요하다. 이때 요구사항의 우선수위 결정을 위하여 본 어플리케이션 시스템의 중요한 품질요소를 결정하는 게 좋다. 우선순위를 가지는 품질요소를 통하여 요구사항에 대한 작업우선순위를 결정하게 되며, 전체 어플리케이션 아키텍처에 해당 요구사항의 변경이 얼마만큼 영향을 미치는지도 결정하게 된다.


따라서, 기본적인 소프트웨어 아키텍처 설계 방법은 세가지 단계로 구성된다. 간단히 설명하면, 기능기반아키텍처 설계, 아키텍처 평가와 아키텍처 전이로 구성된다.


품질요소기반 소프트웨어 아키텍처 설계 방법은 두 개의 반복적인 설계 프로세스로 구성된다. 내부 반복 프로세스는 소프트웨어 아키텍처의 품질 요구사항의 설계, 평가, 전이로 크게 나눠볼 수 있다. 외부 반복 프로세스는 고객의 요구사항을 품질요소에 따른 선택하는 방법에 대한 활동으로 이루어진다.


반복적 소프트웨어 아키텍처 개발 사이클의 외부 소프트웨어 설계는 요구사항 중 가중 높은 고려대상이 되는 제품에 대한 품질요구사항으로 시작된다. 이는 또한 요구사항들의 내부 반복 프로세스를 진행하게 된다. 외부 반복 프로세스는 모든 요구사항이 어플리케이션 아키텍처에 고려될 때까지 나머지 요구사항을 반복하게 된다. 선택된 요구사항은 그림 4과 같이 소프트웨어 아키텍처 분석/설계 및 개발을 위한 핵심 소프트웨어 아키텍처 개발을 통하여 수행된다. 이 과정을 통하여 소프트웨어 아키텍처의 반복적인 수정의 기본 단위 작업들이 수행된다. 여러 개 요구사항은 반복적 소프트웨어 아키텍처 개발 사이클을 통하여 품질요소의 우선순위 또는 작업의 우선순위에 따라 핵심 소프트웨어 아키텍처 개발을 수행하게 된다.


내부 반복 프로세스는 소프트웨어 아키텍처가 구현되는 기본이 되는 요구사항들로 이루어진다. 내부 반복 프로세스의 초점은 품질요소의 평가와 전이이다. 어플리케이션 아키텍처 설계 방법은 목표, 관계상 설계 과정, 균형과 최적화를 지원하도록 제공된다. 반복적인 방법은 모든 품질요구사항이 만족될 때까지 각각의 품질요구사항을 지원하고, 전이로 사용되는 아키텍처로 반영된다.


완성된 어플리케이션 아키텍처는 업무 서브 도메인별 유즈케이스로 상세설계 또는 구현이 되며, 각 요구사항에 대한 단위 테스팅 수행 전체 시스템의 제품을 완성시키기 위한 반복적인 분석/설계 과정으로 대량생산체계를 수립한다. 이때 수정되는 비 기능적인 요구사항은 품질요소에 따라서 평가되어 어플리케이션 아키텍처를 재 수정과정을 통하여 변경된 어플리케이션 아키텍처에 대한 제품적용을 한다. 따라서, 소프트웨어 아키텍처 설계 방법은 소프트웨어 아키텍처 설계와 관련한 프로세스정의뿐만 아니라, 이러한 아키텍처를 설계하기 위한 소프트웨어 아키텍처 문서(SAD : Software Architecture Document)와 설계적 의사결정물 들로 구성된다.

소프트웨어 아키텍처 설계 방법인 그림 5를 살펴보면, 기본적으로 요구사항 정의를 분류한 기능적 요구사항을 기반으로 해서 출발한다. 비록 소프트웨어 엔지니어가 품질요구사항을 명확하게 정의하지 않으면 시스템은 안정적 또는 재사용될 수 없도록 설계되는 게 일반적이다. 이러한 소프트웨어 아키텍처 설계는 품질 요구사항 측면에서 많이 평가된다. 각각의 품질요소는 소프트웨어 아키텍처가 지녀야 할 정량적 또는 정성적 예상 값으로 평가된다. 아키텍처 전이 단계 동안에는, 아키텍처는 적절한 품질요소를 최적화하는 전이 방법을 선택함으로써 더욱 명확하게 된다. 전이단계는 새로운 버전의 아키텍처 설계 버전을 탄생케 한다. 이러한 요구사항 수집, 평가, 전이하는 반복적인 단계는 아키텍처 설계 또는 제품 릴리스 동안 지속적으로 발생하게 된다.

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

소프트웨어아키텍트와 관련된 지식이 널리 퍼지기를 기원하며...
만들었던 초안 그대로 오픈합니다.

소프트웨어아키텍트를 꿈꾸는 분들에게 도움이 되었으면 합니다.

나름 괜찮게 만들어진 내용이라서리...
주변 사람들에게 널리 읽혔으면 좋겠다라는 개인적인 바램이 조금 있습니다.

~.~ 

  • [SA강좌] Part 1-20 SA기초강좌 맺음말…
  • [SA강좌] Part 1-19 아키텍처가 바라보는 View
  • [SA강좌] Part 1-18 간단한 ADD방법
  • [SA강좌] Part 1-17 간단한 아키텍처링 예제
  • [SA강좌] Part 1-16 서비스 시스템의 목표
  • [SA강좌] Part 1-15 소프트웨어 아키텍처의 참고사항
  • [SA강좌] Part 1-14 소프트웨어 아키텍처 팀 운영 시 문제점에 대한 해결방안
  • [SA강좌] Part 1-13 아키텍처와 개발 프로젝트의 다른 역할과의 관계, 개발조직간의 관계
  • [SA강좌] Part 1-12 소프트웨어 아키텍처와 개발 프로세스의 관계
  • [SA강좌] Part 1-11 아키텍트의 의무와 가져야 할 역량 
        [SA강좌] Part 1-10 아키텍트의 역할 정의
  • [SA강좌] Part 1-9 다른 아키텍처와의 관계
  • [SA강좌] Part 1-8 소프트웨어 아키텍처에 포함되지 않는 것
  • [SA강좌] Part 1-7 소프트웨어 아키텍처의 특징과 역활
  • [SA강좌] Part 1-6 소프트웨어 아키텍처의 구성요소
  • [SA강좌] Part 1-5 소프트웨어 아키텍처의 정의
  • [SA강좌] Part 1-4 소프트웨어 아키텍처란?
  • [SA강좌] Part 1-3 본 강좌의 목적
  • [SA강좌] Part 1-2 소프트웨어아키텍처를 도입하면서 달성되는 목표
  • [SA강좌] Part 1-1 시작배경

    하나의 목록으로 만들어 봤습니다.

    1 - 소프트웨어 아키텍쳐 개념에 대한 이해.

    2 - 소프트웨어 아키텍쳐 설계를 하는 방법.

    3 - 컴포넌트 설계를 하는 방법과 설명,

    4 - 아키텍쳐에서 개발로의 이행하는 방법은?.

    5 - 소프트웨어 아키텍쳐 산출물 작성법.

    6 - 소프트웨어 아키텍쳐 설계(실전예제)에서 얻어보기.

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