Software Testing
- Component (Unit) Testing: 컴포넌트 혹은 유닛 테스트
- Unit testing / Module testing
- individual components are tested independently: 각각의 컴포넌트들이 독립적으로 테스트됩니다.
- Components may be functions of objects or coherent groupings of these entities: 컴포넌트들은 이런 요소들의 결합으로 이해되고 작동합니다.
- System Testing: 시스템 테스트
- + Integration Testing: 결합 테스트
- Testing of the system as a whole: 시스템 전체로서 수행되는 테스트입니다.
- Testing of emergent properties is particulary important.
- (User) Acceptance Testing: (사용자) 적응 테스트
- Testing with customer data to check that the system meets the customer's needs: 사용자의 요구에 적합한지를 테스트합니다.
- Validation activities.
또한 V&V에서 사용하는 방법으로는 Review가 있습니다.
Review는 정적/동적 테스트 모두에 속하는 방법으로 document, code, executable file등등 정말 다양한 단계에서 수행될 수 있습니다. 또한 specification에 대한 review라면 verification review가 되고, UX에 관한 review라면 validation review가 됩니다.
System / Integration / Module Test는 모두 Verification에 해당하는 활동으로 defects testing이라고도 불립니다. 이 활동들은 모두 사전에 제작된 Specification을 기준으로 진행됩니다.(* System Test는 SRS, Integration Test는 Subsystem or Design Specification, Module Test는 Unit Specification이 있다면 이를 바탕으로 진행하고, 없다면 프로그래머의 판단으로 진행합니다.)
그리고 각 Spec들을 review나 analysis의 방법으로 서로 평가됩니다. 이때 former analysis(* 정형 분석)가 사용되기도 하는데, 이는 Spec들을 수식으로 전환해 오류가 있는지 확인하는 분석기법입니다.
Software Evolution
Software must also evolve and change, as requirements change through changing business circumstances. Software is inherently and can change.
소프트웨어는 변화하는 환경에 맞춰 반드시 진화하고 변경되어야합니다.
일반적으로 Generic Software의 경우 Evolution, Customized Software의 경우 Maintenance라고 부르지만, 잘 구분하지 않고 사용합니다. 만약 어떤 게임이 소규모 패치를 진행한다면 이는 Maintenance라고 볼 수 있고, 게임의 버젼을 업그레이드한다면 이는 Evolution이라고 할 수 있는것입니다.
Maintenance, Evolution Team의 능력 평가 지표로는 S3M(* SW Maintenance Maturity Model)이 있습니다.
Process Improvement
Understanding exisiting processes and changing these processes to increase product quality and/or reduce costs and development time.
프로세스 개선(?)은 지금 사용중인 프로세스를 이해하고, 제품의 품질이나 비용, 개발 시간의 감소를 위해 그 프로세스들을 변경하는 것을 말합니다.
process improvement의 활동으로는 다음과 같은 활동들이 있습니다:
- Process analysis
- The current process is assessed, and process weaknesses and bottlenecks are identified: 현재의 프로세스를 평가하고 프로세스의 약점이나 병목을 확인합니다.
- Process models (process maps) that describe the process may be developed: 지금의 프로세스가 따르는 프로세스 모델이 개발됩니다.
- Process change
- Process changes are proposed to address some of the identified process weaknesses: 확인된 프로세스의 약점을 해결하기 위해 프로세스의 변경이 제안됩니다.
- These are introduced and the cycle resumes to collect data about the effectiveness of the changes: 변경의 효율에 대한 정보를을 모으기 위해 다시 cycle이 시작됩니다.
- Process measurement
- Measure one or more attributes of the software process or product: 소프트웨어의 프로세스나 제품의 특성들에 대해 측정합니다.
- These measurements forms a baseline that helps you decide if process improvements have been effective: 그 측정값들은 당신이 그 process improvement가 효율적이었는지 아닌지를 판단하는데 도움을 줄 수 있는 baseline을 형성합니다.
Process Measurement
Wherever possible, quantitative process data should be collected. However, organizations often do not have clearly defined process standards. A process should be define before any measurement is possible.
가능한 어느곳이든, 수치화된 프로세스 데이터는 반드시 있어야합니다. 하지만 종종 기업에서는 이런 프로세스 기준이 명확하게 정의되어있지 않습니다. 프로세스는 반드시 평가가 가능한 후에 정의되어야 합니다.
아래는 process metrics의 예시입니다:
- Time taken for process activities to be completed: 프로세스 활동이 끝나는데 걸린 시간
- Resources required for processes or activities: 프로세스나 활동에 필요했던 자원들
- Number of occurrences of a particular event: 결함 발견 횟수와 같은 이벤트 발생 횟수
The SEI SMMi
The level of process maturity, such as CMMi, reflects the extent to which good technical and management practice has been adopted in organizational software development processes.
프로세스에 대한 성숙도를 나타내는 지표로는 CMMi라는 것이 있습니다. 이는 소프트웨어 개발 프로세스를 조직적으로 얼마나 잘 관리하고 사용하는지를 나타내는 지표입니다.
다음은 CMMi단계입니다:
- Initial: uncontrolled
- Repeatable: Product management procedures are defined and used
- Defined: Process management procedures and strategies are defined and used
- Managed: Quality management strategies are defined and used.
- Optimizing: Process improvement strategies are defined and used
'[학교 수업] > [학교 수업] Software Engineering' 카테고리의 다른 글
[Software Engineering] 5주차 (2) (5) | 2024.10.04 |
---|---|
[Software Engineering] 5주차 (1) (3) | 2024.09.30 |
[Software Engineering] 4주차 (1) (0) | 2024.09.23 |
[Software Engineering] 3주차 (2) (0) | 2024.09.20 |
[Software Engineering] 2주차 (2) (0) | 2024.09.13 |