소프트웨어 품질

Software quality

소프트웨어 엔지니어링의 맥락에서 소프트웨어 품질은 관련되지만 서로 다른 [citation needed]두 가지 개념을 의미합니다.

  • 소프트웨어 기능 품질은 기능 요건 또는 [1]사양에 따라 주어진 설계를 얼마나 잘 준수하는지 반영합니다.이 속성은 소프트웨어의 목적에 대한 적합성 또는 가치 있는 [2]제품으로서 시장의 경쟁업체와 비교한 것으로도 설명할 수 있습니다.올바른 소프트웨어가 생산되는 정도를 말합니다.
  • 소프트웨어 구조품질이란 견고성이나 유지보수성 등의 기능요건의 전달을 지원하는 비기능요건을 충족하는 방법을 말합니다.이것은 소프트웨어가 필요에 따라 작동하는 정도와 훨씬 더 관련이 있습니다.

구조적 품질의 많은 면들이 소프트웨어 내부 구조의 분석만 정정을 통해 평가할 수 있도록, 유닛에 효과에 어떻게 볼 때, 아키텍처 소프트웨어 아키텍처의 소리 원리 준수한다 그것의 소스 코드(소프트웨어 계량을 보)[3], 시스템 레벨(때때로 엔드 투 엔드 testing[4]이라고 표현했다.), i.에 대해 설명했다법에 파파Object Management Group([5]OMG; 객체 관리 그룹)에 의한 토픽에 대해 설명합니다.

그러나 사용성과 같은 일부 구조적 품질은 동적으로만 평가할 수 있다(사용자나 다른 사용자가 소프트웨어 또는 적어도 일부 프로토타입 또는 부분 구현과 상호작용한다. 이러한 버전은 프로토타입으로 간주될 수 있기 때문에 골판지로 만든 모의 버전과의 상호작용도 동적 테스트를 나타낸다).신뢰성 등의 다른 측면에는 소프트웨어뿐만 아니라 기본 하드웨어도 포함될 수 있으므로 정적 및 동적(스트레스 테스트)[citation needed]으로 평가할 수 있습니다.

기능 품질은 일반적으로 동적으로 평가되지만 정적 테스트(소프트웨어 [citation needed]검토 등)를 사용할 수도 있습니다.

지금까지 소프트웨어 품질 관리에 적용되는 속성 및 지표의 구조, 분류 및 용어는 ISO 9126 및 후속 ISO/IEC 25000 표준에서 [6]파생되거나 추출되었습니다.이러한 모델(모델 참조)을 바탕으로 IT 소프트웨어 품질 컨소시엄(CISQ)은 소프트웨어가 비즈니스 가치를 제공하는 데 필요한 5가지 [7]바람직한 구조적 특성을 정의했습니다.신뢰성, 효율성, 보안, 유지보수성 및 (적절한) 크기.[8][9][10]

소프트웨어 품질 측정은 소프트웨어 프로그램 또는 시스템이 이들 5가지 차원에 따라 어느 정도 레이트를 산출하는지를 수치화합니다.소프트웨어 품질의 집계 척도는 질적 또는 정량적 스코어링 스킴 또는 양자의 조합과 우선순위를 반영한 가중치 시스템을 통해 계산될 수 있다.소프트웨어 품질이 선형 연속체에 위치한다는 이러한 견해는 특정 상황에서 치명적인 정지 또는 성능 저하를 초래할 수 있다는 "중요한 프로그래밍 오류" 분석에 의해 보완됩니다. 이 경우 집계된 측정에 기초한 등급에 관계없이 특정 시스템을 사용하기에 적합하지 않습니다.시스템 레벨에서 발견되는 이러한 프로그래밍 오류는 프로덕션 문제의 최대 90%를 나타내며, 유닛 레벨에서는 훨씬 더 많더라도 프로그래밍 오류가 프로덕션 문제의 10% 미만을 차지합니다(90-99 규칙 참조).따라서 W. Edwards Deming이 설명한 바와 같이 시스템 전체의 컨텍스트가 없는 코드 품질은 제한된 [citation needed]가치를 가집니다.

소프트웨어 품질 측정을 보고, 탐색하고, 분석하고, 전달하기 위해 정보 시각화의 개념과 기술은 특히 여러 소프트웨어 품질 측정이 서로 또는 소프트웨어 또는 시스템의 구성요소와 관련되어야 하는 경우에 유용한 시각적 대화형 수단을 제공합니다.예를 들어 소프트웨어 맵은 "소프트웨어 개발, 소프트웨어 품질 및 시스템 [11]역학에 대한 정보를 표현하고 결합할 수 있는" 전문화된 접근 방식을 나타냅니다.

소프트웨어 품질은 소프트웨어 프로젝트의 출시 단계에서도 중요한 역할을 합니다.구체적으로는 릴리스 프로세스의 품질과 확립(패치프로세스도 마찬가지),[12][13] 설정 관리는[14] 소프트웨어 엔지니어링 [15][16][17]프로세스 전체의 중요한 부분입니다.

동기

소프트웨어 품질은 적어도 다음 두 가지 주요 관점에 따라 결정됩니다.

  • 리스크 관리: 소프트웨어 장애는 불편함 이상의 것을 초래합니다.소프트웨어 오류로 인해 사망자가 발생할 수 있습니다(예: 소프트웨어 오류 목록 참조).원인은 설계 불량 사용자 인터페이스에서 직접 프로그래밍 [18][19][20]오류까지 다양합니다. 예를 들어 보잉 737 사례, 의도하지 않은 가속[21][22] 사례 또는 Therac-25 [23]사례를 참조하십시오.이로 인해 일부 유형의 소프트웨어 개발, 특히 의료용 및 기타 중요한 인프라스트럭처를 규제하는 기기에 내장된 소프트웨어에 대한 요구가 제기되었습니다.[임베디드 소프트웨어를 작성하는 엔지니어] Java 프로그램이 가비지 수집을 수행하고 사용자 인터페이스를 갱신하는 데 1/3초의 시간이 걸리는 것을 볼 수 있습니다.ce,[24] 그리고 그들은 하늘에서 비행기가 떨어지는 것을 상상한다."미국 연방항공청(FAA) 내에서 FAA 항공기 인증 서비스는 소프트웨어 프로그램, 정책, 지침 및 훈련을 제공하며, 공중 제품에 영향을 미치는 소프트웨어와 복잡한 전자 하드웨어에 초점을 맞추고 있습니다("제품"은 항공기, 엔진 또는 프로펠러입니다).[25]DO-178C, ISO 26262, IEC 62304 등과 같은 인증 표준은 지침을 제공합니다.
  • 비용 관리:엔지니어링의 다른 분야와 마찬가지로 우수한 소프트웨어 품질에 의해 관리되는 소프트웨어 제품 또는 서비스는 유지 비용이 적게 들고 이해하기 쉬우며 비즈니스 요구에 [26]따라 비용 효율이 향상될 수 있습니다.업계 데이터 원가, 일정 초과와 재작업(Muda 일본 용어를 보)의 형태로)폐기물을 만듭니다에서 핵심 사업 애플리케이션(기업 자원 계획(ERP 같은), 고객 관계 관리(CRM)또는 금융 서비스에 큰 거래 처리 시스템)에 가난한 응용 프로그램 구조적 품질 결과를 증명하고 있다.[27][28][29]또한 구조적 품질 저하는 데이터 손상, 애플리케이션 중단, 보안 침해 및 성능 [30]문제로 인한 높은 영향의 비즈니스 중단과 밀접한 관련이 있습니다.
    • CISQ의 저품질 비용 보고서는 다음과 같은 영향을 추정한다.
    • IBM의 데이터 침해 비용 보고서 2020은 데이터 [33][34]침해에 따른 평균 글로벌 비용을 다음과 같이 추정합니다.
      • 386만달러

정의들

ISO

소프트웨어 품질은 "요건에 [35][36]부합하는 소프트웨어 제품의 기능"이지만, 다른 소프트웨어 품질은 고객 또는 가치[37][38] 창출 또는 결함 [39]수준과 동의어가 될 수 있습니다.

ASQ

ASQ에서는 다음 정의를 사용합니다.소프트웨어 품질은 소프트웨어 제품의 바람직한 속성을 나타냅니다.두 가지 주요 접근법이 있습니다. 결함 관리와 품질 [40]속성입니다.

NIST

소프트웨어 어슈어런스(SA)는 자산과 [41]이를 달성하기 위한 프로세스를 모두 커버합니다.

  • [정당성] 소프트웨어에 의도적으로 설계되거나 라이프 사이클 중에 실수로 삽입된 취약점이 없으며 소프트웨어가 의도한 대로 기능한다는 확신
  • 소프트웨어 라이프 사이클 프로세스 및 제품이 요건, 표준 및 절차에 적합하도록 계획되고 체계적인 일련의 활동

PMI

Project Management Institute의 PMBOK Guide의 "소프트웨어 확장"은 "소프트웨어 품질" 자체가 아니라 "소프트웨어 품질 보증(SQA)"을 "다른 소프트웨어 프로세스를 감사하여 이러한 프로세스가 준수되고 있는지 확인하는 지속적인 프로세스(소프트웨어 품질 관리 계획 등)"로 정의하고 있습니다.반면 소프트웨어 품질관리(SCQ)는 "개발 또는 [42]수정 중인 소프트웨어의 품질요건에 대해 작업제품의 만족을 보장하기 위한 방법, 도구, 기술을 적용하는 것"을 의미합니다.

기타 일반 및 이력

품질 역사에 대한 첫 번째 정의는 20세기 초의 쉐하트에서 나온 것입니다. "질에는 두 가지 공통적인 측면이 있습니다. 하나는 인간의 존재로부터 독립된 객관적인 현실로서 사물의 품질을 고려하는 것과 관련이 있습니다. 다른 하나는 객관적인 현실의 결과로서 우리가 생각하고 느끼고 느끼는 것과 관련이 있다. 즉,[43] 품질에는 주관적인 측면이 있습니다."

Kitchenham과 Pfleeger는 David Garvin의 가르침을 자세히 보고하면서 [44][45]품질에 대한 5가지 관점을 파악합니다.

  • 초월적 관점은 품질의 형이상학적 측면을 다룬다.이러한 품질에 대한 견해에서는, 「이상으로서 노력하지만,[46] 결코 완전하게 실시하지 않는 것」입니다.그것은 거의 정의될 수 없지만, 연방 판사가 외설성에 대해 언급했던 것과 유사하다: "나는 그것을 볼 때 그것을 안다."[47]
  • 사용자의 관점은 주어진 사용 상황에 대한 제품의 적절성과 관련이 있습니다.초월적 관점은 천상적인 반면, 사용자 관점은 사용자의 [46]요구를 충족하는 제품 특성에 따라 보다 구체적입니다.
  • 제조의 관점에서는, 품질은 요건에의 준거로서 표현됩니다.품질의 이러한 측면은 ISO 9001과 같은 표준에 의해 강조되며, ISO 9001은 품질을 "일련의 고유한 특성이 요건을 충족하는 정도"로 정의한다(ISO[48]/IEC 9001).
  • 제품의 관점은 제품의 고유한 특성을 측정함으로써 품질을 평가할 수 있음을 의미합니다.
  • 품질에 대한 마지막 관점은 가치 기반입니다.[37]이러한 관점은 품질에 대한 다양한 관점이 다양한 이해관계자들에게 다른 중요성 또는 가치를 가질 수 있다는 것을 인식한다.

거의 모든 제품의 품질을 정의하려는 시도에 내재된 문제는 마스터 Walter A에 의해 언급되었습니다.쉬와트.품질 정의의 어려움은 사용자의 미래 요구를 측정 가능한 특성으로 변환하여 사용자가 지불하는 가격으로 만족할 수 있도록 제품을 설계하고 제작하는 것입니다.이것은 쉽지 않고, 그 노력이 꽤 성공적이었다고 느끼는 순간, 그는 소비자의 요구가 변화하고 경쟁사가 진출했다는 것을 알게 된다.[49]

--

품질은 고객의 결정이지 엔지니어의 결정도 마케팅 결정도 일반적인 경영진의 결정도 아닙니다.이는 고객의 제품 또는 서비스에 대한 실제 경험을 바탕으로 고객의 요구 사항(명언 또는 미발표, 의식 또는 단순한 감지, 기술적 운용 또는 전적으로 주관적)과 비교하여 평가되며 항상 경쟁 [50]시장에서 움직이는 타깃을 나타냅니다.

품질이라는 단어에는 여러 가지 의미가 있습니다.이들 중 두 가지 의미가 가장 많이 사용됩니다. 1. 품질은 고객의 요구를 충족시켜 제품 만족도를 제공하는 제품 특징으로 구성됩니다. 2. 품질은 결점으로부터 자유로움으로 구성됩니다.그럼에도 불구하고, 이와 같은 핸드북에서는 "사용 [51]적합도"라는 단어의 품질을 간략하게 정의하여 표준화하는 것이 편리하다.

Tom DeMarco는 "제품의 품질은 세상을 얼마나 더 [citation needed]좋게 변화시키느냐의 함수"라고 제안했습니다.이는 소프트웨어 품질을 결정할 때 구조적 품질보다 기능적 품질과 사용자 만족도가 더 중요하다는 의미로 해석된다.

Quality Software Management의 Gerald Weinberg가 만든 또 다른 정의는 다음과 같습니다.'[52][53]시스템 사고'는 '품질은 사람에게 가치가 있다'는 것입니다.이 정의에서는 품질은 본질적으로 주관적이라는 점을 강조합니다. 즉, 사람마다 동일한 소프트웨어의 품질을 다르게 경험하게 됩니다.이 정의의 강점 중 하나는 소프트웨어 팀이 검토하도록 유도하는 질문입니다.예를 들어, 「소프트웨어의 가치를 중시하는 사람은 누구입니까?」, 「소프트웨어에게 있어서 무엇이 중요합니까?」 등입니다.

다른 의미와 논란

품질을 정의할 때의 과제 중 하나는 "모두가 [54]이해하고 있다고 느낀다"는 것입니다.또, 소프트웨어 품질의 정의는, 비즈니스에서 사용되는 품질의 개념의 다양한 설명에 근거할 수 있습니다.

또한 소프트웨어 품질은 종종 품질 보증 또는 문제[55] 해결 관리, 품질[56] 관리 또는 DevOps와 혼동됩니다.앞서 언급한 영역(PMI 정의 참조)과 오버랩을 수행하지만 테스트뿐만 아니라 프로세스, 관리, 개선, 평가 [56]등에 초점을 맞추고 있다는 점에서 독특합니다.

측정.

이 섹션에 제시된 개념은 구조 및 기능 소프트웨어 품질에 모두 적용 가능하지만, 후자의 측정은 기본적으로 테스트를 통해 수행됩니다(메인 기사 참조:소프트웨어 테스트][57]그러나 테스트만으로는 충분하지 않습니다.연구에 따르면, 개별 프로그래머는 자신의 소프트웨어에서 버그를 찾는 데 50% 미만이 효율적이라고 합니다.대부분의 테스트 형태는 효율이 35%에 불과합니다.이 때문에 [소프트웨어][58]의 품질을 판단하기가 어렵습니다.

서론

소프트웨어의 바람직한 특성(오른쪽)과 측정 가능한 속성(왼쪽)의 관계.

소프트웨어 품질 측정은 시스템 또는 소프트웨어가 바람직한 특성을 어느 정도 가지고 있는지를 수량화하는 것입니다.이는 정성적 또는 정량적 수단 또는 두 가지 방법을 혼합하여 수행할 수 있습니다.어느 경우든 바람직한 각 특성에 대해 소프트웨어 또는 시스템에 존재하는 것이 이 특성과 관련지어지는 경향이 있는 일련의 측정 가능한 속성이 있습니다.예를 들어, 휴대성과 관련된 속성은 프로그램 내의 타겟 의존 문장의 수입니다.보다 정확하게는, 이러한 측정 가능한 속성은, 상기의 소프트웨어 품질 정의의 「와트」를 유효하게 하기 위해서 필요한 「방법」입니다.

소프트웨어 품질 관리에 적용되는 속성 및 지표의 구조, 분류 및 용어는 ISO 9126-3 및 후속 ISO/IEC 25000:2005 품질 모델에서 파생 또는 추출되었습니다.주된 초점은 내부 구조 품질이다.하위 범주는 비즈니스 애플리케이션 아키텍처와 같은 특정 영역과 데이터 액세스 및 조작 또는 트랜잭션 개념과 같은 기술적 특성을 처리하기 위해 생성되었습니다.

소프트웨어 품질 특성과 측정 가능한 속성 간의 의존 트리는 오른쪽 그림에 나타나 있습니다.여기서 비즈니스 시스템의 사용자(오른쪽) 또는 소유자에게 중요한 5가지 특성은 각각 측정 가능한 속성(왼쪽)에 의존합니다.

  • 응용 프로그램아키텍처 프랙티스
  • 코딩 프랙티스
  • 응용 프로그램의 복잡성
  • 문서
  • 휴대성
  • 기술 및 기능 볼륨

프로그래밍 오류와 프로덕션 결함 간의 상관 관계를 통해 소스 코드의 전체 오류 중 기본 코드 오류가 92%를 차지함을 알 수 있습니다.이러한 코드 레벨의 문제는, 최종적으로 실가동시의 결함의 10%에 지나지 않습니다.아키텍처 레벨의 불량 소프트웨어 엔지니어링 관행은 전체 결함의 8%에 불과하지만 문제를 수정하는 데 드는 작업의 절반 이상이 소요되며,[59][60] 이로 인해 프로덕션에서 심각한 신뢰성, 보안 및 효율성 문제가 90%에 달합니다.

코드 기반 분석

기존 소프트웨어 측정의 대부분은 이러한 개별 명령[61][62] 토큰 제어 구조(복잡도) 및 [63]객체의 소스 코드를 구문 분석하여 발생하는 응용 프로그램의 구조적 요소를 카운트합니다.

소프트웨어 품질 측정은 시스템 또는 소프트웨어가 이러한 치수에 따라 어느 정도 속도를 산출하는지 수량화하는 것입니다.분석은 정성적 또는 정량적 접근법 또는 두 가지 방법을 혼합하여 수행할 수 있다(예: 측정하는 요인 간의 상대적 중요성을 반영하는 가중 평균 사용).

선형 연속체의 소프트웨어 품질에 대한 이러한 견해는 이산적인 중요 프로그래밍 오류를 식별하여 보완해야 합니다.이러한 취약성,지만 특수 상황에서 주어진 시스템 사실상 사용에 상관 없이가 집계된 meas에 기반하여 부적당하게 만든 정지, 성능 저하, 보안 사고 손상된 데이터 및 각종 problems[64]을 일으킬 수 있는 나쁜 관행의 결과는 시험 사례 실패하지 않을 수 있다.ure취약성의 잘 알려진 예로는 응용 프로그램을 보안 침해에 노출시키는 소스 코드의 취약성의 저장소인 Common Ph약점 [65]열거가 있습니다.

중요한 애플리케이션 특성 측정에는 위 그림과 같이 애플리케이션 아키텍처, 코딩 및 인라인 문서의 구조적 특성 측정이 포함됩니다.따라서 각 특성은 어플리케이션의 다양한 추상화 수준에서 속성의 영향을 받으며, 비즈니스에 영향을 미치는 품질 결과의 귀중한 예측 변수가 되려면 특성 측정값을 계산하는 모든 속성을 포함해야 합니다.위 그림에 표시된 특성 측정치를 계산하기 위한 계층적 접근법은 TRW(Boehm, 1978년)[66]에서 Boehm과 그의 동료들에 의해 처음 제안되었으며 ISO 9126 및 25000 시리즈 표준에서 채택된 접근법이다.이러한 속성은 응용 프로그램 소스 코드의 정적 분석의 구문 분석 결과에서 측정할 수 있습니다.신뢰성과 성능 효율과 같은 애플리케이션의 동적 특성도 애플리케이션의 정적 구조에 원인이 있습니다.

구조품질분석 및 측정은 시스템의 개념적 및 논리적 아키텍처를 함께 정의하는 원칙과 표준에 대한 소스 코드, 아키텍처, 소프트웨어 프레임워크, 데이터베이스 스키마의 분석을 통해 수행됩니다.이는 디버깅 및 테스트 활동에서 가장 중요한 구현 고려사항과 관련된 개발 도구에 의해 일반적으로 수행되는 기본 로컬 코드 분석과는 다릅니다.

신뢰성.

신뢰성 저하의 근본 원인은 우수한 아키텍처 및 코딩 프랙티스와 호환되지 않는 데서 찾을 수 있습니다.이 부적합은 애플리케이션의 정적 품질 속성을 측정하여 검출할 수 있습니다.애플리케이션의 신뢰성의 기초가 되는 정적 속성을 평가하면 비즈니스 리스크의 수준과 애플리케이션을 운용할 때 발생할 수 있는 잠재적인 애플리케이션 장애 및 결함의 가능성을 예측할 수 있습니다.

신뢰성을 평가하려면 적어도 다음 소프트웨어 엔지니어링의 베스트 프랙티스와 기술적 속성을 확인해야 합니다.

  • 응용 프로그램아키텍처 프랙티스
  • 코딩 프랙티스
  • 알고리즘의 복잡성
  • 프로그래밍 관행의 복잡성
  • 객체 지향 및 구조화 프로그래밍의 베스트 프랙티스 준수(해당하는 경우)
  • 컴포넌트 또는 패턴 재사용률
  • 지저분한 프로그래밍
  • 오류 및 예외 처리 (모든 레이어 - GUI, 로직 및 데이터)
  • 멀티레이어 설계 컴플라이언스
  • 자원 한계 관리
  • 소프트웨어는 예기치 않은 동작을 일으키는 패턴을 회피한다.
  • 소프트웨어로 데이터 무결성 및 일관성 관리
  • 트랜잭션 복잡도 수준

애플리케이션 아키텍처 및 사용하는 서드파티제 컴포넌트(외부 라이브러리나 프레임워크 등)에 따라 위의 베스트 프랙티스 목록에 따라 커스텀 체크를 정의하여 제공된 소프트웨어의 신뢰성을 보다 정확하게 평가할 수 있도록 해야 합니다.

효율성.

신뢰성과 마찬가지로 성능 비효율의 원인은 애플리케이션의 정적 품질 속성을 측정함으로써 탐지할 수 있는 우수한 아키텍처 및 코딩 관행을 위반하는 데서 종종 발견됩니다.이러한 정적 속성은 특히 복잡한 알고리즘이나 대량의 데이터를 처리하기 위해 빠른 실행 속도를 필요로 하는 애플리케이션의 경우 잠재적인 운영 성능 병목 현상 및 미래의 확장성 문제를 예측합니다.

퍼포먼스 효율을 평가하려면 적어도 다음 소프트웨어 엔지니어링의 베스트 프랙티스와 기술적 속성을 체크해야 합니다.

  • 응용 프로그램아키텍처 프랙티스
  • 비용이 많이 드는 자원 및/또는 리모트 자원과의 적절한 상호작용
  • 데이터 액세스 퍼포먼스 및 데이터 관리
  • 메모리, 네트워크 및 디스크 공간 관리
  • 코딩[67] 프랙티스 준수(베스트 코딩 프랙티스)

보안.

소프트웨어 품질에는 소프트웨어 [68]보안이 포함됩니다.많은 보안 취약성은 SQL 주입이나 사이트 간 [69][70]스크립팅과 같은 잘못된 코딩 및 아키텍처 관행으로 인해 발생합니다.이는 [71]CWE와 카네기 멜론 [67]대학의 SEI/컴퓨터 긴급센터(CERT)가 관리하는 목록에 잘 기록되어 있습니다.

보안을 평가하려면 적어도 다음 소프트웨어 엔지니어링의 베스트 프랙티스와 기술적 속성을 확인해야 합니다.

  • 보안 인식 및 강화 개발 프로세스(예: 보안 개발 수명 주기(Microsoft) 또는 IBM의 Secure Engineering Framework)[72]의 구현, 관리
  • 안전한 애플리케이션 아키텍처[73][74] 프랙티스
  • 멀티레이어 설계 컴플라이언스
  • 보안 베스트 프랙티스(입력 검증, SQL 주입, 사이트 간 스크립팅, 액세스 제어 등)[75][76]
  • 안전하고 양호한 프로그래밍[67] 프랙티스
  • 오류 및 예외 처리

유지 보수성

유지보수성에는 모듈성, 이해성, 변경성, 테스트성, 재사용성 및 개발팀 간 전송성의 개념이 포함됩니다.이것들은 코드 레벨에서는 중대한 문제의 형태를 취하고 있지 않습니다.유지보수가 잘 되지 않는 것은 일반적으로 문서화의 베스트 프랙티스, 복잡성 회피 전략, 기본적인 프로그래밍 프랙티스에 의한 수천 건의 사소한 위반으로 인해 발생합니다.이러한 위반은 깨끗하고 읽기 쉬운 코드와 비조직적이고 읽기 어려운 [77]코드를 구별합니다.

유지보수성을 평가하려면 다음 소프트웨어 엔지니어링의 베스트 프랙티스와 기술적 속성을 확인해야 합니다.

  • 응용 프로그램아키텍처 프랙티스
  • 소스 코드에 내장된 아키텍처, 프로그램 및 코드 문서
  • 코드 가독성
  • 코드 냄새
  • 트랜잭션의 복잡성 수준
  • 알고리즘의 복잡성
  • 프로그래밍 관행의 복잡성
  • 객체 지향 및 구조화 프로그래밍의 베스트 프랙티스 준수(해당하는 경우)
  • 컴포넌트 또는 패턴 재사용률
  • 동적 코딩의 제어 수준
  • 결합비율
  • 지저분한 프로그래밍
  • 문서
  • 하드웨어, OS, 미들웨어, 소프트웨어 컴포넌트 및 데이터베이스 독립성
  • 멀티레이어 설계 컴플라이언스
  • 휴대성
  • 프로그래밍 프랙티스(코드 레벨)
  • 중복 코드 및 기능 감소
  • 소스 코드 파일 구성 청결도

유지관리성은 유지관리성 부족으로 인한 비용 표현인 Ward Cunningham의 기술 부채 개념과 밀접하게 관련되어 있습니다.유지관리성이 낮은 이유는 무모함, 신중함, 신중함, 고의성,[78] 부주의함 등으로 분류할 수 있으며, 그 원인은 개발자의 무능력, 시간과 목표의 부족, 문서 작성 비용과 문서 작성의 이익의 불일치, 특히 유지관리 [79]가능한 소스코드에 기인하는 경우가 많다.

크기

소프트웨어 크기를 측정하려면 데이터베이스 구조 스크립트, 데이터 조작 소스 코드, 컴포넌트 헤더, 구성 파일 등을 포함한 전체 소스 코드를 올바르게 수집해야 합니다.측정하는 소프트웨어 크기에는 기본적으로 기술 크기(풋프린트)와 기능 크기라는 두 가지 유형이 있습니다.

  • 소프트웨어 기술 사이징 방법에는 여러 가지가 있습니다.가장 일반적인 기술적 사이징 방법은 기술별 코드 행 수(#LOC), 파일 수, 함수 수, 클래스, 테이블 등이며, 여기서 백파이어 기능 포인트를 계산할 수 있습니다.
  • 기능 크기를 측정하는 데 가장 일반적인 것은 기능점 분석입니다.기능점 분석은 사용자의 관점에서 제공되는 소프트웨어의 크기를 측정합니다.기능 포인트 사이징은 사용자 요건에 따라 이루어지며 개발자/견적자의 크기와 가치(제공해야 할 기능)를 모두 정확하게 나타내며 고객에게 제공되는 비즈니스 기능을 반영합니다.이 방법에는 사용자가 인식할 수 있는 입력, 출력 및 데이터 저장소의 식별과 가중치가 포함된다.다음으로 소프트웨어 배포와 퍼포먼스를 정량화하고 평가하기 위한 다양한 척도와 함께 사용할 수 있습니다(기능 포인트당 개발 비용, 기능 포인트당 전달 결함 수, 직원 월당 기능 포인트 수).

기능점 분석 크기 표준은 International Function Point Users Group(IFPUG)에서 지원합니다.소프트웨어 개발 라이프 사이클 초기에 적용할 수 있으며 다소 부정확한 Backfireing 방법처럼 코드 행에 의존하지 않습니다.이 방법은 기술에 구애받지 않고 조직 간 및 업계 간 비교 분석에 사용할 수 있습니다.

Function Point Analysis가 시작된 이후 여러 가지 변형이 발전하여 COSMIC, NESMA, Use Case Points, FP Lite, Early 및 Quick FP, 그리고 가장 최근의 Story Points와 같은 사이징 척도가 포함되도록 기능 크기 조정 기법 패밀리가 확장되었습니다.그러나 기능점은 통계적 정확성의 역사를 가지고 있으며, 수많은 애플리케이션 개발 관리(ADM) 또는 아웃소싱 작업에서 공통적인 작업 측정 단위로 사용되어 왔으며, 서비스를 제공하고 성능을 측정하는 "통화" 역할을 해 왔습니다.

Function Point 방법론의 공통적인 제약 중 하나는 수동 프로세스이기 때문에 애플리케이션 개발이나 아웃소싱 계약 등의 대규모 이니셔티브에서 많은 노동력과 비용이 소요될 수 있다는 것입니다.이 방법론을 적용하는 데 있어서 이러한 부정적인 측면이 IT 리더들이 소프트웨어 크기 측정을 자동화하기 위한 계산 가능한 메트릭스 표준을 도입하는 데 중점을 두고 IT 소프트웨어 품질 컨소시엄을 구성하도록 동기 부여한 것일 수 있습니다. IFPUG는 대부분의 활동이 FP 카운터 인증에 의존하고 있기 때문에 수동 접근방식을 계속 추진하고 있습니다.

CISQ에서는 비용 견적, 진척 상황 추적 또는 기타 관련 소프트웨어 프로젝트 관리 활동을 지원하는 소프트웨어의 크기를 추정하기 위해 사이징을 정의합니다.다음 두 가지 표준이 사용됩니다.소프트웨어의 기능 크기를 측정하는 Automated Function Points와 기능 코드와 기능하지 않는 코드의 크기를 한 번에 [80]측정하는 Automated Enhancement Points.

중요한 프로그래밍 오류 식별

Critical Programming Errors(중요한 프로그래밍 오류)는 즉시 또는 장기적으로 가장 높은 비즈니스 중단 [81]위험을 초래하는 특정 아키텍처 및/또는 코딩의 잘못된 관행입니다.

이는 기술과 관련된 경우가 많고 컨텍스트, 비즈니스 목표 및 리스크에 따라 크게 달라집니다.명명 규칙을 존중하는 사람이 있는가 하면 지식 이전을 위한 기반을 마련하는 사람 등 명명 규칙을 절대적으로 중요하게 여기는 사람도 있습니다.

CISQ 특성별로 중요한 프로그래밍 오류를 분류할 수도 있습니다.다음 기본 예:

  • 신뢰성.
    • 예기치 않은 동작을 일으키는 소프트웨어 패턴(미초기 변수, 늘 포인터 등)을 피합니다.
    • 삽입, 업데이트, 삭제, 테이블 생성 또는 선택을 수행하는 방법, 절차 및 기능에는 오류 관리가 포함되어야 합니다.
    • 멀티 스레드 함수는 스레드 안전성을 유지해야 합니다. 예를 들어 서블릿 또는 스트럿 작업 클래스에는 인스턴스/비최종 정적 필드가 없어야 합니다.
  • 효율성.
    • 클라이언트 요구(수신 및 데이터)를 집중 관리하여 네트워크 트래픽을 줄입니다.
    • 루프의 큰 테이블에 대해 인덱스를 사용하지 않는 SQL 쿼리 회피
  • 보안.
    • 최종 정적이 아닌 서블릿 클래스의 필드 피하기
    • 오류 관리를 포함하지 않고 데이터 액세스 방지
    • 컨트롤 리턴 코드를 점검하고 오류 처리 메커니즘을 구현하십시오.
    • 사이트 간 스크립팅 결함 또는 SQL 주입 결함을 방지하기 위해 입력 유효성 검사 확인
  • 유지 보수성
    • 이해도를 높이기 위해 깊은 상속 트리와 중첩을 피해야 합니다.
    • 모듈(팬아웃, 중간)은 변경 전파를 방지하기 위해 느슨하게 결합되어야 합니다.
    • 동종 명명 규칙 적용

운용 가능한 품질 모델

스칼레 및 콰모코와[82] 같은 품질 모델에 대한 새로운 제안은 품질 속성과 측정의 정의에 대한 직접적인 통합을 전파한다.품질 속성을 분석하거나 추가 레이어를 정의함으로써 복잡하고 추상적인 품질 속성(신뢰성 또는 유지보수성 등)을 보다 쉽게 관리하고 측정할 수 있게 됩니다.그러한 품질 모델은 산업적 맥락에서 적용되었지만 널리 채택되지는 않았다.

트리비아

  • "과학은 측정 [83]도구만큼 성숙합니다."
  • "그걸 보면 알아"
  • 측정할 [7]수 없는 것은 제어할 수 없다.(톰 드마르코)
  • 제품의 품질을 검사할 수 없습니다.(W. Edwards Deming)[84]
  • 품질 저하로 인한 쓴맛은 일정준수의 달콤함을 잊은 지 오래다.(익명)[84]
  • "스펙부터 시작하지 않으면 쓰는 모든 코드는 패치입니다."(Leslie Lamport)

「 」를 참조해 주세요.

추가 정보

  • UI, 보안 등의 체크리스트를 포함한 Android OS 품질 가이드라인2021년 7월
  • 해양정보통신관리자협회(AMMITEC)해상 소프트웨어 품질 가이드라인2017년 9월
  • Capers Jones and Olivier Bonsignour, "The Economics of Software Quality", Addison-Wesley Professional, 제1판, 2011년 12월 31일 ISBN978-0-13-258220-9
  • CAT Lab - CNES 코드 분석 도구 연구소 (GitHub)
  • Girish Suryanarayana, 소프트웨어 프로세스와 설계 품질:줄다리기?[85]
  • 정호원, 김승권, 정창신.소프트웨어 제품 품질 측정: ISO/IEC 9126에 관한 조사.IEEE 소프트웨어, 21(5): 10 ~13, 2004년9월/10월
  • 국제 표준화 기구소프트웨어 엔지니어링 - 제품 품질 - 파트 1: 품질 모델ISO, 스위스 제네바, 2001.ISO/IEC 9126-1:2001(E)
  • 소프트웨어 제품 품질 측정: ISO 25000 시리즈 및 CMMI (SEI 사이트)
  • MSQF - 측정 기반의 소프트웨어 품질 프레임워크 Cornell University Library
  • Omar Alshathry, Helge Janicke, "Optimizing Software Quality Assurance", compsacw, 페이지 87~92, 2010 IEEE 제34회 컴퓨터 소프트웨어 및 애플리케이션 컨퍼런스 워크샵, 2010.
  • 로버트 L. 글래스빌딩 품질 소프트웨어프린티스 홀, 어퍼 새들 리버, 1992년 뉴저지 주
  • Roland Petrasch, "소프트웨어 품질의 정의: 실용적인 접근", ISSRE, 1999
  • 소프트웨어 품질 전문가,[86] 미국 품질 협회(ASQ)
  • Software Quality Journal[87] by Springer Nature
  • Spinellis, Diomidis (2006-04-04). Code quality: the open source perspective. Upper Saddle River, New Jersey, US: Addison-Wesley Professional. ISBN 978-0-321-16607-4.
  • 스티븐 H. 칸소프트웨어 품질 엔지니어링의 메트릭과 모델.애디슨-웨슬리, 보스턴, 매사추세츠, 제2판, 2002년
  • 스테판 바그너.소프트웨어 제품 품질 관리스프링거, 2013년

레퍼런스

메모들

  1. ^ Board (IREB), International Requirements Engineering. "Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine". Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine. Retrieved 2021-02-25.
  2. ^ Pressman, Roger S. (2005). Software Engineering: A Practitioner's Approach (Sixth International ed.). McGraw-Hill Education. p. 388. ISBN 0071267824.
  3. ^ "About the Automated Source Code Quality Measures Specification Version 1.0". www.omg.org. Retrieved 2021-02-25.
  4. ^ "How to Perform End-to-End Testing". smartbear.com. Retrieved 2021-02-25.
  5. ^ "How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations" (PDF). Archived (PDF) from the original on 2013-12-28. Retrieved 2013-10-18.
  6. ^ 14:00-17:00. "ISO/IEC 25010:2011". ISO. Retrieved 2021-02-23.{{cite web}}: CS1 maint: 숫자 이름: 작성자 목록(링크)
  7. ^ a b Armour, Phillip G. (2012-06-01). "A measure of control". Communications of the ACM. 55 (6): 26–28. doi:10.1145/2184319.2184329. ISSN 0001-0782. S2CID 6059054.
  8. ^ Voas, J. (November 2011). "Software's secret sauce: the "-ilities" [software quality]". IEEE Software. 21 (6): 14–15. doi:10.1109/MS.2004.54. ISSN 1937-4194.
  9. ^ "Code Quality Standards CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Retrieved 2021-02-25.
  10. ^ "Software Sizing Standards CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Retrieved 2021-02-25.
  11. ^ J. Bohnet, J. Dölner, 2014-04-27 Wayback Machine에 보관된 "소프트웨어 맵에 의한 코드 품질 및 개발 활동 모니터링"기술 채무 관리에 관한 IEEE ACM ICSE 워크숍 진행, 2011년 9-16페이지.
  12. ^ "IIA - Global Technology Audit Guide: IT Change Management: Critical for Organizational Success". na.theiia.org. Retrieved 2021-02-26.{{cite web}}: CS1 maint :url-status (링크)
  13. ^ Boursier, Jérôme (2018-01-11). "Meltdown and Spectre fallout: patching problems persist". Malwarebytes Labs. Retrieved 2021-02-26.
  14. ^ mestew. "Best practices for software updates - Configuration Manager". docs.microsoft.com. Retrieved 2021-02-26.
  15. ^ Wright, Hyrum K. (2009-08-25). "Release engineering processes, models, and metrics". Proceedings of the Doctoral Symposium for ESEC/FSE on Doctoral Symposium. ESEC/FSE Doctoral Symposium '09. Amsterdam, The Netherlands: Association for Computing Machinery: 27–28. doi:10.1145/1595782.1595793. ISBN 978-1-60558-731-8. S2CID 10483918.
  16. ^ van der Hoek, André; Hall, Richard S.; Heimbigner, Dennis; Wolf, Alexander L. (November 1997). "Software release management". ACM SIGSOFT Software Engineering Notes. 22 (6): 159–175. doi:10.1145/267896.267909. ISSN 0163-5948.
  17. ^ Moore, Mike Sutton and Tym (2008-07-30). "7 Ways to Improve Your Software Release Management". CIO. Retrieved 2021-02-26.
  18. ^ Clark, Mitchell (2021-02-24). "iRobot says it'll be a few weeks until it can clean up its latest Roomba software update mess". The Verge. Retrieved 2021-02-25.
  19. ^ "Top 25 Software Errors SANS Institute". www.sans.org. Retrieved 2021-02-25.
  20. ^ "'Turn it Off and On Again Every 149 Hours' Is a Concerning Remedy for a $300 Million Airbus Plane's Software Bug". Gizmodo. Retrieved 2021-02-25.
  21. ^ Software, Gimpel. "MISRA C, Toyota and the Death of Task X". Retrieved 2021-02-25.
  22. ^ "An Update on Toyota and Unintended Acceleration « Barr Code". embeddedgurus.com. Retrieved 2021-02-25.
  23. ^ 의료 기기: The rac-25* 2008-02-16 Washington 대학교 Nancy Levson의 Wayback Machine에서 아카이브 완료 2008-02-16
  24. ^ 임베디드 소프트웨어 2010-07-05 Wayback Machine, Edward A에서 아카이브.Lee, 컴퓨터의 진보 (Marvin Victor Zelkowitz 편집자), 제56권, Academic Press, London, 2002, UCB ERL 메모 M01/26 캘리포니아 대학교 버클리, CA 94720, 미국, 2001년 11월 1일 개정
  25. ^ "Aircraft Certification Software and Airborne Electronic Hardware". Archived from the original on 4 October 2014. Retrieved 28 September 2014.
  26. ^ "The Cost of Poor Software Quality in the US: A 2020 Report CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Retrieved 2021-02-25.
  27. ^ "What is Waste? Agile Alliance". Agile Alliance . Retrieved 2021-02-25.
  28. ^ January 26, Scott Matteson in Software on; 2018; Pst, 7:54 Am. "Report: Software failure caused $1.7 trillion in financial losses in 2017". TechRepublic. Retrieved 2021-02-25.{{cite web}}: CS1 maint: 숫자 이름: 작성자 목록(링크)
  29. ^ Cohane, Ryan (2017-11-16). "Financial Cost of Software Bugs". Medium. Retrieved 2021-02-25.
  30. ^ Eloff, Jan; Bella, Madeleine Bihina (2018), "Software Failures: An Overview", Software Failure Investigation, Cham: Springer International Publishing, pp. 7–24, doi:10.1007/978-3-319-61334-5_2, ISBN 978-3-319-61333-8, retrieved 2021-02-25
  31. ^ "Poor software quality cost businesses $2 trillion last year and put security at risk". CIO Dive. Retrieved 2021-02-26.
  32. ^ "Synopsys-Sponsored CISQ Research Estimates Cost of Poor Software Quality in the US $2.08 Trillion in 2020". finance.yahoo.com. Retrieved 2021-02-26.
  33. ^ "What Does a Data Breach Cost in 2020?". Digital Guardian. 2020-08-06. Retrieved 2021-03-08.
  34. ^ "Cost of a Data Breach Report 2020 IBM". www.ibm.com. 2020. Retrieved 2021-03-08.{{cite web}}: CS1 maint :url-status (링크)
  35. ^ "ISO - ISO 9000 family — Quality management". ISO. Retrieved 2021-02-24.
  36. ^ 14:00-17:00. "ISO/IEC/IEEE 24765:2017". ISO. Retrieved 2021-02-24.{{cite web}}: CS1 maint: 숫자 이름: 작성자 목록(링크)
  37. ^ a b "Mastering automotive software McKinsey". www.mckinsey.com. Retrieved 2021-02-25.
  38. ^ 14:00-17:00. "ISO/IEC 25010:2011". ISO. Retrieved 2021-02-24.{{cite web}}: CS1 maint: 숫자 이름: 작성자 목록(링크)
  39. ^ Wallace, D.R. (2002). "Practical software reliability modeling". Proceedings 26th Annual NASA Goddard Software Engineering Workshop. Greenbelt, MD, USA: IEEE Comput. Soc: 147–155. doi:10.1109/SEW.2001.992668. ISBN 978-0-7695-1456-7. S2CID 57382117.
  40. ^ "What is Software Quality? ASQ". asq.org. Retrieved 2021-02-24.
  41. ^ "SAMATE - Software Assurance Metrics And Tool Evaluation project main page". Nist. 3 February 2021. Retrieved 2021-02-26.
  42. ^ Software extension to the PMBOK guide. Project Management Institute (5th ed.). Newtown Square, Pennsylvania. 2013. ISBN 978-1-62825-041-1. OCLC 959513383.{{cite book}}: CS1 유지보수: 기타 (링크)
  43. ^ SHEWHART, WALTER A. (2015). Economioc control of quality of manufactured product. [Place of publication not identified]: MARTINO FINE Books. ISBN 978-1-61427-811-5. OCLC 1108913766.
  44. ^ Kitchenham, B.; Pfleeger, S. L. (January 1996). "Software quality: the elusive target [special issues section]". IEEE Software. 13 (1): 12–21. doi:10.1109/52.476281. ISSN 1937-4194.
  45. ^ Garvin, David A. (1988). Managing quality : the strategic and competitive edge. New York: Free Press. ISBN 0-02-911380-6. OCLC 16005388.
  46. ^ a b B. Kitchenham 및 S. Pfleeger, "소프트웨어 품질: 이해하기 어려운 목표", IEEE 소프트웨어, vol. 13, no. 1, 페이지 12-21, 1996.
  47. ^ Kan, Stephen H. (2003). Metrics and models in software quality engineering (2nd ed.). Boston: Addison-Wesley. ISBN 0-201-72915-6. OCLC 50149641.
  48. ^ 국제표준화기구, "ISO/IEC 9001: Quality Management Systems -- Requirements", 1999.
  49. ^ W.E. Deming, "위기에서 벗어났다: 품질, 생산성, 경쟁력"케임브리지 대학 출판부, 1988.
  50. ^ A. V. Feigenbaum, "Total Quality Control", McGraw-Hill, 1983.
  51. ^ J.M. Juran, "Juran's Quality Control Handbook", McGraw-Hill, 1988.
  52. ^ Weinberg, Gerald M. (1991). Quality software management: Volume 1, Systems Thinking. New York, N.Y.: Dorset House. ISBN 0-932633-22-6. OCLC 23870230.
  53. ^ Weinberg, Gerald M. (1993). Quality software management: Volume 2, First-Order Measurement. New York, N.Y.: Dorset House. ISBN 0-932633-22-6. OCLC 23870230.
  54. ^ Crossby, P., Quality is Free, McGraw-Hill, 1979년
  55. ^ "SUP.9 – Problem Resolution Management - Kugler Maag Cie". www.kuglermaag.com. Retrieved 2021-02-25.
  56. ^ a b Hoipt (2019-11-29). "Organizations often use the terms 'Quality Assurance' (QA) vs 'Quality Control' (QC)…". Medium. Retrieved 2021-02-25.
  57. ^ Wallace, D.; Watson, A. H.; Mccabe, T. J. (1996-08-01). "Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric". Nist.
  58. ^ Bellairs, Richard. "What Is Code Quality? And How to Improve Code Quality". Perforce Software. Retrieved 2021-02-28.
  59. ^ "OMG Whitepaper CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Retrieved 2021-02-26.
  60. ^ "How to Deliver Resilient, Secure, Efficient and Agile IT Systems in Line with CISQ Recommendations - Whitepaper Object Management Group" (PDF). Archived (PDF) from the original on 2013-12-28. Retrieved 2013-10-18.
  61. ^ "Software Size Measurement: A Framework for Counting Source Statements". resources.sei.cmu.edu. Retrieved 2021-02-24.
  62. ^ Halstead, Maurice H. (1977). Elements of Software Science (Operating and programming systems series). USA: Elsevier Science Inc. ISBN 978-0-444-00205-1.
  63. ^ Chidamber, S. R.; Kemerer, C. F. (June 1994). "A metrics suite for object oriented design". IEEE Transactions on Software Engineering. 20 (6): 476–493. doi:10.1109/32.295895. hdl:1721.1/48424. ISSN 1939-3520.
  64. ^ Nygard, Michael (2007). Release It!. an O'Reilly Media Company Safari (1st ed.). ISBN 978-0978739218. OCLC 1102387436.
  65. ^ "CWE - Common Weakness Enumeration". cwe.mitre.org. Archived from the original on 2016-05-10. Retrieved 2016-05-20.
  66. ^ Boehm, B., Brown, J.R., Kaspar, H., Lipow, M., MacLeod, G.J. 및 Merritt, M.J.(1978년).소프트웨어 품질의 특성.노스홀랜드.
  67. ^ a b c "SEI CERT Coding Standards - CERT Secure Coding - Confluence". wiki.sei.cmu.edu. Retrieved 2021-02-24.
  68. ^ "Code quality and code security: How are they related? Synopsys". Software Integrity Blog. 2019-05-24. Retrieved 2021-03-09.
  69. ^ "Cost of a Data Breach Report 2020 IBM". www.ibm.com. 2020. Retrieved 2021-03-09.{{cite web}}: CS1 maint :url-status (링크)
  70. ^ "Key Takeaways from the 2020 Cost of a Data Breach Report". Bluefin. 2020-08-27. Retrieved 2021-03-09.
  71. ^ "CWE - Common Weakness Enumeration". Cwe.mitre.org. Archived from the original on 2013-10-14. Retrieved 2013-10-18.
  72. ^ Security in Development: The IBM Secure Engineering Framework IBM Redbooks. 2016-09-30.
  73. ^ Enterprise Security Architecture Using IBM Tivoli Security Solutions IBM Redbooks. 2016-09-30.
  74. ^ "Secure Architecture Design Definitions CISA". us-cert.cisa.gov. Retrieved 2021-03-09.
  75. ^ "OWASP Foundation Open Source Foundation for Application Security". owasp.org. Retrieved 2021-02-24.
  76. ^ "CWE's Top 25". Sans.org. Retrieved 2013-10-18.
  77. ^ IfSQ 레벨 2 Wayback Machine, 2008년 8월 제2판, Graham Bolton, Stuart Johnston, IfSQ, 소프트웨어 품질 연구소, 2011-10-27년에 아카이브된 컴퓨터 프로그램 소스코드의 기초 수준 표준.
  78. ^ Fowler, Martin (October 14, 2009). "TechnicalDebtQuadrant". Archived from the original on February 2, 2013. Retrieved February 4, 2013.
  79. ^ Prause, Christian; Durdik, Zoya (June 3, 2012). "Architectural design and documentation: Waste in agile development?". 2012 International Conference on Software and System Process (ICSSP). IEEE Computer Society. pp. 130–134. doi:10.1109/ICSSP.2012.6225956. ISBN 978-1-4673-2352-9. S2CID 15216552.
  80. ^ "Software Sizing Standards CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Retrieved 2021-01-28.
  81. ^ "Why Software fails". IEEE Spectrum: Technology, Engineering, and Science News. 2 September 2005. Retrieved 2021-03-20.{{cite web}}: CS1 maint :url-status (링크)
  82. ^ Wagner, Stefan; Goeb, Andreas; Heinemann, Lars; Kläs, Michael; Lampasona, Constanza; Lochmann, Klaus; Mayr, Alois; Plösch, Reinhold; Seidl, Andreas (2015). "Operationalised product quality models and assessment: The Quamoco approach" (PDF). Information and Software Technology. 62: 101–123. arXiv:1611.09230. doi:10.1016/j.infsof.2015.02.009. S2CID 10992384.
  83. ^ Ebert, Christof (2010). Software Measurement: Establish - Extract - Evaluate - Execute. ISBN 9783642090806. OCLC 941931829.
  84. ^ a b "Managing the Unmanageable: More Rules of Thumb". www.managingtheunmanageable.net. Retrieved 2021-02-26.
  85. ^ Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE Software. 32 (4): 7–11. doi:10.1109/MS.2015.87. S2CID 9226051.
  86. ^ "Software Quality Professional ASQ". asq.org. Retrieved 2021-01-28.
  87. ^ "Software Quality Journal". Springer. Retrieved 2021-01-28.

참고 문헌

  • Albrecht, A. J. (1979), Measuring application development productivity. In Proceedings of the Joint SHARE/GUIDE IBM Applications Development Symposium., IBM
  • Ben-Menachem, M.; Marliss, G. S. (1997), Software Quality, Producing Practical and Consistent Software, Thomson Computer Press
  • Boehm, B.; Brown, J.R.; Kaspar, H.; Lipow, M.; MacLeod, G.J.; Merritt, M.J. (1978), Characteristics of Software Quality, North-Holland.
  • Chidamber, S.; Kemerer, C. (1994), A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, 20 (6), pp. 476–493
  • Ebert, Christof; Dumke, Reiner, Software Measurement: Establish - Extract - Evaluate - Execute, Kindle Edition, p. 91
  • Garmus, D.; Herron, D. (2001), Function Point Analysis, Addison Wesley
  • Halstead, M.E. (1977), Elements of Software Science, Elsevier North-Holland
  • Hamill, M.; Goseva-Popstojanova, K. (2009), Common faults in software fault and failure data. IEEE Transactions of Software Engineering, 35 (4), pp. 484–496
  • Jackson, D.J. (2009), A direct path to dependable software. Communications of the ACM, 52 (4).
  • Martin, R. (2001), Managing vulnerabilities in networked systems, IEEE Computer.
  • McCabe, T. (December 1976), A complexity measure. IEEE Transactions on Software Engineering
  • McConnell, Steve (1993), Code Complete (First ed.), Microsoft Press
  • Nygard, M.T. (2007), Release It! Design and Deploy Production Ready Software, The Pragmatic Programmers.
  • Park, R.E. (1992), Software Size Measurement: A Framework for Counting Source Statements. (CMU/SEI-92-TR-020)., Software Engineering Institute, Carnegie Mellon University
  • Pressman, Roger S. (2005). Software Engineering: A Practitioner's Approach (Sixth International ed.). McGraw-Hill Education. ISBN 0071267824.
  • Spinellis, D. (2006), Code Quality, Addison Wesley

외부 링크

Wikimedia Commons에는 소프트웨어 품질과 관련된 미디어가 있습니다.