[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Data Collection for Project Management Statistics

From: ray <Ray.Joseph_at_CDICorp.com>
Date: Tue, 18 Nov 2008 05:10:25 -0800 (PST)

Andy,

I appreciate your concerns and thank you for your efforts. (The
application on my part is for engineering documents in an industrial
setting as opposed to code thus there are some differences in
processes and requirements. Project sizes range from 2 people to
1000. As difficult as it is for a one size fits all solution,
repeatability and consistancy go a long way in maintaining quality
production. Any one project produces 10s of thousands of documents,
all come under the scrutiny of legal authorities and significant
impact to people and the environment. In common with the vast
majority of coding efforts, there is significant monetary impact of
decisions.)

You are totally correct in your statements about micromanagement. But
the intent of data collection is to help understand the relationships
between activities, behavior, quality and performance. If I can
collect data about how I perform tasks and then (with enough
instances) correlate that with my quality and performance, maybe I can
see if there are relationships that will help me tune my behavior to
be more productive through quality performance. I can be free and
comfortible flying by the seat of my pants, but more important to me
is to be managing my clients money to the best of my abilities. I am
getting paid to perform, not be comfortable although I would like
both. So in the end, the decision is up to me, but I want data to
back it up.

Additionally, the data capture may reveal information about work flow
concerns more than individual work habits. This is the CMM drive.
When requirments change or consequences are revealed that require a
change in plans, it is often difficult to determine how to adjust to
the new view. Having data to help understand how different solutions
have evolved in the past is very helpful in determining the relative
risks of taking different actions in the future. Have data to back up
these considerations bring considerable value - sufficient value to
invest in data collection, management and analysis.

I am not sure that my original requirements must use file system level
auditing. Since all of this boils down to work flow concerns, TSVN
provides for many opportunities to capture such data. Having read the
manual, it seems like there is already significant tools to achieve
the results. But just how to do this is not clear.

With all the people here that have been using the associated tools, I
am looking for help and insight into how best to achieve these goals.

Thanks,
Ray

On Nov 17, 11:41 am, "Andy Levy" <andy.l..._at_gmail.com> wrote:
> On Mon, Nov 17, 2008 at 08:31, ray <Ray.Jos..._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-unsubscr..._at_tortoisesvn.tigris.org
> > For additional commands, e-mail: users-h..._at_tortoisesvn.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr..._at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-h..._at_tortoisesvn.tigris.org- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

---------------------------------------------------------------------
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-18 14:13:08 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.