Section2. 소프트웨어 개발 라이프사이클


목차

 

 

SEL_SEC02_01

SEL_SEC02_02

Figure 2-1.  Activities by Percentage of Total Development Staff Effort

 

라이프사이클의 단계

요구사항 정의

요구사항 정의는 고객의 요구가 명확하게 변환되어 시스템이 해야 하는 것이 무엇인지에 대한 상세한 명세를 의미한다. 항공 다이내믹 어플리케이션의 경우 요구사항 정의 단계는 미션 작업이 수립되자마자 시작한다. 분석 팀은 미션에 대한 가용한 정보를 분석하고 운영 개념을 개발한다. 이것은 미션 이벤트에 대한 timeline, 요구되는 고도 운전, 포함되는 계산적 절차의 타입, 특정 운영 시나리오를 포함한다. 시스템이 수행해야 하는 기능은 서브시스템의 하위 수준으로 정의된다.

경험있는 개발자와의 작업으로 분석가는 현재 프로젝트에서 재 사용할 수 있는 이전에 개발된 소프트웨어가 있는지를 식별한다. 기존이 컴포넌트와의 통합 개발의 장단점이 심사숙고 되고 전체적인 아키텍처적 개념이 협의된다. 이런 분석의 결과가 시스템 및 운영 개념(SOC, system and operations concept) 문서에 기록되고 시스템 개념 검토(SCR, system concept review)에서 평가한다.

SOC에 의한 가이드로 요구사항 정의 팀은 미션 프로젝트 오피스에 의해 제공된 문서로부터 시스템 수준의 요구사항의 세트를 도출한다. 요구사항의 초안(draft) 버전은 소프트웨어 설계를 위한 적절한 용어로 다시 작성된다. 이런 명세는 어떤 데이터가 시스템으로 들어가고 어떤 데이터가 나오며 어떤 단계가 입력에서 출력으로 변환될 때 취해져야 하는지를 정의한다. 수학적 정보의 지원이 포함되며 완성된 요구사항 및 명세 문서가 릴리즈 된다. 이 작업의 결과는 시스템 요구사항 검토(SRR)로 표시되며 시스템을 위한 요구사항 및 명세 동안 평가된다.

 

요구사항 분석

요구사항 분석 단계는 SRR이후에 시작한다. 이 단계에서 개발 팀은 요구사항과 명세문서를 완전성 및 타당성 관점에서 분석한다. 개발 팀은 구조적 혹은 객체 지향적 분석 및 요구사항 분류 방법을 사용하여 명확하게 한다. 개발자들은 요구사항 정의 팀과 밀접하게 작업을 하여 모호함, 불일치, TBD(to-be-determined) 요구사항이나 명세를 해결한다.

재사용에 대한 주제는 요구사항 분석 및 설계 단계에 걸쳐 중요한 역할을 한다. 잠재적으로 재사용할 수 있는 아키텍처, 설계, 코드, 접근법을 식별한다. (라이프라이클에서 재사용에 대한 개요는 이 섹션의 뒤에서 표현된다.)

요구사항 분석이 완료되면, 개발 팀은 예비 설계의 기초로서의 요구사항 분석 보고서 (Requirement analysis report)의 요약을 준비한다. 이 단계는 소프트웨어 명세 검토(software specifications review, SSR)와 함께 끝나며 검토 동안 개발팀은 평가를 위한 분석 결과를 설명한다. 요구사항 정의팀은 요구사항을 업데이트하고 필요한 수정사항을 통합하기 위해 요구사항 및 명세 문서를 업데이트한다.

 

예비 설계

베이스라인된 요구사항과 명세는 요구사항 정의 팀과 개발팀간의 계약을 형성하게 되며 예비 설계를 위한 시작점이다. 이 단계 동안 개발팀의 멤버들은 시스템의 명세를 만족시키는 소프트웨어 아키텍처를 정의한다. 그들은 주요 서브 시스템으로 조직화하고 여럿의 가능한 선택들 중에서 최상의 설계를 선택한다. 모든 내부적 및 외부적 인터페이스가 서브시스템 수준까지 정의되고 높은 수준의 기능/객체의 설계가 명세 된다.

개발 팀은 예비 설계 보고서(preliminary design report)에서 시스템의 높은 수준의 설계를 문서화한다. 예비 설계 단계는 예비 설계 검토(preliminary design review, PDR)와 연결되게 되며 개발 팀은 형식적으로 평가를 위한 설계를 기술한다.

 

상세화된 설계

상세화된 설계 단계 동안 개발 팀은 예비 설계에서 정의된 소프트웨어 아키텍처를 확장하여 단위(unit) 수준까지 내린다. 연속적인 개량(refinement) 작업을 통해, 그들은 예비 설계를 소프트웨어에 대한 코드화 할 수 있는 명세서를 작성한다. 설계를 위한 모든 형식들이 생성되며, 다음을 포함한다.

  • 함수 혹은 객체 지향적 설계 다이어그램
  • 모든 사용자 입력, 시스템 출력(예를 들면, 스크린, 프린터, 플로터), 및 입력/출력 파일에 대한 설명
  • 운영상의 절차
  • 각각의 단위에 대한 기능적 및 절차적 설명
  • 단위들 사이의 모든 내부적 인터페이스의 설명

개발 팀은 이런 설계 문서를 상세설계 문서(detailed design document)에 명세하며 이는 구현의 기본 문서가 된다. 중요 설계 검토(critical design review, CDR)에서 상세 설계가 코딩을 시작하기에 충분히 자세하고 완전한지를 점검하게 되며 상세 설계 검토의 종료와 동시에 이 단계는 종료된다.

 

구현

구현 단계에서(코딩, 단위시험, 통합), 개발자들은 새로운 컴포넌트를 설계 명세서로부터 생성하며 기존의 컴포넌트를 수정하여 새로운 요구사항을 만족시키도록 한다. 그들은 각각의 컴포넌트를 통합하여 점점 큰 시스템으로 만들며 단위 및 통합 시험을 하여 새롭게 추가된 컴포넌트들이 올바르게 동작하는지를 확인한다.

일반적인 프로젝트에서 개발자들은 여럿의 서브시스템을 개별 컴포넌트로부터 동시에 빌드한다. 팀은 반복적으로 새로운 컴포넌트가 코딩되고 통합되어 소프트웨어가 변경될 때마다 각각의 서브시스템을 시험한다. 주기적으로 개발자들은 서브시스템을 묶어서 엔드 투 앤드 처리 능력을 시험하기 위한 동작할 수 있는 시스템으로 만든다. 어떤 컴포넌트를 코딩하고 동작할 수 있는 서브시스템으로 통합할 것인지에 대한 순서 및 이런 서브 시스템을 시스템으로 통합하기 위한 절차가 구현 계획에서 정의되고 상세 설계 단계에서 개발 관리자에 의해 준비된다.

그 팀은 또한 시스템 시험 계획을 생성하고 시스템 시험을 위한 준비에서 시험을 따르기 위한 사용자 가이드의 초판을 작성한다. 시스템을 위한 모든 코드가 동료 검토가 되고, 시험 되고, 통합되어 시스템으로 완성되면 구현 단계는 완료된 것으로 간주된다.

 

시스템 시험

시스템 시험 단계 동안 개발 팀은 완전히 통합된 시스템을 시스템 시험 계획에 따라 종단 사이의 기능 시험을 통해 밸리데이션 한다. 시스템 테스트 계획은 요구사항과 명세 문서를 기반으로 한다. 시험 계획에 명세된 시험의 성공적인 종료는 시스템이 요구사항을 만족함을 입증한다.

이 단계에서, 개발자들은 시스템 시험에 의해 발견된 모든 에러를 수정한다. 그들은 또한 사용자의 가이드를 수정하고 초기 시스템 설명 문서를 생성한다. 시스템 시험은 모든 테스트가 시스템 테스트 계획에 따라 완료될 때 종료된다.

 

인수 시험

인수 시험 단계에서 시스템은 독립적인 인수 시험 팀에 의해 시험되며 소프트웨어가 모든 요구사항을 만족하는지를 확인한다. 독립적인 팀에 의한 시험은 시스템이 원래 요구사항의 의도에 만족한다는 것을 보증한다. 인수 시험 팀은 일반적으로 시스템을 분석하는 사람과 요구사항 정의 팀의 멤버로 구성된다.

수행되어야 하는 시험이 인수 시험 계획에 명세 되며 이 단계 전에 인수 시험 팀에 의해 준비된다. 이 계획은 요구사항 및 명세의 내용과 승인된 명세 변경을 기반으로 한다.

인수 시험 동안, 개발 팀은 시험 팀을 지원하고 인수 시험을 수행한다. 시험에 의해 발견된 에러는 개발팀에 의해 수정된다. 인수 시험은 인수시험 계획이 성공적으로 수행되었을 때 완료된 것으로 간주하고 시스템은 공식적으로 인수된다. 개발 팀은 소프트웨어의 최종 버전과 시스템 문서(사용자 가이드 및 시스템 설명)를 사용자에게 전달한다.

 

유지보수 및 운영

인수 시험의 마지막에서 시스템은 유지 및 운영 그룹의 책임이 된다. 유지 및 운영 단계에서 수행되어야 하는 활동들은 시스템에 속한 소프트웨어의 타입에 의존적이다. 대부분의 항공기 소프트웨어의 경우 이 단계는 기본적으로 전투기 생명을 지속시키며 상대적으로 소프트웨어에 작은 변화를 포함한다. 하지만 도구 및 일반적 미션 지원 소프트웨어의 경우에는 이 단계는 훨씬 길고 더욱 적극적일 수 있는데, 그 이유는 소프트웨어가 요구사항 및 환경의 변경에 따른 응답으로 수정되기 때문이다.

유지보수 및 운영 단계는 특별히 이 문서에서 언급되지는 않는다. 하지만 향상 및 에러 수정은 또한 라이프사이클 개발을 통해 진행되며 여기에서 권장되는 접근법은 대부분의 파트에서 유지보수 및 운영 단계에 적용 가능하다. 형식적 검토의 횟수 및 유지 및 보수 동안 생성되는 문서는 소프트웨어의 규모와 복잡도 및 변경의 정도에 따라 다르다.

 

라이프 사이클의 테일러링

 

다른 범위와 기능의 프로젝트에 대한 (리뷰, 문서, 테스트 포함) 개발 방식을 조정하는 지침은 이 문서를 통해 제공된다. 여백에 가위 기호를 찾습니다.

소프트웨어 개발에 SEL의 권장되는 방법을 구축해 왔던 주요 특성 중 하나는 항공 역학 환경에서 문제 영역의 균일한 특성이다. 대부분의 소프트웨어는 임무 일반 궤도 결정 및 추적을 위한, 또는 임무 계획에 대해, 어느 특정 임무에 대한 태도를 결정 및 제어를 위해 설계되었습니다. 이 프로젝트는 표준 문서를 생성하고 리뷰의 일반적인 세트를 받고, 각 라이프 사이클 단계를 순차적으로 통해 ​​진행한다.

그러나 특정 프로젝트는 이 틀에 맞지 않는다. STL 내에서, 실험은 개발 프로세스를 연구하고 개선하기 위해 실시하고 있다. 고급 도구를 개발하고 있다. 이러한 개발 노력 – 프로토타이핑, 전문가 시스템, 데이터베이스 도구, 클린 룸 실험 등 – 라이프 사이클과는 통합 방법론은 종종 조정이 필요한다. 테일러링은, 수정, 교체 또는 빌드 과정에서 결합 될 수 있다 세부 사항 및 문서 및 리뷰 형식의 정도의 수준의 변화를 할 수 있다. 이러한 원래 제품의 품질을 희생하지 않고 프로젝트에 대한 전반적인 비용에 대해 고유한 요구사항 및 개발 제품에 대한보다 정확한 일치를 제공한다.

다음 단락에서는 다양한 크기와 종류의 프로젝트에 대한 수명주기를 조정하는 일반적인 지침을 설명한다. 추가 권장 사항은 특정 제품, 리뷰, 방법 및 도구에 대한 논의와 함께, 이 문서에서 찾을 수 있다.

 

빌드와 릴리즈

 

일반적 비행기 프로젝트는 상당히 다르다. 시뮬레이터는 3만줄(30KSLOC)에서 16만줄 (16 KSLOC)로 다르다. 고도 지상 지원 시스템은 13만줄에서 30만줄이며, 반면 대형 미션 일반 시스템은 1백만줄이다. 프로젝트가 커질수록 스케줄 지연의 위험은 더 커지며, 요구사항 변경, 인수 문제가 생긴다. 이런 위험을 줄이기 위해서 구현 단계는 프로젝트의 규모에 테일러링 되는 단계로 쪼개진다.

1만 줄 이상의 항공 프로젝트는 빌드로 구현된다. 빌드는 부분적으로 혹은 전체적으로 명세의 식별 가능한 일부를 만족시키는 시스템의 일부이다. 한번 빌드에서 만족되는 사양은 모든 그 뒤의 빌드에서도 만족한다. 그러므로 마지막 빌드는 완전한 시스템이다.

릴리즈는 인수 시험을 위해 전달되는 빌드이고 연속적으로 운영 목적을 위해 배포된다. 30만 줄 이상의 프로젝트는 스케줄링에 명시되지 않으면 일반적으로 단일 릴리즈로 전달된다. 대형 프로젝트 (30만줄 이상)은 30만에서 50만줄의 여러 릴리즈로 전달된다.

대형 프로젝트의 빌드는 6개월 지속될 수 있다. 작은 프로젝트의 빌드는 2~3개월 지속된다.

 

검토

분석가와 개발자가 이해하는 것을 확인하기 위해 그리고 고객의 요구를 만족시키는 것을 확인하기 위해 검토가 수행된다. 검토는 개발자를 도와주기 위한 것이고 불필요하게 그들에게 부담을 지워주려고 하는 것이 아니다. 검토의 횟수는 프로젝트마다 다를 수 있다. 도구 개발의 경우 요구사항, 요구사항 분석, 예비 설계는 PDR에서 동시에 검토될 수 있다. 몇 개월 걸리는 작은 프로젝트에는 단지 두 번의 검토가 적절하다. – SRR과 CDR. 매우 큰 프로젝트에 대해서는 CDR은 각각의 큰 릴리즈 때 혹은 서브시스템에 대해 열릴 수 있는데 이는 시스템의 모든 목적을 커버하고 변경되는 요구사항을 조정하기 위한 목적이다.

한번 혹은 그 이상의 검토가 통합되어야 하는지를 판단하기 위해서 사용되는 판단기준은 개발 프로세스와 라이프사이클 단계에 의존적이다. 요구사항 분석 단계에서 예를 들면, 다음의 질문에 대한 대답은 별도의 SSR에 대한 필요를 판단할 수 있다.

  • 검토되어야 할 필요가 있는 대단한 분석 이슈가 있는가?
  • 얼마나 많은 시간이 요구사항 분석의 시작과 설계의 시작 사이에 필요할 것인가?
  • 요구사항과 명세서가 얼마나 안정적인가?

작은 프로젝트에서 기술 검토는 핵심 인력과 고객 기술 대표와의 대면 미팅보다는 더욱 형식적일 필요는 없다. 하지만 일반적 항공 프로젝트에서는 검토는 형식화되고 특별한 형식을 따른다. 이런 검토에 대한 가이드라인은 섹션 3에서부터 9까지에 걸쳐 제공된다.

 

문서화

작은 프로젝트에서 기술 문서화는 중형이나 대형 프로젝트보다 덜 형식적이며 적은 문서가 출판된다. 일반적으로 큰 프로젝트에 개별적으로 생성되는 문서는 결합된다. 작은 연구 프로젝트에서 작은 설계 문서는 예비 설계 보고서, 상세설계 문서 및 시스템 기술서를 대체할 수 있다.

 

시험 및 검증

독립적 시험은 일반적으로 소규모, 도구 개발에서는 수행되지 않는다. 그와 같은 프로젝트들에 대한 시험 계획은 비형식적일 수 있다. 비록 코드 읽기가 항상 심지어 매우 소규모의 프로젝트에서 수행된다고 해도 단위는 종종 개별적으로 보다는 논리적으로 관련 있는 그룹에서 시험되며 검사(inspection)는 일반적으로 비형식적으로 일대일 세션으로 수행된다.

 

형상관리 및 품질 보증

형상관리는 소프트웨어 시스템의 컨텐츠를 제어하기 위한 관련된 모든 활동을 포함한다. 이런 활동은 시스템 컴포넌트의 상태에 대한 모니터링, 릴리즈된 문서의 무결성 유지, 시스템의 개발 버전의 무결성 유지, 시스템을 통한 변경 효과의 관리이다. 품질 보증 활동은 소프트웨어 개발 프로세스 및 제품이 수립한 기술 요구사항 및 품질 기준에 부합함을 확인하는 것이다.

전달을 위해 개발된 모든 소프트웨어와 문서들은 형식적 형상관리 대상이고 품질 보증 제어 대상이다. 내부 사용을 위해 배타적으로 개발된 도구들은 도구가 시스템을 생성, 실행, 시험하는데 요구되는 것이 아니면 면제된다.

중간 및 작은 프로젝트에서 형상 관리는 지정된 개발 팀의 멤버에 의해 수행될 수 있다 – 매우 큰 프로젝트에 권장되는 프랙티스이다. 유사하게 품질 보증 기능은 다른 책임을 가졌거나 기술 리더에 의해 관리되는 팀 멤버에게 할당될 수 있다.

 

프로토타이핑

프로토타이핑은 요구사항을 수립(establish)하거나 정제(refine) 하기 위해 혹은 중요한 설계 개념을 확인하기 위해 충분한 능력을 가지고 있는 시스템, 시스템의 컴포넌트, 시스템의 기능에 대한 조기 실험적 모델이다. 비행 역학 환경에서, 두 경우의 프로토타이핑에 사용된다. (1) 새로운 기술과 관련된 위험을 완화 (예를 들어, 하드웨어, 언어, 디자인 개념) 또는 (2) 요구사항의 문제를 해결. 후자의 경우, 전체 프로젝트를 저장 시스템에 대한 요구사항을 확립하도록 설계 노력을 프로토타이핑으로 계획할 수 있다.

전체 프로젝트의 최종 생성물은 프로토타이핑이 아니라면, 프로토타이핑의 활동은 일반적으로 요구사항 분석 및 설계 단계에서 완료된다. 프로토타이핑의 활동은 전체 시스템의 수명주기의 초기 단계에 포함되는 자체, 일반적으로 비공식적인, 수명주기가 있다. 프로토타이핑의 일부가 최종 시스템의 일부가 될 경우, 모든 기존 체크 포인트 (디자인 리뷰, 코드 판독, 단위 테스트 및 인증 등)를 통해 확인해야 한다. 일반적으로, 프로토 타이핑 활동은 전체 개발 노력의 더 이상 15 % 이상을 필요로 한다.

그러나 최종 생성물이 프로토 되는 프로젝트의 경우, 반복주기는 바람직 할 수 있다. 새로운 사용자 인터페이스는 시스템의 중요한 구성 요소인 경우에 특히 그러하다. 프로토타이핑의 초기 버전은 설계, 구현 및 추가하거나 그에 따라 요구사항을 개정 고객에게 보여줍니다. 프로토타이핑은 다음 추가 빌드로 확장, 및 완료 조건이 충족 될 때까지 주기가 계속된다.

 

규칙모든 프로토타이핑 활동은 계획되고 제어되어야 한다. 계획은 프로토타이핑의 목적과 노력 포로토타이핑 노력의 범위를 정의해야 하며 특정한 완료 기준을 수립해야 한다. 자세한 사항은 section 4를 참조한다.

 

언제 프로토타이핑을 할 것인가?

실용적인 규칙으로 다음과 같은 상황에서 프로토타이핑을 사용한다.

• 이 프로젝트는 새로운 기술, 예를 들어, 새로운 하드웨어, 개발 언어, 또는 시스템 아키텍처를 포함한다
• 요구사항은 이해되지 않습니다
• 성능, 신뢰성, 또는 타당성에 관한 주요, 해결되지 않은 문제가 있다
• 사용자 인터페이스는 시스템의 성공에 매우 중요하거나 명확하게 이해되지 않습니다

 

프로토타이핑의 모든 유형의 라이프 사이클을 조정하는 것은 주의 깊은 계획이 필요한다. 프로젝트에 사용되는 더 새로운 기술, 더 큰 프로토 노력이 필요하다. 프로토타이핑 노력이 클수록 더 많은 공식화로 기획, 개발, 관리해야한다. 아무리 작은 프로토타이핑 노력의 결과는 항상 문서화 되어야 한다. 프로토타이핑에서 얻은 교훈은 다음 단계에 대한 계획에 통합하는 프로젝트 기록에 포함되어 있다. 계획 및 프로토타이핑 작업을 문서화하는 방법에 대한 자세한 지침 제 4 절을 참조하십시오.

 

라이프사이클을 통한 재사용

주기의 처음부터 끝까지 SEL 추천 소프트웨어 개발 접근법은 재사용의 원리를 강조한다. 광범위하게 말해서, 기존의 경험을 재사용은 모든 영역에서 진행하는 핵심 요소이다. 재사용하지 않고, 모든 것을 다시 기억하고 다시 만들어야 한다. 소프트웨어 개발에서, 재사용은 비용을 절감하고 신뢰성 및 생산성을 모두 향상주기의 각 단계에서 “바퀴를 다시 만들”할 필요 없다.

재사용에 대한 계획 후속 프로젝트의 기간 동안 상각할 초기 시스템을 구축하는 학습의 비용을 수 있도록 하여 이러한 혜택을 극대화 할 수 있다. 계획 재사용은 객체 지향 디자인과 에이다 등의 최근 기술의 뒤에 기본 원동력이다.

 

가능한 재사용을 위한 프로젝트의 핵심 요소를 분석하라

  • 요구사항 특성
  • 소프트웨어 아키텍처
  • 소프트웨어 개발 프로세스
  • 시험 계획 및 절차
  • 코드
  • 스태프

 

 

모든 경험과 소프트웨어 개발 라이프 사이클의 제품 – 사양, 디자인, 문서, 테스트 계획, 뿐만 아니라 코드 – 재사용 할 가능성이 있다. 비행 역학 환경에서 특정 혜택 (참조문헌 7~10참고) 요구사항 및 사양 (즉, 형식, 주요 개념, 높은 수준의 기능을) 재사용 및 재사용을 위해 설계에 의해 얻어졌다.

그림 2-2은 재사용 활동은 소프트웨어 개발 라이프 사이클에 맞는 방법을 보여준다. 그림의 상단 절반에 재사용 할 수 있도록 하기 위해 실시하는 활동이 포함되어 있다. 하반부는 기존의 소프트웨어를 개발중인 시스템에 사용되는 활동을 도시한다. 이러한 활동은 다음 단락에 설명되어 있다.

 

미래의 재사용을 가능하게 하는 활동들

도메인 분석은 공통의 요구사항 및 기능을 식별하기 위해 개발 조직의 애플리케이션 도메인의 시험이다. 통상 요구 정의 및 분석 단계에서 수행되고, 그러나 또한 특정 개발 노력에 연결되지 않은 개별 활동으로 수행 될 수 있다. 도메인 분석은 특정 응용 분야의 일반적인 기능을 통합하고 개별 프로젝트 간의 차이를 수용하도록 정의 할 수 있는 표준, 일반 아키텍처 모델을 생성한다. 이 요구사항을 일반화 할 수 있다, 즉, 그들이 프로젝트나 임무의 선택 “가족”을 커버하는 방식으로 요구사항 및 사양의 준비를 가능하게 한다.

 

SEL_SEC02_03

Figure 2-2. Reuse Activities Within the Life Cycle

 원래 재사용을 위한 소프트웨어가 아닌 명시적으로 다시 사용하기 위해 설계된 소프트웨어보다 새로운 시스템에 통합하기가 더 어렵다. 재사용을 위해 디자인하는 것은 모듈, 표준 인터페이스 및 파라미터를 제공한다. 재사용을 촉진하는 설계 방법은 참고 문헌 9와 11에 설명되어 있다.

 

9. M. Stark, “On Designing Parametrized Systems Using Ada,” Proceedings of the SeventhWashington Ada Symposium, June 1990. Also published in Collected Software

Engineering Papers: Volume VIII, SEL-90-005, November 1990

 

11. G. Booch, Object-Oriented Design (with Applications), Benjamin/Cummings: Redwood

City, CA, 1991

재사용 라이브러리는 재사용 가능한 소스 코드와 관련된 요구사항, 사양, 설계 문서, 테스트 데이터를 보유. 코드 및 관련 제품을 저장하는 것 외에도, 도서관 (키워드 또는 이름 예) 소프트웨어에 액세스하는 여러 가지 방법을 제공하는 검색 기능이 포함되어 있다. 재사용이 설계 드라이버인 프로젝트에서 재사용 라이브러리의 포함하기 위한 소프트웨어 후보의 추출은 시스템 시험이 종료된 후 이루어진다.

 

현재 프로젝트에서의 재사용

요구사항 정의 및 분석 단계 동안 재사용 분석은 기존 소프트웨어의 메이저 세그먼트 (서브 시스템)의 개발이 시스템에서 사용될 수 있는지 결정하기 위해 수행된다. 설계 단계에서 개발자는 개별적으로 재사용 할 수 있는 요소를 검사하여 이러한 분석을 확인한다. 예비 설계 단계에서 개발자는 그대로 재사용 할 수 있거나 수정해야 하는지 여부를 결정하는 주요 구성 요소를 평가한다; 재사용 라이브러리에서 개별 단위는 상세 설계 단계에서 검토된다.

소프트웨어는 그대로 재사용 될 수 있거나 현재 프로젝트의 요구에 맞게 수정될 수 있다. 구현 단계에서 개발자는 재사용 라이브러리에 직접 연결하여 개발 시스템에 기존의 변경 단위를 통합 할 수 있다. 수정 된 소프트웨어, 반면에 통합되기 전에 피어 리뷰 유닛 테스팅을 실시해야 한다.

최종 재사용 활동주기의 유지 및 운영 단계 동안 일어난다. 이 구현의 변경을 통해 유지 보수 팀에 긍정적 또는 부정적으로 시스템의 안정성에 영향을 미칠 수 있다; 예를 들어, “빠른 수정”은 미래의 재사용을 복잡하게 할 수 있다. 분석, 설계, 구현 단계에서 재사용을 촉진 같은 사례의 많은 유지 보수 용으로 보존 기술을 재사용 할 수 있다.

 

측정

프로젝트 진행 상황과 생존의 조치는 소프트웨어 개발 노력의 효과적인 관리의 핵심이다. 수명주기의 각 단계에서 관리자가 진행, 안정성 및 개발 프로젝트의 품질을 평가하기 위해 검토해야 하는 특정 중요한 측정 기준이 있다.

모두 객관적이고 주관적인 데이터가 측정된다. 객관적인 데이터는 독립적으로 검증될 수 있는 항목 (예를 들어, 직원 시간, SLOC, 오류)의 실제 카운트이다. 주관적 데이터는 조건(예를 들어, 문제 또는 요구사항의 명확성의 난이도)의 개인 및 그룹의 평가에 의존적이다. 객관적 및 주관적 데이터들은 함께 견제와 균형의 시스템 역할을 한다. 객관적인 데이터는 관리자가 자신의 주관적인 이해에 의문을 제기하거나 추가로 조사하는 원인이 될 수 있는 반면, 주관적 데이터는 객관적인 데이터를 해석하거나 검증하기 위한 중요한 정보를 제공한다.

목표 측정은 두 그룹으로 분류 될 수 있다: (1) 진행 상황이나 상태를 측정 및 (2) 프로젝트 품질 (예를 들어, 안정성, 완전성 또는 신뢰성)을 측정. 부호화 단위의 개수 혹은 통과된 테스트의 수와 같은 진행 상태 측정은 완료되어야 하는 아이템의 총 개수의 숫자 대비 평가 된다. 반면, 매니저가 모델 또는 예상되어야 하는지를 나타내는 메트릭에 액세스 할 수 있다면 품질 측정은 유용하다.

SEL_SEC02_04

Table 2-1.  Measures Recommended by the SEL

 

SEL에서, 현재와 과거의 프로젝트에서 측정 된 데이터는 프로젝트 기록 데이터베이스에 저장된다. 이러한 데이터베이스로부터 추출된 정보를 이용하여, 관리자는 현재 프로젝트의 추세가 개발 환경에 대한 예상된 모델에서 다른지를 측정 할 수 있다. (참고 12의 섹션 6을 참조하라.)

 

12. Software Engineering Laboratory, SEL-84-101, Manager’s Handbook for Software Development (Revision 1), L. Landis, F. McGarry, S. Waligora, et al., November 1990

 

SEL에서 권장하는 관리 조치는 표 2-1에 나열되어 있다. 그림 2-3은 라이프사이클의 단계에서 각각의 측정이 수집되는 것을 나타낸다.

표 2-1에서 볼 수 있듯이, 개발자는 수집 수단을 많이 제공 할 책임이 있다. SEL 개발자는 이 목적을 위해 다양한 데이터 수집 형태를 사용한다. 각각의 형태가 적용되는 라이프 사이클 단계를 포함하는 이 문서의 섹션에서 설명한다.

 

SEL_SEC02_05

Figure 2-3.  Graph Showing in Which Life-Cycle Phases Each Measure Is Collected

 

실험

측정은 소프트웨어 개발 노력의 관리에 필수적일 뿐만 아니라 소프트웨어 프로세스 개선에도 매우 중요하다. SEL에서, 프로세스 개선은 삶의 방법이다. 실험은 지속적으로 더 높은 품질의 시스템을 구축하고 로컬 생산 공정을 개선하기 위한 노력으로 새로운 소프트웨어 엔지니어링 기술, 관행 및 도구를 조사하기 위해 실시되고 있다. SEL의 지속적인 측정 프로그램은 실험 프로젝트로부터의 데이터가 비교되는 반대 기존 개발 환경의 기준 데이터 및 모델을 제공한다.

수년 동안, SEL은 실험을 실시하고 크린룸 방법론의 적용에 영향을 측정했는데 (참고 문헌 2, 3, 4), 이는 할란 밀스에 의해 1980 년대 초에 개발되었다. 클린 룸 방법론의 목적은 제대로 처음 소프트웨어 제품을 구축하는 것이다. 클린 룸은 소프트웨어 제품을 확인하기 위해 인간의 지성을 사용하는 훈련 “읽기” 기술을 강조한다; 테스트는 오히려 에러를 검출 및 복구하는 방법을 위해서라기보다 품질 평가의 목적을 위해 수행된다.

 

클린룸 방법론은 여전히 SEL 의한 평가 초기 단계에 있다. 예를 들어, 코드 읽기 – – 클린 룸의 방법 중 일부는 SEL의 권장되는 방법에서 기존의 방법과 동일하지만 다른 측면은 실험으로 남아있다. 따라서, 청정실 방법론은 SEL의 추천 방법에 실험과 프로세스 개선의 적분 양태의 예로서 이 문서에서 사용된다. 수명주기 프로세스, 방법 및 클린 룸의 적용으로 인한 도구의 변화는 강조 표시된다. 실험 기호를 찾아라.

 

<상업적 이용 및 배포는 금합니다>

 

Advertisements

4 thoughts on “Section2. 소프트웨어 개발 라이프사이클”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s