Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
1.2.3
| Question | Answer |
|---|---|
| Methodologies | arrangement of SDLC phases and how programmers move from one to another |
| SDLC | Software Development Lifecycle: Phases for developing a solution to a problem for a computer system Feasibility Requirements Analysis and design Implementation Testing Deployment Evaluation Maintenance |
| Feasibility (SDLC) | Is the problem solvable? |
| Analysis and design (SDLC) | How to do the solution |
| Implementation (SDLC) | Coding the solution |
| Testing (SDLC) | Checking the code works |
| Deployment (SDLC) | installing the code in the target environment |
| Evaluation (SDLC) | Checking with the user - is the solution complete? |
| Maintenance (SDLC) | Ensuring the code continues to function properly |
| Waterfall lifecycle (methodologies) | - Simplest, linear stages where each one must be fully completed before moving on - Each phase has a well-defined start and end point - Good for large-scale development projects that are well-understood and carry little risk. |
| Waterfall lifecycle (diagram) (methodologies) | - Some allow going back stages |
| Waterfall lifecycle (methodologies) pros and cons | Pros - Simple and easy to manage - Clear goals and responsibilities - Easy to see if running to schedule Cons - Requirement change isn’t possible - Misunderstandings are very hard to fix - No user input |
| Agile methodologies | Methodologies seeking flexible development because requirements constantly change in development Software produced iteratively (in versions); each builds on the last one Product built in a series of sprints Good if emphasis is code quality |
| Sprints (Agile methodologies) | short, time-boxed periods with focused goals to complete, usually 1-4 weeks long |
| XP (methodologies) | Extreme programming: An example of agile methodologies, but more of a framework Encourages developers to adopt practices based on: - Simplicity - Communication - Feedback - Courage - Respect Encourages regular, small, iterative software releases |
| XP core practices | Commonly accepted core practices: - Collective code ownership - Continuous integration - Code standards - Refactoring - Pair programming |
| Collective code ownership (XP) | each programmer responsible for entire system |
| Refactoring (XP) | making code faster at its task |
| Pair programming (XP) | Someone codes, another gives feedback and they switch |
| Agile methodologies and XP pros and cons | Pros - High quality, efficient code - Productive, collaborative development team Cons - Programmers must work in close collaboration - Some processes can be costly - User must have a full-time representative on team |
| Spiral model (methodologies) | -Risk-driven -A guide, allowing other methodologies to be used as well -Not fixed, depends on project and its risks start at the center, then go outwards -Suitable for high-scale, high-risk problems, where requirements are not fully understood |
| Spiral model (diagram) (methodologies) | |
| Spiral model steps (methodologies) | 1Collect requirements, evaluate restraints, propose potential solutions+determine rotation objectives 2Identify + prevent risks. If the risks are too high, cancel the project 3Implement + test last prototype as a piece of software 4Plan next iteration |
| Spiral model pros and cons (methodologies) | Pros - Good for high risk projects - Risk management at heart of model Cons - Needs pros in risk management - Poor risk management = poor project |
| RAD (methodologies) | Rapid application development - Uses prototypes - Prototypes produced successively to a final version - User gives feedback on each prototype, which is then adjusted - Iterative method - Good when initial requirements aren't fully understood |
| prototypes (RAD) | early versions of systems that lack full functionality |
| OP (Spiral model) | operational prototype |
| RAD pros and cons (methodologies) | Pros - Users prioritised - Flexible to requirements changing - End product meets needs Cons - Inconvenient and regular user contact - Not for large projects with big teams - Not very code efficient |
| Algorithm | a sequence of steps that can be followed to perform a task |
| Writing algorithms | - Flowcharts - Pseudo code - High-level language |
| Pseudo code (Writing algorithms) | text-based method of representing the steps of an algorithm without worrying about syntax, and so that non-programmers can understand it |
| Start/end (Flowcharts) | |
| Process (Flowcharts) | |
| Input/output (Flowcharts) | |
| Decision (Flowcharts) | |
| Sub-process (Flowcharts) | |
| Testing | Makes sure code works as it should |
| Black-box testing | not concerned with process, just checks if input produces expected output |
| White box testing | Ensuring algorithms in the code function as intended, efficiently |
| Alpha + Beta testing | Done after white and black box testing, when most bugs are fixed |
| Alpha testing | Internal employees play as a user would |
| Beta testing | External people use code. More a test for hardware (e.g. can server handle many players at once) |
| Test data types | - No data - Erroneous/invalid data - Normal/typical/valid data - Boundary/extreme/edge data |
| Erroneous/invalid data | should be rejected |
| Normal/typical/valid data | should be accepted |
| Boundary/extreme/edge data | correct type on either edge of accepted inputs |
| Tracing execution/dry runs | Run each line of code yourself at a time and note down each variable in a trace table |
Created by:
FlashCardFun!