Scribd
Upload
22 views23 pages

Module 3 4

Uploaded by

kaushik.22cs075
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
22 views23 pages

Module 3 4

Uploaded by

kaushik.22cs075
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/ 23

MODULE-3 CHAPTER-4

PRINCIPLES THATGUIDE PRACTICE


4.1 SOFTWARE ENGINEERING KNOWLEDGE

• Many software practitioners think of software engineering knowledge almost


exclusively as knowledge of specific technologies: Java, Perl, html, C, Linux,
Windows NT, and soon.

• Knowledge of specific technology details is necessary to perform computer


programming.

• If someone assigns you to write a program in C, you have to know something


about C to get your program to work.
4.2 CORE PRINCIPLES

• Software engineering is guided by a collection of core principles that help in the


application of a meaningful software process and the execution of effective software
engineering methods.
• At the process level, core principles establish a philosophical foundation that guides
a software team as it performs framework and umbrella activities navigates the
process flow, and produces a set of software engineering work products.
• At the level of practice, core principles establish a collection of values and rules that
serve as a guide as you analyze a problem, design a solution, implement and test the
solution, and ultimately deploy the software in the user community.
4.2.1 Principles That Guide Process

• Principle 1. Be agile.
• Principle 2. Focus on quality at every step
• Principle 3. Be ready to adapt.
• Principle 4. Build an effective team.
• Principle 5. Establish mechanisms for communication and coordination.
• Principle 6. Manage change.
• Principle 7. Assess risk.
• Principle 8. Create work products that provide value for others.
4.2.2 Principles That Guide Practice
• Principle 1. Divide and conquer
• Principle 2. Understand the use of abstraction.
• Principle 3. Strive for consistency
• Principle 4. Focus on the transfer of information
• Principle 5. Build software that exhibits effective modularity.
• Principle 6. Look for patterns.
• Principle 7. When possible, represent the problem and its solution from a number of
different perspectives.
• Principle 8. Remember that someone will maintain the software
4.3 PRINCIPLES THAT GUIDE EACH FRAMEWORK ACTIVITY

• Communication Principles
• Planning Principles
• Modeling Principles
• Requirements modeling principles
• Design Modeling Principles.
• Construction Principles
• Coding Principles.
• Testing Principles
• Deployment Principles
4.3.1.Communication Principles

• Principle 1. Listen
• Principle 2. Prepare before you communicate
• Principle 3. Someone should facilitate the activity.
• Principle 4. Face-to-face communication is best.
• Principle 5. Take notes and document decisions.
• Principle 6. Strive for collaboration
• Principle 7. Stay focused; modularize your discussion.
• Principle 8. If something is unclear, draw a picture.
• Principle 9.
• (a) Once you agree to something, move on.
• (b) If you can’t agree to something, move on.
• (c) If a feature or function is unclear and cannot be clarified at
the moment, move on.
• Principle 10. Negotiation is not a contest or a game. It works best when
both parties win.
4.3.2. Planning Principles

• Principle 1. Understand the scope of the project.


• Principle 2. Involve stakeholders in the planning activity.
• Principle 3. Recognize that planning is iterative.
• Principle 4. Estimate based on what you know.
• Principle 5. Consider risk as you define the plan.
• Principle 6. Be realistic.
• Principle 7. Adjust granularity as you define the plan.
• Principle 8. Define how you intend to ensure quality.
• Principle 9. Describe how you intend to accommodate change.
• Principle 10. Track the plan frequently and make adjustments as required.
4.3.3. Modeling Principles

• Principle 1. The primary goal of the software team is to build software, not create
models.
• Principle 2. Travel light—don’t create more models than you need.
• Principle 3. Strive to produce the simplest model that will describe the problem or the
software.
• Principle 4. Build models in a way that makes them amenable to change.
• Principle 5. Be able to state an explicit purpose for each model that is created.
• Principle 6. Adapt the models you develop to the system at hand.
• Principle 7. Try to build useful models, but forget about building perfect models.
• Principle 8. Don’t become dogmatic about the syntax of the
model. If it communicates content successfully, representation
is secondary.

• Principle 9. If your instincts tell you a model isn’t right even


though it seems okay on paper, you probably have reason to be
concerned.
• Principle 10. Get feedback as soon as you can.
Requirements modeling principles

• Principle 1. The information domain of a problem must be represented


and understood.
• Principle 2. The functions that the software performs must be defined.
• Principle 3. The behavior of the software (as a consequence of external
events) must be represented.
• Principle 4. The models that depict information, function, and behavior
must be partitioned in a manner that uncovers detail in a layered (or
hierarchical) fashion.
• Principle 5. The analysis task should move from essential information
toward implementation detail.
Design Modeling Principles

• Principle 1. Design should be traceable to the requirements model.


• Principle 2. Always consider the architecture of the system to be built
• Principle 3. Design of data is as important as design of processing functions.
• Principle 4. Interfaces (both internal and external) must be designed with care.
• Principle 5. User interface design should be tuned to the needs of the end user. However, in every case, it
should stress ease of use.
• Principle 6. Component-level design should be functionally independent.
• Principle 7. Components should be loosely coupled to one another and to the external environment.
• Principle 8. Design representations (models) should be easily understandable.
• Principle 9. The design should be developed iteratively. With each iteration, the designer should strive for
greater simplicity.
4.3.4 Construction Principles

• The construction activity encompasses a set of coding and testing tasks that lead
to operational software that is ready for delivery to the customer or end user. In
modern software engineering work, coding may be
(1) the direct creation of programming language source code (e.g., Java),
(2) the automatic generation of source code using an intermediate design-like
representation of the component to be built, or
(3) the automatic generation of executable code using a “fourth-generation
programming language” (e.g., Visual C).
• The initial focus of testing is at the component level, often called unit
testing. Other levels of testing include
• 1. integration testing (conducted as the system is constructed),
• 2.validation testing that assesses whether requirements have been met for the
complete system (or software increment), and
• (3) acceptance testing that is conducted by the customer in an effort to
exercise all required features and functions.
• The following set of fundamental principles and concepts are applicable to
coding and testing:
• Coding Principles. The principles that guide the coding task are
closely aligned with programming style, programming
languages, and programming methods.

• However, there are a number of fundamental principles that can


be stated:
• Preparation principles: Before you write one line of code, be sure you
• Understand of the problem you’re trying to solve.
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs of the software to be
built and the environment in which it will operate.
• Select a programming environment that provides tools that will make your
work easier.
• Create a set of unit tests that will be applied once the component you code
is completed.
• Programming principles: As you begin writing code, be sure you
• Constrain your algorithms by following structured programming practice.
• Consider the use of pair programming
• Select data structures that will meet the needs of the design.
• Understand the software architecture and create interfaces that are consistent with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them easily testable.
• Select meaningful variable names and follow other local coding standards.
• Write code that is self-documenting.
• Validation Principles: After you’ve completed your first coding pass, be sure you
• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors you’ve uncovered
• Refactor the code.
Testing Principles

• In a classic book on software testing, Glen Myers [Mye79] states a


number of rules that can serve well as testing objectives:
• Testing is a process of executing a program with the intent of finding an
error.

• A good test case is one that has a high probability of finding an as-yet
undiscovered error.
• Principle 1. All tests should be traceable to customer requirements.
• Principle 2. Tests should be planned long before testing begins.
• Principle 3. The Pareto principle applies to software testing
• Principle 4. Testing should begin “in the small” and progress toward
testing “in the large’’
• Principle 5. Exhaustive testing is not possible.
4.3.5 Deployment Principles

• Principle 1. Customer expectations for the software must be managed.


• Principle 2. A complete delivery package should be assembled and
tested.
• Principle 3. A support regime must be established before the software
is delivered.
• Principle 4. Appropriate instructional materials must be provided to
end users.
• Principle 5. Buggy software should be fixed first, delivered later.
END OF MODULE-3

You might also like