티스토리 뷰

앱 개발 계획 수립

개발할 앱의 내용에 대한 앱 개발 계획서 작성

프로젝트 기획서, 문화콘텐츠 기획서, 준비된 개발 환경과 선정된 개발 방법을 바탕으로 개발 계획을 수립할 수 있다.
업무 분석과 사용자 분석을 바탕으로 개발 계획을 수립할 수 있다.

앱(app)은 원래 응용 프로그램(application program)의 줄인 말이다. 응용 프로그램은 우리가 컴퓨터에서 일상적으로 사용하는 오피스, 동영상/오디오 플레이어, 압축 프로그램, 웹 브라우저 등과 같은 프로그램에 대한 통칭이다. 모바일 장비에서 실행되는 소프트웨어를 일컬어서 스마트 앱 혹은 줄여서 앱이라 한다. 따라서 앱 개발 계획을 수립하기 위해서는 기본적으로 소프트웨어 개발 방법론에 근거하여 앱 개발 계획을 세우는 것이 바람직하다.

앱 개발 계획서 즉, 소프트웨어 개발 계획서를 작성하기에 앞서 먼저 소프트웨어 개발 프로세스에 대한 이해와 소프트웨어 개발 프로세서 모델에 대하여 먼저 공부할 필요가 있다. 어떤 소프트웨어 개발 프로세서 모델을 사용하는가에 따라 앱 개발 계획서의 일정과 필요한 인력, 예산, 산출물 등이 변경될 수 있기 때문이다.

소프트웨어 개발 프로세서 모델

소프트웨어 개발 프로세스란 소프트웨어를 개발해 나가는 단계나 과정으로, 소프트웨어의 탄생, 즉 소프트웨어에 대한 계획에서부터 소멸 즉, 사용 종료되는 시기까지의 소프트웨어가 거쳐야 하는 단계들을 말한다. 이렇게 소프트웨어 개발 프로세스는 프로젝트 비용 산정과 개발 계획을 수립하는 기본 골격이 되며, 이는 프로젝트 관리를 용이하게 한다. 소프트웨어 개발 프로세스를 고려한 개발을 할 경우 프로젝트 진행 방향을 명확하게 파악할 수 있기 때문에 사용 종료가 될때까지 각 단계를 고려하여 계획을 세울수있으며, 그 계획에 따라개발하면 프로젝트 도중에 시행착오로 인한 낭비를 최소화하며 목표에 도달할 수 있게 된다는 장점이 있다.

소프트웨어 개발 프로세스는 개략적으로 계획, 요구 분석, 설계, 구현, 테스트, 유지 보수로 나눌 수 있다. 이 단계들을 어떻게 운영하느냐에 따라서 소프트웨어 개발 프로세스가 다양하게 개발되 고 있다. 프로세스를 단계로 나누어 진행하면 소프트웨어의 문제를 나누어 여러 개발 단계에서 다룰수있는데, 이렇게하면개발비용이적게든다. 또한개발을진행하는동안각단계별로 품질과 진도를 점검할 수 있는 장점도 있다. 소프트웨어는 완성되기 전까지는 개발 진도를 확인할 방법이 없는데, 단계적 개발을 하면 중간에 산출물로 진도를 확인하는 것이 가능하며 일정 조절도 가능하다.

요구 분석 단계는 개발해야 될 소프트웨어를 이해하는 단계로, 두 가지 세부 과정을 가지고 있다. 첫 번째가 해결해야 할 문제를 이해하고 분석하는 일인데, 요구를 제시하는 사람도 구체적으로 잘 알지 못하는 것을 파악하는 어려운 작업이다. 두 번째가 찾아진 요구를 정리하는 즉, 문서로 남기는 작업이다. 이 문서를 바탕으로 설계와 개발의 방향이 정해지는 중요한 부분이라고 할 수 있다.

설계 단계는 문서화된 요구를 구현하기 위한 계획을 만드는 단계이다. 시스템 설계는 코딩, 테스팅, 유지 보수 단계에 크게 영향을 주기 때문에 소프트웨어의 품질에 영향을 주는 가장 결정적인 요인이 된다.

구현 단계는 설계 단계의 결과물로 실제 소프트웨어를 만드는 과정이다. 자세한 사항은 개발 언어와 사용도구에 의해서 많은 영향을 받게된다. 그리고 개발된결과물, 즉 프로그램의품질에 따라 후속 단계인 테스팅과 유지 보수 단계의 작업에 많은 영향을 미치게 되는 단계이다. 따라서 프로그램은 관리하기 쉬운 형태로 개발되어야 한다. 테스트는 생산된 소프트웨어의 품질을 관리하는 중요수단이다. 사실요구분석단계와 설계단계는 테스트를 할 수 없는 문서의 형태를가지고 있기때문에, 구현단계는 실질적인 문제점을 찾을 수 있는 첫 단계가된다. 테스트는적용단위에 따라 단위 테스트, 통합 테스트가 있으며, 개발자들이 직접 테스트하는 내부 테스트와 개발팀 외부 인력이 테스트하는 외부 테스트와 최종 인수 테스트 등 다양하다.

소프트웨어 개발 프로세스 모형의 가장 기본이 되는 모형은 다음에 소개하는 폭포수 모형이다. 이 모형을 기반으로, 프로젝트의 특성이나 개발 환경 및 컴퓨터 기술의 발전됨에 따라 변형된 여러 프로세스 모형들이 생겨나고 있다

폭포수(waterfall) 모형

폭포수 모형은 건축에서 사용하는 방법과 유사하다. 아래 그림과 같이 폭포수가 떨어지는 듯한 모양이기 때문에 폭포수 모형이라고 한다. 건축에서는 오랜 경험과 표준화된 공정 및 부품들이 있기 때문에 시행착오 없이 폭포수처럼 진행을 해도 무리가 없다. 그러나 소프트웨어 개발에서 폭포수 모형을 따르기는 쉽지 않다. 건축물은 시공한 뒤에는 변경을 할 수 없지만 소프트웨어는 변경이 가능하기 때문에 요구 사항 변경이 빈번하게 일어나게 된다. 일반적으로 프로젝트에서는 요구 사항 분석을 담당하고 설계하는 아키텍트 역할을 하는 사람들과 구현하는 사람들이 분리되어 있다. 문제는 고객의 요구 사항 변경 요청은 아키텍트의 역할이 끝난 뒤에 이루어지기 때문에 바로 구현하는 사람들에게 할당된다. 아키텍트가 전체적인 관점에서 이런 요구 사항들을 조율한다 면 문제없겠지만 협소한 시각을 가진 구현자에게 요구 사항 추가 · 삭제가 맡겨질 경우 소프트웨 어 전체에 기형적인 부분이 발생할 가능성이 커진다

그림에서 보듯이 각 단계가 다음 단계 시작 전에 끝나야 하며 순차적으로 진행되어 앞뒤 단계의 상호작용이없이단순하다. 폭포수모형은 개발대상이 아주 단순하거나 적용분야를 잘 알고 있는 경우에 적합하다. 전체 절차가 단순하기에 초보자도 쉽게 적용할 수 있으며 개발 대상에 대한 분석과 문서화가 충분히 실행된 후에 구현된다는 것이 장점이다. 하지만 초기 분석 단계가 길어지면 코딩과 검증 및 테스트단계가 지연될수있으며, 각 단계마다 문서화에 대한 요구가 커서 부담이 있다는 단점이 있다. 짧은 개발 기간이 요구되는 현재와 같은 상황에는 부적절한 모형이다. 또한 개발이 완료될 때까지 사용자로부터의 피드백을 받을 수 없어서, 사용자의 요구 사항의 반영 속도가 아주 늦기 때문에 변화가 늦은 분야에만 적용할 수 있다.

프로토타이핑 모형

프로그램 개발에 대한 전문적인 지식이 없는 대부분의 사용자는 정확한 요구 사항을 제시하기 어려우며 완성된 시스템을 정확하게 상상할 수 없기에 프로젝트 실현 가능성에 대한 확신을 할 수 없다. 따라서 축소된 시스템을 만드는 과정을 보면서 실제 프로젝트의 개발 단계를 이해하고 완성된 프로토 타입에서 최종 개발된 시스템을 상상할 수 있게 되어 제대로 된 요구 사항을 제시할 수있게된다. 마치 건축에서 실제 건축물을 만들기 전에 설계도에 따라 작은 모형을 만들듯이 소프트웨어의 기본적인 기능을 알아보기 위해서 원형을 만들고 이후의 소프트웨어 완성품을 예측해 보는 방법이다.

프로토타이핑 모형은 폭포수 모형이 가지는 사용자 피드백 반영이 늦다는 단점을 개선하고, 사용 자의 요구를 프로젝트 초기에 더 정확히 추출하기 위해서 도입된 모형이다. 요구 분석 후에 프로토 타입을 개발하여 알고리즘의 타당성을 확인하고 인터페이스 제작을 사용자에게 검증받을 수 있다.

프로토타이핑 모형에는 개선과 보완을 통해서 실제 목표 시스템으로 발전시켜 나가는 방법이 있는데 이를 진화적(evolutionary) 프로토타입이라고 한다. 반면에 요구 분석 단계에서 사용자의 요구 도출에만 사용하고 버리고 도출된 사용자 요구를 바탕으로 실제 구현하는 방법이 있을 수 있다. 요구 분석만을 위한 프로토타입을 개발할 경우에는 개발 비용을 가능한 한 적게 투자하고 개발할 수 있어야 한다.

프로토타이핑 모형은 프로토타입을 개발하는 비용과 분석 과정이 길어지는 단점이 있지만 프로토 타입 개발 과정에서의 경험으로 후반 개발 비용이 절감될 뿐만 아니라 시스템이 가시화되는 개발 후반에 사용자의 요구 변경이 거의 없어지므로 변경으로 인한 개발 비용을 감소시킬 수 있다.

하지만 프로토타이핑 모형의 가장 큰 단점은 프로토타입이 개발 목표 시스템이라고 믿고 소프트웨 어가 거의 완성되었다고 오해하는 점이다. 이는 개발 기간 단축 요구로 이어지고 이로 인한 부실 개발이야기될수있다. 또 다른 단점은 원래 개발 목표로 한시스템보다 더 많은 기능을 기대하게 만든다는 점이다.

프로토타입 모형은 사용자의 요구가 명확하지 않거나 사용자나 개발자가 개발 대상에 대하여 잘 이해하지 못하고 있거나 기술적으로 확신이 없을 경우에 적용하기 유리하며 이제까지 사용되지 않았던 혁신적인 기술이 사용될 때 사용하기에 적합한 모형이다.

점증형(incremental) 모형

점증적 모형은 개발 주기가 짧은 개발 대상 시스템을 개발할 때 적용하기 용이한 모형이다. 시스템 을 먼저 개발할 부분과 추후에 개발할 부분으로 구별하여 빠른 시간 내에 먼저 완성품을 개발하고 다음 버전에서 기능을 추가하거나 향상시키는 형태로 개발 대상 시스템을 개선하는 모형이다. 초기 버전은 기능이 부족할 수도 있으나 사용자들을 교육하거나 관심을 집중할 수 있는 기능을 할 수 있으며 개선에 대한 기대감을 높일 수 있는 모형이다.

증가 부분이 추가된 새로운 시스템이 생산될 때마다 반복적으로 테스트를 할 수 있는 기회가 있어서 안정적 시스템의 구현이 가능하고, 프로토타이핑 모형과 같이 초기 버전으로 사용자의 요구 사항을 피드백할 수 있다는 장점도 있다.

증가부분 추가에는 두 가지 방법이 있을 수 있다. 첫번째는 개발할 시스템의 기능을 여러 부분으로 나누고 그중 핵심 부분을 먼저 개발하여 릴리스한 후에 나머지 부분을 부분적으로 개발하여 추가하는 단계를 여러번거쳐 최종 완성 시스템을 구축하는 점증적방법이고, 두번째 방법은 처음부터 전체 시스템을 대상으로 개발하되 릴리스할 때마다 새로운 기능을 추가하여 더 완벽히 개발하는 반복적 방법이다.

나선형(spiral) 모형은 보엠(Boehm)에 의해 제안된 점증적 모형의 한 종류이다. 소프트웨어 개발 의 특성상 요구 분석이 처음부터 완벽하기는 힘들고 또한 사용자의 요구 사항도 계속적으로 증대된 다. 따라서 제품의 성숙도를 차츰 높여 가는 개발 방법이 사용되는데, 이것을 나선형 개발 방법론이 라 한다.

나선형 모형은 패키지 제품 등을 개발할 경우 유용한 방법이다. 처음부터 많은 기능과 거창한 제품의 스펙을 생각하고 개발하는 것이 아니기 때문에, 일정에 맞추어 제품의 사양을 조절하고, 현재 사양의 개발에 집중 할 수 있다. 기능간의 우선순위를 정할수 있는기회가 있기 때문에 핵심기능을 명확히 할 수있고, 부가적인기능을 다음 버전으로 미룰 수 있는지표를 마련할 수 있다.

재정적 또는 기술적으로 위험 부담이 큰 경우에 점진적 개발로 한 번에 대규모 프로젝트를 개발하 다가 실패하는 위험을 줄일 수 있으며, 반복적으로 사용자 요구 분석, 개발, 테스트의 단계를 거침으로서 완성도 높은 프로젝트를 수행할 수 있다. 하지만 관리가 복잡하고 위험 분석이 부실할 경우 실패할 확률이 높으며 적용 사례가 적은 모형이다.

V 모형

V 모형은 폭포수 모형에 시스템 검증과 테스트 작업을 강조한 모형이다. 페리(Perry)에 의하여 제안된 것으로 폭포수 모형에 소프트웨어 테스트 프로세스를 강화한 모형이다. 즉, 요구 분석에서 구현까지의 작업은 상세화하는 작업이고 구현에서 인수까지는 시스템의 검증에 집중하는 모형이 다. 모듈의 상세 설계를 단위 테스팅 과정에서 검증하고 시스템 설계는 통합 테스트 단계에서 검증하며,사용자의 요구사항은 시스템 테스팅 과정에서 검증한다. V자 모형 상이를 점선으로 연결한 의미는 각 테스트 단계에서 오류를 발견하였을 때 왼쪽의 요구 분석, 설계, 구현 단계로 되돌아 갈수 있음을 의미한다.

V모형은 모든 단계에 검증과 확인과정이 있어 오류를 줄일 수 있기에, 높은신뢰성이 요구되는 응용 분야 즉, 의료 기기나 원전 제어와 같은 프로젝트에 적합하다. 하지만 생명 주기의 반복을 허용하지 않아 변경을 다루기 쉽지 않으며, 작업이 종료되고 리뷰 후에는 변경할 수 없다. 따라서 이 모형은 요구 사항이 아주 확실하여 개발하는 동안 변경되지 않는 경우는 아주 적합할 수 있으나 현실적으로 많은 변경이 요구되기에 적용에 어려움이 있는 모형이다.

일정 중심 설계 모형

일정 중심 설계 모형은 단계적으로 여러 차례의 반복적인 사이클을 거친다는 면에서 점증형 모형과 유사하지만 반복 사이클이 확정적으로 계획되어 시작되는 것이 아니라 정해진 일정에 맞추기 위해서 중간에 중단할 수 있다는 점이 다르다. 사용자 요구에 대하여 우선순위를 정하고 이를 기초로 각 사이클을 계획한다. 초기 단계에 중요한 기능을 먼저 완성하여 시스템의 골격을 완성하 고 중요도가 떨어지는 기능은 일정에 따라 구현한다. 따라서 일정을 반드시 지켜야 하는 경우에 적용하기 좋은 모형이다. 단점은 우선순위가 낮은 기능은 시스템에 포함되지 않을 수 있음에도 분석하고 설계하는 데 자원을 낭비할 수 있다는 것이다.

진화적 출시(evolutionary delivery) 모형

진화적 출시 모형은 고객의 요구를 여러 사이클에 걸쳐서 개발하여 보여 주면서 제품을 개선하여 나가는 모형이다. 버전 하나를 개발하여 고객에게 보여 주고 고객 반응에 따라 제품을 개발하고 발전적 으로 출시해 나간다. 진화적 출시 모형은 프로토타이핑 모형에서와 같이 여러 사이클에 걸쳐 사용자 요구를 파악하지만 모든 사용자 요구를 반영하는 프로토타이핑 모형과 달리 고객의 요구를 어느 정도 반영하여 반응이 좋으면 발전적 버전을 개발하여 출시한다는 점이 다르다. 먼저 기본 기능을 우선으로 하여 시스템의 핵심을 개발하여 고객의 반응을 보아 가면서 기능을 확장한다. 진화적 출시 모형은 시스템의 구조가 계획되는 동안 사용자에게 피드백을 받아 개선해 나간다는 장점이 있으나 관리나 기술적인 세심한 계획을 하지 않으면 프로젝트 진행에 문제가 발생할 수도 있다.

UI/UX Design

UI/UX 환경 분석

UI/UX 계획 수립

사용자 리서치

UI/UX 요구 분석

UI/UX 콘셉트 기획

UI 아키텍쳐 설계

댓글
댓글쓰기 폼