Bryan Sumner
There is a great number of different design and development models around. When the customer look for a new model, their understanding of software design, software development, software testing is what it can and should or should not be applied to.
The waterfall model for example, restricts design or each phase of work to a concrete stage of the software life cycle model yet prototyping models begin a new design (and as a result new following stages) on each prototype (throw away prototyping).
Having a blur-free understanding of how you perceive design is a powerful concept that is often unaccountable. Many programmers don’t necessarily know why they design something in this way; conditioned over years of creating something the same way. They become informed about the concepts of object-oriented-design and then apply them to problems often with no adequacy or reason.
Knowing why you look at software design in that way, as you do, permits you to be more concentrated and do not make mistakes.
Ask yourself, what is acceptable software design? Maybe you think it’s a design that is simple or light weight. Or maybe it’s something that is easily persuaded. It’ll support a great number of features in the future with little re-write needed. Maybe it is just something that is consistent, predictable and allows you to sorte a problem systematically (software design patterns). All these ways are good and only your choice is going to affect how you design a system. If you think a good design is a design based on simple elements, you must keep in mind that it is fine for small projects. But on something larger you can lose a potentially better (albeit more complex) solution. If you always design with level of accommodation in mind then simple chances automatically connect with complex designs.
If you try to elude making changes, than you might automatically give preference to simpler designs. Unavoidably the client changes their mind, or the specifications change and you get into situation when your design is forced to deal with change.
If your project has specific time constraints (practically all projects are), then your are obliged to look for a simpler design. You don’t have time to engineer a more robust solution.
You as a rule can’t change the time limitation, that you have, but partition this time|division this time into parts will help you prepare your design better. If you suddenly get more time to complete the project, when you have already finished it, leave your design for a while, and later on evaluate again your choices. You may make a multitude of decisions and arrive it at your design, but being away of those decisions can help you improve your next ones.
If you need more information about software design and software development, visit our web software design site.
Tags: business software development, database design, software design, software development, software development company
Posted in Databases · February 15th, 2010 · Comments (0)