Entity- Relationship Diagram and its Importance

Entity- Relationship Diagram and its Importance

Data flow diagrams show how, where, and when data are used or changed in the information system, but they do not show the definition, structure, and relationships within the data.

An Entity can be any object, place, person or class. In E-R Diagram, an entity is represented using rectangles. Consider an example of an Organisation- Employee, Manager, Department, Product, and many more can be taken as entities in an Organisation. E-R model is used to represent real-life scenarios as entities. The properties of these entities are their attributes in the ER diagram and their connections are shown in the form of relationships. An attribute is represented as Oval in an ER diagram.

Entity-relationship (ER) data models are commonly used diagrams that show how data are organized in an information system. 

ER Diagram displays the relationships of entity set stored in a database or we can say that ER diagrams help you to explain the logical structure of databases.

An ER model is generally considered as a top-down approach in data designing.

ER diagram has three main components:

1. Entity

2. Attribute

3. Relationship

How to Draw ER Diagrams

1. Identify all the entities in the system. An entity should appear only once in a particular diagram. ...
2. Identify relationships between entities. Connect them using a line and add a diamond in the middle describing the relationship. A relationship is represented by diamond shape in ER diagram, it shows the relationship among entities. There are four types of relationships:

a.One to One

b. One to Many

c. Many to One

d. Many to ManyAdd attributes for entities.

ER diagrams are used to analyze existing databases to find and resolve problems in logic or deployment. Drawing the diagram should reveal where it's going wrong. Business information systems: The diagrams are used to design or analyze relational databases used in business processes.

An arrow from entity set to relationship set indicates a key constraint, i.e. injectivity: each entity of the entity set can participate in at most one relationship in the relationship set; Have a look at these resources also for better understanding.

ER diagrams are visual representations of databases, processes, and workflow with a particular focus on highlighting the relationships between the existing entities. Adobe Illustrator is a great tool for creating ER diagrams.

Limitations of E-R Diagram    

Limitation of the E-R diagram are as: 

(a) E-R models assume information content that can readily be represented in a relational database. They describe only a relational structure for this.

(b) They are inadequate for the system in which the information can not readily be represented in relational forms, such as with semi-structured data

(c)For many systems, possible changes to information contained are nontrivial and important enough to warrant explicit specification. 

(d) E-R Molding is aimed at specifying information from scratch. This suits the design of a new, standalone information system, but is of less help in integrating pre-existing information sources that already define their own data representation in detail.

(e) Even where it is suitable in principle, ER modeling is rarely used as a separate activity. One reason for this is today's abundance of tools to support diagramming and other design support directly on the relationship database management system, These tools can readily extract database diagrams that are very close to E-R diagram from the existing database and they provide an alternative view on the information contained in such diagrams.

Read More

Program Evaluation Review Technique and its Importance

Program Evaluation Review Technique (PERT)

It is a project management tool that provides a graphical representation of a project's timeline. PERT breaks down the individual tasks of a project for analysis.  

PERT was developed primarily to simplify the planning and scheduling of large and complex projects in 1957.

PERT analyzes the time required to complete each task and its associated dependencies to determine the minimum time to complete a project.

Purpose of PERT Charts

Project managers can use PERT charts to:

• Set a realistic timetable for project completion
• Identify tasks that need to be shortened if the overall project time needs to be reduced
• Identify tasks that can be carried out simultaneously
• Identify slack time where certain tasks are not as time-critical to the overall deadline.

How to draw a PERT chart 

We can design PERT chart with the help of nodes and arrows.

PERT offers a management tool, which relies on arrow and node diagrams of activities and events: arrows represent the activities or work necessary to reach the events or nodes that indicate each completed phase of the total project

Nodes represent events or milestones in your project. You can use either numbered circles or numbered boxes. 

Arrows represent the activities or tasks. The direction of the arrows shows the sequence of tasks. The direction of the arrows shows the sequence of tasks. Diverging arrows indicate that you can complete those tasks concurrently. 

Follow these steps to put your PERT chart together: 

• List all of the activities involved in the project. 
• Consider dependencies. 
• Place nodes and arrows based on the information you have gathered. 
• Add completion time for each activity. 

Critical Path Method (CPM)

We can determine a realistic timeframe for any project with the help of PERT chart. This process is called the Critical Path Method.

PERT and CPM are complementary tools, because "CPM employs one time estimation and one cost estimation for each activity; PERT may utilize three time estimates (optimistic, expected, and pessimistic) and no costs for each activity.

• optimistic time: the minimum possible time required to accomplish an activity or a path, assuming everything proceeds better than is normally expected
• expected time: the best estimate of the time required to accomplish an activity or a path, accounting for the fact that things don't always proceed as normal (the implication being that the expected time is the average time the task
• pessimistic time: the maximum possible time required to accomplish an activity or a path, assuming everything goes wrong (but excluding major catastrophes).

Read More

Data Flow Diagram and its Importance

Data Flow Diagram and its importance

Process modeling involves graphically representing the processes or actions, that capture, manipulate, store and distribute data between a system and its environment and among component within the system. A common form of a process model is a data-flow diagram (DFD). 

A process model is a formal way of representing how a business system operates. Through structural analysis technique called data flow diagram, the system analyst can put together a graphical representation of data processes throughout the organization. 

The purpose of data flow diagram is to show the “flow” and transformation of data through the system. These diagrams are used as visualization tool to help the audience get a better idea of what exactly is going on in the system. 

The DFDs are use to :

1. discuss with the user a diagrammatic interpretation of the process in the system and clarify what is currently being performed. 
2. determine what the new system should be able to do and what information is required for each different process the should be carried out. 
3. Check that the completed system conforms to its intended design. 
4. provides easy  presentation and communication between technical and non technical staff. 

Components of Data Flow Diagram

The components of Data Flow Diagram are always the same but there are different diagrammatic notations used. The notation used here is one adopted by a methodology known as structured systems analysis and design methods there are four different symbols that are normally used on a DFD. The elements represented are : 

• External entities 
• Processes 
• Data stores 
• Data Flows 

External entities are those things that are identified as needing to interact with the system under consideration. The external entities either input information to the system, output information from the system or both. Typically, they may represent job tilled or other systems that interact with the system to be built. 

A process is an activity or a function that is performed for some specific business reason. Processes are actions that are carried out with the data that flows around the system. 

The process symbol has three parts a

  

               1.  Process identifier 2. Where / who             3.   Process name

Data stores are places where data may be stored. This information may be stored. This information may be stored either temporarily or permanently by the user. In any system you will probably need to make some assumptions about which relevant data stores to include. How many data stores you place on a DFD some what depends on the case study and how for you go in being specific about the information stored in them. It is important to remember that unless we store information coming our system it will be lost. 

A data flow is a single piece of data (some times called a data element) or a logical collection of several pieces of information (e.g. purchase receipt). Every data flow should be named with noun. The description of a data flow lists exactly what data elements the flow certain. For example, the payment details data flow can list the payment type, payment amount, and account number as its data elements. 

We must follow a set of rules when drawing data flow diagrams. DFD rules are :

1. Each process must have a minimum of one data flow going into it and one data flow leaving it. 
2. Each data store must have at least one data flow going into it and one data flow leaving it. 
3. A data flow out of the process should have some relevance to one or more of the data flows into a process. 
4. Data stored in a system must go through a process. 
5. Filing systems within an organization cannot logically communicate with one another unless there is a process involved. 
6. All processes in DFA must be linked to either another process or a data store 

DFD Characteristics are :

1. DFD can be used to model physical logical, current or new systems. 
2. DFD does not represent procedural or time-related processes. 
3. Revisions of the same DFD are done to improve model based on understanding. 
4. Decision to stop iterative decomposition may be difficult. 

Read More

Software Engineering: Classification of Requirements

Software Engineering: Classification of Requirements

Requirement can be classified as:

• Functional requirements
• Non-functional requirements
• User requirements
• System requirements

What is a Functional Requirement?

In software engineering, a functional requirement defines a system or its component. It describes the functions a software must perform. A Functional Requirement is a description of the service that the software must offer. It describes a software system or its component.  

For example, in a hospital management system, a doctor should be able to retrieve the information of his patients. 

What is a Non-Functional Requirement?

A non functional requirement defines the quality attribute of a software system. Advantage of Non-functional requirement is that it helps you to ensure good user experience and ease of operating the software. They are also called non-behavioral requirements. Types of Non-functional requirement are  Scalability, Reliability, Availability, Maintainability, Performance, Flexibility Reusability etc.

Functional requirement defines  system or its components whereas anon functional requirement defines the performance attributes of a software system. comparison of functional and non functional is given below:

Parameters	Functional Requirement	Non-Functional Requirement
Requirement	It is mandatory	It is non-mandatory
End-result	Product feature	Product properties
Capturing	Easy to capture	Hard to capture
Objective	Helps you verify the functionality of the software.	Helps you to verify the performance of the software.
Area of focus	Focus on user requirement	Concentrates on the user's expectation.
Documentation	Describe what the product does	Describes how the product works
Type of Testing	Functional Testing like System, Integration etc.	Non-Functional Testing like Performance, Maintainability, Usability, Reliability, etc.
Product Info	Product Features	Product Properties

User Requirement

The user requirements for a system should describe the functional and non-functional requirements so that they are understandable by users who don’t have technical knowledge. User requirements, we must write in natural language supplied by simple tables, forms, and  diagrams etc. Details of system design must be included in requirement.

System Requirement

The system requirements on the other hand are expanded version of the user requirements that are used by software engineers as the starting point for the system design. It is essential that how the user requirements should be provided by the system. 

The system requirements on the other hand are expanded version of the user requirements that are used by software engineers as the starting point for the system design. It is essential that how the user requirements should be provided by the system. 

Read More

Software Engineering : COCOMO (Construction Code Model)

COCO Model  OR COCOMO (Construction Code Model)

The COCOMO is one of the most popularly used software cost estimation models i.e. total project cost and scheduled time for the project based on the size of the software product.T his model depends on the number of lines of code for software product development. It was developed by a software engineer Barry Boehm in 1981.

According to COCOMO, there are three modes of software development projects that depend on complexity.

1. Basic Project: It is the one type of static model to estimates software development effort quickly and roughly. It mainly deals with the number of lines of code and the level of estimation accuracy is less as we don’t consider the all parameters belongs to the project. Developed by small team with good knowledge. For Example  Inventory Management System.
2. Intermediate Project: It is the one type model which estimates software development effort in terms of size of the program and other related cost drivers parameters (product parameter, hardware parameter, resource parameter, and project parameter) of the project. Developed by team having mixed experience to deals with rigid/nonrigid requirements. For Example Database Design or OS development.
3. Embedded Project: It is the advanced model that estimates the software development effort like Intermediate COCOMO in each stage of the software development life cycle process. Embedded project having a high level of Complexity with large team size by, considering all sets of parameters i.e. hardware, software and operational. For Example Banking software. Traffic Light software.

Advantages :

Its easy to estimate the cost of the Project and implement the various factors.

Disadvantages :

It ignores requirements, and limits the accuracy of the software costs. It mostly depends on time factor.

Read More