ScriptPlan

Tests

Probes

Python

Licence

자원 할당 및 의존성 관리를 위해 분 단위의 정확도를 제공하는 정밀한 프로젝트 스케줄링 엔진입니다. 문법은 TaskJuggler (.tjp 파일)와 호환됩니다.

설치 (Installation)

pip install scriptplan

빠른 시작 (Quick Start)

보고서 생성 (Report Generation) (Unix 스타일)

# stdout으로 JSON 보고서 생성
plan report project.tjp

...

출력 형식 (Output Format) (JSON):

{
  "data": [
    {
...

특징 (Features):

stdout으로 출력 (Unix 철학)
메시지는 stderr로 전송
렌더링된 결과에 대한 SHA256 report_id를 제공하여 스케줄이 변경될 때마다 값이 달라짐
소문자 컬럼 이름 사용
HTML 메타데이터 없음
파일 오염 방지 (임시 디렉터리 사용)
독립적인 프로세스 간 충돌 방지: 임시 파일 및 디렉터리는 실행마다 고유함

Python API

from scriptplan.parser.tjp_parser import ProjectFileParser

parser = ProjectFileParser()
...

검증된 내용 (What is verified)

아래의 각 동작은 audit/evaluations/에 있는 프로브(probe)를 통해 ScriptPlan이 자체 API 또는 CLI를 거쳐 결과를 단언합니다. 이들은 테스트 스위트의 일부로 실행되며, 설치된 릴리스에 대해 독립적으로 실행할 수 있습니다:

audit/evaluations/run_all.sh

시간 (Time)

날짜는 프로젝트의 시간대(timezone)로 읽히고 UTC로 스케줄링되며, 보고서에서 다시 변환됩니다.
자원 이동은 일광 절약 시간제(daylight-saving changes)가 양방향으로 발생하는 경우 각자의 시간대를 따릅니다.
자정(midnight)을 넘는 근무 시간 간격은 다음 날에 적용됩니다.
슬롯 크기는 프로젝트에서 사용하는 시간을 기반으로 파생되므로, start 09:30은 정확하게 지켜지며, 08:13 - 11:59, 13:07 - 17:47의 이동 시간은 하루에 실제 8시간 26분을 산출합니다. timingresolution이 이를 재정의합니다.

단위 (Units)

캘린더 시간(duration, gapduration)과 근무 시간(effort, length, gaplength)이 구분되며, 근무 시간은 dailyworkinghours와 yearlyworkingdays로부터 파생됩니다. 여기서 m은 월(months)을 의미하고, min은 분(minutes)을 의미합니다.

자원 (Resources)

effort는 인력 시간(person-time)입니다: 슬롯 하나에 두 개의 자원이 있으면 그만큼의 2개 슬롯이 기여합니다. mandatory는 작업 진행에 필수적인 자원을 요구하며, persistent는 처음에 선택된 자원을 유지하고, alternative는 대체 옵션으로 사용됩니다.
dailymax, weeklymax, monthlymax, maximum 및 이들의 min 대응어들은 상한선(cap)을 설정하고 다음 기간에 해제합니다. 기간은 해당 자원 자체의 캘린더로 계산되며, 하나의 슬롯보다 작은 상한선도 정확하게 반영됩니다.

스케줄링 (Scheduling)

ASAP와 ALAP를 포함하며, 이 두 가지가 혼합된 체인(chains)도 처리합니다.
충돌(Contention)은 우선순위, 그다음 중요도(criticalness), 그리고 선언 순서에 따라 해결됩니다.
한번 선언된 프로젝트 기간은 절대 수정되지 않습니다. 맞지 않는 작업이 있으면 이름과 함께 그 이유가 보고됩니다.
동일한 프로젝트를 두 번 스케줄링해도 같은 날짜와 같은 예약 기록을 생성합니다.
maxgapduration, maxgaplength, maxstart, minstart, maxend 및 minend는 스케줄이 완료된 후에 확인되며, 위반 사항은 오류로 간주됩니다.

정확성 (Honesty)

스케줄링할 수 없는 프로젝트는 0이 아닌 값으로 종료하며 그 이유를 명시합니다. 의존성 순환(dependency cycle)은 스케줄링 이전에 거부되며, 해당 사이클의 이름을 밝힙니다.
파서가 배치할 수 없는 속성이나 참조는 오류이며, 절대 조용히 무시되지 않습니다 (silent drop).
report_id는 렌더링된 결과에 대한 SHA-256 해시값입니다. 따라서 스케줄이 달라지면 이 값도 다릅니다.

알려진 제한 사항 (Known limits)

include, supplement, leaveallowance, 그리고 statussheet는 구현되지 않았습니다.
출력 형식은 JSON과 CSV입니다. ical, tjp, niku, 그리고 MS Project XML은 아무것도 생성하지 않고 조용히 무시하는 대신 파싱 시점에 거부됩니다.
계정(Account)은 파싱되지만 아직 모델링되지 않았기 때문에, chargeset과 charge는 금액을 기록할 뿐 어디에도 전표 처리(posting)하지 않습니다.
onstart 의존성은 "종속 작업이 선행 작업 시작 전에 완료되어야 한다"로 읽히며, 이는 TaskJuggler의 시작부터 시작(start-to-start) 방식이 아니라 ScriptPlan 자체의 해석입니다.

예시 프로젝트 (Example Project)

project "Manufacturing" 2025-07-01 +1m {
  timezone "Etc/UTC"
  timeformat "%Y-%m-%d %H:%M"
...

이 프로젝트는 납품 마감일(ALAP 모드)로부터 역순으로 일정을 계획합니다. 스케줄러는 다음 작업을 수행합니다:

패키징을 7월 18일 16:00에 종료되도록 고정(Anchor)합니다.
두 조립 작업 모두가 패키징 시작 전에 완료되도록 일정을 잡습니다.
자원 경합(단일 기계)을 조립 작업을 연속적으로 배치하여 해결합니다.
주말 경계(월~금 근무 시간)를 준수합니다.

결과:

delivery.pack:       2025-07-18-08:00 -> 2025-07-18-16:00
delivery.assemble_a: 2025-07-14-08:00 -> 2025-07-15-16:00
delivery.assemble_b: 2025-07-16-08:00 -> 2025-07-17-16:00

라이선스 (License)

Apache-2.0

감사의 글 (Acknowledgments)

ScriptPlan은 오직 파일 형식 호환성을 위해 TaskJuggler를 참조합니다. 우리는 TaskJuggler의 소스 코드를 사용하거나 수정하거나 복사한 적이 없습니다. ScriptPlan은 독립적인 클린룸(clean-room) 구현체입니다.

.tjp 파일 형식은 공개적으로 문서화되었으며 프로젝트 관리 커뮤니티에서 널리 사용됩니다.
ScriptPlan의 모든 스케줄링 알고리즘, 파서 및 보고서 생성 기능은 독자적인 구현체입니다.
TaskJuggler는 ScriptPlan이 동일한 프로젝트 파일 형식을 읽을 수 있음을 나타내기 위해서만 언급되었습니다.

상호작용 HTML 보고서와 GUI 도구를 포함하여 전체 기능을 갖춘 원래의 TaskJuggler를 찾고 있다면, taskjuggler.org를 방문해 주십시오.

왜 ScriptPlan인가요? (Why ScriptPlan?)

이 스케줄러는 Highway Workflow Engine의 워커 용량 관리 시스템 일부입니다. 저는 이 정밀한 스케줄링 기능을 커뮤니티가 활용할 수 있도록 오픈소스로 공개하기로 결정했습니다. TaskJuggler에 이미 확립된 문법 덕분에, 사용자들은 새로운 형식을 학습할 필요 없이 ScriptPlan을 쉽게 도입할 수 있습니다.

Farshid 드림.

ScriptPlan: 자원 할당 및 의존성 관리를 위한 정밀 프로젝트 스케줄링 엔진

요약

핵심 포인트