setting up complex projects

[Marcel Gehlen]

Hello,

first of all I think the idea is great and I see a big potential in
this.
Especially when setting up a new project from scratch or (test)
managing a small or medium sizes project.

However I rarely experienced these scenarios in the past, but instead
faced rather complex projects and a lot of legacy code.
The legacy code was sometimes very good and sometimes quite poor.

As I was a little ambitious when testing Google Test Analytics I tried
to set up a complex project with poor quality legacy code.
And there I found myself struggling.

A short background of the project:
In the past the project was buildt by 7 partner companies each
responsible for one ore more component.
The project was a Time & Material project for the customer and usually
the cheapest of the 7 partners get to implement new features in "his"
component.
When we inherited the software it was facing heavy multithreading
issues, the the responsibilities of the components were unclear and no
one really know what the software should do or what it does.

I can now now enter the attributes of my project, which works quite
fine.
Adding the components was easy, too.
The hard part are the capabilities due to several problems I am
facing.
Some functionality should take place in one or two components, but is
actually sprayed over several components. The fact that all the
components need to communicate and work together to complete a task
does not make it better.
So if I try to represent that in the capabilities I end up with two
choices:

1.) write one capablity and apply it to the component, where it should
reside

This does not make me very happy, because it does not represent the
system as it is, but rather the system how it should ideally look
like.
Furthermore the risk overview would loose relevance, because I cannot
adress risks in the correct component, if a assign a capability to
only one ort two components.
So I wanted to go with option 2.)

2.) break down the use case into the capabilites for each component

This however flooded me with capabilities, because even a simple task
like "change the timezone" splits into several capabilites in several
components ("fetch the new timezone", "trigger componenty xy", "start
datetime script", ...).

As I mentioned above the software very complex and I have a lot of use
cases, which are a lot more complex than changing the timezone.
Furthermore I have a lot of configurations, which need to be regarded
like language, timezone, conctract state of the final user or even
number of used mobile devices.

If I take all this into account the configuration of Google Test
Analytics is just as complex as setting up a normal test plan and
faces the same risks of not beeing properly maintained.

Please don't get me wrong:
I still see a lot of value in Google Test Analytics and the Risk
Overview.
But the great great win of beeing able to quickly setting up an
maintaining a test plan seems to be lost to me.

So here I am writing this long post meanwhile having only one
question:

Am I using it wrong?
Am I perhaps beeing to detailed in writing the capabilities?

Thank you very much for your help.

Best Regards,

Marcel

[Jim Reardon]

On Thu, Nov 3, 2011 at 6:32 AM, Marcel Gehlen <marcel...@googlemail.com> wrote:

I can now now enter the attributes of my project, which works quite
fine.
Adding the components was easy, too.
The hard part are the capabilities due to several problems I am
facing.
Some functionality should take place in one or two components, but is
actually sprayed over several components. The fact that all the
components need to communicate and work together to complete a task
does not make it better.

Without knowing any specifics, it's hard to really delve into this.  If you want to/are able to share the project with view access (either with me, or the group) I could give a more detailed answer.

That said, I've seen this problem previously.  Generally the issue was Components that were too specific. Components should be fairly vague, which admittedly is going to be against your first instinct!

For example in the very simple web store example project:

  https://test-analytics.appspot.com/#/54001/project-details

You'll notice the Components are very, very large portions of the project that a developer would likely consider several components in software design.  For example, Shopping Cart is likely a complex entity that a developer might split up, but the idea is to keep it fairly high-level.

 

So if I try to represent that in the capabilities I end up with two
choices:

1.) write one capablity and apply it to the component, where it should
reside

This does not make me very happy, because it does not represent the
system as it is, but rather the system how it should ideally look
like.
Furthermore the risk overview would loose relevance, because I cannot
adress risks in the correct component, if a assign a capability to
only one ort two components.
So I wanted to go with option 2.)

2.) break down the use case into the capabilites for each component

This however flooded me with capabilities, because even a simple task
like "change the timezone" splits into several capabilites in several
components ("fetch the new timezone", "trigger componenty xy", "start
datetime script", ...).

It sounds like your project's Capabilities might need to reflect an ideal design rather than the system design.  Admittedly, I haven't ACCed a project like this, but my instinct would be to reflect the Components not necessarily from an ideal perspective, but from a user perspective.  Spit balling here, I'd say you absolutely should not break up "Change the timezone" into multiple capabilities, but that it rather belongs in wherever a user would utilize that function.

Your capabilities are essentially behaviors -- they might be complex and affect across the swath of the project -- but they should still be fairly discreet in ability to test.

 

- Jim

[Marcel Gehlen]

Hello Jim,

sorry for my late response, but a tenosynovitis in both hands kept me
from writing anything for a while...

Thank you very much for your answer, it has indeed been quite helpfull
for me.
Unfortunately I cannot grant you read access to project, as the code
is confidential.

What I take from your answer is that I maybe should not view on the
components from a rather technical point of view, but from user and or
business perspective.
So in case of that project I would not adopt the components from
archicture 1:1, but adapt them a little to reflect the users point of
view, especially regarding their capabilities.
As you said it makes more sense to connect one capability to the
component the user associates it with instead of breaking up the
capability into the tasks each component has to perform.

If I got you right, this really helps me out here. ;-)

Thank you very much and best regards,

Marcel

On 4 Nov., 08:29, Jim Reardon <j...@google.com> wrote:
> On Thu, Nov 3, 2011 at 6:32 AM, Marcel Gehlen

> <marcel.geh...@googlemail.com>wrote:

[Jim Reardon]

Marcel,

Yes, that sounds right.

Let me/the group know how it works out -- a lot of the methodology is still evolving, so it'd be great to learn from your experience and possibly tweak or extend the ACC system to help address any problems you hit.

- Jim

[Alec Munro]

I'm playing around with ACC finally, and the project I'm working on
doesn't lend itself easily to breaking up into components, without
introducing a lot of redundancy in the capabilities. So this thread
has been very useful.
I'm writing up notes as I try them out, I'll add them here and perhaps
if they are useful they can be incorporated into the documentation.

One area that I'm still pondering is how many components to shoot for?
In a traditional list, 7 is usually what you go for to keep it easily
comprehensible. But given that this is used internally at Google, I'm
wondering if that is really a concern, or are they projects with 20+
components for which the system works well?

Thanks,
Alec

On Dec 5, 2:57 pm, Jim Reardon <j...@google.com> wrote:
> Marcel,
>
> Yes, that sounds right.
>
> Let me/the group know how it works out -- a lot of the methodology is still
> evolving, so it'd be great to learn from your experience and possibly tweak
> or extend the ACC system to help address any problems you hit.
>
> - Jim
>

> On Fri, Nov 25, 2011 at 7:38 AM, Marcel Gehlen <marcel.geh...@googlemail.com

[Jim Reardon]

Hey Alec,

Generally, 5-12 components is the best from my experience.  When we had more we found one of two things were true:

- we were over-specific in generating components.  This is a pretty standard problem for first-time ACCers.  If you get to generating capabilities and you have a lot of empty rows/columns, it's probable you've been too specific with your attributes or components.

- the project needed to be split into smaller projects.  An off-the-cuff example would be that Google Search would not be broken into one ACC model, but several.

Hope this helps, and please continue to share your experience and opinions.

- Jim