MT 413

IT Enabled Business Intelligence

Module I
 Intelligent Information System
Development Concepts

• System Development Life Cycle

• Stages in SDLC
• System Development Life Cycle models
Waterfall model, Spiral model and Iterative model
• Concepts of Artificial Intelligence
• Artificial Intelligence vs Natural Intelligence
Applications
 What is a System?
• The word System is derived from Greek word Systema
• It means an organized relationship between any set of components to achieve
some common cause or objective
Definition:
• A system is “an orderly grouping of interdependent components linked
together according to a plan to achieve a specific goal.”
Implications:
1) A system must be designed to achieve a predetermined objective
2) Interrelationships and interdependence must exist among the components
3) The objectives of the whole have a higher priority than the objectives of its
subsystems
 Types of Systems
• Physical or Abstract Systems
• Open or Closed Systems
• Adaptive and Non-Adaptive System
• Permanent or Temporary System
• Natural and Manufactured System
• Deterministic or Probabilistic System
• Social, Human-Machine, Machine System
• Man–Made Information Systems
Formal Information System 
Informal Information System 
Computer Based System 
 System Analysis
• System analysis helps in discovering means to design systems where sub-
system may have apparently conflicting objectives
• It helps in achieving inter compatibility and unity of purpose of sub-systems
• It offers a means to create understanding of the complex structures

• It helps in placing each sub-system in its proper perspective and context, so

that the system as a whole may best achieve its objectives with minimum
available resources

• Creates synchronization between systems and objectives

 System Development Life
Cycle(SDLC)
• System Development Life Cycle (SDLC) is a conceptual model which
includes policies and procedures for developing or altering systems
throughout their life cycles
• 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
- works effectively and efficiently in the current and planned
Information Technology infrastructure
 Activities in SDLC

 requirements
 design
 implementation
 testing
 deployment
 operations
 maintenance
Phases of SDLC
 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, analyse, 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
 What is SRS?
• A document that describes what the software will do
• how it will be expected to perform
• Describes the functionality the product needs to fulfill all
stakeholders (business, users) needs
• A formal report, which acts as a representation of software
• This enables the customers to review whether it is according to their
requirements
 Software Requirement
Specification (Qualities)
1) Correctness
2) Completeness
3) Consistency
4) Unambiguousness
5) Ranking for importance & Stability
6) Modifiability
7) Verifiability
8) Traceability
9) Design Independence
10) Testable
11) Understandable by the customer
12) Right level of abstraction
 Correctness, Completeness, Consistency

1) Correctness: 
User review is used to ensure the correctness of requirements stated in the SRS.
SRS is said to be correct if it covers all the requirements that are actually
expected from the system.  
2) Completeness: 
Completeness of SRS indicates every sense of completion including the
numbering of all the pages, resolving all the crucial parts to as much extent as
possible as well as covering all the functional and non-functional requirements
properly.  
3) Consistency: 
Requirements in SRS are said to be consistent if there are no conflicts between
any set of requirements. Examples of conflict include differences in terminologies
used at separate places, logical conflicts like time period of report generation,
etc. 
 Unambiguousness, Ranking, Modifiability
4) Unambiguousness: 
A SRS is said to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the
use of modelling techniques like ER diagrams, proper reviews and buddy
checks, etc.  
5) Ranking for importance and stability: 
There should be criterion to classify the requirements as less or more
important or more specifically as desirable or essential. An identifier mark
can be used with every requirement to indicate its rank or stability.  
6) Modifiability: 
SRS should be made as modifiable as possible and should be capable of
easily accepting changes to the system to some extent. Modifications
should be properly indexed and cross-referenced. 
 Verifiability, Traceability, Design Independence

7) Verifiability: 
A SRS is verifiable if there exists a specific technique to quantifiably
measure the extent to which every requirement is met by the system.
For example, a requirement starting that the system must be user-
friendly is not verifiable and listing such requirements should be
avoided.  
8) Traceability: 
One should be able to trace a requirement to design component and
then to code segment in the program. Similarly, one should be able to
trace a requirement to the corresponding test cases.  
9) Design Independence: 
There should be an option to choose from multiple design
alternatives for the final system. More specifically, the SRS should not
include any implementation details. 
Testability, Understandable, Right abstraction
10) Testability: 
A SRS should be written in such a way that it is easy to generate test
cases and test plans from the document.  
11) Understandable by the customer: 
An end user maybe an expert in his/her specific domain but might not
be an expert in computer science. Hence, the use of formal notations
and symbols should be avoided to as much extent as possible. The
language should be kept easy and clear.  
12) Right level of abstraction: 
If the SRS is written for the requirements phase, the details should be
explained explicitly. Whereas, for a feasibility study, fewer details can
be used. Hence, the level of abstraction varies according to the
purpose of the SRS. 
 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.
SDLC Diagram
 Models of SDLC
• Classical Waterfall Model
• Iterative Waterfall Model
• Spiral Model
• V-Model
• Prototyping Model
• Incremental Development Model
• Evolutionary Model
• Rapid Application Development (RAD)
• Agile Development Models
 Classical Waterfall Model
• Simple, basic but idealistic not a practical model
• A theoretical way of developing software
• Other models are refinement of this model
• Not used in practical software development yet gives the
fundamental knowledge
• Divides the life cycle into six phases: 1) feasibility study,
2)requirements analysis & specifications, 3) design, 4) coding & unit
testing, 5) integration & system testing and 6) maintenance
• Resembles a multi-level waterfall
Waterfall Model
 Feasibility Study
• Aim: Financially & technically viable or not
• Activities: Analysis of problem, collection of relevant information
related to input , processing & output of data, the processing
required to carry out the data by the desired system and various
probable constraints
• Outcome of Feasibility Study: 1) A rough description of the problem
2) Formulation of the different solution strategies 3) Analysis of
alternative solution strategies to compare their benefits &
shortcomings
 Requirements Analysis &
Specification
• 1) Requirements gathering and analysis
• 2) Requirements Specifications
• Requirements gathering: Thru interviews & discussions, all relevant
information about the product, with no inconsistency & incompleteness
• Requirements Specifications: SRS document : Components are functional
& non-functional activities
• SRS is written using the end-user terminology which serves as a contract
with the customer
• SRS is known as black-box specification, external behaviour is known
only without knowing the internal details
 Design
• Transforms the requirements of SRS into a structure that is suitable
for implementation in some programming languages
• Software architecture is derived
• Traditional approaches like Procedure Oriented, Object Oriented or
any other latest programming paradigms are considered
 Coding & Unit Testing
• Software design is translated to source code
• Each component is implemented as program module
• End-product is a set of program modules
• Each module is tested individually
 Integration & System Testing
• Modules are integrated in a planned way
• Carried out incrementally
• During each integration the partially integrated system is tested
• After all modules are successfully integrated then system testing
takes place
• There are 3 types of testing: α – testing; β – testing; acceptance
testing
 Maintenance
• Three types of maintenance:
1) Corrective Maintenance
2) Perfective Maintenance
3) Adaptive Maintenance
Relative Effort Distribution among different
Phases
 Shortcomings of Waterfall Model
• No feedback paths
• Difficult to accommodate change requests
• Inefficient error corrections
• No overlapping of phases
 Iterative Waterfall Model
• Applied in practical software development process
• Main change from waterfall model is that providing feedback to the
previous phase
• Feedback path provides correcting the errors occurred in previous
phase
• All stages have a feedback path except for feasibility stage
Iterative Waterfall Model
Distribution of efforts in various stages
 Drawbacks
• Difficult to accommodate change requests
• Incremental delivery not supported
• Phase overlap not supported
• Error correction is expensive
• Limited customer interaction
• Heavy documentation
• No support for risk handling & reuse
 Spiral Model
• Diagrammatic representation is like a spiral with many loops
• Each phase is represented as a loop
• Prototypes are built at the start of every phase
• Each loop has one or more features of the product
• The features are analysed
• The risks are identified & resolved by prototyping
• Finally it is implemented
• The project manager decides dynamically the number of phases as the project
progresses
• The features that can be developed simultaneously are identified to make the model
efficient
Spiral Model
 Phases of Spiral Model
• Quadrant 1: Objectives are investigated, elaborated & analysed;
Risks are identified; alternate solutions are proposed
• Quadrant 2: Alternative solutions are evaluated through prototyping
& the best solution is selected
• Quadrant 3: Developing & verifying the next level of software;
identified features are implemented & the next version of the
software is available
• Quadrant 4: Reviewing the stages of the software developed till that
phase with the customer & planning the next iteration of the spiral
Advantages & Disadvantages