Fundamentals for Self-Taught Programmers E-Book

Jasmine Greenaway

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 404

Veröffentlichungsjahr: 2023

Beschreibung

Software engineering is a set of techniques, including programming, within the computer science discipline associated with the development of software products. This practical guide to software engineering will enable aspiring and new developers to satisfy their curiosity about the industry and become ready to learn more about the basics before beginning to explore programming languages, along with helping junior and upcoming developers to effectively apply their knowledge in the field.
The book begins by providing you with a comprehensive introduction to software engineering, helping you gain a clear, holistic understanding of its various sub-fields. As you advance, you’ll get to grips with the fundamentals of software engineering, such as flow control, data structures and algorithms. The book also introduces you to C# and guides you in writing your first program. The concluding chapters will cover case studies, including people working in the industry in different engineering roles, as well as interview tips and tricks and coding best practices.
By the end of this programming book, you'll have gained practical knowledge of the implementation and associated methodologies in programming that will have you up and running and productive in no time.

Leseprobe

Fundamentals for Self-Taught Programmers

Embark on your software engineering journey without exhaustive courses and bulky tutorials

Jasmine Greenaway

BIRMINGHAM—MUMBAI

Fundamentals for Self-Taught Programmers

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Gebin George

Senior Editor: Rohit Singh

Technical Editor: Jubit Pincy

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Prashant Ghare

Developer Relations Marketing Executives: Sonia Chauhan and Rayyan Khan

First published: May 2023

Production reference: 1070423

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80181-211-5

www.packtpub.com

Thanks for listening to all my incessant begging about getting a computer many years ago, mom. I’m so glad you finally said yes. This is dedicated to you and Colleen for helping me get to where I am today.

– Jasmine Greenaway

Contributors

About the author

Jasmine Greenaway is a New York City-based technologist, software engineering instructor, speaker, and technical community organizer. Her background is in full-stack web development with experience across multiple industries. Jasmine graduated from Embry-Riddle Aeronautical University in Daytona Beach, Florida, with a BS in software engineering in 2011, and graduated with an MS in software engineering from the University of West Florida in 2016.

Jasmine has a passion for helping newcomers to tech, understanding the struggles of what it takes to get started and stay motivated. She is currently working at Microsoft and teaches programming and computer science fundamentals at local colleges in the New York City area.

About the reviewer

Dmitry Vostokov started as a self-taught developer in FORTRAN and PDP-11 assembly language during chemistry studies at Moscow State University and finally got an MSc in software engineering 20 years later. He is now an author with over 50 books on software diagnostics, anomaly detection and analysis, memory forensics, root cause analysis and problem-solving, memory dump analysis, debugging, software trace and log analysis, reverse engineering, and malware analysis. Vostokov also founded the pattern-oriented software diagnostics discipline and Software Diagnostics Institute. In addition, he has over 30 years of experience in various industries in software architecture, design, development, and maintenance. He lives in Dublin, Ireland.

Table of Contents

Preface

Part 1: Software Engineering Basics

1

Defining Software Engineering

Technical requirements

What is computer science?

An introduction to software engineering

Planning

Design

Implementation

Testing

Deployment

Maintenance

Summary

Questions

Further reading and references

2

The Software Engineering Life Cycle

Technical requirements

Setting the scene for building software

Planning and requirements gathering

Creating a high-level and low-level design

High-level design

Low-level design

Developing software and implementation

Software testing and quality assurance

Software deployment and delivery

Maintaining software after deployment

Summary

Questions

Further reading

3

Roles in Software Engineering

The project manager

Defining the purpose and requirements

Identifying and connecting with key contributors

Creating an adaptable plan

The web developer

Frontend developers

Full stack developers

The backend software engineer

Building the backend with data

Developing the application programming interface

Improving performance

The mobile software engineer

The UI

Accessibility

The quality assurance software engineer

Automating test cases

Logging and documentation

The DevOps engineer

Summary

Questions

Further reading

Part 2: Introduction to Programming

4

Programming Languages and Introduction to C#

Technical requirements

Learning the purpose of programming languages

Defining common programming terminology

Building browser-based software with web development languages

Understanding multi-purpose backend languages

Development environments for mobile and smartphone software development

Building software with low-code/no-code platforms

Learning about .NET and C#

Popular uses for C#

Full stack web development with ASP.NET

Game development with Unity

Cross-platform development with .NET MAUI

Summary

Questions

Further reading

5

Writing Your First C# Program

Technical requirements

Introduction to software development tools

Operating system

Browser

Code editor

Software runtime and development kit

Command line

Source control

Installing .NET and tools for .NET development

Installing the .NET SDK and runtime

Installing Visual Studio Code

Configuring Visual Studio Code for C# development

Building a C# console application

Editing a console application in Visual Studio Code

Summary

Questions

Further reading

6

Data Types in C#

Technical requirements

Introduction to variables

Creating a variable

Introduction to the string data type

String concatenation

Operators and type safety

Introduction to numerical data types

Type casting

Updating variable values

Introduction to the Boolean data type

Introduction to the array data type

Summary

Questions

Further reading

7

Flow Control in C#

Technical requirements

Introduction to flow control

Introduction to if statements

Using if..else statements

Introduction to loops

Using a for loop

Using a for loop with arrays

Using a while loop

Introduction to methods

How to create a method

How to call a method

Using method parameters and arguments

How to return a value from a method

Solving the Fizz Buzz problem

Using else..if

Using the remainder operator

Fizz Buzz solution

Summary

Questions

Further reading

8

Introduction to Data Structures, Algorithms, and Pseudocode

Technical requirements

Planning with pseudocode

Exercise – FizzBuzz in pseudocode

The importance of data structures and algorithms

Introduction to the array data structure

Introduction to the selection sort algorithm

Introduction to the linear search algorithm

Introduction to the binary search algorithm

Summary

Questions

Further reading

9

Applying Algorithms in C#

Technical requirements

Writing a selection sort algorithm in C#

Writing a linear search algorithm in C#

Writing a binary search algorithm in C#

Building your own algorithms

Improving algorithms with refactoring

Summary

Questions

Further reading

10

Object-Oriented Programming

Technical requirements

Introduction to object-oriented programming

Understanding objects

Working with objects, classes, and types in C#

Introduction to inheritance

Introduction to encapsulation

Working with access modifiers in C#

Introduction to polymorphism

Static polymorphism

Dynamic polymorphism

Introduction to abstraction

Summary

Questions

Further reading

Part 3: Software Engineering – the Profession

11

Stories from Prominent Job Roles in Software Development

Technical requirements

Android software engineer

iOS software engineer

Generalist software engineer

Engineer #1

Engineer #2

C# software engineer

Frontend web developer

Data engineer

Salesforce software engineer

Summary

Further reading

12

Coding Best Practices

Technical requirements

Following naming guidelines

Naming identifiers

Casing and capitalization

Data should be nouns

Methods should be verbs

Following syntax consistency guidelines

Organizing lines of code

Indentation – tabs versus spaces, the historic debate

Implicitly typed variables

Following reusability guidelines

Method usage

Extensible classes

Following documentation guidelines

Creating documentation with comments in C#

Summary

Questions

Further reading

13

Tips and Tricks to Kickstart Your Software Engineering Career

Technical requirements

Preparing to enter the job market

Strengthening your skills for a role

Getting prepared for an entry-level software engineering role

Putting your portfolio together

Preparing a resume

Additional considerations beneficial for entering the job market

Seeking mentorship

Building your professional networking

Sharing your experiences

Preparing for the technical interview

Searching for software engineering roles

Applying for a role

What to do while waiting for an interview

Experiencing the interview process

Going through a tech screening

Doing the technical interview

Summary

Questions

Further reading

Assessments

Chapter 1 – Defining Software Engineering

Chapter 2 – The Software Engineering Life Cycle

Chapter 3 – Roles in Software Engineering

Chapter 4 – Programming Languages and Introduction to C#

Chapter 5 – Writing Your First C# Program

Chapter 6 – Data Types in C#

Chapter 7 – Flow Control in C#

Chapter 8 – Introduction to Data Structures, Algorithms, and Pseudocode

Chapter 9 – Applying Algorithms in C#

Chapter 10 – Object-Oriented Programming

Chapter 12 – Coding Best Practices

Chapter 13 – Tips and Tricks to Kickstart Your Software Engineering Career

Index

Other Books You May Enjoy

Part 1: Software Engineering Basics

This part introduces the discipline of software engineering as a subset of computer science and provides an overview of the common practices and roles in software engineering.

This part has the following chapters:

Chapter 1, Defining Software EngineeringChapter 2, The Software Engineering Life CycleChapter 3, Roles in Software Engineering

1

Defining Software Engineering

Think of one of your favorite or one of the most memorable types of software that you have used or use often, something that runs on your mobile phone, computer, browser, or game console. Imagine the first day the team that created it got together to get started on it; how did they go from a blank slate on day 1 to creating something you enjoy using? The team could have started coding at the beginning, but how would they know what they were building? There are many questions to answer before a team can get started on a software project. Software that serves the purpose it was intended for, for a long time, and without failure can be defined as high-quality. Building high-quality software consists of thoughtful decisions to make sure these requirements are met. The creators of your favorite software probably didn’t immediately put all their efforts into writing the code on that first day. Instead, they likely carefully planned how to create and deliver software that someone like you would enjoy. The effort that the team took to make quality software is a discipline within computer science called software engineering.

You may now be wondering how creating software relates to engineering. This chapter will answer this question by defining computer science and software engineering and exploring the relationship between the two. Next, we’ll dive further into software engineering by exploring common practices within the discipline.

This chapter will cover the following topics:

Learning what computer science isAn introduction to software engineeringReviewing why software engineering is so named by comparing it to another engineering disciplineThe six phases of the software engineering process and the challenges faced by software engineers in each phase

By the end of this chapter, you will have an understanding of the difference between computer science and software engineering and you’ll learn about the six phases of the software engineering process. You’ll also understand why building software is an engineered process and how software engineers contribute to a project before, during, and after writing code.

Technical requirements

There are no technical requirements for this chapter.

What is computer science?

Computer science is the study of computational problem solving, where computation refers to systems built for the purpose of making a calculation to some effect. These systems could be computers, their internal and/or external hardware that interacts with them, the operating system and software that runs on them, the programming languages used to build them, and the mathematical equations and proofs used to make them efficient.

While computer science is a broad topic that mostly refers to theory, it also serves as an umbrella term for a vast number of practices that require computation, including the practice of writing code, also known as programming. One such practice is data science, which happens to branch out into multiple practices as well. Data science involves the use of scientific methods, such as statistics, to extract knowledge from and understand the hidden relationships within a given set of data. This practice includes building a model, which is a system typically comprised of mathematical computations that will take data as an input and produce a result as an output. This is usually an algorithm, which is a special set of instructions that achieves a certain goal and is typically a computer program that the data scientist may create or use. The output of a model is used to gain actionable insights from the data and is often used to “teach” the model how to produce a more precise output.

The use of models feeds into another practice called machine learning, which focuses on creating models to uncover meaningful information and patterns from data to support rational decisions. Machine learning is a subset of artificial intelligence, where acquired knowledge, such as data, is applied and used to make rational decisions without human interaction. A common example of this is using applications that adopt speech-to-text, where the application will improve and become accustomed to a voice over time, making the conversion to text even more accurate. Artificial intelligence converts your spoken words into text, whereas machine learning uses a model to confirm and improve on words it may have gotten wrong, and data science uses your voice as the data to make sense of.

As you can see, practices within computer science can produce their own set of specialized terms. It’s common for professionals in the computer science field to have breadth in some of these areas and depth in others. For example, a data scientist may have experience building models and building AI applications. Computer science is a vast field of varied specializations but each path leads to computation for solving problems.

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.

Summary

We explored the field of software engineering, its relation to computer science, and how it expands beyond programming. Software engineering, like many applications of engineering, is a process that can be broken down into many phases. It’s these interconnected steps that allow the software to serve its intended purpose for a long time.

Careful planning ensures the project will reach a final point of agreed completion, which enables a detailed and accurate design, makes implementation easier, provides clear testing strategies, and allows for deployment with minimal setbacks and maintenance. It all works together! So, while software engineers will code in a software project, they will also expand their awareness, apply their domain knowledge to all of these phases, and make a concerted team effort to deliver quality software.

In the next chapter, we’ll leave behind the bridge analogy and focus solely on the software engineering process, diving deeper into the practices within these phases.

Questions

What differentiates computer science from software engineering?Name the six phases of the software engineering process.Identify the three problems that could arise in a software engineering project if a team skips the planning phase.How can the deployment stage of a software engineering project get complicated?This chapter drew similarities between civil engineering and bridge construction to software engineering. With this information, how can you justify that software engineering is engineering?

Further reading and references

Bridge Engineering Handbook: Construction and Maintenance (2nd edition), (2014), by W. Chen and L. Duan, CRC PressBeginning Software Engineering (1st edition), (2015), by R. Stephens, WroxBridge Engineering: Design, Rehabilitation, and Maintenance of Modern Highway Bridges, Fourth Edition (4th edition), (2017), J.J. Zhao and D.E. Tonias, McGraw HillMicrosoft. (2021, October 1). Defining Data Science. Data Science for Beginners. https://github.com/microsoft/Data-Science-For-Beginners/tree/main/1-Introduction/01-defining-data-science

2

The Software Engineering Life Cycle

The team that built your favorite application probably followed a process to deliver the first version of the software that was ready for someone like you to use. Have you ever sent a note to the development team, written in an open forum, or left a review asking for a particular thing to be added to an app? Imagine they saw what you wrote and decided that it was a good idea and should be added to the software. What happens when a team needs to deliver a second version of a software with more features?

As a start, most software teams hope to deliver software that achieves most of the main goals of its intended use, also known as the minimal viable product (MVP), as the first version of their software. Practices within software engineering are meant to produce quality software that can be used for a long time. Such software is adaptable to changes in technology, in staff, and, most importantly, over time. As a team approaches maintenance, the last step of the software engineering process, they may consider how the software will live on as there are many approaches to keeping a software maintained. This mostly depends on the team and its goals, the constraints of the software, and the available resources of a software project. Features add to the usability as well as the complexity of the software. Typically, they fall into the maintenance step because the software has already been delivered and is currently being used, which presents its own challenges.

Teams will typically plan, design, implement, and test new additions to the software to make sure changes integrate well with the entire product and enhance the experience for users. This is what makes the software engineering process a life cycle, where a team makes changes to the software to make it better. Believe it or not, your favorite apps and software all have bugs and improvements the team wants to work on! The software engineering process is only complete once the software is no longer being supported or maintained.

In this chapter, we will explore the steps of software engineering in further depth by detailing the goals, common practices, and indicators of success within the planning, design, implementation, testing, deployment, and maintenance steps.

This chapter will cover the following topics:

Setting the scene for building softwarePlanning and requirements gatheringCreating a high-level and low-level designDeveloping software and implementationSoftware testing and quality assuranceSoftware deployment and deliveryMaintaining software after deployment

By the end of this chapter, you will be familiar with the common practices within the software engineering process. You’ll also understand why building high-quality software can’t only be centered around coding.

Technical requirements

There are no technical requirements for this chapter.

Setting the scene for building software

To illustrate the subject matter in this chapter, let’s hear a story about a fictitious software application, an online bank for software engineers called Coder Bank. It was an idea created by a group of bankers who wanted to cater to the financial needs of programmers. These bankers, also known as stakeholders, have hired a large team to build Coder Bank. The software team of Coder Bank has some project managers who make sure the project is going smoothly. As well as this, they have software engineers to build Coder Bank who specialize in a variety of domains such as web development, mobile development, testing, and security.

Planning and requirements gathering

The planning phase is all about questions that can usually fit into these three buckets: what is needed and where can it be found, who is needed, and how many people are needed? Let’s see an example of how the Coder Bank team approaches the planning phase. The team has their first kickoff meeting into the planning phase with stakeholders, project managers, and a representative from the software team, an engineer with the highest seniority. The team has arrived to gather information on what the stakeholders hope to accomplish. This information is crucial for the project managers to estimate how long it will take to build Coder Bank. The project managers, Betty and Charles, begin the meeting by asking the stakeholders to describe what they’d like to create. Betty asks, “What is your vision for Coder Bank?”

Raina, one of the stakeholders, speaks to the group. “We imagine an app that coders can use and integrate into their daily lives. Our customer research suggests that programmers enjoy automating and customizing their software tools, and Coder Bank is an opportunity for them to do that with their finances.”

Betty and Charles exchange glances. Having worked together for a long time, they can read each other’s expressions very well. They think it’s a really strange concept but are not ones to judge. Charles types some loose notes on his laptop “banking for programmers, automation, and customization.” In addition to taking notes, everyone in the room has agreed to record the audio in meetings for reference.

Betty replies, “That’s really interesting, Raina. What features do you imagine programmers will want to see in Coder Bank?”

“Well, programmers want to see their balances in number systems other than decimal. Such as binary and hexadecimal.” The engineer, Ada, is stunned at Raina’s statement and can’t imagine seeing her bank account in 1s and 0s. She quietly thinks to herself, “Which programmers want that?”

After some more discussion, the stakeholders require Coder Bank to have an online bank that is compatible with modern browsers, as well as a mobile app that is available on most modern mobile devices. While this requirement appears to be simple enough, Charles and Betty exchange glances again; they notice it is quite loaded with more questions that need clarification. Project managers have to be perceptive when meeting with stakeholders and they need to know what the customer is actually trying to say. They’re tasked with gathering the requirements of a project and communicating them to the rest of the team; hence, they need clear and concise requirements so that everyone on the team understands what the stakeholders are saying. Usually, this leads to more questions.

Charles and Betty understand what they have to do: ask more questions to clarify what the stakeholders are asking for.

“What does “modern mobile devices” mean to you? How old can these devices be and what capabilities do they have?”

“Devices that have been released at least 5 years ago, have access to an app store, and have the ability to receive text messages and phone calls. It’s not a priority for Coder Bank to work on devices older than 5 years old.”

“5 years from when the app will be launched, is that correct?”

“Yes.”

“What about modern browsers?”

“The top five most popular browsers used today will support the app.”

“In the world? What about popular browsers used by programmers?“

“Oh yes, great catch. Ideally the top five most popular browsers used by programmers in North America, for now.”

“Are your expectations that the web version and mobile app be launched at the same time?”

“Yes.”

“OK, I think we have gotten a great start on gathering your needs, thank you. We’ll need to discuss this with the team, but we will see you next week to talk through our progress and gather more information. We’ll be in touch through email if we have any more questions.”

Betty and Charles go through the list of requirements, then order them by priority:

Mobile and web versions launched at the same time.Ability to use various number systems – Charles adds a note here: “how many do they expect to see?”Mobile apps that are compatible with devices that have been released 5 years ago or less.The web version works best with the top five browsers used by programmers in North America.