정의가 중요한 이유

개발 환경에는 소프트웨어 집약 시스템(소프트웨어가 필수적이고 피할 수 없는 요소인 시스템)을 빌드하고 배치하는 팀에게 필요한 모든 것이 들어있다. 그러므로 개발 환경의 일관된 정의를 보유하는 것이 왜 중요한가? 간단히 말하면, 많은 조직들은 시장 진입 시간을 줄이고, 비용을 절감하며, 품질을 개선하려고 한다. 그리고 이러한 모든 비즈니스 목표는 이러한 시스템을 제작하는 데 사용되는 환경의 품질에 의해 직접 영향을 받게 된다. 개발 환경의 일관되고 포괄적인 정의를 가깝게 보유하는 것은 현재 환경을 개선하기 위해 이니셔티브를 계획하거나 환경에 대한 요구사항을 정의하거나 환경의 아키텍처를 정의하거나 환경을 평가하거나 환경을 변경할 때 적절한 투자수익률을 보장하는 중일 때 어떠한 것도 간과되지 않도록 보장한다. 개발 환경 정의는 이러한 모든 태스크에 대한 중요한 입력이다.

개발 환경을 컨텍스트에 놓기

개발 환경을 이루는 구체적인 요소를 살펴보기 전에 먼저 이러한 환경이 거대한 계획에서 어디에 놓여있는지 이해하는 것이 도움이 된다.

그림 1에서 개발 환경을 작성하고 유지보수할 책임이 있는 Center of Excellence가 표시된다. 이 환경은 개발 프로젝트에 사용되어, 결과적으로 소프트웨어 집약 시스템(또는 컴포넌트나 서비스 등 다른 소프트웨어 관련 전달 내용)을 작성하고 유지보수한다. 이러한 간단한 시각화는 준비된 Center of Excellence의 역할들(팀 구성원의 역할, 프로세스 및 핵심 전달내용인 개발 환경을 포함)과 개발 환경을 사용하는 프로젝트(및 그들의 역할, 프로세스 및 전달 내용) 사이에 구별을 명확히 하는 데 도움을 준다.

위로

개발 환경의 요소

IBM Rational 소프트웨어 전문가에게 개발 환경은 이러한 여섯 가지 요소로 구성되며, 이 중 각각은 그림 2에 표시되고 다음 섹션에서 자세히 설명된다.

• 메소드
• 도구
• 인에이블먼트
• 조직
• 인프라
• 채택

독자는 성공적인 개발 프로젝트의 핵심 요소로서 "인력, 프로세스 그리고 기술"에 익숙할 수 있다. 하지만 이 모델은 이 기사의 목적상 극단적으로 단순화된다. 그럼에도 불구하고 그림 2의 요소는 이 모델에서 다음과 같이 빌드한다.

• 인력은 인에이블먼트와 조직으로 나타난다.
• 프로세스는 메소드에 상응한다.
• 기술은 도구와 인프라로 나타난다.

채택은 조직, 비즈니스 단위 또는 개발 프로젝트 내에서 개발 환경의 도입에 초점을 맞추는 새로운(그리고 매우 중요한) 요소이다.

메소드

어느 개발 환경이나 한 가지 핵심 요소는 종사자(practitioner)들이 공식적 또는 비공식적으로 따르는 메소드이다. 이는 다음과 같은 핵심적인 메소드 관련 요소이다.

• 역할, 중간 산출물(work product), 태스크 및 프로세스 등의 핵심 메소드 요소
• 표준, 가이드라인, 체크리스트, 템플리트 및 예제 등의 보충 메소드 요소
• 예를 들어, 메소드가 회사 인트라넷의 웹 사이트로 배치될 때 고려될 수 있는 메소드 배치 토폴로지. 이 예제에서 웹 서버는 컨텐츠를 수용하는 데 필요하며, 워크스테이션은 설치된 적절한 웹 브라우저와 웹 서버로 연결이 있어야 한다.

도구

개발 도구는 따라야 하는 메소드의 부분을 자동화한다. 예를 들어, 개발 프로젝트에서 요구사항을 저장하고 관리하기 위한 도구를 사용하거나 아키텍처와 설계를 시각적으로 모델링하기 위한 도구를 사용하거나 소프트웨어를 테스트하기 위한 도구를 사용할 수도 있다.

다음은 핵심적인 도구 관련 요소이다.

• 개발 도구 및 이의 통합
• 개발 도구 구성 및 설치 스크립트
• 개발 도구 배치 토폴로지는 클라이언트측과 서버측에 필수 소프트웨어와 하드웨어를 관련된 대상 플랫폼과 에뮬레이터(실시간 또는 임베드된 디바이스를 위해 개발하는 중일 때 등)와 함께 고려한다.

인에이블먼트

개발 환경을 사용하는 면에서 종사자의 인에이블먼트(교육 및 조언)는 성공적인 채택에 기여한다. 그러므로 적용될 수 있는 교육 및 조언 자료의 정의와 제작은 개발 환경의 부분이다. 또한, 성숙한 조직은 해당 직원의 전문화와 외부 전문 조직과의 조화에 특히 주목한다.

다음은 핵심적인 인에이블먼트 관련 요소이다.

• 교육 커리큘럼과 과정. 이는 경험이 있는 종사자를 개발 환경에 맞게 개선하는 것에서부터 새 역할을 맡는 종사자를 위한 포괄적인 교육 커리큘럼에 이르기까지 다양한 교육 필요성을 다룬다.
• 조언 자료. 이는 프로젝트에 대한 경험이 상대적으로 적은 동료를 지도하는 경우 개인들이 사용한다.
• 인에이블먼트 배치 토폴로지. 예를 들어, 배치 토폴로지를 고려하는 것은 인에이블먼트가 웹 기반 교육을 통해 제공될 때 필요하다. 다시 말해서, 웹 서버는 웹 브라우저로 마련된 인에이블먼트 자료와 워크스테이션을 수용하는 데 필요하다. 배치 토폴로지는 강의실 교육을 전달하는 데 필요한 위치와 강의실을 지정할 수도 있다.

조직

개발 환경의 또 다른 고려사항은 적절한 조직이 이를 정의, 배치 및 관리하기 위해 준비되도록 보장하고 있다. 이는 개발 환경의 특정한 부문에서 전문가(예를 들어, 메소드 전문가, 도구 전문가, 교육자 및 조언자), 환경을 관리하고 지원하는 인력, 회사 헬프 데스크에서 적절한 기술을 갖춘 인력 및 실습의 적절한 커뮤니티를 포함한다.

다음은 핵심적인 조직 관련 요소이다.

• 개발 환경의 일부가 되는 조직적 역할과 단위의 정의
• 이러한 조직적 단위의 위치를 표시하는 조직 배치 토폴로지

인프라

개발 환경은 하드웨어와 소프트웨어 둘 다의 측면에서 인프라를 고려한다. 이는 메소드, 도구, 인에이블먼트와 조직을 논의할 때 이전에 이미 알려주었다. 하지만, 다음과 같이 인프라를 핵심 요소로서 독립적으로 고려할 세 가지 이유가 있다.

1. 첫 번째는 통합이다. 예를 들어, 개발 환경의 인프라 필요성을 전체적으로 살펴보면 웹 기반 메소드 컨텐츠와 웹 기반 교육 둘 다 지원하는 단일 웹 서버만 필요하다는 것을 알 수 있다.
2. 두 번째는 독자가 실시간 또는 임베드된 디바이스를 개발하는 중이라면 운영 체제 소프트웨어, 데이터베이스 관리 시스템 또는 보드 레벨 제어 및 테스트 하니스 등 개발 환경을 지원하는 추가적인 하드웨어와 소프트웨어를 적절히 고려하도록 보장하는 것이다.
3. 세 번째는 Center of Excellence가 비즈니스 프로젝트를 지원하는 면에서 어느 프로덕션 인프라에서나 사용 가능하게 되기 전에 개발 환경의 개발과 테스트를 지원하는 인프라가 필요할 수 있다.

다음은 핵심적인 인프라 관련 요소이다.

• 위치, 노드 및 연결
• 소프트웨어(운영 체제, 데이터베이스 관리 시스템, 보드 레벨 제어 및 테스트 하니스 등).

채택

이미 나열된 요소 외에도 조직, 비즈니스 단위 또는 개발 프로젝트 내에서 환경의 채택에 대해 관심을 갖는 것도 중요하다.

다음은 핵심적인 채택 관련 요소이다.

• 채택 계획. 이 계획은 하드웨어와 소프트웨어의 취득 등 환경을 채택할 때 정상적으로 수행되는 태스크를 정의한다.
• 조직적 변경을 추진하기 위한 기술. 이는 영향을 받는 조직적 영역의 일상적인 작업으로 개발 환경을 도입하고 임베드하는 데 필요할 것이다.
• 환경 메트릭의 정의. 메트릭은 환경의 효율성을 측정하는 데 사용된다.

솔루션 컨텍스트

또한 관련된 내용은 솔루션 컨텍스트이다(여기에서 개발 환경은 고려 중인 솔루션임). 컨텍스트는 개발 환경에 대한 요구사항을 표현하고 기능성, 품질 및 제한조건의 측면에서 고려될 수 있다.

• 기능성은 소프트웨어 엔지니어링 실습 또는 개발 환경으로 제공되는 원칙을 표현한다. 이러한 요구사항을 실현하면 이전에 언급된 모든 요소가 고려된다. 예를 들어, 그림 3과 같이 요구사항 관리 원칙은 다음으로 지원될 것이다.
  • 요구사항 관리 메소드
  • 요구사항 관리 도구
  • 요구사항 관리 면에서 교육과 조언
  • 요구사항 관리 솔루션을 아는 헬프 데스크 직원
  • 요구사항 관리 관련 요소를 지원하는 하드웨어 및 소프트웨어
  • 프로젝트에서 요구사항 관리 원칙의 적절한 채택

이러한 사고는 아키텍처 또는 품질 관리 등의 개발 환경의 일부분인 다른 기능에도 적용될 수 있다. 이는 반복적 개발(소프트웨어 개발 및 전달에 대한 애자일 접근방식의 중심에서) 등 특정 실습에 적용될 수도 있으며, 이는 또한 모든 요소를 고려하도록 요구한다.

• 품질은 개발 환경이 표시해야 하는 특성을 나타낸다. 이는 또한 개발 환경의 모든 요소를 고려하도록 요구한다. 예를 들어, 규모 가변성 품질(예를 들어, 수많은 동시 사용자를 지원하는 기능)은 다음과 같은 방식으로 수용될 수 있다.
  • 프로젝트의 크기에 맞추도록 사용자 정의될 수 있는 메소드
  • 구성 가능한 메소드를 지원하도록 구성될 수 있는 도구
  • 다른 프로젝트 크기에 대한 교육의 적절한 메커니즘과 레벨
  • 예상된 개발 프로젝트 숫자를 지원하기 위해 팀 구성원들 사이에 적절한 기술 레벨을 제공하는 조직
  • 예상된 동시 사용자 수를 지원하도록 규모 조정할 수 있는 인프라
  • 환경을 채택하기 위한 적절한 메커니즘
• 개발 환경이 수용해야 하는 제한조건은 개발 환경의 모든 요소를 고려하도록 요청한다. 예를 들어, 기존 환경에서부터 마이그레이션할 필요성으로 인해 다음과 같은 조치가 나타날 수 있다.
• 기존 메소드에서부터 실습하고 새 메소드에서 이를 통합하기
• 중간 산출물(work product)을 더 이상 사용되지 않는 도구 세트에서 다른 도구 세트로 마이그레이션하기(그렇지 않으면 보유할 기존 도구와 통합하는 것을 필요로 함)
• 현재 이해를 인식하고 적절하게 사용자 정의되는 인에이블먼트 제공하기
• 현황(as-is) 상태에서 목표(to-be) 상태로 원활한 전환을 보장하는 인력 제공하기
• 기존 인프라의 재사용(가능한 경우 기존 하드웨어 및 소프트웨어 라이센스 재사용 등)을 최대화하는 인프라 지정하기
• 수행되는 마이그레이션을 인식하는 적절한 채택 메커니즘

조직이 기존 개발 환경으로 변경을 고려할 때 또 다른 중요한 제한조건은 당연히 투자수익률(ROI)이다. 성공하기 위한 이러한 이니셔티브를 위해 해당 이니셔티브에 비즈니스 사례와 일맥 상통하는 긍정적인 결과를 명확히 전달해야 한다. 개발 환경의 각 영역은 비용과 혜택 둘 다의 측면에서 ROI에 영향을 준다.

그림 2에 표시되지는 않지만, 기능성, 품질 및 제한조건은 비즈니스 목표와 같이, 정의된 어떤 비즈니스 컨텍스트와도 일반적으로 연계된다. 이러한 관점에서 솔루션 컨텍스트는 비즈니스 고려사항도 수용한다. 이는 개발 환경이 비즈니스 목표를 직접적 또는 간접적으로 달성하는 데 어떻게 기여하는 지 보여줄 때 특히 중요하다.

위로

정의, 배치, 관리

개발 환경의 다양한 요소를 정의하는 면에서 환경의 라이프사이클(그림 4에 표시됨)의 다음 요소를 고려하는 것이 유용하다고 입증되었다. 왜냐하면 솔루션 컨텍스트 외에도 이들 각각은 정의에 영향을 주는 구체적인 관심사가 있기 때문이다.

• 환경의 정의
• 환경의 배치
• 환경의 관리

이러한 영역들을 살펴보기 전에 이러한 다른 영역들이 그림 4에서 사이클로 왜 연결되는지 설명할 가치가 있다. 이 그림은 효율적인 변경(이 경우에 개발 환경으로의 개선)이 각 증분이 사이클을 통해 하나의 전달을 표현하는 곳을 변경하기 위해(변혁이 아닌 진화) 대폭발 접근방식이 아니라 증분식 변경의 시리즈를 통해 일반적으로 달성되는 점을 인식한다. 하지만, 증분으로 구현된 변경은 정의상 다음 증분에 대한 컨텍스트를 변경한다(예를 들어, 종사자들은 이제 개선된 기술이 있을 수 있고, 새 하드웨어가 사용 가능할 수 있으며, 새 도구가 준비되었을 수 있다). 그러므로, 사이클의 성향이 나타난다.

개발 환경의 각 요소를 고려하는 것은 솔루션 정의, 솔루션 배치 및 솔루션 관리와 관련하여 다음 섹션에서 제시된다.

정의

이전 토론은 개발 환경을 정의할 때 고려할 핵심적인 요소에 주목했다. 이러한 토론은 여기에서 다시 재고되지는 않지만, 완벽을 기하기 위해 정의된 다양한 항목들이 표 1에 다시 재연된다.

또한, 정의가 일반적으로 조직 레벨에서 고려되고, 배치될 때에 특정 비즈니스 단위 또는 프로젝트의 필요를 처리하기 위해 로컬 인스턴스화를 요구할 수 있음을 참고해야 한다. 이는 아래 섹션에 반영된다.

배치

개발 환경의 배치는 각 요소와 관련하여 구체적인 관심사를 도입한다. 이는 표 2에 표시된다.

다음은 핵심적인 메소드 관련 요소이다.

• 로컬 구성을 정의한다. 메소드를 비즈니스 단위 또는 개발 프로젝트에 배치할 때, 비즈니스 단위, 개발 프로젝트 또는 시스템의 구체적인 특성을 반영하기 위해 일부 로컬 구성을 요구할 수 있다(예를 들어, 적절한 의식(ceremony) 레벨 제공하기).
• 메소드를 배치한다. 이는 메소드를 종사자가 사용할 수 있는지 보장한다.

다음은 핵심적인 도구 관련 요소이다.

• 로컬 구성을 수행한다. 어느 로컬 도구 구성이나 로컬 메소드 구성을 자동화하기 위해 적용된다.
• 도구를 설치한다. 설치된 도구(및 이들의 통합)를 종사자가 사용 가능하게 만든다.
• 로컬 데이터를 마이그레이션한다. 예를 들어, 기존 도구 세트에서 업데이트된 도구 세트로 데이터를 마이그레이션하는 것이 필요할 수 있다.

다음은 핵심적인 인에이블먼트 관련 요소이다.

• 로컬 구성을 수행한다. 교육 자료를 필요한 대로 채택, 개선 또는 업데이트한다. 예를 들어, 해당 비즈니스 단위나 개발 프로젝트에 정의된 프로세스를 수용하기 위해 인에이블먼트 자료를 개정할 수 있다.
• 인에이블먼트 자료를 배치한다. 인에이블먼트 자료가 어느 웹 기반 교육에나 액세스하는 것을 포함하여 종사자가 사용할 수 있도록 보장한다.
• 종사자를 교육한다. 종사자들은 교육되고 교육에 대한 피드백이 수집된다.

다음은 핵심적인 조직 관련 요소이다.

• 로컬 구성을 정의한다. 특정 비즈니스 단위 또는 개발 프로젝트의 구체적인 필요성을 지원하는 전문가를 제공하는 것이 필요할 수 있다.
• 재구성한다. 개발 환경을 지원하기 위해 인력과 자원을 구성한다.

다음은 핵심적인 인프라 관련 요소이다.

• 로컬 인프라를 정의한다. 특정 비즈니스 단위 또는 개발 프로젝트에 필요한 인프라를 정의한다.
• 위치, 노드 및 연결을 공급한다. 필요한 어느 하드웨어나 사용 가능하게 만든다(실시간 또는 임베드된 디바이스를 개발할 때 대상 플랫폼과 에뮬레이터 포함).
• 지원 소프트웨어를 공급한다. 개발 환경을 지원하는 어느 소프트웨어나 설치한다(예를 들어, 데이터베이스 관리 시스템 또는 테스트 하니스).

다음은 핵심적인 채택 관련 요소이다.

• 로컬 채택 계획을 정의한다. 비즈니스 단위 또는 개발 프로젝트의 구체적인 필요성을 반영하도록 채택 계획을 개선한다.
• 환경을 유효성 검증한다. 원하는 기능성의 제공하기, 명시된 품질에 부합하기 그리고 정의된 제한조건 내에서 작동하기의 측면에서 정의된 요구사항이 부합하도록 보장하기 위해 배치된 환경을 테스트한다.

관리

표 3과 같이 배치 이후 개발 환경의 관리는 각 요소에 대한 구체적인 관심사를 도입한다.

다음은 핵심적인 메소드 관련 요소이다.

• 메소드에 대한 피드백을 수집한다. 개발 환경을 관리하는 핵심적인 측면은 지속적으로 개선하는 것이다. 그러므로, 각 요소에 대한 피드백을 수집하는 것은 모든 요소에 널리 퍼지는 테마이다. 예를 들어, 피드백은 대개 질문지를 사용하여 객관적으로 수집된다.

다음은 핵심적인 도구 관련 요소이다.

• 데이터를 백업, 아카이브 또는 복원한다. 종사자가 작성한 중간 산출물이 적절하게 관리되고 "우수한 보조관리(hoursekeeping)" 실습이 적용되도록 보장한다.
• 도구에 대한 피드백을 수집한다. 도구의 기능과 성능에 대한 피드백(긍정적 및 부정적)을 수집한다.

다음은 핵심적인 인에이블먼트 관련 요소이다.

• 종사자에게 조언한다. 종사자가 환경을 사용하는 방법을 알도록 프로젝트에 조언자를 지정한다.
• 인에이블먼트에 대한, 그러므로 어느 교육이나 조언에 대한 피드백을 수집한다.

다음은 핵심적인 조직 관련 요소이다.

• 조직에 대한 피드백을 수집한다. 종사자들은 개발 환경을 사용하면서 제공된 지원에 대한 피드백을 제공한다(예를 들어, 헬프 데스크 지원의 품질 등).

다음은 핵심적인 인프라 관련 요소이다.

• 필요한 대로 인프라를 공급하거나 회수한다. 프로젝트가 시작하고 마무리되면서, 개발 환경은 주어진 시간에 환경을 사용 중인 종사자의 수를 최적으로 지원하기 위해 이에 따라 크기를 조정해야 한다.
• 하드웨어 및 지원하는 소프트웨어를 포함하여 인프라에 대한 피드백을 수집한다.

다음은 핵심적인 채택 관련 요소이다.

• 환경 효율성을 측정한다. 이는 성공적인 채택의 핵심적인 측면이다. 예를 들어, 종사자에게 질문지를 제공하여 새로운 실습을 채택하는 면에서 이들이 얼마나 효율적이었는지 측정하도록 물을 수 있다.
• 채택에 대한 피드백을 수집한다. 채택으로 접근방식에 대한 피드백이 수집된다.

위로

상호종속항목

마지막으로 개발 환경의 다양한 요소가 이 기사에서 함축하는 것처럼 독립적이지 않음을 유의하자. 그림 2의 대안 표현은 그림 5에 표시되며, 이는 각 요소에 다른 모든 요소들과의 관계가 있음을 시연한다.

여기에 요소들 사이의 종속성의 몇 가지 예제들이 나와있다.

• 메소드(메소드)는 사용 가능한 교육 과정(인에이블먼트)을 참조한다.
• 도구(도구)는 태스크를 자동화한다(메소드).
• 관리 역할(조직)은 도구(도구)를 지원하기 위해 정의된다.
• 서버(인프라)는 도구 세트(도구)를 수용하도록 공급된다.
• 실습의 채택(채택)은 정의된 접근방식(메소드)을 사용하여 평가된다.

위로

요약

이 기사는 2008년에 The Rational Edge: The Rise of the Development Environment Architect를 출판한 동일한 저자인 Peter Eeles의 기사에 덧붙인다. 여기에서 섹션은 개발 환경을 자세히 구성하는 핵심적인 요소에 대해 자세히 설명하고 이러한 환경을 정의하고 배치하며 관리할 때 다른 관심사에 대해 지적한다. 이는 현재 환경을 개선하기 위한 이니셔티브를 계획하는 중이거나 환경에 대한 요구사항을 정의하는 중이거나 아키텍처를 정의하는 중이거나 환경을 평가하는 중일 때 이러한 모든 측면을 고려하도록 보장하기 위한 간단한 프레임워크를 제공한다.

참고자료

교육

• 상대적으로 간략한 이전 기사는 여기에서 확인할 수 있다: The Rise of the Development Environment Architect(Peter Eeles 저, The Rational Edge, 2008년).
  
  
• developerWorks의 Rational 소프트웨어 영역에서 Rational Software Delivery Platform 제품과 관련된 기술 자료와 우수 사례를 볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.
  • 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
  • developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.
  
  
• 기술을 개선하자. Rational training and certification 카탈로그를 확인한다. 이는 광범위한 주제에 대한 과정 유형이 많이 들어있다. 이 중 일부를 언제 어디서나 확인할 수 있으며, 다수의 "시작하기"는 무료이다.
  
  

제품 및 기술

• Rational 소프트웨어는 무료 평가판 다운로드를 다운로드하거나 평가판 및 데모 페이지를 확인하자.
  
  
• 자신에게 가장 적합한 방법으로 IBM 소프트웨어를 평가해 보자. 시험판 소프트웨어를 다운로드하거나 온라인으로 소프트웨어를 사용해 보거나 클라우드 환경에서 소프트웨어를 사용하거나 SOA Sandbox에서 SOA(Service-Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.
  
  

토론

• Rational 소프트웨어 포럼에 가입하여 질문하고 토론에 참여하자.
  
  
• developerWorks 기사를 기고하여 Rational 소프트웨어를 사용하는 다른 사람을 돕고 지식을 공유하자. developerWorks Rational 웹 사이트를 통해 전 세계적으로 기사를 공개하고 RSS 신디케이션과 필자란 및 전기를 이용할 수 있을 뿐만 아니라 전문적인 편집과 제작 혜택을 누릴 수 있다. what makes a good developerWorks article과 진행 방법을 확인하자. 먼저, what makes a good developerWorks Rational article을 확인하자.
  
  
• Facebook 및 Twitter (@ibmrational)에서 Rational 소프트웨어를 팔로우하고, 댓글과 요청을 추가하자.
  
  
• Rational 포럼, cafés 및 위키에 참여하여 질문과 답을 해보고 자신의 전문성을 강화하자.
  
  
• developerWorks 커뮤니티에 가입하고 개발자 중심 블로그에 응답하여 관심사를 공유하는 다른 사람들과 연결해보자.
  
  

필자소개

Peter Eeles는 전 세계 IBM Rational 소프트웨어 조직에서 관리 IT 아키텍트 및 최고 아키텍트로서 조직이 소프트웨어 개발 기능을 개선하는 데 돕는다. 이는 보통 서비스 지향 아키텍처(SOA) 또는 전략적 재사용 등의 전문적인 심화된 지식을 갖춘 아키텍처 중심 이니셔티브와 연계된다. Peter는 "The Process of Software Architecting"(2009년), "Building J2EE Applications with the Rational Unified Process"(2002년) 및 "Building Business Objects"(1998년)의 공동 저자이다. 그의 이메일 주소는 peter.eeles@uk.ibm.com이다.

아티클 순위

의견

위로

목차

• 정의가 중요한 이유
• 개발 환경의 요소
• 정의, 배치, 관리
• 상호종속항목
• 요약
• 참고자료
• 필자소개
• 의견