꿈꾸는자의 생각의 파편들... :: 'SA' 태그의 글 목록 (5 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
  •  
  •  
  •  
  •  
  •  
  •  

Code View 정의

Code View는 패키지 구조를 보여준다.

그림 3. Code View의 예

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

Allocation View 정의

Allocation View는 컴포넌트가 하드웨어에 어떻게 배치되는지를 보여준다.

그림 2. Allocation View에 대한 예제

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

Module View 정의

이 과정에서 컴포넌트를 파악하고 정의하는 접근하는 방법에 대해서 설명하도록 하겠다.

-. 인터페이스 파악 : 시스템 분해는 몇 개의 컴포넌트와 이들간의 관계를 나타내는 인터페이스를 결정해야 한다.

-. 도메인 파악 : 컴포넌트는 시스템을 구성하는 컴포넌트들이다. 따라서 여기서 두 종류의 도메인으로 파악할 수 있는데, 어플리케이션 도메인과 컴퓨터 사이언스 도메인으로 분류된다. 어플리케이션 도메인은 주로 소프트웨어 시스템과 관련이 있으며, 컴퓨터 사이언스 도메인은 해당 문제를 해결하기 위한 솔루션과 관련 있다.

-. 추상 레이어 구조 파악

세 번째 과정이 분해된 시스템을 추상화 레이어로 재 분해하는 과정이다. 이는 수평적 레이어 분해라고 할 수 있다. 추상화 레이어 단계는 반복적으로 시스템의 컴포넌트를 선택하고 파악하는 과정에서 지속적으로 파악된다.

-. 도메인 엔터티 파악

컴포넌트를 파악하는 네 번째 방법은 문제 도메인 엔터티를 통하여 파악하는 것이다.

-. 아키텍처스타일 실체화

아키텍처스타일은 전 시스템에서 반복 패턴을 정의하는 것이다. 따라서 이러한 아키텍처스타일의 재사용은 컴포넌트의 동일한 아키텍처스타일 선언으로 이루어지며, 이들 컴포넌트들은 동일 규칙, 설계 의사결정, 시스템 구성요소를 간단히 정의할 수 있다.

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

Component Connector View 정의

일단 시스템 컨텍스트로 시스템 경계를 정의하였으면, 다음 과정으로는 시스템을 구성하는 핵심 엔터티에 대해서 abstraction을 파악하고 정의하는 단계로 이행된다. 시스템에 대한 추상화는 component와 connector를 사용하여 표현한다. Component&Connector View에 대한 다이어그램 작성 방법은 별도의 장에서 제시한다.

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

Component&Connector View 작성하기 전에 View 어떤 요구사항과 품질 요소를 반영할 것인가를 결정해야 한다. 또한 요구사항이 모호한 경우나 요구사항이 빠진 경우에는 요구사항을 상세화하거나 추가해야 한다.

  • 설계 전략 수립

아키텍처 설계는 요구사항에 대한 추상적인 해결책을 제시해야 한다. 따라서 요구사항에 대한 해결 전략을 세워야 한다. 예를 들어 현재 세가지 요구사항이 접수됐으며 그에 대한 해결책은 다음과 같다.

  • 개발 기간이 짧다.

    제품의 특성을 추가하거나 제거하기 쉽게 만든다.

  • 일반적인 목적의 하드웨어나 특정 도메인용 하드웨어로 교체하기가 쉬어야 한다.

    특정 도메인용 하드웨어를 캡슐화한다.

  • 제품의 특성을 추가하거나 제거하기 쉽게 만든다.

    컴포넌트를 concer별로 분리한다.

    제품의 일부 특성을 별도의 컴포넌트로 분리한다.

    사용자와의 상호작용 커플링을 줄인다.

  • 설계
    • 최상위 레벨의 다이어그램 작성

      가상의 이미지 관리 시스템에 대한 아키텍처를 작성한다. 시스템은 감시 장비 카메라를 통해 이미지를 획득하는 시스템이다. 시스템은 감시 장비를 제어하는 port 감시 장비에서 환경 데이터를 얻는 port, 감시 카메라의 움직임을 제어한 port, 카메라를 움직이는 동안 이미지를 모니터로 보여주는 port, 이미지를 전성하는 port, 네트워크를 엑세스 하는 port 이루어져 있다.

      컴포넌트는 카메라를 제어하는 컴포넌트, 이미지를 처리하는 컴포넌트, 이미지를 전송하는 컴포넌트로 나누어진다.

그림 Ⅲ-31. 이미지 관리 시스템의 C&C View

사용자는 UserAcqControl 포트를 통해 감시 카메라의 위치를 조정한다. Acquistion 컴포넌트는 감시 장비 하드웨어에 위치를 조정하라는 명령을 probeCommands 포트를 통해 보내고 imaingControl 포트를 통해 Imaging 컴포넌트에는 변경된 위치에 따라 이미지를 작성하여 모니터에 보내도록 명령한다. Imaging 컴포넌트는 probeData 포트를 통해 카메라 주변의 명암 등에 대한 환경 정보를 받고 이미지를 조정하며 UserAcqDisplay 포트를 통해 모니터에 이미지 정보를 보낸다. 만일 사용자가 이미지를 전송하기를 원한다면 Exporting 컴포넌트는 newtworkAccess 포트를 통해 네트워크에 연결하고 useImageExport 포트를 통해 이미지를 내보낸다.

그림 Ⅲ-32. 이미지 전송 시나리오

 

그림 -32 이미지가 어떻게 전송되는지 보여준다. 사용자가 카메라 제어를 요청할 경우에는 probeCommands 통해 감시 장비를 제어하고 주기적으로 이미지를 모니터에 보여주도록 요청한다. 감시 장비의 환경 데이터도 주기적으로 probeData 포트를 통해 들어온다. Imaging 컴포넌트는 Acquisition 컨트롤 명령과 환경 데이터를 합하여 이미지를 만들고 userAcqDisplay 포트를 통해 이미지를 모니터에 보여준다.

만일 사용자가 이미지 전송을 요청하면 Acquisition 컴포넌트에서 주기적으로 이미지를 모니터에 보여주라는 명령과 함께 이미지를 전송하라는 명령을 Imaging 컴포넌트에 보내고 Imaging 컴포넌트는 Exporting 컴포넌트에게 이미지를 전송하도록 명령한다.

  • 다이아그램 상세화

    그림 -33 상세화된 C&C View이다. 외부 시스템에 대한 의존성을 방지하기 위해 외부 시스템을 제어하는 ProbeControl 추가했다.

그림 Ⅲ-33. 상세화된 이미지 관리 시스템의 아키텍처

 

ImageProcessing 상세화는 그림 -34 같다.

그림 Ⅲ-34. ImageProcessing의 상세화

 

ImageProcessing 컴포넌트는 감시 장비에서 받은 데이터를 패킷으로 묶는 Packetizer 컴포넌트와 Image 생성하는 ImagePipeline 컴포넌트로 나누어진다. Packetizer 컴포넌트는 rawDataInput 포트를 통해 데이터가 준비되었다는 메시지를 받으면 포트를 통해 데이터를 요청하면 포트는 데이터를 전달한다. 과정을 sequence diagram 사용하여 표현하면 다음과 같다.

그림 Ⅲ-35. Packetizer의 데이터 전송 과정

 

ImagePipeline 컴포넌트의 상세화는 그림 -36 같다.

그림 Ⅲ-36. ImagePipeline 컴포넌트의 상세화

  • 마무리 작업

컴포넌트와 connector 할당할 자원에 대한 제약사항이 있으면 명세 한다.

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

시스템 컨텍스트 정의

시스템 컨텍스트를 정의하는 과정은 다음 작업들로 이루어진다.

첫 번째 작업은 시스템과 외부 엔터티와 인터페이스를 정의한다. 엔터티를 기술할 경우, 각 레벨에 대해서 명확히 인터페이스를 기술하여야 한다.

두 번째 작업은 각 인터페이스와 관련한 기능적 요구사항과 품질 요구사항을 정의한다.

세 번째 작업으로는 소프트웨어 개발 라인의 경우, 다양한 제품을 지원하는 인터페이스 다양성은 명확하게 정의되고 분류되어야 한다.

시스템 컨텍스트는 상위 시스템과의 관계, 동등한 레벨의 시스템과의 관계, 하위 시스템과의 관계로 이루어진다.

그림 Ⅲ-27. 시스템 컨텍스트

  • Use Case Diagram 사용한 시스템 컨텍스트 작성 방법

Use Case Diagram 사용하여 시스템 컨텍스를 작성할 경우에는 외부 시스템을 액터로 설정하고 시스템의 기능을 Use Case 정하여 시스템 컨텍스트를 작성한다.

그림 Ⅲ-28. Use Case Diagram을 사용한 시스템 컨텍스트 작성 예

 

Use Case Diagram 사용하여 시스템 컨텍스트를 작성할 경우에는 시스템의 기능을 상세하게 알아야 하고 외부 시스템과 어떻게 연결되고 어떤 데이터를 주고 받는지 없기 때문에 최상위의 컨텍스트 다이어그램을 그리는 데는 부적절하다.

Use Case Diagram 사용한 컨텍스트 다이어그램은 어떤 외부 시스템이 있는지 식별할 경우에 사용한다.

  • Component Connector 사용한 컨텍스트 다이어그램

Component, Connector, port 사용하면 외부 시스템과의 인터페이스를 파악하기 쉽다.

그림 Ⅲ-29. Port를 사용한 시스템 컨텍스트 다이어그램 예제

 

그림 -29 화재 경보 시스템의 시스템 컨텍스트 다이아 그램을 보여준다. 화재 경보 시스템은 개의 외부 시스템과 연결되어 있으며 외부 시스템과의 연결점은 개의 포트 p1, p2, p3, p4 표현된다.

  • Use Case Diagram Port 사용한 시스템 컨텍스트 다이어그램의 결합

Port에서 발생하는 시스템 간의 상호작용은 Use Case 표현된다. Port State 연결하여 Port 통한 상호 작용을 표현한다.

그림 Ⅲ-30. 시스템 컨텍스트에서 port를 통한 상호작용을 표현한 예제

  • 시스템 컨텍스트 다이어그램을 작성하는 순서

시스템 컨텍스트 다이어그램을 작성하기 위해서는 다음 순서를 따른다.

첫째, Port 사용하여 외부 시스템과의 연결 관계를 표현한다.

둘째, Port 외부 시스템과 어떤 상호작용을 하는지를 파악하기 위해 외부 시스템을 Actor 두고 Use Case Diagram Use Case Description 작성한다.

셋째, provided, required interface port 사용한 시스템 컨텍스트 다이어그램에 반영하고 인터페이스를 명세 한다.

넷째, 인터페이스를 명확하게 명세할 없는 경우에는 Connector 통해 어떤 데이터가 전달되고 Connector 어떤 기술을 사용하여 구현하는지를 명세 한다.

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

소프트웨어 아키텍처 설계

소프트웨어 아키텍처 설계 활동의 작업들과 작업 절차는 다음과 같다.

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


소프트웨어 아키텍처 설계 과정은 우선 아키텍처 관련 요구사항을 분석하고 그 후 시스템 컨텍스트를 정의한다. 아키텍처의 각 View는 Component&Connector View, Module View, Allocation View, Code View의 순서로 작성한다. 각 View를 작성하기 전에 아키텍처 관련 요구사항을 수정하고 다시 분석할 수도 있다.

그림 Ⅲ-25은 소프트웨어 아키텍처의 각 View와 다른 산출물과의 관계를 보여준다.

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

첫 번째 설계 단계는 설계를 위한 시스템 컨텍스트를 결정한다. 이는 시스템의 행위(behavior)을 결정하는 것으로써 외부 시스템 엔터티와 시스템간의 인터페이스를 결정하는 것이라고 할 수 있다. 두 번째 과정은 아키텍처를 component와 Connector를 사용하여 표현하다. 이는 주요 아키텍처 abstraction과 아키텍처 스타일 간 관계를 정의한다는 것을 말한다. Component&Conenctor View는 시스템을 abstraction하는 과정으로써, 이 과정이 전체 시스템 아키텍처를 결정하는 과정에 속하게 된다. 시스템 전이단계는 단지 추가적으로 아키텍처 스타일을 정의한 부분에 첨부하는 과정에 해당될 뿐이다.

세 번째 과정은 Module View를 결정하는 단계로 아키텍처의 주요 컴포넌트들을 정의하고, 이들간의 관계를 정의하는 시스템 분해와 관련 있다. 네 번째 과정은 Allocation View를 결정하는 단계로 아키텍처의 각 구성 요소가 시스템에서 어떻게 인스턴스화 되고 실행되는지를 보여준다. 다섯 번째 과정은 Code View를 결정하는 단계로 소스코드의 패키지 구조를 보여준다.


그림 Ⅲ-26. 아키텍처 구성 요소

Posted by 꿈꾸는자의 생각의파편들
생산성본부에서 진행하겠다는...
7주짜리...
아키텍트 과정에...
참여해달라고 하는 건수~

델파이 연합에서 진행하는
연말세미나에...
1시간짜리 'SA기초' 세미나...

흠...

아키텍트 과정에 모인 분들을 보니...

이사가 3명
교수님 한분...
나름다 쟁쟁한 사람들이 모였다.

~.~

다만..
화, 목이라는 강의시간...

SA평가 부분의 강좌를 한번 해볼까 하는
생각은 드는데...
흐흠...
조금 고민해보자..

.
.
.

델파이연합의 1시간짜리는...
머..

부담없이 하면 될듯하지만...

3시간짜리 기초강좌를
1시간으로 해야한다라...

흠...

SA에 대한 필요성 정도 이야기하다가...
끝내야할려나?

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

보안

표 Ⅲ-10. 보안 프로파일의 예

Category 

시나리오에 대한 설명

외부 공격

인증 받지 않은 사용자가 시스템을 공격한다.

데이터 보안

예전에 공개되었던 데이터가 private로 바뀌면서 이 데이터에 대한 엑세스도 제한되어야 한다.

보안은 인증된 사용자에게 서비스를 제공하는 동안 인증 받지 않은 사용자의 시스템 사용 요청은 차단하는 것이다. 보안을 파괴하려는 시도를 공격이라고 부르며 다양한 형태를 가지고 있다. 인증 받지 않는 공격은 데이터나 서비스에 접근하거나 데이터를 수정하거나 인증된 사용자가 서비스를 받지 못하게 하려는 목적으로 시도된다.

다양한 경로를 통해 발생하는 시스템 공격은 전자 거래의 이체 시 돈을 빼가거나 민감한 데이터를 수정하거나 신용 카드 번호를 빼가거나 컴퓨터 시스템의 파일을 파괴하고 웜이나 바이러스로 서비스를 마비시키는 등 다양하다.

보안은 부인 봉쇄, 은폐, 통합, 인증, 가용성 등으로 구분된다.

부인봉쇄(Nonreputation)란 어떤 사람도 시스템에 대해 어떤 작업을 시도했다는 사실을 부인하지 못하도록 하는 것이다. 예를 들어 사용자가 인터넷을 통해 주문 했다는 것을 부인하지 못하게 하는 것이다.

은폐(Confidentiality)는 데이터나 서비스를 인증 받지 않은 사용자의 공격에서 보호하는 것을 가리킨다. 예를 들어 해커가 정부 컴퓨터의 소비세 데이터를 접근하지 못하도록 하는 것이다.

정합성(Integrity)는 데이터나 서비스가 의도된 대로 전달되는 것을 의미한다. 예를 들어 성적은 교사가 승인한 후에는 수정할 수 없다.

Assurance는 거래를 하는 당사자가 원래 거래하려던 사람이어야 한다는 것이다. 예를 들어 고객이 인터넷으로 신용 카드 번호를 보내면 인터넷 사이트는 고객이 원래 생각하고 있던 그 사이트여야 한다.

Availability는 시스템이 정상적인 인증을 받은 사람들에게는 사용 가능해야 한다는 것이다. 이것은 해커의 공격 때문에 사용자가 주민 처리하는 것이 중단되어서는 안 된다는 것이다.

Auditing은 시스템이 시스템 안에서 이루어진 행위들을 추적할 수 있어야 한다는 것이다. 이것은 사용자가 한 계좌에서 다른 계좌로 돈을 이체할 경우 시스템이 이체에 대한 모든 기록을 유지행 한다는 것이다.

보안에 대한 시나리오 작성 지침은 다음과 같다.

표 Ⅲ-11. 보안 시나리오 작성 지침

 

설명

이벤트가 발생하는 장소

공격의 근원지는 사람이거나 다른 시스템이다. 공격의 근원지는 이미 식별되었을 수도 있지만 현재는 알려지지 않을 수도 있다.

인증 받은 사용자가

이벤트가 어떻게 시스템에 도착하는가

공격의 종류는 정보를 가로채려는 시도, 정보를 수정, 삭제하려는 시도, 시스템 서비스에 접근하려는 시도, 시스템 서비스의 가용성을 줄이려는 시도로 나눌 수 있다.

데이터를 수정하려고 시도한다.

목표

공격의 목표는 시스템의 서비스이거나 그 안에 있는 데이터이다.

시스템 내의 데이터

환경

공격은 시스템이 네트워크에 연결되어 잇거나 연결되어 있지 않을 때, 시스템이 방화벽 뒤에 있을 때나 네트워크에 열려 있을 때 이루어진다.

정상적인 운영 환경

응답

인증 받지 않고 시스템을 사용하거나 인증 받은 사용자가 시스템을 사용하는 것을 막는 것은 데이터를 가로채거나 수정하는 것과는 목표가 다르다. 따라서 시스템은 정상적인 사용자는 인증하고 데이터나 서비스를 사용하도록 허락해야 한다. 동시에 인증 받지 않은 사용자는 거부하고 서비스에 접근하는 것을 차단해야 한다.

공격을 막는 기술 중의 하나는 모든 접근 시도에 대해 로그를 남겨서 처벌하는 것이다.

시스템은 사용자의 행위를 모두 기록한다.

응답에 대한 측정치

다양한 공격을 시도하는 것이 어느 정도 어려운가, 공격을 받은 후 시스템을 복구하는 것이 얼마나 어려운가를 측정한다.

정확한 데이터를 하루 안에 복구할 수 있어야 한다.

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

가용성(Availability)

표 Ⅲ-8. 가용성 프로파일의 예

Category 

시나리오에 대한 설명

시스템 오류 발생

FTP 사이트로 사용자가 파일을 요청하자 FTP 서버가 down되었다. 시스템은 또 다른 파일 요청에 대한 처리를 10분 동안 중단시켜야 한다.

주문 처리

주문 처리 요청이 들어왔을 때 실패하면 시스템은 10분 동안 처리를 중단시킨다. 그 사이에 시스템 운영자가 주문 처리를 다시 시작시킬 수 있다.

주문 처리

사용자가 매 10분 단위로 주문 처리를 요청할 수 있으며 이 요청은 큐에 저장하여 처리한다.

주문 처리

하드웨어 문제가 발생하면 시스템은 정지되며 5분 안에 주문을 다시 처리한다.

가용성은 시스템에 오류가 발생하면 어떤 결과가 발생하는가에 대한 것이다. 시스템의 오류는 시스템이 더 이상 정해진 규정대로 서비스를 제공하지 못할 때 발생한다.

가용성에서 주된 관심사는 시스템의 오류를 어떻게 감지하는가, 얼마가 시스템 오류가 자주 발생하는가, 오류가 발생했을 때 무슨 일이 일어나는가, 시스템은 제 기능을 하지 못한 채 얼마나 오래 지속되어야 하는가, 오류를 어떻게 막을 수 있는가? 오류가 발생했을 때 어떤 통보를 받을 수 있는가이다.

오류(failure)와 결함(fault)는 구별되어야 한다. 결함은 수정되지 않으면 오류가 뵐 수 있다. 즉 오류는 시스템의 사용자가 관찰 가능한 것이지만 결함은 사용자가 관찰할 수 없다. 결함이 관찰 가능하면 오류가 된다. 예를 들어 결함은 계산시 잘못된 알고리즘을 선택하는 것이다. 결과적으로 잘못된 계산이 발생하고 시스템은 오류가 발생하게 된다.

시스템에 오류가 발생하면 이 오류를 수정하는데 시간이 얼마나 걸리는가가 중요하다. 시스템에 오류가 발생한 것을 사용자가 관찰하고 오류가 수정되는 시간은 사용자가 오류를 더 이상 관찰 할 수 없는 시간이다. 이것은 응답시간이 약간 지연되는 것일 수도 있고 어떤 사람이 산에 올라가서 장비를 고칠 때까지 걸리는 시간일 수도 있다.

표 Ⅲ-9. 가용성 시나리오 작성 지침

 

설명

이벤트가 발생하는 장소

결함이나 오류가 외부에서 발생했는지 내부에서 발생했는지를 구별해야 한다.

예상하지 못했던 메시지가 외부에서 들어온다.

이벤트가 어떻게 시스템에 도착하는가

다음 중에 하나의 결함의 발생할 수 있다.

Omission: 모듈이 받은 입력에 응답하는데 실패했다.

Crach: 모듈이 되풀이해서 입력에 응답하지 못한다.

Timing: 모듈이 응답하지만 너무 빠르거나 너무 늦다.

Response: 모듈이 부정확한 값으로 응답한다.

이 메시지를 처리하는 모듈이 응답시간이 너무 늦다.

시스템

가용성이 높아야 하는 시스템 자원으로 프로세서, 커뮤니케이션 채널, 스토리지 등이다.

커뮤니케이션 채널

환경

오류나 결함이 발생했을 때 이 오류에 대처하는 시스템의 상태를 가리킨다. 예를 들어 시스템이 이미 어떤 결함을 가지고 있었고 비정상적인 모드에서 동작했다면 시스템을 꺼야 한다. 그러나 오류가 발생한 것이 처음이라면 응답시간이 약간 느린 것이 더 나을 수도 있다.

시스템은 정상 모드로 동작해야 한다.

응답

오류가 발생했을 대 시스템의 반응. 예를 들어 오류를 기록하고 사용자가 오류가 발생했음을 알리고 비정상적인 모드로 시스템을 변경하고 외부 시스템과 연결을 차단하는 것 등이다.

시스템은 기대하지 않았던 메시지가 도착했음을 운영자에게 알리고 정상적으로 동작해야 한다.

응답에 대한 측정치

응답에 대한 측정치는 사용성의 비율로 표시하거나 수리하는데 걸리는 시간, 시스템이 가용한 시간 등으로 표시한다.

비정상적인 메시지가 도착해도 시스템이 다운되지 말아야 한다.

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

유지보수에 대한 프로파일

표 Ⅲ-6. 유지보수 프로파일의 예

Category 

시나리오에 대한 설명

기능 변경

사용자에게 화면을 보여주기 위해 추가적인 데이터가 요구된다.

기능 변경

사용자가 화면 추가를 요구한다.

기능 변경

사용자가 화면 상의 처리 절차의 변경을 요구한다.

기능 변경

사용자가 데이터 포맷의 변경을 요구한다.

기능 변경

두 개의 발사 명령을 내렸다. 두 번째가 첫 번째 보다 우선한다고 판단하여 첫 번째 발사 명령을 취소한다. 무기가 다르면 이 원칙이 달라질 수 있다.

기능 변경

무기 발사를 자동화 할 것

기능 변경

메시지 포맷의 변경

기능 변경

지연 사항에 대한 벌금 부과 기능 추가

기능 변경

메타 데이터의 변경을 필요로 하는 새로운 보고서 양식이 추가된다.

플랫폼의 변경

IRIX 6.2에서 IRIX 6.5로 변경하고 하드웨어를 교체하는 것을 하루에 완료해야 한다.

플랫폼의 변경

새로운 디바이스가 추가된다.

플랫폼의 변경

기존의 디바이스가 새로운 메시지 포맷을 받아들이는 것이 가능해야 한다.

플랫폼의 변경

운영체제를 Solaris로 변경한다.

플랫폼의 변경

Oracle을 Informix로 변경한다.

운영 환경의 변화

처리할 수 있는 무기의 수를 18개에서 30개로 증가시킨다.

운영 환경의 변화

시스템에서 사용하지 않는 CD player는 제거한다.

품질 개선

30초 안에 100개의 데이터를 검색할 수 있어야 한다.

품질 개선

검색 시간을 0.5초 이내로 줄여야 한다.

유지보수성은 시스템 변경을 처리하는데 걸리는 비용에 대한 것이다. 여기에는 두 가지 관점이 있다.

첫째는 무엇이 변경되는가에 관련이 있다. 변경은 시스템의 어떤 부분에서도 발생할 수 있다. 대부분 공통 기능이나 플랫폼, 시스템이 동작하는 환경, 품질, 용량(시스템이 지원할 수 있는 동시 사용자의 수 등)에서 발생한다.

둘째는 언제 변경이 발생하며 누가 변경 사항을 처리해야 하는 것이다. 과거에 대부분의 변경은 소스 코드에서 발생한다. 즉 개발자는 코드를 수정하고 테스트하고 배포해야 한다. 그러나 현재 변경이 언제 발생했는가에 대한 문제는 누가 변경 사항을 처리해야하는것과 관련이 있다. 예를 들어 최종 사용자가 스크린 세이버를 수정하면 분명히 시스템을 변경한 것이지만 시스템에는 영향을 끼치지 않는다. 변경은 구현에 대한 변경, 컴파일 시의 변경, 모듈 통합 시의 변경, 시스템 환경 설정 시의 변경, 실행 중의 변경으로 구분된다. 변경은 개발자에 의해 이루어질 수도 있고 최종 사용자, 시스템 관리자에 의해 이루어질 수도 있다.

일단 변경 사항이 정의도면 새로운 시스템이 설계, 구현, 테스트, 배포되어야 한다. 이 모든 행위에는 시간과 돈이 소요된다.

유지보수에 대한 시나리오는 다음 표를 사용하여 작성한다.


표 Ⅲ-7. 유지보수에 대한 시나리오 작성 지침

 

설명

이벤트가 발생하는 장소

누가 변경했는가를 기록한다. 변경은 개발자, 관리자, 최종 사용자에 의해 이루어질 수 있다.

개발자가

이벤트가 어떻게 시스템에 도착하는가

변경 사항에 대한 요청이다. 변경은 기능 추가일 수도 있고 기능의 수정일 수도 있고 기능의 삭제일 수도 있다. 변경 사항은 시스템의 품질에 대해 이루어질 수도 있다. 더 빨리 응답하게 하거나 가용성을 늘릴 수도 있다. 시스템의 용량이 변할 수도 있다. 동시 접속자의 수를 증가시키는 것은 빈번하게 발생하는 요구사항이다.

화면 배경 색깔을 푸른 색으로 수정하려고 한다.

대상

변경이 발생하는 대상을 가리킨다. 이것은 시스템의 기능이거나 플랫폼, 사용자 인터페이스, 환경, 상호운영 중인 다른 시스템일 수 있다.

수정은 사용자 인터페이스에서 발생한다.

환경

언제 변경이 이루어지는 지를 가리킨다. 설계 시, 컴파일 시, 모듈 통합 시, 초기화 시, 실행 시 등으로 구분된다.

수정은 설계 시에 발생한다.

응답

변경을 처리하는 과정을 의미한다. 즉 변경 설계, 테스트, 배포 과정을 의미한다.

변경 처리에는 side effect는 없다.

응답에 대한 측정치

변경을 처리하는 데 걸리는 시간과 비용이 측정치이다.

수정 사항을 처리하는데 세 시간이 걸리지 않는다.

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