Se Prac

Software Engineering (3150711) EN NO.
PRACTICAL:-1
Aim: - Study the complete software development life cycle (SDIC) and analyze various
activity conduct a part of various spaces for each SDCC phase identity the objective
summary outcome.
What is SDLC?
SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan
describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a
methodology for improving the quality of software and the overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.
A typical Software Development Life Cycle consists of the following stages −
Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior
members of the team with inputs from the customer, the sales department, market surveys and domain experts
in the industry. This information is then used to plan the basic project approach and to conduct product
feasibility study in the economical, operational and technical areas.
Planning for the quality assurance requirements and identification of the risks associated with the project is also
done in the planning stage. The outcome of the technical feasibility study is to define the various technical
approaches that can be followed to implement the project successfully with minimum risks.
Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product requirements
and get them approved from the customer or the market analysts. This is done through an SRS (Software
1
Requirement Specification) document which consists of all the product requirements to be designed and
developed during the project life cycle.
Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the product to be
developed. Based on the requirements specified in SRS, usually more than one design approach for the product
architecture is proposed and documented in a DDS - Design Document Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment,
product robustness, design modularity, budget and time constraints, the best design approach is selected for the
product.
A design approach clearly defines all the architectural modules of the product along with its communication and
data flow representation with the external and third party modules (if any). The internal design of all the
modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.
Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code is
generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code
generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and programming tools like
compilers, interpreters, debuggers, etc. are used to generate the code. Different high level programming
languages such as C, C++, Pascal, Java and PHP are used for coding. The programming language is chosen
with respect to the type of software being developed.
Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly
involved in all the stages of SDLC. However, this stage refers to the testing only stage of the product where
product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined
in the SRS.
Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometimes
product deployment happens in stages as per the business strategy of that organization. The product may first be
released in a limited segment and tested in the real business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested enhancements in the
targeting market segment. After the product is released in the market, its maintenance is done for the existing
customer base.
SDLC Models
There are various software development life cycle models defined and designed which are followed during the
software development process. These models are also referred as Software Development Process Models". Each
process model follows a Series of steps unique to its type to ensure success in the process of software
development.
Following are the most important and popular SDLC models followed in the industry −
 Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
2
Waterfall Model - Design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the
project. In "The Waterfall" approach, the whole process of software development is divided into separate
phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase
sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.
The sequential phases in Waterfall model are –
 Requirement Gathering and analysis − All possible requirements of the system to be developed are
captured in this phase and documented in a requirement specification document.
 System Design − the requirement specifications from first phase are studied in this phase and the system
design is prepared. This system design helps in specifying hardware and system requirements and helps
in defining the overall system architecture.
 Implementation − with inputs from the system design, the system is first developed in small programs
called units, which are integrated in the next phase. Each unit is developed and tested for its
functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementation phase are integrated into a
system after testing of each unit. Post integration the entire system is tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing is done; the product is
deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To fix those issues,
patches are released. Also to enhance the product some better versions are released. Maintenance is done
to deliver these changes in the customer environment.
Waterfall Model – Application
Every software developed is different and requires a suitable SDLC approach to be followed based on the
internal and external factors. Some situations where the use of Waterfall model is most appropriate are −
 Requirements are very well documented, clear and fixed.

 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
3
Iterative Model - Design
Iterative process starts with a simple implementation of a subset of the software requirements and iteratively
enhances the evolving versions until the full system is implemented. At each iteration, design modifications are
made and new functional capabilities are added. The basic idea behind this method is to develop a system
through repeated cycles (iterative) and in smaller portions at a time (incremental).
The following illustration is a representation of the Iterative and Incremental model –
Iterative and Incremental development is a combination of both iterative design or iterative method and
incremental build model for development. "During software development, more than one iteration of the
software development cycle may be in progress at the same time." This process may be described as an
"evolutionary acquisition" or "incremental build" approach."
In this incremental model, the whole requirement is divided into various builds. During each iteration, the
development module goes through the requirements, design, implementation and testing phases. Each
subsequent release of the module adds function to the previous release. The process continues till the complete
system is ready as per the requirement.
The key to a successful use of an iterative software development lifecycle is rigorous validation of
requirements, and verification & testing of each version of the software against those requirements within each
cycle of the model. As the software evolves through successive cycles, tests must be repeated and extended to
verify each version of the software.
Iterative Model - Application
Like other SDLC models, Iterative and incremental development has some specific applications in the software
industry. This model is most often used in the following scenarios −
 Requirements of the complete system are clearly defined and understood.

 Major requirements must be defined; however, some functionalities or requested enhancements may
evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development team while working on the
project.
 Resources with needed skill sets are not available and are planned to be used on contract basis for
specific iterations.
 There are some high-risk features and goals which may change in the future.
4
Spiral Model - Design

The spiral model has four phases. A software project repeatedly passes through these phases in iterations called
Spirals.
Identification
This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the
product matures, identification of system requirements, subsystem requirements and unit requirements are all
done in this phase.
This phase also includes understanding the system requirements by continuous communication between the
customer and the system analyst. At the end of the spiral, the product is deployed in the identified market.
Design
The Design phase starts with the conceptual design in the baseline spiral and involves architectural design,
logical design of modules, physical product design and the final design in the subsequent spirals.
Construct or Build
The Construct phase refers to production of the actual software product at every spiral. In the baseline spiral,
when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in
this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working model of the
software called build is produced with a version number. These builds are sent to the customer for feedback.
Evaluation and Risk Analysis

Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management risks,
such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.
The following illustration is a representation of the Spiral Model, listing the activities in each phase.
5
Based on the customer evaluation, the software development process enters the next iteration and subsequently
follows the linear approach to implement the feedback suggested by the customer. The process of iterations
along the spiral continues throughout the life of the software.
Spiral Model Application
The Spiral Model is widely used in the software industry as it is in sync with the natural development process of
any product, i.e. learning with maturity which involves minimum risk for the customer as well as the
development firms.
The following pointers explain the typical uses of a Spiral Model −
 When there is a budget constraint and risk evaluation is important.

 For medium to high-risk projects.
 Long-term project commitment because of potential changes to economic priorities as the requirements
change with time.
 Customer is not sure of their requirements which is usually the case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get enough customer feedback.
 Significant changes are expected in the product during the development cycle.
V-Model – Design
Under the V-Model, the corresponding testing phase of the development phase is planned in parallel. So, there
are Verification phases on one side of the ‘V’ and Validation phases on the other side. The Coding Phase joins
the two sides of the V-Model.
The following illustration depicts the different phases in a V-Model of the SDLC.
6
V-Model - Verification Phases
There are several Verification phases in the V-Model, each of these are explained in detail below.
Business Requirement Analysis

This is the first phase in the development cycle where the product requirements are understood from the
customer’s perspective. This phase involves detailed communication with the customer to understand his
expectations and exact requirement. This is a very important activity and needs to be managed well, as most of
the customers are not sure about what exactly they need. The acceptance test design planning is done at this
stage as business requirements can be used as an input for acceptance testing.
System Design
Once you have the clear and detailed product requirements, it is time to design the complete system. The system
design will have the understanding and detailing the complete hardware and communication setup for the
product under development. The system test plan is developed based on the system design. Doing this at an
earlier stage leaves more time for the actual test execution later.
Architectural Design
Architectural specifications are understood and designed in this phase. Usually more than one technical
approach is proposed and based on the technical and financial feasibility the final decision is taken. The system
design is broken down further into modules taking up different functionality. This is also referred to as High
Level Design (HLD).
The data transfer and communication between the internal modules and with the outside world (other systems)
is clearly understood and defined in this stage. With this information, integration tests can be designed and
documented during this stage.
Module Design
In this phase, the detailed internal design for all the system modules is specified, referred to as Low Level
Design (LLD). It is important that the design is compatible with the other modules in the system architecture
and the other external systems. The unit tests are an essential part of any development process and helps
eliminate the maximum faults and errors at a very early stage. These unit tests can be designed at this stage
based on the internal module designs.
Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the Coding phase. The best
suitable programming language is decided based on the system and architectural requirements.
The coding is performed based on the coding guidelines and standards. The code goes through numerous code
reviews and is optimized for best performance before the final build is checked into the repository.
Validation Phases
The different Validation Phases in a V-Model are explained in detail below.
Unit Testing
Unit tests designed in the module design phase are executed on the code during this validation phase. Unit
testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be
uncovered by unit testing.
7
Integration Testing
Integration testing is associated with the architectural design phase. Integration tests are performed to test the
coexistence and communication of the internal modules within the system.
System Testing
System testing is directly associated with the system design phase. System tests check the entire system
functionality and the communication of the system under development with external systems. Most of the
software and hardware compatibility issues can be uncovered during this system test execution.
Acceptance Testing
Acceptance testing is associated with the business requirement analysis phase and involves testing the product
in user environment. Acceptance tests uncover the compatibility issues with the other systems available in the
user environment. It also discovers the non-functional issues such as load and performance defects in the actual
user environment.
V- Model ─ Application
V- Model application is almost the same as the waterfall model, as both the models are of sequential type.
Requirements have to be very clear before the project starts, because it is usually expensive to go back and
make changes. This model is used in the medical development field, as it is strictly a disciplined domain.
The following pointers are some of the most suitable scenarios to use the V-Model application.
 Requirements are well defined, clearly documented and fixed.

 Product definition is stable.
 Technology is not dynamic and is well understood by the project team.
 There are no ambiguous or undefined requirements.
 The project is short.
What is Agile?
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.
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.
Here is a graphical illustration of the Agile Model −
8
The advantages of the Agile Model are as follows −
 Is a very realistic approach to software development

 Promotes teamwork and cross training.
 Functionality can be developed rapidly and demonstrated.
 Resource requirements are minimum.
 Suitable for fixed or changing requirements
 Delivers early partial working solutions.
 Good model for environments that change steadily.
 Minimal rules, documentation easily employed.
 Enables concurrent development and delivery within an overall planned context.
 Little or no planning required.
 Easy to manage.
 Gives flexibility to developers.
What is RAD?
Rapid application development is a software development methodology that uses minimal planning in favor of
rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product.
In the RAD model, the functional modules are developed in parallel as prototypes and are integrated to make
the complete product for faster product delivery. Since there is no detailed preplanning, it makes it easier to
incorporate the changes within the development process.
RAD projects follow iterative and incremental model and have small teams comprising of developers, domain
experts, customer representatives and other IT resources working progressively on their component or
prototype.
The most important aspect for this model to be successful is to make sure that the prototypes developed are
reusable.
RAD Model Design
9
RAD model distributes the analysis, design, build and test phases into a series of short, iterative development
cycles.
Following are the various phases of the RAD Model –
Business Modelling
The business model for the product under development is designed in terms of flow of information and the
distribution of information between various business channels. A complete business analysis is performed to
find the vital information for business, how it can be obtained, how and when is the information processed and
what are the factors driving successful flow of information.
Data Modelling
The information gathered in the Business Modelling phase is reviewed and analyzed to form sets of data objects
vital for the business. The attributes of all data sets is identified and defined. The relation between these data
objects are established and defined in detail in relevance to the business model.
Process Modelling
The data object sets defined in the Data Modelling phase are converted to establish the business information
flow needed to achieve specific business objectives as per the business model. The process model for any
changes or enhancements to the data object sets is defined in this phase. Process descriptions for adding,
deleting, retrieving or modifying a data object are given.
Application Generation
The actual system is built and coding is done by using automation tools to convert process and data models into
actual prototypes.
Testing and Turnover

The overall testing time is reduced in the RAD model as the prototypes are independently tested during every
iteration. However, the data flow and the interfaces between all the components need to be thoroughly tested
with complete test coverage. Since most of the programming components have already been tested, it reduces
the risk of any major issues.
The following illustration describes the RAD Model in detail.
10
RAD Model - Application
RAD model can be applied successfully to the projects in which clear modularization is possible. If the project
cannot be broken into modules, RAD may fail.
The following pointers describe the typical scenarios where RAD can be used −
 RAD should be used only when a system can be modularized to be delivered in an incremental manner.
 It should be used if there is a high availability of designers for Modelling.
 It should be used only if the budget permits use of automated code generating tools.
 RAD SDLC model should be chosen only if domain experts are available with relevant business
knowledge.
 Should be used where the requirements change during the project and working prototypes are to be
presented to customer in small iterations of 2-3 months.
11
PRACTICAL:-2
Aim: - Study the Software Requirement Specification [SRS] with details.
 Software Requirement Specifications
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 and is constructing when entire requirements are elicited and analyzed. 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. Also, it comprises user requirements for a system as well as detailed
specifications of the system 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.
The two methods create entirely various situations and establish different purposes for the document altogether.
The first case, SRS, is used to define the needs and expectation of the users. The second case, SRS, is written
for various purposes and serves as a contract document between customer and developer.
 Characteristics of good SRS
Following are the features of a good SRS document:-
1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS. SRS is said to be
perfect if it covers all the needs that are truly expected from the system.
2. Completeness: The SRS is complete if, and only if, it includes the following elements:
(1). All essential requirements, whether relating to functionality, performance, design, constraints, attributes, or
external interfaces.
12
(2). Definition of their responses of the software to all realizable classes of input data in all available categories
of situations.
Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all terms and units of
measure.
3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements described in its
conflict. There are three types of possible conflict in the SRS:
(1). the specified characteristics of real-world objects may conflicts. For example,
(a) The format of an output report may be described in one requirement as tabular but in another as textual.
(b) One condition may state that all lights shall be green while another states that all lights shall be blue.
(2). There may be a reasonable or temporal conflict between the two specified actions. For example,
(a) One requirement may determine that the program will add two inputs, and another may determine that the
program will multiply them.
(b) One condition may state that "A" must always follow "B," while other requires that "A and B" co-occurs.
(3). Two or more requirements may define the same real-world object but use different terms for that object. For
example, a program's request for user input may be called a "prompt" in one requirement's and a "cue" in
another. The use of standard terminology and descriptions promotes consistency.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation. This
suggests that each element is uniquely interpreted. In case there is a method used with multiple definitions, the
requirements report should determine the implications in the SRS so that it is clear and simple to understand.
5. Ranking for importance and stability: The SRS is ranked for importance and stability if each requirement
in it has an identifier to indicate either the significance or stability of that particular requirement. Typically, all
requirements are not equally important. Some prerequisites may be essential, especially for life-critical
applications, while others may be desirable. Each element should be identified to make these differences clear
and explicit. Another way to rank requirements is to distinguish classes of items as essential, conditional, and
optional.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain changes
to the system to some extent. Modifications should be perfectly indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective system to
check whether the final software meets those requirements. The requirements are verified with the help of
reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the
referencing of each condition in future development or enhancement documentation.
There are two types of Traceability:
(1) Backward Traceability: This depends upon each requirement explicitly referencing its source in earlier
documents.
13
(2) Forward Traceability: This depends upon each element in the SRS having a unique name or reference
number. The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to be able to
ascertain the complete set of requirements that may be concerned by those modifications.
9. Design Independence: There should be an option to select from multiple design alternatives for the final
system. More specifically, the SRS should not contain any implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate test cases and test plans
from the report.
11. Understandable by the customer: An end user may be an expert in his/her explicit domain but might not
be trained in computer science. Hence, the purpose of formal notations and symbols should be avoided too as
much extent as possible. The language should be kept simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage, the details should be
explained explicitly. Whereas ,for a feasibility study, fewer analysis can be used. Hence, the level of abstraction
modifies according to the objective of the SRS.
Properties of a good SRS document
The essential properties of a good SRS document are the following:
Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and complete.
Verbose and irrelevant descriptions decrease readability and also increase error possibilities.
Structured: It should be well-structured. A well-structured document is simple to understand and modify. In

practice, the SRS document undergoes several revisions to cope up with the user requirements. Often, user
requirements evolve over a period of time. Therefore, to make the modifications to the SRS document easy, it is
vital to make the report well-structured.
Black-box view: It should only define what the system should do and refrain from stating how to do these. This
means that the SRS document should define the external behavior of the system and not discuss the
implementation issues. The SRS report should view the system to be developed as a black box and should
define the externally visible behavior of the system. For this reason, the SRS report is also known as the black-
box specification of a system.
Conceptual integrity: It should show conceptual integrity so that the reader can merely understand it.
Response to undesired events: It should characterize acceptable responses to unwanted events. These are called
system response to exceptional conditions.
Verifiable: All requirements of the system, as documented in the SRS document, should be correct. This means
that it should be possible to decide whether or not requirements have been met in an implementation.
14
PRACTICLE: -3
Aim: - Explain ER Diagram in Brief
The Entity Relational Model is a model for identifying entities to be represented in the database and
representation of how those entities are related. The ER data model specifies enterprise schema that represents
the overall logical structure of a database graphically.
The Entity Relationship Diagram explains the relationship among the entities present in the database. ER
models are used to model real-world objects like a person, a car, or a company and the relation between these
real-world objects. In short, the ER Diagram is the structural format of the database.
Symbols Used in ER Model

ER Model is used to model the logical view of the system from a data perspective which consists of these
symbols:
Rectangles: Rectangles represent Entities in the ER Model.
Ellipses: Ellipses represent Attributes in the ER Model.
Diamond: Diamonds represent Relationships among Entities.
Lines: Lines represent attributes to entities and entity sets with other relationship types.
Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
Double Rectangle: Double Rectangle represents a Weak Entity.
Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.
15
Entity
An Entity may be an object with a physical existence – a particular person, car, house, or employee – or it may
be an object with a conceptual existence – a company, a job, or a university course.
Entity Set: An Entity is an object of Entity Type and a set of all entities is called an entity set. For Example,
E1 is an entity having Entity Type Student and the set of all students is called Entity Set. In ER diagram, Entity
Type is represented as:
1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on other Entity in the
Schema. It has a primary key that helps in identifying it uniquely and it is represented by a rectangle. These are
called Strong Entity Types.
2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some entity type
exists for which key attributes can’t be defined. These are called Weak Entity types.
For Example, A company may store the information of dependents (Parents, Children, Spouse) of an
Employee. But the dependents don’t have existed without the employee. So Dependent will be a Weak Entity
Type and Employee will be Identifying Entity type for Dependent, which means it is Strong Entity Type.
A weak entity type is represented by a Double Rectangle. The participation of weak entity types is always total.
The relationship between the weak entity type and its identifying strong entity type is called identifying
relationship and it is represented by a double diamond.
Attributes
Are the properties that define the entity type? For example, Rollin, Name, DOB, Age, Address, and Mobile
No are the attributes that define entity type Student. In ER diagram, the attribute is represented by an oval.
1. Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the key attribute. For example,
Rollin will be unique for each student. In ER diagram, the key attribute is represented by an oval with
underlying lines.
16
2. Composite Attribute
An attribute composed of many other attributes is called a composite attribute. For example, the Address
attribute of the student Entity type consists of Street, City, State, and Country. In ER diagram, the composite
attribute is represented by an oval comprising of ovals.
3. Multivalued Attribute
An attribute consisting of more than one value for a given entity. For example, Phone No (can be more than
one for a given student). In ER diagram, a multivalued attribute is represented by a double oval.
4. Derived Attribute
An attribute that can be derived from other attributes of the entity type is known as a derived attribute. e.g.;
Age (can be derived from DOB). In ER diagram, the derived attribute is represented by a dashed oval.
The Complete Entity Type Student with its Attributes can be represented as:
Relationship Type and Relationship Set

 A Relationship Type represents the association between entity types. For example, ‘Enrolled in’ is a
relationship type that exists between entity type Student and Course. In ER diagram, the relationship type
is represented by a diamond and connecting the entities with lines.
17
 A set of relationships of the same type is known as a relationship set. The following relationship set depicts
S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in C3.
Cardinality
The number of times an entity of an entity set participates in a relationship set is known as cardinality.
Cardinality can be of different types:
1. One-to-One: When each entity in each entity set can take part only once in the relationship, the
cardinality is one-to-one. Let us assume that a male can marry one female and a female can marry one
male. So, the relationship will be one-to-one.
The total number of tables that can be used in this is 2.
2. One-to-Many: In one-to-many mapping as well where each entity can be related to more than one
relationship and the total number of tables that can be used in this is 2. Let us assume that one surgeon
department can accommodate many doctors. So, the Cardinality will be 1 to M. It means one department
has many Doctors.
Total number of tables that can used is 3.
18
Many-to-One: When entities in one entity set can take part only once in the relationship set and entities in
other entity sets can take part more than once in the relationship set, cardinality is many to one. Let us assume
that a student can take only one course but one course can be taken by many students. So, the cardinality will
be n to 1. It means that for one course there can be n students but for one student, there will be only one course.
Many-to-Many: When entities in all entity sets can take part more than once in the relationship cardinality is
many to many. Let us assume that a student can take more than one course and one course can be taken by
many students. So, the relationship will be many to many.
19
E-R Diagrame for Hotel Room Booking System
20
E-R Diagram for Food Ordering System
21
PRACTICLE: -4
Aim: - Explain Use Case Diagram In brief.
UML Use Case Diagram
A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the system's
functionality by incorporating use cases, actors, and their relationships. It models the tasks, services, and functions
required by a system/subsystem of an application. It depicts the high-level functionality of a system and also tells
how the user handles a system.
Purpose of Use Case Diagrams
The main purpose of a use case diagram is to portray the dynamic aspect of a system. It accumulates the system's
requirement, which includes both internal as well as external influences. It invokes persons, use cases, and several
things that invoke the actors and elements accountable for the implementation of use case diagrams. It represents
how an entity from the external environment can interact with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.

2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.
How to draw a Use Case diagram?
It is essential to analyze the whole system before starting with drawing a use case diagram, and then the system's
functionalities are found. And once every single functionality is identified, they are then transformed into the use
cases to be used in the use case diagram.
After that, we will enlist the actors that will interact with the system. The actors are the person or a thing that
invokes the functionality of a system. It may be a system or a private entity, such that it requires an entity to be
pertinent to the functionalities of the system to which it is going to interact.
Once both the actors and use cases are enlisted, the relation between the actor and use case/ system is inspected.
It identifies the no of times an actor communicates with the system. Basically, an actor can interact multiple times
with a use case or system at a particular instance of time.
Following are some rules that must be followed while drawing a use case diagram:
1. A pertinent and meaningful name should be assigned to the actor or a use case of a system.
2. The communication of an actor with a use case must be defined in an understandable way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of interactions between the
use case and actors.
22
Use Case Diagram Symbols
System
system The rectangular boundary is the system. Use
cases fall inside it, and actors will be placed
outside it.
Actor
When an actor interacts with the system, it
triggers a use case. Actors should be placed
outside the system.
Use Case
An oval shape represents a use case. Use cases
Use case represent the functionality of the system, as well
as the end-goal of the actor. Use cases should be
placed inside the system.
Relationships
Arrows are used to indicate a relationship
between an actor and a use case, or between two
use cases.
An extension indicates that one use case may
include the behavior of another use case.
An inclusion represents one use case using the
functionality of another use case.
23
USECASE Diagrame for Hotel Room Booking System
24
USECASE Diagrame for Food Ordering System
25
PRACTICLE: -5
Aim:- Explain Activity Diagram in Brief
UML Activity Diagram
In UML, the activity diagram is used to demonstrate the flow of control within the system rather than the
implementation. It models the concurrent and sequential activities.
The activity diagram helps in envisioning the workflow from one activity to another. It put emphasis on the
condition of flow and the order in which it occurs. The flow can be sequential, branched, or concurrent, and to
deal with such kinds of flows, the activity diagram has come up with a fork, join, etc.
It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of actions or

operations that are applied to model the behavioral diagram.
Components of an Activity Diagram
Following are the component of an activity diagram
Activities
The categorization of behavior into one or more actions is termed as an activity. In other words, it can be said
that an activity is a network of nodes that are connected by edges. The edges depict the flow of execution. It
may contain action nodes, control nodes, or object nodes.
The control flow of activity is represented by control nodes and object nodes that illustrates the objects used
within an activity. The activities are initiated at the initial node and are terminated at the final node.
Activity partition /swimlane
The swimlane is used to cluster all the related activities in one column or one row. It can be either vertical or
horizontal. It used to add modularity to the activity diagram. It is not necessary to incorporate swimlane in the
activity diagram. But it is used to add more transparency to the activity diagram.
26
Forks
Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of one inward edge
and several outward edges. It is the same as that of various decision parameters. Whenever a data is received at
an inward edge, it gets copied and split crossways various outward edges. It split a single inward flow into multiple
parallel flows.
Join Nodes
Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the inward edges as it
synchronizes the flow of input across one single output (outward) edge.
Pins
It is a small rectangle, which is attached to the action rectangle. It clears out all the messy and complicated thing
to manage the execution flow of activities. It is an object node that precisely represents one input to or output
from the action.
Notation of an Activity diagram
Activity diagram constitutes following notations:
Initial State: It depicts the initial stage or beginning of the set of actions.
Final State: It is the stage where all the control flows and object flows end.
Decision Box: It makes sure that the control flow or object flow will follow only one path.
Action Box: It represents the set of actions that are to be performed.
27
Following are the rules that are to be followed for drawing an activity diagram:
1. A meaningful name should be given to each and every activity.

2. Identify all of the constraints.
3. Acknowledge the activity associations.
When to use an Activity Diagram?
An activity diagram can be used to portray business processes and workflows. Also, it used for modeling business
as well as the software. An activity diagram is utilized for the followings:
1. To graphically model the workflow in an easier and understandable way.

2. To model the execution flow among several activities.
3. To model comprehensive information of a function or an algorithm employed within the system.
4. To model the business process and its workflow.
5. To envision the dynamic aspect of a system.
6. To generate the top-level flowcharts for representing the workflow of an application.
7. To represent a high-level view of a distributed or an object-oriented system.
28
Activity Diagram for Online Art Gallery - Customer
29
Activity Diagram for Online Shopping Management System - Customer
Result
30
PRACTICAL: -6
AIM: Explain Class Diagram in brief.
The class diagram depicts a static view of an application. It represents the types of objects residing in the system
and the relationships between them. A class consists of its objects, and also it may inherit from other classes. A
class diagram is used to visualize, describe, document various different aspects of the system, and also construct
executable software code.
It shows the attributes, classes, functions, and relationships to give an overview of the software system. It
constitutes class names, attributes, and functions in a separate compartment that helps in software development.
Since it is a collection of classes, interfaces, associations, collaborations, and constraints, it is termed as a
structural diagram.
Purpose of Class Diagrams
The main purpose of class diagrams is to build a static view of an application. It is the only diagram that is widely
used for construction, and it can be mapped with object-oriented languages. It is one of the most popular UML
diagrams. Following are the purpose of class diagrams given below:
1. It analyses and designs a static view of an application.
2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.
Benefits of Class Diagrams
1. It can represent the object model for complex systems.
2. It reduces the maintenance time by providing an overview of how an application is structured before
coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be programmed.
5. It is helpful for the stakeholders and the developers.
Class Notation
A class notation consists of three parts:
1. Class Name
 The name of the class appears in the first partition.
2. Class Attributes
 Attributes are shown in the second partition.
 The attribute type is shown after the colon.
 Attributes map onto member variables (data members) in code.
3. Class Operations (Methods)
 Operations are shown in the third partition. They are services the class provides.
 The return type of a method is shown after the colon at the end of the method signature.
 The return type of method parameters is shown after the colon following the parameter name.
 Operations map onto class methods in code
Vital components of a Class Diagram

o Upper Section: The upper section encompasses the name of the class. A class is a representation of similar
objects that shares the same relationships, attributes, operations, and semantics. Some of the following
rules that should be taken into account while representing a class are given below:
a. Capitalize the initial letter of the class name.
b. Place the class name in the center of the upper section.
31
c. A class name must be written in bold format.

d. The name of the abstract class should be written in italics format.
Middle Section: The middle section constitutes the attributes, which describe the quality of the class. The
attributes have the following characteristics:
e. The attributes are written along with its visibility factors, which are public (+), private (-), protected (#),
and package (~).
f. The accessibility of an attribute class is illustrated by the visibility factors.
g. A meaningful name should be assigned to the attribute, which will explain its usage inside the class.
Lower Section: The lower section contain methods or operations. The methods are represented in the form of a
list, where each method is written in a single line. It demonstrates how a class interacts with data.
Relationships
In UML, relationships are of three types:
o Dependency: A dependency is a semantic relationship between two or more classes where a change in
one class cause changes in another class. It forms a weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.
o Generalization: A generalization is a relationship between a parent class (superclass) and a child class
(subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the generalized form of Bank
Account.
o Association: It describes a static or physical connection between two or more objects. It depicts how
many objects are there in the relationship.
For example, a department is associated with the college.
Multiplicity: It defines a specific range of allowable instances of attributes. In case if a range is not specified,
one is considered as a default multiplicity.
For example, multiple patients are admitted to one hospital.
32
Aggregation: An aggregation is a subset of association, which represents has a relationship. It is more specific
then association. It defines a part-whole or part-of relationship. In this kind of relationship, the child class can
exist independently of its parent class.
The company encompasses a number of employees, and even if one employee resigns, the company still exists.
Composition: The composition is a subset of aggregation. It portrays the dependency between the parent and
its child, which means if one part is deleted, then the other part also gets discarded. It represents a whole-part
relationship.
A contact book consists of multiple contacts, and if you delete the contact book, all the contacts will be lost.
Abstract Classes
In the abstract class, no objects can be a direct entity of the abstract class. The abstract class can neither be declared
nor be instantiated. It is used to find the functionalities across the classes. The notation of the abstract class is
similar to that of class; the only difference is that the name of the class is written in italics. Since it does not
involve any implementation for a given function, it is best to use the abstract class with multiple objects.
Let us assume that we have an abstract class named displacement with a method declared inside it, and that
method will be called as a drive (). Now, this abstract class method can be implemented by any object, for
example, car, bike, scooter, cycle, etc.
How to draw a Class Diagram?

The class diagram is used most widely to construct software applications. It not only represents a static view of
the system but also all the major aspects of an application. A collection of class diagrams as a whole represents a
system.
Some key points that are needed to keep in mind while drawing a class diagram are given below:
1. To describe a complete aspect of the system, it is suggested to give a meaningful name to the class diagram.
2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of the unwanted property
will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the aspects of a diagram.
6. The diagrams should be redrawn and reworked as many times to make it correct before producing its final
version.
33
Class Diagram Example

The bank management system is given below.
The hospital management system is given below.
34
PRACTICAL-7
Aim: Explain sequence diagram in brief.
A sequence diagram is a type of interaction diagram because it describes how—and in what order—a group of
objects works together. These diagrams are used by software developers and business professionals to understand
requirements for a new system or to document an existing process. Sequence diagrams are sometimes known as
event diagrams or event scenarios.
Note that there are two types of sequence diagrams: UML diagrams and code-based diagrams. The latter is
sourced from programming code and will not be covered in this guide. Lucidchart’s UML diagramming software
is equipped with all the shapes and features you will need to model both.
Sequence Diagram Notations :
Object:
Represents a class or object in UML. The object symbol demonstrates how an object will behave in the context
of the system. Class attributes should not be listed in this shape.
Activation box:
Represents the time needed for an object to complete a task. The longer the task will take, the longer the
activation box becomes.
35
Actor:
Shows entities that interact with or are external to the system.
Lifeline:
Represents the passage of time as it extends downward. This dashed vertical line shows the sequential events
that occur to an object during the charted process. Lifelines may begin with a labeled rectangle shape or an actor
symbol.
Synchronous message:
Represented by a solid line with a solid arrowhead. This symbol is used when a sender must wait for a response
to a message before it continues. The diagram should show both the call and the reply.
36
Asynchronous message:
Represented by a solid line with a lined arrowhead. Asynchronous messages don't require a response before the
sender continues. Only the call should be included in the diagram.
Asynchronous return message:
Represented by a dashed line with a lined arrowhead.

Asynchronous create message:
Represented by a dashed line with a lined arrowhead. This message creates a new object.
Reply message:
Represented by a dashed line with a lined arrowhead, these messages are replies to calls.
Delete message:
Represented by a solid line with a solid arrowhead, followed by an X. This message destroys an object.
37
Sequence Diagram for Online Shopping Management System
38
Sequence Diagram for Online Pharmacy Management System
39
PRACTICAL-8
Aim:- Explain Data Flow Diagram in brief.
 Data Flow Diagrams
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.
 Characteristics of DFD
 DFDs are commonly used during problem analysis.
 DFDs are quite general and are not limited to problem analysis for software requirements specification.
 DFDs are very useful in understanding a system and can be effectively used during analysis.
 It views a system as a function that transforms the inputs into desired outputs.
 The DFD aims to capture the transformations that take place within a system to the input data so that
eventually the output data is produced.
 The processes are shown by named circles and data flows are represented by named arrows entering or
leaving the bubbles.
 A rectangle represents a source or sink and it is a net originator or consumer of data. A source sink is
typically outside the main system of study.
 Components of DFD
 The Data Flow Diagram has 4 components:
 Process Input to output transformation in a system takes place because of process function. The symbols
of a process are rectangular with rounded corners, oval, rectangle or a circle.
 Data Flow Data flow describes the information transferring between different parts of the systems. The
arrow symbol is the symbol of data flow. A relatable name should be given to the flow to determine the
information which is being moved. Data flow also represents material along with information that is being
moved. Material shifts are modeled in systems that are not merely informative. A given flow should only
transfer a single type of information. The direction of flow is represented by the arrow which can also be
bi-directional.
 Warehouse The data is stored in the warehouse for later use. Two horizontal lines represent the symbol
of the store. The warehouse is simply not restricted to being a data file rather it can be anything like a
folder with documents, an optical disc, a filing cabinet. The data warehouse can be viewed independent of
its implementation. When the data flow from the warehouse it is considered as data reading and when data
flows to the warehouse it is called data entry or data updating.
 Terminator The Terminator is an external entity that stands outside of the system and communicates with
the system. It can be, for example, organizations like banks, groups of people like customers or different
departments of the same organization, which is not a part of the model system and is an external entity.
Modeled systems also communicate with terminator.
40
 Rules for creating DFD
 The name of the entity should be easy and understandable without any extra assistance(like comments).
 The processes should be numbered or put in ordered list to be referred easily.
 The DFD should maintain consistency across all the DFD levels.
 A single DFD can have a maximum of nine processes and a minimum of three processes.
 Symbols Used in DFD
 Square Box: A square box defines source or destination of the system. It is also called entity. It is
represented by rectangle.
 Arrow or Line: An arrow identifies the data flow i.e. it gives information to the data that is in motion.
 Circle or bubble chart: It represents as a process that gives us information. It is also called processing
box.
 Open Rectangle: An open rectangle is a data store. In this data is store either temporary or permanently.
 Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels of DFD are as
follows:
 0-level DFD: It represents the entire system as a single bubble and provides an overall picture of the
system.
 1-level DFD: It represents the main functions of the system and how they interact with each other.
 2-level DFD: It represents the processes within each function of the system and how they interact with
each other.
 3-level DFD: It represents the data flow within each process and how the data is transformed and stored.
41
 Examples of Data Flow Diagram:
1. Data Flow diagram of Hospital Managemeent System

a. Level 0 DFD :-
b. Level 1 DFD :-
42
c. Level 2 DFD :-
2. Data Flow diagram of Railway Reservation System
a. Level 0 DFD :-
Level 0 DFD for Railway Reservation System
43
b. Level 1 DFD :-
Level 1 DFD for Railway Reservation System
44
PRACTICAL-9
Aim:-Define cost effort estimation, Also explain COCOMO model for project estimation.
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.
The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static
single variable models, using KDLOC as the measure of the size. To determine the initial effort E i in person-
months the equation used is of the type is shown below
Ei=a*(KDLOC)b
The value of the constant a and b are depends on the project type.
In COCOMO, projects are categorized into three types:
1. Organic
2. Semidetached
3. Embedded
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. Examples of this type of projects are simple business
systems, simple inventory management systems, and data processing systems.
2.Semidetached: A development project can be treated with semidetached type if the development consists of
a mixture of experienced and inexperienced staff. Team members may have finite experience in related systems
but may be unfamiliar with some aspects of the order being developed. Example of Semidetached system
includes developing a new operating system (OS), a Database Management System (DBMS), and complex
inventory management system.
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. For
Example: ATM, Air Traffic control.
For three product categories, Bohem provides a different set of expression to predict effort (in a unit of person
month)and development time from the size of estimation in KLOC(Kilo Line of code) efforts estimation takes
into account the productivity loss due to holidays, weekly off, coffee breaks, etc.
45
According to Boehm, software cost estimation should be done through three stages:
1. Basic Model
2. Intermediate Model
3. Detailed Model
1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters.
The following expressions give the basic COCOMO estimation model:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Where,
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months (PMs).
Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for each
of the three model i.e., organic, semi-detached & embedded.
Solution: The basic COCOMO equation takes the form:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC
(i)Organic Mode
E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode
E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 D = 2.5 * (4772.8)0.32 = 38 PM
46
PRACTICAL: -10
Aim: Explain Risk Management With RMMM.
RMMM Plan:
A risk management technique is usually seen in the software Project plan. This can be divided into Risk
Mitigation, Monitoring, and Management Plan (RMMM). In this plan, all works are done as part of risk
analysis. As part of the overall project plan project manager generally uses this RMMM plan.
In some software teams, risk is documented with the help of a Risk Information Sheet (RIS). This RIS is
controlled by using a database system for easier management of information i.e creation, priority ordering,
searching, and other analysis. After documentation of RMMM and start of a project, risk mitigation and
monitoring steps will start.
Risk Mitigation:
It is an activity used to avoid problems (Risk Avoidance).

Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
Risk Monitoring:
It is an activity used for project tracking.

It has the following primary objectives as follows.
1. To check if predicted risks occur or not.
2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
Risk Management and planning:
It assumes that the mitigation activity failed and the risk is a reality. This task is done by Project manager when
risk becomes reality and causes severe problems. If the project manager effectively uses project mitigation to
remove risks successfully then it is easier to manage the risks. This shows that the response that will be taken
for each risk by a manager. The main objective of the risk management plan is the risk register. This risk register
describes and focuses on the predicted threats to a software project.
Example:
Let us understand RMMM with the help of an example of high staff turnover.
Risk Mitigation:
To mitigate this risk, project management must develop a strategy for reducing turnover. The possible steps
to be taken are:
 Meet the current staff to determine causes for turnover (e.g., poor working conditions, low pay, and
competitive job market).
 Mitigate those causes that are under our control before the project starts.
47
 Once the project commences, assume turnover will occur and develop techniques to ensure continuity when
people leave.
 Organize project teams so that information about each development activity is widely dispersed.
 Define documentation standards and establish mechanisms to ensure that documents are developed in a
timely manner.
 Assign a backup staff member for every critical technologist.
Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The project manager monitors factors that may
provide an indication of whether the risk is becoming more or less likely. In the case of high staff turnover, the
following factors can be monitored:
 General attitude of team members based on project pressures.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.
Risk Management:
Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has
become a reality. Continuing the example, the project is well underway, and a number of people announce that
they will be leaving. If the mitigation strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team. In addition, the project manager may
temporarily refocus resources (and readjust the project schedule) to those functions that are fully staffed,
enabling newcomers who must be added to the team to “get up to the speed”.
Principles of Risk Management:
There are 5 principles of Risk Management. They are:

1. Global Perspective:
Larger system definitions, design and implementation is considered. The opportunity and the impact that
the risk is going to have is looked. View software risks in the context of a system and the business problem
planned to solve.
2. Forward Looking View:

Looking at the possible uncertainties that might dragged. Possible solutions of the risks that might occur
in the future are considered. Think about the risk which may occur in the future and create future plans for
managing the future events.
3. Open Communication:
This enables the free flow of the communication between the end users and the development team so that
they can clarify the risks. Encourage all the stakeholders and users for suggesting risks at any time.
4. Integrated Management:
Risk management is made an integral part of the project management during this phase. A consideration of
risk should be integrated into the software process.
5. Continuous Process:
Risks are tracked continuously throughout the risk management paradigm during this phase. Modify the
identified risk than the more information is known and add new risks as better insight is achieved.
48
Risk Management Paradigm:
 Identify:
Risks are identified before major problem is created. If the risks are identified before they create a
major problem then there might not be more difficulty in controlling the risks.
 Analyze:
Deep analysis of nature, behavior and type of risk and collect information about it. It is required for the
purpose of the determination of the knowledge about the risk.
 Plan:
Convert the plan into actions and implementation. This phase includes the actions and implementation
of the planning that was done before. After the risk detection plans are made and executed.
 Track:
Necessary actions are monitored. Necessary action means the required work for the removal and
minimization of the risk detected.
 Control:
Correct the deviation and make necessary changes. Put the right thing in the right place and the required
field will changed according to the changes required.
 Communicate:
Discussion about the current risks and the future risks and their management. Make a productive
discussion between the developer and tester on the risks found in the software.
Advantages of RMMM:
 Risk Identification
 Risk Assessment
 Treatment of Risk
 Minimization of Risk
49
 Awareness about the risks

 Successful business strategies
 Saving cost and time
 New opportunities
 Protecting resources
Disadvantages of RMMM:
 Complex calculations
 Unmanaged losses
 Ambiguity
 Depends on external entities
 Mitigation
 Difficulty in implementing
 Performance
 Potential threats
Drawbacks of RMMM:
 It incurs additional project costs.
 It takes additional time.
 For larger projects, implementing an RMMM may itself turn out to be another tedious project.
 RMMM does not guarantee a risk-free project, in fact, risks may also come up after the project is delivered
50
PRACTICAL-11
Aim:- Explain System Testing with its type in details.
Software Testing is a method to assess the functionality of the software program. The process checks whether the
actual software matches the expected requirements and ensures the software is bug-free.
The purpose of software testing is to identify the errors, faults, or missing requirements in contrast to actual
requirements. It mainly aims at measuring the specification, functionality, and performance of a software program
or application.
Software testing is a process of identifying the correctness of software by considering its all attributes (Reliability,
Scalability, Portability, Re-usability, Usability) and evaluating the execution of software components to find the
software bugs or errors or defects.
Different Types Of Software Testing
1. Manual testing
The process of checking the functionality of an application as per the customer needs without taking any help of
automation tools is known as manual testing. While performing the manual testing on any application, we do
not need any specific knowledge of any testing tool, rather than have a proper understanding of the product so
we can easily prepare the test document.
Manual testing can be further divided into three types of testing, which are as follows:
a) White box testing
b) Black box testing
c) Gray box testing
51
2. Automation testing
Automation testing is a process of converting any manual test cases into the test scripts with the help of
automation tools, or any programming language is known as automation testing. With the help of
automation testing, we can enhance the speed of our test execution because here, we do not require any
human efforts. We need to write a test script and execute those scripts.
a) White Box Testing

White box testing techniques analyze the internal structures the used data structures, internal design, code
structure, and the working of the software rather than just the functionality as in black box testing. It is also
called glass box testing or clear box testing or structural testing or transparent testing or open box testing.
The white box testing contains various tests, which are as follows:
 Path testing
 Loop testing
 Condition testing
 Testing based on the memory perspective
 Test performance of the program
Path Testing:-
In the path testing, we will write the flow graphs and test all independent paths.
And test all the independent paths implies that suppose a path from main() to function G, first set the
parameters and test if the program is correct in that particular path, and in the same way test all other paths
and fix the bugs.
Loop Testing:-
In the loop testing, we will test the loops such as while, for, and do-while, etc. and also check for ending condition if
working correctly and if the size of the conditions is enough. Errors often occur at the beginnings and ends of loops.
Simple loops: For simple loops of size n, test cases are designed that:
o Skip the loop entirely
o Only one pass through the loop
o 2 passes
o m passes, where m < n
o n-1 ans n+1 passes
52
Nested loops: For nested loops, all the loops are set to their minimum count and we start from the innermost
loop. Simple loop tests are conducted for the innermost loop and this is worked outwards till all the loops have
been tested.
Concatenated loops: Independent loops, one after another. Simple loop tests are applied for each. If they’re not
independent, treat them like nesting.
Condition testing
In this, we will test all logical conditions for both true and false values; that is, we will verify for both if and
else condition.
Generic steps of white box testing
 Design all test scenarios, test cases and prioritize them according to high priority number.
 This step involves the study of code at runtime to examine the resource utilization, not accessed areas of
the code, time taken by various methods and operations and so on.
 In this step testing of internal subroutines takes place. Internal subroutines such as nonpublic methods,
interfaces are able to handle all types of data appropriately or not.
 This step focuses on testing of control statements like loops and conditional statements to check the
efficiency and accuracy for different data inputs.
 In the last step white box testing includes security testing to check all possible security loopholes by
looking at how the code handles security.
Advantages:-
 White box testing optimizes code so hidden errors can be identified.

 Test cases of white box testing can be easily automated.
 This testing is more thorough than other testing approaches as it covers all code paths.
 It can be started in the SDLC phase even without GUI.
Disadvantages:-
 White box testing is too much time consuming when it comes to large-scale programming applications.
 White box testing is much expensive and complex.
 It can lead to production error because it is not detailed by the developers.
 White box testing needs professional programmers who have a detailed knowledge and understanding of
programming language and implementation.
b) Black Box Testing:-

 Black box testing is a technique of software testing which examines the functionality of software
without peering into its internal structure or coding. The primary source of black box testing is a
specification of requirements that is stated by the customer.
 In this method, tester selects a function and gives input value to examine its functionality, and checks
whether the function is giving expected output or not. If the function produces correct output, then it is
passed in testing, otherwise failed. The test team reports the result to the development team and then
tests the next function. After completing testing of all functions if there are severe problems, then it is
given back to the development team for correction.
Generic steps of black box testing :-
 The black box test is based on the specification of requirements, so it is examined in the beginning.
53
 In the second step, the tester creates a positive test scenario and an adverse test scenario by selecting
valid and invalid input values to check that the software is processing them correctly or incorrectly.
 In the third step, the tester develops various test cases such as decision table, all pairs test, equivalent
division, error estimation, cause-effect graph, etc.
 The fourth phase includes the execution of all test cases.
 In the fifth step, the tester compares the expected output against the actual output.
 In the sixth and final step, if there is any flaw in the software, then it is cured and tested again.
Test procedure:-
 The test procedure of black box testing is a kind of process in which the tester has specific knowledge
about the software's work, and it develops test cases to check the accuracy of the software's
functionality.
 It does not require programming knowledge of the software. All test cases are designed by considering
the input and output of a particular function. A tester knows about the definite output of a particular
input, but not about how the result is arising.
 There are various techniques used in black box testing for testing like decision table technique,
boundary value analysis technique, state transition, All-pair testing, cause-effect graph technique,
equivalence partitioning technique, error guessing technique, use case technique and user story
technique. All these techniques have been explained in detail within the tutorial.
Advantages:-
 A third-party app can be tested quickly.

 It can also test across different browsers and operating systems.
 Provide end-user experience
 Best for testing large applications
 Black box testing has a low cost.
Disadvantages:-
 Designing test cases is challenging.

 Black box testing doesn't provide a detailed explanation
54

Se Prac

Uploaded by

Copyright:

Available Formats

Se Prac

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Se Prac

Uploaded by

Copyright:

Available Formats

Software Engineering (3150711) EN NO.

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Stage 2: Defining Requirements

Stage 3: Designing the Product Architecture

Stage 4: Building or Developing the Product

Stage 5: Testing the Product

Stage 6: Deployment in the Market and Maintenance

Waterfall Model - Design

The sequential phases in Waterfall model are –

Waterfall Model – Application

 Requirements are very well documented, clear and fixed.

Iterative Model - Design

The following illustration is a representation of the Iterative and Incremental model –

Iterative Model - Application

 Requirements of the complete system are clearly defined and understood.

Spiral Model - Design

Evaluation and Risk Analysis

Spiral Model Application

The following pointers explain the typical uses of a Spiral Model −

 When there is a budget constraint and risk evaluation is important.

V-Model - Verification Phases

Business Requirement Analysis

 Requirements are well defined, clearly documented and fixed.

Following are the Agile Manifesto principles −

Here is a graphical illustration of the Agile Model −

The advantages of the Agile Model are as follows −

 Is a very realistic approach to software development

RAD Model Design

Following are the various phases of the RAD Model –

Testing and Turnover

The following illustration describes the RAD Model in detail.

RAD Model - Application

 Software Requirement Specifications

 Characteristics of good SRS

Following are the features of a good SRS document:-

There are two types of Traceability:

Properties of a good SRS document

The essential properties of a good SRS document are the following:

Structured: It should be well-structured. A well-structured document is simple to understand and modify. In

Symbols Used in ER Model

Relationship Type and Relationship Set

The total number of tables that can be used in this is 2.

Total number of tables that can used is 3.

The total number of tables that can be used in this is 3.

The total number of tables that can be used in this is 3.

E-R Diagrame for Hotel Room Booking System

E-R Diagram for Food Ordering System

Purpose of Use Case Diagrams

Following are the purposes of a use case diagram given below:

1. It gathers the system's needs.

How to draw a Use Case diagram?

Use Case Diagram Symbols

USECASE Diagrame for Hotel Room Booking System

USECASE Diagrame for Food Ordering System

UML Activity Diagram

It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of actions or

Components of an Activity Diagram

Following are the component of an activity diagram