thanks I will have a look.
Now busy building furnitures :)
Le 2/1/15 08:36, Daniel Lyons a écrit :
On Dec 28, 2014, at 3:17 PM, stepharo <steph...@free.fr
<mailto:steph...@free.fr>> wrote:
I would be interested by having an example that I could use to
rewrite the spec documentation:
- would be good to have a kind of container relationships
to be able to display multiple list
- the model should not be too complex to explain.
So if you have data and idea I'm all ears.
I have about 1/2 of an application written to implement PERT, which is
something management types study for doing project cost estimation,
but usually don't use in reality. It has a nice container hierarchy
(Project > Phase > Task > Task > ... > Task). I have part of the UI
written in Glamour and part in Spec, but it isn't finished. I'm using
this as a tutorial to teach my wife Pharo—although I'm probably not so
great at it that I should be teaching anybody. :) The tutorial isn't
as far along as the application and is probably wrongly titled at this
point.
I'm happy to give away the code and the tutorial but I'm a little
stuck now since we have just had a baby and are now preparing to move
in three weeks. So I apologize for the rough state of affairs, but
since you asked I only hope it may be better than nothing.
The tutorial can be read here: http://st.7gf.org/PERT/
PDF: http://st.7gf.org/PERT/PERT.pdf
Markdown source: http://st.7gf.org/PERT/PERT.md
Additionally I have a whiteboard capture of the interface I envision
with Glamour (which may or may not be appropriate). The size is quite
large despite the low quality, my apologies:
http://st.7gf.org/PERT/project-window.jpg
http://st.7gf.org/PERT/simulation-window.jpg
http://st.7gf.org/PERT/project-graph-diagram.jpg
It would be hard to come up with a more "boring" and "business"
application domain than this… but for management people the problem is
pretty well-known and for my wife, her only prior programming
experience (not counting Excel) is C and the experience has been
positive for her so far. She's also greatly enjoying going through my
paper copy of Pharo by Example and the built-in tutorial.
The basic concept, in case anyone is interested, is that you can form
a directed acyclic graph between subtasks and then using min/max cost
estimates, determine which tasks are "critical" and which tasks can be
late without affecting the deadline or budget. The "project window"
above uses a GLFinder-like approach to allow drilling down into
subtasks from projects and phases. This means you're stuck with a tree
instead of a DAG.
The target level of sophistication for the final application is one
that can use expected costs and a beta distribution to simulate
thousands of different possible outcomes and then aggregate from there
to see which tasks are likely to be troublesome or have bad estimates.
This is what is pictured in the simulation-window mockup.
The project graph diagram is just a sketch of something that would be
trivial to do with Roassal.
The project and task/activity objects should be fairly obvious. Phase
is just recognition of the idea that projects are usually implemented
in phases, and you usually have to complete one phase before starting
the next: e.g., you must have made the prototype before you can put it
into production. This layer is unnecessary from a computational point
of view (there's nothing like it in the wiki page for PERT either) but
it's a helpful organizational tool, plus it lets you create a nice
boundary to get back some of the nice things about having a DAG that
you lose with a tree representation.
I don't know if this is what you're looking for or not but here it is.
All the best,
—
Daniel Lyons
