programming methodologies

0.0(0)
studied byStudied by 1 person
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
Card Sorting

1/30

flashcard set

Earn XP

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

31 Terms

1
New cards

analysis

stakeholders stake their requirements which are used to define the problem and system requirements

2
New cards

design

the different aspects of the new system are designed (e.g. inputs, outputs, security features)

3
New cards

development

the project is split into individual and self-contained modules and allocated to teams

4
New cards

testing

the program is tested against the test plan formed in the design stage

5
New cards

alpha testing

carried out by in-house software development teams within the company. bugs are pinpointed and fixed.

6
New cards

beta testing

carried out by end-users after alpha testing has been completed. feedback from users is used to inform the next stage of development

7
New cards

white box testing

carried out by the software development team, who know the internal structure of the program, and so all possible routes throughout the program are tested

8
New cards

black box testing

the testers aren’t aware of the internal structure of the program

9
New cards

implementation

once the software has been tested and reviewed, it is installed onto the users’ systems

10
New cards

evaluation

the effectiveness of the system is evaluated against the system requirements. different criteria are considered (e.g. robustness, reliability, portability, and maintainability)

11
New cards

maintenance

any errors or improvements that could be made to the system are flagged by end users. programmers regularly send out software updates to fix bugs, security issues, or make improvements.

12
New cards

waterfall lifecycle

  • if a change needs to be made within a project, developers must revisit all levels between the current stage and where the change needs to be made

  • users have little input as they are only involved at the very beginning and end (during analysis and evaluation)

<ul><li><p>if a change needs to be made within a project, developers must revisit all levels between the current stage and where the change needs to be made</p></li></ul><ul><li><p>users have little input as they are only involved at the very beginning and end (during analysis and evaluation)</p></li></ul><p></p>
13
New cards

agile methodologies

  • a collection of methodologies

  • aim to improve the flexibility of software development + adapt to user requirement changes faster

  • problem is broken down into sections which are developed in parallel

  • different sections of software can be at different levels of development

  • a working prototype will be given early during development, and the prototype is built on in an iterative manner

  • less of a focus on documentation

  • priority given to user satisfaction

<ul><li><p>a collection of methodologies</p></li><li><p>aim to improve the flexibility of software development + adapt to user requirement changes faster</p></li><li><p>problem is broken down into sections which are developed in parallel</p></li><li><p>different sections of software can be at different levels of development</p></li><li><p>a working prototype will be given early during development, and the prototype is built on in an iterative manner</p></li><li><p>less of a focus on documentation</p></li><li><p>priority given to user satisfaction</p></li></ul><p></p>
14
New cards

extreme programming

  • agile model

  • team of a pair of programmers, and a representative end user

  • model built on system requirements that are specified by the end user

  • paired programmers produce high-quality code and work no longer than 40 hour weeks

  • hard to produce high quality documentation

15
New cards

spiral model

  • analysing system requirements > pinpointing and mitigating risks > development, testing + implementation > evaluating to inform the next iteration

  • if the project is found to be too risky at any point is it terminated

<ul><li><p>analysing system requirements &gt; pinpointing and mitigating risks &gt; development, testing + implementation &gt; evaluating to inform the next iteration</p></li></ul><ul><li><p>if the project is found to be too risky at any point is it terminated</p></li></ul><p></p>
16
New cards

rapid application development

  • iterative methodology

  • partially functioning prototypes which are constantly built-upon

  • user requirements are gathered by using focus groups

  • incomplete version of the solution is built and given to the user to trial

  • user feedback is used to generate the next, improved prototype

  • this continues until a final products made

  • common to use where requirements are initially unclear

  • constant changed can make code inefficient

17
New cards

strengths of waterfall

  • straightforward to manage

  • clearly documented

18
New cards

drawbacks of waterfall

  • lack flexibility

  • no risk analysis

  • limited user involvement

19
New cards

waterfall uses

static, low-risk projects which need little user input

20
New cards

strengths of agile

  • produces high quality code

  • flexible to changing requirements

  • regular user input

21
New cards

drawbacks of agile

  • poor documentation

  • requires consistent interaction between user and programmer

22
New cards

uses of agile

small to medium projects with unclear initial requirements

23
New cards

strengths of extreme programming

  • produces high quality code

  • constant user involvement means high usability

24
New cards

drawbacks of extreme

  • high cost of two people working on one project

  • teamwork is essential

  • end-user mat not be able to be present

25
New cards

uses of extreme

small to medium projects with unclear initial requirements requiring excellent usability

26
New cards

strengths of spiral

  • thorough risk analysis and mitigation

  • caters to changing user needs

  • produces prototypes throughout

27
New cards

drawbacks of spiral

  • expensive to hire risk assessors

  • lack of focus on code efficiency

  • high costs due to constant prototyping

28
New cards

uses of spiral

large, risk-intensive projects with a high budget

29
New cards

strengths of RAD

  • caters to changing user requirements

  • highly usable finished product

  • focus on core features, reducing development time

30
New cards

drawbacks of RAD

  • poorer quality documentation

  • fact pace may reduce code quality

31
New cards

uses of RAD

small to medium, low budget projects with short time frames