Facilities Management Software.

[Bart Bartels]

Andrae,

THANK you.  I think that I will take your advice.  This sounds like a good way
to do the initial development and I will also take John Socha's advise and
take the minimalist approach i.e. start using the software as soon as it
starts to work and refine from there.

I am taking the liberty of posting this to the newsgroup as it is good advice
for any beginner

Andrae Muys wrote:

> Noticed your post to comp.lang.python, thought I might just contribute my
> 2c worth.
>
> I'm a software developer by profession, currently working on an xml
> interface to a travel agency's backend system.  I don't have the time to
> assist you directly with your project, however as I have a moment I
> thought I might contribute some advice.
>
> Work out the minimum amount of functionality required to make the
> application useful to you and implement that first.  I suspect that your
> outline post does that adequately.
>
> To summarise your post:
>
> A four stage workflow for requests:
>  S1 - Enter job requests.
>  S2 - Allocate job requests.
>  S3 - Provide feed back to requester.
>  S4 - Close job request.
>
> With two actions permitted at any point after S1.
>
>  A1 - Add misc info to request.
>  A2 - Generate Reports.
>
> The only reports I would support at this stage would be
>
>  R1 - Show request.
>  R2 - List requests.
>
> This gives 8 tasks that your program would need to do.
>
> Regarding the initial architecture I would *not* use the web.  Personally
> I would write my first version to use plain text files stored in
> directories.  This would be moved to some sort of network
> database/repository later, but the important thing for now is to keep it
> simple and functional.
>
> Specifically I would use a directory layout along the lines of
>
> /<app-root>/new-requests/
> /<app-root>/allocated-requests/
> /<app-root>/closed-requests/
>
> Assuming you don't already have a system for allocating request numbers, I
> would just use the current date & time in seconds, as it is unlikely that
> you will create two requests in the same second :).
>
> So requests are plain ascii text files named 2001-08-23-131231.req where
> that date is 1:12:31pm 23rd August 2001.
>
> The contents of the file would be very simple, and best of all, human
> readable.  Along the lines of:
>
> Requester: Andrae Muys
> Phone Number: x54643
> Email Address: andrae at humbug.org.au
> Problem: Broken door handle.
> Location Room 201 Building 52
> Allocated To: John Doe
> Authorised: Mr P.H.Boss.
> etc...
> etc...
> 2001-08-23-132131:
>
> So:
>  S1 - Creates a request file in the new-requests directory.
>  S2 - Adds required rows to file and moves it to allocated-requests/
>  S3 - Requires notification scheme to do properly, but for now we cheat
> and make it the last step of S2.
>  S4 - Adds required rows to file and moves it to closed-requests/
>
>  A1 - Adds extra timestamped rows to file.
>
>  R1 - Displays the contents of a file.
>  R2 - Displays a directory listing, possibly including a summary of the
> contents of each file
>
> So you write 6 small programs
>
> create_request.py : S1
> allocate_request.py : S2/3
> close_request.py : S4
> annotate_request.py : A1
> list_requests.py : R2
> show_request.py : R1
>
> Once you reach this point you will know enough about the problem to
> intelligently decide how to integrate XML/Web/notification/databases/etc.
> More importantly, you will know enough to decide if and *very* importantly
> WHERE you need to use more complicated technologies.
>
> Good luck,
>
> Andrae Muys