An introduction to software engineering
Building quality software is a process with a set of activities focused on creating software that works the way it is intended to. This process is defined as software engineering. If you look at the job description or listing for a software engineer role, you will find that the main requirements are that candidates have experience in a particular programming language, making it easy to assume that software engineering only involves writing code. The software engineering process can be boiled down to six phases: planning, design, implementation, testing, deployment, and maintenance. Software engineers are programmers who take an active role in all or most of the steps of the software engineering process. Making the justification for categorizing building software as engineering can sometimes be difficult to attempt when there’s the belief that it only involves programming. So, let’s make a parallel comparison to engineering a bridge.
Planning
The common phrase “Rome wasn’t built in a day” rings especially true for any large project. Most successful projects take time, starting with careful planning. Planning is essential to ensure the team stays on task and that goals and milestones can be met. It is also important that goals are trackable enough to reach a defined state of “done”, signaling when a project has been completed.
When planning a bridge, there are a few factors to consider before even beginning the design phase, one of the first being the cost. Constructing a bridge is an expensive multi-million dollar project and will need consistent and reliable sources of funding for building and maintenance. At first glance, this may seem to be non-essential information to an engineer, but costs can dictate how long they stay on the project as well as affecting their design choices. Something that a civil engineer may need to consider is the coating on a steel bridge, as it prevents corrosion from the elements, and they will need to make a decision on how to distribute the funds. They may have to choose whether or not to spend extra funding on a high-quality coating that extends the lifespan of the bridge and reduces maintenance costs in the future at the cost of limiting funding on other aspects of the project.
There are many factors to take into consideration when planning a software project: the technology used, the team, and the costs, just to name a few. Out of all things to consider in the planning phase, software projects heavily rely on requirements to guide the process. There are software engineering books that focus solely on requirements gathering because it is that big of a deal! In fact, it has its own field named requirements engineering. These requirements may come from various sources and have to be synthesized and communicated to whom it matters most. This includes the sources themselves in order to clarify that the requirements they ask for are actually the requirements that they want. Requirements are vital to a software project because they may dictate the team, resources, and technology that can be used, and murky requirements can slow down a project’s progress. If a project must be built with a particular programming language, a software engineer may need to consider whether they will use resources or not and if so, how, specifically their time and funding for a project to get up to speed on the language and relevant tools to be able to contribute at an acceptable pace.
Design
Design is the confirmation and integration of project requirements. It’s the first glance at what a finished product will look like and how it will work. The design stage breaks down the requirements into tangible problems, pairing them with practical solutions to create a vision for how it will all work together.
Designing a high-quality and safe bridge requires following a set of standards and specifications that engineers must adhere to. First, they need to design within their regional specifications, such as the American Association of State Highway and Transportation Officials (AASHTO) within the United States. Next are material-related design standards, which again may vary by regional location, such as the American Society for Testing and Materials (ASTM) within the United States. These standards also vary by material, such as steel and concrete, where various bridge components may be made of various materials. To be able to make some of these decisions, engineers need to know where they are building the bridge and will rely on inspections to guide their designs. If an engineer is building a bridge that is crossing a water channel, they will need a thorough inspection to investigate the risk of scour, or the washing away of naturally occurring materials in a body of water, posing a risk to the integrity of the bridge foundation. These and many other specific design considerations are collated into contract documents: a legally binding agreement on what the end result should look like.
Software design can be split into two categories: high-level and low-level design. High-level design focuses on the technologies and platforms that will be used, whereas low-level design focuses on how the decisions made for the high-level design will work. Because software engineers may specialize in a particular technology, the design stage is their first glance at where their skills will be used in the project. Here, they may own a particular piece of the project as the domain experts and be tasked with the design, delegating smaller tasks to other engineers, and communicating with other domain experts to design how their systems will all work together. This is common in web development projects, where software engineers may specialize in frontend development, or the visual and interactive pieces of a website, while backend development takes on the tasks focused on security and data management.
Implementation
The process of building the final product is one of the processes most of us can anecdotally recognize. If you have ever walked past, driven past, or lived near a structure that was built from the ground up, you will have witnessed an incremental change over time into its final state. What is truly being constructed in this step is the design that has been carefully planned and crafted, where it comes to life.
After careful planning of a design that has been thoroughly inspected and approved, bridge construction and construction engineering begin. Believe it or not, in the lifespan of a bridge, bridge failure is more likely to occur during construction than after its completion. Design engineers plan and calculate potential changes in stress on a bridge. For example, changes in traffic patterns will have an effect on a bridge’s load. However, during construction, the components of a bridge will experience various stressors in tension, compression, and load that may be outside the range of normal use. Furthermore, temporary structures will need to be put in place to stabilize the bridge during construction. Bridge construction can be a constant cycle of strengthening and stabilization through decisions on what parts of the bridge to create first and how these parts all fit together to create the bridge to the standards and specifications that were designed.
Implementation in software engineering is programming, where software engineers build the software product as designed. It’s the part of the process that software engineers will most likely spend most of their time on. The goal of implementation for software developers is not just focused on writing the code but also on taking the low-level design created in the design phase and converting them into code. It can be an arduous part of the process because coding takes time. Software engineers are in a constant cycle of coding and testing to ensure the code is working properly, efficiently, and as designed. It’s an incremental and iterative team effort to accomplish building the end result with a minimal number of bugs and errors.
Testing
Testing challenges the fact that something is labeled high-quality or good for use and consumption. Here is where the implementation is confirmed to be working as designed. This cycle of quality control is a final pass at confirming two things: was the right thing built and was the thing built right?
Construction of a bridge involves building it to its designed specifications, where variables such as the external environment, load, and rate of fatigue are taken into consideration to make a sturdy and safe bridge. First, the components of a bridge go through a quality control process that starts with inspecting the raw materials that will be used to fabricate the components. This is to ensure that they don’t contain any contamination in their overall chemistry that could lead to defects. When it comes to a completed project, the design may thoroughly explain how and why the bridge that has been built is in fact sturdy and safe, but is that really a fact when it hasn’t been used yet? How do we really know it’s safe? Bridges go through a critical period of evaluation to confirm these facts, where the goal is to assess all structural components and connections for possible points of failure at various loads. Methods for testing are categorized as destructive, such as drilling a piece of bridge material to examine its mechanical and chemical structure, and non-destructive where one approach uses a tool that sends ultrasonic waves to measure the thickness of the steel. These assessments produce ratings and measurements such as the safety margin that calculates the bridge’s structural strength against its potential load to estimate the probability of failure.
The phrase “quality software” is a loaded term, because high-quality software really touches on multiple aspects of the software that has been built. Software quality assurance (SQA) is a set of activities that assess the requirements, design, and code, as well as the effectiveness of the quality process itself. While some of these aspects may be more of a priority than others, depending on the project and team, what this really alludes to is that quality assurance is a process that is visited at each step within the software engineering process. Yes, it’s a process within a process! Quality happens at every stage in software engineering. Let’s recall the examples we have seen so far: the requirements are checked for accuracy, domain experts work with each other to confirm that their designs will work together, and software engineers test their code for bugs and errors when they’re coding. At this point, quality is quantified into particular metrics to measure and benchmark performance and efficiency. One common metric is test coverage, which is usually a set of additional code and tools used to test the code within the software to confirm its components are working as expected. This is then calculated and quantified into a percentage that signifies how much of the code has been tested for errors. The goal for most software teams is to reach 100% test coverage.
Deployment
Deployment, also known as delivery, focuses on delivering the finished product. Handing it over is not as simple as it seems; whether incremental or immediate, there may be additional steps to take before and after to ensure a smooth transition. Deployments may introduce a big change that has an effect on the people that will use it, or other things that may depend on it, and vice versa. With any large project, there can be multiple unexpected complications in the final delivery and the task may fall on the engineer to reduce these chances or resolve them when they occur.
Deployment considerations for a bridge begin in the planning phase. Restoring an existing bridge or erecting a new bridge will most likely cause disruptions in traffic, considerations that will be agreed upon in the design phase within the contract documents. This involves precautionary steps including mapping appropriate detours, carefully placing signs, warning travelers ahead of time when road closures are happening, redirecting traffic, as well as having a plan for opening or reopening the bridge. In the end, “completion” is an agreement that all parties involved have documented in a delivery and acceptance plan.
Deploying software begins with the tedious task of confirming every part is completed and has gone through sufficient testing. Although a team will design how it’s built, how it’s used, and where the software will run, they need to verify that the design matches the finished product and expectations on how users will interact with it. New or updated software can also involve changes in the systems that host it and the habits of users that consume it. Smartphone apps are a really great example of these changes; sometimes you need to update the operating system to use a new version, or even need a new phone that has the hardware to support it. Think about a phone app that you have used often in the past 5 years. The way it looks and the way you use it has probably changed significantly. Deployment is also the stage where consumers, users who are unaware of how the software was designed and built, may need training and documentation on how to use it. Not only do teams need to deliver the software but they also need to deliver information on how to use it and how to get support and report issues. Users sometimes discover new bugs that were not caught during testing, so providing information on how to be productive with the software helps manage user expectations and can uncover limitations in the software.
Maintenance
Many things that go through an engineering process will need some form of maintenance: airplanes, skyscrapers, space shuttles, or stoves, just to name a few. Built to “stand the test of time,” maintenance makes sure they stay that way by keeping them safe, relevant, and robust. At times, this means starting the whole engineering process again from the beginning as maintenance can be a large undertaking that requires planning and moving through steps to get to delivery or deployment.
The lifespan of a bridge is determined mainly in the planning and some of the design phases, which affect how it’s built and how long that will take. In the design phase, engineers make decisions based on cost, aesthetics, materials, and location, and will have to work these into regulated specifications. Sometimes, they don’t have the financial incentive or enough data to support choices that will increase the durability of the bridge. An important step in assessing the maintenance requirements of a bridge begins with an inspection, using both destructive and non-destructive methods. Defects may be ranked from the most critical to least critical to assist with planning and costs, where some repairs may particular consideration depending on the design. Finally, any expected traffic disruptions may require scheduled shutdowns and signs.
Maintaining software is an expected part of the software engineering life cycle that expands to various activities, the most common being fixing bugs and errors. The goal of many software teams is to ensure the software is working well enough to not disrupt the goals of its users. This means that sometimes smaller bugs will remain until all the prioritized ones have been resolved. Adding new software features or improving existing ones include planning, design, testing, and deployment phases that make the code base larger and more complex to manage. While maintenance is the final step in the software engineering process, it is more of a strategy of how to preserve the quality of the software. Maintenance is a continuous set of practices that can range from collecting and addressing important bugs to rewriting the code of a particular feature. The software engineering process always ends with maintenance, which is an indefinite length of time focused on preserving the software.
