1

SOFTWARE ENGINEERING

UNIT-1

2. WHAT IS SOFTWARE ENGINEERING? EXPLAIN GENERIC PROCESS

FRAMEWORK (ELEMENTS OF A SOFTWARE PROCESS OR SDLC):

■ Software Engineering: (1) The application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software. (2) The study of
approaches as in (1).

■ Layers of software engineering:

4. SOFTWARE PROCESS

• A software process is a set of activities, methods, practices, and transformations that

people use to develop and maintain software and the associated products (e.g., project
plans, design documents, code, test cases, and user manuals)

A GENERIC PROCESS FRAMEWORK (ELEMENTS OF A SOFTWARE PROCESS):

A generic process framework for software engineering encompasses five activities:

• Communication
– Involves communication among the customer and other stake holders;
encompasses requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule
• Modelling (Analyze, Design)
 2

– Encompasses the creation of models to better under the requirements and the
design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and feedback

GENERIC PROCESS MODEL

The umbrella activities in a software development life cycle process include the following:

1. Software project tracking and control: When plan, tasks, models all have been done
then a network of software engineering tasks that will enable to get the job done on time
will have to be created.
2. Formal technical reviews: This includes reviewing the techniques that have been used
in the project.
3. Software quality assurance: This is very important to ensure the quality measurement
of each part to ensure them.
4. Software configuration management: Software configuration management (SCM) is a
set of activities designed to control change by identifying the work products that are
likely to change, establishing relationships among them, defining mechanisms for
managing different versions of these work products.
5. Document preparation and production: All the project planning and other activities
should be hardly copied and the production gets started here.
 3

6. Re-usability management: This includes the backing up of each part of the software

project they can be corrected or any kind of support can be given to them later to update
or upgrade the software at user/time demand.
7. Re-usability management: This will include all the measurement of every aspects of the
software project.
8. Risk management: Risk management is a series of steps that help a software team to
understand and manage uncertainty. It’s a really good idea to identify it, assess its
probability of occurrence, estimate its impact, and establish a contingency plan that─
‘should the problem actually occur’

3. WHAT IS SOFTARE ENGINEERING PRACTICE & SOFTWARE MYTHS &

PROCESS PATTERNS

The essence of software practice according to George Polya is outlined below:

1. Understand the problem (communication and analysis).

a) Who are the stakeholders?
b) What data, functions, and features are required to properly solve the problem?
c) Is it possible to represent smaller problems that may be easier to understand?
d) Can an analysis model be created

2. Plan a solution (modeling and software design).

a) Have you seen similar problems before?
b) If so, are elements of the solution reusable?
c) Can sub-problems be defined?
d) Can you represent a solution in a manner that leads to effective
implementation?

3. Carry out the plan (code generation).

a) Does the solution conform to the plan?
b) Is each component part of the solution provably correct?

4.Examine the result for accuracy (testing and quality assurance).

a) Is it possible to test each component part of the solution?
b) Does the solution produce results that conform to the data, functions, and
features that are required?
DAVID HOOKER’S seven principles for software engineering practice:

Help you establish mind-set for solid software engineering practice (David Hooker 96).
1: The Reason It All Exists: provide values to users
2: KISS (Keep It Simple, Stupid! As simple as possible)
3: Maintain the Vision (otherwise, incompatible design)
4: What You Produce, Others Will Consume (code with concern for those that must maintain and
extend the system)
 4

5: Be Open to the Future (never design yourself into a corner as specification and hardware
changes)
6: Plan Ahead for Reuse
7: Think! Place clear complete thought before action produces better results.

SOFTWARE MYTHS

Definition: Beliefs about software and the process used to build it. Myths have number of
attributes that have made them insidious (i.e. dangerous).
□ Misleading Attitudes - caused serious problem for managers and technical people.
There are three types of myths:
1. Management myths
2. Customer myths
3. Practitioner myths

Management myths
Managers in most disciplines are often under pressure to maintain budgets, keep schedules on
time, and improve quality.

Myth1: We already have a book that's full of standards and procedures for building software;
won't that provide my people with everything they need to know?
Reality:
□ Are software practitioners aware of existence standards?
□ Does it reflect modern software engineering practice?
□ Is it complete? Is it streamlined to improve time to delivery while still maintaining a
focus on quality?

Customer Myths
Customer may be a person from inside or outside the company that has requested software under
contract.
Myth 1: A general statement of objectives is sufficient to begin writing programs— we can fill
in the details later.
Reality: A poor up-front definition is the major cause of failed software efforts. A formal and
detailed description of the information domain, function, behavior, performance, interfaces,
design constraints, and validation criteria is essential. These characteristics can be determined
only after thorough communication between customer and developer.
Practitioner's myths
Myth1: Once we write the program and get it to work, our job is done.
Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll take you to
get done." Industry data indicate that between 60 and 80 percent of all effort expended on
software will be expended after it is delivered to the customer for the first time.

PROCESS PATTERNS

a. A process pattern
 5

i. describes a process-related problem that is encountered during software

engineering work,
ii. identifies the environment in which the problem has been encountered, and
iii. suggests one or more proven solutions to the problem.

Process Assessment and Improvement

i. Standard CMMI Assessment Method for Process Improvement (SCAMPI) —

provides a five step process assessment model that incorporates five phases:
initiating, diagnosing, establishing, acting and learning.

ii. CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides

a diagnostic technique for assessing the relative maturity of a software organization;
uses the SEI CMM as the basis for the assessment [Dun01]

iii. ISO 9001:2000 for Software—a generic standard that applies to any organization
that wants to improve the overall quality of the products, systems, or services that it
provides. Therefore, the standard is directly applicable to software organizations and
companies. [Ant06]

4 .Explain the following software process models?

i. Waterfall model
ii. V model
iii. Incremental model

Prescriptive Models: Prescriptive process models advocate an orderly approach to software

engineering.

The list of prescriptive models is:

1. Waterfall model
2. V-model
3. Incremental model
4. Evolutionary models: Prototyping model, Spiral model and Concurrent model

The Waterfall Model:

1. Waterfall model is linear sequential life cycle model and it is Introduced by Royce 1970.
2. Diagrammatic representation of waterfall model:
 6

3. Principles of waterfall model:

i. Each phase must be completed perfectly for the next phase to begin.
ii. There is no overlap or moving backward in phases.
4. When to use waterfall model:
Some situations where the use of Waterfall model is most appropriate are:
i. If all the requirements are known perfectly well in advance i.e. clear and fixed.
ii. Product definition is stable.
iii. Technology is understood and is not dynamic.
iv. Ample resources with required expertise are available to support the product.
v. The project is short.
5. Advantages of waterfall model:
i. Simple and Easy to understand and implement.
ii. Reinforces good habits: define-before- design, design-before-code
iii. Phases are processed and completed one at a time.
iv. Works well for smaller projects where requirements are very well understood.
6. Disadvantages:
i. Unrealistic to expect accurate requirements so early in project
ii. Doesn’t reflect iterative nature of exploratory development.
iii. Cannot accommodate changing requirements.
iv. Software is delivered late in project, delays discovery of serious errors.
v. Difficult to integrate risk management

The V-Model:
1. V- Model means Verification and Validation model. Just like the waterfall model, the V-
Shaped life cycle is a sequential path of execution of processes.
2. Diagrammatic representation of v-model:
 7

3. Principles of V – Model:
i. Each phase must be completed before the next phase begins.
ii. Testing of the product is planned in parallel with a corresponding phase of
development in V-model.
4. When to use the V-model:
i. The V-shaped model should be used for small to medium sized projects where
requirements are clearly defined and fixed.
ii. The V-Shaped model should be chosen when ample technical resources are
available with needed technical expertise.
5. Advantages of V-model:
i. Simple and easy to use.
ii. Testing activities like planning, test designing happens well before coding.
Hence higher chance of success over the waterfall model.
iii. Proactive defect tracking – that is defects are found at early stage.
iv. Avoids the downward flow of the defects.
v. Works well for small projects where requirements are easily understood.
6. Disadvantages of V-model:
i. Very rigid and least flexible just like water fall model.
ii. Software is developed only during the implementation phase, so no early
prototypes of the software are produced.
iii. If any changes happen in midway, then the test documents along with requirement
documents has to be updated.

The Incremental Model:

1. In incremental model the whole requirement is divided into various builds. Multiple
development cycles take place here, making the life cycle a “multi-waterfall” cycle. 
Cycles are divided up into smaller, more easily managed modules. Each module
passes through the requirements, design, implementation and testing phases.

2. Diagrammatic representation of incremental model:

 8

3. When to use the Incremental model:

i. When major requirements are defined; however, some details can evolve with
time.
ii. There is a need to get a product to the market early.
iii. A new technology is being used
iv. Resources with needed skill set are not available

4. Advantages of Incremental model:

i. Generates working software quickly and early during the software life cycle.
ii. This model is more flexible – less costly to change scope and requirements.
iii. It is easier to test and debug during a smaller iteration.
iv. In this model customer can respond to each built.
v. Lowers initial delivery cost.
vi. Easier to manage risk because risky pieces are identified and handled during it’d
iteration.

Disadvantages of Incremental model:

i. Needs a clear and complete definition of the whole system before it can be broken
down and built incrementally.
ii. Needs good planning and design.
iii. Overall total cost is higher than waterfall.

5. Explain the following software process models?

a) Evolutionary models: prototyping model, spiral model, concurrent
model
b) Other models
 Unified process approach
 Personal software process
 Team software process

Prototyping:
 9

1. The basic idea here is that instead of freezing the requirements before a design or coding
can proceed, a throwaway prototype is built to understand the requirements. This prototype is
developed based on the currently known requirements and it enables the client to better
understand the requirements of the desired system.
2. Diagrammatic representation of prototyping model:

3. When to use Prototype model:  

i. Prototyping is an attractive idea for complicated and large systems for which
there are no existing system to help determining the requirements.
ii. Prototype model should be used when the desired system needs to have a lot of
interaction with the end users such as web interfaces.
iii. Prototyping is an excellent model for designing good human computer interface
systems.

4. Advantages of Prototype model:

i. Users are actively involved in the development
ii. Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
iii. Errors can be detected much earlier.
iv. Quicker user feedback is available leading to better solutions.
v. Missing functionality can be identified easily

5. Disadvantages of Prototype model:

i. Leads to implementing and then repairing way of building systems.
ii. Practically, this methodology may increase the complexity of the system as scope of
the system may expand beyond original plans.
iii. Incomplete or inadequate problem analysis.
The Spiral model:

1. The spiral model places more emphasis placed on risk analysis. The spiral model has four
phases: Planning, Risk Analysis, Engineering and Evaluation. The baseline spiral, starting in
 10

the planning phase, requirements is gathered and risk is assessed. Each subsequent spiral
builds on the baseline spiral.

2. Diagrammatic representation of spiral model:

3.
Different phases
of spiral
model:
i.

Planning Phase: Requirements are gathered during the planning phase. Requirements like
‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System
Requirement specifications’.
ii. Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and
alternate solutions. A prototype is produced at the end of the risk analysis phase. If
any risk is found during the risk analysis then alternate solutions are suggested and
implemented.
iii. Engineering Phase: In this phase software is developed, along with testing at the end
of the phase. Hence in this phase the development and testing is done.
iv. Evaluation phase: This phase allows the customer to evaluate the output of the
project to date before the project continues to the next spiral.

4. When to use Spiral model:

i. When risk evaluation is important
ii. For medium to high-risk projects
iii. Significant changes are expected (research and exploration)
iv. Requirements are complex
v. Users are unsure of their needs

4. Advantages of Spiral model:

i. High amount of risk analysis is done hence, avoidance of Risk is enhanced.
ii. Good for large and mission-critical projects.
iii. Strong approval and documentation control.
iv. Additional Functionality can be added at a later date.
v. Software is produced early in the software life cycle.
 11

5. Disadvantages of Spiral model:

i. Can be a costly model to use.
ii. Risk analysis requires highly specific expertise.
iii. Project’s success is highly dependent on the risk analysis phase.
iv. Doesn’t work well for smaller projects.

Concurrent model

1. The concurrent development model can be represented schematically as a series of

framework activities, Software engineering actions, and their associated states.
2. The concurrent model is often more appropriate for system engineering projects
where different engineering teams are involved.
3. Diagrammatic representation of concurrent model:

4. Explanation of the above diagram:

Figure above provides a schematic representation of one Software engineering task
within the modeling activity for the concurrent process model. The activity –
modeling- may be in any one of the states noted at any given time. All activities exist
concurrently but reside in different states.
For example, early in the project the communication activity has completed its first
iteration and exists in the awaiting changes state. The modeling activity which
existed in the none state while initial communication was completed now makes a
transition into underdevelopment state. If, however, the customer indicates the
 12

changes in requirements must be made, the modeling activity moves from the under
development state into the awaiting changes state.
The concurrent process model defines a series of events that will trigger transitions
from state to state for each of the Software engineering activities, actions, or tasks.
Component based development
1. Commercial off-the-shelf (COTS) Software components, developed by vendors who offer
them as products, can be used when Software is to be built. These components provide
targeted functionality with well-defined interfaces that enable the component to be integrated
into the Software.
2. The component-based development model leads to Software reuse, and reusability provides
Software engineers with a number of measurable benefits.
3. The component-based development model incorporates the following steps:
i. Available component-based products are researched and evaluated for the application
domain in question.
ii. Software architecture is designed to accommodate the components.
iii. Components are integrated into the architecture.
iv. Comprehensive testing is conducted to ensure proper functionality.

The Formal Methods Model

1. The Formal Methods Model encompasses a set of activities that leads to formal
mathematical specifications of Software.
2. Formal methods enable a Software engineer to specify, develop, and verify a computer-
based system by applying a rigorous, mathematical notation.
3. A variation of this approach, called clean-room Software engineering is currently applied
by some software development organizations.
4. Issues of formal methods model:

1. The development of formal models is quite time-consuming and expensive.

2. Software developers should have the necessary background to apply formal
methods and it demands extensive training is required.
3. It is difficult to use the methods as a communication mechanism for technically
unsophisticated customers.

Aspect-Oriented Software Development:

1. Aspects encapsulate functionality that cross-cuts and co-exists with other functionality.
2. Aspects include a definition of where they should be included in a program as well as
code implementing the cross-cutting concern.
3. An aspect is an abstraction which implements a concern. It includes information where it
should be included in a program.
4. A join point is a place in a program where an aspect may be included (woven).
5. A point cut defines where (at which join points) the aspect will be included in the
program.
 13

6. AOSD—provides a process and methodological approach for defining, specifying,

designing, and constructing aspects.
Personal Software Process (PSP)

1. The Personal Software Process is a framework of techniques to help engineers improve

their performance, and that of their organizations, through a step-by-step, disciplined
approach to measuring and analyzing their work.
2. It provides detailed estimating and planning methods, shows engineers how to track their
performance against these plans, and explains how defined processes can guide their
work.
3. The Personal Software Process shows software engineers how to apply advanced
engineering methods to their daily tasks.
4. Phases of Personal Software Process:
i. Planning. This activity isolates requirements and develops both size and resource
estimates. In addition, a defect estimate (the number of defects projected for the
work) is made. All metrics are recorded on worksheets or templates. Finally,
development tasks are identified and a project schedule is created.
ii. High-level design. A component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
iii. High-level design review. Formal verification methods are applied to uncover
errors in the design. The component level design is refined and reviewed.
iv. Development. Code is generated, reviewed, compiled, and tested. Metrics are
maintained for all important tasks and work results.
v. Postmortem. Using the measures and metrics collected (this is a substantial
amount of data that should be analyzed statistically), the effectiveness of the
process is determined. Measures and metrics should provide guidance for
modifying the process to improve its effectiveness.

Team Software Process (TSP):

1. Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans.
2. Show managers how to coach and motivate their teams and how to help them sustain
peak performance.
3. Accelerate software process improvement by making CMM Level 5 behavior normal and
expected.
a. The Capability Maturity Model (CMM), a measure of the effectiveness of a
software process.
4. Provide improvement guidance to high-maturity organizations.
5. Facilitate university teaching of industrial-grade team skills.

The Unified Process of Software Development

 14

1. The key feature: Software development is done in a series of fixed periods, for example,
between 2 and 6 weeks. Each period is called as iteration. At the end of each iteration, we
have an executable system.
2. Each iteration has its own requirement analysis, design, coding and testing.
3. The software development is incremental. Implement New features added apart from the
User’s suggested changes. 
4. Time boxing an Iteration:
i. Each iteration is timeboxed i.e. fixed in length.
ii. The UP recommends each iteration to be between 2 and 6 weeks.
iii. It has no provision for the extension of an iteration period.
iv. If developers are unable to complete coding the given requirements within fixed
time, then decrease the number of requirements to code.  
5. Diagrammatic representation of UP Model:

6. Advantages of Time boxing an Iteration

i. The UP is architecture-centric and risk-driven.
ii. Team forced to identify core architecture and high-risk, high-value requirements
early. So the prioritization of requirements automatically takes place.
iii. Increase in confidence level of the stakeholders in the development team and the
project.
iv. Increase in confidence of the team-members in their own ability leading to team
satisfaction.
7. UP Phases:
a) Inception
The following questions are asked in this phase:
i. What is the product supposed to do?
ii. Why should my organization embark on a project to build this particular
product?
iii. Does my organization have the resources to build this product?
iv. Is it feasible to do so?
v. How much will this product cost and how much will it bring in?
 15

vi. What will be the duration of the project?

vii. Risk analysis is performed.
viii. Decision whether to go ahead with the project or not is taken.

b) Elaboration:
i. System to be built is analyzed in detail.
ii. Use cases used to document the requirements. Main aim: Get the core
architecture and as many use cases as possible.
iii. The core architecture is coded, verified with user and baselined.
iv. Other high-risk requirements are identified and coded.
v. A project plan is drawn in this phase, resources are allocated and a
schedule is planned.
vi. UML diagrams are used to model the system under design.
c) Construction:

i. Remaining use cases are implemented.

ii. If any new use cases are discovered, they are implemented.
iii. Test cases are written, actual tests are carried out and a test report is
prepared.
iv. Documentation for the system as well as guides for the users are written.
d) Transition:

i. System is installed in its environment and beta-tested.

ii. Feedback is received and System is refined and tuned to adapt in response
to the feedback.
iii. It also includes activities like marketing of the product and training of
users.

6. Explain other Agile Process Models in briefly?

Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In Agile, the tasks are divided to time
boxes (small time frames) to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each
build is incremental in terms of features; the final build holds all the features required by the
customer.
Here is a graphical illustration of the Agile Model −
 16

The Agile thought process had started early in the software development and started becoming
popular with time due to its flexibility and adaptability.
The most popular Agile methods include Rational Unified Process (1994), Scrum (1995),
Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven
Development, and Dynamic Systems Development Method (DSDM) (1995). These are now
collectively referred to as Agile Methodologies, after the Agile Manifesto was published in
2001.
Following are the Agile Manifesto principles −
 Individuals and interactions − In Agile development, self-organization and motivation
are important, as are interactions like co-location and pair programming.
 Working software − Demo working software is considered the best means of
communication with the customers to understand their requirements, instead of just
depending on documentation.
 Customer collaboration − As the requirements cannot be gathered completely in the
beginning of the project due to various factors, continuous customer interaction is very
important to get proper product requirements.
 Responding to change − Agile Development is focused on quick responses to change
and continuous development.
7. Explain Extreme Programming Process Model?
 17

Extreme Programming − A way to handle the common shortcomings

Software Engineering involves −

 Creativity
 Learning and improving through trials and errors

 Iterations

Extreme Programming builds on these activities and coding. It is the detailed (not the only)
design activity with multiple tight feedback loops through effective implementation, testing and
refactoring continuously.
Extreme Programming is based on the following values −

 Communication
 Simplicity

 Feedback

 Courage

 Respect

Extreme Programming takes the effective principles and practices to extreme levels.

 Code reviews are effective as the code is reviewed all the time.
 18

 Testing is effective as there is continuous regression and testing.

 Design is effective as everybody needs to do refactoring daily.

 Integration testing is important as integrate and test several times a day.

 Short iterations are effective as the planning game for release planning and iteration
planning.

Advantages:
Extreme Programming solves the following problems often faced in the software development
projects −
 Slipped schedules − and achievable development cycles ensure timely deliveries.
 Cancelled projects − Focus on continuous customer involvement ensures transparency
with the customer and immediate resolution of any issues.
 Costs incurred in changes − Extensive and ongoing testing makes sure the changes do
not break the existing functionality