Part-I Q.1. How can you apply the concept of Feasibility Study in the information systems. Discuss in detail.

Ans) The Feasibility study is an analysis of possible alternative solutions to a problem and a recommendation on the best alternative. It can decide whether a process be carried out by a new system more efficiently than the existing one. The feasibility study should examine three main areas; - market issues, - technical and organizational requirements, - financial overview. The results of this study are used to make a decision whether to proceed with the project, or table it. If it indeed leads to a project being approved, it will - before the real work of the proposed project starts - be used to ascertain the likelihood of the project's success. A feasibility study should provide management with enough information to decide: 1. Whether the project can be done; 2. Whether the final product will benefit its intended users; 3. What are the alternatives among which a solution will be chosen (during subsequent phases)? 4. Is there a preferred alternative? Content of a feasibility study Things to be studied in the feasibility study: The present organizational system Stakeholders, users, policies, functions, objectives... Problems with the present system Inconsistencies, inadequacies in functionality, performance Possible solution alternatives Types of Feasibility

The feasibility study includes complete initial analysis of all related system. Therefore the study must be conducted in a manner that will reflect the operational, economic as well as technical and scheduling feasibility of the system proposal. These are the four main types of feasibility study. Operational This aspect defines the urgency of the problem and the acceptability of any solution. It shows if the system is developed, will it be used. The operational study includes people oriented and social issues: internal issues, such as manpower problems, labor objections, manager resistance, organizational conflicts and policies; also external issues, including social acceptability, legal aspects and government regulations. It takes in consideration whether the current work practices and procedures support a new system and social factors of how the organizational changes will affect the working lives of those affected by the system. Technical The technical aspect exploresif the project feasibility is within the limits of current technology and does the technology exist at all, or if it is available within given resource constraints (i.e., budget, schedule,...). In the technical feasibility the system analyst look between the requirements of the organization, such as, (I) input device which can enter a large amount of data in the effective time (II) Output devices which can produce output in a bulk in an effective time (III) The choice of processing unit depends upon the type of processing required in the organization. Schedule Feasibility Given his technical expertise, the analyst should determine if the project deadlines are reasonable whether constraints placed on the project schedule can be reasonably met. Some projects are initiated with specific deadlines. You need to determine whether the deadlines are mandatory or desirable. If the deadlines are desirable rather than mandatory, the analyst can propose alternative schedules. It is preferable (unless the deadline is absolutely mandatory) to deliver a properly functioning information system two months late than to

deliver an error-prone, useless information system on time! Missed schedules are bad, but inadequate systems are worse! We may have the technology, but that doesn't mean we have the skills required to properly apply that technology. True, all information systems professionals can learn new technologies. However, that learning curve will impact the technical feasibility of the project, specifically, it will impact the schedule. Economic Feasibility The bottom line in many projects is economic feasibility. During the early phases of the project, economic feasibility analysis amounts to little more than judging whether the possible benefits of solving the problem are worthwhile. As soon as specific Requirements and solutions have been identified, the analyst can weigh the costs and Benefits of each alternative. This is called a cost-benefit analysis. Q.2. What is the infeasible project? How are infeasible projects handled? Ans) A report can be infeasible in the following situations. : unnavailability of the technology. Cost over run. Unavailability of the equipment for the required technology. Inefficient man power. Improper planning. Unrealistic goal setting. Wrong predictability. Improper effort estimation. The infeasible projects can be handled by re-planning the requirements again. These projects can be handled by V & V method, i.e verification and validation ofeach step of the development phase. There are many methods to handle infeasible project. 1) Problem can be in project module. 2) Problem can be in designing or coding part of project.

3) We have to find actual solution problem in project it can be testing, coding or designing part of project. 4) The main cause of infeasible project is that, we dont follow SDLC steps Not all projects submitted for evaluation and review are judged acceptable. Requests that fail to pass feasibility tests are not pursued further, unless they are reworked and resubmitted as new proposals .in some cases, only part of a project is actually unworkable part of the project with another feasible proposal. In still other, preliminary investigation produce enough new information to suggest that improvements in management and supervision, not the development of information system, are the actual solutions to reported problems. Q.3. Elaborate the structured analysis Technique? Explain various tools of structured analysis? Ans) we have already mentioned that structured analysis, the major processing tasks (functions) of the system are analyzed, and the data flows among these processing tasks are represented graphically. Significant contribution to the development of the structured analysis techniques have been made by Gane and Saron [1979], and DeMarco and Yourdon [1978]. Structured analysis technique is based on the following essential underlying principals: Top-down decomposition approach Divide and conquer principal. Each function is decomposition independently. Graphical representation of the analysis result using flow diagram (DFDs) A DFD, in simple word, is a hierarchical graphical model of a system that shows the different processing activities or function that the system perform and the data interchange among these function. In the DFD terminology, it is useful to consider each function as a processing station (or process) that consumers some input data and produce some output data. DFD is an elegant modeling technique that turns out to be not only useful to represent the result of structured analysis of a

software problem but also useful for several other application such as showing the flow of document or item in an organization. There are several tools that helps in the structured analysis of the system. Data flow Diagram (DFD) A Data Flow Diagram (DFD) is a graphical representation normally designed by a system analyst and is used as a reference point by the programmer which portrays the "flow" of data through an information system. It is primarily used for the visualization of data processing for the structured design of an information system. It is common practice for a database designer to begin the process by drawing a context-level DFD, which shows the interaction between the system and outside entities. This context-level DFD is then "exploded" to show more detail of the system that is being modeled. Data Dictionary It is a structured repository of data. Although we give descriptive names to the data flows, process and data stores in a DFD, it does not give the details. Hence to keep the details of the contents of data flows, process and data stores we also require a Data Dictionary. This is a structured repository of data. It clearly documents the list of contents of all data flows, processes and data stores. The three classes to be defined are: Data Elements: - this is the smallest unit of data. Further decomposition is not possible. The ISO-11179 Standards give rules for creating Data Element names. Data Structure: - this is a group of Data Elements which together form as a unit in a data structure. Data flows and Data stores: - data flows are data structures in motion. Data Stores are data structures in store. (Data structures in a data store - a data store is a location where data structures are temporarily located.)

Structured English It uses uses logical constructs to carry out instructions for actions. Decision are made through the use of IF, THEN, ELSE and SO statements. It is highly correlated to the decision tree. It would not be be a misnomer to call it the pseudo code of the program. Decision Trees These clearly sketch out the logical structure based on some criteria. Based on the fulfillment of certain criteria, one can traverse from the top level node to the lowest level node. However, this representation of "traversing" can be easily depicted with the use of STRUCTURED ENGLISH. Decision Tables A decision table is a table of contingencies for defining a problem and the actions that need to be taken for it. It is a single representation of the relationships between conditions and actions; these pairs of condition sets and actions sets are known as rules. A condition is usually given a value of 'Y' for 'Yes, it is true", 'N' for 'No' and a dash for 'Do not care' in each rule. A decision tree fails to tell us what conditions to test. Where a decision table wins over a decision tree it that it can clearly call out the conditions that need to be tested. Whereas a decision tree fails to tell us what conditions to test, a decision table can clearly call out the conditions to test. Another advantage is that a decision table can be used to generate code in a procedural application language which is optimized for for performance based on the expected likelihood of a rule being valid in the data. Q.4 Find out the various design methodologies? How and when are they used? Ans) Design Methodology refers to the development of a system or method for a unique situation. Today, the term is most often applied to

technological fields in reference to web design, software or information systems design. Read this article to learn more about what Design Methodology is. Components of Design Methodology The key to Design Methodology is finding the best solution for each design situation, whether it be in industrial design, architecture or technology. Design Methodology stresses the use of brainstorming to encourage innovative ideas and collaborative thinking to work through each idea and arrive at the best solution. Meeting the needs and wants of the end user is the most critical concern. Design Methodology also employs basic research methods, such as analysis and testing. Design Methodology in Technology While Design Methodology is employed in many industries, it is commonly applied in technology fields, including those using the Internet, software and information systems development. Several Design Methodology approaches have developed in the technology industry. Each was a reaction to a different type of problem. Some common technology Design Methodologies include: Top Down Design or Stepwise Refinement: This starts from the end solution and works backwards, refining each step along the way.

Bottom Up Design: This Design Methodology starts with a foundation and works up towards a solution.

Structured Design: This is an industry standard. The technique starts by identifying inputs and desired outputs to create a graphical representation.

Structured Analysis and Design Technique: This approach utilizes a diagram to describe the hierarchy of a system's functions.

Data Structured Systems Development: Data structure determines the system structure in this Design Methodology.

Object Oriented Design: This methodology is based on a system of interacting objects.

Part-II

Q.5. Identify the role of system analyst and what are its attributes? Ans) The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization. Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following:1) System analysis It includes system's study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system. 2) System analysis and design: Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application. 3) Systems analysis, design, and programming: Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application. Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.

Business knowledge: As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses. Interpersonal skills: Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them Problem solving skills: A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.

Q.6. How system life cycle and system development methodology related? Ans) SDLC (System Development Life Cycle), just as the name implies, is defined as the process (as a whole) of developing system or software to meet certain requirements. It covers many activities; starts from understanding why the system should be built, studying the project feasibility, analyzing problems, choosing the system design and architecture, implementing and testing it, up to delivering the system as product to the user. SDLC is a process of gradual refinement, meaning that it is done through several development phases. Each phase continues and refines whats done in the previous phase. Commonly known development phases in SDLC are: Planning. It is the process of understanding why the system should be built and defining its requirements. It also includes feasibility study from several different perspectives, technical, economic, and organization feasibility aspects. Analysis. This phase includes activities such as problems identifying and analysis, and even predicting potential problems that may arise in the future regarding the system. The deliverables / products of this phase will drive how the system will be built and guide the developers works.

Design. System analysis leads to design decision, which exactly determines how the system operates in terms of process, data, hardware, network infrastructures, user interface, and other important factors in the system environment. Implementation. This is probably the most resource-, cost-, and time-consuming phase of all. This is when the system is actually built, tested, and finally installed. It also includes activities such as user training and system maintenance. Some experts like to separate them into different phases Deployment and Maintenance. However the four phases are the most commonly known and accepted steps. SDLC tries to achieve high quality system that meets or exceeds the requirements. Many methodologies have been developed and introduced in order to implement SDLC; some of them also try to improve other (previously) known methodology. Although each method follows certain different techniques and steps, they are all must go into the same development phases described above. There are many system development methods known today, but most of them basically are extended from three main methodologies which are Structured Design, RAD (Rapid Application Development), and Object-oriented Analysis and Design

Q.7. Explain why having a standardized system development process is important to an organization? Ans) Software, in last few decades, has captured a foremost arc of human life. It is now not a product of arbitrary and capricious practices and mere programming activities. Modern software products are engineered under the practice of using selected process techniques to improve the quality of a software development effort. This is based on the assumptions, subject to endless debate and supported by patient experience, that a methodical approach to softwaredevelopment results in fewer defects and, therefore, ultimately provides shorter delivery times and better value. The necessity of selecting and following a formal practice for software development is to provide desired discipline to deliver the quality expected for business success and avoiding the wastage of time, squander productivity, demoralization in developers,

etc. This article summarizes such needs of adopting formal software developmentmethodologies and standards. Like any other engineering products, software products are oriented towards customers and as in any other engineering disciplines; software engineering also has some structured processes and policies for softwaredevelopment. The documented collection of policies, methods and procedures followed by a development team or organization to practice software engineering is called its software development methodology (SDM) or systemdevelopment life cycle (SDLC). Latest software development methodologies are the organized structures of sequential and parallel activities imposed on the development of a software products. Process, in fact, is a series of definable, repeatable, and measurable tasks leading to a useful result. The benefits of a well-defined process are numerous. The expanding role of software in the information world forced attention upon the need of software development at acceptable speed and cost and on traceable time schedules. Software products need to be developed with assurance of acceptably high quality that can be maintained over a long period of time for accommodating the changing requirements of the user. The recognition of these needs has initiated considerable research work for enhancement of software process. Much of the research has addressed the overall characteristics and needs of software processes, focusing on such issues as process architectures, process behavioral characteristics, and how processes fit with higher-level organizational systems and characteristics. According to a report by Dunstan Thomas, for an SDP to be successful, it must be based on best practices, self-improving, easy to implement, acceptable by experienced software professionals, and adaptable to any size of project. In a conclusion of a theory developed by TCS, they define a good software development process to be able to view software development as a value added business activity and not merely as a technical activity. A good software development process should ensure that every product is checked to see if value addition has indeed

taken place and safeguard against loss of value once the product is complete. Such a process provides management information for appropriate control of the process. To define such a process, the following steps need to be followed: Identify the phases of development and the tasks to be carried out in each phase Model the intra and inter phase transitions Use techniques to carry out the tasks Verify and validate each task and the results Exercise process and project management skills

Q8. Why we planning an information system? How does it play a major role in reducing software development cost? Ans) Change is stressful. Good or bad, it adds tension to any office. Throw the word "computer" or "upgrade" or "Internet" into this equation, and stress can skyrocket. Plus, mission-based organizations (nonprofits, non-governmental organizations or NGOs, public sector organizations, civil society organizations, etc.) are often facing intense, even do-or-die deadlines -- so the stress of dealing with computers can sometimes seem too much. Introducing or adding computers to a mission-based organization, or upgrading software or hardware such an organization uses, will change the way staff at the organization access and manage information -- for the better, you hope. But without realistic expectations and a thoughtful strategy, a new system can create as many problems as it is supposed to solve. With all that said: success in using technology tools is driven by user attitude. Users who want to reach out, to make people feel informed and involved, who are committed to quality and timeliness, and who are ready to try something even at the risk of making a mistake are the peo-

ple who flourish using technology. People who hate change, don't like sharing information freely and continually, and don' like involving others in their work are those that struggle with technology. Your company Needs Planning:_ No matter what an agency's mission is, no matter what size an agency's staff or budget, no matter who an agency serves -- your agency needs a computer and Internet technology plan. Just as you should do a critical analysis and form a strategic plan for your fundraising plans, your staffing needs and your program activities, you need to evaluate your technology needs and create strategies to meet those needs. How your organization will access and use technology will effect just about every function of your agency, in fact. If you choose not to create a technology plan, you will find yourself in a constant state of reactive crisis management. So there! At the Philanthropy News Network's "Nonprofits and Technology" conference in Seattle in January 1999, a representative of CompuMentor (now TechSoup) offered advice that still holds true. He told attendees that technology plans are more than just hardware and software wish lists. They can help nonprofits:

become more effective in daily operations budget and spend money more effectively boost fundraising efforts buffer groups from the effects of staff turnover

He cited a 70/30 rule for technology funding used by many large companies and organizations: For every $1 budgeted for technology, 30 cents would be used for hardware and software purchases, with the remaining 70 cents used for training and support. It reducing software development cost