Software Engineering

3150711
Student Name:
__________________________
Enrollment No.:
_________________________
Department of CE/CSE(07/31)

Year - 2023-24
 Faculty of Degree Engineering - 083
Department of CE / CSE – 07 / 31

Certificate
EnrollmentNo.:____________________________________
This is to certify that Mr./Ms. ____________________________________
student of Branch CE / CSE and Semester 5th of Dr. Subhash
Technical Campus has satisfactory carried out practical work
in the subject Software Engineering – 3150711 during
academic year 2023-2024.

Submission Date: ___________________________

_______________________________ ___________________________________

Subject In charge Head of Department

 Faculty of Degree Engineering - 083
Department of CE / CSE – 07 / 31

Name:__________________________________________________________
Enrollment No.:__________________________________________________
Subject Name with Code: Software Engineering - 3150711

INDEX

Sr. Page Date Signature

Title
No. No.
1 Softwaredevelopmentlifecycle(SDLC) 1
2 Projectscheduling&tracking, risk analysis. 5
3 Analysisofsoftwarecodingandstandard 13
4 Softwarequalityassurance (SQA) 19
5 Softwaremaintenance 23
6 Softwareengineeringandsoftware engineering Services. 27
7 Casestudyforlibrary 32
8 Examplesonsoftwareengineeringbased onCOCOMOmodel 36
9 Example of cost estimation 39
10 Prepare software requirement specification (SRS). 44
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 1
AIM: SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

CE / CSE - 07 / 31 Page 1
 DR. SUBHASH TECHNICAL CAMPUS

Definition: Software life cycle models describe phases of the software cycle and the order in
which those phases are executed. Each phase produces deliverables required by the next
phase in the life cycle. The Systems Development Life Cycle (SDLC), or Software
Development Life Cycle in systems engineering, information systems and software
engineering, is the process of creating or altering systems, and the models and methodologies
that people use to develop these systems.

[Fig. Phases of Software Development Life Cycle (SDLC)]

1) System Planning: The Planning phase is the m ost cruci al step in c r e a t i n g

a successful system, during this phase you decide exactly what you want to do and the
problems you are trying to solve by:
• Defining the problems, the objectives and the resources such as personnel and
costs.
• Studying the ability of proposing alternative solutions after meeting with
clients, suppliers, consultants and employees.
• Studying how to make your product better than your competitors.

After analyzing this data, you will have three choices: develop a new system,
improve the current system or leave the system as it is.

2) System Analysis: The end-user’s requirements should be determined and

documented, what their expectations are for the system, and how it will perform. A

CE / CSE - 07 / 31 Page 2
 DR. SUBHASH TECHNICAL CAMPUS

feasibility study will be made for the project as well, involving determining whether
it’s organizationally, economically, socially, technologically feasible. It is very
important to maintain strong communication level with the clients to make sure you
have a clear vision of the finished product and its function.

3) System Design: The design phase comes after a good understanding of customer’s
requirements; this phase defines the elements of a system, the components, the
security level, modules, architecture and the different interfaces and type of data that
goes through the system.
A general system design can be done with a pen and a piece of paper to
determine how the system will look like and how it will function, and then a detailed
and expanded system design is produced, and it will meet all functional and technical
requirements, logically and physically.

4) Implementation and Deployment: This phase comes after a complete

understanding of system requirements and specifications; it is the actual construction
process after having a complete and illustrated design for the requested system.
In the Software Development Life Cycle, the actual code is written here, and if
the system contains hardware, then the implementation phase will contain configuration
and fine-tuning for the hardware to meet certain requirements and functions.
In this phase, the system is ready to be deployed and installed in customer’s
premises, ready to become running, live and productive, training may be required for
end users to make sure they know how to use the system and to get familiar with it,
the implementation phase may take a long time and that depends on the complexity of
the system and the solution it presents.

5) System Testing and Integration: Bringing different components and subsystems

together to create the whole integrated system, and then Introducing the system to
different inputs to obtain and analyze its outputs and behavior and the way it
functions. Testing is becoming more and more important to ensure customer’s
satisfaction, and it requires no knowledge in coding, hardware configuration or
design.
Testing can be performed by real users, or by a team of specialized personnel,
it can also be systematic and automated to ensure that the actual outcomes are compared
and equal to the predicted and desired outcomes.
6) System Maintenance: In this phase, periodic maintenance for the system will be carried
out to make sure that the system won’t become obsolete, this will include replacing the
old hardware and continuously evaluating system’s performance, it also includes
providing latest updates for certain components to make sure it meets the
right standards and the latest technologies to face current security threats.

CE / CSE - 07 / 31 Page 3
 DR. SUBHASH TECHNICAL CAMPUS

OUTCOMES:
• After complete these experiments I have learn what is software development life cycle.
• I learn the different phases of the software development life cycle.
• I learn what working of each phases of software development life cycle.
• I learn how to actual develop the software.

CE / CSE - 07 / 31 Page 4
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 2
AIM: PROJECT SCHEDULING & TRACKING, RISK
ANALYSIS.

CE / CSE - 07 / 31 Page 5
 DR. SUBHASH TECHNICAL CAMPUS

Project Scheduling:
Project Scheduling in a project refers to roadmap of all activities to be done with specified order
and within time slot allotted to each activity. Project managers tend to define various tasks, and
project milestones and they arrange them keeping various factors in mind. They look for tasks
lie in critical path in the schedule, which are necessary to complete in specific manner (because
of task interdependency) and strictly within the time allocated.

Software Project Scheduling Principles

• Compartmentalization - the product and process must be decomposed into a
manageable number of activities and tasks
• Interdependency - tasks that can be completed in parallel must be separated from
those that must completed serially
• Time allocation - every task has start and completion dates that take the task
interdependencies into account
• Effort validation - project manager must ensure that on any given day there are
enough staff members assigned to completed the tasks within the time estimated in
the project plan
• Defined Responsibilities - every scheduled task needs to be assigned to a specific
team member
• Defined outcomes - every task in the schedule needs to have a defined outcome
(usually a work product or deliverable)
• Defined milestones - a milestone is accomplished when one or more work products
from an engineering task have passed quality review
Relationship between People and Effort
• Adding people to a project after it is behind schedule often causes the schedule to slip
further
• The relationship between the number of people on a project and overall productivity
is not linear (e.g. 3 people do not produce 3 times the work of 1 person, if the people
have to work in cooperation with one another)
• The main reasons for using more than 1 person on a project are to get the job done
more rapidly and to improve software quality.
Project Scheduling Process:-
• Task networks (activity networks) are graphic representations can be of the task
interdependencies and can help define a rough schedule for particular project
• Scheduling tools should be used to schedule any non-trivial project.
• Program evaluation and review technique (PERT) and critical path method (CPM) are
quantitative techniques that allow software planners to identify the chain of dependent
CE / CSE - 07 / 31 Page 6
 DR. SUBHASH TECHNICAL CAMPUS

tasks in the project work breakdown structure (WBS) that determine the project
duration time.
• Timeline (Gantt) charts enable software planners to determine what tasks will be need
to be conducted at a given point in time (based on estimates for effort, start time, and
duration for each task).
• The best indicator of progress is the completion and successful review of a defined
software work product.
• Time-boxing is the practice of deciding a priori the fixed amount of time that can be
spent on each task. When the task's time limit is exceeded, development moves on to
the next task (with the hope that a majority of the critical work was completed before
time ran out).
Task set for project planning:-

1. Establish project scope.

2. Determine feasibility.
3. Analyze risks.
4. Define required resources.
a. Determine required software resources.
b. Define reusable software resources.
c. Identify environmental resources.
5. Estimate cost and effort.
a. Decompose the problem.
b. Develop two or more estimates using size, function points, process tasks, or use
cases.
c. Reconcile the estimates.
6. Develop a project schedule.
a. Establish a meaningful task set.
b. Define a task network.
c. Use scheduling tools to develop a time-line chart.
d. Define schedule tracking mechanisms.

CE / CSE - 07 / 31 Page 7
 DR. SUBHASH TECHNICAL CAMPUS

Task Network:-
• Task network
➢ graphic representation of the task flow for a project;
➢ depicts major new tasks
• Take into consideration
➢ task interdependencies
➢ parallel tasks
➢ critical path tasks

Timeline Chart (Gantt chart):-

• GANTT charts are a project planning tool that can be used to represent the
timing of tasks required to complete a project.
• It describes similar information to a PERT chart.
• Here is one that was produced automatically with a project management tool from the
PERT chart info above:

CE / CSE - 07 / 31 Page 8
 DR. SUBHASH TECHNICAL CAMPUS

Tracking Project Schedules:-

• Periodic project status meetings with each team member reporting progress and
problems
• Evaluation of results of all work product reviews
• Comparing actual milestone completion dates to scheduled dates
• Comparing actual project task start-dates to scheduled start-dates
• Informal meeting with practitioners to have them asses subjectively progress to date
and future problems
• Use earned value analysis to assess progress quantitatively

CE / CSE - 07 / 31 Page 9
 DR. SUBHASH TECHNICAL CAMPUS

Risk Analysis & Management

Software Risks:-
Risk always involves two characteristics
• Uncertainty: the risk may or may not happen& that is, there are no probable risks.
• Loss: if the risk becomes a reality, unwanted consequences or losses will occur
When risks are analyzed, it is important to quantify the level of uncertainty and the degree of
loss associated with each risk.
To accomplish this, different categories or types of risks are considered.
• Project Risks
• Technical Risks
• Business Risks
• Known Risks.
• Predictable Risks unpredictable Risks

• Project Risk:-

➢ Project risks make threats the project plan.

➢ That is, if project risks become real, it is likely that project schedule will slip and
that costs will increase.
➢ Project risks identify potential budgetary, schedule, personnel /staffing and
organi+ation0, resource, customer, and requirements problems and their impact on
a software project.
➢ Project comple1ity, size, and the degree of structural uncertainty were also
defined as project risk factors.
• Technical Risk:-

➢ Technical risks threaten the quality and timeliness of the software to be produced.
➢ If a technical risk becomes a reality, implementation may become difficult or
impossible.
➢ Technical risks identify potential design, implementation, interface, verification, and
maintenance problems.
➢ In addition, specification ambiguity, technical uncertainty, and 3leading4edge3
technology are also risk factors.

CE / CSE - 07 / 31 Page 10
 DR. SUBHASH TECHNICAL CAMPUS

• Business Risk:-

➢ Business risks threaten the feasibility of the software to be built.

➢ Business risks often jeopardize the project or the product.
➢ Top five business risks are:
o Building a e1cellent product or system that no one really wants (market risk).
o Building a product that no longer fits into the overall business strategy for the
company (strategic risk).
o Building a product that the sales force does not understand how to sell.
o Losing the support of senior management due to a change in focus or a change
in people (management risk).
o Losing budgetary or personnel commitment (budget risks).

• Known Risk:-

➢ Known risks are those that can be uncovered after careful evaluation of the project
plan, the business and technical environment in which the project is being
developed.
➢ Other reliable information sources (e.g., unrealistic delivery date, lack of documented
requirements or software scope, poor development environment).
• Predictable Risk:-

➢ Predictable risks are generalized from past project e1perience (e.g., staff turnover,
poor communication with the customer, etc).
➢ Unpredictable risks are the joker in the deck. They can and do occur, but they are
e1tremely difficult to identify in advance.
Reactive Risk Management:-
➢ Project team reacts to risks when they occur.
➢ More commonly, the software team does nothing about risks until something goes
wrong.
➢ Then, the team involved into action in an attempt to correct the problem rapidly.
This is often called a fire fighting mode.
➢ When this fails, crisis management! takes over and the project is in real jeopardy.

CE / CSE - 07 / 31 Page 11
 DR. SUBHASH TECHNICAL CAMPUS

Proactive Risk Management:-

➢ Proactive strategy begins long before technical work is initiated.
➢ Potential risks are identified, their probability and impact are assessed, and they
are ranked by importance.
➢ Then, the software team establishes a plan for managing risk.
➢ The primary objective is to avoid risk, but because not all risks can be avoided,
the team works to develop a contingency plan that will enable it to respond in a
controlled and effective manner.

OUTCOMES:
• After complete these experiments I have learnt about project scheduling and project
tracing.
• I have learnt the the risk analysis and different types of risks and risk management.
• I have learnt about all the basic tokens of coding.

CE / CSE - 07 / 31 Page 12
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 3
AIM: ANALYSIS OF SOFTWARE CODING AND STANDARD

CE / CSE - 07 / 31 Page 13
 DR. SUBHASH TECHNICAL CAMPUS

1. Coding Standards:
➢ General coding standards pertain to how the developer writes code. The SISEPG
has come up with a small set of items it feels should be followed regardless of the
programming language being used.

• Indentation :
➢ Proper and consistent indentation is important in producing easy to read and
maintainable programs. Indentation should be used to:
o Emphasize the body of a control statement such as a loop or a select
statement
o Emphasize the body of a conditional statement
o Emphasize a new scope block

Examples:
/* Indentation used in a loop construct. Four spaces are used for
indentation. */

for ( int i = 0 ; i < number_of_employees ; ++i )

{
total_wages += employee [ i ] . wages ;
}
// Indentation used in the body of a method. package
void get_vehicle_info ( )
{
System.out.println ( “VIN: “ + vin ) ;
System.out.println ( “Make: “ + make ) ;
System.out.println ( “Model: “ + model ) ;
System.out.println ( “Year: “ + year ) ;
}
/* Indentation used in a conditional statement. */

IF ( IOS .NE. 0 ) WRITE ( * , 10 ) IOS ENDIF 10 FORMAT ( “Error

opening log file: “, I4 )

• Inline Comments
➢ Inline comments explaining the functioning of the subroutine or key aspects of the
algorithm shall be frequently used. See section 4.0 for guidance on the usage of
inline comments.

• Structured Programming
➢ Structured (or modular) programming techniques shall be used. GO TO
statements shall not be used as they lead to “spaghetti” code, which is hard to read
and maintain, except as outlined in the FORTRAN Standards and Guidelines.

CE / CSE - 07 / 31 Page 14
 DR. SUBHASH TECHNICAL CAMPUS

• Classes, Subroutines, Functions, and Methods

➢ Keep subroutines, functions, and methods reasonably sized. This depends upon
the language being used. For guidance on how large to make software modules
and methods, see section 4.0. A good rule of thumb for module length is to constrain
each module to one function or action (i.e. each module should only do one “thing”).
If a module grows too large, it is usually because the programmer is trying to
accomplish too many actions at one time.

• Source Files
➢ The name of the source file or script shall represent its function. All of the
routines in a file shall have a common purpose.

• Variable Names
➢ Variable shall have mnemonic or meaningful names that convey to a casual
observer, the intent of its use. Variables shall be initialized prior to its first use.

• Use of Braces
➢ In some languages, braces are used to delimit the bodies of conditional statements,
control constructs, and blocks of scope.

for (int j = 0 ; j < max_iterations ; ++j)

{
/* Some work is done here. */
}
or the Kernighan and Ritchie style:
for ( int j = 0 ; j < max_iterations ; ++j )
{
/* Some work is done here. */
}

• Compiler Warnings
➢ Compilers often issue two types of messages: warnings and errors. Compiler
warnings normally do not stop the compilation process. However, compiler errors
do stop the compilation process, forcing the developer to fix the problem and
recompile.
➢ Compiler and linker warnings shall be treated as errors and fixed. Even though the
program will continue to compile in the presence of warnings, they often indicate
problems which may affect the behavior, reliability and portability of the code.

2. Coding Guidelines
➢ General coding guidelines provide the programmer with a set of best practices which
can be used to make programs easier to read and maintain. Unlike the coding standards,
the use of these guidelines is not mandatory. However, the programmer is

CE / CSE - 07 / 31 Page 15
 DR. SUBHASH TECHNICAL CAMPUS

encouraged to review them and attempt to incorporate them into his/her

programming style where appropriate.

• Line Length
➢ It is considered good practice to keep the lengths of source code lines at or below 80
characters. Lines longer than this may not be displayed properly on some terminals
and tools. Some printers will truncate lines longer than 80 columns. FORTRAN is
an exception to this standard. Its line lengths cannot exceed 72 c

• Spacing
➢ The proper use of spaces within a line of code can enhance readability. Good rules
of thumb are as follows:
o A keyword followed by a parenthesis should be separated by a space.
o A blank space should appear after each comma in an argument list.
o All binary operators except “.” should be separated from their operands by
spaces. Blank spaces should never separate unary operators such as unary
minus, increment (“++”), and decrement(“—“) from their operands.
o Casts should be made followed by a blank space.

• Wrapping Lines
➢ When an expression will not fit on a single line, break it according to these following
principles:
o Break after a comma

• Variable Declarations
➢ Variable declarations that span multiple lines should always be preceded by a type.

Example:

Acceptable:
int price , score ;

Acceptable:
int price ;
int score ;

Not Acceptable:
int price ,
score ;

CE / CSE - 07 / 31 Page 16
 DR. SUBHASH TECHNICAL CAMPUS

• Program Statements

➢ Program statements should be limited to one per line. Also, nested statements
should be avoided when possible.

• Use of Parentheses

➢ It is better to use parentheses liberally. Even in cases where operator precedence

unambiguously dictates the order of evaluation of an expression, often it is beneficial
from a readability point of view to include parentheses anyway.

• Inline Comments

➢ Inline comments promote program readability. They allow a person not familiar
with the code to more quickly understand it. It also helps the programmer who
wrote the code to remember details forgotten over time. This reduces the amount of
time required to perform software maintenance tasks.

• Coding for Readability for Efficiency vs.

➢ There are many aspects to programming. These include writing software that runs
efficiently and writing software that is easy to maintain. These two goals often
collide with each other. Creating code that runs as efficiently as possible often means
writing code that uses tricky logic and complex algorithms, code that can be hard to
follow and maintain even with ample inline comments.

• Meaningful Error Messages

➢ Error handling is an important aspect of computer programming. This not only

includes adding the necessary logic to test for and handle errors but also involves
making error messages meaningful.

• Reasonably Sized Functions and Methods

➢ Software modules and methods should not contain an excessively large number of
lines of code. They should be written to perform one specific task. If they become
too long, then chances are the task being performed can be broken down into subtasks
which can be handled by new routines or methods.

• Number of Routines per File

➢ It is much easier to sort through code you did not write and you have never seen
before if there are a minimal number of routines per file. This is only applicable to
procedural languages such as C and FORTRAN. It does not apply to C++ and Java

CE / CSE - 07 / 31 Page 17
 DR. SUBHASH TECHNICAL CAMPUS

OUTCOMES:
• After complete these experiments I have learnt how to code in any languages.
• I have learnt the different coding standards, guidelines and compiler warning when
executing the code.
• I have learnt about all the basic tokens of coding.

CE / CSE - 07 / 31 Page 18
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 4
AIM: SOFTWARE QUALITY ASSURANCE

CE / CSE - 07 / 31 Page 19
 DR. SUBHASH TECHNICAL CAMPUS

Software quality assurance (often called quality management) is an umbrella activity

that is applied throughout the software process.

➢ It is planned and systematic pattern of activities necessary to provide high degree of

confidence in the quality of a product.

➢ Software quality assurance (SQA) encompasses An SQA process. Specific quality

assurance and quality control tasks. Effective software engineering practice. Control of
all software work products and the changes made to them. A procedure to ensure
compliance with software development standards. Measurement and reporting
mechanisms.

• Importance of SQA:

➢ Quality control and assurance are essential activities for any business that produces
products to be used by others.

➢ Prior to the twentieth century, quality control was the sole responsibility of the
craftsperson who built a product.

➢ As time passed and mass production techniques became commonplace, quality control
became an activity performed by people other than the ones who built the product.

➢ Software quality is one of the pivotal aspects of a software development company.

➢ Software quality assurance starts from the beginning of a project, right from the analysis
phase.

➢ SQA checks the adherence to software product standards, processes, and procedures.

➢ SQA includes the systematic process of assuring that standards and procedures are
established and are followed throughout the software development life cycle and test cycle
as well.

➢ The compliance of the built with agreed-upon standards and procedures is evaluated
through process monitoring, product evaluation, project management etc.

➢ The major reason of involving software quality assurance in the process of software
product development is to make sure that the final product built is as per the
requirement specification and comply with the standards.

• SQA Activities:

Preparing SQA plan for a project:

➢ The plan is developed as part of project planning and is reviewed by all stakeholders.

➢ Quality assurance actions performed by the software engineering team and the SQA
group are governed by the plan.

CE / CSE - 07 / 31 Page 20
 DR. SUBHASH TECHNICAL CAMPUS

➢ The plan identifies evaluations to be performed, audits and reviews to be conducted,

standards that are applicable to the project, procedures for error reporting and tracking, work
products that are produced by the SQA group and feedback that will be provided to the
software team.

Participate in the development of the project’s software process description:

➢ The software team selects a process for the work to be performed.

➢ The SQA group reviews the process description for compliance with organizational
policy, internal software standards, externally imposed standards, and other parts of the
software project plan.

Review software engineering activities to verify compliance with the defined software
process:

➢ The SQA group identifies, documents, and tracks deviations from the process and verifies
that corrections have been made.

Audit designated software work products to verify compliance with those defined as
part of the software process:

➢ The SQA group reviews selected work products; identifies, documents, and tracks
deviations; verifies that corrections have been made; and periodically reports the results
of its work to the project manager.

Ensure that deviations in software work and work products are documented and
handled according to a documented procedure:

➢ Deviations may be encountered in the project plan, process description, applicable standards,
or software engineering work products.

Records any noncompliance and reports to senior management:

➢ Noncompliance items are tracked until they are resolved.

• SQA Techniques:

Data Collection:

Statistical quality assurance implies the following steps:

1. Information about software defects is collected and categorized.

2. An attempt is made to trace each defect to its underlying cause (e.g., non- conformance to
specifications, design error, violation of standards, poor communication with the customer).
3. Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all possible
causes), isolate the 20 percent (the "vital few").
4. Once the vital few causes have been identified, move to correct the problems that have caused
the defects.

CE / CSE - 07 / 31 Page 21
 DR. SUBHASH TECHNICAL CAMPUS

➢ A software engineering organization collects information on defects for a period of one year.
➢ Some of the defects are uncovered as software is being developed.
➢ Others are encountered after the software has been released to its end users. Although
hundreds of different errors are uncovered, all can be tracked to one (or more) of the
following causes:
o Incomplete or erroneous specifications (IES)
o Misinterpretation of customer communication (MCC)
o Intentional deviation from specifications (IDS)
o Violation of programming standards (VPS)
o Error in data representation (EDR)
o Inconsistent component interface (ICI)
o Error in design logic (EDL)
o Incomplete or erroneous testing (IET)
o Inaccurate or incomplete documentation (IID)
o Error in programming Language translation of design (PLT)
o Ambiguous or inconsistent human/computer interface (HCI)
o Miscellaneous (MIS)

OUTCOMES:
• After complete these experiments I have learnt about the quality and assurance of
software.
• I have learnt the importance of SQA, different SQA techniques and SQA activities.
• I have learnt the steps about data collection.

CE / CSE - 07 / 31 Page 22
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 5
AIM: SOFTWARE MAINTENANCE

CE / CSE - 07 / 31 Page 23
 DR. SUBHASH TECHNICAL CAMPUS

➢ Definition:-

ntenance in software engineering

Software maintenance engineering is is the
the m odiodifficationonof
modification
a software product after delivery to
to correct
correct faults,
faults, to
to improve ofof
improve performance
performance or
or other
other
attributes. A common perception of of maintenance
maintenance is is that
that itit merely
merely involves
involves fixing
fixing
defects.

• Objectives of Software maintenance:-

➢present a new model of software lifecycle called the staged model

➢describe research issues within this framework.
➢describe agenda for research in software maintenance and evolution over the next
ten years.

• Types Of Software Maintenance:

There are four categories of software change:

➢ Corrective
➢ Adaptive
➢ Perfective
➢ Preventive

CE / CSE - 07 / 31 Page 24
 DR. SUBHASH TECHNICAL CAMPUS

• Corrective Change

Corrective change, most commonly referred to as “bugs,” is the most typical change
associated with maintenance work. Corrective changes address errors and faults in
your software that could affect various areas of your software; design, logic or code.
Most commonly, these changes are sprung by bug reports created by users. It is
important to note that sometimes problem reports submitted by users are actually
enhancements of the system not bugs.

• Adaptive Change

Adaptive change is triggered by changes in the environment your software

lives in. An adaptive change can be triggered by changes to the operating system,
hardware, software dependencies and even organizational business rules and policies.
These modifications to the environment can trigger changes within other parts of
your software. For example, updating the server, compilers, etc or modifications to
shipping carriers and payment processors can affect functionality in your software.

• Perfective Change

Perfective changes refers to the evolution of requirements and features in your

existing system. As your software gets exposed to users they will think of different
ways to expand the system or suggest new features that they would like to see as part
of the software, which in turn can become future enhancements to the system. Perfective
changes also includes removing features from a system that are not effective and
functional to the end goal of the system. Surprisingly, 50-55% of most maintenance
work is attributed to perfective changes.

• Preventive Change

Preventive changes refer to changes made to increase the understanding and

maintainability of your software in the long run. Preventive changes are focused in
decreasing the deterioration of your software in the long run. Restructuring,
optimizing code and updating documentation are common preventive changes.
Executing preventive changes reduces the amount of unpredictable effects a software

CE / CSE - 07 / 31 Page 25
 DR. SUBHASH TECHNICAL CAMPUS

can have in the long term and helps it become scalable, stable, understandable and
maintainable.

• The Advantages of Software Maintenance:-

➢ Software maintenance is termed as modifying a software application or a product

after its delivery to the users.

➢ The main aim of the software application maintenance is to correct the issues and
faults in the product and to improve its performance.

➢ Whilst the common perception regarding the software maintenance is that it is just
meant to fix defects in an application, researches have shown that most of the time
it involves non-corrective actions.

➢ Much like automobiles, the software applications also need timely maintenance in
order to make sure that they run smoothly and prevent of issues from occurring.

OUTCOMES:
• After complete these experiments I have learnt about the software maintenance.
• I have learnt about objectives and different types or categories of software
maintenance.
• I have learnt the advantages of software maintenance.

CE / CSE - 07 / 31 Page 26
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 6
AIM: SOFTWARE ENGINEERING AND SOFTWARE
ENGINEERING SERVICES.

CE / CSE - 07 / 31 Page 27
 DR. SUBHASH TECHNICAL CAMPUS

• Basic path Testing

In this method the procedural design using basic set of execution path is tested. This
basis set ensures that every execution path will be tested at least once.
✓ Flow graph notation
Path testing is a structural testing strategy. This method is intended to exercise every
independent execution path of a program at least once.
Following are the steps that are carried out while performing path testing.
Step 1: Design the flow graph for the program or a component.
Step 2: Calculate the cyclomatic complexity.
Step 3: select a basic set of path.
Step 4: Generate test cases for these paths.

Step 1: Design the flow graph for the program or a component.

Flow graph is a graphical representation of a logical control flow of the program.
Such a graph consists of circle called a flow graph node which basically represent one or
more procedural statements and arrow called as edges or links which basically represent control
flow. In this flow graph the areas bounded by nodes and edges are called regions. Various
notation used in flow graph are (see fig).
On a Flow Graph:

1. Arrows called edges indicates flow of control.

2. Circles called nodes indicates one or more actions.
3. Areas bounded by edges and nodes are called regions.
4. A predicate node is a node containing a condition.

To indicate a Sequence:

Statement 1

Statement 2

To indicate "IF-THEN-ELSE":

CE / CSE - 07 / 31 Page 28
 DR. SUBHASH TECHNICAL CAMPUS

if

True False

To indicate a "WHILE" Loop:

while

True

False

To indicate a "CASE" Statement:

Case 1 Case n

CE / CSE - 07 / 31 Page 29
 DR. SUBHASH TECHNICAL CAMPUS

void search(int key, int n, inta[])

{
int mid;
int bottom = 0;
int top = n - 1;
while (bottom <= top)
{ mid = (top + bottom) / 2;
if(a [mid] == key)
{
printf(“Element is present”);
return;
} //end of if
else
{
if(a [mid] < key)
bottom = mid + 1;
else
top = mid – 1;
} //end of else
} //end of while
} //end of search
The flow graph will be

CE / CSE - 07 / 31 Page 30
 DR. SUBHASH TECHNICAL CAMPUS

Step 2: Calculate the cyclomatic complexity.

The cyclomatic complexity can be computed by three ways:
1) Cyclomatic complexity= total number of regions in the flow graph = 4(note that in
above flow graph regions are given by shaded roman letters)
2) Cyclomatic complexity= E – N + 2 = 13 edges – 11 nodes + 2
=2+2=4
3) Cyclomatic complexity= P + 1 = 3 + 1 = 4. There are three predicted (decision
making) nodes: Nodes 3,5, and 8.

Step 3: select a basic set of path.

The basic paths are:
Path 1 : 1,2,3,4,5,6,7,11
Path 2 : 1,2,3,11
Path 3 : 1,2,3,4,5,8,9,3….
Path 4: 1,2,3,4,5,8,10,3….

Step 4: Generate test cases for these paths.

After computing cyclomatic complexity and finding independent basis paths, the
test cases are to be executed for these paths.

OUTCOMES:
• After complete these experiments I have learnt about the software Software
engineering and software engineering services.
• I have learnt about basic path and graph.

CE / CSE - 07 / 31 Page 31
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 7
AIM: CASE STUDY FOR LIBRARY

CE / CSE - 07 / 31 Page 32
 DR. SUBHASH TECHNICAL CAMPUS

What is a case study?

A case study is an empirical inquiry that investigates a contemporary phenomenon within its
real-life context, especially when the boundaries between phenomenon and context are not
clearly evident.
The case study inquiry

• Copes with the technically distinctive situation in which there will be many more
variables of interest that data points, and as one result
• Relies on multiple sources of evidence, with data needing to converge in a
triangulating fashion, and as another result
• Benefits from the prior development of theoretical propositions to guide data
collection and analysis.

Why conduct a case study?

➢ To gain a deep understanding of a phenomenon
• Example: To understand the capability of a new tool
• Example: To identify factors affecting communication in code inspections
• Example: To characterize the process of coming up to speed on a project
➢ Objective of Investigation
• Exploration- To find what’s out there
• Characterization- To more fully describe
• Validation- To find out whether a theory/hypothesis is true
➢ Subject of Investigation
• An intervention, e.g. tool, technique, method, approach to design, implementation,
or organizational structure.
• An existing thing or process, e.g. a team, releases, defects

Types of Case Studies

1. Explanatory
• Adjudicates between competing explanations
• Example: How important is implementation bias in requirements engineering?
• Rival theories: existing architectures are useful for anchoring, vs. existing
architectures are over-constraining during RE
2. Descriptive
• Describes sequence of events and underlying mechanisms
• Example: How does pair programming actually work?
• Example: How do software immigrants naturalize?
3. Causal
• Looks for causal relationship between concepts
• Example: Requirements errors are more likely to cause safety-related defects than
programming errors.

CE / CSE - 07 / 31 Page 33
 DR. SUBHASH TECHNICAL CAMPUS

4. Exploratory
• Criteria or parameters instead of purpose
• Example: Christopher Columbus’ voyage to the new world
• Example: What do CMM level 3 organizations have in common?

• Problem Statement:

➢ The case study titled Library Management System is library management software for
the purpose of monitoring and controlling the transactions in a library. This case study
on the library management system gives us the complete information about the library
and the daily transactions done in a Library.

➢ We need to maintain the record of new s and retrieve the details of books available in
the library which mainly focuses on basic operations in a library like adding new
member, new books, and up new information, searching books and members and
facility to borrow and return books.

The following are the brief description on the functions achieved through this case study:

• End-Users:

Librarian: To maintain and update the records and also to cater the needs of the users.
Reader: Need books to read and also places various requests to the librarian.
Vendor: To provide and meet the requirement of the prescribed books.

1. Class diagram: These diagrams depict the behavioral pattern of the system, i.e. how each and
every class is inter-related to the other one, which relationship exists among each of the classes,
etc. There would be only one class diagram possible for a single system.

2. Use case diagram: Use case diagram comprises of use cases and actors such that there would
be various kinds of relationships among the use cases and the actors.

3. Activity diagram: This diagram denotes the structural flow of the activities in the form of
flow chart with decision boxes enhanced and hence is also used for troubleshooting like raising
exceptions when a particular action is done and the alternative to be done when something
abnormal is done.

• Class Diagram

Classes identified:
Library
Librarian
Books Database
User
Vendor

CE / CSE - 07 / 31 Page 34
 DR. SUBHASH TECHNICAL CAMPUS

OUTCOMES:
• After complete these experiments I have learnt about case study and why we are using
case study.
• I have learnt about different types or case study.
• I have learnt the different types of class diagrams.

CE / CSE - 07 / 31 Page 35
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 8
AIM: EXAMPLES ON SOFTWARE ENGINEERING BASED
ON COCOMO MODEL.

CE / CSE - 07 / 31 Page 36
 DR. SUBHASH TECHNICAL CAMPUS

• Example:

Suppose that a project was estimate to be 400KLC. Calculate the efforts &
development time for each of the three models.D=Cb(E)db
1) Organic
2) Semidetached
3) Embedded

Solution:
➢ The basic COCOMO equations take the form
E=ab(KLOC)bb
D=cb(E)db

Estimated size of the projects 400KLOC.

1) Organic mode:

E=2.4(400)1.05
E=1295.31 PM

D=2.5(1295.31)0.38
D=38.07 M

2) Semidetached mode:

E=3.4(400)1.12
E=2462.79 PM

D=2.5(2462.79)0.35
D=38.45 M

3) Embedded mode:

E=3.6(400)1.20
E=4772.81 PM

D=3.60(400)0.32
D=37.59 M

CE / CSE - 07 / 31 Page 37
 DR. SUBHASH TECHNICAL CAMPUS

OUTCOMES :
• After complete these experiments I have learnt about COCOMO Model.
• I have learnt examples of COCOMO model and calculation of three modes of
COCOMO model.

CE / CSE - 07 / 31 Page 38
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL : 9
AIM : EXAMPLE OF COST ESTIMATION.

CE / CSE - 07 / 31 Page 39
 DR. SUBHASH TECHNICAL CAMPUS

• Software Measurement:

“Software measurement is an ability to measure attributes of software and software

development process. So that the software engineering activities can be improved.”
1. Direct: Cost, effonapplied, lines of code produced, execution speed, defects.
2. Indirect: Functionality, quality, reliability, efficiency, complexity, maintainability.

• Size oriented matrices:

➢ Derived by considering the size of software that has been produced.
➢ The organization builds a simple record of size measure for the software projects.
➢ It is built on post experiences of organizations.
➢ It is direct measure of software.

Project LOC Effort Cost($) Doc(pgs) Errors Defeats People

ABC 10,000 20 170 400 100 12 4

PQR 20,000 60 300 1000 129 32 6

XYZ 35,000 65 522 1290 280 87 7

. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .

Table: Size measure

A sample set of size measure that can be developed is given below:

1) Size=Kilo Lines Of Code(KLOC)
2) Effort=Person/Month
3) Productivity=KLOC/PM
4) Quality=Number of faults/KLOC
5) Cost=$/KLOC
6) Documentation=Pages of documentation/KLOC

• Function point calculation(Function oriented metrics):

(FP)=Count total × (0.65 + (0.01 × Sum(Fi))

CE / CSE - 07 / 31 Page 40
 DR. SUBHASH TECHNICAL CAMPUS

Once FP is calculated then we can compute various measures as follows:

1) Productivity=FP/PM
2) Quality=Number of faults/FP
3) Cost=$/FP
4) Documentation=Pages of documentation/FP

Example: Study of requirement specification for ABC project has produced following
results.
Need for 7 inputs
10 outputs
6 inquiries
17 files
4 external interfaces
Input and external interface function point attributes are average complexity and all
other function points attributes are of low complexity.
Determine adjusted function points assuming complexity adjustment value is 32.
Solution:
7 inputs
10 outputs
6 inquiries
17 files
4 external interfaces
Adjusted function point value ∑(Fi)=32.
Let us calculate count total value:
Measurement Count Weighting Weighting Weighting
parameters factors factors factors
× Simple Average Complex
Input 7 × 4 28
Output 10 × 4 40
Inquiries 6 × 3 18
Files 17 × 7 119
Interfaces 4 × 7 28
Count FP =233

CE / CSE - 07 / 31 Page 41
 DR. SUBHASH TECHNICAL CAMPUS

FP=UFP × [0.65+0.01+∑ (Fi)]

=233 × [0.65+0.01×32]
=233 × [0.65 + 0.32]
=226.01
Example: Explain function analysis method. Compute function points for the following
data set.
Inputs=8, outputs=12, inquiries=4, logical files=41, interfaces=1, ∑ (Fi2) 41.
Solution:
The given functional units are :
1) Inputs=8
2) Outputs=12
3) Inquiries=4
4) Logical files=41
5) Interfaces=1

Assume complexity adjustment factors and weighting factor as average.

UFP= 8 × 4 + 12 × 5 + 4 × 4 + 41 × 10 + 1 × 7
= 32 + 60 + 16 + 410 + 7
= 525

CAF= (0.65 + 0.01 +∑ (Fi)])

= 0.65 + 0.01(41)
= 1.06

FP= UFP × CAF

= 525 × 1.06
= 556.5

CE / CSE - 07 / 31 Page 42
 DR. SUBHASH TECHNICAL CAMPUS

OUTCOMES :
• After complete these experiments I have learnt about Software measurements.
• I have learnt examples of Cost estimation.

CE / CSE - 07 / 31 Page 43
 DR. SUBHASH TECHNICAL CAMPUS

PRACTICAL: 10
AIM : PREPARE SOFTWARE REQUIREMENT SPECIFICATION
(SRS).

CE / CSE - 07 / 31 Page 44
 DR. SUBHASH TECHNICAL CAMPUS

Software Requirement Specification For Hotel Management System:

1. Introduction :-

• The following subsections of the Software Requirements Specifications (SRS)

document provide an overview of the entire SRS.

1.1 Purpose :-

➢ The Software Requirements Specification (SRS) will provide a detailed description of

the requirements for the Hotel Management System (HMS). This SRS will allow for a
complete understanding of what is to be expected of the HMS to be constructed.

➢ The clear understanding of the HMS and its’ functionality will allow for the correct
software to be developed for the end user and will be used for the development of the
future stages of the project.

➢ This SRS will provide the foundation for the project. From this SRS, the HMS can be
designed, constructed, and finally tested.

➢ This SRS will be used by the software engineers constructing the

➢ HMS and the hotel end users.

1.2 Scope :-

➢ The software product to be produced is a Hotel Management System which will

automate the major hotel operations.
➢ The first subsystem is a Reservation and Booking System to keep track of
reservations and room availability.
➢ The second subsystem is the Tracking and Selling Food System that charges the
current room. The third subsystem is a General Management Services and Automated
Tasks System which generates reports to audit all hotel operations and allows
modification of subsystem information.
➢ The end users are the hotel staff (customer service representative) and hotel managers.
Both user types can access the Reservation and Booking System and the Food
Tracking and Selling System. The General Management System will be restricted to
management users.

1.3 Definition:-

➢ SRS – Software Requirements Specification

➢ HMS – Hotel Management System

➢ Subjective satisfaction – The overall satisfaction of the system

➢ End users – The people who will be actually using the system

CE / CSE - 07 / 31 Page 45
 DR. SUBHASH TECHNICAL CAMPUS

1.3.1 Overview :-

➢ The SRS is organized into two main sections.

➢ The first is The Overall Description and the second is the Specific Requirements. The
Overall Description will describe the requirements of the HMS from a general high level
perspective.

➢ The Specific Requirements section will describe in detail the requirements of the system.

1.4 Additional Information:-

➢ The system work on internet server, so it will operated by any end user for the buying
purpose.

2. General Description:-

➢ The Hotel Management System(HMS) application enables vendors to set up online

Hotel Booking System, customers to browse through the Online Reservation, and a
system administrator can be Request Aceept any Time and maintain lists of Booking
categories. Also the developer is designing an Hotel Management System to manage
the Booking and also help customers Reservation.The Hotel Management System
(HMS) will use the internet as the sole method for Easy Booking The Rooms to the
consumers.

3. Functional Requirement :-

➢ This section provides requirement overview of the system.Various functional modules

that can be implemented by the system will be –

3.1 Description :-

3.1.1 Registration:-

➢ If customer wants to buy the product then he/she must be registered, unregistered user
can’t go to the shopping cart.

3.1.2 Log In:-

➢ Customer logins to the system by entering valid user id and password for the
shopping.

CE / CSE - 07 / 31 Page 46
 DR. SUBHASH TECHNICAL CAMPUS

3.1.3 Payment:-

➢ For customer there are many type of secure billing will be prepaid as debit or credit
card, post paid as after shipping, check or bank draft. The security will provide by the
third party like Pay-Pal etc.

3.1.4 Log Out:-

➢ After the payment or surf the product the customer will logged out.

3.1.5 Report Generation:-

➢ After all transaction the system can generate the portable document file (.pdf) and
then sent one copy to the customer’s Email-address and another one for the system data
base to calculate the monthly transaction .

3.2 Technical Issues :-

➢ This system will work on client-server architecture. It will require an internet server
and which will be able to run PHP application.
➢ The system should support some commonly used browser such as IE etc.

4. Interface Requirement:-

4.1 Hardware Interface :-

➢ The System must run over the internet, all the hardware shall require to connect
internet will be hardware interface for the system. As for e.g. Modem, WAN – LAN,
Ethernet Cross-Cable.

➢ The HMS will be placed on PC’s throughout the hotel.

4.2 Software Interface :-

➢ All databases for the HMS will be configured using Oracle 8i. These databases
include hotel rooms and customers information. These can be modified by the end users.

➢ The room database will include the room numbers and if they are vacant or occupied.

➢ The customers information database will contain all the information of the customer
such as first name, last name, number of occupants, assigned room, default room
rate(may be changed), phone number, whether or not the room is guaranteed, credit
card number, confirmation number, automatic cancellation date, expected check in
date and time, actual check in date and time, expected check out date and time,
amount owed by customer, and abbreviated customer feedback.

CE / CSE - 07 / 31 Page 47
 DR. SUBHASH TECHNICAL CAMPUS

5. Performance Requirement:-

➢ There is no performance requirement in this system because the server request and
response is depended on the end user internet connection.

➢ Supported For All 64Bit and 32Bit Windows OS.

➢ Requirement for 2 GB Ram, Windows XP/7/8/8.1/Technical Previews/10.

6. Feasibility study:-

➢ Depending on the results of the initial investigation the survey is now expanded to a
more detailed feasibility study.

➢ “FEASIBILITY STUDY” is a test of system proposal according to its workability,

impact of the organization, ability to meet needs and effective use of the resources.

6.1 Technical feasibility:-

➢ First of all in the part of “technical feasibility” we study that weathers this software
project is technically feasible or not. Means to study that whether the necessary
software &hardware are available or not. Also study that weather the current software
project can be completed with the technology available in the company or in the
market or not. So, all these above factors are being considered in the study of
“technical feasibility”.

➢ Here in the case of the software project of “HOTEL MANAGMENT” we have done
study on “technical feasibility” and we have derived several points as noted below:

o In these industry they already have computer with latest genuine Secondly they
configuration.

o Secondly they have either windows 98 or windows 2000 operating system in the
entire computer.

o Also they have to manage all the data & all the computers are on the network.

6.2 Economic feasibility :-

➢ Economic justification is generally the “Bottom Line” consideration for most systems.
Economic justification includes a broad range of concerns that includes cost benefit
analysis. In this we weight the cost and the benefits associated with the candidate system
and if it suits the basic purpose of the organization i.e. profit making, the project is
making to the analysis and design phase.

CE / CSE - 07 / 31 Page 48
 DR. SUBHASH TECHNICAL CAMPUS

➢ The financial and the economic questions during the preliminary investigation are
verified to estimate the following:

o The cost to conduct a full system investigation.

o The cost of hardware and software for the class of application being considered.

o The benefits in the form of reduced cost.

7. Other non Functional requirement:-

7.1 Sequrity:-

➢ The system use SSL (secured socket layer) in all transactions that include any
confidential customer information.
➢ The system must automatically log out all customers after a period of inactivity.
➢ The system should not leave any cookies on the customer’s computer containing the
user’s password.
➢ The system’s back-end servers shall only be accessible to authenticated
administrators.
➢ Sensitive data will be encrypted before being sent over insecure connections like the
internet.

7.2 Reliablity :-

➢ The system provides storage of all databases on redundant computers with automatic
switchover.
➢ The reliability of the overall program depends on the reliability of the separate
components. The main pillar of reliability of the system is the backup of the database
which is continuously maintained and updated to reflect the most recent changes.
➢ Thus the overall stability of the system depends on the stability of container and its
underlying operating system.

7.3 Availability:-

➢ The system should be available at all times, meaning the user can access it using a
web browser, only restricted by the down time of the server on which the system runs.
In case of a of a hardware failure or database corruption, a replacement page will be
shown. Also in case of a hardware failure or database corruption, backups of the
database should be retrieved from the server and saved by the administrator.

➢ Then the service will be restarted. It means 24 X 7 availability.

7.4 Maintainability:-

➢ A commercial database is used for maintaining the database and the application server
takes care of the site.

CE / CSE - 07 / 31 Page 49
 DR. SUBHASH TECHNICAL CAMPUS

➢ In case of a failure, a re-initialization of the program will be done. Also the software
design is being done with modularity in mind so that maintainability can be done
efficiently.

7.5 Portability:-

➢ The application is HTML and scripting language based. So The end-user part is fully
portable and any system using any web browser should be able to use the features of
the system, including any hardware platform that is available or will be available in
the future.

➢ An end-user is use this system on any OS; either it is Windows or Linux.

➢ The system shall run on PC, Laptops, and PDA etc.

8. data flow Diagrams:-

8.1 Data Flow Diagram Symbols :-

CE / CSE - 07 / 31 Page 50
 DR. SUBHASH TECHNICAL CAMPUS

8.2 USE THE LINEAR SEQUENTIAL MODEL/WATERFALL MODEL:

• Waterfall Strengths :-

➢ Easy to understand, easy to use of the system.

➢ Provides structure to inexperienced staff.
➢ Milestones are well understood.
➢ Sets requirements stability.
➢ Good for management control (plan, staff, track) For (HMS).
➢ Works well when quality is more important than cost or schedule.

• Waterfall Deficiencies :-

➢ All requirements must be known upfront.

➢ Deliverables created for each phase are considered frozen – inhibits flexibility.
➢ Can give a false impression of progress.
➢ Does not reflect problem-solving nature of Handling of management.
➢ Integration is one big bang at the end.
➢ Little opportunity for customer to preview the system (until it may be too late).
➢ “This model is used to Hotel Management System (HMS) make all works in easily”.

CE / CSE - 07 / 31 Page 51
 DR. SUBHASH TECHNICAL CAMPUS

8.3 Level 0 Data Flow Diagram:-

8.4 Level 1 Data Flow Diagram:-

CE / CSE - 07 / 31 Page 52
 DR. SUBHASH TECHNICAL CAMPUS

8.5 Level 2 Data Flow Diagram:-

CE / CSE - 07 / 31 Page 53
 DR. SUBHASH TECHNICAL CAMPUS

8.5 Use Case Diagram:-

CE / CSE - 07 / 31 Page 54
 DR. SUBHASH TECHNICAL CAMPUS

8.6 E-R Diagram:-

CE / CSE - 07 / 31 Page 55
 DR. SUBHASH TECHNICAL CAMPUS

8.7 Class Diagram:-

CE / CSE - 07 / 31 Page 56
 DR. SUBHASH TECHNICAL CAMPUS

8.8 Activity Diagram:-

Reference sites:-

➢ http://in.zapmetasearch.com/ws?q=hotel management sites&de=c&asid=in_ba_gc5_05

➢ https://jobs.mitula.in/premiumJobs/hotelmanagementtrainingprograms?ntwrk=ba&cmpg=1
1_03_MT_IN_JO_BA_01_03
➢ http://www.academia.edu/2112330/A_SAMPLE_HOTEL_MANAGEMENT_SYSTEM_P
ROJECT_DOCUMENTATION

CE / CSE - 07 / 31 Page 57
 DR. SUBHASH TECHNICAL CAMPUS

OUTCOMES:
• After complete this experiment I have learnt how to prepare SRS document for any
project development.
• I have learnt steps of SRS.

CE / CSE - 07 / 31 Page 58