PSP0 프로세스 및 최신 도구 및 프로그래밍 언어 [폐쇄

Question

그만큼 개인 소프트웨어 프로세스 (PSP)는 소프트웨어 엔지니어가 성능을 이해하고 향상시킬 수 있도록 설계되었습니다. PSP는 스크립트를 사용하여 프로세스를 통해 실무자를 안내합니다. 각 스크립트는 목적, 입력 기준, 수행 단계 및 출구 기준을 정의합니다. PSP0은 개인 프로세스를 시작할 수있는 프레임 워크로 설계되었습니다.

PSP0에 사용되는 스크립트 중 하나는 개발 스크립트이며 개발을 안내합니다. 이 스크립트는 요구 사항 명세서, 프로젝트 계획 요약, 시간 및 결함 기록 로그가 있고 결함 유형 표준이 설정되면 사용됩니다. 이 스크립트의 활동은 디자인, 코드, 컴파일 및 테스트입니다. 스크립트는 철저히 테스트 된 응용 프로그램과 완전한 시간 및 결함 로그가있을 때 종료됩니다.

코드 단계에서는 요구 사항을 검토하고 설계, 로그에서 요구 사항 결함을 기록하고 시간 추적을 수행합니다. 컴파일 단계에서 컴파일하고 컴파일 시간 오류를 수정하고 프로그램이 컴파일 될 때까지 반복하고 결함과 시간을 기록합니다. 마지막으로, 테스트 단계에서는 모든 테스트가 오류없이 실행되고 모든 결함이 고정되어 시간과 결함을 기록 할 때까지 테스트합니다.

현대적인 프로그래밍 언어 (특히 Python, Perl 및 Ruby와 같은 해석 된 언어) 및 IDE를 사용할 때 코드를 관리, 컴파일 및 테스트 단계를 관리하는 방법에 대한 우려가 있습니다.

내 질문 :

• 해석 된 언어에는 컴파일 시간이 없습니다. 그러나 실행에 문제가있을 수 있습니다. "컴파일"또는 "테스트"시간으로 간주되는 장치 (및 기타) 테스트 외부에서 스크립트를 실행하고 있습니까? 결함을 추적 할 때 실행 된 오류가 "컴파일"또는 "테스트"오류로 간주되어야합니까?
• 테스트 케이스가 구문 오류에 직면하면 코드 결함, 컴파일 결함 또는 테스트 결함으로 간주됩니까? 테스트는 실제로 오류를 발견했지만 코드 문제입니다.
• IDE가 실제로 컴파일하기 전에 컴파일을 방지하는 오류를 식별하면 식별해야합니까? 그렇다면 컴파일 오류 또는 코드 오류로 식별 및 추적해야합니까?

적어도 PSP0 기준 프로세스 인 PSP는 텍스트 편집기 (IDE가 아닌)를 사용하여 작성된 컴파일 된 언어 및 소규모 응용 프로그램과 함께 사용되도록 설계된 것처럼 보입니다. 내 질문 외에도 PSP를 사용하거나 사용한 사람의 조언과 논평에 감사드립니다.

Answer 1

답장을 읽은 후 마이크 버튼, Vinko Vrsalovic, 그리고 jrl 그리고 PSP의 적절한 장을 다시 읽습니다 : 소프트웨어 엔지니어를위한 자체 개선 프로세스 인 저는 이러한 문제에 대한 저의 테이크를 생각해 냈습니다. 그러나 좋은 점은 두 페이지가 함께 붙어있을 때 원래 놓친 책의 섹션을 찾았다는 것입니다.

• 해석 된 언어에는 컴파일 시간이 없습니다. 그러나 실행에 문제가있을 수 있습니다. "컴파일"또는 "테스트"시간으로 간주되는 장치 (및 기타) 테스트 외부에서 스크립트를 실행하고 있습니까? 결함을 추적 할 때 실행 된 오류가 "컴파일"또는 "테스트"오류로 간주되어야합니까?

이 책에 따르면, "컴파일하지 않는 개발 환경을 사용하는 경우 컴파일 단계를 건너 뛰어야합니다." 그러나 빌드 단계가 있으면 "컴파일 단계에서 빌드 시간과 빌드 오류를 기록 할 수 있습니다"라고 말합니다.

즉, 해석 된 언어의 경우 추적에서 컴파일 단계를 제거하거나 컴파일을 빌드 스크립트로 바꾸는 것을 의미합니다. PSP0은 일반적으로 소규모 응용 프로그램 (대학 실험실에서 기대할 수있는 것과 유사)과 함께 사용되므로 빌드 프로세스가없고 단순히 단계를 생략 할 것으로 기대합니다.

• 테스트 케이스가 구문 오류에 직면하면 코드 결함, 컴파일 결함 또는 테스트 결함으로 간주됩니까? 테스트는 실제로 오류를 발견했지만 코드 문제입니다.

나는 그들이 위치한 위치에 오류를 기록 할 것입니다.

예를 들어, 테스트 사례에 결함이있는 경우 테스트 결함이됩니다. 테스트가 실행되고 테스트중인 응용 프로그램에서 오류가 발견되면 문제가 실제로 시작된 위치에 따라 코드 또는 설계 결함입니다.

• IDE가 실제로 컴파일하기 전에 컴파일을 방지하는 오류를 식별하면 식별해야합니까? 그렇다면 컴파일 오류 또는 코드 오류로 식별 및 추적해야합니까?

IDE가 구문 오류를 식별하면 실행 전에 오류를 실제로 발견하는 것과 동일합니다. IDE를 올바르게 사용하면 실행에 영향을 미치는 결함이 발생할 수있는 변명은 거의 없습니다 (로직/구현 오류 이외의 응용 프로그램 실행에 오류가 발생 함).

Answer 2

일반적으로 PSP는 a입니다 개인 개선 프로세스, 실제 질문에 대한 답은 하나의 답변을 선택하고 일관되게 적용하는 한 중요하지 않습니다. 이렇게하면 정의 된 각 단계에서 취하는 시간을 측정 할 수 있습니다. 팀이 총체적으로 PSP를 사용하는 경우 사용할 스크립트와 질문에 답변하는 방법에 동의해야합니다.

실제 질문에 대한 나의 취향은 (그것들이 관련이 없음) :

• 해석 된 언어에는 컴파일 시간이 없습니다. 그러나 실행에 문제가있을 수 있습니다. "컴파일"또는 "테스트"시간으로 간주되는 장치 (및 기타) 테스트 외부에서 스크립트를 실행하고 있습니까? 결함을 추적 할 때 실행 된 오류가 "컴파일"또는 "테스트"오류로 간주되어야합니까?

나에게 테스트 시간은 실제 테스트가 실행되는 시간입니다. 이 경우, 오류와 실행 시간을 모두 '컴파일'시간으로 추가하여 코드를 생성하고 실행하는 데 사용됩니다.

• 테스트 케이스가 구문 오류에 직면하면 코드 결함, 컴파일 결함 또는 테스트 결함으로 간주됩니까? 테스트는 실제로 오류를 발견했지만 코드 문제입니다.

구문 오류는 코드 결함입니다.

• IDE가 실제로 컴파일하기 전에 컴파일을 방지하는 오류를 식별하면 식별해야합니까? 그렇다면 컴파일 오류 또는 코드 오류로 식별 및 추적해야합니까?

IDE가 툴체인의 일부라면 오류가 오류를 발견 한 것과 같습니다. 따라서 코드 오류가 발생합니다. IDE를 정기적으로 사용하지 않으면 컴파일 오류로 계산됩니다.

Answer 3

몇 년 동안 PSP를 사용했습니다. 다른 사람들이 말했듯이, 그것은 개인적인 과정이며, 개발 프로세스를 개선하기 위해 PSP0을 발전시켜야합니다. 그럼에도 불구하고, 우리 팀 (모든 PSP 훈련)은 여러 전선에서 이러한 문제로 어려움을 겪었습니다. 관련된 구성 요소에 대한 아이디어를 알려 드리겠습니다. 그런 다음 어떻게 관리했는지 말씀 드리겠습니다.

우리는 PowerBuilder "Tier"를 가졌습니다. PowerBuilder IDE는 코드가 올바르게 컴파일 될 때까지 코드를 저장하고 링크 할 때까지 저장하지 못하게합니다. 시스템의 일부는 JSP를 사용했지만 Java의 양은 사소했고 보일러 플레이트 이었지만 실제로는 전혀 계산하지 않았습니다. 시스템의 상당 부분은 JS/JavaScript에 있었다. 이것은 훌륭한 Ajax 라이브러리가 등장하기 전에 이루어졌으며 작품의 많은 부분을 나타 냈습니다. 다른 큰 부분은 Oracle PL/SQL이었다; 이것은 다소 전통적인 컴파일 단계가 있습니다.

PowerBuilder에서 작업 할 때 개발자가 객체를 저장했을 때 컴파일 (및 링크) 단계가 시작되었습니다. 저장이 성공하면 컴파일 시간을 0으로 기록했습니다. 그렇지 않으면 컴파일 타임 결함을 일으킨 오류를 수정하는 데 걸리는 시간을 기록했습니다. 대부분의 경우, 이들은 코딩에 주입 된 결함이었고 컴파일 단계에서 제거되었습니다.

PowerBuilder IDE의 컴파일/링크 측면은 코드 검토 단계를 컴파일 후로 이동시켜야했습니다. 처음에, 이것은 우리가 그러한 변화가 데이터의 의미에 어떻게 영향을 미칠지 확신하지 못했기 때문에 약간의 고통을 초래했습니다. 실제로, 그것은 비 문제가되었습니다. 실제로, 우리 중 많은 사람들이 Oracle PL/SQL 코드 리뷰를 컴파일 단계 후에도 옮겼습니다. 코드를 검토 할 때 종종 컴파일러가보고 할 구문 오류를 비롯해야합니다.

컴파일 시간 0에는 아무런 문제가 없으며, 테스트 시간이 0 인 것보다 더 잘못된 것보다 더 이상 문제가 없습니다 (오류를 감지하지 않고 단위 테스트가 통과되었으며 측정 단위보다 훨씬 빨리 실행되었습니다). 그 시간이 0 인 경우 해당 단계에서 결함을 제거하지 않으며 DIV/0 문제가 발생하지 않습니다. 더 편안하게 만들거나 측정에 0이 아닌 값이 필요한 경우 공칭 최소 1 분을 기록 할 수도 있습니다.

두 번째 질문은 개발 환경과 무관합니다. 결함이 발생하면 (일반적으로 설계 또는 코드) 주입 한 위상과 제거 단계 (일반적으로 설계/코드 검토, 컴파일 또는 테스트)를 기록합니다. 이는 "레버리지"라는 측정 값을 제공합니다. 이는 특정 단계에서 결함을 제거하는 상대적인 효과를 나타내며 (결함을 더 빨리 제거하는 것이 프로세스에서 나중에 제거하는 것보다 더 효과적이라는 "공통 지식"을 지원합니다). 결함이 주입 된 단계는 유형, 즉 설계 또는 코딩 결함입니다. 결함이 제거 된 단계는 유형에 영향을 미치지 않습니다.

마찬가지로 JS/JavaScript에서는 컴파일 시간이 효과적으로 헤아릴 수 없습니다. 우리는 컴파일 단계에 대한 시간을 기록하지 않았지만 다시, 그 단계에서 어떤 결함도 제거하지 않았습니다. 대부분의 JS/JavaScript 결함이 설계/코딩에 주입되어 설계 검토, 코드 검토 또는 테스트에서 제거되었습니다.

Answer 4

기본적으로 공식적인 프로세스가 연습 프로세스와 일치하지 않는 것처럼 들립니다. 물러서서, 당신이하고있는 일과 다른 공식적인 접근법을 선택 해야하는지 다시 평가하십시오 (실제로 시작하려면 공식적인 접근이 필요한 경우).

Answer 5

• 해석 된 언어에는 컴파일 시간이 없습니다. 그러나 실행에 문제가있을 수 있습니다. "컴파일"또는 "테스트"시간으로 간주되는 장치 (및 기타) 테스트 외부에서 스크립트를 실행하고 있습니까? 결함을 추적 할 때 실행 된 오류가 "컴파일"또는 "테스트"오류로 간주되어야합니까?

오류는 당신이 그것을 찾을 때가 아니라 생성 된 시점에 따라 분류되어야합니다.

• 테스트 케이스가 구문 오류에 직면하면 코드 결함, 컴파일 결함 또는 테스트 결함으로 간주됩니까? 테스트는 실제로 오류를 발견했지만 코드 문제입니다.

같은 상기와. 항상 가장 빠른 시점으로 돌아갑니다. 코딩 중 구문 오류가 도입되면 코딩 단계에 해당합니다. 버그를 고정하는 동안 도입 된 경우 결함 단계에 있습니다.

• IDE가 실제로 컴파일하기 전에 컴파일을 방지하는 오류를 식별하면 식별해야합니까? 그렇다면 컴파일 오류 또는 코드 오류로 식별 및 추적해야합니까?

나는 그것이 믿어야한다고 믿는다 ~ 아니다 식별됩니다. 코드를 작성하는 데 소요되는 시간입니다.

참고로, 프로세스 대시 보드 도구를 사용하여 PSP 데이터를 추적하여 매우 훌륭했습니다. 무료 및 Java 기반이므로 어디서나 실행해야합니다. 여기에서 얻을 수 있습니다.http://processdash.sourceforge.net/