123-software-development Flashcards
1
Q
algorithm thinking
A
way of solving problems by producing algorithms.
2
Q
Algorithm
A
- Sequence of steps to solve a given problem
- May be constructed to describe the operation of a complete system or a particular part of it.
3
Q
Methodologies
A
Collection of defined techniques and sequence of tasks that provides a systematic approach to managing the software development process
4
Q
Methodology: Waterfall Model
A
- Linear, sequential, rigid, structured step-by-step approach
- SDLC phases
- Each stage needs to be finished before moving onto the next one.
- Strong emphasis on upfront requirement, gathering and planning.
5
Q
Pros of Waterfall Methodology:
A
- Well-defined start and end point with clear identifiable deliverables
Each stage is large and thorough and produces a lot of documentation – serves as a reference and aids in maintaining a clear understanding of the program’s progress - Easy to see if running schedule for time management.
- Simple and clear structure – straight-forward to plan, understand and follow.
- fewer production issues during development due to amount of time invested in user reqs, analysis and design
6
Q
Cons of Waterfall Methodology:
A
- High risk
- Very rigid structure: with little scope to go back and make improvements to the program based on client feedback
- Limited user input feedback, only at start and when product nearing competition, so might not meet needs of customer.
- No results until testing phase
- Misunderstanding requirements leads to waste of time + resources.
Inflexibility, changes are difficult to incorporate once a phase is completed – requires additional work and revisiting – delays, costs
7
Q
Scenarios for Waterfall methodology
A
- For: Large/complex SDL projects - clear plan from beginning to follow through, upfront planning and a structured approach is crucial
- Large development team – each programmer clear of their defined responsibilities at each stage
- Well-defined stable requirements that is not subject to frequent changes, predictable development process.
- Static, low risk projects – little need for user input and if client has a clear picture of what they want
- Not for: long-term projects as would take too long to get through each stage,
8
Q
Waterfall process/Software Development Lifecycle (SDLC)
A
- Requirements - project team works with clients to set
- Analysis: feasibility with what, TELOS constraints
- Design: solution + test plan design
- Development/ Implementation: code written, solution built
- Testing: checking it works as intended w/ test plan and meets reqs
- Deployment: installing system in target environment
- Maintenance: ensuring it continues to function (improvements, patches, updates)
9
Q
Spiral Model
A
- iterative incremental approach that focuses building in small cycles, identifying + mitigating risks and getting feedback from client at each step
- elements of both waterfall and prototyping methodologies
-involves series of iterations that follow a spiral path - Produces prototypes (not necessarily a program version) at the end of each cycle of spiral
10
Q
Advantages of the Spiral model:
A
- Thorough risk-analysis and mitigation - dealing with risks before any issues occur
- while improving program overtime
- client able to see the product being developed early on
- client feedback: adapts to changes in requirements, client gets involved, ensures it aligns with their expectations
- document-focused
- More flexible than waterfall: sequential but can evaluate and change more easily at end of each section
11
Q
Disadvantages of the Spiral model:
A
- Risk management is a highly specialized skill
- Lack of focus on code efficiency.
- High time and costs due to constant prototyping, hiring risk analyst and complex nature of risk analysis
-consequences if risk analyst doesn’t manage risk correctly - Project termination if risks are too high.
- iterative nature is complex to manage – esp for inexperienced teams or projects with many dependencies
12
Q
scenarios of spiral
A
- user doesn’t fully understand their requirements upfront/ are unclear and subject to frequent changes e.g startup company new software system – spiral flexibility and continuous refinement
- complex and large-scale projects - risks and uncertainties are high.
- complex: can try out different parts of the system and make improvements along the way
13
Q
Spiral methodology process
A
- planning: determine main objectives and requirements, chosen according to the biggest potential risk.
- risk analysis (identifying and solving risks + alternative options are considered, might involve building prototype of system/if risk is too high, project stopped
- development/testing and implementation –designed and Prototype built to get feedback from client then functionality will be added in each spiral.
- planning for next iteration: evaluation and risk assessment, review what has been achieved before and what needs to be added. if identified risk in spiral not identified, is listed in the next spiral.
14
Q
agile methodology
A
- developing a product over several iterations (sprints), some of the stages are repeated.
- Each iteration increments off the other, increasing the requirements it meets.
- requirements are not fully defined upfront
- Documentation is lighter and more focused on essentials.
15
Q
pros of agile
A
- Adaptable: designed to cope with changing requirements
-can take a product to market quicker - clients receive incremental updates on product
-final product has absolute certainty that it is what the client wants as theyre constantly involved - Flexibility: changes easily accommodated throughout the project.
- regular customer collaboration and feedback – customer satisfaction: faster feedback loops, regular user input, high-quality code, user can change requirements to better fit their needs
- Increased collaboration and teamwork
16
Q
cons agile methodologies
A
- requires constant interaction between the user and programmer.
- challenging to predict project timelines and outcome (uncertainties)
- lack of extensive planning and documentation (understanding and communication)
- better with experienced team
- requires higher time input from client as theyre constantly required for feedback and consultation at all stages of development process
- easily go off track and a project can last well beyond the initial idea, meaning high costs and high time input
17
Q
scenarios of agiles
A
- for emphasis on finished code quality, working software, customer collaboration, responding to change
- not for processes and tools, comprehensive documentation, contract negotiation, following a plan
- not suited for large organizations (needs coordination, communication and alignment is hard across multiple large teams)
- suited for projects with evolving requirements, uncertain or complex environments, and a need for frequent customer involvement.
- where client has a good idea of what they want and time to invest into controlling project and feeding back
18
Q
Agile methodology process
A
- User requirements and a focus of splitting the project into user stories (descriptions of the different ways the system will be used, what it will look like and what they expect it to do)
- Sprint (short time-frame during which a specific user story is completed)
- Sprint planning meeting held to prioritise and categorise the user stories and set up the work for the sprint
- product is full working deliverable that client can use instantly, deliverable is given to client
- Product is evaluated and info fed back into the next sprint meeting
- -planning meeting and sprint repeated multiple times until the full scope of the project is agreed as finished
19
Q
Extreme Programming (XP)?
A
- Produce product quickly for client to use which is then quickly incremented for improvements and additional features (regularly reviewed, iterative process)
- emphasizes coding practices, teamwork, and customer involvement.
- focus is on good quality code and is an agile paradigm
- designed to allow development to respond to changing user requirements
20
Q
pros of XP?
A
- Project is constantly refactoring in response to continuous client feedback. This can save time and money for developing. Project is at a lower risk of failure as client has guided the project with their continuous feedback.
- Improved code quality
- Faster feedback loops and increased customer satisfaction
- Increased collaboration and teamwork, productivity
- encourages regular, small, iterative software releases and promotes developer’s quality of life.
21
Q
cons of XP?
A
- The project can be too code focused and not design focused so may not be the best possible product and extreme programing produces little to no documentation.
- If the developers are split geographically it can cause issues when it is time for code review.
- Requires a high level of skill and experience from team members
22
Q
scenarios of XP
A
- Can be difficult to implement in larger organizations
XP requires a large amount of programmers who can collaborate well together, and the client needs to commit to having a representative with the team - where the client has a constantly changing set of requirements, but needs a product quickly to get to market and for the lowest possible price.
- suitable for projects where the emphasis is on the quality of the finished code.
23
Q
Process of extreme programming
A
Planning: client is in constant communication with the project team to establish the requirements . planning to plan out releases and what will be in each iteration
Designing: project team moves into building simple designs that implement the needed functionality and they develop the project metaphor (describing project and building it up)
Programming: develop the agreed items from the planning. Programmers work in pairs with one coding and other critiquing.
Testing: code is tested in units and integration testing to ensure it works together and code is reviewed for effieicny and quality. Acceptance testing where client feeds back on product in its current stage which is taken into next iteration for next release and repeats until project is completed
24
Q
sprints
A
Sprints are short time-boxed periods when a team has focused goals to complete a set amount of work
25
Paired programming
feature of XP where one person writes the program, and the other critiques it to produce high-quality code
26
What is Rapid Application Development (RAD)?
- Agile methodology that involves building a prototype and refining it over multiple iterations until it becomes the final product.
-focuses on getting a product made and quickly
- Produces iterative deliverables meaning improved versions can be released
27
pros of RAD?
- Reduced development time due to time boxing, each sub task being given a strict time limit
- Increased user involvement/issues can be identified and fixed earily/more likely to meet client requirements
- -requirements do not need to be stated at the start, more flexible
- Continuous feedback from the client
- Focus on usability of the final product
- Highly usable finished product
- Allows product to be made and put to market quickly
- - project is relevant to the client and market by the time it is released
28
cons of RAD?
- Can be time-consuming for the client
- May result in inefficient code
- Focus on usability rather than code efficiency
- Requires heavy time input from client to feedback and guide the project
- -system focuses on delivering a product that is simply ‘good enough’, not perfect
29
scenarios of RAD
Not suited for larger projects
- Suited for large projects that have short time scales where it is important to have a timely release to keep market relevance
30
Process of RAD
Analysis and design-project team looks at user requirements against what they can adapt or use from other places. Team will then produce a simple design. User requirements are initially gathered using focus groups and used to develop an incomplete version of a solution which is given to the user to trial.
Build demonstrate and refine – prototype created. repeated multiple times where project team will develop a product, demonstrate it to the client and refine the product based on the feedback received. Feefdbcvk used to refine next iteration. Any changes are made, process repeated units.
Testing and implementing- testing stage after each build-demonstrate-refine stage once client is happy final stage is implementing product – prototype becomes final product.
User feedback is then used to generate the next, improved prototype, and this continues until the prototype matches the requirements of the end-user, at which point it becomes the final product.
31
Alpha testing
- when software is nearly ready for release
- can be tested as a complete solution
- limited to internal employees, their friends, and families.
32
Beta testing
- opened up to a wider community through a public beta program
- feedback + usability issues, missed bugs, load balancing and multiple hardware compatibility
33
Black-box testing
- not concerned with how the program works
- traces input -> the expected output.
- test data cover range situations
-black box is when the internal strucure/design is not known (to the tester)
- black box rewuires limitation/no programming knwoeldge,
34
White-box testing
- testing all possible paths of execution
- checks all parts of the algorithms in the code function as intended
-white box is when the internal structure/design is knwon (to the tester)
- white box requires programming knowledge
35
Key qualities of good algorithms
Inputs must be clearly defined, must always produce a valid output for any defined input, must be able to deal with invalid inputs, must always reach a stopping condition, must be well documented for reference, and must be well commented so modifications can easily be made.
36
Flowchart
A diagram representing the sequence of steps in an algorithm.
37
Pseudocode
A text-based method of representing the sequence of steps in an algorithm. It is simplified programming code and allows us to lay down the logic of a problem without worrying about rules and syntax of a particular language.
38
Suitable test data
Once you’ve written a program, you need to be able to identify and suggest suitable data that could be used to test it in a variety of scenarios, including no data, erroneous/invalid data, normal/typical/valid data, and boundary/extreme/edge data.
39
Tracing execution
A vital skill for understanding program flow and testing the accuracy of an algorithm for logic. It involves examining a printed extract of program code and running through the program, line by line, while writing out the current state of each variable in a trace table.
40
User feedback
Gaining user feedback at regular points throughout software development is essential. It keeps a project focused, makes sure you develop the actual system the user needs, provides opportunities for discussion, and makes the user feel part of the finished solution.
41
risks
e.g not meeting time frame, costs, not meeting what client wants, resources
42
TELOS
Technical - capable with technology
Economic - short+long term financed
Legal - within law
Operational - implemented and maintained successfully
Scheduled - completed within time frame
43
Testing
Any non-trivial program needs to be tested to make sure it works as intended. Different testing strategies include black-box testing, white-box testing, alpha testing, and beta testing.
44
Extreme programming practices
Planning Game: Collaborative and iterative planning between developers and customers to prioritize and select user stories for each iteration.
Small Releases: Releasing software in small increments to gather feedback and deliver value to customers early on.
Metaphor: Using a shared metaphor or analogy to guide the development process and provide a common understanding among team members.
Simple Design: Emphasizing simplicity and avoiding unnecessary complexity in the software design to improve maintainability and flexibility.
Test-Driven Development (TDD): Writing automated tests before writing the corresponding code to ensure desired functionality and facilitate code refactoring.
Pair Programming: Developers work in pairs, with one actively coding and the other reviewing, providing immediate feedback and improving code quality.
Continuous Integration: Frequently integrating code changes from multiple team members to identify and address integration issues early on.
Refactoring: Restructuring and improving code without changing its external behavior to enhance readability, maintainability, and performance.
Collective Code Ownership: Encouraging all team members to take responsibility for the codebase, allowing anyone to modify and improve the code.
Sustainable Pace: Promoting a work environment that avoids excessive overtime and burnout, enabling consistent productivity and quality.
On-Site Customer: Having a customer representative present on-site to provide immediate feedback, answer questions, and clarify requirements.
Coding Standards: Following agreed-upon coding conventions and guidelines to ensure consistency and readability within the codebase.
Continuous Process Improvement: Regularly reflecting on the development process and seeking ways to improve efficiency, effectiveness, and quality.
