Unit 2 – Software Engineering

2.1. Software Engineering Practices – Definition, Importance, Essence

Software Engineering Practices:
• Software engineering deals with processes to ensure delivery of the software through
management control of development process and production of requirement analysis
models, data models process models, information products, reports and software
documentation.
• Software Engineering practices consist of collection of concepts, principles, methods and
tools that a software engineer calls upon on a daily basis.
• It equips managers to manage software projects and software engineers to build computer
programs.
• Provides necessary technical and management know-how for getting the job done.
• Transforms a haphazard, unfocused approach into something that is more organized, more
effective and more likely to achieve success.
Importance of Software Engineering practices:
The software engineering considers various issues like hardware platform, performance,
scalability and upgrades.
The Essence of software engineering practices:
The essence includes understanding the problem, planning a solution, carrying out the plan and
examining the results for accuracy.
1. Understand the problem (communication and analysis)
• Who has a stake in the solution to the problem?
• What are the unknowns (data, function, behavior)?
• Can the problem be compartmentalized?
• Can the problem be represented graphically?
2. Plan a solution (planning, modeling and software design)
• Have you seen similar problems like this before?
• Has a similar problem been solved and is the solution reusable?
• Can sub problems be defined and are solutions available for the sub problems?
3. Carry out the plan: The design you’ve created serves as road map for the system you want
to build. (Construction, Code generation)
• Does the solution conform 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
reviewed or have correctness proofs been applied to the algorithm?
4. Examine the result for accuracy (testing and quality assurance)
• Is it possible to test each component part of the solution?
• Does the solution produce results that conform to the data, functions and features that
are required? Has the software been validated against all stakeholder requirements?
2.2. Core Principles of Software Engineering (Statements & Meaning of each
Principle)
1. The reason it all exists:
The software system exists in the organization for providing value to its users with, the
availability of hardware and software requirements. Hence all the decisions should be made by
keeping this in mind.
2. Keep it Simple, Stupid (KISS)
Software design is not a haphazard process. There are many factors considered in the design
effort. The design should be straight forward and as simple as possible. This facilitates having
a system which can be easily understood and easy to maintain.
Simple doesn’t mean quick and dirty. In fact, it requires lot of thought and effort to simplify
multiple iterations of a complex task. This results in the advantage that the software is less error
prone and easily maintainable.
3. Maintain the vision
A clear vision is essential for the success of a software project. If the vision is missing, the
project may end up of two or more minds. The team leader has a critical role to play for
maintaining the vision and enforce compliance with the help of the team members.
4. What you produce, others will consume
The design and implementation should be done by keeping in mind the user’s requirements.
The code should permit the system extension. Some other programmers debugging the code
should not have any errors and satisfying all the user needs.
5. Be open to future
The system with the long lifetime has more value. The industry standard software systems
induce for longer. The system should be ready to accept and adapt to new changes. The systems
which are designed by keeping in mind the future needs will be more successful and acceptable
to the users.
6. Plan ahead for reuse
Reuse saves time and efforts. The reuse of code and design is one of the advantages of object
oriented technologies. The reuse of parts of the code helps in reducing the cost and time
evolved, in the new software development.
7. Think
Placing clear and complete thought before action almost always produces better results. With
proper thinking, we are most likely to do it right. We also gain knowledge about how to do it
right again. It becomes a valuable experience, even if something goes wrong, as there was
adequate thought process. Hence when clear thought has gone into the system, value comes
out, this provides potential rewards.
2.3. Communication Practices (Concept, Need of communication, Statements and
Meaning of each Principle)
Effective communication among the technical peers, customers and other stakeholders, project
managers etc. is among the most challenging activities that confront software engineers.
Before customers’ requirements can be analyzed, modeled are specified they must be gathered
through a communication.
Effective communication is among the most challenging activities that designers will confront.
Communication Principles are
1. Listen: Try to focus on the speaker’s words, rather than formulating your response to those
words. Ask for clarification if something is unclear, but avoid constant interruptions.
2. Prepare before you communicate: Speed the time to understand the problem before you
meet with others. If necessary, do some research to understand business domain jargon.
3. Someone should facilitate the activity: Every communication meeting should have a
leader to keep the conversation moving in a productive direction, to mediate any conflict
that does occur and to ensure than other principles are followed.
4. Face-to Face communication is the best: It usually works better when some other
representation of the relevant information is present. For e.g. A participant may create a
drawing or a “strawman” document that serves as a focus for discussion.
5. Take notes and document decisions: Things have a way of falling into cracks. Someone
participating in the communication should serve as a “recorder” and write down all
important points and decisions.
6. Strive for collaboration: Collaboration and consensus occur when the collective
knowledge of members of the team is used to describe product or system functions or
features. Collaboration serves to build trust among team members and creates a common
goal for the team.
7. Stay focused; modularize your discussion: The more likely involved in any
communication, the more likely that discussion will bounce from one topic to next. The
facilitator should keep the conversation modular; leaving one topic only after it has been
resolved.
8. 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.
9. A) Once agree to something, move on. B) If can’t agree to something, still move on
C) If a feature or function is unclear and cannot be clarified at the moment, move on.
Communication, like any software engineering activity, takes time. Rather than iterating
endlessly the people who participates should recognize that many topics require discussion
and that “moving on” is sometimes the best way to achieve communication agility.
10. Negotiation is not a contest or a game. It works best when both parties win: There are many
instances in which the designer and other stakeholders must negotiate functions and
features, priorities, and delivery dates. If the team has collaborated well, all parties have a
common goal still, negotiation will demand compromise from all parties.
2.4. Planning Practices: Concept, Need of planning, basic activities included,
statements and meaning of each principle.
The planning activity encompasses of a set of management and technical practices that enable
the software team to define a road map as it travels towards its strategic goals and tactical
objectives. Like most things in life, planning should be conducted in moderation enough to
provide useful guidance to the team.
Planning Principles:
1. Understand the scope of the project: It is impossible to use a road map if one doesn’t
know where to go. Scope provides the software team with a destination.
2. Involve stakeholders in the planning activity: Stakeholders define priorities and establish
project constraints. To accommodate these realities, software engineers must often
negotiate order of delivery, timelines and other project related issues.
3. Recognize that the planning is iterative: When the project work begins it’s likely that
few things may change. To accommodate these changes the plan must be adjusted, as a
consequence. The iterative and incremental model may dictate re-planning based on the
feedback received from users.
4. Estimate based on what you know: The purpose of estimation is to provide an indication
of the efforts, cost, task duration and skillsets based on the team’s current understanding of
the work and past experience. If the information is vague or unreliable estimates will be
equally unreliable.
5. Consider the risk as you define the plan: The team should define the risks of high impact
and high probability. It should also provide contingency plan if the risks become a reality.
The project plan should be adjusted to accommodate the likelihood of the risks.
6. Be realistic: The realistic plan helps in completing the project on time including the
inefficiencies and change. Even the best software engineers commit mistakes and then
correct them. Such realities should be considered while establishing a project plan.
7. Adjust granularity as you define the plan: Granularity refers to the level of details that
is introduced as a project plan is developed. It is the representation of the system from
macro to micro level. A “high-granularity” plan provides significant work task detail that
is planned over relatively short time increments. A “low-granularity” plan provides broader
work tasks that are planned over longer time periods. In general, granularity moves from
high to low as the project time line moves away from the current date.
8. Define how you intend to ensure quality: The plan should identify how the software team
intends to ensure quality. If technical reviews are to be conducted, they should be
scheduled.
9. Describe how you intend to accommodate change: Even the best planning can be
obviated by uncontrolled change. The software team should identify how the changes are
to be accommodated as the software engineering work proceeds. If a change is requested,
the team may decide on the possibility of implementing the changes or suggest alternatives.
The team should also access the impact of change on the development process and the
changes in cost.
10. Track and monitor the plan frequently and make adjustments if required: Software
projects fall behind schedule one day at a time. Therefore, make sense to track progress on
a daily basis, looking for problem areas and situations in which scheduled work does not
conform to actual work conducted. When slippage is encountered, the plan is adjusted
accordingly.
The W5HH Principle:
Barry Boehm suggest an approach that addresses project objectives, milestones and schedules,
responsibilities, management and technical approaches, and required resources. It is the W5HH
principle, which includes a series of questions:
• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible for a function?
• Where they are organizationally located?
• How will the job be done technically and managerially?
• How much of each resource is needed?
2.5. Modeling Principles
Concept of Software Modeling
In software engineering designers create models to gain a better understanding of the actual
entity to be built. When the entity is a physical thing, such as machine, we can build a model
that is identical in form and shape but smaller in scale. However, when the entity to be built is
software, the model must take a different form. The model must be capable of representing the
information that the software transforms, the architecture and functions that enable the
transformation to occur, the features that the user desires and the behavior of the system as the
transformation is taking place. The models must accomplish these objectives at different levels
of abstraction. Initially the system is represented by depicting the software from the customer’s
point of view (Analysis model). The later the system is represented at a more technical level
providing concrete specification for the construction of the software (Design model). The
Design model represents the characteristics of the software which help the professionals to
construct the software effectively.
In software engineering work, two classes of models are created viz. Analysis Models and
Design Models.
Analysis Models
This model represents the customer requirements by depicting the software in three domains
The information domain
The functional domain
The behavioral domain
Analysis Modeling Principles:
Requirement models (also called analysis models) represent customer requirements by
depicting the software three different domains: the information domain, the functional domain
and the behavioral domain.
1. The information domain of a problem must be represented and understood
The information domain encompasses the data that flow into the system from end users, other
systems or external devices, the data that flow out the system via the user interface, network
interfaces, reports, graphics, and other means and the data stores that collect and organize
persistent data objects i.e. data that are maintained permanently.
2. The functions that the software performs must be defined.
Software functions provide direct benefit to end users and also provide internal support for
those features that are user visible. Some functions transform data that flow into the system. In
other cases, functions affect some level of control over internal software processing or external
system elements. Functions can be described at many different levels of abstraction.
3. The behavior of the software as a consequence of external events must be represented.
The behavior of computer software is driven by its interaction with the external environment.
Input provided by end users, control data provided by an external system, or monitoring data
collected over a network all cause the software to behave in a specific way.
4. The models that depict information function and behavior must be partitioned in a
manner that uncovers detail in a layered fashion.
Requirements modeling are the first step in software engineering problem solving. It allows
you to better understand the problem and establishes a basis for the solution (design). Complex
problems are difficult to solve in their entirely.
5. The analysis task should move from essential information toward implementation
detail.
Requirements modeling begin by describing the problem from the end-user’s perspective. The
“essence” of the problem is described without any consideration of how a solution will be
implemented. For example, a video game requires that the player “instruct” its protagonist on
what direction to proceed as she moves into a dangerous maze. Implementation detail indicates
how the essence will be implemented.
Design Modeling Principles: The software design model is similar to the architect’s plan or
drawing for a house. It begins by representing the totality of the thing to be built and slowly
refines the thing to provide guidance for constructing each detail. The design model created for
the software provides variety of views of the system. This includes the architecture, the user
interface and component – level detail. Design models provide a concrete specification for the
construction of the software. It represents characteristics of the software that help practitioners
to construct it effectively.
The Design Modeling principles are:
1. Design should be traceable to the requirements model.
The design model should translate the information into architecture; a set of subsystems which
implement major functions and a set of component level designs are the realization of the
analysis classes.
2. Always consider the architecture of the system to be built
Software architecture is the skeleton of the system to be built. It affects interfaces, data
structures, program control flow and behavior, the manner in which testing can be conducted,
the maintainability of the resultant system.
3. Design of data is as important as design of processing functions
The data design is an essential element of architectural design. The manner in which data
objects are realized within the design cannot be left to chance. A well-structured data design
helps to simplify program flow, makes the design and implementation of software components
easier, and makes overall processing more efficient.
4. Both internal and external interfaces must be designed with care
The manner in which data flows between the components of a system has much to do with
processing efficiency, error propagation, and design simplicity. A well-designed interface
makes integration easier and assists the tester in validating component functions.
5. User interface design should be tuned to the needs of the end user.
The user interface is the visible manifestation of the software. No matter how sophisticated its
internal functions, no matter how comprehensive its data structures, no matter how well
designed its architecture, a poor interface design often leads to the perception that the software
is “bad”.
6. Component-level design should be functionally independent,
Functional independence is a measure of the “Single-mindedness” of a software component.
The functionality that is delivered by a component should be cohesive-that is, it should focus
on one and only one function or sub function.
7. Components should be loosely coupled to one another and to the external
environment.
Coupling is achieved in many ways- via a component interface, be messaging, through global
data. As the level of coupling increases, the likelihood of error propagation also increases and
the overall maintainability of the software decreases. Therefore, component coupling should
be kept as low as is reasonable.
8. Design models should be easily understandable
The purpose of design is to communicate information to practitioners who will generate code
to those who will test the software and to others who may maintain the software in the future.
If the design is difficult to understand, it will not serve as an effective communication medium.
9. The design should be developed iteratively. With each iteration, the designer should
strive for greater simplicity
Like almost all creative activities, design occurs iteratively. The first iterations work to refine
the design and correct errors, but later iterations should strive to make the design as simple as
possible.
2.6. Construction Practices
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 the end user.
Even the software development process has undergone a radical change over the years.
In the model software engineering work the coding may be:
1. The direct creation of source code using a programming language.
2. Automatic generation of source code using an intermediates design like representation of
the components to be built.
3. Automatic generation of executable code using 4GL language
Coding Principles and concept
The principle and concept that guide the coding task are closely aligned programming style,
programming language, and programming methods. However, there are a number of
fundamental principles that can be stated.
Preparation Principles:
Before writing the lines of code,
1. Understand the problem to be solved
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 the work easier
5. Create a set of unit tests that will be applied once the component code is completed
Coding Principles:
While writing the code, consider the following points:
1. Construct algorithms by following structured programming practice.
2. Consider the use of proper programming language.
3. Select data structures that will meet the needs of the design.
4. Understand the software architecture and create interfaces that are consistent with it.
5. Keep conditional logic as simple as possible.
6. Create nested loops in a way that makes theme easily testable.
7. Select meaningful variable names and follow other local coding standards
8. Write code that is self-documenting
9. Create a visual layout that aids understanding
Validation Principles: After completing the first coding pass, consider the following
points
1. Conduct a code walkthrough when appropriate
2. Perform unit tests and correct errors that are uncovered
3. Refactor the code
Testing principles and concept:
Testing is a process of executing a program with the intent of finding an error.
A good “test-case” is the highest probability of finding an “as-yet undiscovered errors”.
A successful test is a one which uncovers an as-yet undiscovered errors
Davis suggests a set of testing principles as follows:
1. All tests should be traceable to customer requirements.
The objective of software testing is to uncover errors. It follows that the most server defects
from the user’s point of view are those that cause the program to fail to meet its requirement.
2. Tests should be planned long before testing begins
Test planning can begin as soon as the requirements model is complete. Detailed definition of
test cases can begin as soon as the design model has been solidified. Therefore, all tests can be
planned and designed before any code has been generated.
3. The Pareto principle applies to software testing
In this context the Pareto principle implies that 80 percent of all errors uncovered during testing
will likely be traceable to 20 percent of all program components. The problem is to isolate these
suspect components and to thoroughly test them.
4. Testing should begin “in a small” and progress toward testing “in the large”
The initial testing should be on small individual components. As testing progresses, focus shifts
to find errors in integrated clusters of programs and finally in the entire system.
5. Exhaustive testing is not possible
It may be noted that the number of path permutations for even a moderately sized program is
exceptionally large. Hence for this reason it is impossible to execute every combination of the
paths during testing.
2.7. Software Deployment
The deployment phase includes 3 actions namely 1. Delivery 2. Support 3. Feedback
1. The delivery cycle provides the customer and the end user with an operational software
increment that provides usable functions and features.
2. The support cycle provides documentation, human assistance for all functions and features
introduced during all deployment cycles to date.
3. Each feedback cycle provides the software team with useful inputs. The feedback can help
in modifications to the functions, features and even the approach for the next increments.
The delivery of the software increment is an important milestone of any software project. A
number of key principles should be followed as the team prepares to deliver an increment.
1. Customer expectations for the software must be managed
Before the software delivery the project team should ensure that all the requirements of the
users are satisfied.
2. A complete delivery package should be assembled and tested
The system containing all executable software, support data files, tools and support documents
should be provided with beta testing at the actual user side.
3. A support regime must be established before the software is delivered
This includes assigning the responsibility to the team members to provide support to the users
in case of problem.
4. Appropriate instructional materials must be provided to end users
At the end of construction various documents such as technical manual, operations manual,
user training manual, user reference manual should be kept ready. These documents will help
in providing proper understanding and assistance to the user.
5. Buggy software should be fixed first, delivered later.
Sometimes under time pressure, the software delivers low-quality increments with a warning
to the customer that bugs will be fixed in the next release. Customers will forget you delivered
a high-quality product a few days late, but they will never forget the problems that a low quality
product caused them. The software reminds them every day.
2.8. Requirements Engineering
Requirement Engineering helps software engineers to better understand the problem they will
work to solve. It includes the set of tasks that lead to an understanding of:
1. What will be business impact of the software?
2. What the customer wants exactly?
3. How end user will interact with the system software engineering and other project
stakeholders all participate.
1. Inception
Inception means beginning. It is always problematic to the developer that from where to start.
The customer and developer meet and they decide overall scope and nature of the problem.
The aim is
1. To have the basic understanding of problem
2. To know the people who will use the software
3. To know exact nature of problem.
2. Elicitation
Elicitation means to draw out the truth or reply from anybody. In relation with requirement
engineering, elicitation is a task that helps the customer to define what is required. To know
the objectives of the system to be developed is a critical job.
a. Problem of Scope:
The boundary of the system is ill-defined or the customers/users specify unnecessary technical
detail that may confuse, rather than clarify, overall system objectives.
b. Problem of understanding
• Sometimes both customer as well as developer has poor understanding of
• What is needed?
• Capabilities and limitations of the computing environment.
c. Problems of volatility
Volatility means change from one state to another. The customer’s requirement may change
time to time.
3. Elaboration
Elaboration means to work out in detail. The information obtained during inception and
elicitation is expanded and modified during elaboration. Requirement engineering activity
focuses on developing the technical model of the software that will include:
1. Functions
2. Features
3. Constraints
This is an analysis modeling action. It focuses on “How end users will interact with system”.
4. Negotiation
It means discussion on financial and other commercial issues.
In this step customer, user and stakeholder discuss to decode:
• To rank the requirements
• To decide priorities
• To decide risks
• To finalize the project cost
• Impact of above on cost and delivery
5. Specification
The specification is the final work product produced by requirement engineer. The
specification may take different forms: A written document, a set of graphical model, a
collection of scenarios, a prototype, Mathematical model. It serves as the foundation for
subsequent software engineering activities. It describes the function, performance of a
computer-based-system, constraints that will govern its development.
6. Validation
Products are assessed for quality during validation period. Inconsistencies, omission, errors are
detected and corrected. Work products conform to the standards established for the process,
the project and the product. Clarification related to conflicting requirements, unrealistic
expectations, etc.
7. Requirements management
Helps the project team identify, control and track requirements and changes to requirements at
any time of the project proceeds.
Source traceability table – stakeholders, recognize multiple viewpoint
Dependency traceability table – work towards collaboration asking for questions
Subsystem traceability table
Interface traceability table.
2.9. SRS (Software Requirements Specifications)
A Software requirements specification (SRS), a requirements specification for a software
system, is a description of the behavior of a system to be developed and may include a set of
use cases that describe interactions the users will have with the software. In addition it also
contains non-functional requirements. Non-functional requirements impose constraints on the
design or implementation (such as performance engineering requirements, quality standards,
or design constraints)
Software requirements specification establishes the basis for agreement between customers and
contractors or suppliers (in market-driven projects, these roles may be played by the marketing
and development divisions) on what the software product is to do as well as what it is not
expected to do. Software requirements specification permits a rigorous assessment of
requirements before design can begin and reduces later redesign. It should also provide a
realistic basis for estimating product costs, risks, and schedules.
The software requirements specification document enlists enough and necessary requirements
that are required for the project development. To derive the requirements we need to have clear
and thorough understanding of the products to be developed or being developed. This is
achieved and refined with detailed and continuous communications with the project team and
customer till the completion of the software.
 Question Bank
1. Define SE practices, its importance. 3 Marks
2. Staff briefly essence of SE Practices. 4 Marks
3. State and describe Seven core Principles of software Engineering 4 Marks
4. State and explain the communication Principles 8 Marks
5. State and explain eight planning Principle 8 Marks
6. Briefly explain Barry Boehm’s W5HH Principle. 4 Marks
7. Explain five Analysis modeling Principles. 4 Marks
8. Explain eight design modeling Principles. 8 Marks
9. Write a note on Construction practices 3 Marks
10. Explain preparation, Coding & Validation Principles. 8 Marks
11. State five set of S/W testing Principles. 4 Marks
12. Explain S/W Deployment phases and state five principles. 8 Marks
13. State and explain Seven RE tasks. 8 Marks
14. Define SRS and give its contents. 8 Marks