노는 게 제일 좋아

저번 글에서 말했는데 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) 요구 분석팀, 구현팀 등등 이 모델은 단순하거나 응용 분야를 잘 알고 있는 경우 적합하다. 모델 자체가 단순해서 비전문가도 개발과정을 이해하기 쉽다. 즉 요구사항이 명확하고 변경이 거의 없는 경우에 활용한다. 크고 복잡한 오래 지속..

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

어차피 나도 몰랐지만 이쪽 세상에서는 상식들로 알고있는 것들을 몇가지 소개해보겠다. 1. 비밀 암호 알고리즘을 사용하지 말것 비밀 암호 알고리즘을 만들어서 사용할 것이 아니라, 공개되어 있는 강한 암호 알고리즘을 사용해야한다. 공개를 해서 여러가지 테스트를 거쳐야 한다. 여러가지 테스트를 거치지 않으면 강한 암호 알고리즘이라고 생각되지 않는다. 전문가가 볼 때 위험하고, 어리석은 행위로 간주한다고 한다. 숨기는 것에 의한 보안(security by obscurity) 암호 알고리즘 자체를 비밀로 해서 보안을 유지하려고 하는 행위 또한 어리석고 위험한 행동으로 간주한다. 2. 약한 암호는 암호화 하지 않는 것보다 위험 // ㅋㅋ 군대나 공공기관의 비밀번호같이? 사용자는 암호의 강도와는 상관없이 "암호화"되..

크립토그래피(cryptography) 메세지의 내용을 읽지 못하게 하는 기법 스테가노그래피(steganography) -메세지의 내용을 읽지 못하게 하는 것이 아니라 메세지의 존재 자체를 숨기는 기법 -메세지를 숨겨 넣는 방법을 알게 되면 메세지의 내용은 금방 해독가능 2개를 혼동하지 말자. 서로 다르다. 문서에 기록된 인류의 첫 스테가노그래피는 그리스 역사가 헤로도토스(Herodotus)가 쓴 에 등장한다. 기원전 440년, 그리스 왕 히스티아에우스(Histiaeus)는 다른 나라의 인질로 붙잡힌다. 양아들에게 밀서를 보낼 방법을 고민하던 히스티아에우스는 노예의 머리를 깎고 두피에 비밀 메시지를 문신으로 새겨넣었다. 머리가 자라자 문신은 보이지 않았고 노예를 양아들에게 보냈다. 양아들은 노예의 머리를 ..

정보 보호를 생각할 때 가장 먼저 떠오르는 단어 암호 암호에 대해서 공부해보자 우선 암호에서 예를 들때 사람이름을 많이 쓰는데 Alice and Bob 데이터의 송/수신자를 뜻한다 Eve 소극적인 공격자로 (eavesdropper)를 한다. 도청은 하지만 정보를 수정하지는 못한다. 나중에 양자 암호에서는 통신환경을 뜻하기도 한다. Mallory 적극적인 공격자, 악의적인 공격자(malicious)로 이브와는 다르게 정보를 수정하고, 자신의 메세지로 대체하여 재전송하는 등 이브보다 막기 어려운 공격을 수행한다. Trent 영어로 (trusted arbitrator)로 신뢰할 수 있는 중재자를 뜻한다. 중립적 제 3자를 말하고 사용되는 프로토콜에 따라 그 역할이 달라진다 Victor 영어로 verifier를..