This is a mock business report written for Business Communication (English 302).
The premise is that I work for a software company and I am proposing an improvement to an integrated development environment.
Debugging is the most time-consuming process in software engineering. Coding errors are hard to detect, since having even one line wrong can produce disastrous results. Many programmers detect bugs by filling their code with output lines to see what the values of their variables are. This is a very inefficient method, and although tools exist to make the process faster, they are seldom used, perhaps because they are hard to use or because programmers don't feel the need to use them.
My objectives are to cut the cost in time and money of debugging code, and to create a profitable software package for other programmers. Our company stands to gain by creating a smart and easy-to-use debugger. It will make the process of programming swifter and more efficient, leading to both profits by selling the debugger and savings by creating a more efficient software engineering process for ourselves.
The main improvement of our debugger over other debuggers will be a visual component; complex data structures like graphs, tables, and trees will be displayed visually as the programmer conceptually sees them, not as lines of text.
There are three possible directions to take concerning adding a visual debugger to an integrated development environment, or IDE, which is a program used to create programs.
First of all, we could create our own IDE and implement the debugger along with it. This option would take longer to develop than the first, but would not have the difficulties of interfacing with other IDE's, since the debugger would be tailor-made for our own IDE. Also, we could stand to charge more for this product than for a plug-in.
Secondly, we could create the debugger as a plug-in for an environment such as Visual Studio or Eclipse. This would take less time and be cheaper than other options, but may lead to difficulties in interfacing with a variety of IDE's, and may be unstable.
Finally, we could link an existing IDE and an existing graph displayer but program the interface between the two. This would take the fastest among the three options but would not lead to much actual profit by sales. It would, however, improve the efficiency of our own programming practices.
As for the schedule, option 1 could take many years; it would probably demand constant attention. Several years would be a reasonable period for option 2, and option 3 could be done in a matter of months. The duration of one development cycle within these schedules would vary depending on how many versions we release to the awaiting public, among other factors, but the ideal development cycle would be one version per year. Both Eclipse, which was open source starting on November 7, 2001, and GraphViz, which started in 2000, have maintained a nearly...