The document provides an overview of the software development lifecycle (SDLC). It describes the SDLC as a framework that development teams use to systematically produce high-quality software. The SDLC involves gathering requirements, design, implementation, testing, deployment, and maintenance stages. It also discusses stakeholders, attributes of good software like usability and functionality, and the importance of software engineering principles.

1. Introduction to Software
Development Life Cycle
SD 104
By Godwin S. Monserate

2. What is the Software Development
Lifecycle?
• The software development lifecycle (SDLC) is a framework that
development teams use to produce high-quality software in a
systematic and cost-effective way. Both large and small software
organizations use the SDLC methodology. These teams follow
development models ranging from agile to lean to waterfall and
others.
• The software development lifecycle gives organizations a systematic,
step-by-step approach to developing successful software from
gathering the initial requirements for a new product. We’ll teach you
how to employ SDLC by maintaining a mature product on the market.

3. Origins of the Software Development Lifecycle
• SDLC began as the “systems development lifecycle” in the 1960s.
• Large corporations developed the model to help manage complex
business systems that required a lot of data processing and analysis.
• Over time, variations of the framework have been adopted for the
development of hardware and software technology products and
other complex projects.

4. Software Development
• Software development is a complicated process. It requires careful
planning and execution to meet the goals.
• Sometimes a developer must react quickly and aggressively to meet
everchanging market demands.
• Maintaining software quality hinders fast-paced software
development, as many testing cycles are necessary to ensure quality
products.

5. Life Cycle of a Software Development Project
• Software development is a complicated process comprising many
stages.
• Each stage requires a lot of paperwork and documentation in addition
to the development and planning process.
• This is in contrast to the common thinking of newcomers to the
software industry who believe that software development is just
“writing code.”
• Each software development project has to go through at least the
following stages:

6. Life Cycle of a Software Development Project
• Requirement gathering
• Writing functional specifications
• Creating architecture and design documents
• Implementation and coding
• Testing and quality assurance
• Software release
• Documentation
• Support and new features

7. SDLC Model
• There may be many additional
steps and stages depending
upon the nature of the software
product.
• You may have to go through
multiple cycles during the
testing phase as software testers
find problems and bugs and
developers fix them before a
software product is officially
released.

8. Importance of Software Engineering
• Software engineering is the study of and practice of engineering to
build, design, develop, maintain, and retire software.
• There are different areas of software engineering and it serves many
functions throughout the application lifecycle.
• Effective software engineering requires software engineers to be
educated about good software engineering best practices, disciplined
and cognizant of how your company develops software, the operation
it will fulfill, and how it will be maintained.

9. Software Engineering Code of Ethics
• The Software Engineering Code of Ethics focuses on providing high-quality
software. They are committed to analyzing, specifying, designing, developing,
testing, and maintaining software that is beneficial and effective for the company
or client.
• According to the Association for Computer Machinery, the Software Engineering
Code of Ethics is as follows:
1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests
of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications
meet the highest professional standards possible.

10. Software Engineering Code of Ethics
3. PRODUCT - Software engineers shall ensure that their products and related modifications meet
the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional
judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an
ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession
consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their
profession and shall promote an ethical approach to the practice of the profession.

11. Application domain
• An application domain is a mechanism (similar to a process in an
operating system) used within the Common Language Infrastructure
(CLI) to isolate executed software applications from one another so
that they do not affect each other. Each application domain has its
own virtual address space which scopes the resources for the
application domain using that address space. (Wikipedia)

12. Application domain
• One of the prerequisites for the development of a software system is that
we have a definition and a clear understanding of the contents of the
application domain concerned.
• This is the part of an organization for which we are to develop application
software. This means that the application domain is our starting point and
the context for our software development.
• Many development methodologies take this understanding of the
application domain for granted.
• They assume that the developers somehow know what domain they have
to deal with. In our experience, however, this is a crucial issue within a
software project, so we make it explicit in our application-oriented
approach.

13. Definition: Application Domain
• Application domains can either be very extensive or very
limited. In this book, we see application domains mainly in the
context of commercial or governmental organizations, but they
could easily be in social or private organizations.
• Application domains include banks, insurance companies, or
hospitals. Equipment management for a small software
company is our main example. Internet applications have
become increasingly important, especially for the home and
entertainment domains.

14. Definition: Application Domain
• An application domain is the segment of reality for which a software
system is developed. It is the background or starting point for the actual-
state analysis and the creation of a domain model.
• An application domain can be an organization, a department within an
organization, or a single workplace.
• The concept of an application domain is at least as wide, so that the
domain concepts and relations relevant for the construction of models can
be well understood during the analysis of the actual state of the domain.
On the other hand, its extent should always be limited, that is, never be too
complex.
• An application domain normally includes a domain-specific language. This
means that people in this domain use specific terms and concepts and
think about their domain in a specific way.

15. What is a software Stakeholders?
• Stakeholders are individuals, groups, or organizations that are actively
involved in a software project, can influence it due to their position, and
whose interests may be affected by the success or failure of the
project. Stakeholders can have different degrees of responsibilities and
authority that may change throughout the software development lifecycle.
• For example, end-users usually indirectly affect the project. However, if
users take part in testing, they may change their roles and directly impact
the further project development processes.
• All software project stakeholders can be divided into two groups: primary
and secondary. Such classifying helps to prioritize the interests of groups
involved in the project and improve decision-making. Who are the primary
and secondary stakeholders in a software project, and what is their role in
the development of the project?

16. Primary stakeholders in a software
project
• Primary stakeholders have a direct impact on your software
project. They are people, groups, or organizations that have the
strongest voice and can gain or lose their income.
• Knowing and understanding primary stakeholders’ interests can
ensure high performance and the best decisions for your
product.

17. Primary stakeholders in a software
project

18. Primary stakeholders in a software
project
• Customers
• Customers determine the main requirements and project scope as well as
sign contracts with the main project performers. They always interact with
the team, approve or supplement the plan with new implementation points.
• Project Managers
• Project Managers control the entire project creation process, considering
the interests and needs of all stakeholders. Their main interest is to create
a solid product on time and within budget, making customers satisfied.
They lead a development team and supervise the project implementation
processes, making necessary adjustments.
• Business Analysts
• A BA team analyzes the customer’s ideas, communicates with the
development team, and determines project scope and requirements. They
make predictions to understand the project budget and time as well as
create project decomposition.

19. Primary stakeholders in a software
project
• Development Team
• Developers as stakeholders are responsible for timely software delivery
and estimation. Based on their experience and innovation trends, the
developers can provide stakeholders with advice on business idea
implementation and quality estimation needed to understand the scope of
work and resources needed.This group also includes QA engineers who
define bugs to meet specified requirements and prevent failed user
scenarios.
• Designers
• UI&UX designers make the product interface user-friendly and
understandable. They understand that a user comes to the site or works
with the application to solve a specific problem. Therefore, designers make
customers get what they want quickly and easily.
• Primary stakeholders can also be represented by project sponsors,
marketing teams, business partners, suppliers, etc.

20. Secondary stakeholders in a software
project
• Secondary stakeholders have an indirect relationship with a
software development process. They do not have any direct
engagement with a project or a company but can indirectly
affect decisions related to your software product and its
reputation.
• The role of secondary stakeholders should not be undermined
because their identification is crucial for the continuous
improvement of the product.

21. Secondary stakeholders in a software
project

22. Secondary stakeholders in a software
project
• End-users
• Every product has its target audience, whose needs and desires affect the design
and functionality of the system. Users can be engaged as stakeholders in testing
product beta-version to provide the initial feedback. They can point out missing
features and contribute to user experience improvement.
• Government
• The state, represented by the regulatory authorities, can also be a stakeholder.
Regulators adopt international standards that influence the development of a
software product and impose fines for non-compliance with the rules.
• Competitors
• Competitors always implement new features and create industry trends affecting
the market. Thus, your competitors can influence the prioritization of tasks
creating new unexpected challenges to respond to.

23. Secondary stakeholders in a software
project
• Secondary stakeholders can also include the media, consultants, or IT
company employees who are not working on the project.
• Stakeholders in a software project are people or organizations who
have their goals, desires, and biases about software implementation.
Identification of key stakeholders can help you more clearly see social
connections, hidden dangers, and business prospects.

24. Basics of Software Attributes
• Software is defined as a collection of computer programs, procedures,
rules, and data. Software Characteristics are classified into six major
components:
• Software engineering is the process of designing, developing, testing,
and maintaining software. The characteristics of software include:
1.It is intangible, meaning it cannot be seen or touched.
2.It is non-perishable, meaning it does not degrade over time.
3.It is easy to replicate, meaning it can be copied and distributed easily.
4.It can be complex, meaning it can have many interrelated parts and features.
5.It can be difficult to understand and modify, especially for large and complex systems.
6.It can be affected by changing requirements, meaning it may need to be updated or
modified as the needs of users change.
7.It can be affected by bugs and other issues, meaning it may need to be tested and
debugged to ensure it works as intended.

25. ISO/IEC 9126 Software engineering

26. Portability/Availability
• This attribute is indicative as to whether an application will execute
the tasks it is assigned to perform.
• Availability also includes certain concepts that relate to software
security, performance, integrity, reliability, dependability, and
confidentiality.
• In addition, top-notch availability indicates that a software-driven
system will repair any operating faults so that service outage periods
would not exceed a specific time value.

27. Portability/Availability
• Software-driven systems could be required to communicate and act in
tandem to solve certain tasks.
• Interoperability describes the ability of two systems to engage in the
exchange of information via certain interfaces.
• Therefore, Software Quality Assurance engineers must examine the
interoperability attribute in terms of both syntactic and semantic
interoperability.

28. Efficiency/Performance
• This attribute pertains to the ability of a software-driven system to
conform to timing requirements.
• From a testing point of view, it implies that Software Testing
engineers must check whether the system responds to various events
within defined time limits.
• These events may occur in the form of clock events, process
interruptions, messages, and requests from different users, and
others.

29. Maintainability/Testability
• Software testability indicates how well a software-driven system
allows Software Testing professionals to conduct tests in line with
predefined criteria.
• This attribute also assesses the ease with which Software Quality
Assurance engineers can develop test criteria for a said system and its
various components.
• Engineers can assess the testability of a system by using various
techniques such as encapsulation, interfaces, patterns, low coupling,
and more.

30. Reliability/Security
• This attribute measures the ability of a system to arrest and block
malicious or unauthorized actions that could potentially destroy the
system.
• The attribute assumes importance because security denotes the
ability of the system to protect data and defend information from
unauthorized access.
• Security also includes authorization and authentication techniques,
protection against network attacks, data encryption, and such other
risks.
• It is imperative for Software Testing Companies and professionals to
regularly conduct updated security checks on systems.

31. Usability
• Every software-driven system is designed for ease of use to accomplish certain
tasks.
• The attribute of usability denotes the ease with which users are able to execute
tasks on the system; it also indicates the kind of user support provided by the
system.
• The most well-known principle for this property is KISS (Keep It Simple Stupid). In
addition, Software Quality Assurance engineers must test software to check
whether it supports different accessibility types of control for people with
disabilities.
• Usability has a critical and long-standing bearing on the commercial fortunes of a
software application or package.

32. Functionality
• This attribute determines the conformity of a software-driven system
with actual requirements and specifications.
• Most Software Testing professionals view this attribute as crucial and
a foremost requirement of a modern application, and would
therefore advocate the performance of tests that assess the desired
functionality of a system in the initial stages of Software Testing
initiatives.

33. SDLC(Software Development Life Cycle)
• SDLC(Software
Development Life Cycle)
comprises a series of
activities that are used
to design, develop and
test high-
quality software product
s, conforming to time
and cost constraints.

34. Stages of SDLC
• Planning and Requirement analysis
• Requirements are gathered and analysed, a feasibility study
is conducted. Planning for quality assurance requirements
are laid out and possible risk factors are determined.
• Defining requirements
• After the analysis is done, they are clearly defined and
documented. They are documented in Software
Requirement Specification (SRS) document which defines
all the product requirements that need to be developed into a
working software product.

35. Stages of SDLC
• Designing
• Based on the SRS document, the design for the product is outlined and
documented in a Design Document Specification (DDS). Product
modules are designed and data flow amongst them are specified using
several tools.
• Building
• The actual building of the product starts here. Code generation occurs
in this stage referring to the design. Programming languages and other
tools for developing software are chosen in this stage.
• Testing
• In this stage, the errors are detected and fixed using different testing
methods. The product is tested to check whether it has achieved the
requirements and quality standards specified in SRS.

36. Stages of SDLC
• Deployment
• The software product is delivered and implemented in a real business
environment. Customers or end-users evaluate the product which is called
User Acceptance Testing(UAT) and gives feedback based on which the product
is finalized or a call for modification is considered.
• Maintenance
• After the product is accepted by the customer or released into the market,
the software has to be maintained for a long run to incorporate changing
environment requirements of the future, for improving performance and
consistency of the product.