Ssad Notes-Ii Bca
Ssad Notes-Ii Bca
Ssad Notes-Ii Bca
System:
The word System is derived from Greek word Systema, which means an organized
relationship between any set of components to achieve some common cause or objective.
A system is “an orderly grouping of interdependent components linked together
according to a plan to achieve a specific goal.”
Constraints of a System
A system must have three basic constraints:
A system must have some structure and behavior which is designed to achieve a
predefined objective.
Interconnectivity and interdependence must exist among the system components.
The objectives of the organization have a higher priority than the objectives of its
subsystems.
For example, traffic management system, payroll system, automatic library system,
human resources information system.
Properties of a System
A system has the following properties:
Organization
Organization implies structure and order. It is the arrangement of components that helps
to achieve predetermined objectives.
Interaction
It is defined by the manner in which the components operate with each other. For
example, in an organization, purchasing department must interact with production
department and payroll with personnel department.
Interdependence
Interdependence means how the components of a system depend on one another. For
proper functioning, the components are coordinated and linked together according to a
specified plan.
The output of one subsystem is the required by other subsystem as input.
Integration
Integration is concerned with how a system components are connected together. It means
that the parts of the system work together within the system even if each part performs a
unique function.
Central Objective
The objective of system must be central. It may be real or stated. It is not uncommon for
an organization to state an objective and operate to achieve another.
The users must know the main objective of a computer application early in the analysis
for a successful design and conversion.
Elements of a System
The information needs are different at different organizational levels. Accordingly the
information can be categorized as:
strategic information,
managerial information and
operational information.
Strategic information is the information needed by top most management for decision
making.
For example the trends in revenues earned by the organization are required by the top
management for setting the policies of the organization.
This information is not required by the lower levels in the organization.
The information systems that provide these kinds of information are known as Decision
Support Systems.
The second category of information required by the middle management is known as
managerial information.
The information required at this level is used for making short term decisions and plans
for the organization.
Information like sales analysis for the past quarter or yearly production details etc. fall
under this category.
Management information system (MIS) caters to such information needs of the
organization.
Due to its capabilities to fulfill the managerial information needs of the organization,
Management Information Systems have become a necessity for all big organizations.
And due to its vastness, most of the big organizations have separate MIS departments to
look into the related issues and proper functioning of the system.
The third category of information is relating to the daily or short term information needs
of the organization such as attendance records of the employees.
This kind of information is required at the operational level for carrying out the day-to-
day operational activities.
Due to its capabilities to provide information for processing transaction of the
organization, the information system is known as Transaction Processing System or Data
Processing System.
Some examples of information provided by such systems are processing of orders,
posting of entries in bank, evaluating overdue purchaser orders etc.
Systems Design:
An effective System Development Life Cycle (SDLC) should result in a high quality
system that meets customer expectations, reaches completion within time and cost
evaluations, and works effectively and efficiently in the current and planned Information
Technology infrastructure. System Development Life Cycle (SDLC) is a conceptual
model which includes policies and procedures for developing or altering systems
throughout their life cycles.
SDLC is used by analysts to develop an information system. SDLC includes the
following activities:
a. Requirements
b. Design
c. Implementation
d. Testing
e. Deployment
f. Operations
g. maintenance
Phases of SDLC
Systems Development Life Cycle is a systematic approach which explicitly breaks down the
work into phases that are required to implement either new or modified Information System.
Feasibility Study or Planning
Define the problem and scope of existing system.
Overview the new system and determine its objectives.
Confirm project feasibility and produce the project Schedule.
During this phase, threats, constraints, integration and security of system are also
considered.
A feasibility report for the entire project is created at the end of this phase.
Analysis and Specification
Gather, analyze, and validate the information.
Define the requirements and prototypes for new system.
Evaluate the alternatives and prioritize the requirements.
Examine the information needs of end-user and enhances the system goal.
A Software Requirement Specification (SRS) document, which specifies the software,
hardware, functional, and network requirements of the system is prepared at the end of
this phase.
System Design
Includes the design of application, network, databases, user interfaces, and system
interfaces.
Transform the SRS document into logical structure, which contains detailed and complete
set of specifications that can be implemented in a programming language.
Create a contingency, training, maintenance, and operation plan.
Review the proposed design. Ensure that the final design must meet the requirements
stated in SRS document.
Finally, prepare a design document which will be used during next phases.
Implementation
Implement the design into source code through coding.
Combine all the modules together into training environment that detects errors and
defects.
A test report which contains errors is prepared through test plan that includes test related
tasks such as test case generation, testing criteria, and resource allocation for testing.
Integrate the information system into its environment and install the new system.
Maintenance/Support
Include all the activities such as phone support or physical on-site support for users that is
required once the system is installing.
Implement the changes that software might undergo over a period of time, or implement
any new requirements after the software is deployed at the customer location.
It also includes handling the residual errors and resolve any issues that may exist in the
system even after the testing phase.
Maintenance and support may be needed for a longer time for large systems and for a
short time for smaller systems.
UNIT-II
The system analyst is a person who is thoroughly aware of the system and guides the
system development project by giving proper directions.
He is an expert having technical and interpersonal skills to carry out development tasks
required at each phase.
He pursues to match the objectives of information system with the organization goal.
Main Roles
Defining and understanding the requirement of user through various Fact finding
techniques.
Prioritizing the requirements by obtaining user consensus.
Gathering the facts or information and acquires the opinions of users.
Maintains analysis and evaluation to arrive at appropriate system which is more user
friendly.
Suggests many flexible alternative solutions, pick the best solution, and quantify cost and
benefits.
Draw certain specifications which are easily understood by users and programmer in
precise and detailed form.
Implemented the logical design of system which must be modular.
Plan the periodicity for evaluation after it has been used for some time, and modify the
system as needed.
Attributes of a Systems Analyst:
Interpersonal Skills
Interface with users and programmer.
Facilitate groups and lead smaller teams.
Managing expectations.
Good understanding, communication, selling and teaching abilities.
Motivator having the confidence to solve queries.
Analytical Skills
System study and organizational knowledge
Problem identification, problem analysis, and problem solving
Sound commonsense
Ability to access trade-off
Curiosity to learn about new organization
Management Skills
Understand users jargon and practices.
Resource &project management
Change & risk management
Understand the management functions thoroughly.
Technical Skills
Knowledge of computers and software
Keep abreast of modern development.
Know of system design tools.
Breadth knowledge about new technologies.
Skill required for System Analyst:
Interpersonal skills are as follows:
1: Communication:
It is an interpersonal quality; the system analyst must have command on English
language.
Communication is necessary to establish a proper relationship between system analyst
and the user. Communication is need to Gather correct information Establishes a problem
solving ideas in front of the management.
2: Understanding:
This is also an interpersonal quality of the system analyst, understanding includes
Understanding of the objectives of the organization.
Understanding the problems of the system.
Understanding the information given by the user or employee of the organization.
3: Selling:
The ideas of the system analyst are his products which he sells to the manager of a
particular organization.
The system analyst must have not only the ability of creating ideas but also to sell his
ideas.
4: Teaching:
It is also an interpersonal quality.
A system analyst must have teaching skills. He must have the ability to teach team
members and the users.
He has to teach about the new system and also about the proper use of the new system.
5: New technology:
An analyst is an agent of change, he or she must have the ability to show all the benefits
of the candidate system with the new technological advancement, he must knew about
Email Internet Advance graphics Server based networking Network technology etc.
Attributes of System Analyst:
A System Analyst (SA) analyzes the organization and design of businesses, government
departments, and non-profit organizations;
They also assess business models and their integration with technology.
There are at least four tiers of business analysis:
1. Planning Strategically - The analysis of the organization business strategic needs
2. Operating/Business model analysis - the definition and analysis of the organization's policies
and market business approaches
3. Process definition and design - the business process modeling (often developed through
process modeling and design)
4. IT/Technical business analysis - the interpretation of business rules and requirements for
technical systems (generally IT).
Role of System Analyst:
Role of System Analyst differs from organization to organization. Most common responsibilities
of System Analyst are following :
1) System analysis
It includes system's study in order to get facts about business activity. It is about getting
information and determining requirements. Here the responsibility includes only requirement
determination, not the design of the system.
2) System analysis and design:
Here apart from the analysis work, Analyst is also responsible for the designing of the new
system/application.
3) Systems analysis, design, and programming:
Here Analyst is also required to perform as a programmer, where he actually writes the code to
implement the design of the proposed application. Due to the various responsibilities that a
system analyst requires to handle, he has to be multifaceted person with varied skills required at
various stages of the life cycle. In addition to the technical know-how of the information system
development a system analyst should also have the following knowledge.
Business knowledge: As the analyst might have to develop any kind of a business system, he
should be familiar with the general functioning of all kind of businesses.
Interpersonal skills: Such skills are required at various stages of development process for
interacting with the users and extracting the requirements out of them
Problem solving skills: A system analyst should have enough problem solving skills for
defining the alternate solutions to the system and also for the problems occurring at the various
stages of the development process.
Defining Requirement:
The basic step for any system analyst is to understand the requirements of the users. This is
achieved by various fact finding techniques like interviewing, observation, questionnaire etc. The
information should be collected in such a way that it will be useful to develop such a system
which can provide additional features to the users apart from the desired.
Prioritizing Requirements:
Number of users uses the system in the organization. Each one has a different requirement and
retrieves different information.
Due to certain limitations in computing capacity it may not be possible to satisfy the needs of all
the users.
Even if the computer capacity is good enough is it necessary to take some tasks and update the
tasks as per the changing requirements.
Hence it is important to create list of priorities according to users requirements. The best way to
overcome the above limitations is to have a common formal or informal discussion with the
users of the system.
This helps the system analyst to arrive at a better conclusion.
Gathering Facts, data and opinions of Users:
After determining the necessary needs and collecting useful information the analyst starts
the development of the system with active cooperation from the users of the system.
Time to time, the users update the analyst with the necessary information for developing
the system.
The analyst while developing the system continuously consults the users and acquires
their views and opinions.
Evaluation and Analysis:
As the analyst maintains continuous he constantly changes and modifies the system to
make it better and more user friendly for the users.
Solving Problems:
The analyst must provide alternate solutions to the management and should a in dept
study of the system to avoid future problems.
The analyst should provide with some flexible alternatives to the management which will
help the manager to pick the system which provides the best solution.
Drawing Specifications:
The analyst must draw certain specifications which will be useful for the manager.
The analyst should lay the specification which can be easily understood by the manager
and they should be purely non-technical.
The specifications must be in detailed and in well presented form.
Role of a System Analyst:
The system analyst role leads and coordinates requirements elicitation and use-case modeling by
outlining the system's functionality and delimiting the system; for example, establishing what
actors and use cases exist, and how they interact.
An information system development can be successful if the role of Systems Analyst is best.
Among several roles, some important roles are described below:
1. Change Agent:
Among all the roles of a system analyst, it is the most wide-ranging and responsible role.
They are also known as the person who serves as a catalyst for change, develops a plan
for change, and works with others facilitating the change. Analyst carefully plans,
monitors and implements change into the user domain because people inherently resist
changes. In the role of a change agent, Systems Analyst may use different approaches to
introduce changes to the user organization.
2. Consultant:
They are an agent to a business. They set as to address Information Systems issues with
in a business. They can give you different perspective. They will also help you to
understand organizational culture from other viewpoints.
3. Intermediary:
The analyst tries to appease all parties involved while implementing a candidate
system. People can improve acceptance of the system through Diplomacy in dealing.
It is the goal of a system analyst to have the support of all the users. He represents
their thinking and tries to achieve the goals through computerization.
4. Architect:
The architect role of a system analyst is a liaison between the user's logical
design requirements and the detailed physical system design. In this role he also
creates a detailed physical design of candidate systems. On the basis of end user
requirements a systems analyst makes the design of information system
architecture. This design becomes the blue print for the programmers.
5. Motivator:
The analyst's role as a motivator becomes obvious during the first few weeks after
implementation and during times when turnover results in new people being trained
to work with the candidate system. As the System acceptance is achieved through user
participation in its development, effective user training and proper motivation to use
the system.
6. Investigator and Monitor:
A systems analyst as an investigator, investigates the existing system to find the
reasons for the failure. His role is to extract the problems from existing systems and
create information structures that uncover previously unknown trends that may have a
direct impact on organization. And as a monitor, to undertake and successfully
complete a project, the analyst must monitor programs in relation to time, cost, and
quality. Of these resources, time is the most important. If time "gets away", the project
suffers from increased costs and wasted human resources. Implementation delays also
mean the system will not be ready on time, which frustrates users and customers
alike.
7. Psychologist:
Since systems are built around people, a System Analyst plays the role of a
psychologist in the way he/she reaches people, interprets their thoughts,
assesses their behavior, and draws conclusions from these interactions. In other words,
understanding inter functional relationships is important.
8. Salesperson:
Selling change can be as crucial as initiating change. Selling the system actually
types place at each step in the system life cycle, however, Sales skills and
persuasiveness, then, are crucial to the success of the system.
9. Politician:
In implementing a candidate system, the analyst tries to appease all parties
involved. Diplomacy and finesse in dealing with people can improve
acceptance of the system. In as much as a politician must have the support of
his/her constituency, so is the analyst's goal to have the support of
the users' staff. He/she represents their thinking and tries to achieve their goals
through computerization.
The First and perhaps most difficult task of systems analyst is problem definition. Business
problems are quite difficult to define. It is also true that problems cannot be solved until they
are precisely and clearly defined.
Initially a systems analyst does not know how to solve a specific problem. He must consult
with managers, users and other data processing professionals in defining problems and
developing solutions. He uses various methods for data gathering to get the correct solution of
a problem.
Having gathered the data relating to a problem, the systems analyst analyses them and thinks
of plan to solve it. He may not come up personally with the best way of solving a problem but
pulls together other people’s ideas and refines them until a workable solution is achieved.
Systems analysts coordinate the process of developing solutions. Since many problems have
number of solutions, the systems analyst must evaluate the merit of such proposed solutions
before recommending one to the management
Systems analysts are often referred to as planners. A key part of the systems analyst’s job is to
develop a plan to meet the management’s objectives.
When the plan has been accepted, systems analyst is responsible for designing it so that
management’s goal could be achieved. Systems design is a time consuming, complex and
precise task.
Systems must be thoroughly tested. The systems analyst often coordinates the testing
procedures and helps in deciding whether or not the new system is meeting standards
established in the planning phase.
UNIT-III
System Analysis:
Written Documents:
The analyst may collect the information/data from written documents available from
manual-files of an organization.
This method of data gathering is normally used if you want to computerize the
existing manual system or upgrade the existing computer based system.
The written documents may be reports, forms, memos, business plans, policy
statements, organizational charts and many others. The written documents provide
valuable information about the existing system.
Interviews:
Interview is another data gathering technique. The analyst (or project team members)
interviews, managers, users/ clients, suppliers, and competitors to collect the information
about the system.
It must be noted that the questions to be asked from them should be precise, relevant and
to the point.
Questionnaires:
Questionnaires are the feedback forms used to collect Information.
The interview technique to collect information is time consuming method, so
Questionnaires are designed to collect information from as many people as we like.
It is very convenient and inexpensive method to collect information but sometimes the
response may be Confusing or unclear and insufficient.
Observations:
In addition to the above-mentioned three techniques to collect information, the analyst (or
his team) may collect Information through observation.
In this collect technique, the working, behavior, and other related information of the
existing system are observed. It means that working of existing system is watched
carefully.
Information Gathering Techniques:
The main aim of fact finding techniques is to determine the information requirements of
an organization used by analysts to prepare a precise SRS understood by user.
Ideal SRS Document should:
be complete, Unambiguous, and Jargon-free.
specify operational, tactical, and strategic information requirements.
solve possible disputes between users and analyst.
use graphical aids which simplify understanding and design.
There are various information gathering techniques:
Interviewing
Systems analyst collects information from individuals or groups by interviewing. The
analyst can be formal, legalistic, play politics, or be informal; as the success of an
interview depends on the skill of analyst as interviewer.
It can be done in two ways:
Unstructured interview: The system analyst conducts question-answer session
to acquire basic information of the system.
Structured interview: It has standard questions which user need to respond in
either close (objective) or open (descriptive) format.
Advantages of Interviewing
This method is frequently the best source of gathering qualitative information.
It is useful for them, who do not communicate effectively in writing or who may not have
the time to complete questionnaire.
Information can easily be validated and cross checked immediately.
It can handle the complex subjects.
It is easy to discover key problem by seeking opinions.
It bridges the gaps in the areas of misunderstandings and minimizes future problems.
Questionnaires
This method is used by analyst to gather information about various issues of system from
large number of persons.
There are two types of questionnaires:
Open-ended Questionnaires: It consists of questions that can be easily and correctly
interpreted. They can explore a problem and lead to a specific direction of answer.
Closed-ended Questionnaires: It consists of questions that are used when the systems analyst
effectively lists all possible responses, which are mutually exclusive.
Advantages of questionnaires
It is very effective in surveying interests, attitudes, feelings, and beliefs of users which
are not co-located.
It is useful in situation to know what proportion of a given group approves or disapproves
of a particular feature of the proposed system.
It is useful to determine the overall opinion before giving any specific direction to the
system project.
It is more reliable and provides high confidentiality of honest responses.
It is appropriate for electing factual information and for statistical data collection which
can be emailed and sent by post.
Structured Analysis is a development method that allows the analyst to understand the
system and its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the
objectives of an existing system and develop a new system specification which can be
easily understandable by user.
It has following attributes:
It is graphic which specifies the presentation of application.
It divides the processes so that it gives a clear picture of system flow.
It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.
It is an approach that works from high-level overviews to lower-level details.
Structured Analysis Tools
During Structured Analysis, various tools and techniques are used for system development. They
are:
Data Flow Diagrams
Data Dictionary
Decision Trees
Decision Tables
Structured English
Types of DFD
DFDs are of two types: Physical DFD and Logical DFD. The following table lists the
points that differentiate a physical DFD from a logical DFD.
Context Diagram
A context diagram helps in understanding the entire system by one DFD which gives the
overview of a system.
It starts with mentioning major processes with little details and then goes onto giving
more details of the processes with the top-down approach.
Data Dictionary:
A data dictionary is a structured repository of data elements in the system. It stores the
descriptions of all DFD data elements that is, details and definitions of data flows, data
stores, data stored in data stores, and the processes.
A data dictionary improves the communication between the analyst and the user. It plays
an important role in building a database.
Most DBMSs have a data dictionary as a standard feature. For example, refer the
following table:
A data dictionary, metadata repository, as defined in the IBM Dictionary of Computing,
is a "centralized repository of information about data such as meaning, relationships to
other data, origin, usage, and format."
The term may have one of several closely related meanings pertaining to databases and
database management systems (DBMS):
a document describing a database or collection of databases
an integral component of a DBMS that is required to determine its structure
a piece of middleware that extends or supplants the native data dictionary of a DBMS.
Database users and application developers can benefit from an authoritative data
dictionary document that catalogs the organization, contents, and conventions of one or
more databases.
This typically includes the names and descriptions of various tables and fields in each
database, plus additional details, like the type and length of each data element.
There is no universal standard as to the level of detail in such a document, but it is
primarily a weak kind of data.
Decision Trees:
Decision trees are a method for defining complex relationships by describing decisions
and avoiding the problems in communication.
A decision tree is a diagram that shows alternative actions and conditions within
horizontal tree framework.
Thus, it depicts which conditions to consider first, second, and so on. Decision trees
depict the relationship of each condition and their permissible actions.
A square node indicates an action and a circle indicates a condition. It forces analysts to
consider the sequence of decisions and identifies the actual decision that must be made.
The major limitation of a decision tree is that it lacks information in its format to describe
what other combinations of conditions you can take for testing. It is a single
representation of the relationships between conditions and actions.
Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise
manner which is easily understandable.
It is useful in situations where the resulting actions depend on the occurrence of one or
several combinations of independent conditions.
It is a matrix containing row or columns for defining a problem and the actions.
Components of a Decision Table
Condition Stub: It is in the upper left quadrant which lists all the condition to be checked.
Action stub: It is in the lower left quadrant which outlines all the action to be carried out to meet
such condition.
Condition Entry: It is in upper right quadrant which provides answers to questions asked in
condition stub quadrant.
Action Entry: It is in lower right quadrant which indicates the appropriate action resulting from
the answers to the conditions in the condition entry quadrant. The entries in decision table are
given by Decision Rules which define the relationships between combinations of conditions and
courses of action. In rules section,
Y shows the existence of a condition.
N represents the condition, which is not satisfied.
A blank - against action states it is to be ignored.
X (or a check mark will do) against action states it is to be carried out.
Structured English
Structure English is derived from structured programming language which gives more
understandable and precise description of process.
It is based on procedural logic that uses construction and imperative sentences designed
to perform operation for action.
It is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions.
It does not have strict syntax rule. It expresses all logic in terms of sequential decision
structures and iterations.
For example, see the following sequence of actions:
UNIT-IV
System Design:
System design is the phase that bridges the gap between problem domain and the
existing system in a manageable way.
This phase focuses on the solution domain, i.e. “how to implement?” It is the phase
where the SRS document is converted into a format that can be implemented and decides
how the system will operate.
In this phase, the complex activity of system development is divided into several smaller
sub-activities, which coordinate with each other to achieve the main objective of system
development.
Systems design is the process or art of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements.
One could see it as the application of systems theory to product development.
There is some overlap with the disciplines of systems analysis, systems architecture and
systems engineering.
Inputs to System Design
System design takes the following inputs:
Statement of work
Requirement determination plan
Current situation analysis
Proposed system requirements including a conceptual data model, modified DFDs, and
Metadata (data about data).
Outputs for System Design
System design gives the following outputs:
Infrastructure and organizational changes for the proposed system.
A data schema, often a relational schema.
Metadata to define the tables/files and columns/data-items.
A function hierarchy diagram or web page map that graphically describes the program
structure.
Actual or pseudocode for each module in the program.
A prototype for the proposed system.
Database :
Types of Databases
Distributed Databases
Homogeneous DDBMS In homogeneous DDBMS, all sites use the same DBMS
product. Much easier to design and manage.
This design provides incremental growth by making additional new sites to DDBMS
easy.
Allows increased performance by exploiting the parallel processing capability of multiple
sites. Heterogeneous DDBMS :
In heterogeneous DDBMS, all sites may run different DBMS products, which need not to
be based on the same underlying data model and so the system may be composed of
RDBMS, ORDBMS and OODBMS products.
In heterogeneous system, communication between different DBMS is required for
translations. In order to provide DBMS transparency, users must be able to make requests
in the language of the DBMS at their local site.
Data from the other sites may have different hardware, different DBMS products and
combination of different hardware and DBMS products.
The task for locating those data and performing any necessary translation are the abilities
of heterogeneous DDBMS.
centralized database.
The following are not a DDBMS : A time sharing computer system. A loosely or tightly
coupled multiprocessor system.
A database which resides at one of the nodes of a network of computers – this is a
centralized database on a network node.
A "centralized DBMS" is a DBMS where all the data within the database is stored on a
single computer, usually the secondary storage device of the computer.
In a centralized DBMS, as the number of transactions executing on the DBMS increases,
performance of the DBMS significantly decreases and becomes a drain on the overall
performance of the computer
Database Normalization, sometimes referred to as canonical synthesis, is a technique for
designing relational database tables to minimize duplication of information and, in so
doing, to safeguard the database against certain types of logical or structural problems,
namely data anomalies.
For example, when multiple instances of a given piece of information occur in a table, the
possibility exists that these instances will not be kept consistent when the data within the
table is updated, leading to a loss of data integrity.
A table that is sufficiently normalized is less vulnerable to problems of this kind, because
its structure reflects the basic assumptions for when multiple instances of the same
information should be represented by a single instance only.
Higher degrees of normalization typically involve more tables and create the need for a
larger number of joins, which can reduce performance.
Accordingly, more highly normalized tables are typically used in database applications
involving many isolated transactions (e.g. an Automated teller machine), while less
normalized tables tend to be used in database applications that need to map complex
relationships between data entities and data attributes (e.g. a reporting application, or a
full-text search application).
Purpose of normalization :
Entity
An entity can be a real-world object, either animate or inanimate, that can be easily
identifiable.
For example, in a school database, students, teachers, classes, and courses offered can be
considered as entities.
All these entities have some attributes or properties that give them their identity.
An entity set is a collection of similar types of entities. An entity set may contain entities
with attribute sharing similar values.
For example, a Students set may contain all the students of a school; likewise a Teachers
set may contain all the teachers of a school from all faculties.
Entity sets need not be disjoint.
Attributes
Entities are represented by means of their properties, called attributes. All attributes
have values.
For example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes.
For example, a student's name cannot be a numeric value. It has to be alphabetic. A
student's age cannot be negative, etc.
Types of Attributes
Simple attribute − Simple attributes are atomic values, which cannot be divided further.
For example, a student's phone number is an atomic value of 10 digits.
Composite attribute − Composite attributes are made of more than one simple attribute.
For example, a student's complete name may have first_name and last_name.
Derived attribute − Derived attributes are the attributes that do not exist in the physical
database, but their values are derived from other attributes present in the database. For
example, average_salary in a department should not be saved directly in the database,
instead it can be derived. For another example, age can be derived from data_of_birth.
Single-value attribute − Single-value attributes contain single value. For example −
Social_Security_Number.
Multi-value attribute − Multi-value attributes may contain more than one values. For
example, a person can have more than one phone number, email_address, etc.
Super Key − A set of attributes (one or more) that collectively identifies an entity in an
entity set.
Candidate Key − A minimal super key is called a candidate key. An entity set may have
more than one candidate key.
Primary Key − A primary key is one of the candidate keys chosen by the database
designer to uniquely identify the entity set.
Relationship
The association among entities is called a relationship. For example, an employee works_at a
department, a student enrolls in a course. Here, Works_at and Enrolls are called relationships.
Relationship Set
A set of relationships of similar type is called a relationship set. Like entities, a relationship too
can have attributes. These attributes are called descriptive attributes.
Degree of Relationship
The number of participating entities in a relationship defines the degree of the relationship.
Binary = degree 2
Ternary = degree 3
n-ary = degree
Mapping Cardinalities
Cardinality defines the number of entities in one entity set, which can be associated with the
number of entities of other set via relationship set.
One-to-one − One entity from entity set A can be associated with at most one entity of
entity set B and vice versa.
One-to-many − One entity from entity set A can be associated with more than one
entities of entity set B however an entity from entity set B, can be associated with at
most one entity.
Many-to-one − More than one entities from entity set A can be associated with at most
one entity of entity set B, however an entity from entity set B can be associated with
more than one entity from entity set A.
Many-to-many − One entity from A can be associated with more than one entity from B
and vice versa.
Let us now learn how the ER Model is represented by means of an ER diagram. Any
object, for example, entities, attributes of an entity, relationship sets, and attributes of
relationship sets, can be represented with the help of an ER diagram.
Entity
Entities are represented by means of rectangles. Rectangles are named with the entity set they
represent.
Attributes
Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle).
If the attributes are composite, they are further divided in a tree like structure. Every node is
then connected to its attribute. That is, composite attributes are represented by ellipses that are
connected with an ellipse.
Multivalued attributes are depicted by double ellipse.
One-to-one − When only one instance of an entity is associated with the relationship, it
is marked as '1:1'. The following image reflects that only one instance of each entity
should be associated with the relationship. It depicts one-to-one relationship.
One-to-many − When more than one instance of an entity is associated with a
relationship, it is marked as '1:N'. The following image reflects that only one instance of
entity on the left and more than one instance of an entity on the right can be associated
with the relationship. It depicts one-to-many relationship.
Many-to-one − When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.
Many-to-many − The following image reflects that more than one instance of an entity
on the left and more than one instance of an entity on the right can be associated with the
relationship. It depicts many-to-many relationship.
Participation Constraints
Total Participation − Each entity is involved in the relationship. Total participation is
represented by double lines.
Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.
Normalization
If a database design is not perfect, it may contain anomalies, which are like a bad dream for any
database administrator. Managing a database with anomalies is next to impossible.
Update anomalies − If data items are scattered and are not linked to each other properly,
then it could lead to strange situations. For example, when we try to update one data
item having its copies scattered over several places, a few instances get updated properly
while a few others are left with old values. Such instances leave the database in an
inconsistent state.
Deletion anomalies − We tried to delete a record, but parts of it was left undeleted
because of unawareness, the data is also saved somewhere else.
Insert anomalies − We tried to insert data in a record that does not exist at all.
Normalization is a method to remove all these anomalies and bring the database to a consistent
state.
Each attribute must contain only a single value from its pre-defined domain.
If we follow second normal form, then every non-prime attribute should be fully functionally
dependent on prime key attribute. That is, if X → A holds, then there should not be any proper
subset Y of X, for which Y → A also holds true.
We see here in Student_Project relation that the prime key attributes are Stu_ID and Proj_ID.
According to the rule, non-key attributes, i.e. Stu_Name and Proj_Name must be dependent
upon both and not on any of the prime key attribute individually. But we find that Stu_Name
can be identified by Stu_ID and Proj_Name can be identified by Proj_ID independently. This is
called partial dependency, which is not allowed in Second Normal Form.
We broke the relation in two as depicted in the above picture. So there exists no partial
dependency.
o X is a superkey or,
o A is prime attribute.
We find that in the above Student_detail relation, Stu_ID is the key and only prime key
attribute. We find that City can be identified by Stu_ID as well as Zip itself. Neither Zip is a
superkey nor is City a prime attribute. Additionally, Stu_ID → Zip → City, so there
exists transitive dependency.
To bring this relation into third normal form, we break the relation into two relations as follows
−
In the above image, Stu_ID is the super-key in the relation Student_Detail and Zip is the super-
key in the relation ZipCodes. So,
and
Zip → City
Input Design
In an information system, input is the raw data that is processed to produce output. During the
input design, the developers must consider the input devices such as PC, MICR, OMR, etc.
Therefore, the quality of system input determines the quality of system output. Welldesigned
input forms and screens have following properties −
It should serve specific purpose effectively such as storing, recording, and retrieving the
information.
It ensures proper completion with accuracy.
It should be easy to fill and straightforward.
It should focus on user’s attention, consistency, and simplicity.
All these objectives are obtained using the knowledge of basic design principles
regarding −
o What are the inputs needed for the system?
o How end users respond to different elements of forms and screens.
Audit trails for data entry and other system operations are created using transaction logs which
gives a record of all changes introduced in the database to provide security and means of
recovery in case of any failure.
Output Design
The design of output is the most important task of any system. During output design, developers
identify the type of outputs needed, and consider the necessary output controls and prototype
report layouts.
To develop output design that serves the intended purpose and eliminates the production
of unwanted output.
To develop the output design that meets the end users requirements.
To deliver the appropriate quantity of output.
To form the output in appropriate format and direct it to the right person.
To make the output available on time for making good decisions.
Some of the external outputs are designed as turnaround outputs, which are implemented as a
form and re-enter the system as an input.
Internal outputs
Internal outputs are present inside the system, and used by end-users and managers. They
support the management in decision making and reporting.
Detailed Reports − They contain present information which has almost no filtering or
restriction generated to assist management planning and control.
Summary Reports − They contain trends and potential problems which are categorized
and summarized that are generated for managers who do not want details.
Exception Reports − They contain exceptions, filtered data to some condition or
standard before presenting it to the manager, as information.
Printed or screen-format reports should include a date/time for report printing and the data.
Multipage reports contain report title or description, and pagination. Pre-printed forms usually
include a version number and effective date.
Forms Design
Both forms and reports are the product of input and output design and are business document
consisting of specified data. The main difference is that forms provide fields for data input but
reports are purely used for reading. For example, order forms, employment and credit
application, etc.
To keep the screen simple by giving proper sequence, information, and clear captions.
To meet the intended purpose by using appropriate forms.
To ensure the completion of form with accuracy.
To keep the forms attractive by using icons, inverse video, or blinking cursors etc.
To facilitate navigation.
Types of Forms
Flat Forms
It is a single copy form prepared manually or by a machine and printed on a paper. For
additional copies of the original, carbon papers are inserted between copies.
It is a simplest and inexpensive form to design, print, and reproduce, which uses less
volume.
These are papers with one-time carbons interleaved into unit sets for either handwritten
or machine use.
Carbons may be either blue or black, standard grade medium intensity. Generally, blue
carbons are best for handwritten forms while black carbons are best for machine use.
These are multiple unit forms joined in a continuous strip with perforations between each
pair of forms.
It is a less expensive method for large volume use.
Code design
•The purpose of code is to make the task easy for identification and retrieval of items of
information when there are several items in the group
•In any computer system , data to be processed have codes so that sorting , retrieving , storing etc
will become efficient
•Data is simplified and standardized . Hence the number of mistakes are reduced to the extent
possible. •Data processing operations can be done easily
• A code is a group of character or digit that identify and describe an item. E.g. pin code number
• Codes are frequently used to describe customer , product , materials or events . Hence
description of items is also needed. generally code number are referred to as key fields on
transaction and records
• Principle of code design – Uniqueness : code for any particular item is unique eg grno of
student – Compactness: the length of code should be as minimum as possible .
However code alone are not sufficent for easy identification and verification eg the codes mand f
for male n female.
– Uniformity: uniform signs and format is highly desirable in mechanized data processing
system.
Expansibility: the code structure should allow growth. Enough room should be provided in the
construction itself for accommodating possible future expansion
Simplicity: the code should be simple to use and easy to understand by each user even with
minimum experience
Clarification : for the user , sorted output data in a predetermined format is valuable although
data must be sorted and collated , it representative code does not need to be in sortable form
Stability: codes should not be updated or modified frequently
UNIT-V
Testing
Testing is the process or activity that checks the functionality and correctness of
software according to specified user requirements in order to improve the quality and
reliability of system.
It is an expensive, time consuming, and critical approach in system development which
requires proper planning of overall testing process.
A successful test is one that finds the errors. It executes the program with explicit
intention of finding error, i.e., making the program fail.
It is a process of evaluating system with an intention of creating a strong system and
mainly focuses on the weak areas of the system or software.
Test Strategy
It is a statement that provides information about the various levels, methods, tools, and
techniques used for testing the system. It should satisfy all the needs of an organization.
Test Plan
It provides a plan for testing the system and verifies that the system under testing fulfils all the
design and functional specifications. The test plan provides the following information
Procedures and standards required for planning and conducting the tests
Test cases are used to uncover as many errors as possible in the system.
A number of test cases are identified for each module of the system to be tested.
Each test case will specify how the implementation of a particular requirement or design
decision is to be tested and the criteria for the success of the test.
The test cases along with the test plan are documented as a part of a system specification
document or in a separate document called test specification or test description.
Test Procedures
It consists of the steps that should be followed to execute each of the test cases. These
procedures are specified in a separate document called test procedure specification. This
document also specifies any special requirements and formats for reporting the result of testing.
Types of Testing
Testing can be of various types and different types of tests are conducted depending on the kind
of bugs one seeks to discover
Unit Testing
Also known as Program Testing, it is a type of testing where the analyst tests or focuses on each
program or module independently. It is carried out with the intention of executing each
statement of the module at least once.
Integration Testing
In Integration Testing, the analyst tests multiple module working together. It is used to find
discrepancies between the system and its original objective, current specifications, and systems
documentation.
Here the analysts are try to find areas where modules have been designed with different
specifications for data length, type, and data element name.
It verifies that file sizes are adequate and that indices have been built properly.
Functional Testing
Function testing determines whether the system is functioning correctly according to its
specifications and relevant standards documentation. Functional testing typically starts with the
implementation of the system, which is very critical for the success of the system.
Positive Functional Testing − It involves testing the system with valid inputs to verify
that the outputs produced are correct.
Negative Functional Testing − It involves testing the software with invalid inputs and
undesired operating conditions.
Quality Assurance
It is the review of system or software products and its documentation for assurance that system
meets the requirements and specifications.
To monitor the software development process and the final software developed.
To ensure whether the software project is implementing the standards and procedures set
by the management.
To notify groups and individuals about the SQA activities and results of these activities.
To ensure that the issues, which are not solved within the software are addressed by the
upper management.
To identify deficiencies in the product, process, or the standards, and fix them.
At this level, offline software is examined or checked for any violations of the official coding
rules. In general, the emphasis is placed on examination of the documentation and level of in-
code comments.
At this level, it is checked that the software can compile and link all official platforms and
operating systems.
At this level, it is checked that the software can run properly under a variety of conditions such
as certain number of events and small and large event sizes etc.
At this final level, it is checked that the performance of the software satisfies the previously
specified performance level.
Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may be just a
routine maintenance tasks as some bug discovered by some user or it may be a large event in
itself based on maintenance size or nature. Following are some types of maintenance based on
their characteristics:
Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software
maintenance found that the cost of maintenance is as high as 67% of the cost of entire software
process cycle.
On an average, the cost of software maintenance is more than 50% of all SDLC phases. There
are various factors, which trigger maintenance cost go high, such as:
Older softwares, which were meant to work on slow machines with less memory and
storage capacity cannot keep themselves challenging against newly coming enhanced
softwares on modern hardware.
Most maintenance engineers are newbie and use trial and error method to rectify
problem.
Often, changes made can easily hurt the original structure of the software, making it hard
for any subsequent changes.
Changes are often left undocumented which may cause more conflicts in future.
Programming Language
Maintenance Activities
IEEE provides a framework for sequential maintenance process activities. It can be used in
iterative manner and can be extended so that customized items and processes can be included.
Training facility is provided if required, in addition to the hard copy of user manual.
Software Re-engineering
When we need to update the software to keep it to the current market, without impacting its
functionality, it is called software re-engineering. It is a thorough process where the design of
software is changed and programs are re-written.
Legacy software cannot keep tuning with the latest technology available in the market. As the
hardware become obsolete, updating of software becomes a headache. Even if software grows
old with time, its functionality does not.
For example, initially Unix was developed in assembly language. When language C came into
existence, Unix was re-engineered in C, because working in assembly language was difficult.
Other than this, sometimes programmers notice that few parts of software need more
maintenance than others and they also need re-engineering.
Re-Engineering Process
Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing, understanding the
existing system. This process can be seen as reverse SDLC model, i.e. we try to get higher
abstraction level by analyzing lower abstraction levels.
An existing system is previously implemented design, about which we know nothing. Designers
then do reverse engineering by looking at the code and try to get the design. With design in
hand, they try to conclude the specifications. Thus, going in reverse from code to system
specification.
Program Restructuring
It is a process to re-structure and re-construct the existing software. It is all about re-arranging
the source code, either in same programming language or from one programming language to a
different one. Restructuring can have either source code-restructuring and data-restructuring or
both.
Re-structuring does not impact the functionality of the software but enhance reliability and
maintainability. Program components, which cause errors very frequently can be changed, or
updated with re-structuring.
The dependability of software on obsolete hardware platform can be removed via re-structuring.
Forward Engineering
Forward engineering is a process of obtaining desired software from the specifications in hand
which were brought down by means of reverse engineering. It assumes that there was some
software engineering already done in the past.
Forward engineering is same as software engineering process with only one difference – it is
carried out always after reverse engineering.
Component reusability
A component is a part of software program code, which executes an independent task in the
system. It can be a small module or sub-system itself.
Example
The login procedures used on the web can be considered as components, printing system in
software can be seen as a component of the software.
Components have high cohesion of functionality and lower rate of coupling, i.e. they work
independently and can perform tasks without depending on other modules.
In OOP, the objects are designed are very specific to their concern and have fewer chances to be
used in some other software.
In modular programming, the modules are coded to perform specific tasks which can be used
across number of other software programs.
There is a whole new vertical, which is based on re-use of software component, and is known as
Component Based Software Engineering (CBSE).
Reuse Process
Two kinds of method can be adopted: either by keeping requirements same and adjusting
components or by keeping components same and modifying requirements.
Requirement Specification - The functional and non-functional requirements are
specified, which a software product must comply to, with the help of existing system,
user input or both.
Design - This is also a standard SDLC process step, where requirements are defined in
terms of software parlance. Basic architecture of system as a whole and its sub-systems
are created.
Specify Components - By studying the software design, the designers segregate the
entire system into smaller components or sub-systems. One complete software design
turns into a collection of a huge set of components working together.
Search Suitable Components - The software component repository is referred by
designers to search for the matching component, on the basis of functionality and
intended software requirements..
Incorporate Components - All matched components are packed together to shape them
as complete software.
Security
System security refers to protecting the system from theft, unauthorized access and
modifications, and accidental or unintentional damage. In computerized systems, security
involves protecting all the parts of computer system which includes data, software, and
hardware. Systems security includes system privacy and system integrity.
System privacy deals with protecting individuals systems from being accessed and used
without the permission/knowledge of the concerned individuals.
System integrity is concerned with the quality and reliability of raw as well as processed
data in the system.
Control Measures
There are variety of control measures which can be broadly classified as follows −
Backup
Regular backup of databases daily/weekly depending on the time criticality and size.
Incremental back up at shorter intervals.
Backup copies kept in safe remote location particularly necessary for disaster recovery.
Duplicate systems run and all transactions mirrored if it is a very critical system and
cannot tolerate any disruption before storing in disk.
Identification of all persons who read or modify data and logging it in a file.
Password system.
Risk Analysis
A risk is the possibility of losing something of value. Risk analysis starts with planning for
secure system by identifying the vulnerability of system and impact of this. The plan is then
made to manage the risk and cope with disaster. It is done to accesses the probability of possible
disaster and their cost.
Risk analysis is a teamwork of experts with different backgrounds like chemicals, human error,
and process equipment.
ETHICS ISSUES
Ethics in System Development With the increase in computer use, problems of dishonest
and unethical issues are also increased.
These problems have tempted the employees to steal the records and sensitive
information.
Computer related crimes, security ethics have a deep impact on the system analysts. Thus
there is a need to produce the operational codes of ethics that helps to gain the good
knowledge, sense and law.
These codes also help to support the privacy conditions against the religious and political
affiliations.
It aware the security safeguards to make the files confidential.
Ethics Codes and Standards of Behavior Development of Standards and codes of
behavior is necessary to concern the ethical behavior of analysts and professionals.
Three associations are most important, these are
1. Data Processing Management Association,
2. The Association for Computing Machinery
3. Institute for Certification of Computer Professionals.
These codes of ethics handle the problems of honesty, competency, and confidentiality.
Unfortunately there are limited associations that punish the code violators.