NRI INSTITUTE OF INFORMATION SCIENCE

AND TECHNOLOGY, BHOPAL

DEPARTMENT OF
COMPUTER SCIENCE AND ENGINEERING

LAB MANUAL

Skill Development Lab (CS-606)

Semester – 6th
Year – 3rd
S.No. List of Experiments
1. Software Product as Life Cycle :
SDLC (Software Development Life Cycle) Phases,
SDLC models, Agile Model, Agile Vs Traditional SDLC Models

2. Software Products development standards :

Software quality management, Quality assurance, planning,management, Process
and product quality, ISO Standard,
Product metrics
3. Design Pattern -1 :
To perform the user‘s view analysis for the suggested system:
Use case diagram.
4. Do requirement analysis and develop Software Requirement
Specification Sheet (SRS).
5. To perform the function oriented diagram:
Data Flow Diagram (DFD) and Structured chart.
6. To study and perform analysis on Functional and NonFunction Requirement.

7. Design Pattern -2 :
To draw the structural view diagram for the system: Class
diagram, object diagram.
8. To perform the implementation Activity diagram for the
system.
9. Case Study:
To perform various testing using the testing tool unit testing,integration testing for a
sample code of the suggested system.
10. To prepare the Business Model of your project.

ADDITIONAL LIST OF EXPERIMENT

11. Draw use case diagram along with use case description.

12. Develop UML use case model for a problem.

 COURSE OUTCOME (CO)

CS606.1 Understand the basics of software as a product.

CS606.2 Understand the current requirements of industries.

CS606.3 Implement the software as a product using different design patterns.
CS606.4 Apply the software development techniques in real life applications.
 EXPERIMENT No.-1

Aim: S/w Product as Life Cycle: (Software Development Life

Cycle) Phases, SDLC models, Agile Model, Agile Vs Traditional SDLC
Models

Theory: Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality softwares. The SDLC aims to produce a high-quality software that meets or
exceedscustomer expectations, reaches completion within times and cost estimates.

The SDLC process includes planning, designing, developing, testing and deploying with ongoing
maintenanceto create and manage applications efficiently.

There are 7 stages of Software Development Life Cycle.

1. Planning and Requirement Analysis

2. Defining Requirements

3. Designing the Product Architecture

4. Building or Developing the Product

5. Testing the Product

6. Deployment in the Market

7. Maintenance
Waterfall SDLC Model

Waterfall is a cascade SDLC model, in which development process looks

like the flow, moving step bystep through the phases of analysis, projecting,

realization, testing, implementation, and support. This SDLC model

includes gradual execution of every stage completely. This process is

strictly documentedand predefined with features expected to every phase of

this software development life cycle model.

The Waterfall SDLC Model

Advantages of waterfall model

 Simple to use and understand

 Management simplicity thanks to its rigidity. Every phase has a defined result
and processreview.

 Development stages go one by one.

 Perfect for the small or mid-sized projects where requirements are clear and not equivocal.

 Easy to determine the key points in the development cycle.

Disadvantages of waterfall model

 The software is ready only after the last stage is over.

 High risks and uncertainty.

 Not the best choice for complex and object-oriented projects.

 Inappropriate for the long-term projects.

 The progress of the stage is hard to measure while it is still in the development.

Agile Model
The meaning of Agile is swift or versatile."Agile process model" refers to a
software development approach based on iterative development. Agile
methods break tasks into smaller iterations, or parts do not directly
involve long term planning. The project scope and requirements are laid
down at the beginning of the development process. Plans regarding the
number of iterations.
Phases of Agile Model:
Following are the phases in the agile model are as follows:
 Requirements gathering
 Design the requirements
 Construction/ iteration
 Testing/ Quality assurance
 Deployment

Feedback open of each iteration are clearly defined in advance.

Phases of Agile Model:

Following are the phases in the agile model are as follows:

 Requirements gathering
 Design the requirements
 Construction/ iteration
 Testing/ Quality assurance
 Deployment
 Feedback

 Requirement gathering: in this phase, you must define the requirement you should
explain business opportunities and plan the time and effort needed to build the project
based on this information; you can evaluate technical and economics feasible.

 Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the high-
level UML diagram to show the work of new features and show how it will apply to
your existing system.

 Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a
working product. The product will undergo various stages of improvement, so it
includes simple, minimal functionality.

 Testing: In this phase, the Quality Assurance team examines the product's
performance and looks forthe bug.

 Deployment: In this phase, the team issues a product for the user's work environment.

 Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

Agile Testing Methods:

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
 EXPERIMENT NO. 02

Aim: Software Products development standards:

Software quality management, Quality assurance, planning, management, Process and
product quality,ISO Standard, Product metrics

Theory: - Software product development is a repetitive logical process that aims to builds a
programmed software product to mark a unique personal or business goal, process, or
objective.It is mostly a planned strategy that comprises various stages or steps that result in
the creation of an operational software product.

Software product development basically implies the deployment of a set of features in a

software product tailored to meet certain needs of a market. Software product development is
a repetitive logical process that aims to builds a programmed software product to mark a
unique personal or business goal, process, or objective. It is mostly a planned strategy that
comprises various stages or steps that result in the creation of an operational software product.

4 Basic Type of Software Products as per our Business

Needs

 System Software Products

Systems software programs manage the resources of the computer system that
help simplifyapplication programming. They include software such as the
operating system, database management systems, networking software, translators,
And software utilities.

 Programming Software Products

Programming software also knows as development tools such as compilers, text editors,
debuggers, linker are programs or set of programs which help software developers in
creating, debugging, and maintaining other programs and apps.
  Application Software Products:

Application Software is an application or product that can be used to perform tasks. Famous
examplesof application software are data management software, Office productivity suites,
media players, etc.

 Embedded Software Products:

Embedded System Software products are used to control machines and

devices throughtelecommunications networks, industrial robots, cars, and
more.
 EXPERIMENT NO. 03

Aim: Design Pattern -1: To perform the user‘s view analysis for the
suggested system:Use case diagram.

Theory: Use case diagram is a behavioral UML diagram type and frequently used toanalyze
various systems. They enable you to visualize the different types of roles in a system and
how those roles interact with the system. This use case

Diagram tutorial will cover the following topics and help you create use cases better.

Importance of Use Case Diagrams

As mentioned before use case diagrams are used to gather a usage requirement of a
system. Depending on your requirement you can use that data in different ways.

Below are few ways to use them.

 To identify functions and how roles interact with them – The primary
purpose of use case diagrams.

 For a high-level view of the system – Especially useful when presenting to

managers or stakeholders. You can highlight the roles that interact with the system
and the functionality provided by the system without going deep into inner workings
of the system.

 To identify internal and external factors – This might sound simple but in
large complex projects a system can be identified as an external role in another use
case.
Use Case Diagram objects

Use case diagrams consist of 4 objects.

 Actor
 Use case
 System
 Package
 EXPERIMENT NO.4

Aim: Do requirement analysis and develop Software Requirement Specification

Sheet (SRS).

Theory: Typically a SRS is written by a technical writer, a systems architect, or a software

programmer.

An SRS can be simply summarized into four Ds:

1. Define your product's purpose.

2. Describe what you're building
3. Detail the requirements.
4. Deliver it for approval.

An SRS gives us a complete picture of our entire project. It provides a single source of truth
that everyteam involved in development will follow. It is our plan of action and keeps all our
teams — from development to maintenance.
 EXPERIMENT NO.5
Aim: To perform the function oriented diagram: Data Flow Diagram (DFD) and Structured
chart.

Theory: Function Oriented Design Strategies:

Function Oriented Design Strategies are as follows:

1. Data Flow Diagram (DFD):

A data flow diagram (DFD) maps out the flow of information for any process or system. It
usesdefined symbols like rectangles, circles and arrows, plus short text labels, to show data
inputs, outputs, storage points and the routes between each destination.

2. Data Dictionaries:
Data dictionaries are simply repositories to store information about all data items defined in
DFDs. At the requirement stage, data dictionaries contain data items. Data dictionaries
includeName of the item, Aliases (Other names for items), Description / purpose, related
data items, Range of values, Data structure definition / form.

3. Structure Charts:
It is the hierarchical representation of system which partitions the system into black boxes
(functionality is known to users but inner details are unknown). Components are read from top
tobottom and left to right. When a module calls another, it views the called module as black
box, passing required parameters and receiving results.

Function Oriented Design is an approach to software design where the design is

decomposed into a set of interacting units where each unit has a clearly defined function.
 1. Generic Procedure:
Start with a high level description of what the software / program does. Refine each part of
thedescription one by one by specifying in greater details the functionality of each part.
These points lead to Top-Down Structure.
 2. Problem in Top-Down design method:
Mostly each module is used by at most one other module and that module is called its Parent
module.
Solution to the problem:
Designing of reusable module. It means modules use several modules to do their required
functions.
 EXPERIMENT NO. 06

Aim: To study and perform analysis on Functional and Non Function Requirement.

Theory: Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer. All these
functionalities need to be necessarily incorporated into the system as a part of the
contract. These are represented or stated in the form of input to be given to the system,
the operation performed and the output expected. They are basically the requirements
stated by the user which one can see directly in the final product, unlike the non-
functional requirements.

Non-functional requirements: These are basically the quality constraints that the
system must satisfy according tothe project contract. The priority or extent to which
these factors are implemented varies from one project to other. They are also called non-
behavioral requirements.
They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
 EXPERIMENT NO. 07

Aim: - Design Pattern -2: To draw the structural view diagram for the system: Class
diagram, object diagram.

Theory: Design patterns are typical solutions to commonly occurring problems in

software design. They are likepre-made blueprints that you can customize to solve a
recurring design problem in your code. You can't just find apattern and copy it into
your program, the way you can with off-the-shelf functions or libraries.

Three Types of Design Patterns (Behavioral, Creational,

Structural) Distinguish betweenBehavioral, Creational, and
Structural Design Patterns.
A design pattern is a general reusable solution to a commonly occurring problem within a
given context. What doesthat mean?
Programmers often encounter the same problem repeatedly. Rather than have everyone
come up with their own solution to common programming issues, we use a best practice
type solution that has been documented and proven to work.

The word general is important. We cannot just copy and paste a design pattern into our
code. A design patternrepresents an idea, and we should write an implementation for that
pattern and implement that in our code.
Advantages of Design Patterns

Using a design pattern has a few advantages. We get to use a solution that is known to
work. The tradeoffs, if any, are well documented, so we do not stumble over problems that
have already been solved. In addition, design patterns also serve as communication aids.
Your project manager can say, "We will use a singleton,"" and that one word is enough to
tell you what is expected.
When books or web pages document patterns, they do so using a consistent format. We
pay homage to this universal format by including sections for the
1. Problem,
2. Solution, and
3. Benefits of the singleton pattern.
 EXPERIMENT NO. 08

Aim: To perform the implementation Activity diagram for the system.

Theory: - To Draw an Activity Diagram

Step 1: Figure out the action steps from the use case. Here you need to identify the
various activities andactions your business process or system is made up of.
Step 2: Identify the actors who are involved. ...

Step 3: Find a flow among the activities. ...

Step 4: Add swim lanes.
The purpose of an activity diagram can be described as –

 Draw the activity flow of a system.

 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.

Before drawing an activity diagram, we must have a clear understanding about the
elements used in activity diagram. The main element of an activity diagram is the
activity itself. An activity is a function performed by the system. After identifying the
activities, we need to understand how they are associated with constraints and
conditions.

Before drawing an activity diagram, we should identify the following elements −

 Activities
 Association
 Conditions
 Constraints















 EXPERIMENT NO. 09

Aim: - Case Study: - To perform various testing using the testing tool unit testing,
integration testing for a sample code of the suggested system.
Theory: - Unit testing is a kind of white box testing, whereas Integration Testing is
a kind of black-box testing.
For Unit Testing, accessibility of code is required, as it tests the written code, while for
Integration Testing, access tocode is not required, since it tests the interactions and
interfaces between modules.

Unit Testing is a type of software testing where individual units or components of

software are tested. The purposeis to validate that each unit of the software code performs
as expected. Unit Testing is done during the development (coding phase) of an application
by the developers. Unit Tests isolate a section of code and verify its correctness. A unit
may be an individual function, method, procedure, module, or object.
Unit Testing is of two types

 Manual
 Automated

Unit testing is commonly automated but may still be performed manually. Software
Engineering does not favor one over the other but automation is preferred. A manual
approach to unit testing may employ a step-by-step instructional document.
 EXPERIMENT NO. 10

Aim: - To prepare the Business Model of the project.

Case Study: - The term business model refers to a company's plan for making a profit. It
identifies the products or services the business plans to sell, its identified target market,
and any anticipated expenses. Business models are important for both new and established
businesses. They help new; developing companies attract investment, recruit talent, and
motivate management and staff.
KEY TAKEAWAYS
 A business model is a company's core strategy for profitably doing business.
 Models generally include information like products or services the business plans
to sell, target markets, andany anticipated expenses. 
 There are dozens of types of business models including retailers, manufacturers,
fee-for-service, or fermiumproviders. 
 The two levers of a business model are pricing and costs.
 When evaluating a business model as an investor, consider whether the
product being offer matches a trueneed in the market.
Evaluating Successful Business Models

A common mistake many companies make when they create their business models is to
underestimate the costs of funding the business until it becomes profitable. Counting costs
to the introduction of a product is not enough. A company has to keep the business
running until its revenues exceed its expenses.

Types of Business Models

There are as many types of business models as there are types of business. For
instance, direct sales, franchising,advertising-based, and brick-and-mortar stores are
all examples of traditional business models. There are hybrid models as well, such as
businesses that combine internet retail with brick-and-mortar stores or with sporting
organizations like the NBA.
Retailer, Manufacturer, Fee-for-Service, Subscription, Fermium, Bundling, Marketplace
 EXPERIMENT NO. 11
Aim: - Draw use case diagram along with use case description.
Case Study:- Use case diagram is a behavioral UML diagram type and frequently
used to analyze various systems. They enable you to visualize the different types of roles
in a system and how those roles interact with thesystem. This use case diagram tutorial
will cover the following topics and help you create use cases better.
 Importance of use case diagrams
 Use case diagram objects
 Use case diagram guidelines
 Relationships in use case diagrams
o Identifying actors
o Identifying use cases
o When to use “Include”
o How to use generalization
o When to use “Extend”

Importance of Use Case Diagrams

As mentioned before use case diagrams are used to gather a usage requirement of a
system. Depending on yourrequirement you can use that data in different ways.
Below are few ways to use them.

 To identify functions and how roles interact with them – The primary purpose of
use case diagrams.
 For a high-level view of the system – Especially useful when presenting to
managers or stakeholders. You can highlight the roles that interact with the system
and the functionality provided by the system without going deep into inner
workings of the system.
 To identify internal and external factors – This might sound simple but in
large complex projects a systemcan be identified as an external role in another
use case.

Use Case Diagram objects

Use case diagrams consist of 4 objects.

 Actor 
 Use case
 System
 Package