[소프트웨어공학] 2장 소프트웨어프로세스

• 소프트웨어 프로세스 모델
• 공정활동
• 변화에 대처하는 방법
• 공정개선

 

소프트웨어 프로세스 – 소프트웨어 시스템 개발에 필요한 구조화된 활동 집합

명세서(Specification) – 설계 및 구현(Design and implementation) – 검증(validation) - 진화(Evolution)

 

소프트웨어 프로세스 모델은 프로세스의 추상적인 표현이다. 일부 특정 관점에서 프로세스에 대한 설명을 제공합니다.

 

소프트웨어 프로세스 모델(Software process models)

 

>폭포수 모형(The waterfall model)

- 계획 중심 모델 사양 및 개발의 개별적이고 뚜렷한 단계.

>점진적 발전(Incremental development)

- 사양, 개발 및 검증이 서로 인접하지 않게 배열됩니다. 계획 주도적이거나 민첩할 수 있습니다.

>통합 및 환경 설정(Integration and configuration)

- 시스템은 구성 가능한 기존 구성 요소로 조립됩니다. 계획 주도적이거나 민첩할 수 있습니다.

>실제로 대부분의 대형 시스템은 이러한 모든 모델의 요소를 통합하는 프로세스를 사용하여 개발됩니다.

 

폭포 모형 단계(Waterfall model phases)

>폭포 모델에는 다음과 같은 개별 단계가 있습니다.

- 요구사항 분석 및 정의

- 시스템 및 소프트웨어 설계

- 구현 및 유닛 테스트

- 통합 및 시스템 테스트

- 운영 및 유지관리

>폭포 모델의 주요 단점은 공정 진행 후 변경 수용의 어려움이다. 원칙적으로, 한 단계는 다음 단계로 이동하기 전에 완료되어야 합니다.

 

폭포 모형 문제

>프로젝트를 융통성 없이 별개의 단계로 분할하여 변화하는 고객 요구사항에 대응하기 어렵습니다.

- 따라서 이 모델은 요구사항을 잘 이해하고 설계 과정에서 변경이 상당히 제한될 경우에만 적합합니다.

- 안정적인 요구사항을 가진 비즈니스 시스템은 거의 없습니다.

>폭포 모델은 시스템이 여러 현장에서 개발되는 대형 시스템 엔지니어링 프로젝트에 주로 사용됩니다.

- 이러한 상황에서 폭포 모델의 계획 주도적 특성은 작업을 조정하는 데 도움이 됩니다.

 

점진적 발전(Incremental development)

점진적 개발 이익

>변경되는 고객요구 수용비용 절감

- 폭포수 모델에 필요한 것보다 다시 작성해야 하는 분석 및 문서화 양이 훨씬 적습니다.

>개발 작업에 대한 고객의 피드백은 더욱 쉽게 얻을 수 있습니다.

- 고객은 소프트웨어 데모에 대한 의견을 제시할 수 있으며, 구현된 양을 확인할 수 있습니다.

>고객에게 유용한 소프트웨어를 보다 신속하게 전달 및 배치할 수 있습니다.

- 고객은 워터폴 프로세스를 통해 가능한 한 빨리 소프트웨어를 사용하고 가치를 창출할 수 있습니다.

 

점진적 개발 문제

>공정이 보이지 않습니다.

- 진행률을 측정하기 위해 관리자는 정기적인 결과물이 필요합니다. 시스템이 신속하게 개발되면 시스템의 모든 버전을 반영하는 문서를 생성하는 것이 비용 효율적이지 않습니다.

>시스템 구조는 새로운 증분이 추가됨에 따라 저하되는 경향이 있습니다.

- 소프트웨어 개선을 위한 리팩터링에 시간과 비용이 소요되지 않는 한, 정기적인 변경은 소프트웨어 구조를 손상시키는 경향이 있습니다. 추가 소프트웨어 변경사항을 통합하는 것은 점점 더 어려워지고 비용이 많이 듭니다.

 

통합 및 구성(Integration and configuration)

>기존 구성요소 또는 애플리케이션 시스템(COTS - 상용 기성 시스템이라고도 함)에서 시스템을 통합하는 소프트웨어 재사용을 기반으로 합니다.

>재사용되는 요소는 사용자의 요구 사항에 따라 행동과 기능을 조정하도록 구성할 수 있다.

>재사용은 이제 다양한 유형의 비즈니스 시스템을 구축하는 표준 접근법이 되었습니다.

 

재사용 가능한 소프트웨어 유형

> 특정 환경에서 사용하도록 구성된 독립 실행형 애플리케이션 시스템(COTS라고도 함)

>패키지로 개발되어 구성 요소 프레임워크와 통합되는 오브젝트의 모음입니다.(NET 또는 J2EE.)

>서비스 표준에 따라 개발되며 원격 호출이 가능한 웹 서비스

 

주요 프로세스 단계

> 요구사항 명세

> 소프트웨어 검색 및 평가

> 요건 개선

> 응용프로그램 시스템 구성

> 부품 적응 및 통합

 

장점과 단점

> 처음부터 소프트웨어 개발이 줄어들어 비용 및 리스크 감소

> 시스템 제공 및 구축 시간 단축

> 그러나 시스템이 사용자의 실제 요구를 충족하지 못할 수 있으므로 요구사항의 타협이 불가피합니다.

> 재사용되는 시스템 요소의 진화에 대한 제어력 상실

 

2장 Software Processes

• Software process models(소프트웨어 모델에는 무엇이 있는지?)
• Process activities(모델 안에서 우리가 하는 활동들은 무엇인지?)
• Coping with change(변화에 적응하는 것)
• Process improvement(어떻게 하면 프로세스를 개선할 수 있는지)

 

소프트웨어 개발에 보편적인 과정

>명세화 – 우리가 만들 소프트웨어가 어떤 정의를 만족해야하는지 파악하는 것

>소프트웨어 설계, 구현 – 원하는 바를 설계 구현 해봄

>검사/검증 – 원하는 바가 잘 구현되었는지 테스트 해봄

>발전/개선 – 변화에 적응하여 발전 개선하는 것

 

소프트웨어 프로세스 설명

>데이터 모델이 어떠한지, 사용자에게 어떻게 보이는지에 대한 user interface, 그리고 이런 것들이 어떠한 순서로 배치될지를 정의함

 

소프트웨어 과정 속에 산출물 – 가시적 결과물 코드, 문서, 역할이 정해짐(누가 무엇을 할지), 해야 될 일에 앞 단계, 뒤 단계를 순서 결정

 

여기서부터 구체적인 소프트웨어 프로세스 이야기

어떤 일을 하면 그 일의 단계는 무엇이고 단계별로 어떤 산출물이 나오는지 이야기해봄

 

가장 많이 사용되는 프로세스

>Plan-driven Processes(전통적인 방식) - 계획을 세우면 계획에 맞춰서 개발을 함, 누군가 무엇을 만들어야 하는지 명확하게 계획을 함, 명세서가 없으면 설계 안함, 설계가 안 되어 있으면 구현 안함 -> 단계별로 순차적 진행을 강조함

-> 따라서 소프트웨어 개발에 필요한 모든 활동들은 미리 계획되어 있어야하고 계획대로 움직여야만 함(군대식...)

>agile Processes(최근 웹, 앱 등을 제작할 때 사용) - 우선시되는 요소들을 우선 개발하는 단계별 진행(틀린 것이 있다면 그때 그때 수정 및 반영을 함, 변화에 매우 민감하게 대응함)

-> 다양한 곳에서 오는 변화를 반영하는 것이 목표

 

>>둘 중에 특정한 것이 맞고 이런 것이 아니라 프로그램에 맞게 적용하는 것이 중요함(실제로는 병행해서 쓸 수밖에 없다!)

프로세스는 다양한 도구적 관점에서 보아야함 -> 내가 만들고자 하는 소프트웨어의 특성에 맞게 도움을 받는 것이다!

 

Plan-driven Process(순차적이며 계획적이다, 절차를 중시함, 소프트웨어와 하드웨어가 하나의 결과물을 도출할 때 많이 사용됨, 통상적인 물건을 만드는 기법, 공학에서 많이 사용, 보안이 매우 중요!, 미리 검증을 마치고 진행함, 규모가 굉장히 큰 소프트웨어 비즈니스에서 사용하고 부분적으로 하이브리드로 에이자일을 사용할 수 도 있음, 엄격한 단계 구분, 위에서부터 아래로 단계별 진행)

요구사항정의 -> 소프트웨어 설계 -> 소프트웨어 구현 -> 테스트 -> 통합 -> 시스템 테스트 -> 기능에 대한 보안, 업그레이드 작업

>>단계별로 진행됨 오류가 나면 뒤로 돌아가야 함 시간 낭비가 심함

<-

Hybrid Process

->

agile Process(빠른, 신속한 개발 프로세스 변화를 받아들이는데, 비즈니스 어플리케이션, 웹서비스, 완전히 구현되기보단 제때 주요기능이 작동 할 수 있게 하는 것이 중요함, 특징-지금바로 출시해서 시장의 변화를 보고 그에 맞게 변화함)

-> 파트별로 나누어 파트별로 제작을 하여 수행을 검사함(명세, 구현, 검증, 테스트들이 유기적으로 돌아감) -> 버전별로 강화되어 업그레이드됨.

ex. 카카오톡 -> 처음부터 지금의 플랫폼이 만들어져있던 것이 아님 대화방, 게임, 페이 등이 점차 누적되어 만들어진 것임(시장에 반응에 대응하면서)

 

Software process models(소프트웨어 프로세스 모델들)

>Waterfall(폭포수) model – 앞에서 언급한 Plan-driven model, 위에서 아래로 흐르는 개발 단계를 가짐(순차적 단계 진행)

>Incremental development – 앞에서 언급한 agile model, 구현을 하기 위한 규격화, 개발, 검증이 밀 결합되어 있음 -> 핵심기능을 기반으로 점점 자라나듯이 개발이 됨.

-> Plan-driven도 포함될 수 있음!

>Integration and configuration(가능하다면 안짜는 것, 최근에 많이 강조) - 이미 존재하는 것들을 호출해서 사용하는 것, 짜 맞추기, 필요한 부분만 가져다 호출만 해서 사용함

 

Waterfall(폭포수) model

요구사항정의 -> 소프트웨어 설계 -> 소프트웨어 구현 -> 테스트(유닛테스트, 클래스 등으로 나눠서 테스트, 개발부서별로 진행) -> 통합(하나의 큰 소프트웨어로 만드는 것) -> 시스템 테스트(전체적인 소프트웨어가 요구사항에 맞게 유기적으로 수행되는지를 테스트, 전체부서가 함께 진행) -> 운영을 하면서 기능에 대한 보안, 업그레이드 작업, 유지부서

>>앞에서 실패하면 뒤로 가기 어려운 모델(비용이 많이 증가함)

>>변화를 받아들이기 어렵다!

문제점 - 수 시간에 거쳐 소프트웨어를 개발하고 개발이 완료된 상태에서 변화된 요구에 적응하기 가어렵다. -> but 변화가 많지 않은 곳에서는 사용에 적합함

구글, 네이버, 카카오와 같은 비즈니스 시스템에서는 변화가 급박하여 사용이 어렵다.

Plan-driven Process를 적용하기 적절한 예시

>임베디드 시스템 – 소프트웨어를 제외하고 나머지는 순차적이고 절차적인 측면으로 진행이 됨(전통적으로 하드웨어가 주로 사용됨)

>기능을 제공하기 전에 안전성, 보안성, 기능성을 미리 판단을 하는 시스템에서 사용가능(보수적인 측면이 강조될 때), 크리티컬 시스템들

>굉장히 큰 소프트웨어 시스템 일 경우, 전체는 Plan-driven로 하고 하부에서는 하이브리드 식으로 에이자일 등의 프로세스 기법들을 사용한다.

 

Incremental development

중간 중간 여러 단계들이 버전을 계속해서 업그레이드시킴

Concurrent activities부분에서 명세, 개발, 검증이 유기적으로 이루어진다(agile) 각각의 과정을 Plan-driven로 구성시킬 수 있다

-> 문서보다 코드가 우선시 되며 코드가 우수하면 문서가 없을 수 도 있다는 주장을 함

큰 그림을 먼저 우선적으로 출시함

장점

-Plan-driven의 단점이 Incremental development에서는 장점이 됨

-단계별 수정만 하면 되기 때문에 비용이 적게 든다

-사용자의 피드백을 쉽게 반영할 수 있다

-빠른 시간 안에 사용이 가능하다.

단점

-프로세스를 시각적으로 보기가 어렵다.(관리자들이 답답해 할 수 있음, but 결과적으로는 개발이 되고 있음)

-부분적으로 개발하기 때문에 확장성이 떨어지는 소프트웨어 개발로 이어질 수 있다.(전체를 보면서 구현하기 어려움)

 

Incremental development 문제점 예시

출시된 소프트웨어가 유명해지고 많은 수익을 발생시키면서 책임이 따른다.

개발 속도가 매우 빠르기 때문에 개발자가 챙겨야하는 오픈소스 라이센스, 법률적인 문제, 사회적, 정치적, 문화적인 부분들을 간과 하는 경우가 생길 수 있음(개발자 중심 소프트웨어 개발의 문제)

 

Integration and configuration -> 위에 것들과 같다고 보긴 어렵다(개발단계에서의 기법)

-> 가져다 엮어서 구조화함 – 존재하는 요소들을 재사용하던지 오픈소스를 이용하여 기능적인 측면을 대체함

COTS(Commercial-off-the-shelf) - 개발하지 않고 그냥 돈 주고 사오면 되는 것들

하드웨어 -> 부품을 그냥 구매해서 사용

소프트웨어 -> 어파치와 같은 곳에서 상용 소프트웨어를 가져오는 것

가져와서 개발자가 구상한 형태로 사용하면 되는 것

>>개발보단 재사용(짜 집기를 잘 하는 것)

재사용가능한 소프트웨어 종류

>Stand-alon application systems(COTS) - 돈 내고 사와서 사용하는 것

>라이브러리 – 함수나 소프트웨어 같은 것들을 가져다 쓰는 것(ex. 자바의 패키지들) 이미있는 것을 엮어서 사용하는 것 일부 개발이 필요하다.

>웹 서비스 – 아마존, 구글, 네이버와 같은 곳에서 API를 가져다 사용하는 것(클라우드 컴퓨팅), 호출하고 결과만 받으면 됨(최근에 많이 사용됨)

>>개발보단 내가 필요로 하는 것들을 잘 찾아서 사용하는 것

맞는 요소들을 가져와서 맞으면 바로 사용하고 아니면 적절하게 적용해서 만들고 이것도 안된다면 스스로 새로운 것을 만들어 전체를 통합하여 원하고자 하는 소프트웨어를 만듦

>>클라우드, API개발(오픈소스)의 활성화로 더욱 강조 됨

 

주요 프로세스 단계

>Requirements specification – 요구를 명세화

>Software discovery and evaluation – 가능하면 찾아 쓰고 개발

>Requirements refinement – 좀 더 좋은 것으로 반응

>Application system configuration – 부분적으로 있는 것을 짜집기하는 것

>Component adaptation and integration – 요소들을 적용하고 통합

 

장점

-이미 사용되고 있는 것이기 때문에 리스크가 적다

-개발하는 것이 목적이 아닌 소프트웨어를 활용해서 문제를 해결하는 것에 목적을 둠

단점

-내가 요구사항을 통해 개발하려는 소프트웨어인지에 대한 검증이 필요함

-내 시스템이 개발 진화하는 것에 있어서 재사용한 시스템도 같이 가지 않는다면 문제가 더 커질 수 있음

 

Process activities

어떠한 프로세스를 개발하던 요구분석, 설계, 구현, 테스트과정은 포함되어 있음

이런 것들이 순차적으로 이루어지면 폭포수 모델

이런 것들이 유기적이고 동시다발적으로 이루어 질 수 있으면 에이자일 모델

 

각각의 activity는 수행 끝에 나와야할 output이 있고 누가 이것을 수행하지에 대한 책임이 존재 함, 앞 단계와 뒤 단계의 순서도 있음

 

requirements engineering process

요구사항 정리(어떠한 소프트웨어가 만들어지면 이러한 일을 할 것이고 어떻게 기능할지에 대한 분석, 시스템 레벨) ->시스템 설명서(ex. 아이폰이 있으면 이것의 전반적인 기능, 외관들을 설명해주는 설명서)

요구사항을 상세하게 정의하는 과정(외관 같은 것들 말고 시스템의 상세적인 기능들에 대해서 명세화 하는 과정, 시스템 설명서를 받아서 실질적으로 구현을 함, ) -> 사용자와 시스템 사이에서 어떤 일이 벌어질지를 다양한 시나리오를 통해서 구체화하는 작업

요구사항을 검증하는 과정(정상적으로 명세화된 요구인지 검증함)

>> 최종적으로 시스템 설명서와 시나리오를 통해 구체화 된 것들을 다음단계로 전달하기 위해 문서화함 (각각을 Plan-based로 접근을 함)

>>위 부분을 전문적으로 다루는 사람들도 있음

 

소프트웨어 명세

>최초에 요구사항은 무엇인지

>제한 사항은 무엇이 있는지를 확인함

>이 시스템이 무엇인지를 명세

>뭘 원하는지를 구체적으로 명세(ex. 자동차의 경우에는 시동을 켠다던지, 핸들이 조작되는 방법 등) - 사용자와 시스템의 관계에서 시스템이 해줘야할 기능을 명세

>맞는지 틀린 것인지를 검증

>>최종적으로 문서화되면 개발팀에 전달 됨

 

activity가 있고 각각에 output이 있고 activity 간에 전후 관계가 존재한다.(추가적으로 어떤 사람들이 해야 하는지를 명시함)

요구사항 명세서에 굉장히 구체적인 내용이 실림 한 프로세스를 넘버링해서 단계별로 진행사항을 세부적으로 알려 줌.

번호들을 통해서 진행과정이 항목화 된다.

 

요구사항이 문서화되어 만들어지면 설계와 구현을 시작함

Plan-based에서는 설계이후에 구현을 단계별로 진행한다(전통적). 하지만 그냥 설계와 구현을 함께 진행하기도 한다.

이제 앞에서 만든 명세서를 통해 실제 시스템을 만든다.

에이자일과 같은 기법에서는 설계와 구현을 한 번에 묶어서 생각한다.

>소프트웨어 설계

소프트웨어가 어떤 특성을 가지는지 어떤 객체를 가져야할지를 구현하기 전 단계에서 그림을 그리는 작업

>구현

실제 위에 설계를 바탕으로 실행 가능한 소프트웨어를 만들어 내는 것

>>과거엔 두 가지를 엄격하게 구분하였지만 현재는 구분 없이 묶어서 사용하기도 한다.

 

일반적인 설계 과정

>Design inputs

설계에 대한 요구사항(동사적인 구현)이 있고 요구사항을 디자인을 할 타겟이 되는 플랫폼이 주어진다. -> 목적어는 Data가 된다.

>>시스템은 데이터를 플랫폼을 통해 요구사항에 맞는 동작을 할 것이다.

 

>Design activities

Architectural(요구하는 소프트웨어의 틀) Design을 정의하고 이 안에서 일을 할 class와 같은 Component design(큰 골격 안에 작은 요소들, class들, 웹서비스의 프론트앤드, 백엔드, 데이터베이스)들을 정의를 하고 이 요소들을 어떤 식으로 대화를 해야 할지 Interface(서로 주고받을 것)design을 정함 또한 필요시에 데이터를 저장하고 관리하고 다른 애들에게 입출력을 허용할 Database design을 정함 여기까지가 Design activity의 주된 업무이다.

이걸 마치게 되면 각각의 Design activity에 대한 output이 나옴

 

>Design outputs

-System architecture(밑에 것들을 포괄적으로 포함하는 문서)

-Database specification(데이터베이스가 실제로 코드화되었을 때 무엇을 해야 할지를 적어둔 것)

-Interface specification(A를 받으면 B를 돌려줘야하는 대부분 API, 클래스의 경우에는 클래스가 제공해야하는 메서드들이 명세화 된 것)

-Component specification(위의 인터페이스에 의해 정보를 주고받는 엑터들이 있는데 그들을 컴포넌트라고하고 클라스에 관한 것들이 주로 여기서 명시가 됨)

위에서 준 번호들이 추가로 연결 연결되어 뻗어나간다.

 

>Design activity

- Architectural design(시스템을 아주 거시적 총체적으로 봤을 때 어떤 식으로 만들어져야하는 지와 그 안에 어떤 요소들이 있는지를 나타내는 큰 그림, 총체적인 설계도)

- Database design(데이터를 별도로 관리 명세)

- Interface design(요소들 간에 인터페이스를 정의)

- Component selection and design(위에 큰 그림에 세부적인 내용들을 풀어주는 문서)

ex. 아이폰을 만들고자 했을 때 아이폰의 틀을 만들고 각각의 기능을 하는 작은 요소들을 만들고...

 

>System implementation(시스템 구현)

-Plan based 같은 경우는 디자인 문서가 있고 구현단계의 코드가 있지만 에이자일처럼 설계와 구현이 맞물려서 돌아가면 코드가 디자인 문서를 대체하는 경우도 있다

>>케이스 별로 다르다

-프로그래밍은 지극이 개인적인 회사의 고유적인 것으로 판단함

-디버깅을 수반함 -> 각자 만든 코드를 테스트하고 디버깅해봄

 

>Software validation(시험 검증 절차 V&V, Verification-제품을 요구사항에 맞춰서 제대로 구현을 했는지(기능적으로 잘 구현되었는지) and validation-사용자입장에서 실제 의미가 있는 프로그램을 만들었는지(최초에 고객님이 원하던 것이 만들어졌나?))

앞 과정에서 개발 과정을 마쳤고 이번 단계에서 원하는 결과물이 실제로 나온 것인지를 실제로 검증해봄

>>기능에 대해서 제대로 동작하는지를 확인을 하고 제대로 만들었는지 문서와 같은 것들을 평가함

테스트 케이스 별로 제대로 구현이 되었는지를 시험함

>>제 3자가 객관적으로 평가함

Component testing – 각각의 요소들을 테스트

System testing – 위에 요소들을 모아서 시스템 단위로 테스트

Customer testing – 실제 사용자를 대상으로 요구하는 바가 제대로 구현되었는지를 테스트

>>각각의 요소별로 객관적으로 평가를 하고 그것들을 한 대 보아 시스템으로 테스트를 함 -> 그리고 사용자가 실제로 사용가능한지를 테스트한다.

 

>>>요구사항 정의 설계 이런 단계에서 내가 지금 이 시스템이 만들어져야하는 요구사항을 이렇게 정의하는데 나중에 내가 원하던 요구사항이 맞는지를 Plan driven 절차를 가지고 테스트를 하기 위한 문서를 만들어 둔다.(나는 이렇게 테스트 할 겁니다!) (page31)

앞쪽에서는 어떻게 테스트할지를 단계별로 정의(문서화)함 -> 뒤쪽에서 이것을 각각의 구현물에 적용하여 테스트를 해봄

 

Software evolution

이렇게 만들어진 소프트웨어는 유지보수 단계로 넘어감

소프트웨어는 비즈니스적으로 변화를 많이 겪는데 그러한 변화를 유연하게 적응할 수 있어야한다. -> 유지보수를 위해 개발자가 능동적으로 제안할 수도 있어야함

 

 

Coping with change

변화에 우리가 어떤 식으로 대응해 갈 것인지를 알아보자

>변화는 피할 수 없다

-비즈니스적 변화는 당연히 시스템 요구사항의 변화를 이끈다.

-새로운 기술(생산력을 높임)이 등장하면 변화는 따라온다.

-사용환경(플랫폼)을 바꾸는 것 (ex. 애플이 인텔 CPU를 쓰다가 자체적으로 만든 CPU 사용을 도입)

>변화는 새로운 일을 만들고 그에 따라 비용과 시간이 소요된다.

 

우리에 주어진 것은 변화는 필수 불가결하니 우리는 어떻게 그것을 효과적으로 해낼 것인가?

어떻게 하면 변화를 효율적으로(적은 비용, 적은 시간, 적은 인력) 수행할 것인가?

 

비용을 줄이는 방법 (2가지 기법)

-변화를 예측하는 것(프로토타입)

예측을 할 수 있는 것이 좋음 -> 가짜를 빨리 만들어 보는 것

고객님의 모호한 요구를 빨리 만들어서 검증을 해봄(최악을 결과를 미연에 방지함)

-변화를 받아드린다(Incremental, 빨리해야할 것 하고 추가한다)

가장 중요하고 논란이 될 만한 것을 먼저 만들어서 사용자에게 빠른 피드백을 받음

중요한 부분이 먼저 릴리즈 되는 진짜 시스템

 

소프트웨어 프로토타이핑

- 빠른 실례에 데모시스템(목업)을 만든다, 요구사항이 불분명할 때 빠른 판단을 위해 우선적으로 임시 프로그램을 만드는 것(UI에서 많이 사용) -> 소프트웨어 개발에 전방위적으로 사용가능

장점

사용성을 향상시킬 수 있다

사용자의 요구를 밀접하게 판단할 수 있다.

유지보수 가능성을 향상시킨다.

초기비용이 더 들지만 뒤에서 발생할 수 있는 막대한 비용들에 대한 절감이 가능함

 

프로토타입 개발과정

간단한 프로토타입 계획 수립 -> 필수적인 요소들만 구현을 한다. -> 실제 실행을 해봄 -> 그것을 사용자들과 의견을 나누면서 모호성을 해결한다. -> 결과를 보고서로 작성함

>>이렇게 되면 프로토타입으로서의 역할은 끝남

빠른 개발을 위해서 특정 언어(파이썬-간단하기 때문)나 툴을 사용한다.

>>쉬운 언어로 빨리 구현한다.

>>함수 중심으로 프로토타입을 구현한다. -> 되는지 안 되는지 판단용도

>>신뢰성, 보안은 배제가 된다.

 

Throw-away – 보고서까지 모두 작성되었다면 과감하게 버려야한다.

-> 빨리 만드는데 초점을 맞췄기 때문에 전체적인 기능적인 면에서 떨어진다.

 

Incremental development – 요구사항에 맞춰 만들고 뒤에 버전에서 기능들을 추가함, 고유적인 기법으로는 에이자일이 있다

 

Incremental(점진적으로) delivery – 사용자에게 단계별로 기능들을 오픈해주는 것

>요구사항이 구성되게 되면 우선순위가 정해지는데 여기서 우선순위가 높은 것 먼저 사용자에게 주는 것 (진짜 소프트웨어를 주는 것)

애매함이 등장할 수 있다. -> 기존의 시스템이 존재한다면 새롭게 개발된 시스템이 도입되는 전략이 수립되어야만 한다.

 

과정

앞에서 배운 것과 마찬가지로 요구사항을 정의하고 설계 구현을 하고 그 소프트웨어를 시험하고 검증하며 그 것을 Deploy(운영) 함

 

장점

뒤늦게 잘못을 알아채는 오행을 방지할 수 있다.

사용자가 미리사용을 하고 그에 따른 빠른 피드백이 가능함 -> 요구사항을 조기에 명확하게 할 수 있다.

>>프로젝트의 실패확률을 줄일 수 있다.

 

단점

소프트웨어가 되게 거대하기 때문에 서로 유연하게 통합하는 것이 어려울 수도 있다.

중간 결과물로 나온 것이 회사 정책에 부합해야함

규모에 따라 자칫하면 Plan based로 가버릴 수도 있음

개발 외적인 요소들을 받아들일 수 있어야한다.

 

Process improvement -> 좀 더 나은 미래로 가기위해서 어떤 일을 해야 할까?

프로세스가 향상되어야할 이유 – 소프트웨어의 품질을 높이거나 비용을 줄이거나 개발을 좀 더 가속화 할 수 있기 때문이다.(비즈니스적으로 의미 있는 것임)

 

2가지 입장

-process maturity approach(plan based가 강화된 느낌, 굉장히 절차적이고 많은 문서를 만듦)

-agile approach(반복적으로 만들고 행정적인 업무를 줄이는 것을 강조함, 문서를 만들 시간에 좋은 코드를 짜라!)

 

정량적으로 개선되어야 할지 정하고 그 것을 분석하고 적요하는 단계가 순환함(수치적 검증과정이 중요함)

 

>Process measurement

문제점을 개선할 것을 찾아냄

>Process analysis

개선해야할 것을 분석

>Process change

분석을 통해 변화되어야 할 것을 바꾼다.

실제로 수치적으로 어떤 효율성이 생기는지를 보여줌 -> 회사에서 좋아함

며칠이 줄고, 인력이 덜 들고, 비용과 시간이 감소함을 보여줌

 

 

CMMI(Capability Maturity Model Integration, 능력치 성숙도 모델) -> 각 회사에서 프로세스를 개발하고 설계하는 능력이 얼마나 되는지 국제공인해줌

Capability maturity levels

>>

1) Initial – 아무것도 없는 것

2) Repeatable – 제품에 대한 관리를 함

3) Defined – 제품을 만들기 위한 프로세스에 대한 관리까지 함

4) Managed – 제품의 품질에 대한 관리까지 함

5) Optimising – 향상 개발, 증진 시키는 과정까지 함

 

>>CMMI – 소프트웨어가 얼마나 정량적으로 잘 개발되고 있는지를 인증해주는 인증제도, but 오버헤드가 큼...

 

 

 

2장 요약

- 소프트웨어 프로세스는 소프트웨어 시스템 제작과 관련된 활동입니다. 소프트웨어 프로세스 모델은 이러한 프로세스의 추상적인 표현입니다.

- 일반 공정모델은 소프트웨어 공정의 구성을 설명합니다.

이러한 일반 모델의 예로는 '폭포수' 모델, 증분 개발 및 재사용 지향 개발이 있습니다.

- 요구사항 엔지니어링은 소프트웨어 사양(명세서)을 개발하는 프로세스입니다.

- 설계 및 구현(Design and implementation) 프로세스는 요구사항 명세서를 실행 가능한 소프트웨어 시스템으로 전환하는 것과 관련이 있습니다.

- 소프트웨어 검증은 시스템이 그 사양에 부합하는지, 그리고 시스템 사용자의 실제 요구를 충족하는지 확인하는 과정이다.

- 기존 소프트웨어 시스템을 새로운 요구 사항에 맞게 변경하면 소프트웨어 진화가 이루어집니다. 소프트웨어가 계속 유용하도록 진화해야 합니다.

- 프로세스에는 변화에 대처하기 위한 프로토타이핑 및 증분 전달(prototyping and incremental delivery)과 같은 활동이 포함되어야 합니다.

- 시스템 전체에 지장을 주지 않고 변경이 이루어질 수 있도록 반복적인 개발 및 전달을 위한 프로세스를 구성할 수 있습니다.

- 프로세스 개선에 대한 주요 접근 방식은 프로세스 오버헤드를 줄이는 민첩한 접근 방식(agile approaches), 보다 나은 프로세스 관리 및 소프트웨어 엔지니어링 관행을 기반으로 한 성숙도 기반 접근 방식(maturity-based approaches)입니다.

- SEI 프로세스 성숙도 프레임워크는 우수한 소프트웨어 엔지니어링 관행의 사용에 기본적으로 해당하는 성숙도 수준을 식별합니다.