Concepts of Software Engineering
● What are the three ways to deal with complexity? The three ways to deal with
complexity in software systems are Abstraction, Decomposition, and Hierarchy.
○ Abstraction allows ignoring unessential details and is a thought process where
ideas are distanced from objects. It helps group collections of objects to reduce
complexity, a process called "chunking".
○ Decomposition is a technique used to master complexity by breaking a system
into parts ("divide and conquer"). The two major types are functional
decomposition (system decomposed into functions or modules) and
object-oriented decomposition (system decomposed into classes or objects).
○ Hierarchy provides relationships between these "chunks" or abstractions, with
two important types being the "Part-of" hierarchy (Aggregation) and the
"Is-kind-of" hierarchy (Taxonomy or Generalization).
● What is a model? A model is an abstraction of a system. It can be used to describe a
system that no longer exists, an existing system, or a future system to be built. In
software engineering, models are considered theories, and their "truth" is never certain;
they are built and then tested to find counterexamples through activities like
requirements validation, user interface testing, design reviews, and source code testing.
Modeling is defined as the "development of abstractions to answer specific questions
about a set of phenomena while ignoring irrelevant details".
● System model = ?? A System Model is defined as the combination of the Object
model, functional model, and dynamic model.
○ The Object model describes the structure of the system.
○ The Functional model describes the functions of the system.
○ The Dynamic model describes how the system reacts to external events.
● What are the two decomposition methods? The two major types of decomposition are
functional decomposition and object-oriented decomposition.
○ Functional decomposition breaks the system into modules, where each
module is a major function in the application domain. These modules can be
further decomposed. However, its consequence can be source code that is hard
to understand, complex, and difficult to maintain because functionality is spread
across the system. It is important at the requirements engineering phase and for
high-level system descriptions.
○ Object-oriented decomposition breaks the system into classes, where each
class is a major entity in the application domain. Classes can also be
decomposed into smaller classes. This approach is generally considered good.
Project Management and Estimation
● What are the three trade-offs that project managers must manage? The art of
project management lies in making trade-offs among three key aspects:
○ The size of the system: What functionality the system will include.
○ The time to complete the project: When the project will be finished.
○ The cost of the project.
● Why is it not a good idea to add more developers to a team to improve
productivity? Adding more developers to a team does not always result in better
productivity due to increasing complexity with larger teams. The number of potential
communication channels in a team grows quadratically with the number of participants,
represented by the formula n(n-1)/2. In large system development efforts, software
engineers may spend more time communicating than coding, leading to reduced
efficiency rather than improved productivity. Misunderstandings and the need for
coordination increase significantly with team size, as illustrated by communication
challenges in the "Airplane Crash report" example.
Requirements Engineering
● Explain what a functional requirement is. Functional requirements describe the
interactions between the system and its environment, independent of the
implementation. They define what a system is supposed to do and are typically
phrased as actions, such as "An operator must be able to define a new game,"
"Advertise a new league," or "Schedule tournament".
● Explain what a nonfunctional requirement is. What are the primary types of
nonfunctional requirements? Nonfunctional requirements describe aspects not
directly related to the functional behavior of the system. They define how a system
is supposed to be and are phrased as constraints or negative assertions, for example,
"The response time must be less than 1 second" or "A system crash should not result in
data loss".
The primary types of nonfunctional requirements include:
○ Quality requirements:
■ Usability: The ease with which actors can use a system to perform a
function (e.g., number of steps for a task).
■ Reliability: Includes robustness (ability to maintain function despite
wrong input or environmental changes) and safety.
■ Performance: Such as response time, scalability, throughput, and
availability (ratio of expected uptime).
■ Supportability: Including adaptability and maintainability.
○ Constraints (or "Pseudo requirements"):
■ Implementation requirements (e.g., "implementation language must be
Java").
■ Interface, Operation, and Packaging requirements.
■ Legal requirements (e.g., licensing, certification, regulation).
● Use two sentences to summarize the difference between functional and
nonfunctional requirements. Functional requirements define what a system is
supposed to do. In contrast, non-functional requirements define how a system is
supposed to be, focusing on properties and constraints rather than specific actions.
● List the major elements in a textual use case. After scenarios are formulated, use
cases are described in more detail, including the following major elements:
○ Participating actors.
○ Entry condition.
○ Flow of events.
○ Exit condition.
○ Exceptions.
○ Nonfunctional requirements.
● What is the purpose of developing use cases during systems analysis? Use cases
are developed during requirements elicitation and analysis to describe the functional
behavior of the system as seen by the user. They serve as abstractions that describe
a class of scenarios, helping to define the system in terms understood by the customer
("Requirements specification") and subsequently in terms understood by the developer
("Analysis model"). Use cases are a part of the functional model of a system.
● Use cases represent functional requirements or non-functional requirements? Use
cases represent functional requirements. They are part of the functional model and
describe the system's functional behavior from the user's perspective.
● Is it possible that a use case does not have any participating actors? Why? It is
generally not possible for a use case to exist without any participating actors. A use
case diagram represents the functionality of the system "from user’s point of view". The
definition of a use case implies an interaction with an actor to achieve a specific goal.
Therefore, without an actor, the core purpose of a use case – describing functional
behavior as perceived by a user – is not met.
● What is a scenario? List four types of scenarios. A scenario is a synthetic
description of an event or series of actions and events, written from an end user’s
point of view. It is a textual description of the usage of a system and can also include
multimedia elements like text, video, pictures, and storyboards, along with details about
the work environment, social situations, and resource constraints. More concretely, it is a
"narrative description of what people do and experience as they try to make use of
computer systems and applications" and a "concrete, focused, informal description of a
single feature of the system used by a single actor".
The four types of scenarios are:
○ As-is scenario: Describes a current situation, often used in re-engineering
projects where the user describes an existing system.
○ Visionary scenario: Describes a future system, used in greenfield engineering
and re-engineering projects, often requiring collaboration between users and
developers.
○ Evaluation scenario: A description of a user task against which the system is
to be evaluated.
○ Training scenario: A description of step-by-step instructions that guide a
novice user through a system.
● What is the difference between requirements elicitation and analysis? Both
requirements elicitation and analysis are parts of the overall requirements process and
focus on the user's view of the system.
○ Requirements elicitation is the definition of the system in terms understood
by the customer; it results in a "Requirements specification".
○ Analysis is the definition of the system in terms understood by the
developer; it results in a "Technical specification" or "Analysis model".
Essentially, the requirements specification uses natural language, while the
analysis model uses a formal or semi-formal notation like UML.
UML and Modeling
● List the three associations defined between use cases in a use case diagram. The
provided sources do not explicitly detail the "three associations" between use cases.
However, common relationships in UML use case diagrams, which are implied by the
study guide's subsequent questions (such as "extends" and "includes"), often include:
○ Include (also known as «include»)
○ Extend (also known as «extend»)
○ Generalization (for use cases).
● What is the difference between generalization and realization?
○ Generalization is a relationship where one model element (the subclass) is
based on another model element (the superclass), inheriting its characteristics. It
represents an "is-kind-of" hierarchy or taxonomy. For example, a "Red Blood
Cell" is a kind of "Blood Cell," and a "CalculatorWatch" is a kind of "Watch". In
object-oriented programming, this is implemented as inheritance.
○ The provided sources list Realization as a type of relationship, but they do not
provide a detailed definition or a direct comparison to generalization. In broader
UML contexts, realization typically defines that one classifier (e.g., a class) fulfills
the contract specified by another classifier (e.g., an interface).
● What is the difference between aggregation and composition relationships in
UML? The provided sources mention "Part-of' hierarchy (Aggregation)" as a way to
deal with complexity, illustrating it with an example of a "Computer" being part of "I/O
Devices, CPU, Memory". However, the sources do not explicitly define composition
or differentiate it from aggregation. In general UML, both are types of association
representing a "whole-part" relationship, with composition being a stronger form where
parts cannot exist independently of the whole.
● There are three different types of objects? What are they? The provided sources do
not explicitly name "three different types of objects" as specific categories with icons, but
they do discuss different conceptual groupings. For instance, Application Domain
Objects and Solution Domain Objects are used to construct the system model during
analysis and design. The course also mentions OOSE (Object-Oriented Software
Engineering), which commonly classifies objects in an analysis model into Boundary
objects, Control objects, and Entity objects. The study guide's subsequent question
regarding "stereotypes" and "icons for the three types of objects" strongly implies these
OOSE types. However, the provided sources do not visually or textually define these
specific types or their icons.
● What is stereotype? What are the icons for the three types of objects? The
provided sources do not define "stereotype" or show specific icons for the "three types
of objects" (Boundary, Control, Entity). UML conventions described in the sources show
that nodes are drawn as rectangles or ovals, rectangles denote classes or instances,
and ovals denote functions. Class names are not underlined, while instance names are
underlined.
● What is the motivation for classifying objects into three types? While the provided
sources do not explicitly state the motivation for classifying objects into the specific
"three types" (Boundary, Control, Entity), the general motivations for object modeling and
classification are to:
○ Deal with complexity by breaking down systems into manageable "chunks" or
classes.
○ Understand the structure of the system (Object model).
○ Bridge the gap between the application domain and the solution domain by
identifying relevant abstractions in both for constructing the system model.
Different types of objects help organize and clarify responsibilities within the
system's architecture.
● Illustrate the types of relationships that can be defined between classes. Several
types of relationships can be defined between classes in UML:
○ Association: This is a general relationship between two classes that describes a
set of links between their instances. It can have multiplicity, indicating how many
instances of one class relate to instances of another.
○ Aggregation: A specific type of association representing a "part-of" hierarchy,
where one class is composed of other classes. For example, a "Computer" is
composed of "I/O Devices, CPU, Memory".
○ Generalization (Inheritance): This represents an "is-kind-of" hierarchy or
taxonomy, where a subclass inherits characteristics from a superclass. For
example, a "Muscle Cell" is a kind of "Cell".
○ Realization: (Mentioned in the study guide, but not detailed in the sources).
○ Dependency: (Mentioned in the study guide, but not detailed in the sources).
● What are the two variants for association? The study guide itself indicates
Aggregation and Composition as the two variants for association. The provided
sources define "Aggregation" as a "Part-of" hierarchy but do not explicitly define or
differentiate "Composition."
True/False Questions
● A sequence diagram is a type of object modeling. False. Sequence diagrams are a
type of dynamic model, describing the behavior of a system over time, specifically the
dynamic behavior between objects. The object model, by contrast, describes the static
structure of the system, primarily using class diagrams.
● Adding more developers to the team always results in better productivity. False.
Adding more developers can lead to "increasing complexity with larger teams" due to the
exponential rise in communication overhead, represented by the formula n(n-1)/2 for
communication channels. In large system development, significant time is spent
communicating rather than coding, which can hinder productivity.
Questions and Answers on Project Estimation
● Question: What is project management, and what are the three key trade-offs that a
project manager must manage?
○ Answer: Project management is defined as the process of planning and
controlling the development of a system within a specified time frame, at a
minimum cost, and with the right functionality. The three key trade-offs that
project managers must manage are:
■ The size of the system (what it does).
■ The time to complete the project (when the project will be finished).
■ The cost of the project.
● Question: What is generally considered a good range for estimation error in project
management?
○ Answer: An estimation error of 10 to 20% is usually considered good in project
management.
● Question: Describe one of the basic estimation methods based on industry standards.
○ Answer: One basic estimation method relies on typical industry standards for
business applications, which allocate specific percentages of effort to different
phases of the Systems Development Life Cycle (SDLC). For example, Planning
might consume 15% of the effort, Analysis 20%, Design 35%, and
Implementation 30%. This approach allows for estimating the effort for later
stages once actual figures for the initial SDLC phases are known.
● Question: What is the Lines of Code (LOC) method for project estimation, and what
are its main controversies?
○ Answer: The Lines of Code (LOC) method estimates project effort based on the
fully designed, implemented, debugged, and documented source code.
However, it is controversial because it is program language-dependent
(meaning the number of LOC can vary significantly for the same functionality
depending on the programming language used) and quality-dependent (a
well-designed, shorter program might be more effective than a longer, less
optimized one, but the LOC metric wouldn't reflect this quality difference).
● Question: What is COCOMO, and what are the three classes of software projects it
applies to?
○ Answer: COCOMO stands for Constructive Cost Model, and it is an empirical
estimation model developed by B. Boehm. It uses statistical techniques to
create formulas that relate easily measurable software characteristics to desired
software estimates. COCOMO applies to three main classes of software projects:
■ Organic: These are relatively small and simple projects, typically handled
by small teams with good experience, and they tend to have relatively
flexible requirements.
■ Semi-detached: These projects are intermediate in terms of size and
complexity, often involve teams with mixed experience levels, and have a
blend of rigid and flexible requirements.
■ Embedded: These projects are developed within a set of "tight"
constraints, such as specific hardware, software, or operational
limitations.
● Question: Can you provide the basic COCOMO formulas for calculating effort,
development time, and the number of people required for a software project?
○ Answer: The basic COCOMO model uses the following formulas to estimate
project parameters:
■ Effort (in person-months) = a × KLOC^b. (KLOC refers to thousands of
lines of code)
■ Development Time (in months) = c × Effort^d.
■ People required (count) = Effort / Development Time.
○ The specific values for constants 'a', 'b', 'c', and 'd' in these formulas vary
● What are requirements elicitation? Requirements elicitation is the definition of the
system in terms understood by the customer. It is the first step in identifying the
requirements for a system.
● What is the difference between requirements elicitation and analysis?
Requirements elicitation focuses on the definition of the system in terms
understood by the customer (often called the "requirements specification"). Analysis,
on the other hand, involves the definition of the system in terms understood by the
developer (leading to a "technical specification" or "analysis model"). Both activities are
part of the broader requirements process and focus on the user's view of the system.
● Explain what a functional requirement is. Functional requirements describe the
interactions between the system and its environment, independent of the
implementation. They define what a system is supposed to do. These are typically
phrased as actions, such as "An operator must be able to define a new game,"
"Advertise a new league," or "Schedule tournament". Functional requirements describe
user tasks that the system needs to support. Use cases are a representation of
functional requirements.
● Explain what a nonfunctional requirement is. What are the primary types of
nonfunctional requirements? Nonfunctional requirements describe aspects not
directly related to the functional behavior of the system. They define how a system
is supposed to be, often phrased as constraints or negative assertions, such as "The
response time must be less than 1 second".
The primary types of nonfunctional requirements include:
○ Quality requirements:
■ Usability: The ease with which actors can use a system to perform a
function. It must be measurable, for example, by specifying the number of
steps to perform a task.
■ Reliability: The ability of a system to maintain a function, even with
wrong input or environmental changes. This includes robustness and
safety.
■ Performance: Relates to speed, throughput, response time, scalability,
and availability. For example, "The system must support 10 parallel
tournaments".
■ Supportability: Includes adaptability and maintainability. For example,
the ability to add new games without modifying the existing system.
○ Constraints (or "Pseudo requirements"): These are imposed by the client or
the environment, such as "The implementation language must be Java". Other
constraints can relate to implementation, interface, operation, packaging, and
legal aspects (licensing, certification, regulation).
● Do use cases represent functional requirements or non-functional requirements?
Use cases represent functional requirements. They describe the functional behavior
of the system as seen by the user. A use case is an abstraction that describes a class of
scenarios, detailing interactions between an actor and the system.
