Virtualization and Containerization in DevOps

Deployment

• Deployment often proves challenging, with unexpected issues arising during the process of moving code to production.
• Problems can range from complete failure to partial functionality.
• Developers frequently face pressure and scrutiny when issues come up.

Servers

• Server racks hold numerous machines, each with available space and processing power.
• Deploying multiple applications to a single server is complex and potentially dangerous due to version compatibility issues, impacting the existing libraries/web servers/applications.
• Ideally, safe deployment of multiple apps to multiple servers would be advantageous.

Virtual Machines

• Virtual machines (VMs) can emulate entire systems.
• Each VM is completely isolated from others, providing a secure way to deploy various applications.
• However, VMs can be inefficient, especially when running the same OS on multiple VMs.

Advantages of Virtualization

• Reduced hardware costs, achieved from running multiple virtual machines on one physical piece of hardware.
• Simplified disaster recovery and maintenance of hardware.
• Easier consolidation of idle workloads
• Simpler provisioning and administration of both hardware and software.
• Increased flexibility and scalability of multiple operating systems.

Disadvantages of Virtualization

• Each VM requires its own operating system.
• Each OS requires a license.
• Each OS adds compute and storage overhead.
• Maintenance, updates and taxes are needed for VMs.

Solution: Containers

• Run multiple applications on the same virtual machine.
• Applications share the OS overhead.
• Applications cannot interfere with each other.
• Applications access each other's resources with explicit permission
• Notable container solutions include Docker and Kubernetes.

Containers - Further Details

• Multiple containers run on one virtual or physical machine, taking up less space, than VMs.
• All the containers share the common operating system
• Containers are isolated.
• Containers have their own file system/data and own networking. They are portable.
• Containers combine good VM properties with efficient resource utilization

DevOps

• DevOps is a methodology, with steps that include planning, code building, testing, deployment, and monitoring,
• Diagram displays the essential 7 continuous processes of a DevOps methodology.

7Cs of DevOps

• Continuous development (Planning and coding the software with version control
• Continuous Integration (Developers commit changes; Every commit is built, Includes unit, integration, testing, code review, and packaging)
• Continuous Testing (Software is tested for bugs with automated tests, using tools like TestNG, JUnit, Selenium). Docker can be used in testing)
• Continuous Deployment (Code is deployed to production servers. Helps maintain consistency between development, testing, and production environments)
• Continuous Monitoring (The use of the software is recorded and monitored to find trends and problem areas)

Tools

• Production-identical environments for development use Kubernetes and Docker.
• Source control and collaborative coding use Bitbucket, GitHub, and GitLab.

Continuous Delivery

• Automated testing of developed software's deployment to development branches
• Provides option to push to main when branch builds are successful
• Features continuous feedback through real-time chat alerts, using tools like Jenkins, aws, Bitbucket, and circleci

Automated Testing

• Improves software quality and reduces risk.
• Automation tools include UI testing utilities with security scanning, and load testing tools, such as Zephyr Squad, XRAY, mabl, ZAPhyr Scale, synk, MEND.

Automated Deployment

• Utility methods or scripts to automate deployments to various environments.
• Task lists are standardized and standardized for deployments and environment differences minimized.
• Tools such as Bitbucket, and AWS CodePipeline support automated deployment.

Operate and Observe

• Incident, Change, Problem Tracking : Jira Service Management, Jira Software, Opsgenie, and Statuspage
• Application and Server Performance Monitoring tools: AppDynamics, Slack, Splunk, New Relic. DataDog, Opsgenie, pingdom, Nagios, dynatrace, sumo logic.

Open Source

• Git (Version Control)
• Docker (Continuous Deployment)
• Jenkins (Continuous Integration and Continuous Delivery)
• Selenium (Web apps), Bamboo (Server) (Continuous Testing)
• Jira (Continuous Development and Feedback)
• Prometheus (Continuous Monitoring)
• Opsgenie (Continuous Operation).

Testing

• Defining ways to successfully complete a particular software program correctly.

The Biggest Takeaway

• Quality is not a last-minute affair.
• Quality must be considered from the beginning, throughout the entire software development process.
• A collaborative approach and awareness across all departments is needed to improve software quality.

In-Class Exercise

• Quality Assurance (QA) exercise for a banking app.
• Feature is "Transfer Money."
• Requirements include sufficient source funds, a $1-$10,000 transfer amount, active source/destination accounts, and disallowing transfers to the same account.

Types of Issues

• Issues in specifications
• Issues in coding
• Issues in documentation
• System issues (including capacity, performance, recovery, and dependencies)
• Security issues

Specification Issues

• Incomplete or unclear specifications.
• Specification is impossible to implement.
• Specification is outdated or misinterpreted.

How to Prevent Specification Issues

• Active reading and questioning by systems architects to anticipate unusual or overlooked circumstances.
• Active consideration of the workflow and the type of algorithms needed to anticipate problems.

Coding Issues

• Bugs and errors in code.
• Coders must be careful about bugs as they happen to even the best coders on their best days.

Fault Types

• Algorithmic faults (algorithms that may not scale or work as intended).
• UI/code mismatch (incorrect coding of UI elements)
• Logic Errors (“off by one” errors, updating the wrong variables, incorrect operations)
• Out-of-bounds errors (negative numbers, values beyond a set limit)
• Memory errors
• Syntax Errors
• Usability Faults
• Precision Faults

How to Prevent Coding Issues

• Desk checking (coding walkthrough with pencil and paper).
• Unit tests.
• Pair programming or code reviews.
• Automated testing tools (such as valgrind, linters, good IDE, compiler warnings).

Documentation Issues

• Inconsistency between program and specification.
• Unclear or outdated documentation.
• Issues with third-party components.

How to Deal with Documentation Issues

• Close collaboration with the documentation team.
• Active feedback as a volunteer (as to clarity and accuracy).
• Encapsulation to help resolve issues with third-party components.

System Issues

• System under provisioning (insufficient CPU/memory/disk/etc).
• System architecture problems.
• Problems with the chosen operating system
• Issues with any off-the-shelf software.

How to Deal with System Issues

• Addressing these problems in the planning stage.
• Tight collaboration with the systems team.
• Testing any off-the-shelf software suspected to need problems.
• Testing the performance of the system regularly.

Security Issues

• Invalid access to parts of the software.
• Problems with authentication procedures.
• Injection vulnerabilities (such as SQL or JavaScript injection).
• Security issues with configuration (like open ports, default credentials).

How to Deal with Security Issues

• Understanding security as a collective responsibility.
• Designing with security in mind.
• Working with the systems team and communicating effectively with each other.
• Developing specific security tests.

Types of Tests

• Unit Tests
• Integration Tests
• Functional Tests
• System Tests
• Acceptance Tests

Unit Tests

• Testing of individual components (like objects.)
• Unit tests prove components work and allow us to see any bugs found later must have been caused by factors other than the tested components.
• Can prevent issues after future code changes.

How to Write Good Unit Tests

• Tests should be fast (milliseconds).
• Tests should be easy to write (with minimal code required).
• Tests should be isolated (to only affect the tested component).
• Tests should be repeatable (for consistent testing).
• Tests should be self-checking (with results from pass/fail).

Best Practices (Unit Tests)

• Defining good names (understandable names).
• Not reusing between tests (fresh instances for each test).
• Simple tests (no complex logic).
• Helper functions (for complex components).
• Testing one thing at a time.

Dependencies (Unit Tests)

• using mocks to easily test components dependent on outside systems.

Code Coverage

• Understanding what components of a program need testing
• Accessors and mutators do not need to be tested extensively as they cannot fail

TDD (Test Driven Development)

• Writing tests first (the order is the tests, then the actual code.)

Code Inspection (Code Reviews/Pairing)

• A second set of eyes to look at code and find issues
• A structured way for multiple people to examine code to catch bugs
• Follows Linus' Law - With enough eyeballs, all bugs are shallow.

Surviving a Code Review

• The code and any tests need to pass review
• Thorough checking of correct specifications and coding standards
• Ensure code is sufficiently commented
• Actively listening during review
• Learning from others during the review, it is not a judgment.

How to Run a Code Review

• Knowing the code before the review, so one knows what one is reviewing.
• Code reviews shouldn't be performance evaluations.
• Be specific about the problems found in the code.
• Be careful about mentioning opinions in the code review.
• Automate checks to save time in reviews.

CI/CD (Continuous Integration/Continuous Delivery)

• Automated build/test system notifies CI system of code check-ins.
• Checks code and unit tests are complete.
• Builds get pushed to a development environment.
• Testing allows users to test changes immediately with minimal developer intervention.

Achievement - Code Checked In

• QA is responsible for checking the code.
• Unit testing helps define the QA process and responsibility.

Bug/Issue Trackers

• System to facilitate communication of issues and bug reports between team members.
• Github is a common choice.
• The tool enables connections between commits and bugs/issues.

Some Bugs are More Equal Than Others

• Prioritizing different kinds of bugs.
• Issues with varying importance and risk.

Integration Tests

• Confirming that the code works in the context with other integrated components of the software product.

QA

• QA is the term referring to Quality Assurance.
• QA helps improve the quality of released software and catches the bugs in program/software components during testing.
• QA is an essential group and person/persons of the development team.

QA Roles and Benefits

QA team is important to find bugs in the software components and improve program/software quality.

How is Testing Done?

• Often testing is done manually.
• Human eye helps find issues missing in automated testing procedures.
• Manual testing usually involves using some automated testing tool that supplements it.
• Testers/QA are not necessarily developers, so different tools/methods need to be provided

Test Plan Example - Log In Page

• Testing specific situations where the input is validated
• Testing that both inputs are required
• Testing that invalid inputs are reported.

Regression Testing

• Testing that existing features work correctly as new features are added to a software/program product.

Technical Testers

• Testing is sometimes more technical than other aspects.
• Technical testers are essential for setting up test machines to run the software/program.
• They can also test and examine database and network usage.

Performance Testing

• Testing to determine the speed of the software program.
• Various considerations for speed/performance testing include:
• Testing under pressure or stress (many users at once)
• Testing for large files/inputs (speed and reliability)
• Testing for use from different hardware (like in a home)
• Testing for time responses to user commands/actions

QA Summary

• QA is important to the software release process
• It is important to ensure quality.

Software Architectural Questions

• Questions about how to best design the software and its components based on inputs and understanding of users.

Deployment

• Questions regarding how to best deploy the software to users

Desktop/Mobile

• Desktop/Mobile application runs on the device or in a sandbox of the selected device
• Applications can be fast, small, and efficient
• Source code can be optimized and distributed within the application
• Data is stored directly on device OR sent to a service

Desktop/Mobile Stand Alone

• Application resides on a single device and doesn't directly communicate with the outside world.
• The software is completely local.
• Cost savings of significant ongoing operational expense saved by eliminating servers, as data is completely local.
• Slower network access speed may cause slower/harder scaling in large organizations.

Desktop/Mobile Augmented

• Addition of optional networking capability for the above model.
• Additional functionality may be implemented in the background (such as syncing)

Desktop/Mobile Two-Tier

• Requires network access to function.
• Significant work without network access isn't possible (i.e. without the server, there is no application).
• Lost device has no data.

Web Application

• Users interact with the application through a web address (URL).
• Application can be used from any device with internet access.

Hybrid/Offline Web Application

• Web Application functionality that is available offline.
• Files are stored in the browser for offline access and usability.
• Data is sent to the server by the developer’s choice.

Hybrid/Electron

• Web application is "wrapped" in a specialized window
• Application acts like a desktop application.

Other Terms (Network)

• The end user interacts with an application/server, called a "client".
• The other application/server is called a "server".
• "Three tier" is part of the network, adding a specific database server.

Cloud vs On-Premises

• Cloud-based software/programs are usually rented from another source/organization that hosts the program, and the source usually takes care of maintaining the servers/infrastructure requirements
• On-premise software/programs are usually hosted on a company's own servers/computers.
• Cloud-based programs often have better maintenance, are more flexible, and have a smaller cost/resource-hour

How to Choose? - Users

• Consider the target audience/end users.
• Consider the end-user’s needs and how well they’ll understand/interact with the program
• Casual users of a program usually benefit from a simple web-app structure.
• Users with highly specialized needs often require more specific program functionality than those who use the program casually.

How to Choose? Platforms

• Considering the software to run on any system or with very specific system requirements.
• The target system considerations/constraints can influence the approach for selecting the appropriate technology.
• Web approaches are often better for general systems that need to run on many platforms or types of systems
• Specific systems (with platform constraints) can potentially use other techniques that are more complex/have different requirements than web applications.

How to Choose? Scalability

• The ability of the software to respond to changing conditions (such as increased user usage).
• Cloud-based systems are typically better at handling increased user loads than those that run directly on-premise, as it is much simpler to add more servers/processing power to handle increased load/demand.
• On-premise systems usually need more specialized/complex equipment modification or maintenance, which can take longer, especially with large organizations

How to Choose? Data

• Consider what data the program will need from the users
• Consider the type and consistency of data expected
• Consider how/if the data will need to be synchronized with the source

How to Choose? Performance

• Consider the critical nature of the response time.
• For applications requiring quick response times, the cloud-based systems are often more cost-effective than those run directly on-premise
• Consider the requirements of the users and how important quick response times are to the end users.

How to Choose? Skillset

• The expertise and experience of the people on the project team.
• Using appropriate people for the appropriate expertise and needed tasks is essential for developing a quality product
• It may or may not be appropriate to hire specialists for certain tasks.

How to Choose? Cost

• Accounting for the cost of development in addition to the cost of upkeep and maintenance
• Comparing the development costs of using a third-party (cloud) vs. directly developing/purchasing in-house.
• Considering the potential for long-term costs/maintenance, as maintenance and potential future upgrades can cause additional costs.

How to Choose? Security

• The security risks of the application.
• Consider if the program has to directly interact with the Internet.
• Consider all the different security issues that might arise.

How to Choose? Legal

• Be aware of any laws that might regulate the development of the program.
• Consider the rights and responsibilities of all parties involved in the implementation and use of the program.
• Ensuring that all legal requirements are met is essential

Data Storage

• How best to store and handle the data that the program works.
• Choosing the proper data storage options, such as relational or non-relational databases, or flat files.

Relational Database Management System (RDBMS):

• A data storage method well suited for structured data, using constraints of entities to organize data.

SQLite

• Open-source database management system.
• Lightweight and capable of providing similar functionalities of a full server-based RDBMS.

NoSQL

• A good choice for situations where data is not relational.
• This may involve non-relational databases like key-value stores (similar to JavaScript hash maps).
• NoSQL can offer speed and scalability advantages.

Flat Files

• Data organized into files.
• Suitable for data that is not needed in a consistent/uniform structure.
• Best if all operations are atomic operations.
• Often used for images, sounds, animations, etc.

On-Prem Architectural Decisions

• Considering how to best design a system to run exclusively on the company's existing hardware

How Many Environments?

• Suggesting using 3 environments: Development (dev), Testing (test), and Production (prod).
• Separating these environments to prevent conflicting interactions

How Many Machines/Environments?

• Determining the necessary hardware to appropriately run the program and complete required tasks (often measured in CPU, disk, and memory requirements)
• Web servers that can handle many requests simultaneously and database servers optimized for large databases.

Backup Strategy

• Strategies for backing up your data and how this relates to data security.
• Regularly backing up critical data is important to maintain data security.
• Consider hardware options like using swappable hardware to ensure continuity of operation during hardware failure

Operating System Support

• Considering the operating system of the system and planning for any updates (especially important with business systems/programs)
• Having a schedule and plan for updating operating systems is a good idea to avoid problems later on.

Licensing

• Different licenses are often used for software programming and application development. Considering the licensing of any existing and used components of the project.

Hardware Upgrades

• Scheduling hardware upgrades is important, especially in business applications/systems
• Consider the potential usage history of the hardware in the development, testing, and production parts of the system and the impact on upkeep costs

Backup Power/Internet

• Issues with electrical outages and Internet outages need to be considered in deployment/infrastructure
• Multiple Internet Providers (wireless preferred), and backups for electrical power
• Backup Considerations - Using backup power for electrical failures and internet outages

Staffing

• The importance and specifics of staffing decisions during planning and implementation (depending on the size of the company)

On-Prem vs Cloud

• Costs/upkeep associated with using company-owned hardware (on-premise) vs. renting software/services from external providers (“cloud”).

User Interfaces

• The best UI is an intuitive and clear UI.
• Essential UX consideration, such as clarity and usefulness, is important alongside aesthetics/visual design, to provide helpful functionality

User Interface and User Experience

• Interface (UI): The portion of the software seen and used by the end user.
• Experience (UX): Total experience of using the software, from visual design to total impressions.

User Interfaces - Principles

• Usefulness (and not visual aesthetics) is the most important characteristic of a good or successful UI design.
• It's easy to make something pretty, but hard to make something useful with a good user experience
• Useful and well-paced UIs typically avoid surprising the user, and use similar functionality and elements to previously used applications or services

User Interfaces - Layers

• Utility: The core functionality.
• Usability: Ease of learning and use.
• Desirability: Aesthetics and design.
• Aspirational: Feelings about product/service/program

UI - Art Form

• UI/UX is a combination of technology and humanity.

Obvious Is Better

• Avoiding overly complicated or complex interfaces

Familiarity

• Familiarity with the interface is one of the keys to creating a successful program/application design
• Using similar terms, functions, and interactions as those that the users are already familiar with is key to a generally accepted program/application design.

Minimal Surprise

• Avoiding surprising users through the design or interface, so users do not encounter difficulty and problems

Consistency

• Consistency in similar interactions is appreciated by users.

Recoverability

• Implementing features (like undo) and providing recovery tools for users.

User Diversity

• Providing options for different kinds of users (like different user types)

Feedback

• Providing a confirmation or feedback to the user after completing an action or transaction

Preventing Mistakes

• Avoiding non-valid options or actions, and blocking any non-sensical inputs or commands from the user.

Hick's Law

• Reducing the number of choices to keep the process easy and fast for the user

How Many Environments? and How Many Machines?

• Keeping the various stages of the software product or program separated can potentially avoid problems during use
• Consider the development, test, and production environments to enable the various testing/debugging groups/people within the organization to run the software in separate environments (to avoid negative impacts on the program's functionality from outside interference).
• Additional servers may be necessary—like potentially using more “web servers” which take many/thousands of requests simultaneously, or more computationally intensive servers/hardware which can handle higher processing power requirements

Backup Strategy

• Regular backing up is important, especially with business products

Operating System Support

• Updating or maintaining the operating system is important (especially with long-term operations/use)
• Having a schedule and maintenance window for updates and/or upgrades is part of the process planning.

Licensing

• Ensuring that all software has proper licenses

Hardware Upgrades

• Updating, replacing, or modifying hardware components used for the program is often necessary to maintain the functionality and efficiency of the program.

Backup Power/Internet

• Ensuring that systems can continue operating during an outage, whether electrical or internet.

Project Justification

• Justification for the cost of creating/maintaining the program (what will it save/cost)

Project Costs

• Considering the costs of development of the program, including salaries, any external contracted help, and the opportunity costs.

Project Benefits

• The expected benefits from having the program, including increased services, increased/new revenue generation

System Request

• Presenting a system request to upper or executive/management

Example - Golf System

• Example of a business/system request for a golf course reservation system.
• Describes the needs in terms of current problems, costs, and potential improvements (like saving money and increasing revenue).
• Describes business requirements and value, and constraints.

Approval

• Getting upper/management to approve the system request, or new systems

Feasibility Study

• A study of the costs/benefits and the possible approach to the implementation

Feasibility Types

• Technical (how it works)
• Economic (how much money, impact on revenue/costs)
• Organizational (how the company/organization reacts/supports the program)

Technical Feasibility

• Evaluating the technological approach (COTS/homegrown/hybrid models)

Technical Feasibility Considerations

• Technical Risks (to other systems)
• Required Staff
• Hardware requirements
• Licensing requirements

COTS vs. Homegrown vs. Hybrid

• Comparing Commercial, off-the-shelf software options vs. designing the software internally (homegrown) vs using a mix of options.

Technical Feasibility Output

• Documenting technical feasibility, as well as costs and timelines.
• Estimating costs
• Outlining different possibilities (as part of the process)

Time Estimates

• Emphasizing that estimates should be conservative (as estimates often vary/fail to meet the expected times/costs).

Costs

• Details and considerations (salaries, benefits, amortization, equipment, training, etc.)

Costs - Average

• Average costs of certain positions/roles, to help estimate costs in projects/organizations

Economic Analysis Example

• Illustrative costs/benefits and their timelines.
• Showing typical cost and revenue over expected times

Economic Feasibility

• Determining the financials/economic value of the program and considering any and all possible costs/benefits

What About No Revenue Projects?

• Considering the costs involved with systems that do not necessarily collect revenue/profits.
• Determining the economic value of the system based on other possible benefits (like improved efficiency, reduced risk, or other corporate goals)

Some Revenue Ideas

• Tangible revenue opportunities, including increased sales, reduced staff, reduced inventory, reduced costs, better supplier pricing, and more agile operational approaches.
• Intangible revenue benefits, including strengthened brand recognition, better customer service, stronger supplier relations, and more favorable corporate perceptions

Economic Feasibility Concepts

• Return on Investment (ROI)

• Break-even Point

Example

• Example application of ROI concepts to typical software feasibility study scenario.

Example - Economic Costs/Benefits

• Example of economic costs/benefits

What do you do if the economics don't work?

• Ways to adapt when economic feasibility models aren't successful
• The options/alternatives to consider if costs are too high
• Reducing project scope is one approach, along with possible approaches involving developers/design, hiring/staff changes, and other approaches.

What do you not do if the economics don’t work?

• Avoid incorrect or unreliable data/numbers
• Avoiding putting undue pressure on the development and testing team

Organizational Feasibility

• The project's acceptance into/relationship with the organization.
• The organization's support of and attitude toward the initiative.
• Considering who is approving the project and who could oppose/resist the project

Organizational Perspective

• Champion, Management, and User perspectives/feedback are crucial to success.

Organizational Feasibility Output

• Summarizing the organizational process and response/reception to the project (in terms of support from upper management, etc.).

Risk

• Potential for risks
• Highlighting risk levels
• Identifying risks and factors relevant to the project (development costs, revenue expectations, etc.)

Executive Summary

• A short, usually single page summary on a project's feasibility study

Starting the Project

• How a project begins/starts.

The Idea

• The basic idea behind a system/project

What Gap are we trying to fill?

• Understanding the specific problems or issues/shortcomings with the existing system that are targeted for resolution by the new system/product.

How is it done now?

• Outlining how the current system is being used and operates,
• Identifying the pain points and issues within the workflow of the current/existing system.

Example: Pros/Cons (Monopoly Game)

• Basic aspects of the game, and the advantages and disadvantages of playing on a board game

Example: In-Person Shopping

• Listing advantages and problems (in terms of the shopping experience) of in-person shopping experience

Pros and Cons (Opportunities)

• Listing possible advantages and disadvantages of the new system/product, and ways in which they might possibly overcome any potential problems.

What if I don't know?

• The need to consult other specialists for expert input for programs/applications in new/unfamiliar areas

Project Justification

• Why is the project/program needed?
• Considering the potential rewards, how they provide potential benefit to the project/organization, and the costs. (the ‘benjamins’)

Software Development Life Cycle (SDLC)

• A series of steps that outline/structure the development of a software product. Planning and requirements gathering to testing and validation and maintenance.

Waterfall Model

• A sequential approach in which all phases must be completed before proceeding to the next phase.

Waterfall Advantages

• Well-suited for stable requirements and non-integrated teams/developers
• The steps/phases are documented and well-defined for easier understanding of the workflow

Waterfall Critiques

• Issues with changes and accommodating changes
• Risk to the organization if any part of the planned work/phase fails

Waterfall Conclusion

• Waterfall is typically taught in the educational setting, but not a common (industrial/operational) methodology in project management
• It is still a useful, simple, model to understand.

Iterative/Agile Model

• The stages/phases in an Agile software project are interleaved, allowing for flexibility and changes.

Iterative/Agile Description

• The method of working in stages, usually over a set period, and building working software (not complete) over that period.
• Flexibility in the plan is prioritized (in terms of changing requirements/user needs).

Iterative/Agile Advantages

• Flexibility and responsiveness to changing needs
• Immediate user feedback and faster program completion.

Iterative/Agile Disadvantages

• Requires a highly collaborative (integrated) development team
• Re-work is often necessary as parts of the project are modified

Agile Questions

• Scalability factors (how large a team is involved/can the current approach be adapted to handle larger teams?).
• Whether a more distributed/specialized approach to the project can be achieved using multiple teams rather than one larger team

Scaling Up

• Scaling the approach to use more people/employees

Scaling Out

• Scaling the approach to use multiple teams/groups

Contracts

• Details on contractual obligations and the relationship/interface with the buyer and seller of the project

Agile on Existing Projects

• Adapting the Agile methodology to existing programs/applications

"Not for Everyone/Every Company"

• Not every company/situation or organization uses the same method for a given task or project (can be based on business needs and preferences)
• Agile methods can present challenges/issues, such as customer involvement, for some organizations/companies.

A (Very) Brief Introduction to the Corporation

• Short introductions to a corporation/organization

Purpose

• Corporation purpose

Growth

• How organizations and companies grow from startups (few employees) to large organizations (many departments).

Departments

• Different departments in an organization, along with their roles

Engineering

• Engineering department's specific responsibilities

Product Management

• Product management's specific needs and responsibilities

Project Management

• Project management's responsibilities for tracking resources and costs, and to help deliver on time

Operations/IT

• Operations/IT's responsibilities from maintaining hardware and software (like electricity and internet)

DevOps

• The methodology that combines the development and operation teams

Quality Assurance

• Responsibilities for quality of the product/software

Accounting

• Accounting's responsibilities for business finances and financial processes/tasks (bills, paying bills, tax obligations, and ensuring financials are in line with overall company goals).

Human Resources

• HR’s role in fulfilling legal obligations and in handling operations/procedures related to people, such as payroll, benefits, hiring, firing, etc

Sales

• Sales’ role in customer management, engagement, and generating revenue

Marketing

• Marketing in terms of branding and other marketing operations (like trades shows, adverts, email, etc.)

The C-Suite

• The various C-Suite personnel's/roles

Customers

• The end-users and different organizations that will be using the software product

Many Different Possible Customers

• Different types of companies/people/organizations who could be using the product

Internal Customers

• Internal users/members of the organization who are using the software product

External: B2C

• When the software is sold to the general public/end users, and are usually less expensive than those sold to other organizations.

External: B2B

• When software is sold to other businesses. Typically these require more custom/complicated designs than those sold to individual consumers.

External: Contracting

• Customers contracting to have software built. Typically done on a time-and-materials basis, often in an iterative/Agile manner.

External: Consulting

• Customers using consultants to augment or handle a project

Business Model

• The approach to be used for generating revenue from the software product

Free: Ad-based

• Displaying ads to generate revenue

Free: Someone else pays

• The organization/company receives funding from other parties (not the end user).

Purchase

• Paying once for the software/program

Subscription

• Paying monthly/yearly

Much More...

• The business models are quite varied, which needs to be considered when analyzing potential products and costs associated with their development, upkeep, and usage by users and organizations using the products.

ICSI 418Y Software Engineering

• Course information/description, for a typical software engineering course.

Course Description

• Course description for software engineering

What You Will Learn

• Skills to be learned in the course

Course Instructors

• Instructors for the course (and TA or Teaching Assistant)

Grading

• Grading details and weights

Tentative Lecture Plan

• The topics to be covered during the lecture

Labs

• Lab details and timing information

Week 1 Goals

• Specific goals for the first few weeks of the course

Skill - Web Development

• Important skills related to web development

HTML, HTML+CSS, HTML+CSS+JavaScript

• HTML (HyperText Markup Language), HTML+CSS (with additional CSS), and HTML+CSS+JavaScript (combining HTML structures and additional formatting/functionality with JavaScript)

MVC (Model-View-Controller).

• Model: The data part of a system
• View: The user interface
• Controller: The middleware between the model and the view

The Workflow

• The overall flow and structure for how the Model, View, and Controller parts interact

HTML (HyperText Markup Language / HyperText)

• Used to specify content and structural elements of a website

HTML - Overall Structure

• The basic structure of an HTML document

HTML - Text Formatting

• Various text formatting and structure tags in HTML

HTML - Lists

• Using lists (unordered and ordered)

HTML - Tables

• How to format tables using the <table, , , > tags

So, so much more

• Various websites and other helpful resources

How do these systems (HTML, CSS, JavaScript, servers, browsers) interact?

Header

<script>

Key Attributes

CSS

• Cascading Style Sheets, which are used to style text and various presentation elements in a website or webpage.

So Bland...

Changes and Repetition

CSS Basics

Whole Example

Multiple Selectors

Other Selectors

Pseudo-Classes

So much more...

Lab 1

• The specific requirements for the first lab, which may involve various packages and coding/programming tools

JavaScript

• JavaScript overview

JavaScript Looks Like Java

• JavaScript looks similar to Java

Dynamically Typed

Built in Data Types

String Template Literals

No enhanced-for, but

Interacting with the web page

The DOM

I want

Changing other data

Changing classes

Events

How do I add Javascript to my HTML?

Console/Debugger

Console

Inspect

So, so much more...

(Lab 1 details)

This quiz explores key concepts related to virtualization and containerization in the context of DevOps. It covers challenges in code deployment, advantages of virtual machines, and how containers improve resource efficiency. Test your understanding of these essential technologies and their roles in modern software development.