컨텍스트 : 저는 모든 MS 상점의 엔터프라이즈 개발자입니다. 누구나 코드 또는 응용 프로그램의 유지 관리 성 을 객관적으로 측정 하는 좋은 방법을 추천 할 수 있습니까 ? 유지 관리 성 이유 : 그룹의 "품질"지표에 수 많은 버그와 코드 적용 범위 만 관련되어 있습니다. 특히 유지 관리 성을 측정하지 않는 경우 …
1977 년 Maurice Howard Halstead는 소프트웨어 시스템에 대한 복잡한 측정법을 소개했습니다 는 프로그램 어휘, 프로그램 길이, 볼륨, 난이도, 노력 및 모듈의 예상 버그 수를 측정하는 . Wikipedia에 따르면, 어려움은 프로그램을 읽거나 쓸 때 프로그램을 이해하는 어려움과 관련이 있으며 노력은 시간 = (노력 / 18) 초인 응용 프로그램을 코딩하는 데 걸리는 …
조직 내에서 코드 검토 프로세스를 도입했으며 제대로 작동하는 것 같습니다. 그러나 시간이 지남에 따라 프로세스의 효과를 측정 할 수 있기를 원합니다. 즉, 코드가 깨끗하거나 사람들이 버그를 찾지 않기 때문에 버그를 찾지 못하고 있습니까? 현재 효과적인 완전 자동화 테스트 프로세스가 없습니다. 우리는 주로 수동 테스트를 사용하므로이 단계에서 발견 된 결함에 의존하여 …
경영진이 리팩토링에 노력을 기울 이도록 설득하기위한 논쟁을 찾고 있습니다. Jira를 사용하여 작업을 기록하고 모든 svn-commit을 jira 호출과 관련시킵니다. 내 생각은 다음을 수행하는 것입니다. User-POV 및 Developer-POV (버그 수정) 모두에서 매우 잘못 구현되었지만 자주 사용되는 코드 영역을 수동으로 발견 JIRA- 문제가 포함 된 svn-commits 가져 오기 일부 기준 (문제 유형, 버전, …
다음은 SLIM 및 소프트웨어 추정과 관련하여 직장에서 교육 매뉴얼을 인용 한 것입니다. 노력과 결함 사이에는 상관 관계가 있습니다. 즉, 지정된 규모의 프로젝트에 더 많은 사람이 할당 될수록 더 많은 결함이 발생합니다. 노력은 프로젝트의 사람-시간 (사람-년, 사람-월)입니다. 결함은 수명주기의 어느 시점에서나 감지 된 결함의 수입니다. 크기는 프로젝트를 구성하는 사용 사례, 기능 …
폐쇄되었습니다 . 이 질문은 더 집중되어야 합니다. 현재 답변을받지 않습니다. 이 질문을 개선하고 싶습니까? 이 게시물 을 편집 하여 한 가지 문제에만 집중할 수 있도록 질문을 업데이트하십시오 . 휴일 3 년 전 . 소프트웨어 제품에서 측정 할 수있는 다양한 유형의 품질이 있습니다 (예 : 목적 적합성 (예 : 최종 사용), …