Exam Flashcards

Question

1. IT Project Barrier (barrier to erosion)

Answer 1

``` Divided into 2 categories: IT Characteristics (technology) • Visibility • Uniqueness • Complexity ``` Implementation processes • Implementation process complexity • Degree of Process Change

Answer 2

``` Switching cost: 3 sources of switching costs: 1. Co-specialized tangible investments, 2. Co-specialized intangible investments, and 3. Collective switching costs ```

Answer 3

Methods as described in text books

Answer 4

The methods actually used by developers.

Answer 5

Business analyst, programmers

Answer 6

Different rational and political roles

Answer 7

The context in which the system is developed and used

Answer 8

The new system

Answer 9

Discrete stages with a specific end product, stage-limited commitment, specialization, bureaucrazy, documentation. Used when uncertainty is low, or if complexity is high. You always have to tailor the method to the specifik context you are working in.

Answer 10

Short iterations, feature planning, dynamic prioritization, feedback and change. Used when unvertainty is high and complexity is low. You always have to tailor the method to the specifik context you are working in.

Answer 11

Complexity: High complexity = Plan-driven Solved vs. unsolved: If solved before = low uncertainty = Plan-driven Mature vs. new technology: New = prototypes and more quality assurance = Agile Systems and change: More change = Agile

Answer 12

Proactive: An opportunity might show up, and the organization changes the context before problems materialize. Reactive: Organizations react to problems in the contexts as they turn up. Problem-solving: Projects attempts to understanding the current business process, fix errors, and optimize the process using IS. Analysis play a big role. Innovation: Change is viewed as a creative way to form a new context. We are not just fixing errors. Creativity and design plays a big role.  Innovation is high risk and hard. Incremental: Change is accomplished in several small steps (related to problem solving) Radical: More risk. Change is accomplished in major steps that fundamentally changes the context.  Radical changes are only done when it is absolutely necessary for the organization. We prefer incremental changes.

Answer 13

Typically contains a series of development phases arranged in a certain sequence. The phases are typically concerned with planning, analysis, design, programming of systems. Typically not the implementation, which is problematic because development and implementation are closely related. Like the waterfall model or an agile model.

Answer 14

A coherent and systematic approach, based on a particular philosophy of systems development, which will guide developers on what steps should be performed and why these steps are important in the development of an information system. Like object oriented analysis & design. Technique: How to do more specific task. E.g. how to illustrate a business process using a swimlane diagrams. Tool: An instrument that might support a specific method or technique. E.g. A tool that supports designing E-R diagrams and generate databases.

Answer 15

Reduce complexity: E.g. by dividing a complicated process into smaller and more manageable and less complex steps. Facilitate project management: E.g. creating transparency by having developers do interim products that makes it possible to evaluate the progress. Allow skill specialization: By defining roles and activities that can be allocated to specific developers. Standardization: By having several projects in the same organixation work in similar ways, thereby making it easier to share developers and experience. Economics: By improving productivity. Learning: E.g. getting new employees integrated faster because they can read and learn how things are dine in this organization. Quality: Reduce the reliance upon individual developer skills.

Answer 16

Assure customers, Legitimate specific ways, Professionalization, A power base

Answer 17

Requirements are stable Technology is well-known and mature Everything happens as one would expect Not much new or unknown We have done something similar before

Answer 18

Short iterations Feature planning Dynamic prioritization Feedback and change Teamwork Customer collaboration

Answer 19

The major challenge is that our methods-in-actions have to be changed whenever the context changes, and this is one of the major reasons behind the many projects delays and budget overruns. The problems: Predictability: We have difficulties estimating how much time and other resources we need. Costs: Development and implementation gets more expensive than originally expected. Change: We have difficulties implementing the organizational changes that are needed to benefit from the new system. Quality: New systems do often not work properly in the context they should support, users to not find the system usable. Value: We have difficulties realizing the expected benefits from IT investments, maybe nobody actually takes responsibility for doing so. Examples: There is no single best strategy: 1. Alternative 1: The development of an entirely new system from scratch 2. Alternative 2: Buying/re-using some components and developing other components 3. Alternative X: The configuring of a standard application to fit a specific organization. These are variations of agile and plan-driven development.

Answer 20

Advise: If there is an application out there you can use - use it! Don't develop a new system unless it the ultimately important.

Answer 21

Who are they • Technical experts in computer science, programmers, database specialists, business analysts or change agents. • Together they are multiple stakeholders working together in a cross-functional effort • Both developers and users learn throughout the project. Difficult if not impossible to know all requirements up front. Skills • Ability to communicate and collaborate with client and users – must be able to explain technological issues to users and managers • Analytical skills: being able to analyze and understand complex problems • Creative skills: Design solutions to problems • Compositional skills: Come up with new systems and join the existing system and the existing context into a whole system. ``` Motivation • Communication and motivation are vital • New technology • Ownership • Working with top management • Trust and autonomy ```

Answer 22

Typically contains a series of development phases arranged in a certain sequence. Use this type of model to benefit from previous experience and knowledge and to establish some kind of shared understanding.

Answer 23

Adapting a general development process model to be used in a specific project.

Answer 24

The system development model that is used should be as simple as possible given the level of complexity involved.

Answer 25

When complexity increases: A rational model for developing large and complicated systems. 1. We understand the requirements 2. We design a solution 3. We make a solution 4. And test it and remove errors However it seldom works in practice. We have to go back and make som adjustments to make it work.

Answer 26

When we waste time because we have to go back in the proces and remake some processes to fix the problem.

Answer 27

• Introduce a preliminary design phase before analysis with the purpose of identifying the technical constraints that the analysis have to respect. This will increase the technical feasibility of the development effort.  The idea of doing more analysis and more design only works in stable conditions. • Document the design carefully. The argument is that documentation supports communication and coordination and makes it possible to monitor progress. Force designers to make design decisions, makes quality of design transparent and reduce cost during test, operations and maintenance and reduce reliance on specific programmers. • Do it twice. When developing something unfamiliar – do it twice. Build a simulation (pilot model) to gain experience. Focus on critical issues. • Plan, control and monitor testing. Use independent testers, review before testing, test all logical parts in a program, test again when identified errors have been fixed. • Involve the customer. Important to involve the customer in a formal way so that they have committed themselves at earlier points before final delivery.

Answer 28

The traditional development paradigm does not respond well to increased complexity and uncertainty. Tendency is to increase controls and to require more precise requirements definitions which does not fit this specific context. Users recognize potential benefits of new applications but are not able to describe the necessary details of a solution. We can’t get better requirements just by asking questions. "You want to try are car before buying it"

Answer 29

1. Identify the user’s basic information requirements: Focus on data and process 2. Develop: A purposely limited prototype is developed in a short timeframe. Design and implementation are accomplished by building a working system 3. Implement and use the prototype system: “Hands-on” use of the system provides experience, understanding, and evaluation. 4. Revise and enhance the prototype system: Undesirable or missing features identified by the user must be corrected.

Answer 30

* “True evaluation”: The most effective representation possible since it enables evaluation of proposed design in context. * Accomodates change: Change in both the user and systems environment * Development and operations mixed: If user environment is unstable or extremely dynamic, development iterations could continue indefinitely. In such situations: Traditional systems methodologies are integrated by the prototype model. * In a more static environment where a prototype meets the user’s full needs, it may either serve as-is or be used to design specifications for a more efficient information system. In a stable environment, the decision to replace an operating prototype system with a traditional system can be made with relatively simple breakeven analysis.

Answer 31

* Users: Users play more active roles in prototyping than is possible with traditional development methods. They become system designers who use and evaluate a system. * Developers: They construct successive versions of the system, compromising and resolving conflicts between the context (users needs and desires) and the form, as constrained by technology and economics.

Answer 32

XP = Extreme prototyping Before users would define all requirements at once and the system was then designed, coded and tested. It did not work. Users can’t tell us once and for all what exactly they want – maybe they don’t know, or they changed their minds.

Answer 33

* Planning game: Customers decide the scope and timing of releases based on estimates provided by the programmers. * Small releases: The system it put into production in a few months, before solving the whole problem. New releases are made often (daily/monthly) * Metaphor: The shape of the system is defined by a metaphor. * Simple design: At every moment, the design runs all the tests, communicate everything the programmers want to communicate… “Say everything once and only once” * Tests: Programmers write unit tests minute by minute. * Refactoring: The design of the system is evolved through transformations of the existing design that keep all the tests running * Pair programming: All the production code is written by two people at one screen. * Continuous integration: New code is integrated with the current system after no more than a few hours. * Collective ownership: Every programmer improves any code anywhere in the system at any time if they see the opportunity. * On-site customer: A customer sits with the team full-time * 40-hour week: No one can work second consecutive week of overtime. * Open workspace: The team works in a large room with small cubicles around the periphery. * Just rules: Being part of the Extreme team, you sign up to follow the rules. The team can always change the rules as long as they agree on how they will assess the effects of the change.

Answer 34

* Releases: The project (that is not a project) is divided into releases. The customer picks the nest release cu choosing the most valuable features (called stories in XP) from among all the possible stories. * Iterations: Each release is divided into even smaller iterations. The customer picks the next iteration’s stories by choosing the most valuable stories remaining, again informed by the costs of the stories and the team’s speed. * Task: The programmers turn the stories into smaller-grained tasts, which they individually accept the responsibility for. * Test case: Then the programmer turns a task into a set of test cases that will demonstrate that the task is finished * Design, programming and test: Working with a partner, the programmer makes the test cases run, evolving the design in the meantime to maintain the simplest possible design for the system as a whole.

Answer 35

If you have commited to more than you can accomplish: • Reduce the occurrence of underestimation as much as possible by getting lots of practice estimating • If you are overcommitted – ask the following internally first: Slipped away from practices? Are you doing as well as you can? Are you delivering more than the customer needs? • If you cannot find a way to be faster, you have to ask the customer for relief.

Answer 36

* Trying to build a trust relationship with the customer * If trust begins to break – figure out if it is your fault. * If they don’t change – make your concerns more visible. If no one cares enough to solve the problem – maybe the project isn’t high enough priority to go on.

Answer 37

People turnover is not a big problem since all programming are done in pairs.

Answer 38

Not an issue since XP is designed to deal with change in a low cost way. • Little or no documentation • The code is nice and clean due to refactoring • Iterations are short, so we will learn fast if something needs to be changed.

Answer 39

The act of a company/institution taking a function once performed by employees and outsourcing it to an undefined (and generally large) network of people in the form of an open call. Different from outsourcing: • Work announced through an open call to which anyone can respond • The workers who volunteer are unknown to the organization needing the work done • The group of workers can be very large and geographically, culturally etc. distanced

Answer 40

Peer production • The oldest and best-known model • Open source development is an example of peer production – a model in which control is decentralized and contributions are made without monetary reward. • The contributors, rather than the paying client, decide the project’s scope and goals • Contributors are typically motivated by the opportunity to gain experience with new technologies, gain reputation and contribute to a good cause Competition • Competitions are similar to traditional outsourcing, in which a client requests work and pays for its completion. They treat workers as contestants rather than collaborators. • A client proposes a project. Then a copilot (an experienced worker who gets paid) decomposes the project into a series of competitions that might cover requirements, architecture and so on. • The copilot divides each competition into tasks that can be completed in an number of days. • Contestants each provide a competing solution. The copilot selects a winner, runner up and the corresponding workers are paid. • This gives the clients access to diverse solutions, which might lead to higher-quality results. Microtasking • Decomposes work into a set of self-contained micotasks, which can each be completed in minutes and which together constitute a solution to a more complex task. • Typified by Amazon’s Mechanical Turk – a general platform in which clients post batches of microtasks. That workers (“Turkers”) complete one at a time. • Multiple worker can be asked to complete the same task to ensure quality. Best solution will be selected by voting. • Advantage: Extreme scalability. Work can be distributed to arbitrary large crowds, enabling a quick completion of large tasks.

Answer 41

``` Advantage: • Increased development speed • Generating alternative solutions • Getting easier access to specialist • The democratization of participation: Contributors determines how, when and what to contribute. • Learning through work ``` Crowd sourcing challenges: You don't know if you are going to get anything useful or when you will get it. - It might be risky.

Answer 42

1. Apply risk analysis to specific risk areas associated with agile and plan-driven methods (specific risk categories: environmental, agile and plan-driven) 2. Evaluate the risk analysis results to determine of the project is appropriate for either purely agile or purely plan-driven methods. 3. If the risk analysis shows that the project has no clear agile or plan-driven home ground. It also applies to cases in which parts of the system have such different risks that they fall into different home grounds. 4. In this step overall project strategy that addresses the identified risks is developed. This involves identifying risk resolution strategies for each risk and integrating them. 5. No decision is ideal for all time, the management team must constantly monitor and evaluate the performance of its selected processes while keeping an eye on the environment.

Answer 43

Closed invocation paradigm: Like waterfall, prototyping, agile etc. all belongs to the closed invocation paradigm Open Innovation paradigm open innovation paradigm, as in crowd sourcing open innovation paradigm, as in crowd sourcing

Answer 44

* Lack of benefits realization * Perceiving projects as IT projects, not techno-change projects * Separating systems development from organizational development and change * Lack of integration of implementation concerns in solution design * Poorly managed organizational change OBS. The model is competencies not activities

Answer 45

A project that changes an organization based on new uses of IT. Technochange from article: Using IT in ways that can trigger major organizational changes creates high-risk, potentially high-reward, situations that I call technochange (for technology-driven organizational change) Today these project would be labelled as “transformational” or “disruptive”. Perceiving a Technochange project as an IT project is a classic mistake.

Answer 46

A purely technical IT project (such as upgrading a web-server).

Answer 47

The problems that comes from separating IT development from organizational development.

Answer 48

A design that not only consist of the design of an IT systems but also the design of the changes to the organization.

Answer 49

A design without misfits towards key organizational characteristics such as the culture, business process and incentives.

Answer 50

An iterative approach that not only focus on the development of IT, but the organizational changes and benefits as well

Answer 51

the process of organizing and managing, such that the potential benefits arising from the use of IT are actually realized.

Answer 52

the ability to effectively identify and enumerate the planned outcomes of an IS development project and explicitly stipulate the means by which they will be achieved. * Benefits do not simply emerge, as if by magic, from the introduction of a new technology. * Their realization needs to be carefully planned and managed. Examples: • Understand business strategy: Clarify the strategic/business drivers for the project and how the project might contribute to the achievement of business strategy. • Understand stakeholders: Analyze stakeholders’ requirements in terms of benefits that should be delivered by the project. • Identify benefits: Use the strategic/business drivers and stakeholder requirements to identify the agreed upon benefits to be delivered by the project. • Plan benefits realization: Develop an overall plan to show the business case (what the benefits are) and how they are going to be realized. Define who is responsible.

Answer 53

the ability to design and execute the programme of organizational change necessary to realize all of the benefits specified in the benefits realization plan. * Benefits primarily arise from the organizational change that accompanies an IT implementation, rather than directly from the technology * Consequently, organizations will only be able to deliver value from their IT investments if they can develop a benefits delivery competence as the technical solution gradually takes shape, so does the organizational re-design. Examples: • Actively lead the business change: Design, build and lead the project team and governance framework with a focus on realizing benefits. • Specify changes to work and organizational design: The project focuses on the design and delivery of a business solution. • Benefits-driven training and education: Ensure education and training are focused on the realization of benefits. • Implement organizational changes: Implement new and revised business processes, working practices, structures, roles, management framework and performance measures. Take action as required to encourage cultural changes.

Answer 54

the organization's ability to effectively assess the success of a project in terms of the potential benefits, the delivered benefits, and the identification of the ways and means by which further benefits might be realized. * The benefits from IT investments will only be realized if they are measured and managed in a systematic way. * Organizations must, therefore, be able to effectively monitor and evaluate the results of their projects, on an on-going basis, to ensure that its ability to deliver business value is incrementally improved. Remember lag effects! Examples: • Benefits-driven project appraisal: Use agreed evaluation criteria to undertake a systematic assessment of benefits. • Identify actions to realize further benefits: Where planned benefits have not been achieved, or opportunities for new benefits have been identified, a benefits’ action plan needs to be established

Answer 55

The adoption of the portfolio of practices required to realize the potential benefits from information, applications and IT services, over their operational life * Attempts to capture benefits from a piece of business software should not cease as soon as it has been implemented. * It is often the case that the full potential of a particular application does not become apparent until it is fully operational and the stakeholder community has become experienced in its use. Managers responsibility Examples: • Ensure ownership of continued benefits exploitation: Establish a clear business role for ongoing ownership of realizing benefits. • Maintain benefits-driven training: Training is focused around benefits realization and establishing new ways of working. • Evolve working practices: Continue to evolve working practices post deployment to realize further benefits.

Answer 56

* Classic IT project management (and systems development models and software engineering) do typically not address the major risk in technochange: that people will not use IT and related work practices. The focus is on project cost, project schedule, and system functionality. * Although the discipline of project management is a very important contributor to successful technochange, it has very little to say about how to manage the risks associated with people’s ‘resistance to change’. Why not just IT project management + change management? too much separation. • The problem is that the ‘organizational solution’ is expected to conform to the ‘IT solution’, when a better outcome would be an integrated technochange solution. For example we need to align system design and job design in a concurrent process. Implementation issues should be considered during the design process.

Answer 57

Bad technochange: Technochange solutions can be bad in two major and related ways: • They can be incomplete, • and they can be misaligned with the organization. Incomplete technochange solutions: are simply IT solutions; they lack the other supportive changes required for use of the IT solution to yield the desired results. For example, getting the desired results from CRM software may require reallocated sales territories and new salesforce incentive systems etc. Misaligned technochange solutions: may or may not be complete, but conflict so seriously with the existing organization that they are likely to be rejected. For example, health information systems that require doctors to enter information sometimes offend doctors’ sense of status and fail to gain their acceptance. Technochange projects should change organizations – but in ways that are implementable.

Answer 58

* Lack of IT understanding in business: * Lack of business understanding in IT: * Bad strategy for collaborative innovation: Although ‘user representatives’ on IT project design teams are common, their involvement may not be sufficient to guarantee a good IT solution. People involved in participatory design processes often produce incremental solutions, even when more radical change is needed. • Unless decisions about new IT and business processes changes are integrated, the likelihood of an incomplete or misaligned solution is large.

Answer 59

3 major problems: 1. Time and distance effects • Team members get organizationally and phychologically distant from the ongoing operations of the organization. • A design team can lose their ability to think like a ‘user’ within a matter of weeks. • Time and distance effects can create ‘drift’ between the project and the business needs that led to it • The agile / iterative systems development models reduce time and distance effects. 2. Exported problems • Exported problems are problems that arise during one phase of the life cycle but either are not recognized as problems or fixed at that time. Instead, they show up in later phases, when it may be too late or too expensive to fix them. • The classic example of an exported problem is failure during the chartering phase to recognize that a proposed IT implementation is actually a technochange situation: 3. Technochange failure creating a culture of failure and unintended consequences • Canceling a failing project (blaming technology) rather than sinking more time and effort into the attempt to overcome resistance may be a sound business decision. • Failing in this way can have long-term negative side effects on the organization’s ability to succeed in future change efforts (‘here it comes again’)… • Even completed and apparently successful technochange initiatives can have unintended consequences, that were not expected or intended by executives or project personnel.

Answer 60

1. Phase 2. Chartering 3. Project 4. Shakedown 5. Benefit capture

Answer 61

* Technochange prototyping is iterative / agile development + organizational changes integrated into one, and the same, process. * The essential characteristic of the Technochange prototyping approach is that each phase (iteration) involves both new IT functionality and related organizational changes, such as redesigned business processes, new performance metrics, and training. * In successful techochange, both the solution and the process of arriving at the solution are important.

Answer 62

1. A complete solution: The first is a technochange solution that is capable of yielding the desired results if it is properly implemented. * The benefits are only realized when organizations reorganize work in new ways to take advantage of the capabilities of IT. * When organizations fail to make complementary changes, they often lose business value from their IT investments: If you automate a bad business process, you get a faster, more expensive, but bad business process. 2. An implementable solution: The second is that the solution is actually used effectively. * The second condition for a successful technochange is a solution that can be, and is, adopted and used. * But many technochange solutions simply cannot be adopted and used easily or at all, because they conflict with existing organizational structures, cultures, or practices. All technochange has the potential to provoke the human reaction often called ‘resistance to change’. * But not all technochange solutions are actually resisted. For almost any organizational change goal, it is possible to design several complete technochange solutions that could accomplish the goal, if the solution were adopted and used. The challenge of successful technochange management is to design or select a complete solution that is likely to be adopted and used. Such solutions are said to be implementable. * It is a much better idea to try to prevent resistance than to hope you will be successful in eliminating it after it arises. 3. A solution where benefits are actually exploited: The third is that the benefits of the solution are actively captured and exploited. • The benefits of technochange, unlike those of IT projects, are not automatic. Effort is required to turn potential benefits into measurable organizational results. An example: o A major benefit of a technochange is that it enables accountants to do their work in less time. o How does the organization benefit? If the accountants have been completing their work in unpaid overtime, there is no financial benefit to the organization (just happier accountants). If the accountants can now do their work in 6 hours instead of 8hours, does the organization benefit financially? To realize financial benefits, managers would have to reassign work and reduce the number of accountants. Would they actually do so? There are lots of reasons not to. • To make sure that managers actually capture these benefits, the managers must have incentives (such as rewards) to reduce their costs actively.

Answer 63

1. Task or business process misfits • A solution may be technically adequate but still not fit the ways people work in particular settings. For example: o Knowledge bases designed for use by experts often do not work well when they are made available to novices. o Systems that work well in one national context with particular business practices or legal frameworks do not work well in other countries with different norms and requirements. 2. Cultural misfits • A technically adequate solution may not fit particular settings for reasons that reflect organizational or national culture more than particular tasks. • Organizational culture can be defined as ‘the way we do things around here’. It often reflects what has been successful in the past. • Differences between technochanges and organizational culture can contribute to ‘resistance’. For example: o Systems aimed at increasing administrative efficiency are often resented by doctors and nurses who are committed to patient care. o Systems designed to promote teamwork may be rejected by people who typically work alone. 3. Incentive misfits • Technically adequate solutions may be misaligned with the authority and reward systems of an organization. • These misfits are sometimes called ‘political’ misfits, because change managers who promote technochanges with incentive misfits often run into lots of destructive organizational politics. For example o When Lotus Notes was first introduced into a consulting firm to promote knowledge sharing, it was not used that way. The reason was that, in the company’s up-or-out promotion system, consultants got ahead by hording what they knew. The system only gained got success when the firm began making promotion decision in part on the basis of consultants’ contributions to the knowledgebase. o Corporate accountants introduced a new financial system to give them detailed visibility into what was happening in the divisions. The system was strenuously opposed by division managers who wanted to avoid headquarters interference.

Answer 64

* Unfortunately, misfits often have the appearance of technical inadequacy, and those who experience misfits often claim that the system is inadequate. * Therefore, it is important to take potential misfits carefully into account when designing technochange solutions and when dealing with apparent cases of resistance to technochange.

Answer 65

How to increase chances of succes: • Systems quality – in which way does quality matter for the creation of benefits? Which quality attributes are especially important (e.g. security etc.) • Information quality – what kind of information should be offered by the system to help create benefits? • Service quality – what kind of service should be offered to support the creation of these particular benefits? And continuously assess: • Intention to use and • User satisfaction For each of the quality aspects we have to design some kind of evaluation that has a high likelihood of identifying any problems with the requirements. You should continuously through a project try to measure and improve system quality, information quality and service quality as perceived by the users. User perception of these factors has major impact on their intention to use the system, their satisfaction with the system, and actual use of the system.

Answer 66

Trust is defined as an individual’s willingness to depend on another party because of the characteristics of the other party.

Answer 67

Companies should design and build implementability into information systems (e.g. that systems helps users achieve goals that are supported by incentives)

Answer 68

IS Success variable: Not surprisingly the users perception of system quality, information quality and service quality has impact on the user intention to use, and use, of systems and impact on user satisfaction. Many systems development methods neglects service quality.

Answer 69

During the design: • You should incorporate all the quality requirements into your design (e.g. if something should be “easy to use” you have to incorporate that into your design and later verify that the design actually fulfill the requirements. • In the agile approach you will face the challenge that there are no documents describing the relationship between the requirements and the design. • In a plan-based project the same applies: You have to incorporate the quality requirements into the design, and you have to verify that it is done correctly. However it will be a more formal and documented approach.

Answer 70

The purpose of test is to find problems in the code regarding these quality attributes, as well as errors regarding the functional aspects of the code. * One of the major benefits of agile development is that you test often and also get frequent feedback about the quality, that can be used in later iterations. It is however important that these test / evaluations cover all the quality requirements in a systematic way. * The plan based approach has a long history of designing tests for all the different kinds of quality. Performance test, usability test, deployment test….. But in practice these tests are not executed properly in many cases.

Answer 71

Task • Task compatibility: the alignment of the technology with the work processes or work styles. • Task difficulty: task difficulty has an inverse relationship with IS success. The easier the task, the more successful the IS. User • Enjoyment: the degree to which users have a positive affect toward the use of technology or an IS. • Trust: in the technology or IS. • User expectations: reasonable expectations toward an IS by users is a precursor to IS success. • Attitudes toward technology: the users general attitude towards the use of technology. • Organizational role is: a user’s role in an organization does affect the user’s resistance to a new IS. • Technology experience: the users experience with technology in general (good or bad). • Self-efficacy: one’s belief that he or she is capable of performing tasks with an IS. Project • User involvement: has long been associated with IS success. • The relationship with developers: the relationship between the IS group and the users, has been shown to have a positive effect on several dimensions of IS success. This relationship between the users and developers is maintained through a partnership, shared knowledge, trust, and effective communication during the development process. • Domain expert knowledge: has not been studied much, but when it has been included as an independent variable predicting IS success, there is often support for this relationship. Organization • The use of extrinsic motivation: such as incentives or pressure by the organization to use the IS, has strong support as a predictor of IS success. • IT infrastructure: the sophistication or level of IT infrastructure. • Management support: management support refers to the willingness to allocate time, resources, and encouragement for the use of an IS. • Organizational competence: managers with higher levels of IT knowledge and competencies affect the adoption of IS and the extent of use of IS within the organization. • Management processes: such as the culture, bureaucracy, or change control processes, also affect IS success. When management invokes processes that encourage open communication or strongly inform users about the benefits of the new IS, more use of the IS seems to follow. Formal management processes must be adopted to influence the resulting benefits received from the IS. In these cases, management processes strongly affects both use and net benefits

Answer 72

* Limited project level impact on some factors: When looking at these factors it is obvious that only some of them might be managed by an individual projects – for example a project has limited impact on the organizational factors and more impact on the project factors. * Understand your development context: Nevertheless projects should analyze these factors as part of their efforts to understand the development context, so they know what they are facing, and e.g. plan the implementation effort accordingly. * Use the factors when doing risk analysis: The factors would be very useful when doing a risk analysis of a specific project. * Increase organizational maturity and possibilities for success: In organizations that depends on IT, management could invest in more general organizational development programs that tries to impact these factor in a way that smoothens the way for individual projects.

Answer 73

* Trust is commonly defined as an individual’s willingness to depend on another party because of the characteristics of the other party. * Trust situations arise when one has to make oneself vulnerable by relying on another person or object. * Trust is crucial to almost any type of situation in which either uncertainty exists or undesirable outcomes are possible - as in systems development projects. * What it is about technology that makes the technology itself trustworthy?

Answer 74

Propensity to trust Propensity to trust: A tendency to trust other persons. o When applied to trust in technology, propensity to trust suggests that one is willing to depend on a technology across situations and technologies. Propensity to trust technology is composed of: o Faith in general technology: refers to individuals’ beliefs about attributes of IT in general. For example, an individual with higher faith in general technology assumes IT is usually reliable, functional, and provides necessary help. o Trusting stance: refers to the degree to which users believe that positive outcomes will result from relying on technology.

Answer 75

``` Institution-based trust: focuses on the belief that success is likely because of situational normality and structures that provides assurance. • It is normal and therefore safe: Situational normality reflects a belief that when a situation is viewed as normal and well-ordered, one can extend trust to something new in the situation. • Situational normality technology reflects the belief that using a specific class of technologies in a new way is normal and comfortable within a specific setting. If using spreadsheets is perceived as a normal work activity, you are predisposed to feel comfortable working with spreadsheets generally. This may result in trust in a particular spreadsheet application. ``` Structural assurance: • I have a safe contract and guaranties: Structural assurance refers to the infrastructure supporting technology use. • It means the belief that adequate support exists (legal, contractual, or physical, such as replacing faulty equipment) to ensure successful use of an IT. • For example, contractual guarantees may lead one to expect a successful software implementation. Structural assurance helps individuals form confidence in software, thereby fostering trust in a specific technology.

Answer 76

• Trusting beliefs in a specific technology: In contrast to institution-based trust’s focus on classes of technology (e.g., spreadsheets), trusting beliefs in a specific technology reflect beliefs about the favorable attributes of a specific technology (e.g., MS Excel). • Trusting beliefs in a specific technology is reflected in three beliefs: o Functionality: refers to whether one expects a technology to have the capacity or capability to complete a required task. o Helpfulness: the help function, i.e., is it adequate and responsive? o Reliability: expectations about a technology to work consistently and predictably. • Knowing how a technology will respond: Trust in specific technology is grounded in users’ knowing the technology sufficiently well that they can anticipate how it will respond under different conditions. • The authors propose that users will be more willing to: o experiment with different features (intention to explore) or o to use more features (deep structure use) of a technology • because they understand it well enough to believe that it has the attributes (i.e., functionality, helpfulness, and reliability) necessary to support extended use behaviors.

Answer 77

Resistance is a complicated concept. It might be both positive (used as a resource) and negative, and it is hard to differ between background resistance and resistance related to a specific project. It might be used as a bad excuse for failing projects, exist only in the head of change agents, and change agent behaviour might increase ”resistance”.

Answer 78

Where a mismatch occurs between the expectations of technology and actual working practice, employees may implement a ‘workaround’ by deviating from set procedures. This notion of workaround is defined as: ‘informal temporary practices for handling exceptions to workflow’.

Answer 79

Three theories (but not the whole story) Persons and Systems: Persons: • Resistance is caused by factors internal to persons or groups (e.g. whether persons trust technology in general) o The person or subunit may be believed to have resisted because of factors internal to the person or group. These factors may be common to all persons and groups or unique to the one being examined. o people resist all change; people with analytic cognitive styles accept systems, while intuitive thinkers resist them. Systems: • Resistance is caused by factors internal to systems (e.g. usability) o the person or group may be believed to have resisted because of factors inherent in the system being implemented. o Examples of compatible explanations are people resist technically deficient systems, systems that are not ergonomically designed, and systems that are not user friendly. Interaction: • Resistance is caused by the interaction between factors related to the persons (groups) and factors related to the system (e.g. the alignment between the way persons work and the system). o Centralization cs. decentralization: systems that centralize control over data are resisted in organizations with decentralized authority structures. o Loose vs. gain power: systems that alter the balance of power in organizations will be resisted by those who lose power and accepted by those who gain it. o Systems vs. social context: and resistance arises from the interaction of technical design features of systems with the social context in which the systems are used (e.g. mobile apps that disturbs during social events).

Answer 80

Socio-technical explanations: • The sociotechnical variant: focuses on the distribution of responsibility for organizational tasks across various roles and on the work-related communication and coordination around this division of labor. Socio-technical design focus on achieving excellence in technical performance and quality in people's work lives through joint optimization. o Example: - A municipality invested in new tablets through which social workers (each morning) were told which elderly citizens to visit. The social workers resisted. They were used to meet each morning, have a cup of coffee, talk, and receive information about which citizens to visit. For the social workers the morning meeting was not just about planning the day, but also about social relations with co-workers.

Answer 81

Political explanations: - The political variant: Resistance is explained as a product of the interaction of system design features with the intra-organizational distribution of power. - Example: An organization invested in an ERP system that standardized cross functional processes across the departments in the organization. Some departments resisted the system, because they were used to locally decide how processes were designed and executed. Depending om which theory you believe in you will e.g. plan the implementation process differently and respond to resistance differently.

Answer 82

Person determined theory of resistance An implementor holding the person-determined theory of resistance would typically choose tactics like: • Selecting users: carefully selecting the people who will use a new system or allowing users to self-select after careful explanations about the system • Educating users: to change their cognitive styles or attitudes about technology and computing • Increase commitment: getting users to participate in the design process so that they will feel more committed to the outcome • Management support: gaining support of the users' bosses who will encourage or demand compliance of from users • New incentives: changing organizational structures or reward systems to conform to the features of the system System determined theory of resistance lmplementors who hold the interaction theory of resistance find that no tactics are useful in every situation: • Example: o Applying user participation in the design process where management actually has decided the design, or is going to decide the design, is a bad idea. In such situations, users are likely to resent strongly a tactic that is meant to make them feel as though they have some say in the matter, when they obviously do not. • Analyze the existing situation: identify factors that will facilitate or hinder the change. The best prescriptions for an implementation strategy and for the specific design content of a system will follow from a thorough diagnosis of the organizational setting in which the system will be used. • Integrated approach: integrate and align organizational changes, systems design and implementation. Introduce organizational changes before or during implementation. Interaction-determined theory of resistance • Consider and design the relationship between users and designers: the specific designs of systems are in part a product of the relationships between users and designers. No designers are ever completely neutral. The implementor must consider himself or herself as one of the parties in the analysis. Self-examination of interests, payoffs, and power bases will increase implementor's ability to understand other people's reactions to the systems the implementor is designing and installing. • Don’t overcome resistance – avoid it: the goal is not to "overcome" resistance, but to avoid it, if possible, and to confront it constructively. • Perceive resistance as a clue: resistance is not a problem to be solved so that a system can be installed as intended. It is a useful clue to what went wrong and how the situation can be righted. • Focus on the benefits: focus on how the benefits can be achieved – not on how specific changes or systems can be implemented. Maybe there is another way, that doesn’t create resistance.

Answer 83

A Biased perspective: • In favor of change agents: The predominant perspective on resistance is decidedly one sided, in favor of change agents and their sponsors. • Most studies appear to take the perspective, or bias, of those seeking to bring about change: Change agents are doing the right things while change recipients throw up unreasonable obstacles or barriers "screwing up" the change. • Change agents are portrayed as undeserving victims of the irrational and dysfunctional responses of change recipients. • But maybe: o Resistance is an interpretation assigned by change agents to the behaviors and communications of change recipients, and maybe o these interpretations are either self-serving or self-fulfilling. Expectations: • If resistance is expected – it might come: o Expectation Effects: The work on self-fulfilling prophecies and the Pygmalion effect (that the expectations you have to other people affect their behavior) suggests that if change agents go into a change expecting resistance, they are likely to find it. Explanation to failure: • Resistance is a convenient way to explain failure: o In some situations labelling events as “change resistance” is just an easy to believe explanation of failure. o Change agents' accounts of unexpected problems in a change process can safely attribute those problems to resistance as a way to divert attention from other factors, including their own failings. o Change agents are thereby encouraged to engage in sensemaking that builds upons scapegoating and avoiding responsibility by blaming difficulties on resistance. Broken agreements and the violation of trust • Research on organizational justice has shown that when people see themselves as being treated fairly, develop attitudes and behaviors associated with successful change. • When people experience an injustice or betrayal, they report resentment, a sense of being done to, and a desire for retribution, which can result in negative behaviors. • Change agents who repair damaged relationships and restore trust both before and during change are less likely to encounter resistance than agents who do not. • Failing to repair damaged relationships and restore trust leads to responses that will be labeled resistance: cynicism, critical behaviors toward both change and change agents, and lower work motivation and commitment. Communication breakdown: • Justify the change: Change agents must provide justifications for the appropriateness and rationality of change, create readiness for change, and increase the likelihood of fast recipient acceptance and participation in the change. • Explain the benefits: Recipient acceptance of and participation in the initial stages of a change has been shown to depend on recipients' assessment of the likelihood the change will lead to personal and organizational benefits. • Take objections toward change serious and use them to improve: Well-developed supporting justifications tend to be accepted and weak ones rejected. By dismissing objections as resistance, change agents not only miss the opportunity to provide compelling justifications that help make recipients more supportive Misrepresesentation: • Just don’t do it: o Change agents may engage in intentional misrepresentation to induce recipients' participation, to look good, or to avoid losing face and looking bad. o Deception and misrepresentation are bargaining tactics that may be used during negotiations and are more likely to occur in competitive situations where the stakes (e.g., reputations and careers) are high and there are incentives (e.g., "winning") for unethical behavior. Bias towards optimism • Not all misrepresentations of change are intentional. Decision makers have a bias toward optimism. • Change agent optimism may be genuine and not intended to be misleading. • As a result of their optimism, agents may oversell the positive and undersell the negative. • As change unfolds and recipients compare actual results to the original promises, unfavorable deviations can result in perceptions of misrepresentation, injustice, and violations of trust that undermine agent credibility and add to recipient anticipation of future inconsistencies. No call for action: • Change is fundamentally about mobilizing action, and although talk is essential, not all talk leads to action. • When change agents mistakenly assume that understanding is sufficient to produce action, they are likely to emphasize conversations for understanding over conversations for performance and are, as a consequence, likely to see little or no action. You have to tell people exactly what you expect them to do. Resisting Resistance: • Change agents may be resistant to the ideas, proposals, and counteroffers submitted by change recipients. • If change agents fail to treat the communications of change recipients as genuine and legitimate, or as extensions and translations of the change, they may be seen as resistant (e.g., "defensive" "unreceptive“) • Change agent defensiveness may also be more likely when recipient reactions indicate that more effort will be required to accomplish the change than was originally planned or that there will be undesirable budget or other performance impacts, or when the change agent has career consequences associated with the success of the change. • The cost of this defensiveness is the persistence of resistance and its escalation in a vicious cycle, in which resistance be gets resistance.

Answer 84

• Keeping the change on the agenda: Resistance helps keep conversations in existence. Talking in a negative way has been labeled as resistance. It can nevertheless be functional because it keeps the topic "in play“. • Engagement: o Resistance is a form of engagement with change and may reflect a higher level of commitment than acceptance, because some resistance is thoughtful. People might resist simply because they care and wants the best solution. o Change recipients who are highly committed to the success of the organization but who disagree with a proposed change may engage in the change process by expressing their concerns. Such expressions are likely from recipients who are high in organizational identity and psychological ownership. Strengthening: • Resistance is a form of conflict. Conflict has been found to strengthen not only the quality of decisions but also participants' commitments to the implementation of those decisions. Resistance can provide a similar strengthening value during change. • As long as functional conflicts do not turn into dys-functional conflicts. • A world with absolutely no resistance, no change would stick, and recipients would completely accept the advocacy of all messages received, including those detrimental to the organization. Conflict is one of the ways used to help inoculate and immunize people against subsequent change, including backsliding.  One possible outcome of resistance, then, is a potentially stronger commitment.

Answer 85

* Recipient action, which is any behavior or communication that occurs in response to a change initiative and its implementation. * Agent sense making, including agents' interpretations of and meanings given to actual or anticipated recipient actions as well as the actions agents take as a function of their own interpretations and meanings. * Agent recipient relationship, that provides the context in which the first two elements occur and that shapes, and is shaped by, agent-recipient inter actions. * Each of these elements has implications for the reconstruction of resistance. * Recipient resistance is public: only the public behaviors, conversations, and observable activities that contitute the interactions between agents and recipients might be labelled as resistance. * There is no resistance to change existing as an independent phenomenon apart from change agent sensemaking. None of the recipient actions/reactions are, in themselves, resistance, and they do not become resistance unless change agents assign the label resistance to them as part of their sense making. * A lot of things make change difficult – but they are not necessarily resistance: There might be a lot of things (background resistance) that make a change difficult (foot dragging, failing to follow procedures, being late for or missing meetings, complaining, gossiping, failing to perform etc.), but they are not necessarily related to a specific change. * Normal organizational activities and behavior is not resistance: Because change is often associated with greater urgency, pressure, and risk than normal organization activities, agents may be less tolerant of and more frustrated by actions habitually displayed by recipients. * The relationship: The change agent's job surely include responsibility for the relationship with recipients, as well as the tactics of change implementation. * Resistance might be positive: While deviation in a non-managerially prescribed manner is typically regarded as resistance, on closer inspection, this type of behavior may also be revealed as positive or supportive and undertaken in order to overcome the shortcomings of new technology which, for example, is genuinely unable to sustain, monitor or track actual working practices at the same time as allowing employees to work cooperatively or flexibly.

Answer 86

Compliance: assumes that the user interacts with the system in the prescribed manner, although it has been argued that total compliance is unlikely and that a low level of resistance is inevitable Resistance: Resistance, whereby the user opposes or challenges the system prescribed view, can be subdivided into positive or negative perspectives. • Negative resistance is typically manifest by behaviours (or workarounds) such as: physical sabotage; deliberate entering of incorrect data; deliberate omission of auditable steps in procedures and ‘fiddling’ of time targets and production level data. • Positive resistance is typically manifest by behaviours (or workarounds) such as deviation from procedure or covert cooperative working and seeks to support or improve working practices. Workarounds

Answer 87

Hindrance workarounds Hindrance workarounds occur when the use of the system is viewed as too time consuming, onerous or difficult. • The worker perceives that the system is burdensome; they may not see the point or relevance of the data that they are entering and therefore partially enter data, enter approximate data or fail to fully comply with procedure. o Example:  A study of patient care plans in U.K. hospitals, a monthly audit found that according to computer records, one ward had only six patients.  Nursing staff had failed to enter and update patient information seeing accurate data entry as a hindrance and as low priority in comparison to their ‘real’ job of nursing patients. Harmless workarounds Harmless workaround occurs when users do not use the system in the prescribed manner, but their workarounds do not affect workflow or the accuracy of captured data. Essential workarounds Essential workarounds are those regarded as critical or vital by the workforce, even though they do not follow prescribed procedures. • Consider the type of behaviour exhibited by ‘professionals’ who are requesting equipment or dynamically recording emergency incidents and procedures. • The workaround behaviours undertaken are seen by the professionals as essential to the safety of lives, property or situations and are not simply motivated by the protection or defence of professional judgement, status or position.

Answer 88

A core tool for constructing a benefits realization plan is a Benefits Dependency Network (BDN). The BDN provides the framework for explicitly linking the overall investment objectives and required benefits (the ends) with the business changes (the ways) necessary to deliver those benefits and the essential IT capabilities (the means) that enable these changes.

Answer 89

ends-driven because the goal is the target improvements. * Clear targets: When the investment is problem-driven, setting targets is appropriate. The organization can usually identify and quantify the benefits of removing known problems through new IT means and new ways of executing business processes and activities. * The main challenge: agreeing on the best combination of ways and means for accomplishing the improvements.

Answer 90

ways and means-driven because the goal is to discover better ways of working by utilizing IT (the means) or new ways of e.g. organizing (the ways). * Unclear targets: In these interventions, an organization has difficulty specifying the ends because it is uncertain that the new IT capabilities and the business changes can be implemented successfully and what they can be used for. * Unclear benefits: Consequently, the benefits the changes will actually deliver are not clear. * Requires creativity and change: The business value realized from innovation-based investments depends on the organization’s ability to identify, create, and successfully implement advantageous new ways of conducting business and new IT means. * Requires on-gong learning: The uncertainty implies that the objectives and scope may well change during implementation, as the organization learns more about what can and cannot be achieved, and how. * Risk – too much focus on technology: A potential issue with IT-enabled innovations is that the organization pays too much attention to what the technology can do, rather than to the changes the organization needs to make to exploit the technology.

Answer 91

The broad spectrum of task and techniques that lead to an understanding of requirements (to IT systems).

Answer 92

the calculations, information etc that the system has to deliver.

Answer 93

such as security, usability, performance etc.

Answer 94

We have a business process using several IT system. Target: Improve productivity and increase quality with x %. How can we combine IT enablers and business changes to achieve this?

Answer 95

These investments exist when an identifiable opportunity is spotted. The BDN is developed to assess whether or not the organization can make the necessary changes to gain advantage from that opportunity. Example: Driven by new ways: How could our organization benefit from using sharing economy? (a new way of providing services to customers) What is the vision? What are the new ways –the business changes? How can we use IT to make it happen?

Answer 96

These investments exist when a new technology appears to offer opportunities to create an advantage Example: Driven by new means: How could our organization use AI? (new means) What changes to our process would be beneficial using AI? What benefits could be realized?

Answer 97

The most important outcome is the shared understanding and commitment that making the diagram might create between you, IT management and business managent about what this investment is going to achieve and how it is going to be achieved. • The diagram is simple to draw – the difficult part is the shared understanding and commitment between key stakeholders.

Answer 98

Assumptions: The assumptions underlying RE in traditional development include the following: • The customer is able to specify all his/her needs in the initial phase. • One or more stakeholders are in charge of the requirements gathering activity. • The development team can readily understand customer needs. • The structure of the organizations is hierarchical, and there is a sharp separation of the different functions.

Answer 99

Inception (starting point) • Identify stakeholders o “who else do you think I should talk to?” o Make a list of all the stakeholders that must be included • Recognize multiple points of view o Different departments or roles will typically have different, sometimes conflicting requirements • Work toward collaboration o Identify requirement that all agree on and the requirements that conflicts

Answer 100

Elicitation Requirements: • Meetings are conducted and attended by both software engineers and customers: o rules for preparation and participation are established o an agenda is suggested o a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting o a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used • the goal is o to identify the problem o propose elements of the solution o negotiate different approaches, and specify a preliminary set of solution requirements Elicitation work-products • a statement of need and feasibility. • a bounded statement of scope for the system or product. • a list of customers, users, and other stakeholders who participated in requirements elicitation • a description of the system’s technical environment. • a list of requirements (preferably organized by function) and the domain constraints that apply to each. • a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. • any prototypes developed to better define requirements. Eliciting non-functional requirements: • We also try to identify all the non-functional requirements such as security, usability, performance etc. Eliciting functional requirements – use cases: • A collection of user scenarios that describe the thread of usage of a system • Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way

Answer 101

• Elaboration: create an analysis model that identifies data, function and behavioral requirements

Answer 102

Negotiation requirements: • Key stakeholders will be involved in the negotiation • Determine each of the stakeholders “win conditions” o Win conditions are not always obvious • Negotiate o Work toward a set of requirements that lead to “win-win”

Answer 103

• Specification: can be any one (or more) of the following: o A written document o A set of models o A formal mathematical model o A collection of user scenarios (use-cases) o A prototype

Answer 104

Validation requirements: • Is each requirement consistent with the overall objective for the system/product (the benefits defined in the benefits plan / BDN)? • Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? • Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? • Is each requirement bounded and unambiguous? • Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? • Do any requirements conflict with other requirements? • Is each requirement achievable in the technical environment that will house the system or product? • Is each requirement testable, once implemented?

Answer 105

• Is the management effort focusing at: o Managing all changes to the requirements o Maintaining the relationships among the requirements, the project plans, and the work products (and also the benefits) o Identifying inconsistencies among the requirements, the project plans, and the work products o Taking corrective actions if problems are identified

Answer 106

Why Agile RE? • Rapid changes: o The traditional way of requirements engineering (RE) has been challenged by the rapidly changing business environment in which most organizations operate today o Changes in: competitive threats, stakeholder preferences, software technology, time-to-market pressures etc. o Makes requirements evolve or become obsolete: Requirements tend to evolve very quickly and become obsolete even before project completion.

Answer 107

Assumptions: • The changing-requirements assumption: Requirements always evolve. o Therefore, agile development does not spend much time in initial requirements elicitation. Instead, requirements emerge during the development process. • The documentation assumption: Developing extensive documentation and models is counterproductive. o Therefore, agile development does not document requirements in detail upfront. • The customer interaction assumption: Customers are available for frequent interaction with the developers. o Agile development relies on these interactions to elicit and validate requirements. • The cost-of-change assumption: The cost of making changes to the system does not dramatically increase over time. o As evolving requirements do not increase the development cost, RE is carried out iteratively and incrementally

Answer 108

Six agile practices: 1. Face-to-face communication over written speciﬁcations, • Agile software processes prefer face-to-face communication over written speciﬁcations. o The focus of RE in an agile environment is to effectively transfer ideas from the customer to the development team, rather than creating extensive requirements documents. • Simple techniques such as user stories are used to deﬁne high-level requirements. o These short and abstract descriptions serve mainly as anchors for future discussion. o Project managers use them to estimate project costs and schedules. o Requirements are discussed in detail with the customers before and/or during the implementation (programming). • User story: o As a so that I can . o As a cyclist , I want to register my routes, so I can invite other cyclist to join me when training • The effectiveness of this practice heavily depends on the intensive interaction between customers and developers. • The customer needs to be collaborative, representative, available, capable and knowledgeable to provide the right requirements to the development team. • For projects that cannot achieve such high-quality interaction, this approach poses high risks, including inadequately developed requirements or, worse still, wrong requirements • Most agile methods require co-located customers (for example, XP mandates it as a core practice). • However, it is very difﬁcult to implement this practice. Most software projects studied as part of this research did not have direct access to a customer representative. • If a real customer is not available, product managers or business analysts, who have direct contacts with customers, act as surrogates. • A short daily meeting between the team and the customer is another mechanism used to enhance communication. 2. iterative RE, • In agile development, requirements are not pre-deﬁned; instead they emerge during the development process. • Initially, high-level requirement analysis is carried out at the beginning of the project. At this time, the development team acquires a high-level understanding of the critical features of the application, rather than creating a detailed speciﬁcation of requirements. • Requirements are not intended to be complete or cover all the features of the system. They serve as a starting point to plan the initial release cycle of the project. As more is known about the product, more features or user stories are added. • Agile requirements analysis continues at each development cycle. • At the beginning of each development cycle, the customer sits down with the development team to provide detailed information on a set of features that need to be implemented. • Requirements analysis is often intertwined with the design activity. • Although iterative requirements analysis is often associated with dynamic business environments where requirements change frequently, this approach may be appropriate even in stable business environments where the changes often come from unforeseen technical details when using new technologies. 3. managing requirements change through constant planning, • A core principle in agile software development is to adapt and react quickly to changes demanded by the environment. • Accommodating changes in requirements during the development process is a way of tuning the system to better satisfy customer needs. • Changes are easier to implement and cost less in agile development. • In agile development, generally two types of changes are commonly made: o features are added or dropped; o and changes are made to features already implemented. 4. extreme requirements prioritization, Requirement prioritization • Prioritization is essential in requirements analysis, especially for projects that have limited resources in terms of budget, staff and schedule • Requirements can be categorized from the standpoint of importance into o essential requirements, o useful capabilities and o desirable capabilities • The project should deliver the most valuable features as early as possible so that the customers can realize most business value. • During development, the customer’s, as well as developer’s, understanding of the project improves and new requirements are added, or existing requirements are modiﬁed. 5. prototyping, and review meetings and tests. Prototyping • One of the fastest ways to settle requirements speciﬁcations seems to be the development of a prioritized list of features. • Instead of using formal requirements documents, many projects use prototyping as a way to communicate with their customers. • To a certain extent, the production software itself can be a form of an operational prototype. o The rush to market encourages a tendency to deploy these prototypes rather than wait for robust implementations of the desired features. o This can cause problems with issues such as scalability, security and robustness, and prototypes may not be easy to maintain or evolve. 6. Review meeting and tests: • Agile approaches use frequent review meetings for requirements validation. At the end of each development cycle, a meeting that involves developers, customers, Quality Assurance (QA), management and other stakeholders is scheduled. • The review meetings show whether the project is on target and within schedule, increase customer trust and conﬁdence in the team, and highlight problems early. • Acceptance tests developed by the customer, sometimes with help from QA, are used in validation and veriﬁcation. • Requirements validation is also carried out at the iteration planning meeting (up-front), where the team communicates with the customers about detailed requirements.

Answer 109

• However, there are some serious challenges with agile RE. • Problems with cost and schedule estimation: The agile approach towards RE makes the estimation of costs and schedules more difﬁcult than with traditional methods. o Agile development helps create better cost and schedule estimates for individual development cycles, o but because the scope of the project is subject to constant change, it is difﬁcult to create accurate cost and schedule estimates for the entire project. • Inadequate or inappropriate architecture: The architecture chosen during the early cycles may become inadequate as newer requirements become known. o Rework (refactoring) of the architecture may add signiﬁcantly to project cost. • Neglect of non-functional requirements: A major concern with iterative RE in agile development is the inadequate attention given to non-functional requirements. o They are often ill deﬁned and ignored during early development cycles. Customers often focus on core functionality and ignore issues related to scalability, maintainability, portability, safety or performance. • Many organizations suggested that the tendency to ignore critical issues such as security and performance early in the process has resulted in major issues as the system grows • Customer acces and participation: The effectiveness of communication between the customer and team depends on several factors, including: o customer availability; o customer consensus; and o customer trust, especially at the beginning of the project. • The study ﬁnds that onsite customer representation is difﬁcult to attain. Of all the projects studied, none of them had real onsite customers, but only used product managers as surrogates. • Customer acces and participation: • Several customers groups: o When a system involves more than one customer group and each is concerned about different aspects of the system, achieving consensus or compromise within the short development cycle may be challenging. o The development team needs to spend extra effort to integrate the requirements of different segments through negotiation with each customer. • Trust: o The establishment of trust between the customer and the developer can be very challenging in agile development. The customers may come from the traditional development background and do not understand or trust the development process that does not produce detailed requirements or design speciﬁcations. • Prioritization on a single dimension: o The business value-oriented approach to requirements analysis results in better understanding of the business domain and the system, prioritization of requirements, changes to design and elimination of unneeded functionality. o However, using business value (often focused on time-to-market) as the only or primary criterion for requirements prioritization may cause problems such as:  an architecture that is not scalable or  a system that is unable to accommodate requirements that may appear secondary at the beginning of the project, but become critical for operational success (such as security and efﬁciency requirements). • Inadequate requirements veriﬁcation: o Agile RE focuses more on requirements validation than traditional approaches. o Agile RE does not address aspects of veriﬁcation as there is no formal modelling of detailed requirements. o Consistency checking or formal inspections are seldom performed during agile RE. o The lack of clear or complete speciﬁcation of several critical requirements sometimes makes development difﬁcult. • Minimal documentation: Agile RE focuses on communication rather than documentation. o While access to the right customer makes the need for documentation of speciﬁcations less important, close collaboration and proximity to other members of the development team often obviate the need for elaborate design documentation. o However, when there is a breakdown in communication caused by a variety of problems, including the rapid turnover of personnel, rapid changes to requirements, non-availability of appropriate customer representatives and growing complexity of the application, the lack of such documentation may cause a variety of problems.

Answer 110

• In both cases you need to integrate benefits realization (for example using BDN) into RE processes, to make sure that you actually work on the requirements that might support the creation of business benefits. The two approaches to RE (plan-driven and agile) are related to the two different ways of using BDN’s: A plan-driven approach will be extremely difficult when working with innovation-based interventions • It is clear that both plan-driven and agile approaches lacks a transparent and explicit linkage between the business benefits to be achieved and the requirements to IT systems. None of the approaches are benefits driven.

Answer 111

1. Why must we improve? 2. What improvements are necessary or possible? (Key stakeholders must agree to these improvements, which become the investment objectives.) 3. What benefits will be realized by each stakeholder if the investment objectives are achieved? 4. How will each benefit be measured? 5. Who owns each benefit and will be accountable for its delivery? (The benefit owner will be responsible for the value assigned to the benefit in the business case.) 6. What changes are needed to achieve each benefit? (The key to realizing benefits is identifying explicit links between each benefit and required changes.) 7. Who will be responsible for ensuring that each change is successfully made? 8. How and when can the identified changes be made? (To answer this question, the organization must assess each stakeholder group’s ability and capacity to make the identified changes.)

Answer 112

* Principle #1: IT Has No Inherent Value. Just having technology does not confer any benefit or create value. * Principle #2: Benefits Arise When IT Enables People to Do Things Differently. * Principle #3: Only Business Managers and Users Can Release Business Benefits * Principle #4: All IT Projects Have Outcomes, But Not All Outcomes Are Benefits. * Principle #5: Benefits Must Be Actively Managed to Be Obtained.

Answer 113

User involvement might have different purposes o from improving requirements and the design to making implementation easier. o It can - take place in different stages, - be achieved using many different methods (e.g. interviews, prototyping), - and cover anything from symbolic involvement to involvement by strong control.

Answer 114

a frame is a buildup repertoire of tacit knowledge that is used to impose structure upon, and impart meaning to, otherwise ambiguous social and situational information to facilitate understanding.

Answer 115

o Nature of Technology: People's images of the technology and their understanding of its capabilities and functionality. o Technology Strategy: People's views of why their organization acquired and implemented the technology. It includes their understanding of the motivation or vision behind the adoption decision, and its likely value to the organization. o Technology-in-Use: People's understanding of how the technology will be used on a day-to-day basis, and the likely or actual conditions and consequences associated with such use.

Answer 116

• Contributes to success: User involvement does contribute positively to system success. • But it is difficult: It is a double edged sword and if not managed carefully it may cause more problems than benefits. • Used to exploit knowledge: o Know the work the system should support: Users typically have significant knowledge of the application domain, the tasks they perform, work practices, context of the system use and their behavior and preferences. o Some knowledge is tacit: A part of the knowledge is tacit thus difficult to be articulated with typical elicitation techniques (such as interviews). o Better requirements: User involvement might improve the quality, accuracy and completeness of requirements. • But also to ease implementation. The best design is the design “owned” by the users.

Answer 117

* Analysis: Involving users during early phases of development like requirements elicitation is necessary to capturing their needs and to make sure that systems are aligned with business processes. * Design: It is also important to involve users in design – e.g. by having users participate in prototyping. By involving user in design the IT-systems and future work practices can be aligned. Furthermore requirements can be validated. * Programming: E.g. answering questions and clarifying requirements. * Testing: Verifying that the system actually comply with the requirements – and is useful. * Implementation: Change agents. * Senior management may be required to be involved throughout development, e.g. to make sure that projects are properly aligned with business strategies, and middle management and other employees, would be required for their contribution during analysis, design, programming and testing.

Answer 118

``` Phychological perspective • More relevance • Better relations • Increased buy-in • Easier implementation • It supports what Markus labels implementable design • User system satisfaction / acceptance • Facilitating change • Increased customer loyaloty ``` Managerial perspective • It supports what Markus labels implementable design • AND it might reduce costs by decreasing changes later on • Reducing cost of the system • Better communication • Improved Management Practice • Helping in conflict resolution ``` Methodological perspective • More relevance • Better relations • Increased buy-in • Easier implementation • It supports what Markus labels implementable design, and complete design • Better understanding of user requirements • Improving quality design decisions ``` ``` Cultural perspective • What Markus labels A solution where benefits are actually exploited • Increased system usage • Facilitating knowledge sharing • Improving user’s skills ``` ``` Political perspective • What Markus labels A solution where benefits are actually exploited • Democracy in workplace There can be potential conflicts between users and the development team (or just between users) and it is imperative that conflict resolution strategies are available when this occurs. Benefits of user involvement Phychological perspective • More relevance • Better relations • Increased buy-in • Easier implementation • It supports what Markus labels implementable design • User system satisfaction / acceptance • Facilitating change • Increased customer loyaloty ``` Managerial perspective • It supports what Markus labels implementable design • AND it might reduce costs by decreasing changes later on • Reducing cost of the system • Better communication • Improved Management Practice • Helping in conflict resolution ``` Methodological perspective • More relevance • Better relations • Increased buy-in • Easier implementation • It supports what Markus labels implementable design, and complete design • Better understanding of user requirements • Improving quality design decisions ``` ``` Cultural perspective • What Markus labels A solution where benefits are actually exploited • Increased system usage • Facilitating knowledge sharing • Improving user’s skills ``` Political perspective • What Markus labels A solution where benefits are actually exploited • Democracy in workplace There can be potential conflicts between users and the development team (or just between users) and it is imperative that conflict resolution strategies are available when this occurs.

Answer 119

Challenges of user involvement Phychological perspective • Legacy thinking: Users may not appreciate the idea of change in their exiting work environment • Users’ lack of motivation: They may not want to participate or get involved in the project • Users expertise: Users may not have the right level of expertise to participate or get involved and might feel intimidated and resist the system Managerial perspective • Efforts required by users: User participation requires extra work on their part which may not be possible for them Methodological perspective • Impact of change: The development of new system will bring change in the work environment and it would be challenging to introduce and communicate the impacts of such changes. Cultural perspective • Impact of change: The development of new system will bring change in the work environment and it would be challenging to introduce and communicate the impacts of such changes. Political perspective • Conflicts: There is always a chance that conflicts arise between users and development team and effective conflict resolution is required from management.  The top challenge that hinders effective involvement of users is their lack of motivation followed by problems with their attitude and behavior.

Answer 120

The involvement or participation has to be effectively managed to achieve its intended objectives and the desired benefits: Identifying users • Before the selection process, the users are to be identified and the concept of ‘user’ is to be clearly understood: o Primary users are those likely to be frequent hands-on users of the system o Secondary users are occasional users or those who use the system through an intermediary o Tertiary users are those affected by the introduction of the system, or who will influence its purchase • Furthermore you need to consider: o How to fund: allocation of financial resources needed o How to get management support: ensure higher level of management commitment and support • Factors be considered for the selection of the users: o Who will be affected? o What are the characteristics of people in each user category? o What are the characteristics of the task performed by each user category? o What do different users like and dislike about their jobs? o How are the different users likely to react to the system? Who might help / inhibit implementation? Be specific about the goal • Use the five perspectives (Psychological, Managerial, Methodological, Political and Cultural) to design the involvement • Consider which benefits that are especially important, how to avoid the problems and overcome the challenges. o How?  More relevance  Better relations  Increased buy-in  Easier implementation • Depending on the goals you need to consider how to involve: selecting methods for involvement, and • When to involve: decide who should be involved in what stages / decisions of development Consider stages and type of system: • To achieve the benefits in methodological and psychological perspectives, user involvement in requirements phase seems to be the most effective. • For political and cultural benefits, users need to be involved in design and implementation phases • Research indicates that the types of systems being developed create a different context for user participation and therefore have different requirements regarding various aspects of user involvement. • Selection of method for user involvement depends on • The intensity of involvement required in the system development process. • Project complexity • Available technological resources Involvement • Involvement by strong control: users may pay directly for new development out of their own budgets, or the user’s overall organizational performance evaluation depends on the outcome of the development effort • Involvement by doing: a user is a design team member, or is the official liaison with the information systems development group • Involvement by weak control: users have sign-off responsibility at each stage of the system development process • Involvement by advice: advice is solicited through interviews or questionnaires • Symbolic involvement: user input is requested but ignored • No involvement: users are unwilling or not invited to participate • On-site customer: A single user takes part in development. • Representative: All levels and functions of the affected user groups are represented in the system design team. • Consensus: An attempt is made to involve all workers in the user department, at least through communications and consultation, throughout the development process.

Answer 121

Successful user involvement contributes to the alignment of technological frames (shared understanding) between developers and users.

Answer 122

• Technological frames, a framework that can be used to: Examining the underlying assumptions, expectations, and knowledge that people have about technology. • The way we think about and understand technology matters for the way we act: Our understanding critically influence the way we act around technology. • They are critical for both development and implementation of IT systems, and for collaboration with users.

Answer 123

* A frame: A built-up repertoire of tacit knowledge that is used to impose structure upon, and impart meaning to, otherwise ambiguous social and situational information to facilitate understanding * Shapes understanding and action: By shaping individuals' interpretations of organizational phenomena, frames implicitly guide individuals to make sense of and take action in organizations * Operate in the background (unconsious): They typically operate in the background and have both facilitating and constraining effects. * Facilitating effects: Frames are facilitative when they structure organizational experience, allow interpretation of ambiguous situations, reduce uncertainty in conditions of complexity and changing conditions; and provide a basis for taking action. * Constraining effects: Reinforce unreflective reliance on established assumptions and knowledge; distort information to make it fit existing cognitive structures; and inhibit creative problem solving. They might make us less innovative.

Answer 124

• Use of IT requires sensemaking: o To interact with technology, people have to make sense of it. In this sensemaking process, people develop particular assumptions, expectations, and knowledge of the technology, which then serve to shape their subsequent action towards it • Understanding users sensemaking is vital: o Understanding of people's interpretations of a technology is critical to understanding their interaction with it. • But it is difficult because they are taken-for-granted: o These interpretations of technology become taken-for-granted and are rarely surfaced and reflected on • Impacts : Technological frames have powerful effects in design, implementation and use of those technologies • By embodying frames: o IT systems form and function will embody their sponsors' and developers' objectives, values, interests, and knowledge regarding that technology. • And impacts organizations: o An implemented technology carries with it a powerful vision of the society in which it is to be used and a plan for the way people will have to arrange themselves to use it. - You are also sharing frames within communities When you are new in a organization you might observe these frames and get puzzled, but when you get socialized, you don’t notice them anymore.

Answer 125

o A concept used to describe the nature and extent of difference among frames. • High incongruence – high risk: Might create difficulties in, and unanticipated outcomes off, technology implementation • It is especially critical if people responsible for implementation have different frames than other groups – and are unaware of it - and plan implementation based on their own frames.

Answer 126

• Establish proper collaboration between users and developers: By carefully considering the purpose of collaborating with users in the different stages, the benefits and challenges, the methods and different types of collaboration. o Identify the users o Be specific about what the goal is o Carefully consider the degree and level of user involvement o Consider how to collaborate in different stages depending on the type of system

Answer 127

o Create shared understanding between users and developers: By analysing and aligning users and developers technological frames. Attempts to surface the common assumptions, expectations, and knowledge people have of technology can be particularly useful before the design and implementation of a system, to • identify where and why key stakeholder groups' are incongruent, This might reduce the likelihood of unintended misunderstandings and delusions around the implementation and use of a new information technology.  User involvement varies throughout a project – it is especially important in the analysis phase/activity.

Answer 128

A business process: A business process is a collection of • interrelated activities, • initiated in response to a triggering event, • which achieves a specific, discrete result for the customer and other stakeholders of the process.”

Answer 129

Because we know that IT in it self is just a cost – it is only when you change processes and do things differently that IT is valuable

Answer 130

Scope Establish process context, scope, and goals: Define business processes. For each process: What is the scope, content, key characteristics regarding current implementation, goals for the new process. Analyze Understand the current (as-is) process: Modelling of current process and observe factors that has impact on process performance. Design Design the new (to-be) process: Finish the assessment of the current processes, identify, evaluate and chose improvements, and define key characteristics regarding the new implementation. + (Pro’s) • Focus on business processes – not just technology • Diagrams are relatively easy to understand for customers and users • The method includes enablers, that support processes, and contextual factors, that constrains processes and how the might be improved • It shows how IT and processes might be integrated ’- (con’s) • You might get lost in making diagrams – become less agile • Too many details, if not carefull • Not suitable for all kinds of processes – best for relatively structured processes

Answer 131

* Work to be accomplished: Involves work to be accomplished, typically by an organization, or some organizations that collaborate. * Name should reflect the outcome: The name should reflect the outcome of the process as wanted by the customer (e.g. Recruit new employee). * Clear and important outcome: The outcome must be clear, measurable and important for the customer.

Answer 132

Mission: The purpose off the organization – Why it exist? What it does, who it does is for and how it would like to be perceived by the stakeholders? Strategy: How the organization differentiate itself from competitors and why customers should choose this organization? Strategic options: • Low-cost leadership • Product differentiation • Focus on market niche • Strengthen customer and supplier intimacy. In most cases: Improvements should respect the choosen strategic option Goals and objectives • Goals: The direction of improvements – the state you are aiming for. • Objectives: Performance targets that must be accomplished. • Goals and objectives changes: “being the industry’s undisputed leader in customer service” is a goal that will mean different things, requiring different objectives, as the competitive landscape changes. • Must be aligned: Individual processes have their own goals that must be aligned with organizational goals and objectives. • Goals and objectives are used as criteria for choosing between alternative options when designing processes.

Answer 133

Illustrated through a swim-lane diagram

Answer 134

* Enablers: Factors that, when adjusted, can change the performance of the process. * Which enablers has a negative impact or an un-exploited potential? Process modelling and analysis is very much about identifying enablers that has a negative impact, or an un-exploited potential. * Improved according to goals and objectives: The re-designed process is based on changed enablers that secures that the process delivers according to goals and objectives within the constraints the process must respect.

Answer 135

The essential characteristic of the Technochange prototyping approach is that each phase (iteration) involves both new IT functionality and related organizational changes, such as redesigned business processes, new performance metrics, and training. Technochange: Each iteration focus on software + organizational changes and the integration off the two Combining Technochange and business process improvement implies that each iteration would focus on all the enablers for a part (a sub-process) of a business process

Answer 136

--> Enablers make a process work in real life • Needs to be aligned: A process will not work before the enablers are co-specialized and aligned with each other (e.g. that systems match the process – that a BI systems match the decisions in a process) • Process improvement is about more than IT and workflows: For example it might require new incentives or different facilities • The enablers must support each other and facilitate the overall goals and objectives • Enablers are like handles you can turn up or down to change the process

Answer 137

It is vital that the processes and the improvement project are properly scoped: • The participants should be able to recognize the processes • You should focus on processes and how to improve them – not on technology • You should not define what the problem is too fast – we want to fix the real problem and sometimes we don’t see the problem in the beginning. How to discover business processes: 1. Prepare and manage the process (read about it) 2. Understand the organization: Collect background information, meet the sponsor and learn about: strategies, business model, problems, goals and participants? 3. Understand processes: Understand processes from the perspective of the various functional departments: Responsibilities, problems, process activities, key concepts? 4. Define processes: Connect activities, identify processes by analyzing the links (1:1, 1:M, etc). Validate and name the processes. 5. Choose process to be improved: Using experience or a systematic approach.  Processes are most easily discovered buttom-up because that makes them easier to recognize. This is done in workshops involving employees. Focus on knowledge sharing, multiple perspectives and commitment.

Answer 138

``` A process area contains processes that: • Concerns the same topic • Contribute to the same goals • Share information • Are inter-dependent ```

Answer 139

Key concepts: • It is easier to identify processes when you agree on the on the objects – or key concepts – that they work on and need information about • The concepts are later on used to name processes and when designing information systems you will be interested in how they are related and which information that is needed for each of the concepts • Critieria for key concepts: o Information is needed: It is something that the organization needs information about o More than one: There is more than one instance (e.g. there are multiple accounts) o Different: The instances can be separated from each other (e.g. we know the difference between all accounts in the bank) o Used by processes: Processes operates on the concepts (e.g. there is a process that creates new accounts in the bank) o Refers to the essence: Not the implementation (“what, not how”) so it is not a report, form, list, query, screen, metric, or other depiction of things and facts. Key concepts vs. Key activities Key concepts: Order, facilities, customer, customer equipment, call… Key activities: Take service order, Assign central office facilities…

Answer 140

Two methods: • Divine Intervention: Thou shalt fix business process X! Which is not even a process. • Systematic analysis: How important is it for our CSF’s (Critical succes factor)? How good is the process? * Difficulties: How difficult would it be to improve the process? * Customer value: Is the process closely related to our customers? * Easy wins: Is the process complicated – or are there easy wins? * Management commitment: Is management committed to improving the process? * Sequence: Are there any dependencies that implies that we should improve this process first? * Other issues: Are there any other issues that makes it attractive to improve this process first?

Answer 141

Establish process scope and content is performed for the chosen process… • Your scope will clarify exactly what a project will include, and, just as important, what you’ll exclude. • This can be a tricky area, because your scope should be small enough to master, yet large enough to make a difference. • The scope must match the authority and responsibility of the managers involved – they should be able to implement the changes • Start: What triggers the process ? (the real triggering event) • Stop: What outcome do the process have for the various stakeholders? o Customers, other employees…? o Products, services, quality or performance criteria? • Process: Are their any sub-processes? o A sub-process marks that an importent milestone has been reached • Variations: In which major ways does the process variate? o For example different variations for hiring different kinds of employees? • Departments: Which departments participate in the process? • Actors: Which actors participate from the various departments? • Support: Systems, tools, documents, data etc that supports the process

Answer 142

Understand what needs to be changed and document in a ”process case for action”. • The process case for action is a concise statement of why the current process cannot be left as is, and the process vision articulates the goals for the to-be process.  Neither will work unless they are completely factual and unexaggerated. * Stakeholders: For each stakeholder investigate which problems the stakeholder thinks should be fixed? * The context: What has changed in the context that makes the process less than optimal? * Enablers: Any problems? * Consequences if not fixing the problems: What will happen if we don’t fix the problems? Considering the process from the perspective of each distinct stakeholder, one at a time, yields insights that would be missed otherwise. * Workflow Design: For example if there are any activities that do not create value? Information systems: Does the systems fit the process? Is the right tasks automated? Does our BI solutions support decision-making properly? * Motivation and Measurement: Do we use the right incentives? * Human ressource: Do we use the right people – do they have the right skills? * Policies and Rules: Are policies and rules adequate?, are they actually used? * Facilities: Are facilities supporting work properly? Poorly thought out motivation and measurement are the root cause of poor process performance in the majority of cases we study Vision • In which direction should we improve? o Consider each problem for each stakeholder o Describe how this problem is solved in the future o If possible, describe objective performance measures and goals Synthesize all of the goals for a stakeholder into a single statement that describes their experience with and / or perception of the process. If your competitive environment has changed drastically, you might need to fundamentally rethink what you are doing, not just how you are doing it. A process that does the wrong things faster doesn’t really help—as Ghandi said, “There’s more to life than increasing its speed.” Don’t promise more than you can deliver—it’s supposed to be inspiring, but plausible Strategy Assume that your process customers could select among several competing processes—what would make them select your alternative? Limitations: The process context constrains the possible solutions – solutions that require changes to organizational culture and fundamental beliefs are not solutions.

Answer 143

Swimlane diagrams show the flow between steps (activities) in a process The diagram illustrates: • What is done – the steps in a process • By who – the actors in a process • The sequence of the steps An actors responsibilities are defined by the steps accomplished by the actor Swimlanes are used to: • Make a process visible • To make an assessment of the process • To design IT systems that supports the process Sequence and dependencies (time) flows from left to right ``` Actors Generally, an actor is any identifiable person or group that handles the work (whether or not it is a “value-added” contribution) between the initial event and the achievement of the process’s result Examples: • Customers • Central actors • Actors that supports central actors • Other processes • Places where work products are stored • Systems and machines Named by job title ``` Steps and decision “A step represents some unit of work performed by an actor” Steps can: • Involve more than one actor (e.g. conversations, meetings, one actor helping another) • These steps are called collaborative steps Steps can be parallel • These steps are called concurrent steps Naming: • Action verb (assign, validate, sort, …) • Optional qualifier (initial, replacement, …) • Noun(s) (service request, payment, …) • Optionally, information on how (on Form MS-17, by fax, …) When interviewing an actor: Not all the tasks performed by an actor might be relevant for this particular process. Flow • A flow illustrates how work flows between steps • A handoff is a flow where work changes from one actor to another – from one swim lane to another • Pay attention to handoffs: o “They are a focus for process analysis, because they are often a source of the “three deadly sins”—delay, errors, and expense.” • A flow indicates dependency – that next step cannot start before the previous step is completed. • A conditional flow comes after a step where a decision is made.

Answer 144

3 levels of detail • Hand-off – the level we are using here • Service level – more detail. Each step at the hand-off level is broken down to smaller and more detailed steps • Task level – even more detailed --> Hand-off will be sufficient for our purpose in most cases

Answer 145

1. Prepare and manage the process There can be resistance against using time on modelling the existing process – it has to be changed anyway, but.. • We have to understand the causes behind bad / good process performance • We have to know who contributes to the process • We want to base improvements on facts • It is a good idea to have a baseline • It is needed to prepare change management and training: People need to now what is changing • To learn about dependencies to IT systems and other processes “Most of all, experience shows time and again that even though workflow design is usually not the real issue, the workflow model provides the best framework for uncovering what the real issue is.” * There is occasionally the desire not to include front line workers because (a) they’re really busy, and (b) “we know what they do.” * Whatever the reasoning, this is among the worst ideas that come up during process improvement projects. The problem in all cases is that knowing how things are supposed to work is no substitute for knowing the day-to-day reality of how things actually work. * You will always get a better understanding of process behavior when the people in the process participate. Looking ahead, participation leads to buy-in that will be invaluable when you get into process redesign and implementation. 2. Develop the first version of as-is hand-off level workflow model • Flow first – then details • Flow first – assessment later • Flow first – improvements later • Primary flow first – the alternative flows later one at a time • We make models that illustrates how work actual take place – not how it is supposed to take place • If we cannot model specific details – then describe them in text 3. Validate the model and develop a new version • Hand off : How does work get from one step to the next? • Naming: Do the names describe the outcome of the step? • Trigger: What initiates a step? • Actors: Do we miss any actors? • Outcome: Are all results / outcomes incorporated? You should always finish by confirming your conclusions through direct observation, what is known as walking the flow . * Confirm stakeholder assessment and process goals from initial assessment * Capture first impressions of process strengths and weaknesses * Identify leverage points * Assess by each enabler in turn, generating process improvement ideas * Assess individual steps * Make the initial decision on what to do with the process—leave it as is, abandon it, improve it, and so on * Consolidate process improvement ideas * Design new process * Validate Confirm initial assessment: Is the case for action and the vison still valid after having made a model of the as-is process?

Answer 146

* Identify leverage points in the as-is process. * A leverage point is a point where a relatively small change can have major impact * Leverage point typically is in the beginning of a process Improvements at the front end of a process often have major impact through the rest of the process. You must concentrate on the vital few defects that cause the majority of loss, not the trivial many.

Answer 147

Work Flow Design: • Are there too many actors? • Do exceptions or “tough stuff” get in the way of the other 80 or 90 percent? Process redesign often involves “triage” at the front end to direct an instance of the process into a flow that is designed for that particular case. • Are roles undefined, leading to confusion about who is responsible for what? Assessment of individual steps • Is the step supported appropriately by enablers? The rest of the enablers • Information Systems: For example.. Are systems tailored to the process? Are they integrated, or do actors move information from one system to another? • Motivation and Measurement: For example… Do we measure and reward behavior that actually matters for our customers? • Human Resources: For example… Do actors have the knowledge and skills needed for performing the steps? • Policies and Rules: For example.. Are there unnecessary policies and rules that make processes difficult? • Facilities: Do the facilities support the processes properly?

Answer 148

* Kill the process: simply kill the process – it does not create any value. * Outsource the process: get another organization, the customer or citizen, or the crowd to do the job. * Keep the process: keep the process as it is. * Optimize the process: keep the structure of the process and optimize it. * Re-engineer the process: change the process radically.

Answer 149

Pitfalls • Tunnel vision — focusing exclusively on workflow and IT: Use a holistic view • Paving the cow paths — simply automating or re-automating the as-is instead of rethinking it: o challenge underlying assumptions. • Unanticipated consequences — Implementing “improvements” without understanding what it will take to make them work and what the consequences will be: o Assess each potential improvement enabler by enabler to ensure that process requirements (and consequences) are understood. To-do • Describe major characteristics of the to-be process –this is the specification for the new process • Make swimlanes for the to-be process • Evaluate with stakeholders To-be specification • Start from the assessment results and the ideas developed here o Explore and refine the ideas o Focus on leverage points • Get inspiration from other processes and companies – but tailor ideas to this specific process • Explore the enablers – do they offer obvious opportunities for improvement ( for example new technologies) • Test the ideas (conduct a challenge session). • Evaluate the ideas from the perspective of all the other enablers (e.g. what would using this technology imply for HR) • Choose the ideas for the to-be specification --> Document the characteristics of the to-be process

Answer 150

From technochange - We must design a complete solution:  The additional changes required to make IT productive can be called complementary changes. Examples are: Changes in business processes and workflow, new job designs, new skills training, and so on. - The entire proces: The vision for the new process - The assessment of the old process - The process specification - The workflow: Designing the IS of a part of the workflow – here the workflow refers to a swinlane diagram:

Answer 151

* Understanding: Somehow you need some kind of understanding of what your systems is going to be used for – the work (or entertainment) it is going to support. Maybe it is only in your head, and maybe your theory about the work is wrong. * Designing: You also have to design the system, the user-interface, the functions and information provided by the user interface. Maybe the relation between your theory about the work and the design is explicit and documented – maybe it is only in your head. Maybe the relation is weak and wrong, maybe you actually nail it. * Evaluate: Your design will be evaluated – maybe the evaluation is actually planned, maybe the system is just put into production and the design will be evaluated when it meet the users. Understanding work Understanding work will lead to some kind of idea about the different activities performed by an actor in a process step For example in the “Prepare enrollment package” future students: (illustrated in a swinlane diagram) 1. Prepare photographs (passport size) 2. Make a copy of passport 3. Get transcripts of your previous education 4. Provide proof of English proficiency 5. Make a Curriculum Vitae with Work certificates/references 6. Include a health practitioner’s report We try to breake down the proces steps. What does the user do and what does the user really need? Designing work and supporting systems Then for each of these activities you will design the functions and information provided by the system that might support the activity. • For example “Prepare photographs”: o Information: The systems should contain passport size photographs of a future student. o Functions: The systems should contain functions to upload, display, and delete photographs of students.  All the information and functions will then be packaged into a window / web-page / app that supports the entire step (or part of the step) in the process Evaluate the design Your design will be evaluated – either before you release it for use, but certainly when the design meets the user in real use.. • Maybe you will get to know the outcome of the evaluation and use that to improve the design. But in many cases you will never know what the users think about your design. Of cause in most cases we will already evaluate the design the in the implementation proces.

Answer 152

Understanding work • Level of data collection: You might just use the understanding of the work that you already have, you could ask an on-site customer as in XP, you could interview users, you could observe users doing the work, or you could apply advanced techniques for eliciting expert knowledge.. There are many more options. Furthermore, you have to decide how many users, and which users, to collect data from. • Level of description: You could choose not to make any descriptions and just keep the understanding of work in your head, to have very short descriptions like user-stories in XP or chose to have more detailed descriptions and diagrams like use-cases. • You could choose to invest less in understanding and more in evaluation (e.g. using prototypes), which is the choice in agile methods. Consider the level of data collection: We could choose to have just an one-site customer and ask that customer. Observation takes a lot.more time - a lot more time demanding. Prototypes can be compared to a field experiment. This also requires less data. - Relying on on-site customers - Using use-case - Observing the future users in context - Elicit expert knowledge

Answer 153

1. Relying on on-site customers This is the agile approach: A on-site customer is added to the team. The on-site customer writes user-stories that describe scenarios (very high-level use cases) that the system should support.

Answer 154

2. Using use-case 1. The starting point could a swimlane diagram of the business process 2. Then for each of the steps we (e.g. Prepare enrollment package) we will develop a use-case describing how the step is performed by the actor using the new system 3. Based on the use-case we will the design the system in terms of which functions and information the system should provide (or store) to make the use-case work Use-cases: Remind us about the simple approach about how to collect data from users. Starting point: Swim-lane diagrame. “[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).” Ivar Jacobson The inception and elicitation (the classic requirement engineering techniques) and the business process provide you with the background information you’ll need to begin writing use cases. You will need more meetings with the act The photograph in passport size example: For each of the activities in the step consider: • Should the system support the step (e.g. should we use the laptop camera to make a photo) • Which kinds of functions and information should the system contain to support the individual activities? Questions in each use-case: Each use-case answers the following questions: • Who is the primary actor, the secondary actor (s)? • What are the actor’s goals? • What preconditions should exist before the use-case begins? • What main activities are performed by the actor? • What variations in the actor’s interaction are possible? • What system information will the actor acquire, produce, or change? • Will the actor have to inform the system about changes in the external environment? • What information does the actor desire from the system? • Does the actor wish to be informed about unexpected changes?  Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario. Review Each use-case should be reviewed and refined to see if alternative interactions are possible • Can the actor take some other action at this point? • Is it possible that the actor will encounter an error condition at some point? If so, what? • Is it possible that the actor will encounter some other behavior at some point? If so, what?

Answer 155

3. Observing the future users in context • It is by understanding each person in the context of that person’s work that the team comes to understand the whole work problem • It is the relationship between designers and customers that determines how well the design team understands the customer problem: This includes not only the overall relationship between design team and customer community, but the individual, minute-by-minute process by which a single designer works with a single customer to understand the customer’s work. The designer • Designers will build different systems depending on how they understand their customers’ work. • The most important of rule is a commitment to designing from actual, observed data rather than from personal experience. Benefits: • Teaching ability is not needed: Customers, are not natural teachers. A master teaches by doing the work and talking about it while working. This makes teaching simpler. • Seeing the work reveals what matters: People are not aware of everything they do. Each step of doing a task reminds them of the next step; each action taken reminds them of the last time they had to take such an action and what happened then. • Seeing the work reveals details: Talking about work while doing it allows a master craftsperson to reveal all the details of a craft. While working, the master can describe exactly what he or she is doing and why. As master or apprentice observes a pattern or principle in action, he or she can point it out immediately. Every action customers take and every object around them helps them talk about what they are doing in detail. • Seeing the work reveals structure: Observing multiple events and multiple customers learn us about the common strategies underlying the work. Once we understand the basic strategies, we can start to imagine a system that would support those strategies Sequence model In this method the designer observes practice and makes a sequence model describing what she observes. 1. Such a model is made for several user doing the same step in a process 2. Based on these models the general structure of work can be identified What we list in the model is the actions that people acutally take to do their job. Apprenticeship model The designer must be responsible for seeing work structure and: • the strategy to get work done, • constraints that get in the way, • the structure of the physical environment as it supports work, • the way customers divide work into roles, • the recurring patterns in their work, • and what all this implies for any potential system. The detail the apprenticeship model makes available and the dialog it encourages make it easy to see work structure and reveal opportunities to improve work with technology. Improvements: • The apprenticeship model allows both designer and customer to introduce design ideas as the work suggests them. • The customer can respond to the idea while doing the work the idea supports. There is no better time to get feedback on an idea. • The designer expands his or her understanding of the work in this way: if the idea does not work out, there is some aspect of the work the designer is not accounting for. Validate understanding • If designers do not articulate the structure they see to their customers, they cannot get their understanding corrected. • The system they build based on their inaccurate understanding will not be useful. Designers cannot afford to find out they do not understand by building the wrong system. • Even iterating prototypes will be a long and difficult process if the basic understanding of the work is wrong • Designers fail in the entire purpose of working with customers if they do not share and validate these interpretations.

Answer 156

Sequence model In this method the designer observes practice and makes a sequence model describing what she observes. 1. Such a model is made for several user doing the same step in a process 2. Based on these models the general structure of work can be identified What we list in the model is the actions that people acutally take to do their job.

Answer 157

Apprenticeship model The designer must be responsible for seeing work structure and: • the strategy to get work done, • constraints that get in the way, • the structure of the physical environment as it supports work, • the way customers divide work into roles, • the recurring patterns in their work, • and what all this implies for any potential system. The detail the apprenticeship model makes available and the dialog it encourages make it easy to see work structure and reveal opportunities to improve work with technology. Improvements: • The apprenticeship model allows both designer and customer to introduce design ideas as the work suggests them. • The customer can respond to the idea while doing the work the idea supports. There is no better time to get feedback on an idea. • The designer expands his or her understanding of the work in this way: if the idea does not work out, there is some aspect of the work the designer is not accounting for.

Answer 158

4. Eliciting expert knowledge For decades we have tried to improve human performance in decision-making tasks. These efforts include for example: • BI & machine learning: o the development and implementation of technologies to aid or automate cognitive and behavioral components of human performance; • Training: o attempts to speed up the training of individuals to expert-level in task performance A common element that exists in all efforts to improve human performance is a specification of the skills and knowledge used by experts: Very experienced managers etc.

Answer 159

• The Critical decision method (CDM builds) elicit expert knowledge by studying critical incident trying to understand the bases for situation assessment and decision-making during non-routine incidents: o How does experts make decisions in critical situations – what kind of knowledge are they using to make the decisions? • Using CDM you interview expert decision-makers to examine recent cases of interest – for example o the latest hard decision made by a manager, or o the latest critical decision made by a doctor or a firefighter etc. • The approach is especially valuable for examining skilled performance under time pressure, where there is a limited opportunity for conscious thinking. • In this method we are not just gathering data from random users: o We try to learn from the best and use this knowledge to design information systems and training material that allows other user to reach a similar level. • We study (in detail) the o general knowledge, o specific information, and o reasoning processes an expert uses, and o model the task in a way that exhibits some of the properties of the expert being modeled. • This model can be used to identify opportunities for improved training of non-experts and for aiding and supporting decision-making using IT.

Answer 160

Knowledge Expertise is based on different kinds of knowledge: • Explicit knowledge: One class of knowledge necessary for expertise is explicit and objective knowledge- factual knowledge, rules, and analytical procedures. The kind of knowledge you read in papers and learning in this course. • Tacit knowledge: A second component of expertise is “tacit knowledge”. For example specific skills or intuitions that takes years to train. Contextual knowledge is viewed as the background of practices enabling experts to articulate if/then rules and apply analytical procedures. Analogical reasoning is sometimes explicit, but tacit inferences may be drawn by the way the situation is recognized. Judgments of typicality are tacit since you don’t have to analyze a situation to determine that you experienced similar cases in the past. • Perceptual-motor feel: As skills are mastered, finer discriminations are made and tools come to be manipulated automatically. Flying an airplane, driving a car, playing tennis, and putting out fires in apartment buildings all require perceptual learning, whereas chess and computer programming do not. Don’t forget tacit knowledge • It may not be possible to analyze tacit knowledge, but knowledge elicitation methods should describe the function served by tacit knowledge in proficient task performance so that it should not appear that explicit knowledge is sufficient for proficient performance. • If the knowledge elicitation method is insensitive to tacit knowledge, then it is easy to draw the mistaken conclusion that explicit knowledge is sufficient for performing a task well.

Answer 161

Step 1 – select incident • Incidents are selected that can illustrate nonroutine aspects of a domain, and illustrates the expertise of the interviewed person. • The idea is to probe for components that go beyond the general knowledge and procedures that enable a competent individual to perform routine tasks: we want to study those components that might discriminate the true expert. • In doing this, it makes sense to select cases that presented a unique level of challenge for the individual. • Thus we ask the decision-maker to select an incident that was challenging and that, in his or her decision-making, might have differed from someone with less experience. Step 2 – Obtain unstructured incident account The interviewed experts is asked for an unstructured initial description of the incident. The purpose is: • To create a context for understanding. It is important to have a sense of the expert’s awareness of the event to avoid our own biases. • To activate the experts memory of the event as a context for questioning. • To achieve a high level of cooperation from the expert by establishing us as listeners rather than interrogators. Obtaining cooperation is absolutely essential to any knowledge elicitation effort. Step 3- Construct incident timeline Reconstruct the account in the form of a timeline that establish the sequence and duration of each event reported by the expert. • Events include both objectively verifiable occurrences (e.g., “the second alarm equipment arrived two minutes later”) and • thoughts and perceptions reported by the officer (e.g., “the color of the smoke indicated the presence of a toxic substance. I thought I might have to call a second alarm at this point”). The timeline serves to establish a shared awareness of the “facts of the case” from the experts’s perspective. Inconsistencies in the account are detected and corrected on the basis of the timeline, and missing facts filled in. Step 4 – Decision point identification • During the timeline construction, specific decisions are identified for further probing. o In some cases the verbal cues marking a decision are obvious (e.g., “I had to decide whether it was safe enough to send my crews inside”), but this is not always the case. o In other cases, it is clear that an expert is taking one of several possible courses of action or is making a judgment that affected the outcome, but there is no clear indication that the expert saw him/herself as “making a decision” at this point. o A decision point is probed if the expert agrees that other reasonable courses of action are possible or that another expert (perhaps one with less or greater expertise) might have chosen differently. Step 5 – Decision point probing Different studies use different probes to understand how decisions are made. Example probes: • Cues (characteristics of the situation): Questions to elicit the details of cue usage is asked first as part of the timeline construction, and represented the current information that is likely to have been heeded at each event time. • Prior knowledge: is also probed. Prior experiences that influence the expert’s understanding or expectancies about a situation. • Goals: are an important part of situation assessment. It is important to elicit the specific goals that the expert had in the specific situation.

Answer 162

Cognitive probes Many of the probes in the critical decision interviews are directed at gaining specific cues that were used in formulating a situation assessment or considering options. Many of these cues are not spontaneously mentioned by decision-makers and do not result from asking very general questions like “Why did you make this particular decision?” This is why cognitive probes are needed.

Answer 163

Situation Assessment: Because decision-making is perceived as a form of complex pattern matching, much of the expertise elicited appears as situational assessment that we see as the expert’s understanding of the dynamics of a particular case.

Answer 164

* Level of creativity: There are 1000 different options even for a small step in a process like “Prepare enrollment package” e.g. from providing a complete solution where the system contains windows to make the entire enrollment package to the minimal solution of having the user upload a pdf file containing the information. You have to choose how much you will invest in stimulating creativity and how many different alternative solutions you want to explore. * Level of description: You could choose not to make any descriptions and just keep the design in your head until you start programming like in XP, to have text-based descriptions of your design or diagrams, simple muck-ups or fancy prototypes. You could choose to keep the relation between your understanding of work and the design in your head or chose to make it explicit. The more critical the process is the more you will invest in the design proces.

Answer 165

* When to evaluate: For example, you could choose to evaluate the design while it is being made, like in XP where you have an on-site customer to consult with and show your design to. You could choose to evaluate the design when ending each iteration, or you could chose having the user evaluate the design when it is put into production. * What to evaluate: You could choose just to tell about your design and get some comments, to evaluate the design by having users or other developers evaluating diagrams and documents describing the design, or evaluate the design using prototypes or the final system. You could consider completeness, implementability and benefits? * How to evaluate: Basically, there are two options: You can let other people read / see the design and provide comments, or you can make them use the design and see how it works. Both options can be done more or less systematic and formal.  In all 3 steps we have to decide how much we want to involve the user (lecture 6) However there are some obvious factors that might help: • Considering the importance of the particular part of the system • Consider the risk involved • Consider the benefits you want to achieve • Consider the costs Reflections:  The specific methods presented here are all weak in the sense that they only to a limited extent helps design what Markus calls the complete package.

Answer 166

We begin by ‘testing-in-the-small’ and move toward ‘testing-in-the-large’ • The module (component) is our initial focus • Integration of modules follows

Answer 167

* Collect information about errors: Information about software errors is collected and categorized. * Identify the underlying causes: An attempt is made to trace each error its underlying cause (e.g., non-conformance to specifications, design error, violation of standards, poor communication with the customer). * Identify the vital few causes: Using the Pareto principle (80 percent of the errors can be traced to 20 percent of all possible causes), isolate the 20 percent (the vital few). * Remove the causes: Once the vital few causes have been identified, move to correct the problems that have caused the errors.

Answer 168

The factors that impacts programming productivity can be divided into technical factors and soft factors.

Answer 169

Tailoring of ERP systems encompass both configuration and modification.

Answer 170

There are formal controls (outcome and behavior) and informal controls (self-control and clan control) that can be used when controlling (outsourced) development projects.

Answer 171

We will look into key issues in three different possibilities for accomplishing the programming effort: 1. Programming from scratch internally (factors) 2. Buying a standard application (tailoring) 3. Outsourcing development to a vendor (Hoe to control the vendor) (Crowd sourcing - covered in lecture 3)

Answer 172

Programming from scratch internally in your organization Here we will focus on how to achieve a high level of productivity. Issues: Two issues has been given much attention from both research and practice: • How to achieve a high level of productivity (programming faster). • How to achieve a high level of predictability (estimate when we will be finished). Here we will focus on the first issue. Productivity • Development company attempts to predict, control and improve their productivity. • When estimating and planning a project you need some kind of measure that you can use to determine the size of a program in your system – and you will then use the size to estimate how many hours programmers will use to develop the program. • However, it is hard to measure productivity for software development: o How do you measure the size of a program? o Which activities (time) should be included when calculating productivity? • In software development lines-of-code (LOC) (and other measures) has been used to estimate and determine the size of programs, and productivity has been measured as the amount of LOC produced per hour by a developer. o However, you don’t necessarily use more hours as the number of LOC increases (e.g. if it is easy because you have done something similar before) - Technical factors - Soft factors

Answer 173

The technical factors that has impact on programming productivity can be divided into three categories: - Product – the program might be more or less complicated Not surprisingly it matters if we have developed something similar before and are able to reuse previous work, how difficult the requirements are (e.g. reliability, user friendliness, various constraints), how complicated the system is (e.g. complicated business rules), and how large it is. Size impacts productivity for several reasons: E.g. more people are needed for large systems which increases overhead. Furthermore most components in a large system are different. - Process – the programming process might be more or less efficient The way we work – the process we use – matters for productivity. It matters whether we pro-actively reduce risk that might create problems later, whether we have a well-defined process that is understood by all participants, that we are not set back by major changes (platform volatility, prototyping, concurrent hardware development), that we know what to program before we start, that we do not have to over-staff the project, and that we find errors early and remove them efficiently and effectively. - Development environment – the development environment might be more or less supportive The adequacy of our tools and the methods that we use has great impact on productivity. Programming in a high-level language, for example, is much easier that programming in assembler (a low level very technical language).

Answer 174

Factors that affect productivity can be divided into following: - Corporate culture and team culture Culture is difficult to change – but it matters a lot for productivity. As a project manager or participant you have some impact on team culture. As a project manager it might pay-off to invest in initial efforts that affects team culture positively such as team building. - Capabilities and experiences The difficult part is defining what it is. In XP pair-programming is suggested as a way to even out capabilities by having experienced developers working together with junior developers. - Environment The E-factor might have become even more important because social media applications, mobiles, mails creates lots of disturbances. - Project A hectic, far to compressed schedule decreases productivity. Requirements changes also decreases productivity (even though they might increase the value of the system). Productivity is generally lower in larger teams due to increased overhead, communication and coordination

Answer 175

Here we will focus on issues concerning how much and how to tailor ERP systems to the specific organization. Instead of developing a system from scratch we might buy (and tailor) a standard system.

Answer 176

* ERP packages / systems: are software programs developed by independent software vendors for sale to organizations that use them. * General needs: Packages are designed to meet the general needs of a class of organizations, rather than the unique needs of a particular organization, as is the case in custom software development. * Attractive compared custom software development: to By adopting standard packages, organizations can substantially reduce the costs, risks and delays associated with custom software development. * Support services: And they can benefit from the on-going support services provided for packages by vendors and consultants. • ERP systems do not neatly fit the traditional distinction between “custom-built” software and “off-the-shelf” packages in several important respects: o The scope: The scope of ERP packages is much broader than that of early software packages (like mainframe-based financial software or PC-based personal productivity tools). o Support and integrate all functions in a company: ERP packages integrate many formerly discrete applications around a common database. They enable adopters to integrate data and processes throughout the organization, and they support nearly all functions, e.g., accounting, human resources, operations and logistics. o Are more complicated: This means that they are much more complex than traditional packages, requiring more knowledge, effort and skill to adapt them to the characteristics of a particular organization.

Answer 177

• ERP systems are flexible (to some degree) o ERP packages allow for a great deal more flexibility in the way a company operates than traditional packages do, because business processes are not hardcoded • “vanilla implementations” of ERP packages o are much more likely to be successful (from a development perspective) than implementations that require modifications of package code. • However: o Many companies have had to modify ERP software to meet essential business needs. • So how should companies: o Understand and choose the right strategy for tailoring packages?

Answer 178

When changing ERP packages we distinguish between: • Configuration refers to setting parameters in the package to reflect organizational features. • Modification refers to changing package code to perform unique business processes, often resulting in loss of vendor support. • Tailoring encompass both configuration and modification and a range of options in between. Cost of modifying • Modifying software packages (whether traditional or ERP packages) is often strongly discouraged. • Software license agreements may deny adopters access to source code and explicitly prohibit the making of modifications. • Vendors may refuse to make changes themselves, claiming high development and maintenance costs and low market demand. • Even when vendors allow access to the source code by the adopter or a third party for the purpose of making modifications, they may refuse to provide future support for the package.

Answer 179

* ERP packages are generally structured so that both data and many procedures are represented as parameters in tables— many thousands of tables in the most elaborate packages. * Implementation involves setting parameters to represent both fixed organizational data (such as the number and location of sales offices) and whether and how particular processes should operate. * As a result, many more unique organizational circumstances can generally be supported by ERP systems without program modifications than is true for traditionally designed packages. * Because of the way ERP packages are designed, some tailoring is always required to get them up and running. But the extent of the tailoring can vary from one organization to the next, based on a number of factors.

Answer 180

A difficult choice: Many ERP adopters must face a painful choice when adopting a package that works differently than they do. 1. Adapt the organization to the software: They can adopt the business process built into the software, making the necessary organizational changes such as departmental reorganization and shifts in job duties. 2. Live with lack of fit: They can just live with the lack of fit between the package and their procedures which entails problems and inefficiencies such as redundant manual processes and other workarounds. 3. Adapt the software to the organization: They can try to adapt the ERP package to the organization’s existing business process. This is where tailoring comes in

Answer 181

* Which types: are applied. Configuration much easier (from a programming perspective) than package code changes. * How extensively: a particular type of tailoring is applied. * The number: of different tailoring types used, which may be an indicator of tailoring complexity * Changes to data: the degree to which tailoring changes the data stored in the system or the data structures. * Interdependence: among tailoring efforts. * Protection: The degree to which tailoring can be “protected” when the system is upgraded * Organizational complexity and geographic dispersion: which influence the scope of tailoring effort.

Answer 182

A choice between development and implementation problems: • The greater the “impact” of tailoring on the ERP system, the more likely it is that the ERP system implementation project will encounter difficulties and suffer on cost, schedule and performance metrics. • The greater the “impact” of tailoring on the ERP system the more likely it is that organizational adaptation to the ERP system will be easy and that the system will meet the needs of the business. Maintenance problems: • The greater the “impact” of tailoring on the ERP system the more likely it is that that a company will experience difficulties when attempting to upgrade to a later package release or convert to a later package version.

Answer 183

Here we will focus on the how to control the vendor. Outsourced systems development projects creates unique problems that make controlling them challenging: • Controlling vendor behavior: client may lack the direct authority to prescribe vendor behaviors. • Difficult to monitor vendor behavior: It is more difficult to monitor vendor behavior due to geographical distance, coordination problems, and loss of communication richness. • No existing reporting relationship: There are usually no pre existing reporting relationships or systems that can be used to facilitate control • Cultural differences: Another challenge, not mentioned by the paper, is cultural differences when outsourcing development e.g. from Denmark to India

Answer 184

• This paper views control broadly as attempting to ensure individuals act in a manner that is consistent with achieving desired goals • A control situation typically involves an individual controller evaluating and influencing an individual controlee. • For example user managers and the ISD managers might be perceived as controllers and the IS project manager as the controlee. • In outsourced IS projects: o The controllers and controlees are members of different organizations. o The controller and the controlee may not be single individuals but teams of individuals representing their respective organizations.

Answer 185

Control modes • The controller uses control mechanisms to promote desired behavior by the controlee. • These control mechanisms help implement control modes. Formal controls: o Formal controls: for example modes that rely on mechanisms that influence the controlee's behavior through performance evaluation and rewards. Two types of formal controls have been commonly considered in the literature: • Outcome control • Behavior control Outcome control: • Focus on the outputs: In outcome control, the controller focuses on the outputs (both final and interim such as specifications, design documents, test plans, programs etc.) of the project without regard to the process by which these outputs are produced. • Specifies requirements to the outputs: The controller explicitly states desired outcomes or goals (for example that the program should fulfill al the requirements in the specification) and rewards the controlee for meeting those goals (a part of the fee in the contract is paid). • Uses procedures that evaluates the outputs: Evaluates the controlee's performance with respect to the outcomes (e.g., testing by client personnel). Behavior control: • Focus on behavior: The controller seeks to influence the process by explicitly prescribing specific rules and procedures, observing the controlee's behaviors, and rewarding the controlee based on the extent to which the controlee follows stated procedures. • Specifies behaviors: Behavior control is implemented through mechanisms that specify appropriate behaviors (e.g., which development methodology to use). • Evaluate behavior: Includes various information-gathering mechanisms, such as direct observation (e.g., placing client personnel on vendor premises) and other information systems (e.g., weekly progress reports, periodic meetings, or conference calls). • 3. party control: Another behavior control mechanism, not mentioned by the paper, is to have a 3. third party organization conduct audits or assessments of the process used by the vendor and report deviations and problems to the client. Informal controls o Informal controls: for example modes that utilize social or people strategies to reduce goal differences between controller and controlee. Informal controls are: • clan control • self-control Clan control: • A clan is a group of individuals who are dependent on one another and who share a set of common goals. • Clan control is implemented through mechanisms that minimize the differences between controller's and controlee’s preferences by common values, beliefs, and philosophy within a clan. For example by identifying and reinforcing acceptable behaviors (e.g. the Agile manifesto) through shared experiences, rituals, and ceremonies. • Clan control may be difficult to achieve in outsourced systems development projects unless they are part of a long term alliance. Self-control: • Relies on the controlee engaging in behavior consistent with the best interests of the controller without formal controls. • Self-control is a function of individual objectives and standards and intrinsic motivation (e.g. a medical doctor or a systems developer performing according to professional standards). • In self-control, the controlee determines both the goals and the actions through which they should be achieved, as in self regulated teams (e.g. an agile development team). • Mechanisms supporting self-control are primarily implemented by the controlee. Such mechanisms may include the controlee identifying and establishing standards for its own behavior, or establishing a timetable for project milestones and monitoring progress against these milestones. The controller can also encourage or enable the controlee to exercise self-control.

Answer 186

• Portfolios of controls: Controlling outsourced development projects (and also internal projects) is accomplished by establishing a portfolio of controls that fits the project and the organizations: o The portfolio of control contains combinations of the four control modes. o The portfolio of control is typically described in the contract (using different concepts off course – they don’t call it a “portfolio of control”) • Control modes can be implemented through multiple control mechanisms. For example: o Behavior control may be achieved through some mechanisms that specify desired behavior (a description of a test procedure to be followed by the vendor) and others that monitor the controlee's behavior (an independent audit of the test process). • The same general mechanism can support more than one control mode: o A project plan can prescribe a specific development methodology, thereby supporting behavior control. The same project plan might also be a mechanism of outcome control by specifying deadlines for products. The same general mechanism can support more than one control mode: • A contract between the client and the vendor can facilitate o outcome control by specifying outcomes and associated rewards, o but it can also facilitate clan control if it is structured to enhance shared goals between the two organizations. • A monthly progress review meeting might provide o insights into the actions taken by system developers (behavior control) as well as o the progress they have made relative to the project schedule (outcome control).

Answer 187

When deciding which control modes to use, several factors are considered: • Task characteristics. The effects of several task characteristics on control have been examined: o behavior observability, i.e., ability to gather information about controlee behavior, outcome measurability, i.e., ability to specify and track desired outcomes, and project size. • Behavior observability: High behavior observability generally facilitates behavior control. But it requires that the controller is knowledgeable. • Outcome measurability: Has consistently been found to facilitate out come control. • When behavior observability and outcome measurability are both low: Informal controls (clan and/or self) are used. – Or you try to redesign your project in a way that increases observability and measurability. Project size: Self-control in smaller projects. More formal controls in larger projects. Project-related knowledge of the participants • Project-related knowledge of the controller and the controlee also affect the choice of control modes. o A knowledgeable controller is likely to be more confident, and more inclined to specify the exact process the controlee should follow. Thus, a controller's project related knowledge facilitates behavior control. o On the other hand, a more knowledgeable controlee would make the controller feel more confident in using outcome control or self-control Role expectations: Role expectations are individuals' perceptions about their own and others' roles. Role expectations might include norms about collegiality (which may enable clan control) or independence (which may promote self-control). When choosing the control modes you should be aware off how the various control modes impact motivation and responsibility. For example using behavior control om very experienced people might not be successful.  Maybe not surprisingly it seems like outsourcing pushes projects towards the control mechanisms typically used in planned systems development models – not the agile models.

Answer 188

* Outcome control: Dominates as expected. * Behavioral control: Extra controls added when projects got into problems. * Self-control: Minimally used. * Clan-control: Minimally used. * Only one project seemed to rely largely on clan control from the beginning: * The client and the vendor structured their contract so that each would be able to use the resulting system to showcase their respective technologies. * This changed the typical buyer-vendor relationship into a clan-like situation where both par ties strongly believed in, and strived to attain, a common goal of making the system work. This allowed the client to leave many details unspecified, confident that the vendor would adapt to later changes. --> You should understand control issues in outsourcing projects: I order to design the right governance mechanisms and controls for successful outsourcing. You can use the four control modes and the specific control mechanisms mentioned in the paper to design your approach when outsourcing development.

Answer 189

software quality has many different dimensions (e.g. McCall’s Quality Factors) * The transcendental view argues (like Persig) that quality is something that you immediately recognize, but cannot explicitly define. * The user view sees quality in terms of an end-user’s specific goals. If a product meets those goals, it exhibits quality. * The manufacturer’s view defines quality in terms of the original specification of the product. If the product conforms to the spec, it exhibits quality. * The product view suggests that quality can be tied to inherent characteristics (e.g., functions and features) of a product. * Finally, the value-based view measures quality based on how much a customer is willing to pay for a product. In reality, quality encompasses all of these views and more.

Answer 190

there are three types of cost: prevention, internal failure and external failure. The later an error is identified, the more costly it is.

Answer 191

Which basically is an independent control of software engineering activities to verify compliance with the defined software process.

Answer 192

is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user.

Answer 193

Evaluating whether "we are building the product right?"

Answer 194

Evaluating whether "we building the right product?“

Answer 195

An effective software process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it. 1. Effective Software Process 2. Useful Product 3. Adding Value Effective software process – making quality less dependent on individuals • Establish an supporting infrastructure: An effective software process establishes the infrastructure that supports any effort at building a high quality software product. o For example supporting standards, tools, specialists. • The management aspects of process create the checks and balances that help avoid project chaos—a key contributor to poor quality. o For example the right life cycle model, project planning. • Software engineering practices allow the developer to analyze the problem and design a solid solution—both critical to building high quality software. o For example sound practices for analysis, design and programming • Finally, umbrella activities o such as change management and technical reviews have as much to do with quality as any other part of software engineering practice. Useful product • Delivers the needed content: A useful product delivers the content, functions, and features that the end-user desires. • With no (important) errors: It delivers these assets in a reliable, error free way. • Satisfies explicit requirements: A useful product always satisfies those requirements that have been explicitly stated by stakeholders. • Satisfies implicit requirements: Satisfies a set of implicit requirements (e.g., ease of use) that are expected of all high quality software. Adding value • Adds value: By adding value for both the producer and user of a software product, high quality software provides benefits for the software organization and the end-user community. • The software organization: gains added value because high quality software requires less maintenance effort, fewer bug fixes, and reduced customer support. • The user community: gains added value because the application provides a useful capability in a way that expedites some business process. • The end result is: o greater software product revenue, o better profitability when an application supports a business process, and o improved availability of information that is crucial for the business.

Answer 196

* Performance Quality. Does the software deliver all content, functions, and features that are specified as part of the requirements model in a way that provides value to the end-user? * Feature quality. Does the software provide features that surprise and delight first-time end-users? * Reliability. Does the software deliver all features and capability without failure? Is it available when it is needed? Does it deliver functionality that is error free? * Conformance. Does the software conform to local and external software standards that are relevant to the application? Does it conform to de facto design and coding conventions? For example, does the user interface conform to accepted design rules for menu selection or data input? * Durability. Can the software be maintained (changed) or corrected (debugged) without the inadvertent generation of unintended side effects? Will changes cause the error rate or reliability to degrade with time? * Serviceability. Can the software be maintained (changed) or corrected (debugged) in an acceptably short time period. Can support staff acquire all information they need to make changes or correct defects? * Aesthetics. Most of us would agree that an aesthetic entity has a certain elegance, a unique flow, and an obvious “presence” that are hard to quantify but evident nonetheless. * Perception. In some situations, you have a set of prejudices that will influence your perception of quality.

Answer 197

Product Revision, Product Transition, Product Operations Measuring quality – Make it specific • General quality dimensions and factors are not adequate for assessing the quality of an application in concrete terms • Make the factors specific and operational in your projects: Project teams need to develop a set of targeted questions to assess the degree to which each application quality factor has been satisfied o For example you need to define exactly what “usability” means in your project. • Subjective measures of software quality may be viewed as little more than personal opinion • Use some kind of hard metrics: Software metrics represent indirect measures of some manifestation of quality and attempt to quantify the assessment of software quality

Answer 198

SQA dilemma • If you produce a software system that has terrible quality, you lose because no one will want to buy it. • If on the other hand you spend infinite time, extremely large effort, and huge sums of money to build the absolutely perfect piece of software, then it's going to take so long to complete and it will be so expensive to produce that you'll be out of business anyway. • Either you missed the market window, or you simply exhausted all your resources. • So people in industry try to get to that magical middle ground where the product is: o good enough not to be rejected right away, such as during evaluation, o but also not the object of so much perfectionism and so much work that it would take too long or cost too much to complete.

Answer 199

“Good enough” software Good enough software delivers high quality functions and features that end-users desire, but at the same time it delivers other more obscure or specialized functions and features that contain known bugs. Arguments against “good enough.”: • It is true that “good enough” may work in some application domains and for a few major software companies. After all, if a company has a large marketing budget and can convince enough people to buy version 1.0, it has succeeded in locking them in. • If you work for a small company be wary of this philosophy. If you deliver a “good enough” (buggy) product, you risk permanent damage to your company’s reputation. You may never get a chance to deliver version 2.0 because bad buzz may cause your sales to plummet and your company to fold. • If you work in certain application domains (e.g., real time embedded software, application software that is integrated with hardware) it can be negligent and open your company to expensive litigation.

Answer 200

``` Prevention costs include • quality planning • formal technical reviews • test equipment • Training Internal failure costs include • rework • repair • failure mode analysis External failure costs are • complaint resolution • product return and replacement • help line support • warranty work ``` - -> The relative costs to find and repair an error or defect increase dramatically as we go from prevention to internal failure to external failure costs. - -> This is the reason why we try to prevent errors, and the reason we try to find them as early as possible.

Answer 201

Typical management actions that makes software quality suffer: • Estimation decisions – irrational delivery date estimates cause teams to take short-cuts that can lead to reduced product quality o E.g. too little time to do a complex program • Scheduling decisions – failing to pay attention to task dependencies when creating the project schedule o E.g. that requirements are unclear when design starts • Risk-oriented decisions – reacting to each crisis as it arises rather than building in mechanisms to monitor risks may result in products having reduced quality o E.g. that projects “gets surprised” and has to re-schedule continuously.

Answer 202

Software quality is the result of good project management and solid engineering practice. • Project management – project plan should include techniques and activities for quality and change management • Quality control - series of inspections, reviews, and tests used to ensure conformance of a work product to its specifications • Quality assurance - consists of the auditing and reporting procedures used to provide management with data needed to make proactive decisions • Projects should integrate software quality assurance practices (SQA).

Answer 203

``` Elements of SQA: • Standards • Reviews and Audits • Testing • Error/defect collection and analysis • Change management • Education • Vendor management • Security management • Safety • Risk management ``` Creating the process infrastructure for these elements are too expensive for most individual projects and they are provided by a corporate level SQA group. This group supports the projects – but it also controls the projects.

Answer 204

SQA Group: Support Prepares an SQA plan for a project: How should SQA be performed in this project? • The plan identifies o evaluations, audits and reviews to be performed o standards that are applicable to the project o procedures for error reporting and tracking o documents to be produced by the SQA group o amount of feedback provided to the software project team Participates in the development of the project’s software process description: How should the project work? • The SQA group reviews the process description for compliance with organizational policy, internal software standards, externally imposed standards (e.g., ISO-9001), and other parts of the software project plan. SQA Group: Control Reviews software engineering activities to verify compliance with the defined software process. • identifies, documents, and tracks deviations from the process and verifies that corrections have been made. Audits designated software work products to verify compliance with those defined as part of the software process. • reviews selected work products; identifies, documents, and tracks deviations; verifies that corrections have been made • periodically reports the results of its work to the project manager. • Ensures that deviations in software work and work products are documented and handled according to a documented procedure. • Records any noncompliance and reports to senior management. • Noncompliance items are tracked until they are resolved. SQA Goals: • Requirements quality. The correctness, completeness, and consistency of the requirements model will have a strong influence on the quality of all work products that follow: So, how is the project going to assure requirements quality? • Design quality. Every element of the design model should be assessed by the software team to ensure that it exhibits high quality and that the design itself conforms to requirements: How is the project going to accomplish this? • Code quality. Source code and related work products (e.g., other descriptive information) must conform to local coding standards and exhibit characteristics that will facilitate maintainability: How is standards enforced by the project? • Quality control effectiveness. A software team should apply limited resources in a way that has the highest likelihood of achieving a high quality result: Is the approach chosen by the project efficient?  The SQA group and the projects will typically try to monitor SQA processes and quality using quantitative data

Answer 205

* Collect information about errors: Information about software errors is collected and categorized. * Identify the underlying causes: An attempt is made to trace each error its underlying cause (e.g., non-conformance to specifications, design error, violation of standards, poor communication with the customer). * Identify the vital few causes: Using the Pareto principle (80 percent of the errors can be traced to 20 percent of all possible causes), isolate the 20 percent (the vital few). * Remove the causes: Once the vital few causes have been identified, move to correct the problems that have caused the errors.

Answer 206

• Before testing: To perform effective testing, you should conduct effective technical reviews. By doing this, many errors will be eliminated before testing commences. o Reviews are conducted by reading the code checking for errors. • Testing order: o Testing begins at the component level and works "outward" toward the integration of the entire computer-based system. • Choosing the right testing techniques : o Different testing techniques are appropriate for different software engineering approaches and at different points in time. • Organizing testing: o Testing is conducted by the developer of the software and (for large projects) an independent test group. Order of testing We begin by ‘testing-in-the-small’ and move toward ‘testing-in-the-large’ • The module (component) is our initial focus • Integration of modules follows Test: Verification and validation Verification refers to the set of tasks that ensure that software correctly implements a specific function. Validation refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements. • Verification: "Are we building the product right?" • Validation: "Are we building the right product?" The less certain we are about the requirements the more time we have to use on validation. The if the users are not specific abou the requirements.

Answer 207

• Developer o Understands the system but will test ”gently” and is driven by ”delivery” • Independent tester o Must learn about the system but will attempt to break it and is driven by quality.

Answer 208

QA techniques can be categorized into two types, static and dynamic. * Static techniques: Do not involve the execution of code (e.g. reviews). This examination might be assisted by software tools, e.g., inspection of the requirements specification and technical reviews of the code. Static techniques involve examination of documentation by individuals or groups. * Dynamic techniques: Do involve the execution of code (tests). Testing and simulation are dynamic techniques. * The waterfall model uses both static and dynamic techniques. However, agile methods mostly use dynamic techniques. Agile methods with QA • Integrated QA: in agile methods, there are some practices that have both development functionality and as well as QA ability. o This means that agile methods move some QA responsibilities and work to the developers. • Fast QA feedback: In an agile methods phase a small amount of output is sent frequently to quality assurance practices and fast feedback is provided. o The development practices and QA practices cooperate with each other tightly and exchange the results quickly in order to keep up the speed of the process. Plan based: Uncertainty low Agile: Uncertainty high - System metaphor - On-site customer - Pair-programming - Refactoring - Continuous integration - Acceptance testing - Customer feedback

Answer 209

• System metaphor: is used instead of a formal architecture. It presents a simple shared story of how the system works. • There are two main purposes for the metaphor. o The first is communication. It bridges the gap between developers and users to ensure an easier time in discussion and in providing examples. o The second purpose is that the metaphor contributes to the team’s development of a software architecture. o This practice helps the team in architecture evaluation by increasing communication between team members and users

Answer 210

* On-site customers: Having an On-site customer is a general practice in most agile methods. Customers help developers refine and correct requirements – validation. * In the waterfall model, customers are typically involved in requirements definition and possibly system and software design but are not involved as much and do not contribute as much as they are expected to in an agile development. * Consequently customer involvement in agile methods is much heavier than in waterfall development. * In practice, in a waterfall development, some milestone reviews might be set up and customers will participate, but this kind of customer involvement is less intense than it is in an agile development.

Answer 211

* Pair programming means two programmers continuously working on the same code. * Pair programming can improve design quality and reduce defects. * This shoulder-to-shoulder technique serves as a continual design and code review process.

Answer 212

* Refactoring: is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. * Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. * Because each refactoring is small, the possibility of going wrong is also small and the system is also kept fully functional after each small refactoring. Refactoring can reduce the chances that a system can get seriously broken during the restructuring. * During refactoring developers reconstruct the code and this action provides code inspection functionality. This activity reduces the probability of generating errors during development e.g. because the code becomes easier to understand and less complicated.

Answer 213

* Continuous integration: a popular practice among agile methods means the team does not integrate the code once or twice. * Instead the team needs to keep the system fully integrated at all times. Integration may occur several times a day. * The key point is that continuous integration catches enough bugs to be worth the cost. Continuous integration reduces time that people spend on searching for bugs and allows detection of compatibility problems early. * This practice is an example of a dynamic QA technique. Waterfall model development integration is done much later and its frequency is much lower than in an agile method development. In the waterfall model: People might find errors quite late because the proces is not iterative.

Answer 214

* Acceptance testing: is carried out after all unit test cases have passed. This activity is a dynamic QA technique. * A Waterfall approach includes acceptance testing but the difference between agile acceptance testing and traditional acceptance testing is that acceptance testing occurs much earlier and more frequently in an agile development; it is not only done once.

Answer 215

* Early customer feedback: is one of the most valuable characteristics of agile methods. * The short release and moving quickly to a development phase enables a team to get customer feedback as early as possible, which provides very valuable information for the development team.

Answer 216

We can compare the differences between the SQA from three aspects: • Timing: many of the agile quality activities occur much earlier than they do in waterfall development, • Frequency: the frequency of these activities is much greater than in the waterfall model; most of these activities will be included in each iteration and the iterations are frequently repeated during development, • Static/dynamic: agile methods have fewer static quality assurance techniques. Compare the two approaches: • Comparing the methods and not actual practices.

Answer 217

• Static / dynamic: Agile methods move into the development phase very quickly. This makes most separate static techniques on early phase artifact unsuitable, code makes dynamic techniques useful and available very early. • Organization: Developers are more responsible for quality assurance compared with having a separate QA team and process. • Integrating QA and development: This allows more integration of QA into the development phase. • Frequent feedback: Small releases also bring customer feedback for product validation frequently and requirements verification. • The QA techniques for agile methods are based on: o Applying dynamic QA techniques as early as possible (e.g. TDD, acceptance testing) o Moving more QA responsibility on to the developer (e.g. code inspection in peer/pair programming, refactoring, collective code ownership, coding standards) o Early product validation (e.g. customer on site, acceptance testing, small release, continuous integration) --> The dynamic techniques are applied late in a waterfall development when compared with agile development.

Answer 218

* Are the quality goals defined for the project: Is it defined which quality dimensions (reliability, usability ect. ) that are specifically critical in this project? * Are the dimensions operationalized so that it can be determined whether they have been achieved or not: For example, is it defined what “usability” means in this particular project? * Are there a proper strategy for prevention and identification of errors: E.g. has the project defined how to prevent and identify usability errors. * Is there a proper strategy for prevention and identification of errors: Does the strategy prevent and identify errors as early as possible to minimize quality costs? * Validation: Is the process for finding out whether the project is developing the right system (the right requirements) convincing? * Verification: Is the process for finding out whether the project is developing the systems right (actually delivering a systems that fulfills the requirements) convincing? * Independency: Are their any independent SQA that controls whether the project actually follows the process that it has planned to follow – or whether the project is “cutting corners” not delivering the intended level of quality. * Resources and responsibilities: Are resources and responsibilities for SQA and test appropriate and well defined? Are project plans realistic? * Transparency: Is the quality status transparent – e.g. does the project know how many errors that are open? Which modules have been tested? etc. * Statistical SQA: Are quantitative data used to understand the quality of products and processes and are root causes identified end removed?

Exam Flashcards

(242 cards)