Planning Iterations

[Paul W]

I've seen a similar post but I want to ask it in a different way.
As a Business Analyst working for a software company we have produced the requirements set (Requirements, Domain Model, Use Case Model) for a new integrated version of the company's three products.

A new CTO has joined the company and wants to start developing releases on an extremely agile basis with product releases every month.
The content of the requirements is still the same, only now we have to determine how much of a Use Case can be completed within a two week development period. This means that I have to divide up the Use Cases and apply each Scenario to a development iteration.

Is there anything in EA that can help me with this?

Is there anybody out there that does something similar that can explain what they do?

[Oliver F.]

A new CTO has joined the company and wants to start developing releases on an extremely agile basis with product releases every month.

I believe he has read a book and stumbled across the term "agile". Happens often today.
I am having a hard time telling people that "agility" does not mean doing more work with fewer people and having more frequent releases. There is simply more change involved in a company- eg. the mindset at all stages.

Regarding your question: TimeArchitect is an addin which lets you assign efforts and progress to each element (UseCAses, Compoennts, etc.) and then creates a gantt chart, backlog, etc. to track them down.
http://www.timearchitect.net

For everything else: Good luck.

Oliver

[Paul W]

I'm looking at something that breaks down below the Use Case level.

Ideally if each scenario had a phase and version I could make it work.
Creating just Scenario diagrams doesn't work because the diagrams don't have Phase and Version (just Version)

Looks like I'm going to have to create Scenario/User Story pacakges under the  Use Case to hold the diagrams.
Don't know how I'm going to split the Web Service operations on the object model between phases.

[Oliver F.]

Looks like I'm going to have to create Scenario/User Story pacakges under the  Use Case to hold the diagrams.
Don't know how I'm going to split the Web Service operations on the object model between phases.

You can not create packages below elements but basically you are on the right path.
Create a stereotype labeled "User Story" of metaclass "use case", "requirement" or "change" (depending on your preference) and put the stereotyped elements (user stories) below each use case to break down its activities.
I'd prefer "change" as it comes closest to the idea of user stories.
If you are using a UML profile for that task you can assign specific tagged values to your user story objects to hold more specific information.
Get a glimpse on the UML profile topics in the online help and the white papers.

For your web service I suggest to create an interface object with methods and attributes in the static section of the model (usually the connection section in the component or domain/class model) and then transform it into a WSDL file.

HTH

Oliver

[jeshaw2]

Paul;

I'm concerned that your approach (scenario by scenario) might lead to much modification of implemented software and attendant possibilities to "break" working applications.  It might also lead to software which is not robust enough to deal with dynamic contingencies of the real world.

I suggest that you review Ivar Jacobson's papers on Aspect Orientation and Use Cases.  I can't find the exact paper I'm thinking of, but here http://www.jot.fm/issues/issue_2003_07/column1.pdf is a starting point for you.  In the paper I'm thinking of, Ivar demonstrates how a UML Class element is enhanced with a Point cut compartment.  I've asked Sparks to add this feature, but since it is not pure UML, they recommend using a shape script to create the compartment.

You are probably aware of the Extension relationship between use cases.  I like to implement phases by extension use cases rather than revisiting working code to implement scenario after scenario.

Think Features, not scenarios...

HTH
Jim

[bioform]

I would think that Features are not granular enough.
Scenarios an be a useful way to move forward with iterations.

The baseline release's scenarios (business & system) should be able be used to express/exercise the functional requirements.

Part of the solution I believe is to make use of both internal and external requirements. Since each element (be it a domain class, use case, activity/action element of a use case) has a phase/version field this is how I approach the problem.

BR1 - An external requirement (realize relationship with the use case or use case's element) represents the requirements of the current production release (this way the requirement's Phase/Version is independent of the UC's phase/version.

BR2 - An internal requirement (unrealized relationship) represents the "additional" requirements UC or UC's elements phase/version (inherits all of the base-lined requirements)

BR3 - When a UC is to be promoted to the next release, it's internal requirements are changed to external requirements, and then become part of the new baseline.

The cycle would repeat for each iteration. Only once the iteration has been accepted, do the internal requirement change into external requirements.

Does that make any sense to you?

I will soon be trying to master the baseline capabilities of EA and DOORS (ugg) to support an existing project I am the requirements lead for. Right now I am trying to create the existing production requirement baseline and then support the new project's management that will be using small iterative development.

David

[Oliver F.]

I will soon be trying to master the baseline capabilities of EA and DOORS (ugg) to support an existing project I am the requirements lead for.

Would be interesting to hear about your experiences regarding DOORS and EA interoperation. Mine are a bit mixed, to say the least...

Oliver

[bioform]

Yes, I know what you mean. I am waiting for approval of a purchase request for the DOORS add-in, so I can get access to an EA/Add-In/DOORS environment.

I did a quick install and peek at the add-in during a previous job (FINRA) and it did seem to enable round-trip editing. If something was deleted from the DOORS module, the EA object(s) were moved to a trashcan package so you COULD recover if you choose to.

When I am modeling functional (external) requirements, they are "owned" by the object that they apply to (e.g., UC, Action/Activity/UI.) So the external FR would have both "realize" association (resulting from moving the internal to external) and an “Owned” relationship (in the EA tables) from placing the FR directly under the object it applies to.

The quick test I did to look at round-tripping was package based (so to refresh the data in EA, you had right-click to see the option to refresh. This might have meant that you were constrained to keeping your requirements in a package based structure. This would not be a problem (my NFR have a rather robust package based hierarchy tree already) doing the same for FRs would not be a big deal, just a similar approach.

Once I get past the admin folks installing EA and the Add-In in the DOORS environment, maybe it would be worthwhile to start a separate thread on that subject?

As Gene Wilder (Waco Kid) said in answer to Cleavon Little's (Bart) question "Do you need some help?" He answered "oh... just all I can get..."

David  

[Oliver F.]

Yes, I know what you mean. I am waiting for approval of a purchase request for the DOORS add-in, so I can get access to an EA/Add-In/DOORS environment.

I did a quick install and peek at the add-in during a previous job (FINRA) and it did seem to enable round-trip editing. If something was deleted from the DOORS module, the EA object(s) were moved to a trashcan package so you COULD recover if you choose to.

Looks like this goes offtopic now- maybe we should really start a new thread once you got some more hands-on information with the current version.

You are right, I have made the same experience. The fact that packages are thrown into a trashcan is a remarkable feature. However I would not speak about roundtrip engeneering- the DOORs addin indeed requires to keep everything in one package, if you move things out then you get duplicates. There is no way to synchronise requirements back and forth. Eg. we create use cases from feature and requirements specifications, those use cases are modeled in EA but shall be stored in DOORs (which I do not agree with, but this is a different story). A reimport in DOORs is not possible.
So round tripping was not the word which sprang to my mind first

Additionally the addin looses its import settings if you close the connection.

Light and shadow in this area

Oliver