On Mon, Nov 17, 2008 at 08:31, ray <Ray.Joseph_at_cdicorp.com> wrote:
> Andy,
>
> Thank you for the comments. I understand your statement about the
> solution with out a problem. In this case, I don't know what problems
> will come up in the future or what opportunities an analysis may
> conjecture. So I would like to collect data which would seem to carry
> some information about work processes. Then, when someonw chooses to
> study the behavior, there will be an existing set of data to analyse.
>
> CMM suggests that if you must deviate from the given project execution
> plan, the deviation should have statistical data to indicate that this
> direction has a greater chance of success than some other identifiable
> direction. This means that we should have data about our processes.
> Since file activities carry some information about processes, it seems
> that capturing that data might have some value. Of course such data
> would have to be correlated with higher level activities so other
> record keeping task cover that aspect.
I don't understand what file editing "habits" have to do with the
project execution plan in the first place. What does it matter, at the
project management level, how many times I open a file for editing, or
how many times I save it? What does it matter whether I perform one
commit of 20 changes related to a project, or 20 commits of one change
each for that same project? As long as the project is completed on
schedule and in accordance with our project/change management
processes, I'm doing things right.
This really sounds like a level of micromanagement which will only
bother developers and end users, and cause additional work for whoever
is overseeing the process. Unless one of the goals is job security for
the person overseeing/managing it all.
> Yes, auditing at the filesystem level could capture this info. But
> due to the features built into TSVN, it looks like it could be done
> here at just the right level on information.
Many of your "required" items from your original post can only be
achived via a combination of FS-level auditing, creating a custom SVN
client which you require be the exclusive SVN client used with your
repository, and some sort of required "editing environment" (IDE, for
example) which disallows editing of your code in any other fashion.
At that point, you're in a position of editing all your code directly
in a database, similar to how Vignette StoryServer (versions 4-6 are
the only ones I have experience with, so things may have changed w/
future releases) works, but there are even loopholes there that could
be exploited by someone who really dislikes working within that
editing environment (myself being one of those people).
> Andy, I would like to hear from you further.
>
> Ray
>
> On Nov 15, 6:56 pm, "Andy Levy" <andy.l..._at_gmail.com> wrote:
>> On Sat, Nov 15, 2008 at 19:49, ray <Ray.Jos..._at_cdicorp.com> wrote:
>> > An implication of the capability maturity model (CMM) is the
>> > collection of project data for subsequent statistical analysis for use
>> > to help determine the best practices.
>>
>> > I would like to collect data on project file access. I do not have a
>> > model to describe any requirements so I would like to collect a broad
>> > spectrum of process data.
>>
>> It sounds more like you're looking for a solution you haven't defined
>> without knowing what the problem is.
>>
>> > For example, record access of each file, how it is accessed (open,
>> > update, close, commit), the time of each activity and any user notes
>> > about the file.
>>
>> > Once the data is collected, it should be loaded into a database.
>>
>> > All this data should be at the client level.
>>
>> > I would appreciate all comments as to how to collect such data.
>>
>> I don't understand what these numbers would have to do with CMM in the
>> first place.
>>
>> You need something other than Subversion here. You're talking about
>> auditing at the filesystem level IN ADDITION TO whatever Subversion
>> activity you might be doing.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr..._at_tortoisesvn.tigris.org
>> For additional commands, e-mail: users-h..._at_tortoisesvn.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-11-17 18:41:44 CET