---

소프트웨어 공학 실무적 접근

저자

Roger S. Pressman, Bruce R. Maxim 지음

출판사

McGRAW HILL | 2015-01-02 출간

카테고리

컴퓨터/IT

책소개

▶ 이 책은 소프트웨어 공학 이론서입니다. 소프트웨어 공학의 기...

---

애자일 개발

 애자일 개발은 문서가 생성되지 않는다는 것을 의미하는 것이 아니고, 개발 프로세스의 뒤에서 참조되어질 수 있는 문서들을 만든다는 것을 의미한다. 애자일 방법은 종종 라이트 방법(light methods) 또는 린 방법(lean methods)라고도 한다.

[애자일 소프트웨어 개발 선언문]

우리는 소프트웨어를 개발하면서, 또 다른 사람들이 그 일을 하는 것을 도와주면서, 소프트웨어 개발을 위한 더 좋은 방법을 찾아내고 있다. 이 작업을 통해 다음과 같은 것에 가치를 둔다.

        프로세스와 도구보다 개인과 상호작용에

        포괄적인 문서보다 작동하는 소프트웨어에

        계약 협상보다 고객과의 협동에

        계획을 따르는 것 보다 변경에 대한 대응에

즉, 왼쪽 항목도 가치가 있지만, 오른쪽 항목에 더 높은 가치를 둔다.

1  민첩성이란

 민첩성이란 환경의 변화에 재빨리 그리고 효율적으로 적응하는 능력의 의미한다. 애자일에서는 고객을 개발 팀의 멤버로 받아들이고, 커뮤니케이션을 보다 쉽게 할 수 있도록 해주는 팀 구조와 사고방식을 장려한다.

2  민첩성과 변경 비용

[그림 1] 개발에서의 시간에 따른 변경 비용

 소프트웨어 개발에 있어서 전통적으로는 변경 비용이 시간이 증가함에 따라 비선형 형태로(짙은 실선) 비용이 급속하게 증가한다. 하지만 잘 설계된 애자일 프로세스는 변경 비용 곡선이 평평하게 되도록 하고, 소프트웨어 팀이 과도한 비용을 쓰지 않고 또 개발시간에 영향을 받지 않으면서 나중에 변경하는 것이 가능하게 해준다고 한다. 애자일 프로세스는 소프트웨어가 점증의 형태로 릴리스 되고, 점증 내에서 변경을 보다 잘 제어할 수 있기 때문에 변경 비용을 감소시켜 준다. 또한, 단위 테스팅과 페어 프로그래밍과 같은 다른 애자일 실무와 연관되어 있으면 변경을 하는 데 드는 비용이 적어진다.

페어 프로그래밍 : 한 개의 컴퓨터에 두 명의 프로그래머가 앉아 컴포넌트의 코드를 작성하는 소프트웨어 개발 접근법. 키보드를 잡고 있는 사람을 driver라고 하고 다른 한 사람을 Observer, pointer, navigator라고 한다. 실시간 코드 리뷰가 수행된다는 것을 암시적으로 의미한다.

3   애자일 프로세스란?

  애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말이 아니라 애자일(agile=기민한, 좋은 것을 빠르고 낭비 없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다 - 애자일 소프트웨어 개발, 위키백과

3.1  애자일리티 원칙

 애자일 연합은 민첩성을 달성하기 원하는 사람들을 위해 12가지 애자일리티 원칙을 정의하였다.

1)   가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시킨다.

2)   개발 후반부일지라도 요구사항 변경을 반겨라. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

3)   작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두 달 간격으로 하되 더 짧은 기간을 선호하라.

4)   비즈니스 쪽의 사람들과 개발자들은 프로젝트 진행하는 동안 같이 일해야 한다.

5)   동기부여가 된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 자원을 주고 그들이 일을 끝내리라고 신뢰하라.

6)   개발 팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

7)   작동하는 소프트웨어가 진척의 주된 척도이다.

8)   애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.

9)   기술적 탁월성과 좋은 설계에 대한 지속적 관심이 민첩성을 높인다.

10)  간결함-처리하지 않은 작업의 양을 최대로 해주는 기술-은 필수적이다.

11)  최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 나온다.

12)  팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

3.2  애자일 개발 전략

 "... 아무도 민첩성을 반대하지는 않는다. 실질적인 질문은 다음과 같은 것이다. 민첩성을 얻기 위해 가장 좋은 방법이 무엇인가? 중요한 것은, 고객의 오늘의 요구를 만족하고 오랜 기간 동안 요구를 만족하도록 확장 가능한 품질 특성을 가지고 있는 소프트웨어를 어떻게 개발하나?이다. ... 두 학파의 좋은 점만 생각하면 얻을 수 있는 것이 많이 있고, 각 방식을 폄하하면 아무것도 얻을 것이 없다."

 애자일리티와 소프트웨어공학 중에서 선택할 필요는 없다. 그보다는 애자일한 소프트웨어 공학을 정의하라.

4  익스트림 프로그래밍

 익스트림 프로그래밍(eXtreme Programming, XP)은 켄트 백 등이 제안한 소프트웨어 개발방법으로, 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다. -위키백과

4.1  XP 프로세스

 XP는 객체지향 기법을 개발 패러다임으로 사용하고, 네 가지 프레임워크 액티비티(계획 수립, 설계, 코딩, 테스팅) 맥락 안에서 이루어지는 규칙들과 실무들을 포함한다.

[그림 2] 익스트림 프로그래밍 프로세스

●  계획 수립 : 계획 수립 액티비티(=planning game)는 요구하는 출력과 주요 특징과 기능에 대한 요구 사항(스토리)을 수집한다. 고객은 각 스토리를 인덱스 카드에 정한다(우선순위 설정). XP팀은 스토리를 평가하고 비용과 시간(주 단위)을 판단한다. 3주 이상이 된다면 스토리를 더 작은 스토리로 나눠야 한다.

●      XP팀에 의해 개발될 다음 릴리스(다음 점증)에 요구사항 그룹을 어떻게 나눌지 결정하기 위해 고객과 개발자는 같이 작업한다. 개발이 진행되면서, 고객이 요구사항을 변경할 수 있다. XP는 남아 있는 모든 릴리스를 다시 생각하고 그것에 따라 계획을 수정한다.(Small Release)                                                        

●  설계 : XP설계는 엄격하게 KIS(keep it simple), KISS(keep it small and simple) 원칙을 따른다. 복잡한 표현보다는 항상 간단한 설계를 선호한다.(Simple Design)

●   XP에서는 소프트웨어를 객체지향 맥락으로 생각하기 위한 효율적인 방법으로 CRC카드를 사용할 것을 권장한다. CRC(class-responsibility-collaborator) 카드는 객체 지향 소프트웨어설계에서 사용되는 브레인스토밍 툴로, 지금의 소프트웨어 점증에 적합한 객체지향 클래스를 파악하고 구조화한다. 일반적으로 디자인을 시작할 때 어떤 객체가 필요하고 그들이 어떻게 상호 연계할지 여부를 결정하는 데 사용한다.

●   만약 스토리 설계의 한 과정에서 어려운 설계 문제를 접하게 되면, XP는 그 부분에  대해 작동하는 프로토타입을 즉각적으로 만들 것을 권장한다.

●  코딩 : 코딩을 시작하기 전에 단위 테스트를 생성한다.(XP 방식의 핵심 요소) 관련 없는 것은 더 이상 추가하지 않는다(KIS). 코드가 완성되면 즉시 단위 테스트가 이루어지고, 개발자에게 즉각적인 피드백을 제공하게 된다.

●   코딩 액티비티를 진행하는 동안의 핵심 개념은 페어 프로그래밍(pair programming)이다. 이 방법은 실시간 문제 해결과 실시간 품질보증을 위한 메커니즘을 제공한다. 작업을 완수하면 다른 사람이 작업한 것과 통합한다. 통합 팀에 의해 하루 단위로 이루어지고, 다른 경우 페어 프로그래머가 통합의 책임을 진다. "지속적인 통합" 전략은 호환성과 인터페이스 문제들을 피하도록 해주고, 초기에 에러를 발견하는 "스모크 테스팅(smoke testing)" 환경을 제공해 준다.

●  테스팅 : 단위 테스트는 자동적인 수행을 가능하게 해주는 프레임워크를 사용하여 구현되어야 한다. 이렇게 하는 것은 코드가 수정될 때 마다(XP 리팩토링 철학에 따라, 자주) 회귀 테스트 전략을 쓸 것을 권장한다.

●   고객 시험(customer test)이라고도 하는 XP의 인수시험(acceptance test)은 고객에 의해 명시되고, 보여지고, 검토되는 전반적인 시스템 특성과 가능에 초점을 맞춘다. 인수 시험은 소프트웨어 릴리스의 일부분으로 구현되는 사용자 스토리로부터 만들어진다.

4.2   산업계 XP

 Joshua Kerievaky는 산업계 익스트림 프로그래밍(Industrial Extreme Programming, IXP)을 다음과 같이 묘사하였다. "IXP는 XP가 자연스럽게 발전한 것이다. XP가 가진 최소화, 고객 중심, 테스트 구동 정신으로 가득 차 있다. 기존 XP와의 차이점으로 더욱 많이 포함되어 있는 관리, 확장된 고객의 역할, 개선된 기술적 실무 측면이 있다. 대규모 조직 안에서 XP팀이 중요한 프로젝트를 성공적으로 수행하기 위해 고안된 여섯 가지의 새로운 실무과정은 다음과 같다.

●   준비 평가 : 모든 구성원이 준비가 되었는지, 적합한 개발환경이 만들어졌는지, 연관된 수준의 기술을 이해하고 있는지 확인한다.

●   프로젝트 커뮤니티 : 커뮤니티는 기술자와 다른 이해관계자들을 포함해야 하고, 프로젝트 팀을 위해 알맞은 사람들이 필요한 기술과, 훈련이 잘 되어있는지 결정한다.

●   프로젝트 차터링 : 프로젝트를 위한 적합한 비즈니스 명분이 있는지와, 프로젝트가 조직의 전반적인 목표와 목적을 발전시킬 것인지를 결정하기 위해 프로젝트 자체를 평가한다.

●   테스트-주도 관리 : 일련의 측정 가능한 목표를 설정하고, 이러한 목표에 도달하였는지 여부를 결정하기 위한 메커니즘을 정의한다.

●   회고 : 소프트웨어 점증이 인도된 후에 특별한 기술적 검토를 수행한다. 회고라고 불리는 검토에서는 소프트웨어 점증과 또는 전체적인 소프트웨어 릴리스를 통해 "이슈, 이벤트 그리고 학습한 교훈"을 조사한다.

●   지속적 학습 : 고품질 프로덕트를 만들 수 있도록 새로운 방법론과 기술을 배울 것을 권장한다.

5  그 외 애자일 프로세스 모델

 가장 광범위하게 사용되는 애자일 프로세스 모델은 익스트림 프로그래밍이다. 그 외에 네 가지 일반적인 애자일 방법에 대해 살펴본다.

5.1  스크럼(scrum, 럭비 경기의 액티비티에서 유래)

 스크럼은 특정 언어나 방법론에 의존적이지 않으며, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법이다. 프로젝트관리를 위한 상호, 점진적 개발방법론으로, 개발 프로젝트를 위해 고안되었지만 유지보수 팀이나 일반적 프로젝트/프로그램 관리에서도 적용 가능하다. 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같  은 특성을 가지고 있다.

●   솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.

●   개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.

●   개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.

●   날마다 15분 정도 회의를 가져라.

●   항상 팀 단위로 생각하라.

●   원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.

[그림 3] 스크럼 프로세스 흐름

 각각의 프레임워크 액티비티(요구사항, 분석, 설계, 변경, 인도를 포함하는 개발 액티비티)에서, 작업 태스크는 스프린트(Sprint)라 불리는 프로세스 패턴 안에서 생긴다. 스프린트 안에서 수행되는 작업은 스크럼 팀에 의해 당면한 문제에 맞춰지고 실시간으로 정의되고 또한 종종 수정된다.

 스크럼은 빠듯한 시간, 요구사항의 변경, 그리고 사업상 위험한 상태를 가지고 있는 프로젝트에 효과적이고, 프로젝트 우선순위, 구분되어 있는 작업 단위, 커뮤니케이션, 그리고 빈번한 고객 피드백을 강조하는 일련의 프로세스 패턴을 포함하고 있다

●   백로그(Backlog) : 개발할 제품에 대한 요구 사항 목록

●   스프린트(Sprints) : 반복적인 개발 주기, 미리 정의된 타임박스(일반적으로 30일)에 적절하게, 백로그에 정의되어 있는 요구사항을 완수하는 데 필요한 작업 단위.

●   스크럼 미팅(Scrum meeting) : 스크럼 팀에 의해 매일 열리는(일반적으로 15분) 회의. 세 가지 주요 질문내용에 대해서 모든 팀 멤버가 묻고 대답한다.

●   지난번 팀 미팅 이후에 무엇을 하였나?

●   어떤 걸림돌이 있나?

●   다음 팀 미팅 때까지 무엇을 완수할 계획인가?

 스크럼마스터(ScrumMaster)라 불리는 팀 리더는 미팅을 주관하며, 팀원을 코칭하고, 프로젝트의 문제 상황을 해결하는 역할을 하고, 각 멤버들의 답변을 평가한다.

●   데모(Demos) : 소프트웨어 점증을 고객에게 인도해서, 고객에게 구현된 기능이 보여지고 평가될 수 있도록 한다. 데모에는 계획한 모든 기능이 포함되어 있지 않을 수 있지만, 설정된 타입-박스 안에는 인도될 수 있는 기능들이 포함되어 있다는 것을 아는 것이 중요하다.

5.2  동적 시스템 개발 방법(Dynamic Systems Development Method, DSDM)

 DSDM은 통제된 프로젝트 환경에서, 점증적 프로토타이핑을 통해 빠듯한 시간 제약조건 내에 시스템을 개발하고 유지보수하기 위한 프레임워크를 제공하려는 개발 방식이다. 또한, Rapid Application Development (RAD) 방법론에서 발전한 것으로, 초기부터 지속적으로 사용자의 적극적 참여를 통한 요구사항 즉시 반영 방식이다.

●   DSDM의 9개의 철학

●   적극적인 사용자 참여.

●   DSDM 팀은 결정을 내릴 수 있어야 한다.

●   수시로 제품을 인도해야 한다.

●   비즈니스 목적에 맞추는 것은 인도물의 필수 기준이다.

●   반복적이고 점증적인 개발은 정확한 비즈니스 솔루션으로 수렴

●   개발 동안 변경이 가능함

●   요구사항은 상위 수준에서 우선순위가 정해져야 한다.

●   생애주기를 통한 통합 테스팅

●   모든 이해관계자 간의 협업과 협조가 필수적이다.

●   DSDM의 5단계

●   Feasibility Study(타당성 분석)

●   Business Study(비즈니스 요구사항 분석)

●   Functional Model Iteration(기능 모델 반복)

●   Design and Build Iteration (설계와 구현통합)

●   Implementation(구현)

5.3  애자일 모델링(Agile Modeling)

 "애자일 모델링은 소프트웨어-기반 시스템의 효과적인 모델링과 문서화를 위한 실무-기반 방법론이다. 간단히 말하자면, 애자일 모델링은 소프트웨어 개발 프로젝트에 효과적이고 경량적인 방법으로 적용할 수 있는, 소프트웨어를 모델링하기 위한 가치, 원칙 그리고 실무의 모임이다. 애자일 모델은 전통적인 모델들보다 더 효과적이라. 왜냐하면 그것은 약간 좋은 것이고 완벽할 필요가 없기 때문이다. ", AM을 유일한 것으로 만들어주는 원칙들은 다음과 같다.

●   목적을 가진 모델 : 모델을 생성하기 전에 특정한 목표를 가지고 있어야 하며, 목표가 정해지면 어느 표기 유형을 사용할 것 인지와 요구되는 상세함의 수준이 더 명확해 질 것이다.

●   다중 모델 사용 : 필요한 통찰력을 제공하기 위해서 각 모델이 시스템의 다른 측면을 나타내야 하고, 대상으로 삼은 고객에게 가치를 제공해 주는 모델만 사용 하여야 한다는 것을 제안한다.

●   가벼운 여정 : 소프트웨어공학 작업이 진행됨에 따라, 장기적인 가치를 제공하는 모델만을 유지하고, 나머지는 폐기하라. 보관되는 모든 작업 산출물은 변경이 이루어지면 유지보수가 되어야 한다.

●   표현보다 컨텐츠가 더 중요 : 모델링은 대상으로 하는 고객에게 정보를 전달해 주어야 한다.

●   개발툴과 모델에 대해 알기 : 소프트웨어를 개발하기 위해 사용하는 각 모델의 강점과 약점을 이해하라.

●   부분 적 적용 : 모델링 방식은 애자일 팀의 필요에 따라 적응되어야 한다.

5.4  애자일 통합 프로세스(Agile Unified Process, AUP)

 AUP는 크게는 순차적, 작게는 반복적인 철학을 채택하였다. 전통적인 UP 단계 액티비티 -inception, elaboration, construction, transition-를 채택함으로써 순차적 오버레이를 제공한다. 각 액티비티동안 민첩성을 얻기 위해, 그리고 가능한 한 빨리 최종 사용자에게 점증을 인도하기 위해 팀은 반복 수행한다. AUP 반복에서는 다음과 같은 액티비티에 역점을 둔다.

●   모델링 : 비즈니스와 문제 영역에 대한 UML 표기를 생성한다. 하지만, 민첩성을 유지하기 위해 "단지 좋을 정도"이어야만 한다.

●   구현 : 모델은 소스코드로 변환 되어야 한다.

●   테스팅 : XP와 같이 에러를 발견하고 소스코드가 요구사항을 만족시킨다는 것을 확실히 하기 위해 팀은 일련의 테스트를 설계하고 실행시킨다.

●   배치 : 소프트웨어 점증의 인도와 최종 사용자부터의 피드백 획득에 초점을 맞춘다.

●   형상과 프로젝트 관리 : 형상관리는 변경관리, 리스트관리, 팀이 개발하는 것을 제어한다. 프로젝트 관리는 팀의 진척사항을 추적하고 관리하며 팀 액티비티를 조정한다.

●   환경 관리 : 팀에 가능한 표준, 도구, 다른 지원 기술을 포함하는 프로세스 인프라를 조정한다.

6  애자일 프로세스 도구

  협력과 커뮤니케이션 "도구"들은 일반적으로 기술수준이 낮으며, 애자일 개발자간의 정보와 조화를 제공하는 매커니즘("물리적 근접, 화이트 보드, 포스트 시트, 인덱스 카드 그리고 스티커 메모지" 또는 최근 소셜 네트워킹 기술들)을 포함한다. 능동적 커뮤니케이션은 팀 역학(예를 들어, 페어 프로그래밍)을 통해 얻어지며, 반면에 수동적 커뮤니케이션은 "정보 라디에이터"에(예를 들어, 하나의 점증을 구성하는 서로 다른 컴포넌트들의 전체적인 상태를 나타내는 평범한 패널 디스플레이)에 의해 얻어진다. 애자일 프로세스를 지원하는 "도구 모음"은 기술적인 측면보다는 사람 측면에 더 초점을 맞추고 있다.

---

소프트웨어 공학 실무적 접근

저자

Pressman 지음

출판사

McGRAW HILL | 2015-01-02 출간

카테고리

컴퓨터/IT

책소개

▶ 이 책은 소프트웨어 공학 이론서입니다. 소프트웨어 공학의 기...

---

1.   소프트웨어의 본질

 소프트웨어(software 이하 SW)는 프로덕트이며, 동시에 프로덕트를 전달하는 수단이다. ① 프로덕트로써, 소프트웨어는 하드웨어나 네트워크에 의해 구체적인 컴퓨팅 잠재력을 전달한다. ② 프로덕트를 전달하는 수단으로써, 소프트웨어는 컴퓨터를 제어(운영체제)., 정보의 전달(네트워크), 다른 프로그램을 생성하고 제어(소프트웨어 도구와 환경)하는 역할을 한다.

  소프트웨어는 가장 중요한 프로덕트인 정보(한 개의 비트에서부터 많은 데이터로 만든 멀티미디어 데이터)를 생산, 관리, 획득, 수정, 표시, 전파시킨다. 개인적인 관점에서 더욱 유용하게 사용할 수 있도록 개인적인 데이터를 변환하거나, 경쟁력을 향상시키기 위해 사업관련 정보를 관리하거나, 전 세계적인 정보 네트워크로의 게이트웨이를 제공하거나, 다양한 형태의 정보를 획득할 수 있는 수단을 제공한다.

  지난 50년간 하드웨어 성능 개선, 컴퓨터 구조 변화, 저장용량 증가, 다양한 입출력 장치 등으로 인해 컴퓨터 소프트웨어는 더욱 정교해지고 복잡하게 변화하였다. 그러나 개발자의 입장에서는 큰 어려움이 되기도 하였다. 소프트웨어의 규모가 커짐에 따라 개인이 시스템을 개발하는 것이 아닌 여러 개의 팀으로 대체되었다. 하지만 여전히 같은 질문을 하고 있다.

Ÿ   시간 : 소프트웨어가 완성되기 위해 왜 그렇게 많은 시간이 필요한가?

Ÿ   비용 : 소프트웨어 개발 비용이 왜 그렇게 많이 드는가?

Ÿ   소프트웨어를 고객에게 전달하기 전에 왜 모든 에러를 찾지 못하는가?

Ÿ   개발된 프로그램을 유지 보수하는 데 왜 그렇게 많은 시간과 노력을 들여야 하나?

Ÿ   소프트웨어를 개발하고 유지 보수할 때 진척 정도를 측정하기가 왜 어려운가?

  이와 같은 질문들은 소프트웨어의 개발 방식에 대한 질문으로, 이런 질문으로 소프트웨어공학 기술의 필요함을 알려준다.

1.1   소프트웨어 정의

  먼저 프로그램은 특정 문제를 해결하기 위한 명령어들의 정렬된 집합을 말한다. 소프트웨어란 컴퓨터 프로그램과 함께 관련된 문서(요구서, 설계서, 분석서, 에러리포트, 설명서, 테스트 리포트, 테스트 케이스등 유지 보수하는데 사용되고, 개발하면서 필요한 모든 문서들)를 포함한 것을 말한다. 곧 프로그램은 하나의 소프트웨어의 진부분집합이다.

"소프트웨어는 ① 실행되면서 원하는 기능이나 함수, 성능을 제공해 주는 명령어들, ② 프로그램이 데이터를 적절하게 처리할 수 있게 해주는 자료구조, ③ 프로그램의 사용이나 운영을 나타내는 하드카피나 가상 형태의 문서이다.”

- 교재 p5

[그림 1] 하드웨어 고장률 곡선

  그림 1은 하드웨어 고장률을 나타낸다. 욕조 커브(bathtub curve)로 불리는 그래프로, 하드웨어의 생명주기 초기에는 설계나 제조과정의 결점으로 인해 고장률이 높다. 그리고 결점의 수정을 통해 안정적인 수준으로 떨어진다. 하지만 시간의 지남에 환경적 요인(먼지, 진동, 오용, 극단적인 온도 등)을 겪으며 마모되고 고장률은 다시 올라가게 된다

.

[그림 2] 소프트웨어 고장률 곡선

  소프트웨어는 하드웨어와 달리 환경적 요인에 의해서 마모되지 않는다. 즉, 하드웨어는 부품이 마모되면 새것으로 교체하면 되지만 소프트웨어는 오류가 발생하면 코드를 변경해야 한다. 이론상으로는 소프트웨어는 마모되지 않으므로 그림 2와 같이 초기에는 높은 고장률을 보이다가 수정을 통해 낮은 고장률인 곡선의 형태를 보여야 한다. 하지만 소프트웨어는 마모되는 것이 아니라 악화되는 것이다.

그림 2의 실제 곡선(Actual curve)과 같이 뾰족한 고장률 곡선이 나타난다. 생명주기에는 발견되지 않은 결함으로 인해 높은 고장률을 나타낸다. 결함들이 수정되어지면 다시 일정하게 낮아진다. 하지만 새로운 요구사항으로 인해 소프트웨어에 변경이 이루어지면 급격하게 고장률은 높아진다. 수정을 통해 곡선은 낮아지다가 안정적인 고장률로 돌아가기 전에 다른 요구사항으로 인해서 곡선은 뾰족하게 된다. 즉, 변경과정에서 많은 에러를 동반한다. 이러한 반복으로 인해 전체적으로 고장률 수준이 올라가기 시작하면서 소프트웨어는 저하된다. 따라서 변경을 요하는 소프트웨어 유지보수 작업은 하드웨어 유지보수보다 상당히 복잡하다.

  소프트웨어공학 방법론에서는 소프트웨어 고장률 그래프에 변경으로 인해 고장률이 높아진 정도를 줄이기 위해 노력하고 있다.

1.2   소프트웨어 애플리케이션 도메인

  컴퓨터 소프트웨어는 넓게 7가지 범주로 나눌 수 있다.

Ÿ   시스템 소프트웨어(System software) : 컴파일러나 파일 관리 유틸리티와 같은 시스템 소프트웨어는 결정적(소프트웨어의 입력, 처리, 출력의 시간과 순서가 예측 가능)인 정보구조를 처리하고, 운영체제 컴포넌트, 드라이버, 원거리 통신 처리기와 같은 시스템 소프트웨어는 비결정적인 데이터를 처리한다.

Ÿ   애플리케이션 소프트웨어(Application software) : 특수한 업무상의 요구를 해결해 주는 독자적인 프로그램이다.

Ÿ   공학/과학용 소프트웨어(Engineering/scientific software) : '수 처리' 알고리즘으로 사용되는 것들로, 천문학부터 화산학, 자동차 스트레스 분석부터 우주 왕복선 궤도 역학 등 다양하게 응용된다.

Ÿ   임베디드 소프트웨어(Embedded software) : 제품이나 시스템에 내정되어 있으면서 시스템 자체를 위한 특징적인 기능만 구현하고 제어하는 데 사용된다. 예를 들어 전자레인지나 밥솥에 내장된 소프트웨어를 말한다.

Ÿ   프로덕트라인 소프트웨어(Product-line software) : 많은 고객들이 사용할 수 있는 특수한 기능을 제공하기 위하여 설계되어지며, 제한적이고 개인적인 프로덕트나 또는 대규모 고객을 위한 프로덕트에 주안점을 두고 개발할 수 있다.

Ÿ   웹/모바일 애플리케이션(Web/mobile applications) : 네트워크 중심 소프트웨어의 범주에는 다양한 응용 분야가 있을 수 있으며, 브라우저 기반의 앱들과 모바일 기기들에서 동작하는 소프트웨어들을 모두 포함한다.

Ÿ   인공지능 소프트웨어(Artificial intelligence software) : 계산이나 직접적인 방법으로는 분석할 수 없는 복잡한 문제를 해결하기 위해 비수치적 알고리즘을 사용한다. 로보틱스, 패턴인식, 인공신경망 등을 분야로 들 수 있다.

  일부 새로운 시스템이 만들어지고 있지만, 대부분, 기존 애플리케이션이 수정되고, 적용되며, 개선되고 있다. 이처럼 지난 세대의 소프트웨어 종사자들이 각 범주 별로 유산을 남겨두었다. 즉, 재사용성이 가능하도록 하여 새로운 시스템을 개발하는데 있어서 부담을 덜 수 있게 되었다.

1.3   레거시 소프트웨어

  레거시 소프트웨어란 과거에 개발되어 현재에도 사용 중인 낡은 소프트웨어를 말한다. 이는 현대까지도 남아 쓰이는 기술일 수도 있고, 쓰이지 않더라도 현대의 기술에 영향을 주는 경우도 있다. 보통 레거시 소프트웨어는 오래 전에 개발되어서 품질이 낮은 경우가 많다. 즉, 확장 불가능한 설계, 매우 복잡한 코드, 문서화가 되어있지 않은 경우, 변경에 대한 기록이 없는 경우이다. 이 시스템이 "사업의 핵심 기능을 지원하며 사업상 꼭 필요한 것이다."라고 하면 어떻게 할 것인가?

  이 질문에 대해서 한 가지 적합한 해결책은 아무것도 하지 않는 것이다. 만약 레거시 시스템이 사용자의 요구를 만족시키고 믿을 수 있게 작동한다면 이 시스템은 고장 난 것이 아니며, 고칠 필요가 없다. 하지만 레거시 시스템은 다음과 같은 이유로 계속 진화한다.

Ÿ   새로운 컴퓨팅 환경이나 기술이 필요한 경우 소프트웨어가 이를 만족시키기 위해 적응 되어야만 한다.

Ÿ   사업상 새로운 요구를 만족시키기 위해 기능이 향상되어야 한다.

Ÿ   새로운 시스템이나 데이터베이스와 상호 운용될 수 있도록 소프트웨어가 확장되어야 한다.

Ÿ   진화하는 컴퓨팅 환경에서 실행 가능하도록 하기 위해 소프트웨어는 재설계되어야 한다.

  이런 식으로 점진적인 진화가 이루어지면 레거시 시스템은 새로운 환경에 맞게 재공학되어야 한다. 현대의 소프트웨어공학의 목표는 "진화 기초를 둔 방법론은 고안하는 것"이다. 진화 개념이란 소프트웨어는 계속적으로 변화한다는 것으로, 예전 소프트웨어와 새로운 소프트웨어 모두 서로 상호운용되어야 하고 서로 협력해야 한다는 것이다.

2.   소프트웨어 본질의 변화

  산업계를 지배하며 진화하고 있는 소프트웨어에는 네 가지 범주가 있고, 약 10여 년 전까지 초기 단계에 머물러 있었다. 하지만 오늘날 급격하게 변화하였으며 각각의 범주는 다음과 같다.

1.1           웹앱

  월드 와이드 웹은 하이퍼텍스트라는 기능에 의해 인터넷상에 분산되어 존재하는 온갖 종류의 정보를 통일된 방법으로 찾아볼 수 있게 하는 광역 정보 서비스 및 소프트웨어이다. 초기 단계에는 텍스트와 한정된 그래픽만을 사용하여 구성되어 있었다. 시간이 흘러, HTML(HyperText Markup Language)은 개발도구에 의해 확대되어 졌고, 정보 컨텐츠와 함께 계산 기능을 제공하는 것을 가능하게 하였다. 그로 인해 웹 기반 시스템과 응용프로그램(웹앱)들이 생겨났다.

  지난 10여 년 동안, 씨맨틱 웹(Semantic Web) 기술들(종종 Web 3.0으로 표현됨)은 계속 진화해왔다. 그로 인한 정교하고 복잡한 관계형 자료 구조는 이전에는 불가능했던 상이한 정보들에 대한 접근을 가능하게 함으로써, 완전히 새로운 웹앱을 만들 수 있는 길을 열어주었다.

  시맨틱 웹(Semantic Web)은 '의미론적인 웹'이라는 뜻으로, 현재의 인터넷과 같은 분산환경에서 리소스(웹 문서, 각종 화일, 서비스 등)에 대한 정보와 자원 사이의 관계-의미 정보(Semanteme)를 기계(컴퓨터)가 처리할 수 있는 온톨로지형태로 표현하고, 이를 자동화된 기계(컴퓨터)가 처리하도록 하는 프레임워크이자 기술이다. 웹의 창시자인 팀 버너스 리가 1998년 제안했고 현재 W3C에 의해 표준화 작업이 진행 중이다.

- '시맨틱 웹', 위키백과

1.2           모바일 앱

  앱(app)이란 모바일 플랫폼에서 동작하도록 제작된 소프트웨어를 뜻한다. 모바일 앱과 모바일 웹 응용프로그램 사이의 차이점을 인식하는 것은 중요하다. 모바일 웹 응용프로그램(WebApp)은 모바일 디바이스로 하여금 모바일 플랫폼의 장단점을 포함하도록 디자인된 브라우저를 통해 웹 기반의 컨텐츠에 대한 접근을 가능하게 해준다. 즉, 모바일 브라우저를 통해서 실행되는 응용프로그램을 말한다. 반면에 모바일 앱은 특정 모바일OS에서 구동되는 것으로 하드웨어 특징들에 대한  직접적인 접근이 가능한 것을 말한다. 하지만 오늘날, 기술의 발전으로 브라우저들이 디바이스를 컨트롤 가능하게 되었기 때문에 모바일 앱과 모바일 웹 응용프로그램 간의 차이는 점점 흐려지고 있다.

1.3           클라우딩 컴퓨팅

  클라우딩 컴퓨팅은 모든 사용자들이 장소에 구애 받지 않고 광범위한 범위에서 컴퓨팅 장치를 사용하여 컴퓨팅 자원들을 공유하게 하는 인프라스트럭처 또는 "생태계"를 포함한다.

  클라우드 컴퓨팅의 구현은 프론트앤드와 백앤드 서비스들을 포함하는 구조의 개발이 필요하다. 프론트앤드는 클라이언트 디바이스와 백앤드 서비스에 대한 접근을 가능하게 해주는 응용 소프트웨어를 말한다. 백앤드는 서버와 관련 컴퓨팅 자원들, 데이터 저장 시스템, 서버에 상주하는 응용프로그램, 그리고 관리 서버들을 포함한다.

  클라우드 컴퓨팅은 소프트웨어가 전달되는 방식과 존재하는 환경을 바꿀 것이다.

1.4           프로덕트 라인 소프트웨어

  카네기 멜론 대학의 소프트웨어공학 연구소는 소프트웨어 프로덕트 라인을 "특정 시장 분야 또는 임무에 필요하며, 공통으로 관리되는 특징들을 공유하고, 규정된 방식에 따라 핵심 자산들로부터 개발된 일련의 소프트웨어 집약 시스템"으로 정의했다. 즉, 프로덕트 라인 내의 모든 프로덕트들 사이에서 공통적인 컴포넌트, 아키텍처, 모델 등을 활용하여 재사용하고 개발 기간을 단축시켜 생산성을 높이고 품질이 좋은 소프트웨어를 개발할 수 있게 됨을 의미한다.

1. XP ?

애자일 개발 프로세스가 불리는 개발 방법 중의 대표적인 방법으로 10~12개 정도의 구체적인 실천 방법을 정의한다.

비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋으며, 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 크다. - 위키

형식적인 작업 순서와 문서 형식의 산출물을 정의하고 있지 않은 대신 기본 이념인 '4가지 가치'와, xp를 실천하기 위한 작업 항목인 '12가지 실천 항목'을 정의한다.

2. 4가지 가치

2-1. 의사 소통(Communication)

팀의 맴버와 고객과의 의사 소통을 중시한다.

2-2. 단순성(Simplicity)

설계에 얽매이지 않고, 최소한의 필요와 단순함을 지키는 것을 중시하며 변경할 필요가 있으면 언제든지 기존 프로그램의 내부 구조를 개선하는 리팩토링(refactoring)을 행한다.

2-3. 피드백(Feedback)

완성한 프로그램은 바로 실행시켜 테스트를 하고, 그 결과를 피드백해서 개선한다.

2-4. 용기(Courage)

필요한 경우에는 용기를 가지고 설계를 변경한다.

3. 12가지 실천 항목

계획 게임

작은 릴리즈

메타파

단순한 디자인

테스팅

리팩토링

페어 프로그래밍

공동 소유권

계속적인 통합

주 40시간 노동

온 사이트 고객

코딩 표준

1. RUP ?

미국의 UML을 처음으로 제창하고, 표준화에 커다란 역할을 한 Rational사(社)가 개발에서 판매하고 있는 상용 개발 프로세스이다. (Rational사는 2003년에 IBM사에 합병되었지만, 제품의 브랜드는 아직도 그대로 사용되고 있다.)

2. 특징

2-1. 반복형 개발을 전제로 프로젝트 계획 전체를 4가지 단계로 분할하는 지침을 제공한다.

1) 개념화(Inception) 단계

시스템의 전체적인 모습을 정의한다.

2) 구체화(Elaboration) 단계

적용 기술을 평가하고, 어플리케이션 기본 구조를 만들기 위해 일부 중요한 기능을 한정하여 실제로 어플리케이션을 만든다.

3) 구축(Construction) 단계

어플리케이션 기능의 전체를 개발한다. 어플리케이션 기능의 우선 순위가 높은 순으로 단계적으로 개발하는 것을 장려한다.

4) 전이(Transition) 단계

실제 운용을 위해 필요한 작업(종합 테스트, 성능 개선, 운용 교육 등)을 실행한다.

사진 출처(링크)

2-2. 커스터마이징을 전제로 하고 있다.

RUP가 정의하는 작업 항목과 산출물은 의무가 아닌 선택 사항이며, 프로젝트의 설징과 상황에 따라 필요한 것을 선택해서 이용하는 것을 전제로 한다.

개발 프로세스(Development Process)

폭포수형 개발 프로세스(waterfall development process)

1. 폭포수형?

작업의 순환을 회피하고, 물의 흐름처럼 유유하게 진행하는 것을 목표로 하는 방법.

기본적으로 '소프트웨어의 변경에는 많은 비용이 든다.'라는 것과 '소프트웨어보다도 문서를 만드는 비용이 훨씬 적게 든다.'라는 것을 전제로 함

2. 한계

2-1. 요구의 문제

요구 사양을 정하는 사람이 업무 전체를 정확히 이해하고 있다고 할 수 없으며, 의견이 다른 경우와 편견이 원인이 되어 모순된 사양을 결정하는 경우가 있다. 

더욱이 외부 요인에 의해 시스템의 전제 조건과 목표가 바뀌는 경우도 있어, 처음 단계에서 아무리 심사 숙고해서 정의했다 하더라도 나중에 여기저기서 변경 요소가 발생하는 것이 일반적이다.

2-2. 기술의 문제

신기술과 신제품의 적절한 이용 방법과 성능 면의 문제는 실제 프로그램을 작성해서 움직이는 단계에서 알되게는데 폭포수형 개발 프로세스의 경우 이러한 문제는 늦게 인식하게 된다. 그리고 그 단계에서 커다란 문제가 발생하면 프로젝트의 계획 전체가 막대한 영향을 받게 된다.

사진 출처 (링크)

현실 세계와 소프트웨어의 차이를 메울 3가지 단계와 이를 원활히 진행할 모델링 기술.

모델링 : 3가지 단계에 관해서 객체지향은 모델링을 지원한다. 

모델링에서는 하나의 어플리케이션이라도 업무 분석, 요구 정의, 설계의 산출물이 각각 다르다. 현실 세계와 소프트웨어의 차이를 메우는 3가지 단계는 현실 세계를 그대로 받아들이는 시점으로부터 컴퓨터의 상황에 맞추는 시점으로 바꾸어 가는 단계라고도 볼 수 있다.

• 프로그램을 표현하는 기술
• 형태가 없는 소프트웨어를 보는 도구
• 프로그램의 구조와 동작을 표현하기 위해 사용되는 대표적인 다이어그램 - 클래스 다이어그램, 시퀀스 다이어그램, 커뮤니케이션 다이어그램
• 클래스 다이어그램
• 집합론으로 분류, 정리된 현실 세계 사물의 관계를 표현
• 정적인 정보를 표현한다.
• 프로그램이 실행될 때의 구조 표현(클래스의 정의 정보와 클래스 간의 관계 표현)
• 시퀀스 다이어그램, 커뮤케이션 다이어그램
• 역할 분담 표현, 프로그램의 움직임을 표현한다.
• 동적인 정보를 표현한다.
• 상위 공정에서 '정해진 역할을 갖는 복수의 사람과 조직이 협조해서 전체의 일을 달성하는 모습'의 표현에 사용 가능
• 시퀀스 다이어그램

사진 출처

• 실행될 경우에 인스턴스 간의 메소드 호출을 시계열로 표현한다.
• 역할 분담된 사람과 조직이 협력해서 전체의 일을 달성하는 모습을 시계열로 표현한다.
• 시퀀스 다이어그램 모델링 하기
• 커뮤니케이션 다이어그램
• 실행될 경우에 인스턴스 간의 메소드 호출을 인스턴스의 관계 중심으로 표현한다.
• 역할 분담된 사람과 조직이 협력해서 전체의 일을 달성하는 모습을 구조 중심으로 표현한다.
• 유스케이스 다이어그램
• 컴퓨터가 수행하는 일의 범위를 명확하게 표현한다.
• 즉, 시스템의 전체 모습을 개략적으로 파악하는 데 유용한 다이어그램이다.
• 액티비티 다이어그램
• 프로그램의 논리를 기술하기 위해 사용한다.
• 현실 세계의 업무 흐름을 표현할 목적으로 종종 사용한다. 
• 시퀀스 다이어그램과 커뮤티케이션 다이어그램으로 표현 가능하지만, 실제로 일의 모습을 분석할 때는 통상 등장 인물의 역할 분담보다도 전체의 흐름을 이해하는 데 중점을 두기 때문에 직감적으로 표현 가능한 액티비티 다이어그램을 이용한다.
• 스테이트 머신 다이어그램
• 외부로부터의 이벤트에 의해 사물의 상태가 변화해 가는 모습을 표현한다.

UML(Unified Modeling Language, 통합 모델링 언어)

• 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어(위키)
• 객체 지향 기술에 관한 국제 표준화 단체인 OMG(Object Management Group)라는 조직에 의해 표준으로 채택.
• 1990년대 후반에 주요한 개발 방법론의 제안자인 그래디 브츠(Grady Booch), 제임스 럼보우(James RumBaugh), 이바 야콥슨(Ivar Jacobson)이 모여서 도식 표현을 통일하여 만들어진 결과가 UML. (이 3명은 Three Amigos라고 불리고 있다.)

표. UML2.0에 규정된 13종류 다이어그램