복잡도는 어디에나 존재하며, 빠르게 증가하고 있다. 2010년 CEO의 IBM 글로벌 설문조사(참고자료 참조) 보고서에서는 "오늘날의 복잡도는 증가할 것으로만 예상하고 있으며, 절반 이상의 CEO들이 이를 관리하는 자신들의 능력을 의심하고 있다"고 보고한다.

애플리케이션, 시스템 및 제품들은 이제 성능, 지능 및 기능 면에서 빠르게 개선되어 그 자체로 복잡하다. 하지만, 더 이상 고립되어 작동하지 않는다. 이제 이는 시스템의 항상 복잡한 시스템에서 새 서비스를 제공하고 새 비즈니스 및 사회적 가치를 제공하기 위해 상호 연결한다. 조직들은 한 곳에 모여 심지어 개발 팀을 넘어 점점 더 복잡한 시장 환경의 수요에 부합하기 위해 이러한 시스템에서 협업해야 한다. 조직이 개발 중인 산업 또는 산업간 프로젝트에 관계없이, 회사에 복잡도를 야기하는 도전과제는 동일하다.

이 기사는 세 가지 구별되는 복잡도의 유형인 조직적, 프로세스 및 설계에 대해 주목한다. 그 다음에 IBM® Rational® 설계 및 개발 애플리케이션의 확장된 새로운 기능이 이러한 각각의 내용을 어떻게 다루는지 설명한다.

소프트웨어 및 시스템 설계자에 영향을 주는 세 가지 복잡도 유형

조직적 복잡도는 제작 중인 제품, 소프트웨어 및 시스템에 영향을 주는 내부적으로(부서, 위치, 원칙 및 팀 가운데) 그리고 외부적으로(공급자, 고객 및 다른 조직들과) 존재하는 장애물을 처리한다.

보통 비즈니스의 방향, 조직의 우선순위, 비즈니스 조직의 계통 및 IT 인프라 필요성에 대한 의사결정은 사용 가능한 올바른 정보 없이 그리고 적시에 올바른 이해 당사자와의 협업 없이 정해진다. 이는 매뉴얼, 관련 정보에 대한 오류가 발생하기 쉬운 업데이트, 연결되지 않고 문서화되지 않은 계획 및 팀 그리고 정보가 너무 적거나 관련 컨텐츠를 감추는 방대한 정보가 들어있는 보고서 등 수많은 요인 등이 원인이 된다.

조직적 구조는 종종 복잡하고 정렬이 안 되어 있다. 함께 작업해야 하는 사람들이 서로 다른 연결되지 않은 팀에 사일로화된다. 보고 체인은 팀 사이에 정보의 흐름을 방해하여, 문제가 되는 조직적 구조가 있기 때문에 토론에 참여하는 올바른 이해 당사자들을 판별하기가 어려운 경우가 많다.

프로세스 복잡도는 소프트웨어 전용이든지 하드웨어 및 소프트웨어를 수반하는 소프트웨어 집중 시스템이든지 간에, 제품의 작성 또는 진화를 위한 프로세스에 내재된 복잡도를 처리한다. 애자일 개발로부터 혼합 반복, 규제가 심한 폭포형(waterfall) 접근방식에 이르기까지 설계, 개발, 전달 및 유지보수 활동에 참여한 팀들은 프로세스와 관련한 도전과제에 직면한다. 게다가, 다양한 프로세스 유형은 조직 전반에 걸쳐서 통합해야 한다. 비즈니스 프로세스, 소프트웨어 및 시스템 개발 프로세스 그리고 운영적 프로세스 모두 서로 원활하게 흘러가야 한다. 한 쪽에서 단순성과 다른 쪽에서 준수와 신뢰성 사이의 균형을 유지하면 최선의 프로세스를 정확히 이해하기 어려워질 수 있다.

감사에 직면하고 규제 및 기업 표준의 준수를 시연하는 것은 소프트웨어 또는 시스템의 작성이나 향상 프로세스에서 제작된 대규모 설계 세트 및 라이프사이클 아티팩트에 걸쳐서 정보를 수집하는 능력이 없기 때문에 어려운 경우가 많다. 매뉴얼 프로세스, 라이프사이클을 통한 도구 통합의 부재 및 소프트웨어 및 시스템을 지정하고 설계하며 구조하고 배치하며 유지보수하는 데 사용되는 아티팩트의 추적성의 부재로 인해 모든 규제 준수를 문서화하기 위해 올바른 형식으로 올바른 정보를 전달하는 기능이 방해를 받는다.

프로젝트가 어느 지점에서 계획에 관련되는지 이해하는 것은 프로세스 복잡도로 복잡해져서, 중대한 사건에 마주칠 때 진행 상황 평가 및 예측 가능성이 단지 추측이 된다. 이는 일반적으로 전체 라이프사이클 및 팀 노력에 대한 메트릭의 부재에서 나타난다. 팀 전반에 걸쳐서 진행 상황을 수동으로 추적하는 것은 오류가 발생하기 쉽고 불일치가 적용된다. 이는 복잡도의 레벨을 창의성을 차단하고 생산성을 줄이는 프로세스로 도입한다.

설계 복잡도는 사양과 기능 또는 외부 시스템으로의 연결이든지 간에 소프트웨어, 시스템 및 제품 자체에 배치된 늘어난 수요를 처리한다. 이 복잡도는 크고 작은 팀들이 같이 경험한다. 이는 변경의 영향을 빠르게 평가하고 이에 대한 조치를 취하는 능력이 없다는 면에서 뿐만 아니라 결과적으로 종종 가장 깊게 영향을 받은 사람들, 즉, 팀의 외부에 있는 이해 당사자의 설계에 대한 제한된 이해 측면에서 스스로 드러난다.

소프트웨어 및 시스템의 아키텍처뿐만 아니라 작동적 특성은 이해하기에 점점 더 어려워진다. 늘어난 기능성에 대한 새 요구사항은 각각 복잡도를 증가시킨다. 소프트웨어와 시스템을 다른 시스템에 상호 연결할 이러한 필요성을 더하면, 설계 복잡도는 훨씬 더 증가한다. 모델링과 추상의 모든 레벨에서 설계를 시각화하는 수단 없이 그리고 자동화를 활용하지 않고 코드 중심 접근방식을 통해 이러한 시스템을 설계하려고 시도하면 프로젝트 지연, 불확실한 기능 준수 및 고장난 인터페이스 및 시스템을 초래한다.

위로

결과적으로 나타나는 다섯 가지 도전과제

IBM은 조직이 소프트웨어 집약적 시스템과 제품을 설계하고 빌드하며 전달하는 데 도움을 주는 설계 및 개발 솔루션의 풍성한 세트를 갖추고 있다. 소규모 팀이든지 대규모 팀이든지, IBM® Rational® Software Architect 및 IBM® Rational® Rhapsody®와 관련하여 제작된 솔루션을 사용하여 설계에 대해 작성하고 협업한다. 이들은 애플리케이션과 시스템 복잡도를 간소화하는 면에서 중요한 결과를 확인하고 수정하기에 가장 저렴할 때 라이프사이클 중 초기에 문제와 결함을 식별하며, 이해 당사자에 빌드하도록 의도하는 것을 문서화하고 의사소통해야 하므로 이러한 특정 제품을 선택한다.

하지만, 가장 최고의 설계 도구를 사용해도 중요한 도전과제는 여전히 존재한다. 이러한 문제점은 다음 다섯 가지 영역으로 그룹화될 수 있다.

1. 설계 팀은 프로젝트 이해 당사자의 중요한 부분과 별개로 작업한다. 이로 인해 매우 자주 설계와 전달된 소프트웨어 및 시스템이 기대에 부합하지 못하게 되며, 이는 설계 및 조직적 복잡도의 증상을 보인다.
2. 설계 요소는 프로젝트 계획, 요구사항, 테스트 계획, 테스트 케이스, 운영 및 유지보수 안내서 및 고객 안내서 및 매뉴얼 등의 라이프사이클에서 다른 아티팩트와 느슨하게 결합된다. 이로 인해 변화의 영향이 불확실하게 되며, 이는 프로세스 복잡도의 증상을 보인다.
3. 설계는 검토하기에 어렵고 개발이 시작된 후에 거의 유지보수되지 않는다. 이는 많은 경우에 무시되기도 한다. 이로 인해 요구사항과 전달된 제품 사이에 중요한 연결이 끊어지게 되며, 이는 설계 및 프로세스 복잡도의 증상이다.
4. 설계 프로세스에서 예측 가능성과 효율성은 불확실하다. 이로 인해 릴리스가 지연되며 개발 자원의 비효율적인 사용이 나타나며, 이는 프로세스 복잡도 문제와 직접 관련된다.
5. 설계의 보고 및 문서화는 전체 프로젝트와 연관되므로 노동 집약적이며 오류가 발생할 가능성이 높다. 이로 인해 감사 실패가 나타나고 표준 및 규제와의 준수를 표시하는 데 무력하게 된다. 다시 말해, 이는 프로세스 복잡도의 증상을 보인다.

우리는 모델링, 설계 및 아키텍처의 영역에서 중대한 지점에 있다. 모델 구동형 개발(MDD) 및 모델 기반 시스템 엔지니어링은 더 스마트한 제품을 설계하고 시스템의 시스템을 위한 기초가 된다. 하지만, 설계 팀은 오늘날의 개발 제한조건의 요구사항을 맞추기 위해 노력하고 있으며, 급변하는 협업적인 애자일 영역에서 특히 그렇다. 이러한 도전과제를 처리하기 위해 다음을 수행한다.

위로

새로운 Collaborative Design Management 기능이 도움이 되는 방법

IBM은 IBM 설계 소프트웨어의 다음 진화 및 Collaborative Design Management를 통해 이러한 도전과제를 처리하고 있다. 이러한 접근방식은 팀을 넘어서 협업을 확장하고 아키텍처와 제품 설계 원칙으로 라이프사이클 전반에서 추적성을 확장한다. IBM은 Rational Rhapsody 및 Rational Software Architect 설계 및 모델링 도구의 기능을 확장하였으므로 설계가 소프트웨어 및 시스템 개발 라이프사이클의 나머지에서부터 테스팅을 통해 요구사항 정의에서부터 심지어 운영적 자산에 이르기까지 아티팩트와 통합된다. 게다가 모든 관련된 이해 당사자는 IBM® Rational® Jazz™ 기술에 빌드된 고도로 협업적인 환경을 통한 웹 중심의 직관적 인터페이스를 갖춘 설계 프로세스에 참여하게 된다.

Collaborative Design Management 기능

• 설계 스토리지를 위한 Jazz 기술 기반 중앙 설계 허브로서 중앙 위치에서 모든 설계가 검색 가능하고 액세스 가능하게 된다.
• 어디서나 설계에 간편하게 액세스하기 위한 직관적인 웹 클라이언트로서 이해 당사자 협업을 향상시킨다.
• 웹 또는 리치 클라이언트를 통해 설계 요소의 주석과 마크업으로 자동화된 설계 검토
• OSLC(Open Source Lifecycle Collaboration)를 사용하여 관련된 모든 소스로부터 데이터를 뽑아내는 자동화된 보고서와 진행 상황 추적을 위한 대시보드를 통한 자동화된 문서 생성 및 보고
• 영향 분석과 보고를 향상시키기 위해 다른 소프트웨어 개발 라이프사이클 아티팩트로 OSLC 기반 연결

이러한 기능이 다섯 가지 복잡도 도전과제를 처리하는 방법

이러한 Collaborative Design Management 기능이 이전에 설명한 다섯 가지 복잡도 도전과제로 어떻게 적용될 수 있는지 알아보자.

1. 프로젝트 이해 당사자의 중요한 부분과 별개로 설계 팀이 작업하여 설계 및 전달된 소프트웨어 및 시스템이 기대에 부합하지 않게 된다.
   • 처리된 복잡도: 설계, 조작적
   • 사용된 Collaborative Design Management 기능: 이해 당사자 협업, 중앙 설계 허브, 검토 및 마크업, 관계 다이어그램
   
   
   그림 1. 확장된 팀 구성원들의 웹 기반 검토 및 설계의 마크업
   
   
   
   Collaborative Design Management(CDM) 소프트웨어는 고객, 분석가, 품질 보증 전문가, 공급업체 및 개인 운영자와 아키텍트 및 개발자 등 개발 중인 소프트웨어 또는 시스템에 관련된 모든 영역으로부터 이해 당사자에 입력을 제공하는 기능을 자동화한다. 설계 팀 외부의 검토자는 웹 클라이언트를 사용하여 중앙 설계 허브에 저장된 설계를 검색, 검토 및 주석을 추가하고 마크업할 수 있다. CDM을 사용하는 설계 팀은 더 이상 별개로 작업하지 않지만 설계 및 개발 프로세스 전반에 걸쳐서 이해 당사자로부터 항상 건설적인 피드백을 보유한다. 이해 당사자들은 중대한 작업을 설계하기 위해 스스로 수행하는(self-serve) 액세스가 있으며, 이는 본인들의 이해와 설계의 품질을 개선한다. 이해 당사자들은 본인들의 태스크와 관심 영역이 항목, 요구사항 및 테스트 케이스를 작업하기 위해 추적 가능한 링크가 있는 설계에 어떻게 연관되는지 판별할 수 있다.
   
   여러 가지 설계가 관계 다이어그램에 검색되고 필터링될 수 있으며, 전체 설계의 복잡도가 각 이해 당사자의 시각에 관련된 특정한 시각으로 간소화될 수 있다. 사일로화된 팀에 명백한 운영적 복잡도는 모든 이해 당사자가 중앙 설계 허브 및 웹 클라이언트로 보유한 간편한 액세스를 통해 처리되며, 이는 설계에서 협업이 가능하게 된다.

2. 프로젝트 계획, 요구사항, 테스트 계획, 테스트 케이스, 운영 및 유지보수 정보 그리고 고객 안내서와 매뉴얼 등의 라이프사이클에서 설계 요소가 다른 아티팩트에 느슨하게 결합되어, 이는 변경의 영향이 불확실해진다.
   • 처리된 복잡도: 프로세스
   • 사용된 CDM 기능: 중앙 설계 허브, OSLC 기반 추적성, 관계 다이어그램
   
   
   그림 2. OSLC를 통해 요구사항, 테스트 계획 및 다른 설계로 연결
   
   
   
   

   CDM을 통해 이해 당사자는 설계 요소에서 요구사항, 테스트 계획, 테스트 케이스, 프로젝트 계획 및 태스크로 링크를 작성하기 위해 OSLC를 사용할 수 있다. 이는 라이프사이클 전반에 걸쳐서 설계의 중요한 부문으로 추적성을 제공하므로 전체 프로세스 복잡도 문제를 처리하는 데 도움을 준다. 이러한 링크는 자동화된 보고서를 통해 관계 다이어그램에서 검토자, 설계자 및 개발자에 사용 가능하므로, 설계 또는 관련된 아티팩트에서 연결된 아티팩트를 수반하여 변경의 영향을 평가하기 위해 사용한다. 팀 구성원들은 이러한 도전과제로부터 나온 태스크에 대해 정보를 받고 영향 평가에 따라 필수 업데이트를 만들 수 있다. 라이프사이클 전반에 걸친 추적성도 포괄적인 보고서와 문서의 작성을 가능하게 하여 규제 또는 기업 표준 요구사항 및 감사를 충족시킨다.

3. 개발이 시작한 후에 설계가 검토하기에 어렵고 거의 유지보수되지 않으며, 이는 설계와 전달된 제품 사이에 중요한 연결이 끊어지게 된다.
   • 처리된 복잡도: 프로세스, 설계
   • 사용된 CDM 기능: 중앙 설계 허브, 관계 다이어그램, 자동화된 설계 검토
   
   
   그림 3. 확장된 팀이 참여하는 웹 기반의 자동화된 검토 태스크
   
   
   
   

   CDM을 사용하여 조직에 걸쳐서 그리고 라이프사이클 전반에 걸쳐서 나온 이해 당사자들은 설계를 검색, 분석 및 검토하기 위해 중앙 설계 허브에 액세스할 수 있다. 이들은 심지어 동일한 검색에서 여러 설계에 액세스할 수 있으므로 직관적인 웹 클라이언트를 사용하여 설계의 관련된 측면을 전체적으로 탐색하고 이해할 수 있다.

   설계자들은 어느 설계 및 이해 당사자를 포함하도록 지정하여 자동화된 검토를 시작할 수 있다. 이해 당사자들은 설계를 보고 웹 또는 리치 클라이언트를 사용하여 주석과 마크업을 첨부할 수 있다. 설계 검토는 계획과 추적을 위해 IBM® Rational Team Concert™ 작업 항목에 연결될 수 있다. 이러한 자동화된 검토 프로세스는 모든 관련된 이해 당사자를 참여시켜서 설계 및 개발 프로세스를 간소화하고 프로세스의 올바른 지점에 올바른 주제 전문가를 참여시켜 설계에서 복잡도 문제를 처리하는 데 도움을 준다.

4. 설계 프로세스에서 예측 가능성 및 효율성이 불확실하다는 것은 릴리스의 지연과 개발 자원의 비효율적인 사용을 야기한다.
   • 처리된 복잡도: 프로세스
   • 사용된 CDM 기능: 자동화된 설계 검토, 자동화된 문서 및 보고 생성
   
   
   그림 4. 개인화된 대시보드가 한 눈에 프로젝트 상태를 표시함
   
   
   
   

   Collaborative Design Management를 사용하여 팀들은 요구사항이 완성되면 바로 솔루션의 구현방식을 목표로 협업하고 작업하기 시작한다. 설계 프로세스가 잦은 변경, 끊임없는 유효성 검증 및 피드백이 개발 활동의 방향을 견고하게 해주는 팀 활동이 된다. 가시성이 더 높기 때문에 이해 당사자들은 초기 단계에서 팀 작업의 더 우수한 아이디어를 얻고 "실행 가능"한 내용이 전달되기 전에 팀의 진행 상황과 결과물로 최신 상태를 유지할 수 있다. 가장 중요한 것은 전체 개발 프로세스에 걸쳐서 이에 대해 활동을 연관시키고 추적하는 기능을 통해 설계가 다른 라이프사이클 아티팩트와 동일하게 취급된다.

5. 설계의 보고와 문서화는 노동 집약적이고 오류가 발생하기 쉬우며, 이로 인해 감사 실패를 야기하고 표준과 규제의 준수를 표시하기에 무력해지게 된다.
   • 처리된 복잡도: 프로세스, 설계
   • 사용된 CDM 기능: 중앙 설계 허브, 자동화된 문서화 및 보고, OSLC 추적성

   Collaborative Design Management 제품, Rational Software Architect Design Manager 및 Rational Rhapsody Design Manager는 둘 다 IBM® Rational® Publishing Engine과 통합되며, 이는 이질적인 애플리케이션에서 문서 생성을 자동화한다(그림 5 참조). 이는 대부분의 사용자 정의 가능한 부분이 자동으로 동적으로 작성됨을 의미한다. 이는 설계를 최신 상태로 유지하기 위한 보너스이며 공식적인 검토, 계약 의무 또는 표준 및 규제의 준수 증거를 위한 문서를 빠르고 간편하게 작성하기 위한 것이다.

   
   
   그림 5. 여러 OSLC 연결된 소스로부터 그린 자동화된 보고
   
   
   

설계의 주요 이점은 팀이 소프트웨어 또는 시스템의 작업에 통찰력을 확보하는 데 도움을 주는 문서를 작성하는 기능이다. Collaborative Design Management는 소프트웨어 또는 시스템이 자동화 및 일상적인 작업으로 통합을 통해 진화하면서 팀이 현재 및 최신 상태를 유지하도록 장려한다. 이는 프로젝트의 유지보수 또는 향후 확장에 사용될 수 있는 문서를 제작하는 데 도움을 줄 뿐만 아니라, 개발 감사 도중에 업계 표준의 준수를 보장하고 유효성 검증하는 방법으로서 역할을 담당할 수 있다.

위로

요약

설계를 작성하기 위해 Rational Software Architect 또는 Rational Rhapsody 설계 및 모델링 도구에서 설계를 작성하고, IBM의 시장을 선도하는 설계 및 개발 툴링을 사용하여 통합 작성된 Collaborative Design Management 기능을 활용하여, 조직들은 소프트웨어 및 시스템 전달의 끊임없이 늘어나는 복잡도와 관련된 중대한 도전과제를 처리할 수 있다. CDM은 고객, 비즈니스 관리자 계통, 운영 팀 및 다른 원칙과 조직의 다른 사람들을 비롯하여 광범위한 이해 관계자들을 함께 모아 제품, 소프트웨어 및 시스템의 설계에 기여하고 영향을 미친다. 이렇게 하면 개선된 품질을 추진하는 데 도움을 주고 원하는 비즈니스 결과물을 달성할 가능성이 증가한다.

Collaborative Design Management는 세 가지 중대한 목표를 달성할 수 있는 웹 기반 및 Jazz 기반 사용자의 직관적인 경험을 통해 설계 프로세스를 중심으로 이러한 이해 당사자들을 결집한다.

1. 설계에 대한 중앙 위치를 제공하여 생산성을 극대화하고 비용을 절감하여 검토자가 소스의 다양성으로부터 여러 설계에 걸쳐서 재사용 기회를 검색, 확인, 분석 및 식별하도록 사용한다.
2. 모든 이해 당사자를 참여시키는 설계 검토에서 협업을 통한 솔루션 품질을 개선한다.
3. 살아있는 동적인 설계, 메트릭 및 보고서를 통해 프로젝트 전달을 가속화한다.

참고자료

교육

• Capitalizing on Complexity: Insights from the IBM 2010 Global CEO Study: 1500건의 대면 인터뷰, 60개 국가의 다양한 규모의 회사들이 33개의 산업을 대표한다, (PDF)
  
  
• IBM.com의 Collaborative Design Management 페이지
  
  
• Rational Software Architect Design Manager 개요를 확인하자. Rational Software Architect에 대해 자세히 배우려면 developerWorks 페이지에서 시작하자. 또한 제품 개요 및 Information Center를 탐색하자. 여기에 설치 및 사용 지시사항이 나와있다.
  
  
• Rational Rhapsody Design Manager 개요를 읽어보자. 임베드된 시스템을 위한 협업적인 모델 구동형 개발을 위한 이러한 Rational Rhapsody 소프트웨어에 대해 자세히 학습하려면 IBM developerWorks에서 Rational Rhapsody 소개 및 Rational Rhapsody 페이지에서 시작하자.
  
  
• 또한 Rational Rhapsody 7.6 Information Center를 참조하고 다양한 버전을 살펴보자.
  
  
• 애플리케이션에 걸쳐서 문서 생성을 자동화하는 방법에 대해 자세히 학습하려면 Rational Publishing Engine의 developerWorks 페이지로 시작하자.
  
  
• Jazz.net에서 협업적인 아키텍처 설계 및 분석 프로젝트인 Design Management를 참조하자.
  
  
• developerWorks의 Rational 소프트웨어 영역에서 Rational Software Delivery Platform 제품과 관련된 기술 자료와 우수 사례를 볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.
  
  
• 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
  
  
• developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.
  
  
• 기술을 개선하자. Rational training and certification 카탈로그를 확인한다. 이는 광범위한 주제에 대한 과정 유형이 많이 들어있다. 이 중 일부를 언제 어디서나 확인할 수 있으며, 다수의 "시작하기"는 무료이다.
  
  

제품 및 기술

• Rational Software Architect Standard Edition 또는 Rational Software Architect for WebSphere Software에서 둘 중 하나 또는 둘 다 체험판 버전을 다운로드하자.
  
  
• Rational Rhapsody Developer를 다운로드하여 30일간 무료로 사용해보자.
  
  
• 자신에게 가장 적합한 방법으로 IBM 소프트웨어를 평가해 보자. 시험판 소프트웨어를 다운로드하거나 온라인으로 소프트웨어를 사용해 보거나 클라우드 환경에서 소프트웨어를 사용하거나 SOA Sandbox에서 SOA(Service-Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.
  
  

토론

• Rational Development Tools 포럼, Rational Rhapsody 포럼 및 Rational Publishing Engine 포럼의 토론에 참여하자.
  
  
• Jazz Community에 참여하여 Jazz.net에 대해 알아보자.
  
  
• developerWorks 기사를 기고하여 Rational 소프트웨어를 사용하는 다른 사람을 돕고 지식을 공유하자. 전 세계적으로 공개, RSS 신디케이션, 필자란과 전기 및 developerWorks Rational 웹 사이트에서 전문적인 편집과 제작의 혜택을 누리게 될 것이다. what makes a good developerWorks article과 진행 방법을 확인하자. what makes a good developerWorks Rational article을 찾아 시작하자.
  
  
• Facebook, Twitter(@ibmrational) 및 YouTube에서 Rational 소프트웨어를 따라하고, 주석과 요청을 추가하자.
  
  
• Rational 포럼, cafés 및 위키에 참여하여 질문과 답을 해보고 자신의 전문성을 강화하자.
  
  
• developerWorks 커뮤니티에 가입하고 개발자 구동 블로그에 응답하여 관심사를 공유하는 다른 사람들과 연결해보자.
  
  

필자소개

Neil은 IBM Rational 소프트웨어가 제공하는 시스템 솔루션에 대한 마케팅 관리자이며, 특히 설계 및 개발 기능 부문 전문가이다. 그는 예전에 IBM 비즈니스 파트너를 위한 Product Management의 디렉터이자, Rational Rose Technical Developer 및 Rational Systems Developer 등의 Rational 시스템 모델링 제품에 제품 관리자이었다. Neil은 Rational 기술 필드 팀 구성원 및 임베드된 소프트웨어 개발자로서 수 년간의 경험을 비롯하여 시스템 개발 부문에서 강력한 배경지식을 갖추었다. 그는 캐나다 오타와주에 거주한다.

아티클 순위

의견

위로

목차

• 소프트웨어 및 시스템 설계자에 영향을 주는 세 가지 복잡도 유형
• 결과적으로 나타나는 다섯 가지 도전과제
• 새로운 Collaborative Design Management 기능이 도움이 되는 방법
• 요약
• 참고자료
• 필자소개
• 의견