Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

analysis and design > feasibility analysis > Flashcards

feasibility analysis Flashcards

1
Q

feasibility analysis must assess three areas

A

technical -economic -organizational

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

return on investment

A

(roi)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

ROI

A

TOTAL BENIFITS -TOTAL COSTS/TOTAL COSTS

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

BEP

A

BREAK EVEN POINT

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

BEP

A

NUMBER OF YEARS OF NEGATIVE CASH FLOW+NET CASH FLOW - CUMULITIVE CASH FLOW /NET CASH FLOW

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

PV

A

CASH FLOW AMOUNT /(1+RATE OF RETURN)^N

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

NPV

A

NET PRESENT VALUE

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

NET PRESENT VALUE

A

SEGMA PVOF TOTAL BENIFITS -SEGMA PRESENT VALUE OF TOTAL COSTS

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

WHEN I KNOW THAT THE PROJECT ECONOMILY ACCSPTABLE

A

NPV IS GREATER THAN ZERO

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Development costs

A

are those tangible expense that are incurred during the creation of the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

operational costs

A

are those tangible costs that are required to operate the system such as salaries for optional staff

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

tangible benifits

A

includ revenue that the system that the system enables the organization to collect

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

stakholder

A

is person or group or organization that can affect a new system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

pmp

A

project amngement proffessional

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

sources of risk

A

technical feasibility first users and

analysts lack of familiarity with the
]
business application area 
another source of risk is lack of
01:48
familiarity with technology 
project
02:02
size
compatibility with the existing system
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

size of the project

A 
can be determined by the number of
02:03
people how long it will take to complete
02:06
the project
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

comatability with existing systems

A 
ntegration that is required does the
02:18
system that you're building have to
02:19
integrate directly with another system
18
Q

methodology

A 
a methodology is
00:30
a formalized approach to implementing
00:32
the systems development lifecycle
19
Q

Waterfall

A 
it assumes a project phase
01:06
is complete before moving on to the next
01:08
phase and the goal of waterfall
01:11
development is doing each phase
01:13
thoroughly before moving forward which
will ensure correct and high-quality
20
Q

waterfall method first the strengths

A 
are
01:56
that the system requirements are
01:57
identified long before the construction
02:00
of the system begins
02:03
requirements are frozen as project as
02:05
the project proceeds so no moving
02:07
targets are allowed
21
Q

weaknesses waterfull

A 
you must
02:12
wait a long time before there is visible
02:15
evidence of the new system and it takes
02:17
a long time from the start to finish
22
Q

waterfall development:

A

parallel development and the
02:37
v-model

23
Q

parallel development methodology looks
02:49
like

A 
you start with your planning
02:51
phase and do all of your planning before
02:53
you move on to your analysis phase once
02:55
your analysis is full and complete then
02:57
you move on to a general design of your
02:59
system at that point you break up your
03:02
project into several sub projects and
03:04
for each sub project you simultaneously
03:07
work on designing and implementing those
03:10
sub projects then at the end you bring
03:12
all of your sub projects together into
03:15
one big system implementation
24
Q

what are
03:17
the strengths
parallel methodology

A 
comparison to the traditional
03:23
waterfall it reduces the overall project
03:25
time because you are able to work on
03:27
multiple sub projects at once it also
03:29
reduces the need for rework with a
03:32
shorter time frame you have less chance
03:33
other requirements changing from
03:36
beginning to end
25
Q

the weaknesses parallel

A 
weaknesses of the
03:38
parallel methodology are first that you
03:41
have to create the sub projects which
03:42
requires some careful design decisions
03:45
up front it's hard to know exactly how
03:48
to split up your project into different
03:50
sub projects and it's also hard at the
03:52
end to integrate sub projects if they
03:54
are complex and difficult
26
Q

v model

A 
you start with planning then you
04:03
move to analysis and then design and
04:05
then implementation however in the V
04:08
model while you are doing analysis and
04:10
design you make careful plans for how
04:13
you will do testing of your system once
04:16
you get to the implementation phase in
04:18
this way you are thinking more about the
04:21
ultimate coding and testing of your
04:23
system while you are still in the
04:25
earlier phases of development so then
04:27
once you get to implementation you spend
04:29
a lot of time focusing on testing based
04:31
on the tests that you've developed
04:32
during your analysis and design phases
27
Q

the strengths of the V model

A 
the strengths of the V model are that
04:38
it's simple and straightforward again
04:40
you're just moving from planning to
04:42
analysis to design to implementation but
04:45
you also have improved quality because
04:47
you emphasize testing even while you're
04:49
still in the analysis and design phases
04:52
it also includes Quality Assurance
04:54
expertise early in the project to ensure
04:57
that you have a high quality system
28
Q

weaknesses of the v-model like the

A 
the
05:00
weaknesses of the v-model like the
05:02
traditional waterfall method are that
05:04
it's rigid and is difficult to use in a
05:06
dynamic business environment when things
05:09
are going to be changing or you might
05:11
have new requirements coming up so tit's simple and straightforward again
04:40
you're just moving from planning to
04:42
analysis to design to implementation but
04:45
you also have improved quality because
04:47
you emphasize testing
29
Q

iterative development

A

involves a series of versions developed
07:32
sequentially

30
Q

system prototyping

A 
involves
07:35
creating a prototype or model of the
07:37
system and growing it into the final
07:39
system
31
Q

throwaway metyhodology

A 
is like
07:43
system prototyping but the prototype
07:45
alternative designs are done in a more
07:47
experimental way and are discarded
07:49
before the actual system is
32
Q

he strengths
08:31
of the iterative development methodology

A 
are that users get to use a system more
08:35
quickly users can also identify
08:38
additional leads for later versions
08:40
based on their actual experience with
08:42
the first version of the system whereas
08:44
in the waterfall method users have to
08:46
use the only version that was developed
33
Q

the weaknesses of iterative development

A 
the weaknesses of iterative development
08:51
are that users are faced with using an
08:53
incomplete system for a time when
08:55
version 1 is done users will be using a
08:58
system that is not as complete as they
09:00
would like it to be and users must also
09:03
be patient and wait for the fully
09:04
functional system to be ready
34
Q

he strengths of system prototyping

A 
he strengths of system prototyping are
10:11
that users get to work with a prototype
10:13
very quickly and the feedback cycles let
10:16
users identify changes and refine real
10:18
requirements
35
Q

weaknesses methododlogy

A 
weaknesses as with every methodology
10:23
superficial analysis may cause problems
10:26
and initial design decisions may be poor
10:28
and there might be overlooked features
10:31
that are hard to have later
36
Q

throwaway prototyping development looks strenghth

A 
throwaway prototyping development looks
10:37
like it's similar to system prototyping
10:39
except that the prototype is more
10:42
experimental in nature and not usable it
36
Q

throwaway prototyping development looks strenghth

A 
throwaway prototyping development looks
10:37
like it's similar to system prototyping
10:39
except that the prototype is more
10:42
experimental in nature and not usable it
37
Q

he
11:17
weaknesses of throwaway

A 
he
11:17
weaknesses is that it might take longer
11:19
compared to system prototyping because
11:21
the actual system isn't being developed
11:23
during the iterative process so to
11:26
summarize in rapid application
11:27
development we have iterative which goes
11:30
from a full version to improve
11:33
we have the system prototyping where the
11:35
system is built one piece at a time and
11:38
we have the throwaway prototyping where
11:40
a prototype is built one piece at a time
38
Q

he final
11:46
grouping of methodologies is agile

A 
he final
11:46
grouping of methodologies is agile
11:48
development agile development refers to
11:50
carrying out the SDLC in a series of
11:54
several iterations of full mini SD LCS
11:58
over a period of time so you do planning
12:00
analysis design and implementation over
12:03
and over and over until you're satisfied
12:05
that the system is at a good place
12:07
agile development was developed to
12:09
overcome limitations of the traditional
12:11
and even the Riv methodologies so formal
12:14
modeling and documentation are
12:16
eliminated in favour of face-to-face
12:18
communication with the user and the goal
12:21
of an agile development is early
12:23
customer satisfaction the priority of
12:25
allowing changing requirements and the
12:27
priority of good communication with the
12:29
user over formal and slow documentation
39
Q

the strengths
13:00
of agile

A 
the strengths
13:00
of agile development are that you get
13:02
very fast delivery of results and it
13:04
works well in projects that have
13:06
undefined or changing requirements
40
Q

the weakness of methodology

A 
at the same time it requires
13:11
discipline and significant user
13:13
involvement there's also an initial high
13:17
learning curve involved in agile
13:19
methodologies and it works best in
13:22
smaller projects more coordination is
13:24
required because the analysts and the
13:26
designers and the users all have to come
13:28
together in every iteration in some
13:30
times of agile methodology there's a
13:32
team that is put together of analysts
13:35
design end users and they meet every two
13:37
to four weeks so users are heavily
13:38
involved which can be a pro but it can
13:41
also be a con because of the increased
13:43
coordination

analysis and design (8 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions