SDLC - The Software Development Lifecycle

What is Software Engineering?

• Application of scientific principles for design and creation of software
• Systematic approach to software development
  • Design
  • Build
  • Test

Software Crisis:

• Began in mid-1960s

• Resulted from software development that ran over budget and behind schedule with unmanageable and buggy code

• By the time old software solutions were developed, the newer technologies got the traction, and code refactoring would become necessary

• Solutions didn’t scale well to large projects

  Engineering principles:

• Resolved as standardized methods in software engineering and computer-aided software engineering (CASE) tools were developed

Software engineer vs. software developer:

SE responsibilities:

• Design, build and maintain software systems

• Write and test code

• Consult with stakeholders, third party vendors’ security specialists, and other team members

  Software Development Life Cycle (SDLC):

• Scientific approach to software development

• Guides the software development process

• Identifies discrete steps needed to develop software

Introduction to SDLC

• Systematic process to develop high-quality software

• Aims to produce software that meets requirements

• Defined phases with their own processes and deliverables

• Cycle of planning, design, and development

• Minimizes development risks and costs

  History of the SDLC:

• Conceived of in the mid-1960s

• A deliberate approach needed to manage complex projects

• Initially used the waterfall method

• Adapted to use iterative methods

  Advantages of the SDLC:

• Improves efficiency and reduce risks

• Team members know what they should be working on and when

• Facilitates communication among stakeholders

• Team members know when development can move to the next phase

• Respond to changing requirements

• Solve problems early in the process

• Reduces overlapping responsibilities

Phases of the SDLC

• Organizations may have different names for each stage
• Some organizations have more or fewer stages

Phase 1: Planning

Requirements;

• Gathered
• Analyzed
• Documented
• Prioritized

Prototyping:

• Small-scale replica to clarify requirements

• Tests design ideas

• Can be developed at various stages of the SDLC

  Software Requirements Specification:

• Requirements are documented in the SRS

• All stakeholders must agree

Phase 2: Design

Phase 3: Development

Development starts when the design document is finalized and sent to the developers to write code for it.

Phase 4: Testing

• Code is tested to ensure stability, security, and that it meets requirements from the SRS

• Bugs reported, tracked, fixed, and retested

  Some common tests:

• Unit testing

• Integration testing

• System testing

• Acceptance testing

Phase 5: Deployment

Phase 6: Maintenance

Building Quality Software

Common software engineering processes:

• Requirements gathering
• Design
• Coding for quality
• Testing
• Release
• Documenting

Requirement Gathering

• The SRS encompasses the process of collecting and documenting the set of requirements that the software needs to adhere to

• It may include a set of use cases that describe the business needs and user flows that the software must implement

  Software requirements can be classified into four broad categories:

  1. Functionality
  2. External & user interface
  3. System features
  4. Non-functional

Design

• Transforming requirements into code
• Breaking down requirements into sets of related components
• Communicating business rules and application logic

Coding for quality

It refers to characteristics of the code, including attributes:

• Maintainability

• Readability

• Testability

• Security

  Quality code must fulfill the intended requirements of the software without defects

• Clean and consistent

• Easy to read and maintain

• Well documented

• Efficient

  Coding for quality entails a following set of coding practices during development;

• Following coding standards

• Using linters to detect errors

• Commenting in the code itself to make it easy to understand and modify

Testing

The process of verifying that the software matches established requirements and is free of bugs

• Identify errors, gaps, or missing requirements

• Ensures reliability, security, performance, and efficiency

• Software testing can often be automated or done manually

  The types of testing are;

• Unit testing

• Integration testing

• System testing

• User acceptance testing (UAT) or Beta testing

Releases

Documenting

System documentation:

README files, inline comments, architecture and design documents, verification information, and maintenance guides

User documentation:

User guides, instructional videos, manuals, online and inline help

Requirements

Steps to gathering requirements:

• Identifying stakeholders
• Establishing goals and objectives
• Eliciting requirements from the stakeholders
• Documenting the requirements
• Analyzing and confirming the requirements
• Prioritizing

1) Identifying stakeholders

Key personnel:

• Decision-makers
• End-users
• System administrators
• Engineering Marketing
• Sales
• Customer support

2) Establishing goals and objectives

Goals: broad, long-term achievable outcomes

Objectives: actionable, measurable actions that achieve the goal

3) Eliciting, documenting, confirming

Elicit:

• Surveys

• Questionnaires

• Interviews

  Document:

• Align with goals and objectives

• Easily understood

  Confirm:

• Consistency

• Clarity

• Completeness

4) Prioritizing

• Must-have
• Highly desired
• Nice to have

Requirements documentation:

• Software requirements specification (SRS)
• User requirements specification (URS)
• System requirements specification (SysRS)

1) Software requirements specification (SRS)

• Captures functionalities the software should perform
• Establishes benchmarks / service-levels for performance
• Purpose and scope
  • Purpose
    • Who has access to the SRS
    • How it should be used
  • Scope - Software benefits
• Constraints, assumptions, dependencies
  • Constraints: how the software must operate under given conditions
  • Assumptions: required OS or hardware
  • Dependencies: on other software products
• Requirements
  • Functional: functions of the software
  • External interface: users and interactions with other hardware or software
  • System features: functions of the system
  • Non-functional: performance, safety, security, quality

2) User requirements specification (URS)

• Describe business need and end-user expectations
• User stories:
  • Who is the user?
  • What is the function that need to be performed?
  • Why does the user want this functionality?
• Confirmed during user acceptance testing
• Often combined into the SRS

3) System Requirements Specification (SysRS)

• Outlines requirements of the system
• Broader than an SRS
• Contains;
  • System capabilities
  • Interface and user characteristics
  • Policy
  • Regulation
  • Personnel
  • Performance
  • Security
  • System acceptance criteria
  • Hardware expectations

The Software Building Process and Associated Roles

Software Development Methodologies

Common development methodologies:

A process is needed to clarify communication and facilitates information sharing among team members.

Some of these methodologies are:

• Waterfall

• V-shape model

• Agile

Sequential vs. iterative:

Waterfall pros and cons

V-shape model pros and cons

Agile pros and cons

Software Versions

• Software versions are identified by version numbers, indicate:

  • When the software was released
  • When it was updated
  • If any minor changes or fixes were made to the software

• Software developers use versioning to keep track of new software, updates, and patches

  Version numbers:

• Version numbers can be short or long, with 2, ,3, or 4 set

• Each number set is divided by a period

• An application with a 1.0 version number indicates the first release

• Software with many releases and updates will have a larger number

• Some use dates for versioning, such as Ubuntu Linux version 18.04.2 released in 2018 April, with a change shown in the third number set

  What do version numbers mean?

  Some version numbers follow the semantic numbering system, and have 4 parts separated by a period

• the first number indicates major changes to the software, such as a new release

• The second number indicates that minor changes were made to a piece of software

• The third number in the version number indicates patches or minor bug fixes

• The fourth number indicates build numbers, build dates, and less significant changes

Version compatibility:

• Older versions may not work as well in newer versions
• Compatibility with old and new versions of software is a common problem
• Troubleshoot compatibility issues by viewing the software version
• Update software to a newer version that is compatible
• Backwards-compatible software functions properly with older versions of files, programs, and systems

Software Testing

• Integrate quality checks throughout SDLC
• Purpose
  • Ensure software meets requirements
  • Error-free software

Test cases:

Three types of testing:

1. Functional testing:

The purpose of functional is to check:

• Usability
• Accessibility

2. Non-functional testing

Its attributes are:

• Performance
• Security
• Scalability
• Availability

Non-functional testing questions:

• How does the application behave under stress?
• What happens when many users log in at the same time?
• Are instructions consistent with behavior?
• How does the application behave under different OSs?
• How does the application handle disaster recovery?
• How secure is the application?

3. Regression Testing

• Confirms changes don’t break the application
• Occurs after fixes such as change in requirements or when defects are fixed

Choosing test cases for regression testing:

Testing levels

Unit → Integration → System → Acceptance

1. Unit testing

• Test a module code
• Occurs during the build phase of the SDLC
• Eliminate errors before integration with other modules

2. Integration testing

• Identify errors introduced when two or more modules are combined
• Type of black-box test
• Occurs after modules are combined into larger application

Purpose of integration testing:

3. System testing

• Compliance with SRS
• Validate the system
• Functional and non-functional
• Staging environment

4. Acceptance testing

Software Documentation

• Written assets

• Video assets

• Graphical assets

  Product vs. process documentation:

  Product Documentation	Process Documentation
  Relates to product functionality	Describes how to complete a task

Types of product documentation

1. Requirements documentation

Intended for the development team including developers, architects, and QA. Describes expected features and functionality.

It includes:

• SRS
• SysRS
• User acceptance specification

2. Design documentation

Written by architects and development team to explain how the software will be built to meet the requirements.

• Consists of both conceptual and technical documents

3. Technical documentation

Written in the code to help developers read the code:

• Comments embedded in code and working papers that explain how the code works, documents that record ideas and thoughts during implementation

4. Quality Assurance documentation

Pertains to the testing team’s strategy progress, and metrics:

• Test plans, test data, test scenarios, test cases, test strategies, and traceability matrices

5. User documentation

Intended for end-users to explain to operate software or help install and troubleshoot system:

• FAQs, installation and help guides, tutorials, and user manuals

Standard operating procedures

• Accompanies process documentation
• Step-by-step instructions on how to accomplish common yet complex tasks
• Ex: organization specific instructions for check in code to a repository
• Types of SOPs
  • Flowcharts
  • Hierarchical
  • Step-by-step

Updating documentation

• Must be kept up-to-date
• Documentation should be reviewed and updated periodically

Roles in Software Engineering Projects

• Project manager / Scrum master

• Stakeholders

• System / software architect

• UX Designer

• Developer

• Tester / QA engineer

• Site reliability / Ops engineer

• Product manager / Product owner

• Technical writer / Information developer

Introduction to Software Development

Overview of Web and Cloud Development

Cloud Applications

• Built to work seamlessly with a Cloud-based back-end infrastructure

• Cloud-based data storage and data processing, and other Cloud services, making them scalable and resilient

  Building websites and cloud applications:

  The environment is divided into two primary areas:

1. Front-End

• Deals with everything that happens at the client-side
• Specializes in front-end coding, using HTML, CSS, JavaScript and related frameworks, libraries, and tools

1. Back-End

• Deals with the server before the code and data are sent to the client
• Handles the logic and functionality and the authentication processes that keep data secure
• Back-end developers may also work with relational or NoSQL databases

Full-stack developers have skills, knowledge, and experience in both front-end and back-end environments.

Developers Tools:

• Code editor
• IDE

Learning Front-End Development

• HTML is used to create the structure and CSS is used to design it and make it appealing

• CSS is also used to create websites that have cross browser compatibility such as PC, mobiles devices etc.

• JS adds interactivity

  A front-end development language is Syntactically Awesome Style Sheets (SASS)

• An extension of CSS that is compatible with all versions of CSS.

• SASS enables you to use things like variables, nested rules, inline imports to keep things organized.

• SASS allows you to create style sheets faster and more easily.

  Learner Style Sheets (LESS)

• LESS enhances CSS, adding more styles and functions.

• It is backwards compatible with CSS.

• Less.js is a JS tool that converts the LESS styles to CSS styles.

  Websites are designed as reactive and responsive

• Reactive or adaptive websites display the version of the website designed for a specific screen size.

• A website can provide more information if opened on a PC than when opened on a mobile device.

• Responsive design of a website means that it will automatically resize to the device.

• If you open up a products’ website on your mobile device, it will adapt itself to the small size of the screen and still show you all the features.

JavaScript’s frameworksorks:

Angular Framework:

• an open-source framework maintained by google

• Allows websites to render HTML pages quickly and efficiently

• Tools for routing and form validation

  React.js:

• Developed and maintained by Meta

• It is a JS library that builds and renders components for a web page

• Routing is not a part of this framework and will need to be added using a third-party tool

  Vue.js:

• maintained by the community and its main focus is the view layer which includes UI, buttons, visual components

• Flexible, scalable, and integrates well with other frameworks

• Very adaptable – it can be a library, or it can be the framework

  The task of a front-end developer evolves continuously.

• The technologies are upgraded constantly, and so the front-end developers need to keep upgrading the websites that they create.

• The websites that they create should work in multiple browsers, multiple operating systems, and multiple devices.

The importance of Back-End Development

• Creates and manages resources needed to respond to client requests

• Enables server infrastructure to process request, supply data and provide other services securely

  What does the back-end developer do?

• Process the data you enter while browsing, such as:

  • Login information
  • Product searches
  • Payment information

• Write and maintain the parts of the application that process the inputs

Back-End Developer skills:

Examples of tasks and associated skills that back-end developers need:

APIs, routing, and endpoints:

• APIs, routes, and endpoints process requests from the Front-End
  • API is a code that works with data
  • Routes is a path to a website or page
  • Endpoint can be an API or route
• Back-end developers create routes to direct requests to correct service
• APIs provide a way for Cloud Apps to access resources from the back-end

Back-end languages and frameworks:

Some popular back-end languages are:

• JavaScript
  • Node.js
  • Express
• Python
  • Django
  • Flask

Working with databases:

Languages and tools for working with databases:

• Structured Query Language (SQL)
• Object-Relational Mapping (ORM)

Introducing Application Development Tools

A cloud application developer’s workbench includes:

• Version Control
• Libraries
  • Collection of reusable code
  • Multiple code libs can be integrated into a project
  • Call from your code when required
  • Used to solve a specific problem or add a specific feature

Frameworks:

• Provide a standard way to build and deploy applications

• Act as a skeleton you extend by adding your own code

• Dictate the architecture of the app

• Call your code

• Allow you less control than libs

  Inversion of Control:

• Libs allow you to call functions as when required

• Frameworks define the workflow that you must follow

• Inversion of control makes the framework extensible

  

  More tools:

• CI/CD

• Build tools

  • Transform source code into binaries for installation
  • Important in environments with many interconnected projects and multiple developers
  • Automate tasks like
    • Downloading dependencies
    • Compiling source code into binary code
    • Packaging that binary code
    • Running Tests
    • Deployment to production systems

Examples of Build Tools:

Packages:

• Packages make apps easy to install
• Packages contain
  • App files
  • Instructions for installation
  • Metadata

Package managers:

• Make working with packages easier
• Coordinate with file archives to extract package archives
• Verify checksums and digital certificates to ensure the integrity and authenticity of the package
• Locate, download, install, or update existing software from a software repository
• Manage dependencies to ensure a package is installed with all packages it requires

Package Managers by platform:

Cloud application package managers:

Introduction to Software Stacks

What is a software stack?

• Combination of technologies

• Used for creating applications and solutions

• Stacked in a hierarchy to support the application from user to computer hardware

• Typically include;

  • Front-end technologies
  • Back-end technologies

  Parts of the software stack:

  

  Examples of software stack:

• Python-Django

• Ruby on Rails

• ASP .NET

• LAMP

• MEAN

• MEVN

• MERN

LAMP Stack:

MEAN and relasted stacks:

Comparison of MEAN, MEVN, and LAMP:

• MEAN
  • All parts use JS – one language to learn
  • Lost of documentation and reusable code
  • Not suited to large-scale applications or relational data
• MEVN
  • Similar to MEAN
  • Less reusable libs
• LAMP
  • Lots of reusable code and support
  • Only on Linux
  • Not suited in non-relational data
  • Uses different languages

Programming Languages and Organization

Interpreted and Compiled Programming Languages

Interpreted programming:

Interpreted programming examples:

Compiled programming:

• Programs that you run on your computer
• Packaged or compiled into one file
• Usually larger programs
• Used to help solve more challenging problems, like interpreting source code

Compiled programming examples:

• C, C++, and C# are used in many OSs, like MS Windows, Apple macOS and Linux
• Java works well across platforms, like the Android OS

Compiled programming:

Comparing Compiled and Interpreted Programming Languages

Choosing a programming language:

Developers determine what programming language is best to use depending on:

• What they are most experienced with and trust
• What is best for their users
• What is the most efficient to use

Programming languages:

Interpreted vs. compiled

Query and Assembly Programming Languages

Programming language levels:

High-level programming languages:

• More sophisticated

• Use common English

• SQL, Pascal, Python

  Low-level programming languages:

• Use simple symbols to represent machine code

• ARM, MIPS, X86

Query languages:

• A query is a request for information from a database
• The database searches its tables for information requested and returns results
• Important that both the user application making the query and the database handling the query are speaking the same language
• Writing a query means using predefined and understandable instructions to make the request to a database
• Achieved using programmatic code (query language/database query language)
• Most prevalent database query language is SQL
• Other query languages available:
  • AQL, CQL, Datalog, and DMX

SQL vs. NoSQL:

• NoSQL (Not Only SQL)
• Key difference is data structures
• SQL databases:
  • Relational
  • Use structured, predefined schemas
• NoSQL databases:
  • Non-relational
  • Dynamic schemas for unstructured data

How does a query language work?

Query language is predominantly used to:

• Request data from a database
• Create, read, update, and delete data in a database (CRUD)
• Database consists of structured tables with multiple row and columns of data

When a user performs a query, the database:

1. retrieve data from the table
2. Arranges data into some sort of order
3. Returns and presents query results

Query statements:

• Database queries are either:

  • Select commands
  • Action commands (CREATE, INSERT, UPDATE)

• More common to use the term “statement”

• Select queries request data from a database

• Action queries manipulate data in a database

  Common query statements:

query statement examples:

Assembly Languages

• Less sophisticated than query languages, structured programming languages, and OOP languages

• Uses simple symbols to represent 0s and 1s

• Closely tied to CPU architecture

• Each CPU type has its own assembly language

  Assembly language syntax:

• Simple readable format

• Entered one line at a time

• One statement per line

  {lable} mnemonic {operand list} ;{comment}

  mov TOTAL, 212 ;Transfer the value in the memory variable TOTAL

  Assemblers:

• Assembly languages are translated using an assembler instead of a compiler or interpreter

• One statement translates into just one machine code instruction

• Opposite to high-level languages where one statement can be translated into multiple machine code instructions

  Translate using mnemonics:

• Input (INP), Output (OUT), Load (LDA), Store (STA), Add (ADD)

  Statements consist of:

• Opcodes that tell the CPU what to do with data

• Operands that tell the CPU where to find the data

Understanding Code Organization Methods

Pseudocode vs. flowcharts:

Flowcharts:

• Graphical or pictorial representation of an algorithm
• Symbols, shapes, and arrows in different colors to demo a process or program
• Analyze different methods of solving a problem or completing a process
• Standard symbols to highlight elements and relationships

Flowchart software:

Pseudocode:

Pseudocode Advantages:

• Simply explains each line of code
• Focuses more on logic
• Code development stage is easier
• Word/phrases represent lines of computer operations
• Simplifies translation to code
• Code in different computer languages
• Easier review by development groups
• Translates quickly and easily to any computer language
• More concise, easier to modify
• Easier than developing a flowchart
• Usually less than one page

Programming Logic and Concepts

Branching and Looping Programming Logic

Introduction to programming logic:

Boolean expressions and variables:

Branching programming logic:

Branching statements allow program execution flow:

• if
• if-then-else
• Switch
• GoTo

Looping programming logic:

While loop: Condition is evaluated before processing, if true, then loop is executed

For loop: Initial value performed once, condition tests and compares, if false is returned, loop is stopped

Do-while loop: Condition always executed after the body of a loop

Introduction to Programming Concepts

What are identifiers?

• Software developers use identifiers to reference program components
  • Stored values
  • Methods
  • Interfaces
  • Classes
• Identifiers store two types of data values:
  • Constants
  • Variables

What are containers?

• Special type of identifiers to reference multiple program elements

  • No need to create a variable for every element
  • Faster and more efficient
  • Ex:
    • To store six numerical integers – create six variables
    • To store 1,000+ integers – use a container

• Arrays and vectors

  Arrays:

• Simplest type of container

• Fixed number of elements stored in sequential order, starting at zero

• Declare an array

  • Specify data type (int, bool, str)
  • Specify max number of elements it can contain

• Syntax

  • Data type > array name > array size []

  int my_array[50]

Vectors:

• Dynamic size
• Automatically resize as elements are added or removed
  • a.k.a. ‘dynamic arrays’
• Take up more memory space
• Take longer to access as not stored in sequential memory
• Syntax
  • Container type/data type in <>/name of array

vector <int> my_vector;

What are functions?

• Consequence of modular programming software development methodology

  • Multiple modular components

• Structured, stand-alone, reusable code that performs a single specific action

• Some languages refer to them as subroutines, procedures, methods, or modules

  Two types:

• Standard library functions – built-in functions

• User-defined functions – you write yourself

What are objects?

• Objects are key to understanding object-oriented programming (OOP)
• OOP is a programming methodology focused on objects rather than functions
• Objects contain data in the form of properties (attributes) and code in the form of procedures (methods)
• OOP packages methods with data structures
  • Objects operate on their own data structure

Objects in programming

• Consist of states (properties) and behaviors (methods)
• Store properties in fields (variables)
• Expose their behaviors through methods (functions)

Software Architecture Design and Patterns

Introduction to Software Architecture

Software architecture and design:

• Design and documentation take place during the design phase of the SDLC

• Software architecture is the organization of the system

• Serves as a blueprint for developers

• Comprised of fundamentals structures and behaviors

  Early design decisions:

• How components interact

• Operating environment

• Design principles

• Costly to change once implemented

• Addresses non-functional aspects

  Why software architecture is important:

• Communication

• Earliest design decisions

• Flexibility

• Increases lifespan

  Software architecture and tech stacks:

• Guides technology stack choice

• Tech stacks must address non-functional capabilities

• Tech stacks include:

  • Software
  • Programming languages
  • Libs
  • Frameworks
  • Architects must weigh advantages and disadvantages of tech stack choices

Artifacts

• Software design document (SDD)
• Architectural diagrams
• Unified modeling language (UML) diagrams

1. Software Design Document (SDD)

• Collection of tech specs regarding design implementation
• Design considerations:
  • Assumptions
  • Dependencies
  • Constraints
  • Requirements
  • Objectives
  • Methodologies

2. Architectural diagrams
   It displays:

• Components
• Interactions
• Constraints
• Confines
• Architectural patterns

2. UML diagrams

• Visually communicate structures and behaviors
• Not constrained by a programming language

Deployment considerations

• Architecture drives production environment choices
• Production environment is the infrastructure that runs and delivers the software
  • Servers
  • Load balancers
  • Databases

Software Design and Modeling

Software Design:

Software design is a process to document:

• Structural components

• Behavioral attributes

  Models express software design using:

• Diagrams and flowcharts

• Unified Modeling Language (UML)

  Characteristics of structured design:

• Structural elements: modules & submodules

• Cohesive

• Loosely coupled

  Structure diagram example:

Behavioral models:

• Describe what a system does but doesn’t explain how it does it
• Communicate the behavior of the system
• Many types of behavioral UML diagrams
  • State transition
  • Interaction

Unified Modeling Language (UML):

• Visual representations to communicate architecture, design, and implementation
• Two types: structural and behavioral
• Programming language agnostic

Advantages of Unified Modeling Language (UML):

State transition diagram example:

Interaction diagram:

Object-Oriented Analysis and Design

Object-Oriented Languages:

• A patient could be an object
• An object contains data, and an object can perform actions

Classes and objects:

Object-Oriented analysis and design:

• Used for a system that can be modeled by interacting objects
• OOAD allows developers to work on different aspects of the same application at the same time
• Visual UML diagrams can be made to show both static structure and dynamic behavior of a system

Class diagram:

Software Architecture Patterns and Deployment Topologies

Approaches to Application Architecture

What is component?

• An individual unit of encapsulated functionality
• Serves as a part of an application in conjunction with other components

Component characteristics:

1. Reusable: reused in different applications
2. Replaceable: easily replaced with another component
3. Independent: doesn’t have dependencies on other components
4. Extensible: add behavior without changing other components
5. Encapsulated: doesn’t expose its specific implementation
6. Non-context specific: operates in different environments

Components examples:

Component-based architecture:

• Decomposes design into logical components
• Higher level abstraction than objects
• Defines, composes, and implements loosely coupled independent components, so they work together to create an application

Services

• Designed to be deployed independently and reused by multiple systems
• Solution to a business need
• Has one unique, always running instance with whom multiple clients communicate

Examples of Services:

• A service is a component that can be deployed independently
• Checking a customer’s credit
• Calculating a monthly loan payment
• Processing a mortgage application

Service-oriented architecture:

• Loosely coupled services that communicate over a network
• Supports building distributed systems that deliver services to other applications through the communication protocol

Distributed systems

• Multiple services located on different machines
• Services coordinate interactions via a communication protocol such as HTTP
• Appears to the end-user as a single coherent system

Distributed system characteristics:

• Shares resources
• Fault-tolerant
• Multiple activities run concurrently
• Scalable
• Runs on a variety of computers
• Programmed in a variety of languages

Nodes:

• Any devices on a network that can recognize, process, and transmit data to other nodes on the network
• Distributed systems have multiple interconnected nodes running services

Distributed system architectures:

Architectural Patterns in Software

Types of architectural patterns:

2-tier

3-tier

Peer-to-peer (P2P)

Event-driven

Microservices

Examples:

Combining patterns

Application Deployment Environments

Application environments:

Include:

• Application code/executables
• Software stack (libs, apps, middleware, OS)
• Networking infrastructure
• Hardware (compute, memory and storage)

Pre-production environments:

Production environment

• Entire solution stack ++

• Intended for all users

• Take load into consideration

• Other non-functional requirements

  • Security
  • Reliability
  • Scalability

• More complex than pre-production environments

  On-premises deployment:

• System and infrastructure reside in-house

• Offers greater control of the application

• Organization is responsible for everything

• Usually more expensive than compared to cloud deployment

Cloud deployment types:

Production Deployment Components

Production deployment infrastructure:

Web and application servers:

Proxy server:

• An intermediate server that handles requests between two tiers

• Can be used for load balancing, system optimization, caching, as a firewall, obscuring the source of a request, encrypting messages, scanning for malware, and more

• Can improve efficiency, privacy, and security

  Databases and database servers:

• Databases are a collection of related data stored on a computer that can be accessed in various ways

• DBMS (Database Management System) controls a database by connecting it to users or other programs

• Database servers control the flow and storage of data

Job Opportunities and Skill sets in Software Engineering

What does a Software Engineer Do?

Software engineering:

• Engineering

• Mathematics

• Computing

  Types of Software:

• Desktop and web applications

• Mobile Applications

• Games

• Operating Systems

• Network controllers

  Types of technologies:

• Programming languages

• Development environments

• Frameworks

• Libs, databases, and servers

  Categories of software engineer:

• Back-end engineers or systems developers

• Front-end engineers or application developers

  Software engineering teams:

• Off-the-shelf software

• Bespoke software

• Internal software

  And within the teams they might work on:

• Data integration

• Business logic

• User interfaces

  Software engineering tasks:

• Designing new software systems

• Writing and testing code

• Evaluating and testing software

• Optimizing software programs

• Maintaining and updating software systems

• Documenting code

• Presenting new systems to users and customers

• Integrating and deploying software

Responsibilities:

Skills Required in Software Engineering

What are hard skills?

Commonly required hard skills in software engineering:

• Programming languages
• Version control
• Cloud computing
• Testing and debugging
• Monitoring
• Troubleshooting
• Agile development
• Database architecture

What are soft skills?

• Hard to define, quantify, or certify
• Easily transferable

Hard skills for software engineers

Analysis and design:

• Analyze users’ needs

• Design solutions

  Development:

• Computer programming

• Coding

• Languages:

  • Java
  • Python
  • C#
  • Ruby

• Frameworks

Test:

• Testing

  • Meets functional specification
  • Easy to use

• Debugging

  Deployment:

• Shell scripting

• Containers

• CI/CD

• Monitoring

• Troubleshooting

Soft Skills for Software Engineers

Teamwork:

• Different teams

  • Project-based
  • Role-based

• Squads

• Pair programming

• Take advantage of strengths

• Learn from each other

  Communication:

• Peers

• Managers

• Clients

• Users

  Time management:

• Time-sensitive projects

  • Meet deadlines
  • Avoid delays

• Teams across time-zones

  Problem-solving:

• Design an appropriate solution

• Write an effective code

• Locate and resolve bugs

• Manage issues

  Adaptability:

• Client changes

• Management request

• User needs

  Open to feedback:

• Peer review

• Mentor

• Stakeholders

Careers in Software Engineering

Job Outlook for Software Engineers

Employment options:

• Employed roles:
  • Apprenticeship/internship
  • Part-time
  • Full-time
• Self-employed/independent:
  • Contracting/consulting
  • Freelancing
• Volunteer on open source projects

Career Paths in Software Engineering

Technical

• Coding and problem-solving

  Management

• Leadership and soft skills

Career progression:

• Junior or Associate Software Engineer
  • Develop small chunks of software
  • Supported by a team leader or mentor
  • Gain new skills and experience
• Software Engineer
  • Break tasks down into sub-tasks
  • Learn new languages
  • Understand the software development lifecycles
  • Mentor junior software engineers
• Senior Software Engineer
  • Work across a project
  • Mentor software engineers and review code
  • Solve problems efficiently
• Staff Software Engineer
  • Part of the technical team
  • Develop, maintain, and extend software
  • Ensure software meets expectations
  • Ensure software uses resources efficiently
• Technical Lead
  • Manage a team of developers and engineers
  • Responsible for development lifecycle
  • Report to stakeholders
• Principal Engineer/Technical Architect
  • Responsible for architecture and design
  • Create processes and procedures
• Engineering Manager
  • Support team
  • Encourage career progression
• Director of Engineering
  • Strategic and technical role
  • Determine project priority
  • Identify hiring needs
  • Define goals
  • Define new projects
  • Specify requirements
• Chief Technology Officer (CTO)
  • Oversee research and development
  • Monitor corporate technology
  • Evaluate new technology and products

Other career directions

• Prefer interacting with clients:
  • Technical sales
  • Customer support
• Prefer working with numbers and data:
  • Data engineering
  • Data science
  • Database administration
  • Database development
• Prefer finding and fixing bugs:
  • Software testing

Software Engineering Job Titles

Job Titles:

• Front-end engineer

• Back-end engineer

• Full-stack engineer

• DevOps engineer

• Software Quality Assurance Engineer

• Software Integration Engineer

• Software Security Engineer

• Mobile App Developer

• Games Developer

Code of Ethics

Origins of the code of ethics:

• Developed by the Joint Task Force on Software Engineering Ethics and Professional Practices
  • Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS)
  • Association for Computing Machinery (ACM)
  • Championed the need to hold software engineers accountable

About the code of ethics:

• Pertains to the analysis, design, development, testing, and maintenance software cycle
• Dedicated to serving the public interest

The 8 principles

1. Public

2. Client/Employer

3. Product

4. Judgement

5. Management

6. Profession

7. Colleagues

8. Self

Supplemental guide to behavior

• Use in conjunction with conscientious decision-making and common sense
• Knowing where to apply principles is at the discretion and wisdom of the individual