/*
* This file contains an example project. It is part of the
* TaskJuggler project management tool. It uses a made up software
* development project to demontrate some of the basic features of
* TaskJuggler. Please see the TaskJuggler manual for a more detailed
* description of the various syntax elements.
*/
project acso "Accounting Software" "1.0" 2002-01-16 2002-04-28 {
# Pick a day during the project that will be reported as 'today' in
# the project reports. If not specified the current day will be
# used, but this will likely be ouside of the project range, so it
# can't be seen in the reports.
now 2002-03-05-13:00
# Hide the clock time. Only show the date.
timeformat "%Y-%m-%d"
# The currency for all money values is EUR.
currency "EUR"
# We want to compare the baseline scenario, to one with a slightly
# delayed start.
scenario plan "Plan" {
scenario delayed "Delayed"
}
}
# This is not a real copyright for this file. It's just used as an example.
copyright "© 2002 Crappy Software, Inc."
# The daily default rate of all resources. This can be overriden for each
# resource. We specify this, so that we can do a good calculation of
# the costs of the project.
rate 310.0
# This is one way to form teams
macro allocate_developers [
allocate dev1
allocate dev2 { limits { dailymax 4h } }
allocate dev3
]
flags team
resource dev "Developers" {
resource dev1 "Paul Smith" { rate 330.0 }
resource dev2 "Sébastien Bono"
resource dev3 "Klaus Müller" { vacation 2002-02-01 - 2002-02-05 }
flags team
}
resource misc "The Others" {
resource test "Peter Murphy" { limits { dailymax 6.4h } rate 240.0 }
resource doc "Dim Sung" { rate 280.0 vacation 2002-03-11 - 2002-03-16 }
flags team
}
# In order to do a simple profit and loss analysis of the project we
# specify accounts. One for the development costs, one for the
# documentation costs and one account to credit the customer payments
# to.
account dev "Development" cost
account doc "Dokumentation" cost
account rev "Payments" revenue
# Now we specify the work packages. The whole project is described as
# a task that contains sub tasks. These sub tasks are then broken down
# into smaller tasks and so on. The innermost tasks describe the real
# work and have resources allocated to them. Many attributes of tasks
# are inherited from the enclosing task. This saves you a lot of
# writing.
task AcSo "Accounting Software" {
# All work related costs will be booked to this account unless the
# sub tasks specifies it differently.
account dev
task spec "Specification" {
# The effort to finish this task is 20 man days.
effort 20d
# Now we use the above declared macro to allocate the resources
# for this task. Since they can work in parallel, this task may be
# finshed earlier than 20 working days.
${allocate_developers}
# Each task that does not have sub tasks must have a start or end
# criteria and a duration. For this task we use a reference to a
# further down defined milestone as a start criteria. So this task
# cannot start, before the specified milestone has been reached.
# References to other tasks may be relative. Each ! means 'in the
# scope of the enclosing task'. To descent into a task the .
# together with the id of the tasks have to be specified.
depends !deliveries.start
}
task software "Software Development" {
# The software is the most critical task of the project. So we set
# the priority of this tasks (and all sub tasks) to 1000, the top
# priority. The higher the priority the more likely will the task
# get the requested resources.
priority 1000
task database "Database coupling" {
effort 20d
# This task depends on a task in the scope of the enclosing
# tasks enclosing task. So we need 2 ! to get there.
depends !!spec
allocate dev1, dev2
}
task gui "Graphical User Interface" {
effort 35d
# This task has taken 5 man days more than originally planned.
# We record this as well, so that we can generate reports that
# compare the delayed schedule of the project to the original plan.
delayed:effort 40d
depends !database, !backend
allocate dev2, dev3
}
task backend "Back-End Functions" {
effort 30d
# This task is behind schedule since it should have been
# finished already. To document this we specify that the tasks
# is 95% completed. If nothing is specified, TaskJuggler assumes
# that the task is on schedule and computes the completion rate
# according to the current day and the plan data.
complete 95
depends !database, !!spec
allocate dev1, dev2
}
}
task test "Software testing" {
task alpha "Alpha Test" {
# Efforts can not only be specified as man days, but also man
# weeks, man hours, etc. Per default taskjuggler assumes a man
# week is 40 man hours or 5 man days. These values can be
# changed though.
effort 1w
depends !!software
allocate test, dev2
note "Hopefully most bugs will be found and fixed here."
}
task beta "Beta Test" {
effort 4w
depends !alpha
allocate test, dev1
}
}
task manual "Manual" {
effort 10w
depends !deliveries.start
allocate doc, dev3
account doc
}
task deliveries "Milestones" {
# Some milestones have customer payments associated with them. We
# credit these payments to the 'rev' account.
account rev
task start "Projectstart" {
# A task that has no duration is a milestone. It only needs a
# start or end criteria. All other tasks depend on this task.
milestone
start 2002-01-16
# For some reason the actual start of the project got delayed.
# We record this, so that we can compare the plan run to the
# delayed run of the project.
delayed:start 2002-01-20
# At the begining of this task we receive a payment from the
# customer. This is credited to the account assiciated with this
# task when the task starts.
startcredit 33000.0
}
task prev "Technology Preview" {
milestone
depends !!software.backend
startcredit 13000.0
}
task beta "Betaversion" {
milestone
depends !!test.alpha
startcredit 13000.0
}
task done "Ship Product to customer" {
milestone
# The next line can be uncommented to trigger a warning about
# the project being late. For all tasks limits for the start and
# end value can be specified. Those limits are checked after the
# project has been scheduled. For all violated limits a warning
# is issued.
# maxend 2002-04-17
depends !!test.beta, !!manual
startcredit 14000.0
}
}
}
# Now the project has been completely specified. Stopping here would
# result in a valid TaskJuggler file that could be processed and
# scheduled. But no reports would be generated to visualize the
# results. So we define 2 interactive reports, 7 HTML reports and
# 1 XML report.
# This task report is for use with the TaskJugglerUI. It provides a
# first overview of the project
taskreport "Project Overview" {
headline "Accounting Software Project - Overview"
columns index, name, start, end, effort, duration, completed, status, note
hideresource 1
scenario delayed
}
# Another report showing a Gantt chart
taskreport "Gantt Chart" {
headline "Accounting Software Project - Gantt Chart"
columns hierarchindex, name, start, end, effort, duration, chart
hideresource 1
scenario plan
}
# A report with cost and revenue numbers
taskreport "Project Cost and Revenue" {
headline "Accounting Software Project - Cost and Revenue"
columns hierarchindex, name, start, end, cost, revenue
hideresource 1
scenario delayed
}
# A resource report for use with the TaskJuggler GUI
resourcereport "Resource Usage" {
headline "Accounting Software Project - Resource Allocations"
columns name, effort, freeload, utilization, rate, chart
scenario delayed
hideresource 0
loadunit days
}
# For conveniance we would like each report to contain links to the
# other reports. So we declare a macro with a fragment of raw HTML
# code to be embedded into all the HTML reports.
macro navbar [
rawhead
'
'
]
# As the first report, we would like to have a general overview of all
# tasks with their computed start and end dates. For better
# readability we include a calendar like column that lists the effort
# for each week.
htmltaskreport "Tasks-Overview.html" {
# This report should contain the navigation bar we have declared
# above.
${navbar}
# The report should be a table that contains several columns. The
# task and their information form the rows of the table. Since we
# don't like the title of the effort column, we change it to "Work".
columns hierarchindex, name, duration, effort { title "Work"},
start, end, weekly
# For this report we like to have the abbreviated weekday in front
# of the date. %a is the tag for this.
timeformat "%a %Y-%m-%d"
# Don't show load values.
barlabels empty
# Set a title for the report
headline "Accounting Software Project"
# And a short description what this report is about.
caption "This table presents a management-level overview of the
project. The values are days or man-days."
}
# Now a more detailed report that shows all jobs and the people
# assigned to the tasks. It also features a comparison of the plan and
# delayed scenario.
htmltaskreport "Tasks-Details.html" {
${navbar}
# Now we use a daily calendar.
columns no, name, start, end, scenario, daily
#start 2002-03-01
#end 2002-04-01
# Show plan and delayed scenario values.
scenarios plan, delayed
headline "Accounting Software Project - March 2002"
caption "This table shows the load of each day for all the tasks.
Additionally the resources used for each task are listed. Since the
project start was delayed, the delayed schedule differs significantly
from the original plan."
# Don't hide any resources, that is show them all.
hideresource 0
}
# The previous report listed the resources per task. Now we generate a
# report the lists all resources.
htmlresourcereport "Staff-Overview.html" {
${navbar}
# Add a column with the total effort per task.
columns no, name { cellurl "http://www.tj.org" }, scenario, weekly, effort
scenarios plan, delayed
# Since we want to see the load values as hours per week, we switch
# the unit that loads are reported in to hours.
loadunit hours
headline "Weekly working hours for the Accounting Software Project"
}
# Now a report similar to the above one but with much more details.
htmlresourcereport "Staff-Details.html" {
${navbar}
columns name, daily, effort
# To still keep the report readable we limit it to show only the
# data for March 2002.
start 2002-01-16
end 2002-04-01
hidetask 0
# The teams are virtual resources that we don't want to see. Since
# we have assigned a flag to those virtual resource, we can just
# hide them.
hideresource team
# We also like to have the report sorted alphabetically ascending by
# resource name.
sortresources nameup
loadunit hours
headline "Daily working hours for the Accounting Software Project -
March 2002"
}
htmlweeklycalendar "Calendar.html" {
${navbar}
headline "Ongoing Tasks - March 2002"
start 2002-03-01
end 2002-04-01
}
htmlstatusreport "Status-Report.html" {
${navbar}
}
# To conclude the HTML reports a report that shows how badly the
# project is calculated is generated. The company won't get rich with
# this project. Due to the slip, it actually needs some money from the
# bank to pay the salaries.
htmlaccountreport "Accounting.html" {
${navbar}
# Besides the number of the account and the name we have a column
# with the total values (at the end of the project) and the values
# for each month of the project.
columns no, name, scenario, total, monthly
headline "P&L for the Accounting Software Project"
caption "The table shows the profit and loss
analysis as well as the cashflow situation of the Accounting
Software Project."
# Since this is a cashflow calculation we show accumulated values
# per account.
accumulate
scenarios plan, delayed
}
# Finally we generate an XML report that contains all info about the
# scheduled project. This can be used to export the schedule project to
# other applications that can read the TaskJuggler XML fine.
xmlreport "AccountingSoftware.tjx" {
version 2
}