노는 게 제일 좋아

이제 계획은 다 세웠으니까 실제로 프로젝트를 진행해봐야겠지? 그러면 이제 고객의 요구(requirement)가 뭔지를 분석해야 요구에 맞는 소프트웨어를 개발하겠지? 그래서 이번엔 요구분석에 대해 알아보려고 한다. 요구 분석이란 새 시스템이나 변경할 시스템의 요구를 결정하는 작업으로 개발자, 관리자, 사용자 모두가 참가해서 서로의 상충되는 요구를 조정하는 단계이다. 이 단계를 잘못하면 프로젝트를 완료해도 망한 소프트웨어가 나올 게 뻔해지니까. 정말 중요한 단계다. 실제로 개발의 첫 단계로 요구 분석을 진행한다. 요구 분석은 다시 두 가지 단계로 나뉜다. 분석 단계와 요구 명세서 작성 단계 분석 단계에서는 현재 상태를 파악하고 요구를 정의하고 문제 해결과 구현될 시스템의 목표를 도출한다. 명세서 작성 과정에..

비용, 일정 예측도 했으니까 이제 누가 할 지를 짜야겠지? 그렇다면 팀은 어떻게 짤지 알아보자 축구팀 짜듯이 그냥 엎어라 뒤쳐라 하면 될까? 묵찌? 그렇게 하면 프로젝트 작살난다. 개개인의 역할을 정의하고 프로젝트에 적절히 할당해서 목표를 이뤄야한다. 비용, 일정 다 잘 예측해도 사람을 제대로 배치 안하면 망한다. //경찰한테 집에 불난 것 끄라하면 제대로 하겠나? 소방관한테 맡겨야지 그래서 서로 협력도 잘하고 상호 작용도 잘 이뤄지게 팀을 짜야한다. 각설하고 소프트웨어 개발은 조금 다른 특징을 가지고 있어서 조직 구성 방법에 따라 품질이 달라질 수 있다. //축구 포메이션이랄까? 선수는 같아도 포메이션 마다 성적이 다른 느낌?? 팀을 구성하는데 고려할 점을 살펴보자 그 후 방법을 살펴볼 것이다. 1. ..

그렇다면 이제 진짜로 일정, 날짜 같은 것을 예측해야겠지? 출시 예정일 같은 것들을 알아야 광고도 찍고 홍보도 하지 그래서 이번엔 스케줄링을 알아보려고 한다. 일정 계획(Scheduling) 개발할 소프트웨어의 규모와 인력 총량이 결정되었으면 이제는 상세한 일정을 잡아야한다. 개발 프로세스를 이루는 소작업들을 파악해서 소작업들의 순서와 일정을 정하는 일, 바로 스케줄링이다. 다시 말해서, 개발 프로세스 모델을 결정하고, 소작업, 산출물, 이정표들을 설정하는 과정이다. 일정계획은 간단하게 4단계라고 말할 수 있다. 1. 작업분해 (Work Breakdown Structure) 2. CPM (Critical Path Method) 네트워크 작성 3. 최소 소요 기간을 구함 4. 간트 (Gannt) 차트 도출..

저번 글에서 말했는데 LOC 산정이 힘들어서 기능점수로 규모를 파악할 수도 있다고 했다. 그래서 이번엔 기능 점수에 대해 알아보려고 한다. **COCOMO II에서 기능점수를 이용한다. 기능 점수란 소프트웨어 시스템이 가지는 기능을 정량화한 것이다. LOC의 예측은 힘들기 때문에 시스템이 가질 기능의 개수로 규모를 판단하는 것이다. ** 이 방법은 경험 중심적인 방법으로 비즈니스 응용 분야의 소프트웨어 개발비용 산정에 정확하다고 한다. ** 기능 점수를 이용해서 예측하려면 생산성 메트릭이 있어야한다. 다시 말해서 단위 시간당 프로그래머의 생산성을 기능 점수로 표현한 자료가 있어야한다. 기능 점수(function points)  소프트웨어 규모를 측정하는 방법  기능적 요구 사항이 중심이 되는 측정 방..

프로젝트 계획 작업에서는 비용 예측과 기간 예측이 정말 정말 중요하다. 그래서 그러한 예측은 어떻게 하는지 알아보자. 소프트웨어 개발 비용의 대부분은 인력에 대한 비용이라서 대부분 MM(man - month)로 초점이 맞춰져있다. 그 이유는 소프트웨어는 다른 공학과는 다르게 원자재라는 것이 거의 없다. 인건비 + 하드웨어 + 소프트웨어 비용 + 사무실, 재료비 등 이것이 비용의 전부인 경우가 많다. 그 또한 인건비가 대부분이라 비용 예측이 사실 노력 예측이라고 말해도 과언이 아니다. 그렇다면 노력 예측은 어떻게 해야하는 것일까? 건축 공사와 달리 개발자 중심 개발자의 능력에 따른 생산성의 차이 다양한 개발 프로세스로 인한 표준화/자동화의 어려움 사람 by 사람이다 보니까 예측이 너무 어렵다. 그래도 비용..

어떻게 해야하는지 청사진을 그려봤으니까 이제 자세하게 배워볼 차례다. 요구 분석의 전 단계인 계획부터 배워보자 계획을 세우는 것은 좋은데 왜 세워야하는지 알고 세우면 더 잘 세울 수 있겠지? 계획의 부재는 프로젝트의 불확실성 일정의 차질, 경비의 초과, 저품질, 높은 유지보수비용, Risk 프로젝트 실패를 초래한다. 그래서 소프트웨어 프로젝트의 계획을 세울 때는 개발 과정과 일정, 비용, 조직, 생산 제품에 대하여 계획을 해야하고 우리가 해결해야 할 문제가 무엇인지 이해하고 정의 해야한다. 즉 SW개발계획서를 도출해내기 위해서는 일정예측: 문제정의>>소작업 정의>> 우선순위 비용 예측: 필요 자원의 정리 및 계산 위험 분석: 위험 요소 판별 같은 일련의 과정을 수행해야한다. **SW개발계획서라는 것은 사..

프로세스들을 앞에서 배웠으니까 이제 어떻게 접근할까?? 라는 방법론에 대해 알아보자 방법론과 프로세스의 비교는 전에도 했지만 서로 다르다. 방법론은 소프트웨어 프로세스의 각 작업을 어떻게 수행하느냐? 라는 것을 알고 가자 방법론은 결국 프로세스를 어떻게 구현할 것이냐? 라고 볼 수 있다. ++ 프로세스는 각 단계의 입력 자료와 결과물을 제시하지만 그 내용이 어떻게 표현되어야 하는지는 규정하지 않았다. 바로 방법론에 따라 다르게 표현하는 것이다. 그렇다면 방법론이 뭐가 있는지 보자 1. 구조적 방법론 복잡한 문제를 쉽게 다루기 위하여 분할과 정복( divide and conquer)원리를 적용한다. 맨 처음에는 시스템 전체를 하나의 프로세스로 보고 최상위 레벨의 자료흐름도 (DFD,data flow dia..

앞에서는 개발 프로세스에 관한 글이었다면 이제는 개발을 도와주는 프로세스인 지원 프로세스에 대해 알아보겠다. 지원 프로세스는 개발을 도와주는 프로세스로 프로젝트 관리 프로세스 형상 관리 프로세스 품질 관리 프로세스 프로세스 관리 프로세스 등이 있다. (이 외에도 있다) 이런 작업들은 개발을 하면서 꾸준히 필요한 프로세스다. *지원 프로세스를 우리는 우산(umbrella) 프로세스라고도 부른다. 관리 프로세스들을 알아보자면 비용을 낮추고 품질을 높이고 프로젝트를 관리하는 데 필요한 모든 작업 (ex 모니터링, 자원 할당 등) 관리 프로세스의 작업은 크게 3가지 단계가 있다. 계획, 모니터링 및 제어, 분석 3가지가 있다. 계획 단계에서는 비용, 일정 예측, 중간 점검에 대한 결정을 하고 이 계획을 바탕으로..

이전 글에서 설명했다시피 차례대로 개발프로세스의 특징을 소개해보려고 한다. 1. 폭포수(water fall) 모델 보는 것과 같이 위에서 아래로 물이 흐르는 듯한 모양을 가지고 있다. 특징으로는 각 단계가 다음 단계 시작 전에 끝나야함 각 단계 사이에 중복이나 상호작용이 없다. 각 단계의 결과는 다음 단계의 시작 전에 점검한다. 결과가 만족되지 않으면 바로 전 단계로 돌아가 다시 수행한다. 각 단계가 순차적이라 직능 중심의 프로젝트 조직화가 가능하다 (pipeline) ex) 요구 분석팀, 구현팀 등등 이 모델은 단순하거나 응용 분야를 잘 알고 있는 경우 적합하다. 모델 자체가 단순해서 비전문가도 개발과정을 이해하기 쉽다. 즉 요구사항이 명확하고 변경이 거의 없는 경우에 활용한다. 크고 복잡한 오래 지속..

우리가 컴퓨터를 이용하는 모든 이유는 문제해결이다. 프로세스란 어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업으로 구성된 것을 의미한다. 즉 소프트웨어를 개발하는 과정, 작업 순서를 말한다. 이는 순서 제약이 있는 소프트웨어의 특징이기도 하고 높은 품질과 생산성을 위해서는 프로세스를 지켜야 한다고 볼 수 있다. *프로세스가 없는 개발은 즉흥적 개발로 단순하지만 비생산적인 개발이 될 것이다. 요구 분석을 하지 않아서 생기는 비효율성이 발생할 것이고 즉흥적인 개발로는 소프트웨어의 구조가 나빠질 것이다. 또한 계획이 없으니 작업의 목표가 없어서 프로그래밍을 잘했는지 비교대상도 없으며 비용과 일정을 예측할 수 없다. 프로세스랑 방법론을 착각하는 경우가 많은데 비슷하면서도 다르다. 전에도 말했다시피 ..