소프트웨어 공학 (4), 소프트웨어 프로세스 2

소프트웨어 프로세스 2​

---

​1. Process Activities

1) 디자인과 구현

요구사항에 대한 명세를 실제 시스템으로 만들기 전에 진행하는 단계

---

전통적으로는 이 둘을 구분하지만 웹, 비즈니스 기반인 경우에는 둘을 혼용해서 사용하기도 한다. 하지만 아직까지도 이 둘을 구분하지 않았을 때 리스크가 큰 경우에는 둘을 구분해서 사용하는 경우가 많다.

 

 

 

(1) 디자인

 

요구사항에 대한 소프트웨어의 특성, 객체, 클래스 등을 구현하기 전 단계에서의 설계를 의미한다. 전통적인 입장에선 구현과 관련된 것들과는 독립적으로 이야기한다. 최근에는 agile이나 비즈니스 어플리케이션에서 디자인과 구현이 함께 이야기되고 있다. 즉, 디자인과 구현에 대한 구분은 주어진 비즈니스나 산업에 따라 달라질 수 있다는 점을 알 수 있다.

 

 

• Design inputs
  • Platform information: 하드웨어나 운영체제에 대한 정보
  • Requirements sprecification: 요구사항(기능 위주)
  • Data description: 사용자와 시스템간의 인터렉션을 통해 발생, 관리하는 데이터에 대한 명세

 

• Design activities
  • Architectural design: 시스템의 가장 적합한 거시적인 소프트웨어들의 틀을 디자인하는 단계
  • Component design: 큰 골격 안에 들어가있는 각각의 소프트웨어로 프론트앤드, 백앤드, 데이터 베이스, 더 세부적으론 클래스들 등이 이에 해당한다.
  • Interface design: component간에 주고받는 것을 정의하는 것
  • Database design: 데이터를 저장, 관리, 입출력하기 위한 데이터 베이스 관리

 

• Design outputs
  • 각 디자인 단계의 결과물
  • 디자인 단계에서의 결과물은 코드가 아닌 명세다.

 

 

(2) 구현

 

주어진 요구사항과 디자인을 실제 코드로 작성하는 단계로 일반적으로 소프트웨어 프로세스에서 프로그래밍은 개인적인 영역으로 본다. 따라서 각자 본인이 만든 프로그램을 테스트하고 디버깅하는 과정도 포함한다.

 

 

2) 검증 단계

 

- verification은 프로그램을 요구사항/디자인에 맞춰서 제대로 구현했는가 -> 시험

- validation은 프로그램을 고객 입장에서 의미있게 구현했는가 -> 검증

- 기능에 대해 제대로 돌아갔는지 테스트 및 리뷰하는 과정을 거친다.

- '제 3자'가 객관적으로 테스트하는 과정이 필요하다.

 

• Component testing: 각각의 구성요소를 테스트
• System testing: 구성요소를 합쳐서 테스트
• Customer testing: 실제 고객 입장에서 테스트

 

 

ex) Plan-driven software process

요구사항 정의, 설계 단계에서 이후 test하는 방법에 대한 문서까지 작성하는 것을 확인할 수 있다.

 

 

 

3) Evolution (유지 보수 단계)

- 소프트웨어는 flexable하고 비즈니스 차원에서 바뀌어야한다.

- 소프트웨어는 변화에 주저하면 안되는 것이 하나의 추세이다.

- 일정 지연 및 개발을 더 하는 것을 감수하는 것이 중요하다.

---

 

2. Coping with change

비즈니스 환경/새로운 기술의 도입/종속된 플랫폼의 변화 등에 따른 소프트웨어의 변화는 필수불가결하다. 따라서 변화를 어떻게 효과적으로 해낼 것인가가 주요한 이슈이다.

 

 

1) 유지보수과정에서 rework 비용을 줄이기 위한 방법

(1) prototype

진짜를 만드는데 시간이 오래걸리거나 고객의 요구가 불분명할 때 빠른 시간 내에 데모 시스템을 만드는 것

---

 

논란이 되거나 변화가 발생하면 영향을 있을 만한 것들을 가짜로 만들어서 고객의 니즈를 확인하는 건 rework 비용을 줄이는데 많은 도움을 준다. 시각적으로 확인할 수 있어 고객의 요구사항이 모호한 경우에도 검증할 수 있다는 장점이 있다. 하지만 빠른 시간 내에 만들어야한다는 점과, 이는 차후 만들어질 소프트웨어에서 사용할 수 없다는 단점이 있다. 

 

[프로토타입 개발 프로세스]

 

---

 

프로토타입은 유저인터페이스를 할 때에도 많이 사용하고, 테스트 목적으로도 사용하기도 한다. 즉, 개발 단계에서 전방위적으로 사용할 수 있다. 성능을 보기보단 대부분 기능(functionality)에 초점을 맞춰서 빠르게 만드는 것을 목적으로 한다.

 

 

프로토타입을 만들 때에는 다음과 같은 사항을 고려해야한다. 모호한 것의 명확화를 중심으로 코드를 짜고, 집중이 필요한 부분에만 집중을 하며,  뢰성이나 보안은 대체로 제거가 된 상태로 프로토타입을 짠다.

 

 

위에서도 언급을 했듯이 프로토타입은 반드시 버려야한다. 이에 따라 앞으로 evolution을 할 수 없다는 단점이 있고 성능이나 보안면에서 문제가 발생할 수 있도 있다. 또한 관리가 안되는 시스템이니 앞으로 뭐가 나올지 알 수 없다.

 

 

프로토타입을 만들어서 발생할 수 있는 장점으로는 다음과 같다. 모호한 것을 구체화할 수 있다. 또한  어떤 기능에 중점을 둬야할지 파악할 수 있고,  디자인이 제대로 되어있는지를 명확히 이해할 수 있다. 이는 유지보수를 할 때에도 도움을 준다. 즉 전반적인 개발에 대한 노력과 리스크를 줄일 수 있다.

 

 

 

(2) incremental methods

중요한 기능(피쳐)을 하는 것부터 먼저 만들어서 출시한 뒤 점차 기능을 확장해나가는 방식

---

 

변화를 받아들여 발전시키는 것에 초점을 맞춘다. 만들어진 소프트웨어를 전달하는 딜리버리의 단계를 쪼개서 변화를 일으키는 유저들에게 incremental 버전을 먼저 오픈한다.

 

[Incremental 종류]

i) Incremental delivery

요구사항에 맞춰 만들고 기능을 추가하기에 대부분 agile 기법에 해당한다. 유저가 evalutation한다는 특징이 있다.

 

ii) incremental delivery

버전업된 소프트웨어를 유저에게 전달하는 과정으로 진짜 소프트웨어를 전달하고 피드백을 전달받을 수 있다는 특징이 있다. 기존 시스템을 대체하는 경우 새로운 시스템에 들어가야할 전략이 수립되어야한다.

 

 

[Incremental delivery]

 

incremental delivery의 장점은 다음과 같다. 모두 만들어서 제공하는 것보단 중간중간에 제공함으로서 유저들에게 검증을 받을 수 있고 우선순위가 큰 것을 먼저 하면서 안정화될 수 있다. 또한 프로젝트가 실패할 가능성이 줄어든다.

 

incremental delivery의 단점은 다음과 같다. 커다란 시스템에서 여러 기능을 나눠서 개발하는 경우에는 개발 정도가 다르기에 적용하기 어려울 수 있다. 라이센스나 규제를 관리해야할 경우에는 agile이 위험할 수 있다.

 

---

 

3. Process improvement

적은 시간에 고객이 원하는 것을 적은 비용으로 만드는 것이 소프트웨어 개발의 핵심

---

1) improvement에 대한 접근 방법

(1) Process maturity approach

- 프로세스가 강화되어 검증하는 행정적인 부담이 많다.

 

(2) Agile approach

- 문서를 만드는 시간을 줄이고 반복적인 개발에 초점을 맞춘다.

 

 

[Improvement cycle]

정량적으로 검증할 수 있는 것을 측정하는 것이 중요하다.

 

 

2) Process Improvement activites

(1) Process measurement

- 어떤 것을 개선할지 찾기 위한 기초단계

 

(2) Process analysis

- 우리 프로세스의 단점 및 병목을 분석하는 단계

 

(3) Process change

- 분석한 내용을 토대로 개선하는 단계

 

정량적인 데이터를 찾아야고 개선해야하는 것에 목표를 두고 있다. 프로세스를 공인하는 대표적인 모델인 능력 성숙도 통합 모델이 이를 확인할 수 있는 지표이고, 전통적인 대기업, 하드웨어가 있는 기업인 경우에는 이를 준수한다.  오버헤드가 크지만 유명한 기법이다.