Software specification
- System의 운영과 개발에 있어 필요한 기능과 제한사항을 서술하는 단계
requirements engineering process
- Requirements elicitation and anlysis
- system stakeholder가 system에서 어떤 것을 기대하고 필요로 하는지에 대하여 기술한다.
- Requirements specification
- requirements에 대하여 세세하게 기술한다.
- Requirements validation
- requirements에 대하여 검증한다.
Software design and implementation
- System specification을 실행가능한 시스템으로 만드는 과정
Software design
- 명세서를 구체화한 소프트웨어의 구조 (프로그래밍 언어, 운영체제 등과는 독립적)
- 입력으로 요구사항 명세서, 하드웨어/소프트웨어의 외적인 일을 고려하여 요구사항을 tageting하는 플랫폼 정보, 데이터의 사용과 첨삭, 활용에 대한 정보가 사용될 수 있다.
System Implementation
- 설계된 소프트웨어를 실행가능한 프로그램으로 구현한다.
- 구현단계는 개발자가 프로그램을 개발하거나 application을 configuraing하는 작업을 포함한다.
- programming은 개인적인 활동으로써 표준이 없으며 debugging단계를 포함한다.
디자인 활동
- 결과물로 디자인 활동의 명세서가 도출된다.
architectural design
- 주요 구성요소들이 어떠한 관계를 가지고 어떻게 분산되었는지 등 시스템 전체의 큰 틀을 설계한다.
component design
- 세부적인 구성요소에 대한 디자인
interface design
- 구성 요소 간의 인터페이스를 디자인
database design
- 데이터 베이스에 대한 디자인
Software validation (v & v, 제3자 입장에서 검증)
- 명세서에 기술된 요구사항이 제대로 구현되었는지에 대하여 validation/verification을 진행한다.
Component testing
- 개별적인 구성요소들을 독립적으로 검증한다.
- 구성요소들은 함수나 객체 또는 동질집단으로 구성된 객체를 지칭한다.
System testing
- 시스템 전체를 verification/validation한다.
Acceptance testing
- 고객의 데이터를 입력하여 요구사항을 만족시키는지 검증한다.
testing phases in a plan-driven software process(V-model)
Software Evolution
- 시장상황의 변화나 고객의 요구사항 변경에 맞추어 software도 변화하고 진화할 수 있어야 한다.
Coping with change
변화는 규모가 큰 모든 소프트웨어 프로젝트에서 피할 수 없다.
- 시장 상황이 바뀌며 요구사항이 변화한다.
- 새로운 기술이 등장하면서 소프트웨어 구현 레벨을 향상시키기 위하여 변화한다.
- application의 변화를 위해 플랫폼이 변화한다.
Reducing the cost of reworks
변화를 예측한다
- 주요한 사항에 대하여 rework가 필요하다고 예상되는 사항에 대하여 미리 예측한다.
- 중대한 사항에 대해 프로토타입을 만들어 고객의 요구사항을 만족하는지 빠르게 테스트하고 실행 가능 여부에 대하여 판단한다.
변화를 인내한다.
- incremental 기법을 사용하여 변화가 발생했을 경우 일정 기간 변화를 인내하고, products에 주는 영향이 큰 부분을 먼저 구현하여 고객에게 피드백을 받은 후 수정을 거친다.
Software prototyping
- 설계의 옵션과 고객의 요구사항을 빠르게 만들어 검증해본다.
- 요구사항이 불분명할 때 요구사항을 추출하고 검증하는 곳에 사용된다.
- 유저 인터페이스에 대해 미리 만들어봄으로써 다시 이전 단계로 돌아오는 위험을 줄인다.
- 프로토타입의 목표를 정의하고 프로토타입의 기능을 명확하게 정의하여 지정된 범위의 기능만 개발하고 실행, 평가 및 정리를 한다.
- 프로토타입은 빠른 개발이 중요하기에 빠른 프로토타입 언어와 도구를 사용해야 한다.
- 이해의 정도가 낮은 부분에 대하여 프로토타입 구현을 집중한다.
- 성능보다 기능에 초점을 두며, 에러/안정성/신뢰성을 크게 고려하지 않는다.
- 안정성이나 보안 같은 non-functional 보다 functional에 집중한다.
- design 단게에서 UI, 테스트 목적으로 프로토 타입을 활용할 수 있다.
장점
- 미리 프로토타입을 만듦으로써 구체화할 수 있으며 시스템의 사용성을 높일 수 있다.
- 고객의 필요에 근접할 수 있다.
- 유지보수 측면에서 향상시킬 수 있으며 개발에 투입되는 노력을 줄일 수 있다.
- 모호한 부분에 대하여 미리 구체화할 수 있으며, 이를 통하여 요구사항을 정확하게 파악하여 해결할 수 있다.
- 각 시스템에서의 중요 요소들을 파악할 수 있으며, 디자인의 질을 향상시킬 수 있다.
프로토 타입은 개발단계에서 사용되지 않아야 한다.
- 프로토타입은 Non-functional 요구사항에 대해 조정할 수 없다.
- 프로토타입은 제대로 된 요구사항을 기술하거나 디자인 하지 않았다.
- 프로토타입은 성능을 고려하지 않았기에 변화에 빠르게 대응하지 못한다.
Incremental delivery
- 우선순위가 높은 것을 먼저 구현하여 고객에게 제공한다.
- 다음 단계의 구현을 시작하기 전에 해당 단계의 개발과 검증을 시행한다.
- 검증은 user/customer proxy에 의해 수행된다.
- 실제적인 프로그램을 주므로 더 실질적인 피드백을 받을 수 있다.
- 다음 incremental이 더 낮은 성능을 제공할 때 교체하기 힘들다.
장점
- 각 increment에 대한 고객의 평가가 빨리 반영되어 변화에 빨리 대응할 수 있다.
- 이전의 increment는 프로토타입의 역할을 하며 이후의 개발에 대한 요구사항을 추출할 수 있다.
- 전체적인 프로젝트 실패에 대한 위험을 낮춘다.
- 가장 중요한 기능이 가장 많은 검증을 받는다.
단점
- 거대한 소프트웨어가 다른 소프트웨어나 기능으로 유기적으로 연결되어 있다면, 적용이 힘들 수 있다.
- 라이센스나 법적 관리가 힘들 수 있다.
Process improvement
- 소프트웨어의 품질을 올리거나 비용을 낮출 수 있고, 개발의 속도를 높일 수 있다.
Process maturity approach(PLAN-BASE가 강화된 절차)
- 프로세스의 단계를 향상시키거나 프로젝트의 관리에 집중하며 좋은 소프트웨어 공학 기술을 도입
- Capability maturity levels
능력 성숙도 통합 모델, CMMI
- 능력 성숙도 모델은 회사의 프로세스의 성능을 공인하는데 사용된다.
Agile approach
- 반복적인 개발에 집중하면서 개발 상의 오버헤드를 줄인다. (행정 부담/문서 작성을 줄인다)
Process improvement activities
Process measurement
- 소프트웨어 개발 단계나 결과물의 복수 개의 특징을 측정한다.
- 이러한 측정은 공정 개선이 효과적이었는지 여부를 결정하는 데 도움이 되는 기준선을 형성한다.
- 가능한 많은 데이터가 수집되어야 한다.
- 조직에서 프로세스 표준을 명확하게 정의하지 않은 상태라면 어떤 것을 측정해야하는 지에 대해 어려움이 있을 수 있으므로 프로세스는 측정 전에 정의되어야 한다.
- process measurements는 프로세스 향상에 대한 평가 척도로 사용되어야 한다.
- 측정이 항상 향상을 의미하지는 않는다.
Process analysis
- 프로세스 상의 약점과 병목 지점을 식별한다.
Process change
- 도출된 약점을 수정한다
KHU, SWCON