[알쓸신잡] 소프트웨어 개발 방법론

[소프트웨어 개발 방법론]

소프트웨어 공학

- 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문

- 여러가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 함

- 1968년 NATO 회의에서 소프트웨어의 위기를 타개해야 한다는 의견이 나왔고 처음으로 소프트웨어 공학이라는 용어가 생성

소프트웨어 개발방법론과 프로젝트 관리

- 소프트웨어 개발방법론 : 마케팅과 같이 성공을 위해서 해야 할 여러 일들에 대한 전략적인 측면의 일

- 기술적인 역할과 책임을 규정

- 주요 산출물을 서술하고 구성

- 비즈니스 이슈를 해결하기 위한 근간을 정의

- Waterfall, OOP, CBD, UP, Agile

- 프로젝트 관리 : 영엄과 같이 성공을 위한 운영적인 측면의 일

- 관리적인 역할과 책임을 규정

- 산출물을 만들어 내기 위한 일을 서술하고 구성

- 일의 계획과 관리를 위한 근간을 정의

- PMBOK, PRINCE2

Waterfall의 단계

- 소프트웨어 개념

- 요구사항 분석

- 아키텍쳐 설계

- 상세설계

- 구현과 디버깅

- 시스템 테스트

Waterfall 장점

- 시스템 개발에 필요한 태스크들을 한눈에 파악 가능 (사후 관리 유리)

- 각 단계가 매우 명확하다

- 대규모 시스템 개발 프로젝트의 프레임워크를 제공

Waterfall 단점

- 실제 시스템 개발 패턴에 맞지 않음 (개발하기 전과 개발 한 뒤의 생각이 다를 수 있음)

- 이전 단계에 대한 오류 수정 및 추가 개선이 용이하지 않음

- 종종 엄청난 양의 문서 작업을 야기한다 (각 단계별로 문서를 작성하기 때문)

- 시스템 테스트 하다가 좋은 아이디어가 생각나면 설계 단계부터 다시 시작

실제적인 프로그램 개발의 단계

- 시스템 명세서 (없을수도 있음)

- 짜보고 고치기

- 출시 (못할 수도 있음)

실제적인 프로그램 개발의 장점

- 최소한 프로그램을 개발하여 내놓는 면에서는 가장 빠른 방법

- 프로그래머들이 가장 선호

- 관리자의 입장에서 이러한 방법을 사용는 프로그래머가 가장 능률이 뛰어난 것으로 보인다.

- 만드는 시간이 빠르기 때문

실제적인 프로그램 개발의 단점

- 프로그램의 유지 및 개선이 어렵다

- 프로그래머가 변경되면 코드를 알기가 어렵다. (새롭게 다시 시작해야함)

- 프로그래머의 시간과 노력이 가장 비효율적이다

- 시스템 상의 오류, 누락, 개선 요구사항이 발견 되었을 때에는 늦었다.

- 오류에 대한 검증 및 수정이 불가능할 정도로 많이 발견되는 경우가 많다.

범위, 일정, 비용의 준수

- 범위, 일정, 비용을 모두 준수했지만 시장에서 별로 가치가 없다면?

- 시장 및 고객에게 무엇이 가치가 있는지에 따라 신축성 있게 조정해야 한다.

일정과 예산의 합리성(불확실성의 원추)

- 일정과 예산은 정확하게 추정을 할 수 있는가?

- 개발자마다 생산성이 다르기 때문에 비용산정에 처음부터 정확하게 반영할 수 없다.

- 프로젝트를 수행해 나가면서 일정과 예산을 수정해 나간다.

- 초기에 하는 비용산정은 그저 추정일 뿐이다.

- 프로젝트가 시작되면 예측하지 못한 변수와 다양한 외부요인으로 달라 질 수 있다.

요구사항의 정의

- 모든 요구사항은 반드시 구현해야 하는가?

- 발주자들은 보통은 포괄적인 요구사항을 정해놓고 발주를 한다.

- 요구사항의 변경들을 개발업체가 수용하면서 개발을 해야한다.

- 모든 요구사항을 반드시 구현 하지 않으면 애자일 개발방법론을 적용하기 어려움

상습적 야근의 생산성 효과

- 야근하지 않으면 열심히 일하지 않는다?

- 과학적으로도 잘못됨

- 제조업 중심으로 발전한 우리나라의 산업 구조는 업무 성과가 투입 시간에 비례한다고 여기는 경영자가 많음

- 공장을 예로 들면 근무 시간이 길수록 새로운 상품들을 많이 나옴

- 하지만 소프트웨어 개발의 경우 오랜 시간동안 하면 오히력 생산성이 떨어짐

- 예술관련 일을 하는사람들은 출퇴근 시간이 자유로움

- 즉, 상상력을 위해서라도 쉬어야함

기존 프로젝트 수행방식의 한계

- 프로젝트 초기에 구체적인 요구사항들을 도출하기 어려움

- 프로젝트 중간에 발생하는 요구사항의 변경을 반영하기 어려움

- 프로젝트 과정 중 중간 산출물을 많이 요구함

-  PM 중심의 명령과 통제 방식 때문에 구성원은 수동적으로 바뀌고, 커뮤니케이션은 매우 부족