Software Engineering 2 - words/knowledge needed for 5-10 of the "Multible choice" Flashcards

1
Q

In UML class diagrams, what does an association relationship represent?

A

In UML class diagrams, an association relationship represents a structural relationship that defines how instances of one class are related to instances of another class. This is depicted as a line connecting two classes, often with multiplicities (e.g., 1-to-1, 1-to-many) indicating how many objects of one class can be linked to objects of the other.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Explain the Waterfall modell

A

The Waterfall model is a traditional software development methodology that follows a linear and sequential process. Each phase of the development process must be completed before moving on to the next, and there is typically little or no overlap between phases.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Mention 3 key characteristics of the waterfall model

A

Key Characteristics of the Waterfall Model:
1. Sequential Phase
2. No Iteration
3. Documentation-Driven

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Explain the first key characteristic of the waterfall model:

  1. Sequential Phases
A
  1. Sequential Phases: Development flows step-by-step through predefined stages:
    - Requirements gathering and analysis
    - System design
    - Implementation (coding)
    - Testing
    - Deployment
    - Maintenance
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Explain the second key characteristic of the waterfall model:

  1. No Iteration
A
  1. No Iteration: Once a phase is completed, revisiting it is difficult or discouraged.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Explain the third key characteristic of the waterfall model:

  1. Documentation-Driven
A
  1. Documentation-Driven: Each phase is heavily documented to ensure clarity and continuity.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Mention 3 Strengths of the Waterfall Model

A

Strengths of the Waterfall Model:

  1. Clear structure: Each phase has a distinct goal and deliverable.
  2. Easy to manage: Simple and straightforward for projects with well-defined requirements.
  3. Good for documentation: Comprehensive documentation is created at each step.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Mention 3 Weaknesses of the Waterfall Model

A

Weaknesses of the Waterfall Model:

  1. Inflexibility: Difficult to adapt to changes once a phase is completed.
  2. Late testing: Issues are often discovered only during the testing phase, which can lead to costly fixes.
  3. Not suitable for dynamic projects: Works poorly for projects where requirements frequently change.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Explain “Burn-down Chart”

A

A Burn-down Chart is a key tool in Agile project management used to track progress and measure how much work remains in a Sprint or project. It provides a visual representation of the team’s progress toward completing their goals.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Explain 4 Key Features of a Burn-down Chart

A

Key Features of a Burn-down Chart:

  1. X-axis: Represents time (e.g., days in a Sprint).
  2. Y-axis: Represents the remaining work (e.g., story points, hours, or tasks).
  3. Ideal Burn-down Line: A straight line showing the expected progress rate.
  4. Actual Progress Line: A line that reflects the actual rate of work completion over time.

This chart helps teams identify if they are on track to meet deadlines or if adjustments are needed in planning or execution.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What’s the purpose of a Burn-down Chart in Agile?

A

Purpose of a Burn-down Chart in Agile:
- To monitor progress in real-time.
- To predict whether the team will complete all tasks by the end of the Sprint or project.
- To identify bottlenecks or issues early and facilitate better planning.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

True or false?

One of the main challenges Software Engineering facing today is the requirement of most software systems to work with a multitude of homogenous systems

A

False

This statement is misleading. The challenge is often the opposite: software systems need to interact with heterogeneous systems, not homogenous ones. Working with a variety of systems (e.g., different operating systems, platforms, or databases) is a key challenge, not just a uniform set.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

True or false?

Legacy systems are custom developed software systems for the legal domain

A

False

Legacy systems refer to old or outdated software that is still in use, and they are not necessarily custom-developed for the legal domain. Legacy systems can be found in many industries, not just the legal domain, and they often have outdated technology or architecture.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

True or false?

Software does not wear-out in the traditional sense of the term, but software does tend to deteriorate as it evolves

A

True

This refers to software aging, where software can become harder to maintain and more prone to defects as it evolves due to factors such as accumulated changes, lack of proper documentation, and the challenge of adapting to new environments.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

True or False?

Since software is essentially intangible it is relatively easy to manage software projects

A

False

The intangibility of software actually makes it harder to manage, not easier. Unlike physical products, software doesn’t have a tangible form that can be measured, making it difficult to visualize progress, communicate requirements, and manage resources effectively. This adds complexity to software project management.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

True or False?

With the advent of component-based software assembly, we find that only less than 20% of today’s software is still custom built.

A

False

This statement is incorrect. While component-based software assembly has become more common, it’s not accurate to say that only 20% of software is custom built. Many software systems, especially in areas like enterprise applications or specialized industries, still require significant custom development. The actual percentage varies depending on the type of software and industry.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

True or false?

The fundamental reason that software cannot be considered to be engineered is the complexity of systems and their interaction continues faster than we can understand it.

A

True

This is the fundamental reason why software cannot always be considered to be engineered in the traditional sense. Software systems can become highly complex, and the speed at which new technologies, components, and interactions evolve often outpaces our ability to fully comprehend and predict their behavior. This rapid complexity growth makes it difficult to apply traditional engineering principles in the same way as fields like civil or mechanical engineering, where systems are generally more stable and predictable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

True or false?

The fundamental reason that software cannot be considered to be engineered is that It is designed by humans and therefore flawed

A

False

While human design can lead to flaws, this isn’t the primary reason software cannot be considered traditionally engineered. All engineering fields involve human design, but with established principles and practices to minimize flaws. The issue with software lies more in its inherent complexity and rapid change rather than just human error.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

True or false?

The fundamental reason that software cannot be considered to be engineered is that Software engineering (as opposed to other forms of engineering, such as Civil) is an art - not a science.

A

False

This is an oversimplification. While software engineering does involve creative problem-solving, it is also rooted in scientific and engineering principles. The issue with software engineering isn’t that it’s an art, but rather that it faces unique challenges like rapidly changing technology and highly complex system interactions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

True or false?

The fundamental reason that software cannot be considered to be engineered is that The discipline is relatively new, say in comparison to bridge building that is an activity that has millennia of practice.

A

False

Although software engineering is a newer field compared to civil engineering, this is not the fundamental reason software can’t be considered traditionally engineered. Newer disciplines can still apply rigorous engineering practices. The real challenge lies in the complexity of software and the speed at which it evolves.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Explain what a “rapid prototype” is

A

A rapid prototype is a preliminary version of a product created quickly to visualize and test concepts. It’s used in the early stages of development to gather feedback from stakeholders, identify requirements, and refine the design. The goal is to create a working model that can be easily modified based on input, allowing for faster iteration and better alignment with user needs before developing the final product.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Explain “Views of quality software”

A

“Views of quality software” refers to the different perspectives or criteria that can be used to evaluate whether software is of high quality. These views can vary depending on the stakeholders involved (e.g., developers, users, business leaders), but they generally focus on certain key attributes that contribute to software’s overall quality.

23
Q

Explain the View of quality software “Optimizing price and performance”

A

Quality software often aims to balance cost and performance. Optimizing performance means that the software runs efficiently, utilizing system resources effectively. Price optimization is important because software needs to be developed within budget constraints, delivering value for the cost incurred.

24
Q

Explain the View of quality software “Minimizing the execution errors”

A

A key indicator of quality software is minimizing execution errors, which refers to bugs or defects that prevent the software from functioning as expected. High-quality software is typically free from critical bugs and handles edge cases well.

25
Q

Explain the View of quality software “Conformance to specification”

A

Quality software must conform to the specifications set forth in the requirements phase. This means that the software meets the expectations, features, and behavior defined by stakeholders and documented in the requirements.

26
Q

Explain the View of quality software “Establishing valid requirements”

A

Quality software starts with valid and clear requirements. Without well-defined, valid requirements, the resulting software may fail to meet user needs and expectations. Establishing solid, accurate requirements ensures that the software will deliver value and meet objectives.

27
Q

Explain “Planning Poker” in the Agile process

A

Planning Poker is a consensus-based technique used in Agile project management, particularly during Sprint Planning in Scrum. Its purpose is to estimate the effort or complexity required to complete user stories or tasks in the product backlog. The technique helps the team reach a collective understanding of how much effort each task will take, using a fun and interactive approach.

In summary, Planning Poker is a collaborative technique for estimating tasks in Agile, helping teams come to a shared understanding of the work involved while encouraging communication and teamwork.

28
Q

Mention the 5 steps of Planning Poker in the Agile process

A
  1. Preparation
  2. Story Presentation
  3. Estimation
  4. Reveal and Discuss
    5.Re-estimation
29
Q

Explain the “Preparation”-step of Planning Poker in the Agile process

(first step)

A

Preparation: Each participant (usually the development team, but sometimes including the product owner and Scrum master) is given a deck of cards. Each card has a number representing an estimate of effort, typically in Fibonacci numbers (1, 2, 3, 5, 8, 13, etc.)

30
Q

Explain the “Story Presentation”-step of Planning Poker in the Agile process

(second step)

A

Story Presentation: The product owner or team lead presents a user story or task that needs to be estimated. The description of the story is clarified if necessary.

31
Q

Explain the “Estimation”-step of Planning Poker in the Agile process

(third step)

A

Estimation: Each participant independently chooses a card from their deck that represents how much effort they believe the task will require. The cards are hidden from others until everyone has selected their estimate.

32
Q

Explain the “Reveal and Discuss”-step of Planning Poker in the Agile process

(fourth step)

A

Reveal and Discuss: Once everyone has selected a card, the estimates are revealed simultaneously. If everyone agrees, the task is assigned that estimate. If there is a significant difference in estimates, the team discusses the reasons behind their choices. Team members explain their rationale, and the group tries to reach a consensus.

33
Q

Explain the “Re-estimation”-step of Planning Poker in the Agile process

(fifth step)

A

Re-estimation: After the discussion, the team may re-estimate the task, with everyone selecting a new card based on the discussion. This process can be repeated as necessary until consensus is reached.

34
Q

Explain Agile

A

Agile is a software development methodology that emphasizes flexibility, collaboration, and customer-centric approaches to deliver high-quality software quickly and iteratively. It focuses on adapting to changing requirements and delivering functional software in small, incremental releases rather than all at once.

35
Q

Mention the 5 Key Principles of Agile

A

Key Principles of Agile:
1. Iterative Development
2. Collaboration
3. Customer Focus
4. Adaptability
5. Working Software

36
Q

Shortly explain the first Key Principle of Agile:

  1. Iterative Development
A
  1. Iterative Development: Work is broken into small, manageable iterations (Sprints), typically 1-4 weeks long.
37
Q

Shortly explain the second Key Principle of Agile:

  1. Collaboration
A
  1. Collaboration: Close communication between team members and stakeholders (developers, testers, product owners, and customers).
38
Q

Shortly explain the third Key Principle of Agile:

  1. Customer Focus
A
  1. Customer Focus: Continuous feedback ensures the software aligns with user needs and evolving requirements.
39
Q

Shortly explain the fourth Key Principle of Agile:

  1. Adaptability
A
  1. Adaptability: The team welcomes changing requirements, even late in the project.
40
Q

Shortly explain the fifth Key Principle of Agile:

  1. Working Software
A
  1. Working Software: The primary measure of progress is delivering functional, tested software frequently.
41
Q

Mention 4 benefits of agile

A

Benefits of Agile:
- Faster delivery of working software.
- Better response to changes.
- Improved collaboration and transparency.
- Higher customer satisfaction.

42
Q

Explain scrum

A

Scrum is an Agile framework for managing and developing complex software projects. It emphasizes teamwork, iterative progress, and adaptability to deliver high-quality products efficiently.

43
Q

Explain the three roles in scrum

A

Roles in Scrum

Product Owner:
Represents the stakeholders and the voice of the customer.
Defines the product vision and prioritizes the Product Backlog (a list of features or tasks).

Scrum Master:
Facilitates the Scrum process and ensures the team adheres to Scrum principles.
Acts as a coach for the team, removing obstacles and enabling productivity.

Development Team:
A cross-functional group responsible for delivering the Increment of work at the end of each Sprint.

44
Q

Explain the three phases in Scrum

A

The three phases in Scrum:

Planning: The initial phase is an outline planning phase where you
establish the general objectives for the project and design the
software architecture.

Sprints: This is followed by a series of sprint cycles, where each cycle
develops an increment of the system.

Closure: The project closure phase wraps up the project, completes
required documentation such as system help frames and user
manuals and assesses the lessons learned from the project.

45
Q

Explain the scrum-term: Development team

A

A self-organizing group of software developers, which should be no more than 7 people. They are responsible for developing the software and other essential
project documents.

46
Q

Explain the scrum-term: Potentially shippable product increment

A

The software increment that is delivered from a sprint. The idea is that this should
be ‘potentially shippable’ which means that it is in a finished state and no further
work, such as testing, is needed to incorporate it into the final product. In practice, this is not always achievable

47
Q

Explain the scrum-term: Product backlog

A

This is a list of ‘to do’ items which the Scrum team must tackle. They may be
feature definitions for the software, software requirements, user stories or
descriptions of supplementary tasks that are needed, such as architecture definition
or user documentation.

48
Q

Explain the scrum-term: Product owner

A

An individual (or possibly a small group) whose job is to identify product features or
requirements, prioritize these for development and continuously review the product backlog to ensure that the project continues to meet critical business needs. The Product Owner can be a customer but might also be a product manager in a
software company or other stakeholder representative.

49
Q

Explain the scrum-term: Scrum meeting

A

A daily meeting of the Scrum team that reviews progress and prioritizes work
to be done that day. Ideally, this should be a short face-to-face meeting that
includes the whole team.

50
Q

Explain the scrum-term: ScrumMaster

A

The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she is
responsible for interfacing with the rest of the company and for ensuring that
the Scrum team is not diverted by outside interference. The Scrum developers
are adamant that the ScrumMaster should not be thought of as a project
manager. Others, however, may not always find it easy to see the difference.

51
Q

Explain the scrum-term: Sprint

A

A development iteration. Sprints are usually 2-4 weeks long.

52
Q

Explain the scrum-term: Velocity

A

An estimate of how much product backlog effort that a team can cover in
a single sprint. Understanding a team’s velocity helps them estimate what
can be covered in a sprint and provides a basis for measuring improving
performance.

53
Q

Mention 4 Benefits of Scrum

A

Benefits of Scrum
- Increases productivity and transparency.
- Enables frequent delivery of valuable software.
- Promotes collaboration and adaptability to changes.
- Encourages continuous improvement through feedback.