Software Development Flashcards
1
Q
Agile Approach
A
flexible and collaborative way of working on software projects. Small manageable units of work are done on different aspects of development. Often features iteration.
2
Q
Iteration
A
Iteration repeatedly executes a set of instructions to solve a problem
maybe kinda wrong: when problems are encountered you go back to a prior step or checkpoint and work through the process again
3
Q
Key Features of agile approach
A
- frequent and close collaboration between developers and users
- Willingness to respond to changing user requirements
- producing working software early and getting feedback from users
- simplicity of design
- self organising teams
4
Q
Waterfall approach
A
formal and linear. Different stages are completed one after another
5
Q
Waterfall approach key features
A
-formal documentation produced at the end of each stage to inform the next
-no stage begins till the last is done
-every stage is strictly regulated
6
Q
arguments for waterfall approach
A
- problems found early in project means they are easier and less costly to fix than if they were found later
- documentation makes process easier to understand for new team members
- progress monitored clearly
7
Q
Software Development Lifecycle (SDLC)
A
1.Investigate / Analysis
2.Plan
3.Design
4.Create / Development
5.Evaluate / Testing
-Iterate back to 2.
6.Document / Maintenance
8
Q
- Invetigate
A
identify and understand user and problem. Carry out a feasibility study to whether a practical solution exists
9
Q
- Plan
A
software development plan ensures everyone understands what must happen, when and by whom
10
Q
- Design
A
Has multiple methods (Top-down / modular). Includes protoyping and making flowcharts
11
Q
Top Down Design
A
main system at top and breaks it down into smaller units. Each unit is further broken down until they are manageable. It’s an example of decomposition
12
Q
Modular design
A
Main system divided into smaller units called modules. Each represents a self contained task independent of others. ONce written can by used by various parts of system
13
Q
benefits of modular design
A
- REUSE. modules can be reused in the project and possibly others too
- SIZE modules are relatively small so problems are easier to find and fix
- easy to UNDERSTAND
- SIMPLIFIES large projects
14
Q
prototype
A
early version of model or product. tests concept or process and gets feedback from users. Most suitable for projects with high user interaction like an online system
15
Q
flowchart circle
A
start / end
16
Q
flowchart arrow
A
connector
17
Q
flowchart parallelogram
A
input / output
18
Q
flowchart rectangle
A
process
19
Q
flowchart diamond
A
decision
20
Q
benefits of flowcharting
A
-SHARED understanding on the part of team and users
-CHECKS if development process is correct
-IDENTIFY and eliminate unnecessary steps
21
Q
data table
A
lists all data to be used and how it will be stored
22
Q
variable table
A
variables that the software will need
23
Q
user-centred design
A
gives top priority to the needs of the user and ensures they can use it as easily as possible. Consider UX and UD
24
Q
UX
A
User Experience. experience of user when interfacing with a product. Includes: perception, preferences, emotion, and others. Key component is UI
25
UI and definition
User Interface.
**Point of interaction between user and computer through the use of Input and Output devices**. necessary for people to use computers. **Means by which user provides input to computer and computer conveys output to the user.**
Usually a graphical interface through which the UX takes place. Can take different forms depending on design decisions
26
UD and definition
Universal Design. Designing a product so **everyone can understand, access and use** it. Know your users to increase chance of success
27
UD principles 1-4
1.Equitable Use [useful for people with diverse abilities]
2.Flexability in Use [accomodates wide range of preferences and abilities]
3.Simple and Intuitive use [easily understandable to use]
4.Perceptible information [communicate necessary info effectively regardless of users sesnsory abilities
28
Adaptive Technology
**provide features or add feature enhancements to existing technologies** to aid their use for people with disabilities and older people. E.g. screenreaders, alternative keyboards, text-to-speech synthesizers
29
Impairment types
-Cognitive [e.g. learning]
-Visual [e.g. blindness]
-Hearing [e.g. deafness]
-Motor/dexterity [e.g. paralysis, amputation]
30
4. Create
**softare is written.** System created based on previous stages. e.g. modular or topdown design. **Unit testing**, is normally carried out and **system design may have to be modified** if issues arise.
31
5. Evaluate
Begins with **software tests** for errors or anything it shouldn't do. These are usually functional tests, system tests and acceptance tests. Then a **broader evaluation compares finished system with specified requirements.**
32
Functional Testing
testing each function of a system. Can test usability, accessibility and error conditions. **tests whether system meets its requirements** and **works as intended**
33
System Testing
Testing **entire system** to ensure it **works as intended** and **meets specification agreed with client and users.** Usually conducted by **testers (acting as proxies for end-users)**. Includes testing how system operates in abnormal circumstances.
Can be broken down to alpha and beta testing. **Encompasses both functional and non-functional testing**
34
Alpha Testing
test software **in house**. Test as many paths through the system as possible. Discover and fix problems before users test it
35
Beta testing
**early version of software sent to potential users** for testing. Users perform tests of what would take place under **real life conditions**. **Record problems and notify developers**. Each user will use software slightly differently so they find faults not discovered in-house
36
Acceptance Testing
Beta testing continues until all issued raised by users are resolved. Once this has happened, the users are asked to sign off to confirm they are accepting of this software
37
what Test data should include
Should include normal, incorrect, extreme and boundary values.
38
6. Document
Keep records of communication as well as formal project documentation. Helps ensure responsibility of decisions, clear understanding, **issues can be discussed between developers and non-technical staff**. Saves time later when problems need to be fixed.
39
Typical Roles in software development
-Business Analyst
-Project Manager
-System Analyst
-Designer
-Developer
-Tester
-User liaison and training
-Administrative support
40
Business Analyst roles
1. Involved from Investigate stage before rest of team is formed
2. Identifies users and other stakeholders and their requirements along with the business'
3. Investigates nature of the problem
4. works with system analyst to produce specification of requirements
41
Project manager roles
1. involved with feasability study and specification of requirements
2. ensure project is delivered **on time and within budget**
3. oversee project schedule, plan and set key dates
4. **resource project** with staff, equipment and finance
5. **assign tasks** related to design, implementation, testing, etc.
6. communicate with and motivate team and ongoing liaison with customer
7. monitor project progress
8. forms project team
42
System Analyst
1. Involved from investigate stage, before rest of team formed
2. once business and user requirements identified, establish hardware and software requirements
3. Investigate technical aspects of the problem
4. works with business analyst to produce specification of requirements
43
Designer roles
-Design software to meet specification
-produce design documentation
-amends design documentation if necessary
44
Developer roles
-**Writes** programs
-maintains **backup** of programs
-carries out unit **testing**
-produces software **documentation**
45
Tester roles
-produces **test plans**
-produces **test data**
-carries out **tests**
-ensures test results are **documented**
46
User liaison and training
-ensures communication between team and users is effective at all stages
-ensures users prepared to carry out testing
-prepares training
-ensures user support is in place when system is introduced to them
47
Administrative Support
-Organise meetings
-Organises documentation
-Keeps track of correspondence(e.g. emails)
48
Factors influencing teamwork
-clarity of roles
-communication quality
-regularity of project updates
-support when things go wrong
-working environment quality
-recognition of work
-opportunity to learn as project develops
-constructive feedback from others
49
benefits of teamwork
-new skills and knowledge from other members
-collaborative problem solving
-developing leadership qualities
-improve communication skills
-experience of conflict resolution
-develop working relationships with colleagues
-access to support from members with problems
-job satisfaction and confidence
50
stakeholders
-business (the client)
-user
-general public
51
Use case testing
testing each possible use case(input) to ensure that each works as intended and meets requirements
52
Why SDLC is important
1. structured approach reduces complexity
2. minimises overrun on budget/cost
3. minimises risk of missing deadlines
4. maximises use of resources
5. improves quality by increasing potential it will reach requirements while reducing risk of failure
53
Why choice of development approach is important
Enables a project to:
1. provide better estimates,
2. keep customers informed,
3. create a clear understanding of task
4. identify potential pitfalls earlier
5. allowing time to make adjustments
54
Example of user-centred design on a website
1. Consistent page layout with a navigation at the top of every page
2. Good balance of content and white space
3. Good contrast between text and background
4. Consistent font in terms of size and formatting
5. Responsive design (works on different device types and browsers)
6. Visited links change appearance
55
Wireframe
1. Sketch diagram of webpage that shows its overall structure(navigation bar, headings, images, content, footer)
2. Drawn during the design stage.
3. Do not contain real content and are relatively quick and cheap to develop and modify.
56
Wireframe vs prototype
1. Wireframe is made during design stage whereas prototype is during create
2. Prototype is software whereas wireframe are just sketches
3. Prototypes provide a mid to high fidelity visual representation of system whereas wireframe is low-fidelity of just one aspect
57
High level languages
use **english like words** such as while. Programs using these languages are **translated into machine code using a compiler or interpreter**. High level languages are **machine independent**. E.g. python and JavaScript
58
Low level languages
write code **for a specific processor architecture**. The language is **constrained by a processor’s instruction set**. E.g. assembly languages and machine code(code using 1s and 0s)
59
UD Principles 5 - 7
5.Tolerance for error [**minimizes hazards and adverse consequences** of accidental actions]
6.Low physical effort [**comfortable** with minimum fatigue]
7.size and space for approach and use [provides s and s regardless of body size posture or mobility]
60
Non-Functional Testing
**Tests how well requirements are met** e.g. performance, usability, reliability. Carried out **after functional testing**
61
Functional Testing examples
1. Unit Testing
2. Whitebox testing
3. Blackbox testing
4. Integration testing
5. Smoke testing
6. User acceptance testing
62
Non-Functional Testing examples
1. performance testing
2. stress testing
3. usability testing
4. installation testing
5. security testing
6. Compatibility testing
63
IS and definition
Information System. system that helps **organize and analyze data.** Designed to **collect, store, process, and distribute** information to **support decision-making** and other organizational tasks.
64
Benefits of Information Systems
1. Improve **efficiency** (automatic additions)
2. improve **decisions** and planning
3. cost **reductions**
65
Types of UI
1. GUI (environment has **windows, icons, menus** and is **controlled by pointing devices**)
2. CLI (Command Line Interface) (**non-graphical** mathod of interaction. **Text-only** with commands and feedback appearing in text. **Requires knowledge of commands** to use)
66
Factors contributing to UI's usability
1. Intuitive navigation
2. design consistency
3. User-centred design
4. accessibility
5. error prevention
6. familiar language to make system easier to understand
67
Regression testing
ensures that **a change to the code does not result in breaking some pieces of code that had already been tested**. It ensures that no new bugs are introduced as a result of implementing a software update.
68
Integration Testing
**multiple parts** of a software system are **tested as a group** to ensure they function correctly together
69
Smoke Testing
ensure a new build is stable enough to proceed with further testing, focusing on core functionalities and identifying major issues early on
70
Stress Testing
**determine the stability and resilience** of a system by subjecting it to intense or thorough **testing beyond normal operational capacity**, often **to a breaking point**, **to observe the results.**
71
Installation Testing
verifies that software installs, updates, and uninstalls correctly across different systems
72
Compatibility Testing
verifies that software functions correctly across different environments, including different devices and configurations, **ensuring a consistent user experience.**
73
Usability Testing
**real users interact** with a product or interface **while being observed**, to identify usability problems and areas for improvement, ultimately aiming to create a product that is easy and intuitive to use
74
Blackbox testing
tester examines the **functionality of an application** without peering into its internal structures or workings.
75
Whitebox testing
provides the tester with complete knowledge of the application being tested, including access to source code and design documents
76
System Test examples
1. Handle realistic no. of simultaneous users
2. end-to-end testing of system
3. user-friendly experience
4. complies with privacy regulations
77
How to implement Equitable Use
**Accessability features**
-adjustable font sizes
-colour contrasts
-audio feedback
78
How to implement Flexibility in Use
allow user to interact with system in different ways. e.g. touch screen / voice commands
79
How to implement Simple and Intuitive Use
straightforward and intuitive menu with **easily understandable icons and labels.** Avoid complexity to make it **user-friendly** for all experience levels
80
How to implement Perceptible Information
menu and instructions **communicated to user in various ways.** e.g. visual cues, text labels, audio instructions cater to **different sensory abilities**
81
How to implement Tolerance for Error
-confirmation dialogs
-clear feedback messages
-ability to review actions before submission
82
How to implement Low Physical Effort
-responsive regardless of pressure
-allow alternate input methods
e.g. lightly responsive touch interface
83
How to implement Size and Space for Approach and Use
-accommodate to various heights and builds to **interact comfortably**
-space for wheelchair users
