Hi,
is there something like a documentation glossary, as what kind of documentations exists, with a short description what these documents pretend to be. I found often myself struggling in my german speaking world with anglo-saxon documentation names and do not know what the customer really means by it 
.
So a list of all kinds of documentation would really help.
Regards,
Darya
Hi all,
I looked for the FDD certification schedule at FDD and found that the links to Borland for the next coming FDD Trainings do not work :(. Does anyone has the right links?
Thanks,
darya
Is there such a thing as FDD like system for independent testing teams using work packages?
We have a dedicated (independent) testing team in our company whose current brief includes testing, I supposed you'd call them, monthly service packs. These involve the typical fixes, enhancements and new work. Due to a restructure these guys now report to the development manager and he wants them incorporated into the FDD fold. The main difference being that they will continue testing after our FDD process has finished (i.e. all features for a service pack are finished according to FDD). So, in summary, development does its FDD development and every month (or so) puts together a new service pack of the product and delivers to the testing team for a full test.
Last year I came across a tool called Agitator by a company called Agitar (www.agitar.com).
While it looked quite "cool"and a little "out there" back then, I have really only had the opportunity to get into it in depth in the past couple of weeks, as we use it on our current project (which is not using FDD).
For context, agitar agitator is geared towards unit testing (true unit testing, not running junits as functional tests etc), and plugs into your ide (we use RAD/eclipse).
What I did notice about the tool was how well it seemed to support the FDD Process 5 - build by feature: code and unit test. The time it took to effectivly gain test coverage on some of my classes as well as obtain test points (think of these as assertions in junit) to the same degree as junit was to me, an order of magnitude less. This allowed me to test just a little bit more, and get a higher degree of confidence in my code pre code inspection (which we are still doing). What was once taking me tens of minutes is now minutes.. and on tricky classes, what was once hours is 10s of minutes. The other thing i liked about it was that it fit in well with taking a design, implementing it, testing it, coding some more, testing some more, CABTAB etc. It does not really work well with TDD (even though Kent Beck is on their payroll), but suits more rational development of conceptualising a design like in FDD Process 4, and then realising it then testing it, iteratively till you are satisfied. That aside, the agitar people themselves pretty much like building to interfaces a la peter coad, and reinforce it in their tool. If you can define interfaces in your pd layer, agitar will stub whats behind that for you automatically. It can also stub out jdbc, struts etc. Very handy. The other thing i really liked about it is that it unintentionally reinforces class ownership. You can get stats on developers and the classes they own; how many bugs they contributed etc. You can set it up so that only errors in classes owned by you show up in your ide.
I just completed my first project using (a bastardization of) FDD.
The project was small, so I felt like I could leave out some pieces of FDD without too much impact.
Mostly I skipped through Process #1, #2, & #3 quickly and did a lot of reiterative design at each #4. However the real negative impact on the project came because I skipped the validation steps on #4 & #5.
Now, I'm beginning a 2.0 release of the project and am hoping to adher more strictly to FDD. Since I'm just starting to "Develop an Overall Model" I figured I should get some feedback.
The first thing I think I'll wrestle with is when I try to capture the customer's Wish list for 2.0 as a Feature list.
Hello All,
TargetProcess http://www.targetprocess.com
It is web based .NET application.
Features:
* Planning Module
- Extreme Programming style project planning (iterative development)
- User stories management
- Releases and Iterations planning
- Project dashboard
- Personalized ToDo lists
- Burn Down chart
- Multiple projects support
* Bug Tracking module
- ToDo list for bugs
- Bug dashboard
- Stats and charts
- Comments and changes history
- Attachments
* Time Tracking module
- Time Tracking for projects and user stories
The official release of FDDPMA is now available at SourceForge.net: http://sourceforge.net/projects/fddpma/
FDDPMA is an open-source, web-based, cross-platform, multi-user FDD project management application. It facilitates iterative development by reducing FDD management overhead, producing graphical progress reports, providing a workplace where all the FDD related documentation is collected.
Use FDDPMA in one of the two ways:
- Access the deployed application at http://www.fddpma.net
- Download the Java source code install it on your own server
Following the topic around Projects Aspect, my interest in FDD extensions and adaptations has grown. I've been doing it for a couple years, but in the last few weeks I've been looking for a more normalized approach to the issue that encompasses needs beyond the traditional PD, DM, UI and SI aspects (for instance to include Documentation).
Probably people have tried to do this before hence raising this issue on this forum. To jump start let me introduce what I've been thinking, so invite you to clarify and challenge these ideas so we can come to a conclusion that is satisfactory.
The problem that I have with FDD is that the method for tracking artifacts in use is "limited" the development phase (DBF/BBF iteration) has the process is defined. In other words, just because all features are marked 100% may not mean that the project is finished and the "product" is delivered. This because features are taken and defined over an overall domain model designed (Object Model) on the 1st phase, and the description of this (ETVX Template) phase does not take into account issues such as UI, Documentation, Installation etc, just to name a few things. Only the concepts that need to be developed in the PD layer are taken into account. Although we can argue that these are not issues from developer's point of view or that this layer is the most important (etc, etc) and I tend to agree, it means that FDD does not cover the SDL as whole. So this "tool" may not be adequate at first to some projects from the start. In spite of this, the underling concepts of the tracking strategy have the potential to be used not only to track de development of features but also other "things".
Starting a new thread to answer the question raised in this thread.
Let's start simple and then refine and enhance as our understanding increases.
An aspect is some slice of a project for which you want visibility and communicability. What's mostly talked about are the three main aspects I use which are the PD, UI and the SI. That is, there is a features list and a parking lot chart and a weekly summary report and a trend report and kill sheets and work packages for PD. There is also a features list and a parking lot chart and a weekly summary report and a trend report and kill sheets and work packages for UI. And the same for SI.
One of the hot topics whenever you think of FDD and Requirements Management is how/if they coexist. The approach I've been using is that Feature Areas/Sets/and Features themselves are in fact of a specific requirement type (that lives in harmony with Business Requirements, User Requirements, etc.).
Here's an example of this implementation:
Using the CaliberRM SDK we also created a "project tracking" portal. The initial project status and selection page looks like this:
