Week 1: The Software Development Lifecycle

Welcome to Software Engineering! Are you interested in learning
about software engineering? Does finding out more about the
software building process appeal to you? Would you like to get more information
about software development? Does learning about the basics
of programming interest you? Would you like to know more about
software architecture and design? Have you ever wondered what the job
prospects are like for a software engineer? If so, this course is for you! According to the most recent US Bureau of
Labor Statistics report about 1,850,000 software engineer type jobs are
posted annually in the US alone, and job growth in the industry is projected
to increase 22 percent through 2030, At the time of this course publication, the
median US software developer specialist salary is 110,140 US dollars annually, and
per hour pay is almost $53 US dollars. Software engineering jobs are also a great way to start on your path to a high-paying
career in information technology. This course has three instructors: Rav
Ahuja, Bethany Hudnutt, and Lin Joyner. Rav is a Global Program Director at IBM and
the architect for several IBM Professional Certificates. Bethany is an Instructional
Designer at Skill-Up Technologies. And, Lin is also an Instructional Designer
at Skill-Up Technologies. So, what’s in this course?
It’s divided into five modules: The Software Development Lifecycle Introduction to Software Development Basics of Programming Software Architecture, Design, and Patterns And Job Opportunities and Skillsets
in Software Engineering And when you complete this
course, you’ll be able to Describe software engineering and
approaches to software development. Identify software development
tools and technologies, Compare different types of programming languages
and recognize basic programming constructs, Outline approaches to application
and deployment architectures, And review the skills required in software engineering and describe the
career options it provides. During this course, you will learn through: guided instructional videos that walk you through
key concepts, with essential need-to-know facts. interactive exercises to reinforce
what you’ve learned in videos, insider viewpoints that enrich your
understanding of IT support work. practice assessments to help
you gauge your knowledge, and, finally, graded assessments
to prove what you’ve learned. Upon successful completion of this course, you’ll earn a shareable badge and certificate
that you can show to prospective employers. We’re here to support your success. If you have any questions for the course staff or if you want to connect with
your peers in this course, Please feel free to post on
the course discussion forums. We’re excited you’re here.
So, let’s get started!

Welcome to Meet the Experts. In this course, you will learn from several
experts in various roles, who will provide their insights and perspectives about Software
Engineering. Let’s meet these experts and learn about
where they work and what they do. Hi, my name is Kadesha. And I currently work as a developer advocate
at GitHub. My name is Liseidy Bueno. I’m a Software Engineer and I work at Blend,
also known as Blend Labs. My name is Tommy Young. I’m a software engineer at Google. My role is Uber Technical Lead overseeing
publisher video ads. My name is Diane Panagiotopoulos. I am a research and development engineer at
Bandwidth. And I work directly through Bandwidth, I am
not self employed as like a contractor with them. Hi, my name is Zubin Pratap. I’m a software engineer and currently I’m a developer advocate at
a Web3 startup My name is Daniel Rudnitski, and I’m a
full stack software engineer at IBM. My name is James Reeve and I’m a full stack
software engineer at IBM. Hi my name is Rupinder and I work as a Chief
Solutions Architect at Skillup Technologies. Hello, everyone, my name is Upkar Lidder and
I’m a developer advocate with IBM. Hi, I’m Yann Stoneham. I’m a solution architect at Smartronics. Now, lets listen to some of these experts
describe a little more in detail about what they do. Yes, so, a developer advocate is a software
engineer who enables developer to be successful with a product. That was a mouthful. So, essentially, what that means is, for example,
at GitHub, I create a lot of content. So I will do blog posts, workshops, go to
conferences to speak about GitHub, the product, I will also showcase developers in the open
source community, and to like, give publicity to the projects that they’re
working on. And being an advocate means that I’m able
to communicate deeply about technical concepts in a way that’s digestible for engineers across
experience level to understand. Before I was an advocate, I worked as a software
engineer in the finance sector for two years. I spent a majority of my time
coding, I primarily worked on the front end of the application, using tools such as Git,
Docker, GraphQL, React, JavaScript, and the very few times I would go into the back end, we use Node js on our back end to make changes
and updates. My experience as a software engineer, and
also as a technical content creator, paved the way for me to become a developer advocate
at GitHub today. I’m a software engineer right now. I’m still
pretty Junior. So most of my tasks involve creating new features,
fixing bugs, and addressing any customer concerns that we have with that they have with the
current software. Yeah, so, I work on a suite of products that
are they’re targeted to large content creators,
video publishers, customers, such as ESPN, Disney, etc. We basically have suites of tools to help
them monetize their video content, help them distribute it, help them target it appropriately,
report on it, troubleshoot it, for across all devices, all surfaces. So it’s kind of the full suite of products,
starts with the user interfaces that their sales teams and trafficking teams use to
sell the ad space, upload the creatives, the advertisements,
and, you know, target them to their audiences and contextually to the content that they’re,
that they create. We offer reporting on that. So, a lot of its performance and various other
analytics, reach analytics, and so forth. Previously, before this, I was a software
engineer at Google. And before that, I was a software engineer
at a small startup. But before that, for about over 15 years,
I was a corporate lawyer, and then a business executive for a while and even had my own
startup in the middle. So yeah, very diverse background. And I taught myself to code in my very late
30s. When my startup started to fail, and I really
needed to keep it going, and my tech co founder quit. So that’s what I do. That’s who I am today. I as a developer advocate, I not only write
code, I also produce a lot of educational content, and material that is useful for people
to onboard onto Web3 and other technologies. And my role is really to help connect the
product team with the actual developer ecosystem. Bring the two together through code content,
education and community.

Welcome to “What Is Software Engineering.” After watching this video, you will be able
to define software engineering, list the responsibilities of a software engineer, and compare and contrast
software developers and software engineers. Software engineering is the application of
scientific principles to the design and creation of software. The field uses a systematic approach to collect
and analyze business requirements in order to design, build, and test software applications
to satisfy those business requirements. When computing began in the late 1950s, software
engineering was a relatively undefined discipline, but over time it transformed into a modernized engineering
field. The software engineering field became a discipline
in the 1960s and evolved as new technologies were developed and the approach to software
development became more scientific. Trends in software engineering transformed
from ad hoc programming towards more formal and standardized methods. Initially, the creation of software lacked
a formal development process. As the world widely adopted computers, software
became increasingly integral to more aspects of life. The inefficiencies in the software development
process made it difficult to meet the rapidly increasing demand for computing resources
and complex software. This led to what is known as the “Software
Crisis” which began in the mid-1960s and lasted until the mid-1980s. During this period, software development often
ran over budget, behind schedule, and consisted of unmanageable, buggy code. By the time older software solutions came
to fruition, newer, better, and faster technologies had already been developed, causing software
engineers to have to refactor their code, or completely redesign their system. Often software development solutions that
worked for small software systems did not scale to large, complex projects. Now, Some of these issues still exist today, although
to a much lesser extent due to the consistent application of engineering principles to the
software development process. Computing resources have become more widely
available and standardized methodologies for software development allow for large, complex
solutions that scale. The solution to the “Software Crisis”
involved transforming unorganized coding efforts into an established engineering discipline. The mid 1980s also saw a rise in the growth
of computer-aided software engineering or CASE which also helped to relieve the software
crisis. CASE tools can be divided into six categories:
business analysis and modeling, development tools such as debugging environments, verification
and validation tools, configuration management, metrics and measurement, and project management. The term “software engineer” is often
used interchangeably with software developer but there are subtle differences. Software engineers are also developers, but
the term “software developer” is usually deemed narrower in scope than that of a software
engineer. A software engineer’s knowledge is usually
broader. Software engineers take a systematic, big
picture approach in their thinking to software development whereas developers may have more
creative approaches. Both software engineers and software developers
have specialized knowledge, but software engineers use that knowledge to build entire systems
whereas software developers use their knowledge to write code to implement specific functionality
within a system. Software engineers are often employed on larger
scale projects and they are focused on the broad structure rather than solving an immediate
problem. Software engineers are tasked with designing,
building, and maintaining software systems. Their Responsibilities include writing and testing
code, and consulting with stakeholders such as clients, third party software vendors, security
specialists, and other team members. The adoption of a measured, scientific approach
to software development has influenced the way software is created and designed. Today, the development process is typically
guided by the Software Development Lifecycle or SDLC. The SDLC identifies the steps needed to develop
high-quality software. Later in this module, we will discuss the
SDLC, the traits of high-quality software, and roles common in the field of software
engineering. In this video you learned that: Software engineering is the systematic approach
to design and development of software. Responsibilities of a software engineer include: Designing, building, and maintaining software
systems, writing and testing code, and consulting with stakeholders, third party
vendors, security specialists, and other team members. And finally, software engineers build systems while software
developers implement specific functionalities.

Welcome to Insiders’ Viewpoints:
What is software engineering? In this video, we will hear from experts discussing software
engineering. I think software engineering is the process
of using programming languages and engineering principles to build products. These products
could look like web apps, mobile apps, desk
top apps, operating systems, or even networking
systems. It is a skill that’s integral to the success of our modern society. Because
without technology, we couldn’t get a lot of things done today. Within software engineering.
It’s a very broad term. And so within software engineering, you have roles such as front
end, back end, security, mobile test, full stack, DevOps, cloud data, and machine learning.
And these are all different types of engineers within software engineering. I would define software engineering as building
and improving software from anywhere from design architecture to the user interface
to fixing small bugs. So anything that falls in that range, that’s what software
engineers do So software engineering, to me, I think really
has to do with, I consider it a creative process. And it’s fundamentally is the practice of
designing, envisioning implementing, and then supporting and maintaining software through
the full lifecycle of it. So not just writing code, but, you know, thinking about the software
you’re building before you even written a line of code, the the the journey from idea
inception to, to actual implementation and launching upset software and then maintaining
it, improving it, supporting it, and potentially evolving into something else. So it’s very
much a sort of creative and full, full lifecycle end to end engineering process. So I know in the United States, at least software
engineering, software development programming they all have, depending on who you ask, they
mean very specific things or very hazy things or very contradictory things. Or it’s like
why do we even have three different titles for the same thing. I think of those titles
is kind of all meaning the same thing. RECORD NARRATION: What s the difference between a software engineer
and a developer? Yeah, I think the difference for me, I consider
engineering to be a little bit sort of broader software engineer be broader than then development,
I think development to me means is sort of one part of the process. So I think one fundamental
difference for me is I think software engineering is beyond just writing code, which I think
a developer often is handed a task to, to write a piece of code, create a a module,
piece of software, whatever term you want to use, I think engineering involves sort
of starting, you know, a very long time before you even get to the development process and
continues on beyond the time you would actually take your code, deploy it. So this kind of
goes into the full lifecycle. In my opinion, there isn’t A difference really.
So for example, I was trained as a full stack engineer or a full stack developer, but I
was hired as a software engineer to work on the front end of the company’s application.
So I think it’s a matter of semantics. And a lot of it, I think, is a lot of gatekeeping.
To keep people who don’t know anything about about the industry out. Somebody who has
studied CS may argue differently from I do, but as a person with a non traditional
path into the world of software engineering, I only see it as like title changes and title
differences. And I think it depends on what company you work in, and what company you
work for. Because at the end of the day, we’re all using the same tools and technology to
get the product shipped to production . I think that they are pretty similar roles.
They are used interchangeably a lot, I think. But I think the main difference is that software
engineers are also responsible for the system design and architecture as well as data, how
it’s received, used, and how it’s disseminated. Whereas software developers, I think, focus
more on the building of apps and features. So, in Canada, being a computer programmer,
or a software developer is incredibly different than being a computer engineer or a software
engineer, where to be an engineer, it means you’ve taken specific classes in like codes
of ethics. And you’re held to the same ethical standards as a civil engineer or a mechanical
engineer. And so depending on where you are, the name, the titles can mean very different
things. And I know for purposes of immigration, the titles also can mean very specific things.
And you have to be careful about like, what it is that you put down. But in job descriptions,
I kind of see them all used interchangeably, and I tend to just kind of think of them all
as the same thing. The, you know, it’s much of a more of a longer
time horizon, I think, in front in terms of engineering versus development. I think there’s
a lot more considerations and hats you need to put on throughout the software engineering
lifecycle versus the kind of more narrowly scoped development cycle.

Welcome to the introduction to the software
development life cycle. After watching this video, you will be able
to describe what the software development life
cycle is, explain its history, and discuss some key advantages of using it. The Software Development Life Cycle, known
as the SDLC, is a systematic process to develop high-quality
software in a predictable timeframe and budget. The goal of the SDLC is to produce software
that meets a client’s business requirements. The SDLC defines phases of the software development
process that encompass their own process and deliverables. It is a cycle of planning, design, and development
that can be implemented as an iterative approach to software development. Adherence to the SDLC minimizes risks and
costs to the development of high-quality, deployable software. The software development life cycle began
to take shape in the mid-1960s as software development began to necessitate a more detailed
approach because of its growing complexity. The SDLC led to a more deliberate approach
as large corporations needed to manage complex business systems requiring heavy computational
resources. In its initial conception, it used what is
called the “waterfall method” to manage projects where the development of software
follows a linear pattern through discrete stages. The SDLC has since been adapted, however,
to more iterative methods in response to addressing customer needs and shifting requirements. Waterfall and other approaches to software
development will be discussed in another lesson. There are some key advantages for businesses
in following the SDLC. The first advantage is that it gives development
teams a process to follow rather than using an ad hoc approach to improve efficiency and
reduce risks. Secondly, there are discrete phases to the
SDLC. Each phase is well defined so that team members
know what they should be working on and when. The phases of the SDLC will be discussed in
another video. Because of the well-defined phases, it facilitates
communication between the customer, other stakeholders, and the development team. The SDLC offers an overview of the process,
so stakeholders know where they fit in to that process. Also, since each phase is discrete, cross-domain
teams know when they have completed their tasks and when development can move to the
next phase. The SDLC provides room for iteration where,
at the end of a cycle, the process can circle back to incorporate additional requirements
as needed. Problem solving is incorporated early in the
cycle so problems are addressed in a timely fashion and can be addressed in the design
phase rather than during coding. Finally, each team member has a well-defined
role which reduces conflict and overlapping responsibilities. In this video you learned that the SDLC provides a systematic process for
software development. Its initial development in the 60s and 70s
was driven by the need for a systematic approach because of the growing complexity of software. Key advantages of the SDLC include: A roadmap to the software development process,
helping to reduce risk and improve efficiency, Increased communication between the team and
stakeholders, Clearly defined and understood responsibilities
for each team member, and The ability to be used iteratively, allowing
for changing requirements.

Welcome to the Phases of the Software Development
Life Cycle. After watching this video, you will be able
to name the phases involved in the SDLC, describe each phase, and identify several tasks associated with each
phase. There are generally six phases in the SDLC
process, planning, design, development, testing, deployment,
and maintenance. Each phase is discrete meaning that tasks
from a previous phase do not overlap with tasks in the next phase. The original SDLC was conceived as a traditional
waterfall method where the phases are linear, but have since been adapted to introduce iteration
so that shifting requirements can be accommodated. Waterfall and other approaches to software
development will be discussed in another video. Note that some organizations may have different
names for each stage. For example, “planning” may be called
“requirements” or “strategy” or “analysis”. Also, some organizations may have additional
or fewer stages. In the first stage of the SDLC, the planning
phase, requirements are gathered, analyzed, documented and prioritized. When planning a software solution, the following
factors must be considered: users of the solution the overall purpose of the solution, data inputs and outputs, legal and regulatory compliance, risk identification, quality assurance requirements, allocation of human and financial resources,
and project scheduling. As part of the planning process, labor and material costs are estimated and weighed against time constraints. Also, project teams are identified, and roles
of each team member are proposed. If stakeholders are struggling to define requirements,
often the development team may produce prototypes during the planning stage to tease out those
requirements. A prototype is a small-scale replica of the
end product used to get stakeholder feedback and establish requirements. A prototype is used to test basic design ideas. Though prototyping usually occurs during the
planning stage, prototyping can occur at various phases of the SDLC whenever requirements need
to be reconsidered or clarified as the project develops. After requirements have been gathered, they
are combined into a document called a software requirements specification, or SRS,
document. The SRS needs to be clearly understood and
approved by all stakeholders. The developers are also involved at this stage
so they can gain a clear understanding of these requirements. Requirements and the SRS will be discussed
in more detail in a later video. In the design phase, the requirements gathered from the SRS are used to develop
the software architecture. Several team members work together at this
stage to design the architecture. The architecture is reviewed by the stakeholders
and team. And during this phase, prototypes can be designed. A prototype is a preliminary mock-up of the
system, or parts of the system, used for demonstration purposes. The document created in this phase is called
a design document, and is used by developers during the next phase, which is the development
phase. The development phase, sometimes called the
“building” phase or the “implementation” phase, is when the developers start the coding
process once the design document is completed. The project planners use the design document
to determine and assign coding tasks. This phase often requires the use of programming
tools, different programming languages, and software stacks. Organizations may also have standards or guidelines
that need to be followed. The testing phase is next in the process once
the coding is complete. And some large projects have dedicated testing
teams. Code needs to be thoroughly tested to ensure
it is stable, secure, and meets the requirements outlined in the SRS. Testing can be manual, automated, or a hybrid
of both. Product bugs are reported, tracked, and fixed,
and code is retested until the software is stable. Some common levels of testing include unit testing, integration testing, system testing, and acceptance testing. Each of these testing levels will be described
in further detail in another video. The deployment phase is where the application
is released into the production environment and made available to users. This can also happen in stages— first, it is released onto a user acceptance
testing, also called UAT, platform and once the customer signs off on the functionality, it is released to production. This approach can be used for making software
available on a website, mobile device app store, or a software distribution server on
a corporate network. Finally, the maintenance phase happens once the code
has been deployed into a production environment. This phase helps to find any other bugs, identify user interface issues, or UI for
short, and identify other requirements that may not have
been listed in the SRS. Code enhancements can also be identified at
this stage. If bugs are discovered in this phase that
were missed during testing, these errors may need to be fixed for high-priority issues
or incorporated into the requirements as part of a future software release and the process
can start over again. In this video, you learned that The SDLC can be divided into six phases,.Planning
involves requirement gathering and development of the SRS. The architecture is developed during the design
phase and the design document is created. The Development phase is when coding takes
place, and then during the testing phase issues with the code
are found and fixed if possible. Deployment is when the code is released to
the production environment. And finally, in the maintenance stage feedback
is collected from stakeholders, other UI issues may be identified, and code enhancements suggested. And this information then can be fed into another
software development cycle if necessary.

Welcome to Building Quality Software. After watching this video, you will be able
to: list common software engineering processes
and describe the common software engineering processes
required for building-high quality software. There are numerous processes that are common
to software engineering projects. In this video we will discuss six of them: requirements gathering, design, coding for quality, testing, releases, and documenting. The software requirements specification, or
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: functional, external and User Interface, or UI, system features, and non-functional. These categories are discussed in more detail
in another video. Software design is the process of transforming
the requirements into a structure that is implementable using code. The software design process translates the
requirements into a language the developers can use to write the code. It transforms the
requirements into a software solution. The technical lead breaks down requirements
into sets of related components with clearly defined behaviors, boundaries, and interactions.
These components define the system architecture. The system design incorporates guidance on
system functions, performance, security, and platform characteristics. The design communicates business rules and
application logic, application programming interface design, which is how apps talk to
each other or communicate with the database, user interfaces, and database design. Code quality refers to the characteristics
of the code including attributes such as maintainability, readability, testability, and security. Quality code must fulfill the intended requirements
of the software without defects. Additionally, it should be clean and consistent, easy to read and maintain, well documented, and efficient. Coding for quality entails following a set
of coding practices during development. These include: following common coding standards, conventions,
patterns and styles, using automated tools, known as linters, to
detect programmatic and stylistic errors, and commenting in the code itself to make it easy
for others to understand and modify. Software testing is the process of verifying
that the software matches established requirements and is free of bugs. Its purpose is to identify errors, gaps, or
missing requirements when compared with stated requirements. Properly tested software ensures reliability,
security, performance, and efficiency. Software testing can often be automated
or done manually. Levels of testing include unit, integration,
system, and user acceptance. Unit testing is often done by the developer
and tests the smallest component of code that can be isolated from the rest of the system. Once the components are integrated into the
larger product, integration testing occurs. Then, after the larger product is deemed completed,
system testing can take place. User acceptance testing, or UAT for short
and sometimes called beta testing, is when the software is tested by the intended end
user. Types of testing can broadly be divided into three categories, functional, non-functional,
and regression. Testing levels and types will be further explained in an upcoming video. When the newest version of the software is
distributed, it is referred to as a “release.” Different types of releases are intended for
different audiences. There is generally an “alpha,” a “beta,”
and a “GA” release. GA stands for general availability. The alpha release is the first functioning
version of the system released to a select group of stakeholders. The alpha release likely contains errors and may not contain the full feature set but does
contain most of the desired functionality. Design changes may still occur during this
release stage. The beta release, also called a limited release,
is given to the stakeholders outside of the developing organization. One of the intents of the beta release is
to try out the software under real conditions, test the functionality, and identify any
outstanding bugs or errors. The beta release should meet all the functional
requirements. Then, after beta release changes are agreed upon,
made, and tested, and a stable version is released. The audience for the GA release is all users. Software documentation should be provided
to both non-technical end-users and technical users. System documentation is geared towards the
technical user. Technical users may be other engineers, developers, or architects. System
documentation explains how the software operates or how to use it. It consists of README files,
inline comments, architecture and design documents, verification information, and maintenance
guides. User documentation is provided to the non-technical
end-users to assist them in the use of the product. Generally, user documentation is
provided in the form of user guides, instructional videos and manuals, online help, and inline
help. More details about documentation will be discussed
in another video. In this video, you learned that: Requirement gathering is collecting and documenting
the set of requirements that the software needs to adhere to. Designing transforms requirements into a structure
that developers can use. Coding for quality entails following a set
of coding practices during development. Testing is the process of verifying that the
software matches established requirements and is free of bugs There are three types of releases including:
alpha, beta, and general availability. And finally, documenting requires text or video that explains
the software to technical and non-technical users.

Welcome to Requirements. After watching this video, you will be able to: Describe the steps of the
requirement gathering process. Explain the purpose of a User Requirement
Specification, or URS, document. Explain the purpose of a Software Requirement
Specification, or SRS, document, and Explain the purpose of a System Requirement
Specification, or SysRS, document Requirement gathering is a six-step
process of defining a problem to be solved and documenting how to go about
solving that problem. These steps include: identifying stakeholders, establishing goals and objectives, eliciting requirements from the stakeholders, documenting the requirements, analyzing and confirming the requirements, and prioritizing. Generally, the stakeholders
work for the organization that requests the development of the software product. Key personnel from the organization may include decision-makers, end-users, system administrators, engineering, marketing, sales, and customer support personnel. It is good to have a representative from
every group that the product affects. The goals of the product
should be clearly defined. Goals are broad, long-term achievable outcomes. Goals can include customer
outcomes and business goals. Next, objectives should be identified.
Objectives are more specific than goals and they are actionable and measurable
actions that achieve the stated goals. The next three steps, eliciting, documenting, and requirement confirmation are
usually completed iteratively. Elicitation can be accomplished through surveys, questionnaires, and interviews. As the
requirements emerge, they should be documented and checked to ensure they align with the goals and objectives. Documented requirements should be easily
understood by stakeholders and the project team. In order to confirm the requirements, they should be analyzed to ensure consistency, clarity, and completeness. And after analysis, the
requirements should be shared with and approved by the stakeholders. After confirmation, requirements
should be prioritized. Labels such as “must-have,” “highly desired,” and “nice to have” are helpful. If possible, order
the requirements within those categories. Typically, there may be three documents that
result from the requirements gathering process: software requirements specification, or SRS, user requirements specification, or URS, and system requirements specification, or SysRS. The most common of these is the
software requirements specification. The software requirements specification, or SRS, is a document that captures the functionalities
that the software should perform and also establishes benchmarks or
service levels for its performance. Parts of an SRS include: A purpose statement that contains the intended use of the SRS, its audience and scope, constraints, assumptions and dependencies, and requirements, which can be
sorted into four categories: Functional requirements External Interface requirements System Features Non-functional requirements The product’s purpose describes who will have access to the SRS and how they should use it. The scope describes the benefits of the software, its goals, and objectives. The second part of the SRS should detail
constraints, assumptions, and dependencies. Constraints describe how the product must
operate under given conditions that may limit options in the design phase such as
conformation to standards or hardware limitations. Assumptions may include things like a required operating system or hardware that is
needed by the software to function. Dependencies on other software
products should also be noted. Requirements can be classified
into four categories. Functional requirements are those that
cover the functionalities of the software. External requirements are the requirements
that address the behavior of the software in relation to external entities such as users
and interactions with other hardware or software. System features are a subset
of functional requirements. These are required features
for the system to function. There are also non-functional requirements
such as specifying performance, safety, security, and quality standards. User requirements describe the
business need and expectations of the end-users from the software system. The user requirements are
written as “user stories” or “use cases” that answer three questions: Who is the user? What is the function that needs to be performed? Andhy does the user want this functionality? User acceptance testing determines
if these requirements have been met. Often though, the user requirements
and software requirements are combined into a single SRS document. The SRS details
the expectations of the software system. The System Requirement Specification
document, or SysRS, to differentiate it from the SRS, clearly outlines the requirements
of an entire system. The system requirement specification is often used interchangeably
with software requirement specification, but the SysRS is actually
broader in scope than the SRS. Many software projects develop
an SRS rather than a SysRS. The SysRS contains system capabilities, interfaces, and user
characteristics. It also may include policy requirements, regulation requirements, personnel requirements, performance requirements, security requirements, and system acceptance criteria. It also outlines expectations of
the hardware needed for the system in addition to software requirements. In this video you learned that: The requirement gathering process entails
identifying stakeholders, establishing goals and objectives, and eliciting, documenting,
confirming, and then prioritizing requirements. The SRS documents functional, external,
system, and non-functional requirements. The URS documents user stories. And finally, the SysRS documents system
capabilities and acceptance criteria, and policy, regulation, personnel, performance,
security, and hardware requirements.

Welcome to Software Development Methodologies. After watching this video, you will be able
to list several commonly used approaches to the
software development life cycle, explain waterfall, V-shape model, and Agile
methods, and compare the pros and cons of each of these
three methods. There are many ways to approach software development. A specific methodology for developing software
is commonly used in order to assist the development team to clarify communication among team members
and determine how and when the information is shared. In this video, we will discuss three of these
approaches: Waterfall, V-shape model, and Agile. In the beginning, when the SDLC was conceived,
it implemented what is known as the waterfall method. Waterfall is a sequential method of software
development where the output of one phase is the input for the next phase of the cycle. Development and work on the next phase start
only after the completion of the previous phase. All planning, such as defining requirements
and architectural design, is done up front. The customer usually does not see the product
until it is in the testing phase. For a major version release of the product,
the same process is repeated resulting in long intervals, such as years, between releases. The V-shape model is named as such because
the phases form the shape of a V. The phases going down the left side of the
V are called “verification”. Then, going up the right side of the V, those
phases are called, “validation.” The V-shape model is like waterfall in that
it is also sequential. Each phase in verification corresponds with
a validation phase. There are four stages that occur on each side
of the V. Going down the V are planning, system design, architecture design, and then module
design. The bottom of the V is the coding phase. And going back up the V are the four phases that
correspond to the phases going down the V: unit testing, integration testing, system testing, and acceptance testing. The tests are written during the verification
phases on the left and executed during the validation stages on the right. Now, the Agile model is different. It focuses on a collaborative software development
process over multiple short cycles rather than a strictly top-down linear process. Agile is what is called an iterative approach
to development. It still aligns with the SDLC, but each phase
is short. Teams work in cycles, or sprints, which are
usually one to four weeks long. Unit testing happens in each sprint to minimize
the risk of failure. Rather than the “maintenance” stage of
the SDLC, the final stage of the sprint is a feedback stage. At the end of each sprint, a chunk of working
code is released at a meeting called the “sprint demo” where stakeholders can see the new
functionality and provide feedback. After the sprint demo, the entire process
is repeated for every sprint cycle. After several sprint cycles, a minimum viable
product, or MVP, is developed so stakeholders can provide feedback on the basic feature
set. The MVP contains a feature set to validate
assumptions about the software. The four core values of Agile development
outlined in what is known as the “Agile manifesto” are: individuals and interactions over processes
and tools working software over comprehensive documentation customer collaboration over contract negotiation,
and responding to change over following a plan. The main difference between traditional SDLC
methods such as waterfall and the v-shape model compared to
the Agile method of software development is the
former are sequential whereas Agile is cyclical. Traditional SDLC methods, such as waterfall
and V-shape, center around the whole product being developed before soliciting customer
feedback, whereas Agile focuses on quick, short bursts of development. There are pros and cons to each method, though Agile is probably
the most popular method used in modern software development. Regarding the pros of the waterfall method,
it is easy to understand and follow. Each stage is discrete and well-defined, making
it easy for all team members to understand their roles. Also, since planning is done upfront, it is
easier than iterative methods to estimate a budget and allocate resources. That said, waterfall lacks flexibility. Since all planning is done upfront if a requirement
is changed or overlooked that change can be hard to incorporate at a later date. Inevitably, unforeseen complications happen,
or agreed upon functionality shifts from what was initially envisioned. Like waterfall, the V-shape model is simple
and easy to use. It is even more rigid than waterfall but designing test plans during the verification
phase saves considerable time during coding and validation phases. Drawbacks are also similar to waterfall because
it does not readily accommodate changing requirements. Once an application is in the testing phase
it is extremely difficult to go back and change functionality. Agile development is different, relying on
ongoing research, planning, and testing during product development. When adding new features to a project, development
still goes through the same phases as in traditional SDLC, but with Agile, new, and changing requirements
are handled quickly and easily because planning is initiated at the beginning of each sprint
cycle. Most resources are spent on the building phase. At the end of each cycle, the QA team, stakeholders,
and the customer have some piece of working code to test against requirements and are
encouraged to provide feedback. As coding languages and technologies have
developed in recent years, they now allow for modular design, where developers can focus
on smaller chunks of code that are readily integrated into the larger product. These small chunks can be released to provide
the MVP. Cons of Agile are that upfront planning such
as budgeting and scheduling can be challenging because the overall scope of the product is not clearly
defined. In this video, you learned that: Three of the common approaches to software
development include waterfall, V-shape model, and Agile waterfall and V-shape are sequential whereas
Agile is iterative both waterfall and V-shape models are easy
to implement but neither accommodates changing requirements well and Agile allows for changing requirements but
resource allocation can be challenging.

Welcome to Software Versions. After watching this video, you will be able
to: Discuss software versions on computing platforms and identify software versions and numbering. Software versions tell us a lot about programs
and applications. Users can determine what software version
they are using, and developers can provide useful information with version numbers. Software version numbers vary in length and
meaning; however, most version numbers follow a similar format and represent similar information. Version numbers indicate when the software
was released, when it was updated, and if any minor changes or patches were made to
the software. Software versioning is how software developers
keep track of new software, updates, and patches for programs and applications. Version numbers can be displayed in several
ways. Version numbers can be short or long, depending
on the software and the preference of the developer, with 2, 3, or 4 number sets. Each number set is divided by a period. The first release of an application or program
might have a 1.0 as the version number to indicate no updates, patches, or fixes to
the software. Note: A version still in beta or testing could
have a version number lower than 1, such as 0.9. A program or application with many releases
and updates will have a longer number, sometimes 4 different number sets within the version
number Some software developers may use dates for
their versioning. For example: Ubuntu Linux version 18.04.2
was released in 2018 April. The third number set, point-2, designates
an additional change or update. What do these numbers mean? Some version numbers follow the semantic numbering
system and have 4 parts separated by a period, but not all numbering systems follow this
4-part example. In semantic numbering, the first number indicates
major changes to the software, such as a new release. The second number indicates that minor changes
were made to the software. The third number in the version number indicates
patches or minor bug fixes. Finally, the fourth number indicates a build
number or a build date, and it can indicate less significant changes made. Software version numbers are identified in
the About or Help section of software. You can practice identifying your version
number in a web browser. This example illustrates how to view the version
number in the Google Chrome desktop web browser; however, if you are using a different web
browser, you should be able to follow the same or similar steps. To view the browser version: First, select the three dots or three lines
in the top-right corner of your browser. Next, select the menu item “Help.” Then, select “About” to view the version
information. The version of your web browser will display. Are newer versions of software compatible
with older versions? Lack of compatibility between old and new
versions of software is a common problem. You can troubleshoot compatibility issues
by viewing the software version to determine if you are using an outdated version of the
software. Sometimes updating software to a newer version
will resolve compatibility issues. Some software is backwards compatible. If a program or application is backwards compatible,
then the older versions of files, programs, and systems will work properly with newer
versions. In this video, you learned that: Version numbers indicate the history of changes,
updates, and patches to software, Some version numbers follow the semantic numbering
system and have 4 parts separated by a period, Compatibility with old and new versions of
software is a common problem, and you should view the version of the software
you are using to determine software compatibility.

Welcome to Software Testing. After watching this video, you will be able
to: Define the terms functional testing, non-functional
testing, and regression testing, and compare and contrast typical testing levels. Software Testing is the practice of integrating
quality checks throughout the software development cycle. The purpose of testing is to check whether the software matches expected
requirements and ensure error-free software. In order to test software, the team writes
“test cases.” These test cases are written to verify the
functionality of a software application and ensure requirements have been satisfied. Test cases can be written in different stages
of the SDLC and may vary depending on the type of test or the method used to develop
the software, such as Agile or waterfall. A test case contains: steps, inputs, data, and the expected corresponding outputs. Regardless
of the test type or development method, test cases should always be written after requirements
are finalized. Software testing helps evaluate the software
to identify whether or not the software product meets requirements and is error-free. Types of testing can be broadly classified
into three categories: Functional testing, Non-Functional testing, and Regression testing Functional testing usually involves black
box testing which is a method of testing without looking at source code or internal
structure. Functional testing is only concerned with
inputs and corresponding outputs of the system under test, also called
the SUT. It is entirely based on testing functional requirements. Functional testing can be carried out manually
or using automated tools. The goal is to test the functionality of the
application making sure the application is usable and accessible. Functional testing tests the SUT,
to make sure it meets functional requirements. Functional testing makes sure that when
user errors or input edge cases do occur, the software handles those exceptions seamlessly
by displaying appropriate error messages. Non-functional testing includes testing the
application for attributes like performance, security, scalability, and availability. Non-functional testing checks
to see if the SUTs non-functional behavior is performing properly. Non-functional testing should answer questions
like the following: How does the application behave under stress? What happens when many users log in at the
same time? Are the instructions in documents and user
manuals consistent with the application’s behavior? Does the application behave similarly under
different operating systems? How does the application handle disaster recovery? And how secure is the application? Regression testing, also called maintenance
testing, confirms that a recent change to the application, such as a bug fix, does not adversely affect already existing functionality. Regression testing should occur when there
has been a change in requirements or when defects have been fixed. In order to conduct regression testing, all
or some of the test cases should be selected to test against the application. Regression
test case selection and prioritization can be challenging and can depend on several factors. Common reasons for regression test case selection
include cases that: have frequent defects , contain frequently used functionality, contain features with recent changes, or are complex test cases, edge cases, and randomly successful or failed test cases. Now that we have discussed different types
of testing, let’s discuss testing levels. There are four testing levels: unit, integration, system, and acceptance. Each level occurs at a different time in the
SDLC. There are 4 different levels in order to reduce the amount of time spent on testing
by preventing overlap. We will discuss each of these testing levels next. Unit testing refers to tests that verify the
functionality of a specific section of code, usually at the function level. It is performed by the software developer
or engineer during the development phase of the software development life cycle. Unit testing aims to eliminate construction
errors before code is integrated with other modules. Unit testing is intended to increase
the quality of the resulting software as well as the efficiency of the overall development
process. Integration testing seeks to identify errors when two or more
smaller, independent code modules are combined. Integration testing is another type of black-box
testing. Prior to integration testing, smaller,
independent code modules that passed unit testing are incorporated into the larger software
application. After modules are integrated together, then
integration testing can occur. Integration testing exposes bugs that occur
when those smaller units of code interact with each other. Integration testing uncovers deficiencies
in communication with a new module in conjunction with other existing modules, databases, or external hardware. Integration testing uncovers
situations where bugs develop due to differing programming logic between modules, for instance.
Also, sometimes during module development, requirements change, and the module isn’t
fully unit tested. Poor exception handling can cause problems when modules are integrated
together. System testing occurs after integration testing
and is conducted on a complete, integrated system to evaluate the system’s compliance with its
specified requirements. It validates the system as a fully completed
software product. System testing is both functional and non-functional. System testing is done in a staging environment,
which should be similar to the production environment. And finally, acceptance testing is formal testing with
respect to user needs, requirements, and business processes. It determines whether a system
satisfies the needs of the users, customers, and other stakeholders. Acceptance testing is
usually done by the customer or the stakeholders during the maintenance stage of the SDLC. In this video you learned that: There are three categories of testing: functional,
non-functional, and regression . Unit testing verifies small, independent chunks
of code. Integration testing looks for errors when
two or more small chunks of code are combined. System testing validates the system as a fully
completed software product and acceptance testing verifies correct implementation
of user requirements and business processes.

Hello and welcome to Software Documentation. After watching this video, you will be able
to: List documentation formats. Compare and contrast product documentation
to process documentation. Describe the categories and types of documentation. And explain the purpose of standard operating
procedures. Software documentation is information about
the software that describes what the product is and how to use it. These can be written, video, or graphical assets associated with a software
product’s development and use. Documentation can be in any of these three
formats. Documentation is an essential aspect of software
engineering applicable across all the phases of SDLC. Software Documentation can be written for
different types of audiences – such as end users, software developers, QA engineers,
system administrators and other stakeholders. Documentation can be divided into two categories,
product and process. Product documentation relates to the product’s
functionality, whereas process documentation describes how to complete a task. Process documentation should provide the requirements
for the quality implementation of a business process. Now, let’s discuss some specific types of
product documentation. There are many types of documentation, and we
will discuss five categories including requirements, design, technical, quality assurance, and user documentation. Requirements documentation is written during
the planning phase of the SDLC and is intended for the development team including the developers,
architects, and QA personnel. Requirements documentation describes the expected
features and functionality of the software system. It includes the software requirements specifications,
system requirement specifications, and user acceptance specifications. Design documentation is written by the software
architects and the development team to explain how the software will be built to meet the
requirements. It consists of both conceptual and technical
design documents. Technical documentation includes comments
written in the code to help other developers read the code to understand its behavior.
It also may include working papers that explain how the code works and documents that record
engineers’ ideas and thoughts during project implementation. Quality assurance documentation includes all
documents that pertain to a testing team’s strategy, progress, and metrics. Types of test documentation include test plans,
test data, test scenarios, test cases, test strategies, and traceability matrices. Traceability
matrices map test cases to their requirements. User documentation is intended for end-users
and explains how to operate the software or help them to install or troubleshoot the system. End-user documentation includes frequently
asked questions, installation and help guides, tutorials, and user manuals. Standard operating procedures, called SOPs,
often accompany process documentation. Process documentation provides an overview
of a process, but SOPs go through much greater detail. The SOP is written documentation that
explains step-by-step how to accomplish a common, yet complex task that is organization
specific. For example, checking in code using a code repository is common knowledge for
a software engineer. However, an organization might have specific
steps to follow for that organization in order to get code merged into the main branch. The SOP documentation explains those steps
in detail. SOPs can be in the form of a flowchart, a hierarchical outline, or step-by-step instructions. Documentation, in any form, must be kept up
to date. Take for instance online user manuals. If a cloud-based application user interface
changes, then the accompanying online documentation must be updated accordingly. Businesses need
to ensure they allot resources for this step. With regards to the software development and
the SDLC, updating documentation happens during the maintenance phase. Ideally, documentation should also be reviewed
periodically to ensure its accuracy. In this video you learned that: Documentation comes in three formats: written,
video, or graphical. Process documentation describes how to complete
a task. Product documentation relates to how a product
functions. The types of product documentation include
requirements, design, technical, QA, and user. And SOPs are written instructions detailing
an organization’s specific procedure.

Welcome to Roles in Software Engineering Projects. After watching this video, you will be able
to list the common roles on a software engineering
project, describe each role, and
explain the responsibilities of each role. There are several common roles on a software
development project. And these roles can have different names depending on the approach
being used, such as Agile or waterfall. Sometimes different companies have different names for
similar jobs. But, not all projects will have all these roles. The roles we will discuss
in this video are project manager or scrum master,
stakeholder, system or software architect,
UX designer, software developer,
tester or QA engineer, site reliability or Ops engineer,
product manager or owner, and technical writer or information developer.
Now let’s describe each role and some of the responsibilities for each job. Traditional SDLC methods have
project managers but in Agile the equivalent role is called a
Scrum master. A project manager makes sure the project runs smoothly and facilitates
communication about the project. The project manager often deals with bigger picture issues
such as: Planning, scheduling, and budgeting;
Allocating personnel and resources; Executing the software plan; and
Team communication. In Agile, there is a Scrum master. Rather
than focusing on planning, the Scrum master is focused on ensuring team and
individual success. Remember that the four core Agile values
prioritize people and communication over process, and the Scrum master is
responsible for facilitating that communication. The stakeholders are the
people for whom the product is being designed. They include individuals such as the customer,
end-users, decision-makers, system administrators, and other key personnel.
The stakeholder is mainly responsible for defining project requirements and
providing feedback if the team members need clarification on requirements or if a proposed solution
cannot be solved as planned. The stakeholders may also sometimes participate
in beta testing and acceptance testing before the software is released. The system architect,
designs and describes the architecture of a project as well as communicates that architecture
to team members. They are sometimes also called a software
architect or a solution architect. They are responsible for
designing the essential characteristics of the inner structure and
technical aspects of the software. The architect provides
technical support across the different stages of the SDLC. Note: software architecture will be discussed
in further detail in another module. UX means user experience.
The goal of a UX designer is to balance making the software intuitive but also as robust
as it needs to be to address requirements. They define how the software behaves from
the user’s perspective. The UX designer determines
how the software communicates its functionality to the end-user and
how the end-user interacts with it. Next, the developers
write the code that powers the software. Responsibilities include
implementing the architecture laid out in the design document,
incorporating the requirements laid out in the software requirements specification, and
employing the UX requirements determined by the UX designers. Testers or QA engineers are
in-charge of ensuring the quality of the product and that the software solution meets customer
requirements. They are responsible for
writing and executing test cases to identify bugs or deficiencies and
provide this feedback to the development teams. A site reliability engineer, sometimes called
an SRE or ops engineer, bridges development and operations by combining
software engineering expertise with IT systems management.
They track incidents and facilitate meetings to discuss them.
They also automate systems, procedures, and processes;
assist with trouble shooting; and ensure reliability for the customer. The product manager or product owner has the
vision of what the product should look like. They have an intimate
understanding of the client’s requirements, and the end-user’s needs. They are
responsible for leading development efforts to create the
software and for ensuring the product provides the value
stakeholders are looking for. Finally, the technical writer or information
developer writes documentation for the end-user. They
write documentation on technical material geared towards a non-technical
audience. Not only does this documentation help the end-user to use the software, but
it also helps the customer so they can provide timely feedback to the development teams.
Technical writers may be asked to write user manuals, reports, white papers, and press releases. In this video you learned that:
There are a variety of job roles on a software development project and
each occupation has responsibilities unique to each role.

Welcome to Insiders’ Viewpoints: Job Roles
in Software Engineering Teams. In this video we will hear from experts discussing
the various job roles you can expect to work with on your Software Engineering team. On the engineering team I worked with,
we had a product manager, we had a tech lead, we had a QA, we had a few QA analysts or test
engineers. And we also had access to UX designers. And so the product manager ensured that we
were on task and on track to deliver the features that we said we were going to build according
to the business needs, that way we’re not left behind. Yeah, I think, in my experience, the
roles that the software engineers would interact with the most, I think would, you know, in no
particular order product managers, so the folks who are actually sort of working with
the sales teams, the marketing teams, figuring out what actually needs to be built, what
our customer needs, what are innovations and ideas that, you know, looking forward, that
we might, you might want to invest in and build out. We asked our experts to describe these job
roles in software engineering teams in further detail I think software engineering these days, as
it becomes more and more, more more and more large scale, more complex more systems at
play. More considerations, there’s just a lot of
things to consider in today’s in today’s world as a software engineer, so you often work
with a project or program manager who helps you set up your timelines, helps
you ensure you’re meeting your goals, helps you unblock yourself helps you keep your stakeholders
community up to date with what is what is happening with your project. So there’s just a lot of pieces involved. And I think project and program managers really
are there to help tie it all together. So the product manager would always act
somewhat like a scrum master. So like, we would have stand ups. And we would talk about the tickets that we
had in JIRA. And it was it was like, okay, so what are
you working on? What do you need help with? And are there any issues. And during that process, the product manager
does ensure that we were on task and on track, and if we had any issues, he would help us
to resolve it. You’ll have a software engineer who’s more
focused on the architecture and they can keep the the big picture in their brain more easily. And then some software engineers who are more
than nitty gritty, I’m sitting down and I am writing code and my my job is to like,
turn business logic into computer logic. And some companies have those all split out
as different roles. I think software engineers, and then these
roles that the more they’re embedded and work closely together and actually collaborate
as part of a single team. versus handing off things in a more waterfall
approach. I think that that’s generally the the best
way, or was one of the most effective ways is to actually work together as much as possible
regular check ins, actually having, you know, brainstorming sessions, group chats that involve
all the various folks, all the roles, I think, close collaboration, there is super key And at some companies, all the different hats
have their own titles. So you might be talking to a software engineer
who’s actually doing more kind of DevOps infrastructure building, monitoring and alerting kinds of
work. And then there’s a software engineer who’s
also doing QA work. And they’re the ones who are focusing on pipelines
and continuous continuous development, continuous integration type projects, working on getting
test suites and automation all set up. In terms of working with the UX designer or
the UX engineer, they would give me like specific specs from figma. In order to meet the certain specifications
of the business, it’s let’s say, we’re building a checkout page. So the UX UX designer would design the spec
page and figma and then deliver that spec to me, and then I would code it according
to the design. UX designers who actually come up with it,
if you work, if you’re working on an engineering or user interface, you work with UX designers
to, to essentially from the moment of sketching out sort of a, you know, a draft on paper
or whiteboard of an idea all the way down to working with them on mocks and implementing
the mocks iterating. On those UX researchers often are worked with
when you actually need to go out and do research and market and interview your partners or
customers to get sort of as real time as possible. And just, you know, real feedback from real
users of your, of your software. So once I code something, I get it reviewed
by my tech lead or my senior engineer, it would go to QA for them to test the application
to ensure that whatever I did or implemented, didn’t break anything. If something is broken, that I didn’t catch,
the QA tester would write up like a test plan or would do like a detailed testing document. That way I understood exactly what needed
to be resolved. And I would resolve it, and then go back to
the QA person and say, Hey, this is fixed, can you take a look at it again, and they
would tell me whether or not it’s fixed and whether or not something else was broken,
which often happens with code. So you know, you generally work a lot with
product managers, because you need to know what to build. And they generally give you a lot of guidance
on, on what they want to build, and you collaborate with them in terms of how to build it and
discuss trade offs and timelines, and expectations. So it’s a very much a collaborative process. Typically, I have found that I interact most
with product owners. So either at some places, it’s been a customer
who works inside the company. And so I go to them quite frequently for questions
on clarifying refinements for getting test schedules up and running for figuring out
pain points and trying to optimize their workflow workflows using technology to support them. Software engineers work often with site reliability
engineers, or Sysadmins is maybe there, the role could be called to actually maintain
and help run the software and deploy it and actually get it running somewhere that’s not
on your desktop, you often work with more dedicated test engineers who are responsible
for end to end testing, automated testing, integration testing, at all, at all points
of the lifecycle. So as an engineer, you’re never alone. You’re never working alone. It’s just a matter of like knowing how to
communicate directly with the people on your team