엔지니어의 프로세스를 분석하는 우아한 방법이 있습니까?

커밋 측정이 부적절하다는 정서가 많이 있습니다 .

커밋보다 더 많은 소스를 얻으려고 시도한 연구가 있습니까?

• 브라우징 패턴
• IDE 작업 (사전 커밋)
• 유휴 시간
• 멀티 태스킹

이러한 조치를 수행하는 쉬운 방법은 생각할 수 없지만 어떤 연구가 수행되었는지 궁금합니다.

개인적으로, 나는 자신의 '메트릭'에 대한 성찰이 성능 평가를 위해 이들을 사용하거나 관계없이 가치가 있다고 생각합니다. IE는 습관을 반영하는 편견없는 방법입니다. 그러나 이것은 Q & A 이외의 토론 문제입니다.

우아하다고 생각할지 모르겠지만 Watts Humphrey는 개인 소프트웨어 프로세스라는 책을 썼습니다. 그는 책상에서의 시간과 중단 시간, 다양한 종류의 소프트웨어 수명주기 활동에 소요 된 시간, 코드 양당 결함과 같은 입력에 대한 메트릭을 설명했습니다. 다음에 짧은 버전을 제공하는 기술 보고서가 있습니다.

http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm

개발자 코드의 품질과 같은 것을보고 싶다면 Chidamber & Kemerer 는 객체 지향 코드에 대한 몇 가지 메트릭을 제안했습니다.

객체 지향 코드에 대한 메트릭

• 상속 깊이 트리,
• 가중 된 방법의 수,
• 멤버 함수 수
• 어린이 수
• 객체 간의 결합.

그들은 기본 코드를 사용하여 공변량 분석을 사용하여 이러한 메트릭을 결함 밀도 및 유지 관리 노력과 연관 시키려고했습니다. 이후의 연구는 수백 개의 Source Forge Java 프로젝트에 대해 유사한 분석을 수행하여 CK 지표 및 나중에 제안되는 일부 추가 지표와 관련된 특성을 결정했습니다.

코드 검토와 관련하여 발생하는 지표

결함은 여러 기준으로 분류 할 수 있습니다.

• 심각도 : (주요, 미성년자, 미용, 조사 / 알 수 없음),
• 유형 (논리, ​​오타, 철자, 코딩 표준 위반 등)
• 원산지 / 단계 억제 (요구 사항, 설계, 코드 등).

또한 준비 및 검사 속도 (검토 자당 시간, 코드 라인 당 시간) 및 결함 밀도 ( KLOC (천 라인 코드) 당, 분당 검사자 / 검토 자 시간)가 있습니다.

이러한 값을 관리도에 도표로 표시하면 프로세스 범위 내에 있는지 여부를 알 수 있습니다 (예 : KLOC 당 평균 25 개의 결함이있는 그룹에서 결함이없는 200 줄의 코드를 검사하는 팀이 오작동 할 수 있음).

다른 측정 항목

다음에 대한 통계를 포함하는 데 도움이되는 기타 통계

• 추정 보정에 도움이되는 획득 한 가치
• Scrum 또는 Kanban을 사용하는 사람들을위한 속도 .
• 의 작품 파레토 , 주란 , Demming , 이시카와 품질과 산업 공학에서, 그리고 다른 상상의 약간의 소프트웨어 개발에 다소 휴대용입니다.

분석의 한계

지표의 가치에는 엄청난 한계가 있습니다. 개발자마다 수정 된 버그는 거의 모든 것을 의미 할 수 있으며, 해당 측정에 대해 처벌하거나 보상하기 시작하면 버그가 더 많고 세분화되며, 수정하기 어려운 어려운 버그의 조합도 팀 체리가 선택함에 따라 변경됩니다. 가장 많이 경주합니다.

또한 방해가되는 측정으로 인해주의가 산만 해지고 집중력과 즐거움이 상실 될 수 있습니다. Wordsworth 와 같은 호수 시인보다 훨씬 더 우아하고 감정적으로 부담을 느끼지 못합니다 .

      Sweet is the lore which Nature brings;
      Our meddling intellect
      Mis-shapes the beauteous forms of things:--
      We murder to dissect.

소프트웨어가 정확히 자연은 아니지만 고등학교 영문학 수업에서는 아무것도 사용하지 않을 것이라고 생각했기 때문에 위도를 알려주십시오.

애자일은 중앙 집중식 대규모 프로세스에 대한 반응으로 간주 될 수 있습니다. 때로는 해당 작업 모드에서 소프트웨어를 작성하는 동안 플로우 에 도달하는 기능이 사라지 도록 많은 분석 노력이 필요할 수 있습니다 .

필요에 따라 조정할 수있는 기본 도구를 훔치기 위해 표준 소프트웨어 엔지니어링 관행에서 다른 분야로 향하는 대안 적 답변을 추가하고 싶습니다. 품질 보증 사람들은 소프트웨어 개발자와 마찬가지로 생산, 생산량, 결함 감지 및 예방에 관심을 가지고 있습니다.

http://en.wikipedia.org/wiki/Seven_Basic_Tools_of_Quality

나는 관리도를 좋아한다.

http://en.wikipedia.org/wiki/Control_chart

활동, 메트릭 구성, 다른 작업 수행, 메트릭 구성 등을 수행하십시오. 예를 들어, 매일 플롯 커밋. 차트는 최소에서 최대까지 범위의 데이터를 분산시킵니다. 나중에 나중에 값을 낮게 설정하고 진행을 방해하고 너무 높으면 작업이 빠르고 느슨하게 시작된다고 판단하기 위해 결과를 특성화 할 수 있습니다. 근로자가 속도를 높이거나 늦추도록 격려하는 방법은 귀하에게 있습니다.

개인 측정 항목은 다음과 같은 질문에서 시작하여 "내가 가장 생산적이라고 느낀다"와 같은 질문으로 시작할 수 있습니다.

• 코딩을 시작하기 전에 완전한 사용 사례를 작성하십시오.
• 코드 전에 단위 테스트를 작성하십시오.
• 요구 사항이 변경되지 않도록 보장하기 위해 이해 관계자와 자주 확인하고 쓸모없는 계획을 위해 수행 한 작업에 대한 대규모 재 작업을 생성하십시오.
• 가능한 한 많은 코드를 변경하십시오.
• 내가 변경하도록 요청한 부분에 대해 가장 전문가 인 팀 구성원에게 잘 정의 된 변경 사항을 위임하십시오.
  • 우리 팀에게 완전한 개요를 제공하지만 우선 순위를두고 현재 스프린트에서 완료 할 수 있습니다.
  • 디렉토리, 파일, 클래스, 메소드, 방정식, 변수, 문서 등의 계층 목록으로 리팩토링 패스를 시작하십시오.
  • 더 나은 솔루션을 만드는 데 필요한 범위와 주요 개선 사항을 추정하여 선행 기술 솔루션을 찾기 위해 높은 수준의 문제를 연구하십시오.

우리가 측정 한 것은 과거에 수행 한 결과가 제한 요인으로 판단한 사항에 따라 문제를 공격 할 수 있다는 것을 알았습니다.

또는 파레토 다이어그램을 기반으로 우선 순위에 따라 여러 가지 요소가 있습니다.

http://en.wikipedia.org/wiki/Pareto_chart