The following is an overview of the Software Engineering Basics course of Viking Code School’s prep work. The course covered a wide range of topics, including the history of software engineering, the four step engineering problem solving approach, Agile Development, XP and SCRUM techniques, software testing, Test-Driven and Behavior Driven Development, pseudocoding, modularity, and best practices for software engineers.
The first assignment of the course involved following the SCRUM technique for the development of an e-commerce application, including writing stories, assigning acceptance criteria, and prioritizing them into epics. I learned how to use Pivotal Tracker, a web based Agile Development management program, for all of these tasks.
The next set of assignments for the course had me pseudocode three different programs, including a logic game. A fourth program was written with pseudocode for the operation of an elevator and broken down in modular components that each solved a particular problem while all working toward a common goal.
The final project of the course began with adding further stories to Pivotal Tracker for the e-commerce app for a pagination feature in the item results. Next, pseudocode was written for this feature using modules and testing of the code for various edge cases and variations was completed.
All of the above assignments and projects I completed can be viewed in previous posts.
The following are a series of questions that cover the main topics of the Software Engineering Basics course that I answered to review the material and test my knowledge.
The Principles of Software Engineering
How did software engineering actually begin?
Software engineering grew out of computer programmers needing to establish best practices to implement and produce software at scale commercially in the 1960s. This was during the “Software Crisis” and the term “software engineering” first emerged in 1968 at a conference to help solve these issues.
What processes were early software engineering techniques modeled after?
Early software engineering techniques were modeled after other engineering fields. Software engineering is the study and application of engineering to the design, development, and maintenance of software.
What macro-scale trends helped define the arc of software engineering over the past half-century?
The first high level programming language was Fortran by IBM in 1957, followed by Cobol in 1962. The rapid advance of technology, including Moore’s Law (the doubling of transistors in a microprocessor every 2 years), has continually guided the advancement of software engineering. In 1968, best practices were first established to help combat the “software crisis.” The internet was born in 1969, but webpages were not created until the early 1990s. In the 1970s, the use of modules began. The language C was created in 1973. The first interactive PC was manufactured in 1975, changing the way that software engineers worked – transitioning from time sharing of a computer main frame to individual computer workstations. In the 1980s, object-oriented programming began and the first graphical interfaces for operating systems.
What specific advances have led to rapid change in the discipline since the 1990s?
What characteristics of the web make modern day web software development more flexible than traditional software?
The web allows for easier collaboration, version control, and updates. Cloud computing, specifically, allows software to be updated uniformly without users having to re-download a newer version.
Why are software engineers more like architects than builders?
Engineers write source code, which acts as the instructions (or blueprint) for the compiler to build the actual machine code that is used by the computer to run the software. Software produced by engineers is therefore not the commodity itself, but the technical blueprints to build the commodity. This equates software engineers with architects or designers and not simply builders.
Why are software engineers actually very similar to visual or UX designers in some ways?
Software engineers must consider visual design and user experience throughout their work, especially before the production phase even begins. They must utilize good design practice and awareness of user needs and goals to write source code that is effective in achieving them.
What are the four steps of the high level engineering problem solving process?
- Understand the problem
- Plan a solution
- Carry out that plan
- Examine your results for accuracy
What are the specific things you need to do to implement each of these four steps, particularly the first two?
During the first phase of understanding the problem, the engineer must clarify the problem, model the system and break the problem into pieces (or modules), and research similar solutions. During the second phase of planning a solution, the work and modules must be prioritized and a strategy must be mapped out to work most efficiently and effectively toward the end product.
Why is thinking about the user so important for engineers?
Understanding the user experience that will be had by the software being created is essential for an engineer to work toward source code that reflects the goals of the project. Without this understanding and awareness, much time and effort can be wasted in writing code that does not meet this core aspect of software development.
What does KISS stand for and why do engineers love it?
KISS stands for Keep It Simple, Stupid. It promotes keeping source code focused on each particular task, all working toward the major goals of the project.
What does DRY stand for and why is it relevant to you?
DRY stands for Don’t Repeat Yourself. This principle tells engineers that they should always try to reuse code that solves for a certain problem. There is no point in writing source code multiple times to solve for the same solution, when the same code can be reused just as easily.
What is “You ain’t gonna need it?” (YAGNI)
YAGNI indicates that engineers should not try to write additional code for features and functionality that ultimately do not pertain to the primary goals of the project. Many times this leads to code that ends up not even being utilized. Additional features for later versions should be considered only after all of the primary objectives have been completed.
What do you think are the top 3 themes of good software engineering?
Based on this course, some of the top themes to consider as a software engineer are:
- Source code is like a blueprint and should be viewed as such. It acts as technical instruction to create the product.
- Engineers should always plan and think ahead about the product they are creating and how they will go about creating it, before any code is written.
- Simplicity in code is key. Source code should provide instruction in the most efficient and succinct manner possible. Bloat should be avoided and code compacted and re-utilized, while staying organized and readable to other engineers. If open source code exists that tackles a particular problem you need to solve, work with or use this code rather than re-inventing the wheel.
Why do we say that the engineering approach covers both Product and Process?
The product is what is actually being built – the software application or website that will function to help a user or solve a problem. The process is how that product is created using visual design, user experience considerations, and ultimately, source code instructions to build the product. Software engineering encompasses considerations of both as the product and process are very much interdependent on one another.
Introduction to Agile Development
What is Waterfall Development?
Waterfall is an older development method where each phase is verified and approved before moving to the next. The steps are as follows:
- Requirements Specification (or Understanding the Problem) – “Product Requirements Document”
- Design (or Planning your Solution) – architecture of software
- Construction/Implementation (or Executing your Solution) – build the software
- Testing (or Verifying your Results) – make sure it works before shipping
- Installation – install the product with the consumer or end user
- Maintenance – address issues that arise from actual use
Why does Waterfall seem to follow the core engineering problem solving steps?
Waterfall basically goes through each of the four problem solving steps of engineering, breaking them down and tackling one piece at a time before moving on to the next.
What is Waterfall good for?
The Waterfall model was first used when software was shipped on disks and had to be updated manually. It ensures that each step of the process is completed and that a functional product is being produced. Because of its structure, Waterfall can be long, bureaucratic, and costly, but is still useful for projects with high barriers to future change or serious safety or reliability needs. Software for space programs and critical health applications in the medical field are both areas in which the Waterfall model is still useful. In these situations, the cost and time to produce are mitigated by the fact that the software must function flawlessly upon release without failure.
What is Waterfall not good for?
The lengthy and costly nature of the Waterfall model can be detrimental to most modern software engineering projects. Engineers cannot always know everything about the users or customers before the release of software. Consumer-facing software must keep up with rapid demands of the market and implement fixes and solutions to problems, as well as additional features, as the need arises.
What is Agile Development?
Agile Development is an alternative approach to software engineering that allows for a much more rapid pace of production and flexibility and adaptability to changing user needs. The Agile Manifesto was written in 2001 and lays out the following principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile Development includes the following components:
- Expectation of changes in the project requirements
- Short development cycles
- Heavy client involvement throughout the project
- Frequetn re-evaluation of priorities and needs
- Working in small cross-functional teams
What is Agile good for?
Agile is suited for delivering software in a dynamic environment. It is more responsive to change than traditional approaches to software engineering. Agile promotes working with customers during the development process and updating after. It also promotes collaboration and adaptability, producing updates in short cycles of 1-2 weeks.
What is Agile not good for?
Again, Waterfall is more suited than Agile for software solutions that involve very high risk and demand accuracy and flawless performance upon immediate release. Software related to space programs and the medical field fall within these categories.
What is eXtreme Programming?
eXtreme Programming (XP) provides a framework to make developers more productive by focusing teams on producing code. It is less about project management and more about production.
What development techniques does XP advocate?
XP advocates for a release planning phase, utilizing user stories, embedding a user to provide real time feedback, building short iterations, and empowering the user to decide when enough features have been built. XP also uses Continuous Integration (CI) whereby branches are integrated with the main code base often rather than doing large code merges. Velocity is measured for a better estimate of how much longer a project will take. Pair programming is also used as a constant code review process.
What is SCRUM?
SCRUM is an Agile Development management technique. All work is broken down into user stories, prioritized, and placed into the product backlog. The backlog is broken into short iterations, called sprints, each sprint creating a discrete or deployable product. There is a SCRUM Master who oversees the project and the daily SCRUM meetings before work begins. The Product Owner is the person who advocates on behalf of the user and determines if finished stories are accepted or rejected for further development in relation to user needs.
What are the common principles of XP and SCRUM?
Both XP and SCRUM utilize user stories and, therefore, make users and their needs and goals an integral part of the development process. Both techniques are broken down into short iterations for efficient production.
What are User Stories?
User stories are brief statements in the language of the perspective user that guide the development process by defining what needs to be achieved for user experience and goals.
What is the format of a typical story?
A story contains who the user is (specifically), what the user’s goal is for the story, and why that goal is important to the user. The format they are written in usually follow the template of: As a [specific type of user], I want to [accomplish some specific goal], so I can [achieve some benefit].
What are Acceptance Criteria?
Acceptance criteria are attached to each user story and describe the specific tasks that need to be achieved in order for the story to be finished and accepted by the user.
What is a Burndown Chart and how is it useful?
A burndown chart is used in SCRUM to show how much progress has been made to finishing the project, how much work is yet to be done, and how the rate of work completed compares to the time remaining to work on the project. Each story is assigned a set of points based on their difficulty. Velocity is an average of the points completed over a certain time period to show the rate of progress.
What is Pivotal Tracker?
Privotal Tracker is a web based project management program that allows for the implementation of Agile Development within a team. Team members work together in organizing stories, prioritizing work, and marking work completed based on the acceptance criteria, all within Pivotal Tracker.
What are the 6 steps of implementing a typical new Agile project?
- Gather Requirements
- Stories Breakdown
- Story Estimation – points
- Prioritize the Stories – done by PO
- Build the Software
- Acceptance – PO decides whether code built satisfies the criteria
What is Software Testing?
Software testing is the process by which source code is checked to ensure that it functions properly and meets the goals of the project. It is used to help identify and resolve bugs in the code.
Why do we need automated testing?
Automated software testing involves a set of instructions that allows the computer to run through many or all possible variations of user input and variables to ensure that the software functions for many different scenarios.
What does a QA department do?
A Quality Assurance (QA) department usually runs manual checks through the software.
What are the general characteristics of automated testing software?
In automated software tests, the engineer specifies:
- How to prepare for the test
- Some action to take
- Expectation for what should happen afterward
What does Test Coverage mean?
Test coverage refers to how much of the code is actually tested. Test coverage can be broken down into several smaller coverage areas, such as:
- function coverage
- statement coverage
- branch coverage
- decision coverage
- condition coverage (booleans, true/false)
- state coverage
- parameter value coverage
What is Unit Testing?
Unit testing involves isolating a very specific unit of code to determine if it is functioning as expected.
What is Integration Testing?
Integration testing verifies the interfaces between units.
What is Acceptance Testing?
Acceptance testing is when the system is delivered to the user (or the Product Owner in Agile Development) for acceptance or rejection.
What general types of behavior should you test?
- Anything you would otherwise manually test.
- All critical paths the users will take, like signing in and using the app’s core functions.
- Anything that might reasonably break later.
- All critical methods that are run during the critical user paths.
- Any bugs you discovered along the way.
What is TDD?
Test-Driven Development (TDD) involves writing the test for a specific piece of code before actually writing the code.
What are the advantages of TDD?
TDD ensures that all source code is tested after it is written and never released without some level of functionality review. TDD also prevents scope creep, which refers to unchecked expansion of source code into features that go beyond the scope of the original goals, potentially wasting lots of time and effort.
What does “Red/Green/Refactor” mean?
Red/Green Refactor means writing a test for a piece of code that initially runs red (or negative) before the code is written, then should run green (or positive) after the source code is written properly.
What is BDD?
Behavior-Driven Development (BDD) is where business stakeholders work with developers to write high-level tests called scenarios, which are based on their desired behavior of the code.
How does BDD unite the ideas of User-Centered Design with TDD?
BDD involves the users goals into the testing phases by focusing tests on actual behavior sought by the users. BDD is essentially a more specific implementation of TDD.
Pseudocoding and Good Software Design
What is Pseudocoding?
Pseudocode is the process of writing out the logic of solutions to specific coding challenges using plain English. It is a good way to write out all of the code you will need to write before actually coding and is not very time consuming.
What is Whiteboarding?
Whiteboarding is just the use of a dry erase board to write out pseudocode quickly and brainstorm possible logical solutions to coding challenges before actually diving into the coding itself.
Why is pseudocoding useful for a beginner?
Pseudocoding helps a beginner learn the analytical and logical approaches to solving complex coding challenges before even involving the syntax of a programming language.
Why is pseudocoding useful for an experienced engineer?
Pseudocoding as an exercise in the production phase aids experienced engineers in creating a basic outline of what their source code will look like and the path they will take to reach it.
Why do we say that code follows “Sequence”?
Sequence is simply the order that a program runs, from top to bottom.
What is Flow Control?
The flow of the program can be diverted based on certain conditions. The use of IF and ELSE statements are examples of how the flow can be diverted.
What is Iteration?
Iteration refers to looping, whereby the sequence of a program will run through a loop until a condition is met. WHILE and DO are examples of statements used to create iterations in the sequence.
What is Modularity?
Modularity is the degree to which a system can be broken into its components and recombined.
How does modularity help us think about systems?
Modularity allows software to operate as a system of separate and mostly independent sub-tasks working together towards a common goal. Benefits of modularity include:
- you can use abstractions to avoid re-inventing code
- specialization of tasks so each component gets very good at its job
- can identify trouble areas more easily
- can add, remove, or modify specific parts without needing to change every other part
What is an Interface?
An interface allows the exchange of information between modules. Interfaces essentially form the connections between modules, allowing for a cohesive program while containing specific coding tasks to each module.
How can the real world be modeled as a modular system?
An example of modularity in the real world used in the course was that of organizing a child’s birthday party. Rather than one person organizing all of the components, different people (modules) are delegated certain tasks. For example, a baker might be tasked with baking the birthday cake, while another person may be tasked with creating invitations.
How specific should your modules be?
Each sub-task that solves for a particular problem should usually be assigned its own module.
How can you apply modules to your pseudocode “programs”?
Separate programs can be written for the different tasks of a pseudocode and called up by the main program to be run when the problem they solve needs to be addressed, sometimes initiated by a particular condition.
What is SOA?
Service-Oriented Architecture is modularity on a large scale. Independent sub sections communicate with interfaces called Application Programming Interfaces (APIs).
How was Amazon’s transition to using SOA an example of high level modularity at work?
Amazon transitioned to assigning each group of tasks its own modules, such as the shopping cart, or payment processing.
Why was it important for Amazon to make this transition?
By making this transition, Amazon can use modules within multiple applications and expand their reach in the market.
What are the three characteristics of good modules?
- Low Coupling – minimally dependent on each other
- High Cohesion – focused on achieving overall goal
- High Encapsulation – shouldn’t reveal their implementation details to anyone else
What is Coupling?
Coupling is the degree to which the components of a system rely on each other.
How much coupling should good modules have?
Good modules should have a minimal amount of coupling, so that they can function more independently of each other.
What is Cohesion?
Cohesion is how closely the components of a system are working towards a common goal.
How much cohesion should good systems of modules have?
There should be very high cohesion in a good module system. Although each module performs a certain tasks, all of the modules should be communicating to work together toward the software’s primary goals.
What is Encapsulation?
Encapsulation is the extent to which the implementation details are hidden.
How much encapsulation should good modules have?
Each module should be encapsulated. Another module should not concern itself with how another module functions. In other words, the proper execution of source code in one module should not be dependent on that of another.
What are the SOLID principles good for?
The SOLID principles are good for actually implementing the three good characteristics of modules into engineering software.
What are each of the SOLID principles?
- Single Responsibility Principle (SRP) – modules should only serve one purpose
- Open/Closed Principle (OCP) – modules should be open for extension, but closed to modification
- Liskov Substitution Principle (LSP) modules that inherit from a parent should not alter any of that parent’s functionality
- Interface Segregation Principle (ISP) – each user of a module should access it via specialized interface that only requires them to provide the minimal amount of info
- Dependency Inversion Principle (DIP) – higher level modules should dictate the implementation details of lower level modules, not the other way around