퍼스널 소프트웨어 프로세스

Personal software process

퍼스널 소프트웨어 프로세스(PSP)는 소프트웨어 개발 방법을 규율화하고 코드의 예측 및 실제 개발을 추적함으로써 소프트웨어 엔지니어가 보다 잘 이해하고 성능을 향상시킬 수 있도록 설계된 구조화된 소프트웨어 개발 프로세스입니다.개발자들에게 제품의 품질 관리 방법, 건전한 계획 수립 방법 및 약속 방법을 명확하게 보여줍니다.또한 계획을 정당화하기 위한 데이터도 제공합니다.개발 시간, 결함, 크기 데이터를 분석 및 검토하여 작업을 평가하고 개선 방향을 제시할 수 있습니다.PSP는 Watts Humphrey가 소프트웨어 엔지니어링 연구소(SEI)의 기능 성숙도 모델(CMM)의 기본 원칙을 단일 개발자의 소프트웨어 개발 실무에 적용하기 위해 만들었습니다.소프트웨어 엔지니어에게 팀 소프트웨어 프로세스(TSP) 팀에서 작업하는 데 필요한 프로세스 기술을 제공한다고 주장합니다.

"퍼스널 소프트웨어 프로세스" 및 "PSP"는 Carnegie Mellon [1][2]대학의 등록 서비스 마크입니다.

목적

PSP는 소프트웨어 엔지니어에게 개인 소프트웨어 개발 프로세스를 개선하기 위한 규율 있는 방법을 제공하는 것을 목적으로 합니다.PSP는 소프트웨어 엔지니어의 다음 작업을 지원합니다.

  • 평가 및 계획 능력을 향상시킵니다.
  • 그들이 지킬 수 있는 약속을 하세요.
  • 프로젝트의 품질을 관리합니다.
  • 작업의 결함 수를 줄입니다.

PSP 구조

PSP 트레이닝은 진화적인 개선 접근방식을 따릅니다.PSP를 자신의 프로세스에 통합하는 방법을 학습하는 엔지니어는 첫 번째 레벨인 PSP0에서 시작하여 마지막 레벨인 PSP 2.1까지 진행됩니다.각 레벨에는 엔지니어가 필요한 단계를 안내하고 엔지니어를 지원하는 상세한 스크립트, 체크리스트 및 템플릿이 준비되어 있습니다.개인 소프트웨어 프로세스를 개선할 수 있습니다.Humphrey는 숙련된 엔지니어가 자신의 장점과 단점을 이해할 수 있도록 이러한 스크립트 및 템플릿을 커스터마이즈할 것을 권장합니다.

과정

PSP에 대한 입력은 요건입니다.요건 문서는 작성되어 엔지니어에게 전달됩니다.

PSP0, PSP0.1 (프로세스 규율 및 측정 도입)

PSP0에는 계획, 개발(설계, 코드, 컴파일, 테스트) 및 사후 모템의 3가지 단계가 있습니다.프로그래밍에 소요된 시간, 주입/제거된 결함, 프로그램 크기 등의 현재 프로세스 측정 기준선이 설정됩니다.사후 분석에서 엔지니어는 프로젝트의 모든 데이터가 적절하게 기록되고 분석되었는지 확인합니다.PSP0.1은 코딩 표준, 크기 측정 및 개인 프로세스 개선 계획(PIP)의 개발을 추가하여 프로세스를 진행시킵니다.PIP에는 엔지니어가 자신의 프로세스를 개선하기 위한 아이디어를 기록합니다.

PSP1, PSP1.1(견적 및 계획 도입)

엔지니어는 PSP0 및 PSP0.1에서 수집된 베이스라인 데이터를 바탕으로 새로운 프로그램의 크기를 예측하고 테스트 보고서(PSP1)를 작성합니다.이전 프로젝트에서 누적된 데이터를 사용하여 총 시간을 추정합니다.새로운 프로젝트마다 실제 소요 시간이 기록됩니다.이 정보는 태스크 및 스케줄 계획 및 견적(PSP1.1)에 사용됩니다.

PSP2, PSP2.1 (품질관리 및 설계 도입)

PSP2에는 설계 검토와 코드 검토라는 두 가지 새로운 단계가 추가되었습니다.PSP2에서는 결함 예방과 제거가 중점입니다.엔지니어는 각 개발 단계에서 작업 소요 시간과 주입 및 제거되는 결점의 수를 측정하여 프로세스를 평가하고 개선하는 방법을 학습합니다.엔지니어는 설계 및 코드 검토를 위해 체크리스트를 작성하고 사용합니다.PSP2.1은 설계사양 및 분석기법을 도입하고 있습니다.

(PSP3는 TSP로 대체된 레거시레벨입니다).

데이터의 중요성

PSP의 핵심 요소 중 하나는 이력 데이터를 사용하여 프로세스 성능을 분석하고 개선하는 것입니다.PSP 데이터 수집은 다음 4가지 주요 요소로 지원됩니다.

  • 스크립트
  • 방안
  • 표준

PSP 스크립트는 프로세스 단계를 따르기 위한 전문가 수준의 지침을 제공하며 PSP 조치를 적용하기 위한 프레임워크를 제공합니다.PSP에는 다음 4가지 핵심 척도가 있습니다.

  • 크기 – 코드 라인(LOC) 등 제품 부품의 크기를 측정합니다.
  • 작업 – 작업 완료에 필요한 시간.보통 분 단위로 기록됩니다.
  • 품질 – 제품의 결함 수.
  • 스케줄 – 프로젝트 진행 상황을 계획 및 실제 완료일과 비교하여 추적합니다.

프로세스에 표준을 적용하면 데이터의 정확성과 일관성을 보장할 수 있습니다.데이터는 보통 PSP 소프트웨어 도구를 사용하여 폼으로 기록됩니다.SEI는 PSP 도구를 개발했으며 프로세스 대시보드와 같은 오픈 소스 옵션도 사용할 수 있습니다.

PSP 툴에서 수집된 주요 데이터는 시간, 결함 및 크기 데이터입니다. 각 단계에서 소요된 시간, 결함의 주입, 발견 및 수정 장소, 제품 부품의 크기입니다.소프트웨어 개발자는 성능을 이해하고 개선하기 위해 이 세 가지 기본 척도에서 파생된 다른 많은 척도를 사용합니다.파생척도는 다음과 같습니다.

  • 추정 정확도(크기/시간)
  • 예측 구간(크기/시간)
  • 위상 분포 시간
  • 결함 주입 분포
  • 결함 제거 분포
  • 생산성
  • 재사용률
  • 코스트 퍼포먼스 지수
  • 계획치
  • 취득 가치
  • 예측 이익 가치
  • 결함 밀도
  • 위상별 결함 밀도
  • 단계별 결함 제거율
  • 결함 제거 레버리지
  • 리뷰 레이트
  • 공정 수율
  • 위상 수율
  • 품질 고장 비용(COQ)
  • 평가 COQ
  • 평가/실패 COQ비

계획 및 추적

과거 데이터는 추정 정확도를 향상시키는 데 사용되므로 시간, 결함 및 크기 데이터를 로깅하는 것은 PSP 프로젝트를 계획하고 추적하는 데 있어 필수적인 부분입니다.

PSP는 PROXY-Based Estimation(PROBE) 방법을 사용하여 개발자의 견적 스킬을 향상시켜 보다 정확한 프로젝트 계획을 수립합니다.프로젝트 추적의 경우 PSP는 취득값 방법을 사용합니다.

PSP는 또한 상관 관계, 선형 회귀 및 표준 편차 등의 통계 기법을 사용하여 데이터를 추정, 계획 및 품질을 개선하기 위한 유용한 정보로 변환합니다.이러한 통계식은 PSP 툴에 의해 계산됩니다.

PSP 사용

PSP는 개발자가 개인 프로세스를 개선하는 것을 목적으로 하고 있습니다.따라서 PSP 개발자는 프로세스를 지속적으로 조정하여 개인 요구를 충족시킬 수 있도록 해야 합니다.

PSP 및 TSP

실제로 PSP 스킬은 TSP 팀 환경에서 사용됩니다.TSP 팀은 PSP 훈련을 받은 개발자로 구성되며 프로젝트 담당 분야를 자원봉사로 지원하므로 프로젝트 관리는 팀 자체에서 이루어집니다.PSP 기술을 사용하여 수집된 개인 데이터를 사용하여 팀은 계획을 수립하고, 견적을 내고, 품질을 관리합니다.

PSP 프로세스 방식을 사용하면 TSP 팀이 스케줄 공약을 충족하고 고품질 소프트웨어를 제작할 수 있습니다.예를 들어 Watts Humphrey의 조사에 따르면 모든 소프트웨어 프로젝트의 3분의 1이 [3]실패하지만 13개 조직의 20개 TSP 프로젝트를 조사한 SEI 조사에 따르면 TSP 팀은 목표 일정을 평균 6%[4]밖에 달성하지 못했습니다.

일정의 약속을 성공적으로 이행하는 것은 이력 데이터를 사용하여 보다 정확한 견적을 내기 때문에 프로젝트는 현실적인 계획에 기초하고 있습니다.또한 PSP 품질 방법을 사용하여 결함이 적은 소프트웨어를 제작할 수 있기 때문에 통합이나 인수 테스트 등 후단계에서의 결함 제거에 소요되는 시간을 단축할 수 있습니다.

PSP 및 기타 방법론

PSP는 개별 개발자의 요구에 맞게 조정할 수 있는 개인 프로세스입니다.프로그래밍 또는 설계 방법론에 한정되지 않으므로 신속한 변화를 위한 소프트웨어 개발을 비롯한 다양한 방법론과 함께 사용할 수 있습니다.

소프트웨어 엔지니어링 방법은 예측에서 적응까지 다양하다고 볼 수 있습니다.PSP는 예측 방법론이며, Agile은 적응력이 뛰어난 것으로 간주되지만, TSP/PSP와 Agile은 서로 다른 점에도 불구하고 여러 가지 개념과 접근 방식, 특히 팀 구성과 관련하여 공유합니다.이 두 가지 기능을 통해 팀은 다음과 같은 일을 할 수 있습니다.

  • 목표와 기준을 정의합니다.
  • 작업의 견적과 스케줄을 설정합니다.
  • 현실적이고 달성 가능한 일정을 결정합니다.
  • 계획을 세우고 프로세스를 개선합니다.

Agile과 TSP/PSP는 모두 팀원들이 자신의 업무에 책임을 지고 함께 협력하여 현실적인 계획에 합의함으로써 신뢰와 책임의 환경을 조성한다는 생각을 공유하고 있습니다.그러나 TSP/PSP는 프로세스 문서화 및 프로젝트 일정 예측 및 정의용 데이터 사용에 중점을 두고 있다는 점에서 Agile과는 다릅니다.

퀄리티

고품질 소프트웨어는 PSP의 목표이며, 품질은 결함의 관점에서 측정됩니다.PSP의 경우 품질 프로세스는 사용자의 요구를 충족하는 결함 낮은 소프트웨어를 생성해야 합니다.

PSP 단계 구조를 통해 PSP 개발자는 장애를 조기에 발견할 수 있습니다.PSP는 장애를 조기에 발견함으로써 테스트 등의 후속 단계에서 소요되는 시간을 단축할 수 있습니다.

PSP 이론은 결함을 주입한 장소와 시기에 최대한 가깝게 제거하는 것이 경제적이고 효과적이기 때문에 소프트웨어 엔지니어는 개발 단계별로 개인 리뷰를 실시하도록 권장한다.따라서 PSP 단계구조에는 다음 두 가지 검토 단계가 포함됩니다.

  • 설계 리뷰
  • 코드 리뷰

효과적인 검토를 위해서는 체계적인 검토 프로세스를 따라야 합니다.PSP는 개발자가 일관성 있는 절차를 따르도록 하기 위해 체크리스트를 사용할 것을 권장합니다.

PSP는 사람들이 실수를 했을 때, 그들의 오류는 보통 예측가능하기 때문에 PSP 개발자들은 체크리스트를 개인화하여 자신의 일반적인 오류를 대상으로 삼을 수 있다는 전제를 따르고 있습니다.소프트웨어 엔지니어는 현재 성능에서 개선이 필요한 취약 영역을 식별하기 위해 프로세스 개선 제안서를 작성해야 합니다.과거 프로젝트 데이터는 시간이 소요되고 결함이 발생한 위치를 나타내므로 개발자가 개선해야 할 영역을 식별하는 데 도움이 됩니다.

또한 PSP 개발자는 동료 또는 팀 리뷰를 받기 전에 개인 리뷰를 수행해야 합니다.

인정.

PSP에 관한 인증은 Carnegie Mellon University의 SEI에 의해 제공됩니다.SEI 인증 PSP 개발자가 되기 위한 절차는 다음과 같습니다.PSP 학습, 인정시험 응시, 자격증 유지입니다.PSP Developer 검사는 PSP [5]Body of Knowledge에서 발견된 개념을 기반으로 합니다.SEI는 인증에 관한 FAQ를 유지하고[1] 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b "SEI-Certified PSP Developer: Frequently Asked Questions". SEI Training. Pittsburgh, Pennsylvania: Software Engineering Institute, Carnegie Mellon University. Archived from the original on 29 November 2014. Retrieved 17 November 2014. {{cite web}}:외부 링크 work=(도움말)
  2. ^ "Terms of Use". USA: Software Engineering Institute, Carnegie Mellon University. Retrieved 14 January 2013.
  3. ^ Humphrey, Watts S. "대규모 소프트웨어 프로젝트가 실패한 이유:12가지 주요 질문"CrossTalk 2005년 3월 http://www.crosstalkonline.org/storage/issue-archives/2005/200503/200503-Humphrey.pdf Wayback Machine에서 2019-11-05년 아카이브 완료
  4. ^ 데이비스, 누퍼, 줄리아 멀레이니.실천 중인 팀소프트웨어 프로세스 SM(TSP SM):최근 결과의 요약.Pittsburgh, PA: Software Engineering Institute, 2003년 9월
  5. ^ Pomeroy-Huff, Marsha; Cannon, Robert; Chick, Timothy A.; Mullaney, Julia; Nichols, William (2009). The Personal Software Process (PSP) Body of Knowledge, Version 2.0 (PDF). Pittsburgh, Pennsylvania: Software Engineering Institute, Carnegie Mellon University. Retrieved 17 November 2014. 무료로 다운로드 가능한 스페셜 리포트 CMU/SEI-2009-SR-018, 2009

추가 정보

외부 링크

  • 소프트웨어 프로세스 대시보드, 오픈 소스(GPL3) PSP 및 TSP 툴. 독자적인 SEI 스크립트가 없는 경우와 없는 경우 모두 제공되며, 그 후에는 무료 SEI 등록이 필요합니다.