CS-05 - Elements Of Systems Analysis And Design BCA (3)-/Assignment/ 2010

There are five questions in this assignment. Answer all the questions. You may use illustrations and diagrams to enhance explanations. Question 1: Define the term System Analysis. (3 Marks) Question 2: Define the term System Design. (3 Marks) Question 3:Explain the responsibilities of a System Analyst? (4 Marks) 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)

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 email 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: 1.Interact with the customers to know their requirements 2.Interact with designers to convey the possible interface of the software 3.Interact/guide the coders/developers to keep track of system development 4.Perform system testing with sample/live data with the help of testers

5.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 minutes 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 Feasibility Analysis System Implementation System Design System Specification 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, well 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 prefixfor example, strCustomerFirst and strCustomerLastto 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 youre 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 IfThen. .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?