Using Oracle Developer In a Team Environment
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Only a handful of software development projects are small enough to warrant development by a single software engineer. The rest will require team interaction to complete the project for the given schedule. Team dynamics have the potential to complicate development efforts, but can be minimized using the guidelines set forth in this article. Although some of these guidelines can be used for any software development project, this article will apply them to Oracle Developer projects.
Software development can be broken down into the following stages:
- Design
- Development or coding
- Testing
- Deployment
- Support
Oracle Developer projects are no different. Before jumping in and creating the code for your application, you must design it properly. After the design is created and has been reviewed by the appropriate individuals (the boss is always a good starting point, but don't forget to include some potential users as well), actual coding can begin. Testing of the code should begin well before it is considered "done." However, after the coding has been completed, testing usually continues until there is some level of assurance that the project works as expected. Then, it is time to deploy the software. Finally, after software is in use, it must be supported. Even the best-designed projects require deployment support. Often, it is as simple as showing the user how to take advantage of a particular feature. Other times, support requires making an enhancement or fixing a bug.
All aspects of the software development process are important, but for the purpose of this article, I will focus on the first two: design and development. Small teams may have one designer or system architect, and employ a group of experienced coders to create the system. As the project grows in scale, however, these roles will grow in size and complexity, requiring larger teams.
The Design Team
When I was at Oracle, I was responsible for a development team to create sample applications for one of Oracle Developer's predecessors. The team was made up of three coders, and that was it. Luckily, one of the coders had extensive graphics design experience. Although the other two were good at getting the product to do some phenomenal things, the graphics designer was able to make it look good. At that early stage of my career, I learned the importance of having a graphics designer on staff. When it came time for me to move onto a different project and create a new development team, the first person I hired was a graphics designer.
In addition to the graphics designer, it is critical to have an architect for the software development project. That individual should have intimate knowledge of Oracle Developer and know what it is capable of doing. The architect should also be able to communicate with the graphics designer. Communication is a two-way street. Not only does the architect need to be able to describe the interface elements, but also listen to feedback.
With the architect and graphics designer on the team, you need to augment their skills with team members to collect application requirements. The requirements gatherers need to work with potential users and/or customers to make sure all the features required by the application will be included in it. These requirements should then be brought back and incorporated into the system design. Generally, the requirements gatherers should be made up of some of the coders who will actually build the application.
The output of the design team should be a design document. This document should include the following:
Screen shots for every form, graph, or menu used in the application
Report examples for every report
Colors to be used for application elements (that is, background color should be #F0F0F0, Text Entry Fields should be white, boilerplate text should be black, and so on)
Fonts to be used for various aspects of the application
Algorithms to be used for calculations
Anything else that is required to complete the development of the application
With the design completed, you should review the design document. It is not necessary to have all the potential users review the document, but it is helpful to have some. You should also have it reviewed by all the software engineers who will be involved in building the application. It is less costly to fix bugs in a design document than it is to fix them in a completed application.