소프트웨어 개발 특성과 테스트 프로세스

소프트웨어란?

• Software = Programs + Documentation + Operating Procedures

소프트웨어 특성은?

우리가 알고 있듯이 소프트웨어는 컴퓨터가 특정 작업을 수행하도록 안내하는 일련의 명령으로 정의될 수도 있는 모든 컴퓨터 프로그램입니다.

다음은 소프트웨어의 8가지 주요 특성입니다.

1. 소프트웨어는 마모되지 않습니다.
2. 소프트웨어는 제조가 아니다
3. 소프트웨어의 유용성
4. 구성요소의 재사용성
5. 소프트웨어의 유연성
6. 소프트웨어의 유지보수성
7. 소프트웨어의 이식성
8. 소프트웨어의 신뢰성

1) 소프트웨어가 마모되지 않습니다.

옷, 신발, 장신구 등 다양한 물건은 시간이 지나면 낡아집니다. 그러나 한번 만들어진 소프트웨어는 결코 낡지 않습니다. 필요한 만큼 오랫동안 사용할 수 있으며 업데이트가 필요한 경우 동일한 소프트웨어에서 필요한 변경을 수행한 다음 업데이트된 기능으로 추가로 사용할 수 있습니다.

 

2) 소프트웨어가 제작되지 않았습니다.

소프트웨어는 제작되는 것이 아니라 개발되는 것이다. 따라서 개발에 원자재가 필요하지 않습니다.

 

3) 소프트웨어의 유용성

소프트웨어의 유용성은 사용자 측면에서 소프트웨어의 단순성을 의미합니다. 소프트웨어가 사용자에게 사용하기 쉬울수록, 더 많은 사람들이 이제 소프트웨어를 사용할 수 있게 되고, 용이성으로 인해 더 기꺼이 사용하게 되므로 소프트웨어의 유용성은 더 커집니다.

 

4) 구성요소의 재사용성

소프트웨어는 결코 마모되지 않으므로 구성 요소, 즉 코드 세그먼트도 마모되지 않습니다. 따라서 다른 소프트웨어에 특정 코드 세그먼트가 필요한 경우 이미 존재하는 소프트웨어에서 기존 코드를 재사용할 수 있습니다. 이로 인해 작업량이 줄어들고 시간과 비용도 절약됩니다.

 

5) 소프트웨어의 유연성

소프트웨어는 유연합니다. 이것이 의미하는 바는 미래의 필요에 따라 소프트웨어에 필요한 변경을 할 수 있고 그때에도 동일한 소프트웨어를 사용할 수 있다는 것입니다.

 

6) 소프트웨어의 유지보수성

모든 소프트웨어는 유지 관리가 가능합니다. 즉, 소프트웨어에 오류나 버그가 나타나면 수정할 수 있습니다.

 

7) 소프트웨어의 이식성

소프트웨어의 이식성은 소프트웨어를 한 플랫폼에서 다른 플랫폼으로 쉽게 전송할 수 있음을 의미합니다. 이로 인해 개발자와 다른 구성원 간의 소프트웨어 공유가 유연하게 이루어질 수 있습니다.

 

8) 소프트웨어의 신뢰성

이는 모든 조건에서 원하는 기능을 제공하는 소프트웨어의 능력입니다. 이는 우리 소프트웨어가 각 조건에서 제대로 작동해야 함을 의미합니다.

 

소프트웨어 개발 특성

1) 분석/사양 매뉴얼

분석 및 사양 매뉴얼은 소프트웨어 개발 초기 단계인 요구사항 분석 단계에서 작성됩니다. 이 매뉴얼은 소프트웨어의 요구 사항을 지정하는 모든 정보로 구성됩니다. 분석/사양 매뉴얼의 이 정보는 다음을 통해 표현됩니다.

• 공식 사양: 소프트웨어의 모든 요구 사항을 자세히 설명합니다.
• 컨텍스트 다이어그램: 이 다이어그램은 이름에서 알 수 있듯이 소프트웨어의 컨텍스트와 소프트웨어가 어떻게 될 것인지를 제공합니다.
• 데이터 흐름 다이어그램: 소프트웨어 내부에서 발생하는 데이터 흐름을 그림으로 표현한 것입니다.

2) 설계 매뉴얼

디자인 매뉴얼은 우리 소프트웨어가 (사용자 인터페이스 측면에서) 최종 제품으로 어떻게 보여야 하는지에 대한 소프트웨어 디자인으로 구성됩니다. 디자인 매뉴얼은 더욱 과하게 구성되어 있는데,

• 흐름도: 그림 표현을 통해 소프트웨어의 작업 절차를 표현합니다.
• 엔터티 관계 다이어그램: 관계, 카디널리티 등의 측면에서 개체가 다른 개체와 어떻게 관련되는지 알려줍니다.

3) 구현 매뉴얼

구현 매뉴얼은 프로젝트가 구축 및 개발 단계에 있는 동안 준비됩니다. 이 매뉴얼에는 소프트웨어의 프로그램 코드에 관한 모든 간략한 정보가 포함되어 있으며, 여기에 사용되는 다양한 알고리즘과 데이터 구조 및 구현 방법으로 구성되어 있습니다. 따라서 구현 매뉴얼에는 다음 내용이 포함되어 있습니다.

• 소스 코드 목록: 해당 소프트웨어용으로 개발된 코드입니다.
• 상호 참조 목록: 코드 모듈이 소프트웨어에서 사용되고 있지만 다른 사람이 개발한 경우 해당 코드 모듈의 참조입니다.

4) 테스트 매뉴얼

테스트 매뉴얼은 소프트웨어의 테스트 단계에서 준비됩니다. 여기에서 테스터는 소프트웨어에 다양한 입력을 제공하여 소프트웨어가 생성한 결과를 문서화합니다. 테스터는 소프트웨어의 최고 및 최악의 작동 사례를 포함하여 거의 모든 유형의 입력을 확인하고 결과를 기록합니다. 따라서 테스트 매뉴얼은 다음과 같이 구성됩니다.

• 테스트 데이터: 처리를 위한 입력으로 소프트웨어에 제공되는 데이터입니다.
• 테스트 결과: 제공된 테스트 데이터에 대해 소프트웨어에서 생성된 출력입니다.
  

1) User Manuals

사용자 매뉴얼은 특정 소프트웨어의 작동 방법, 기능 등에 대한 완전한 설명을 제공합니다. 사용자 매뉴얼에는 다음 세 가지 사항이 포함되어 있습니다.

 

1.1) System Overview

이는 소프트웨어의 목적이 무엇인지 정의합니다. 이름에서 알 수 있듯이, 이 소프트웨어가 왜 유용한지, 동일한 목적으로 이미 시장에 나와 있는 다른 소프트웨어보다 얼마나 나은지 등과 같은 전체 소프트웨어에 대한 개요를 제공합니다.

 

1.2) Beginner’s Guide Tutorial

이 안내서에는 소프트웨어의 각 기능을 작동하는 단계별 절차가 포함되어 있습니다. 이 모듈은 소프트웨어를 작업하는 초보자가 소프트웨어에 대해, 어떻게 사용하는지, 어떻게 작동하는지 모른다는 점을 염두에 두고 만들어졌습니다. 따라서 이를 통해 사용자는 소프트웨어를 알아가는 데 도움을 받을 수 있습니다.

 

1.3) Reference Guide

이 가이드는 사용자를 위한 일종의 도움말 북입니다. 사용자가 소프트웨어에 익숙해진 후에도 어딘가에 갇혀서 작동하는 데 어려움을 겪을 수 있습니다. 따라서 그때 그는 사용자 설명서의 참조 가이드에서 참조를 기대할 수 있습니다.

 

2) Operational Manuals

운영 매뉴얼은 귀하의 컴퓨터에서 특정 소프트웨어를 실행하는 데 필요한 하드웨어 요구 사항과 소프트웨어 지원에 대해 설명합니다. 이는 주로 다음 두 가지 하위 모듈로 구성됩니다.

 

2.1) Installation Guide

이 모듈을 통해 컴퓨터에 소프트웨어를 설치하는 것과 관련된 완전한 정보를 얻을 수 있습니다. 이는 소프트웨어 설치 디스크를 통하거나 특정 소프트웨어를 다운로드할 수 있는 인터넷 링크 형태를 통할 수 있습니다.

 

2.2) System Administration Guide

이 모듈에서는 소프트웨어를 실행하는 동안 필요한 관리 설정 및 권한에 대해 설명합니다. 여기에는 소프트웨어에 관한 다양한 이용 약관과 다양한 정책도 포함됩니다. 이를 충족하지 않으면 소프트웨어를 사용할 수 없습니다.

 

테스트 프로세스 개요

• 테스팅은 결함이 존재함을 밝히는 활동이다.
  - 테스팅은 소프트웨어에 잠재적으로 존재함을 밝히는 활동이다.
• 완벽한 테스팅( Exhaustive testing )은 불가능하다.
  - 테스팅은 소프트웨어에 잠재적으로 존재하는 결함을 줄일 수는 있지만, 결함이 전혀 발견되지 않은 경우라도 해당 소프트웨어에 결함이 없다고 증명할수 없다.
• 테스팅을 개발 초기에 시작한다.
  - 테스팅 활동은 소프트웨어나 시스템 개발 수명주기에서 가능한 초기에 시작되어야 하며, 설정한 목표에 집중해야 한다.
• 결함집중( Defect clustering )
  - 출시 전 대다수의 결함들은 소수의 특정 컴포넌트( 모듈 )에 집주오디어 발생되는 경향을 보이며, 이러한 결함의 집중은 대부분 운영상의 장애를 초래한다.
• 살충제 패러독스( Pesticide paradox)
  - 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행한다면, 나중에는 더 이상 새로운 결함을 찾아내지 못한다. 따라서 새로운 테스트 케이스를 추가할 필요가 있다.
• 테스팅은 맥락( Context )에 의존적이다.
  - 테스팅은 맥락에 따라 다르게 진행한다. 예를 들면 안전이 최우선인 소프트웨어를 테스트하는 경우, 전자상거래를 테스트하는 경우와 다른 방식으로 진행해야한다.
• 오류 / 부재의 궤변 ( Absence - of - errors fallacy )
  - 사용자 또는 비즈니스의 요구를 충족하지 못한다면, 설사 결함을 모두 발견하여 제거하였다고 하더라도 품질이 높다고 할 수 없다.

결과적으로 테스트는 계획, 실행, 모니터링, 조정 과정이 지속적으로 이루어질 수 있도록 전략이 수립되어야 한다.