소프트웨어 공장

Software factory
Microsoft의 소프트웨어 팩토리는 소프트웨어 팩토리(Microsoft)를 참조하십시오.NET).
Factory(객체 지향 프로그래밍)와 혼동하지 마십시오.

소프트웨어 팩토리는 조립 과정을 통해 외부적으로 정의된 특정 최종 사용자 요건에 따라 컴퓨터 소프트웨어 애플리케이션 또는 소프트웨어 구성요소를 생산하는 데 도움을 주는 관련 소프트웨어 자산의 구조화된 모음입니다.[1]소프트웨어 공장은 기존 제조의 장점을 모방하기 위해 소프트웨어 개발에 제조 기법과 원칙을 적용한다.소프트웨어 공장은 일반적으로 아웃소싱된 소프트웨어 제작에 관여한다.

설명

소프트웨어 엔지니어링과 기업용 소프트웨어 아키텍처에서, 포괄적인 도구, 프로세스 및 콘텐츠를 템플릿 스키마, 조립, 그리고framework-based 부품 구성을 채택해 한archetypical 제품의 변형들의 개발과 유지 보수 자동화에 이용하여 구성합니다, 소프트웨어 공장은 소프트웨어 제품 라인.[2]

코딩은 소프트웨어 엔지니어(또는 전통 제조업의 병행자, 숙련된 장인)가 필요하기 때문에 응용 계층의 프로세스에서 제거되고, 소프트웨어는 기존의 IDE를 사용하는 대신 미리 정의된 구성품을 조립하여 만들어진다.전통적인 코딩은 새로운 요소나 서비스를 창조하기 위해서만 남겨진다.전통적인 제조와 마찬가지로 엔지니어링은 구성 요소의 생성과 시스템에 대한 요구 사항 수집에 맡겨진다.소프트웨어 공장에서 제조하는 최종 결과는 복합 응용 프로그램이다.

목적

소프트웨어 공장 기반의 애플리케이션 개발은 유사한 애플리케이션을 개발하여 생산되는 자산과 지식을 활용하지 않고 애플리케이션을 개발하고 제공하는 기존의 애플리케이션 개발 문제를 해결한다.교육, 문서화 및 프레임워크와 같은 많은 접근방식이 이 문제를 해결하기 위해 사용되지만, 이러한 접근방식을 사용하여 이전에 여러 애플리케이션을 개발하는 동안 얻은 귀중한 지식을 일관성 있게 적용하는 것은 비효율적이고 오류가 발생하기 쉬운 프로세스가 될 수 있다.

소프트웨어 공장은 프로젝트 팀이 채택하기 쉬운 통합 지침 패키지 안에 특정 유형의 응용 프로그램을 개발하기 위한 입증된 관행을 암호화하여 이 문제를 해결한다.적합한 소프트웨어 공장을 사용하여 애플리케이션을 개발하는 것은 생산성, 품질 및 진화 능력 향상과 같은 많은 이점을 제공할 수 있다.[1]

구성 요소들

소프트웨어 공장은 독특하기 때문에 특정 유형의 응용 프로그램을 구축하는 데 도움이 되도록 설계된 고유한 자산 세트를 포함한다.일반적으로 대부분의 소프트웨어 공장에는 다음과 같은 유형의 상호 관련 자산이 포함되어 있다.

  • 공장 스키마 : 시스템 구축 및 유지보수에 사용되는 자산(XML 문서, 모델 등)을 질서 있게 분류·정리하고, 이들 간의 관계를 규정하는 문서.[2]
  • 참조 구현: 소프트웨어 팩토리가 개발자를 돕는 실제적인 완제품의 예를 제공한다.
  • 아키텍처 지침 및 패턴:응용프로그램 설계 선택사항과 해당 선택사항에 대한 동기 부여에 대해 설명하십시오.
  • 사용 방법 항목: 작업을 완료하기 위한 절차와 지침을 제공하십시오.
  • 조리법:전체 또는 특정 단계에 따라 사용 방법 항목에서 절차 자동화개발자가 최소한의 입력만으로 일상적인 작업을 완료할 수 있도록 지원할 수 있다.
  • 템플리트: 인수에 대한 자리 표시자가 있는 미리 작성된 응용프로그램 요소.그것들은 초기 프로젝트 항목을 만드는 데 사용될 수 있다.
  • 설계자: 개발자가 더 높은 수준의 추상화로 애플리케이션을 모델링하는 데 사용할 수 있는 정보를 제공하십시오.
  • 재사용 가능한 코드:공통 기능 또는 메커니즘을 구현하는 구성요소.소프트웨어 공장에서 재사용 가능한 코드를 통합하면 수동으로 작성된 코드에 대한 요구사항을 줄이고 애플리케이션 전체에 걸쳐 재사용할 수 있다.[1]

상품개발

소프트웨어 팩토리를 이용한 제품 구축에는 다음 활동이 수반된다.

  • 문제 분석:제품이 소프트웨어 공장의 범위에 있는지 여부를 결정한다.적합치는 제품의 전부 또는 일부가 소프트웨어 공장과 함께 제조되는지 여부를 결정한다.
  • 제품 사양:다양한 제품 사양 메커니즘을 사용하여 제품 라인 요구사항과의 차이를 간략히 설명하여 제품 요구사항을 정의한다.
  • 제품 설계:요구사항의 차이를 제품 라인 아키텍처와 개발 프로세스의 차이에 매핑하여 맞춤형 프로세스를 생산한다.
  • 제품 구현:차이의 정도에 따라 구현을 개발하기 위해 다양한 메커니즘을 사용할 수 있다.
  • 제품 배포:기본 배포 제약 조건을 생성하거나 재사용하고 배포 중인 실행 파일을 설치하는 데 필요한 리소스 구성
  • 제품 테스트:시험 자산(시험 사례, 데이터 세트, 스크립트 등)을 생성하거나 재사용하고 계측 및 측정 도구를 적용하는 것을 포함한다.[2]

혜택들

소프트웨어 공장을 이용하여 애플리케이션을 개발하는 것은 기존의 소프트웨어 개발 접근방식에 비해 많은 이점을 제공할 수 있다.여기에는 다음이 포함된다.

  • 일관성: 소프트웨어 공장은 소프트웨어 제품군의 여러 인스턴스(유사한 특징과 아키텍처를 공유하는 일련의 애플리케이션)를 구축하기 위해 사용할 수 있어 일관성 확보가 용이하다.이는 거버넌스를 단순화하고 교육 및 유지관리 비용도 절감한다.
  • 품질:소프트웨어 공장을 사용하면 개발자들이 입증된 관행을 더 쉽게 배우고 구현할 수 있다.재사용 가능한 코드의 통합으로 개발자들은 각 애플리케이션에 고유한 기능에 더 많은 시간을 할애할 수 있어 설계 결함과 코드 결함의 가능성을 줄일 수 있다.소프트웨어 공장을 사용하여 개발된 애플리케이션도 배치 전에 검증할 수 있어 개발 중에 공장별 모범 사례가 준수되었는지 확인할 수 있다.
  • 생산성:소프트웨어 자산을 재사용하고 애플리케이션 요소와 메커니즘의 추상화로부터 코드를 생성하는 등 많은 애플리케이션 개발 활동을 간소화하고 자동화할 수 있다.[1]

이러한 이익은 다음과 같은 방법으로 여러 다른 팀에게 가치를 제공할 수 있다.

비즈니스 가치

비즈니스 작업을 단순화하여 사용자 생산성을 크게 높일 수 있다.이는 최종 사용자 교육의 필요성을 줄이는 공통적이고 일관된 사용자 인터페이스를 사용하여 달성된다.새로운 기능과 업데이트된 기능의 손쉬운 배치와 유연한 사용자 인터페이스를 통해 최종 사용자는 비즈니스 워크플로우를 따르는 방식으로 작업을 수행할 수 있다.데이터 품질 향상으로 ALT+TAB 및 복사/붙여넣기 기법을 통한 애플리케이션 부품 간 데이터 교환 필요성이 감소한다.[3]

건축가의 가치

소프트웨어 공장은 설계자가 품질과 일관성이 향상된 애플리케이션과 시스템을 설계하기 위해 사용할 수 있다.이는 가장 중요한 메커니즘과 공유 요소만을 포함하는 솔루션의 부분적인 구현을 만드는 능력을 통해 달성된다.기본 아키텍처로 알려진 이러한 유형의 구현은 설계 및 개발 과제를 해결하고, 아키텍처 결정을 노출하며, 개발 주기의 초기에 위험을 완화할 수 있다.소프트웨어 공장은 또한 비즈니스 논리와 무관하게 아키텍처 표준을 시행하기 위해 비즈니스 구성요소를 개발, 포장, 배치 및 업데이트하는 일관되고 선결적인 방법을 만들 수 있는 능력을 가능하게 한다.[3]

개발자 가치

개발자들은 소프트웨어 공장을 사용하여 생산성을 높이고 증가 시간을 줄일 수 있다.이는 코드와 패턴을 포함하는 애플리케이션의 고품질 출발점(기본점)을 만들어 달성한다.이를 통해 프로젝트는 전통적으로 개발된 애플리케이션보다 높은 수준의 성숙도로 시작할 수 있다.재사용 가능한 자산, 지침 및 예를 통해 공통 시나리오와 과제를 해결하고 공통 작업의 자동화를 통해 개발자는 일관된 방식으로 지침을 쉽게 적용할 수 있다.소프트웨어 공장은 애플리케이션 복잡성을 숨기고 우려를 분리하는 추상화 레이어를 제공하여 개발자가 인프라나 기본 서비스에 대한 심층적인 지식 없이도 비즈니스 논리, 사용자 인터페이스(UI) 또는 애플리케이션 서비스 등 다른 분야에 집중할 수 있도록 한다.일반적인 개발자 작업의 추상화와 인프라 코드의 재사용 가능성 증가는 생산성과 유지보수를 향상시키는 데 도움이 될 수 있다.[3]

작업 값

소프트웨어 공장으로 구축된 애플리케이션은 운영 노력의 통합으로 귀결된다.이를 통해 공통 비즈니스 요소와 모듈을 보다 쉽게 구축할 수 있어 애플리케이션 제품군 전체에 걸쳐 일관된 구성 관리가 가능하다.애플리케이션은 운영 팀이 기본 서비스를 제어할 수 있는 플러그형 아키텍처를 통해 중앙에서 관리할 수 있다.[3]

기타 접근법

소프트웨어 공장 개념에 대해 도구 지향적인 시책에서 프로세스 지향적인 시책에 이르기까지 대조적인 견해를 나타내는 몇 가지 접근법이 있다.다음 접근방식은 일본, 유럽, 북미 이니셔티브를 다룬다.[4]

산업화된 소프트웨어 조직(일본)

이 접근법 하에서 소프트웨어 공장에서 생산된 소프트웨어는 주로 제어시스템, 원자로, 터빈 등에 사용된다.이 접근법의 주요 목표는 품질과 생산성이 일치하여, 증가된 비용이 경쟁력을 약화시키지 않도록 하는 것이다.또한 설계, 프로그래밍, 시험, 설치 및 유지보수가 통일된 방식으로 수행될 수 있는 환경을 조성한다는 추가적인 목적이 있다.

품질과 생산성을 향상시키는 열쇠는 소프트웨어의 재사용이다.조직 설계의 주요 특징에는 운영 작업을 일상적이고 단순하며 반복적으로 만들고 작업 프로세스를 표준화하려는 단호한 노력이 포함된다.

이 접근방식의 대표적인 것이 1981년과 1987년 각각과 같이 회사의 소프트웨어 부문과 절차를 나타내는 도시바의 소프트웨어 공장 개념일 것이다.

일반 소프트웨어 팩토리(유럽)

이 접근방식은 유레카 프로그램에 의해 자금을 지원받았고 유레카 소프트웨어 팩토리라고 불렸다.이 프로젝트에는 유럽 대기업, 컴퓨터 제조업체, 소프트웨어 하우스, 연구소, 대학 등이 참여한다.이 접근방식의 목적은 소프트웨어 공장이 독립적 공급업체가 판매하는 부품으로 건설되고 맞춤화되기 위해 기술, 표준, 조직 지원 및 기타 필요한 인프라를 제공하는 것이다.

이 접근법의 목적은 통합 개발 환경을 위한 구조와 프레임워크를 생산하는 것이다.일반 소프트웨어 공장은 소프트웨어 부품에 대한 표준과 지침과 함께 소프트웨어 공장의 일부인 부품과 생산 환경을 개발한다.

경험 기반 부품 공장(북미)

경험에 근거한 부품 공장은 NASA 고다드 우주 비행 센터의 소프트웨어 공학 연구소에서 개발되었다.이 접근법의 목표는 "생산 환경에서 소프트웨어 프로세스를 이해하고, 이용 가능한 기술의 영향을 파악하며, 식별/정정정된 방법을 개발 프로세스에 다시 주입하는 것"이다.그 접근방식은 생산 환경에서 새로운 기술을 실험하고, 실험에서 경험과 데이터를 추출하여 적용하며, 비용, 신뢰성 및 품질에 대한 영향을 측정하는 것이었다.

이 접근방식은 특정 공정 특성과 제품 품질 사이의 관계를 이해함으로써 지속적인 개선을 강조한다.소프트웨어 공장은 강점과 약점에 관한 데이터를 수집하여 개선을 위한 기준선을 설정하고 새로운 프로젝트에 재사용할 경험을 수집하는 데 사용된다.

성숙한 소프트웨어 조직(북미)

역량 성숙도 모델에 의해 정의된 이 접근방식은 예측 가능하고, 신뢰할 수 있으며, 고품질의 소프트웨어를 생산하는 자체적인 소프트웨어 개발 프로세스를 달성하기 위한 프레임워크를 만들려는 것이다.이 전략은 소프트웨어 조직의 단계적 개선으로 구성되며, 어떤 프로세스가 개발의 핵심인지를 정의한다.소프트웨어 프로세스와 소프트웨어 제품 품질은 측정할 수 있는 한도 내에서 유지되기 때문에 예측 가능하다.

역사

쿠스마노는[8] 소프트웨어 공장에는 다음과 같은 6개의 단계가 있다고 제안한다.

  • 기본 조직 및 관리 구조(1960년대 중반 ~ 1970년대 초반)
  • 기술 맞춤화 및 표준화 (1970년대 초반에서 1980년대 초반)
  • 프로세스 기계화 및 지원 (1970년대 후반)
  • 프로세스 개선 및 확장(80년대 초반)
  • 통합 및 유연한 자동화(1980년대 중반)
  • 점진적인 제품/버라이어티 향상(1980년대 후반)

참고 항목

참조

  1. ^ a b c d "Software Factories". MSDN.
  2. ^ a b c Greenfield, Jack; Short, Keith; Cook, Steve; Kent, Stuart (2004). Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. ISBN 0-471-20284-3.
  3. ^ a b c d "Software Factories: Scenarios and Benefits". MSDN.
  4. ^ a b Aaen, Ivan; Bøttcher, Peter; Mathiassen, Lars (1997). "The Software Factory: Contributions and Illusions" (PDF). Proceedings of the Twentieth Information Systems Research Seminar. Scandinavia, Oslo.
  5. ^ Bratman, H.; Court, T. (1975). "The Software Factory". Computer. 8 (5): 28–37. doi:10.1109/c-m.1975.218953. S2CID 537648.
  6. ^ Cusumano, Michael A. (March 1989). "The Software Factory: A Historical Interpretation". IEEE Software. 6 (2): 23–30. doi:10.1109/ms.1989.1430446. S2CID 18982313.
  7. ^ Griss, M. L. (1993). "Software reuse: From library to factory". IBM Systems Journal. 32 (4): 548–566. CiteSeerX 10.1.1.88.2855. doi:10.1147/sj.324.0548.
  8. ^ Cusumano, Michael A. (1991). "Factory Concepts and Practices in Software Development". Annals of the History of Computing. 13 (1): 3–32. doi:10.1109/mahc.1991.10004. S2CID 7733552.

외부 링크