Cbap, Iiba 2.0 - Najważniejsze

Front 1

Workflow of Business analysis

Back 1

Front 2

Czego dotyczy obszar Underlying Competencies

Back 2

This area provides a description of the behaviors, characteristics, knowledge and personal qualities that support the practise of business analysis.

Front 3

Business Analysis Planning and Monitoring

Czym się różni plan-driven approach od change-driven

Back 3

Plan-driven to metoda kaskadowa prowadzenia projektów, gdzie wiemy co chcemy osiągnąć od samego początku a ryzyko błędu musi być minimalne,

Change-driven - to metoda gdy mniej więcej wiemy gdzie chcemy dojść, ale idziemy małymi kroczkami i korygujemy plan w razie potrzeby (metody Agile).

Front 4

Horizontal prototyping

Back 4

Horizontal prototype models a shallow and possibly wide view of the system's functionality

Front 5

Vertical prototyping

Back 5

Vertical prototype models a deep and usually narrow slice of the entire system's functionallity.

Front 6

Throwaway prototyping

Back 6

Throw away prototyping seeks to quickly uncover and clarify interface requirements

Front 7

Evolutionary prototyping

Back 7

Evolutionary or Functional prototype extends initial interface requirements into a fully functioning system and requires a specialized prototyping tool or language.

Front 8

Feasibility study

Back 8

studium wykonalności

Front 9

Inherit

Back 9

dziedziczyć

Front 10

Justify

Back 10

usprawiedliwiać

Front 11

Quantitative

Back 11

ilościowy

Front 12

Elicitation

Back 12

aktywizacja, wydobycie, ujawnienie

Front 13

Validation

Back 13

Uprawomocnienie, ratyfikacja, akceptacja

Front 14

Ambiguity

Back 14

dwuznaczność, niejasność

Front 15

Reimburse

Back 15

Zwracać (np. koszty)

Front 16

Metadata modelling

Back 16

?

Front 17

Merge

Back 17

Łączyć

Front 18

Joint

Back 18

Połączenie

Front 19

Branch

Back 19

Odgałęzienie

Front 20

Solution Assessment

Back 20

Ocena rozwiązania

Front 21

Facilitator

Back 21

Moderator

Front 22

Rollout

Back 22

Wdrożenie

Front 23

Stakeholder

Back 23

Interesariusz

Front 24

Articulate

Back 24

artykułować (wyrażać, wypowiadać)

Front 25

Evolve

Back 25

Rozwijać, pochodzić z, ewaluować

Front 26

Facilitate

Back 26

Ułatwić, udogodnić

Front 27

Asset

Back 27

Kapitał

Front 28

Merit

Back 28

Zasługa

Front 29

Concise

Back 29

Zwięzły (nie długi)

Front 30

Effort

Back 30

Wysiłek, koszt, praca

Front 31

Tenure

Back 31

Okres (np. posiadania nieruchomości, pracy w jakiejś firmie), kadencja,

Front 32

Benchmarking

Back 32

Benchmark studies are performed to compare the strengths and weaknesses of an organization against its peers and competitors.

Front 33

Business Rules Analysis

Back 33

To define the rules, that govern decisions in an organization and that define, constrain or enable organizational operations.

Front 34

Data Flow Diagram

Back 34

To show how information is input, processed, stored and output from a system.

Front 35

Data modelling

Back 35

The purpose of data model is to describe the concepts relevant to a domain, the relationships between those concepts and information associated with them

Front 36

Relacje w data modelling

Back 36

Front 37

Decision analysis

Back 37

To support decision making when dealing with complex, difficult or uncertain situations. Common valuation techinques include:

1. Discounted Cash Flow - future value on a specific data,

2. Net present value - future view of costs and benefits converted to todays value,

3. Internal rate of return - interest rate (or discount) when the net present value is equal to zero,

4. Average rate of return - estimate of rate of return on an investment,

5. Pay Back Period - the amount of time it takes for an investment to pay for itself,

6. Cost-benefit analysis - quantification of costs and benefits for a proposed new solution.

Front 38

Document analysis

Back 38

Is a means to elicit requirements by studing avaliable documentation on existing and comparable solutions and identifing relevant information.

Front 39

Estimation

Back 39

Estimation techniques forecast the cost and effort involved in pursuing a curse of action.

Front 40

Focus Groups

Back 40

A focus group is a means to elicit ideas and attlitudes about a specific product, service or opportunity in an interactive group environment. The participants share their impressions, preferences and needs, guided by a moderator.

Front 41

Functional decomposition

Back 41

WBS

Front 42

Interface analysis

Back 42

To identify interfaces between solutions and/or solution components and define requirements that describe how they will interact.

Front 43

Organization modelling

Back 43

Is used to describe roles, responsibilities and reporting structures, that exist within an organization and to alignthose structures with the organization goals.

Front 44

Root cause analysis

Back 44

The purpose is to determine the underlying source of a problem.

Front 45

Scope modelling

Back 45

Scope models are used to describe the scope of analysis and the scope of solution.

Front 46

Structured walkthrough

Back 46

Are performed to communicate, verify and validate requirements.

Front 47

User stories

Back 47

Are a brief description of functionallity that users need from a solution to meet a business objective.

Front 48

Vendor assessment

Back 48

To assess the ability of a potential vendor to meet the commitments regarding a product or service.

Front 49

Czego dotyczy obszar Business Analysis Planning and Monitoring

Back 49

The Business Analysis Planning and Monitoring Knowledge Area defines the tasks associated with the planning and monitoring of business analysis activities, including:

* identifying stakeholders
* defining roles and responsibilities of stakeholders in the business analysis effort
* developing estimates for business analysis tasks
* planning how the business analyst will communicate with stakeholders
* planning how requirements will be approached, traced, and prioritized
* determining the deliverables that the business analyst will produce
* defining and determining business analysis processes
* determining the metrics that will be used for monitoring business analysis work

Front 50

Business Analysis Planning and Monitoring
ITO

Back 50

Hint 50

przyjęcie

Front 51

Plan Business Analysis Approach

Back 51

This task describes how to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted regarding and informed of the approach, and the rationale for using it.

Front 52

Conduct Stakeholder Analysis

Back 52

This task covers the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables.

Front 53

Plan Business Analysis Activities

Back 53

Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables.

Front 54

Plan Business Analysis Communication

Back 54

A business analysis communications plan describes the proposed structure and schedule for communications regarding business analysis activities. Record and organize the activities to provide a basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications.

Front 55

Plan Requirements Management Process

Back 55

Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope.

Front 56

Manage Business Analysis Performance

Back 56

To manage the performance of business analysis activities to ensure that they are executed as effectively as possible.

Front 57

Czego dotyczy obszar Elicitation

Back 57

Elicitation (wydobywanie wymagań),

The definition of elicitation is:

1. To draw forth or bring out (something latent or potential) => wydobyć, wyciągnąć coś ważnego,

2. To call forth or draw out (as information or a response) => wydobyć informację lub odpowiedź,

Front 58

Elicitation
ITO

Back 58

Hint 58

logiczne jak z warsztatami

Front 59

Prepare for Elicitation

Back 59

Ensure all needed resources are organized and scheduled for conducting the elicitation activities.

Front 60

Conduct Elicitation Activity

Back 60

Meet with stakeholder(s) to elicit information regarding their needs.

Front 61

Document Elicitation Results

Back 61

Record the information provided by stakeholders for use in analysis.

Front 62

Confirm Elicitation Results

Back 62

Validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder’s needs.

Front 63

Czego dotyczy obszar Requirements Management & Communication

Back 63

This area desribes the activities and considerations for managing and expressing requirements to a broad and diverse audience.

These tasks are performed to ensure, that all stakeholders have a shared understanding of the nature of the solution and to ensure, that those stakeholders with approvel authority are in agreement as to the requirements that the solution shall met.

Front 64

Requirements Management and Communication
ITO

Back 64

tu jest błąd powinno być create requirements package

Hint 64

scope

Front 65

Manage Solution Scope and Requirements

Back 65

Obtain and maintain consensus among key stakeholders regarding the overall solution scope and the requirements that will be implemented.

Front 66

Manage Requirements Traceability

Back 66

Create and maintain relationships between business objectives, requirements, other team deliverables, and solution components to support business analysis or other activities.

Front 67

Maintain Requirements for Re-use

Back 67

To manage knowledge of requirements following their implementation.

Front 68

Prepare Requirements Package

Back 68

To select and structure a set of requirements in an appropriate fashion to ensure that the requirements are effectively communicated to, understood by, and usable by a stakeholder group or groups.

Front 69

Communicate Requirements

Back 69

Communicating requirements is essential for bringing stakeholders to a common understanding of requirements.

Front 70

Czego dotyczy obszar Enterprise Analysis

Back 70

This area describes the business analysis activities necessary to identyfy a business need, problem or opportunity, define the nature of solution, that meets that need and justify the investment necessary to deliver that solution.

Enterprise analysis output provide input for requirements analysis.

This is commonly starting point of a project.

Front 71

Enterprise Analysis
ITO

Back 71

Hint 71

Dziura w drodze

Front 72

Define Business Need

Back 72

Identify and define why a change to organizational systems or capabilities is required.

Front 73

Assess Capability Gaps

Back 73

To identify new capabilities required by the enterprise to meet the business need.

Front 74

Determine Solution Approach

Back 74

To determine the most viable solution approach to meet the business need in enough detail to allow for definition of solution scope and prepare the business case.

Front 75

Define Solution Scope

Back 75

To define which new capabilities a project or iteration will deliver.

Front 76

Define Business Case

Back 76

To determine if an organization can justify the investment required to deliver a proposed solution.

Front 77

Czego dotyczy obszar Requirements analysis

Back 77

This area describes the tasks and techniques used by a business analyst to analyze stated requirements in order to define the required capabilities of a potential solution that will fulfill stakeholder needs.

RA may be performed to develop models of the current state of an organization.

Front 78

Requirements Analysis
ITO

Back 78

Hint 78

priorytety i potem jak w Asseco

Front 79

Prioritize Requirements

Back 79

Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements.

Front 80

Organize Requirements

Back 80

The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives.

Front 81

Specify and Model Requirements

Back 81

To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models.

Front 82

Define Assumptions and Constraints

Back 82

Identify factors other than requirements that may affect which solutions are viable.

Front 83

Verify Requirements

Back 83

Requirements verification ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work.

Front 84

Validate Requirements

Back 84

The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need.

Front 85

Czego dotyczy obszar Solution Assesment nad Validation

Back 85

This area describes the tasks that are performed in order to ensure that solutions meet the business need and to facilitate their successful implementation.

Front 86

Solution Assessment and Validation
ITO

Back 86

Hint 86

zaczynamy tak jak nazwa obszaru

Front 87

Assess Proposed Solution

Back 87

To assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements.

Front 88

Allocate Requirements

Back 88

Allocate stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team.

Front 89

Assess Organizational Readiness

Back 89

Assess whether the organization is ready to make effective use of a new solution.

Front 90

Define Transition Requirements

Back 90

To define requirements for capabilities needed to transition from an existing solution to a new solution.

Front 91

Validate Solution

Back 91

Validate that a solution meets the business need and determine the most appropriate response to identified defects.

Front 92

Evaluate Solution Performance

Back 92

Evaluate functioning solutions to understand the value they deliver and identify opportunities for improvement.

Front 93

Czym się zajmuje Underlying Competencies

Back 93

The Underlying Competencies Knowledge Area provides a description of the behaviors, characteristics, knowledge and personal qualities that support the practice of business analysis.

The underlying competencies are, of course, not unique to the business analysis profession. They are described here to ensure readers are aware of the range of fundamental skills required, and provide a basis for them to investigate further into the skills and knowledge that will enable them to be accomplished and adaptable business analysts.

Front 94

Analytical Thinking and Problem Solving

Back 94

Business analysts must be effective in generating new ideas for approaches to problem solving and in generating alternative solutions.

Front 95

Behavioral Characteristics

Back 95

A business analyst must be able to behave ethically in order to earn the trust and respect of stakeholders, and be able to recognize when a proposed solution or requirement may present ethical difficulties.

Front 96

Business Knowledge

Back 96

Business analysts require an understanding of fundamental business principles and best practices, in order to ensure that they are incorporated into and supported by solutions.

Front 97

Communication Skills

Back 97

Oral communication skills enable business analysts to effectively express ideas in ways that are appropriate to the target audience.

Front 98

Interaction Skills

Back 98

Business analysts facilitate interactions between stakeholders in order to help them resolve disagreements regarding the priority and nature of requirements.

Front 99

Software Applications

Back 99

Business analysts use office productivity applications to document and track requirements.

Front 100

Czym zajmuje się Techniques

Back 100

The Techniques Chapter provides a high-level overview of the techniques referenced in the Knowledge Areas of the BABOK® Guide. Techniques alter the way a business analysis task is performed or describe a specific form the output of a task may take.

Front 101

Acceptance and Evaluation Criteria Definition

Back 101

To define the requirements that must be met in order for a solution to be considered acceptable to key stakeholders.

Front 102

Benchmarking

Back 102

Benchmark studies are performed to compare the strengths and weaknesses of an organization against its peers and competitors.

Front 103

Brainstorming

Back 103

Brainstorming is an excellent way to foster creative thinking about a problem. The aim of brainstorming is to produce numerous new ideas, and to derive from them themes for further analysis.

Front 104

Business Rules Analysis

Back 104

To define the rules that govern decisions in an organization and that define, constrain, or enable organizational operations.

Front 105

Data Dictionary and Glossary

Back 105

A data dictionary or glossary defines key terms and data relevant to a business domain.

Front 106

Data Flow Diagrams

Back 106

To show how information is input, processed, stored, and output from a system.

Front 107

Data Modeling

Back 107

The purpose of a data model is to describe the concepts relevant to a domain, the relationships between those concepts, and information associated with them.

Front 108

Decision Analysis

Back 108

To support decision-making when dealing with complex, difficult, or uncertain situations.

Front 109

Decision tree

Back 109

A decision tree is a method of assessing the preferred outcome where multiple sources of uncertainty may exist.

Front 110

Document Analysis

Back 110

Document analysis is a means to elicit requirements by studying available documentation on existing and comparable solutions and identifying relevant information.

Front 111

Estimation

Back 111

Estimating techniques forecast the cost and effort involved in pursuing a course of action.

Front 112

Analogous Estimation

Back 112

Use of a similar project as the basis for developing estimates for the current project. It is used when little is known. Analogous estimating is often used to develop a rough order of magnitude (ROM) estimate, and is also known as "top-down" estimating. This is usually done at the beginning of the project or project phase and more detailed estimates follow as more is known.

Front 113

Parametric Estimation

Back 113

The use of parameters, multiplied by the number of hours. For parametric estimating to be usable, enough history has to be available to be used as a basis of comparison. With this type of estimating, the business analyst has done enough work to determine which parameters can be used and how many there will be. For example, the business analyst has determined that there will be ten use cases developed. The business analyst also has history that indicates for each use case the total hours that will be spent, in this case will be 20 hours. Using this technique, the business analyst can multiply 10 x 20 to get a total, or 200 hours.

A number of well-defined methods for parametric estimation exist for software development, such as COCOMO II, Function Point Counting, Use Case Points, and Story Points.

Front 114

Bottom-up Estimation

Back 114

Using this technique the business analyst has collected the deliverables, activities, tasks, and estimates from all the involved stakeholders and rolls them up to get a total for all the activities and tasks. Because it is normally easier to estimate smaller items than larger items, bottom-up estimating can produce the most accurate and defensible estimates.

Front 115

Rolling Wave

Back 115

This is a technique involving refinement of estimates. Estimate the details for activities in the current iteration or increment and provide an analogous estimate for the entire scope of work. As the end of the iteration approaches, estimates for the next iteration can be made and the initial estimate for all activities is refined.

Front 116

Three-point Estimation

Back 116

Uses scenarios for:
* The most optimistic estimate, or best-case scenario
* The most pessimistic estimate, or worst-case scenario
* The most likely estimate

Note that the most likely estimate is not an average of best and worst case scenarios. It requires in depth knowledge of the situation. Under the right circumstances, the best-case scenario may also be the most likely.

Front 117

Historic Analysis

Back 117

Uses history as a basis for estimating. It is similar to analogous estimation, but is used not only for the top-down estimate, but for the detailed tasks as well. Historic estimates require prior project records, whether maintained formally in a project repository or informally in individual project documentation.

Front 118

Expert Judgment

Back 118

Estimating relies on the expertise of those who have performed the work in the past. These experts can be internal or external to the project team or to the organization.

Front 119

Delphi Estimation

Back 119

This technique uses a combination of expert judgment and history. There are several variations on this process, but they all include individual estimates, sharing the estimates with experts, and having several rounds until consensus is reached. An average of the three estimates is used. Sometimes the average is weighted by taking the optimistic, pessimistic and four times the most likely, dividing by six to get the average.

Front 120

Focus Groups

Back 120

A focus group is a means to elicit ideas and attitudes about a specific product, service or opportunity in an interactive group environment. The participants share their impressions, preferences and needs, guided by a moderator.

Front 121

Functional Decomposition

Back 121

To decompose processes, functional areas, or deliverables into their component parts and allow each part to be analyzed independently.

Front 122

Interface Analysis

Back 122

To identify interfaces between solutions and/or solution components and define requirements that describe how they will interact.

Front 123

Interviews

Back 123

An interview is a systematic approach designed to elicit information from a person or group of people in an informal or formal setting by talking to an interviewee, asking relevant questions and documenting the responses.

Front 124

Lessons Learned Process

Back 124

The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases.

Front 125

Metrics and Key Performance Indicators

Back 125

The purpose of metrics and key performance indicators are to measure the performance of solutions, solution components, and other matters of interest to stakeholders.

Front 126

Non-functional Requirements Analysis

Back 126

The purpose of non-functional requirements is to describe the required qualities of a system, such as its usability and performance characteristics. These supplement the documentation of functional requirements, which describe the behavior of the system.

Front 127

Observation

Back 127

Observation is a means of eliciting requirements by conducting an assessment of the stakeholder's work environment. This technique is appropriate when documenting details about current processes or if the project is intended to enhance or change a current process.

Front 128

Organization Modeling

Back 128

Organization Modeling is used to describe the roles, responsibilities and reporting structures that exist within an organization and to align those structures with the organization's goals.

Front 129

Problem Tracking

Back 129

Problem tracking provides an organized approach to tracking, management, and resolution of defects, issues, problems, and risks throughout business analysis activities. Management of issues is important so that they can be resolved in a timely manner to ensure success.

Front 130

Process Modeling

Back 130

To understand how work that involves multiple roles and departments is performed within an organization.

Front 131

Flowchart

Back 131

Front 132

Activity diagram

Back 132

Front 133

Prototyping

Back 133

Prototyping details user interface requirements and integrates them with other requirements such as use cases, scenarios, data and business rules. Stakeholders often find prototyping to be a concrete means of identifying, describing and validating their interface needs.

Front 134

Requirements Workshops

Back 134

A requirements workshop is a structured way to capture requirements. A workshop may be used to scope, discover, define, prioritize and reach closure on requirements for the target system.

Well-run workshops are considered one of the most effective ways to deliver high quality requirements quickly. They can promote trust, mutual understanding, and strong communications among the project stakeholders and project team and produce deliverables that structure and guide future analysis.

Front 135

Etapy Requirements Workshop

Back 135

1 Prepare for the Requirements Workshop

2 Conduct the Requirements Workshop

3 Post Requirements Workshop Wrap-Up

Front 136

Risk Analysis

Back 136

To identify and manage areas of uncertainty that can impact an initiative, solution, or organization.

Front 137

Root Cause Analysis

Back 137

The purpose of root cause analysis is to determine the underlying source of a problem.

Front 138

The Fishbone Diagram

Back 138

Front 139

Scenarios and Use Cases

Back 139

Scenarios and use cases are written to describe how an actor interacts with a solution to accomplish one or more of that actor's goals, or to respond to an event.

Front 140

Scope Modeling

Back 140

Scope models are used to describe the scope of analysis or the scope of a solution.

Front 141

Scope Modeling

Context Diagram

Back 141

A context diagram is a top-level data flow diagram. It uses a single data process to describe the scope and shows the external entities and data stores that provide data to and receive data from the system. Context diagrams are still used on many projects that do not otherwise use data flow diagrams.

Front 142

Scope Modeling

Context Diagram (Gane-Sarson Notation)

Back 142

Front 143

Scope Modeling

Context Diagram (Yourdon Notation)

Back 143

Front 144

Scope Modeling

Events

Back 144

External events happen in an External Entity. They are external to the boundaries of the system being studied (a customer makes a request, a partner sends a message).

Temporal events are driven by time (e.g. monthly or annual reports). The time is determined by time-related business rules (e.g. produce this report at the end of every day, or prepare a tax return at the end of each tax period).

When events have been identified, the next question asked is "What processes are required to provide a complete response to this event?" The answers to this question identify the processes of the system. These processes may then be documented, and further analyzed, using an appropriate process modeling technique.

Front 145

Scope Modeling

Features

Back 145

A feature is a service that the solution provides to fulfill one or more stakeholder needs. Features are high-level abstractions of the solution that must later be expanded into fully described functional and supplemental requirements. They allow for early priority and scope management and for validating the stakeholders' view of the solution.

Front 146

Scope Modeling

Use Case Diagram

Back 146

A use case diagram visually depicts the use cases supported by a system, the actors who trigger those use cases, and relationships between the use cases.

Front 147

Scope Modeling

Business Process

Back 147

A high-level business process model may also be used as a scope model.

Front 148

Sequence Diagrams

Back 148

Sequence diagrams are used to model the logic of usage scenarios, by showing the information passed between objects in the system through the execution of the scenario.

Front 149

State Diagrams

Back 149

A state diagram shows how the behavior of a concept, entity or object changes in response to events.

Front 150

State Machine Diagram

Back 150

Front 151

Class diagram

Back 151

1. Top compartment should indicate name of class.

2. Second compartment (optional) lists attributes of the class, sucha as description of possible states, data or functionallity required to support the class.

3. Third department describe operations which class can do, e.g. save, print, report.

Front 152

Entity relationship diagram

Back 152

An entity relationship diagram, also called entity relationship model, is a graphical representation of entities and their relationships to each other, typically used in computing in regard to the organization of data within databases or information systems.

Front 153

Structured Walkthrough

Back 153

Structured walkthroughs are performed to communicate, verify and validate requirements.

Front 154

Survey or Questionnaire

Back 154

A survey is a means of eliciting information from many people, sometimes anonymously, in a relatively short period of time. A survey can collect information about customers, products, work practices and attitudes. A survey may also be referred to as a questionnaire.

Front 155

SWOT Analysis

Back 155

A SWOT analysis is a valuable tool to quickly analyze various aspects of the current state of the business process undergoing change.

Front 156

User Stories

Back 156

User Stories are a brief description of functionality that users need from a solution to meet a business objective.

Front 157

Vendor Assessment

Back 157

To assess the ability of a potential vendor to meet commitments regarding a product or service.

Front 158

Comprehensive

Back 158

wszechstronny

Front 159

Creep

Back 159

Pełzanie

np. scope creep - pełzający zakres

Front 160

Ascertain

Back 160

upewnić się, przekonać się, stwierdzić

Front 161

Viable means

Back 161

Realne środki

Front 162

Capabilities

Back 162

Możliwości

Front 163

Entity

Back 163

Jednostka

Front 164

Compartment

Back 164

Przedział, przegroda

Front 165

scaffolding

Back 165

rusztowanie

Front 166

Cardinality

Back 166

Liczność

Front 167

unambiguous

Back 167

niedwuznaczny (jednoznaczny)

Front 168

Accuratelly

Back 168

dokładnie

Front 169

endeavor

Back 169

dążenie, usiłowanie, staranie

Front 170

envisioning

Back 170

przewidywanie

Front 171

precede

Back 171

poprzedzać, mieć pierwszeństwo

Front 172

quantifiable

Back 172

wymierne

Front 173

embark

Back 173

rozpocząć

Front 174

thorough

Back 174

dokładny, gruntowny, kompletny

Front 175

auctionable

Back 175

możliwy do sprzedaina

Front 176

CRUD Matrix

Back 176

In computer programming, create, read, update and delete (CRUD) are the four basic functions of persistent storage.

Front 177

justification

Back 177

usprawiedliwienie

Front 178

Pareto Diagram

Back 178

Front 179

COTS

Back 179

In the United States, commercial off-the-shelf (COTS) is a Federal Acquisition Regulation (FAR) term for commercial items, including services, available in the commercial marketplace that can be bought and used under government contract. For example, consumer goods and construction materials may qualify as COTS but bulk cargo does not. Services associated with the commercial items may also qualify as COTS, including (but not limited to) installation services, training services, and cloud services.

Front 180

contractual

Back 180

umowny

Front 181

adamant

Back 181

nieugięty

Front 182

Force-field analysis

Back 182

Force-field analysis is an influential development in the field of social science. It provides a framework for looking at the factors (forces) that influence a situation, originally social situations. It looks at forces that are either driving movement toward a goal (helping forces) or blocking movement toward a goal (hindering forces).

Front 183

Crawford Slip Method

Back 183

The Crawford Slip Method is a simple yet effective type of brainstorming that gives the opinions of all team members equal weight, however quiet they are. the method simply involves collating input from people on slips of paper (nowadays often on sticky notes)

Front 184

project charter

Back 184

karta projektu

Front 185

binding

Back 185

wiążący

Front 186

scrutiny

Back 186

badanie, przestudiowanie, lustracja

Critical observation or examination.

Front 187

assignment

Back 187

przyporządkowanie

Front 188

POLDAT model

Back 188

One of the models which can be used to compare and contrast similar processes in an organization, especially if these are undertaken at different locations, is the POLDAT approach first used by the American Computer Services Corporation, and is used to record:

* The Processes undertaken.
* The Organization setting.
* The Location of where the processes are undertaken.
* The Data that is managed.
* The Application of the Data, and finally.
* The Technology used in undertaking the task.

Front 189

Mitigation

Back 189

łagodzenie, osłabienie

Front 190

reluctant

Back 190

niechętny, ociągający się

Front 191

incurred

Back 191

poniesiony (np. wydatek)

Front 192

Multivoting

Back 192

Multivoting narrows a large list of possibilities to a smaller list of the top priorities or to a final selection. Multivoting is preferable to straight voting because it allows an item that is favored by all, but not the top choice of any, to rise to the top.

Front 193

Business Domain Model

Back 193

The Business Domain Model provides the business vocabulary - terms and facts - on which Business Rules can be modeled.

Front 194

Business policy

Back 194

Polityka firmy

Front 195

Forward traceability

Back 195

Forward traceability means mapping requirements with test cases (allocation)

Front 196

Backward traceability

Back 196

Backward traceability means mapping testcases with requirements (derivation).

Front 197

allocation

Back 197

Przydział

Front 198

derivation

Back 198

Pochodzenie

Front 199

Stakeholder profile

Back 199

A stakeholder profile describes in detail the
characteristics of a stakeholder group or organisation. It
is a useful reference for staff to draw on when planning
for a program or project.

Front 200

All In

Back 200

Timeboxing technique

All In: Begin with all the eligible requirements with assigned Duration or Cost. Remove the requirements in order to meet the calendar dates or budget limit.

Front 201

All out

Back 201

Timeboxing technique

All Out: Begin with adding the requirement(s) with assigned duration or cost to the calendar or budget. Stop when the calendar dates are met or budget limit is reached.