|
Ol� pessoal,
Esse artigo passa alguns conceitos de como
desenvolver projetos
eficentes utilizando JSP ... creio que grande parte
dessas id�ias
sejam essenciais para qualquer projeto de
Sistemas.
*********** Design Methodologies for a JSP
Project ***********
by Casey Kochmer - www.jdance.com I have been asked to what design methodology I subscribe in building projects. The answer is no official one. Most design methodologies are bloated and impractical. If it takes a 200 page book to explain, then it is just too complicated to use in real life. I believe design methodologies should be simple and holistic in nature. Probably the most important key to a successful design methodology isn't design related but rather depends on a solid project management policy. No matter how good your design is, it still fails if your project is mismanaged. The final important factor about a design methodology is that it provides a simple framework to hold together the contradictory forces required in a successful project. So the methodology I use and believe in can be boiled down to these basic tenets. Project Management Tenets: 1) Know the reasons why projects fail. Here are the top ten reasons projects fail: - The project is too rigid and doesn't allow changes which are required by the users. - The project is not rigid enough and constant changes by the customer prevent the final product from being completed in a timely manner. - Communication is poor or nonexistent between users/customers and coders. - Expectations are unrealistic. - Timelines are unrealistic. - The project is too large to be managed successfully. - No testing or too much testing is done. - The wrong tool is used for the job. - The technology used in the project is still too new for the project/users. - The project doesn't respect its members. Many of the next tenets are designed to address these issues. Each project, however, has its own balance. Because of this, both the project manager and lead programmer must tinker with the internal balances. 2) A project needs to be flexible and allow the users to ask for changes as the code is being developed. At the same time, the project needs to be rigid and minimize design changes during development. Balancing these contradictory needs is a fine art and each project will have its own unique balance. 3) The project team needs direct access to the customers throughout the project for mini reviews and clarification of questions. 4) A project should be less than 1 year in length from start to finish, ideally 6 to 9 months in length. Any project that is longer/larger needs to be broken into sub-projects. 5) The project manager and lead programmer should always be two different people. Combining these roles ends up being too much for one person to do well. 6) A project team should be no larger than 7 people (my ideal size is 5). 7) A project team should have a mix of senior and junior developers. I have found a project team consisting of all senior developers tends to be stale and stuck in its habits. A project team of only junior developers fails due to a lack of experience. A mixture works best since the junior developers keep the senior developers on their toes. A junior person will ask why something is a certain way, and those questions promote improvement. Also, as the senior programmers train the junior programmers, it often leads to examination of existing infrastructure and, consequentially, improvement. 8) The tools used in the project need to be readily accessible to the staff who will maintain the project; or the staff maintaining the project will require easy access to people who can help them. 9) Start with a realistic timeline. If the schedule is unreasonable at the start, then the timeline and staffing need to be adjusted quickly. Many projects make the mistake of only adding resources to speed up the schedule. This is often a mistake. When a schedule is unreasonable it often means more is wrong than a just a lack of resources. When re-evaluating the schedule also examine the project goals, methods and choices. Make sure you are working under valid assumptions and information. After this re-examination, make project changes as required by your review. 10) Everyone on the main project team needs to feel comfortable, be able to ask questions and freely talk with each other. Without clear communications projects rapidly fail. The first sign of trouble is when people have trouble exchanging information. Silence is not a sign that work is being accomplish. It is a sign that everyone in your project is working in a vacuum. 11) Everyone on the project should understand these tenets and examine the project up front. If a project can't meet these tenets, each team member needs to bring up the issues as early as possible. When I work on a project, often times I will spot something which is wrong and I always bring up the issue immediately. When problems are addressed before or at the beginning of a project, solutions are often easier to find. Ignoring these issues, however, often leads to ulcers, finger pointing and unsuccessful projects. I will not accept any project to which I cannot apply these tenets. These project tenets are my guideline to being successful and I know ignoring any one of them has dire consequences. Design Tenets 1) Avoid being the first on the block to use a new technology. Let a technology or product and its support information mature. How do you tell if a technology is mature enough? Watch the degree of support and information available on the Internet. A new tool is only good as the help you can find to use it. 2) When you must use newer technology, always have a backup plan in the case things don't work. I have discovered newer technologies will fail roughly half the time at some critical point in your path. Plan your backups from the start to avoid large scale problems later. Always use new technology as early as possible in a project to evaluate if the it will work. 3) Make sure the user is advanced enough for the technology in the project. For example, don't use client-side XML/XSL if the customer is on a 3.x browser. It may make sense, however, to use server-side XML/XSL since the user wouldn't be impacted. 4) Build towards minimal needs. This prevents bloat, speeds up coding and is easier to test. For programmers this means don't over build. See my ramble on coding re-use for more discussion of this topic. Customers and users should only ask for what is needed. 5) The primary goal is to build maintainable code; the secondary goal is to build reusable code. With Java, object orientation is one of our primary tools for success. But don't be blinded by object orientation. You can build reusable code with very basic templates, function libraries and wise design choices. Object orientation is just one trick in a bag of many tricks we have available for our use in programming. 6) Testing and piloting of the project is a critical part of its success. (For additional information on setting up a testing schedule.) In addition, the pilot phase should be robust enough to approximate reality with a schedule that allows enough time for fixes. 7) After the main project is finished, a small second stage should address and rebuild sections which don't work as well as expected in the final environment. 8) Think in terms of multiple projects. Often times a project team will be together for more than one project. Project staff should rotate responsibilities over time. This automatically builds backup capability into future projects. Also, as each project member will be doing new things over time they won't get as bored. (This means your project teams will be stable over a longer period of time.) 9) Plan on having several people work on the same code. To implement this I reuse code from project to project. However, we do more than re-use the code. On each new project someone else works on an existing piece of code. Every time someone new hits a reused piece of code they should revise and optimize it. In this manner code will improve over time. It will have less bugs, be more efficient and have more complete documentation. Not only will the code improve but it will evolve over time and be up-to-date with the latest technology. 10) Use open source code when possible. 11) Use JSP's distributed environment to your advantage. Use client-side scripting to take advantage of your client's machine. Really rely on the database to build centralized stored procedures for data processed logic. Use a J2EE server to generate XML and XSL data templates for HTML output. Avoid concentrating the design and evenly spread the work to the areas where performing the work is most efficient. 12) Avoid putting too much logic in any one JSP page. The more things a JSP page does, the bigger the impact to your project when you have to update or fix that JSP page. Keep JSP pages as atomic as possible. Also take advantage of Tag and JavaBean libraries to build reusable modules. This will aid in making the JSP pages maintainable. Conclusion This is the basic outline of the design philosophy I use on projects. It has served me well and works. Try it! []s Bruno Reded -+=+=+=+=+=+=+=+=+=+=+=+=+- Picture Internet - S�o Paulo - Brazil [EMAIL PROTECTED] "Entrega o teu caminho ao Senhor; confia Nele, e Ele tudo far�". Salmo 37:5 |
