0% found this document useful (0 votes)
10 views

Unit 2.1 and 2.2

The document outlines the principles and practices of software engineering, emphasizing the importance of understanding the problem, planning solutions, executing the plan, and validating results. It highlights key practices such as effective communication, iterative planning, and maintaining simplicity in design and implementation. Additionally, it stresses the need for thorough testing, customer involvement, and managing expectations throughout the software development lifecycle.

Uploaded by

Mayur Sarate
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views

Unit 2.1 and 2.2

The document outlines the principles and practices of software engineering, emphasizing the importance of understanding the problem, planning solutions, executing the plan, and validating results. It highlights key practices such as effective communication, iterative planning, and maintaining simplicity in design and implementation. Additionally, it stresses the need for thorough testing, customer involvement, and managing expectations throughout the software development lifecycle.

Uploaded by

Mayur Sarate
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

 Software engineering (SE) is concerned with

developing and maintaining software systems that


behave reliably and efficiently, are affordable to develop
and maintain, and satisfy all the requirements that
customers have defined for them.
1) Understand the problem (communication and analysis)
• Who has a stake in the solution to the problem?
• What are the unknowns? and what (data, function, 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 analysis model
be created?

2) Plan a solution (planning, modeling and software design)


• Have you seen similar problems like this before?
• Has a similar problem been solved? If so, are the elements of the
solution reusable?
• Can sub problems be defined and are solutions available for the
sub problems?
3) Carry out the plan (construction; code generation)
• Does the solution conform to the plan? Is the source code
traceable back to the design?
• Is each component of the solution correct? Has the design and
code been reviewed, or better?

4) Examine the results for accuracy (testing and quality assurance)


• Is it possible to test each component of the solution? Has a
reasonable testing strategy been implemented?
• Does the solution produce results that conform to the data,
function, and behavior that are required?
• Has the Software been validated against all stakeholders
requirement?
1) Remember the reason that the software exists
• The software should provide value to its users and satisfy the
requirements

2) Keep it simple
• All design and implementation should be as simple as possible

3) Maintain the vision of the project


• A clear vision is essential to the project’s success

4) Others will consume what you produce


• Always specify, design, and implement knowing that someone else
will later have to understand and modify what you did
5) Be open to the future
• Never design yourself into a corner; build software that can be easily
changed and adapted.

6) Plan ahead for software reuse


• Reuse of software reduces the long-term cost and increases the value of the
program and the reusable components.

7) Think, then act


• Placing clear, complete thought before action will almost always produce
better results
 Communication Practice
 Planning Practice
 Modeling Practice
 Construction Practice
 Testing Practice
 Deployment Practice
Communication
Project initiation
Requirements gathering

Planning Estimating
Scheduling Tracking

Modelling
Analysis Design

Construction
Code Test
Deployment
Delivery
Support
Feedback
1) Listen to the speaker and concentrate on what is being said
2) Prepare before you meet by researching and
understanding the problem
3) Someone should facility the meeting and have an agenda
4) Face-to-face communication is best, but also have a
document or presentation to focus the discussion
5) Take notes and document decisions
6) Strive for collaboration and consensus
7) Stay focused on a topic; modularize your discussion
8) If something is unclear, draw a picture
9) Move on to the next topic a) after you agree to something,
b) if you cannot agree to something, or c) if a feature or
function is unclear and cannot be clarified at the moment
10) Negotiation is not a contest or a game; it works best when
both parties win

14
1) Understand the scope of the project
2) Involve the customer in the planning activity
3) Recognize that planning is iterative; things will
change
4) Estimate based only on what you know
5) Consider risk as you define the plan
6) Be realistic on how much can be done each day
by each person and how well
7) Adjust granularity as you define the plan
8) Define how you intend to ensure quality
9) Describe how you intend to accommodate
change
10) Track the plan frequently and make adjustments
as required
15
1) Understand the problem you are trying to solve
2) Understand basic design principles and concepts
3) Pick a programming language that meets the needs of
the software to be built and the environment in which it
will operate
4) Select a programming environment that provides tools
that will make your work easier
5) Create a set of unit tests that will be applied once the
component you code is completed
1) Constrain your algorithms by following structured
programming practices
2) Select data structures that will meet the needs of the
design
3) Understand the software architecture and create
interfaces that are consistent with it
4) Keep conditional logic as simple as possible
5) Create nested loops in a way that makes them easily
testable
6) Select meaningful variable names and follow other
local coding standards
7) Write code that is self-documenting
8) Create a visual layout (e.g., indentation and blank lines)
that aids code understanding
1) Conduct a code walkthrough
2) Perform unit tests (black-box and white-box) and
correct errors you have uncovered
3) Refactor the code
1) All tests should be traceable to the software
requirements
2) Tests should be planned long before testing begins
3) The Pareto principle applies to software testing
• 80% of the uncovered errors are in 20% of the code
4) Testing should begin “in the small” and progress toward
testing “in the large”
• Unit testing --> integration testing --> validation
testing --> system testing
5) Exhaustive testing is not possible
1) Customer expectations for the software must be
managed
• Be careful not to promise too much or to mislead the
user
2) A complete delivery package should be assembled and
tested
3) A support regime must be established before the
software is delivered
4) Appropriate instructional materials must be provided to
end users
5) Buggy software should be fixed first, delivered later

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy