I infere from one of messages posted by Chris (and other one by myself) to the "Open Discussion" forum, that we have a vague proposal for V1 (it was a projectile, wasn't it).
It would be a project planning application with project tracking capabilities, networked.
Please, list essential (in your opinion) features (like diagram types, reporting capabilities, important architectural issues etc.).
I assume next step should be to establish a task of defining requirements. Then we should charge someone with the important task of drawing first version of the requirements document for V1.
Feel free to suggest your features as well as changes to the action plan I suggested above.
Regards,
Marcin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This article consists of two parts. The first one is rather philosophical and considers why we need these requirements and what they are for. I personally like this kind of introduction, because they make me feel clever.
This is a nice feeling, after all. If someone would prefer to skip my dubious theories about software development principles, than he might choose go directly to part two, titled "Proposed feature list for Projectile V1". The second section lays out a list of features I found to be of the essence. I shall try to provide decent justification for each feature included. If you find something missing, feel free to suggest a feature or demand a decent justification of not including it.
A. Requirements vs. feature set
This is usual for software project to determine set of functional and technical objectives up front. The very idea is to assure, the effect of the project is something that meets (at least to reasonable extent) customers' expectations and is usable. Defining requirements also involved some technical matters - you have to design the system so it can bear certain workload, allow certain things etc.
This is extremely important for projects where the software is created for some specific company. If the thing is not working properly, customer is not going to pay (if this is in-house project, someone will get toast). However, this is not our case. For shrink-wrap type software, sold by pound (or by box, whatever) people rather think in terms of "competitive advantage" - how to devise a feature our clients may need and our competition has not (or has it conceived in some lousy way). Or maybe - they won't need it at all, but could be talked into thinking, they need it. This is not our case either.
Even though none of the cases matches us, I believe, the latter is closer to where we are. We want to propose users a system that can be used instead of shrink-wrapped software. At the beginning we will be able to offer much
narrower functionality and we shall try to compensate for it by being open-sourced, not-bloated and free (beer and speech). And of course quality has to be reasonable (this is also a requirement, by the way).
I think, that what we need is to define coherent set of features along with feasible technical architecture. We will not be able to be specific about some technical requirements (what kind of load should it take etc.).
Besides, it is not necessary, since the first iteration is going to end up in delivering something simple, yet useful. No one will be willing to use it for very fancy things at the first shot. If people would be willing it as desktop app, there will shall go. If the mobile or web aspect will prove more important, there shall we strengthen the program.
B. Proposed feature list for Projectile V1
1. Scope and objectives.
I think, we agreed, V1 was going to be a relatively unsophisticated project planning and tracking application with basic workgroup support. Let me broke these things in pieces:
a) planning
b) tracking
c) workgroup support
Now I will specify what exactly I understand by these phrases. The form is a1...an for each objective in group a. Ditto for b and c.
a0 - Program can handle multiple projects. Project consists of number of scheduled tasks. Dependencies (shared resources, timelines) can be viewed across projects.
a1 - User is able to schedule number of tasks in time. Tasks can be interdependent (1).
a2 - User is able to assign resources to tasks. Therefore there must be "resource definition". Program makes sure, unique resources(2) are not assigned to competing tasks performed at the same time.
a3 - User can define teams of people. A calendar can be established for each person. (Program is time-aware; besides, we don not support sweat shops ;-)).
a4 - Tasks are assigned to people(3) or teams.
a5 - Tasks can be nested (we support subtasks).
a6 - Program supports directly only waterfall (iterative projects are to be considered) (4).
a7 - Program does not have specific support for certain types of projects (like construction or software) (we should plan for it in future and develop or leave place for sort of "template" mechanism).
a8 - People and resources exist independently from projects. Teams can exist either between projects or be "persistent".
a8 - Interfaces for scheduling: Gantt chart, network view, list of tasks.
a9 - Views: Tasks assignments can be viewed globally, per team, per person and per resource (either interactive or static reports - details TBD).
b1 - Program (if appropriately configured) may fire alarms, when a task should be completed (but is not marked as such), when task should be started). Status of these alarm clocks should be on per-task basis (we can switch off something for a certain tasks without switching off all others)
b2 - Users can enter information stating how much certain tasks are advanced (for tasks containing subtasks it shall be calculated automatically, using underlying data).
b3 - Reports describing projects' advance can be generated.
b4 - Tasks can be rescheduled while project is pending. Information about original scheduling shall be stored (at user's discretion) for later reference.
c1 - Access to tasks / subtasks based on privileges assigned.
c2 - Possibility of receiving customized wake-up calls.
c3 - Negotiating changes in schedule, messaging between task members, projects' resource storage, mobile capabilities shall not be implemented in this version (say, we save this for later).
Glossary
(1) Tasks can be interdependent - one may depend on completion of another one(s) or on certain percentage done. Dependencies can include lag time (forward and backward).
(2) Resources can be owned and priced (priced are infinite, we are not dealing with shortages here). Resource can be marked, that it can be assigned only to one task at all times (but user can override this constraint).
(3) People work according to the calendar. Program warns if a person is "overworked" - like too many concurrent tasks.
(4)Waterfall model is quite obvious. Support for iterative project would mean, that some task (maybe containing subtasks) could be repeated over and over again until a certain goal is achieved. If someone has an idea, how to model iterative tasks, do not hesitate to post a note regarding this.
2. Basic technical considerations.
There may be number of technical requirements. In addition to the very basic ones (cross-platform + python) I recognised the following:
There should be essentially two versions (types of installation)
a) multi-user, employing central storage (database), providing web-based interface and capable of raising alarms when due (that implies having a daemon/service separated from the GUI)
b) single-user, saving data in the file.
User interface and logic should be identical for both. This assumption implies certain way of design/implementation (this is why I found it necessary to put it here).
I guess, it would be natural to start with (b), but there are certain perils in doing so (like creating a monster, that will never become a robust, multi-user program).
*************
This is all for now, please fill free to suggest changes / additions to the list. Should you suggest something, please make sure, appropriate explanation is provided.
Some time next week (late next week) I will review possible submission and prepare new, better combed version of this draft.
Regards,
Marcin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Back from sunny NY - things seemed to have slowed up in the last couple of days.
I think we made some good progress and actually need to produce *something* now that we can play with.
Anyway, took a stab at some XML defs based on the requirements that are floating around. Planning to build a wxPython gui to read/create/edit them over the next couple of days - any suggestions for an existing XML parser in python (I'll search sourforge of course)?
My first use of XML so I have probably violated every rule.
Feel free to flame passionately - I have thick skin ;)
Simon
<?xml version="1.0" standalone="yes" ?>
<!-- This is the DTD for a PROJECT -->
<!-- S.Emmett 17 July 2000 -->
<!-- V 0.1 -->
<!DOCTYPE project [
<!ELEMENT project (name, calendar, task*)>
<!ATTLIST project projectId ID #REQUIRED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT calendar (calendar)>
<!ELEMENT task (task)*>
<!ATTLIST task taskId IDREF #IMPLIED>
]
>
<!-- This is the DTD for a RESOURCE -->
<!-- S.Emmett 17 July 2000 -->
<!-- V 0.1 -->
<!DOCTYPE resource [
<!ELEMENT resource (name, calendar, skillType*)>
<!ATTLIST resource resourceId ID #REQUIRED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT calendar (calendar)>
<!-- I guess skillTypes are user defined -->
<!ELEMENT skillType (#PCDATA)>
]
>
<!-- This is the DTD for a TEAM -->
<!-- S.Emmett 17 July 2000 -->
<!-- V 0.1 -->
<!DOCTYPE team [
<!ELEMENT team (name, resource*)>
<!ATTLIST team teamId ID #REQUIRED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT resource (resource)*>
]
>
<!-- This is the DTD for a TASK -->
<!-- S.Emmett 17 July 2000 -->
<!-- This requires mucho work, particularly on summary vs milestone etc -->
<!-- V 0.1 -->
<!DOCTYPE task [
<!ELEMENT task (description, type, effort, constraint, assignedResource*>
<!ATTLIST task
taskId ID #REQUIRED
workType (fixedUnit | fixedDuration | fixedWork)
deadline CDATA #IMPLIED>
<!ELEMENT description (#PCDATA)>
<!-- Prob. need more types -->
<!ELEMENT type (milestone | summary | regular) >
<!ELEMENT milestone (#PCDATA) >
<!ELEMENT summary (task)*>
<!ELEMENT regular (#PCDATA) >
<!ELEMENT effort (#PCDATA) >
<!ATTLIST effort
unit (minutes | hours | days | weeks | months | quarters | years) #REQUIRED
quantity CDATA #REQUIRED
>
<!ELEMENT constraint (#PCDATA) >
<!ATTLIST constraint (asSoonAsPossible | asLateAsPossible | finishNoLaterThan | startNoLaterThan | finishNoEarlierThan | startNoEarlierThan | mustStartOn | mustFinishOn) >
<!ELEMENT assignedResource (team | resource)* >
]
>
<!-- This is the DTD for a DEPENDANCY-->
<!-- A dependancy represents the relationship between EXACTLY 2 tasks -->
<!-- S.Emmett 17 July 2000 -->
<!-- V 0.1 -->
<!DOCTYPE dependancy [
<!ELEMENT dependancy (taskA, taskB, dependancyType)>
<!ATTLIST dependancy
dependancyId ID #REQUIRED
leadTime CDATA #IMPLIED
lagTime CDATA #IMPLIED>
<!ELEMENT taskA (taskId) >
<!ATTLIST taskA taskId IDREF #REQUIRED>
<!ELEMENT taskB (task) >
<!ATTLIST taskB taskId IDREF #REQUIRED>
<!ELEMENT dependancyType (finishToStart | startToStart | finishToFinish | startToFinish)
]
>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I infere from one of messages posted by Chris (and other one by myself) to the "Open Discussion" forum, that we have a vague proposal for V1 (it was a projectile, wasn't it).
It would be a project planning application with project tracking capabilities, networked.
Please, list essential (in your opinion) features (like diagram types, reporting capabilities, important architectural issues etc.).
I assume next step should be to establish a task of defining requirements. Then we should charge someone with the important task of drawing first version of the requirements document for V1.
Feel free to suggest your features as well as changes to the action plan I suggested above.
Regards,
Marcin
This article consists of two parts. The first one is rather philosophical and considers why we need these requirements and what they are for. I personally like this kind of introduction, because they make me feel clever.
This is a nice feeling, after all. If someone would prefer to skip my dubious theories about software development principles, than he might choose go directly to part two, titled "Proposed feature list for Projectile V1". The second section lays out a list of features I found to be of the essence. I shall try to provide decent justification for each feature included. If you find something missing, feel free to suggest a feature or demand a decent justification of not including it.
A. Requirements vs. feature set
This is usual for software project to determine set of functional and technical objectives up front. The very idea is to assure, the effect of the project is something that meets (at least to reasonable extent) customers' expectations and is usable. Defining requirements also involved some technical matters - you have to design the system so it can bear certain workload, allow certain things etc.
This is extremely important for projects where the software is created for some specific company. If the thing is not working properly, customer is not going to pay (if this is in-house project, someone will get toast). However, this is not our case. For shrink-wrap type software, sold by pound (or by box, whatever) people rather think in terms of "competitive advantage" - how to devise a feature our clients may need and our competition has not (or has it conceived in some lousy way). Or maybe - they won't need it at all, but could be talked into thinking, they need it. This is not our case either.
Even though none of the cases matches us, I believe, the latter is closer to where we are. We want to propose users a system that can be used instead of shrink-wrapped software. At the beginning we will be able to offer much
narrower functionality and we shall try to compensate for it by being open-sourced, not-bloated and free (beer and speech). And of course quality has to be reasonable (this is also a requirement, by the way).
I think, that what we need is to define coherent set of features along with feasible technical architecture. We will not be able to be specific about some technical requirements (what kind of load should it take etc.).
Besides, it is not necessary, since the first iteration is going to end up in delivering something simple, yet useful. No one will be willing to use it for very fancy things at the first shot. If people would be willing it as desktop app, there will shall go. If the mobile or web aspect will prove more important, there shall we strengthen the program.
B. Proposed feature list for Projectile V1
1. Scope and objectives.
I think, we agreed, V1 was going to be a relatively unsophisticated project planning and tracking application with basic workgroup support. Let me broke these things in pieces:
a) planning
b) tracking
c) workgroup support
Now I will specify what exactly I understand by these phrases. The form is a1...an for each objective in group a. Ditto for b and c.
a0 - Program can handle multiple projects. Project consists of number of scheduled tasks. Dependencies (shared resources, timelines) can be viewed across projects.
a1 - User is able to schedule number of tasks in time. Tasks can be interdependent (1).
a2 - User is able to assign resources to tasks. Therefore there must be "resource definition". Program makes sure, unique resources(2) are not assigned to competing tasks performed at the same time.
a3 - User can define teams of people. A calendar can be established for each person. (Program is time-aware; besides, we don not support sweat shops ;-)).
a4 - Tasks are assigned to people(3) or teams.
a5 - Tasks can be nested (we support subtasks).
a6 - Program supports directly only waterfall (iterative projects are to be considered) (4).
a7 - Program does not have specific support for certain types of projects (like construction or software) (we should plan for it in future and develop or leave place for sort of "template" mechanism).
a8 - People and resources exist independently from projects. Teams can exist either between projects or be "persistent".
a8 - Interfaces for scheduling: Gantt chart, network view, list of tasks.
a9 - Views: Tasks assignments can be viewed globally, per team, per person and per resource (either interactive or static reports - details TBD).
b1 - Program (if appropriately configured) may fire alarms, when a task should be completed (but is not marked as such), when task should be started). Status of these alarm clocks should be on per-task basis (we can switch off something for a certain tasks without switching off all others)
b2 - Users can enter information stating how much certain tasks are advanced (for tasks containing subtasks it shall be calculated automatically, using underlying data).
b3 - Reports describing projects' advance can be generated.
b4 - Tasks can be rescheduled while project is pending. Information about original scheduling shall be stored (at user's discretion) for later reference.
c1 - Access to tasks / subtasks based on privileges assigned.
c2 - Possibility of receiving customized wake-up calls.
c3 - Negotiating changes in schedule, messaging between task members, projects' resource storage, mobile capabilities shall not be implemented in this version (say, we save this for later).
Glossary
(1) Tasks can be interdependent - one may depend on completion of another one(s) or on certain percentage done. Dependencies can include lag time (forward and backward).
(2) Resources can be owned and priced (priced are infinite, we are not dealing with shortages here). Resource can be marked, that it can be assigned only to one task at all times (but user can override this constraint).
(3) People work according to the calendar. Program warns if a person is "overworked" - like too many concurrent tasks.
(4)Waterfall model is quite obvious. Support for iterative project would mean, that some task (maybe containing subtasks) could be repeated over and over again until a certain goal is achieved. If someone has an idea, how to model iterative tasks, do not hesitate to post a note regarding this.
2. Basic technical considerations.
There may be number of technical requirements. In addition to the very basic ones (cross-platform + python) I recognised the following:
There should be essentially two versions (types of installation)
a) multi-user, employing central storage (database), providing web-based interface and capable of raising alarms when due (that implies having a daemon/service separated from the GUI)
b) single-user, saving data in the file.
User interface and logic should be identical for both. This assumption implies certain way of design/implementation (this is why I found it necessary to put it here).
I guess, it would be natural to start with (b), but there are certain perils in doing so (like creating a monster, that will never become a robust, multi-user program).
*************
This is all for now, please fill free to suggest changes / additions to the list. Should you suggest something, please make sure, appropriate explanation is provided.
Some time next week (late next week) I will review possible submission and prepare new, better combed version of this draft.
Regards,
Marcin
All,
Back from sunny NY - things seemed to have slowed up in the last couple of days.
I think we made some good progress and actually need to produce *something* now that we can play with.
Anyway, took a stab at some XML defs based on the requirements that are floating around. Planning to build a wxPython gui to read/create/edit them over the next couple of days - any suggestions for an existing XML parser in python (I'll search sourforge of course)?
My first use of XML so I have probably violated every rule.
Feel free to flame passionately - I have thick skin ;)
Simon
<?xml version="1.0" standalone="yes" ?>
<!-- This is the DTD for a PROJECT -->
<!-- S.Emmett 17 July 2000 -->
<!-- V 0.1 -->
<!DOCTYPE project [
<!ELEMENT project (name, calendar, task*)>
<!ATTLIST project projectId ID #REQUIRED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT calendar (calendar)>
<!ELEMENT task (task)*>
<!ATTLIST task taskId IDREF #IMPLIED>
]
>
<!-- This is the DTD for a RESOURCE -->
<!-- S.Emmett 17 July 2000 -->
<!-- V 0.1 -->
<!DOCTYPE resource [
<!ELEMENT resource (name, calendar, skillType*)>
<!ATTLIST resource resourceId ID #REQUIRED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT calendar (calendar)>
<!-- I guess skillTypes are user defined -->
<!ELEMENT skillType (#PCDATA)>
]
>
<!-- This is the DTD for a TEAM -->
<!-- S.Emmett 17 July 2000 -->
<!-- V 0.1 -->
<!DOCTYPE team [
<!ELEMENT team (name, resource*)>
<!ATTLIST team teamId ID #REQUIRED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT resource (resource)*>
]
>
<!-- This is the DTD for a TASK -->
<!-- S.Emmett 17 July 2000 -->
<!-- This requires mucho work, particularly on summary vs milestone etc -->
<!-- V 0.1 -->
<!DOCTYPE task [
<!ELEMENT task (description, type, effort, constraint, assignedResource*>
<!ATTLIST task
taskId ID #REQUIRED
workType (fixedUnit | fixedDuration | fixedWork)
deadline CDATA #IMPLIED>
<!ELEMENT description (#PCDATA)>
<!-- Prob. need more types -->
<!ELEMENT type (milestone | summary | regular) >
<!ELEMENT milestone (#PCDATA) >
<!ELEMENT summary (task)*>
<!ELEMENT regular (#PCDATA) >
<!ELEMENT effort (#PCDATA) >
<!ATTLIST effort
unit (minutes | hours | days | weeks | months | quarters | years) #REQUIRED
quantity CDATA #REQUIRED
>
<!ELEMENT constraint (#PCDATA) >
<!ATTLIST constraint (asSoonAsPossible | asLateAsPossible | finishNoLaterThan | startNoLaterThan | finishNoEarlierThan | startNoEarlierThan | mustStartOn | mustFinishOn) >
<!ELEMENT assignedResource (team | resource)* >
]
>
<!-- This is the DTD for a DEPENDANCY-->
<!-- A dependancy represents the relationship between EXACTLY 2 tasks -->
<!-- S.Emmett 17 July 2000 -->
<!-- V 0.1 -->
<!DOCTYPE dependancy [
<!ELEMENT dependancy (taskA, taskB, dependancyType)>
<!ATTLIST dependancy
dependancyId ID #REQUIRED
leadTime CDATA #IMPLIED
lagTime CDATA #IMPLIED>
<!ELEMENT taskA (taskId) >
<!ATTLIST taskA taskId IDREF #REQUIRED>
<!ELEMENT taskB (task) >
<!ATTLIST taskB taskId IDREF #REQUIRED>
<!ELEMENT dependancyType (finishToStart | startToStart | finishToFinish | startToFinish)
]
>
For XML/Python related resources see:
http://www.python.org/sigs/xml-sig/
http://www.vex.net/parnassus/apyllo.py?i=2678626
Regards,
Marcin