Physical and Conceptual Models of organization

Data modeling in software engineering is the process of creating a data model by applying
formal data model descriptions using data modeling techniques.
Data modeling is a method used to define and analyze data requirements needed to support the
business processes of an organization. The data requirements are recorded as a conceptual data
model with associated data definitions. Actual implementation of the conceptual model is called
a logical data model. To implement one conceptual data model may require multiple logical data
models. Data modeling defines not just data elements, but their structures and relationships
between them [2] Data modeling techniques and methodologies are used to model data in a
standard, consistent, predictable manner in order to manage it as a resource. The use of data
modeling standards is strongly recommended for all projects requiring a standard means of
defining and analyzing data within an organization, eg using data modeling:

to manage data as a resource;

for the integration of information systems;

for designing databases/data warehouses (aka data repositories)

Data modeling may be performed during various types of projects and in multiple phases of
projects. Data models are progressive; there is no such thing as the final data model for a
business or application. Instead a data model should be considered a living document that will
change in response to a changing business. The data models should ideally be stored in a
repository so that they can be retrieved, expanded, and edited over time. Whitten (2004)
determined two types of data modeling:[3]

Strategic data modeling: This is part of the creation of an information systems strategy,
which defines an overall vision and architecture for information systems is defined.
Information engineering is a methodology that embraces this approach.
Data modeling during systems analysis: In systems analysis logical data models are
created as part of the development of new databases.

Data modeling is also a technique for detailing business requirements for a database. It is
sometimes called database modeling because a data model is eventually implemented in a
database.

Data models

How data models deliver benefit.support data and computer systems by providing the definition
and format of data. If this is done consistently across systems then compatibility of data can be
achieved. If the same data structures are used to store and access data then different applications
can share data. The results of this are indicated above. However, systems and interfaces often
cost more than they should, to build, operate, and maintain. They may also constrain the business
rather than support it. A major cause is that the quality of the data models implemented in
systems and interfaces is poor.[1]
Business rules, specific to how things are done in a particular place, are often fixed in the
structure of a data model. This means that small changes in the way business is conducted
lead to large changes in computer systems and interfaces.
Entity types are often not identified, or incorrectly identified. This can lead to replication
of data, data structure, and functionality, together with the attendant costs of that
duplication in development and maintenance.

Data models for different systems are arbitrarily different. The result of this is that
complex interfaces are required between systems that share data. These interfaces can
account for between 25-70% of the cost of current systems.

Data cannot be shared electronically with customers and suppliers, because the structure
and meaning of data has not been standardized. For example, engineering design data and
drawings for process plant are still sometimes exchanged on paper.

The reason for these problems is a lack of standards that will ensure that data models will both
meet business needs and be consistent

Data modeling process

Data modeling in the context of Business Process Integration.[5]

In the context of Business Process Integration, see figure, data modeling will result in database
generation. It complements business process modeling, which results in application programs to
support the business processes.[5]
The actual database design is the process of producing a detailed data model of a database. This
logical data model contains all the needed logical and physical design choices and physical
storage parameters needed to generate a design in a Data Definition Language, which can then be
used to create a database. A fully attributed data model contains detailed attributes for each
entity. The term database design can be used to describe many different parts of the design of an
overall database system. Principally, and most correctly, it can be thought of as the logical design
of the base data structures used to store the data. In the relational model these are the tables and
views. In an Object database the entities and relationships map directly to object classes and
named relationships. However, the term database design could also be used to apply to the
overall process of designing, not just the base data structures, but also the forms and queries used
as part of the overall database application within the Database Management System or DBMS.
In the process system interfaces account for 25% to 70% of the development and support costs of
current systems. The primary reason for this cost is that these systems do not share a common
data model. If data models are developed on a system by system basis, then not only is the same
analysis repeated in overlapping areas, but further analysis must be performed to create the
interfaces between them. Most systems contain the same basic components, redeveloped for a
specific purpose. For instance the following can use the same basic classification model as a
component:[1]

Materials Catalogue,
Product and Brand Specifications,

Equipment specifications.

The same components are redeveloped because we have no way of telling they are the same
thing.

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems
engineering and software engineering, is the process of creating or altering systems, and the
models and methodologies that people use to develop these systems. The concept generally
refers to computer or information systems.
In software engineering the SDLC concept underpins many kinds of software development
methodologies. These methodologies form the framework for planning and controlling the
creation of an information system[1]: the software development process.

Overview
Systems Development Life Cycle (SDLC) is a logical process used by a systems analyst to
develop an information system, including requirements, validation, training, and user
(stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds
customer expectations, reaches completion within time and cost estimates, works effectively and
efficiently in the current and planned Information Technology infrastructure, and is inexpensive
to maintain and cost-effective to enhance.[2]
Computer systems are complex and often (especially with the recent rise of Service-Oriented
Architecture) link multiple traditional systems potentially supplied by different software vendors.
To manage this level of complexity, a number of systems development life cycle (SDLC) models
have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping";
"incremental"; and "synchronize and stabilize".[citation needed]

SDLC models can be described along a spectrum of agile to iterative to sequential. Agile
methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid
changes along the development cycle. Iterative methodologies, such as Rational Unified Process
and Dynamic Systems Development Method, focus on limited project scopes and expanding or
improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models,
such as Waterfall, focus on complete and correct planning to guide large projects and risks to
successful and predictable results.
Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional"
processes; however, SDLC is an umbrella term for all methodologies for the design,
implementation, and release of software.[3][4]
In project management a project can be defined both with a project life cycle (PLC) and an
SDLC, during which slightly different activities occur. According to Taylor (2004) "the project
life cycle encompasses all the activities of the project, while the systems development life cycle
focuses on realizing the product requirements".[5]

Systems development phases

Systems Development Life Cycle (SDLC) adheres to important phases that are essential for
developers, such as planning, analysis, design, and implementation, and are explained in the
section below. There are several Systems Development Life Cycle Models in existence. The
oldest model, that was originally regarded as "the Systems Development Life Cycle" is the
waterfall model: a sequence of stages in which the output of each stage becomes the input for the
next. These stages generally follow the same basic steps but many different waterfall
methodologies give the steps different names and the number of steps seem to vary between 4
and 7. There is no definitively correct Systems Development Life Cycle model, but the steps can
be characterized and divided in several steps.

PROTOTYPE APPROACH

Overview
The process of prototyping involves the following steps
1. Identify basic requirements
Determine basic requirements including the input and output information
desired. Details, such as security, can typically be ignored.
2. Develop Initial Prototype
The initial prototype is developed that includes only user interfaces. (See
Horizontal Protype, below)
3. Review
The customers, including end-users, examine the prototype and provide
feedback on additions or changes.
4. Revise and Enhance the Prototype

Using the feedback both the specifications and the prototype can be
improved. Negotiation about what is within the scope of the contract/product
may be necessary. If changes are introduced then a repeat of steps #3 ands
#4 may be needed.

Dimensions of prototypes
Nielsen summarizes the various dimensions of prototypes in his book Usability Engineering

Horizontal Prototype
A common term for a user interface prototype is the horizontal prototype. It provides a broad
view of an entire system or subsystem, focusing on user interaction more than low-level system
functionality, such as database access. Horizontal prototypes are useful for:

Confirmation of user interface requirements and system scope

Demonstration version of the system to obtain buy-in from the business

Develop preliminary estimates of development time and cost

Vertical Prototype
A vertical prototype is a more complete elaboration of a single subsystem or function. It is
useful for obtaining detailed requirements for a given function, with the following benefits:

Refinement database design

Obtain information on data volumes and system interface needs, for network
sizing and performance engineering

Clarifies complex requirements by drilling down to actual system functionality

Advantages of prototyping
There are many advantages to using prototyping in software development some tangible, some
abstract.[11]
Reduced time and costs: Prototyping can improve the quality of requirements and specifications
provided to developers. Because changes cost exponentially more to implement as they are
detected later in development, the early determination of what the user really wants can result in
faster and less expensive software.[8]
Improved and increased user involvement: Prototyping requires user involvement and allows
them to see and interact with a prototype allowing them to provide better and more complete
feedback and specifications.[7] The presence of the prototype being examined by the user
prevents many misunderstandings and miscommunications that occur when each side believe the
other understands what they said. Since users know the problem domain better than anyone on

the development team does, increased interaction can result in final product that has greater
tangible and intangible quality. The final product is more likely to satisfy the users desire for
look, feel and performance

Disadvantages of prototyping
Using, or perhaps misusing, prototyping can also have disadvantages.[11]
Insufficient analysis: The focus on a limited prototype can distract developers from properly
analyzing the complete project. This can lead to overlooking better solutions, preparation of
incomplete specifications or the conversion of limited prototypes into poorly engineered final
projects that are hard to maintain. Further, since a prototype is limited in functionality it may not
scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if
developers are too focused on building a prototype as a model.
User confusion of prototype and finished system: Users can begin to think that a prototype,
intended to be thrown away, is actually a final system that merely needs to be finished or
polished. (They are, for example, often unaware of the effort needed to add error-checking and
security features which a prototype may not have.) This can lead them to expect the prototype to
accurately model the performance of the final system when this is not the intent of the
developers. Users can also become attached to features that were included in a prototype for
consideration and then removed from the specification for a final system. If users are able to
require all proposed features be included in the final system this can lead to conflict.
Developer misunderstanding of user objectives: Developers may assume that users share their
objectives (e.g. to deliver core functionality on time and within budget), without understanding
wider commercial issues. For example, user representatives attending Enterprise software (e.g.
PeopleSoft) events may have seen demonstrations of "transaction auditing" (where changes are
logged and displayed in a difference grid view) without being told that this feature demands
additional coding and often requires more hardware to handle extra database accesses. Users
might believe they can demand auditing on every field, whereas developers might think this is
feature creep because they have made assumptions about the extent of user requirements. If the
solution provider has committed delivery before the user requirements were reviewed,
developers are between a rock and a hard place, particularly if user management derives some
advantage from their failure to implement requirements.
Developer attachment to prototype: Developers can also become attached to prototypes they
have spent a great deal of effort producing; this can lead to problems like attempting to convert a
limited prototype into a final system when it does not have an appropriate underlying
architecture. (This may suggest that throwaway prototyping, rather than evolutionary
prototyping, should be used.)
Excessive development time of the prototype: A key property to prototyping is the fact that it is
supposed to be done quickly. If the developers lose sight of this fact, they very well may try to
develop a prototype that is too complex. When the prototype is thrown away the precisely
developed requirements that it provides may not yield a sufficient increase in productivity to
make up for the time spent developing the prototype. Users can become stuck in debates over
details of the prototype, holding up the development team and delaying the final product.

Expense of implementing prototyping: the start up costs for building a development team
focused on prototyping may be high. Many companies have development methodologies in
place, and changing them can mean retraining, retooling, or both. Many companies tend to just
jump into the prototyping without bothering to retrain their workers as much as they should.
A common problem with adopting prototyping technology is high expectations for
productivity with insufficient effort behind the learning curve. In addition to training for
the use of a prototyping technique, there is an often overlooked need for developing
corporate and project specific underlying structure to support the technology. When this
underlying structure is omitted, lower productivity can often result.

INTRODUCTION
Systems are created to solve problems. One can think of the systems approach as an organized
way of dealing with a problem. In this dynamic world, The subject System Analysis and Design,
mainly deals with the software development activities.
29.2 OBJECTIVES
After going through this lesson, you should be able to:

understand a system
understand the different phases of system developments life cycle

know the components of system analysis

know the components of system designing

29.3 Defining A System

A collection of components that work together to realize some objective forms a system.
Basically there are three major components in every system, namely input, processing and
output.

In a system the different components are connected with each other and they are interdependent.
For example, Human body represents a complete natural system. We are also bound by many
national systems such as political system, economic system, educational system and so forth. The

objective of the system demand that some output is produced as a result of processing the
suitable inputs.
29.4 SYSTEM LIFE CYCLE
System life cycle is an organisational process of developing and maintaining systems. It helps in
establishing a system project plan, because it gives overall list of processes and sub-processes
required developing a system.
System development life cycle means combination of various activities. In other words we can
say that various activities put together are referred as system development life cycle. In the
System Analysis and Design terminology, the system development life cycle means software
development life cycle.
Following are the different phases of software development cycle:

System study
Feasibility study

System analysis

System design

Coding

Testing

Implementation

Maintenance

The different phases of software development life cycle is shown in Fig.29.1

Fig. 29.1 Different phases of Software development Life Cycle

29.5 PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE

Let us now describe the different phases and the related activities of system development life
cycle in detail.
(a) System Study
System study is the first stage of system development life cycle. This gives a clear picture of
what actually the physical system is? In practice, the system study is done in two phases. In the
first phase, the preliminary survey of the system is done which helps in identifying the scope of
the system. The second phase of the system study is more detailed and in-depth study in which
the identification of users requirement and the limitations and problems of the present system
are studied. After completing the system study, a system proposal is prepared by the System
Analyst (who studies the system) and placed before the user. The proposed system contains the
findings of the present system and recommendations to overcome the limitations and problems
of the present system in the light of the users requirements.
To describe the system study phase more analytically, we would say that system study phase
passes through the following steps:

problem identification and project initiation

background analysis

inference or findings

(b) Feasibility Study

On the basis of result of the initial study, feasibility study takes place. The feasibility study is
basically the test of the proposed system in the light of its workability, meeting users
requirements, effective use of resources and .of course, the cost effectiveness. The main goal of
feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility
study, the cost and benefits are estimated with greater accuracy.
(c) System Analysis
Assuming that a new system is to be developed, the next phase is system analysis. Analysis
involved a detailed study of the current system, leading to specifications of a new system.
Analysis is a detailed study of various operations performed by a system and their relationships
within and outside the system. During analysis, data are collected on the available files, decision
points and transactions handled by the present system. Interviews, on-site observation and
questionnaire are the tools used for system analysis. Using the following steps it becomes easy to
draw the exact boundary of the new system under consideration:

Keeping in view the problems and new requirements

Workout the pros and cons including new areas of the system

All procedures, requirements must be analysed and documented in the form of detailed data flow
diagrams (DFDs), data dictionary, logical data structures and miniature specifications. System
Analysis also includes sub-dividing of complex process involving the entire system,
identification of data store and manual processes.

The main points to be discussed in system analysis are:

Specification of what the new system is to accomplish based on the user requirements.
Functional hierarchy showing the functions to be performed by the new system and their
relationship with each other.

Function network which are similar to function hierarchy but they highlight the those
functions which are common to more than one procedure.

List of attributes of the entities - these are the data items which need to be held about
each entity (record)

(d) System Design

Based on the user requirements and the detailed analysis of a new system, the new system must
be designed. This is the phase of system designing. It is a most crucial phase in the development
of a system. Normally, the design proceeds in two stages :

preliminary or general design

Structure or detailed design

Preliminary or general design: In the preliminary or general design, the features of the new
system are specified. The costs of implementing these features and the benefits to be derived are
estimated. If the project is still considered to be feasible, we move to the detailed design stage.
Structure or Detailed design: In the detailed design stage, computer oriented work begins in
earnest. At this stage, the design of the system becomes more structured. Structure design is a
blue print of a computer system solution to a given problem having the same components and
inter-relationship among the same components as the original problem. Input, output and
processing specifications are drawn up in detail. In the design stage, the programming language
and the platform in which the new system will run are also decided.
There are several tools and techniques used for designing. These tools and techniques are:

Flowchart
Data flow diagram (DFDs)

Data dictionary

Structured English

Decision table

Decision tree

Each of the above tools for designing will be discussed in detailed in the next lesson.
(e) Coding
After designing the new system, the whole system is required to be converted into computer
understanding language. Coding the new system into computer programming language does this.
It is an important stage where the defined procedure are transformed into control specifications

by the help of a computer language. This is also called the programming phase in which the
programmer converts the program specifications into computer instructions, which we refer as
programs. The programs coordinate the data movements and control the entire process in a
system.
It is generally felt that the programs must be modular in nature. This helps in fast development,
maintenance and future change, if required.
(f) Testing
Before actually implementing the new system into operations, a test run of the system is done
removing all the bugs, if any. It is an important phase of a successful system. After codifying the
whole programs of the system, a test plan should be developed and run on a given set of test
data. The output of the test run should match the expected results.
Using the test data following test run are carried out:

Unit test
System test

Unit test: When the programs have been coded and compiled and brought to working conditions,
they must be individually tested with the prepared test data. Any undesirable happening must be
noted and debugged (error corrections).
System Test: After carrying out the unit test for each of the programs of the system and when
errors are removed, then system test is done. At this stage the test is done on actual data. The
complete system is executed on the actual data. At each stage of the execution, the results or
output of the system is analysed. During the result analysis, it may be found that the outputs are
not matching the expected out of the system. In such case, the errors in the particular programs
are identified and are fixed and further tested for the expected output.
When it is ensured that the system is running error-free, the users are called with their own actual
data so that the system could be shown running as per their requirements.
(g) Implementation
After having the user acceptance of the new system developed, the implementation phase begins.
Implementation is the stage of a project during which theory is turned into practice. During this
phase, all the programs of the system are loaded onto the user's computer. After loading the
system, training of the users starts. Main topics of such type of training are:

How to execute the package

How to enter the data

How to process the data (processing details)

How to take out the reports

After the users are trained about the computerised system, manual working has to shift from
manual to computerised working. The following two strategies are followed for running the
system:

i.

Parallel run: In such run for a certain defined period, both the systems i.e. computerised
and manual are executed in parallel. This strategy is helpful because of the following:

i.

Manual results can be compared with the results of the computerised system.

Failure of the computerised system at the early stage, does not affect the working
of the organisation, because the manual system continues to work, as it used to do.

Pilot run: In this type of run, the new system is installed in parts. Some part of the new
system is installed first and executed successfully for considerable time period. When the
results are found satisfactory then only other parts are implemented. This strategy builds
the confidence and the errors are traced easily.

(h) Maintenance
Maintenance is necessary to eliminate errors in the system during its working life and to tune the
system to any variations in its working environment. It has been seen that there are always some
errors found in the system that must be noted and corrected. It also means the review of the
system from time to time. The review of the system is done for:

knowing the full capabilities of the system

knowing the required changes or the additional requirements

studying the performance