Interview
개발 프로세스
요구분석 및 시스템 명세 작성 :
- 문제분석 단계라고도 하며, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 사용자와 함께 정확히 정의하는 단계이다.
- 개발하고자 하는 소프트웨어의 성격을 정확히 이해하여 이를 토대로 개발 방법과 필요한 자원 및 예산 예측 후 요구명세를 작성한다.
설계 :
- 설계단계에서는 앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정한다.
- 크게 시스템, 프로그램, UI(User Interface) 설계로 나뉘며, 시스템 구조설계는 시스템을 구성하는 내부 프로그램이나 모듈 간의 관계와 구조를 설계하고, 프로그램설계는 프로그램 내의 각 모듈에서의 처리 절차나 알고리즘을 설계한다.
구현 :
- 설계 단계에서 논리적으로 결정한 문제 해결 방법을 프로그래밍언어를 사용하여 실제 프로그램을 작성한다.
- 이때 프로그래밍 기법은 구조화 프로그래밍과 모듈러 프로그래밍 두 개로 나뉜다.
- 구조화 프로그래밍 : 조건문, 반복문을 사용하여 프로그램을 작성하고, 순차구조, 선택구조, 반복구조의 세 가지 제어구조로 표현하며, 구조가 명확하여 정확성 검증과 테스트 및 유지보수가 쉬운 장점이 있다.
- 모듈러 프로그래밍 : 프로그램을 여러 개의 작은 모듈로 나누어 계층 관계로 구성하는 프로그래밍 기법으로, 모듈별로 개발과 테스트 및 유지보수 가능하며, 모듈의 재사용 가능하다는 장점이 있습니다.
테스트 :
- 테스트 단계에서는 개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사하고 평가하는 일련의 과정이다.
- 미처 발견하지 못한 오류를 발견할 수 있기 때문에 매우 중요한 과정입니다.
배포 및 유지보수 :
- 배포와 유지보수 단계는 시스템이 인수되고 설치된 후(배포) 일어나는 모든 활동을 지칭한다.
- 이후 일어나는 커스터마이징, 구현, 테스트 등 모두 이 단계에 포함되므로 소프트웨어 생명주기에서 가장 긴 기간을 차지한다
- 유지보수의 유형에는 수정형, 적응형, 완전형, 예방형 총 네 가지가 있다.
- 수정형 유지보수 : 사용 중에 발견한 프로그램의 오류 수정 작업을 진행한다.
- 적응형 유지보수 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업한다.
- 완전형 유지보수 : 시스템의 성능을 향상하기 위한 개선 작업한다.
- 예방형 유지보수 : 앞으로 발생할지 모를 변경 사항을 수용하기 위한 대비 작업을 수행한다.
전통적인 개발 프로세스
- 기존에 존재하고 있던 개발 프로세스는 워터폴(Waterfall) 방식이 있다.
- 영어에서 주는 직관적인 느낌 그대로, 폭포와 같이 한 방향으로만 프로세스가 진행되는 개발 과정을 뜻한다.
- 실제로 한국어로도 “폭포수 개발 방식” 이라고도 한다.
- 이런 워터폴 개발 방식은 실제 출시 기한을 정해놓고 순차적으로 프로세스가 진행시켜 어플리케이션(소프트웨어)를 완성해 배포하기 때문에 실제로 배포되어 유저에게 전달되는 시간이 오래 걸린다.
- 또한 실제 디자인 또는 개발된 화면을 시각적으로 확인할 수 있는 단계는 이미 많은 단계가 지나온 시점이기 때문에 어떤 버그나 수정 사항이 생기면 다시 처음으로 돌아가 수정되기 때문에 일정과 비용 등 많은 부분에서 에로 사항이 생기게 된다.
- 대부분 출시 시점에 소프트웨어의 신뢰성 및 안정성을 보장 받기가 힘들며, 배포 직후에도 수많은 버그를 마주하게 될 가능성이 있다.
모던 개발 프로세스
- 전통적인 개발 프로세스에서 벗어나기 위해 만들어진 프로세스 중 하나가 애자일(Agile) 방식이다.
- 이 애자일 방식은 ‘스프린트(sprint)’ 라고 불리는 짧은 주기의 개발 사이클을 계속해서 반복한다.
- 계획에 의존하여 형식적인 절차를 끝까지 따라야 하고 중간에 뒤로 회귀할 수 없는 전통적인 개발 프로세스보다는 훨씬 효율적으로 개발에 착수할 수 있다.
- 애자일 개발 프로세스를 적절히 사용하면 빠르게 문제를 해결해 하루에도 여러 번의 배포가 가능해진다.
- 이러한 방식은 SaaS(Software as a Service, 서비스형 소프트웨어)를 개발하는 데에 적합하다.
| 워터폴 | 애자일 | ||
|---|---|---|---|
| 장점 | 프로세스가 길고 순서가 잡혀 있으므로 팀의 규모에 상관 없이 따르기 쉬움 | 개발 주기가 정해져 있으므로 새로운 프로젝트를 안정적으로 시작 가능 요구 사항이 확정되어 있으므로 프로젝트를 실행하기 수월하며, 개발 목표를 자주 변경하지 않아도 됨 프로젝트의 전 과정에 필요한 예산 및 자원이 초기에 확정되어 예상 결과와 리스크를 통제하기 훨씬 쉬움 | - 빠르면서 유연한 개발 과정 짧고 반복적인 스프린트로 구성되어 있어 품질에 초점을 맞출 수 있으므로 빠르게 결함을 인지하고 수정 가능 스프린트를 통한 짧은 반복 과정으로 개발 과정 중에 신속히 제품 변경 가능 |
| 단점 | 개발이 순차적으로 진행되므로 앞 단계가 완성되지 않으면 다음 단계로 넘어갈 수 없어 개발 속도가 느리고 유연성이 떨어짐 테스팅 단계에 이르러서 이슈가 발견되는 경우가 왕왕 있음 개발 요구 사항이 초기에 확정되므로 범위 변경이 자유롭지 못함 | 스프린트에 대한 경험이 있으며 빠른 반복 작업에 익숙한 스크럼 마스터가 필요함 고객이 수많은 변경 사항을 검토해야만 하는 번거로움 발생 팀원이 잘 조직되어 있지 않거나 자립성이 떨어지는 경우 애자일론을 채택할 시 문제가 발생 | |
| 이런 상황에 적합 | 높은 예측 가능성과, 순차적인 프로젝트 타임라인, 사전 확정 예산이 필요한 경우 프로젝트 팀의 경험이 적은 경우 요구사항이 간단하거나, 타임라인이 긴 프로젝트를 수행하는 경우 | - 고성능 소프트웨어 개발 중에서도 특히 소프트웨어 개발을 할 경우 고품질의 결과물과 지속적인 개선에 초점을 맞출 경우 프로젝트가 완벽히 수행될 때까지 결과물을 기다리는 것보다 결과물에 대해 빠른 피드백이 필요한 경우 | |
| 이런 기업 및 팀에 적합 | 개발상의 변경이나 리스크에 덜 민감한 기업 및 팀 제한적인 시간과 자원 탓에 협업이 자유롭지 못한 고객을 둔 기업 및 팀 | - IBM, 시스코, AT&T, 마이크로소프트와 같이 크고 복잡한 회사들이 프로세스를 간소화해 변화에 더욱 신속하게 대응하고자 할 때 고객 및 외부 관계자와 정기적으로 긴밀한 협업을 수행하는 프로젝트 팀 |