6 October 2007

사회에 나가면

  • 다른 사람이 이야기를 할 수 있도록 경청하는 자세를 갖기.
  • 불평 하지 말고 대안을 제시하기
  • 요구하지 말고 부탁하기
  • 명령하지말고 제안하기
  • 여유있는 마음을 갖지만, 안주하지는 말기
  • 동료들에게 진심으로 대하기

그리고...

  • 처음 마음 잊지 말기

4 October 2007

"From Requirements Negotiation to Software Architectural Decisions" Summary

Park, Hyun Jung

1. Motivation

1) Software 집약적인 시스템의 Architecture design과 Requirement negotiation은 밀접한 연관관계를 갖지만, 현대의 대부분 프로세스는 이 두 개의 행위 사이에 큰 단절이 존재한다.

2) Architecture design과 Requirement negotiation 각각의 분야에 대한 연구는 계속 되어 왔지만, 어떻게 주요 요구사항을 identify할 것인가와 요구사항을 architecture 결정에 연결 시킬지에 대한 가이드 라인이나 방법은 극히 적다.

3) 대부분의 요구사항이 변동적이며 많은 요구사항은 시스템의 디자인이 조사될 때까지 발견되지 않거나 확실히 되지 않는다.

4) 시간, 돈, 위험, 질적인 측면을 위해 Architecture design과 requirement negotiation 단계를 통합하는 것이 필요하다.

5) ATAM: 기술적 trade-off를 분석하는데 사용

6) CBAM: ATAM + 비용/스케줄/이익/사용자의 요구 조절. (비즈니스 측면 고려)

2. Problem Definition

1) Software Architect는 계속 변한다.

2) 상충되는 요구들을 해결해야 한다.

3. Solution Approach - WinCBAM

1) WinWin 방법론에 기반한 Architecture Design method인 CBAM의 확장판인 WinCBAM을 제안한다. WinCBAM는 WinWin모델과 CBAM를 각각 따로 실행하는 것 보다 강력하다.

2) WinCBAM를 이용하여 개발을 시작하기 전인 Design Stage에서 Stakeholder들의 합의를 이끌어낸다.

3) 논문의 page 3, WinCBAM Steps 참고.

4. Main Results

1) WinCBAM은 의사결정을 돕는 도구로서의 역할을 한다.

2) AS를 선택하는 협상을 도울 뿐만 아니라 Stakeholder들이 본래의 요구사항을 반영할 수 있는 정보를 제공한다.

5. Salient Features

1) Requirements와 Architectural Design을 연결해주는 다리 역할을 한다.

2) 개발의 대안들을 비용, 이득, 스케줄, 불확실성 등과 연관시켜 요구조건 충돌을 해결한다.

3) Stakeholder들이 미처 깨닫지 못했던 요구조건들 사이의 충돌을 찾아낼 수 있다.

4) 더 많은 평가 기준을 제공함으로써 전체적인 요구조건 협상에 정보를 준다.

6. Critique

1) 다양한 옵션들이 있을 때 결정을 돕기 위하여 부분적인 합의의 과정과 수치화를 통해 최종 결정을 도울 수 있다.

2) 기술적 측면과 비즈니스적인 측면을 함께 고려하는 개념이 유용하다.

CBAM: ATAM(기술) + (비즈니스 측면 고려)



논문 링크: http://www.cin.ufpe.br/~straw01/epapers/paper13.pdf