The document discusses system analysis and development models. It describes the need for system analysis from various points of view like system objectives, boundaries, importance, etc. It then explains the key stages in system analysis like system study, feasibility study, system analysis, system design, coding, testing, implementation and maintenance. It also discusses various system analysis tools like data flow diagrams, decision tables, etc.

1. Module-4
System analysis and development and
models

2. Need for system analysis
 When you are asked to computerize an system, it is
necessary to analyze the system form different angles.
 The analysis of the system is the basic necessity for an
efficient system design.
 The need for analysis can be studied from the following
points of view.
 System objective
 System boundaries
 System importance
 Nature of the system
 Role of the system as an interface
 Participation of users
 Understanding of resource needs
 Assessment of feasibility

3. System objective
 It is necessary to define the system objectives.
Many a times, it is observed that the systems
are historically in operation and have lost their
main purpose of achievement of objectives.
 The users of the system and the personnel
involved are not in a position to define the
objectives.
 Since you are going to develop a computer
based system, it is necessary to redefine or
reset the objectives as a reference point in
context of the current business requirement.

4. System boundaries
 It is necessary to establish the system
boundaries which would define the scope and
the coverage of the system.
 This helps to sort out and understand the
functional boundaries of the system, the
department boundaries in the system, and
the people involved in the system.
 It also helps to identify the inputs and the
outputs of the various subsystems, covering
the entire system.

5. System importance
 It is necessary to understand the importance
of the system in the organisation.
 This would throw more light on its utility and
would help the designer to decide the design
features of the system.
 It would be possible then to position the
system in relation to the other systems for
deciding the design strategy and
development.

6. Nature of the system
 The analysis of the system will help the
system designer to conclude whether the
system is the closed type or an open, and a
deterministic or a probabilistic.
 Such an understanding of the system is
necessary, prior to design the process to
ensure the necessary design architecture.

7. Role of the system as an interface
 The system, many a times, acts as an
interface to the other systems.
 It is necessary to understand the existing role
of the system, as an interface, to safeguard
the interests of the other systems.
 Any modifications or changes made should
not affect the functioning or the objectives of
the other systems.

8. Participation of users
 The strategic purpose of the analysis of the
system is to seek the acceptance of the
people to a new development.
 System analysis process provides a sense of
participation to the people.
 This helps in breaking the resistance to the
new development and it also then ensures
the commitment to the new system.

9. Understanding the resources
 The analysis of the system helps in defining the
resource requirements in terms of hardware and
software.
 If any additional resources are required, this
would mean an investment.
 The management likes to evaluate the
investment from the point of view of return on
such investment.
 If the return on the investment is not
attractive, the management may drop the object.

10. Assessment of feasibility
 The analysis of the system helps to establish
the feasibility from different angles. The
system should satisfy the technical, economic
and operational feasibility.
 Many a times, the system are feasible from
the technical and economic point of view; but
they may be infeasible from the operational
point if view.
 The assessment of feasibility will save the
investment and the system designers time.

11.  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.
 In the System Analysis and Design
terminology, the system development life
cycle means software development life cycle.

12. Stages in system analysis
 System study
 Feasibility study
 System analysis
 System design
 Coding
 Testing
 Implementation
 Maintenance

13. System Study
 System study is the first stage of system development life
cycle. 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 user’s
requirement and the limitations and problems of the present
system are studied.
 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

14. 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 user’s
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.

15. System analysis
 System analysis is the analysis of the problem that
the org will try to solve with an information system.
 It consists of defining the problem, identifying the
causes, specifying the solution, and identifying the
information requirements that must be met by a
system solution.
 System analysis process identifies several
alternative solutions that the org can pursue.
 It is up to management to determine which mix of
costs, benefits, technical features, and org impacts
represents the most desirable alternative.

16. 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.

17.  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

18. 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.

19. 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).

20.  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 analyzed.
 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.

21. 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 computerized system,
manual working has to shift from manual to computerized
working. The following two strategies are followed for running the
system:

22.  Parallel run: In such run for a certain defined period, both
the systems i.e. computerized and manual are executed in
parallel. This strategy is helpful because of the following:
 Manual results can be compared with the results of the
computerized system.
 Failure of the computerized 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.

23. 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
 If a major change to a system is needed, a new project may have to be
set up to carry out the change. The new project will then proceed
through all the above life cycle phases.

25. Data Flow Diagram
 A graphical tool that depicts the sequence of
processes and functions contained within a
specific system boundary and the flow of data
through that system.
 DFD - data flow diagram - used to chart the
input, processes, and output of the
business's functions in a structured graphical
form

26. DFD Symbols
 Four basic symbols
 Process
 Data Flow
 Data Store
 External Entity
 Two popular symbol sets
 Gane and Sarson
 DeMarco and Yourson

27. Figure 5-1. Comparison of DFD Symbols

28. DFD Components
 Data Flow
 Represented by a line with arrowhead indicating
direction of flow
 Data in motion
 Use noun to name the data content
 Data Store
 Represents a repository for data recorded within
the system
 Data at rest

29. DFD Components
 Process
 Transform data into another form
 Process inputs to create a set of output data flows
 Using the input as output in its same basic form
 Reorganize the inputs
 External agent
 Someone or something interacts with the system but
resides outside the system boundary
 Source: serve as the origin of data flowing into
the system
 Sink: represents a destination for data flowing
out from the system

30. Figure 5-2. Data Flow Diagram for Logical Apple-Peeling Process

31. DFD Guidelines
 Establish system boundary.
 Label processes and data flows with
sufficient information.
 Think WHAT and not HOW.
 Think data FLOW, not control.

32. Context diagram
 A context diagram is a graphic design that clarifies
the interfaces and boundaries of the project or
process at hand.
 It not only shows the process or project in its
context, it also shows the project’s interactions with
other systems and users.
 Context diagram is “is the highest level view of a
system showing a system as a whole and its inputs
and outputs to external factors”.
 A context diagram “shows the interactions between
a system and other actors with which the system is
designed to interface.

33. A Context Diagram
Process bubble
Customer Relevant Environment
comprised of External Entities
Payment Cash
Receipts }Boundary (border between a
system and its environment)
Process
Dataflows Deposit
(Interfaces) Bank
This is a flow connecting a system
with its environment

34. Why is a context diagram beneficial?
 Context diagrams are instrumental in advancing the
thinking process and triggering memory recall of subject
matter expects who create and study them.
 A context diagram will also reveal omissions and errors in a
business plan or business requirements so that any
necessary corrections can be brought to light and
addressed before a project is deployed.
 A context diagram may serve to unambiguously and quickly
define a project’s scope. It facilitates the discovery and/or
confirmation of high-level events that trigger the
process, including external entities that interact with project
or process, inputs to and outputs from the project or
process, and initial sub-process requirements.

35. Decision Tables
 A diagram of all the logic and possible outcomes
associated with a particular process
 Process rules
 Condition stubs
 Action stubs
 Process rule and condition stubs
 represent the specific rule for making a decision
 Action stubs
 represent all possible courses of action associated
with a given set of conditions and rules

36. Decision table Example
Conditions/cour Rule Rule Rule
ses and actions
Condition C1 Employee S M O
stub type <40 >40 >40
C2 Hours taken
Action Pay base salary X X
statement Calculate hourly X X
wage
Produce absence X
report

37. Driver Age 25 yrs 25 < 25 < 25 < 25 < 25 < 25 < 25
+ yrs + yrs yrs yrs yrs yrs yrs
Accident Free Y N N Y Y Y Y Y
Driver Gender - - - Female Male Male Male Male
Driver’s - - - - N Y Y Y
Education
College - - - - - N Y Y
(attending
/completed)
High School - - - - - - < 3.25 3.25+
GPA
20% X
surcharge
15% X
surcharge
12% X
surcharge
10% X X
surcharge
7% X X
surcharge
No X
surcharge
Table 5-5. Decision Table for Insurance Rating System

38. Structure Diagram
 Structure Diagram is a data model used to
describe conceptual data models by
providing graphical notations which
document entities and their relationships, and
the constraints that binds them.
 The basic graphic elements of SDs
are boxes, representing
entities, and arrows, representing
relationships.
 Data structure diagrams are most useful for
documenting complex data entities.

39. System Development models
 Water Flow Model
 Prototype Model
 Spiral Model
 RAD

40. Water flow model
 In order to design a good system, the developers
have used the Waterfall model on a traditional basis,
as shown as in the figure.
 The waterfall model is a sequential design process,
often used in software development, in which
progress is seen as flowing steadily downwards (
like a waterfall) through the phases of SDLC.
 This model fits well when the changes into the
requirement specifications are not required
frequently.
 As waterfall flows from the top to the bottom, the
system model shows the development process from
the top to the bottom in steps.

41.  As water does not rise from a lower level to a
higher level, it is presumed that once a step in
the model is over, it is not required to go back.
 The minor changes can be taken care of through
a maintenance process or through small design
changes.
 The waterfall model applies well to the basic rule
based data and information processing systems
in accounting materials, production & personnel.

42. Water Flow Model

43. Analysis
 The analysis is carried out from the top towards
the bottom in the organization hierarchy.
 This step links the goals and objectives of the
organization with the strategy mix to achieve
them.
 In this step, the information needs of the
individuals, groups and functions are analyzed
from a decision making/support point of view.
 Such information needs would fully satisfy the
operational and management information needs.

44. Requirement specification
 Once the information needs are justified, the next
step is to define them in clearer terms for the
purpose of development.
 This definition brings clarity in the content and its
applications in various ways in the organization.

45. System Design
 This step consists of three sub-steps:
 Input Design
 Process Design
 Output Design
 Here a physical and a logical system is designed
through which the outputs are designed.
 The processes which would give the outputs are
determined and the data which would be required by
these processes is finalized in terms of
definitions, source & quality
 Also, the collection, creation, validation & storage of
the input data is also decided.

46. Implementation
 the system is implemented at the site, on the
hardware and software platform.
 The implementation step has its own procedure
starting from the installation of the hardware &
software, training the users & then fully shifting to
a fully designed system.
 During implementation, some minor
modifications/adjustments are required, so as to
ease the work of the user.

47. System Testing
 The system is tested as a whole for several
aspects such as information, quality, performance,
utility, user acceptance & so on.

48. Maintenance
 Even after complete installation, some
modifications/changes/adjustments of functions
and features are required over a period of time.
 The process of introducing these new
requirements without disturbing the time tested
basic system is called maintenance.
 Such changes are required immediately, hence
they are required to be carried out very easily
 Hence, the system has to be designed to allow
such changes to take place in the post-
implementation period.

49. Waterfall model
Advantages Disadvantages
 It is linear and therefore  Tester role only happen in the
very easy to be test phase
implemented  Unable to make any changes
 Required amount of to middle or any phases after
resources are minimal the process started
 Waterfall model is not
 A documentation is simultaneous
produced at every stage of  Only able to use when the
waterfall model requirements are fixed
development
 Unable to move back to the
 After every major stage of previous phase
coding, testing is done to  If any mistake happen on
check whether the code middle phases, should start
running is correct or not from the scratch

50. Spiral model
 Some systems are more dynamic and require changes in
specifications more often to continue to be useful.
 These modifications are termed as the versions of the basic
model.
 One of the popular models developed is the Spiral Model by
Boehm.
 A spiral model fits well, when we are developing large systems,
where the specifications cannot be ascertained in one stroke
completely and correctly
 Some of them get surfaced when the system is put to use after
its testing
 The user wants the system to be user friendly, reliable &
effective, and one which gives correct results,
 The developer wants the system easy to modify, easy to
understand, portable and compatible to other systems.

52. Spiral model
 A spiral phase begins in the top left quadrant
(quadrant 1), by determining objectives of that
phase, alternatives and constraints. This is a way to
define a strategy for achieving the goals of this
iteration.
 Next (quadrant 2), the strategy is analyzed form the
viewpoint of risk, and solutions to minimize these
risks are investigated, often using prototyping. Then
(quadrant 3), in light of the investigations made in
quadrant 2, a solution is put into practice to produce
the artifacts necessary to reach the goals identified
in quadrant 1.

53.  This quadrant (3) corresponds to where the
traditional waterfall model phases are put into
practice.
 Finally (quadrant4), the results of the risk-
reduction strategies are assessed, and if all risks
are resolved, the next phase is planned and
started. If some risks are left unsolved, another
iteration can be made to continue to work on the
uneliminated risks. If certain risks can not be
resolved, the project might be terminated
immediately (under some circumstances project
might be continued but in a smaller scale).

54. Advantages
 Emphasis on alternatives and constraints supports the
reuse of existing solutions.
 Targets testing by treating it as a risk, which has to be
addressed.
 Maintenance is just another phase of the spiral model. It is
treated in the same way as development.
 Estimates (budget and schedule) get more realistic as work
progresses, because important issues are discovered
earlier.
 It is more able to cope with the (nearly inevitable) changes
that software development generally entails.
 Software engineers, who can get restless with protracted
design processes, can get their hands in and start working
on a project earlier.

55. Disadvantages
 Only intended for internal projects (inside a
company), because risk is assessed as the project
is developed. Hardly suitable for contractual
software development.
 In case of contractual software development, all risk
analysis must be performed by both client and
developers before the contract is signed and not as
in the spiral model.
 Spiral model is risk driven. Therefore it requires
knowledgeable staff.
 Suitable for only large scale software development.
Does not make sense if the cost of risk analysis is a
major part of the overall project cost.

56. Prototype model
 The goal of prototyping based development is to counter
the first two limitations of the waterfall model.
 The basic idea here is that instead of freezing the
requirements before a design or coding can proceed, a
throwaway prototype is built to understand the
requirements.
 This prototype is developed based on the currently
known requirements.
 Development of the prototype obviously undergoes
design, coding and testing. But each of these phases is
not done very formally or thoroughly.

57.  By using this prototype, the client can get an "actual feel" of the
system, since the interactions with prototype can enable the client to
better understand the requirements of the desired system.
 Prototyping is an attractive idea for complicated and large systems
for which there is no manual process or existing system to help
determining the requirements. In such situations letting the client
"plan" with the prototype provides invaluable and intangible inputs
which helps in determining the requirements for the system.
 It is also an effective method to demonstrate the feasibility of a
certain approach. This might be needed for novel systems where it
is not clear that constraints can be met or that algorithms can be
developed to implement the requirements.

58. Prototype model

59. Prototype model
 The basic reason for little common use of prototyping is the cost
involved in this built-it-twice approach. However, some argue that
prototyping need not be very costly and can actually reduce the
overall development cost.
 The prototype are usually not complete systems and many of the
details are not built in the prototype. The goal is to provide a
system with overall functionality.
 In addition, the cost of testing and writing detailed documents are
reduced. These factors helps to reduce the cost of developing
the prototype.
 On the other hand, the experience of developing the prototype
will be very useful for developers when developing the final
system.
 This experience helps to reduce the cost of development of the
final system and results are more reliable and better designed
system.

60. Advantages of Prototyping
 Users are actively involved in the development
 It provides a better system to users, as users have
natural tendency to change their mind in specifying
requirements and this method of developing
systems supports this user tendency.
 Since in this methodology a working model of the
system is provided, the users get a better
understanding of the system being developed.
 Errors can be detected much earlier as the system
is mode side by side.
 Quicker user feedback is available leading to better
solutions.

61. Disadvantages
 Leads to implementing and then repairing
way of building systems.
 Practically, this methodology may increase
the complexity of the system as scope of the
system may expand beyond original plans.

62. Rapid application development
 Rapid application development (RAD) is a software development
methodology that uses minimal planning in favor of rapid
prototyping.
 The "planning" of software developed using RAD is interleaved with
writing the software itself. The lack of extensive pre-planning
generally allows software to be written much faster, and makes it
easier to change requirements.

63.  Rapid application development is a software development
methodology that involves methods like iterative
development and software prototyping.
 In rapid application development, structured techniques and
prototyping are especially used to define users' requirements and
to design the final system.
 The development process starts with the development of
preliminary data models and business process models using
structured techniques.
 In the next stage, requirements are verified using
prototyping, eventually to refine the data and process models.
 These stages are repeated iteratively; further development
results in "a combined business requirements and technical
design statement to be used for constructing new systems"

64. Phases of RAD
 Requirements Planning phase – combines
elements of the system planning and systems
analysis phases of the System Development Life
Cycle (SDLC).
 Users, managers, and IT staff members discuss
and agree on business needs, project scope,
constraints, and system requirements.
 It ends when the team agrees on the key issues
and obtains management authorization to
continue.

65.  User design phase – during this phase, users
interact with systems analysts and develop
models and prototypes that represent all system
processes, inputs, and outputs.
 The RAD groups or subgroups typically use a
combination of Joint Application Development
(JAD) techniques and CASE tools to translate
user needs into working models.
 User Design is a continuous interactive process
that allows users to understand, modify, and
eventually approve a working model of the
system that meets their needs.

66.  Construction phase – focuses on program
and application development task similar to
the SDLC.
 In RAD, however, users continue to
participate and can still suggest changes or
improvements as actual screens or reports
are developed.
 Its tasks are programming and application
development, coding, unit-integration and
system testing.

67.  Cutover phase – resembles the final tasks in
the SDLC implementation phase, including data
conversion, testing, changeover to the new
system, and user training.
 Compared with traditional methods, the entire
process is compressed.
 As a result, the new system is built, delivered,
and placed in operation much sooner.
 Its tasks are data conversion, full-scale testing,
system changeover, user training.

68. What are the advantages and
disadvantages of RAD?
 RAD reduces the development time and reusability
of components help to speed up development. All
functions are modularized so it is easy to work with.
 For large projects RAD require highly skilled
engineers in the team.
 Both end customer and developer should be
committed to complete the system in a much
abbreviated time frame.
 If commitment is lacking RAD will fail. RAD is based
on Object Oriented approach and if it is difficult to
modularize the project the RAD may not work well.

69. Roles and responsibilities of system analyst
 The role of an analyst is to help organizations understand
the challenges before them to make this transition and to
ensure that the needs and expectations of the client are
represented correctly in the final solution.
 The analyst is responsible for ensuring that the
requirements set forth by the business are captured and
documented correctly before the solution is developed and
implemented.
 In some companies, this person might be called a Business
Analyst, Business Systems Analyst, Systems Analyst or a
Requirements Analyst.
 The main responsibility is to capture and document the
requirements needed to implement a solution to meet the
clients' business needs.

70.  Analyzing and understanding the current state processes to
ensure that the context and implications of change are
understood by the clients and the project team
 Developing an understanding of how present and future business
needs will impact the solution
 Identifying the sources of requirements and understanding how
roles help determine the relative validity of requirements
 Developing a Requirements Management Plan and
disseminating the Plan to all stakeholders.
 Identifying and documenting all business, technical, product and
process requirements
 Working with the client to prioritize and rationalize the
requirements
 Helping to define acceptance criteria for completion of the
solution

71. Database Administrator (DBA)
 An information specialist who has responsibility for the
database is called DBA.
 Typical responsibilities of DBA are:
 Helps an org decide to maintain and update data field in a
database.
 Assures access to database information to each department that
needs it.
 Secures databases or portions of databases from unauthorized
use.
 Protects databases from physical harm by supervising the
creation of backup copies and establishing fallback procedures.
 Coordinates the work of individuals making file modifications,
policy changes and improvements of databases.

72.  Transferring Data
 Replicating Data
 Maintaining database and ensuring its
availability to users
 Maintaining the data dictionary.
 Controlling privileges and permissions to
database users
 Monitoring database performance
 Database backup and recovery
 Database security

73. Database Designer
 Database designer or developer works in information technology
(IT) to design and implement databases for the
collection, protection and analysis of data.
 Responsibilities:
 Database developers work in the IT department of an
organization and focus mainly on the programming aspect of
database design, analyzing data inquiry needs, ensuring security
of information and organizing layout to best present the
information needed.
 These professionals work closely with other IT team
members, including systems administrators and database
administrators.
 Depending on the size of the company, many database
developers take on some of the duties of database
administrators and must maintain data backup, storage and data
integrity in addition to their other duties.

74. End of Module-4
Thank you