• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/50

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

50 Cards in this Set

  • Front
  • Back
1. Discuss the issues the project manager must consider when assigning programming tasks to programmers.
Project managers must consider the complexity of the modules being programmed against the programmers available, as well as the programmer’s expertise and experience. Ideally, a project manager will be able to assign experienced programmers to the more complex modules, and the less experienced programmers to the less complex modules. If the programmer’s skill and expertise are not a good match for the project, the project manager may suggest additional training or mentoring to increase the programmer’s skill level.
2. If the project manager feels that programming is falling behind schedule, should more programmers be added to the project? Why or why not?
Adding programmers does not shorten the project time, and can actually increase it due to the increased communication and coordination that must take place on the programming team. When the team members have to spend time coordinating their work with others, they are not spending time programming, and their productivity diminishes.
3. Describe the typical way that project managers organize the programmers’ work storage areas. Why is this approach useful?
Project managers often set up three distinct areas in which programmers work. Each of these can be a directory on a server, a separate server, or different physical locations, which all the programmers have access to. The three areas are the development area, the testing area, and the production area. The development area is limited to files created during the development process. Once the files or programs are complete, they are moved to the testing area. This area is used to test the code. Often, code is moved from development, to test, then back to development when and if problems are identified. Once all errors have been corrected, the program then moves to the production area.
4. What is meant by change control? How is it helpful to the programming effort?
Change control is the act of coordinating a program as it changes throughout the construction process. One technique associated with change control is a program log, which has programmers indicating ‘signing out’ module of code to work on, then ‘signing in’ modules of code when complete. This aids not only in understanding where in the construction process a module lies, but also in ensuring that duplicate effort is not being made, that code is complete before testing, etc.
5. Discuss why testing is so essential to the development of a new system.
The cost associated with finding and fixing a major software bug after a system has been implemented is very high. Therefore, thorough testing of the system is imperative. It is not enough to have written a program; it also needs to be tested completely to verify it performs as specified.
Explain how a test case relates to a test plan.
A test is a particular aspect of the system that needs to be evaluated. The test plan outlines all of the tests that need to be performed on the system. Test cases are the sample data that will be run through or entered into the system. A test will state its objective, list the test cases that will check the desired feature or function, and define the expected results. Actual test results will also be recorded on the test.
What is the primary goal of unit testing?
A unit test checks a single program or program module to ensure that it performs the function designated in the program specification.
How are the test cases developed for unit tests?
Test cases come from the program specification. Based upon the description of what the program is supposed to do, test cases can be developed that verify that the program actually does those things.
What is the primary goal of integration testing?
Integration testing evaluates whether a set of modules or programs work together successfully. The span of an integration test is more broad than unit testing, but not as broad as system testing.
Describe the four approaches to integration testing.
The purpose of the user interface testing is to have the user test each interface function. The purpose of the use scenario testing is to have the tester test each use scenario. The purpose of the data flow testing is to have the tester test each process using a step-by-step method. The purpose of the system interface testing is to test the exchange of data among systems.
How are the test cases developed for integration tests?
Test cases are designed to check the entire user interface; check the use cases developed earlier to verify their functioning; check the performances of all the processes outlined on the physical DFDs; and check the system interfaces outlined on the physical DFDs.
Compare and contrast black box-testing and white-box testing.
Black box testing checks the performance of a program or program module by starting with a particular input and generating an output. By knowing what the output should be from that particular input (based upon program specifications), the program can be assessed. White box testing evaluates the actual code in the program or program module. Review of the source code can reveal problems or incorrect assumptions that need to be corrected, particularly when the logic is complex.
Compare and contrast system testing and acceptance testing.
System testing evaluates the entire system, not only to verify that it runs without error or breakdown, but also that it fulfills the business requirements of the system.

Acceptance testing is performed with the system users to confirm that the system is complete, that it meets the needs of the business area, and that it is acceptable to the users.
Describe the five approaches to systems testing.
The purpose of requirements testing is to determine whether the original business requirements have been met. The purpose of usability testing is to determine how convenient the system is to use from a user standpoint. The purpose of security testing is to test disaster recovery processes and unauthorized access processes. The purpose of performance testing is to examine the system’s ability to perform under high loads. The purpose of documentation testing is to determine the accuracy of the current documentation.
Discuss the roles users play in testing.
Users are instrumental in acceptance testing. As this is the first time the users experience the functionality of the system, it is hoped that the system has undergone an in depth systems testing to ensure that the end product is of the highest quality possible and that attention has been paid to usability of the system product. While the new product may meet all the business requirements, if it does not pass acceptance testing by the users, then the system might very well be considered a failure.
What is the difference between alpha testing and beta testing.
The term ‘alpha testing’ is the preliminary stage of acceptance testing in which the users work with and test the system using /dummy’ data. In the ‘beta testing’ stage of acceptance testing, the users begin to use the system with ‘live’ data, but are closely monitored for errors and problems.
Explain the difference between user documentation and system documentation.
System documentation is created for the system developers, in order to document what was done during the development process, and to help them maintain the system after its installation. User documentation is designed specifically for the system users to help them work successfully with the system.
What are the reasons underlying the popularity of online documentation?
Online documentation is popular for several reasons. First, it is often easier to find information using the search index. Second, it is possible to present help information in multiple formats, increasing its utility to the end users. Third, presenting information while interacting with the computer permits novel ways of presenting the information to be employed. Fourth, the cost of distributing online documentation is considerably less than printing and distributing paper manuals.
Are there any limitations to online documentation? Explain.
One problem is simply that many users are unfamiliar with seeking information online. We have all been exposed to paper manuals, and they are more familiar to many users. Also, online documentation is not portable. It is not possible to take an online help system home and review it before using a system as one could with a procedure manual or tutorial.
Distinguish between these types of user documentation: reference documents, procedures manuals, and tutorials.
Reference documents are the help system that explains how to perform a specific task or function. Procedures manuals describe how to accomplish a particular business task with the system, often involving several steps. Tutorials are training systems that teach the user how to use the system.
Describe the five types of documentation navigation controls?
A table of contents organizes the information in a logical form. An index provides access to the help topics through keywords listed in the index. Test search allows the user to search for any topics that match the text entered by the user. An intelligent agent can be used to assist the user in the search. Links can be established that permit the user to jump between related topics.
What are the commonly used sources of documentation topics? Which is the most important? Why?
One source is the set of commands and menus in the user interface. A second source is the use cases for the system that outline commonly performed tasks. A third source are the important terms associated with the system. The most important source is probably the use cases for the system, since these define how to perform needed functions with the system.
What are the commonly used sources of documentation navigation controls? Which is the most important? Why?
The table of contents is developed directly from the logical structure of the documentation topics. Index terms can come from the user interface commands and functions, the major concepts (entities) of the system, the business tasks performed by the system user, and synonyms or alternate terms for the above.
What do you think are three common mistakes made by novice systems analysts during programming and testing?
While an analyst usually has little to do with the actual programming, they may certainly assist project managers in understanding the potential pitfalls in this phase:
• Using low-cost personnel, which usually results in lower production or a low quality of work
• Failing to control changes in code, either allowing scope creep, or not organizing the work through the development process
• Failing to take the time to plan and conduct testing in terms of unit, integration, system, and acceptance
What do you think are three common mistakes made by novice analysts in preparing user documentation?
• Leaving documentation to the end and not having sufficient time to do it well.
• Failing to test the documentation with users to verify its usability.
• Failing to develop the documentation in terms of tasks that users need to perform.
In our experience, documentation is often left to the very end of projects. Why do you think this happens? How could it be avoided?
It may be that documentation is viewed as less "important" than other aspects of system development; consequently, it gets left to the very end of the project. Also, some analysts may be uncomfortable with the writing that must be done to produce documentation, so it is avoided as long as possible. To avoid a mad rush to churn out documentation at the end, the team should develop notes on documentation topics throughout the project. These notes can then be assembled into polished documentation.
In our experience, few organizations perform as thorough testing as they should. Why do you think this happens? How could it be avoided?
The problem may be due to the fact that the team is up against a deadline and does not have enough time to perform thorough testing. When in a hurry, the testing tends to be ad hoc rather than carefully planned. As a result, errors can be easily overlooked. As the systems analysts complete work on program specifications, they should immediately begin developing test plans, so that complete and thorough testing is structured for the programmers as they complete the programming tasks.
Develop several guidelines to use to develop good documentation? Hint: think about behaviors that might lead to developing poor documentation.
• Consider what documentation the users need and understand how they will use the documentation.
• Develop a set of documentation topics; tasks to be performed, description of commands, and definition of terms.
• Develop a set of documentation navigation controls to support the documentation topics; table of contents, index, text search, intelligent agents, and links between topics
• Develop a prototype of the user interface and have users test it for navigability and usability
What are the three basic steps in managing organizational change?
According to Kurt Lewin, change is a three-step process: Unfreeze - preparing people and the organization to break out of their current way of doing things; Move - transition from the old to the new way of doing things; and Refreeze - establish the new system as the way things are done.
What are the major components of a migration plan?
One part of the migration plan is the technical plan, which discusses how the new technology will be implemented in the organization. The other major part of the migration plan is the organizational plan, which helps users adjust to and adopt the new system.
Compare and contrast direct conversion and parallel conversion.
Both conversion strategies focus on the way in which users are switched over to the new system. Direct conversion is an abrupt change: the old system is ‘unplugged’ and the new system is turned on. The users have no choice but to work with the new system. In the parallel conversion strategy, the new system is turned on, but the old system is used simultaneously for a time. Clearly, the direct strategy is more risky because there is no fall-back if significant system bugs are discovered. With parallel conversion, the old system will still be available if there is a major bug discovered in the new system. However, the cost and extra work of using both systems simultaneously must be considered.
Compare and contrast pilot conversion, phased conversion, and simultaneous conversion.
These terms refer to how the organizational locations are transitioned from the old system to the new system. In a pilot conversion, one location or part of the organization is converted first. The system is installed at that location and is used for a time until it appears to be stable (initial bugs discovered and fixed). Then the system is installed at the other locations. The pilot location serves as a shakedown site for the system. In the phased conversion approach, the system is installed sequentially at different locations. Gradually, the conversion process spreads across all locations until all have been converted. Simultaneous conversion means that all locations are converted at the same time. With this strategy, there is no period in which some locations are using the old system and other locations are using the new system.
Compare and contrast modular conversion and whole-system conversion.
Whole system conversion means that the entire system is installed at one time. This is the most common circumstance. Modular conversion, in which the various modules or components of the system are installed gradually over time, is less common, but can be used if the system is large and complex and has been designed as a set of independent system modules.
Explain the trade-offs among selecting between the types of conversion.
Direct conversion will be the quickest and lowest cost conversion style. Parallel conversion reduces risk, but costs much more and takes more time to complete.

Pilot conversion is the least risky way to convert organizational location. By debugging the system at the pilot location, the installation at the other locations should go smoothly. Phased conversion adds a little more risk in that time is not devoted to debugging the system totally before moving on to other sites. Phased conversion takes longer, however, than pilot conversions. The simultaneous approach will be the highest risk and most expensive approach of the three, but takes the least amount of time.

Whole system conversion is most risky, especially if the system is large and complex, but completes the conversion in the shortest amount of time. Modular conversion reduces risk somewhat because the system is implemented gradually. It adds cost and time to the process, however.
What are the three key roles in any change management initiative?
The project sponsor is the person or organizational unit that wants the change. The change agent is the person or group who leads the change effort. The potential adopter is the person or group who must actually do the changing.
Why do people resist change? Explain the basic model for understanding why people accept and resist change.
Resistance to change is a typical response to an externally-imposed need to change. In determining their own response to a need to change, people will evaluate (implicitly or explicitly) the potential value of the new system (expected costs versus expected benefits), and will also assess their perceptions of the expected costs and benefits of transitioning from the status quo to the new situation. Only if the perceived benefits of the change and the perceived benefits of the transition outweigh the perceived costs will people’s resistance to change be low.
What are the three major elements of management policies that need to be considered when implementing a new system?
One element is the organization’s standard operating procedures. These procedures define proper behavior, and communicate behavioral norms to the employees. The second element is defining measurements and rewards, which explains what is important to the organization (worth measuring) and how desired behavior will be reinforced with rewards. The third element is resource allocation. By allocating resources in certain ways, management can send both actual and symbolic messages to the organization.
Compare and contrast an information change management strategy with a political change management strategy. Is one better than the other?
Both of these change management strategies are focused on convincing the target adopters of the change that the benefits of the change outweigh the costs of the change. An informational approach may work when those change benefits really do exceed the change costs, but the target adopters may not have enough information to realize it. The informational strategy seeks to give them that information and encourage adoption because they now perceive the advantages of the new system. With the political change management strategy, organizational power is used to motivate change, not information. The change may not actually provide a direct benefit to the target adopters, but it may benefit the organization as a whole. In this case, political power may be employed to lead the target adopters to the conclusion that they should comply with the change (or pay a penalty).
Explain the three categories of adopters you are likely to encounter in any change management initiative.
There will usually be a small group (20-30 percent) who are ready adopters. These individuals quickly adopt the change. Another group of about the same size (20-30 percent) will be resistant adopters. They will refuse to accept the change and may actively fight against it. The remaining larger group is the reluctant adopters. These people will go which ever way the organizational wind is blowing.
How should you decide what items to include in your training plan?
Focus on helping the users to accomplish their jobs, not just on how to use the system. Focus on the system as it exists in its organizational context of getting day to day business done. Keep the emphasis on what the user needs to do; don’t get caught up in what the system can do. Referring to the use cases can be helpful here, since if we design our training to cover the use cases, we should be able to make the users very comfortable with the system for their routine tasks.
Compare and contrast three basic approaches to training.
Classroom training is the traditional approach to training in which a number of people are trained simultaneously with one instructor. One-on-one training puts one trainer with one student at a time. Computer-based training uses a CD or Web-based training program delivered to students as needed. Classroom training is moderately effective. Its costs are moderate, and it is fairly effective, especially since it is the method that many people are most familiar with. One-on-one training is very effective, but is expensive to deliver and reaches only a few people. Computer-based training is very costly to develop, but is inexpensive to disseminate after development. It can reach a large number of people, but its effectiveness can be limited.
What is the role of the operations group in the systems development life cycle (SDLC)?
The operations group takes the system that the development team has created and makes it work for the organization on a daily basis.
Compare and contrast two major ways to provide system support.
System support is focused on helping users understand how to perform tasks and answering user questions. This can be accomplished with online support such as reference documentation and help screens, and also with special web-sites that answer frequently asked questions. The goal here is to enable the user to find the answer to his/her question without talking to a human. When human help is needed, it is usually provided through a help desk. Help desks can provide human response to questions for the entire organization.
How is a problem report different from a change request?
A problem report documents a problem that has been encountered with the system that cannot be immediately resolved. The problem report will usually be passed to an application specialist, who will attempt to clear up the problem. If he/she cannot resolve the problem, then it is likely that a system bug has been encountered. At this point, the problem report becomes a change request, which is used to inform the system maintenance group that an unresolvable problem has been discovered that probably requires a system fix.
What are the major sources of change requests?
The most common source of change requests is the problem reports from the operations group that identify bugs encountered in the system. A second source is the system users, who submit ideas for minor changes and enhancements to the system. Third, other systems development project may have an effect on a system, and change requests may result in order to integrate the systems. A fourth source is senior management, who may trigger change requests in order to tailor the system to the organization’s business strategy.
Why is project assessment important?
Project assessment is important because it enables the team and the IS organization to learn from its experience, and hopefully improve future systems development projects with the benefit of that experience.
How is project team review different from system review?
The project team review summarizes performance by the team members. Its purpose is to help the team members better understand what was done well and what needs improvement. The system review looks back at the projected costs and benefits for the system, and assesses whether these costs and benefits have been achieved following implementation. Estimates of future project costs and benefits can be improved if the accuracy of each project’s estimates is evaluated.
What do you think are three common mistakes that novice analysts make in migrating from the as-is to the to-be system?
• Failure to fully consider the risks associated with the different conversion strategies. May just blithely assume direct conversion is the way to go.
• Failure to adequately train the end users for the work they must perform on the new system.
• Failure to manage the process of change that will be necessary with the new system.
21. Some experts argue that change management is more important than any other part of the SDLC. Do you agree or not? Explain.
Change management is essential in helping to ensure that the system is accepted and used in the organization. While change management cannot substitute for a system that does not do what it is supposed to do, failing to consider the required process of change may result in even the best system being rejected by the users.
In our experience, change management planning often receives less attention than conversion planning. Why do you think this happens?
Most systems analysts are more comfortable with the technical aspects of the system rather than the behavioral (people) aspects. As a result, the assumption is made that the people will just adapt to whatever is thrown at them. This is a poor assumption, and attending to change management planning can make a dramatic difference in the ultimate success or failure of the new system.