Tools Required for Software Development

Software is being created at a smaller cost than it ever has. Yet, more money is being spent on the engineering of software than ever before. On one side there are single person “teams” that do every part of the planning, design, implementation, testing, deployment and post-delivery maintenance themselves. On the other hand companies like Google, Microsoft and Amazon employ thousands of employees. According to Statista.com, Alphabet (Google’s parent company) alone had over 88,000 full-time employees in more than 50 countries during 2017.

Not all of these employees work directly on software. 

Those that do, work on many different software products. Even still, the number of software engineers on a particular product is many and growing. The average annual salary for a Software Engineer at Google is estimated to be over $120,000. Add to this cost of tools such as computers and software licenses. Compare that to the single person working from home on an inexpensive laptop and there is quite a difference in cost. This paper will focus on the tools software engineers use to build software. These tools are known as CASE (computer aided software engineering) tools.

CASE tools are generally categorized into two groups. Upper CASE tools are tools that are used in the planning stages of a project. These tools are used to design and analyze a project. Tools used to create flowcharts or diagrams are useful for planning the flow of data and control for a project. Documentation is needed throughout the entire software production process. There are tools to help create documentation for both the software developers themselves, as well as for end users. These can be thought of as project management tools, though they are likely to be used by more than just project managers. (tutorialspoint.com)

Lower CASE tools are used for implementation. These are the tools most people become first accustomed to when learning computer programming for the first time. Historically programmers used simple text-editors to write code. As time went on more and more programmers used IDEs (Integrated Development Environments). IDEs generally consist of a text-editor with special features built in. Common features include a GUI (graphical user interface) with buttons to perform tasks when pressed that would have taken much longer. Examples of these are compilation and run buttons. When writing a program with the C programming language one must save the code, compile it, and run it. 

Doing this manually requires the programmer to save the file, switch to the command prompt or terminal, move to the directory the file they want to compile is in, compile the code by typing ‘gcc filename.c -o filename’ (this example using the gcc compiler), and finally they can run the file by typing ‘./filename’. Those steps are not difficult, nor are they particularly time consuming when performed once. When performed upwards of one hundred times a day this act becomes costly. When performed one-hundred times a day by one-thousand employees the cost is great at best. With an IDE this act is reduced to pressing a compilation button (most IDEs automatically save the code when compiled) and then a run button.

Another use of lower CASE tools is for testing the overall behavior of an application. To test applications software engineers write tests to perform on the software. These tests are software themselves. This means that the tests need to go through the design, implement and test cycle themselves. Many companies have created software to serve this purpose. There are even open source projects available for use by anyone for free. (Software Testing Tools list, softwaretestingclass.com)

CASE tools are often designed to exploit stepwise refinement. Stepwise refinement is “a means to postpone decisions on details until as late as possible to concentrate on the important issues.” (Schach, 124) By design CASE tools push the user to focus on only a few things at a time. Miller’s Law asserts that people in general can concentrate on roughly seven things at a time. (Schach, 125) A simple way to think about Miller’s Law and how it can help develop software is to consider the bit. A bit gives only two possibilities. Now consider 4 bits. There are now six-teen different possibilities to choose from making choices harder. (Laws of UX, lawsofux.com) This inability to focus on infinitely many things at a time can become a strength when tools are built around it.

Many software engineers would say that version control software is the most important CASE tool for software development. Git is free, open source version control software. (Git, git-scm.com) It is famously used by the company GitHub. GitHub is a web-app that provides free and paid remote repository services. A repository is essentially the directory a project is contained within. Often this includes all documentation and source code. This repository can be uploaded to a remote server. This allows a team of people to view and work off of the same code. Each team member downloads or “clones” the repository to their machine. They will create a branch. The team member can then change any code they want on their branch. Once they have completed a task they will “commit” the code. This finds the changes they made to the code and updates it. Every time this happens Git takes a “snapshot” of the repository. This is really where git becomes useful. Git backs up the source code every time a change is made. This allows programmers to have piece of mind when something breaks as they can revert to a working version of the software.

Git is useful for the implementation phases of software development but becomes indispensable during the post-delivery-maintenance phase. As this is the longest stage of development, anything that allows an increase in productivity will greatly reduce the lifetime cost of development. It is so helpful at this stage because it allows the use of different branches for different purposes. One branch will generally be the currently deployed code. It is important to have this backed up in case something was to happen to the hardware that is running the software. For example, a web-app will be hosted on a server. The server could malfunction or become damaged and stop working. With the unaltered code on the deployment branch of the repository the code could be redeployed as soon as a new server is set up. Since it is so important to have this “clean” version of the software available, a separate branch is set up for development. One more branch is commonly used for testing. This means a code change will go from the development branch to the testing branch. Only once it is tested and determined to be working will the change be merged into the deployment branch. This systematic approach to code changes goes a long way towards keeping code clean and avoiding as many bugs as possible.

Hardware is generally not considered a CASE tool. It is however required to use CASE tools. With hardware becoming faster and cheaper to purchase, CASE tools become faster and more feature rich. The cost of hardware tools come not only from its price to purchase but from the time it takes to complete its task. In the 1960’s the primary hardware for computing were mainframes. These large systems were prohibitively expensive and compared to the standards of even the 1980’s or 1990’s excruciatingly slow. This meant every time a programmer ran their code, they had to wait a long time to get the results from the program run. Often, they did not get the results until the next day. Today most programmers can run their code over and over making small changes to find errors and keep things running smoothly.

CASE tools can come with risks associated. The most basic problem that arises from the use of CASE tools is the tools not meeting expectations. Once the tools are purchased the developers will need to become familiar with them. This can take weeks to months. Inadequate training is a surefire way for a company to loose money. Often the people trying to get an organization to begin using a particular tool may over-promise about how much the tools will help. This leads to unrealistic expectations, and again a loss overall. (Computer-aided software engineering, wikipedia.org)

There are many more CASE tools available for free as well as paid options than were discussed here. These tools are required to build software efficiently. More tools are developed every day. Even more are updated to be more powerful and easier to use every day. The tools you use today will be different on some level from the ones you use next year. With all of the languages software developers often have to learn, the tools can be forgotten about. It is important to continue learning how to use different CASE tools throughout a career in software development. Most software engineers expect to learn many languages over the course of their career. For each of those languages that is learned many tools will be learned as well. It can be said that if you do not like to learn something new every day, software development is simply not for you.

Citations

• Computer-aided software engineering. (2018, December 02). Retrieved from https://en.wikipedia.org/wiki/Computer-aided_software_engineering#Major_CASE_Risk_Factors 
• Git (n.d.). Retrieved from https://git-scm.com/ 
• Laws of UX. (n.d.). Retrieved from https://lawsofux.com/millers-law
• Number of Google employees 2017. (n.d.). Retrieved from https://www.statista.com/statistics/273744/number-of-full-time-google-employees/
• Schach, S. R. (2011). Object-oriented and classical software engineering. New York: McGraw-Hill.
• Software Testing Tools list. (2018, November 26). Retrieved from https://www.softwaretestingclass.com/software-testing-tools-list/
• Tutorialspoint.com. (n.d.). Software Case Tools Overview. Retrieved from

Did you like this example?

972

41