Process Activities

단계별로 산출물, tool들이 다르기 때문에 과정별로 하는 일이 다르다

Software specification (요구공학)

고객의 요구사항 & 제약사항을 도출하는 것

Requirments engineering process

• Requirements elicitation and analysis 요구사항 도출 & 분석

  • 이해 당사자들이 무엇을 기대하고 요구하는 지

    이해당사자 : 하나의 업무프로세스에 연관된 모든 사람들

• Requirements specification
  요구사항들을 문서로 작성

  • 사용자 요구사항 : technical하지 않은 용어로 쓰는 (고객용) 문서 ( 고수준의 언어로 쓰인 명세서 )
  • 시스템 요구사항 : 최대한 상세하게 쓰는 개발자들용 문서

• Requirements validataion 명세서의 내용검증

  

Software design and implementation

Software design -> Implementation

Software design

design ) 소프트웨어의 구조를 정한다

설계 입력
SW가 돌아갈 환경, 어떤 데이터를 처리하는지, 어떤 요구사항이 있는지에 대한 정보

• 나의 시스템과 다른 시스템과의 관계성
• 플랫폼 정보 : 어떤 데이터베이스, 환경 에서 돌아가는 지 등 플랫폼에 대한 정보
• 소프트웨어 요구사항 : 명세서
• 데이터 설명 : 어떤 데이터를 처리할 것인지

설계 활동
모듈들 사이의 인터페이스를 설계
( 모듈들 사이에서 어떤 정보를 주고 받으며 작동하는 지 )
DB에 어떤 방식으로 저장할 것인지
어떤 세부적인 기능들 (컴포넌트들)을 넣을 것인지

• 나의 시스템 내에서의 관계성

System implementation

프로그래머의 개인적인 작업으로 취급하기때문에 방법론이 존재하지 않는다
디버깅
오류는 찾아내어 제거하는 활동

> 이 때, 오류는 문법적 오류, 에러를 말하는 것이 아니다
 각 컴포넌트 별로 해야하는 기능들이 잘 돌아가고 있는지 테스트 데이터를 가지고 테스틑하는 것이다

Software Validation 검증

주문받은대로 잘 개발을 했는지 검증하는 것

V & V ( Verification and Validation )

• Verification : 요구사항 명세서에 맞게 만들어졌는가
• Validation : 고객이 의도한 요구사항에 따라 구현되었는가

Testing stages

Component testing

컴포넌트는 하위로 내려오며 점점 쪼개진다.
각각의 하위 기능들 + groupings (연동되는 기능들)이 잘 작동하는지

System testing

testing as a "whole"

💡Emergent properties (창발성)
시스템 컴포넌트가 통합되었을 때 서브 시스템들의 관계로부터 나타나는 현상

• 기능적 창발성 ) 시스템의 모든 부분이 작동했을 때 나타나는 기능

  - ex. 자전거의 경우
       타이어, 브레이크, 기어 모두 OK
       이것들을 모두 조립하여 '자전거'를 만드니 '사람이 타고 달릴 수 있다'는 '기능' 이 생김

  📍컴포넌트들이 조합되어야만 만들 수 있는 기능이다

• 비기능적 창발성 ) 시스템 행위와 관련됨
  ex. 신뢰성, 성능, 안전성, 보안성 등 기능적이지 않은 새로운 특성

• Component testing, System testing은 test용 데이터를 사용한다

Customer testing

고객의 니즈에 맞춰 testing
실제 데이터로 testing 하며 customer들이 직접 testing 하기도 함
= 커스터머의 니즈를 정확히 맞췄는지 확인하는 과정 ( V&V의 Validation )

Alpha Test

개발된 시스템을 개발자들이 내부에서 진행하는 자체 검사

Beta Test

고객이 한정되지 않는 경우 주로 많이 사용한다

CBT (Close Beta Test) 한정된 인원이 진행
OBT ( Open Beta Test) 한정되지 않은, 공개적으로 모집하여 진행

베타 테스트를 통해 파악한 버그들을 모두 잡진 않고 핵심적인 버그들을 주로 고쳐서 release하고 계속 진화시킨다.

Software Evolution

요구사항, 환경이 바뀜에 따라 evolution이 진행되어야 한다

기존 시스템 평가를 하여 변경사항을 제안한다
제안하는 변경사항 = SI - 새로운 개발 단계 | SM - 유지보수

전체적인 시스템 구조를 바꾸는 등의 작업은 아무리 점진적 개발방법을 사용하여도 개발과정에서 수정하기 힘들기 때문에 진화과정에서 바꾸며, SI팀에서 새로운 개발단계로 시작하기도 함

시스템을 수정하여 신규시스템을 만든 후, 바로 신규 시스템을 도입하여 사용하지 않고 일정기간동안 기존 시스템과 '하이브리드'로 사용한다

Cope with Changes

변화는 불가피하다

• Business changes
  경영진이 바뀔 수도, 비즈니스 환경이 변할 수도 있으며, 경쟁기업이 뭘 개발하는지의 영향을 받기도..
• New technologies
• Changing platforms

Change leads to rework
rework에는 cost가 발생한다
rework에는 기존 시스템에 대한 분석이 필요하다 - 이 분석이 대개 오래 걸리고, 이 시간을 단축하기 위해 '명세서'가 필요하다

Reducing the cost of rework

Change Anticipation 변경 예측
Change Tolerance 변경 허용
: 변경하기 쉽게 코드를 짠다

Software prototyping

변경 예측에 해당하는 접근법

시스템의 초기버전

• 요구공학 단계에서 요구사항을 도출하는데 도움이 됨
• UI 디자인에 필수적
• 테스팅 단계에서 back-to-back test 하는데에 쓰임
• 성능상의 비기능적인 요구사항을 반영하지 않음
• 변경된 기능적 요구사항을 받아내기 위해 사용

프로토타이핑의 장점

• 시스템의 사용성 높임 - 시스템의 장단점을 파악하기 쉽기 때문
• 사용자의 니즈를 더 정확히 파악 가능
• 디자인 퀄리티 향상
• 유지보수성 향상
• 개발에 드는 비용 줄어듦 ( 최종본을 고치는 것에 비해 )
• 사용자들이 깜빡하거나 개발자들이 miss한 부분을 잡아낼 수 있다

• 프로토타입 개발 프로세스

• 프로토타입 버전은 아예 따로 새롭게 만드는 것

  검증하고 싶은 목표를 설정
  그 목표에 필요한 기능들 정의

Incremental delivery

변경 허용에 해당하는 접근법

개발을 축적해서 한다 = 버전별로 출시된다
-> 고객 입장에서 (일이 진행되는 것을 볼 수 있으니 ) 신뢰감이 쌓이며 의견이 반영될 수 있어 좋음
하지만 개발하는 도중에는 요구사항이 frozen 이어야한다

• Incremental delivery의 장점

  • 고객의 지속적인 컨펌을 받으므로 고객의 요구사항을 쉽게 반영 가능 ( 고객 만족도 높아짐 )

• 계속해서 새로운 버전을 받아 사용해볼 수 있다 ( 고객들의 효과적 사용 )

• 프로젝트 실패에 대한 risk가 낮아짐

• 우선순위가 높은 것들을 먼저 개발하므로, 우선순위 높은 항목들에 대한 충분한 검증 가능 = ' 안정화 ' 가능

• Incremental delivery의 단점

• user가 새로나오는 버전들을 사용하지 않음 - 번거롭고 새 기술에 거부감

• 조달시스템에는 명세서가 필요한데, 이 과정을 따르는 경우 '괴리'가 발생한다

  • 개발하면서 요구사항들이 점차 많아지고 수정됨 - 개발이 끝나야만 확정된 명세서..

• 중요한 기능들을 먼저 개발해야하는데, 어떤 기준으로 중요한 기능을 뽑을 것인가