II-II CSE SE LAB PROGRAMS:

1. Draw the Work Breakdown Structure for the system to be automated.

A work breakdown structure starts with a large project or objective and breaks it down into smaller, more
manageable pieces that you can reasonably evaluate and assign to teams. Rather than focusing on individual actions
that must be taken to accomplish a project, a WBS generally focuses on deliverables or concrete, measurable
milestones. These deliverables may also be called work packages, tasks, sub-tasks, or terminal elements. A work
breakdown structure looks something like this:

Fig: Example of Work Breakdown Structure

2. Schedule all the activities and sub-activities using the PERT/CPM charts.

Essentially, there are six steps which are common to both the techniques. The procedure is listed below:

a. Define the Project and all of it’s significant activities or tasks. The Project (made up of several tasks)
should have only a single start activity and a single finish activity.
b. Develop the relationships among the activities. Decide which activities must precede and which must
follow others.
c. Draw the "Network" connecting all the activities. Each Activity should have unique event numbers.
Dummy arrows are used where required to avoid giving the same numbering to two activities.
d. Assign time and/or cost estimates to each activity
e. Compute the longest time path through the network. This is called the critical path.
f. Use the Network to help plan, schedule, monitor and control the project.

The Key Concept used by CPM/PERT is that a small set of activities, which make up the longest path through the
activity network control the entire project. If these "critical" activities could be identified and assigned to responsible
persons, management resources could be optimally used by concentrating on the few activities which determine the
fate of the entire project.

Fig: CPM/PERT Activity Diagram

Each activity (or sub-project) in a PERT/CPM Network is represented by an arrow symbol. Each activity is
preceded and succeeded by an event, represented as a circle and numbered. At Event 3, we have to evaluate two
predecessor activities – Activity 1-3 and Activity 2-3, both of which are predecessor activities. Activity 1-3 gives us
an Earliest Start of 3 weeks at Event 3. However, Activity 2-3 also has to be completed before Event 3 can begin.
Along this route, the Earliest Start would be 4+0=4. The rule is to take the longer (bigger) of the two Earliest Starts.
So the Earliest Start at event 3 is 4.

Similarly, at Event 4, we find we have to evaluate two predecessor activities – Activity 2-4 and Activity 3-4. Along
Activity 2-4, the Earliest Start at Event 4 would be 10 wks, but along Activity 3-4, the Earliest Start at Event 4
would be 11 wks. Since 11 wks is larger than 10 wks, we select it as the Earliest Start at Event 4.We have now
found the longest path through thenetwork. It will take 11 weeks along activities 1-2, 2-3 and 3-4. This is the
Critical Path.
3. Define use cases and represent them in use-case document for all the stakeholders of the
system to be automated.

A use case describes how a user uses a system to accomplish a particular goal. A use case diagram consists of the
system, the related use cases and actors and relates these to each other to visualize: what is being described?
(system), who is using the system? (actors) and what do the actors want to achieve? (use cases), thus, use cases help
ensure that the correct system is developed by capturing the requirements from the user’s point of view.

A use case diagram is usually simple. It does not show the detail of the use cases:

 It only summarizes some of the relationships between use cases, actors, and systems.
 It does not show the order in which steps are performed to achieve the goals of each use case.

Fig:Use-Case Diagram

Actor
 Someone interacts with use case (system function).
 Named by noun.
 Actor plays a role in the business
 Similar to the concept of user, but a user can play different roles
 For example:
 A prof. can be instructor and also researcher
 plays 2 roles with two systems
 Actor triggers use case(s).
 Actor has responsibility toward the system (inputs), and Actor have expectations from the system
(outputs).

Use Case
 System function (process — automated or manual)
 Named by verb + Noun (or Noun Phrase).
 i.e. Do something
 Each Actor must be linked to a use case, while some use cases may not be linked to actors.

Communication Link
 The participation of an actor in a use case is shown by connecting a
actor to a use case by a solid link.
  Actors may be connected to use cases by associations, indicating that the actor and the use case
communicate with one another using messages.

Boundary of system
 The system boundary is potentially the entire system as defined in the
requirements document.
 For large and complex systems, each modules may be the system boundary.
 For example, for an ERP system for an organization, each of the modules such as
personal, payroll, accounting, etc.
 Can form a system boundary for use cases specific to each of these business functions.
 The entire system can span all of these modules depicting the overall system boundary
4. Identify and analyze all the possible risks and its risk mitigation plan for the system to be automated.

Risk is the future of uncertainty among events that have a probability of occurrence and a potential for loss. To
protect business interests the quality of software applications, QA testers must be able to quickly and accurately
identify and manage software testing risks. The three fundamental steps in managing these concerns are:
1.Create a list
2. Plan your execution
3. Use test management to handle risk

The Risk Mitigation Processes are as follows:

1. Mitigate risk through planning
2. Specify risk
3. Treating Identified Risk
4. Analysis Solutions

Upfront analysis identifies software risks that could even be responsible for crashing entire systems, preventing:
 Loss of revenue
 Customer dissatisfactions
 Costly time delays
 Data inconsistencies
 Lost data
 Failure to fulfill contracts
5. Diagnose any risk using Ishikawa Diagram (Can be called as Fish Bone Diagram or Cause &
Effect Diagram)
Cause and Effect Analysis was devised by professor Kaoru Ishikawa, a pioneer of quality management, in the
1960s. The technique was then published in his 1990 book, "Introduction to Quality Control."
The diagrams that you create with are known as Ishikawa Diagrams or Fishbone Diagrams (because a completed
diagram can look like the skeleton of a fish).
Although it was originally developed as a quality control tool, you can use the technique just as well in other ways.
For instance, you can use it to:
 Discover the root cause of a problem.
 Uncover bottlenecks in your processes.
 Identify where and why a process isn't working.
How to Use the Tool
Follow these steps to solve a problem with Cause and Effect Analysis:
Step 1: Identify the Problem
First, write down the exact problem you face. Where appropriate, identify who is involved, what the problem is, and
when and where it occurs.
Then, write the problem in a box on the left-hand side of a large sheet of paper, and draw a line across the paper
horizontally from the box. This arrangement, looking like the head and spine of a fish, gives you space to develop
ideas.

Step 2: Work Out the Major Factors Involved

Next, identify the factors that may be part of the problem. These may be systems, equipment, materials, external
forces, people involved with the problem, and so on.
Try to draw out as many of these as possible. As a starting point, you can use models such as the McKinsey 7S
Framework (which offers you Strategy, Structure, Systems, Shared values, Skills, Style and Staff as factors that you
can consider) or the 4Ps of Marketing (which offers Product, Place, Price, and Promotion as possible factors).
Then draw a line off the "spine" of the diagram for each factor, and label each line.
Example:
The manager identifies the following factors, and adds these to his diagram:
 Site.
 Task.
 People.
 Equipment.
 Control

Step 3: Identify Possible Causes

Now, for each of the factors you considered in step 2, brainstorm possible causes of the problem that may be related
to the factor.
Show these possible causes as shorter lines coming off the "bones" of the diagram. Where a cause is large or
complex, then it may be best to break it down into sub-causes. Show these as lines coming off each cause line.
Example:
For each of the factors he identified in step 2, the manager brainstorms possible causes of the problem, and adds
these to his diagram, as shown in figure 3.

Step 4: Analyze Your Diagram

By this stage you should have a diagram showing all of the possible causes of the problem that you can think of.
Depending on the complexity and importance of the problem, you can now investigate the most likely causes
further. This may involve setting up investigations, carrying out surveys, and so on. These will be designed to test
which of these possible causes is actually contributing to the problem.
Example:
The manager has now finished his analysis. If he hadn't looked at the problem this way, he might have dealt with it
by assuming that people in the branch office were "being difficult."
Instead he thinks that the best approach is to arrange a meeting with the Branch Manager. This would allow him to
brief the manager fully on the new strategy, and talk through any problems that she may be experiencing.
6. Define complete project plan for the system to be automated using Microsoft Project Tool.

Let’s create a new project and make some general adjustments by using MS Project 2016.
STEP 1: CREATING THE PROJECT
After MS Project has launched, choose File > New > Blank Project

STEP 2: GENERAL PROJECT SETTINGS

For every new project, you want to change some key information before continuing.
Go to Project > Project Information

STEP 2.1 – PROJECT START DATE

Enter the start date of your project:
STEP 2.2 – SET THE CALENDAR
See field Calendar in the same dialog: Here you can select alternative calendars:
 Standard – 8-hour work days from Monday to Friday, with 1-hour break (use this one)
 24 hours – if there are no breaks and no non-working time
 Night Shift – Covers 11 pm to 8 am an all nights from Monday to Friday, with one hour breaks
Once you have made the settings, choose “OK” to close the dialog box.
Let’s create a real project
I’m not going to bore you with an artificial project like ‘how to bake a cake’ or that kind of BS.
We’ll create the plan for a real project.
In this case, it’s a project where a company is moving to a new office space, and we are in charge of planning the
move, including getting office furniture and all office stuff shipped to the new location. And we want to do this
without interfering with daily business. People should be able to do their work, then on the weekend all items will be
transferred, so that your colleagues can start working from the new office building the following Monday.
Key project data:
 Goal: Office relocation
 Timeline: March – October
 Project phases: Project preparation, Selection of offices, Space design and furnishing, Physical relocation

Building the Task List

STEP 1: ENTER TASKS
Now enter the tasks for the first project phase in the tabular view:

STEP 2: ENTER TASK DURATION

Now we enter the start and finish date for each task.
In this case, MS Project automatically calculates the duration:
Tip: You can also enter a start date and a duration, and let MS Project calculate the Finish date.
When entering duration, use the following logic:
Duration you want to enter What to enter How it appears in MS Project
30 minutes 30m 30 mins
6 hours 2h 6 hrs
3 days 3d 3 days
6 weeks 6w 6 weeks
4 months 4mo 4 months
Now we have to talk about how Project uses those values to calculate the duration of your project. When you enter
for example a duration of 12 days for a task, the task will span across 3 weeks. Why? In MS Project’s default
configuration, a week as only 5 workdays. Therefore the task will consume two full weeks plus 2 days of the 3rd
week. Got it?
The following table shows you what default settings apply:
Value Value MS Project default value
entered
1 month 28 to 31 days, depending on the month 160 hours (20 workdays)
1 week 7 days 40 hours (5 workdays)
1 day 24 hours 8 hours (1 workday)
1 hour 60 minutes 60 minutes

STEP 3: CREATING SUMMARY TASKS

When you have to manage dozens or even hundreds of tasks, it makes sense to group tasks together into summary
tasks.
A summary task is not an actual task. It’s more like a “wrapper” to group several related tasks together under one
name. Duration, start and end date of a summary task depends on the tasks included under the summary task. The
start date will be the earliest start date of all subordinated tasks. Likewise, the end date of a summary task is equal to
the latest end date of the subordinated tasks.
To create a summary task, we first create a new task above the first one.
Select the 2nd row, press the right mouse button and choose Insert Task:
Project preparation is now a summary task. You can see this by the bold font and the little black triangle next to the
task.
Project preparation is our first project phase during which we set up the project, including creating a project plan,
staffing the project and creating a project budget.
7. Define the Features, Vision, Business objectives, Business rules and stakeholders in the vision document.
The manager’s employees and other stakeholders of an organization might be interested to understand where the
organization is going and what it aspires to be.
Meaning of Vision
Effective strategy making begins with a vision. Vision is a future-oriented concept of the business. Forming a
strategic vision is an exercise in thinking about where a company needs to head to be successful.
A vision is a mental image of a possible and desirable future state of the organization. A vision describes aspirations
for the future – a destination for the organization. We can say that a vision is a dream – a distant, long-term dream.

BUSINESS OBJECTIVES:
Business objectives are the results you hope to achieve as you run and grow your business. As an entrepreneur, you
are concerned with every aspect of your business and need to have clear goals in mind for your company if you are
to stay on track. Having a comprehensive list of business objectives creates the guidelines that become the
foundation for your business planning. The following are some of the business objectives
1. Getting and Staying Profitable
2. Productivity of People and Resources
3. Excellent Customer Service
4. Employee Attraction and Retention
5. Mission-driven Core Values
6. Sustainable Growth
7. Maintaining a Healthy Cash Flow
8. Dealing with Change
9. Reaching the Right Customers
10. Staying Ahead of the Competition

BUSINESS RULES:

They’re statements that describe how you must carry out certain operations and if there is some limit that you need
to apply. They guide behaviors and define what, where, when, why and how something should be done in a
company. These rules may be served in a formal, informal, written or automated manner. However, because they’re
so relevant, they’re not only properly recorded, but are also increasingly being implemented with the help of
technology through specialized software. These rules will state how a company works and therefore need to reflect
the organization’s policies. Thus, they point out requirements that shape the execution of activities and processes,
guiding the decision-making of its employees.
Common examples of processes that use business rules:
 Pricing Calculations
 Degrees of customer discount
 Budget approvals
 Loan releases
 Benefits offered
 Establishment of priorities
8. Define the functional and non-functional requirements of the systems to be automated by using Usecases and
document in SRS document.
Functional requirements:
Functional requirements are product features or functions that developers must implement to enable users
to accomplish their tasks. So, it’s important to make them clear both for the development team and the stakeholders.
Generally, functional requirements describe system behavior under specific conditions. For instance:
A search feature allows a user to hunt among various invoices if they want to credit an issued invoice.
Here’s another simple example: As a guest, I want a sofa that I can sleep on overnight.
Requirements are usually written in text, especially for Agile-driven projects. However, they may also be visuals.
Here are the most common formats and documents:
 Software requirements specification document
 Use cases
 User stories
 Work Breakdown Structure (WBS) (functional decomposition)
 Prototypes
 Models and diagrams
Nonfunctional requirements
Nonfunctional requirements describe how a system must behave and establish constraints of its functionality. This
type of requirements is also known as the system’s quality attributes.
Let’s have a close look at typical nonfunctional requirements.
 Usability
 Security
 Reliability
 Performance
 Availability
 Scalability

Use cases
Use cases describe the interaction between the system and external users that leads to achieving particular goals.
Each use case includes three main elements:
Actors:- These are the users outside the system that interact with the system.
System:- The system is described by functional requirements that define an intended behavior of the product.
Goals:- The purposes of the interaction between the users and the system are outlined as goals.
There are two formats to represent use cases:
 Use case specification structured in textual format
 Use case diagram

A use case specification represents the sequence of events along with other information that relates to this use case.
A typical use case specification template includes the following information:
 Description
 Pre- and Post- interaction condition
 Basic interaction path
 Alternative path
 Exception path
 Fig: Use-Case diagram
9. Define the following traceability matrices:
1. Usecase Vs Features
2. Functional requirements Vs Usecases
In a software development project, Requirements Traceability Matrix (RTM) is a document which is used to validate
that all the requirements are linked to test cases. This helps to ensure that all the requirements will be covered in the
testing phase. A Requirements Traceability Matrix is usually in tabular format as it holds multiple relationships
between requirements and test cases.
1. Use-case Vs Features:
Features:
Once we understand user needs, we translate them into features – one or more features meet one or more user needs.
Features are descriptions of high-level product functionality. Usually a feature is something you’ll print on a detailed
datasheet of your product – i.e. to share with your customers and prospective customers.
Use Cases:
We then derive one or more use cases from each feature. A use case defines how a user achieves a goal using our
product.Here’s how use cases are related to requirements:
Use cases are a way to document a specific type of requirement – called “Functional Requirements”. There
are many benefits to using use cases to document functional requirements.
2. Functional requirements Vs Usecases:
Functional Requirements Functional requirements capture the intended behavior of the system. This behavior may
be expressed as services, tasks or functions the system is required to perform. Use cases have quickly become a
widespread practice for capturing functional requirements. This is especially true in the object-oriented community
where they originated, but their applicability is not limited to object-oriented systems.
A use case defines a goal-oriented set of interactions between external actors and the system under
consideration. Actors are parties outside the system that interact with the system. An actor may be a class of users,
roles users can play, or other systems. Cockburn (1997) distinguishes between primary and secondary actors. A
primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the
system needs assistance.
10. Estimate the effort using the following methods for the system to be automated:
1. Function point metric
There are other ways of measuring software, such as counting user stories, counting use cases, counting the
number of pages of written requirements. However these are all highly variable measures from one project to
another. The only common and consistent currency is that of Function Points. The following are the methods to
estimate function point metric:
 Counting Function Points by Estimation
 Backfiring Function Points from Lines of Code
 Automated Function Point Count from Code
 Automated Function Point Count from Written Requirements

2. Usecase point metric

Use Case Points (UCP) is an estimation method that provides the ability to estimate an application’s size
and effort from its use cases. Based on work by Gustav Karner in 1993, UCP analyzes the use case actors, scenarios
and various technical and environmental factors and abstracts them into an equation.
The equation is composed of four variables:
1.Technical Complexity Factor (TCF).
2.Environment Complexity Factor (ECF).
3.Unadjusted Use Case Points (UUCP).
4.Productivity Factor (PF).
Each variable is defined and computed separately, using perceived values and various constants. The complete
equation is:
UCP=TCP * ECF * UUCP * PF
The necessary steps to generate the estimate based on the UCP method are:
1.Determine and compute the Technical Factors.
2.Determine and compute the Environmental Factors.
3.Compute the Unadjusted Use Case Points.
4.Determine the Productivity Factor.
5.Compute the product of the variables.
11. Develop a tool which can be used for quantification of all the non-functional requirements.
Satisfying goal is a design decision that has been chosen to satisfy a specific non-functional
requirement goal. Quantifying a goal involves assigning a particular algorithm to perform the required function.
Specific performance characteristics for the algorithm must be available before it can be assigned.

12. Write a python program for classifying various types of coupling.

In object oriented design, Coupling refers to the degree of direct knowledge that one element has of another. In other
words, how often do changes in class A force related changes in class B.
There are two types of coupling:
Tight coupling : In general, Tight coupling means the two classes often change together. In other words, if A knows
more than it should about the way in which B was implemented, then A and B are tightly coupled.
Example : If you want to change the skin, you would also have to change the design of your body as well because
the two are joined together – they are tightly coupled. The best example of tight coupling is RMI(Remote Method
Invocation).
// Java program to illustrate
// tight coupling concept
class Subject {
Topic t = new Topic();
public void startReading()
{
t.understand();
}
}
class Topic {
public void understand()
{
System.out.println("Tight coupling concept");
}
}
Explanation: In the above program the Subject class is dependents on Topic class. In the above program Subject
class is tightly coupled with Topic class it means if any change in the Topic class requires Subject class to change.
For example, if Topic class understand() method change to gotit() method then you have to change the
startReading() method will call gotit() method instead of calling understand() method.
// Java program to illustrate
// tight coupling concept
class Volume
{
public static void main(String args[])
{
Box b = new Box(5,5,5);
System.out.println(b.volume);
}
}
class Box
{
publicint volume;
Box(int length, int width, int height)
{
this.volume = length * width * height;
}
}
Output:
125
Explanation:In the above example, there is a strong inter-dependency between both the classes. If there is any
change in Box class then they reflects in the result of Class Volume.

2. Loose coupling : In simple words, loose coupling means they are mostly independent. If the only knowledge
that class A has about class B, is what class B has exposed through its interface, then class A and class B are
said to be loosely coupled. In order to over come from the problems of tight coupling between objects, spring
framework uses dependency injection mechanism with the help of POJO/POJI model and through
dependency injection its possible to achieve loose coupling.
Example : If you change your shirt, then you are not forced to change your body – when you can do that, then
you have loose coupling. When you can’t do that, then you have tight coupling. The examples of Loose
coupling are Interface, JMS.
// Java program to illustrate
// loose coupling concept
public interface Topic
{
void understand();
}
class Topic1 implements Topic {
public void understand()
{
System.out.println("Got it");
}
} class Topic2 implements Topic {
public void understand()
{
System.out.println("understand");
}
} public class Subject {
public static void main(String[] args)
{
Topic t = new Topic1();
t.understand();
}
}
Explanation : In the above example, Topic1 and Topic2 objects are loosely coupled. It means Topic is an
interface and we can inject any of the implemented classes at run time and we can provide service to the end
user.
// Java program to illustrate
// loose coupling concept
class Volume
{
public static void main(String args[])
{
Box b = new Box(5,5,5);
System.out.println(b.getVolume());
}
}
final class Box
{
privateint volume;
Box(int length, int width, int height)
{
this.volume = length * width * height;
}
publicintgetVolume()
{
return volume;

}
}
Output:
125
Explanation : In the above program, there is no dependency between both the classes. If we change anything in the
Box classes then wedont have to change anything in Volume class.
13. Write a C/C++/Java/Python program for classifying the various types of cohesion.
In object oriented design, cohesion refers all about how a single class is designed. Cohesion is the Object Oriented
principle most closely associated with making sure that a class is designed with a single, well-focused purpose.
The more focused a class is, the cohesiveness of that class is more. The advantages of high cohesion is that such
classes are much easier to maintain (and less frequently changed) than classes with low cohesion. Another benefit of
high cohesion is that classes with a well-focused purpose tend to be more reusable than other classes.
Example : Suppose we have a class that multiply two numbers, but the same class creates a pop up window
displaying the result. This is the example of low cohesive class because the window and the multiplication operation
don’t have much in common.
To make it high cohesive, we would have to create a class Display and a class Multiply. The Display will call
Multiply’s method to get the result and display it. This way to develop a high cohesive solution.
// Java program to illustrate
// high cohesive behavior
class Multiply {
int a = 5;
int b = 5;
publicintmul(int a, int b)
{
this.a = a;
this.b = b;
return a * b;
}
}

class Display {
public static void main(String[] args)
{
Multiply m = new Multiply();
System.out.println(m.mul(5, 5));
}
}
Output:

25
// Java program to illustrate
// high cohesive behavior
class Name {
String name;
public String getName(String name)
{
this.name = name;
return name;
}
}

class Age {
int age;
publicintgetAge(int age)
{
this.age = age;
return age;
}
}

class Number {
intmobileno;
publicintgetNumber(intmobileno)
{
this.mobileno = mobileno;
 returnmobileno;
}
}

class Display {
public static void main(String[] args)
{
Name n = new Name();
System.out.println(n.getName("AshokaEnggCollege"));
Age a = new Age();
System.out.println(a.getAge(10));
Number no = new Number();
System.out.println(no.getNumber(1234567891));
}
}
Output:
AshokaEnggCollege
17
1234567891
Difference between high cohesion and low cohesion:
 High cohesion is when you have a class that does a well defined job. Low cohesion is when a class does a
lot of jobs that don’t have much in common.
 High cohesion gives us better maintaining facility and Low cohesion results in monolithic classes that are
difficult to maintain, understand and reduces re-usability
14. Write a C/C++/Java/Python program for object oriented metrics for design proposed Chidamber and Kremer.
(Popularly called as CK metrics)