Module-4

System analysis and development and models

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

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.

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.

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.

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.

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.

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.

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.

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.

 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.

Stages in system analysis

System study Feasibility study System analysis System design Coding Testing Implementation Maintenance

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

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.

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.

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

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.

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

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:

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.

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.

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

DFD Symbols

Four basic symbols Process Data Flow Data Store External Entity

Two popular symbol sets Gane and Sarson DeMarco and Yourson

Figure 5-1. Comparison of DFD Symbols

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

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

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

DFD Guidelines

Establish system boundary. Label processes and data flows with

sufficient information. Think WHAT and not HOW. Think data FLOW, not control.

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.

A Context Diagram

Customer

CashReceiptsProcess

Bank

Payment

DepositDataflows(Interfaces)

Process bubble

}Boundary (border between asystem and its environment)

Relevant Environmentcomprised of External Entities

This is a flow connecting a systemwith its environment

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.

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

Decision table Example

Conditions/courses and actions

Rule Rule Rule

Condition stub

C1 Employee typeC2 Hours taken

S<40

M>40

O>40

Action statement

Pay base salaryCalculate hourly wageProduce absence report

XX

X

XX

Driver Age 25 yrs +

25 yrs +

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

Accident Free Y N N Y Y Y Y Y

Driver Gender - - - Female Male Male Male Male

Driver’s Education

- - - - N Y Y Y

College (attending /completed)

- - - - - N Y Y

High School GPA

- - - - - - < 3.25 3.25+

20% surcharge

X

15% surcharge

X

12% surcharge

X

10% surcharge

X X

7% surcharge

X X

No surcharge

X

Table 5-5. Decision Table for Insurance Rating System

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.

System Development models

Water Flow Model Prototype Model Spiral Model RAD

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.

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.

Water Flow Model

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.

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.

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.

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.

System Testing

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

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.

Waterfall model

Advantages It is linear and therefore very

easy to be implemented Required amount of

resources are minimal A documentation is

produced at every stage of waterfall model development

After every major stage of coding, testing is done to check whether the code running is correct or not

Disadvantages Tester role only happen in the test

phase Unable to make any changes to

middle or any phases after the process started

Waterfall model is not simultaneous Only able to use when the

requirements are fixed Unable to move back to the

previous phase If any mistake happen on middle

phases, should start from the scratch

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.

http://newton.cs.concordia.ca/~paquet/wiki/index.php/Image:Spiral_model.gif

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.

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

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.

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.

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.

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.

Prototype model

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.

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.

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.

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.

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"

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.

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.

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.

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.

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.

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.  

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

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.

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

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.

End of Module-4Thank you