A Concise Software Engineering Beginner’s Guide for Business Tech Enthusiasts

This content originally appeared on DEV Community and was authored by ᗰṳhumuzå ₱ɨuṩ

INTRODUCTION

Back in the 1950s, when the dependency on computers increased, the software needed to manage them also grew and thus Software Engineering/Development became a necessity for businesses and users all over the world.

“Our civilization depends critically on software, and we have a dangerously low degree of professionalism in the computer fields.” — Bjarne Stroustrup

In the last 63 years (since 1960), the amount of software produced and used by modern society increased greatly necessitating a need to set principles, objectives, and standards, when estimating the necessary resources (like cost and human capital) for developing quality software to meet customer requirements and manage their expectations.

Today, it is hard to imagine an area of human activity or business endeavour where software is not used, considering most of the devices used in workplaces, households and the large computer infrastructures operating in governmental organizations or large corporations are powered by software.

This publication tries to break down most of the software development-related concepts, practices, and topics that anyone in the business of Software Engineering as well as enthusiasts should know about. Most of which i wish i know when starting out.

DISCLAIMER NOTE

As an Informational and Educational resource inspired by my Software Engineering research and learning summary notes, this documentation although not deeply exhaustive in the discipline of Software Engineering seeks to "softly spolight" the discipline and basics of Software Engineering, Software development definitions, concepts, approaches, processes and practices that software engineering begineers, business technologists, software enthusiasts, and thought leaders can understand and even use as a launchpad for even better learning.

WHAT IS SOFTWARE ENGINEERING

Software Engineering is the art and science of applying different software development methods, involving teamwork, following industry standards and best practices, with innovative creativity and a great deal of balancing time, cost and scope (the triple constraint) to efficiently create extensible, sustainable programs/software products that solve problems people care about.

IEEE defines software engineering as: _The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software.

It is an engineering branch associated with the development of efficient and reliable software product (Software Development)_ using well-defined scientific principles, methods and procedures. And to some, a technical discipline or approach that applies computer science and engineering concepts to design, develop, test and maintain quality, reliable, usable, and dependable software.

The professional practice of Software Engineering requires technical proficiency and a high code of ethics, which all enthusiasts of Software Engineering should embody. The 10 commandments of Egoless programming by inspired by the book, The Psychology of Computer Programming, first released in the 1970s, where Jerry Weinberg coined the term “egoless programming” partly speaks to this effect.

• The term Software Engineering is composed of two words, Software and Engineering, where Software being more than just a program is an executable code, which serves some computational purpose and Engineering on the other hand being all about developing products, using well-defined, scientific principles and methods.

• Software is considered to be a collection of executable programming code, algorithms, associated libraries and documentations which when made (Software Development) for a specific requirement ( typically in the context of Software Engineering) is called a Software Product.

A Brief History Of Software Engineering

As computers became larger and more powerful, the task of creating equally large and powerful software (computer programs) also became gigantic, and the field struggled to keep up, leading to the situation referred to today as “The Software Crisis” a term coined together by attendees at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany.

Software Crisis was the term used in the early days of computing science referring to the difficulty coders and programmers faced writing efficient computer programs (Software) and developing large, complex systems within the required time due to the rapid increase in computer power in the 1960s (through the 1970s -80s).

During the Software Crisis period, the increasing complexity of the software, along with the inadequacy of the existing software development and management methods, caused many large-scale software development projects to fail leading to many software related problems arising like software projects running over budget and schedule, some causing property damage and a few leading to loss of life.

This ended up costing more money and taking more time to develop Software than was estimated, with the final product often being inefficient and low quality, if, and when, finished at all.

In his 1972 Turing Award lecture, Edsger Dijkstra made a reference to this same problem.

“But I called this a minor cause; the major cause is... that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming had become an equally gigantic problem.” –-Edsger Dijkstra, The Humble Programmers (1972)

By identifying the many problems of software development in the wake of this Software Crisis, there was a proposition for the adoption of an engineering approach to developing software which is how Software Engineering was conceptualized, emerging as a new engineering discipline concerned with all aspects associated with the theories, concepts, principles, techniques, standards, and tools that could be used for developing high-quality and reliable professional software.

The term "Software Engineering", also first used in the late 1950s and early 1960s, where "The Concept of Software Engineering" was mentioned while discussing this Software Crisis at the two The NATO Software Engineering Conferences in 1968 and 1969, sponsored by The NATO Science Committee, generally believed to have marked the official start of the 'Software Engineering' profession and giving the field its initial boost at these conferences

Software Engineering emphasizes a systematic, disciplined approach to the development of software that typically applies to the construction of large software systems (or products) involving numerous Software Development and engineering teams.

Today, Software Development and Engineering teams will typically fall under Front-end, Back-end or full-stack development, as is with Developers, Engineers and sometimes Programmers.

Defining Programming

The terms "Programming" and "Software Engineering" have been used interchangeably in the software engineering indutry for quite some time, even though each term has a different empahsis and different implications depending on context. Back then university students would study computer science and get jobs writing code as "programmers", but today between univesity courses ranging from computer science, software engineering, and Information Technology to certificate courses, bootcamps and technical training in Programinig fundamentals, web development and Programming language specific short courses, anyone can become a Software Engineer or Software Developer.

Programming requires logical thinking and the ability to break down complex problems into smaller, more manageable parts. Programmers use logic to develop algorithms, which are step-by-step procedures for solving problems. These algorithms must be logical and accurate, with each step leading logically to the next.

It is believed that, the history of programming dates back to the early 19th century when mathematician Ada Lovelace created an algorithm for Charles Babbage's Analytical Engine, which is considered the first computer. However, the first actual programming language was developed in the 1950s, called FORTRAN (Formula Translation) used for scientific and engineering calculations.

Think of Software Engineering as a systematic collection of past experience arranged in form of methodologies and guidelines used to develop amazing software products and Programming as the ability to provide a computer with a set of instructions in a particular language that it can understand and perform operations and tasks on. It's a creative skill for which, the more you practise and learn the better you become.

Generally Programming Languages are compiled before execution and the source code is converted into machine code that can be directly executed by the computer's processor. Programming languages and scripting languages are both used to develop applications, but they differ in their execution methods as Scripting Languages are typically interpreted during runtime and the source code is executed line by line by an interpreter or a runtime environment, without the need for explicit compilation.

Types of Programming Languages

Programming languages can be broadly classified into three categories:

• Low-Level Languages: These languages are closer to the machine language and are used to write operating systems, device drivers, and firmware. Examples include Assembly Language, C, and C++.

• High-Level Languages: These languages are easier to learn and use than low-level languages. They are used to write applications, games, and websites. Examples include Java, Python, and Ruby.

• Scripting Languages: These languages are used to automate repetitive tasks, such as web development and system administration. Examples include Perl, PHP, Javascript, Python, and Ruby.

Programming methods

These are Structured and Functional Programming Methods

Structured Programming

Structured Programming states how the program shall be coded.

In the process of coding, the lines of code keep multiplying, thus, size of the software increases. Gradually, it becomes next to impossible to remember the flow of program. If one forgets how software and its underlying programs, files, procedures are constructed it then becomes very difficult to share, debug and modify the program. The solution to this is structured programming. It encourages the developer to use subroutines and loops instead of using simple jumps in the code, thereby bringing clarity in the code and improving its efficiency Structured programming also helps programmer to reduce coding time and organize code properly.

In Structured programming;-

• A software is always made to perform some rational work. This rational work is known as problem in the software parlance. Thus it is very important that we understand how to solve the problem. Under top-down analysis, the problem is broken down into small pieces where each one has some significance. Each problem is individually solved and steps are clearly stated about how to solve the problem.

• While programming, the code is broken down into smaller group of instructions. These groups are known as modules, subprograms or subroutines. Modular programming based on the understanding of top-down analysis. It discourages jumps using ‘goto’ statements in the program, which often makes the program flow non- traceable. Jumps are prohibited and modular format is encouraged in structured programming.

• In reference with top-down analysis, structured coding sub-divides the modules into further smaller units of code in the order of their execution. Structured programming uses control structure, which controls the flow of the program, whereas structured coding uses control structure to organize its instructions in definable patterns.

Functional Programming

Functional programming is style of programming language, which uses the concepts of mathematical functions. A function in mathematics should always produce the same result on receiving the same argument. In procedural languages, the flow of the program runs through procedures, i.e. the control of program is transferred to the called procedure. While control flow is transferring from one procedure to another, the program changes its state.

In procedural programming, it is possible for a procedure to produce different results when it is called with the same argument, as the program itself can be in different state while calling it. This is a property as well as a drawback of procedural programming, in which the sequence or timing of the procedure execution becomes important.

Functional programming provides means of computation as mathematical functions, which produces results irrespective of program state. This makes it possible to predict the behavior of the program.

Functional programming uses the following concepts:

• First class and High-order functions - These functions have capability to accept another function as argument or they return other functions as results.

• Pure functions - These functions do not include destructive updates, that is, they do not affect any I/O or memory and if they are not in use, they can easily be removed without hampering the rest of the program.

• Recursion - Recursion is a programming technique where a function calls itself and repeats the program code in it unless some pre-defined condition matches. Recursion is the way of creating loops in functional programming.

• Strict evaluation - It is a method of evaluating the expression passed to a function as an argument. Functional programming has two types of evaluation methods, strict (eager) or non-strict (lazy). Strict evaluation always evaluates the expression before invoking the function. Non-strict evaluation does not evaluate the expression unless it is needed.

• λ-calculus - Most functional programming languages use λ-calculus as their type systems. λ-expressions are executed by evaluating them as they occur.

Common Lisp, Scala, Haskell, Erlang and F# are some examples of functional programming languages.

Programming/Coding style

It can become tedious or even impossible, for multiple Software Engineers/Software Developers/Programmers in a software project, to work on a software product/ program code or a codebase written by some other Software Engineer/ Software Developer, if they do not follow some standard programming style to code the program.

A Programming style is set of coding rules followed by all the Software Engineers/Software Developers/Programmers to write the code.

An appropriate programming style includes using function and variable names relevant to the intended task, using well-placed indentation, commenting code for the convenience of reader and overall presentation of code which makes the program code readable and understandable by all, which in turn makes debugging and error solving easier. Also, proper coding style helps ease the documentation and updation.

Programming/Coding Guidelines

Coding style Practices vary with different individuals, teams, organizations, operating systems and even the language of coding itself.

Some general coding elements defined under an organisation/team's coding guidelines can be;-

• Naming conventions - This section defines how to name functions, variables, constants and global variables.
• Indenting - This is the space left at the beginning of line, usually 2-8 whitespace or single tab.
• Whitespace - It is generally omitted at the end of line.
• Operators - Defines the rules of writing mathematical, assignment and logical operators. For example, assignment operator = should have space before and after it, as in x = 2.
• Control Structures - The rules of writing if-then-else, case-switch, while- until and for control flow statements solely and in nested fashion.
• Line length and wrapping - Defines how many characters should be there in one line, mostly a line is 80 characters long. Wrapping defines how a line should be wrapped, if is too long.
• Functions - This defines how functions should be declared and invoked, with and without parameters.
• Variables - This mentions how variables of different data types are declared and defined.
• Comments - This is one of the important coding components, as the comments included in the code describe what the code actually does and all other associated descriptions. This section also helps creating help documentations for other developers.

DEFINING SOFTWARE

Software is a set of computer programs that enable a computer system (hardware) to perform specific tasks. Software runs on hardware which are the tangible components, or delivery systems that store and run the written instructions provided by the software to perform the actual work.

Software products vs. other products

There are mainly two differences between software products and any other type of products.

• Software is intangible in nature and therefore difficult to control. It is very difficult to control and manage anything that is not seen. In contrast, any other industries such as car manufacturing industries where one can see a product being developed through various stages such as fitting engine, fitting doors, etc. Therefore, it is easy to accurately determine how much work has been completed and to estimate how much more time will it take.

• During software development, the only raw material consumed is data. In contrast, large quantities of raw materials are consumed during the development of any other product.

Characteristics of Software

• Software is developed or engineered and not manufactured.
• Software doesn’t wear out but it does require enhancements or scaling depending on how, where, and for whom it’s being developed.
• Software should be applicable, maintainable, scalable, reliable, efficient, and well documented at the very least to be considered quality when handing it over to the client.
• Software and especially good software is operational, transitional, and maintainable.
• Software can also have some restrictions e.g., legal compliances, industry standards, Cost, talent hiring, and time to market among others that need to be considered.

High-quality software is often characterized with being highly dependable, safe, secure, reliability, efficient, usable, accessible, and maintainable. It is not feasible to achieve all these in any one software product but achieving some is possible.

A software product can be judged by what it offers and how well it can be used and should therefore be Operational, Transitional and Maintenable at the very least.

Well-engineered and crafted software is expected to have the following characteristics:

• Operational:- which tells us how well software works in operations, often measured on factors like;- Budget, Usability, Efficiency, Correctness, Functionality, Dependability, Security, and Safety.

• Transitional:- An important aspect especiaally when the software product is being moved from one platform to another often measured on factors like;- Portability, Interoperability, Reusability,and Adaptability.

• Maintenable:- An aspect of how well a software's capability to maintain itself in the ever- changing environment often measured or assessed on factors like:- Modularity, Maintainability, Flexibility, and Scalability.

Software Requirements

A software requirement is a rule the software must conform to: What it must do, how well it must do what it does, and within what constraints or limitations to keep the development team on track, working together toward creating and delivering software projects that client (or users) want and avoiding software project failures.

Good requirements are considered to be:

• Correct because what they say is right.
• Consistent because they don't contradict each other.
• Unambiguous because there is only one way to interpret them.
• Complete because they cover all that’s important.
• Relevant because they meet a stakeholder need.
• Testable because there’s a way to figure out if they’re satisfied.
• Traceable because it’s possible to figure out where they came from.

And requirements that fail to have these characteristics can lead software engineers/developers to develop features for a software product nobody needs, wasting time and other resources and potentially jeopardizing the software project.

Requirements can come from any stakeholder, including clients, managers, users, governments, developers of the software your software product will integrate with, your development team, and yourself.

Three of the most important, distinct, and universal categories of stakeholders include:

• Clients: The people who request the software and have most of the authority over its requirements (e.g., because they are paying for it).
• Users: The people who will use the software.
• Developers: The people who will make the software, including those who manage the software engineers.

Types of Software Requirements

There are two types of requirements namely- the Functional requirements that describe what functionalities a software product should have to pass acceptance criteria and the Non-Functional requirements that describe how well the software product is expected to perform.

Functional Requirements

Functional requirements specify the desired functionality of software (e.g., if I click the Log In button, the Login page appears) often organized in functional areas with each functional area group's requirements describing a homogeneous set of functions. For instance, an “accounting function” section in a requirements document can describing all requirements pertaining to accounting functions of a software product.

They answer the question, “What should the software do?” and can be specified with the help of User stories and Use cases.

User Stories

A User Story is short description of a software feature from the perspective of fulfilling a user need For example, "As a I can , so that ". Tasks, priorities, time/cost estimates, and acceptance criteria may be associated with a user story.

They describe a small piece of the software’s functionality in simple, straightforward and easy to read sentences that even non-technical people (e.g., users, clients, other stakeholders) can understand.

User stories have a title and are commonly written using this format:

As a ⟨USER⟩, I want ⟨TO BE ABLE TO LOG INTO THE SYSTEM AS AN EXISTING USER OR REGISTER AS A NEW USER ⟩ so that I ⟨CHECK MY BANK BALANCE AND ALSO MAKE A TRANSACTION⟩.

These short sentences in a user story can be written on sticky notes and placed on a wall or whiteboard or can also be typed into task and project management systems like trello, Jira, Asana, etc.

Features or capabilities are negotiated with the client and then added to the user story as acceptance criteria. Acceptance criteria say what must be true about the functionality specified by the user story in order for the user story to be considered done (i.e., establishing the Definition of Done for the user story). It uses the Given ...when ...then ... format with “and”’s as optional parts of the format.

Anyone on the team—or any project stakeholder—might come up with user stories. Once the user stories are initially defined, they can be used to start a conversation with the client and others on the team. Clients can guide you on setting priorities for user stories. This conversation is also a good time to get more details about the user stories, which should be added to the card.

Characteristics of good user stories (INVEST):

• I Independent: Doesn’t depend on other user stories.
• N Negotiable: Can be changed during development.
• V Valuable: Fulfills a user need.
• E Estimable: Can be given a time estimate.
• S Small: Can fit into a single development period (e.g., a 2- week Sprint)
• T Testable: Possible to determine it’s done.

Use Cases

Use cases are a more formal method of specifying functional require- ments. They are structured descriptions of what a system is required to do when a user interacts with it.
Use cases are not specific to a particular software process model (e.g., Agile, Waterfall, Spiral) or environment. Instead, like much of what you will encounter in this book, they are a well-known method software teams can choose to use (and many do), or not.

A good Use case should have:

• Name: A short title for the use case that often starts with a verb (e.g., Schedule weekly wellness check). Briefly states the user objective the use case will be describing.

• Actors: The user or users (human / non-human / computer) that are interacting with the software (e.g., Medical staff). Sometimes, the actor is implied through the flow of events (e.g., Shopper selects the calendar icon). Other times, the actor is stated separately from the flow of events (e.g., Actor: Shopper).

• Flow of events (a.k.a. “basic course of action” or “success scenario”): Sequence of actions describing the interaction be- tween the actor and the software.

Additional Parts included in a Use Case:

• Identifier: A unique way of referring to the use case (e.g., UC-002)
• Pre-conditions: What must be true before the flow (e.g., The shopper has added at least one product to their shopping cart.)
• Post-conditions: What must be true after the flow (e.g., The shopper received an order confirmation email.)
• Business relevance: Justification for why the use case exists.
• Dependencies: Other use cases the use case relies on. This unique identifier is handy for this part.
• Extensions: Contingencies, alternate routes, and branches to other use cases.
• Priorities: The importance of the use case.
• Non-functional requirements: How well the software must perform during the flow.

The correct amount of detail to give a use case is the minimum amount to adequately describe what you’re trying to communicate.

Non-Functional Requirements

Nonfunctional requirements on the other hand specify qualities the software should have (e.g., usable, portable, modular, etc.) organized in groups of usability, reliability, performance, and supportability answering the questions, “How well should the software perform?” and “What limits or constraints is the software subject to?”

• Quality attributes are characteristics of software used to describe how good it is. They are not the same as a non-functional requirements but rather, good for specifying non-functional requirement and labelling what a non-functional requirements is about.

Each quality attribute can be converted to a scale. For example, the lowest value on a reliability scale could be “the function succeeds 0% of the time” and 100% would of course be the opposite pole. Given this scale, we can specify a non-functional requirement by defining a performance threshold:

The function must have high reliability (succeeds >99% of the time).

When you select quality attributes for your software, you are prioritizing what qualities matter most to you / your team / the software project. Ideally, your team would keep these quality attributes (and the cor- responding non-functional requirements) in mind for the duration of the software project; If the software is not meeting the non-functional require- ments, either the software or the threshold of acceptability needs to change.

Examples of quality attributes:

• Reliability: How often does function X succeed?
• Efficiency: How many resources does the software need?
• Integrity: How frequently does the software have errors that require a restart?
• Memorability: How many times must users learn a function before they no longer need documentation?
• Flexibility: How many ways can the software be used?
• Interoperability: How well can the software integrate with other software?
• Reusability:To what extent can the code be used to solve other problems without being modified?

Why Requirements Matter

Deciding what software to make, and doing so successfully, is a complex process influenced by human factors affecting all involved. So how does one elicit requirements? By having conversations or otherwise collecting information from stakeholders. The amount of stakeholder communication can vary by project, project type, the software process model being used, and other factors. This is further explained in the SDLC requirements gathering phase.

The design and implementation of software should, ideally, follow from the requirements. Here are some ways requirements are helpful and reasons they are important:

• When developers aren’t given requirements, they might prior- itize functionality they personally think is important or fun to implement—but what developers want to implement might not make the project successful.
• When multiple developers are working on the same code, re- quirements can help them stay in sync with one another and have the same goal. Without requirements, time, effort, and money can be wasted implementing conflicting code.
• Whenrequirementsaren’tspecified,it’seasierforprojectstake- holders (e.g., clients, partners, investors, consultants, manage- ment, etc.) to influence the project toward satisfying their own (possibly fleeting) wants or needs. This can result in the project drifting away from what it was originally intended to do—and can lead to project failure.
• Requirements are helpful for communicating about software with stakeholders, keeping track of everything that needs to get done, and helping you and the client decide what really needs to get done (clients sometimes don’t know what they
really need).

SOFTWARE RELIABILITY

Software Reliability can be defined as the probability of the software product working “correctly” as well as its trustworthiness or dependability.over a given period of time.

A software product that has a large number of defects is often considered to be unreliable and the reliability of this system will usually improve, among other things, if the number of defects in it is reduced. However, it's important to keep in mind that there is no simple relationship between the observed system reliability and the number of latent defects in the system.

Software products' failures can be classified into five different types is as follows:

• Transient: failures occur only for certain input values while invoking a function of the system.
• Permanent: failures occur for all input values while invoking a function of the system.
• Recoverable: When recoverable failures occur, the system recovers with or without operator intervention.
• Unrecoverable: In unrecoverable failures, the system may need to be restarted.
• Cosmetic: These classes of failures cause only minor irritations, and do not lead to incorrect results. An example of a cosmetic failure is the case where the mouse button has to be clicked twice instead of once to invoke a given function through the graphical user interface.

SOFTWARE QUALITY

It's important to note that software requirements are the foundation/benchmark from which quality is measured and specified requirements and set industry standards define the development criteria that guide the manner in which software is developed/engineered.

Therefore, Software quality is the process of conforming to explicitly stated functional and performance requirements, documented development standards, and implicit characteristics when developing software products.

It measures how well the software is designed (quality of design), and conforms to that design (quality of conformance), often described as the "fitness for purpose" of a piece of software and its desirable attributes.

If at any one-time software does not meet the set requirements or standards then its quality is put into question.

The quality of a software product can be ascertained through several quality factors such as:

• Portability: A software product is said to be portable, if it can be easily made to work in different operating system environments, in different machines, with other software products, etc.
• Usability: A software product has good usability, if different categories of users (i.e. both expert and novice users) can easily invoke the functions of the product.
• Reusability: A software product has good reusability, if different modules of the product can easily be reused to develop new products.
• Correctness: A software product is correct, if different requirements as specified in the SRS document have been correctly implemented.
• Maintainability: A software product is maintainable, if errors can be easily corrected as and when they show up, new functions can be easily added to the product, and the functionalities of the product can be easily modified, etc.

The Concept Of Software Quality

Is simply the degree of conformance to explicit or implicit requirements and expectations where the explicit and implicit expectations correspond to the two basics levels of software quality; -

• Functional — the product's compliance with functional (explicit) requirements and design specifications. This aspect focuses on the practical use of software, from the point of view of the user: its features, performance, ease of use, and absence of defects.
• Non-Functional — system's inner characteristics and architecture, i.e., structural (implicit) requirements. This includes code maintainability, understandability, efficiency, and security.

Note: Software requirements can be classified as functional or non-functional, therefore to deliver quality software, a lot of activities are done before, within and beyond the software development lifecycle.

Aspects Of Software Quality

The quality of software today really matters because the world as we know it today runs on software, businesses depend on it, standalone and mobile devices use it, automobiles now also rely on it, in fact it can be argued that without software modern civilization could possibly fall apart or hypothetically reset back to the stone age(will link the series RESET/REVOLUTION) which would be, for luck of a better word;- catastrophic and for this reason, low quality software just isn't acceptable anymore.

It's often good to quickly and effectively figure out what software quality is and isn't as there is no one single right way to think of what entails of quality software given its complexity.

The various components that define the idea of quality software can be grouped into functional, structural and process broad aspects.

1. Functional Quality which looks at how the software product functions and if it correctly does what it's meant to do for the users.

This means meeting the specified requirements set for the software based on a customer's needs, creating software that has few defects or errors in its codebase as zero defects is rather unrealistic, achieves good enough performance and ensure ease of learning and used.

1. Structural quality which refers to the features and characteristics of a software product e.g the codebase which in some cases can be hard o quantify but with the right tools possible.

The focus here is code testability(is the code organized enough to make testing easy), code maintainability(how easy is it to add new code or change existing code without introducing new bugs, errors of defects), code understandability(the complexity of the codebase and the learning curve for new developers or engineers being introduced to the code), code efficiency, and code security.

1. Process quality which looks at the degree/percentage to which a process in software development meets or exceeds the expectations and requirements of its customers or stakeholders. The quality of a development process can also affect the value seen or expected by users, development team and other members who have a stake in the quality of a software and its improvement.

Here the focus lies on meeting delivery dates, meeting budgets, and having a repeatable development process that reliably delivers quality software.

As far as software quality is concerned, most cases, users care about functional quality while development teams care about structural quality and stakeholders like sponsors care mostly about process quality. This is because everyone who interacts with a software product as any point o its lifecycle only and mostly cares about its quality aspect that impacts them the most in terms of needs, expectations and deliverables among other things.

Common Software Quality issues

The common software quality issues that Software Quality Assurance can help with include;-

• Functional defects: These are errors or bugs that prevent the software from performing its intended functions or meeting its requirements thus causing unexpected behaviors, crashes, incorrect outputs, or failures.

• Non-functional defects: These are issues that affect the quality attributes of the software, such as performance, reliability, security, usability, and maintainability causing system downtime, slow responses, data breaches, high maintenance costs, or user dissatisfaction.

• Code smells: These are indicators of poor design or implementation choices that can make the software hard to understand, modify, or reuse thus causing excessive complexity, code duplication, low cohesion, high coupling, or technical debt.

• Configuration issues: These are problems that arise from the mismatch or inconsistency between the software and its environment, such as hardware, operating system, network, or dependencies thus causing compatibility, interoperability, or deployment challenges.

• User feedback issues: These are problems that stem from the lack of or inadequate communication with the users or stakeholders of the software product thus causing miscommunication, mismatched expectations, unmet needs, or low satisfaction.

• Process issues: These are problems that result from the inefficiency or ineffectiveness of the software development processes thus causing delays, cost overruns, scope creep, or quality degradation.

How Quality is determined by SQA teams

There are two main approaches when it comes to quality assurance: the quality attributes approach and the defect management approach.

The Quality Attributes Approach in Software Quality assurance focuses on six main quality attributes as a measure of performance (measurable indicators) to determine the quality of a product. These are; -

• Reliability — which determines how the software performs under specific conditions to see how often it fails as well as figure out how quickly the system can reach its full operational level post-fail.
• Functionality — QA teams test the software's functions to see if they're appropriate or if they have been implemented correctly. QAs will also try to test the software to see how it interacts with other system components. Assess its data security and if it complies with the required laws and mandatory guidelines.
• Efficiency — should always be considered when designing software architecture which is why the QA team will try to determine if the development team followed good coding practices while developing the software product.
• Usability — It's important that users understand the software product's functions as easily as possible. If it takes too much effort or isn't possible then it doesn't pass the QA.
• Portability — simply ensures that every piece of the software product and the software as a whole has the ability to adapt to changes in its environment, it's easy to install, and system components within a specific environment are easy to replace.
• Maintainability — assess how easy it is to identify defects, root out the main cause of failure within the software product, and go on to fix it. QAs also look at how difficult modifying code will be in the event of a fault and the stability of the system's performance during the application of these changes.
• Performance – speed, response, scalability.
• Security – protected from threats.

The Defect management approach in Software Quality Assurance helps track defects which are assigned categories based on the rank of the severity of each defect.

The Difference Between an Error, a Defect, and a Failure?

The terminology around software anomalies can be confusing. It's important to distinguish the subtle differences between errors, defects and failures.

• An Error is a human mistake made by a QA engineer, software quality assurance analyst, tester or other stakeholder. An example is misunderstanding a requirement and coding to the wrong specification.

• A Defect is a flaw or imperfection inserted into a software work product due to an error. This could be a bug in the code or issues with other artifacts like requirements. Defects get inserted when errors are made.

• A Failure represents the termination of the software's ability to function as intended. Failures occur when the software executing encounters a defect. Failures are user-facing; the user experiences the software failing in some unintended way.

What are the possible software failures that necessitate SQA?

Although software failures often result from software programming errors, they do not always result from the incompetency or mistakes of the Software Engineer/Developer.

Sometimes software failures may be as trivial as;-

• miscommunication within the project team,
• module integration failures,
• physical equipment failure,
• downtimes,
• poor documentation,
• sudden updates on APIs or third-party software being used for the project,
• change in software engineering team availability or skill-set,
• or changes in the final client's requirements.

It's also important to note that there are many definitions of software failures — errors, bugs, inconsistencies, incidents or defects, etc. Therefore, investing in good, consistent Software Quality Assurance is key.

An error leads to the insertion of a defect, which in turn can lead to observable software failures upon execution. Engineers aim to prevent errors and remove defects before they turn into failures.

Measuring and Maintaining Software Quality?

The basic rule of thumb stands that software can never be 100% bug, defect or error free but by applying software quality assurance, these issues can be controlled or mitigated.

Software quality measurement provides data to help assess current quality levels and drive improvement initiatives. It is easier to prevent issues than getting rid of them later.

Common measures include:

• Error density – errors per size of work product (requirements, design, code). Helps find problem areas.
• Defect density – defects per size of software. Used to gauge release readiness.
• Failure rate – mean time between failures. Tracks system reliability. Reliability models – estimate of future failures based on defect data. Predicts field quality.
• CoSQ – cost of software quality analysis. Justifies quality spending.
• Escaped defects – defects missed during development. Assesses testing effectiveness.

Measurements are used to monitor trends, compare benchmarks, predict failures, optimize testing, and prioritize improvements. Statistical analysis like Pareto charts helps interpret the data.

Often times, to figure out if software is ready for release, checks like;-

• Does the software do what it's meant to do based on set requirements or does it still do everything it used to do before the change among other questions are explored by the software teams, which has now become the job of QA teams. QA team in this respect act as some sort of gate keepers between development of software and merging to production or release/launch of software.

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

SOFTWARE QUALITY MANAGEMENT(SQM)?

Software quality management refers to the oversight, control, and coordination of policies, procedures, activities, and people to achieve quality objectives. It's concerned with ensuring that the required level of quality is achieved in a software product.

Key SQM elements include:

• Quality planning which defines quality objectives, requirements, targets, and planning of quality assurance activities.
• Quality control, a Technique to measure quality characteristics, review work products, and find defects.
• Quality assurance which are the processes and audits to ensure compliance with procedures.
• Quality improvement which consists of defect analysis and process enhancements to improve quality.
• Resources are typically the infrastructure, tools, training that enable quality processes.
• Standards are the regulations, models, certifications that guide quality work.
• Culture which encompasses the values, behaviors that encourage quality mindset.

Quality management spans the entire software lifecycle and involves various roles like project managers, quality engineers, developers, testers, and customers. When done effectively, it provides confidence that software meets critical quality characteristics.

Software Quality Management focuses on Three principal concerns :

• At the organizational level, quality management is concerned with establishing a framework of organizational processes and standards that will lead to high-quality software.
• At the project level, quality management involves the application of specific quality processes and checking that these planned processes have been followed.
• At the project level, quality management is also concerned with establishing a quality plan for a project. The quality plan should set out the quality goals for the project and define what processes and standards are to be used.

While Software Quality management is particularly important for large, complex systems with quality documentation(a record of progress supporting continuity of development as the development team changes) quality management for smaller systems, requires less documentation thus putting more focus on establishing a quality culture.

Quality Assurance(QA), QC, and Testing

Although these three terms are often used interchangeably, they refer to slightly different aspects of Software Quality Management and use different approaches to delivering a software product of the best possible quality, both structurally and functionally.

Quality Assurance

Quality Assurance (QA) is a method of preventing mistakes and defects in manufactured products and assuring no problems at delivery (release, launch, shipping or deployment) to customers or end-users. It is the administrative and procedural operation in a quality system to ensure that the products, services or activity's objectives and goals are met.

• QA includes the management of the quality of raw materials, assemblies, products, software and its processes in a quality system. It assists companies develop good/products and services that fulfill consumer/end-user's demands and expectations.

• A QA program's procedures assist with the avoidance of product faults before they occur.

A QA methodology is a structured approach in the form of a 4 phase PDCA (Plan-Do-Check-Act) Cycle or Demin's cycle where a team or organization Plans and creates process related objectives, followed by process development and testing (Do), followed by checking, monitoring, modifying these processes and finally coming up with necessary steps to enhance existing processes/procedures based on findings.

The purpose of QA is to set up adequate processes and introduce standards of quality to prevent or at best limit the number of errors/flaws (bugs) in a software product. QA focuses on processes with the aim of prevention done by the software team including the various stakeholders which is done throughout the software development process.

Is the optimizing of the development & testing processes in software development as well as selecting approaches to minimizing the number of errors.

Quality Assurance comprise of defining requirements, setting up deliverables and automating processes testing can use.

QA best Practises:

• Clear release criteria.
• Fixing is a priority
• Early automation.
• Dedicated security team.
• Responsibility for performance quality.
• Short feedback loops.

Elements of Effective QA with Agiles:

• Planning
• Documentation & Communication.
• Automation.
• Metrics.
• Continuous Improvement.

The Different Mehtods in which QA is carried out

These are, "but not limited to" methods, quality assurance utilizes to deliver quality software products or services;-

• Statistical process control(SPC) used to manage and regulate product manufacturing using statistical methods. Here teams use statistical techniques to control a process or production method which can also help to understand variations(discover internal issues, process behavior) to guide in finding necessary solutions and taking the most appropriate actions.

• Total Quality Management(TQM) which is a strategy of continuous improvement that uses quantitative approaches to assist product planning and performance assessment.

TQM depends on facts, data and analysis because the quality of a product is determined by the quality of the elements that make it up, some of which are sustainable and well controlled while others are not.

TQM is addressed by the processes handled using quality assurance. The software product's quality cannot be guaranteed if the specifications don't represent the genuine quality requirements.

Quality Control (QC)

Quality control(QC) is concerned with the managing and monitoring the output of the product or services. Through Quality Control the team verifies the product's compliance with the functional requirements.

QC makes sure that the software product corresponds to the requirements and specs before it is released and focuses on the product as a whole with the aim of verification done specifically by the team.

Software quality control techniques systematically find issues in products. Common techniques include;-

• Inspections, the formal, disciplined review of requirements, design, code, etc.
• Testing, the execution software to surface failures.
• Static analysis, the analyzing of code without executing it.
• Defect tracking, the recording of defects and tracking rework.
• Root cause analysis, the systematic finding of root causes of defects.

The data from these techniques helps characterize types of defects and their sources. This enables process changes to prevent recurrence in the future. Quality control provides essential feedback for driving continual improvement.

Testing

This activity aims at detecting and solving software errors/flaws(bugs) focusing on the source code and design of the software product usually done at the testing stage or along with the development process.

Note: Look at Quality Control as being a subset of quality assurance and testing as a subset of quality control.

Software Quality Management System

A quality management system (often referred to as quality system) is the principal methodology used by organizations to ensure that the products they develop have the desired quality.

A quality system consists of the following:

• Managerial Structure and Individual Responsibilities- A quality system is actually the responsibility of the organization as a whole. However, every organization has a separate quality department to perform several quality system activities. The quality system of an organization should have support of the top management. Without support for the quality system at a high level in a company, few members of staff will take the quality system seriously.

• Quality System Activities whicg encompass the following:

  • auditing of projects.
  • review of the quality system.
  • development of standards, procedures, and guidelines, etc.
  • production of reports for the top management summarizing the effectiveness of the quality system in the organization.

Evolution of Quality Management System

Quality systems have rapidly evolved over the last five decades. Prior to World War II, the usual method to produce quality products was to inspect the finished products to eliminate defective products. Since that time, quality systems of organizations have undergone through the (inspection ---> quality control ---> quality assurance ---> Total quality management(TQM)) stages of evolution .

The initial product inspection method gave way to quality control (QC). Quality control focuses not only on detecting the defective products and eliminating them but also on determining the causes behind the defects. Thus, quality control aims at correcting the causes of errors and not just rejecting the products. The next breakthrough in quality systems was the development of quality assurance principles.
The basic premise of modern quality assurance is that if an organization’s processes are good and are followed rigorously, then the products are bound to be of good quality. The modern quality paradigm ( product assurance ---> process assurance) includes guidance for recognizing, defining, analyzing, and improving the production process. Total quality management (TQM) advocates that the process followed by an organization must be continuously improved through process measurements. TQM goes a step further than quality assurance and aims at continuous process improvement. TQM goes beyond documenting processes to optimizing them through redesign. A term related to TQM is Business Process Reengineering (BPR). BPR aims at reengineering the way business is carried out in an organization. From the above discussion it can be stated that over the years the quality paradigm has shifted from product assurance to process assurance.

Some development best practices that ensure quality software, but not limited to, include;-

• static code analysis which examines the code without launching it and checks it according to defined coding standards.
• Peer to Peer (P2P) review with tool like git for version control and remote repository management where whenever a software product feature is completed, teammates or a team member can act as a code reviewer by accessing the code that has been pushed to a repository before merges or releases to producton.
• Reviews by senior developers or engineers who can help point out issues and areas of improvement to ensure quality software by junior software engineers and developers.

Software Quality Metrics

These mostly consist of;-

1. Product Quality Metrics
   Which regulate how a software product should perform from the client and server side including components such as reliability, performance, security, and maintainability among other things.

2. Code Quality Metrics
   Which checks if code being written for a software product is readable, well documented, testable and meets the set criteria for accessing code quality.
   The criteria can be;-

   • number of lines.
   • Static code analysis.
   • Software complexity.
   • Testability, portability, and reuseability

Among other criteria. This can depend of the development team, software development standards or coding culture adopted or nature of client needs/requirements.

Apart from the expertise of the software engineering team, the quality of software can be assured through a set of dedicated quality management activities such as Quality Management, quality assurance , quality control , and testing often done by SQA Teams e.g., testers & software quality Assurance Engineers among others. And this is where Software Quality Assurance comes in.

As an Integral part of the the software development lifecycle (SDLC), Software Quality Assurance(SQA)'s primary goal is to establish and maintain high-quality software throughout the software development life cycle (SDLC) and should in fact be involved in all phases of the development process, as much as possible from requirements gathering to deployment and maintenance.

Software Quality Standards & Compliance

A Software Engineering or Development standard may be defined as any standard, protocol, or similar document that outlines the rules and processes for the creation of software products.

It's common practise for companies that have been in the software business for a long time to have standards in place, although they will mostly be applicable to just that company which is where international/industry standards come in.

"The first standard to be published in the area of software engineering was a US military standard on software quality assurance in 1972."— Introduction to Software Engineering Standards,Francois Coallier,Prof. Motoei Azuma

Companies will have such documents on hand, intended for usage only by that business or organization's Software Engineering or Development team and will often get certifications to adhere to established standards, with ISO being the most prominent and well-known.

Standard compliance frequently requires the drafting of documentations and following them to the dot.

• For software engineering, ISO advises starting with a quality manual which helps in maintaining and improving the quality of a software life cycle, as well as track Software Engineering team production and client satisfaction.

• The next stage would be to put this quality manual that explains the software development process into action often times, with a framework or methodology in place to guide the team.

• Creating a hierarchy to aid in the improvement of overall process performance is a good practise to facilitate continuous improvement. All Software Quality processes should be designed, executed, measured, and improved, according to Industry standards e.g. _ISO Standard_ which is how Software Quality Assurance comes into the picture. ISO and IEEE are two of the most well-known international standards bodies whose standards enable software businesses globally effectively structure their operations by providing well-defined and effective guidelines and frameworks.

• An auditing process can also be in place to make sure standards, processes, procedures and set conditions are being followed as required. Engineering teams and even client project teams often carry out audits before, during and even after a Software Project Development Lifecyle. Auditing is a procedure in which an impartial agent or body examines the operations of the audited party (vendor project team, Software Engineering team, client project team) and issues a formal report on the results. As a requirement for thorough impartial and unbiased results, auditing must be carried out independently and in/or privately.

• To further improve Software Quality standards compliance, some software development projects include User Acceptance Tests where an acceptance criteria is followed to ensure software products to be handed off are to standards and follow set requirements before sign off.

There are various ISO certifications applicable to software companies on the ISO Website.

SOFTWARE QUALITY ASSURANCE (SQA)

Software Quality Assurance (SQA) facilitates the delivery of quality software products that meet and satisfy unique customer needs through applying a series of methods, approaches and best practices to ensure software quality.

it is a broad term in Software Engineering/Development that encompasses a wide range of tools, practices, activities and processes designed and applied to discover, validate, verify, monitor, evaluate, assess and improve processes to ensure that software products meet the desired quality standards, requirements, business objectives and exceed customer expectations.

It focuses on the reliability, quality management of Software

SQA is typically implemented by a dedicated team or department within an organization, responsible for overseeing the quality of Software Projects. Software engineering teams are the key to good software although its quality isn't always guaranteed right away.

SQA is an important part of the software development process because it helps to ensure that software products are:

• Reliable : Software products should be able to perform their intended functions consistently and accurately.
• Usable : Software products should be easy to learn and use, even for users with no prior experience with the software.
• Maintainable : Software products should be easy to modify and update to meet changing requirements.
• Secure : Software products should be protected from unauthorized access, modification, or destruction.

By and large, SQA is all about; — Business value addition, customer satisfaction, reliability, information confidentiality, cost-effectiveness, usability, performance, security,flexibility, improvement and guarantee of service delivery on Software projects as per set requirements and Standards.

In order esure the release of safe software that functions as expected, the concept of software quality was introduced.

SOFTWARE ARCHITECTURE

software architecture: Code de- sign. Can be shown at different levels of abstraction and detail.

High-level architecture is the software’s all-encompassing code design. When described with the diagram, a high-level architecture usually looks like a few to dozens of interconnected shapes with short labels, an abstraction that usually represents the entire codebase. In this chapter, we’ll use “architecture” interchangeably with “high- level architecture” (in other contexts, architecture can refer to code design at lower levels).

If you’re developing new software, you might get to choose the high-level architecture, or it may already be baked into a framework you’ve chosen. For example, many web application frameworks use the Model-View-Controller (MVC) architecture or variants. In the latter case, you have to learn MVC and how to work within it; The design decision is made for you.

Monolith Architecture

Monolith software is one or few pieces and cannot easily be divided into multiple independent components that run separately and are individually useful. What about when the client side, the server side, and the database are all separate, can that be a monolith? Yes. If the client-side part of the software will not start or is not useful without the database or server-side part of the software, that’s a monolith.
If you’re trying to think of an example of a monolith and noth- ing is coming to mind, that’s probably because this architecture is so common; it can arise without having to plan. Your first computer program was probably a small monolith. If you keep adding more code / files / classes / components, the software becomes a bigger monolith—unless you make a different design decision.

Microservice Architecture

Microservices are multiple pieces of software, each of which runs in a separate process and can be individually useful. The communication pipe within microservice architectures is sim- ple and the services themselves take care of translating and otherwise processing messages. For example, microservices commonly com- municate through a REST API, which allow these kinds of messages: GET, POST (create), PUT (update), or DELETE. The contents of the messages can be complex but it’s the job of the services to deal with that.

In a microservice architecture, components are services. The Lewis and Fowler definition of a component is, “a unit of software that is independently replaceable and upgradeable”. A service provides functionality while running in its own process. In a monolith, it’s more common to have more tightly coupled code and components that run in the same process.

Advantages of splitting components into services:

• Independence: Each individual service can be updated, tested, launched, and stopped without requiring the same from other parts of the software. In contrast, with some monolithic soft- ware, for example, all tests must be run each time a developer commits to a change, which can make for a long wait. If a service fails, any software depending on it will be without that service but the rest of the software needn’t be affected.

• Standardized component communication: Service commu- nication pipes can be simple and the same each time. This can make for less thinking, fewer mistakes, and less violation of encapsulation when connecting two components—just use the pipe.
  Disadvantages of splitting components into services

• Moreexpensivecommunication:Whereasinamonolithcom- munication between components can be direct calls (fast, light- weight), with microservices requests often happen over a net- work, need to include metadata to explain the request, and, be- cause the pipes are “dumb”, responses can contain extra data the requester didn’t ask for (slower, heavier).

• Potentiallylesssecurecommunication:Communicationover a network can be more prone to interception and alteration.
  In a microservice architecture, each service typically has its own database instead of sharing a centralized database. This helps keep the microservices independent, which has many benefits including failure containment. A disadvantage is that interoperating microservices can end up with copies of the same data that are inconsisent (e.g., because one database has not yet received the update). The term for this is eventual consistency, which means that, with time, each microservice will have the most up-to-date information but meanwhile there could be a mismatch (perhaps one that will annoy or mislead human users).

Microservices need only be compatible at their interfaces (communication pipe), leaving flexibil- ity in how each is implemented. For example, each service can be written in a different language, reducing the weight of tech stack decisions and decreasing the need to compromise on those de- cisions: For each service, teams can choose the optimal programming language, framework, ar- chitecture, etc. If, later, the team needs to change to different technologies, only the one service is affected. On the other hand, in a monolith, teams might only need to maintain a small set of technologies (e.g., if there’s only one framework, only one framework will need updates installed) and might not need as broad of expertise (e.g., having working knowledge of five programming lan- guages). Also, when code is more-or-less part of the same codebase, it might be easier to maintain the same standards across the code.

Comparison Between Monolith and Microservices

• In a monolith, communication (e.g., between classes and components) can happen in many ways, including through direct calls and over a network. With microservices, communication typically happens over a network such as through HTTP requests/responses, through “dumb”, standardized communication pipes. While microservices communication pipes are less complex, that means the endpoints need to be smarter. Also, communication over a network can be less reliable.

• Monolithic software often needs to be deployed all at once. Microservices can be independently deployed, and can potentially be stopped without stopping connected services.

• In terms of scaling If your monolithic software needs more resources to be able to support how much it’s being used, it can be copied onto multiple machines. Each machine must have enough space, memory, pro- cessing speed, etc. to support the entire monolith. If your microservices software needs more resources, you have more options. For example, the services that are used more can be replicated more times.

• In microservice software, each service can be independently tested. In a monolith, the way you test is influenced by dependencies within the code, which could reach broadly across the software (and make for slow tests).

• Each microservice can be written in a different language (e.g., one in Python, another in Java, another in C++, etc.), and can run in different contexts (e.g., machines with different operating systems, libraries, versions of libraries, etc.). In theory, this means they can be independently upgraded. With a monolith, upgrading may require more care; each component must be compatible with the new context (but this is also sometimes true with microservices).

• Monolithic software might have just one database, potentially a very large one. This can create a bottleneck if multiple parts of the software need to access the database in parallel and can make for slow database backing up and restoring, among other drawbacks. However, if you only have one database, that’s just one place for managing database access accounts and one database to maintain / back up / restore / etc. In contrast, each microservice typically has its own data storage.

The microservices architecture has advantage of being modular, where each service can be independently- managed. Communication mechanisms between modules can be standardized. However, creating a monolith can require less planning ahead of time and modules within a monolith can commu- nicate directly, which can be more reliable, less expensive, and provide better consistency than communicating to many pieces of software through a network.

SOFTWARE ENGINEERING PRINCIPLES

You can attempt to write a small program without using software engineering principles and it would be fine but an endeavor of developing a large software product, requires software engineering principles in order to produce cost effective good quality software.

When developing large commercial Software Products, the complexity (difficulty levels) of these programs increase exponentially with their sizes thus following sound Software engineering principles helps to reduce this programming complexity.

Without using software engineering principles it would be difficult to develop large programs (software products) that accommodate multiple functions, algorithms, industry standards and other complex features.

Software engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition.

• The principle of abstraction implies that a problem can be simplified by omitting irrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purpose and suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the omitted details can be taken into consideration to solve the next lower level abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem.

• The other approach to tackle problem complexity is decomposition. In this technique, a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. However, in this technique any random decomposition of a problem into smaller parts will not help. The problem has to be decomposed such that each component of the decomposed problem can be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem should minimize interactions among various components. If the different subcomponents are interrelated, then the different components cannot be solved separately and the desired reduction in complexity will not be realized.
  To Better understand software complexity and how to overcome it, read The Principles of Good Software Design by John O.

FRONTEND VS BACKEND VS FULLSTACK DEVELOPMENT

Front-ends work on what the user can see while Back-ends build the infrastructure that supports it and Full-stacks are both in one. Both Front-ends & Back-ends are necessary components for high-functioning software or applications.

• Front-end — ensures a satisfactory user experience with no issues, errors, or downtime by planning, designing, building, and implementing quality user interface systems for the software or application in question. Front-ends create and optimize systems, resolve UI/UX issues and even play an active role in testing and troubleshooting activities.

• Back-end — typically deals with the logical back-end and core computational logic. Back-ends are responsible for the server-side/back-end part of a software or application and usually write the business logic of software, web services, and APIs used by front-end.

• Full-stack — usually comes with experience of working both as a Front-end and Back-end. Often referred to as “jack-of-all-trades”, Full-stacks have skills in a wide variety of coding niches, databases, graphic design, and UI/UX that enables them do their job well working both the client and server ends.

DEVELOPER EXPERTISE LEVELS

As software Engineer/Developer will typically progress through several levels of experience while working in a Software Engineering industry depending on the organisation or the standards upheld within the geographical location he/she is working within.

In some countries or companies, you will find 5 or 7 levels depending on the breakdown and classifications of the expertise levels but the 3 common levels are;-

• Junior Software Engineer/Developer:

While starting out, most Developers will be Trainees/Apprentices or referred to as Junior Developer most as commonly known in the software industry. At this level, you probably have 0 to 1.5 years of experience tops and everything you know about Software Engineering is basic at best.

You will work on a team where you either pair, work with or have your code reviewed by another Developer probably a mid-level developer before it gets to the Senior developer or Lead Developer.

Read my Article; — The Struggles of a Junior Software Developer to get a feel of the experience a typical Junior Developer goes through.

• Mid-Level Developer or simply Software Engineer/Developer:

Mostly referred to as Intermediate Developer on some Job descriptions (JDs) put out by hiring companies or recruiter, a mid-level Developer is any developer with 2–3 years under their belt and has developed a substantial level of technical skills in the software engineering industry.

At this level, a developer has worked on some projects and can work unsupervised on a team among other things or under limited supervision which is typically code/tasks review from the Senior Developer who will act as a guide, mentor, and advisor for the most part.

• Senior Software Engineer/Developer:

This developer is also sometimes called a Developer Lead or Team Lead and is often referred to as a problem solver, because of their deep, specialized knowledge and exhaustive experience in the software engineering industry, knowledge of programming languages, tech stack, or even a specific product they are working or worked on.

At this level, a Developer has somewhere 5 to 8 years+ of experience and able to handle complex problems, comfortably review other developers’ codes, solve their problems, be a trendsetter when working on projects, and most importantly mentor Junior & Mid-level Developers.

DESIREABLE SKILLS FOR SOFTWARE ENGINEERS

These are some of, but not limited to skills the average software Engineer should have under their belt;-

1. Programming Languages: proficiency in any one or a combination of Python, Java, C++, etc.
2. Alogrithms & Data Structures: Core problem solving tools for coding.
3. SDLC: Knowledge from planning to software maintainance.
4. Version Control: Good undersand and use of Git for versioning and code collaboration among other benefits.
5. Debugging & Testing: Identifying, fixing bugs and testing code.
6. Databases: Should have knowledge or be able operate DBs like MySQL, MsSQL, PostgreSQL, SQLite, MongoDB among others efficiently.
7. Cloud Computing:Use AWS, GCP, AZURE Computing tools effeciently for app deployment and management.
8. Software Architecture: Be able to design robust software structures.
9. Project Management: Be able to plan, monitor and manage software projects.
10. Network Basics: Should have some understanding of TCP/IP, DNS, HTTP for web apps.
11. Security Practises: Basic understanding and knowkledge of securing app against vulnerabilities.
12. Communication: profiecent in clear verbal, written interaction with team members and stakeholders.
13. Operating Systems: Insights into OS components like Memory, processes and file systems etc.
14. CI/CD: Be able to automate tests, & do deployment with pipelines, etc.
15. Problem Solving: Tackle complex software issues effectively.
16. Machine Learning: Know-how in ML Alogrithms for AI Projects.
17. AI: Use tools like ChatGPT to speed up developemt.
18. Continous Learning: stay updated with tech advancements.

SOFTWARE ENGINEERING ECONOMICS

In the business environment, Software vendors (can be a Software Company or individual Software Engineers/Developers) are subcontracted to develop all, or some components, of a software system and/or setup the hardware on which that software will run. In such cases, the vendors make bids by providing proposals (technical and financial capability) in response to a request for proposals (RFP) which are evaluated before the contract is offered.

And the success of developing good software products is partly dependent on effective business management and understanding the underlying economics of Software Engineering.

Every time we make a decision involving multiple choices, we are making an opportunity cost based decisions and since most of these future costs are uncertainty, we need to estimate opportunity costs and the probability of making the right choice to produce the desired beneficial outcomes.

Software Engineering Economics involves formulating, estimating, and evaluating the economic outcomes to accomplishing a defined software development purpose when alternatives are available. It provides a systematic way of examining the attributes of software and it's processes that relates them to economic measures.

The dynamic values of money and assets as well as the patterns of cash flows, can be modeled in support of management's need to make decisions in the presence of constant uncertainties associated with developing Software in which case Software Engineering Economics can be based on elements like software costs, software engineering project costs estimations, economic analyses of software engineering projects, and software maintenance cost models.

Cost Estimation Models in Software Engineering

Cost estimation is a technique used to find out the cost estimates(the financial spend that is done on the efforts to develop and test software) of developing software. Cost estimation models are mathematical algorithms or parametric equations used to estimate the cost of a product or a project.

Most software cost models can be abstracted into a function of five basic parameters: size, process, personnel, environment, and required quality.

1. The size of the end product typically quantified in terms of the number of source instructions or the number of function points required to develop the required functionality.
2. The process used to produce the end product, in particular the ability of the process to avoid non-value-adding activities (rework, bureaucratic delays, communications overhead)
3. The capabilities of software engineering personnel, and particularly their experience with the computer science issues and the applications domain issues of the project
4. The environment, which is made up of the tools and techniques available to support efficient software development and to automate the process
5. The required quality of the product, including its features, performance, reliability, and adaptability

The relationships among these parameters and the estimated cost can be written as follows:

Effort = (Personnel) (Environment) (Quality)(SizeProcess)

In Software Engineering, Software Economics is a research area that focuses on the challenges associated with valuing software and determining or estimation the costs involved in its engineering (design, development, Implementation, testing and Maintenance among other things). The paper, "Barry Boehm & Kevin J.Sullivan in Software Economics: A Roadmap" outlines these difficulties and challenges, also presenting how software economics principles can be applied to improve software design, development, and evolution.

Software economics is basically situated at intersection of information economics and Software Engineering.

VERSIONING IN SOFTWARE ENGINEERING

Versioning or Version Control is the creation and management of multiple product releases, all of which have the same general function, but are improved, upgraded or customized. It helps developers, project managers, product managers and consumers keep track or identify the state a software product or package is in with a unique name and/or a number, thus providing a universal way of understanding the release process.

For example, say a fictional company Intellus Business Solutions was developing a software product for release, it can assign unique names or specific numerical identifiers to ongoing series of this product releases, such as intellus v.1, v.1.1,---n, v.2.0, 2.1,---n.

The numbers represent different versions of the same software product or application, and the numbers assigned increase to correspond to the latest development and releases.

Subsequent releases of the same product can also be assigned numerical identifiers consisting of two or three numbers separated by periods.

• The first number, called the major number, is increased when there are significant improvements or changes in functionality. For example, when Intellus v.1 makes major upgrades, from its erstwhile Intellus 1 to Intellus 2, intellus v.1, changes to v.2.
• The second number, called the minor number, is incremented when there are minor feature changes or notable fixes. Intellus v.1 can indicate minor changes were made to it by indicating the release as, Intellus v.1.1.
• The third number, if it exists, is called the revision number and is added or increased when minor bugs are eliminated. For example, Intellus v.1.1.2 would show that bug fixes were made to the previous version.

To sum this up, given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backward compatible manner
3. PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

In software engineering , versioning allows software development teams keep track of major & minor changes they make to the software project code, which may include new functions, features or bugfixes. It can also be an internal practice used to make it easier for developers to keep track of code evolution.

Semantic Versioning (SemVer)

Semantic Versioning, often abbreviated as SemVer, is a widely adopted versioning scheme in the software development industry proposed by Tom Preston-Werner in 2013 for software release version control with the aims of conveying meaning about the underlying changes in a release through version numbers.

Semantic versioning, or SemVer, is often used as a versioning framework for applications, plugins, extensions and different software objects.

SemVer comprises three parts, X.Y.Z, where X, Y and Z are non-negative integers. This means that the primary or major version is X, and the minor version is Y. Bug fixes and patches are called version Z. So, it always takes the form of X.Y.Z, or major.minor.patch. For example, in SemVer 1.8.0, 1 indicates the major version, 8 the minor version, and 0 the bug fixes or patches.

SemVer consists of three components: major, minor, and patch versions, represented as MAJOR.MINOR.PATCH.

• Major Version (MAJOR): This digit is incremented when incompatible changes are introduced in the software. It signifies that there are breaking changes in the codebase, and developers should expect potential backward compatibility issues.
• Minor Version (MINOR): When new features or enhancements are added in a backward-compatible manner, the minor version is incremented. Developers can safely update to a new minor version without worrying about breaking changes.
• Patch Version (PATCH): The patch version is incremented for backward-compatible bug fixes and minor improvements that do not introduce new features or breaking changes.

Benefits of Semantic Versioning

• Predictability: By adhering to SemVer, developers and users of a library or package can anticipate the impact of an update. They can quickly assess whether an upgrade is safe or might require adjustments to their codebase.
• Dependency Management: Package managers like npm, Composer, and pip rely on Semantic Versioning to resolve and install compatible dependencies automatically. This helps maintain consistency in your project's ecosystem.
• Communication: SemVer serves as a communication tool between developers. When a new version is released, the change in version number provides immediate insight into the nature of the update.
• You can keep track of every transition in the software development phase. Versioning the software ensures you that every team member or user can keep track of what has been changed and when;
• Versioning can do the job of explaining to the developers what type of changes have taken place and the possible updates that should take place in the software;
• It helps to keep things clean and meaningful. So, other people who might be using your project as a dependency;
• SemVer lets you know which version of a product is no longer backward compatible.

Using Semantic Versioning Effectively

• Start with Version 1.0.0: Every project should begin with version 1.0.0. This signifies that it's in its initial development phase.
• Increment Versions Mindfully: Major (MAJOR) for backward-incompatible changes.Minor (MINOR) for new features or enhancements.Patch (PATCH) for backward-compatible bug fixes.
• Use Pre-release and Build Metadata: SemVer allows for appending pre-release and build metadata to versions. For example, you can have versions like 1.0.0-alpha or 1.0.0+20231006.
• Document Changes: Maintain a changelog or release notes to document the changes made in each version. This helps users understand what has been added, fixed, or changed.
• Test and Automate: Implement automated testing and continuous integration to ensure that changes introduced in different versions do not break existing functionality.

Other existent versioning schemes

• CalVer this scheme relies on the date of the release. It is not as specific as the SemVer scheme but is used by projects such as Pip the Python package manager and Ubuntu
• Python Versioning Scheme is a scheme defined to identify distributions of Python. The scheme uses five segments called epoch, release, pre-release, post-release, and development
• Named Versions some projects opt to name their releases with a unique name. For example, Android has an interesting collection of version names that started off with Cupcake, Donut, and Eclair!
• Spring Project Version Scheme — this is a common method in Spring Framework and Spring Boot projects and expands on SemVer with some additional labels such as RC (release candidates) and BUILD-SNAPSHOT ( for a development release)

Git and How it Works

Git is a distributed version control tool that facilitates monitoring changes made to your code over time. Git makes it simple to track changes to your codebase and collaborate on projects with others. It was authored by Linus Torvalds in 2005 for developing the 𝗟𝗶𝗻𝘂𝘅 𝗸𝗲𝗿𝗻𝗲𝗹, with other kernel developers contributing to its initial development.

It enables us to 𝘁𝗿𝗮𝗰𝗸 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 𝗶𝗻 𝗼𝘂𝗿 𝗰𝗼𝗱𝗲 𝗮𝗻𝗱 𝗰𝗼𝗹𝗹𝗮𝗯𝗼𝗿𝗮𝘁𝗲 𝘄𝗶𝘁𝗵 𝗼𝘁𝗵𝗲𝗿𝘀 others by working on a different part of a codebase. When we say distributed, we may think we have code in two locations: a remote server and a local one, but the story is a bit more complex.

Git has three local storages: a working directory, a staging area, and a local repository.

1. Working Directory: Is where you work and your files live (also called "untracked"). All file changes here will be marked, and if they are not saved to GIT, you will lose them. The reason is that GIT is not aware of those files.

2. Staging Area: When you save your changes with git add, GIT will start tracking and saving your changes with files. These changes are stored in the .git directory. Then, files are moved from the Working Directory to the Staging Area. Still, if you change these files, GIT will not know about them; you need to tell GIT to notice those changes.

3. Local Repository: Is the area where everything is saved (commits) in the .git directory. When you want to move your files from the Staging Area to the Local Repository, you can use the git commit command. After this, your Staging area will be empty. If you want to see what is in the Local repository, try git log.

While many developers and vendors use the term Versioning in different contexts, it mostly often applies to operating systems, software artifacts and web services.

SOFTWARE PROJECT MANAGEMENT

Software project management is the planning, managing and tracking of software development projects. While the deliverable might differ from other projects that produce tangible deliverables, the processes are basically the same as the management of any other type of project.

It is a holistic approach to managing software projects throughout a software lifecycle with a project management mindset which focuses on the management of project information, resourcing, costing and budgeting among other key activities to deliver on-time, on-budget and in-scope projects.

It is a holistic approach to managing software projects throughout a software lifecycle with a project management mindset which focuses on the management of project information, resourcing, costing and budgeting among other key activities to deliver on-time, on-budget and in-scope projects. While the deliverable might differ from other projects that produce tangible deliverables, the processes are basically the same as the management of any other type of project.

In Software projects management the Software Development Life Cycle (SDLC) process(Plan, Design, Implement, Test, Deploy, Maintain phases), often overlaps the traditional Project Management Life Cycle process(Initiation, Planning, Execution, Monitoring and Control, Closing project life cycle phases) and are managed together for successful software development.

When a software product is being developed, there must be a clear understanding among the software project team members on when and what to do, otherwise there will be chaos leading to project failure.

A typical Software Development process from beginning to end will often looks like;-

• Idea Conception: The initial phase where the concept for a software project is conceived and outlined.
• Requirements Gathering: Involves collecting and documenting the functional and non-functional requirements for the software.
• Design and Planning: Creating the architecture and planning the development process based on the gathered requirements.
• Software Development: The actual coding and implementation of the software based on the design and plan.
• Continuous Integration and Testing: Regularly integrating code changes and performing automated testing to ensure software quality.
• Deployment to Staging: Deploying the software to a staging environment for further testing and validation.
• User Acceptance Testing (UAT): Allowing end-users to test the software to ensure it meets their expectations and requirements.
• Deployment to Production: Releasing the software to the live production environment for public use.
• Monitoring and Incident Response: Continuous monitoring of the production environment, with immediate response to any incidents or issues.
• Post-Production Iteration and Scaling: Making improvements to the software based on user feedback and scaling the system to handle increased load or demand.

In order to effectively manage Software Projects from begiining to end Software Project teams often have to manage it's software lifecycle using the Software Development Life Cycle (SDLC) whose phases (Requirements, Design, Implementation, Testing, Maintainance), are inherited from and thus losely overlap with the traditional _Project Management Life Cycle phases(Initiation, Planning, Execution, Monitoring and Control, Closing).

Software Development Lifecycle (SDLC) Phases

The Software development lifecycle (SDLC) is a series of development stages of a software Lifecycle through which a software project is managed from beginning to end.

Because all Software Projects have some semblance of a Software Development Lifecycle, the basic SDLC phase;-

1. Requirements: Defining what the software must do, how well it must do what it will do, and under what limitations or con- straints
2. Design: Defining how the code will be structured and how the user will experience the software
3. Implementation: Coding or otherwise converting the design into a product
4. Testing: Checking that the code was written without fault(verification) and that the software is what the users or client wants (validation)
5. Maintenance: Improving software’s existing functionality

can further be broken down to look somewhat like:

1. Requirement gathering:: This is where you listen to your client and understand what they want.
2. Defining:: This is where you and your client settle on the product to be built, based on the requirements you gathered.
3. Designing: Before writing any code, you need to have an idea of what you’re going to be building. This phase is not only about UI design, but about overall architecture as well.
4. Coding: Now we’re talking. This is where we write the code that makes every- thing defined so far a reality.
5. Testing: This is the validation of the coding work and in fact happens during the Verification and validation of software products or even during software quality assurance. This is where the quality threshold is set, and if your work does not meet that threshold, it won’t move forward. The true test of quality comes from the validation of an objective party: the testing team, sometimes also known as the quality assurance team or the quality control team.
6. Deployment: Here you move the tested work into the hands of the users.
7. Maintenance: When your deployed code is no longer going to be heavily changed, you might keep adding to it or fixing small problems, but the overall feature is done.

Depending on the Software Engineer/Developer, Software team, or Software Company.

There steps/phases are not absolute, and because every project goes through them multiple times, different Software teams are inclined to utilize the SDLC differently which is why it’s a cycle and not a straight path from start to finish.

There are different ways to travel through the SDLC stages and these patterns are called software lifecycle models, software process models or simply process models.

What is Software Lifecycle Model?

A software lifecycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle, mapping the different activities performed on a software product from start to end. It essentially captures and represents all the required activities and the order in which they are to be undertaken to make a software product transit through its life cycle phases.

Software development teams are required to identify suitable lifecycle models based on the project needs, specified requirements or client expectations for a particular software project undertaking and adhere to them for the duration of the entire project.

Choosing and using a particular lifecycle model helps software project teams ensure systematic and disciplined development of quality software products that meeting client expectations and industry standards without which, software project managers can face challenges executing and monitoring the progress of a software project.

The Different Software Development Life Cycle models

Over the years many life cycle models have been proposed and used with each model presenting some advantages as well as some disadvantages.
A few important and commonly used life cycle models include:

Classical Waterfall Model

Though the classical waterfall model is elegant and intuitively obvious, it is not a practical model in the sense that it cannot be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software. But all other life cycle models are essentially derived from the classical waterfall model.

The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the engineers during any of the life cycle phases. However, in practical development environments, the engineers do commit a large number of errors in almost every phase of the life cycle. The source of the defects can be many: oversight, wrong assumptions, use of inappropriate technology, communication gap among the project engineers, etc. These defects usually get detected much later in the life cycle.

For example, a design defect might go unnoticed till we reach the coding or testing phase. Once a defect is detected, the engineers need to go back to the phase where the defect had occurred and redo some of the work done during that phase and the subsequent phases to correct the defect and its effect on the later phases. Therefore, in any practical software development work, it is not possible to strictly follow the classical waterfall model.

Iterative Waterfall Model

The iterative waterfall model was conceptualized mainly to overcome the major shortcomings of the classical waterfall model. The advantage of this model is that there is a working model of the system at a very early stage of development which makes it easier to find functional or design flaws. Finding issues at an early stage of development enables to take corrective measures in a limited budget.

In the same breath, this SDLC model is mostly applicable only to large and bulky software development projects. This is because it is hard to break a small software system into further small serviceable increments/modules.

Prototyping Model

A prototyping model can be used when technical solutions are unclear to the development team. A developed prototype can help engineers to critically examine the technical issues associated with the product development. Often, major design decisions depend on issues like the response time of a hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve the technical issues.

A prototype is a toy implementation of the system that usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software built using several shortcuts.

The shortcuts might involve using inefficient, inaccurate, or dummy functions. The shortcut implementation of a function, for example, may produce the desired results by using a table look-up instead of performing the actual computations. A prototype usually turns out to be a very crude version of the actual system.

There are several uses for prototypes such as illustrating input data formats, messages, reports, and the interactive dialogues to a customer which can be a valuable mechanism for gaining better understanding of the customer’s needs or gaining customer buy-in prior to actual development of the software product e.g;-

• how the screens might look like.
• how the user interface would behave.
• how the system would produce outputs.

Developing prototypes is also important because it's not easy to get the perfect software product in the first attempt thus Many engineering teams and business analysts often advocate and plan for the possibility of throwing away the first version on the way to developing a good final software product. In most cases the experience gained when developing the prototype can be and is often used to develop the final software product that is shipped to the client.

In other cases, a prototype of the actual product maybe preferred where user requirements are not complete or technical issues are not clear.

Evolutionary Model

It is also called successive versions model or incremental model. At first, a simple working model is built. Subsequently it undergoes functional improvements & we keep on adding new functions till the desired system is built.

Applications:

• Large projects where you can easily find modules for incremental implementation. Often used when the customer wants to start using the core features rather than waiting for the full software.
• Also used in object oriented software development because the system can be easily portioned into units in terms of objects.

Advantages:

• User gets a chance to experiment partially developed system
• Reduce the error because the core modules get tested thoroughly.

Disadvantages:

• It is difficult to divide the problem into several versions that would be acceptable to the customer which can be incrementally implemented & delivered.

Spiral Model

Each loop of the spiral represents a phase of the software process, and each phase in this model is split into four sectors (or quadrants).

The following activities are carried out during each phase of a spiral model.

First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.

Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.

Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified risks.

Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next iteration around the spiral.
• Progressively more complete version of the software gets built with each iteration around the spiral.

*Circumstances to use spiral model *

The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models – this is probably a factor deterring its use in ordinary projects.

Comparison of different life-cycle models

The classical waterfall model can be considered as the basic model and all other life cycle models as embellishments of this model. However, the classical waterfall model cannot be used in practical development projects, since this model supports no mechanism to handle the errors committed during any of the phases.

This problem is overcome in the iterative waterfall model. The iterative waterfall model is probably the most widely used software development model evolved so far. This model is simple to understand and use. However this model is suitable only for well-understood problems; it is not suitable for very large projects and for projects that are subject to many risks.

The prototyping model is suitable for projects for which either the user requirements or the underlying technical aspects are not well understood. This model is especially popular for development of the user-interface part of the projects.

The evolutionary approach is suitable for large problems which can be decomposed into a set of modules for incremental development and delivery. This model is also widely used for object- oriented development projects. Of course, this model can only be used if the incremental delivery of the system is acceptable to the customer.

The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models – this is probably a factor deterring its use in ordinary projects.

The different software life cycle models can be compared from the viewpoint of the customer. Initially, customer confidence in the development team is usually high irrespective of the development model followed. During the lengthy development process, customer confidence normally drops off, as no working product is immediately visible. Developers answer customer queries using technical slang, and delays are announced. This gives rise to customer resentment. On the other hand, an evolutionary approach lets the customer experiment with a working product much earlier than the monolithic approaches.

Another important advantage of the incremental model is that it reduces the customer’s trauma of getting used to an entirely new system. The gradual introduction of the product via incremental phases provides time to the customer to adjust to the new product. Also, from the customer’s financial viewpoint, incremental development does not require a large upfront capital outlay. The customer can order the incremental versions as and when he can afford them.

NEED OF SOFTWARE ENGINEERING

The need of software engineering a rises because of higher rate of change in user requirements and environment on which the software is working.

• Large software - It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process.

• Scalability-If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one.

• Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted.

• Dynamic Nature- The always growing and adapting nature of software hugely depends upon the environment in which the user works. If the nature of software is always changing, new enhancements need to be done in the existing one. This is where software engineering plays a good role.

• Quality Management- Better process of software development provides better and quality software product.

===============================================

CONCLUSION

Software engineering is a branch of computer science, which uses well-defined engineering concepts required to produce efficient, durable, scalable, in-budget and on-time software products.

Software Engineering/Development outside in the business environment is a very complex process, mostly because real-world software is much larger, more complex and run on big budgets with a lot of uncertainties, timelines and often unreasonable expectations from the various stakeholders.

"Programming isn't about what you know; it's about what you can figure out." – Chris Pine.

It is a lucrative venture and getting proficient or mastering the various software engineering concepts, principles, essential processes and industry standards can give you an edge in the cut-throat competitive technology space.

There are several areas to focus on within Software Engineering, such as _Programming Basics, Software design, Software Processes, Software Project management, Software testing, Software Quality Assurance(SQA), Configuration Management, Database Design and Administration, Human-Computer Interaction, UI/UX Concepts, Operating Systems, Computer and Software Architecture, Software Modelling and Analysis, Embedded Systems, ML/AI & GenAI, Computer Networking and Security concepts, Research and Development(R&D)/Research Methodology, Data Structures and Algorithms(DSA), Technical Writing and Social Responsibility/Legal & Ethics among other disciplines.

Today, software development teams run lean processes to focus on end-user feedback and increased value, as noted in the Lean Startup, by Eric Ries, who advocates for rapid prototyping, end-user feedback and early and rapid product delivery.

Software requirements can be classified as functional or non-functional, therefore to deliver quality software, a lot of activities are done before, within and beyond the software development lifecycle. And the best way to guarantee that a company releases reliable, high-quality software products is through thorough quality assurance.

At its core, Software Quality refers to how well a software product conforms to its requirements and meets the needs of its users which involves both the software product as well as the processes used to develop it.

Quality Assurance in a nutshell is the what, methodology, best practice, and QA methods used by industries from which Software Quality Assurance is curved based on standard software engineering/development standards to ensure delivery of quality software products.

While quality assurance is all about preventive activities and quality control focuses on corrective processes. Software Quality Assurance combines both preventative activities and corrective processes to ensure quality software delivery.

The ISO/IEC 25000 series of standards, also known as SQuaRE (System and Software Quality Requirements and Evaluation), contains a framework to evaluate software product quality. ISO/IEC 25010 defines a set of eight software quality characteristics, or system “-ilities,” i.e. security, reliability, and maintainability.

ISO25010 describes two quality models:

• The quality in use model composed of five characteristics (some of which are further sub-divided into sub-characteristics) that relate to the outcome of interaction when a product is used in a particular context of use.
• A product quality model composed of eight characteristics (which are further sub-divided into sub-characteristics) that relate to static properties of software and dynamic properties of the computer system. The characteristics and sub-characteristics provide consistent terminology for specifying, measuring and evaluating system and software product quality. They also provide a set of quality characteristics against which stated quality requirements can be compared for completeness.

There are many different ways of versioning software products and artifacts with one of the most popular schemes being Semantic Versioning(SemVer).

SemVer is a popular versioning scheme that is used by a vast amount of open-source projects to communicate the changes included in a version release. As developers, it’s important for us to understand how to use SemVer in our own projects and also how to interpret a specific version change.

Semantic Versioning is a powerful tool for versioning software that fosters predictability, ease of communication, and efficient dependency management. By following the guidelines of SemVer, developers can maintain a well-structured versioning system that benefits both creators and consumers of software packages.

GLOSSARY

Abstraction: Representation that is purposely missing details to fo- cus attention on purpose of the ob- ject / idea / etc. being represented.

• Acceptance criterion: A state- ment about functionality that, when satisfied, mean the func- tionality has been satisfactorily implemented.
• Agile is a software process model and philosophy for managing and developing software projects.
• Business Capability: the potential of a business resource (or groups of resources) to produce customer value by acting on their associated factors.
• Class diagram: Visualization of how classes are built in relation to other classes in object-oriented software. Includes properties and methods of individual classes and “has a” and “is a” relationships be- tween classes.
• Client (a.k.a. customer): One or more people or organizations who are requesting the software be made and have decision-making authority about the software (e.g., because they are paying for it or otherwise providing resources).
• Client-server Architecture: Over- all code design characterized by one component (the server) responding to requests and providing resources while other components (clients) request those resources.
• Component: A unit of the code within a codebase, containing related functionality. Ideally, is both replaceable and reusable.
• Computer programs are a set of instructions/algorithms applied to various types of data that is used as a process of creating the software program with the help of a programming language.
• Coupling: The degree to which one unit of code is dependent on another.
• Definition of Done (DoD): The set of acceptance criteria which, once satisfied, mean a user story has been satisfactorily implemented.
• Development: Is the process of developing, being developed, or the result of developing.
• Disintermediation: is the process of technology replacing a middleman in a transaction.
• Economic efficiency: Economic efficiency is the ratio of output to input of a business system. (Economic efficiency (%) = Output/Input × 100 = Worth/Cost × 100).
• Efficiency: Efficiency of a system is generally defined as the ratio of its output to input. The efficiency can be classified into technical efficiency and economic efficiency.
• Engineering: Mostly involves applying science, conventional methods, and applicable tools to find cost-effective and sustainable/scalable solutions to developing problems. This can be in any industry where engineering is applicable.
• Encapsulation: It's a concept in object-oriented programming, of combining data and the methods that act upon that data into one unit of code. A way of preventing external direct access to data within a unit of code.
• Engineering Economics is a branch of microeconomics dealing with engineering related economic decisions and the application of economic principles and methods to engineering problems and decisions. It helps in evaluating the costs and benefits of different alternatives, such as projects, products, processes, or policies,in to make the best choice for your team, business or organization.
• ERP system: is an application with a centralized database that can be used to run a company’s entire business. With separate modules for accounting, finance, inventory, human resources, and many more.
• Eventual Consistency: Characteristic of software systems where different parts of the system can have less up-to-date information (e.g., state, data) than other parts but the inconsistencies are temporary.
• Functional requirement: Description of what functionality the software needs to have.
• High-level Architecture: Abstract representation of overall code de- sign; covers all parts of the soft- ware.
• Integrated Development Environment (IDE): . Software/pplication/Program specifically for creating software.
• Increment: A measurable increase in functionality in the software context.
• Institute of Electrical and Electronics Engineers (IEEE): The IEEE is a 501 professional association for electronics engineering, electrical engineering, and other related disciplines.
• Interaction Diagram: A visualization of collaboration between different parts of software.
• International Organization for Standardization (ISO): The ISO is a global standard-setting organization that spans multiple sectors. It is a consortium of 63 countries established to formulate and foster standardization.
• INVEST: Characteristics of good user stories (independent, nego- tiable, valuable, estimable, small, testable) (Wake 2003).
• Investment: Is an asset or item acquired with the goal of generating income or appreciation. (Interest = Current Value – Original Amount)
• ISO 9000: is a series of three standards(ISO 9001, ISO 9002, and ISO 9003), that specify the guidelines for maintaining a quality system, specifically the production process.

This ISO 9000 standard :

• ISO 9001 applies to organizations engaged in design, development, production, and servicing of goods. This is the standard that is applicable to most software development organizations.
• ISO 9002 applies to those organizations which do not design products but are only involved in production. e.g steel and car manufacturing industries that buy the product and plant designs from external sources and are involved in only manufacturing those products. Therefore, ISO 9002 is not applicable to software development organizations.
• ISO 9003 applies to organizations that are involved only in installation and testing of the products.

essentially specifies guidelines organisations should adhere to for repeatable, high quality product development.

• ISO/IEC 25010:2023: Systems and software engineering [Systems and software Quality Requirements and Evaluation (SQuaRE)] – which defines a product quality model, which is applicable to ICT (information and communication technology) products and software products.
• ISO/IEC 25019:2023: Systems and software engineering [Systems and software Quality Requirements and Evaluation (SQuaRE)] – which defines a quality-in-use model composed of three characteristics (which are further subdivided into sub-characteristics) that can influence stakeholders when products or systems are used in a specified context of use.
• Maintenance: Development activities unrelated to implementing new features that improve software but that (e.g., correcting bugs, improving organization of code, etc.)
• Microservices Architecture: Overall code design characterized by multiple independent com- ponents that each run in their own process and communicate between one another without direct access.
• Monolith Architecture: Overall code design characterized by be- ing in one or few pieces; cannot be easily divided into components that run separately and are inde- pendently useful.
• Non-functional requirement: Description of how well software is expected to perform.
• Project management is the process of planning and executing a project while balancing the time, cost, and scope constraints. Time, cost, and scope are known as the triple constraint.
• Quality attribute: A characteristic of software used to describe how good it is.
• Requirements elicitation: The process of gathering requirements from project stakeholders. user story: “Short, simple de- scriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. It's a method for specifying functional requirements.
• Scrum: An Agile framework “for developing and sustaining com- plex products.” (Schwaber and Sutherland 2020).
• Semantic Versioning: Often abbreviated as SemVer, is a versioning scheme for software that aims to convey meaning about the underlying changes in a release through version numbers.
• Sequence Diagram: Interaction diagram showing how different participants (e.g., users, software components, classes, etc.) collaborate during a single use case.
• Service: A unit of software that re- ceived and fulfills requests.
• Software is a set of computer programs that enable a computer system (hardware) to perform specific tasks.
• Software Architecture: Refers to the fundamental structures or building blocks of a software system (code design). The way software components (subroutines, classes, functions) are arranged and interact or integrate with each other. Can be shown at different levels of abstraction and detail.
• Software Development: Is a set of activities conceiving, specifying, designing, programming, deploying, documenting, and testing (bug fixing) involved in the process of creating and maintaining software applications, frameworks, or other software components.
• Software Development Life Cycle (SDLC) it is the phases (requirements, design, implementation, testing, maintenance) through which a software’s development proceeds from start to finish.
• Software Economics deals with the application of economic principles to software development by focusing on the ever challenging issue of valuing software and estimating the costs involved in its production.
• Software Engineering is a technical discipline or approach that applies computer science and engineering concepts in the design, development, testing and maintenance of quality reliable, usable, and dependable software. Simply put, it's an engineering-based approach to software development.
• Software Engineering economics is the application of economic techniques to the evaluation of Software design, development and engineering alternatives. It facilitates assessment of the appropriateness of a given software project, estimating its value, and justifying it from an business & engineering standpoint.
• Software Process Model: is a philosophy and/or set of approaches for software development and/or software project management. Each software process model has a different way of proceeding through the software development lifecycle (SDLC).
• Software Requirements Specification (SRS): A document that contains software requirements. It's often confused with another type of software document called a Software Design Document (SDD) although sometimes there is often overlap between the two. If the SRS is what the software should do, the SDD is what the software is.
• Stakeholder: Anyone who is or will be affected by the soft- ware or its development (e.g., clients, companies, users, devel- opers, managers, politicians, etc.)
• Technical Efficiency: It is the ratio of the output to input of a physical system. The physical system may be a diesel engine, a machine working in a shop floor, a furnace, etc. (Technical efficiency (%) = Output/ Input × 100).
• Tech Stack: The set of programming languages, frameworks, and other technologies chosen or needed for implementing a piece of software.
• Triple constraint is a concept in project management, that emphasizes the three limiting factors that govern project execution: time, cost, and scope where Scope includes quality, Cost includes spending money and resources and Time address the timeframe over which milestones and targets must or should be met within.
• Unified Modeling Language (UML): A set of notation and methods for describing and designing software.
• Use Case: “A contract for the be- havior of the system under discus- sion” (Cockburn 2001) requirements specification: Converting stakeholder requests into written requirements.
• Verification: Confirming that software satisfied its requirements (“did we build the software right?”).
• Validation: Confirming that software meets the users' needs (“did we build the right software?”).
• Waterfall (software process model): Way of going about software development and management that is characterized by extensive planning, comprehensive documentation, and moving linearly through stages of the software development lifecycle (SDLC).
• Service Level Indicator (SLI): a well-defined measure of 'successful enough'
  • used to specify SLO/SLA
  • Func(metric) < threshold
• Service Level Objective (SLO): a top-line target for fraction of successful interactions
  • specifies goals (SLI + goal)
• Service Level Agreement (SLA): consequences
  • SLA = (SLO + margin) + consequences = SLI + goal + consequences

SOFTWARE ENGINEERING RELATED RESOURCES AND REFERENCES

• Software Engineering Body of Knowledge (SWEBOK)
• Handbook of Software Engineering Methods by Lara Letaw
• Software Engineering at Google by Titus Winters , Tom Manshreck , and Hyrum Wright
• Software Project Management by Adolfo Villafiorita
• Skills of a Successful Software Engineer by FERNANDO DOGLIO
• The philosophy of software design
• Book Review: How to Manage Projects by Paul J Fielding
• What is Software Implementation
• History of software engineering
• Software engineering history
• The History of Software Engineering
• The Evolution of Programming Languages: Past, Present, and Future
• Coding From 1849 to 2022: a Guide to The Timeline of Programming Languages
• The Software of Civilization
• The Humble Programmer | Edsger W. Dijkstra | ACM Turing Lecture 1972
• The Humble Programmer; Recorded by Eric Normand. Published: August 2, 2021. Updated: August 17, 2021.
• Software Engineering Techniques
• Has the Software Crisis Passed?
• Building Secure and Reliable Systems
• Google Site Reliability Engineering(SRE) Books
• Google SRE Book Github
• Google SRE Book Read Online
• system-design-primer
• The Economics of Software Development: Beyond Cost
• Software Cost Estimation
• Cost Estimation Models in Software Engineering
• Software Cost Estimation Models in Software Planning
• WHAT IS Software Quality?
• What are the most common software quality issues and how can you address them?
• Understanding Software Quality: A Guide for Non-Technical Founders
• - Deliver High-Quality Software: Best Practices and Strategies
• Introduction Of Software Quality Assurance
• Software Configuration Management in Software Engineering
• ISO (International Organization for Standardization)
• What Is ISO 25010?
• Software Development Standards: ISO compliance and Agile
• What Software Development Standards Should You Be Aware Of?
• A Guide to Understanding ISO Standards
• Project Management: An Agile Approach to Projects.
• Agile 101
• Manifesto for Agile Software Development
• History: The Agile Manifesto
• Principles behind the Agile Manifesto
• Authors: The Agile Manifesto
• The Agile Coach
• What is “Given - When - Then?”
• Agile Alliance(n.d.).
• Scrum Guides
• Book Review: Scrum by Jeff Sutherland.
• Semantic Versioning 2.0.0
• Gentle introduction to semantic versioning
• A Guide to Semantic Versioning
• versioning
• Automating Versioning and Releases Using Semantic Release
• GitHub Pages
• Netlify
• How to merge two or multiple git repositories into one
• combining-git-repositories.md
• Git in 15 Minutes
• GitHub in 20 Minutes
• Software Development Life Cycle: Phases and Models
• What is CMMI? A model for optimizing development processes
• 10 Types of Software Testing Models
• The Testing Pyramid: Simplified for One and All
• What is Testing Pyramid? How Does It Benefit Agile Teams?
• Test Pyramid by Martin Fowler
• Software Testing Models | What it is, Types & How They Work?
• Differences between Black Box Testing vs White Box Testing
• Black Box Testing vs White Box Testing: Key Difference
• The 3 Types of Design Patterns All Developers Should Know (with code examples of each)
• Understanding Functional Requirements in Software Development
• The 10 Minute Test Plan By James Whittaker
• How Much Testing is Enough? By George Pirocanac
• Test Types and Maintenance Testing
• The 4 Levels of Testing in Software Engineering Explained
• The Role of Business Analysis in Project Management
• The Importance of a Business Analyst in Project Management
• Project Managers: How to Leverage Business Analysis for Project Success
• 9 Steps to Software Project Handovers
• Martin Fowler and J Lewis (Aug. 2019). Microservices Guide
• INVEST in Good Stories, and SMART Tasks by Bill Wake.
• Mike Cohn (n.d.). User Stories and User Story Examples.
• Google SRE publications(SRE Books, articles, trainings)
• Site Reliability Engineering: Measuring and Managing Reliability
• Dehaghani, S. M. H., & Hajrahimi, N. (2013). Which Factors Affect Software Projects Maintenance Cost More? Acta Informatica Medica, 21(1), 63–66.

KEYWORDS

Technology, Software, Program, Application, Software Application, Software Product, Software Product Development, Software Architecture, Programming, Coding, Programmer, Software Engineering, Software Engineer, Software Design, Software Development, Software Developer, Software Development Lifecycle, Software Development Lifecycle(SDLC), SDLC, SDLC Phases, SDLC Model, SDLC Methodologies, Software Configuration Management, Projects, Project Management, Software Project Management, Software Projects, Project Estimation, Software Implementation, Software Management, Software Crisis, The Humble Programmer, Principles, Methodologies, Computer Science, Software Quality, Software Quality Assurance, Software Quality Assurance(SQA), Software Testing, NATO Science Committee, The NATO Software Engineering Conferences, SWEBOK, Software Economics, Engineering Economics, Software Engineering Economics, Software Cost Models, Software Product Line Engineering, Product Management, Computer Programming Costs, management decision aids, Software Economics, Software Engineering Economics, Software Cost Estimation, Software Estimation, Economic Analysis Methodologies, International Organization for Standardization(ISO), ISO Compliance, Agile, Processes, Process Optimization, Process Improvement, Quality Control, Quality Assurance, Software Process, ISO Standards, Standardization, Functional Quality, Structural Quality, Process Quality, Software Testing Lifecycle (STLC), Software Testing Models, Software Testing Pyramid, Quality Management, Software Automation Testing, Agile Model, Spiral model, V model , waterfall model, Iterative model, software applications, Model-based testing, IT Project Implementation, Storytelling, System Implementation, Product Walkthrough, User system, User Training, Post Implementation, Versioning, Version Control, SemVer, Semantic Version Control, Git, Git Commands, GitHub, GitHub Actions, Software Lifecycle Models, Software Process Models, Process Models, Site Reliability Engineering, SRE, Site Reliability Engineers, DevOps, DevOps Engineer, Google, Google Cloud, Google Cloud Community

This content originally appeared on DEV Community and was authored by ᗰṳhumuzå ₱ɨuṩ

Print Share Comment Cite Upload Translate Updates

APA

ᗰṳhumuzå ₱ɨuṩ | Sciencx (2025-01-29T14:27:54+00:00) A Concise Software Engineering Beginner’s Guide for Business Tech Enthusiasts. Retrieved from https://www.scien.cx/2025/01/29/a-concise-software-engineering-beginners-guide-for-business-tech-enthusiasts/

MLA

" » A Concise Software Engineering Beginner’s Guide for Business Tech Enthusiasts." ᗰṳhumuzå ₱ɨuṩ | Sciencx - Wednesday January 29, 2025, https://www.scien.cx/2025/01/29/a-concise-software-engineering-beginners-guide-for-business-tech-enthusiasts/

HARVARD

ᗰṳhumuzå ₱ɨuṩ | Sciencx Wednesday January 29, 2025 » A Concise Software Engineering Beginner’s Guide for Business Tech Enthusiasts., viewed ,<https://www.scien.cx/2025/01/29/a-concise-software-engineering-beginners-guide-for-business-tech-enthusiasts/>

VANCOUVER

ᗰṳhumuzå ₱ɨuṩ | Sciencx - » A Concise Software Engineering Beginner’s Guide for Business Tech Enthusiasts. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2025/01/29/a-concise-software-engineering-beginners-guide-for-business-tech-enthusiasts/

CHICAGO

" » A Concise Software Engineering Beginner’s Guide for Business Tech Enthusiasts." ᗰṳhumuzå ₱ɨuṩ | Sciencx - Accessed . https://www.scien.cx/2025/01/29/a-concise-software-engineering-beginners-guide-for-business-tech-enthusiasts/

IEEE

" » A Concise Software Engineering Beginner’s Guide for Business Tech Enthusiasts." ᗰṳhumuzå ₱ɨuṩ | Sciencx [Online]. Available: https://www.scien.cx/2025/01/29/a-concise-software-engineering-beginners-guide-for-business-tech-enthusiasts/. [Accessed: ]

rf:citation

» A Concise Software Engineering Beginner’s Guide for Business Tech Enthusiasts | ᗰṳhumuzå ₱ɨuṩ | Sciencx | https://www.scien.cx/2025/01/29/a-concise-software-engineering-beginners-guide-for-business-tech-enthusiasts/ |

Please log in to upload a file.

There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.