Monday, October 24, 2011

IGNOU (BCA) ASSIGNMENTS Year 2011 (3rd Semester) CS-63 CS-05


1. IGNOU BCA-CS-63 Assignment 2011(solved)
 
2. IGNOU BCA-CS-05 Assignment 2011(solved)
 



Course Code : CS-63
Course Title : Introduction to Software
Assignment Number : BCA(3)-63/Assignment/2011
Maximum Marks : 25
Last Date of Submission : 30th April, 2011/30th October, 2011

There are six questions in this Assignment. Answer all the questions. You may use illustrations and diagrams to enhance explanation.

Question 1: Explain the three main purposes of an operating system? What is layered approach to OS design? Also, describe its advantages and disadvantages.
(4 Marks)

Question 2: Write a shell program to generate the first 25 prime numbers.
(4 Marks)

Question 3: What is ‘Mutual Exclusion’? Write pseudo code to implement
mutual exclusion using:

(i) Test and Set instruction and
(ii) Swap instruction
(4 Marks)

Question 4: Consider the following set of processes:

Process Burst time (ms)

P1 10
P2 29
P3 3
P4 7
P5 12

Evaluate the performance of FCFS, SJF and RR (Quantum = 10 ms) algorithms for scheduling the above processes.
(3 Marks)

Question 5: Write a shell program to cipher all the text/content in any text document in the current working directory and also use another shell program to decipher it to read. Use any scheme for ciphering.
(6 Marks)

Question 6: Write the UNIX commands for the following tasks:
• find lines common to two or more files
• compare files but stops at first occurrence of a difference
• show differences of two files
• list all jobs in the waiting queue
(4 Marks)

Course Code : CS-05
Course Title : Elements of System Analysis and Design
Assignment Number : BCA (3)-05/Assignment/ 2011
Maximum Marks : 25
Last date of Submission : 30th April, 2011/30th October, 2011

There are three questions in this assignment. Answer all the questions. You may use illustrations and diagrams to enhance your explanations.

Question 1: Explain how the existence of remote users might complicate information system design. Describe a system in which you might be considered a remote user.
(10 Marks)
Question 2: Define well-formulated educational objectives for your academic career. Describe at least five constraints that could limit your ability to achieve your objectives.
(5 Marks)
Question 3: How does a project management life cycle (or process) contribute to an organization’s ability to achieve CMM level 5 certification?
(10 Marks)

Sunday, April 12, 2009

CS-05 Elements of System Analysis and Design

MCA Project  4#


CUSTOMER CARE MANAGEMENT SYSTEM PROJECT IN ASP NET

FRONTEND - C # AND .NET FRAMEWORK 

BACKEND - SQL SERVER 2008

Synopsis- Available- Click on the Project link above to review
Final report- Available - Click on the Project link to review
Course Code : CS-05
Course Title : Elements of System Analysis and Design
Assignment Number : BCA (3)-05/Assignment/ 2009
Maximum Marks : 25
Last date of Submission : 30th April, 2009/30th October, 2009

Q. 1 Define the term “ System Analysis”.
Ans 1.
System Analysis

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.

Q. 2 Define the term “System Design”.
Ans 2:
System Design
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

Q. 3 Explain the responsibilities of a System Analyst?
Ans 3.
System Analyst

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 syste

Q. 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.
Ans4:
ER - DIAGRAM
BOOKS
TITLE BOOK ID
PUBLISHER
AUTHOR
ISSUED
TO
MEMBERS
NAME MEMBER
ID
SEX
TELEPHONE ADDRESS
RETURN
DFD for Library Books
Book request
Book Issue
Receipt
Late Fine
Update Book
Record
D2: Accounts D3: Library
Student
LIBRARY
Accounts
Print
Report

Q. 5 Develop Design document for LIS in Question no.4 above
Ans 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. In
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?