티스토리 뷰

앱 개발 계획 수립

개발 일정 및 환경 계획에 대한 앱 개발 계획서 작성

개발 일정, 투입 인력, 소요 비용, 활용 장비, 적용 시스템을 계획하고 선정할 수 있다.

소프트웨어 개발 계획

소프트웨어 개발 계획은 프로젝트가 수행되기 전에 소프트웨어 개발 타당성을 분석하고 소프트웨 어 개발 범위를 결정하며 필요한 자원, 비용, 일정 등을 예측하는 작업이다. 소프트웨어 개발 계획 수립을 해야 하는 이유는 계획 수립을 통해 주어진 기간 내에 최소의 비용으로 사용자를 만족시킬 수 있는 시스템을 개발하기 위해서이며 소프트웨어 개발 과정에서 발생할 수 있는 여러 가지 위험성을 최소화하여 소프트웨어 개발 성공률을 높일 수 있기 때문이다.

소프트웨어개발계획수립후에는목표, 개발범위, 타당성분석, 추진전략등이포함된시스템 정의서와 소프트웨어 개발 프로세스 모델, 기본 일정, 예산, 팀의 구성, 관리 기준, 완료 조건 등이 포함된 프로젝트 계획서가 산출된다. 시스템 정의서에 해당하는 개발 소프트웨어의 개발 타당성 분석이나 개발 범위에 대한 고려는 이전 학습모듈인 스마트 문화 콘텐츠 발굴, 프로젝트 기획 단계의 교육 내용으로, 중복을 피하기 위해서 여기에서는 소프트웨어 개발에 대하여 직접 관련된 부분만을 언급할 것이다.

소프트웨어 개발 계획서 작성

개발계획서의 작성은 시스템을 구현 할 수있는 최적의 개발전략을 인적. 기술적. 투자자금 등으로 구체화하는 작업이다. 개발 계획서에는 개발 절차, 문서화, 일정, 인원, 예산, 개발 환경 등의 계획이 분야별로 나열되어야 한다.

개발 절차 계획 부분에는 개발에 사용할 프로세스 모형, 산출물의 정의(products definition)가 포함되어야 한다. 문서화 계획 분야의 경우 적용하는 프로세스 모형이나 개발 방법론이 정해지면 생산되어야 하는 산출물이 결정된다. 인원·조직 계획 부문에는 개발 조직과 소요되는 개발자의 등급별 기능별 인원과, 필요하다면 유지 보수 단계에 필요한 인원에 대한 내용도 언급될 필요가 있다. 소프트웨어 개발 계획서에서 인원 계획은 전체 개발비를 산정하는 데 가장 중요한 요소이므로 제대로 작성하지 않을 경우 개발비의 정확한 예측이 불가능하게 된다.

예산계획부분에는 크게 직접경비와 간접경비로 나눌수 있다. 직접경비는 소프트웨어를 개발하는데 필요한 필수경비를 말하는것으로 인건비, 장비사용료, 개발도구 구입비등이 포함되는데, 직접 경비의 가장 유동적이며 큰 부분을 차지하는 것은 인건비일 것이다. 인건비는 앞에서 언급한 인력 계획을 바탕으로 계산되므로 인력 계획이 중요하다. 간접 경비는 통신비, 정보 수집비, 회의비, 교육훈련비, 보험료, 도서 구입비, 교통비 등 소프트웨어 개발 활동을 하는 데 필요한 경비로 적절한 확보가 필수적이다.

일정(scheduling) 계획은 프로젝트의 프로세스를 작은 기능으로 구분하고 인력을 각 기능에 분배하 며, 각 기능의 개발 기간으로 일정을 정하는 것이다.개발 환경 계획 부분에는 개발에 사용되는 사용 언어와 개발에 포함되는 개발 도구 혹은 개발 환경을 구성하여 생산성을 높이는 등에 필요한 도구, 개발장비 및 운영장비와 장비 구성과 역할 등에 대한 언급이 필요하다. 여기에서는 앞에서 언급된 프로세스 모형 및 개발 방법론과 관련된 부분은 제외하고 인력 계획과 예산 계획, 일정에 대하여 중점적으로 소개하겠다

일정 계획

일정 계획은 개발할 시스템을 소작업 단위로 분할하여, 투입 예측된 노력을 각 작업에 분배하며 작업의 순서와 일정을 정하는 것이다. 소작업별 개발 기간을 바탕으로 전체 프로젝트의 지연을 방지하고 계획대로 각 작업들이 진행되도록 일정을 계획한다. 계획된 일정은 프로젝트에 인력, 예산 및 기타 자원 투입의 기초자료가 된다. 따라서 계획한 프로젝트일정과 진도에 차질이 발생하면 일정 조정에 가장 영향을 미치는 부분을 파악하여 조치를 취할 수 있다. 프로젝트 일정계획을 위한 도구로는 1950년대에 제임스 켈리(James Kelley)와 모건 워커(Morgan Walker)에 의해서 소개 된 CPM(Critical Path Method)과 헨리 간트(Henry Gantt)에 의해 소개된 간트 차트(Gantt chart)가 대표적으로 사용된다.

일정을 계획할 때는 여러 개의 작은 작업들로 분할하여 각 작업별로 특정 팀에게 할당하여 책임을 지게하여야 한다. 이때 분할된 작업들이 어떤 상호 의존성이 있는 지즉선행작업과 후행작업의 연관성을 확인해야 한다. 또 각 작업이 개발되는 시간이 결정하고 이에 적절한 팀원의 수가 할당되 었는지 확인해야 한다.

프로젝트의 특성에 따라 차이가 있겠지만 인력이나 시간의 투입은 40:20:40 비율을 사용하는 것이 일반적이다. 이 배율의 의미는 자원과 시간을 분석 단계와 설계 단계에 40%, 코딩 단계에 20%, 테스트 단계에 40%를 분배한다는 의미로, 요구 분석 단계가 10~20%, 설계 단계에 20~25%, 코딩단계가 15~25%, 테스팅과 디버깅 단계에 30~40% 정도를 고려하는 것이 통상적이다. 앞에서 언급하 였듯이 이것은 통상적인 지침이며 각 프로젝트의 특성에 맞게 적절한 분배가 필요하다.

  • 작업 분해
    • 개발 대상을 작은 관리 단위로 분할하여 각 소관리 단위별로 관리하는 것이 전체를 대상으로 관리하는 것보다 쉽고 효율적이다. 개발 프로젝트를 여러 개의 작은 관리 단위(소작업)로 분할하 고 파악된 소작업을 계층적으로 기술한 목록을 구성하는 것을 WBS(Work Breakdown Structure) 이라 한다. WBS를 구성하는 일은 일정 계획의 첫 단계에서 작업을 분할할 때 일반적으로 사용되는 방법이다. 나누어진 소작업들은 계획 관리 단계에서 일정 계획과 인력 계획, 비용 산정의 기본 단위로 사용된다.
  • CPM(Critical Path Method) 네트워크
    • CPM 네트워크는 작업을 표시하는 원형 정점(node), 이정표(milestones)를 표시하는 사각 정점, 정점, 그리고 정점 즉, 작업과 작업 사이의 선후 의존 관계를 보여 주는 화살표 형태의 간선(edge) 으로 구성된 네트워크이다. 간선의 화살표가 의미하는 것은 작업의 진행 방향으로,ᅵ 화살표 머리 쪽 작업은 화살표 꼬리 쪽 작업이 끝나기 전에는 시작할 수 없음을 나타낸다. CPM 네트워크를 이용하여 전체 프로젝트 개발 기간을 결정하는 임계 경로(CP: Critical Path)를 파악할 수 있으며 통계적방법을 이용하여 각 작업에 소요되는 시간을 산정 할 수 있다. 또 각작업에 대한시작 시간을 정의하여 작업간의 경계시간을 계산 할 수 있게한다. CPM네트워크는 각작업의 순서와 의존 관계 그리고 동시에 수행될 수 있는 작업을 한눈에 파악할 수 있는 장점이 있다. 일반적으로 CPM 네트워크는 소작업과 이정표를 같이 표시한다. 중간 점검에 해당하는 이정표를 넣어서 다시 구성하면 아래와 같다. 한 이정표에서 다음 이정표에 도달하기 전에 두 이정표 사이에 있는 모든 작업이 완료되어야만 한다. 예를 들어 작업 J는 이전 이정표와 M7 이정표 사이의 작업 G나 작업 E가 완료되어 이정표 M7에 도달하면 시작할 수 있다. 그림에서 보듯이 CPM 네트워크는 소작업의 의존 관계와 동시에 수행될 수 있는 작업을 직감적으로 보여 주기 때문에 전체 일정 관리에 많이 사용된다. CPM 네트워크에서 작업 간의 의존 관계를 파악하여 각 작업을 시작할 수 있는 가장 빠른 시간 (earliest start time), 각 작업을 끝낼 수 있는 가장 빠른 시간(earliest finish time)과 작업을 시작할 수 있는 가장 늦은 시간(latest start time), 최대한 늦추어 끝낼 수 있는 시간(latest finish time)을 쉽게 찾을 수 있다.
  • 간트 차트(Gantt chart)
    • 간트 차트는 프로젝트를 이루는 각 소작업의 시작과 종료 일정을 한눈에 볼 수 있게 막대 도표를 이용하여 나타내는 프로젝트 일정표이다. 각 막대는 해당 작업의 시작에서부터 종료까지의 시간을 보여 준다. 간트 차트는 CPM 네트워크와 같이 파악된 WBS를 기초로 만들어지므로 선행 작업 분석 단계가 필요하다. 간트 차트는 CPM 네트워크로부터 만들 수 있으며 특히 개발 자원 투입 계획, 즉 예산의 지출 관리, 자원 배치와 인원 계획에 유용하게 사용되지만 작업 경로를 표시할 수 없는 단점이 있다. 그리고 계획의 변화에 따라 간트 차트를 처음부터 다시 작성해야 하므로 변화에 대한 적응성이 약하며, 계획수립 또는 수정때 주관적 수치에 영향받기 쉬운 단점이있다.
인원 · 조직 계획

소프트웨어는 거의 대부분을 사람이 직접 코딩하여 개발하기 때문에 다른 제품과 달리 개발 조직 구성 방식이 개발에 많은 영향을 준다. 여기에서 언급하는 인원 · 조직 계획은 프로젝트에 참여하는 각 구성원들의 역할을 할당하고 서로 어떤 방식으로 통제 및 소통할 것인가를 정의하는 것이다. 인원·조직계획에 크게 영향을 주는 요소는 프로젝트 수행기간, 작업의 특성, 팀구성원사이의 의사소통방식, 예산, 품질등이 있으며 이 요소들에 의해 팀구성방법은 크게 달라 질 수 있다.

프로젝트 팀구성방법은 의사결정군의 분배 형태에 따라 분산형 팀구성, 중앙집중형팀구성, 계층적팀구성으로 나눌 수 있다. 분산형 팀구성은 모든팀원이 의사결정에 참여하는 민주주의식 팀 구성이다. 의사 결정을 민주주의식으로 결정하기 때문에 팀 구성원의 적극적 참여가 있고 작업 만족도가 높으며 따라서 이직률이 낮은 것이 장점이다. 팀 구성원은 서로의 일을 검토하고 다른 구성원이 일한 결과에 대하여 같은 그룹의 일원으로서 책임을 진다. 여러 사람의 의사를 교류하므 로 복잡하고 이해되지 않는 문제가 많은 장기 프로젝트 개발에 적합하지만 팀 구성 방법 중 가장 많은 의사 소통 경로를 갖는 구조이기 때문에 의사 교환 비용의 증대로 대규모 프로젝트에는 적합하지 않다. 모든 구성원이 만족할 수 있는 해결 방안을 찾기 힘들기 때문에 개인의 생산성이 떨어지는 단점이 있다.

중앙 집중형 팀 구성은 팀 구성원들은 한 관리자의 의사 결정에 따라 작업을 하고 그 결과를 보고하는 구성 방식으로 책임 프로그래머 팀 구성이라 불리기도 한다. 프로젝트 수행에 따른 모든 권한과 책임이 한 관리자(책임 프로그래머)에게 주어지기 때문에 책임 프로그래머의 기술적 관리 적 능력에 전적으로 의존하는 형태이다. 책임 프로그래머 한 사람에 의해 의사 결정이 이루어지기 때문에 의사 결정 속도가 빠르고 의사 교환 경로를 줄일 수 있지만 팀의 다른 구성원의 의견은 무시 될 수 도있으며 책임 프로그래머에게 과중한 부하가 걸릴 수 있다. 한사람이 통제할 수 있는 비교적 소규모 프로젝트에 적합하며 초보 프로그래머로 구성된 팀에 적합하다.

혼합형팀구성은분산형팀구성과중앙집중형팀구성의단점을줄이기위해두가지팀구성 방법을 혼합한 형태로, 계층형 팀 구성이라고도 한다. 5~7명의 초급 프로그래머로 작은 그룹을 만들어 각 그룹을 중견 프로그래머가 직접 관리하게 한다. 권한은 프로젝트 리더와 고급 프로그래머에게 분산하여 부여하고 의사 교환은 초급 프로그래머와 중간 계층 관리자로 분산한다. 프로젝 트 리더가 검토회(walkthrough)를 통해 문제점을 토론하고 해결하며, 그룹 간의 일정 및 업무를 조절한다. 개발 대상이 계층적으로 잘 분할될 경우에 적용하기 적합한 조직 형태이다.

하위 프로그래머들을 관리하기 위해서는 중간 관리자를 중견 기술 인력이 담당하게 되는데, 이들 기술 인력이 관리를 담당하기 때문에 개발보다는 관리에 시간을 투입하느라 기술력을 사장시킬 수 있으며 기술 인력이 조직과 업무 관리 능력을 갖춰야 한다는 단점이 있다.

예산 계획

소프트웨어의 특성상 개발 비용의 대부분이 인건비라는 것은 이미 알려진 사실이다. 따라서 소프 트웨어 개발 프로젝트의 경우 예산은 인-월(man-month)를 척도로 하는 것이 일반적이다. 이 말은 인-월이 나오면 여기에 간접 비용을 추가함으로써 예산은 거의 확정된 것으로 볼 수 있기 때문에, 소프트웨어 프로젝트의 예산은 인-월에 초점이 두고 있다고 보면 될 것이다.

비용 산정 기법은 그 방법에 따라 하향식(top-down) 비용 산정 기법, 상향식(bottom-up) 비용 산정 기법 그리고 수학적 산정 기법으로 분류할 수 있다.

하향식 비용 산정 방법은 개발 대상 소프트웨어의 규모를 예측하여 과거 경험을 바탕으로 소요 인력과 개발 기간을 추산하는 방식이다. 소프트웨어의 규모는 원시 코드 라인 수(lines of code)나 기능 점수(functional point)로 나타내며 이를 바탕으로 과거 프로젝트 수행 경험에 의하여 인-월 을 구한다. 상향식 비용 산정 방법은 개발 대상 소프트웨어를 소작업으로 분해하고 이 소작업에 소요되는 기간을 산정한 후에 투입 인력과 참여도로 최종 소요 인건비를 산정한다.

  • 하향식 비용 산정 기법
    • 하향식 비용 산정 기법은 개발 경험이 많은 개발자들이 모여 과거의 프로젝트 실행 경험을 바탕으 로 하여 비용을 추산하는 방법이다. 과거에 수행된 프로젝트의 경험을 바탕으로 하지만 프로젝트 의 특성이 다르며 엄청난 속도로 발전하는 기술로 인하여 과거의 경험치를 그대로 적용하기에는 문제가 많다. 또한 몇몇 전문가의 과거 경험을 바탕으로 주관적으로 비용을 추정하기에 비과학적 이라고할수있다. 하향식 비용산정기법에는 전문가 감정기법, 델파이기법 등이 있다.
      • 전문가 감정(expert judgement) 기법
        • 전문가 감정 기법은 일반적으로 조직 내에서 간단히 판단할 때 사용하는 방법으로, 유사한 경험이 많은 두 명 이상의 전문가들에게 비용 산정을 의뢰하는 기법이다. 간편하고 신속하게 비용을 산정 할 수 있으며 의뢰자로부터 신뢰를 얻을 수 있지만 전문가의 주관에 따라 크게 차이가 날 수 있다. 또한새로운프로젝트는과거와는다른개발및운영환경에서다른기술및개발도구를 사용하여 개발될 수 있기 때문에 과거에 경험한 프로젝트 경험으로는 예측할 수 없을 수도 있다.
      • 델파이(Delphi) 기법
        • 델파이 기법은 너무 주관적인 결과가 생산될 수 있는 전문가 감정 기법의 단점을 보완하기 위해 보다 많은 전문가의 의견을 종합하여 산정하는 기법이다. 가능한 한 주관적인 의견을 배제를 위하 여한명의 조정자와 여러명의 전문가 비용 산정팀이 구성된다. 조정자는 각비용산정전문가들에 게 개발될 시스템에 대한 정보를 제공하고 전문가들은 제공된 정보를 바탕으로 익명으로 소요 비용을 산정한다. 조정자는 각 전문가의 산정 결과를 다른 산정 요원들에게 배포하고 전문가들은 제공된 다른 전문가들의 의견을 이용하여 다시 익명으로 예산을 산정한다. 비용 산정 요원 간의 의견이 거의 일치할 때까지 이 과정을 반복한다. 전문가들이 상호 의견을 조정하는 델파이 기법이 합리적으로 보이기는 하지만 생성된 결과가 현실 상황과 관계없는 경우도 발생하기 때문에 예측이 빗나가는 경우가 많이 발생하는 단점이 있다.
  • 상향식 비용 산정 기법
    • 상향식 비용 산정 기법은 프로젝트의 소작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하기 때문에 추산된 예산이 비교적 객관적이다. 상향식 비용 산정 기법에는 모델을 사용하는 수학적 산정 기법인 COCOMO 모형이나 기능 점수 모형이 주로 사용된다. 각 모형에는 비용 산정 공식을 사용하는데, 이는 과거 유사한 프로젝트의 소요 비용을 기반으로 하여 경험적으로 유도된 것이다.
      • COCOMO 모형
        • COCOMO(COnstructive COst MOdel) 모형은 B. 보엠(Boehm)에 의해 제안된 모형으로 개발될 소프트웨어의 규모인 원시 코드 라인 수(LOC)와 개발할 소프트웨어의 특성을 고려한 여러 가중치 가 포함된 공식을 사용하여 비용 산정 기법이다. 1981년에 처음 제안된 후 기술의 발전에 따라 1995년에 COCOMO II로 발전하여 소프트웨어 개발비 견적에 널리 통용되고 있다. 같은 규모의 프로그램이라도 그 특성에 따라 비용이 다르게 산정되며 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력 인-월으로 나타난다. 초기 COCOMO 모형은 소프트웨어의 복잡도 혹은 유형에 따라 단순형(organic model), 반분리형(semi-detached model), 내장형(embedded model)으로 분류하여 비용 산정 공식을 만들었다. 하지만 소프트웨어 기술의 발전과 사용 환경의 변화함에 따라 비용 산정 단계 및 적용 변수의 구체화 정도를 구분하여 기본형(basic), 중간형 (intermediate), 상세형(detailed)으로 발전하여 개발 소프트웨어의 특성에 따라 많은 수의 가중 치를 다루게 되어 복잡한 수식의 이해가 필요하다. 여기에서는 COCOMO의 기본적인 아이디어만 을 살펴보도록 하겠다. 단순형 프로젝트는 중소 규모의 일괄 자료 처리, 과학 기술 계산, 비즈니스 자료 처리 시스템이, 중간형 프로젝트는 트랜잭션 처리나 운영 체제, 데이터베이스 관리 시스템과 같은 시스템 소프트 웨어 개발이, 내장형 프로젝트는 실시간 시스템이나 제어 시스템과 같은 하드웨어를 제어하는 용도의 소프트웨어 개발이 각 유형에 속한다. 기본 공식은 아래와 같고 소프트웨어의 특성에 따라 a, b값에 차이가 있다. 단순형은 2.4, 1.05 반분리형은 3.0, 1.12, 내장형은 3.6, 1.20이다. 여기에서 KDSI(Kilo Delivered Source Instruction)는 개발 대상 소프트웨어의 라인 수를 1,000으로 나눈 값이 된다.
      • 기능 점수(function point) 모형
        • 기능 점수 모형은 사용자 관점에서 요구 기능을 정량적으로 산정하여 소프트웨어의 규모를 측정하 고 이를 바탕으로 소프트웨어 개발과 유지 관리를 위한 비용과 자원을 산정하는 방법이다. 기능 점수 모형은 1979년 IBM의 알브레이트(Albrecht)에 제안되었으나 발표 초기에는 관심을 받지 못하였다. 그러나 최근에는 그 유용성과 간편성으로 비용 산정 기법 가운데 최선의 평가를 받고 있으며, 우리나라에서도 앞에서 설명한 투입 공수에 의한 방식에서 기능 점수를 사용하는 방식으 로 가기 위해 한국소프트웨어진흥원, 한국소프트웨어산업협회 등에서 많은 노력을 하고 있다. 기능 점수 모형은 개발 이전에 업무량을 추산할 수 있으며, 소프트웨어 수명 주기에서 개발뿐만 아니라계획, 운영, 유지보수등전수명주기에적용이가능하기때문이다. 그동안사용된투입 공수 산정 방식이 개발자 관점에서 개발비를 산정하는 방법이라면 기능 점수 모형은 사용자 관점에서 사용 기술과는 무관하게 개발 규모를 측정할 수 있는 방법이다
        • 사실 개발 전에 소프트웨어의 정확한 LOC를 예측하기는 힘들다. 따라서 소프트웨어를 개발하는 데필요한5개의기능즉, 입력, 출력, 질의파일, 인터페이스기능의개수를파악하고이들기능의 개수로 소프트웨어의 크기와 복잡도를 추정하는 근거 자료로 하여 시스템 개발 기간과 소요 인력을 추산한다. 각 기능별로 소프트웨어 개발에 미치는 영향에 따라 가중치를 가지게 되는데, 파악된 5개각기능의개수에기능별가중치를곱하여계산된값을모두더하면기능점수가된다. 가중치 는 프로젝트 개발 경험과 프로젝트의 특성에 따라 다르게 적용될 수 있다. 입력은 사용자가 시스템 에 입력하는 입력 화면을, 출력은 시스템에서 사용자에게 제공하는 출력 화면 혹은 보고서를 말한 다. 따라서 입력 기능의 개수는 입력 화면의 개수를 말하는 것으로 각 화면이나 보고서에 포함된 세부 데이터의 개수가 아니다. 질의는 사용자가 시스템 내부의 자료를 요청하는 데 필요한 대화형 질의를 말하며 내부에 보관된 파일을 변경하지 않고 단순히 조회하는 기능이다. 파일은 시스템이 보관해야 하는 자료를 말한다. 한국소프트웨어산업협회의 가이드에서는 이들 5가지 기능을 다른 이름으로 부르고 있다. 입력은 외부 입력(EI), 출력은 외부 출력(EO), 질의는 외부 조회(EQ), 파일은 내부 논리 파일(ILF), 인터페이스는 외부 연계 파일(EIF)로 달리 호칭하지만 기본 의미는 동일하다.

소프트웨어 개발 계획서 작성

개발 계획서의 내용은 프로젝트의 성격과 사용자의 요구에 따라 변경될 수 있는 부분이다. 개발 계획서에는 프로젝트 개요, 인력, 일정, 조직 구성, 작업, 품질 관리, 산출물 등에 대한 내용이 언급되어야 한다

  1. 개요
    • 프로젝트 개요
    • 프로젝트 산출물
    • 정의, 약어
  2. 자원 및 일정예측
    • 자원
    • 일정
  3. 조직구성 및 인력배치
    • 조직 구성
    • 직무 기술
  4. WBS
  5. 기술 관리 방법
    • 변경 관리
    • 위험 관리
    • 비용 및 진도 관리
    • 문제점 해결 방안
  6. 표준 및 개발절차
  7. 검토 회의
    • 검토 회의 일정
    • 검토 회의 진행 방법
    • 검토 회의 후속 조치
  8. 개발 환경
  9. 성능 시험 평가
  10. 문서화
  11. 유지 보수
  12. 설치, 인수
  13. 참고문헌및부록

UI/UX Design

UI/UX 환경 분석

UI/UX 계획 수립

사용자 리서치

UI/UX 요구 분석

UI/UX 콘셉트 기획

UI 아키텍쳐 설계

댓글
댓글쓰기 폼