MODULE 1

S2 : SOFTWARE DESIGN & PROJECT MANGEMENT

Entity
An entity is something that has a distinct, separate existence, although it need not be a material
existence. Entities are used in system developmental models that display communications and
internal processing of, say, documents compared to order processing.

An entity may be defined as a thing which is recognized as being capable of an independent

existence and which can be uniquely identified. An entity may be a physical object such as a
house or a car, an event such as a house sale or a car service, , Entities can be thought of as
nouns. Examples: a computer, an employee, a song, a mathematical theorem.

Relationship

A relationship captures how two or more entities are related to one another. Relationships can be
thought of as verbs, linking two or more nouns. Examples: an owns relationship between a
company and a computer, a supervises relationship between an employee and a department, a
performs relationship between an artist and a song, a proved relationship between a
mathematician and a theorem.

E-R Diagram
Generally E-R Diagrams require the use of the following symbols:

There are three basic elements in ER models:

Entities are the "things" about which we seek
information.

Attributes are the data we collect about the entities.

Relationships provide the structure needed to draw

information from multiple entities.

DATA FLOW DIAGRAM (DFD) concepts

A Data Flow Diagram (DFD) is a diagrammatic representation of the information flows within a
system, showing:

 how information enters and leaves the system,

 what changes the information,
 where information is stored.

The figure below shows the simplest data flow diagram.

The figure above shows a top-level description of a system specification. The system as a whole
is viewed as one process. The input and output to the system at this level of abstraction is from
the environment. In the above figure there is a single external entity (source) which sends data
(input) to the system, and a single external entity (sink) which receives data from the system
(output). This is commonly known as a ‘context diagram’, or a 0-level DFD.

Advantages of DFDs

 a simple but powerful graphic technique which is easily understood.

 represents an information system from the viewpoint of data movements, which includes
the inputs and outputs to which people can readily relate.
 the ability to represent the system at different levels of details gives added advantage
(you can include the advantages of decomposition listed earlier)
 helps to define the boundaries of the system.
  a useful tool to use during interviews.
 serve to identify the information services the users require, on the basis of which the
future information system will be constructed.

Entity Life histories (ELH).

An Entity Life History (ELH) diagram represents the life cycle of entities within the database.An
Entity Life History diagram is used to show the sequencing, iteration or timing of an entity. For
example take a supporter of a charity for example. A supporter is an Entity within a charity and
therefore real world events cans happen to this supporter such as change of address. Where as
and Entity relationship Model (ERM) shows the link between supporters and cash, an Entity Life
History diagram shows the events that take place on an entity such as a supporter.

The above diagram shows the events of a Supporter. From the diagram one can easily see that a
supporter record is created once a supporter makes a donation and can only be deleted after
7years have lapsed from the death of a supporter. This type of information can easily be missed
out is other structured models. An ELH model should be created for each entity on the ERM. If
an event is repeated, place a small asterisk (*) in its upper right hand corner.
EXAMPLE-2

Modular Programming

Modular programming can be used to break up a large program into manageable units, or to
create code that can be easily re-used.  A modular program consists of a main module and one or
more auxiliary modules.

Modular programming is a software design technique that increases the extent to which
software is composed of separate, interchangeable components, called modules. Conceptually,
modules represent a separation of concerns, and improve maintainability by enforcing logical
boundaries between components. Modules are typically incorporated into the program through
interfaces. A module interface expresses the elements that are provided and required by the
module.
The value of this approach is finally filtering down to the level of individual applications.
Applications are getting more and more complicated, and they are increasingly assembled from
pieces developed independently. Modular coding enables you to achieve and manage that
complexity. Since applications are growing in size and functionality, it is necessary to separate
them into individual pieces (whether as“components,” “modules,” or “plugins”). Each such
separated piece then becomes one element of the modular architecture. Each piece should be
isolated and should export and import well-defined interfaces. Splitting an application into
modules has benefits for software quality

Details of SDLC approach

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle ,is the
process of creating or altering systems, and the models and methodologies that people use to
develop these systems.

Systems and Development Life Cycle (SDLC) is a 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.

The Traditional SDLC Phases or Stages:

1. Project feasibility study: Under this phase the software analysts and strategy makers
establish a descriptive view of the intended project and determine its goals & objectives.

2. Requirement specifications: Under this phase analysts refines project goals into defined
functions and operation of the intended software application.

3. System analysis: Under this phase analysts analyze the end-user information needs and
prepare a solid plan. The goal of system analysis is to determine where the problem is in
an attempt to fix the system. This step involves breaking down the system in different
pieces to analyze the situation, analyzing project goals, breaking down what needs to be
created and attempting to engage users so that definite requirements can be defined

4. Systems design: Now the software development team describes desired features,
functionalities and operations in detail, including SDLC process & screen layouts,
business rules & standards, process diagrams & DFD, pseudo-code and related
documentation.

5. Implementation/ coding/ development: Under this phase the actual code is written.
They divide the work in distributed fashion and assign it to the particular specialized
team member. This stage is intermingled with the next in that individual modules will
need testing before integration to the main project.

6. Integration and Software testing: Under this phase developers integrate all the modules
together into a single system for special testing cases and maintenance to check errors,
bugs and interoperability as per standard testing methods.

7. Acceptance, installation, deployment: This is the final stage of SDLC life cycle. The
development team puts the compiled software onto end-user unit or interface and runs
targeted business.
8. Maintenance: Under this phase or stage any changes, correction, additions, inter
platform movement or say migration and porting and many more. It is the least
glamorous and perhaps most important step of all, goes forever during whole system life.