Sunday, 22 September 2013

Software Engineering Exam papers

1)    Which type of risk factor is most likely to cause problems for a software project developing commercial software?

        (a)     Inadequate user documentation
        (b)     Litigation expense
        (c)     Low productivity
        (d)    Cancellation of project


2)    Defect prevention is defined as:

        (a)     Finding and fixing errors after insertion
        (b)     Finding and fixing errors before release but after insertion
        (c)     Finding and fixing errors after release
        (d)    Avoiding defect insertion


3)    Product quality is defined as:

        (a)     Delivering a product with correct requirements
        (b)     Delivering a product using correct development procedures
        (c)     Delivering a product which is developed iteratively
        (d)    Delivering a product using high quality procedures


4)    Which of the following is NOT a main reason to undertake software quality assurance activities:

        (a)     Reduce software personnel turnover
        (b)     Legal liability
        (c)     Insistence by the user on a satisfactory software quality assurance programme
        (d)    Marketing reasons


5)    Which type of risk factor is most likely to cause problems for a software project which develops military software?

        (a)     Unused or unusable software
        (b)     Legal expenses
        (c)     Excessive paperwork
        (d)    High maintenance costs


6)    The main goal of quality assurance is:

        (a)     Set coding standards.
        (b)     Improve software project management
        (c)     Reduce the technical and programmatic risks in developing the software
        (d)    Specify corrective actions.


7)    Software interoperability is:

        (a)     The ability of a software system to work on different hardware platforms.
        (b)     The ability of a software system  to work under different operating systems.
        (c)     The ability of a software system to exchange information with other software systems and to use the exchanged information.
        (d)    The ability to replace a software system with another software system that has similar functionality
       

8)    With respect to software metrics, which statement is NOT true:

        (a)     A indirect measure focuses on attributes of a project which can be measured by examining a process, product or resource
        (b)     A direct measure focuses on attributes of a project which can be measured by examining a process, product or resource
        (c)     External attributes are always measured indirectly
        (d)    Lines of code is a direct measurement


9)    Which of the following statements is NOT true.

        (a)     Coding standards address naming of constants.
        (b)     Coding standards address the number of errors encountered per 1000 lines of code.
        (c)     Coding standards address layout of code text.
        (d)    Coding standards address the use of program comments.


10)  Measures for a project are given as:

                 Effort:  12
                 Cost:   £24,000
                 Thousand lines of code: 600k
                 Defects:  120

        What is the productivity of the project?

        (a)     0.1
        (b)     2000
        (c)     5
        (d)    50

11)  Which of the following statements is NOT true:

        (a)     A good design methodology should provide a clear division of design from implementation
        (b)     A good design methodology should not promote a top-down decomposition strategy.
        (c)     A good design methodology should encourage phased development of the software
        (d)    A good design methodology should help to minimise future maintenance.


12)  Formal Reviews seek to:

        (a)     Identify system faults, but not to attribute blame or seek solutions
        (b)     Identify system faults, attribute the source of errors, but not seek solutions
        (c)     Identify system faults, attribute the source of errors and seek solutions
        (d)    Identify system faults, seek solutions, but not to attribute blame


13)  Using the following table for function point weightings:

Factors
Weights
Simple
Average
Complex
Number of user inputs
3
4
6
Number of user outputs
4
5
7
Number of user inquiries
3
4
6
Number of files
7
10
15
Number of external interfaces
5
7
10

        A system being developed has the following characteristics:

Number of user inputs               10 (simple)
Number of user outputs             7 (simple)
Number of user inquiries            3 (average)
Number of files                          6 (average)
Number of external interfaces   1 (complex)

        The function point count for the system is:

        (a)     27
        (b)     31
        (c)     58
        (d)    140


14)  Which form of software development model is most suited to a system where all the requirements are known at the start of a project  and remain stable throughout the project.

        (a)     Waterfall model
        (b)     Incremental model
        (c)     Evolutionary model
        (d)    Spiral model



15)  What type of software development model is shown in the following diagram:

        (a)     Waterfall model
        (b)     Incremental model
        (c)     Evolutionary model
        (d)    Spiral model



16)  Which of the following statements is NOT true:

        (a)     Requirements must be testable
        (b)     Requirements must  be concerned with system functionality only
        (c)     Requirements must be complete
        (d)    Requirements must be unambiguously stated


17)  The following software configuration diagram states that:

        (a)     Version 1.3 is replacing version 2.1
        (b)     Version 1.3 is evolving in parallel with the versions of the new release 2.1
        (c)     Version 1.3 is the combination of versions 2.1 and 1.4
        (d)    Only one of versions 2.1 and 1.4 should be developed.



18)  Which of the following is NOT part of a software quality assurance plan:

        (a)     Reference documents
        (b)     Configuration Action
        (c)     Supplier Control
        (d)    Customer Control



19) Who of the following is NOT usually present in a technical review

        (a)     User
        (b)     Quality Engineer
        (c)     The programming tools supplier
        (d)    Specialist with knowledge of the application


20)  The following diagram shows that:

        (a)     Specification is completed before delivery
        (b)     Specification is not completed until delivery
        (c)     Specification is part of delivery.
        (d)    Specification is an ongoing activity.





US216
(7)


SECTION B: You must answer 1 question in this section


21)  Answer all parts

        (a)     Explain the main differences between software review and software inspection or walkthrough.
(6 marks)

        (b)     Lines of code (LOC) and function point counts (FPC)  are two measures of the size of a system.  Explain the advantages and disadvantages of using these two metrics for measuring systems.
(6 marks)

        (c)     Produce a critical path network, showing the earliest start times and latest start times for each task, using the data in the table below.

Task code
Task name
Duration
Starts after completion of task(s)
PLAN
Plan project
3

REQ
Capture requirements
8
PLAN
AGREE
Agree requirements with customer
2
REQ
DESIGN
Design system
10
AGREE
CODE
Code system
12
DESIGN
ID
Identify subcontractors
3
DESIGN
BUY
Buy-in subcontractor code
5
ID
INTEG
Integrate code and buy-in code
6
CODE, BUY
TRAIN
Train staff
5
DESIGN
REL
Release system
4
INTEG, TRAIN

(13 marks)


22)  Answer all parts

        (a)     What are the main risk factors which may be encountered in the development of software?
(8 marks)

        (b)     Give a suitable definition of software quality and briefly describe the rationale for your definition.
(6 marks)

        (c)     Why should an organisation be concerned about software risk factors and software quality?
(11 marks)

23)  Answer all parts

        (a)     How does development of software differ from that of hardware from a quality viewpoint? 
(9 marks)

        (b)     What are the main objectives of configuration management and version control?
(6 marks)

        (c)     What are ‘throwaway’ prototypes and ‘evolutionary’ prototypes? How can production of a prototype be controlled and why is this important?
(10 marks)



Wednesday, 23 January 2013

Chapter 5: Determining Object-Oriented Systems Requirements




True-False Questions

1.      A systems requirement identifies how a systems solution is supposed to be accomplished.

Answer:    False                Page Reference:  132                         Difficulty:  Moderate


2.      Corporate traditions and habits are valid constraints limiting the types of questions that a systems analyst should ask during interviews.

Answer:    False                Page Reference:  132                         Difficulty:  Moderate


3.      JAD and prototyping are techniques for keeping analysis efforts at a minimum while maintaining maximum effectiveness.

Answer:    True                 Page Reference:  134                         Difficulty:  Moderate


4.      When preparing for an interview all possible questions should be written down beforehand, and the interview itself should be completely scripted.

Answer:    False                Page Reference:  134-135                  Difficulty:  Moderate


5.      If an interviewer has very limited knowledge of the subject’s job and usage patterns, it is best to start with open-ended questions.

Answer:    True                 Page Reference:  137                         Difficulty:  Moderate


6.      The interviewer should avoid telling the interviewee about the likes and dislikes of other users of the system.

Answer:    True                 Page Reference:  137                         Difficulty:  Moderate




7.      The requirements determination interview is a good time for the systems analyst to describe to the user the way that the new system will function.

Answer:    False                Page Reference:  138                         Difficulty:  Moderate


8.      Whereas interviews provide objective information, observation is a source of more subjective information.

Answer:    False                Page Reference:  139                         Difficulty:  Moderate


9.      A written work procedure document is often used by the systems analyst as a guide for determining user likes and dislikes.

Answer:    False                Page Reference:  140-141                  Difficulty:  Moderate


10.  Follow-up and probing capabilities are generally higher for direct observation than for document analysis.

Answer:    True                 Page Reference:  144                         Difficulty:  Moderate


11.  Conflicts and disagreements between different users are likely to become readily apparent when performing joint application design.

Answer:    True                 Page Reference:  144-145                  Difficulty:  Moderate


12.  JAD sessions are usually held in remote sites and specialized conference rooms.

Answer:    True                 Page Reference:  144-145                  Difficulty:  Moderate


13.  The person who organizes and leads JAD sessions is called a sponsor.

Answer:    False                Page Reference:  145                         Difficulty:  Moderate


14.  Systems analysts and the IS staff are major sources of information and should be vocal when participating in a JAD session.

Answer:    False                Page Reference:  145                         Difficulty:  Moderate


15.  A Joint Application Design session is unlikely to involve heated discussions or disagreements.

Answer:    False                Page Reference:  146                         Difficulty:  Moderate


16.  Prototyping enables users to experience working with a proposed information system and modify requirements accordingly.

Answer:    True                 Page Reference:  147-148                  Difficulty:  Moderate


17.  An advantage of prototyping is that they are easy to generalize and adapt for use by multiple people in an integrated environment.

Answer:    False                Page Reference:  148                         Difficulty:  Moderate


18.  Agile usage-centered design is more similar to the traditional system development cycle than to system prototyping.

Answer:    False                Page Reference:  148                         Difficulty:  Moderate


19.  Agile usage-centered design is most likely to be successful if the development teams are small.

Answer:    True                 Page Reference:  148                         Difficulty:  Moderate


20.  Inclusion of a venting session and use of 3X5 task cards are characteristic elements of the agile usage-centered design methodology.

Answer:    True                 Page Reference:  148                         Difficulty:  Moderate


21.  eXtreme programming involves a clear separation of planning, analysis, design, and construction into separate project phases.

Answer:    False                Page Reference:  149                         Difficulty:  Moderate


Multiple-Choice Questions


22.  The systems analysis portion of a development project involves all the following tasks EXCEPT:

a.       creating design elements.
b.      determining systems requirements.
c.       selecting  design strategies.
d.      structuring systems requirements.

Answer: a                          Page Reference:  131                         Difficulty:  Moderate


23.  Requirements structuring involves creation of:

a.       use cases and class diagrams.
b.      interview questions and questionnaires.
c.       project goals and objectives.
d.      transcripts and frames.

Answer: a                          Page Reference:  132                         Difficulty:  Moderate


24.  Which of the following is NOT a deliverable resulting from the requirements determination process?

a.       Interview transcripts
b.      Documentation of existing system
c.       Procedure manuals
d.      Project schedule

Answer: d                         Page Reference:  133                         Difficulty:  Moderate


25.  Which of the following does NOT enhance the effectiveness of a systems analyst’s interviewing process?

a.       Note taking
b.      Planning
c.       Advocacy
d.      Neutrality

Answer: c                          Page Reference:  135, 137-138                      Difficulty:  Moderate


26.  The agenda for an interview is a list of:

a.       facts about the interviewer’s experience and opinions.
b.      topics to cover and approximate time limits.
c.       major objectives and goals regarding what needs to be accomplished.
d.      specific questions and answers.

Answer: b                         Page Reference:  135-136                  Difficulty:  Moderate


27.  Which of the following is an advantage of open-ended interview questions over close-ended interview questions?

a.       Better control of question flow
b.      Lead to probing questions
c.       Increased confidentiality
d.      Requires less time commitment

Answer: b                         Page Reference:  137                         Difficulty:  Moderate


28.  Which of the following is considered to be an open-ended question?

a.       True-false
b.      Multiple-choice
c.       No options specified
d.      List ranking

Answer: c                          Page Reference:  137                         Difficulty:  Moderate


29.  As a rule of thumb, the maximum time delay that a systems analyst can afford to wait for keying and organizing interview notes before memory about the interview fades is:

a.       thirty minutes.
b.      two hours.
c.       forty-eight hours.
d.      one week.

Answer: c                          Page Reference:  138                         Difficulty:  Moderate





30.  Which of the following is a rationale for utilizing direct observation as an information gathering technique?

a.       Subject’s desire for confidentiality
b.      Subject’s inaccuracy in self-reporting
c.       Desire for open-ended discussion
d.      Availability of system usage data

Answer: b                         Page Reference:  138                         Difficulty:  Moderate

31.  Studying the organization’s written documents is a promising way of obtaining information about all of the following EXCEPT: 

a.       policies and procedures.
b.      mission and goals of the company.
c.       usage habits and behaviors of individuals.
d.      reports of system performance issues.

Answer: c                          Page Reference:  139-140                  Difficulty:  Moderate


32.  A written work procedure document is most useful as a source of requirements information when the formal system and the informal system are:

a.       very different.
b.      nearly identical.
c.       nonexistent.
d.      noncompliant.

Answer: b                         Page Reference:  140                         Difficulty:  Hard


33.  The type of written document that is most likely to be directly translated into a screen image of an application program is a(n):

a.       data dictionary.
b.      work procedure.
c.       organization chart.
d.      business form.

Answer: d                         Page Reference:  141-142                  Difficulty:  Hard




34.  Information obtained via document analysis is likely to be ____________ than information obtained via direct observation.

a.       richer
b.      older
c.       timelier
d.      more time-consuming

Answer: b                         Page Reference:  144                         Difficulty:  Hard


35.  Joint application development is best described as:

a.       highly structured and group-oriented.
b.      iterative and rudimentary.
c.       inexpensive and low-key.
d.      dispersed and long-term.

Answer: a                          Page Reference:  144-145                  Difficulty:  Hard


36.  Note taking during a JAD session is the responsibility of the:

a.       session leader.
b.      systems analyst.
c.       scribe.
d.      sponsor.

Answer: c                          Page Reference:  145                         Difficulty:  Easy


37.  During a Joint Application Design session, the IS personnel should spend most of their time:

a.       venting.
b.      listening.
c.       explaining.
d.      scribing.

Answer: b                         Page Reference:  145                         Difficulty:  Easy


38.  Which of the following factors support use of prototyping as a means for requirements determination?

a.       Many users and stakeholders are involved.
b.      Formal systems requirements documentation is desired.
c.       The system is to be integrated and shares data with other systems.
d.      User requirements are not clear or well-understood.

Answer: d                         Page Reference:  148                         Difficulty:  Moderate


39.  Prototyping is similar to OOSAD in the sense that it is characterized by:

a.       extensive up-front analysis and planning.
b.      iterative and incremental development.
c.       polymorphic system components.
d.      class generalization and inheritance.

Answer: b                         Page Reference:  148                         Difficulty:  Moderate


40.  Which of the following requirements determination approaches is characterized by involvement of 2-person programming teams?

a.       Agile usage-centered program design
b.      Joint Application Design
c.       eXtreme programming
d.      System prototyping

Answer: c                          Page Reference:  149                         Difficulty:  Moderate


41.  All of the following are phases of the eXtreme programming Planning Game EXCEPT:

a.       venting.
b.      exploration.
c.       commitment.
d.      steering.

Answer: a                          Page Reference:  149                         Difficulty:  Moderate


42.  Unlike the Planning Game between Business and Developers, the Iteration Planning Game:

a.       involves the use of story cards.
b.      does not include an exploration phase.
c.       iIs not an aspect of eXtreme programming.
d.      is played only by programmers.

Answer: d                         Page Reference:  149                         Difficulty:  Moderate



Essay Questions


43.  Describe the personal characteristics that facilitate a systems analyst’s efforts at determining requirements. 

Answer:

The systems analyst should be impertinent, impartial, open-minded, meticulous, and creative. Impertinence does not mean being disrespectful, but it does mean the systems analyst should question everything, similar to how a detective would work when solving a mystery. The systems analyst should also be impartial, not advocating or justifying any position or opinion but instead taking all viewpoints into account. In maintaining an open-minded attitude, the systems analyst relaxes constraints, at first assuming everything is possible. He should not be limited by tradition or habit. Meticulousness means paying attention to detail, and making sure that every fact fits with every other fact. When contradictions, imprecision, or inconsistencies are discovered, it is the systems analyst’s job to resolve these. Finally, a systems analyst should be creative, and should be able to look at the organization in new ways, to reframe problems in a new light, which helps to generate innovative solutions.

Page Reference:  132-133                  Difficulty:  Moderate


44.  Describe the deliverables that should result from the requirements determination process.  What sort of information should they contain, and what understanding should have been gained? What is the next step after requirements determination? Finally, what condition can result from spending too much time in requirements analysis?

Answer:

Requirements determination produces deliverables containing the information gained during interviews, surveys, observation, and other requirements gathering activities. This information takes many forms, such as interview transcripts, observation notes, survey analyses, forms, reports, prototypes, and others. By the end of this process, the systems analyst should understand: business objectives; the information and data required for individuals and organizations to perform their tasks; rules, procedures and policies; and events affecting data values and systems states. All of this information serves as input to the next phase of systems analysis, requirements structuring. Care must be taken, however, not to get bogged down in analysis paralysis, particularly for object-oriented systems, which place a premium on speed and iteration.

Page Reference:  133-134                  Difficulty:  Moderate




45.  Compare and contrast the three traditional approaches for determining systems requirements. Briefly identify and define each of these approaches, and then discuss the factors that would lead an analyst to choose one approach over another.

Answer:

The four main approaches for requirements determination are interviews, direct observation, and document analysis. An interview is a discussion, involving a combination of open-ended and closed-ended questions that takes place between the systems analyst and another stakeholder such as a user or manager. With direct observation, the systems analyst watches and listens as the user or manager works with an existing system or performs the tasks in his or her job. In documents analysis, the systems analyst studies manuals, organizational policy documents, procedures documents and memos in order to glean information regarding system requirements. There are a variety of factors that influence which approach to use, such as expense, information richness, time commitment, confidentiality, probing, subject involvement, and potential audience. Interviews and direct observation tend to require more time and expense than document analysis, but tend to provide richer information and allow for better probing and follow-up opportunities. Confidentiality is limited with observation and interviews, and tends to be greater with document analysis (although this depends on the nature of the document). With interviews and observation, the time expense and need for subject involvement is so high that potential audience is limited, which is not the case with document analysis. In the final analysis, a requirements determination effort will probably involve some combination of all three approaches.

Page Reference:  134-144                  Difficulty:  Hard


46.  Discuss some general guidelines that should be followed when conducting interviews for requirements determination.  In doing so, discuss characteristics of good and bad questions, and identify some pitfalls to avoid.

Answer:

It is important to plan and prepare thoroughly prior to conducting the interview. This involves setting an appointment with the interviewee and fully explaining the purpose of the interview. The interviewer should prepare a list of questions and organize them sequentially. Often this is done in the form of an interview guide or checklist, which should include an agenda and anticipated time limits for each topic being discussed. The questions should include both open-ended and closed-ended questions. For open-ended questions, the interviewer should have some probing questions prepared for anticipated responses. Closed-ended questions can take the form of multiple-choice, true-false, rating, or ranking questions. For these questions, it is important to be precise with terms so as to avoid any ambiguity and confusion.  The interviewer should be careful to avoid asking leading questions that imply a right or wrong answer; the questions should be worded as neutrally as possible and should not imply any opinion on the interviewer’s part. Equally important is to avoid making any promises about the system or set any expectations in the mind of the interviewee; the purpose of the interview is to get information from the interviewee, not to describe design solutions. A key feature of successful interviewing is to listen carefully, taking detailed notes and if acceptable to the interviewee tape-recording the interview. After the interview, the interviewer should be prompt in transcribing and organizing the notes; this should be done within 48 hours to avoid forgetting important information. Finally, it is important to interview a variety of subjects, including users, managers, and information systems staff so that all views will be taken into account.

Page Reference:  134-138                  Difficulty:  Hard





47.  What is a closed-ended question? What is an open-ended question? Give a definition and examples of each. Describe the circumstances in which you would prefer one over the other.  What is a natural way to lead from a closed-ended question to an open-ended question?

Answer:

A closed-ended question is one in which a respondent is given a set of specified responses from which to choose. Examples of these are true-false, multiple choice, and ratings or rankings questions. By contrast, an open-ended question is one that has no specified answers, but instead leads to free-form discussion. In an interview, open-ended questions often put the subjects at ease because they are able to respond using their own words and structure, giving the interviewee a sense of control. Open-ended questions are useful to probe for information when the precise questions to ask are unknown, and these are the questions that are most likely to result in follow-up questions. However, they are more time-consuming than closed- ended questions. Closed-ended questions work best when the major answers to questions are well known. Because they take less time than open-ended questions, more topics can be covered in the same time frame. However, useful information may be lost because of the limitations placed on possible answers. One way to let closed-ended questions lead to open-ended questions is to provide an “other” option; if the interviewee selects “other”, the interviewer can invite further comments as a follow-up.

Page Reference:  136-138                  Difficulty:  Moderate



48.  What are some limitations of interviews that can be overcome by utilizing direct observation as a requirements determination technique? How does direct observation compare to document analysis as a technique? What are some pitfalls and shortcomings of direct observation?

Answer:

Interviews rely on self-reporting by subjects, requiring people to recall and convey information about their work processes and information systems use. Although this is a useful source of information, interview subjects are not always reliable or accurate in self-reporting. For example, they may describe the formal procedures of their work tasks, but neglect to accurately describe the real ways in which they work. Or they may not give accurate estimates of the amount of time they spend using various information systems applications. With direct observation, a systems analyst can obtain a snapshot of the real way a systems user works with the system, and thus obtain behavioral measures that are not available via interviews or questionnaires. Compared to document analysis, the richness of information and chance for follow-up is greater with direct observation than with document analysis. Observation is not a perfect approach, however. Direct observation is time-consuming and expensive, and requires some committed involvement from the subject, although perhaps not as much as if interviewing were taking place. Moreover, subjects who are aware of being observed may alter their normal work behaviors, producing biased results. Also, observation is not continuous, so at best the observer gets a snapshot of the person performing a task.

Page Reference:  138-140, 144                      Difficulty:  Moderate


49.  Discuss how business documents can assist in the requirements determination effort. Give examples of relevant types of documents and describe the kinds of information can these documents provide. What are advantages and disadvantages of relying on business documents for this purpose?

Answer:

Many types of business documents can be used including mission statements, memos, business plans, organization charts, and reports. These provide information such as problems with existing systems, organizational directions, opportunities that can be met by new information systems. One useful document is a written work procedure that specifies the formal procedures for performing specific work tasks; this can be used as input for developing systems that help automate the work process. Another useful document is a business form, which may be used to ascertain the way a computer input screen for an application should look. Business documents can provide information in a less costly or time-consuming manner than interviews or observation, and require much less involvement of users or stakeholders. In addition, documents provide a historical perspective that may not be available from interviews or observation. However, they are not as information rich or timely nor do they provide as much support for asking follow-up or probing questions. Furthermore, it must be noted that, although written work procedures may give accurate information about formal systems, in reality systems are often used and implemented differently from the formal approach described in these documents. Other sources are needed to provide information about these informal system processes.

Page Reference:  139-144                  Difficulty:  Moderate


50.  Discuss the joint application design process. Which company is credited with creating JAD and when did it originate? What are the typical personnel roles involved in JAD, and what purposes do they serve? Describe the JAD environment. How does JAD differ from traditional approaches to requirements determination? What is the deliverable resulting from a JAD session?

Answer:

Joint application design (JAD) is a highly-structured, intensive and group-oriented activity in which all stakeholders of the system come together in a common location for an extended period of time in order to focus entirely on systems requirements determination with no distractions from other work responsibilities. The idea was originated in the 1970s by IBM. People involved in JAD include managers and users who are the key sources of information regarding the requirements of the system. Because of the high cost and heavy time commitment, a high-level executive usually serves as the sponsor for the JAD session, appearing for a short time to provide the corporate-wide strategic perspective. Systems analysts and other IS personnel also attend, but their role is primarily as listeners. They are there to obtain information from the users and managers, although they sometimes will provide input about technical issues. The JAD session is led by a session leader, who serves as a facilitator and organizes the meeting. Finally, a scribe records the notes of the meeting.

JAD sessions are usually held off-site in order to allow participants to focus entirely on the task at hand, and may extend for several days. A typical JAD conference room includes a U-shaped table, a magnetic white board and flip chart for presentations and meeting agendas, and an overhead projector. The format is like a group interview combined with individual presentations; it is highly interactive, but structured and controlled by the JAD session leader so as to keep members on task and resolve conflicts that may arise.

Because it is usually held off-site, there are additional expenses for travel and lodging, and taking people away from their normal day-to-day work activities entails significant labor costs. Also, because multiple stakeholders are available simultaneously, points of agreement and disagreement among different stakeholders quickly become evident. In this respect, JAD differs significantly from standard interviews and questionnaires. 

A JAD session will result in a set of documents that detail the workings of the current system and the desired features of the replacement system, which is then used for the requirements structuring process.

Page Reference:  144-147                  Difficulty:  Hard


51.  What is prototyping? Describe the typical process of using prototyping as a requirements analysis technique, and discuss how this process relates to OOSAD principles. Also discuss the factors that support the use of prototyping as a requirements determination technique, as well as drawbacks of the prototyping approach.

Answer:

Prototyping is a repetitive process in which developers build a rudimentary version of an information system based on initial user requests, and then repeatedly refine it based on user feedback. It begins with user interviews in order to obtain initial requirements, followed by construction of an initial prototype. After this comes an iterative process in which the user works with the prototype, identifies its strengths and weaknesses and revises requirements accordingly, and then the developer refines the prototype based on the user’s feedback. This process will repeat several times until the prototype is judged to meet the user’s requirements. Afterward, the prototype may be used as is, or if it is inefficient in its performance or design, converted into an operational system.

Because prototyping is an iterative process, it ties in nicely with the OOSAD principle of incremental, iterative development. Like OOSAD, a prototype iteration involves a combination of requirements determination, design, and construction, and therefore differs from the traditional SDC.

Prototyping is an appropriate method to use when user requirements are unclear or unknown, when communications problems exist between users and analysts, when there are relatively few stakeholders involved, when possible designs are complex and require concrete form to fully evaluate, and when there are rapid application development tools available. The problems with prototyping is that careful requirements analysis and documentation are often bypassed in favor of quick solutions, that the solutions often reflect a narrow viewpoint of a single stakeholder, and that the resulting system is usually a stand-alone program that does not take into account systems integration issues.

Page Reference:  147-148                  Difficulty:  Moderate


52.  What is Agile Usage-Centered Design? How is this approach similar to JAD? List and describe the steps involve in this methodology.

Answer:

Agile Usage-Centered Design is a systems development methodology that relies on continuous user involvement during the requirements determination and design process. Like JAD, this approach involves bringing all stakeholders together into a group meeting under the auspices of a facilitator. The process involves nine main steps. First, groups of analysis, programmers, users, and testers gather together for collaborating on the design. Second, each individual is given an opportunity to vent about the current system and discuss their desires for the proposed system, and all these ideas are recorded. Third, a role model is created. This involves defining the pertinent user role, writing them onto 3X5 cards, and sorting them based on similarity. Fourth, each user role will be broken into tasks, which are also written on 3X5 cards, sorted based on importance. Fifth, the task cards are grouped by similarity into clumps, called "interaction contexts". Individuals or groups in the meeting will be responsible for an interaction context. Sixth, the task cards of an interaction context are elaborated by writing the steps required for each task. Seventh, screen designs are proposed for each interaction context, sketched on paper. Finally, each user role steps through its relevant set of tasks in order to refine the steps of the tasks and the proposed screen designs.  


Page Reference:  148-149                  Difficulty:  Moderate