계획 → 요구분석 → 설계 → 구현 → 시험 → 유지보수
프로젝트 계획
· 일정 계획
· 조직 계획
· 위험 분석
◆ 중앙 집중식 조직
특징
- 의사 결정이 빠름
- 소규모 프로젝트에 적합
- 초보 프로그래머를 훈련시키는 기회로 적합
단점
- 보조 프로그래머의 역할이 모호
- 한 사람의 능력과 경험이 프로젝트의 성패 좌우
◆ 분산형 조직
특징
- 작업 만족도 높음
- 의사 교류 활성화
- 장기 프로젝트에 적합
단점
- 책임이 명확하지 않은 일이 발생
- 대규모 프로젝트에 적합하지 않음(의사 결정 지연 가능)
◆ 혼합형 팀조직
특징
- 초보자와 경험자를 분리
- 프로젝트 관리자와 고급 프로그래머에게 지휘권한이 주어짐
- 의사교환은 초보 엔지니어나 중간 관리층으로 분산
단점
- 기술인력이 관리를 담당
- 의사 전달 경로가 김
※ 리팩토링
◆ 정의
소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함' 을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다.
사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.
◆ 목적
· 버그를 찾아내기 쉽게 한다. (디버깅 자체는 리팩토링이 아니지만, 리팩토링을 하면 프로그램이 정리되어 숨어 있는 버그를 찾아내기 쉬워진다.)
· 기능을 추가하기 쉽게 한다. (기능 추가 자체는 리팩토링이 아니지만 리팩토링을 하면 프로그램에 새호운 기능을 추가하기 쉬워 진다. 리팩토링이 되지 않은 코드는 일반적으로 기능을 추가하면 소스코드가 점점 더 복잡해지고 결국 구조가 무너진 소스가 된다. 하지만 리팩토링을 한 코드는 탄탄한 구조를 갖게 되어 기능추가에 있어서 편할 것이다.)
· 리뷰하는 것이 쉬워진다. (리팩토링하여 깨끗해진 코드는 읽기 쉽고 이해하기 쉬워진다. 이는 결국 코드리뷰에 있어서 쉬워짐을 의미한다.)
◆ 리팩토링의 예제
1. 메소드 정리
(1) Extract Method
그룹으로 묶을 수 있는 코드 조각이 있으면 별도의 메소드로 뽑아낸다. 코드의 목적이 잘 들어나는 메소드의 이름을 짓는다
(2) Inline Method
호출하는 곳에 메소드의 몸체를 넣고 메소드를 삭제한다.
(3) Inline Temp
간단한 수식의 결과값을 가지는 임시변수를 모두 원래의 수식으로 바꾼다.
(4) Replace Temp With Query
어떤 수식의 결과 값을 저장하기 위해서 임시 변수를 사용하고 있다면 이 수식을 뽑아서 새로운 메소드로 만들고 임시변수를 모두 찾아서 메소드 호출로 바꾼다.
(5) Introduce Explaining Variable
복잡한 수식이 있는 경우, 수식의 결과나 수식의 일부에 자신의 목적을 잘 설명하는 이름으로 된 임시변수를 사용한다.
(6) Split Temporary Variable
임시변수에 값을 여러 번 대입하는 경우, 각각의 대입에 대해서 따로따로 임시변수를 만든다.
(7) Remove Assignments to Parameters
파라미터에 값을 할당하는 코드가 있으면 임시변수를 사용한다.
(8) Substitute Algorithm
알고리즘을 보다 명확한 것으로 바꾸고 싶을 때는 메소드의 몸체를 새로운 알고리즘으로 바꾼다.
2. 객체간의 기능 이동
(1) Move Method
메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면, 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만들고 이전 메소드는 간단한 위임으로 바꾸거나 완전히 제거한다.
(2) Move Field
필드가 자신이 정의된 클래스보다 다른 클래스에 의해서 더 많이 사용되고 있다면, 타켓 클래스에 새로운 필드를 만들고 기존 필드를 사용하고 있는 모든 부분을 변경한다.
(3) Extract Class
두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우, 새로운 클래스를 만들어서 관련 있는 필드와 메소드를 예전 클래스에서 새로운 클래스로 옮긴다.
(4) Inline Class
클래스가 하는 일이 많지 않은 경우에는, 그 클래스에 있는 모든 변수와 메소드를 다른 클래스로 옮기고 그 클래스를 제거하라.
3. 데이터의 구성
데이터를 좀 더 쉽게 다루기 위한 여러가지 리팩토링이다.
(1) Self Encapsulate Field
필드에 직접 접근하고 있는데 필드에 대한 결합이 이상해지면 get/set 메소드를 만들어 필드에 접근한다.
(2) Change Value to Reference
동일한 인스턴스를 여러 개 가지고 있는 클래스가 있고 여러개의 동일한 인스턴스를 하나의 객체로 바꾸고 싶으면 그 객체를 참조객체로 바꾸어라.
(3) Replace Array with Object
배열의 특정 요소가 다른 뜻을 가지고 있다면, 배열을 각각의 요소에 대한 필드를 가지는 객체로 바꾼다.
◆ 리팩토링의 한계
리팩토링은 언제라도 가능한 것은 아니다. 리팩토링을 적용할 수 없는 경우도 있다.
· 프로그램이 아직 동작하지 않는 경우
만들고 있는 중이라 아직 동작하지 않는 프로그램은 리팩토링 할 수 없다. 리팩토링하기 전에 먼저 동작하는 프로그램을 만들어야만 하며, 또한 설계와 코딩이 좋지 않아 버그투성인 사용할 수 없는 프로그램에 대해서도 리팩토링 할 수 없다.
· 시간이 얼마 남지 않았을 경우 (마감일에 가까워 졌을 때)
납기 기간이 매우 엄격한 코드를 리팩토링하는 것은 현명한 방법이 아니다. 리팩토링이라는 것은 시간이 지나면서 차차 효과가 나타나는 것이다. 또한 납기 직전에 커다란 리팩토링은 하지 않도록 하는 것이 좋다.
소프트웨어 개발 방법론
◆ 많이 사용되고 있는 4가지 패러다임
폭포수 모델 , 원형 패러다임 , 나선형 모델 , 4세대 기법
◆ 패러다임의 선정은 프로젝트의 성격, 소요되는 기간, 방법과 도구 등에 의해 이루어 진다.
1 . 폭포수 모델
특징
· 고전적 라이프 사이클 패러다임
· 가장 오래되고 널리 사용되는 패러다임
· 순차적인 접근방법
· 하향식 접근방법
장점
· 프로젝트 진행과정을 세분화하여 관리 용이
단점
· 대규모일 수록 부분 순환이 발생하기 때문에 순차적인 흐름을 따라가는 데 어려움이 있다.
· 요구사항을 초기에 구체적으로 기술하기 어렵다.
· 결과가 후반부에 가서야 얻어짐으로써, 중요한 문제점이 뒤에 발견된다.
2. 원형 (Prototyping) 패러다임
적용 환경
· 목표를 정하였으나 속성을 어떻게 만족시킬지 모르는 경우
· 사용자의 요구사항이 무엇인지, 요구를 어떻게 변경될지 구체적으로 모르는 경우
· 개발자들이 고객의 요구를 불완전하게 이해하고 있는 경우
· 고품질 시스템의 요구사항을 명세화하기 어려울 경우
◆ 프로토타입 개발
· 장점
- 개발 초기에 미리 결과물을 확인할 수 있다는 점에서 사용자의 이해를 도운다.
- 개발의 초기 단계에서 수정 / 보완할 사항을 미리 파악할 수 있다.
- 분석 및 설계 과정에 사용자가 동참하여 즉각적인 피드백을 줄 수 있다.
· 단점
- 일회적 프로젝트나 대규모 프로젝트의 개발에는 적용하기 쉽지 않다.
- 불완전한 요구사항을 바탕으로 시제품이 만들기 때문에 결과적으로 불완전한 시스템을 산출하여 수정과 보 완 에 많은 인력과 시간이 투입된다.
완료된 프로토타입을 이용하여 시스템을 구현하였으나 원하는 시스템이 아닐 경우
재 작업 실시
3. 나선형 패러다임
◆ 폭포수 모델과 원형 패러다임의 장점에 새로운 요소인 위험 분석을 추가하여 만든 것 (높은 위험도가 예상될 경우)
◆ 위험을 관리하고 최소화하려는 것이 이 패러다임의 주 목적
◆ 나선을 돌면서 점진적으로 완벽한 시스템 개발
◆ 각 나선은 4단계로 나뉘어져 있다.
1) 계획 및 정의 단계
2) 위험 분석 단계
3) 개발 단계
4) 고객 평가 단계
◆ 나선형 패러다임
· 장점
- 비용이 많이 들고 시간이 오래 걸리는 대형 시스템구축(대형사업)에 가장 현실적인 접근방법 성과를 보면서 위험부담을 줄일 수 있는 방법
· 단점
- 모델자체가 복잡하여 프로젝트 관리가 어려움 , 상업용 제품에는 이방법보단 프로토타입이 적합
4. 4세대 기법
◆ 요구사항 명세서로부터 실행코드를 자동으로 생성할 수 있게 하여주는 방법
◆ 현재 4GT 도구들은 자연언어를 실행코드로 바꾸어 줄 만큼 정교하지 못하다.
◆ 형식 규격 언어로 표현하려는 노력 ( 예 : EER(Enhanced Entity-Realtionship) 모델로 만들어진 명세서에서 데이터베이스의 코드가 생성)
5. 애자일(Agile) 방법론
◆ 기존 방법론은 프로젝트의 본질적인 목표보다 계획 수립, 문서화, 품질 관리등 부수적으로 수행되는 작업이 오버헤드(overhead) 비용을 발생시킨다.
◆ 1990년대 민첩성과 실용성을 앞세운 가벼운 경량급 개발 방법론인 애자일 기법을 제안
◆ 특징
· 기술적 부채 해결
· 리팩토링 활용
· 객체지향 기법의 적용
◆ 애자일 기법
· 장점
- 빠른 프로토타입과 짧은 릴리즈 → 소프트웨어 개발 성공률을 높일 수가 있다.
- 작은 프로젝트부터 쉽게 도입 → 비용과 위험도도 상대적으로 낮다
· 단점
- 성공 사례가 많지 않다 → 개발자와 고객이 함께 협업
사용자 스토리를 작성
테스트케이스를 작성
자원을 추정
릴리즈 계획의 수립
- 참여와 소통, 개인의 성숙도, 상호협력이 중요
- 개발 프로세스 및 소프트웨어 공학에 관한 수준 높은 기술이 필요
6. 익스트림 프로그래밍(XP)
◆ XP는 애자일 소프트웨어 개발 방법론 중 가장 많이 알려진 방법이다.
◆ XP는 의사소통, 단순함, 피드백, 용기, 존중 등 5가지의 가치에 시초
◆ XP는 개발 속도를 높이는 가속 기술이며, 그 중심은 단순한 디자인 정신, 테스트 우선프로그래밍, 리팩토링이라 할 수 있다.
※ 사용자 스토리 (user story)
◆ 사용자 스토리는 고객이 원하는 기능을 짧게 표현해 놓은 것
- 고객과 직접 상의하고 작성한다.
- 간략한 설명이나 키워드를 포함하는 짧은 문장
- 스토리 작성은 다음을 가정한다
1. 요구사항은 변할 수 있다.
2. 요구사항을 정확히 알지 못할 수가 있다.
- 사용자와 개발자가 지속적으로 대화
◆ 좋은 사용자 스토리
1. 독립적이다.
2. 협상 가능하다.
3. 사용자와 고객에게 가치가 있다.
4. 추정 가능하다.
5. 작다.
6. 테스트 가능해야 한다.
