Project

  • 프로젝트란 무엇인가?

    • 일정한 기간 안에 일정한 목적을 달성하기 위해 수행하는 업무의 묶음이다. 하나의 프로젝트는 정해진 기간(Time), 배정된 금액(Cost), 투입인력(Quality) 등 일정한 제약조건하에서 각종 요구사항을 수행하는 방식으로 진행된다.

  • 왜 프로젝트가 생겼을까?

    • 어떤 제품을 만드는 데는 여러가지로 많은 문제들이 발생한다.
    • 예상보다 많은 비용을 지출, 약속된 일정 내에 제품을 출시 못함, 고객의 요구사항을 충분히 파악하지 못함, 설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발, 리스크 관리를 하지 않아서 프로젝트 실패, 팀원에 문제가 있어서 불화 발생 등등 수없이 많다.

  • 왜 프로젝트 개발 방법론이 생겼을까?

    • 프로젝트가 작다면 무사히 완성할 수도 있으나, 대규모 프로젝트에서는 어떤 설명없이 프로젝트를 한다는 것은 불가능 하다. 그래서 가능하면 소규모 프로젝트에서도 잘 정리된 스펙 문서가 필요하고 대규모라면 더더욱 그렇다.

    • 게다가 앞으로는 프로그램에 대한 사용자의 기대가 커지면서 소프트웨어에 대한 요구 사항도 더욱 복잡해지고 있어 이러한 모든 요소에 절충이 필요하고 균형을 맞춰야 하기 때문에 더욱 필요해지고 있다

  • 그렇다면 어떻게해야 프로젝트를 잘 만들 수 있을까?

    • 프로젝트를 잘 만들기 위해선 정말 여러 가지가 필요하다. 처음에는 고객의 요구가 있을테고 개발자는 그 경우에 따라서 하나하나 다 만들어야 한다. 중요한 건 소프트웨어이기 때문에 만들었다고 끝이 아니라는 것이다. 다 만들고 난 뒤에도 계속 버그를 수정하고 오류를 고치고, 더 나은 소프트웨어로 가기 위해서 계속 유지하면서 더 좋게 발전시켜 나가야 한다.

    • 옛 사람들도 물론 이걸 모를리 없어서 이 체계를 보기 쉽게 만들었다. 이게 바로 ‘SDLC(Software Devlopment Life Cycle)’ 이다. 그리고 이를 활용해서 만들어진 모델을 Waterfall Model이라고 한다.

Waterfall Model

  1. 요구사항

    1. 추출 -> 일단 말 그대로 고객의 요구를 파악해야 한다. 워크숍을 하거나 설문지로 파악해도 되지만 보다 상세하게 파악할 수 있도록 직접 인터뷰를 하는 게 좋다.

    2. 요구사항은 몇 가지 방법으로 분류할 수 있는데 고객, 기능, 비기능, 성능 등이 있다.

    3. 분석 -> 요구사항들을 수집했으면 그 요구사항들이 관련이 있는 것끼리 묶고, 우선순위를 정한다.

    4. 명세 -> 누구나 잘 알아볼 수 있도록 하기 위해서 문서화를 한다. 문서화를 하면 저장하기도 편하고 자세히 파악할 수 있다. Ex) 요구사항 추적 매트릭스

    5. 검증 -> 문서에서 오류가 나면 엄청난 재작업의 비용이 발생할 수 있기 때문에 확실하게 검증을 해야한다.(요구사항간에 충돌이 생기지는 않는지, 주어진 예산으로 요구사항을 구현할 수 있는지 등등…)

  2. 설계

    1. RFP(Request For Proposal)가 나왔으면 UML(Unified Modeling Language) 같은 다이어그램으로 설계, 모델링하면 된다. 그 종류에는 클래스 다이어그램, 유스케이스 다이어 그램, 상태 다이어 그램, 시퀀스 다이어 그램 등등이 있다. 각각 시간의 흐름이라든지, 사용자의 입장에서 볼 때라든지 사용하는 곳이 다르다.

    2. 분석 툴 같은 경우, DFD(Data Flow Diagram), HIPO Diagram, Pseudo-Code, E-R Diagram 등등이 있다.

  3. 개발

    1. 설계에 맞는 환경의 좋은 프로그래밍 언어가 필요하다.

    2. 당연히 성능에도 신경을 써야 하고, 입력데이터나 프로그램 내의 자료를 어떻게 구성할 것인지(자료 구조 등등)를 고민해봐야 한다.

  4. 테스트

    1. 당연히 개발을 했다고 해서 그 프로그램이 요구사항에 맞춰서 완전히 개발됐다고 할 수 없다. 결함은 일어나기 마련인데 이 결함을 찾기 위한 것이 테스트로, 개발자들은 여러 가지 테스트 케이스를 만들어 낸다.

    2. 이렇게 테스트를 위해서 만들어진 방법론도 있는데 바로 TDD(Test Driven Development)이다.

    3. 테스트를 쉽게 하기 위해서는 제어 흐름 분기를 최대한 간단히 해야 나중에 테스트를 할 때 많은 시간이 소모되지 않는다.

  5. 유지 보수

    1. 테스트까지 완전히 끝났으면 이제 그 소프트웨어가 지속적으로 오류없이 작동하도록 해야한다.

    2. 일단 유지보수가 생기는 정확한 문제점을 파악한다. 여기에는 집중 안 하고 신규 프로젝트에 치중을 한다던지, 사용자 만족도가 안 좋다던지, 버그가 생겼다던지 여러 가지 이유가 있을 수 있다.

    3. 그러나 유지보수를 한다고 해서 다 잘되는 게 아니고 오히려 다른 버그가 생길 가능성도 있다. 또한 유지보수를 하면 인력을 써야하니 비용도 증가하기 마련이다.

  • 최근 대기업에서는 어떤 모델을 쓸까?

    • 가장 보편적으로 사용되는 방식은 애자일 방법론이라 불리는 방식이다.

    • 그 이외 다른 곳에서는 폭포수 모델에서 조금씩 변형된 모델을 사용한다.