Again, my comments in blue
On 11/30/06, Shawn Abigail <[EMAIL PROTECTED]> wrote:
I like the Cycle 1 to 4 approach Carlos suggests. I will let you know when
Claus and Gil respond, or preferably they can simply respond to the
dev-list
themselves with their suggestions and preferences.
It would probably be dangerous to let me code on this project 8-), so I
will leave the definition of the development environment and tools to
others. My only suggestion is that whatever language is chosen, we find an
open source tool which can do static code analysis and insist on clean
runs
before we check code in. I was involved in the analysis of a major code
base
15 years after development started, and I think it would be a really good
idea to use some of these scanning tools right from the start.
My main background is Java, but I have also worked on projects where C++
was the main tool, one thing I'd like to hear about the other guys in the
list, is what their ideas are as far as development tools go for projects of
OOo. To be honest I have never seen a line of code for OOo, I believe it is
coded in C++ but I've also read on the site that Java can be used with it,
so if somebody could clarify this for me I'd be very thankful. In any case I
think we could use Eclipse for IDE (we can use the CDP plug-in if we decide
to go for C++), Ant for building, JUnit (or a C++ equivalent)...
I did review most of the wish list suggestions before coming up with my
suggestions for R0.1 functionality. The R0.1 functionality I suggested
provides a foundation that we could build additional wish list function
on.
Perhaps I can elaborate on some of my suggestions for R0.1.
Internal Data Structures Defined:
Just about every user operation is going to use an internal data structure
which holds all project information. Saving the project will involve
writing
this information out, and loading a project will involve reading this
information into the data structure. Creating a new project will mean
initializing the data structure. If we allow several projects to be open
at
the same time, we'll need to have a way of jockeying several of these data
structures together. We will probably want standard routines to handle
reading, writing and searching the data structure. So this is something we
will need to get correct right from the start. No, this is not a user
visible feature, and we'll have to be careful about blurring the
distinction
between requirements and implementation details. But it is something we
will
need to plan for in R0.1.
I think that if we format the project (OOPM file) as XML we could kill two
birds with one shot, because the XML DOM would serve as our main data
structure and we could output it to a file for persistence.
File Format Defined:
Saving the project to a file and reading a project in from a file is
fairly
basic functionality. This needs to be in R0.1.
I/O Module Defined:
All loading and saving of the project should be handled through an I/O
module (or a set of library routines). At some point in the future we may
want to replace the flat file format with a database. By having all
loading
and saving functionality work through an I/O module, we could move to a
different file format or move to database storage of the project without
much difficulty. Basically this is the implementation of the save and load
functionality, so it needs to be in R0.1.
I agree on this, we should make is as extensible as possible, just in case
the user wants to use a DB as storage.
2 Layer Architecture Defined:
This one is going to require some explaining, because I think there are a
number of significant advantages, but it is going to require a lot of
extra
work in R0.1. I'd like to suggest a thin user interface which communicates
with a thick core that contains most of brains of the application. This
would obviously require extra work, but there are two significant
advantages. First, I'd really like to design this software with automated
testing in mind. Provided a scripting language can do the same calls the
interface would generate, it should be possible to develop an extensive
automated regression suite. Second, at some point we may want to have this
run as a client/server application with multiple users running the
interface
and a single core back end processing all the project inputs (and the back
end running on a different computer, in a different geographical location,
possibly behind a firewall). I know, I'm asking for a lot! But if we do it
this way it opens up a lot of really great possibilities for the future;
possibilities which would differentiate our application from MS-Project.
If
we don't put this in the very first release (R0.1) we will never get
around
to doing it this way in the future.
I also agree on this, I have worked on N Layer projects (mostly for Web) and
they can be very flexible, although this can be dangerous because we could
end up with a lot of small intermediate layers that will slow down the app,
we need to put some thinking on this so we can come up with a solution that
is both flexible and performs well.
WBS on Interface:
Everything I've mentioned so far is design and architecture. None of it is
user visible, and none of it has anything to do with the user's projects.
So
R0.1 needs to have a way of entering information for the Work Breakdown
Structure for each task. This will be entered through the interface, and
stored in the internal data structure. This isn't much by way of user
functionality, but the foundational work we do in this first release will
put us in good shape for the next release.
I think this is very important because we need so show something to the user
(and the community) so they can believe we are working :D
Again, all this is open for comment. I have lots of ideas, but I'm no prima
donna trying to force my vision on others.
Same on my part, this are just my 2 cents, I just want to see the project
rolling...
Regards,
Shawn
Regards,
Carlos
----- Original Message -----
From: "Carlos Luis Zúñiga Sibaja" <[EMAIL PROTECTED]>
To: <dev@oopm.openoffice.org>
Sent: Thursday, November 30, 2006 10:27 PM
Subject: Re: [oopm-dev] Potential Roadmap for OOPM (was Activity Level...)
See my comments below in blue
On 11/30/06, Shawn Abigail <[EMAIL PROTECTED]> wrote:
>
> This could end up as the first software project in history where there
are
> more people interested in writing requirements than in coding. 8-)
>
>
> I sent an email to the two project coordinators today (Claus and Gil) to
> ask
> them what their level of interest is in this project, and whether some
> work
> behind the scenes has been proceeding. I'd like to avoid stepping on
> peoples
> toes if they are still interested in driving this project. If they are
> interested, they can speak up. Otherwise I'd suggest we proceed.
Please let us know what Claus and Gil responded...
As has been mentioned, this is complex software, and so I'd like to
propose
> a roadmap that involves walking before running. If there is general
> agreement on the roadmap, we can then prepare the requirements
> specification
> for Release 0.1, sign up a development team, produce a schedule,
etc. The
> roadmap I'd like to propose (and this is definitely an Request For
> Comment)
> is as follows:
I think before establishing a stable roadmap we should examine the wish
list
and see which requirement/wish corresponds to each release.
On the other hand, I'm 100% behind you on the walk-before-run approach,
and
I'd like refine Release 0.1 a little bit more:
Release 0.1 - internal data structures defined, file format defined, 2
layer
> architecture defined, I/O module defined, WBS on interface
+ Cycle 1
- Define project tree structure
- Define dev environment and tools (these should be recommendations
not hard constraints)
+ Cycle 2
- Define architecture
- Define data structures
+ Cycle 3
- Define I/O module
- Create Task, Resource and Calendar maintenance interface
+ Cycle 4
- Create WBS interface
Release 0.2 - GANTT chart display, basic MS-Project file conversion,
> automated test hooks
>
> Release 0.3 - GANTT chart drag and drop, Critical path, baseline,
printing
>
> Release 0.4 - Resource view, resource graph, resource leveling,
assigning
> resources to tasks, vacation calendar, stat holidays calendar
>
> Release 0.5 - PERT chart, tracking GANTT
>
>
>
> So realistically, following a walk before you run approach, what should
> the
> roadmap include for the first couple of development releases? Is my
> proposal
> for some definitions and architecture in R0.1 realistic, with the only
> interface visible component being the ability to enter, save and load a
> WBS?
As Shawn says, my comments are open for discussion and I'd love to hear
other ideas :D
Let me know what you think. And again I apologize if I'm stepping on
> anyone's toes. I'd just really like to see this project moving along!
I'm very glad to see the activity building up, I hope we keep it up!
Regards,
> Shawn Abigail
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Carlos Luis Zúñiga Sibaja
__________________________
[EMAIL PROTECTED]
divide et impera...
