Cards Linked With LOs

Question 1

White-Box Testing

Answer 1

White Box Testing is the testing of a softwares solutions internal coding and infrastructure. This testing is inside the box. Also know as, Clear, Open, Structural or Glass Box Testing This involves checking a series of predefined inputs against expected or desired outputs How to perform: 1. Understand the source code 2. Create test cases and test them Uses Code Coverage Analysis

Question 2

Black-Box Testing

Answer 2

This involves testing from an external or end-user type perspective. Only end user experience is tested - just the interface Doesn’t concern the internals of the ‘box’. Types: Functional Testing Non-Functional Testing Regression Testing How to perform: 1. Examine initial requirements 2. Tester uses valid and invalid inputs and predicts the outputs

Question 3

Code Coverage Analysis

Answer 3

It identifies areas of a program that are not exercised by a set of test cases. Once gaps are identified, you create test cases to verify untested parts of code, thereby increase the qualify of the software product. Used by White-Box Testing Uses the following techniques -Statement Coverage -Branch Coverage

Question 4

Statement Coverage

Answer 4

Requires every possible statement in the code to be tested at least once during the test process. Used by Code Coverage Analysis

Question 5

Branch Coverage

Answer 5

Checks every possible path (if- else and other conditional loops) of a software application Used by Code Coverage Analysis

Question 6

Functional Testing

Answer 6

Is related to functional requirements of a system; it’s done by software testers. Part of Black-Box Testing

Question 7

Non-Functional Testing

Answer 7

Not related to testing pod a specific functionality, but non-functional requirements such as performance, scalability or usability. Part of Black-Box Testing

Question 8

Regression Testing

Answer 8

Is done after code fixes, upgrades or any other system maintenance to check the new code has not affected the existing code. Part of Black-Box Testing

Question 9

Five Causes of Poor Software Quality

Answer 9

1. Lack of Domain Knowledge 2. Lack of Technology Knowledge 3. Unrealistic Schedules 4. Badly Engineered Software 5. Poor Acquisition Practices https://www.datamation.com/applications/top-five-causes-of-poor-software-quality/

Question 10

Volere Template

Answer 10

Template for a requirements document. Also includes other issues that may affect requirements. The template his organised into five main sections - Project drivers, Project constraints, Functional requirements, Non-functional requirements and Project issues. https://learn2.open.ac.uk/mod/oucontent/view.php?id=1681023&section=6.1

Question 11

Volere Snowcard

Answer 11

This is written for each functional and non-functional requirement, including the following information: requirement number – this is to identify the requirement uniquely event/use case – identify which use case or event is associated with this requirement description – a one-sentence statement of the intent of the requirement rationale – why the requirement is considered important or necessary originator – who raised the requirement in the first instance fit criterion – this is the acceptance criterion, written in a quantified manner so that the solution can be tested against the requirement customer satisfaction/dissatisfaction – this is an indication of the customer’s reaction to the requirement’s omission from the solution priority – a mark of the value of the requirement for the customer conflicts – requirements that contradict this one or make this one less feasible supporting materials – link to other documents to help understand the requirement history – origin of and changes to the requirement. https://learn2.open.ac.uk/mod/oucontent/view.php?id=1681023&section=6.1

Question 12

Software Architecture

Answer 12

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”

Excerpt From: The Open University. “TM354 Block 3 Unit 9”. Apple Books.

Question 13

Examples of Software Architecture

Answer 13

• LAMP stack
• client-server
• peer-to-peer
• pipe and filter

Question 14

ASR

Answer 14

Architecturally Significant Requirments

“the requirements that drive a system’s software architecture. The four characteristics they identified were as follows.

• Quality attributes* are non-functional requirements such as security, reliability, availability, usability, maintainability, portability and so on that you have met in earlier units. In Unit 10 we shall look in some detail at how these quality attributes (often called ilities) drive architectural decisions.
• Core features* are described by Chen et al as ‘the problem the software is trying to solve’. For example, an online chat application is intended to allow participants in different locations to exchange text messages. To do this a network of some sort is essential, which immediately has implications for the architecture.
• Constraints*. All requirements can be described as constraints, but here the authors mean requirements such as technical constraints – for example, the client may have specified a particular programming language – or non-technical constraints such as budget or time.
• Application environment.* This is the environment in which the system will run. For example, a navigation app will need GPS connectivity.”

Excerpt From: The Open University. “TM354 Block 3 Unit 9”. Apple Books.

Question 15

TDD

Answer 15

Test-Driven Developent

Code for this is wirten in very small increments - usually no more than five or ten lines of code. There are six principle steps to this; decide of a code increment, decide on a test, write the test, run all the tests, write the code, run all the tests again.

Question 16

Unit Testing

Answer 16

Unit testing is usually perform on classes of object-oriented systems. The focus is on the systmatic testing of metods using test classes. An common example for this in Java is JUnit. Each time the tests are run, JUnit generates a report listing that itemises which tests the software passed and which failed.

The first stage of developmental testing in which units of functionality (for example, the classes in an object-oriented system) are tested in isolation.

Question 17

Examples of Testing

Answer 17

• TDD
• Black-Box Testing
• White-Box Testing
• Unit Testing
• Functional Testing
• Non-Functional Testing
• Usability Testing
• Requirements-based Testing
• Developmental Testing
• Regression Testing

Question 18

Benefits of TDD

Answer 18

“TDD is claimed to bring many benefits, including the following:

• Test coverage*: Test coverage is in some respects comprehensive, with virtually all code having associated tests. These tests should all have been run successfully throughout development. Finished code therefore already has an extensive test suite.
• Regression testing and early discovery of errors*: Many kinds of error are discovered and corrected at the earliest opportunity. Changes that break tests can be quickly identified and rectified.
• Executable documentation*: The tests both show how the code should be used and indicate what it should do by means of test cases.
• Beneficial effect on design*: The writing of tests contributes to design as well as to testing. TDD encourages clarity, modularity and a focus on interface over implementation.
• Complementarity with DbC*: TDD tests by test cases, whereas DbC tests by invariants. These perspectives are usefully complementary.
• Promotes good code quality*: TDD promotes sustained focus on quality, design for testability and early and frequent refactoring.
• Inhibition of ‘featuritis’*: Because addition of extraneous code is discouraged during TDD cycles, creeping featuritis – the addition of unnecessary features – is inhibited.”

Excerpt From: The Open University. “TM354 Block 3 Unit 11”. Apple Books.

Question 19

Limitations and Pitfalls of TDD

Answer 19

“User interface: TDD does not readily apply to user interface testing, for which it is better to apply techniques such as usability testing.
Testing of applications integrated with databases: TDD alone is not adequate for the comprehensive testing of databases.
Multithreaded systems: TDD is not generally suitable for the testing of multithreaded systems, as results may depend on the vagaries of timing.
Customer acceptance: TDD cannot take the place of customer testing.
Legacy systems and systems reusing large code components: If large amounts of code are being reused and TDD was not applied when they were being coded, then at best unit tests can be added retrospectively. Such a retrofit would not constitute TDD, since the testing would not guide the evolution of the code. In many cases, retrofitting unit tests to large bodies of existing code may be impractical.
Management support: If management chooses to penalise time spent on writing tests during development, TDD is unlikely to flourish.
Code whose requirements are liable to change greatly: Sometimes, for example during scientific research or product development research, the purpose of developing software may be to find out what the requirements should be in some little-understood area or what happens in some poorly understood situation. This is known as exploratory programming. In these and other situations, requirements may change so extensively and frequently that there is repeated wholesale invalidation of existing unit tests. This would render TDD a hindrance rather than a help.
Integration testing: TDD cannot take the place of integration testing, for reasons discussed below in detail in subsection 4.3.
TDD is only as the tests devised: Devising good tests and effective test cases is an important art and one that applies with a scope far beyond TDD alone. Because of this wider scope and importance, we will defer the discussion of strategies for creating test cases until Section 4.4, at which point you will have had a chance to become familiar with wider aspects of testing.”Excerpt From: The Open University. “TM354 Block 3 Unit 11”. Apple Books.

Question 20

DbC

Design by Contract

Answer 20

The process of developing software based on the notion of contracts between objects, which are expressed as assertions.

“One way to ensure that a software system performs its intended functions (its specification) is based on the real-world concept of a contract.”

Excerpt From: The Open University. “TM354 Block 2 Unit 6”. Apple Books.

“In real life, contracts are very often formal and binding agreements between two parties; in object-oriented software development, contracts are used to produce more formal descriptions of objects and the services they provide.”

Excerpt From: The Open University. “TM354 Block 2 Unit 6”. Apple Books.

Question 21

Assertion

Answer 21

In DbC, a precondition, a postcondition or an invariant.

Question 22

Class Invariant

Answer 22

A constraint that must be true at all times, other than during when one of its methods is executing. A statement about the values of the attributes of a class that must hold for all instances of that class.

Question 23

Non-Functional Requirement

Answer 23

A quality that a system must have.

Question 24

Functional Requirement

Answer 24

a specified action that a system has to perform

Question 25

DbC vs TDD

and it cant be used

Answer 25

Here’s the basic difference:

A DbC contract is a mathematical specification of the valid domain (input state space) and/or result (output state space) of a routine within a class;

TDD is development using ‘tests’ that constitute specific points in a routine’s input value space, which test a routine on an instance.

https://wolandscat.net/2021/03/04/design-by-contract-dbc-v-test-driven-design-tdd/

“There are circumstances where TDD and DbC may not be particularly applicable. These include projects that make intensive use of legacy code or reuse large components, and projects where there is a heavy emphasis on user interfaces.”

Excerpt From: The Open University. “TM354 Block 3 Unit 11”. Apple Books.

Question 26

Developmental Testing

Answer 26

Encopasses the testing during development; the three groups are Unit Testing, Intergration Testing and System Testing

Question 27

Integration Testing

Answer 27

The second stage of developmental testing in which previously tested units are tested together as an integrated whole.

Question 28

System Testing

Answer 28

The third stage of developmental testing in which the completed system is tested against the customer’s requirements.

Question 29

Requirements Engineering

Answer 29

An activity in the process of developing software that aims to elicit and specify the requirements of the client(s)/user(s) in a form that can be used in the design of the software and in assessing its quality once it is built. It can be divided into two main activities: requirements elicitation and requirements analysis.

Question 30

Requirement Eliciation

Answer 30

An activity undertaken to discover, identify, review, articulate and understand the users’ needs and constraints on the software and its development. The result is a clear statement of the problem to be addressed.

Question 31

Requirements Analysis

Answer 31

An activity undertaken to decide what needs to be done to solve the problem that has been articulated during requirements elicitation. The result is a deliverable that forms the basis for a solution to be implemented. It is expressed in technical terms that are understandable to the developers.

Question 32

Requirements Engineering Process

Answer 32

https://www.inflectra.com/GraphicsViewer.aspx?url=~/Ideas/Whitepapers/principles-of-requirements-engineering.doc&name=wordml://03000002.png

Question 33

OOAD

Answer 33

Object-Oriented Analysis and Design

This is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

OOAD in modern software engineering is typically conducted in an iterative and incremental way. The outputs of OOAD activities are analysis models (for OOA) and design models (for OOD) respectively. The intention is for these to be continuously refined and evolved, driven by key factors like risks and business value.

https://en.wikipedia.org/wiki/Object-oriented_analysis_and_design

Question 34

Core Activites of Software Development

Answer 34

Processes, Requirements, Design, Engineering, Construction, Testing, Debugging, Deployment, and Maintenanace

Question 35

Charatistics of a good software system

Answer 35

Usable (meeting user’s needs), Reliable, Fliexible, Available and Affordable

Question 36

“How might greater flexibility make a software system more affordable over its whole life?”

Question 37

“Give two reasons why a delivered software system might not meet its users’ needs.”

Answer 37

“Software systems are usually out of date even as they are being developed because:
some needs are often missed during requirements capture
users’ needs change with time.”

Excerpt From: The Open University. “TM354 Block 1 Unit 1”. Apple Books.

Question 38

Life Cycle

Answer 38

The sequence in which a number of different activities are carried out to define an overall process for the development of a software system.

Question 39

UP

Answer 39

Unified Process

A popular iterative and incremental process for building enterprise systems based on an object-oriented approach. It consists of four phases: inception, elaboration, construction and transition.

Question 40

UP - Incepetion

Answer 40

This is the inital planning phase of development. This is when the vision is defined, a buiness case is made and development is justified.

“The activities carried out are usually defined under project management and are not covered in this module. They include:

• planning the project schedule
• finding the right people to work on the project and assigning them to tasks
• making sure the team is properly trained and has the proper tools and work environment
• liaising with the customer
• analysing and managing the risks
• estimating the effort required
• making sure that the lessons learnt on other projects in the organisation feed into this project and that this project’s lessons are passed on to others.”

Excerpt From: The Open University. “TM354 Block 1 Unit 4”. Apple Books.

Question 41

UP - Elaboration

Answer 41

This comes after the Inception phase, but before the Construction phase.

“There will be some domain modelling (in the UP it is called business modelling), requirements, analysis, design, implementation and testing in each iteration, but the amount of work involved in each of these will vary from one iteration to the next, as shown in Figure 2.”

Excerpt From: The Open University. “TM354 Block 1 Unit 4”. Apple Books.

Question 42

An Agile UP

Answer 42

UP is a flexiable process and most of the artefaces are not mandatory.

Introducting Agile to UP means that interatrions come from months to weeks.

The mix of the two stress simplicity, agility and focus on activies that return value and satify a customers need’s.

Question 43

Types of Value for Performance Scenarios

Answer 43

“A sporadic event is one that is infrequent and isolated. A stochastic event is one occurring randomly but according to a well-defined probability distribution: for example heads coming up when a coin is flipped. Bursty events are ones coming in sudden and unpredictable clusters overlaying normally low background activity.
Latency is the time taken to process a stimulus, for example how long does a search engine take to respond to a query? Throughput is the number of events dealt with in a given time. Jitter is the amount of variation in latency: for example, are some responses very quick while others take much longer? Miss rate measures the proportion of events that are not responded to, and data loss measures how much data is lost because the system fails to record it.”

Excerpt From: The Open University. “TM354 Block 3 Unit 10”. Apple Books.

Question 44

Example of Performance Scenario

Answer 44

Question 45

Example of Usability Scenario

Answer 45

Question 46

Tatics for meeting performance requirements

Answer 46

1. Manage Demand
   
   1. Reduce Frequency of Events
   2. Limit Demand
   3. Making Processing More Efficcent
2. Manage System Capacity
   
   1. Increase Resources
   2. Reduce Bottlenecks
   3. Exploit Concurrency
3. Match Resources to Demand
   
   1. Schedule Schedules

Question 47

LOC

Answer 47

Lines-Of-Code Metric

A very simple measure of the complexity of a system description is given by counting the number of lines in a piece of code.

Question 48

Cyclomatic-Complexity Metric

Answer 48

A measure of the complexity of a method by counting the number of independent paths through a method body.

Question 49

5 Steps to Draw a State Machine Diagram

Answer 49

Step 1 - Define States - A state is a condition a object can be in its lifetime

Step 2 - Describe States - add documentation of what is meant by this

Steps 3 - Draw Transitions - lines to indecate a state to another

Step 4 - Define Transition Triggers - specify what needs to happen to make this transition happen

Step 5 - Define Guard Condtions - this makes a transition conditional, only when consraints are met.

Question 50

OCL

Answer 50

Object Constraint Language

• Officail part of UML
• Strongly typed, declarive specification of system properties
• Means of expressing contrains + collection classes
• Expresses UML Diagram Navigation

https://www.youtube.com/watch?v=v7PTDwGrciE

Question 51

Buisness Domain

Answer 51

Business Domain refers to real-world aspects of your solution (e.g. Healthcare, Aviation, Finance, Military, Retail, etc). The business domain informs your requirements and acceptance criteria for the system; it can be suggestive of a very high-level form of segregation for different areas.

https://softwareengineering.stackexchange.com/a/314839

Question 52

What is the importance of Use Cases?

Answer 52

Use cases have been used extensively over the past few decades. The advantages of Use cases includes:

• The list of goal names provides the shortest summary of what the system will offer
• It gives an overview of the roles of each and every component in the system. It will help us in defining the role of users, administrators etc.
• It helps us in extensively defining the user’s need and exploring it as to how it will work.
• It provides solutions and answers to many questions that might pop up if we start a project unplanned.

Question 53

SOA

Answer 53

Service-oreinted Arcitecture

SOA is an approach to build enterprise systems that deliver application functionality either as services to end-user applications or to build other services. In this approach, services are software assets, which are described and interact in a standard way, so that the focus of application development is the assembly of services as building blocks.

Question 54

TDD Cycle

Answer 54

https://medium.com/swlh/learning-to-love-tdd-f8eb60739a69

Question 55

Eight most common Agile Estimation Techniques

Answer 55

1. Three Point Estimate - By finding the most likely, the optimistic estimate and the pessimestic one, and then looking at the average of these.
2. Planning Poker - Teams of eight, look at the requirements of each task, and anoymously estimate task time and sumbit it on a card to be collated.
3. Affinity Grouping - Grouping tasks to similar length tasks to try and esitmate a time for the group to be completed.
4. Random Distribution - This technique places items in an order from low to high. Each person takes a turn, choosing either to move an item up or down one spot, discussing an item, or passing. Your process is done once everyone passes on their turn.
5. T-shirt Sizes - Giving a task the ‘size’ XS, S, M, L, XL and then estimating lenght from this.
6. Buckets - Similar to planning poker, the bucket technique aims for consensus through discussion, and by assigning values to each task. The facilitator starts with one task, sets it in the middle, and then continues to read and place tasks in buckets relative to the first one. The team can divide up tasks and bucket them, before coming back together and reviewing. Discussion is key to make sure everyone agrees before the final estimates are set. You’ll also look to make sure tasks are evenly distributed and not, say, all under the 200 bucket.
7. Large, Small, Uncertain - Fast, simple, and productive, this technique is like bucketing but with only three possible values to assign. You’ll start out discussing, and then divide and conquer to get all the tasks added to the large, small, or uncertain groups.
8. Dot Voting - This one is fairly simple: each person gets a number of dots and uses them to vote on which projects are big and small. More dots mean more time and effort is required. Fewer dots indicate a fairly straightforward and quick item.
   https: //hubstaff.com/tasks/agile-estimation-techniques

Question 56

Four Main Activites of Requirements Engineering

Answer 56

1. Elicitation - Understanding and Gathering
2. Documenetation - Capturing Reqirements Formally
3. Validation & Negotiation - Ensure these are valid and understanadble
4. Management - Managing any changes that aries

https://www.youtube.com/watch?v=_llqRnlrzWw

Question 57

Types of Non-Functional Requirements

Answer 57

• Look-and-feel requirements. The spirit of the product’s appearance.
• Usability and humanity requirements. The product’s ease of use and any special usability considerations.
• Performance requirements. How fast, how safe, how accurate, how reliable, and how available the functionality must be.
• Operational and environmental requirements. The environment on which the product will have to work (under water, for example), and what considerations must be made for this environment.
• Maintainability and support requirements. Expected changes, and the time allowed to make them.
• Cultural requirements. Special requirements that come about because of the people involved in the product’s development and operation.
• Legal requirements. The laws and standards that apply to the product.
• Security requirements. The security and confidentiality of the product.”

Excerpt From: The Open University. “TM354 Block 1 Unit 2”. Apple Books.