The primary goal is to build software not models. Building models is great, but if it doesn’t get you to software being built, it’s not helping.
“Travel Light” – Don’t build more models than you need. By working only on the models you are about to write software for, you minimize unnecessary work.
Build it simple, but no simpler. Keeping the model simple, will most likely keep the code simple. But don’t be so simple that it doesn’t do what is needed.
Build models in a way that is amendable to change. Since change happens, keep with a process that allows for change.
Be able to state the explicit purpose of each model.
Adapt the models you develop to the system at hand. Different types of systems will require different types of models.
Try to build useful models, but not necessarily perfect models. Too much time on a model, means less time on developing code.
Don’t be dogmatic about modeling “language”, get it so it conveys what it should.
If your instincts tells you it isn’t right, you’re probably right. Learn to listen to your instincts and do a deep dive into the model if you think something is wrong.
Get feedback as soon as you can.
Design Modeling Principles
Design should be traceable back to the requirements.
Always consider the architecture of the system to be built.
Design of the data is as important as design of the processing functions.
Interfaces (both internal and external) must be designed with care.
The User Interface (UI) should be tuned to the needs of the end user. In every case, it should stress ease of use. (Facebook story.)
Component level design should be functionally independent.
Components should be loosely coupled to one another and to the external environment.
Design models should be easily representable.
The design should be handled iteratively.
Creation of the design model does not preclude an agile approach.
Modeling Principles was originally found on Access 2 Learn
