Software Engineering Laboratory Manual - Prof. Dave, Study Guides, Projects, Research of Software Engineering

Download Software Engineering Laboratory Manual - Prof. Dave and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

SAL College of Engineering

IT Department

Software Engineering ( 3161605 )

Laboratory Manual

Year: 2021 - 2022

Prepared By:

Nilam Thakkar

INDEX

Sr.

No.

Experiment

Page No.

Date Marks Signature From To

Study the complete Software

Development Life Cycle (SDLC)

and analyze various activities

conducted as a part of various

phases.

Develop Requirement

Specification for a given

problem

Case Study on Rational Rose

Tool.

Prepare Data dictionary for

given system.

Prepare Use Case Diagram for

given system.

Prepare all the levels of DFD

diagram for given system.

Prepare ER diagram on given

system.

Develop Activity diagram for

given system.

Calculate FP based Estimation

and LOC based Estimation for

any project.

Consider the any code segment:

1. Guarantees that all

independent execution path is

exercised at least once; 2.

Calculate the Cyclomatic

complexity for given code

Page 2 of 40

1. Requirement Analysis

Software Development Life Cycle begins with Requirement Analysis phase, where the

stakeholders discuss the requirements of the software that needs to be developed to achieve a

goal. The aim of the requirement analysis phase is to capture the detail of each requirement

and to make sure everyone understands the scope of the work and how each requirement is

going to be fulfilled.

It is a normal practice to also discuss how each requirement will be tested and so testers can

add great value in participating in requirement analysis meetings. Depending on which

software development methodology is used, different approaches are taken in moving from

one phase to another. For example, in the waterfall or V model, the requirement analysis phase

are saved in a SRS (Software Requirement Specification) document and needs to be finalized

before the next phase can take place.

2. Design

The next stage of Software Development Life Cycle is the Design phase. During the design

phase, developers and technical architects start the high-level design of the software and

system to be able to deliver each requirement.

The technical details of the design are discussed with the stakeholders and various parameters

such as risks, technologies to be used, capability of the team, project constraints, time and

budget are reviewed and then the best design approach is selected for the product. The selected

architectural design, defines all the components that needs to be developed, communications

with third party services, user flows and database communications as well as front-end

representations and behavior of each component. The design is usually kept in the Design

Specification Document (DSD)

3. Development Implementation

After the requirements and design activity is completed, the next phase of the Software

Development Life Cycle is the implementation or development of the software. In this phase,

developers start coding according to the requirements and the design discussed in previous

phases. In this the work is divided in modules/units and actual coding is started. Since, in this

phase the code is produced so it is the main focus for the developer. This is the longest phase

of the software development life cycle.

Database admins create the necessary data in the database, front-end developers create the

necessary interfaces and GUI to interact with the back-end all based on guidelines and

procedures defined by the company. Developers also write unit tests for each component to

test the new code that they have written, review each other’s code, create builds and deploy

software to an environment. This cycle of development is repeated until the requirements are

4. Testing

Testing is the last phase of the Software Development Life Cycle before the software is delivered

to customers. During testing, experienced testers start to test the system against the

requirements. The testers aim to find defects within the system as well as verifying whether the

application behaves as expected and according to what was documented in the requirements

analysis phase.

Testers can either use a test script to execute each test and verify the results. It is possible that

defects are identified in the testing phase. Once a defect is found, testers inform the developers

about the details of the issue and if it is a valid defect, developers will fix and create a new

version of the software which needs to be verified again. This cycle is repeated until all

requirements have been tested and all the defects have been fixed and the software is ready to

be shipped.

5. Deployment and Maintenance

Once the software has been fully tested and no high priority issues remain in the software, it is

time to deploy to production where customers can use the system.

Once a version of the software is released to production, there is usually a maintenance team

that look after any post-production issues. If an issue is encountered in the production the

development team is informed and depending on how severe the issue is, it might either

require a hot-fix which is created and shipped in a short period of time or if not very severe, it

can wait until the next version of the software.

EVALUATION:

Involvement

Understanding /

Problem solving

Timely

Completion

Total

Signature with date:

Page 5 of

What do you mean by requirement analysis in SDLC?

Functional requirements specify a function that a system or system component must be able to

perform. It can be documented in various ways. The most common ones are written

descriptions in documents, and use cases.

Use cases can be textual enumeration lists as well as diagrams, describing user actions. Each

use case illustrates behavioral scenarios through one or more functional requirements. Often,

though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive

the functional requirements that must be implemented to allow a user to perform each use

case.

Functional requirements are what a system is supposed to accomplish. Its m

● Calculations

● Product details

● Data manipulation

● Data processing

● Other specific functionality

A typical functional requirement will contain a unique name and number, a brief

summary, and a rationale. This information is used to help the reader understand why the

requirement is needed, and to track the requirement through the development of the system.

Non-Functional Requirement: -

Non-functional requirements are any other requirement than functional requirements.

This are the requirements that specifies criteria that can be used to judge the operation

of a system, rather than specific behaviors.

Non-functional requirements are in the form of "system shall be " , an overall property of the

system as a whole or of a particular aspect and not a specific function. The system's overall

properties commonly mark the difference between whether the development project has

succeeded or failed. Non-functional requirements - can be divided into two main categories:

● Execution qualities , such as security and usability, which are observable at run

time.

● Evolution qualities , such as test-ability, maintainability, extensibility and

scalability, which are embodied in the static structure of the software system

Non-functional requirements place restrictions on the product being developed, the development

process, and specify external constraints that the product must meet.

Some typical non-functional requirements are:

● Performance – for example Response Time, Throughput, Utilization,

Static Volumetric.

● Scalability.

● Capacity.

● Availability.

● Reliability.

● Recoverability.

● Maintainability.

● Serviceability.

Requirement Analysis for Smart shop

Now a day, every person is using android OS. We have made one website named “Smart

shop”. Customer can purchase products. Admin can upload products like wheat, rice etc.

Customer can login from his/her ID & Password. Then they can able to purchase products.

Admin also change his profile & he/she also change personal details but cannot change

his/her id or subject.

● User must have product easily to buy in smart shop.

● User must have identity on understand on appropriate function of website.

● User must have required plug in for this website.

● User must know how to run website.

● User must have good understanding to use the system more efficiently

with the use of appropriate messages given while using the system.

● User must be aware of the terminology used in the system.

● User must have provided different type of searching facilities.

Exercise: Analyses all the functional requirements of Society management system.

According to Roger Pressman in Software Engineering: A Practitioner's Approach (McGraw-Hill

Publications) [SEPA–1997], the requirement specification document is produced at the end of Analysis of

the system. This document is a very comprehensive document & contains all the User requirements &

Analysis diagrams.

The Requirements are broadly divided into two groups:

1. Functional requirements

2. Non-functional requirements

The main purpose of functional requirements within the requirement specification document is to define all

the activities or operations that take place in the system. These are derived through interactions with the users

of the system. Since the Requirements Specification is a comprehensive document & contains a lot of data,

it has been broken down into different Chapters in this report. The depiction of the Design of the System in

UML is presented in a separate chapter. The Data Dictionary is presented in the Appendix of the system. But

the general Functional Requirements arrived at the end of the interaction with the Users are listed below. A

more detailed discussion is presented in the Chapters, which talk about the Analysis & Design of the system.

System Requirement:

System requirements study involves a clear and thorough understanding of the product to be developed with

the view of removing all ambiguities from customer perception.

User Characteristics:

There are four types of users in these application Society members, Committee members, Security guard and

Admin. Admin can manage application and database and account of maintenance bills, receipt, and vendor

list, etc. society members check and pay their maintenance bill. In others, members can do complains and all

can give their suggestion and also search vendor and committee members contacts, can read daily newspaper

as per their requirements. Committee members manage a society member and handle them complains as well

as send a notification for meetings, events, notice, etc. Security guard do a guest verification for society and

their member’s security by unwanted guest and he can read newspapers.

Functional Requirements:

1. Admin can create account for users.

2. Admin can approve request and track for maintenance payment.

3. Admin can notify and track the fault in any house after lodging complaint.

4. Members can save their maintenance status, get notified regarding events, general notices.

5. Easy maintenance bill payment using online payment integration which helps cashless service.

6. User will able to give feedback.

Non-Functional Requirements

1. Should work efficiently even on slow internet connections.

2. Secure Database.

3. Secure Payments.

4. Communication between admin and users.

5. Allow profile changes and can request for updation

6. Provide detailed sitemap.

7. Users’ satisfaction

ExperimentNo:3 Date: / /

TITLE: Case study on Rational Rose visual modeling Tool.

OBJECTIVES:

➢ Study the benefits of visual modeling

➢ Complete understanding of Rational Rose

THEORY:

Visual Modeling

Visual Modeling is a way of thinking about problems using models organized around real- world

ideas. Models are useful for understanding problems, communicating with everyone involved

with the project (customers, domain experts, analysts, designers.), modeling enterprises,

preparing documentation, and designing programs and databases

Visual Modeling

➔Capture the structure and behavior of architectures and components.

➔Show how the elements of the system fit together.

➔Hide or expose details appropriate for the task.

➔Maintain consistency between a design and its implement.

What is Rational Rose?

● ROSE stands for Rational Object-oriented Software Engineering.

● Rational Rose is developed by Rational Corporation which is under IBM.

● Rational Rose is a tool for modeling software systems.

● Rational Rose supports UML.

● The Rational Rose product family is designed to provide the software developer

with a complete set of visual modeling tools for development of robust, efficient

solutions to real business needs in the client/server, distributed enterprise and

real-time systems environments. Rational Rose products share a common

universal standard, making modeling accessible to non-programmers wanting to

model business processes as well as to programmers modeling applications logic.

Rational ROSE DIAGRAMS

● Use Case

● Collaboration

● Sequence

● Class

● State chart

● Activity

● Component

● Deployment

Page 10 of 40

● Right-clicking as shortcut

● Adding diagram elements from toolbar and browser

● Setting up default stereotypes

● Idea about the Reverse engineering

● Deleting from a diagram and the browser

Operations with Diagram

1. Creating a diagram

2. Linking a diagram

a. Create a note on any diagram.

b. Display the browser if not already visible.

c. In the browser, locate the diagram that you want to link.

d. Drag the diagram icon from the browser onto the note icon on the

diagram. A

e. s you position the cursor onto the note, you will see the shortcut

symbol (a dotted square and a curved arrow inside a solid square).

f. The fully qualified name is displayed in an underline

font. Note: You may need to resize the note to see the

entire name.

g. Change the text in the note (if desired) to something more meaningful

to your project.

h. Double-click on the note to view the linked diagram.

3. Displaying a diagram.

4. Rename a Diagram.

5. Deleting a diagram

Exercise:

1. How to Create a diagram in draw.io

2. Draw a diagram for flow chart of library management system using draw.io

EVALUATION:

Involvement

Understanding /

Problem solving

Timely

Completion

Total

Page 12 of 40

Signature with date: _

Experiment No: 4 Date: //

TITLE: Prepare Data dictionary for given project.

OBJECTIVES:

➢ Complete Understanding of Data Dictionary.

➢ Importance of Data Dictionary.

THEORY:

What is Data Dictionary?

A data dictionary is a collection of descriptions of the data objects or items in a data model for

the benefit of programmers and others who need to refer to them. A first step in analyzing a

system of objects with which users interact is to identify each object and its relationship to other

objects. The users of the database normally don't interact with the data dictionary, it is only

handled by the database administrators.

The data dictionary in general contains information about the following:

1. Names of all the database tables and their schemas.

2. Details about all the tables in the database, such as their owners, their

security constraints, when they were created etc.

3. Physical information about the tables such as where they are stored and how.

4. Table constraints such as primary key attributes, foreign key information.

5. Information about the database views that are visible.

This is a data dictionary describing a table that contains employee details.

Field Name Data Type Field Size

for display

Description Example

Employee

Number

Integer 10 Unique ID of each

employee

Name Text 20 Name of the employee David

Hesto

n n

Date of Birth Date/Time 10 DOB of Employee 08/03/

Phone

Number

Integer 10 Phone number of

employee

Data dictionary Exercise:

Table 1: tblsocietymember

Field Name

Data Type

(Length) Constraint Description

House_Id Varchar (5)

Primary

Key This Field Has Information of House Block.

S_Member_Firstname Varchar (30) Not Null This Field Has Society Member First Name.

S_Member_Lastname Varchar (30) Not Null This Field Has Society Member Last Name.

S_Member_Middlename Varchar (30) Not Null This Filed Has Society Member Middle Name.

Contact_No Varchar (10) Not Null This Field Has Contact Number.

Update Varchar (15)

Foreign

Key This Field Has Update for Member Information.

Status Varchar (10) Not Null This Field Has Member Status.

Table 2: tbl_memberlist

Field

Name

Data Type

(Length)

Constraint Description

House_No Varchar (5) Primary

Key

This field contain information of house number.

Contact_No Varchar (10) Foreign

key

This field contain information of user contact

number.

Table 3 : tbl_transaction

Field Name Data Type

(Length)

Constraint Description

User_id Varchar (10) Primary

key

This field contain detail maintenance of month

wise.

S_Member_Name Varchar (30) Not Null This field contain resident id.

Date Int (10) Not Null This field contain date of transaction.

Amount int (10) Not Null This field contain pay amount.

Type_of_Payment Varchar (10) Not Null This field contain type of payment information.

Bank name Varchar (20) Not Null This field contain bank name.

Account_Number Int (16) Foreign

key

This field contain bank number.

Month Varchar (10) Not Null This field contain your ATM card expire month.

Year Int (4) Not Null This field contain your ATM cart expire year.

Table 4 : tbl_visitorlog

Field Name Data Type

(Length)

Constraint Description

Visitor_Name Varchar (30) Not Null This field contain information of visitor name.

S_member_Name Varchar (30) Not Null This field contain a member name.

Block_Name Varchar (5) Not Null This field contain block name.

House_No Varchar (5) Primary

Key

This field contain House number.

Gender Varchar (6) Not Null This field contain gender information.

Number_Visitor Int (20) Not Null This field contain how many numbers of visitor for

visited.

Vehicle_Number Int (20) Not Null This field contain number of vehicles.

In_Time Varchar (10) Not Null This field contain information of in time.

Out_Time Varchar (10) Not Null This field contain information of out-time.

Purpose Varchar (20) Not Null This field contain information of purpose of visit.

Status Varchar (10) Not Null This field contain check status.

Table 5 : tbl_guestlog

Field Name Data Type

(Length)

Constraint Description

Guest Name Varchar (5) Not Null This field contain guest name.

House_No Varchar (5) Primary

Key

This field contain house number.

Number_Guest Int (20) Not Null This field contain number of guests.

Visiting_Date Varchar (10) Not Null This field contain information of visiting date.

Purpose Varchar (10) Not Null This field contain information of visiting purpose.

Mobile_Number Varchar (10) Foreign

Key

This field contain guest mobile number.

Status Varchar (10) Not Null This field contain check status.

Table 6 : tbl_notifications

Field Name Data Type

(Length)

Constraint Description

Message Title Varchar (20) Not Null This field contain notification for message.

Content_Type Varchar (20) Not Null This field contain information of contain type.

Date Varchar (15) Not Null This field contain information of date

Time Varchar (10) Not Null This field contain information of time.

Table 7 : tbl_faultrepairing

Field Name Data Type

(Length)

Constraint Description

House_No Varchar (5) Primary

Key

This field contain House number.

Fault_Name Varchar (20) Not Null This field contain information of fault name.

Description Varchar (50) Not Null This field contain information of fault description.

Action Varchar (50) Not Null This field contain information of action.

Status Varchar (10) Not Null This field contain check status.

Mobile_Number Varchar (10) Not Null This field contain member mobile number.

Table 8 : tbl_emergencycontact

Field Name Data Type

(Length)

Constraint Description

Name Varchar (30) Primary

Key

This field contain person name

Mobile_Number Varchar (10) Not Null This field contain person mobile number.

Status Varchar (10) Not Null This field contain check status.

Table 9 : tylotic

Field Name Data Type

(Length)

Constraint Description

Name Varchar (30) Not Null This field contain information name.

Date Varchar (10) Not Null This field contain notice date.

In_Time Varchar (10) Not Null This field contain start time.

Experiment No: 5 Date: / /

TITLE: Prepare Use Case Diagram for given system.

OBJECTIVES:

➢ Learn use case diagrams: discovering actors and discovering use cases.

➢ Practice use cases diagrams using Rational Rose.

THEORY:

What is Use Case diagram?

A use case diagram at its simplest is a representation of a user's interaction with the system

that shows the relationship between the user and the different use cases in which the user is

involved.

Use case diagrams are ideal for:

● Representing the goals of system-user interactions

● Defining and organizing functional requirements in a system

● Specifying the context and requirements of a system

● Modeling the basic flow of events in a use case

Use case diagram components

● Actors: The users that interact with a system. An actor can be a person, an

organization, or an outside system that interacts with your application or

system. They must be external objects that produce or consume data.

● System: A specific sequence of actions and interactions between actors

and the system. A system may also be referred to as a scenario.

● Use-cases: sequence of actions.

Basic Use Case Diagram Symbols and Notations

System: Draw your system's boundaries using a rectangle that contains use cases. Place

actors outside the system's boundaries.

Use Case: Draw use cases using ovals. Label the ovals with verbs that represent the system's

functions.

Actors: Actors are the users of a system. When one system is the actor of another system,

label the actor system with the actor stereotype.

Relationships: Illustrate relationships between an actor and a use case with a simple line.

For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses"

relationship indicates that one use case is needed by another in order to perform a task. An

"extends" relationship indicates alternative options under a certain use case.

Online-shopping use case diagram example