Software Engineering Glossary

Here are a few key concepts from software engineering expressed in glossary form.  These terms are

used in many fields, but the definitions we present here are narrowed to address the interests and concerns of software engineering.  This is not a complete list, but it touches on frequently-encountered ideas that we think are important.

Agile Development - Various development models that emphasize short turnaround time for changes, minimal overhead directed to internal documentation, and close contact with Stakeholders.  I’ve collected information about some of these models (e.g. “Notes on Scrum”) as other essays in the Software Engineering section.

Architecture - The large scale aspects of a software product’s design.  The architecture of a software product impacts every aspect of the product.  In particular, a product’s extensibility, reliability, ease-of-use, perceived quality, performance, size, etc., are all impacted by its architecture.  There are many types of software architecture, and it’s important to choose (or create) one that fits the needs of the product’s stakeholders.  Read the wikipedia article titled “Software Architecture” for a nice introduction to the subject.  

Here are a few examples of software architecture types:

1.Client-server model

2.Database-centric

3.Event-driven

4.Monolithic

5.Plugin

Capability Maturity Model (CMM) - a development model.  The CMM is a method for improving an Organization’s software Development Process.  CMM is actually a service mark owned my CMU.  See the CMM article on wikipedia for a more complete description, but the basic idea is that we measure an Organization’s product development effectiveness and use those measurements to improve quality and repeatability.

Charter - The primary roles, responsibilities, and deliverables of a software group.  Examples of charter could be coarse-grained, e.g. “build team,” “development,” “documentation,” “quality assurance,” etc.  Also, within these larger categories, we can establish fine-grained charters.  Examples of development charters include “utilities,” “OS layer,” “GUI,” “engine,” and so on.  Examples of quality assurance charters could include “system level test,” “regression test,” “integration test,” and so on.  

Ideally, Charter will be congruent with Organization, but over time a team’s activities may drift in response to business needs, talents, and interests.  This drift may cause issues with ownership, inter-team deliverables, and scheduling (among other things).  If a team’s charter is no longer reflected in the work being done, it’s a clue that it could be time for a reorganization of the larger Organization.  Members of a team should be able to articulate their team’s Charter.

Code - The implementation of a Detailed Design.  Code is generally written (expressed) in some kind of Implementation Language.  A very few examples include C, C++, Java, PHP, python.

Customers - The end-users of a software product.  Customers are important Stakeholders in a Software Ecosystem.  Those who purchase or pay for a license to use a software product are examples of external customers.  External customers can be consumers, other companies, government agencies, and so on.  We also have internal customers for our products.  These may be other teams within the company who use our product as part of a larger system that is delivered to external customers.  A team may also deliver software to internal customer for use exclusively within a company.

Detailed Design - A hierarchical description of the algorithms, data structures, objects, methods, file types, database elements, and other building blocks that go together to make up a software product.  Ideally, a Detailed Design starts at a very high level and proceeds by decomposition to a level just above Code.  Detailed Design may be (some say should be) implementation language agnostic.

Development Process - The steps a software organization follows to produce a deliverable product.  Ideally, the Development Process will minimize overhead while helping the company produce and deliver high quality products, at predictable cost according to a predetermined schedule.  We usually start with a very lightweight process, do a project and see how we do.  At the end of a project, we look at what went well and what did not, and we add, remove, or change elements of the development process in an attempt to make things better.

Functional Specification - The high level description of the externals of a software product.  By “externals” we mean what’s visible to the customer.  Ideally, Inbound Marketing, Applications Engineering (aka “Support”), QA, and Development all participate in the development of a Functional Specification.  A successful Functional Specification will guide the Development organization, allow QA to operate independently early in the project to produce test plans, allow the Documentation team to begin work, and so on.  In practice, we nearly always learn new things during a development project that cause us to require (or at least to want) changes in the Functional Specification.  This is one of the biggest reasons for adopting Agile Development models (as opposed to the formal “Waterfall Model”).  It’s important that the Functional Specification should stay above implementation details.

Interfaces - In the context of software product development, we consider two types of Interfaces: Inter-component and User.  Inter-component Interfaces (“ICI’s”) allow development teams to access the capabilities of each others’ work outputs (objects, routines, libraries, etc.).  User Interfaces allow end users, customers, to access the features of the software product.  Well defined, stable interfaces are one of the most important means we have available to us to decompose the work so that team members can operate in parallel.  I can scarcely over-estimate this point.

Integration Testing - Pair-wise testing of software components to verify that the output of one is valid, useful input for another.  In complex software systems, Integration Testing provides a useful intermediate step between Unit Testing and System Level Testing.  It’s simply a lot easier to figure out what is going on when you look at the interaction between two components rather than an arbitrarily large collection of components.

Organization - In this context, I refer to various collections of staff members, with well-defined Charters, who contribute to the delivery of a software product.  Teams are Organizations of individual contributors and their Team leader (or manager).  Departments are Organizations of Teams with related Charters.  A Division is an Organization of Departments.  A Company is an Organization of Divisions.

Personnel Management - This is the collection of activities related to hiring, retaining, organizing, coaching, developing, promoting, disciplining, or dismissal of employees.

Project Management - This is the collection of activities related to tracking a Software Development Project through the various stages in a Development Process and then, at the end of the Project, analyzing the performance of the Organization to see how the Process may be improved.

Regression Test - Regression testing is intended to verify that changes to a software product, either during development or maintenance phases, do not re-introduce defects or other reduction in quality.  In practice, we approach this ideal by maintaining a collection of tests that we run on our software prior to any release of the product.  We can have Regression Tests at the Unit, Integration, and System Levels.  Because Test collections (also called “test databases” or “test libraries”) usually grow over time, we usually try to automate our Regression Tests to the extent possible.  This is especially difficult for interactive (GUI-based) software products.

Software Ecosystem - The Software Ecosystem is the software product together with the market conditions, third-party partners, competitors, customers, etc., in which the software product exists.

Stakeholders - People or groups, inside and outside the company, which have an interest in a software product are Stakeholders.  Customers (internal and external) are Stakeholders.  Upper management is a Stakeholder.  Marketing (Inbound and Outbound) consists of Stakeholders.  One development Team can be a Stakeholder for another.  QA is a Stakeholder relative to Development.  Usually, the more Stakeholders you can get bought into product decisions, the more smoothly your product development effort goes.

System Level Testing - This is testing of the software product in the form seen by end-users (customers).

Unit Testing - Before trying to integrate software components into more complex modules, we test individual components of a software system.  Ideally, we begin Unit Testing at the atomic level.  This component-level testing is called “Unit Testing.”

Waterfall Model - The Waterfall Model is an early attempt at a Development Process.  In this model, we try to complete each step in the process before moving to the next.  Here are examples: Functional Specification, Detailed Design, Coding, Unit Test, Integration Test, System Level Test, Product Release.  Unfortunately, if we find a mistake at a given step, we may need to climb back up “the waterfall” to fix a problem in a previous step.  The farther back we have to climb to fix the problem, the more expensive the error.  For large or complex software products, the Waterfall Model usually breaks down.  Alternatives such as Spiral (aka “Iterative”) Models are an attempt to address this problem and provide better response to market conditions and Stakeholder needs.


© Michael C. Glaviano 2009 - 2016