본문으로 이동

소프트웨어 팩토리

위키백과, 우리 모두의 백과사전.

소프트웨어 팩토리(software factory)는 제조 과정을 통해 외부에서 정의된 특정 최종 사용자 요구 사항에 따라 컴퓨터 소프트웨어 응용 프로그램 또는 소프트웨어 구성 요소를 생산하는 데 도움이 되는 관련 소프트웨어 자산의 구조화된 모음이다.[1] 소프트웨어 팩토리는 전통적인 제조의 이점을 모방하기 위해 소프트웨어 개발에 제조 기술 및 원칙을 적용한다. 소프트웨어 팩토리는 일반적으로 아웃소싱된 소프트웨어 생성과 관련이 있다.

설명

[편집]

소프트웨어 공학 및 엔터프라이즈 소프트웨어 구조에서 소프트웨어 팩토리는 프레임워크 기반 구성 요소를 조정, 조립 및 구성하여 전형적인 제품의 변형 개발 및 유지 관리를 자동화하기 위해 스키마 기반 템플릿을 사용하여 광범위한 도구, 프로세스 및 콘텐츠를 구성하는 소프트웨어 제품군이다.[2]

코딩은 소프트웨어 공학자 (또는 전통적인 제조의 경우 숙련공)를 필요로 하므로, 응용 프로그램 계층에서 프로세스에서 제거되고 소프트웨어는 전통적인 IDE를 사용하는 대신 미리 정의된 구성 요소를 조립하여 생성된다. 전통적인 코딩은 새로운 구성 요소나 서비스를 생성하는 데에만 사용된다. 전통적인 제조와 마찬가지로 엔지니어링은 구성 요소 생성과 시스템 요구 사항 수집에 남겨진다. 소프트웨어 팩토리에서 제조의 최종 결과는 복합 응용 프로그램이다.

목적

[편집]

소프트웨어 팩토리 기반 응용 프로그램 개발은 유사한 응용 프로그램 개발에서 얻은 지식과 생성된 자산을 활용하지 않고 응용 프로그램이 개발 및 제공되는 전통적인 응용 프로그램 개발의 문제를 해결한다. 교육, 문서화 및 프레임워크와 같은 많은 접근 방식이 이 문제를 해결하는 데 사용된다. 그러나 이러한 접근 방식을 사용하여 여러 응용 프로그램 개발 중에 이전에 얻은 귀중한 지식을 일관되게 적용하는 것은 비효율적이고 오류가 발생하기 쉬운 프로세스일 수 있다.

소프트웨어 팩토리는 프로젝트 팀이 채택하기 쉬운 통합 지침 패키지 내에서 특정 스타일의 응용 프로그램을 개발하기 위한 검증된 사례를 인코딩함으로써 이 문제를 해결한다. 적절한 소프트웨어 팩토리를 사용하여 응용 프로그램을 개발하면 생산성, 품질 및 진화 기능 향상과 같은 많은 이점을 얻을 수 있다.[1]

구성 요소

[편집]

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

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

제품 개발

[편집]

소프트웨어 팩토리를 사용하여 제품을 구축하는 데는 다음과 같은 활동이 포함된다.

  • 문제 분석: 제품이 소프트웨어 팩토리 범위에 속하는지 여부를 결정한다. 적합성은 제품의 전부 또는 일부가 소프트웨어 팩토리로 구축되는지 여부를 결정한다.
  • 제품 사양: 다양한 제품 사양 메커니즘을 사용하여 제품군 요구 사항과의 차이점을 설명함으로써 제품 요구 사항을 정의한다.
  • 제품 디자인: 요구 사항의 차이점을 제품군 아키텍처 및 개발 프로세스의 차이점으로 매핑하여 맞춤형 프로세스를 생성한다.
  • 제품 구현: 차이점의 정도에 따라 구현을 개발하는 데 다양한 메커니즘을 사용할 수 있다.
  • 제품 전개: 배포되는 실행 파일을 설치하는 데 필요한 자원을 생성하거나 재사용하고 구성하는 것을 포함한다.
  • 제품 테스트: 테스트 자산(테스트 케이스, 데이터 세트 및 스크립트 등)을 생성하거나 재사용하고, 계측 및 측정 도구를 적용하는 것을 포함한다.[2]

이점

[편집]

소프트웨어 팩토리를 사용하여 응용 프로그램을 개발하면 기존 소프트웨어 개발 접근 방식과 비교하여 많은 이점을 얻을 수 있다. 다음과 같은 이점이 있다.

  • 일관성: 소프트웨어 팩토리는 소프트웨어 제품군(유사한 기능과 아키텍처를 공유하는 응용 프로그램 집합)의 여러 인스턴스를 구축하는 데 사용될 수 있어 일관성을 쉽게 달성할 수 있다. 이는 거버넌스를 단순화하고 교육 및 유지 보수 비용을 절감한다.
  • 품질: 소프트웨어 팩토리를 사용하면 개발자가 검증된 사례를 더 쉽게 배우고 구현할 수 있다. 재사용 가능한 코드의 통합 덕분에 개발자는 각 응용 프로그램에 고유한 기능에 더 많은 시간을 할애할 수 있어 설계 결함 및 코드 결함 발생 가능성이 줄어든다. 소프트웨어 팩토리를 사용하여 개발된 응용 프로그램은 배포 전에 검증될 수도 있어 개발 중에 팩토리별 모범 사례가 준수되었는지 확인할 수 있다.
  • 생산성: 소프트웨어 자산 재사용 및 응용 프로그램 요소 및 메커니즘의 추상화에서 코드 생성과 같은 많은 응용 프로그램 개발 활동을 간소화하고 자동화할 수 있다.[1]

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

비즈니스를 위한 가치

[편집]

비즈니스 작업이 단순화되어 사용자 생산성을 크게 높일 수 있다. 이는 최종 사용자 교육의 필요성을 줄이는 일반적이고 일관된 사용자 인터페이스를 사용하여 달성된다. 새롭고 업데이트된 기능의 쉬운 배포와 유연한 사용자 인터페이스 또한 최종 사용자가 비즈니스 워크플로에 따라 작업을 수행할 수 있도록 한다. 데이터 품질 향상은 ALT+TAB 및 복사 및 붙여넣기 기술을 통한 응용 프로그램 부분 간의 데이터 교환 필요성을 줄인다.[3]

아키텍트를 위한 가치

[편집]

아키텍트는 소프트웨어 팩토리를 사용하여 품질과 일관성이 향상된 응용 프로그램 및 시스템을 설계할 수 있다. 이는 가장 중요한 메커니즘과 공유 요소만 포함하는 솔루션의 부분 구현을 생성하는 능력을 통해 달성된다. 기준 아키텍처라고 불리는 이러한 유형의 구현은 설계 및 개발 문제를 해결하고, 아키텍처 결정을 노출하며, 개발 주기 초기에 위험을 완화할 수 있다. 소프트웨어 팩토리는 또한 비즈니스 로직과 무관하게 아키텍처 표준을 적용하기 위해 비즈니스 구성 요소를 개발, 패키징, 배포 및 업데이트하는 일관되고 예측 가능한 방법을 생성할 수 있도록 한다.[3]

개발자를 위한 가치

[편집]

개발자는 소프트웨어 팩토리를 사용하여 생산성을 높이고 램프업 시간을 줄일 수 있다. 이는 코드와 패턴을 포함하는 응용 프로그램의 고품질 시작점(기준선)을 생성함으로써 달성된다. 이를 통해 프로젝트는 전통적으로 개발된 응용 프로그램보다 더 높은 성숙도 수준에서 시작할 수 있다. 재사용 가능한 자산, 지침 및 예제는 일반적인 시나리오 및 과제를 해결하는 데 도움이 되며, 일반적인 작업의 자동화는 개발자가 일관된 방식으로 지침을 쉽게 적용할 수 있도록 한다. 소프트웨어 팩토리는 응용 프로그램 복잡성을 숨기고 관심사를 분리하는 추상화 계층을 제공하여 개발자가 인프라 또는 기준 서비스에 대한 심층적인 지식 없이 비즈니스 로직, 사용자 인터페이스(UI) 또는 응용 프로그램 서비스와 같은 다양한 영역에 집중할 수 있도록 한다. 일반적인 개발자 작업의 추상화 및 인프라 코드의 재사용성 증가는 생산성 및 유지 관리성을 높이는 데 도움이 될 수 있다.[3]

운영을 위한 가치

[편집]

소프트웨어 팩토리로 구축된 응용 프로그램은 운영 노력의 통합을 가져온다. 이는 일반적인 비즈니스 요소 및 모듈의 쉬운 배포를 제공하여 응용 프로그램 제품군 전반에 걸쳐 일관된 구성 관리를 가능하게 한다. 응용 프로그램은 플러그형 아키텍처를 통해 중앙에서 관리할 수 있으며, 이를 통해 운영 팀은 기본 서비스를 제어할 수 있다.[3]

다른 접근 방식

[편집]

소프트웨어 팩토리 개념에 대한 대조적인 견해를 나타내는 여러 접근 방식이 있으며, 도구 지향적인 것부터 프로세스 지향적인 이니셔티브까지 다양하다. 다음 접근 방식은 일본, 유럽 및 북미 이니셔티브를 다룬다.[4]

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

[편집]

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

품질과 생산성을 향상시키는 핵심은 소프트웨어 재사용이다. 조직 설계의 지배적인 특징은 운영 작업을 일상적이고 단순하며 반복적으로 만들고 작업 프로세스를 표준화하려는 확고한 노력이다.

이 접근 방식의 대표적인 예는 도시바의 소프트웨어 팩토리 개념으로, 각각 1981년과 1987년의 회사 소프트웨어 부서 및 절차를 나타낸다.

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

[편집]

이 접근 방식은 유레카 프로그램의 지원을 받아 유레카 소프트웨어 팩토리라고 불렸다. 이 프로젝트의 참가자는 유럽 대기업, 컴퓨터 제조업체, 소프트웨어 회사, 연구 기관 및 대학이다. 이 접근 방식의 목표는 독립 공급업체가 판매하는 구성 요소에서 소프트웨어 팩토리를 구축하고 맞춤화하는 데 필요한 기술, 표준, 조직 지원 및 기타 필수 인프라를 제공하는 것이다.

이 접근 방식의 목표는 통합 개발 환경을 위한 아키텍처와 프레임워크를 생산하는 것이다. 일반 소프트웨어 팩토리는 소프트웨어 구성 요소를 위한 표준 및 지침과 함께 소프트웨어 팩토리의 일부인 구성 요소 및 생산 환경을 개발한다.

경험 기반 구성 요소 팩토리(북미)

[편집]

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

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

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

[편집]

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

역사

[편집]

쿠수마노(Cusumano)[8]는 소프트웨어 팩토리의 여섯 가지 단계를 제안한다.

  • 기본 조직 및 관리 구조 (1960년대 중반 ~ 1970년대 초반)
  • 기술 맞춤화 및 표준화 (1970년대 초반 ~ 1980년대 초반)
  • 프로세스 기계화 및 지원 (1970년대 후반)
  • 프로세스 정제 및 확장 (1980년대 초반)
  • 통합 및 유연한 자동화 (1980년대 중반)
  • 점진적인 제품/다양성 개선 (1980년대 후반)

같이 보기

[편집]

각주

[편집]
  1. ↑ 가 나 다 라 “Software Factories”. MSDN. 2014년 5월 20일. 
  2. ↑ 가 나 다 Greenfield, Jack; Short, Keith; Cook, Steve; Kent, Stuart (2004). 《Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools》. Wiley. ISBN 0-471-20284-3. 
  3. ↑ 가 나 다 라 “Software Factories: Scenarios and Benefits”. MSDN. 2014년 5월 20일. 
  4. ↑ 가 나 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. 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. 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. 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. 3–32쪽. doi:10.1109/mahc.1991.10004. S2CID 7733552. 

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=소프트웨어_팩토리&oldid=40330362"