123-software-development

Question 1

algorithm thinking

Answer 1

way of solving problems by producing algorithms.

Question 2

Algorithm

Answer 2

• 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.

Question 3

Methodologies

Answer 3

Collection of defined techniques and sequence of tasks that provides a systematic approach to managing the software development process

Question 4

Methodology: Waterfall Model

Answer 4

• 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.

Question 5

Pros of Waterfall Methodology:

Answer 5

• 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

Question 6

Cons of Waterfall Methodology:

Answer 6

• 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

Question 7

Scenarios for Waterfall methodology

Answer 7

• 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,

Question 8

Waterfall process/Software Development Lifecycle (SDLC)

Answer 8

• • 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)

Question 9

Spiral Model

Answer 9

• 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

Question 10

Advantages of the Spiral model:

Answer 10

• 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

Question 11

Disadvantages of the Spiral model:

Answer 11

• 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

Question 12

scenarios of spiral

Answer 12

• 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

Question 13

Spiral methodology process

Answer 13

• 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.

Question 14

agile methodology

Answer 14

• 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.

Question 15

pros of agile

Answer 15

• 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

Question 16

cons agile methodologies

Answer 16

• 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

Question 17

scenarios of agiles

Answer 17

• 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

Question 18

Agile methodology process

Answer 18

• 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

Question 19

Extreme Programming (XP)?

Answer 19

• 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

Question 20

pros of XP?

Answer 20

• 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.

Question 21

cons of XP?

Answer 21

• 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

Question 22

scenarios of XP

Answer 22

• 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.

Question 23

Process of extreme programming

Answer 23

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

Question 24

sprints

Answer 24

Sprints are short time-boxed periods when a team has focused goals to complete a set amount of work

Question 25

Paired programming

Answer 25

feature of XP where one person writes the program, and the other critiques it to produce high-quality code

Question 26

What is Rapid Application Development (RAD)?

Answer 26

- 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

Question 27

pros of RAD?

Answer 27

- 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

Question 28

cons of RAD?

Answer 28

- 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

Question 29

scenarios of RAD

Answer 29

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

Question 30

Process of RAD

Answer 30

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.

Question 31

Alpha testing

Answer 31

- when software is nearly ready for release - can be tested as a complete solution - limited to internal employees, their friends, and families.

Question 32

Beta testing

Answer 32

- opened up to a wider community through a public beta program - feedback + usability issues, missed bugs, load balancing and multiple hardware compatibility

Question 33

Black-box testing

Answer 33

- 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,

Question 34

White-box testing

Answer 34

- 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

Question 35

Key qualities of good algorithms

Answer 35

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.

Question 36

Flowchart

Answer 36

A diagram representing the sequence of steps in an algorithm.

Question 37

Pseudocode

Answer 37

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.

Question 38

Suitable test data

Answer 38

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.

Question 39

Tracing execution

Answer 39

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.

Question 40

User feedback

Answer 40

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.

Question 41

risks

Answer 41

e.g not meeting time frame, costs, not meeting what client wants, resources

Question 42

TELOS

Answer 42

Technical - capable with technology Economic - short+long term financed Legal - within law Operational - implemented and maintained successfully Scheduled - completed within time frame

Question 43

Testing

Answer 43

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.

Question 44

Extreme programming practices

Answer 44

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.