Software Engineering 2 - words/knowledge needed for 5-10 of the "Multible choice" Flashcards
In UML class diagrams, what does an association relationship represent?
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.
Explain the Waterfall modell
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.
Mention 3 key characteristics of the waterfall model
Key Characteristics of the Waterfall Model:
1. Sequential Phase
2. No Iteration
3. Documentation-Driven
Explain the first key characteristic of the waterfall model:
- Sequential Phases
- Sequential Phases: Development flows step-by-step through predefined stages:
- Requirements gathering and analysis
- System design
- Implementation (coding)
- Testing
- Deployment
- Maintenance
Explain the second key characteristic of the waterfall model:
- No Iteration
- No Iteration: Once a phase is completed, revisiting it is difficult or discouraged.
Explain the third key characteristic of the waterfall model:
- Documentation-Driven
- Documentation-Driven: Each phase is heavily documented to ensure clarity and continuity.
Mention 3 Strengths of the Waterfall Model
Strengths of the Waterfall Model:
- Clear structure: Each phase has a distinct goal and deliverable.
- Easy to manage: Simple and straightforward for projects with well-defined requirements.
- Good for documentation: Comprehensive documentation is created at each step.
Mention 3 Weaknesses of the Waterfall Model
Weaknesses of the Waterfall Model:
- Inflexibility: Difficult to adapt to changes once a phase is completed.
- Late testing: Issues are often discovered only during the testing phase, which can lead to costly fixes.
- Not suitable for dynamic projects: Works poorly for projects where requirements frequently change.
Explain “Burn-down Chart”
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.
Explain 4 Key Features of a Burn-down Chart
Key Features of a Burn-down Chart:
- X-axis: Represents time (e.g., days in a Sprint).
- Y-axis: Represents the remaining work (e.g., story points, hours, or tasks).
- Ideal Burn-down Line: A straight line showing the expected progress rate.
- 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.
What’s the purpose of a Burn-down Chart in Agile?
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.
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
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.
True or false?
Legacy systems are custom developed software systems for the legal domain
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.
True or false?
Software does not wear-out in the traditional sense of the term, but software does tend to deteriorate as it evolves
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.
True or False?
Since software is essentially intangible it is relatively easy to manage software projects
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.
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.
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.
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.
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.
True or false?
The fundamental reason that software cannot be considered to be engineered is that It is designed by humans and therefore flawed
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.
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.
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.
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.
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.
Explain what a “rapid prototype” is
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.