-
Notifications
You must be signed in to change notification settings - Fork 1
/
Roadmap.txt
188 lines (172 loc) · 6.92 KB
/
Roadmap.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
This is a description of the next and next-next generation of to be
implemented features.
There is no exact time line because the amount of time spend for this
tools changes from time to time (depending on many factors). From
history it may be assumed that it takes about 6 to 8 weeks for one
release.
Also the version number shown here might change: if there are other
requests from customers those will be done first. Also it might be
that from time to time there is a bug-fix release of rmtoo.
The history of this file, i. e. the already implemented features can
be found the appropriate release notes.
There are some major aims to go for:
o Get rmtoo listed in the INCOSE tool survey.
o Get rmtoo added to at least one Linux distribution (preferred
Debian)
=> Mail to INCOSE was sent - they answered that they will include
rmtoo in their list as soon as possible. (Status 2011-02-14:
they move servers - therefore the inclusion will take some time.)
=> This will be the point of time to get rmtoo into one Linux
distribution - preferred Debian.
Problem: will eat up a lot of time
v21
===
o Remove RequirementsSet
o Clean up Git-History repeating (read also the topics from git)
o Improve git history:
o Update to a new version
o Read only the files which are needed
(delayed read in?!?)
o Document: Understanding that all requirements need at least one edge
solved it for me.
-> rmtoo general overview man page.
o Bug fixes!
- Time zone problem when running test cases
o Man page:
+ graph
+ graph2
+ EfEU
o Fix asserts from 'RequirementStatus.py'
v22
===
o Check Web-Site for user features / bugs
- Fix (small) bugs
- Add feature request requirements
v23
===
o Add to FAQ: max level of topic inclusion.
o Add changes to presentation
o More testcases
o Archive old versions from slashdot to flonatel.de
(leave only last three versions on slashdot)
o Major code refactoring is needed
- restriction of reqset to topic set
+ especially the new constraints
+ Is the 'reqset' needed at all?
+ How to 'restrict' different views? Have the same objects
around with different pointers or copy the objects?
IMPORTANT
=========
o Design GUI
- Server
- Clients
- Protocoll / Interface
o Add requirements from Roadmap.
o Rethink about the modules: they should also run (at least partially)
for the topic based output. Is there a way to unify this?
OTHER / LATER
=============
o Draw overview picture for current Sprint (a la 'Paper' overview with
'Chosen', 'In Progress' and 'Finished'.
o Now that the finished date and duration is available, gantt output
should be extended to use this.
o SCRUM Burndown diagram
o Due Date for all requirements as optional
o Requirement: prosponed, withdrawn as additional state of a requirement
o For later 'gantt' export:
start-date, end-date, ...
o Design issue: (from WEB)
If the intent of the original heuristic was to discover disconnected
(i.e. floating) topics, the checks should definitely be adjusted to
also count sub-topics and parent topics, as parent-child connections
are of course valid connections, too.
o Build a server which can serve as the interface to different GUIs
(e.g. native gtk, WEB, ...)
- Build gtk GUI
- Build WEB GUI
o Include sub-graphs in the PDF and HTML documentation
- Topic based (all reqs of a topic)
- req based (all reqs dependend and depend on one req)
- Try to implement this is a generic way that makes it
possible to include dot files from within a requirement.
(If this is not possible, add this to the OTHER / LATER
features.)
o Adapt man pages
o Adapt presentation
o It often happens that one requirement is resolved into two different
'types' of solutions:
1) The genral properties of all 'direct' solutions
2) The direkt solutions.
There is currently no way to differ between those two different
'types' of requirements. It should be elaborated if these are really
two 'types' or if this can be described with the current implemented
features.
o Long Term Evolution: It's all about data storage and who (which
program) can access (read, write, change, ...) which data.
- Write requirements
- Discuss with other projects (ganttproject, freemind, ...)
- Storage vs. Bus-System
- Verfügbarkeit
- Ausfallsicherheit
- Colaboration
- Concurrency
o Add makefile dependencies: .rmtoo_dependencies depends
on the ConfigX.py file.
o output level in 'prios.py' must be configurable
o traceability of changes
- Dependent on changes: list all depended requirements which must
be checked.
o Add change marks for at last latex output:
- specify one additional version number from which the difference is
made
- Mark
+ Additions
+ Changes
+ Deletions
(Should be not that hard when creating the difference based on the
requirements - but also the topics must be included)
o Translations / Intenationalization
- Input: possible define a new set of tags - one for each language.
o Topic includereqs: There is the need to at least specify ONE
requirement which is located before all others.
o Add version number to rmtoo -v or something
o Add roadmap feature
o Add ToDo list feature
o History in document: specify two versions and create automatically a
list of all changed requirements.
o Clean up code (XXX, ToDo, ...)
o Use MemLog instead of print.
o 'The only requirement management tool which comes with the
requirements for the tool'.
o A requirement cannot be 'finished' if on of the dependent is not
finished.
o Add glossary
o Add man page for glossary
o Add glossary to presentation
o Emacs mode for editing topic (tic) files.
o Better list of preconditions
(When is what needed? Version?)
Long Term Evolution or:
This will be another project
============================
Interaction between programs
----------------------------
The *nix base idea is: let one thing do one thing (but this very
well). Examples: mostly all commands in /bin and /usr/bin. They
all work on plain text files and every program has exactly one
functionality.
When looking to mostly all other areas of data processing, the
interaction of different programs is very, very limited - which
depends on the file format. Complex programs (like office word
processor) work on complex data. Mostly each program has it's own
file format. The file format is mostly not interchangeable with other
programs - and if so, it's mostly hard to convert and often some
aspects are lost during conversion.
Another aspect is, that mostly all programs work on the input data in
a way that they think they 'own' the data. When programs cannot deal
with data, they tend to either complain about corrupted input files or
they ignore the unknown parts in the way that when saving the read-in
data in a program those unknown parts are not contained any more.
Others just rename internally used labels and attributes in a way that
it is impossible to find the original elements after one of those
programs worked on them. Example: OpenOffice Calc.