School Project Theory Question: analysing, methods and modeling languages

Hi,

I am studying to become an "industrial engineer in the field of electronics, multimedia and IT". "Project management" is an important part of this course.

Currently I am working on my master-test.
I am creating a desktop application for a security firm that allows the user to annotate videoframes. Just to give you an idea of what it does: These annotation envolve drawing circles around people and changing settings such as weather conditions.

No analyse was made in advance
Because I constantly have a lot of technical issues (setting up DirectShow under C#.NET, XML-based standards I need to follow) and because the project owner sometimes demands new features ...
==> I did not make an analyse before I started programming.

Then again, I am really good with object oriented thinking and I am good with design patterns, and I made simular, even more complicated applications before (such as drawing applications, layout editors, administrative software).

I do make UML class diagrams and I make small sketches of how components should interact before I start programming. I do not have a fixed notation style for these sketches though. And what I program today can be changed tomorrow or next month. So, it is really impossible to make an analysis in advance.

Analysing methods - Which one am I using?
For my master-test I will need to motivate my choice of analysing method.

When I was still in my bachelor studies one of my teacher told me that not always the analysing should be done in advance. He told me there are also other models like: the spiral model, Prototyping, Rapid Prototyping, The waterfall model, ... So no mistakes are made yet.

In fact I think that my style of working is probably pretty much according to the Spiral Model, prototyping or rapid prototyping? But to be honest I do not know the difference between prototyping and the spiral model. Can anybody tell me which model I am following at the moment?

Usually I make a list of required new features (Problem definition). Next, I think a bit about how I will implement them, I draw a bit, I sketch a bit (Design). And bam :eek2: ! I make changes to the existing application (Implementation) and test it (Testing). I repeat this process over and over. Pretty much like the spiral model I think, but I think prototyping and Rapid prototyping also work in a circular motion.

About modelling
I will need some models and like I said before I made some UML class diagrams. (Nicely integrated in VS 2005 these days)

In the past I have worked with other UML diagrams as well such as the Use Case Diagrams, State Diagrams, Collaboration Diagrams, ... etc. The problem with these is that they take a huge amount of time and require a lot of thinking about "who are the actors, what are the components, what actions should who be allowed to do". My next question is: Is there a good free software package that is design only for UML diagrams?

Like I said before I use a lot of design patterns: events (Observer pattern), decorator pattern, command pattern, wrappers, singleton pattern, strategy pattern, factory pattern, ... Can you imagine making (state, collaboration, ...) diagrams of (for example) a factory pattern based on an enumeration ? :-s. This will be more complex than the actually programming code.

For these reasons lately I have become aware of the fact that UML is pretty cool for websites and client/server applications where there are multiple Actors and where data should be exchanged between them and stored in a database. But for a desktop application UML seems to be the wrong choice. Is there anything more appropriate than UML? Maybe there is something that supports the use of design patterns directly?

Repeating my 3 questions
1) Can anybody tell me which analysing method I am following at the moment?
2)Is there a good free software package that is design only for UML diagrams?
3)Is there a more appropriate modelling language than UML?

Thank you for reading my long question. I hope my questions are clear, and I hope somebody can give me quality-advice. (not like: everything sucks, I use nothing, and so should you!)

:) thanks :) :afrog:

1 - You might be following an Agile Development process of some variety, but it is purely "accidental" at this point. Note that there are numerous Agile methodologies that all define their own set of practices, but that there are many common practices among the methodologies. Which exact methodology you most closely match is something that you might want to explore a little bit.

One of the oldest defined practices that is commonly accepted to some degree by all Agile methodologies is IID - Incremental and Iterative Development (or is it Iterative and Incremental Development?). A tenet of this concept is that getting working software into the hands of the end user as quickly as possible is important to the creation of quality software. This embodies the idea that discovery happens at a faster and more fundamental level during IID than it can using an "up front" analysis methodology.

Typical Agile practices include "user stories", rather than requirements documents or Use Cases. It looks to me that you are using user stories.

Your method is very "process light", which is Agile.

It sounds like you are using incremental delivery - each "release" adds a small, defined set of functionality to an existing project, and iterative development - where you are only doing analysis and coding that is important to achieve the current set of features being added and then repeat the process several times for each release.

You are communicating directly with your "Customer", which is a critical Agile practice. The concept of customer is universally important to all Agile methodologies.

Note: Most software project management methodologies being taught in universities are heavy process methodologies (including most CMMI, RUP, PMI type stuff). In my opinion, in many cases these methodologies are harmful to the success of a project. However, they seem logical and useful, and it is not uncommon to see these heavy process methodologies to be considered vaild where Agile methodologies are not. This is one case where the proof of the pudding is in the eating, as they say. Just becaue something seems logical and useful doesn't mean it is. What I am saying is that you should verify that the professors grading you aren't died in the wool heavy process folks - in other words, give them what they want if you possibly can.

2 - Regarding tools, have a look at Robert Martins UML for Java book, or his Agile Software Development Principles, Patterns, and Practices book to get a perspective on these tools, and what he considers reasonable documentation. The crux of it is, a white board is the best UML tool, and a digital camera is the way to document it. Or a little pencil and paper system is sufficient.

3 - The most appropriate modeling language is anything the developers on the project find useful for communicating with each other. On a very large project with teams that are not co-located, it can mean having to use a formal modeling language, but for a truly agile team it is usually a mix of standard (but minimal) UML-ish stuff and metaphor ala(look that up).

Thank you for reading my long answer. I hope my answers are clear, and I hope you find it to be quality advice. (And I hope this doesn't sound like: everything sucks, I use nothing, and so should you!)

Sorry, for the late response. (Busy life :()

IID sounds cool :) I will give it a shot and look up some more information. Thank you for your help