Introduction to Software Engineering and Models pptx
1. Department of Computer Science (UG)
Basics of Open Source Demistfyed
21BCA2T341
Mr. Narikamalli Yaswanth,
Assistant Professor,
Department of Computer Science,
Kristu Jayanti College (Autonomous)
3. Software is defined as the set of programs that are used by a
computer for performing specific tasks.
Engineering on the other hand, is all about developing products,
using well-defined, scientific principles and methods.
Software Engineering is an engineering branch associated with
development of software product using well-defined scientific
principles, methods and procedures. The outcome of software
engineering is an efficient and reliable software product.
7. Software products
• Generic products – Stand-alone systems that are marketed and sold
to any customer who wishes to buy them. – Examples – PC software
such as graphics programs, project management tools; CAD
software; software for specific markets such as appointments systems
for dentists.
• Customized products – Software that is commissioned by a specific
customer to meet their own needs. – Examples – embedded control
systems, air traffic control software, traffic monitoring systems.
8. Product specification
Generic products – The specification of what the software should
do is owned by the software developer and decisions on software
change are made by the developer.
Customized products – The specification of what the software
should do is owned by the customer for the software and they make
decisions on software changes that are required.
10. Dual Role of Software
There is a dual role of software in the industry. The first one is as a product and the
other one is as a vehicle for delivering the product. We will discuss both of them.
1. As a Product
● It delivers computing potential across networks of Hardware.
● It enables the Hardware to deliver the expected functionality.
● It acts as an information transformer because it produces, manages, acquires,
modifies, displays, or transmits information.
11. 2. As a Vehicle for Delivering a Product
● It provides system functionality (e.g., payroll system).
● It controls other software (e.g., an operating system).
● It helps build other software (e.g., software tools).
13. (i) Management Myths:
Myth 1:
We have all the standards and procedures available for software development.
Fact:
All existing processes are incomplete as new software development is based on new and different problem.
Myth 2:
The addition of the latest hardware programs will improve the software development.
Fact:
The role of the latest hardware is not very high on standard software development; instead (CASE)
Engineering tools help the computer, they are more important than hardware to produce quality and
productivity.
14. (ii)Customer Myths:
Myth 1:
A general statement of intent is enough to start writing plans (software development) and details of objectives can be done over
time.
Fact:
Official and detailed description of the database function, ethical performance, communication, structural issues and the
verification process are important.
Myth 2:
Software requirements continually change, but change can be easily accommodated because software is flexible
Fact:
It is true that software requirements change, but the impact of change varies with the time at which it is introduced. When
requirements changes are requested early (before design or code has been started), the cost impact is relatively small. However, as
time passes, the cost impact grows rapidly—resources have been committed, a design framework has been established, and
change can cause upheaval that requires additional resources and major design modification.
15. (iii)Practitioner’s Myths:
Myths 1:
They believe that their work has been completed with the writing of the plan.
Fact:
It is true that every 60-80% effort goes into the maintenance phase (as of the latter software release). Efforts
are required, where the product is available first delivered to customers.
Myth 2:
Software engineering will enable us to build powerful and unnecessary document & always delay us.
Fact:
Software engineering is not about creating documents. It is about creating a quality product. Better quality
leads to reduced rework. And reduced rework results in faster delivery time.
16. A software engineering code of ethics is a moral compass, guiding
professionals to make responsible decisions and ensuring that the products
and services they develop align with societal values and expectations.
Software engineering is about writing code and creating solutions that
positively impact society.
Ethical considerations are crucial in this process, as they help software
engineers navigate complex issues and make choices that prioritise the well-
being of users and the broader community.
17. The role of ethics in software development
Ethics play a significant role in software development as they guide engineers in
making choices that align with ethical principles.
Software development involves various stages, including planning, designing,
coding, testing, and maintenance.
At each stage, ethical considerations should be considered to ensure that the
software created is reliable secure and respects user privacy.
18. The Code of Ethics: during the planning phase
During the planning phase, software engineers must consider the potential impact of their
work on different stakeholders.
They need to assess the ethical implications of the software’s purpose and functionality,
ensuring that it does not harm individuals or perpetuate discrimination.
This requires a deep understanding of societal values and anticipating potential risks.
19. The Code of Ethics: during the design phase
Engineers must strive to create intuitive, inclusive interfaces and respect users’
privacy.
The coding phase is where software engineers translate their designs into actual
code.
Ethical coding involves writing clean, well-documented code that is easy to
maintain and understand.
Engineers should also prioritise security measures, implementing robust
authentication and encryption mechanisms to protect user data.
20. The Code of Ethics: during the testing phase
Testing is another critical stage where ethics are essential. Engineers must
thoroughly test the software for reliability, accuracy, and security.
They should also consider the potential biases that may arise from the algorithms
used in the software and take steps to mitigate them.
21. The Code of Ethics: when maintaining software
Maintenance is an ongoing process in software development, and ethical
considerations should continue to be prioritised.
Engineers must respond to user feedback and promptly address any
issues or vulnerabilities.
They should also stay current with emerging ethical standards and adapt
their software accordingly.
22. What is a software process model?
A software process model is an abstraction of the software development
process. The models specify the stages and order of a process. So, think
of this as a representation of the order of activities of the process and
the sequence in which they are performed.
A model will define the following:
● The tasks to be performed
● The input and output of each task
● The pre and post-conditions for each task
● The flow and sequence of each task
23. The goal of a software process model is to provide guidance for
controlling and coordinating the tasks to achieve the end product
and objectives as effectively as possible.
24. Types of Software Process Models
There are many kinds of process models for meeting different requirements.
We refer to these as SDLC models (Software Development Life Cycle models).
The most popular and important SDLC models are as follows:
● Waterfall model
● Prototype model
● Spiral model
● Incremental model
● Agile model
25. Waterfall Model
The waterfall model is a sequential, plan driven-process where you must plan and schedule all
your activities before starting the project. Each activity in the waterfall model is represented as a
separate phase arranged in linear order.
It has the following phases:
● Requirements
● Design
● Implementation
● Testing
● Deployment
● Maintenance
26. Each of these phases produces one or more documents that need to be approved before the next phase
begins.
The waterfall model is used for the projects where the requirements are well-defined, stable, and unlikely
to change during the development process.
27. Spiral Model
The spiral model is a risk driven iterative software process model. The spiral
model delivers projects in loops. Unlike other process models, its steps aren’t
activities but phases for addressing whatever problem has the greatest risk of
causing a failure.
You have the following phases for each cycle:
1. Address the highest-risk problem and determine the objective and alternate
solutions
2. Evaluate the alternatives and identify the risks involved and possible
solutions
3. Develop a solution and verify if it’s acceptable
4. Plan for the next cycle
29. Note: It was designed to include the best features from the waterfall and introduces risk-
assessment.
You develop the concept in the first few cycles, and then it evolves into an implementation.
Though this model is great for managing uncertainty, it can be difficult to have stable
documentation.
The spiral model can be used for projects with unclear needs or projects still in research
and development.
30. Incremental Model
The incremental model divides the system’s functionality into small increments
that are delivered one after the other in quick succession. The most important
functionality is implemented in the initial increments.
The subsequent increments expand on the previous ones until everything has
been updated and implemented.
Incremental development is based on developing an initial implementation,
exposing it to user feedback, and evolving it through new versions. The process’
activities are interwoven by feedback.
32. The incremental model lets stakeholders and developers see results with the first
increment. It is efficient as the developers only focus on what is important and
bugs are fixed as they arise, but you need a clear and complete definition of the
whole system before you start.
The incremental model is great for projects that have loosely coupled parts and
projects with complete and clear requirements.
33. Prototyping Model
The prototype model requires that before carrying out the development of actual
software, a working prototype of the system should be built. A prototype is a toy
implementation of the system. A prototype usually turns out to be a very crude
version of the actual system, possible exhibiting limited functional capabilities,
low reliability, and inefficient performance as compared to actual software.
34. Steps of Prototype Model
1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product
The Prototyping Model is best suited for projects where requirements are not
clearly defined, or when the end-users are not entirely sure what they want.