1. People far more important
Your development software is for others to use, no one is used by the software that is not meaningful. Many hipsters in software are flat in the early days of their career, because they will focus on the main energy at that time. Obviously, components, EJB (Enterprise Java Beans, and Agent) are very interesting. But for the user, if your software is difficult to use or you can't meet their needs, the background uses better technology to do things. Multi-speaking time to software needs and design a user can easily understand the interface.
2. Understand what you want to achieve
Good software designers spend most of the time on building a system model, occasionally writing some source code, but that is just to verify the problems encountered during the design process. This will make their design more feasible.
3. Modest is a must
You can't know everything, you don't even work hard to get enough knowledge. Software development is a complex and arduous job because software development has been continually updated. Moreover, a person is impossible to understand all the processes developed. The fresh things that you have contacted daily in everyday life may not be too much. But for people engaged in software development, you can learn a lot of new things (if you want) every day.
4. The demand is demand
If you don't have any needs, you don't want to develop any software. Successful software depends on time (completed within the time required), the budget and whether the user needs to meet the needs of users. If you can't exactly know what the user needs, or the demand definition of the software, then your project is destined to fail.
5. The demand is actually rarely changed, and it changes your understanding of the needs.
Doug Smith of Object Toolsmiths (www.objecttoolsmiths.com) often likes: "Analysis is a science, design is an art." He means that there is only one "correct" analysis model in many "correct" analysis models that can fully meet the needs of a specific problem (I understand what needs analysis requires meticulous, accurate completion, and design Instead, you can play creativity and imagination - translator's note).
If the demand is often changed, it is likely that you don't have a need for demand analysis. It is not really changed.
You can complain that users can't tell you what they want, but don't forget, collecting demand information is your work.
You can say that the new developers make things a mess, but you should determine what should I do and how to do it in the first day of the project.
If you think that the company does not allow you to get into contact with users, you can only explain the company's management is not really supporting your project.
You can complain that the company's management system is unreasonable, but you have to know how Most of the same contact is doing.
You can excuse your competitors' success because they have a new idea, but why didn't you think of it first?
There are very few things that demand truly change, but there is no reason to do a good job of demand analysis.
6. Read often
In this daily industry, you can't get intoxicated too long in your achievements.
Reads at least 2,3 professional magazines or 1 professional books per month. Keeping a lot of time and money, but will make you a very powerful competitor.
7. Reduce coupling between software modules
The system of high coupling is difficult to maintain. The modification of one is caused to change the changes in even more.
You can reduce the coupling of the program by the following methods: Hide implementation details, force the component interface definition, do not use the public data structure, do not allow the application to directly operate the database (my experience is: When the application is written when writing SQL code The coupling of your program is already very high).
Software with low coupling can be easily reused, maintained, and expanded.
8. Improve the cohesiveness of the software
If a software module is only implemented, then the module has high cohesiveness. High cohesive software is more easily maintained and improved.
Determine if a module has high cohesiveness, see if you can describe its function with a simple sentence. If you use a bit or you need to use similar words "and", "or", you need to refine the module.
Only high cohesive modules may be reused.
9. Consider the graft of software
Transplantation is a specific and actual work in software development, do not believe that some software tools advertising advertising (such as Java's propaganda slogan Write Once Run Many Translator Note).
Even if only the software is regularly upgraded, it is also as important as it is as important as the other operating system or database transplant.
Remember to transplant from 16 Windows to 32-bit Windows "fun"? When you use a feature of an operating system, such as its process communication (IPC) policy, or writing a stored procedure with a database. Your software and that specific product combination are already very high.
A good software designer packed the unique implementation details, so when those features change, you just need to update that package.
10. Accept changes
This is an old saying: the only change is only changed.
You should record all systems will have possible changes and potential demand for future implementation (see "Architecting for Change", Thinking Objectively, May 1999)
By considering these assumptions during modeling, you may develop a strong enough and easy maintenance software. Designing strong software is your most basic goal.
11. Do not underestimate the demand for software size
The largest lesson of Internet brings us is that you must consider the expansion of software scale in the initial stage of software development.
Today, only 100 applications used by the department, which may be used by tens of thousands of people tomorrow, next month, there may be millions of people through the Internet.
In the early stages of software design, the basic functions of the software are determined according to basic transactions that must be supported in the use case model. Then, gradually add a relatively common function when the system is constructed.
In the design, consider the size demand of the software, avoid rewriting the software if the user group is suddenly increased.
12. Performance is only one of many design factors
Pay attention to an important factor in software design - performance, this seems to be the user's most concerned. A poor performance will inevitably be rewritten.
But your design must also have reliability, availability, portability, and scalability. You should define and distinguish these factors in the start of the project to use it in your work. Performance can be, or it is not a priority factor, my point of view is to give each design factor consideration.
13. Management interface
"UML User Guide" (Grady Booch, Ivar Jacobson, 1999) pointed out that you should define the interface between software modules in the early days of the development phase.
This helps your developers fully understand the software design structure and make unanimous comments, so that the module development team is relatively independent. Once the interface is determined, the module is not very important.
Fundamentally, if you can't define your module "What will look like outside", you are sure you don't know what you want to implement within the module.
14. Take a longer time to walk near the road
There is no shortcut in software development.
Shorten your time spent on demand analysis, the result can only be developed software that cannot meet the needs of users, must be rewritten.
Every week in the software modeling, it will spend more time for a few weeks during the future coding phase, because you will write a handwritten program before comprehensively thinking.
In order to save a day's test time, you will miss a bug, in the future maintenance stage, it may take a few weeks or even a few months to repair. In this way, it is better to rearrange the project plan. Avoid picking up the cantress, only one time but do it (Do It oncé by doing it right).
15. Don't trust anyone
Products and Service Sales companies are not your friend, most of your employees and senior management people are not.
Most product suppliers want to tie you in their products, which may be operating systems, databases, or a development tool.
Most consultants and contractors are only concerned about your money is not your project (stop paying them to you, see how long they will stay around).
Most of the programmers think they are more excellent than others, they may abandon your design model and think it is better to use it.
Only good communication can solve these problems.
It is clear that do not rely on a product or service provider, even if your company (or organization) has invested a lot of money to the company in terms of modeling, documentation and procedures.
16. Prove that your design is feasible in practice
A technology prototype should be established first, or a "end-to-end" prototype. To prove your design is capable.
You should do these things in the early days of development, because if the software design is not feasible, there is no matter what measures taken in the code implementation phase. The technical prototype will prove the feasibility of your design, so your design will be easier to support support.
17. Apply known models
At present, we have a large number of ready-made analysis and design patterns and solutions to solutions.
Generally speaking, good model design and developers will avoid redesigning mature and widely used things. http://www.ambysoft.com/processpatternspage.html The information of many development modes is available.
18. Study the strengths and weaknesses of each model
There are currently many types of models available, as shown below. The use case captures is system behavior requirements, and the data model describes the data required to support a system run. You may try to join the actual data description in the use case, however, this is not very useful to developers. Similarly, the data model is useless to describe software requirements. Each model has its corresponding position during your modeling, however, you need to understand where, when you use them.
19. Apply multiple models in existing tasks
When you collect demand, consider using the use case model, user interface model, and class-level models.
When you design the software, you should consider making a class model, sequential diagram, state diagram, collaboration map, and final software actual physical model.
Program designers should slowly realize that software implemented only with a model is either unable to meet the needs of users, or it is difficult to expand.
20. Education your audience
You spent a lot of effort to build a very mature system model, and your listener can't understand them, even worse - even why don't know how to build a model first. Then your work is meaningless.
Teach your developer's basic modeling knowledge; otherwise, they will only look at the beautiful graphs you draw and continue to write irregular procedures.
In addition, you also need to tell you some basic knowledge of some need modeling. Explain your use case and user interface model so they understand what you want to express. When everyone can use a universal design language (such as UML-Translator Note), your team can realize real cooperation.
21. Fool with tools or fool
You give me a CAD / CAM tool, please design a bridge. However, if the bridge is built, I definitely don't want to be the first person from the bridge, because I don't have a good job of architecture.
Using a very excellent CASE tool does not make you a modeling expert, you can only make the user of an excellent Case tool. Become an excellent modeling expert takes many years of accumulation, will not be a week of training for a few thousand dollars in a week. A excellent CASE tool is important, but you must learn to use it and can use it to design it. 22. Understand the complete process
Good designers should understand the entire software process, although they may not be proficient in all implementation details.
Software development is a very complicated process, remember "Object-Oriented Software Process" page 36 of "Object-Oriented Software Process"? In addition to programming, modeling, testing, you have a lot of work to do.
Good designers need to consider the global. How to make the software meet the needs of users, how to provide maintenance and technical support, etc.
23. Frequent test, early test
If the test is nothing to do, then there is more than half of your software, it is necessary to be developed.
Establish a technical prototype for technical review to test your software model.
In the software life cycle, the more difficult the error found, the more difficult to modify the cost. It is worth it as early as possible.
24. Archive your work
Work that is not worth archiving is often not worth doing. Archive your ideas and make the decision made according to the idea; the archive software model is important but not very obvious. Give each model some summary description to make others very quickly understand the content expressed by the model.
25. The technology will change, the basic principle is not
If someone says "use a certain development language, a tool or a certain technology, we don't need to do demand analysis, modeling, coding or testing. Don't believe that this only shows that he lacks experience. Those out of technology and human factors, the basic principles of software development have not changed since the 1970s. You must also define demand, modeling, encoding, testing, configuring, facing risk, publishing products, managing staff, etc.
Software modeling technology is a need for many years of practical work to fully master. Fortunately, you can start from my suggestion, perfect your own software development experience.
Start with chicken soup, add your own vegetables. Then start enjoying your own hearty dinner.
