'프로그래머'에 해당되는 글 4건

  1. 2009.09.21 Programmer's day (2)
  2. 2009.07.10 소프트웨어 품질 측정의 척도. (2)
  3. 2009.06.01 사실과 오해
  4. 2008.01.05 프로그래머 10계명

Programmer's day

Etc 2009.09.21 13:20

이야 부럽네요.ㅋ

러시아에는 프로그래머들의 기념일이 있답니다.ㅋ

http://opendotdotdot.blogspot.com/2009/09/russias-new-holiday-programmers-day.html

Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요

  1. 지나가다가.. 2009.09.21 14:31  댓글주소  수정/삭제  댓글쓰기

    저는 어떻게 러시아어를 읽으셨는지 그게 더 신기하고 부럽습니다 >..<

    아.. 제목은 영어로군요;;

  2. BlogIcon 미남 2009.09.21 16:35  댓글주소  수정/삭제  댓글쓰기

    ㅋㅋㅋㅋㅋ


IT 산업이 발달하면서 제품에서 소프트웨어가 차지하는 비중이 점점 높아지고 있으며, IT 기업들이 국내 시장을 확보하거나 국산 소프트웨어의 수출을 위해서 소프트웨어 품질 확보는 이미 필수적인 문제가 되었습니다. 이러한 소프트웨어 품질의 표준화를 담당하고 있는 기구로서는 ISO ( International Organization for Standardization ) IEEE (Institute of Electrical and Electronics Engineers ) 가 대표적입니다. 전자는 제품 평가 분야, 프로세스 평가 분야, 품질시스템 구축 분야를 진행하고 있고, 후자는 일관성, 합리적 절차, 공개성과 균형성을 위해 IEEE 표준 프로젝트를 검토하는 업무를 담당하고 있습니다. 또한 국내에서는 기술 표준원 ATS ( Korean Agency for Technology and Standards ) 과 한국 정보통신 기술협회 TTA ( Telecommunications Technology Association ) 에서 소프트웨어 품질 관련 표준을 제정 및 관리하고 있습니다. 그럼 이러한 기구들에서 정해놓은 소프트웨어 품질 평가의 척도에는 어떤 것들이 있는지 이야기해보겠습니다.

 

COCOMO Model ( COnstruction Cost Model )

è           미국 TRW 사의 B. Boehem 이 소개한 1981년 원시 프로그램의 규모에 의한 비용산출 방법입니다. 이 것은 SLOC ( Source lines Of Code ), SDI ( Delivered Source Instruction ) 으로부터 비용을 예측합니다. 즉 시스템의 크기에 의존하게 됩니다. 어떤 프로그래밍 언어를 사용하느냐에 따라서 예상되는 크기가 다를 수 있고, LOC ( Lines Of Code ) 를 초기 단계에서 추정해야만 하는 어려움이 있습니다. COCOMO 의 분류기준은 크게 Basic Model, Intermediate Model, Detailed Model 세 가지를 들 수 있으며, 일반적으로 각각 응용 프로그램, 유틸리티 프로그램, 시스템 프로그램을 가리킨다고 볼 수 있겠습니다. 참고로 Intermediate COCOMO 의 비용요소들에는 다음과 같은 것들이 있습니다.

1.)    제품 속성 : 요구되는 소프트웨어의 신뢰도, 응용 데이터베이스의 크기, 제품의 복잡성.

2.)    컴퓨터 속성 : 실행시간의 성능 제한 조건, 주기억장치의 제약, 컴퓨터의 안정성, 반환 시간

3.)    인력 속성 : 분석가의 지질, 프로그래머의 지질, 응용분야의 경험, 컴퓨터와의 친숙성, 프로그래밍 언어의 경험

4.)    프로젝트 숙성 : 소프트웨어 공학 기법의 응용, 개발도구의 사용도, 개발기간의 산정

 

 

Doty Model

è           Doty Model 은 인터뷰와 문헌을 바탕으로 만들어진 Model 로써, 프로그램의 규모를 알 수 있다는 전제하에서 총공수를 구하게 되며, 공식은 다음과 같습니다.

총공수 ( MM ) = 상수 * 프로그램의 소스 코드 라인수

 

Putman Model ( 생명주기 예측모델 )

è           이미 대규모 R&D 프로젝트에 적용되었던 모델을 기초로 가설을 세울 수 있게 해 줍니다. 프로젝트의 Life Cycle 기간 동안 노력의 특수한 분포 ( Rayleigh ) 를 가정해주는 Dynamic Multivariable Model 입니다.

 

FP ( Function Point )

è           1979 , IBM Albrecht 는 소프트웨어 규모를 측정 및 예측하는 기법으로 기능 점수 ( Function Point ) 라는 것을 제안하였습니다. 그 당시 Function Point 는 소프트웨어 개발 프로젝트의 규모를 측정하기 위해서 사용되었는데, 소프트웨어 산업이 발전함에 따라 점차 공학적 접근을 통한 다양한 분야에서 쓰이고 있습니다. 벤치마킹 조사, 소프트웨어 계약과 관련된 소송, 아웃 소싱 계약, 품질 측정, 산출물의 규모 예측 등이 바로 그 것들입니다. 그럼 Function Point 를 사용하여 어떻게 분석을 하는지 알아보겠습니다.

기능 점수 분석법 ( Function Point Analysis ) 의 핵심은 개발자 중심의 관점에서 벗어나 사용자 관점에서 소프트웨어 개발 규모를 측정한다는 데에 있습니다. COCOMO LOC 에 기반하여 소프트웨어 규모를 파악하는 데 반하여, 기능 점수 분석법에서는 사용자의 요구 기능을 분석하여 소프트웨어 규모를 파악하게 됩니다. 사용자의 요구 기능이라 함은 데이터를 조작 ( 저장, 삭제, 이동 등 ) 하는 트랜잭션 기능 따위를 말하는 것입니다. 이렇게 함으로써 기술적 요구사항과는 독립적으로 개발 및 유지보수 소프트웨어 규모를 측정하는 것이 기능 점수 분석법의 목적입니다. 기능 점수를 측정하는 절차는 다음과 같습니다.



측정 유형의 결정

측정 범위와

경계 결정

데이터 기능 측정

트랜잭션 기능 측정

UFP 산정.

VAF 확정

AFP 산정

* UFP : Unadjusted Funtion Point

* VAF : Value Adjustment Factor s

* AFP : Adjusted Function Point

Halstead 의 소프트웨어 복잡성 척도 ( Halstead Complexity Measures )

è           이 것은 복잡도를 방법으로써 프로그램에서 사용된 연산자 / 피연산자의 개수와 종류,발생 빈도 간의 관계 등을 이용하게 됩니다. 이 방법의 장단점은 다음과 같습니다.

Advantage

1.)    프로그램의 구조를 깊게 분석할 필요가 없습니다.

2.)    에러율과 유지보수 비용을 예측할 수 있습니다.

3.)    계산 방법이 단순합니다.

4.)    어떤 프로그래밍 언어에 대해서도 사용이 가능합니다.

단점

1.)    완성된 코드에 의존해야 합니다.

2.)    Predictive estimating model 에 대해서는 거의 사용하지 못 합니다.

 

McCabe 의 회전 복잡도 ( Cyclomatic Complexity )

è           McCabe 의 회전 복잡도는 상세 설계가 완료된 후부터 사용이 가능하며, 프로그램의 제어 흐름도를 기반으로 분석하게 됩니다. 그래프를 이용하게 되는데 각 노드 안에 처리 작업을 나타내고, 화살표로 제어의 흐름을 표시하게 됩니다. 그리고 각각의 개수를 세어서 복잡도를 계산하게 되는데 공식은 다음과 같습니다.

Cyclomatic Complexity (G) = 화살표의 수 노드 수 + 2

복잡도가 낮을수록 프로그램이 구조적으로 안정되었다는 의미이며, 높을수록 프로그램이 비 구조적이며 불안정하다는 의미입니다.

 

LOC ( Line Of Code )

è           말 그대로 프로그램 코드의 라인 수, 다시 말해 크기를 중심으로 개발자의 관점에서소프트웨어를 측정하는 방법입니다. 다음과 같은 공식들에 의해 측정이 이루어집니다.

생산성 = KLOC ( K Line Of Code )

비용 = 오류의 수 / KLOC

문서화 = 문서의 페이지 수 / KLOC

LOC 의 가장 큰 장점은 측정하기가 매우 쉽다는 것입니다. LOC 를 중심으로 예측하는 자료들이 이미 많이 존재하기 때문이기도 합니다. 하지만 프로그래밍 언어에 dependency 가 있으며 개발 초기나 기획 단계에서는 정확한 LOC 측정이 불가능하다는 단점이 있습니다.

 

 프로그래머가 완전하게 테스트했다고 믿는 소프트웨어도 보통은 로직 경로의 55~60%만 테스트된 경우가 많다고 합니다. 현재의 개발 부서와 검증 부서가 나뉘어지게 된 것도 그런 이유에서 비롯된 것이 아닌가 생각을 해 봅니다. 

Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요

  1. BlogIcon 박영식 2010.01.19 11:40  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다.ㅋ

출처 : http://yong0703.tistory.com/

오늘 책 3권 빌려왔는데, 볼려니 도저히 글 읽기가 싫어서 못보겠다...

일딴 내일 반납해야겠다.

책중에 우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해에서 목록이 눈에 띄어 남긴다.

사실 1. 소프트웨어 직업에서 가장 중요한 요소는 프로그래머가 사용하는 도구나 기술이 아니라, 프로그래머의 자질이다.
사실2. 최고의 프래그래머는 최하의 프로그래머보다 28배 뛰어나다.
사실3. 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 늦어진다.
사실4. 작업환경은 생산성과 품질에 지대한 영향을 미친다.
사실5. 소프트웨어 업계에는 과대선전(도구와 기술에 대한)이 만연해 있다.
사실6. 새로운 도구와 기술은 도입 초기에 생산성/품질 저하를 초래한다.
사실7. 소프트웨어 개발자는 도구에 대해 많은 말을 하지만, 별로 사용하지 않는다.
사실8. 폭주하는 프로젝트의 가장 흔한 원인 두 가지 중 하나는 부정확한 추정이다.
사실9. 소프트웨어 추정은 보통 부적절한 시기에 수행된다.
사실10. 소프트웨어 추정은 보통 부적절한 사람들에 의해 수행된다.
사실11. 프로젝트가 진행되면서 소프트웨어 추정을 수저하는 경우는 거의 없다.
사실12. 소프트웨어 추정이 부정확한 것은 별로 놀라운 일이 아니다. 그러나 우리는 추정에 죽고 산다.
사실13. 경영진과 프로그래머 사이에는 단절이 있다.
사실14. 타당성 조사에 대한 대답은 항상 "타당하다"이다.
사실15. 소규모 재사용은 잘 해결된 문제다.
사실16. 대규모 재사용은 여전히 해결되지 않은 어려운 문제다.
사실17. 대규모 재사용은 서로 관련 있는 시스템 사이에서 가장 잘 적용된다.
사실18. 재사용 가능 컴포넌트는 만들기가 3배 어렵고, 3곳에 적용해봐야한다.
사실19. 재사용된 코드를 수정하는 것은 특히 오류를 범하기 쉽다.
사실20. 디자인 패턴 재사용은 코드 재사용 문제에 대한 해결책이다.
사실21. 문제의 복잡성이 25% 증가하면서 솔루션의 복잡성은 100%증가한다.
사실22. 소프트웨어 작업의 80%가 지적인 작업이다. 그 중 상당부분이 창조적인 작업이다. 사무적인 일은 거의 없다.
사실23. 폭주하는 프로젝트에서 가장 흔한 원인 두가지 중 하나는 불안정한 요구사항이다.
사실24. 요구사항의 오류는 생산 단계에서 수정하는데 가장 비용이 많이 든다.
사실25. 누락된 요구사항은 가장 수정하기 힘든 오류이다.
사실26. 명시적 요구사항을 설계로 옮겨갈 때 '파생 요구사항'이 폭발적으로 증가한다.
사실27. 소프트웨어 문제에서 최적의 솔루션이 하나 존재하는 경우는 거의 없다.
사실28. 설계는 복잡하고 반복적인 과정이다. 초기 설계 솔루션은 보통 잘못 되었거나, 최적이 아닌 경우가 많다.
사실29. 설계자의 기본단위와 프로그래머의 기본단위가 일치하는 경우는 거의 없다.
사실30. 코볼은 별로 훌륭한 언어가 아니지만, (비즈니스 데이터 처리에 대해서는)다른 언어도 마찬가지다.
사실31. 오류제거는 생명주기에서 가장 많은 시간을 소모하는 단계다.
사실32. 프로그래머가 완전하게 테스트했다고 믿는 소프트웨어도 보통은 로직 경로의 55~60%만 테스트된 경우가 많다.
사실33. 100% 테스트 커버리지도 결코 충분하지 않다.
사실34. 테스트 도구는 꼭 필요하지만, 많은 경우 거의 사용되지 않는다.
사실35. 특정 테스트 프로세스는 자동화할 수 있고, 또 자동화해야 한다. 그러나 자동화할 수 없는 테스트 작업도 많다.
사실 36. 프로그래머가 작성한 디버그 코드는 테스트 도구에 대한 중요 보완 수단이다.
사실37. 엄격한 검사는 첫 번째 테스트 케이스를 실행시키기도 전에 소프트웨어 제품에 포함된 오류의 90%까지 제거 할 수 있다.
사실38. 엄격한 검사도 테스트를 대체할 수는 없다.
사실39. 출시후 검토는 중요하지만, 거의 실행되지 않는다.
사실40. 검토는 기술적 측면과 사회학적 측면을 모두 가지는데, 어느쪽도 무시하면 안된다.
사실41. 유지보수는 보통 소프트웨어 비용의 40~80%를 차지한다. 따라서, 유지보수는 소프트웨어 생명주기 중 가장 중요한 단계일 것이다.
사실42. 유지보수 비용의 60%는 개선 작업에 소요되는 비용이다.
사실43. 유지보수는 문제가 아니라 해결책이다.
사실44. 요지보수에서 가장 어려운 작업은 기존 시스템을 이해하는 것이다.
사실45. 더 좋은 소프트웨어 공학 기술로 개발하면 더 많은 유지보수가 필요하다.
사실46. 품질은 속성의 집합이다.
사실47. 품질은 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성, 또는 신뢰성이 아니다.
사실48. 대부분의 프로그래머가 흔히 범하는 오류가 있다.
사실49. 오류는 뭉치는 경항이 있다.
사실50. 소프트웨어 오류 제거에 있어 단 하나의 최상의 방법은 없다.
사실51. 오류는 항상 남아 있다. 심각한 오류를 제거하거나 최소화하는 것이 목표가 돼야한다.
사실52. 효율은 훌륭한 코딩보다는 훌륭한 설계에 더많은 영향을 받는다.
사실53. 고급 언어 코드도 어셈블리어 코드의 90%에 가까운 효율을 낼 수 있다.
사실54. 크기와 속도 사이에는 트레이드오프가 있다.
사실55. 많은 연구자들이 연구보다는 옹호에 치중한다.


오해1. 측정할 수 없는 것은 관리할 수 없다.
오해2. 소프트웨어 품질은 관리로 해결 할 수 있다.
오해3. 프로그래밍은 비자아적이 될 수 있고, 또 되어야 한다.
오해4. 도구와 기술: 한 가지로 모든 문제를 해결 할 수 있다.
오해5. 소프트웨어 분야에는 더 많은 방법론이 필요하다.
오해6. 비용과 일정을 추정하기 위해서는 먼저 LOC를 추정해야 한다.
오해7. 랜덤 테스트 입력은 테스트를 최적화하는 좋은 방법이다.
오해8. 보는 눈이 많으면 모든 버그는 그 깊이가 얕다.
오해9. 과거의 비용 데이터를 살펴봄으로써 미래의 유지보수 비용을 예측할 수 있고 시스템 교체 결정을 내릴 수 있다.
오해10. 프로그래밍을 가르칠 때 프로그램을 어떻게 작성하는지 보여주며 가르친다.
Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요

프로그래머 10계명

Etc 2008.01.05 14:19

시작부터 경지에 이르기까지…

1. 정보를 모음에 소홀히 하지 말고 설명서를 읽음에 게을리 하지 말지어

다. 오늘 필요 없는 정보는 내일 필요하리라. 가장 가치 있고도 저렴한

지식은 책 속에 있느니라. 서점과 동료의 책꽂이에 무엇이 꽂혀 있는지

때때로 살피어라. 무심코 흘렸던 종이 한 장이 너의 근심을 풀어 주었

으리라. 설명서는 충분히, 꼼꼼히 읽을지어다. 모든 의문은 설명서를

안 보는 데서 생기니라. 그렇더라도 모두 다 읽을 필요는 없느니라.

2. 너의 PC가 안전하다고 믿지 말지어다. 5분 후에 정전이 되고 내일 너의

하드가 맛이 가리라. 그러하니 너의 소중한 소스 코드는 정기적으로 여

러 군데에 단계별로 백업해 두어라.

3. 변하는 수를 다룰 때에는 늘 조심할지어다. 정수가 절대로 그 한계를

넘지 않으리라 가정하는 것은 어리석음이라. 127, -128, 255, 32767,

-32768, 65535, 이 숫자들을 너의 골수에 새기어라. 0.0은 0이 아니니

실수는 원래부터 결코 정밀하지 않느니라. 부호 없는 것과 있는 것을

어울리거나 정수끼리 나눌 때에는 늘 조심하여라.

4. 무슨 일을 반복시킬 때에는 처음과 끝에 유의할지어다. 너의 컴퓨터는

1보다는 0을 좋아 하니라. 배열의 첨자가 그 범위를 넘지 않을지 손 댈

때마다 따져 보아라. 수식에 1을 더하거나 뺄 때에는 늘 긴장하라. 너

의 프로그램은 단지 한 번 덜해서 틀리고 한 번 더해서 다운되느니라.

5. 항상 모든 경우의 수를 고려하고 섣불리 생략하지 말지어다. 절대로 일

어나지 않을 일은 반드시 일어나고, 가장 드물게 일어날 일이 가장 너

를괴롭히리라. 그러하니 언제나 논리에 구멍이 없는지 꼼꼼히 따져 보

고, if를 쓸 때에는 else부터 생각하라.

6. 함수 안에서 매개 변수값은 결코 믿지 말지어다. 지금 그 매개 변수가

결코 가질 수 없다는 값을 내일부터는 가지리라. 그러하니 매개 변수값

이 올바름을 항상 검사할지어다. 그렇더라도 처리 속도가 문제가 되는

경우는 예외이니라.

7. 오류를 알려 주는 기능은 있는 대로 모두 활용할지어다. 컴파일러의 경

고는 모두 켜 두어라. 경고는 곧 오류이니라. 오류를 알리는 함수의 결

과를 확인하지 않는 우를 범하지 말지어다. 모든 파일 입출력과 모든

메모리 할당은 조만간 실패할 것이라.

8. 한 번의 수정과 재컴파일만으로 연관된 모든 것이 저절로, 강제로 바뀌

도록 할지어다. 어떠한 것을 수정했을 때에 연관된 것이 따라서 변하지

않는다면 그것이 곧 벌레이니라. 컴파일러로 하여금 매개 변수 리스트

를 완전하게 검사하도록 하고, 언젠가 손대야 하거나 따라서 변해야 하

는 수치는 전부 매크로로 치환하며, 형 정의를 적극 활용하여라.

9. 사용자가 알아서 잘 써 주리라고 희망하지 말지어다. 너의 프로그램은

항상 바ㅇ보와 미ㅇ친ㅇ놈만이 쓰느니라. 사용 설명서를 쓸 때에는 결코 빠뜨

리지 말아라. 빠뜨린 만큼 사용자는 너를 괴롭힐 것이니라.

10.매사에 겸손하고 항상 남을 생각할지어다. 가장 완벽한 프로그램일수록

가장 완벽하게 숨은 벌레가 있느니라. 네가 이 세상 최고의 프로그래머

라고 떠들며 자만할 때, 옆집 곳간에서는 훨씬 더 뛰어난 것을 묵묵히

만들고 있느니라. 아무렴 프로그래밍은 혼자 잘나서 할 게 아니니, 너

로 인해 다른 사람들도 더불어 잘 되면 그얼마나 좋은 것이냐.

이 모든 것을 깨닫고 지키려 애쓰는 자는, 있어도 없어도 되어도 아니

되어도 늘 평온하리라.있나니 너희는 모든 프로그램에 대해서 위의 프로시줘를 따를 지니라.



도스시절 한글라이브러리인 한라 프로를 만드신 임인건님께서 쓰신 글입니다.

프로그래밍을 공부하시는 분들께 큰 도움이 되리라 생각합니다.

Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요