|
| Re: OSEE Setup Too Hard for Customers Who Do Requirements??? [message #10301 is a reply to message #10267] |
Mon, 14 April 2008 08:03   |
|
On Sun, 13 Apr 2008 21:15:31 +0000 (UTC), bengarbers@gmail.com (Ben
Garbers) wrote:
>
>I almost think that when designing this we should offer the flexibility of
>a user to choose whether they want to use an OSEE backend or to just input
>information where it would be stored in an xml based file. This would
>give customers flexibility to choose whether or not they would want to set
>up the osee environment so their eclipse clients could communicate to it.
I see your point that a user should not be concerned with servers
and/or DB connections.
On the other hand (from my experience) projects which actually use a
development process (with all the artefacts like requirements, test
specifications, ...) are done by several people. A file based solution
would be next to useless in such an environment. You can't get the
document locking and merging right and would end up having all files
scattered throughout the workspaces.
Considering the limited resources avalilable on OSEE/ORMF I would go
for a server/DB solution and try to include a small footstep server/DB
as a simple (and limited?) single user solution.
Achim
--
Achim Lörke
Eclipse-Stammtisch in the Braunschweig, Germany area:
http://www.bredex.de/de/career/eclipse.html
Achim Lörke
|
|
|
| Re: OSEE Setup Too Hard for Customers Who Do Requirements??? [message #10367 is a reply to message #10301] |
Tue, 22 April 2008 22:17 |
 Donald Dunne
Messages: 194
Registered: July 2009 |
Senior Member |
|
|
>
> Considering the limited resources avalilable on OSEE/ORMF I would go
> for a server/DB solution and try to include a small footstep server/DB
> as a simple (and limited?) single user solution.
>
>
> Achim
Great idea. We were thinking of providing 3 types of downloads from the
OSEE project site and would be very interested in any thoughts
recommendations.
One would be for the simplest of uses where we would bundle an open
source database, like Derby, with the release. This would allow the
user or small team of users to test out OSEE or use it for some simple
projects. One thing to keep in mind would be the difficulty of
providing a one-size-fits-all solution. We would need to provide an
easy way for the user to specify their requirements hierarchy in order
to configure OSEE correctly. This is where we like ORMF's solution of
providing schema's describing the models that could drive the
configuration and, as in ORMF, the creation of the specific editors
needed/desired by the user.
The second would be an OSEE release with database and demo data. This
would be our demonstration model that users could download and take for
a test drive. It would contain data and be tied tightly to screencasts
that describe the features of OSEE. We currently have a version of this
bundled with the PostgreSQL database (available via email, if
interested). Unfortunately, we can not provide it through the
Eclipse.org/osee site due to PostgreSQL's pedigree. Due to this, we are
feverishly trying to get Derby working for not only this solution, but
the previous one.
The third would be the deployment to a large and/or multi-site project
that would include all the steps necessary to configure and setup.
Although the simplest case could certainly work as a file-based system
and there are even solutions that exist that do this, our experience was
with 300+ users accessing artifact data in parallel. This is where re
ran into problems.
|
|
|
|
| Re: OSEE Setup Too Hard for Customers Who Do Requirements??? [message #10433 is a reply to message #10400] |
Wed, 23 April 2008 04:34 |
|
On 2008-04-22 23:26:27 +0100, Don Dunne <donald.g.dunne@boeing.com> said:
> Ben Garbers wrote:
>> input requirements information. If they are dependent on OSEE in
>> communicating with the plugin they will have to set this up which for
>> novice users could take some time. Individuals who do requirements
>> usually are not database setup savvy.
>
> Please see the more detailed post to Achim Lorke's response that lays
> out different approaches to deployment depending on the needs of the
> user.
>
> We definitely agree that there is a great need for a simple
> requirements solution. One of the deployments we planned to offer, and
> are certainly interested in comments, is an OSEE release bundled with a
> small footprint open source database like Derby. This would provide
> the basic capabilities without the large overhead of the server-side
> setup.
>
> We currently have one bundled with PostgreSQL, but are unable to
> provide it from the eclipse.org site due to it's pedigree (it is
> available via email if interested). It is a single executable jar that
> installs OSEE, PostgreSQL and populates the database with demo data.
> The user simply clicks the short-cut and is off. I would think the
> same solution could be provided for the simplest of deployments as long
> as we can figure out a good way to allow the user to
> configure/customize the installation to fit their requirements (or
> other artifact capture) needs.
For those who are not quite familiar with Derby, I would like to note a
couple of the key "features" of it.
1. It is a very low foot print database
2. It takes little (or no) management by the user, i.e. a DB Admin is
not necessary
3. It can be ran in embedded mode or server mode. In both cases its
life cycle can be managed by the application or application server, so
no extra overhead is put onto the user.
4. It is robust.
5. IBM will support it commercially if the end user desires the
security blanket.
We have been using for a few years with Useme/ORMF with next no problems.
Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
| Re: OSEE Setup Too Hard for Customers Who Do Requirements??? [message #563440 is a reply to message #10267] |
Mon, 14 April 2008 08:03 |
|
On Sun, 13 Apr 2008 21:15:31 +0000 (UTC), bengarbers@gmail.com (Ben
Garbers) wrote:
>
>I almost think that when designing this we should offer the flexibility of
>a user to choose whether they want to use an OSEE backend or to just input
>information where it would be stored in an xml based file. This would
>give customers flexibility to choose whether or not they would want to set
>up the osee environment so their eclipse clients could communicate to it.
I see your point that a user should not be concerned with servers
and/or DB connections.
On the other hand (from my experience) projects which actually use a
development process (with all the artefacts like requirements, test
specifications, ...) are done by several people. A file based solution
would be next to useless in such an environment. You can't get the
document locking and merging right and would end up having all files
scattered throughout the workspaces.
Considering the limited resources avalilable on OSEE/ORMF I would go
for a server/DB solution and try to include a small footstep server/DB
as a simple (and limited?) single user solution.
Achim
--
Achim Lörke
Eclipse-Stammtisch in the Braunschweig, Germany area:
http://www.bredex.de/de/career/eclipse.html
Achim Lörke
|
|
|
| Re: OSEE Setup Too Hard for Customers Who Do Requirements??? [message #563487 is a reply to message #10301] |
Tue, 22 April 2008 22:17 |
Donald Dunne
Messages: 194
Registered: July 2009 |
Senior Member |
|
|
>
> Considering the limited resources avalilable on OSEE/ORMF I would go
> for a server/DB solution and try to include a small footstep server/DB
> as a simple (and limited?) single user solution.
>
>
> Achim
Great idea. We were thinking of providing 3 types of downloads from the
OSEE project site and would be very interested in any thoughts
recommendations.
One would be for the simplest of uses where we would bundle an open
source database, like Derby, with the release. This would allow the
user or small team of users to test out OSEE or use it for some simple
projects. One thing to keep in mind would be the difficulty of
providing a one-size-fits-all solution. We would need to provide an
easy way for the user to specify their requirements hierarchy in order
to configure OSEE correctly. This is where we like ORMF's solution of
providing schema's describing the models that could drive the
configuration and, as in ORMF, the creation of the specific editors
needed/desired by the user.
The second would be an OSEE release with database and demo data. This
would be our demonstration model that users could download and take for
a test drive. It would contain data and be tied tightly to screencasts
that describe the features of OSEE. We currently have a version of this
bundled with the PostgreSQL database (available via email, if
interested). Unfortunately, we can not provide it through the
Eclipse.org/osee site due to PostgreSQL's pedigree. Due to this, we are
feverishly trying to get Derby working for not only this solution, but
the previous one.
The third would be the deployment to a large and/or multi-site project
that would include all the steps necessary to configure and setup.
Although the simplest case could certainly work as a file-based system
and there are even solutions that exist that do this, our experience was
with 300+ users accessing artifact data in parallel. This is where re
ran into problems.
|
|
|
|
| Re: OSEE Setup Too Hard for Customers Who Do Requirements??? [message #563535 is a reply to message #10400] |
Wed, 23 April 2008 04:34 |
|
On 2008-04-22 23:26:27 +0100, Don Dunne <donald.g.dunne@boeing.com> said:
> Ben Garbers wrote:
>> input requirements information. If they are dependent on OSEE in
>> communicating with the plugin they will have to set this up which for
>> novice users could take some time. Individuals who do requirements
>> usually are not database setup savvy.
>
> Please see the more detailed post to Achim Lorke's response that lays
> out different approaches to deployment depending on the needs of the
> user.
>
> We definitely agree that there is a great need for a simple
> requirements solution. One of the deployments we planned to offer, and
> are certainly interested in comments, is an OSEE release bundled with a
> small footprint open source database like Derby. This would provide
> the basic capabilities without the large overhead of the server-side
> setup.
>
> We currently have one bundled with PostgreSQL, but are unable to
> provide it from the eclipse.org site due to it's pedigree (it is
> available via email if interested). It is a single executable jar that
> installs OSEE, PostgreSQL and populates the database with demo data.
> The user simply clicks the short-cut and is off. I would think the
> same solution could be provided for the simplest of deployments as long
> as we can figure out a good way to allow the user to
> configure/customize the installation to fit their requirements (or
> other artifact capture) needs.
For those who are not quite familiar with Derby, I would like to note a
couple of the key "features" of it.
1. It is a very low foot print database
2. It takes little (or no) management by the user, i.e. a DB Admin is
not necessary
3. It can be ran in embedded mode or server mode. In both cases its
life cycle can be managed by the application or application server, so
no extra overhead is put onto the user.
4. It is robust.
5. IBM will support it commercially if the end user desires the
security blanket.
We have been using for a few years with Useme/ORMF with next no problems.
Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Powered by
FUDForum. Page generated in 5.05343 seconds
] 
Search
Help
Register
Login
Home
