Hi All,
There is plenty of material on developing software with FDD from scratch, but what about maintenance ? How does FDD work in the maintenance phase, after product delivery ?
mark
Maintenance & FDD
User login
Random image
Syndicate
Hi All,
There is plenty of material on developing software with FDD from scratch, but what about maintenance ? How does FDD work in the maintenance phase, after product delivery ?
mark
The Same Way
Hi Mark,
it works the same way and is only influenced by the granularity of the maintenance work itself. You list features that describe the work to be done - in this case it just so happens to be maintenance work. You model first, you list features, you plan, you design and build by feature.
Jeff
What about if it is not from scratch?
Hi all,
Almost all the projects that I've been envolved make use of what is commonly called Solutions (Document Management, Content Management, ERP, and Portal Software).
I understand how FDD as whole can be applied as I've adapting it to my own purposes, but still the first phase (Overall Domain Modeling) offers some puzzles when it comes to implementation. One of them is that UML based Models as is being used in the litterature cannot be mapped directely to standard OO objects and classes (Java or C#), but to a colletion of systems and components that need to be orchestrated towards the funcionality required. In this case UML functions more as a mental map of the logical architecture then how actually the system would or should work. Furthermore, the WorkPackages having a section enumerating actual classes (C# or Java) and class owners, cannot be interpreted in the same manner has the books I read do.
Any experiences on this kind of technological contexts that one would like to share?
Best regards,
Nuno Lopes
Most projects are like that
Very few projects are totally green field. They almost all involve other systems such as you mention.
> UML based Models as is being used in the litterature cannot be mapped directely to standard OO objects and classes...
> ...In this case UML functions more as a mental map of the logical architecture then how actually the system would or should work
They most certainly can, and should, be mapped directly to standard classes and objects. I'm not the best person to answer this, but we do not believe in logical models or implementation models and so on. I'd refer you to Peter Coad's books to learn more about this thinking.
The model that comes out of Develop an Overall Model is directly implemented. There's very little that changes to it - things like adding interfaces for packaging is just one example of such a change.
> WorkPackages having a section enumerating actual classes (C# or Java) and class owners, cannot be interpreted in the same manner has the books I read do.
I don't understand this - can you explain?
Jeff
Thanks for the reply Jeff. Wo
Thanks for the reply Jeff. Wow I would never imagined myself talking to you.
>They most certainly can, and should, be mapped directly to standard >classes and objects
My little experience is that sometimes one can, sometimes one can't (the semantics of "can" and "can't" is fuzzy). If one needs to integrate a custom made system with an ERP or a CRM then yes. But if one is configuring one Solution, such as a CRM system, most probaly not (Siebel), at least not all classes. But definitely an isomorphism can be drawn between classes and configuration actions, but has you have mentioned it is a strategy asking for trouble. I have used a CMS tool that almost all configuration was done in a point and click interface (workflow, roles, etc etc), there was no code, just configuration meta-data.
>WorkPackages having a section enumerating actual classes (C# or >Java) and class owners, cannot be interpreted in the same manner >has the books I read do.
I think I have explained myself badly. When you have just configuration meta-data (no code generation) the semantics of Class is changed. The Semantics of a Workbook with respect to the FDD process does not change, but with respect to implementation actions does. You just don't go and change a class, probably you go and configure the system to fit the funcionality required (business rules, etc).
Hope I have explained myself better. Don't get me wrong I think that even in this case FDD can be aplied quite well. I personnally (and my clients) like the idea that all development activities are planned upon client valued funcionality kind of reasoning rather then any other.
Best regards,
Nuno Lopes
"Does FDD work with maintenance?" is a question I hear often
DNC / Archetype UML models most certainly can be directly mapped to Java classes.
However, it is fair to say that UML models are not easily mapped to J2EE and EJBs and some other component frameworks which prefer to break encapsulation. Nevertheless, teams I work with benefit greatly from the domain modeling effort and still create PD classes based on it. However, the need to provide additional wrapping to fit the Coad style PD model into J2EE.
I also agree that maintenance can be problematic - particularly if the existing code is monolithic. It is (usually) necessary to model the whole scope to get the correct DNC model. This facilitates a Feature List which will be accurate. However, the implementation may not allow a class for each domain model class because the existing code would need to be refactored and there may be no time in the schedule for that refactoring.
In my experience, this is OK. The benefit of domain understanding from the modeling step and the precise control and tracking provided by the Feature List and Plan-by-Feature steps pays big dividends. It also provides a map which represents the end-goal for a refactoring exercise.
I still prefer to bite the bullet and "go FDD" but, for a small maintenance cycle on a very large project, I would agree - FDD could be problematic and some managers and developers may prefer not to try.
Regards,
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
FDD and maintainence cycles
The benefit of domain understanding from the modeling step...
agreed - extremely valuable.
for a small maintenance cycle on a very large project, I would agree - FDD could be problematic and some managers and developers may prefer not to try.
Is that because of the question of team size, which is being discussed elsewhere on the site, or something else? If the latter, could you elaborate? It's not clear to me from your post why you'd suggest that.
PaulS.