It’s me on February 2012.
First, I want to apologize for my so so English.
In theory, every single aspect of the UML is potentially useful, but in practice, there never seems to be enough time to do modeling, analysis, and design. There’s always pressure from management to jump to code, to start coding prematurely because progress on software projects tends to get measured by how much code exists.
I partially agree with these. Every aspect of the UML is important as it will be useful. However, clock is ticking. To do a proper modelling and a thorough analysis seems really difficult in practice. We may have no patient and want to jump to design as fast as we can. Hah! Even though management doesn’t really want to see how many line of code we did, but they really want to see something, something in GUI and it works.
ICONIX Process lays down a simple, minimal set of steps that generally lead to pretty good results. These results have proven to be consistent and repeatable over the last 12 years.
Woot! I am not sure whether 12 years later I will still do a project including ICONIX. However, I have confidence that at least if the ICONIX process have been nicely done, it should be good for several years later. Some revisions should be easier to do.
ICONIX Process is divided into dynamic and static workflows, which are highly iterative: you might go through one iteration of the whole process for a small batch of use cases (perhaps a couple of packages’ worth, which isn’t a huge amount given that each use case is only a couple of paragraphs), all the way to source code and unit tests. For this reason, ICONIX Process is well suited to agile projects, where swift feedback is needed on such factors as the requirements, the design, and estimates.
I need to make a statement here. I can not define what exactly agile projects are, haha. Because projects I have done that considered to be agile project does not strictly follow the rules.
The domain model also provides a common vocabulary to enable clear communication among members of a project team.
I agree that we need something to understand common objects of a project. I have experienced annoying communication about understanding common objects. It made programming becomes more difficult.
when you use ICONIX Process, your goal is to produce an object-oriented design that you can code from.
For you who had learned Object-Oriented Programming (OOP), this ICONIX is pretty easy task, in my consideration. It might be beneficial for you to learn OOP. Maybe sometimes later you will be surprised that OOP help you in several programming projects.
The quoted texts are parts of this book.