RAINSTORY.RAINMAKER

프로그래밍의 20가지 법칙

편집자 : cache

1. 프로그램의 치명적인 실행 중단은 절대로 용납하면 안 된다.

이는 가장 중요한 법칙이다. 사용자만이 프로그램을 중지시킬 권한이 있다. 프로그램이 중단되려고 하면, 프로그램에서는 에러를 찾아 사용자에게 알려주고, 사용자가 데이터를 저장할 수 있게 한 후에 중지 버튼을 눌러 프로그램을 종료시키도록 해야 한다. 이는 곧 운영체제가 사용자에게 직접 에러 메시지를 보내서는 절대로 안 된다는 뜻이다. 운영체제는 항상 치명적인 중단을 한다.

2. 사용자 매뉴얼, 명세서, 도움말, 소스 코드 순서로 일하라

이 과정을 따라 프로그램을 설계할 때쯤 되면 이미 계획서가 만들어져 있다. 사용자 매뉴얼을 쓸 때 사용자들의 참여를 요구하라. 이렇게 하면, 더욱 일관성 있게 마감 시간을 지킬 수 있을 것이고, 사용자들은 그들이 원하는 대로 설계가 된다는 사실에 기쁨을 느낄 것이다.

원하는 곳에 기술적인 문서와 같은 다른 요소를 넣어도 되지만, 사용자 매뉴얼, 명세서, 도움말, 소스 코드 순서는 항상 같아야 한다.

3. 위험 요소 분석(RFA)을 사용하지 않으면, 프로그램 개발은 계속해서 생각하는 것보다 2배는 더 걸린다.

그렇다. 계속해서 2배 더 걸린다. 만일 연구를 위해 프로젝트 시간을 2배로 늘린다고 해도 문제가 생길 것이다.

RFA가 해결하는 문제는 연구 시간이다. 모든 프로그래머들은 연구가 얼마나 걸릴지를 과소평가한다. 우리는 프로젝트 내의 모든 것을 할 수 있는 기회가 별로 없다. 그러므로 우리가 어떻게 해야 하는지 모르는 일이 얼마나 걸릴지도 예상해야 한다! RFA는 이러 연구 시간에 대한 답을 준다.

4. 코드 짜는 부분은 개발의 20%를 넘지 않아야 한다.

좋은 설계를 가지고 있는 경우, 실제 코드를 쓰는 부분은 전체 개발의 10%만 차지할 수도 있다! 개발 노력의 20% 이상을 코딩에 쓰고 있다면, 그 원인은 거의 잘못된 초기 설계 때문 일 것이다.

5. 검사는 적어도 프로젝트의 30%는 차지해야 한다.

프로젝트 시간을 예상할 때 검사를 위한 30%를 추가하라. 자동화된 검사를 하더라도 검사를 위해 30% 소비해야 한다. 자동화된 검사는 더 완벽하게 검사할 수 있도록 해주지만, 그것만으로 충분하지는 않다. 만일 마감 시간 때문에 프로그램 테스트에 30%정도의 시간도 할당해 두지 않는다면, 이는 프로그램에 버그를 만들며, 프로그램을 문서화하는데도 오류를 남기게 된다.

6. 주석은 소스의 20%를 차지해야 한다.

유지는 그것이 문제점을 고치는 것이든, 향상할 부분을 추가하는 것이든, 프로그램 수명의 반을 소비한다. 모든 변수 선언을 문서화해서 다음 프로그래머의 작업이 쉬워지도록 한다. 함수의 이름으로 그 함수의 기능을 충분히 알아볼 수 없는 한, 중요한 함수에는 그 목적을 써줘야 한다. 주석에는 저자, 버전 날짜, 그리고 자주 빼먹는 수정 일지가 들어있어야 한다.

주석은 대부분을 /// 형식으로 짜는 것을 고려하라. VS.NET에서 직접 입력해야 할 내용을 많이 줄여줄 것이다. .

7. 에러 메시지는 무엇이 일어났는지, 사용자가 무엇을 할 수 있는지, 프로그램이 다음에 무엇을 할 것인지, 코드의 어느 줄이 문제를 일으켰는지를 알려줘야 한다. 시간, 사용자 이름, 그리고 환경도 알려줄 수 있다.

보통, 에러 메시지로 통하는 것이 일반적으로 에러 메시지의 제목에 들어간다! 불쌍한 사용자가 프로그램 개발자를 증오하지 않고 사랑할 수 있게 하라.

8. 좋은 프로그램들은 자동으로 최근의 에러 메시지를 영구적인 매체에 저장해 둔다.

메시지들을 원형 큐에 넣어 메시지가 디스크 공간을 차지하지 않도록 하라. ASCII 텍스트를 사용하여 아무 편집기나 워드 프로세스에서 볼 수 있도록 한다.

사용자가 프로그램 개발자에게 메시지를 보낼 수 있는 방법을 제공한다. 버튼 클릭 하나로 할 수 있다면 더욱 좋다.

9. 루틴을 세 번 부른다면? 숨겨라. 한 번 부른다면? 숨기지 말라.

단 한 번 사용하는 루틴은 숨기지 말라. 소스 코드에 inline 으로 추가하라. 그러나 루틴을 여러 번 사용한다면 함수로 만들어 묘사적인 이름을 붙여라.

10. 루틴은 단 하나의 진입점과 탈출점이 있어야 한다.

예외에는 메뉴와 에러 잡는 코드가 있다.

Structured Programing 의 저자들 중에는 그 누구도 goto 문의 결여를 받아들인 사람이 없다. 대신, 그들은 루틴에 단 하나의 진입점을 요구했다. 그들은 메뉴나 에러 잡는 코드와 같은 예외적인 경우만 여러 개의 탈출점을 허용했다.

C#은 goto 문이 필요 없을 정도로 이 예외를 잘 처리한다.

11. 변수와 루틴을 위한 명확한 이름으로 코드를 문서화하라.

가장 좋은 문서화는 변수, 함수, 클래스, 그리고 패키지의 이름이다. 관습을 채택해도 좋다. 일반 프로그래머들 사이에는 헝가리언 표기법이 선호되지 않지만, 이것을 쓰면 변수형을 바르게 할 수 있다. 또, 이 방식은 프로그램 수명 기간의 반을 책임지는 유지 프로그래머들을 돕는다.

12. 관계 데이터베이스를 쓴다.

작은 파일들과 에러 메시지를 기록하는 파일은 순차적인 파일이어도 된다. 그러나 만일 데이터를 많이 쓰고자 한다면, 그 테이블을 위한 관계 데이터베이스를 작성할 시간의 여유를 둔다. 이렇게 하면, 일반적으로 개발 시간을 줄이고 디스크 공간을 덜 소비하며, 성능을 향상시킬 수 있을 것이다.

가장 큰 이익은 프로그램 향상 기간에, 특히 파일을 관계 데이터베이스로 변환해야 할 때 나타난다. 변환한다는 의미는 주로 프로그램 전체를 다시 짜야한다는 뜻이다.

13. 항상 제일 좋은 알고리즘을 사용하라.

"제일 좋은" 성능, 디스크 공간 사용량, CPU 사용량, footprint 등으로 결정된다. 그러나 "가장 나쁜"과 "가장 좋은"의 차이는 1000:1일 수 있다.

14. 가장 느린 루틴을 먼저 최적화하라. Profiler로 이들을 찾아낸다.

이 작업은 여러분의 에너지를 가장 잘 활용할 수 있는 곳에 집중하는 일이다. 100초 걸리는 루틴을 반으로 줄이는 일을 미루고, 1초 걸리는 루틴을 반으로 줄이는데 매달리는 것은 말이 안 된다.

15. 가장 좋은 언어는 가장 적은 개발 시간을 필요로 하는 언어이다.

여기에서 중요한 조건이 있다. 여러분이 기존의 프로그램을 업그레이드 하는 중이면, 그것을 작성할 때 사용했던 언어를 유지하도록 노력한다. 이를 통해 시간적 우위를 가질 수 있다. 그러나 프로젝트를 지원하느냐 안 하느냐의 문제에서 제품을 시장에 낼 때까지 걸리는 시간은 매우 큰 요소이다. 그러므로 새로운 언어로 인해 개발 시간을 최단으로 줄일 수 있다면, 그 언어를 선택해야 한다.

한 가지 플랫폼 이상에서 돌아가는 프로그램을 개발한다면, 이는 C#를 선택할 충분한 동기가 된다.

16. 사용자 서명을 요구하라.

계약서 없이 집을 살 수 있는가? 중고차를 그런 식으로 살 수 있겠는가? 그렇다면 해야 하는 일을 확실히 알지도 못하면서 왜 이것들보다 훨씬 비싼 컴퓨터 프로그램을 만들고자 하는가? 결국, 계약서는 이해를 명확하게 결정짓는 도구에 불과하다. 이는 소송을 위한 준비 작업이 아니다. 계약서에는 여러분과 사용자가 각각 무엇을 할 것인지 명기하고 있으므로 나중에 다시 참조해도 된다.

17. 위험한 모듈들부터 작성하라.

이렇게 하면, 나쁜 소식을 먼저 알아낼 수 있어서 좋고, 나중에 고치는 비용이 덜 든다.

18. 유지하기 편하도록 하라.

주석을 자세하게 다는 것만으로는 충분하지 않다. 간단하게 명확한 알고리즘을 사용한다. 복잡한 과정들이 나올 때는 이름을 잘 붙인 임시 변수 여러 개를 사용하여 단계별로 주석을 쓸 수 있도록 한다. 이런 변수들은 유지 프로그래머가 중간 값을 점검하고, 어느 곳에서 프로그램이 이상하게 되었나를 알아낼 때 도움이 된다.

19. 여러분이 쓰는 모든 것의 철자를 점검하고 서명하라.

여러분이 하는 일에 자부심을 가지고 서명하라. 어느 날 누군가가 전화해서 여러분이 했던 멋진 일에 대해 축하해 줄 것이라는 희망을 가져라. 그것은 이 세상에서 가장 좋은 느낌이다.

20. 언제가 끝인지 알자.

범위에 대한 두려움은 프로젝트의 독이다. 피하라. 거부하라. 다음 단계로 넘겨라. 그러면 프로젝트를 다 끝내고 한숨을 돌리며 말할 수 있다. "이 프로젝트는 끝났다!" 그리고는 커피 한 잔을 마시고 프로젝트를 넘기고 향상 점들에 대해 의논하라.

[김익환] SW 개발에서 가장 중요한 문서

김익환 SW컨설턴트 ik_kim@yahoo.com
2004년 07월 04일

소프트웨어를 개발하다 보면 많으나 적으나 문서 산출물이 나오게 된다. 그 중에서 가장 중요한 문서를 하나 선택하라고 하면 무엇일까.

소프트웨어 개발과 관련된 분야에는 시스템소프트웨어 개발, 응용소프트웨어 개발, 용역개발, ERP 구현, 전산실의 자체 개발, 펌웨어(Firmware) 개발 등을 들 수 있다.

이런 다른 종류의 소프트웨어 개발에 참여해본 사람들은 자기분야에서의 경험에 기준을 두고 소프트웨어를 얘기하게 된다. 산출물도 각각 다를 수 밖에 없다.

필자가 지금까지 경험해 본 소프트웨어 프로젝트를 보면 똑 같은 산출물을 요구하는 프로젝트는 한번도 없었다. 그 만큼 프로젝트가 다양하다는 것을 의미한다. 그래서 여러가지 방법론이 존재하고 새로 생겨나기도 한다.

특정한 방법론에 나오는 프로세스와 산출물을 모든 프로젝트에 획일적으로 사용할 수가 없다. 그래도 모든 프로젝트가 지켜야 하는 핵심 프로세스와 핵심 산출물은 유사하다. 다만 형식이나 이름이 다르게 나타나기 때문에 상이한 것처럼 보이나 소프트웨어개발의 근본원칙에서 보면 핵심이 다를 수는 없다.

기본적으로 대형 프로젝트를 하게 되면 수십개, 수백개나 되는 많은 산출물이 요구되고 그러다 보면 중복된 정보가 여기저기 나타나게 된다. 회사가 커지면 나타나는 피할 수 없는 관료적인 비효율성의 문제와 비슷하다. 작은 프로젝트는 2-3개의 문서만 작성해도 충분할 지 모른다.

산출물 문서중에 'Software Requirement Specification(SRS)'이라는 문서가 있다. 개발방법론이나 회사에 따라 '요구사항명세서', '요구분석서' 등 다른 이름으로 호칭되기도 하나 근본적으로 동일한 목적을 가지고 있다. 개발하려는 것이 무엇인가를 정의하는 것이다. 단순히 기능정의서만으로 생각하면 오산이다. 기능정의는 SRS의 일부분이다. 뒷부분에서 부연 설명을 하겠다.

필자가 미국의 국방산업체인 록히드와 수행한 프로젝트의 예를 들어보자. 첫 회의에서 프로젝트의 개요와 우리가 할 수 있는지를 확인했다. '록히드쪽에서 RFP(제안요청서)를 쓰고 우리가 제안서를 쓰고 진행할 것인지', 아니면 '록히드가 RFP와 함께 SRS를 쓰고 우리가 구현만 할 것인지'를 의논한 결과 SRS를 록히드가 작성하기로 하고 우리는 SRS에 기초해서 제안서를 내기로 했다. 이 제안서에는 SRS에 모든 기능이 명시되어 있기 때문에 기능에 대한 명시는 없이 가격과 개발기간 등 그 외에 제안서에 필요한 정보만 포함되었다. 물론 SRS를 우리가 작성하기로 했다면 가격은 더 비쌌을 것이다.

SRS와 함께 'Acceptance Test Plan(ATP)'도 록히드가 작성했다. 프로젝트의 검수는 주어진 ATP에 있는 테스트케이스만 통과하면 되는 것이었다. 명확하게 우리가 해야 할 일을 프로젝트 시작과 동시에 알고 있는 것이다. 이것보다 프로젝트의 내용이 더 정확히 정의될 수는 없을 것이다. ATP를 통과하는 것 자체가 검수승인을 의미한다. 그 후에 발견되는 결함들은 당연히 유지보수 비용을 받고 수정해 주게 된다. 그러므로 록히드쪽에서도 완벽을 기하려고 한다.

그 대신 우리가 SRS에 약속했던 기능을 구현해 주지 못하면 상당한 불이익을 받는다. 비용을 못 받을 수도 있고 고소를 당할 수도 있다. 소프트웨어 회사 중에 처음에는 잘 나가다가 너무 급격히 성장하면서 고객에게 무리한 약속을 해서 실패한 회사도 많다. 대부분 부실한 SRS 때문이다.

록히드 프로젝트 경우에 구현해야 하는 기능에 대해서 주관적인 판단은 거의 없었다. 커뮤니케이션에 오류가 있을 확률이 매우 낮았다는 것이다. 내가 수행했던 다른 프로젝트들이 이렇게 완벽하게 진행된 것은 아니었지만 적어도 프로젝트가 객관적으로 서로 동의한 기능구현을 목적으로 수행되어야 하는 것은 매우 중요하다.

패키지를 개발하든지 SI 업체로서 프로젝트를 수주하든지 기능을 원하는 측과 기능을 구현하는 측이 얼마나 빨리 서로 일치하느냐가 성공의 관건이다. 서로 일치하는지를 확인하는 가장 좋은 방법이 문서이다. 제안서나 제품기획서는 소프트웨어 개발의 첫 단계인 기획 단계에서의 커뮤니케이션의 핵심이다.

제품기획이 완성되면 개발팀으로 넘어와 소프트웨어적인 측면에서 SRS를 작성하게 된다. 여기에서 모든 기능이 확정되고 모든 부서가 동시에 일을 추진하게 된다. 그래서 SRS는 개발팀, 마케팅, 기술문서, 테스트팀, PM 등 모든 팀과의 커뮤니케이션의 중심이 된다.

소프트웨어 개발에 있어 가장 중요한 하나의 문서를 꼽으라면 단연코 SRS이다. SRS에는 가능설명이외에도 성능요구사항, 인터페이스요구사항, 국제화, 하드웨어와 소프트웨어의 환경 등, 이 소프트웨어가 무엇을 하는지를 알 수 있는 모든 항목이 들어 있다.

프로젝트 매니저(PM)가 개발계획을 정확히 수립할 수 있도록 기능도 세세히 분리해야 한다. 각 기능항목을 2시간~ 2일 사이로 시간 측정 가능하도록 나누어야 한다고 주장하는 사람도 있으나 필자는 1일~2일 정도의 단위가 적당하다고 본다. 전체 소프트웨어 결함중에 56%가 요구사항분석 단계, 27%가 설계단계, 7%가 코딩에서 생긴다는 통계가 있다. 요구사항 분석단계에서 대충 SRS를 작성하기 때문에 생기는 결과이다.

개발방법론을 한번이라도 접해본 사람들은 다 들어본 적이 있는 '1:10:100 법칙'이라는 것이 있다. 요구사항 단계에서 잘못된 것을 발견해서 수정하는 것과 설계단계에서 수정하는 것과는 10배의 시간과 비용이 들고 코딩단계에서 발견하면 100배의 시간이 더 든다는 것이다. 책과 머리로는 이해하나 이것을 진실로 이해해서 제대로 실천하는 사람은 보기 드물다. 요구사항을 정확히 정의해야 하는 중요성은 전 개발과정중의 핵심중의 핵심이라고 아무리 강조해도 지나치지 않다.

이런 중요한 문서를 대충 적고 넘어가는 이유는 많다. 기능을 구현해 보지 않고는 할 수 있는지가 확실하지 않다는 이유가 그 중의 하나이다. 이런 경우의 판단은 두 가지 방법에 의존할 수 밖에 없는데 최단기간 내에 프로토타입을 만들어 보던가 아니면 경험자의 판단을 믿든가이다. 프로토타입을 만드는데 사용한 코드는 버리고 다시 개발하는 것이 좋기 때문에 당연히 경험자의 판단으로서 하는 것이 시간적으로 효율적인 것은 두말할 나위도 없다.

작은 프로젝트에서 발생하는 극단적인 케이스는 개발 종료후 보고서 제출용으로 SRS를 작성하려는 경우도 심심치 않게 본다.

잘 작성된 SRS는 결국 소프트웨어의 개발기간을 단축시켜 준다. SRS를 안 적거나 대충 적는 이유의 대부분이 시간이 없다고 한다. 잘 씌여진 SRS는 시간을 절약하게 해준다. '시간이 없어서' SRS를 정확하게 작성하지 않았다면 다음 개발단계를 빨리 시작할 수는 있으나 최종개발이 끝나는 시점은 더 늦어지게 된다. 그 외에도 부실한 SRS는 미래에 많은 문제를 파생시키게 된다.

정확한 SRS의 중요성은 강조했으나 이를 성취하기 위해서는 프로젝트의 종류에 따라 다르지만 소위 '갑' 이라고 하는 발주업체나 제품기획자의 능동적인 협조가 필요하다. '나중에 생각나면 추가하자'는 생각은 실패의 지름길이다. 한번 시작하면 변경하지 못한다는 생각으로 임해야 한다.

반대로 개발자의 입장에서도 무엇을 할 수 있는지, 자기의 능력도 확실히 알아야 한다. 할 수 없는 것을 할 수 있다고 해서 나중에 난감한 상황에 빠진 경험을 한번쯤은 가지고 있을 것이다. 좋은 소프트웨어가 나오기 위해서는 '갑'과 '을', 혹은 제품기획자와 개발자의 협력과 많은 시간투자가 초기단계에서 필요하다.

Allegedly, the first software support tool for project management was developed by Datasaab for their computer D21 in the early 1960s. It was tailored to support the PERT model. Nowadays project planning software is widely used and abused.

The software industry research company, Gartner (http://www.gartner.com/), periodically publish the "Project Management Software Magic Quadrant Report", a review of major packages (2002 report in pdf here).

Problems with project management software

• Few packages are built around a sound project management method. What is even worse, e.g. Microsoft Project encourages counterproductive behavior by inexperienced project managers by offering as the default start-up view the Gantt chart. This encourages too early focus on task identification and scheduling vs. proper formulation of project objectives and final deliverables. So, such packages implicitly force upon an unsuspecting user an unsound project management process.
• Many packages also offer e-mail integration, which encourages automatic assignment of tasks and due dates. This universally leads to counterproductive, date-driven behavior (see: critical chain) and may contribute to improper setting of team members' performance expectations .
• Software gives one the illusion that one can do without paper. See discussion on paper-ful project management.
• Much software creates horrible project graphics. See discussion of project management graphics.
• Compare the cultural effects of MS Power Point

Selecting project management software

• large developer group: >5 members
• large user group
• both online(web-based) and offline(local machine) work model
• multiuser, multigroup, multiproject,multilingual
• recurring tasks support: example: monthly task define
• To track multiple projects and innumerable small tasks
  • tasks and their dependencies: multiple dependencies: n to n dependence.
  • Gantt graph
  • Tree view for project and nested tasks and subtasks
  • Task completion statistics: status reports
  • archived projects/tasks
  • project calendars & reminder
• resource management
  • resource constrains
  • resource usage tables
  • project accounting statements
• extensible: easy to add new components or be plugged into existing components
  • bugtracker
  • email notification
  • forums
  • wikis

Proprietary non-internet packages

Critical path support

• TrackerOffice - A groupware solution which leverages Microsoft Outlook / Exchange
• Tracker Suite - A groupware solution which leverages Lotus Notes / Domino
• Microsoft Project -- a part of Microsoft Office, [1]
• Primavera -- a high end solution, [2]
• Artemis -- a high end solution, [3]
• Asta Powerproject -- mid-range solution, [4]
• Projetex - Project management software for expert teams

Critical chain support

• ProChain (add-on to Microsoft Project), http://www.prochain.com/index.asp
• Sciforma Corporation , http://www.sciforma.com
• Project Flow by Realization Technologies, Inc, http://www.realization.com
• CCPM+ (add-on to Microsoft Project), http://www.advanced-projects.com
• Asta Powerproject -- mid-range solution which includes Buffer Management [5]

Open source software

• http://www.openworkbench.org/ An industrial-strength MS Project replacement made open source by Niku
• http://www.tutos.org/ A powerful web-based multilingual tool to manage the organizational needs of small groups, teams, departments .... It contains calendar, mailbox, bug-tracking, project/product management, task management, document management,
• http://webcollab.sourceforge.net A light-weight, easy collaborative web-based system for projects and project management; suited to tracking multiple projects and innumerable small tasks across an organisation of any size. Avoid reminder notes stuck all over your desk.
• GanttPV -- project scheduling software for Windows & Mac, scriptable w/ python. http://www.pureviolet.net/ganttpv/
• PHProjekt -- an open-source, internet-based groupware suite, http://www.phprojekt.com/index.php
• DotProject -- open-source, internet-based, in early development, http://www.dotproject.net/index.php
• MrProject -- was a part of GNOME but MrProject has been renamed as Planner (See next entry). There is no new development on MrProject and all new development is now done on Planner.
• Planner -- a GNOME tool for planning, scheduling and tracking projects and is released under a GPL license. This evolved out of the MrProject code. The current developers of Planner include the original developers who now work for Imendio http://www.imendio.com/ . Planner uses an XML file format or PostgreSQL database to store the project details and is written in C programming language. See http://www.imendio.com/projects/planner/ for more details on where to get the code or how to join mailing lists.
• KPlato -- a project management application KOffice suite (in early stages of development), http://www.koffice.org/kplato/
• Project/Open -- open-source, internet-based "Project-ERP", with an emphasis on project collaboration and financials, http://www.project-open.com/
• Gantt-Project -- written in Java for all OS http://ganttproject.sourceforge.net/
• Many more listed in the external link part of this page

Proprietary internet-based

• cando Project Intelligence -- http://www.candoprojects.com
• Project Arena -- http://www.projectarena.com
• Celoxis -- http://www.celoxis.com/
• ProjectWeb -- http://www.infograph.com/web-project-management.htm
• Basecamp (simplicity and ease of use) -- http://www.basecampHQ.com
• Infowit Creative Manager -- http://www.infowit.com/
• Project.Net -- http://www.project.net
• eProject -- http://www.eproject.com
• Projectplace -- http://www.projectplace.com
• TrioProject -- http://www.trioform.com/project_management_software.htm
• ValleySpeak Project Server -- http://www.valleyspeak.com/ps.html
• CoP -- http://www.s-m-c.de
• TargetProcess -- http://www.targetprocess.com

External links

• Project Management Software Directory http://www.thesoftwarenetwork.com/Project-Management-Software
• Project Portfolio Managment increases profitability -- http://www.projectarena.com/partners/Apples_to_Apples.pdf
• Two Models for Project Portfolio Management -- http://www.projectarena.com/solutions/Yes_or_No.pdf
• Directory of project management software -- http://www.infogoal.com/pmc/pmcswr.htm
• Open Directory "Top: Computers: Software: Project Management" -- http://www.dmoz.org/Computers/Software/Project_Management/
• http://www.linux.org/apps/all/Office/Project_Management.html
• http://sourceforge.net/softwaremap/trove_list.php?form_cat=130 sourceforege software map: Topic-> Office/Business-> Scheduling
  

Books

• Eric Uyttewaal. Dynamic Scheduling With Microsoft(r) Project 2000: The Book By and For Professionals. ISBN 0970827601
• George Suhanic. Computer-Aided Project Management. ISBN 0195115910
• Richard E. Westney. Computerized Management of Multiple Small Projects. ISBN 0824786459

Source : LITH Blog