SlideShare a Scribd company logo
Nadar saraswathi college of arts and
Science
Software Engineering
Software Engineering Practice
Submitted by,
S.Vijayalakshmi.
SOFTWARE ENGINEERING PRACTICE
 In this part of “software engineering; a practitioner’s approach”
you’ll learn about the principles, concepts, and methods that comprise
software engineering practice.
 Practice is a broad array of concepts, principles, methods, and tools
that you must consider as software planned and developed. It
represents the details-the technical considerations and how to—that are
below the surface of the software process: the things that you’ll need
to actually build high-quality computer software.
 Practice encompasses the technical activities that produce all work
products that are defined by the software process model that has been
chosen.
The essence Practice
 In a classic book, How to Solve It, written before modern computes
existed, gorge Polya outlined the essence of problem solving, and
consequently, the essence of software engineering practice:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
Understand the problem:
 Who has a stake in the solution to the problem? That is, who are the
stakeholders?
 What are the unknowns? What data, functions, features, and behavior
are required to properly solve the problem?
 Can the problem be compartmentalized? Is it possible to represent
smaller problems that may be easier to understand?
 Can the problem be represented graphically? Can an analysis model be
created?
Plan the solution:
 Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that
implements the data, functions, features, and behavior that are
required?
 Has a similar problem been solved? If so, are solutions readily
apparent for the sub-problems?
 Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created?
Carry out the plan:
 Does the solution confirm to the plan? IS source code traceable to the
design model?
 Is each component part of the solution probably correct? Have the
design and code been received, or better, has correctness proof been
applied to the algorithm?
Examine the result:
 Is it possible to test each component part of the solution? Has a
reasonable testing strategy been implemented?
 Does the solution produce results that confirm to the data? Functions,
features and behavior that are required? Has the software been
validated against all stakeholder requirements?
CORE PRINCIPLES
The Reason It All Exists
 A software system exists for one reason: to value to its users. All
decisions should be made with this in mind. Before specifying a
system requirement, before noting a piece of system functionality,
before determining the hardware platforms or development processes,
ask yourself questions such as: Does this add real value to the system?
If the answer is no, don’t do it. All other principles support this one.
KISS (Keep It Simple, Stupid)
 Software design is not a haphazard process. There are many factors to
consider in any design effort. All design should be as simple as
possible, but no simpler. This facilities having a more easily
understood, and easily maintained system. This is not to say that
features, even internal features, should be discarded in the name of
simplicity. Indeed, the more elegant designs are usually the simple
ones. Simple also does not mean “quick and dirty.” In fact, it often, it
often takes a lot of thought and works over multiple iterations to
simplify.
Maintain the Vision
 A clear vision is essential to the success of a software project. Without
one, a project almost unfailingly ends up being “of two [or more]
minds” about itself. Without conceptual integrity, a system threatens to
become a patchwork of incompatible designs, held together by the
wrong kind of screws…
what you produce, others will consume
 In some way or other, someone else will use, maintain, document, or
otherwise depend on being able to understand your system. So always
specify, design and implement knowing someone else will have to
understand what you are doing. The audience for any product of
software development is potentially large. Specify with an eye to the
users. Design, keeping the implementers in mind.. Someone may have
to debug the code you writ, and that makes them a user of your code.
Making their job easier adds value to the system.
Think!
 Placing clear, complete thought before action almost always produces
better results. When you think about something, you are more likely to
do it right. You also gain knowledge about how to do it right again. If
you do think about something and still do it wrong, it becomes
valuable experience. A side effect of thinking is learning to recognize
when you don’t know something, at which point you can research the
answer. When clear thought has gone into a system, value comes out.
Applying the first Six Principles requires intense thought, for which
the potential rewards are enormous.
COMMUNICATION PRACTICES
 Before customer requirements can be analyzed, modeled, or specified
they must be gathered through a communication (also called
requirements elicitation) activity. A customer has a problem that may
be amenable to a computer- based solution. A developer responds to
the customer’s request for help. Communication has begun. But the
road from communication to understanding is often full of potholes
 Effective communication (among technical peers, with the customer
and other stakeholders, and with project managers) is among the most
challenging activities that confront software engineer. In this context,
we discuss communication principles that apply equally to all forms of
communication that occur within a software project.
Prepare before you communicate
 Spend the time to understand the problem before you meet with others.
If necessary, do some research to understand business domain jargon.
If you have responsibility for conducting a meeting, prepare an agenda
in advance of the meeting.
Someone should facilitate the activity.
 Every communication meeting should have a leader (facilitator) to
keep the conversation moving in a productive direction: (2) to mediate
any conflict that does occur; (3) to ensure that other principles are
followed.
Face–to-face communication is best.
 But it usually works better when some other representation of the
relevant information is present. For example, a participant may create
a drawing or a “strawman” document that serves as a focus for
discussion.
Take notes and documentation decisions:
 Things have a way of falling into the cracks. Someone
participating in the communication should serves to build trust
among team members and creates a common goal for the team.
Stay focused, modularize your discussion.
The more the people involved in any communication, the more likely
that discussion will bounce from one topic to the next. The facilitator
should keep the conversation modular, leaving one topic to the next.
The facilitator should keep the conversation modular, leaving one topic
only after it has been resolved
If something is unclear, draw a picture.
Verbal communication goes only so far. A sketch or drawing can often
provide clarity when words fail to do the job.
Negotiation is not a contest or a game. It works best when both parties
win.
There are many instances in which the software engineer and the
customer must negotiate functions and features, priorities, and delivery
dates. If the team has collaborated well, all parties have a common
goal. Therefore, negotiation will demand compromise from all parties.
PLANNING PRACTICES
 The communication activity helps a software team to define its
overall goals and objectives (subject, of course, to change as time
passes). However, understanding these goals and objectives is not
the same as defining a plan for getting there. The planning
activity encompasses a set of management and technical practices
that enable the software tam to define a road map as it travels
towards its strategic goal and technical objectives.
 Here are many different planning philosophies. Some people are
“minimalists, “arguing that change often obviates the need for a
detailed plan. Others are “traditionalists,” arguing that the plan
provides an effective road map, and the more detail it has, the
less likely the team will become lost. Still others are “agilists,”
arguing that quick “planning game” may be necessary, but that
the road map will emerge as “real work” on the software begins.
Understand the scope of the project
 It’s impossible to use a road map if you don’t know
where you’re going. Scope provides the software.
Involve the customer in planning activity
 The customer defines priorities and establishes the
project constraints.
Recognize that planning is iterative.
As work begins, it is very likely that things will
change. As a consequence, the plan must be adjusted
to accommodate these changes. In addition, iterative
and incremental process models dictate re-planning
based on feedback received from users.
Estimate based on what you know.
 The intent of estimation is to provide an indication of effort, cost, and task
duration, based on the team’s current understanding of the work to be done.
Consider risk as you define the plan
 If the team has defined risks that have high impact and high
probability, contingency planning is necessary.
Be realistic. People don’t work 100 percent every
day.
 Noise always enters into any human communication. Omission and
ambiguity are facts of life. Change will occur. Even the best software
engineers make mistakes. These and other realities should be
considered as a project plan is established.
Adjust granularity as you define the plan.
 Granularity refers to the level of detail that is introduced as a project
plan is developed. A “fine granularity” plan provides significant work
detail that is planned over relatively short time increments.
Define how you intend to ensure quality.
 The plan should identify how the software team intends to ensure
quality. If formal technical reviews are to be conducted, they should be
scheduled.
Describe how you intend to accommodate change.
 Even the best planning can be obviated by uncontrolled change. The
software team should identify how changes are to be accommodated as
software engineering work proceeds.
Track the plan frequently and make adjustments
are required.
 Software project falls behind schedule one day at a time. Therefore, it
makes sense to track progress on a daily basis, looking for a problem
areas and situation in which scheduled work does not confirm to actual
work conducted. When slippage is encountered, the plan is adjusted
accordingly.
Thank you

More Related Content

PPTX
Software engineering
PPTX
Introduction to Software Engineering
PPT
Introduction to Software Engineering SE1
PDF
Software Engineering - Basics
PPTX
Process and Project Metrics-1
PDF
software engineering
PPTX
Software engineering
PPSX
Scope of software engineering
Software engineering
Introduction to Software Engineering
Introduction to Software Engineering SE1
Software Engineering - Basics
Process and Project Metrics-1
software engineering
Software engineering
Scope of software engineering

What's hot (20)

PDF
An introduction to software engineering
PPT
Slides chapters 26-27
PPTX
Models of SDLC (Software Development Life Cycle / Program Development Life Cy...
PPT
Software System Engineering - Chapter 1
PPT
Pressman ch-1-software
PPT
An introduction to software engineering
PPT
Advanced topics in software engineering
PPT
Software Engineering (Introduction to Software Engineering)
PPT
Software Processes
PPT
Software Process in Software Engineering SE3
PDF
Introduction to Software Engineering
PPTX
2 approaches to system development
PPT
software Engineering process
DOCX
Software engineering Questions and Answers
PDF
Software engineering introduction
PPT
Software Engineering 2 lecture slide
PDF
Software engineering note
PPTX
Software engineering
An introduction to software engineering
Slides chapters 26-27
Models of SDLC (Software Development Life Cycle / Program Development Life Cy...
Software System Engineering - Chapter 1
Pressman ch-1-software
An introduction to software engineering
Advanced topics in software engineering
Software Engineering (Introduction to Software Engineering)
Software Processes
Software Process in Software Engineering SE3
Introduction to Software Engineering
2 approaches to system development
software Engineering process
Software engineering Questions and Answers
Software engineering introduction
Software Engineering 2 lecture slide
Software engineering note
Software engineering
Ad

Similar to Software engineering (20)

PPTX
software engineering 2 Chapter notes of software engineering in detail to stu...
PPT
Software engineering
PDF
softwareengineeringpractice-141002214920-phpapp02 (1).pdf
PPT
unit - 2 - software engineer practices.ppt
PPTX
Week 1Lecture2222222222222222222222.pptx
PPTX
Software Engineering Practice
PPTX
It's computer science something UNIT 2.pptx
PDF
Introduction to software engineering
PPTX
sepm.pptx tttg. Y tfczAff. Rrfv vv f rfv.
PPT
Software engineering -core topics
PDF
Introduction to Software Engineering & Project Management.pdf
PPTX
Software process is tge helpful for software engineer
PDF
The Nature of Software and Software Engineering ppt.pdf
PDF
Various Process of Software Engineering notes
PPT
Lecture note 3 on software engineering and development
PPT
Chapter1 Advanced Software Engineering overview
PPTX
3.pptx
PPTX
CSE_2014 SE MODULE 1 V.10 (2).pptx
PPTX
UNIT V - 1 SPM.pptx
software engineering 2 Chapter notes of software engineering in detail to stu...
Software engineering
softwareengineeringpractice-141002214920-phpapp02 (1).pdf
unit - 2 - software engineer practices.ppt
Week 1Lecture2222222222222222222222.pptx
Software Engineering Practice
It's computer science something UNIT 2.pptx
Introduction to software engineering
sepm.pptx tttg. Y tfczAff. Rrfv vv f rfv.
Software engineering -core topics
Introduction to Software Engineering & Project Management.pdf
Software process is tge helpful for software engineer
The Nature of Software and Software Engineering ppt.pdf
Various Process of Software Engineering notes
Lecture note 3 on software engineering and development
Chapter1 Advanced Software Engineering overview
3.pptx
CSE_2014 SE MODULE 1 V.10 (2).pptx
UNIT V - 1 SPM.pptx
Ad

More from sweetysweety8 (20)

PPTX
Artificial neural network
PPTX
Compiler Design
PPTX
Software engineering
PPTX
WEB PROGRAMMING ANALYSIS
PPTX
Software engineering
PPTX
Compiler Design
PPTX
WEB PROGRAMMING ANALYSIS
PPTX
WEB PROGRAMMING
PPTX
Bigdata
PPTX
BIG DATA ANALYTICS
PPTX
BIG DATA ANALYTICS
PPTX
Compiler Design
PPTX
WEB PROGRAMMING
PPTX
BIG DATA ANALYTICS
PPT
Data mining
PPTX
Operating System
PPTX
Relational Database Management System
PPTX
Relational Database Management System
PPTX
Relational Database Management System
PPTX
Operating system
Artificial neural network
Compiler Design
Software engineering
WEB PROGRAMMING ANALYSIS
Software engineering
Compiler Design
WEB PROGRAMMING ANALYSIS
WEB PROGRAMMING
Bigdata
BIG DATA ANALYTICS
BIG DATA ANALYTICS
Compiler Design
WEB PROGRAMMING
BIG DATA ANALYTICS
Data mining
Operating System
Relational Database Management System
Relational Database Management System
Relational Database Management System
Operating system

Recently uploaded (20)

PPTX
Primary and secondary sources, and history
PPTX
Impressionism_PostImpressionism_Presentation.pptx
DOC
学位双硕士UTAS毕业证,墨尔本理工学院毕业证留学硕士毕业证
PPTX
fundraisepro pitch deck elegant and modern
PDF
oil_refinery_presentation_v1 sllfmfls.pdf
PPTX
An Unlikely Response 08 10 2025.pptx
PPTX
Role and Responsibilities of Bangladesh Coast Guard Base, Mongla Challenges
PPTX
Human Mind & its character Characteristics
PPTX
BIOLOGY TISSUE PPT CLASS 9 PROJECT PUBLIC
PPTX
AcademyNaturalLanguageProcessing-EN-ILT-M02-Introduction.pptx
PPTX
nose tajweed for the arabic alphabets for the responsive
PDF
Instagram's Product Secrets Unveiled with this PPT
DOCX
ENGLISH PROJECT FOR BINOD BIHARI MAHTO KOYLANCHAL UNIVERSITY
PPTX
Project and change Managment: short video sequences for IBA
PDF
Swiggy’s Playbook: UX, Logistics & Monetization
PPTX
Introduction to Effective Communication.pptx
PDF
Parts of Speech Prepositions Presentation in Colorful Cute Style_20250724_230...
PPTX
INTERNATIONAL LABOUR ORAGNISATION PPT ON SOCIAL SCIENCE
PDF
Nykaa-Strategy-Case-Fixing-Retention-UX-and-D2C-Engagement (1).pdf
PPTX
Tour Presentation Educational Activity.pptx
Primary and secondary sources, and history
Impressionism_PostImpressionism_Presentation.pptx
学位双硕士UTAS毕业证,墨尔本理工学院毕业证留学硕士毕业证
fundraisepro pitch deck elegant and modern
oil_refinery_presentation_v1 sllfmfls.pdf
An Unlikely Response 08 10 2025.pptx
Role and Responsibilities of Bangladesh Coast Guard Base, Mongla Challenges
Human Mind & its character Characteristics
BIOLOGY TISSUE PPT CLASS 9 PROJECT PUBLIC
AcademyNaturalLanguageProcessing-EN-ILT-M02-Introduction.pptx
nose tajweed for the arabic alphabets for the responsive
Instagram's Product Secrets Unveiled with this PPT
ENGLISH PROJECT FOR BINOD BIHARI MAHTO KOYLANCHAL UNIVERSITY
Project and change Managment: short video sequences for IBA
Swiggy’s Playbook: UX, Logistics & Monetization
Introduction to Effective Communication.pptx
Parts of Speech Prepositions Presentation in Colorful Cute Style_20250724_230...
INTERNATIONAL LABOUR ORAGNISATION PPT ON SOCIAL SCIENCE
Nykaa-Strategy-Case-Fixing-Retention-UX-and-D2C-Engagement (1).pdf
Tour Presentation Educational Activity.pptx

Software engineering

  • 1. Nadar saraswathi college of arts and Science Software Engineering Software Engineering Practice Submitted by, S.Vijayalakshmi.
  • 2. SOFTWARE ENGINEERING PRACTICE  In this part of “software engineering; a practitioner’s approach” you’ll learn about the principles, concepts, and methods that comprise software engineering practice.  Practice is a broad array of concepts, principles, methods, and tools that you must consider as software planned and developed. It represents the details-the technical considerations and how to—that are below the surface of the software process: the things that you’ll need to actually build high-quality computer software.  Practice encompasses the technical activities that produce all work products that are defined by the software process model that has been chosen.
  • 3. The essence Practice  In a classic book, How to Solve It, written before modern computes existed, gorge Polya outlined the essence of problem solving, and consequently, the essence of software engineering practice: 1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine the result for accuracy (testing and quality assurance). Understand the problem:  Who has a stake in the solution to the problem? That is, who are the stakeholders?  What are the unknowns? What data, functions, features, and behavior are required to properly solve the problem?  Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand?
  • 4.  Can the problem be represented graphically? Can an analysis model be created? Plan the solution:  Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, features, and behavior that are required?  Has a similar problem been solved? If so, are solutions readily apparent for the sub-problems?  Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? Carry out the plan:  Does the solution confirm to the plan? IS source code traceable to the design model?  Is each component part of the solution probably correct? Have the design and code been received, or better, has correctness proof been applied to the algorithm?
  • 5. Examine the result:  Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?  Does the solution produce results that confirm to the data? Functions, features and behavior that are required? Has the software been validated against all stakeholder requirements? CORE PRINCIPLES The Reason It All Exists  A software system exists for one reason: to value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: Does this add real value to the system? If the answer is no, don’t do it. All other principles support this one.
  • 6. KISS (Keep It Simple, Stupid)  Software design is not a haphazard process. There are many factors to consider in any design effort. All design should be as simple as possible, but no simpler. This facilities having a more easily understood, and easily maintained system. This is not to say that features, even internal features, should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the simple ones. Simple also does not mean “quick and dirty.” In fact, it often, it often takes a lot of thought and works over multiple iterations to simplify. Maintain the Vision  A clear vision is essential to the success of a software project. Without one, a project almost unfailingly ends up being “of two [or more] minds” about itself. Without conceptual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws…
  • 7. what you produce, others will consume  In some way or other, someone else will use, maintain, document, or otherwise depend on being able to understand your system. So always specify, design and implement knowing someone else will have to understand what you are doing. The audience for any product of software development is potentially large. Specify with an eye to the users. Design, keeping the implementers in mind.. Someone may have to debug the code you writ, and that makes them a user of your code. Making their job easier adds value to the system. Think!  Placing clear, complete thought before action almost always produces better results. When you think about something, you are more likely to do it right. You also gain knowledge about how to do it right again. If you do think about something and still do it wrong, it becomes valuable experience. A side effect of thinking is learning to recognize when you don’t know something, at which point you can research the answer. When clear thought has gone into a system, value comes out. Applying the first Six Principles requires intense thought, for which the potential rewards are enormous.
  • 8. COMMUNICATION PRACTICES  Before customer requirements can be analyzed, modeled, or specified they must be gathered through a communication (also called requirements elicitation) activity. A customer has a problem that may be amenable to a computer- based solution. A developer responds to the customer’s request for help. Communication has begun. But the road from communication to understanding is often full of potholes  Effective communication (among technical peers, with the customer and other stakeholders, and with project managers) is among the most challenging activities that confront software engineer. In this context, we discuss communication principles that apply equally to all forms of communication that occur within a software project. Prepare before you communicate  Spend the time to understand the problem before you meet with others. If necessary, do some research to understand business domain jargon. If you have responsibility for conducting a meeting, prepare an agenda in advance of the meeting.
  • 9. Someone should facilitate the activity.  Every communication meeting should have a leader (facilitator) to keep the conversation moving in a productive direction: (2) to mediate any conflict that does occur; (3) to ensure that other principles are followed. Face–to-face communication is best.  But it usually works better when some other representation of the relevant information is present. For example, a participant may create a drawing or a “strawman” document that serves as a focus for discussion. Take notes and documentation decisions:  Things have a way of falling into the cracks. Someone participating in the communication should serves to build trust among team members and creates a common goal for the team.
  • 10. Stay focused, modularize your discussion. The more the people involved in any communication, the more likely that discussion will bounce from one topic to the next. The facilitator should keep the conversation modular, leaving one topic to the next. The facilitator should keep the conversation modular, leaving one topic only after it has been resolved If something is unclear, draw a picture. Verbal communication goes only so far. A sketch or drawing can often provide clarity when words fail to do the job. Negotiation is not a contest or a game. It works best when both parties win. There are many instances in which the software engineer and the customer must negotiate functions and features, priorities, and delivery dates. If the team has collaborated well, all parties have a common goal. Therefore, negotiation will demand compromise from all parties.
  • 11. PLANNING PRACTICES  The communication activity helps a software team to define its overall goals and objectives (subject, of course, to change as time passes). However, understanding these goals and objectives is not the same as defining a plan for getting there. The planning activity encompasses a set of management and technical practices that enable the software tam to define a road map as it travels towards its strategic goal and technical objectives.  Here are many different planning philosophies. Some people are “minimalists, “arguing that change often obviates the need for a detailed plan. Others are “traditionalists,” arguing that the plan provides an effective road map, and the more detail it has, the less likely the team will become lost. Still others are “agilists,” arguing that quick “planning game” may be necessary, but that the road map will emerge as “real work” on the software begins.
  • 12. Understand the scope of the project  It’s impossible to use a road map if you don’t know where you’re going. Scope provides the software. Involve the customer in planning activity  The customer defines priorities and establishes the project constraints. Recognize that planning is iterative. As work begins, it is very likely that things will change. As a consequence, the plan must be adjusted to accommodate these changes. In addition, iterative and incremental process models dictate re-planning based on feedback received from users. Estimate based on what you know.  The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of the work to be done.
  • 13. Consider risk as you define the plan  If the team has defined risks that have high impact and high probability, contingency planning is necessary. Be realistic. People don’t work 100 percent every day.  Noise always enters into any human communication. Omission and ambiguity are facts of life. Change will occur. Even the best software engineers make mistakes. These and other realities should be considered as a project plan is established. Adjust granularity as you define the plan.  Granularity refers to the level of detail that is introduced as a project plan is developed. A “fine granularity” plan provides significant work detail that is planned over relatively short time increments.
  • 14. Define how you intend to ensure quality.  The plan should identify how the software team intends to ensure quality. If formal technical reviews are to be conducted, they should be scheduled. Describe how you intend to accommodate change.  Even the best planning can be obviated by uncontrolled change. The software team should identify how changes are to be accommodated as software engineering work proceeds. Track the plan frequently and make adjustments are required.  Software project falls behind schedule one day at a time. Therefore, it makes sense to track progress on a daily basis, looking for a problem areas and situation in which scheduled work does not confirm to actual work conducted. When slippage is encountered, the plan is adjusted accordingly.