Large Project Structure

[jdavid]

Hello

We are in the process of evaluation Enterprise Architect as our modeling tool, we are in a great position design-wise since we are starting from the ground-up and replacing all of the systems that were developed over the last couple of years. The CIO would like to see all of the new enterprise in one model….what I wanted to find out is do you have an example of a large enterprise wide model to start from or any suggestions on how we should proceed. We are using .net, asp.net, c#, and Sql2000 for all of the development work. Below is some of the namespaces and system structure.



Class files are kept in separate solution such as

Nordis.Enterprise.BusinessObjects

Nordis.Enterprise.DataAccess

Nordis.Enterprise.Security



The applications that we are building are comprised of:

Web Apps

Web Services,

Windows Services,



The overall enterprise application architecture looks like the outline below:

Nordis Systems

           |

           |-- Enterprise Systems

           |

           |-- Client Specific Systems

           |

           |-- Print Engine (Dialogue 3.0)



Enterprise Systems

           |

           |-- Work Management

           |

           |-- Client Relationship Management

           |

           |-- Resource Management



Work Management

           |

           |-- Work Requirement Management

           |

           |-- Work Effort Management

           |

           |-- Task Management



Work Requirement Management

           |

           |-- Manage Proposals

           |

           |-- Manage Programs

           |

           |-- Manage Change Requests



Etc, etc



We are also trying to implement most of the principles behind FDD (feature driven development) and still produce UML models

Any suggestions that you could provide as to setting up Enterprise Architect to support the above structure would be greatly appreciated



Thank You



Jack David

Enterprise Architect

[email protected]

www.nordisdirect.com

[Martin Terreni]

I'm doing the same here in Intel so I think I might be able to give you some words about it.

For one thing I can tell you that I've reversed engineered a complex model with more then 2000 entities (classes mainly, but also enums and structs) and, though it took a couplt of hours for EA to do it, the result was more then reasonable and EA stands the large model very well. This can help you model old projects to see what you can save from them.

On the hand of new projects modeling what we do is the following:

1) Top down modeling to deside on main packages.
2) Design devided to packages and then exported to XML with declered ownership.
3) Every one imports the XML needed for them.

This way instead having a large and complex projcet had handle and design you get many small packaged taking care of deferent features (FDD )
and every developer gets too see only the relevant things instead of having a headecha with all the project+ you can show your manager a clean top model from where you onle see packages (the same way you would see classes) and maybe interfaces.

Hope it helps, Martin

[sshearer]

Hi, this seems like a good place to add my wrinkle to the problem - maybe someone can comment on how they do it ?

Our organization has implemented it's own flavour of Microsoft's Solution Framework - complete with Brand, Product, and Program Managers, and funnily enough, Business Analysts.  (We also have the development, QA, and implementation teams.)

We've done this in support of 3 main 'product' areas:
- web applications (internal and external),
- back-office applications, and
- (custom) telephony applications.

The Product Managers, Program Managers, and BAs are all responsible for being (or becoming) Subject Matter Experts in various combinations of the above products.

The BAs (7, of which I'm 1) have traditionally been creating their Business & Functional Requirements & Spec documents in Word and Visio.

Until mid-last year, all the products were separate and distinct.  Since then, they've all been integration projects - and it's only going to continue.

The team has been lobbying for a Requirements Management Tool for a while now - and we finally have an agreement-in-principal.  This year's budget is to be approved imminently ...

Feature Requests (FRs) are documented by Product Managers (and clarified by BAs   ). Then the assigned BA(s) get to work creating diagrams and documents.

A FR may result in Change Requests (CRs) to any one or more products.  CRs are assigned to pre-scheduled 'Release Buses' that contain portions of multiple FRs.  (And the list of included CRs is dynamic up to the point of beginning development due to workload, ahhh, negotiation   ) with the Resource Manager(s) for the various development teams.

Have I blown your mind yet ?  

All this means that we have huge traceability requirements between multiple products across multiple releases as a result of multiple projects.

Not only do we have project-level documentation, but we also (try to) maintain 'Master' specs for the various products as reference material for future projects.

I was hoping that EA would be a great tool to recommend for my company - but based on the comments from earlier postings I really can't imagine:
- asking our DBAs to create 1 DB per project plus 1 DB per product,
- linking requirements across the DBs,
- generating the definitive 'Master' spec.

Can someone please confirm this ?

BTW, we've already ruled out the use of Rational.  We are aware of Doors and CaliberRM.

Thanks,
Steven.

[Martin Terreni]

I can only answer generally since I'm not there to analyze you needs, but I'll try to give some answers....

- asking our DBAs to create 1 DB per project plus 1 DB per product

Lets say that you have diferent products using diferent conbinations of your projects to deliver. In this case there is no other option. But if code projects are mainly related each to one product you can do DB's only per product.

Any way I was a DBA my self and we hold in our severs docens of DB's , this shouldnt be problematic.

- linking requirements across the DBs

You can use UseCases for requirments (which is what they are for) and export is to XML so all projects related to same requierments can import it (even keeping it up-t-date with version control).

- generating the definitive 'Master' spec.

I'm not sure what you mean by this.
If you mean to have some standard profile then you can create a project with all you need (macros, default langage, etc....) and make it base project for all.

Maybe you could be more spesific about your needs (though if you already were then maybe I just dont get it).
May be you should make some meetings with all parties to deside on a standard methodology framework, or bring a consultant to make the 1st moves ( which is my job here in Intel).

Enjoy  

[sshearer]

Wow - I wasn't expecting such a fast reply !

Regarding some of your comments:

Yes, 1 project usually involves many changes to at least 1 of our products.  For example, in a recent project to create a web-based solution to streamline the act of getting customers' voice recordings approved before publishing:
- our IVR product needed to be updated to:
a) provide a 'web service' for guaranteed file/data delivery between IVR server & web server,
b) transfer the recording and related data to web server,
c) notify web server if the member recorded again before the first one was reviewed,
d) accept notification from the web server indicating whether the recording was approved or not (& why).

- our (new) web product (application) was created to:
a) allow an administrator to define & manage users,
b) provide a login page for users,
c) accept incoming files & data from IVR server,
d) allow users to hear 'the next' recording and document any issues with it,
e) notify the IVR server of the result,
f) accept notifications from IVR server

- our back-end customer mgmt app was updated to:
a) accept notification of repeated disapprovals, resulting in further action (against) a customer.

Now, all of the above was just 1 project which implied changes to 2 existing products and the creation of a new product.

Now, from a business perspective, we have 'master functional specs' for each of our products which documents each products' business requirements, features and business rules.  Each master functional spec documents the product in it's entirety 'as of this date'.  (Hence the title.)  

We have these because as soon as there is a project to be done, we need to know what will be changed and what the impact will be for each change.

So, it sounds to me like this would be 1 DB for each product - possibly each major business feature would be it's own exportable 'package'.

Then for each _project_, we'd create 1 DB and import all the appropriate packages.  When the project is completed, we'd export those packages and re-import them into the product-specific DBs.

If I understand EA correctly, then this picture isn't too bad when you have 1 project at-a-time and maybe 4 projects per year.

We have about a dozen projects per year, with 2 - 4 of them happening concurrently, each of them needing requirements defined, analysis performed, etc.

Now, the above was just for 1 project that started last summer.  This year, we're adding more features to it, meaning changing some things and adding new things - all of which implies more requirements gathering, analysis, impact analysis, etc.

We already know that we definitely need a true Req's Mgmt tool (ie. the new add-in for EA recently released), or Doors or CaliberRM.

Hopefully I've been clear that we not just a few analysts collaborating on a one-off project  

I guess I was just looking for other (large) users' feedback on how they manage situations like ours.

Thanks,
Steven.

[Martin Terreni]

I have here about 200 developers devided in many teams, from what you say it might be a litle less then you, so maybe it allows as to warok diferently.

We already know that we definitely need a true Req's Mgmt tool (ie. the new add-in for EA recently released), or Doors or CaliberRM

your probably right about it. we have many project runing and very cross related, but we dont have as many large changes as you.

any way we use a template documant we created called EPS (external product spesification) for requirments gathering and analysing and another one called IPS (internal...) for internal coordination of requirments. of course it is good only when starting a new project or making realy big changes, but for us right now it's enough.

sorry I couldnt help more than that.

[Kevin Brennan]

Steven,

While EA is a great tool for what it does, it's not robust enough in the requirements management area to do the kinds of things you're looking for it to do. The plug-in has potential but it's not that robust as of yet.

I believe that you'll need to look at DOORS or Caliber. I haven't been able to find a tool that is to them as EA is to Rose.