INSTITUTE OF MANAGEMENT AND TECH.

PRACTICAL FILE
ON SOFTWARE ENGINEERING.
BATCH(2019-22)

PARTIAL FULFILMENT OF THE AWARD OF DEGREE OF

BACHELOR OF BUSINESS ADMINISTRATION AND COMPUTER AIDED
MANAGEMENT

SUBMITTED TO: SUBMITTED BY:

Mrs.Jyoti thakur Name:Praveen

Ragistration no:191150111
Rollno:
S.NO DESCRIPTION PG.NO SIGN.

1 STUDY THE COMPLETE SOFTWARE

DEVELOPMENT LIFE CYCLE AND ANALYSE
1-2
VARIOUS ACTIVITIES CONDUCTED PART
OF VARIOUS PHASES FOR EACH SDLC
PHASE IDENTIFY THE OBJECT AND
SUMMARISE OUTCOME.

2 PREPARE THE SRS DOCUMENT. 3-5

3 DRAW THE ENTITY

DIAGRAM OF PROJECT.
RELATIONSHIP 6-10

4 DRAW DATA FLOW DIAGRAM AT LEVEL 0

AND LEVEL 1.
11-12

5 DRAW USE CASE DIAGRAM OF BANK

APPLICATION MANAGEMENT,LIBRARY
13-17
MANAGEMENT,COLLEGE MANAGEMENT.
 PRACTICAL 1
Objective:- Study the complete Software Development Life Cycle (SDLC) and analyse various activities
conducted as a part of various phases. For each SDLC phase, identify the objective and summaries
outcomes.

Result:
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.

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.
Outcome of this stage is a requirement specification.

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 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
1
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.

2
 PRACTICAL 2
Objective: Prepare a SRS document in line with the IEEE recommended standards.

Description:

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system
requirements and dependencies at a particular point in time (usually) prior to any actual design or
development work. It's a two-way insurance policy that assures that both the client and the organization
understand the other's requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a software
system (i.e., a software application, an eCommerce Web site, and so on) must provide, as well as states any
required constraints by which the system must abide. The SRS also functions as a blueprint for completing a
project with as little cost growth as possible. The SRS is often referred to as the "parent" document because
all subsequent project management documents, such as design specifications, statements of work, software
architecture specifications, testing and validation plans, and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer
design suggestions, possible solutions to technology or business issues, or any other information other than
what the development team understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary to
address those problems. Therefore, the SRS should be written in natural language (versus a formal
language, explained later in this article), in an unambiguous manner that may also include charts,
tables, data flow diagrams, decision tables, and so on.

3
 It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the problem,
solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

It serves as an input to the design specification. As mentioned previously, the SRS serves as the
parent document to subsequent documents, such as the software design specification and statement
of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so
that a design solution can be devised.

It serves as a product validation check. The SRS also serves as the parent document for testing and
validation strategies that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development," which is the initial
product development phase in which information is gathered about what requirements are needed--and not.
This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a
return-on-investment (ROI) analysis or needs analysis of the customer or client's current business
environment. The actual specification, then, is written after the requirements have been gathered and
analyzed.

SRS should address the following

The basic issues that the SRS shall address are the following:

● Functionality. What is the software supposed to do?

●
● External interfaces. How does the software interact with people, the system’s hardware, other
hardware, and other software?
●
● Performance. What is the speed, availability, response time, recovery time of various software
functions, etc.?
●
● Attributes. What are the portability, correctness, maintainability, security, etc.considerations?
●
● Design constraints imposed on an implementation. Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, operating
environment(s) etc.

Characterstics of good SRS

4
An SRS should be

a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
● Correct - This is like motherhood and apple pie. Of course you want the specification to be correct. No one writes a
specification that they know is incorrect. We like to say - "Correct and Ever Correcting." The discipline is keeping the
specification up to date when you find things that are not correct.
● Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.
Again, easier said than done. Spending time on this area prior to releasing the SRS can be a waste of time. But as you find
ambiguities - fix them.
● Complete - A simple judge of this is that is should be all that is needed by the software designers to create the software.
● Consistent - The SRS should be consistent within itself and consistent to its reference documents. If you call an input
"Start and Stop" in one place, don't call it "Start/Stop" in another.
● Ranked for Importance - Very often a new system has requirements that are really marketing wish lists. Some may not
be achievable. It is useful provide this information in the SRS.
● Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another of my favorites is - "The
system should never crash." Instead, provide a quantitative requirement like: "Every key stroke should provide a user
response within 100 milliseconds."
● Modifiable - Having the same requirement in more than one place may not be wrong - but tends to make the document
not maintainable.
● Traceable - Often, this is not important in a non-politicized environment. However, in most organizations, it is sometimes
useful to connect the requirements in the SRS to a higher level document. Why do we need this requirement?

5
 PRACTICAL 3
Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard
keyboard n mouse, colored monitor.
Software Requirements: SmartDraw, MS Word.

Outcome: Can produce the requirements in Entity Relationship diagram.

Objective: Prepare a Requirement document in by using Entity Relationship Diagram.

Description: An Entity Relationship (ER) Diagram is a type of flowchart that

illustrates how “entities” such as people, objects or concepts relate to each other
within a system. ER Diagrams are most often used to design or debug relational
databases in the fields of software engineering, business information systems,
education and research.

Components: An ER diagram is a means of visualizing how the information a system

produces is related. There are five main components of an ERD:

Entities, which are represented by rectangles. An entity is an object or concept

about which you want to store information. A weak entity is an entity that

must defined by a foreign key relationship with another entity as it cannot be

uniquely identified by its own attributes alone.

Actions, which are represented by diamond shapes, show

how two entities share information in the database. In some cases, entities
can be self-linked. For example, employees can supervise other employees.

6
Attributes, which are represented by ovals. A key attribute is the unique, distinguishing characteristic of
the entity. For example, an employee's social security number might be the employee's key attribute

A multivalued attribute can have more than one value. For example, an
employee entity can have multiple skill values.

A derived attribute is based on another attribute. For example, an employee's

monthly salary is based on the employee's annual salary.

Connecting lines, solid lines that connect attributes to show the relationships
of entities in the diagram.
Cardinality specifies how many instances of an entity relate to one instance of
another entity. Ordinality is also closely linked to cardinality. While cardinality
specifies the occurrences of a relationship, ordinality describes the
relationship as either mandatory or optional. In other words, cardinality
specifies the maximum number of relationships and ordinality specifies the
absolute minimum number of relationships.

7
There are many notation styles that express cardinality.

8
Tips for Effective ER Diagrams
1. Make sure that each entity only appears once per diagram.
9
 2. Name every entity, relationship, and attribute on your diagram.

3. Examine relationships between entities closely. Are they necessary? Are

there any relationships missing? Eliminate any redundant relationships. Don't
connect relationships to each other.

4. Use colors to highlight important portions of your diagram.

Entity Relationship Diagram Example

10
 PRACTICAL 4
Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard
keyboard n mouse, colored monitor.

Software Requirements: SmartDraw/MS Word, Windows XP.

Outcome: Can produce the requirements in Data Flow diagram.

Objective: Prepare a Requirement document in by using Data Flow Diagram.

Description: Data flow diagram is graphical representation of flow of data in an

information system. It is capable of depicting incoming data flow, outgoing data
flow and stored data. The DFD does not mention anything about how data flows
through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts
flow of control in program modules. DFDs depict flow of data in the system at
various levels. DFD does not contain any control or branch elements.

Components:

External Entity an outside system that sends or receives data, communicating with
the system being diagrammed. They are the sources and destinations of information
entering or leaving the system. They might be an outside organization or person, a
computer system or a business system. They are also known as terminators, sources
and sinks or actors. They are typically drawn on the edges of the diagram.
Process any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on business
rules. A short label is used to describe the process, such as “Submit payment.”
Data store files or repositories that hold information for later use, such as a
database table or a membership form. Each data store receives a simple label, such
as “Orders.”
Data flow the route that data takes between the external entities, processes and
data stores. It portrays the interface between the other components and is shown
with arrows, typically labeled with a short data name, like “Billing details.”

DFD rules
11
● Each process should have at least one input and an output.
● Each data store should have at least one data flow in and one data flow out.
● Data stored in a system must go through a process.
● All processes in a DFD go to another process or a data store.
DFD Levels:
A data flow diagram can dive into progressively more detail by using levels and
layers, zeroing in on a particular piece. DFD levels are numbered 0, 1 or 2, and
occasionally go to even Level 3 or beyond.
1. DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole
system or process being analyzed or modeled. It’s designed to be an at-a-glance view,
showing the system as a single high-level process, with its relationship to external
entities. It should be easily understood by a wide audience, including stakeholders,
business analysts, data analysts and developers.

2. DFD Level 1 provides a more detailed breakout of pieces of the Context Level
Diagram. You will highlight the main functions carried out by the system, as you
break down the high-level process of the Context Diagram into its subproces

Finance
VerifiCation

Verify Issue
Item
Profess Order

Customer Data

12
 PRACTICAL 5
Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard
keyboard n mouse, colored monitor.

Software Requirements: Argo UML, Windows XP.

Outcome: Can produce the requirements in Use Case diagram.

Objective: Prepare a Requirement doccument in by using Use Case Diagram.

Description: According to the UML specification a use case diagram is “a diagram

that shows the relationships among actors and use cases within a system.” Use case
diagrams are often used to:

Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model

Communicate the scope of a development project

Model your analysis of your usage requirements in the form of a system use case
model

Use case models should be developed from the point of view of your project
stakeholders and not from the (often technical) point of view of developers. There are
guidelines for:

Use Cases

Actors

Relationships

System Boundary Boxes

1. Use Cases

13
A use case describes a sequence of actions that provide a measurable value to an
actor. A use case is drawn as a horizontal ellipse on a UML use case diagram.

1. Use Case Names Begin With a Strong Verb

2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases.

2. Actors

An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use
Case diagrams).

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don’t Interact With One Another
8. Introduce an Actor Called “Time” to Initiate Scheduled Events

3 .Relationships

There are several types of relationships that may appear on a use case diagram:

An association between an actor and a use case

An association between two use cases
A generalization between two actors
A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an

optional open-headed arrowhead on one end of the line indicating the direction of the
initial invocation of the relationship. Generalizations are depicted as a close-headed
arrow with the arrow pointing towards the more general modeling element.

1. Indicate An Association Between An Actor And A Use Case If The Actor Appears
Within The Use Case Logic

2. Avoid Arrowheads On Actor-Use Case Relationships

3. Apply <<include>> When You Know Exactly When To Invoke The Use Case

14
 4. Apply <<extend>> When A Use Case May
Be Invoked Across Several Use Case Steps

5. Introduce <<extend>> associations sparingly

6. Generalize Use Cases When a Single

Condition Results In Significantly New Business
Logic

7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>

8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case To The Right Of The Invoking Use
Case
10. Place An Extending Use Case Below The Parent Use Case
11. Apply the “Is Like” Rule to Use Case Generalization
12. Place an Inheriting Use Case Below The Base Use Case
13. Apply the “Is Like” Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor

4. System Boundary Boxes

The rectangle around the use cases is called the

system boundary box and as the name suggests
it indicates the scope of your system – the use
cases inside the rectangle represent the
functionality that you intend to implement.

1. Indicate Release Scope with a System Boundary Box.

2. Avoid Meaningless System Boundary Boxes.

Creating Use Case Diagrams

we start by identifying as many actors as possible.

You should ask how the actors interact with the
system to identify an initial set of use cases. Then,
on the diagram, you connect the actors with the
use cases with which they are involved. If actor
supplies information, initiates the use case, or

15
receives any information as a result of the use
case, then there should be an association
between them.

Conclusion: The Use case diagram was made successfully by

following the steps
described above.

COLLEGE

BANK APPLICATION MANAGEMENT

16
LIBRARY MANAGEMENT SYSTEM.

17