Skip to main content
  1. Home
  2. Software Development Practices and Tools

Software Development Practices and Tools

Software development processes are supported by practices. Practices are developer behaviors, maybe supported by techniques and tooling, that provide a systematic way for developers to develop software as part of a larger software development process [ieee10]. We will use several software engineering practices this semester as we develop software to demonstrate the technical learning outcomes of the course. These practices are used in industy by software engineers. Additionally, we will describe tools that we will use in CSC216 to support development practices. The specific tools we will use are frequently used in industry, but some companies or teams may use other, similar tools. That means that the tools we use in this class are representative examples of tools to support a given practice. You should be able to pick up how to use similar tools quickly since you will have experience using our tools suite.

Design Practices

Design practices are activities that support creating and maintaining a software design. The design phase is when we consider the architecture, software components, and data that are needed in a system to satisfy the requirements. For our class, we are going to focus on class-level design. We are interested in identifying the important objects in our system and defining the template classes, states, and behaviors of those objects and the relationships between multiple objects. We represent the class-level view of our system as a Unified Modeling Language (UML) class diagram. UML can also model other aspects of software.

A class diagram models a static overview of the system. In a class diagram, each class or interface is modeled with its state (fields) and behavior (methods). The has-a (composition) and is-a (inheritance) relationships between classes are modeled with connectors. The entire skeleton (e.g., classes with fields and method headers) of a program can be generated from a complete class diagram.

Supporting tool: UML Editors

  • Dia - Creates UML diagrams, including class diagrams.
  • UMLetino - Online tool with text based properties that can be exported/imported in XML.
  • PlantUML - Tool that lets you “program” UML diagrams.
  • Draw.io - Online tool to draw diagrams
  • LucidChart - A commercial UML and diagramming tool that is free for students. You must use your NCSU email address to register.

Integrated Development Environments

Integrated Development Environments (IDEs) provide an environment and common tooling that software engineers use when writing software. IDEs typically incorporate tools that support several of the other practices listed below including a compiler for one or more programming languages, documentation tools, unit testing tools, version control tools, and refactoring tools. Additional functionality or tooling can be added to IDEs through plug-ins.

Supporting tool: Eclipse - an open source IDE for Java development that can be extended with plug-ins.

Supporting resource: See the Eclipse Guide for instructions on how to set up Eclipse and use tools that are part of the Eclipse system.

Programming Language

Selection of an appropriate programming language to solve a problem is a crucial decision during the design phase of development. For this course, we will be using the Java programming language and that means the applications we create will be most appropriate as a stand-alone application. If we were to create an embedded system, we would choose another language like C. For a web-application, we would like work with Java Script libraries or the .NET framework. While this course focuses on Java as the programming language to demonstrate your understanding of learning outcomes like advanced object-orientation and linear data structures, the underlying object-oriented principles are similar in other languages like C# and fundamental data structure concepts apply when writing a linked list in C. The theory transcends the current popular language.

Supporting tool: Java - an open source, object-oriented programming language.

Supporting resource: See the Eclipse Guide for instructions on how to set up and use Java in Eclipse.

Reviews & Inspections

Software reviews are “a process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval” [ieee10]. An inspection takes a review a step further through “a visual examination of a software product to detect and identify software anomalies, including errors and deviations from standards and specifications” [ieee10]. The goal of inspections are to find problems in a given software artifact before that artifact makes it to the next phase of development or to the customer. That means that all types of artifacts can be reviewed or inspected: requirements specifications, design documents, source code and supporting documentation, and test code. We’ll review all of these artifact types over the course of the semester.

Static Analysis

Static analysis is “the process of evaluating a system or component based on its form, structure, content, or documentation” [ieee10]. Automated static analysis tools look for common patterns of misuse, security vulnerabilities, or violations of programming language recommended practice and notify software engineers about the potential problems in their code without execution of the source code [ayewah08][ayewah07]. Reviews and inspections are a manual form of static analysis; tools allow us to find common mistakes quickly so that software engineers can focus on larger problems related to requirements during reviews and inspections.

There are various types of static analysis tools. Some provide feedback on the style of your code (e.g., correct naming conventions, correct Javadoc syntax, etc.). Others provide notifications from a deeper analysis and may identify more significant problems (e.g., test methods with out asserts, possible null pointer exceptions, unclosed resources, etc.).

Supporting tools:

  • FindBugs - an open source tool and Eclipse plug-in that finds misuse of common programming practice, security problems, possible null pointers, and various other potential problems.
  • CheckStyle - an open source tool and Eclipse plug-in that finds where source code does not meet the style guidelines for an organization.
  • PMD - an open source tool and Eclipse plug-in that finds style issues and common testing mistakes.

Supporting resource: See the Eclipse Guide for instructions on how to set up and use static analysis tools in Eclipse.

Documentation

Documentation is a critical aspect of developing software because documentation describes the requirements of the system, reasoning behind a design, details about an implementation, description of tests, and how to install and use a system. The Java Application Program Interface (API) describes the classes, state, and behaviors of the Java library; having the API documentation is critical to the success of software engineers using Java libraries to develop their system. We expect that you will document your own source and test code and provide other supporting documentation like design rationale and black box test plans.

Supporting tool: Javadoc - a tool that translates in-code Javadoc comments to a set of web-pages for reference by other software engineers.

Supporting resource: See the Eclipse Guide for instructions on generating Javadoc in Eclipse.

Testing Practices

Testing is an “activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component” [ieee10]. Testing is an activity associated with the test phase of development where we validate that software requirements are met. There are many different types of testing, including unit testing and system testing, that are practices associated with evaluating different aspects of the system.

Many software engineers use the practice of test-driven development (TDD) while unit testing a method or class during development. TDD is a practice where unit tests are written before any implementation code is written. The tests initially fail and developers then implement code that passes the tests. By writing tests first the testing phase of development isn’t pushed to the last minute.

Another common practice with testing is automation, especially with unit tests. A unit test is written to exercise a single unit of code, usually a method. If the unit test exercises additional code, it is then an integration test (e.g., the test exercises method1(), which calls method2()). Unit testing is a form of white box testing, where the code under test is known. Unit tests are typically written by the developer. Tests are typically automated through the use of a framework (like JUnit), and they can be run quickly after changes to the code to ensure there is no regression in functionality.

System tests are executed on completed or mostly completed software programs and exercises a full path of functionality through the program. System tests are created from the requirements and are typically written before software is developed. System testing is a form of black box testing, where details of the code under test are typically not known.

Supporting tool: JUnit - an open source, automated, unit testing tool for Java. See the Eclipse Guide for instructions on running system and unit tests in Eclipse.

Code Coverage

Code coverage is a measure of the source code executed by a suite of tests [marick97][williams13]. The idea behind code coverage is that executed code is more likley to be bug-free. Code coverage can help identify how to test every path in a program’s exeuction by identify the possible valid paths through a method. Code coverage tools calculate what portions of the code have been covered by a test execution.

Supporting tool: EclEmma - an open source Eclipse plug-in that uses the Jacoco library to measure code coverage of a test execution.

Supporting resource: See the Eclipse Guide for instructions on setting up code coverage plug-ins and using code coverage.

Version Control

Version control is the “establishment and maintenance of baselines and the identification and control of changes to baselines that make it possible to return to the previous baseline” [ieee10]. In software development, we use a version control system to maintain versions or baselines of code a different points of development and when a major or minor version of source code is released. Modifications when fixing bugs and adding functionality are also committed to version control systems. Version control systems maintain the development history for a software product. An additional benefit of version control systems is that they allow for collaboration between multiple developers and facilitate the merging of code edited by more than one person. A repository is a structure in a version control system that contains code artifacts. A version control system may have multiple repositories.

We will use a version control system for submission of projects starting with the initial set up of the project through the final submission before a deadline. Version control will also support collaborative development for labs and some projects.

Supporting tools: Git and GitHub - Git is an open source, distributed version control system. GitHub is a web-wrapper around Git that provides additional functionality like issue trackers and wikis.

Supporting resource: See the CSC Git Guide for details on working with Git.

Continuous Integration

Continuous integration is the practice of merging code changes into the master development branch in a version control system. From there, the modified code base is evaluated by automated tests, static analysis tools, and other tools. In CSC216, we’ll use a continuous integration system to automatically evaluate and provide progress on your solution to labs and projects.

Supporting tool: Jenkins - an open source continuous integration server that connects to version control systems like GitHub and is customizable through plug-ins.

References

  • [ieee10] “Systems and software engineering – vocabulary,” ISO/IEC/IEEE 24765:2010(E), pp. 1–418, Dec 2010.
  • [marick97] B. Marick, “How to misuse code coverage,” 1997.
  • [williams13] L. Williams, An introduction to software engineering. Amazon Digital Services LLC, 2013.
  • [ahm08] N. Ayewah, D. Hovemeyer, J. D. Morgenthaler, J. Penix, and W. Pugh, “Using static analysis to find bugs,” IEEE Software, vol. 25, no. 5, pp. 22–29, Sept 2008.
  • [apm07] N. Ayewah, W. Pugh, J. D. Morgenthaler, J. Penix, and Y. Zhou, “Evaluating static analysis defect warnings on production software,” in Proceedings of the 7th aCM sIGPLAN-sIGSOFT workshop on program analysis for software tools and engineering, 2007, pp. 1–8.