1.2.3 software development Flashcards

You may prefer our related Brainscape-certified flashcards:
1
Q

what does SDLC stand for

A

Software/Systems Development Life Cycle

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

what is SDLC

A
  • number of distinct phases programmers work through when developing a solution to a problem for a computer system
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

outline the stages of the software development lifecycle (F, R, A+D, I, T, D, E, M). Then explain briefly what is involved in each stage.

A

-Feasibility (is problem solvable)
- Requirements (work out what solution needs to do)
- Analysis + Design (work out how solution needs to do it
- Implementation (code solution)
- Testing (check it works)
- Deployment (install in target environment)
- Evaluation (check with user that solution is complete)
-Maintenance (ensuring it continues to function. improve by patches/updates)

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

define software development methodology

A
  • arrangement of distinct phases and how programmers move from one phase to another (forwards or backwards)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

what are the five methodologies i need to know

A
  • Waterfall
  • Rapid Application Development
  • Spiral
  • Agile
  • Extreme Programming
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

describe the waterfall lifecycle

A
  • each phase has a well-defined start and end with identifiable deliverables
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

positives of waterfall lifecycle

A
  • clear responsibilities at each stage
  • simplicity = easy to manage
  • clear deliverables
  • possible for different parts of team to be geographically remote
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

drawbacks of waterfall life cycle

A
  • if requirements change part way through project, previous stages must be repeated delaying project
  • caries risk
  • end user doesnt see project until end
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

what type of project is waterfall lifecycle suited to

A
  • large projects with static, well understood requirements and one carrying little risk
  • not suitable for complex projects
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

how has a slight evolution of waterfall model changed what it allows you to do

A
  • allows you to move back to previous phases as well as forwards (reflects fact that developers often have to rework earlier stages in light of knowledge gained as development progresses)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

what is RAD methodology

A
  • involves producing successive prototypes of software until a final version is produced and approved
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

what follows initial approval of a feasible program (RAD)

A
  • increasingly refined prototypes made with reduced functionality which are designed, coded + tested then evaluated with end user until final working solution is achieved.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

what happens if user wants prototype to be improved

A
  • further improvements needed –> starts new iteration (analysis, design, coding, testing, evaluation)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

positives of RAD

A
  • continuous feedback from client means solution likely to have good usability
  • requirements dont need to be entirely clear
  • focus groups involving user can be used to gather requirements without need for full formal requirement document upfront
  • can be confident end product meets users needs
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

drawbacks of RAD

A
  • little attention paid to program efficiency due to focus on usability
  • doesnt scale well
  • can overrun initial budgets due to being agile approach
  • regular contact with client must be maintained
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

what type of project is RAD suited to

A
  • smaller projects where there is ready access to an end user
  • projects where initial requirements not fully understood as iterative nature prevents side tracking of development
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

what is the spiral model

A
  • risk-driven development methodology
  • acts as more of a guide for development teams allowing them to adopt elements of one or more other methodologies like waterfall or RAD
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

what are the 4 stages of the spiral model (each taking up one quadrant of the spiral).

A
  • quadrant 1: Objectives and requirements determined
  • quadrant 2: risks and issues. A prototype is then developed
  • quadrant 3: this prototype tested.
  • After this the project is either complete or if the user wants more the final quadrant works on what will go into the next spiral.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

is the spiral model a fixed process that is followed in correct order (true or false)

A
  • false, spiral model order is dependent on project and its unique risks
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

positives of spiral method

A
  • prioritises risk management and can handle changes in requirements
  • suitable for high risk applications
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

drawbacks of spiral method

A
  • if risk analysis done badly, project will suffer
  • complex nature of risk analysis increases costs (risk management is a highly specialised skill)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

what projects is spiral best suited for

A
  • large, high-risk projects without tight time constraints and one where user doesnt fully understand their requirements upfront
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

what is agile devlopement

A
  • group of methodologies which focus on idea that requirements will shift and change during development - this can only be dealt with by producing software in an iterative way
  • they’re a more refined form of older concepts behind RAD
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

what idea is at the core of agile methodologies

A
  • building each iteration in sprint cycles
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

what are sprint cycles (agile)

A
  • short, time-boxed periods (no longer than 1-4 weeks) when a team has focused goals to complete a set amount of work
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

positives of agile

A
  • adapts to users needs –> final system tailored to meet end user requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

drawbacks of agile

A
  • continual collaboration needed between software developers and end users
  • hard to determine timescale and outcomes early on
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

what types of project is agile best suited to

A
  • projects where initial requirements are hard to determine from outset and in which end user can play active role in development process
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

what is extreme programming

A
  • not so much of a software methodology as it is a framework that encourages regular, small iterative software releases
  • designed to allow development to
    respond to changing user
    requirements.
  • its an example of an agile software development methodology
30
Q

what does extreme programming aim to produce?

A
  • aims to produce very high quality code and promote developers quality of life by encouraging them to adopt a set of common practices that focus on values of: Simplicity, Communication, Feedback, Courage and Respect
31
Q

what is at the core of extreme programming

A
  • at its core are the concepts of collective ownership and every team member being of equal value
32
Q
  1. how many core XP practices are there
  2. how many of these boost the overall quality of completed solutions for any project
A
  1. 12
  2. 5
33
Q

what are the names of these 5 core XP practices that boost the overall quality of completed solutions for any project

A
  • collective code ownership (everyone in charge of code)
  • continuous integration
  • code standards
  • refactoring (revisiting old code and repurposing)
  • paired programming
34
Q

what is paired programming?

A
  • idea of two programmers sitting side by side at one computer while code is written. One drives + other analyses giving instant feedback. They would switch roles often.
  • Although it sounds expensive it’s claimed this approach produces higher quality code sooner –> saving time + effort later on.
35
Q

how many of the 12 core XP practices can you name

A
  • test-driven development
  • simple design
  • refactoring
  • continuous integration
  • code standards
  • customer tests
  • whole team
  • small releases
  • planning games
  • collective code ownership
  • paired programming
  • sustainable pace
36
Q

give positives about XP

A
  • emphasises programming so quality of code likely to be high
  • core principles and processes promote respect and collaboration leading to productive development team
37
Q

give drawbacks about using XP

A
  • requires team of programmers of close collaboration (hard if team distributed geographically)
  • client must be able to fully commit to having full time representative working with development team
  • paired programming can be costly
38
Q

what project type is extreme programming suited for

A
  • when emphasis of project is on quality of finished code
39
Q

what is an algorithm

A
  • a sequence of steps designed to perform a task
40
Q

what is a flow chart

A
  • one way of representing sequence of steps in an algorithm in diagram form
41
Q

what is pseudocode

A
  • simplified, generic programming code which is an alternative, text-based method of representing the sequence of steps of an algorithm
42
Q

why do we use pseudocode

A
  • allows us to lay down logic of a problem in an “almost-like-real-code” way without worrying about rules and syntax of a particular language
43
Q

what are the flowchart symbols

A
  • oval = terminal
  • rectangle = process
  • arrow = control passing (flow) between connected shapes
  • diamond = decision
  • parallelogram = input/output operations
  • rectangle with lines on either side = subroutine
44
Q

any non-trivial program must be what (beginning with t) and why

A
  • tested to ensure it works as intended
45
Q

to fully test a solution, developers need to adopt a number of different testing strategies.

Name the 4 different testing strategies

A
  • black-box testing
  • white-box testing
  • alpha testing
  • beta testing
46
Q

what is black-box testing

A
  • not concerned with how program works but checks whether every possible input produces expected output
47
Q

fill the gaps:

with ______ - box testing, code ____________ isn’t important as long as ______ return desired ______

A
  • black
  • efficiency
  • inputs
  • outputs
48
Q

what is a drawback of black-box testing

A
  • every possible input can’t always be tested as it’s often not feasible like if there’s an infinite amount of inputs such as numbers
49
Q

if there is an infinite amount of input and you are using black-box testing, how should you test inputs give desired output

A
  • choose appropriate test data to cover a range of situations
50
Q

what is white-box testing

A
  • involves testing algorithms in code and ensuring all parts of those algorithms function as intended
  • also checks overall efficiency of code
51
Q

what does white-box testing focus on

A
  • identifying and testing all possible paths of execution through a program
52
Q

white-box testing:
what happens on each successive test run?

A
  • on each successive test run, the path of execution is noted so it can be compared with other runs
53
Q

when are alpha and beta testing carried out

A
  • when software is nearly ready for release and can be tested as complete solution
54
Q

when should you use alpha and beta testing and why?

A
  • commercial software testing such as games
  • developers want wider community audience to test product
55
Q

what are the 2 differences between alpha and beta testing

A
  • when they take place
  • who performs the testing
56
Q

alpha testing:

  1. when they take place
  2. what state is the software in
  3. who performs the testing
A
  1. occurs first
  2. very early version of finished software is tested so could contain bugs
  3. limited to internal employees and their friends and family
57
Q

beta testing:

  1. when they take place
  2. what state is the software in
  3. who performs the testing
A
  1. occurs after alpha
  2. almost-finished state
  3. testing opened up to wider community through a public beta program
58
Q

what do developers test in beta testing

A
  • developers test areas like load balancing and multiple hardware compatibility
59
Q

what is the order of the testing strategies once development of software started

A
  • start of development
  • white-box testing
  • black-box testing
  • alpha testing
  • beta testing
60
Q

when testing data, what types of data should you test (4 types)

A
  • no data (special case)
  • erroneous / invalid data
  • normal / typical / valid data
  • boundary / extreme / edge data
61
Q

what is erroneous / invalid data

A
  • data that should be rejected by program
62
Q

what is normal / typical / valid data

A
  • data that should be accepted by program, without causing errors
63
Q

what is boundary / extreme / edge data

A
  • data of correct type that is on either edge of accepted validation limits
64
Q

what is tracing execution / performing dry runs

A
  • vital skill for understanding program flow and testing accuracy of an algorithm for logic
65
Q

what does tracing execution / performing dry runs involve you doing?

what should you use in order to track programs flow

A
  • involves examining a printed extract of code and running through program one line at a time
  • trace table
66
Q

what is the purpose of a trace table

A
  • taking each line at a time and writing out the current state of each variable, noting any output program produces in order to track down logic errors in a program
67
Q

in the trace table, what should each variable have

A
  • its own column
68
Q

when should a new row be added to the trace table

A
  • if state of a variable changes
69
Q

when should you gain user feedback

A

at regular intervals throughout development of software

70
Q

why is regular feedback from user about a project being worked on so important

A
  • keeps project focused
  • ensures software being developed for client is the actual system they need
  • provides opportunities for discussion (could push project further)
  • makes user feel part of finished solution