POINT 4

1. What is structured approach to software development?

The structured approach to software development is characterized by distinct
stages, each stage is completed before the next is commenced, this is necessary as
teams of developers with varying skills and responsibilities.
2. The stages in Program Development / Structured Approach
i.
defining and understanding the problem
ii.
planning and designing
iii.
implementing
iv.
testing and evaluating
v.
maintaining
DEFINING THE PROBLEM
Defining the problem is the most important part of the software development cycle.
If the requirements and the parameters of the problem are clearly understood, then
the actual output of the development program (process) is far more likely to meet
the expected output. The first step in defining a problem is to fully understand the
problem which needs to be solved.
This includes:
i.
ii.
iii.

stating the problem in other terms which give greater meaning to the
problem.
explaining the essential qualities or aspects of the problem
deciding the boundaries of the problem

PLANNING AND DESIGNING

At this stage the structures that will hold the data to be used during processing are
designed. The nature of processing that will occur should be considered at this time.
Well-designed structures can greatly reduce the processing required.
This includes planning the Feasibility Study:
Feasibility Study
A feasibility study is carried out to select the best system that meets performance
requirements.
The main aim of the feasibility study activity is to determine whether it would be
financially and technically feasible to develop the product. The feasibility study
activity involves the analysis of the problem and collection of all relevant
information relating to the product such as the different data items which would be
input to the system, the processing required to be carried out on these data, the
output data required to be produced by the system as well as various constraints on
the behaviour of the system.
B- Budgetary

Economic analysis is the most frequently used technique for evaluating the
effectiveness of a proposed system. More commonly known as Cost / Benefit
analysis, the procedure is to determine the benefits and savings that are expected
from a proposed system and compare them with costs. If benefits outweigh costs, a
decision is taken to design and implement the system. Otherwise, further
justification or alternative in the proposed system will have to be made if it is to
have a chance of being approved. This is an outgoing effort that improves in
accuracy at each phase of the system life cycle.
O- Operational
This is mainly related to human organizational and political aspects. The points to
be considered are:
What changes will be brought with the system?
What organizational structure are disturbed?
What new skills will be required? Do the existing staff members have these skills?
If not, can they be trained in due course of time?
This feasibility study is carried out by a small group of people who are familiar with
information system technique and are skilled in system analysis and design process.
Proposed projects are beneficial only if they can be turned into information system
that will meet the operating requirements of the organization. This test of feasibility
asks if the system will work when it is developed and installed.
T- Technical
This is concerned with specifying equipment and software that will successfully
satisfy the user requirement. The technical needs of the system may vary
considerably, but might include:
The facility to produce outputs in a given time.
Response time under certain conditions.
Ability to process a certain volume of transaction at a particular speed.
Facility to communicate data to distant locations.
In examining technical feasibility, configuration of the system is given more
importance than the actual make of hardware. The configuration should give the
complete picture about the systems requirements:
How many workstations are required, how these units are interconnected so that
they could operate and communicate smoothly.
What speeds of input and output should be achieved at particular quality of
printing.
S- Scheduling
A project will fail if it takes too long to be completed before it is useful. Typically, this
means estimating how long the system will take to develop, and if it can be

completed in a given time period using some methods like payback period.
Schedule feasibility is a measure of how reasonable the project timetable is. Given
our technical expertise, are the project deadlines reasonable? Some projects are
initiated with specific deadlines. It is necessary to determine whether the deadlines
are mandatory or desirable.

IMPLEMENTING
During this stage the solution is coded in a programming language. Programmers
are allocated specific modules to code. They are given system models, the nature
and names of relevant data structures together with algorithms.
TESTING AND EVALUATING
Before the solution can be used it must be thoroughly tested. Large software
development companies have teams of testers whose sole function is to check
products against the original requirements. This stage involves testing for errors in
the code as well as testing the performance of the product under real conditions.
MAINTAINING
Almost all software products have a life span. They are upgraded to include new
functionality and to improve existing functionality. When using the structured
approach each modification is performed using the steps of the program
development cycle. Finally, the modified product is implemented.
CHARACTERISTICS OF STRUCTURED APPROACH
1. Distinct formal phases.
2. Long time periods
i.
Because of the nature of the Structured Approach it takes the longest
time to produce. this is because of the several stages which other
approaches do not have.
3. Large scale projects
i.
The Structured approach is best suited to large scale projects as the
quality required increases with the size of the project
4. Large budgets
i.
A Large Budget is needed as the amount of expertise, equipment and
time required far exceeds the other software development approaches.
INVOLVEMENT OF PERSONNEL IN DEVELOPMENT
1. Analysts
i.
A team of system analysts first collect data from asample of
employees. The analysts meet with management to determine the
workflow and organisational structure of the company. Detailed
recomendations are compiled. Objectives of the new system need to
be determined. They plan for the development of the software.
2. Designers
i.
They design the software and use ideas from the analysts and put
them into practise when creating the software.
3. Programmers

i.

The grunts of the project, programmers work marking the design they
have been given reality.
4. Users as clients
i.
Users compile of the people whom the end product is aimed at. They
often test and report back via forums etc.
5. Management as clients
i.
Management has to manage resources like the allocation of expertise
etc. They must also keep all the steps in the approach in check.
6. Team Approach
i.
AEM coordinates technical assistance from state, federal and local
government programs, as well as the private sector.
PROGRAM CYCLE OF DEVELOPMENT

The waterfall method shows this

SOFTWARE REQUIREMENTS
Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts
with gathering requirements from the user. Analysts and engineers communicate
with the client and end-users to know their ideas on what the software should
provide and which features they want the software to include.
Software Requirement Specification
SRS is a document created by system analyst after the requirements are collected
from various stakeholders.

SRS defines how the intended software will interact with hardware, external
interfaces, speed of operation, response time of system, portability of software
across various platforms, maintainability, speed of recovery after crashing, Security,
Quality, Limitations etc.

The requirements received from client are written in natural language. It is the
responsibility of system analyst to document the requirements in technical
language so that they can be comprehended and useful by the software
development team.
SRS should come up with following features:
1. User Requirements are expressed in natural language.
2. Technical requirements are expressed in structured language, which is used
inside the organization.
3. Design description should be written in Pseudo code.
4. Format of Forms and GUI screen prints.
5. Conditional and mathematical notations for DFDs etc.
Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts
may interpret the requirements incorrectly. This results in huge increase in cost if
not nipped in the bud. Requirements can be checked against following conditions
1.
2.
3.
4.
5.

If
If
If
If
If

they can be practically implemented

they are valid and as per functionality and domain of software
there are any ambiguities
they are complete
they can be demonstrated

Requirement Elicitation Process

Requirements gathering - The developers discuss with the client and end users and
know their expectations from the software.
Organizing Requirements - The developers prioritize and arrange the requirements
in order of importance, urgency and convenience.
Negotiation & discussion - If requirements are ambiguous or there are some
conflicts in requirements of various stakeholders, if they are, it is then negotiated
and discussed with stakeholders. Requirements may then be prioritized and
reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.
Documentation - All formal & informal, functional and non-functional requirements
are documented and made available for next phase processing.
Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended
software system by communicating with client, end users, system users and others
who have a stake in the software system development.
There are various ways to discover requirements

Interviews
Interviews are strong medium to collect requirements. Organization may conduct
several types of interviews such as:

Structured (closed) interviews, where every single information to gather is decided

in advance, they follow pattern and matter of discussion firmly.
Non-structured (open) interviews, where information to gather is not decided in
advance, more flexible and less biased.
Oral interviews
Written interviews
One-to-one interviews which are held between two persons across the table.
Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.
Surveys
Organization may conduct surveys among various stakeholders by querying about
their expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is
handed over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in
the questionnaire, the issue might be left unattended.
Task analysis
Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain
operation, it is studied and requirements of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert people in the domain
can be a great help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.

Prototyping
Prototyping is building user interface without adding detail functionality for user to
interpret the features of intended software product. It helps giving better idea of
requirements. If there is no software installed at clients end for developers
reference and the client is not aware of its own requirements, the developer creates
a prototype based on initially mentioned requirements. The prototype is shown to
the client and the feedback is noted. The client feedback serves as an input for
requirement gathering.
Observation
Team of experts visit the clients organization or workplace. They observe the actual
working of the existing installed systems. They observe the workflow at clients end
and how execution problems are dealt. The team itself draws some conclusions
which aid to form requirements expected from the software.
Data Flow Diagram
Data flow diagram is graphical representation of flow of data in an information
system. It is capable of depicting incoming data flow, outgoing data flow and stored
data. The DFD does not mention anything about how data flows through the
system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts
flow of control in program modules. DFDs depict flow of data in the system at
various levels. DFD does not contain any control or branch elements.
Types of DFD
Data Flow Diagrams are either Logical or Physical.

Logical DFD - This type of DFD concentrates on the system process, and flow
of data in the system. For example in a Banking software system, how data is
moved between different entities.

Physical DFD - This type of DFD shows how the data flow is actually
implemented in the system. It is more specific and close to the
implementation.

DFD Components
DFD can represent Source, destination, storage and flow of data using the following
set of components -

Entities - Entities are source and destination of information data. Entities are
represented by a rectangle with their respective names.

Process - Activities and action taken on the data are represented by Circle or
Round-edged rectangles.

Data Storage - There are two variants of data storage - it can either be
represented as a rectangle with absence of both smaller sides or as an opensided rectangle with only one side missing.

Data Flow - Movement of data is shown by pointed arrows. Data movement is

shown from the base of arrow as its source towards head of the arrow as
destination.

Levels of DFD

Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which

depicts the entire information system as one diagram concealing all the
underlying details. Level 0 DFDs are also known as context level DFDs.

Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD.
Level 1 DFD depicts basic modules in the system and flow of data among
various modules. Level 1 DFD also mentions basic processes and sources of
information.

Level 2 - At this level, DFD shows how data flows inside the modules
mentioned in Level 1.

Higher level DFDs can be transformed into more specific lower level DFDs with
deeper level of understanding unless the desired level of specification is achieved.
Structure Charts
Structure chart is a chart derived from Data Flow Diagram. It represents the system
in more detail than DFD. It breaks down the entire system into lowest functional
modules, describes functions and sub-functions of each module of the system to a
greater detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific
task is performed.
Here are the symbols used in construction of structure charts

Module - It represents process or subroutine or task. A control module

branches to more than one sub-module. Library Modules are re-usable and

invokable from any module.

Condition - It is represented by small diamond at the base of module. It

depicts that control module can select any of sub-routine based on some

condition.

Jump - An arrow is shown pointing inside the module to depict that the control

will jump in the middle of the sub-module.

Loop - A curved arrow represents loop in the module. All sub-modules

covered by loop repeat execution of module.

Data flow - A directed arrow with empty circle at the end represents data

flow.

Control flow - A directed arrow with filled circle at the end represents control

flow.
Data Dictionaries
A data dictionary is a collection of descriptions of the data objects or items in a data
model for the benefit of programmers and others who need to refer to them. A first
step in analyzing a system of objects with which users interact is to identify each
object and its relationship to other objects. This process is called data modeling and
results in a picture of object relationships. After each data object or item is given a
descriptive name, its relationship is described (or it becomes part of some structure
that implicitly describes relationship), the type of data (such as text or image or

binary value) is described, possible predefined values are listed, and a brief textual
description is provided. This collection can be organized for reference into a book
called a data dictionary.
Semantic Data Models (ERD)
ER-modeling is a data modeling technique used in software engineering to produce
a conceptual data model of an information system. Diagrams created using this ERmodeling technique are called Entity-Relationship Diagrams, or ER diagrams or
ERDs. So you can say that Entity Relationship Diagrams illustrate the logical
structure of databases.
Dr. Peter Chen is the originator of the Entity-Relationship Model. His original paper
about ER-modeling is one of the most cited papers in the computer software field.
Currently the ER model serves as the foundation of many system analysis and
design methodologies, computer-aided software engineering (CASE) tools, and
repository systems.
The original notation for ER-Diagrams uses rectangles to represent entities, and
diamonds to represent relationships. Alternative notations include:

Crow's Foot

IDEF1X

There are three basic elements in ER-Diagrams:

Entities are the "things" for which we want to store information. An entity is a
person, place, thing or event.

Attributes are the data we want to collect for an entitiy.

Relationships describe the relations between the entities.

ERDs show entities in a database and relationships between tables within that
database. It is essential to have ER-Diagrams if you want to create a good database
design. The diagrams help focus on how the database actually works.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software
development project. Hence they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:

1. Clear
2. Correct
3. Consistent
4. Coherent
5. Comprehensible
6. Modifiable
7. Verifiable
8. Prioritized
9. Unambiguous
10.Traceable
11.Credible source
Object Modelling
http://www.slideshare.net/guest7fe55d5e/object-modelling-in-softwareengineering
Needs elaboration.
CASE (COMPUTER AIDED SOFTWARE ENGINEERING)
CASE Tools
CASE tools are set of software application programs, which are used to automate
SDLC activities. CASE tools are used by software project managers, analysts and
engineers to develop software system.
There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management
tools, Database Management tools, Documentation tools are to name a few.
Use of CASE tools accelerates the development of project to produce desired result
and helps to uncover flaws before moving ahead with next stage in software
development.
Components of CASE Tools
CASE tools can be broadly divided into the following parts based on their use at a
particular SDLC stage:

Central Repository - CASE tools require a central repository, which can serve
as a source of common, integrated and consistent information. Central
repository is a central place of storage where product specifications,
requirement documents, related reports and diagrams, other useful
information regarding management is stored. Central repository also serves
as data dictionary.

Upper Case Tools - Upper CASE tools are used in planning, analysis and
design stages of SDLC.

Lower Case Tools - Lower CASE tools are used in implementation, testing and
maintenance.

Integrated Case Tools - Integrated CASE tools are helpful in all the stages of
SDLC, from Requirement gathering to Testing and documentation.

CASE tools can be grouped together if they have similar functionality, process
activities and capability of getting integrated with other tools.
Scope of Case Tools
The scope of CASE tools goes throughout the SDLC.
Case Tools Types
Now we briefly go through various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow among
various software components and system structure in a graphical form. For
example, Flow Chart Maker tool for creating state-of-the-art flowcharts.
Process Modeling Tools
Process modeling is method to create software process model, which is used to
develop the software. Process modeling tools help the managers to choose a
process model or modify it as per the requirement of software product. For example,
EPF Composer
Project Management Tools
These tools are used for project planning, cost and effort estimation, project
scheduling and resource planning. Managers have to strictly comply project
execution with every mentioned step in software project management. Project

management tools help in storing and sharing project information in real-time

throughout the organization. For example, Creative Pro Office, Trac Project,
Basecamp.

Documentation Tools
Documentation in a software project starts prior to the software process, goes
throughout all phases of SDLC and after the completion of the project.
Documentation tools generate documents for technical users and end users.
Technical users are mostly in-house professionals of the development team who
refer to system manual, reference manual, training manual, installation manuals
etc. The end user documents describe the functioning and how-to of the system
such as user manual. For example, Doxygen, DrExplain, Adobe RoboHelp for
documentation.
Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For
example, Accept 360, Accompa, CaseComplete for requirement analysis, Visible
Analyst for total analysis.
Design Tools
These tools help software designers to design the block structure of the software,
which may further be broken down in smaller modules using refinement techniques.
These tools provides detailing of each module and interconnections among
modules. For example, Animated Software Design
Configuration Management Tools
An instance of software is released under one version. Configuration Management
tools deal with

Version and revision management

Baseline configuration management

Change control management

CASE tools help in this by automatic tracking, version management and release
management. For example, Fossil, Git, Accu REV.
Change Control Tools
These tools are considered as a part of configuration management tools. They deal
with changes made to the software after its baseline is fixed or when the software is
first released. CASE tools automate change tracking, file management, code
management and more. It also helps in enforcing change policy of the organization.
Programming Tools

These tools consist of programming environments like IDE (Integrated Development

Environment), in-built modules library and simulation tools. These tools provide
comprehensive aid in building software product and include features for simulation
and testing. For example, Cscope to search code in C, Eclipse.
Prototyping Tools
Software prototype is simulated version of the intended software product. Prototype
provides initial look and feel of the product and simulates few aspect of actual
product.
Prototyping CASE tools essentially come with graphical libraries. They can create
hardware independent user interfaces and design. These tools help us to build rapid
prototypes based on existing information. In addition, they provide simulation of
software prototype. For example, Serena prototype composer, Mockup Builder.
Web Development Tools
These tools assist in designing web pages with all allied elements like forms, text,
script, graphic and so on. Web tools also provide live preview of what is being
developed and how will it look after completion. For example, Fontello, Adobe Edge
Inspect, Foundation 3, Brackets.
Quality Assurance Tools
Quality assurance in a software organization is monitoring the engineering process
and methods adopted to develop the software product in order to ensure
conformance of quality as per organization standards. QA tools consist of
configuration and change control tools and software testing tools. For example,
SoapTest, AppsWatch, JMeter.
Maintenance Tools
Software maintenance includes modifications in the software product after it is
delivered. Automatic logging and error reporting techniques, automatic error ticket
generation and root cause Analysis are few CASE tools, which help software
organization in maintenance phase of SDLC. For example, Bugzilla for defect
tracking, HP Quality Center.

Software Requirements
We should try to understand what sort of requirements may arise in the requirement
elicitation phase and what kinds of requirements are expected from the software
system.
Broadly software requirements should be categorized in two categories:
Functional Requirements
Requirements, which are related to functional aspect of software fall into this
category.
They define functions and functionality within and from the software system.

EXAMPLES
1.
2.
3.
4.
5.

Search option given to user to search from various invoices.

User should be able to mail any report to management.
Users can be divided into groups and groups can be given separate rights.
Should comply business rules and administrative functions.
Software is developed keeping downward compatibility intact.

Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this
category. They are implicit or expected characteristics of software, which users
make assumption of.
Non-functional requirements include 1. Security
2. Logging
3. Storage
4. Configuration
5. Performance
6. Cost
7. Interoperability
8. Flexibility
9. Disaster recovery
10.Accessibility
Requirements are categorized logically as
Must Have : Software cannot be said operational without them.
Should have : Enhancing the functionality of software.
Could have : Software can still properly function with these requirements.
Wish list : These requirements do not map to any objectives of software.
While developing software, Must have must be implemented, Should have is a
matter of debate with stakeholders and negation, whereas could have and wish
list can be kept for software updates.
User Interface requirements
UI is an important part of any software or hardware or hybrid system. A software is
widely accepted if it is 1.
2.
3.
4.

easy to operate
quick in response
effectively handling operational errors
providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the
only way for users to perceive the system. A well performing software system must
also be equipped with attractive, clear, consistent and responsive user interface.
Otherwise the functionalities of software system can not be used in convenient way.

A system is said be good if it provides means to use it efficiently. User interface

requirements are briefly mentioned below 1. Content presentation
2. Easy Navigation
3. Simple interface
4. Responsive
5. Consistent UI elements
6. Feedback mechanism
7. Default settings
8. Purposeful layout
9. Strategical use of color and texture.
10.Provide help information
11.User centric approach
12.Group based view settings.