Software Engineering

1) Classical Waterfall Model: The classical waterfall model is the basic software
development life cycle model. It is very simple but idealistic. Earlier this model was very
popular but nowadays it is not used. But it is very important because all the other
software development life cycle models are based on the classical waterfall model.

The classical waterfall model divides the life cycle into a set of phases. This model
considers that one phase can be started after the completion of the previous phase. That
is the output of one phase will be the input to the next phase.

Thus the development process can be considered as a sequential flow in the waterfall.
Here the phases do not overlap with each other.

Different Phases:-
i) Feasibility Study: The main goal of this phase is to determine whether it would be
financially and technically feasible to develop the software.
ii) Requirements analysis and specification: The aim of the requirement analysis and
specification phase is to understand the exact requirements of the customer and
document them properly.
iii) Design: The goal of this phase is to convert the requirements acquired in the SRS into a
format that can be coded in a programming language.
iv) Coding and Unit testing: In the coding phase software design is translated into source
code using any suitable programming language. The aim of the unit testing phase is to
check whether each module is working properly or not.
v) Integration and System testing: Integration of different modules are undertaken soon
after they have been coded and unit tested. System testing consists of three different
kinds of testing activities:
 Alpha testing: Alpha testing is the system testing performed by the development
team.
 Beta testing: Beta testing is the system testing performed by a friendly set of
customers.
 Acceptance testing: After the software has been delivered, the customer
performed acceptance testing to determine whether to accept the delivered
software or reject it.

vi) Maintenance: Maintenance is the most important phase of a software life cycle. The
effort spent on maintenance is 60% of the total effort spent to develop a full software.
2) Software Requirement Specification (SRS)
Ans: The production of the requirements stage of the software development process
is Software Requirements Specifications (SRS) (also called a requirements document). This
report lays a foundation for software engineering activities.
SRS is a formal report, which acts as a representation of software that enables the
customers to review whether it (SRS) is according to their requirements.
The SRS is a specification for a specific software product, program, or set of applications
that perform particular functions in a specific environment.
It serves several goals depending on who is writing it. First, the SRS could be written by the
client of a system. Second, the SRS could be written by a developer of the system.
In first case, SRS, is used to define the needs and expectation of the users.
In second case, SRS, is written for various purposes and serves as a contract document
between customer and developer.
Properties of a good SRS Document:-
Concise: The SRS report should be concise and at the same time, unambiguous, consistent,
and complete.
Structured: It should be well-structured. A well-structured document is simple to
understand and modify.
Black-box view: It should only define what the system should do and refrain from stating
how to do these.
Conceptual integrity: It should show conceptual integrity so that the reader can merely
understand it.
Verifiable: All requirements of the system, as documented in the SRS document, should be
correct.
Features of Good SRS Document:-
Correctness: SRS is said to be perfect if it covers all the needs that are truly expected from
the system.
Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict.
Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted.
Modifiability: SRS should be made as modifiable as likely and should be capable of quickly
obtain changes to the system to some extent.
Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.
 Class Diagram Object Diagram
1) It depicts the static view of a system. 1) It portrays the real-time behavior of a
system.
2) Dynamic changes are not included in the 2)Dynamic changes are captured in the
class diagram. object diagram.
3) The data values and attributes of an 3) It incorporates data values and attributes
instance are not involved here. of an entity
4) The object behaviour is manipulated in 4) Objects are the instances of a class.
the class diagram.
4) Sate Chart Diagram:- It is also known as state machine diagram or state transition
diagram, which shows the order of states underwent by an object within the system. It
captures the software system's behaviour. It models the behaviour of a class, a subsystem,
a package, and a complete system.
Behaviour State Chart Diagram:- The behavioural state machine diagram records the
behavior of an object within the system. It models the behaviour of the system.
Protocol state Chart Diagram:- It captures the behaviour of the protocol. It depicts the
change in the state of the protocol and parallel changes within the system.

5) Software Project Management:- Software project management is an art and discipline of

planning and supervising software projects. It is a procedure of managing, allocating and
timing resources to develop computer software that full fill requirements.

6) Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed

project or system. Feasibility study is one of stage among important four stages
of Software Project Management Process. Feasibility study is carried out to analyse
whether software product will be right in terms of development, implantation,
contribution of project to the organization etc.

7) Lines of code(LOC):- LOC count the total number of lines of source code in a project.

 KLOC- Thousand lines of code

 NLOC- Non-comment lines of code
 KDSI- Thousands of delivered source instruction
It’s tough to estimate LOC by analysing the problem definition. An accurate LOC is
estimated only after the whole code hac been developed.

Advt: i) Universally accepted and is used in many models like COCOMO.

ii) Estimation is closer to the developer’s perspective.
iii) Simple to use.
8) Function Point Analysis: In this method, the number and type of functions supported
by the software are utilized to find FPC(function point count). The steps in function point
analysis are:

 Count the number of functions of each proposed type.

 Compute the Unadjusted Function Points(UFP).
 Find Total Degree of Influence(TDI).
 Compute Value Adjustment Factor(VAF).
 Find the Function Point Count(FPC).

9) COCOMO Model: Boehm proposed COCOMO (Constructive Cost Estimation Model) in

1981.COCOMO is one of the most generally used software estimation models in the world.
COCOMO predicts the efforts and schedule of a software product based on the size of the
software.

The necessary steps in this model are:

1. Get an initial estimate of the development effort from evaluation of thousands of

delivered lines of source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the
multiplying factors i.e., multiply the values in step1 and step2.

To determine the initial effort Ei in person-months the equation used is Ei=a*(KDLOC)b

where the value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic:- A development project can be treated of the organic type, if the project
deals with developing a well-understood application program, the size of the
development team is reasonably small, and the team members are experienced in
developing similar methods of projects.
2. Semidetached:- A development project can be treated with semidetached type if the
development consists of a mixture of experienced and inexperienced staff.
3. Embedded:- A development project is treated to be of an embedded type, if the
software being developed is strongly coupled to complex hardware, or if the
stringent regulations on the operational method exist.

10) Gantt Chart:- It Stands for Generalized Activity Normalization Time Table (GANTT)
chart. It is a type of chart in which series of horizontal lines are present that show the
amount of work done or production completed in given period of time in relation to
amount planned for those projects. It is horizontal bar chart developed by Henry L. Gantt
(American engineer and social scientist) in 1917 as production control tool.

11) PERT Chart:- It Stands for project evaluation and review technique. It is a procedure
through which activities of a project are represented in its appropriate sequence and
timing. It is a scheduling technique used to schedule, organize and integrate tasks within a
project. PERT is basically a mechanism for management planning and control which
provides blueprint for a particular project.

12) Risk Management:- A risk is a probable problem- it might happen or it might not.
There are main two characteristics of risk.
Uncertainty- the risk may or may not happen that means there are no 100% risks.
loss – If the risk occurs in reality , undesirable result or losses will occur.
Risk management is a sequence of steps that help a software team to understand ,
analyze and manage uncertainty.
Risk management consists of
 Risk Identification
 Risk analysis
 Risk Planning
 Risk Monitoring
13)
Cohesion Coupling
Cohesion is the concept of intra-module. Coupling is the concept of inter-module.
Cohesion represents the relationship within Coupling represents the relationships
a module. between modules.
Increasing cohesion is good for software. Increasing coupling is avoided for software.

Cohesion represents the functional strength Coupling represents the independence

of modules. among modules.
Highly cohesive gives the best software. Whereas loosely coupling gives the best
software.
In cohesion, the module focuses on a single In coupling, modules are connected to the
thing. other modules.
Cohesion is created between the same Coupling is created between two different
module. modules.
There are Six types of Cohesion There are Six types of Coupling
1. Functional Cohesion. 1. Common Coupling.
2. Procedural Cohesion. 2. External Coupling.
3. Temporal Cohesion. 3. Control Coupling.
4. Sequential Cohesion. 4. Stamp Coupling.
5. Layer Cohesion. 5. Data Coupling
6. Communication Cohesion. 6. Content Coupling.
14) Data Flow Diagram (DFD):- A Data Flow Diagram (DFD) is a traditional visual
representation of the information flows within a system. A neat and clear DFD can depict
the right amount of the system requirement graphically. It can be manual, automated, or a
combination of both.

It shows how data enters and leaves the system, what changes the information, and where
data is stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may
be used as a communication tool between a system analyst and any person who plays a
part in the order that acts as a starting point for redesigning a system. The DFD is also called
as a data flow graph or bubble chart.

Symbols of Data Flow Diagram:-

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or
sink of system outputs.

Data Store: A set of parallel lines indicates that the data is stored which can be used at a
later stage or by the other processes in a different order.

Levels in DFD:- i) 0-level DFD ii) 1-level DFD iii) 2-level DFD

15) Entity Relationship Diagram:- It is a data modelling method used in software

engineering to produce a conceptual data model of an information system. Diagrams
created using this ER-modelling method are called Entity-Relationship Diagrams or ER
diagrams or ERDs.

Components of a ER Diagram:-

i) Entity:- An entity can be a real-world object, either animate or inanimate, that can be
merely identifiable. An entity is denoted as a rectangle in an ER diagram. For example, in a
school database, students, teachers, classes, and courses offered can be treated as entities.
All these entities have some attributes or properties that give them their identity.

ii) Attributes:- Entities are denoted utilizing their properties, known as attributes. All
attributes have values. For example, a student entity may have name, class, and age as
attributes. There exists a domain or range of values that can be assigned to attributes. For
example, a student's name cannot be a numeric value. It has to be alphabetic. A student's
age cannot be negative, etc.
iii) Relationship:-The association among entities is known as relationship. Relationships are
represented by the diamond-shaped box. For example, an employee works_at a
department, a student enrolls in a course. Here, Works_at and Enrolls are called
relationships.

16) Decision Table:- It is a brief visual representation for specifying which actions to
perform depending on given conditions. The information represented in decision tables
can also be represented as decision trees or in a programming language using if-then-else
and switch-case statements. It is also known as cause-effect table.

17)

Bug Defect Error Fault Failure

It is an informal It is the difference It is a mistake It is a state that If the software has

name specified to between the actual made in the code; causes the software lots of defects, it
the defect. outcomes and that's why we to fail to accomplish leads to failure or
expected outputs. cannot execute or its essential causes failure
compile code. function.
The Test The Testers identify The Developers Human The failure finds
Engineers submit the defect. and automation mistakes cause by the manual test
the bug. test fault. engineer through
engineers raise the development
the error. cycle.
Different type of Different type of Different type of Different type of
bugs are as Defects are as Error is as below: Fault are as follows:
follows: follows:
o Syntactic o Business
Based on priority:
o Logic bugs Error Logic Faults
o High
o Algorithmic o User o Functional
bugs o Medium
interface and Logical
o Resource o Low error Faults
bugs o Flow o Faulty GUI
control o Performance
error Faults
o Error o Security
handling Faults
error o Software/
o Calculation hardware
error fault
o Hardware
error
o Testing
Error
18) Regression Testing is the process of testing the modified parts of the code and the
parts that might get affected due to the modifications to ensure that no new errors have
been introduced in the software after the modifications have been made. Regression
means return of something and in the software field, it refers to the return of a bug.

19)

Verification Validation
It includes checking documents, design, It includes testing and validating the actual
codes and programs. product.
Verification is the static testing. Validation is the dynamic testing.
It does not include the execution of the It includes the execution of the code.
code.
20) Corrective maintenance:
Corrective maintenance of a software product may be essential either to rectify some
bugs observed while the system is in use, or to enhance the performance of the system.

21) Adaptive maintenance:

This includes modifications and updations when the customers need the product to run
on new platforms, on new operating systems.

22) Perfective maintenance:

A software product needs maintenance to support the new features that the users want.

23) Preventive maintenance:

This type of maintenance includes modifications and updations to prevent future
problems of the software.
24)
Black Box Testing White Box Testing
1) It is a way of software testing in which 1) It is a way of testing the software in
the internal structure or the program or the which the tester has knowledge about the
code is hidden and nothing is known about internal structure or the code or the
it. program of the software.

2) Implementation of code is not needed 2) Code implementation is necessary for

for black box testing. white box testing.
3) It is mostly done by software testers. 3) It is mostly done by software developers.
4) No knowledge of implementation is 4) Knowledge of implementation is
needed. required.
5) It can be referred to as outer or external 5) It is the inner or the internal software
software testing. testing.
6) It is a functional test of the software. 6) It is a structural test of the software.
7) No knowledge of programming is 7) It is mandatory to have knowledge of
required. programming.