IGNOU BCA CS-05 Solved Assignments 2010

IGNOU BCA CS-05 Solved Assignments 2010

Course Code : CS-05

Course Title : Elements of Systems Analysis and Design

Assignment Number : BCA (3)-/Assignment/ 2010

Maximum Marks : 25

Last Date of Submission : 30^th April, 2010 (For January Session)

30^th October, 2010 (For July Session)

Question 1: Define the term “System Analysis (3 Marks)

Ans 1. System Analysis is the Modern e-mail systems are based on a store-and-forward model in which e-mail computer server systems, accept, forward, or store messages on behalf of users, who only connect to the e-mail infrastructure with their personal computer or other networkenabled device for the duration of message transmission or retrieval to or from their designated server. Rarely is e-mail transmitted directly from one user's device to another's. While, originally, e-mail consisted only of text messages composed in the ASCII character set, virtually any media format can be sent today, including attachments of audio and video clips.

System analysis is the branch of electrical engineering that characterizes electrical

systems and their properties. Although many of the methods of system analysis can be

applied to non-electrical systems, it is a subject often studied by electrical engineers

because it has direct relevance to many other areas of their discipline, most notably signal processing and communication systems.

=====================================================================

Question 2: Define the term “System Design”. (3 Marks)

Ans 2: Systems design is the process or art of defining the architecture, components, modules,

interfaces, and data for a system to satisfy specified requirements. One could see it as the

application of systems theory to product development. There is some overlap and synergy

with the disciplines of systems analysis, systems architecture and systems engineering.

Systems design is the process or art of defining the architecture, components, modules,

interfaces, and data for a system to satisfy specified requirements. One could see it as the

application of systems theory to product development. There is some overlap and synergy

with the disciplines of systems analysis, systems architecture and systems engineering.

Major System Design Activities are

1. DB design

2. Program design

3. System & program test preparation

4. System Interface Specification

5. Audit Consideration

6. Audit control & Documentation control

Major design process parts are

1. O/p design

2. I/p design

3. File Design

4. Procedure design

- Computer design

- Non-computer design

5. Control design

=====================================================================

Question 3: Explain the responsibilities of a System Analyst? (4 Marks)

Ans 3 : Systems analyst is responsible for researching, planning, coordinating and

recommending software and system choices to meet an organization's business

requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and

interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems.

Technical skills help systems analysts understand the potential and the limitations of

information technology. The systems analyst must be able to work with various

programming languages, operating systems, and computer hardware platforms.

Management skills help systems analysts manage projects, resources, risk, and change.

Interpersonal skills help systems analysts work with end users as well as with other

analysts, programmers, and other systems professionals.

Systems analysts may act as liaisons between vendors and the organization they

represent. They may be responsible for developing cost analyses, design considerations,

and implementation time-lines. They may also be responsible for feasibility studies of a

computer system before making recommendations to senior management.

Basically a systems analyst performs the following tasks:

Interact with the customers to know their requirements

Interact with designers to convey the possible interface of the software

Interact/guide the coders/developers to keep track of system development

Perform system testing with sample/live data with the help of testers

Implement the new system

====================================================================

Question 4: Assume that you are appointed as System Analyst for the development of a “Library Information System(LIS)”. Develop SRS for it. Make necessary assumptions (8 Marks)

Question 5: Develop design document for LIS in Question no.1 above. (7 Marks)

Ans : 4 n 5 DESIGN ..The most creative and challenging phase of the system life cycle is system design. The term design describes a final system and the process by which it is

developed. It refers to the technical specifications (analogous to the engineer's

blueprints) that will be applied in implementing the candidate system. It also

includes the construction of programs and program testing. The key question

here is: How should the problem be solved?

The first step is to determine how the output is to be produced and in what

format. Samples of the output (and input) are also presented. Second input data

and master files (database) have to be designed to meet the requirements of the

proposed output. The operational (processing) phases are handled through

program construction and testing, including a list of the programs needed to meet

the system's objectives and complete documentation. Finally, details related to

justification of the system and an estimate of the impact of the candidate system

on the user and the organization are documented and evaluated by management

as a step toward.

Implementation

The final report prior to the implementation phase includes procedural flowcharts,

record layouts, report layouts, and a workable plan for implementing the

candidate system. Information on personnel, money, hardware, facilities and their

estimated cost must also be available. At this point projected costs must be close

to actual costs of implementation.

In some firms, separate groups of programmers do the programming whereas

other firms employ analyst-programmers who do analysis and design as well as

code programs. For this discussion, we assume two separate persons carry out

the analysis and programming. There are certain functions, though, that the

analyst must perform whole programs are being written. Operating procedures

and documentation must be completed. Security and auditing procedures must

also be developed.

INTRODUCTION OF PHYSICAL DESIGN

The systems objectives outlined during the feasibility study serve as the basis

from which the work of system design is initiated. Much of the activities involved

at this stage is of technical nature requiring a certain degree of experience in

designing systems, sound knowledge of computer related technology and

thorough understanding of computers available in the market and the various

facilities provided by the vendors. Nevertheless, a system cannot be designed in

isolation without the active involvement of the user. The user has a vital role to

play at this stage too. As we know that data collected during feasibility study will

be utilized systematically during the system design. It should, however, be kept in

mind that detailed study of the existing system is not necessarily over with the

completion of the feasibility study. Depending on the plan of feasibility study, the

level of detailed study will vary and the system design stage will also vary in the

amount of investigation that still needs to be done. This investigation is generally

an urgent activity during the system design, as the designer needs to study

minute’s details in all aspects of the system. Sometimes, but rarely, this

investigation may form a separate stage between Feasibility Study and Computer

System Design. Designing a new system is a creative process, which calls for

logical as well as lateral thinking. The logical approach involves systematic

moves towards the end product keeping in mind the capabilities of the personnel

and the equipment at each decision making step. Lateral thought implies

encompassing of ideas beyond the usual functions and equipment. This is to

ensure that no efforts are being made to fit previous solutions into new situations.

System Design Considerations

The system design process is not a step-by-step adherence of clear procedures

and guidelines. Though, certain clear procedures and guidelines have emerged

in recent days, but still much of design work depends on knowledge and

experience of the designer.

When designer starts working on system design, he will face different type of

problems. Many of these will be due to constraints imposed by the user or

limitations of the hardware and software available in the market. Sometimes, it is

difficult to enumerate the complexity of the problems and solutions thereof since

the variety of likely problems is so great and no solutions are exactly similar.

However, following considerations should be kept in mind during the systemdesigning

phase:

The primary objective of the design: Of course, is to deliver the requirements

as specified in the feasibility report. In general, the following design objectives

should be kept in mind:

a) Practicality: The system must be stable and can be operated by people with

average +

b) Efficiency: This involves accuracy, timeliness and comprehensiveness of the

system output.

c) Cost: it is desirable to aim for a system with a minimum cost subject to the

condition that it must satisfy all the requirements.

Flexibility: The system should be modifiable depending on the changing needs

of the user. Such modifications should not entail extensive reconstructing or

recreation of software. It should also be portable to different computer systems.

d) Security: This is very important aspect of the design and should cover areas

of hardware reliability, fall back procedures, physical security of data and

provision for detection of fraud and abuse.

System design involves first logical design and then physical construction of the

system. The logical design describes the structure and characteristics of

features, like the outputs, inputs, files, databases and procedures. The physical

construction, which follows the logical design, produces actual program software,

files and a working system.

The designer normally will work under following constraints:

1. Hardware: The existing hardware will obviously affect the system design.

2. Software: The available software (operating system, utilities, language

etc.) in the market will constrain the design.

3. Budget: The budget allocated for the project will affect the scope and

depth of design.

4. Time-scale: The new system may be required by a particular time (e.g.

the start of a financial year). This may put a constraint on the designer to

find the best design.

5. Interface with other systems: The new system may require some data

from another computerized system or may provide data to another system

in which case the files must be compatible in format and the system must

operate with a certain processing cycle.

4. SYSTEM DEVELOPMENT LIFE CYCLE

User Revised Requirement

Requirement Specification

Decision to

Design Information

System

Feasibility

Test Plan Study

Logical System Design Functional Spec.

Physical

Requirement

System Configuration

Requirement

Determination

Initial

Requirement

Investigation

Feasibil

ity

Analysi

s

System

Implementation

System

Design

System

Specifica

tion

Analysis

System

Evaluation

Hardware

Study

Data

Schedule Budget

Revised

Requirement

System Modification Improved System

Maintenance

Context Level DFD For

Library Management System

Member

Details

Book

Details

Library

Management

System

CODING STANDARDS

Coding standards can improve the quality of our work and help make our team

more efficient and effective. In “VB programming standards lead to better code”,

we discussed some coding standards and naming conventions for controls,

variables, constants, enumerations, and procedures. To improve the readability

of your Visual Basic programs even further, we’ll explore some suggested

standards for variable qualifiers, menus, code formatting, and commenting.

Variable qualifiers

Often, projects contain variables that are related to one another. So your

variables should be named in a way that makes the related information easy to

find. For example, if you are retrieving information about a customer, such as first

name and last name, use Customer as a standard qualifier for naming all

variables related to Customer. Your qualifier will go right after the variable data

type prefix—for example, strCustomerFirst and strCustomerLast—to denote that

both variables relate to information gathered about a customer. Use the common

variable qualifiers listed in Table A for naming related variables.

Qualifier Description

Txt First element of the textbox

Cmb First element of the combo box

Lbl First element of the label

Frm First element of the form

Lst First element of the list box

Str First element in a set

Next Next element in a set

Prev Previous element in a set

Cur Current element in a set

Min Minimum value

Max Maximum value

Tmp A highly localized “scratch” variable

Src Source; often used in transfer routines

Dst Destination; often used in conjunction with src

Table A Suggested prefixes for frequently used controls

Menus

All menus should have the standard mnu prefix. Menu control prefixes should

also include an additional prefix for each level of nesting, with the final menu

caption at the end of the name string. For example, in our application we have

three top-level menus called Details, Facility and Reports with their submenu

items . Code formatting and commenting conventions. The addition of indents and

comments can greatly improve the readability of your code. Properly used,

indents can make it easy for someone reading your program to quickly identify

the program structures. In fact, it can help reveal bugs or unnecessarily complex

portions of the code before you ever run the program.

Code formatting

In general, your code should be easy for you and others to read. If you don't

indent your statements, it is practically impossible to make sense of what you’re

doing.

When you format your code, you should:

Make it easy to read and to understand.

Reduce the work necessary to understand structural constructs.

Make the structure of code as self-documenting as possible.

Indent continuation lines.

Use indentation to show organizational structure.

In other words, by formatting the code, it should be clear where various elements

such as decision structures begin and end. If there is an else, you should be able

to quickly identify the code that will execute for each portion of the if-else branch.

More specifically, you should indent:

After an If statement when an End If is used.

After an Else statement.

After a Select Case statement.

After a Case statement.

After a Do statement.

Successive lines of a statement that has been split with the line

continuation character.

After a With statement.

After calling an Edit or AddNew method of a Record set object. The

Update or CancelUpdate method should appear at the same level of

indention as the Edit or AddNew statement.

After a prcconnect method call.

In the declarations section of a module.

In the bodies of user-defined data type declarations.

In the bodies of enumeration declarations.

Code that is subordinate to a line label. Visual Basic doesn't allow you to

indent labels, and this works to your advantage. If you indent the entire

highest-level code one tab stop from the left side of the code window, the

labels within the procedure will stand out because they are left aligned in

the code window.In addition, you should use white space to group related statements. Insert a

blank line:

Before and after each If…Then.

Before and after each Select Case.

Before and after each loop.

After declaring a block of variables.

Between groups of statements that perform a step in an overall task.

Verification & Validation

The goal of verification and validation activities is to assess and improve the

quality of the work products generated during development and modification of

software. Quality attributes of interest include correctness, completeness,

consistency, reliability, usefulness, usability, efficiency, conformance to

standards, and overall cost effectiveness.

There are two types of verification: life-cycle verification and formal verification.

Life-cycle verification is the process of determining the degree to which the work

products of a given phase of the development cycle fulfill the specifications

established during priori phases. Formal verification is rigorous mathematical

demonstration that source code conforms to its specifications. Validation is the

process of evaluating software at the end of the software development process to

determine compliance with the requirements. Boehm phrases these definitions

as follows:

Verification: “Are we building the product right?”

Validation: “Are we building the right product?”

Program verification methods fall into two categories-static and dynamic

methods. In dynamic method, the program is executed on some test data and the

outputs of the program are examined to determine if there are any errors present.

Hence, dynamic techniques follow the traditional pattern of testing, and the

common notion of testing refers to this technique.

Static techniques, on the other hand, do not involve actual program execution on

actual numeric data, though it may involve some form of conceptual execution. In

static techniques, the program is not compiled and then executed, as in testing.

Common forms of static techniques are program verification, code reading, code

reviews and walkthroughs, and symbolic execution. In static techniques, often

the errors are detected directly, unlike dynamic techniques where only the

presence of an error is detected. This aspect of static testing makes it quite

attractive and economical.

It has been found that the types of errors detected by the two categories of

verification techniques are different. The type of errors detected by static

techniques is often not found by testing, or it may be more cost-effective to detect

these errors by static methods. Consequently, testing and static methods are

complimentary in nature, and both should be used for reliable software.

Code Reading

Code reading involves careful reading of the code by the programmer to detect

any discrepancies between the design specifications and the actual

implementation. It involves determining the abstraction of a module and then

comparing it with its specifications. The process is the reverse of design. I

design, we start from an abstraction and move toward more details. In code

reading, we start from the details of a program and move toward an abstract

description. The process of code reading is best done by reading the code inside out starting

with the innermost structure of the module. First, determine its abstract behavior

and specify the abstraction. Then, the higher-level structure is considered, with

the inner structure replaced by its abstraction. This process is continued, until we

reach the module or program, being read. At that time, the abstract behavior of

the program/module will be known, which can then be compared to the

specifications to determine any discrepancies.

Code reading is very useful and can detect errors often not revealed by testing.

Reading in the manner of stepwise-abstraction also forces the programmer to

code in a manner conducive to this process, which leads to well-structured

programs. Code reading is sometimes called desk review.

Static Analysis

Analysis of programs, by methodically analyzing the program text, is called static

analysis. Static analysis is usually performed mechanically by the aid of software

tools. During static analysis, the program itself is not executed, but the program

text is the input to the tools. The aim of the static analysis tools is to detect errors

or potential errors or to generate information about the structure of the program

that can be useful for documentation or understanding of the program. Different

kinds of static analysis tools can be designed to perform different types of

analysis.

Many compilers perform some limited, static analysis. More often, tools explicitly

for static analysis are used. Static analysis can be very useful for exposing errors

that may escape other techniques. As the analysis is performed with the help of

software tools, static analysis is a very cost-effective way of discovering errors.

An advantage is that static analysis, sometimes, detects the errors themselves,

not just the presence of errors, as in testing. This saves the effort of tracing the

error from the data that reveals the presence of errors. Furthermore, static

analysis can provide "warnings" against potential errors and can provide insight

into the structure of the program. It is also useful for determining violations of

local programming standards, which the standard compilers will be unable to

detect. Extensive static analysis can considerably reduce the effort later needed

during testing

Data flow analysis is one form of static analysis that concentrates on the uses of

data, by programs and detects some data flow anomalies. Data flow anomalies

are "suspicious" use of data in a program. In general, data flow anomalies are

technically not errors, and they may go undetected by the compiler. However,

they are often a symptom of an error, caused due to carelessness in typing or

error in coding. At the very least, presence of data flow anomalies implies poor

coding. Hence, if a program has data flow anomalies, it is a cause of concern,

which should be properly addressed.

X = a;

x does not appear in any right hand side

x = b;

A CODE SEGMENT

An example of the data flow anomaly is the live variable problem, in which a

variable is assigned some value but then the variable is not used in any later

computation. Such a live variable and, assignment to the variable are clearly

redundant.

Monitoring and Control

The review process was started with the purpose of detecting defects in the

code. Though design reviews substantially reduce defects in code, reviews are

still very useful and can considerably enhance reliability and reduce effort during

testing. Code reviews are designed to detect defects that originate during the

coding process, although they can also detect defects in detailed design.

However, it is unlikely that code reviews will reveal errors in system design or

requirements.

Code inspections or reviews are, usually, held after code has been successfully

completed and other forms of static tools have been applied but before any

testing have been performed. Therefore, activities like code reading, symbolic

execution, and static analysis should be performed, and defects found by these

techniques corrected before code reviews are held. The main motivation for this

is to save human time and effort, which would otherwise be spent detecting

errors that a compiler or static analyzer can detect. In other words, the entry

criteria for code review are that the code must compile successfully and has

been "passed" by other static analysis tools.

The documentation to be distributed to the review team members includes the

code to be reviewed and the design document. The review team for code reviews

should include the programmer, the designer, and the tester. The review starts

with the preparation for the review and ends with a list of action items.

The aim of reviews is to detect defects in code. One obvious coding defect is that

the code fails to implement the design. This can occur in many ways. The

function implemented by a module may be different from the function actually

defined in the design or the interface of the modules may not be the same as the

interface specified in the design. In addition, the input-output format assumed by

a module may be inconsistent with the format specified in the design.

Other code defects can be divided into two broad categories: logic and control

and data operations and computations. Some examples of logic and control

defects are infinite loops, unreachable code, incorrect predicate, missing or

unreferenced labels, and improper nesting of loops and branches. Examples of

defects in computation and data operations are missing validity tests for external

data, incorrect access of array components, improper initialization, and misuse of

variables.

A Sample Checklist: The following are some of the items that can be included in

a checklist for code reviews.

Do data definitions exploit the typing capabilities of the language?

Do all the pointers point to some object? (Are there any "dangling pointers"?)

Are the pointers set to NULL, where needed?

Are the array indexes within bound?

Are indexes properly initialized?

Are all the branch conditions correct (not too weak, not too strong)?

Will a loop always terminate (no infinite loops)?

Is the loop termination condition correct?

Is the number of loop executions "off by one"?

Where applicable, are the divisors tested for zero?

Are imported data tested for validity?

Do actual and formal interface parameters match?

Are all variables used? Are all output variables assigned?

Can statements placed in the loop be placed outside the loop?

Are the labels unreferenced?

Will the requirements of execution time be met?

Are the local coding standards met?

===============================================================================================================================================================================================================