1. What is SDLC? SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance.

SDLC is also known as information systems development or application development. SDLC is a systems approach to problem solving and is made up of several phases 2. What is the primary role and duty of System Analysts? Primary duties: Designs data models, prepares screen mock-ups and system prototypes, logic diagrams and performs additional systems analysis functions and reviews functional areas to facilitate design and structural improvements to the Development Information System. Ensures that cross-training takes place among the the Development Information System analysts an all phases of their work including a comprehensive understanding of the Development Information System online systems, data models, data extraction, and other facets related to ongoing enhancements to the Development Information System and subsequent extraction of data for reporting, downloads and other purposes. Primary roles: Consultant Supporting expert Agent of change

3. Explain the differences among Methodologies, Techniques, and Tools. Tools: Software support that helps create models or other required project components Range from simple drawing programs to complex CASE tools to project management software

Techniques: Collection of guidelines that help analysts complete a system development activity or task Can be step-by-step instructions or just general advice

Methodologies: Comprehensive guidelines to follow for completing every SDLC activity Collection of models, tools, and techniques

4. There are several approaches for system development. Briefly discuss each one of these approaches.

Approach to system development 1. 2. 3. 4. 5. There are three strategies of IS development Process-oriented approach Data-oriented approach Object-oriented approach Process-oriented approach An strategy to IS development that focuses on how and when data are moved through and changed by an IS Data-oriented approach An strategy to IS development that focuses on the ideal organization of data rather than where and how data are used. Object-oriented approach A system development methodologies and techniques base on objects rather than data or process

Waterfall model The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. The advantage of waterfall development is that it allows for departmentalization and managerial control. The disadvantage of waterfall development is that it does not allow for much reflection or revision.

Spiral model: Breaks each project into smaller pieces, each with a different type of risk (Sources of risk: undefined requirements, complex technology, uncertain competitive environment) The project begins in the center of the spiral where project is still small, easy to manage and low in risk Then the project slowly expands The project starts out small, initially handling a few of the risks Then the project expands in next iteration to address more of the risks Eventually the system is completed (all risks addressed) Advantage: The iterative nature and focus on risk reduction The Parallel Model The Parallel Model attempts to address the problem of long delays between the analysis phase and the delivery of the system. Instead of doing the design and implementation in sequence, it performs a general design for the whole system and then divides the project into series of distinct subprojects that can be designed and implemented in parallel Once all subprojects are complete, the final integration of the separate pieces is delivered Primary advantages: Can reduce the schedule time required to deliver a system There is less chance of changes in the business environment causing rework Key disadvantages: Still suffers from problems caused by paper documentation A new problem: sometimes the subprojects are not completely independent; design made in one subproject may affect another and the end of the project may require significant integrative efforts Phased Development Model Breaks the overall system into a series of versions that are developed sequentially The analysis phase identifies the overall system concept. The project team, users and system sponsors categorize the requirements into a series of versions The most important and fundamental requirements are bundled into the first version of the system. The analysis phase then leads into design and implementation, but only with the set of requirements identified for version 1 Once version 1 is implemented, work begins on version 2. Additional analysis is performed on the basis of the previously identified requirements and combined with new ideas and issues that arose from users experience with version 1. Version 2 then is designed and implemented, and work immediately begins on the next version. This process continues until the system is complete

 Advantages: Quickly getting a useful system into the hands of users. Although it does not perform all the functions the users need, it helps them sooner to identify important additional requirements Disadvantages: The users begin to work with systems that are incomplete. It is critical to identify the most important and useful features and include them in the first version.

5. Discuss the steps involved when identifying and selecting projects and initiating and planning projects. The Process of Identifying and Selecting IS Development Projects Project identification and selection consists of three primary activities: 1. Identifying potential development projects 2. Classifying and ranking IS development projects 3. Selecting IS development projects Each of these steps is described below:

1. Identifying potential development projects. Organizations vary as to how they identify projects. This process can be performed by A key member of top management, either the CEO of a small- or mediumsized organization or a senior executive in a larger organization A steering committee, composed of a cross section of managers with an interest in systems User departments, in which either the head of the requesting unit or a committee from the requesting department decides which projects to submit (often you, as a systems analyst, will help users prepare such requests) The development group or a senior IS manager In sum, projects are identified by both top-down and bottom-up initiatives. The formality of the process of identifying and selecting projects can vary substantially across organizations. 2. Classifying and ranking IS development projects. The second major activity in the project identification and selection process focuses on assessing the relative merit of potential projects. As with the project identification process, classifying and ranking projects can be performed by top managers, a steering committee, business units, or the IS development group. Additionally, the criteria used when assigning the relative merit of a given project can vary. As with the project identification and selection process, the actual criteria used to assess projects will vary by organization. An important project evaluation method that is widely used for assessing information systems development projects is called value chain analysis. Value chain analysis is the process of analyzing an organizations activities for making products and/or services to determine where value is added and costs are incurred.

3. Selecting IS development projects. The final activity in the project identification and selection process is the actual selection of projects for further development. Project selection is a process of considering both short- and long-term projects and selecting those most likely to achieve business objectives. Additionally, as business conditions change over time, the relative importance of any single project may substantially change. Thus, the identification and selection of projects is a very important and ongoing activity. Initiating and planning: -

The second phase of the SDLC in which a potential IS project is explained and an argument for continuing with the project is presented. A detailed plan is also developed for conducting the remaining phases of the SDLC for the propose system. Output are: Detailed step work plan - high level system requirement assignment of team members
The initiating stage should include a plan that encompasses the following areas:

analyzing the business needs/requirements in measurable goals reviewing of the current operations financial analysis of the costs and benefits including a budget stakeholder analysis, including users, and support personnel for the project project charter including costs, tasks, deliverables, and schedule

Planning and design

After the initiation stage, the project is planned to an appropriate level of detail (see example of a flow-chart). The main purpose is to plan time, cost and resources adequately to estimate the work needed and to effectively manage risk during project execution. As with the Initiation process group, a failure to adequately plan greatly reduces the project's chances of successfully accomplishing its goals. Project planning generally consists of

determining how to plan (e.g. by level of detail or rolling wave); developing the scope statement; selecting the planning team; identifying deliverables and creating the work breakdown structure; identifying the activities needed to complete those deliverables and networking the activities in their logical sequence; estimating the resource requirements for the activities; estimating time and cost for activities; developing the schedule; developing the budget; risk planning; gaining formal approval to begin work.

Additional processes, such as planning for communications and for scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable. For new product development projects, conceptual design of the operation of the final product may be performed concurrent with the project planning activities, and may help to inform the planning team when identifying deliverables and planning activities. 9. Briefly discuss the guidelines for interface design. "Eight Golden Rules of Interface Design" are a guide to good interaction design. 1 Strive for consistency. Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout. 2 Enable frequent users to use shortcuts. As the frequency of use increases, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user. 3 Offer informative feedback. For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial. 4 Design dialog to yield closure. Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions. 5 Offer simple error handling. As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error. 6 Permit easy reversal of actions. This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions. 7 Support internal locus of control. Experienced operators strongly desire the sense that they are in charge of the system and that the

system responds to their actions. Design the system to make users the initiators of actions rather than the responders. 8 Reduce short-term memory load. The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions. 8. Explain the process of designing forms and reports and the deliverable for their creation. Designing Forms and Reports: System inputs and outputs are produced at the end of the analysis phase Precise appearance is not necessarily defined during analysis phase Forms and reports are integrally related to DFD and E-R diagrams

Designing Forms and Reports Key Concepts: -

Form A business document that contains some predefined data and may include some areas where additional data are to be filled in An instance of a form is typically based on one database record Report A business document that contains only predefined data A passive document for reading or viewing data Typically contains data from many database records or transactions

The Process of Designing Forms and Reports: User Focused Activity Follows a Prototyping Approach Requirements Determination: Who will use the form or report? What is the purpose of the form or report? When is the report needed or used? Where does the form or report need to be delivered and used? How many people need to use or view the form or report? Prototyping Initial prototype is designed from requirements Users review prototype design and either accept the design or request changes If changes are requested, the construction-evaluation-request cycle is repeated until the design is accepted

Deliverables and Outcome: Design specifications are major deliverables and contain three sections 1. Narrative overview 2. Sample design 3. Testing and usability assessment