Unit 5 - Practice Quiz

The core responsibility of project management is to balance the constraints of time (schedule), cost (budget), and scope (features/quality) to achieve the project's goals successfully.

The Iron Triangle, or Triple Constraint, illustrates the fundamental trade-offs in project management: Scope (what the project will deliver), Time (the schedule), and Cost (the budget). Changing one affects the others.

A milestone represents a major achievement or a key decision point in a project. It has zero duration and is used to mark progress, such as 'Design Phase Completed' or 'User Acceptance Testing Started'.

A Gantt chart is a popular project management tool that displays tasks as horizontal bars along a timeline, showing their start dates, end dates, and durations, which helps in planning and tracking project progress.

SCM is the discipline of managing the evolution of software systems. Its main goal is to control changes, maintain integrity, and provide traceability for all project artifacts (code, documentation, etc.) throughout the development lifecycle.

A Version Control System, such as Git or SVN, is a fundamental tool of SCM that tracks revisions, allows for collaboration, and enables teams to revert to previous states of their work.

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed by Barry Boehm, which uses formulas based on project size (like lines of code) to predict effort and duration.

CI stands for Continuous Integration, the practice of automating the integration of code changes from multiple contributors into a single software project. It's a fundamental DevOps practice.

PERT is a project scheduling technique used to analyze the tasks involved in completing a given project, especially the time needed to complete each task, and to identify the minimum time needed to complete the total project.

Function Point analysis measures software size by quantifying the functionality provided to the user based on logical design and user requirements, rather than counting physical lines of code.

Project monitoring and control is a continuous process of observing project execution to identify potential problems in a timely manner and take corrective action when necessary.

By frequently merging code changes into a central repository and running automated builds and tests, CI helps teams detect integration issues as soon as they are introduced, making them easier and less costly to fix.

The critical path is the longest-duration path through a network diagram. Any delay in a task on this path will directly delay the entire project's completion date.

A baseline acts as a stable reference point in development. It's a snapshot of key project artifacts (e.g., requirements, code) that has been reviewed and approved and can only be changed through a formal change control process.

The Project Manager is the key individual responsible for leading the project team to achieve the project goals within the given constraints.

GitHub Actions workflows are configured using YAML syntax. These workflow files must be stored in the .github/workflows directory of your repository.

UCP is specifically designed to estimate project size and effort based on the number and complexity of use cases and actors, which are central artifacts in object-oriented analysis and design.

Git is a distributed VCS, meaning every developer has a full copy of the entire repository history. SVN, CVS, and VSS are examples of older, centralized version control systems.

The WBS is a key project deliverable that organizes the team's work into manageable sections. It is a hierarchical decomposition of the total scope of work to be carried out by the project team.

The Basic COCOMO model relies on an estimate of the program's size, typically measured in KLOC (Kilo Lines of Code) or DSI (Delivered Source Instructions), as its main driver for calculating development effort.

Slack (or float) is the amount of time a task can be delayed without affecting subsequent tasks or the overall project completion date. As long as the delay is within the task's available slack, the project's final deadline remains unchanged.

First, calculate the VAF: . Then, calculate the Adjusted Function Points (AFP) by multiplying the UFP by the VAF: . A VAF greater than 1.0 indicates the system is more complex than average.

This practice, known as Feature Branching, is a core concept in modern SCM. Its main purpose is to allow developers to work on new features or bug fixes in an isolated environment without affecting the stability and integrity of the main or release branch.

The needs: build directive ensures that the 'deploy' job waits for the 'build' job to complete successfully. The if: github.ref == 'refs/heads/main' condition adds a second requirement: the event that triggered the workflow must have occurred on the 'main' branch. Both conditions must be met.

The '90% syndrome' often occurs when tasks are too large and ill-defined. Progress is easy to report at the beginning, but the remaining 10% contains all the unforeseen complexities. Breaking work down into smaller, concrete, and measurable packages (a key principle of a Work Breakdown Structure) makes progress tracking more accurate and avoids this issue.

The PERT expected time is calculated using the formula . Plugging in the values: days. A wide range between the optimistic (3) and pessimistic (15) estimates is a clear indicator of high uncertainty and risk associated with the task.

COCOMO modes are based on the nature of the project and the team. 'Organic' projects involve small, experienced teams working on familiar problems. 'Semi-Detached' projects involve teams with a mix of experience levels, facing requirements that are less rigid than 'Embedded' systems but more complex than 'Organic' ones, thus leading to higher effort.

In a DVCS like Git, merging happens on the developer's local repository. The developer resolves conflicts and tests the result before sharing the changes. In a CVCS like SVN, a developer's commit can fail if their local copy is out of date. They must update, resolve conflicts, and then attempt the commit again. The conflict resolution is tied to the act of synchronizing with the central server.

According to the Iron Triangle, if one constraint (Scope) is changed, at least one other constraint (Time or Cost) must also be adjusted to maintain balance. Since Cost is fixed, the only remaining variable that can be logically adjusted to accommodate more work is Time. Decreasing quality is another possible outcome, but extending the timeline is the direct trade-off.

Continuous Integration (CI) is the practice of frequently merging all developer working copies to a shared mainline several times a day. Each merge triggers an automated build and test sequence. The goal is to detect integration errors as quickly as possible. It does not necessarily include automatic deployment to production, which is part of Continuous Deployment/Delivery.

Use Case Points are specifically designed for estimation based on use cases, which are common in object-oriented analysis and design. They are particularly useful early in the lifecycle when detailed functional decompositions (required for FPs) are not yet available, but the system's actors and their interactions (use cases) have been identified.

The WBS decomposes the total project scope into manageable work packages. Each work package can then have its own budget, schedule, and resource assignments. This hierarchical structure allows project managers to accurately track progress, measure performance (e.g., using Earned Value Management), and control costs and schedules at various levels of detail.

A baseline is a formally reviewed and agreed-upon version of a software configuration item (e.g., code, documentation, design). It serves as a fixed reference point for all subsequent changes. Any changes after a baseline is established must go through a formal change control process, ensuring stability and traceability.

In project management and Gantt charts, a milestone is a specific point in time that marks the completion of a major phase, deliverable, or decision. It is represented as a diamond or a single point on the timeline because it has no duration itself; it is a marker of progress.

Cost drivers are multipliers that adjust the nominal effort. A requirement for 'High' reliability (RELY) means more rigorous testing, fault tolerance, and verification activities are needed. This increases the complexity and work required, so the effort multiplier for this driver will be greater than 1.0, thus increasing the final estimated effort.

This scenario involves identifying a potential problem (deprecated technology, skill gap), analyzing its impact, and planning a response (training, contingency plan). This entire process—from identification to response planning—is the core of project Risk Management.

Both practices ensure that software can be released at any time. The key differentiator is the final step. In Continuous Delivery, the release to production is a manual, business decision. In Continuous Deployment, the process is fully automated, and every change that passes all automated tests is deployed to production automatically.

Velocity is an indicator of a team's past performance, used for future planning, not a target to be manipulated. Forcing a team to increase velocity often results in perverse incentives, such as cutting corners on testing (reducing quality) or 'gaming the system' by assigning more points to tasks without an actual increase in work delivered (story point inflation).

To find the critical path, we calculate the duration of all possible paths from start to finish:

• Path 1: A -> B -> D = 5 + 3 + 6 = 14 days.
• Path 2: A -> C -> E = 5 + 4 + 2 = 11 days.
  The critical path is the longest path, as it determines the minimum time to complete the project. Therefore, A -> B -> D is the critical path with a duration of 14 days.

A key principle of version control is the 'atomic commit'. All changes related to a single logical unit of work (like a bug fix or a new feature) should be grouped into a single commit or changeset. This makes the project history easier to understand, track, and revert if necessary.

This requires a multi-step PERT calculation. First, calculate the expected time () and the standard deviation ().

1. Expected Time: days.
2. Standard Deviation: days.
3. Now, calculate the Z-score for the target completion time of 10 days: .
4. Using a standard Z-table, a Z-score of -1.0 corresponds to a cumulative probability of approximately 0.1587 or 15.87%. The closest answer is 18.7%, which might reflect slight variations in distribution assumptions or rounding, but it's the only one in the correct ballpark. The core analysis shows the probability is significantly less than 50%.

The analysis requires understanding the multiplicative nature of the Effort Adjustment Factor (EAF). The EAF is the product of all 15 cost drivers. Here, EAF = 0.71 (ACAP) 1.21 (VEXP) (1.00)^13 = 0.8591. The adjusted effort is Person-Months. This is a significant reduction from the initial estimate of 533 PM. The key insight is that cost drivers are multiplicative, not additive. A driver like ACAP with a value of 0.71 provides a 29% reduction, while VEXP with a value of 1.21 adds a 21% penalty. The reduction is stronger than the penalty, leading to an overall significant decrease in the estimated effort.

Gitflow is specifically designed for projects with scheduled releases. The long-running develop branch allows for integration without destabilizing main (production). Team A can work on its long-running feature/X branch for months, merging into develop when ready. Team B can use short-lived feature branches or hotfix branches for their work. The release branch provides a dedicated place to stabilize the quarterly release without blocking new development from being merged into develop. Trunk-Based Development would be difficult with the long-running feature unless it's meticulously hidden behind feature toggles, which adds complexity. Direct commits to main or GitHub Flow are unsuitable for a project with a strict, non-continuous release cycle and long-running, potentially unstable features.

This question highlights a critical security vulnerability in GitHub Actions. The pull_request_target event is dangerous because, unlike pull_request, it runs the workflow defined in the base repository but checks out the code from the head of the pull request. If the workflow script itself is not what's being modified, but a build or test script called by the workflow is, that malicious code from the PR gets executed with the permissions and secret access of the base repository. Option C is incorrect because the workflow file is from the base, but the rest of the code, including scripts it might run, is from the PR. Option A is incorrect because pull_request_target is specifically designed to access secrets for tasks like labeling. Option D describes a feature (environment with protection rules) but is not the default behavior. The default behavior is dangerously permissive, leading to secret exfiltration.

This requires selecting the correct EAC formula based on the project's performance context. The key phrase is "current cost and schedule variances are expected to continue".
First, calculate the Cost Performance Index (CPI) and Schedule Performance Index (SPI).

• CPI = EV / AC = $60,000 / $80,000 = 0.75 (The project is over budget).
• SPI = EV / PV = $60,000 / $75,000 = 0.80 (The project is behind schedule).
  There are several formulas for EAC. Since the prompt states that current variances are typical for the rest of the project, the most appropriate formula is EAC = BAC / CPI.
• EAC = $200,000 / 0.75 = $266,666.67.
  This formula projects that the current rate of cost overrun (25% over budget for every unit of work) will persist until the end. Other formulas, like EAC = AC + (BAC - EV), assume future work will be done at the budgeted rate, which contradicts the problem statement.

This question requires detailed knowledge of the IFPUG complexity matrices.

1. For the ILF: It has 1 Record Element Type (RET) and 25 DETs. The complexity matrix for ILFs/EIFs is: Low (1-19 DETs), Average (20-50 DETs), High (>50 DETs). Since 25 DETs falls in the 20-50 range, the ILF is 'Average'.
   • For 0-1 FTR: Low (1-4 DETs), Average (5-15 DETs), High (>15 DETs).
   • For 2-3 FTRs: Low (1-4 DETs), Average (5-15 DETs), High (>15 DETs).
   • For >3 FTRs: Low (1-3 DETs), Average (4-12 DETs), High (>12 DETs).
   • First EI: 1 FTR, 3 DETs. This falls into the 'Low' category.
   • Second EI: 1 FTR, 10 DETs. This falls into the 'Average' category.
     Therefore, the correct classification is: EI-1 is Low, EI-2 is Average, and the ILF is Average.

To find the float of activity C, we must first identify the critical path.

• Path 1 duration: Duration(A) + Duration(C) + Duration(E) = 4 + 5 + 3 = 12 days.
• Path 2 duration: Duration(B) + Duration(D) = 6 + 7 = 13 days.
  The critical path is the longest path to the merge point, which is Path 2 (B->D) with a duration of 13 days. Activity F can only start on day 14 (after 13 full days have passed).
  Now, let's analyze Path 1. Its total duration is 12 days. This means it has 1 day of slack before it would delay the start of activity F. This 1 day of slack is shared among all activities on Path 1 (A, C, and E). Therefore, the total float for activity C is 1 day. It can be delayed by 1 day without affecting the project's overall completion time.

This question tests the nuances of GitHub Actions conditional execution. The default behavior is that a job only runs if all its dependencies (needs) succeed. Therefore, checking needs.test.result == 'success' or success() is redundant for the success path; the job won't even start if test fails. The primary challenge is to restrict the push to the main branch.

• Option A (success() && ...) is redundant.
• Option C (needs.test.result == 'success' && ...) is also redundant for the same reason.
• Option D (always() && ...) is incorrect because always() would cause the job to run even if the test job failed.
• Option B is the most robust and idiomatic way. It correctly specifies the dependency with needs: test. The if condition correctly checks that the trigger event was a push and that the branch name (ref_name) is main. The implicit success dependency from needs: test handles the test-passing requirement automatically.

Trunk-Based Development relies on frequent, small commits to the main branch (the trunk). To prevent this trunk from being constantly broken, there must be a strong safety net. The most critical part of this safety net is a robust automated testing suite (including unit, integration, and sometimes end-to-end tests) that is executed automatically on every commit or pull request before it is merged. This CI (Continuous Integration) practice ensures that changes don't break existing functionality. While code reviews (Option C) are important, they are not sufficient to catch all regressions and can become a bottleneck. Uniform IDEs (Option A) are a minor convenience, not a critical prerequisite. Adopting Gitflow (Option D) is the exact opposite of the proposed solution.

The key challenge in this project is the high technical risk and uncertainty related to the core algorithm, even though other parts of the project are stable. The Spiral model is uniquely suited for this. Each loop of the spiral involves identifying objectives, evaluating alternatives, identifying and resolving risks (e.g., building a prototype of the ML algorithm), and planning the next iteration. This allows the team to tackle the high-risk component through experimentation and prototyping before committing to a full-scale implementation. Waterfall is unsuitable due to the high uncertainty. While Scrum is iterative, it doesn't have the same explicit, formal risk-assessment phase in each cycle as the Spiral model. The V-Model is a variation of Waterfall and shares its rigidity in the face of uncertainty.

This question tests the subtle rules for weighting actors in UCP. Actor complexity is not just about being human vs. system. It's about the interaction protocol.

• A 'Simple' actor (weight 1) is another system with a defined API, like a REST service. The Logging Service fits this perfectly.
• An 'Average' actor (weight 2) is another system that interacts through a protocol like TCP/IP or a database.
• A 'Complex' actor (weight 3) is a human interacting through a GUI or a system with a complex, message-based protocol. The API Gateway, being a complex message-based system, correctly fits the 'Complex' category. Therefore, weighting the API Gateway as complex and the Logging Service as simple is the most accurate application of the UCP rules.

This question assesses the understanding of data persistence and sharing between jobs in GitHub Actions. Jobs run on separate, clean virtual machine instances and cannot access each other's filesystems directly (ruling out Option C). The intended mechanism for sharing data between jobs within the same workflow run is artifacts. The build job uploads the artifact once. Both the test and deploy jobs can then download and use this same artifact. This 'build once, use many times' pattern is highly efficient. Regenerating the binary (Option B) is wasteful of compute time and resources. While using external storage like S3 (Option D) is a valid pattern for sharing artifacts between different workflow runs or projects, it adds unnecessary complexity and latency for sharing data within a single workflow run compared to the built-in artifact mechanism.

This question differentiates between related but distinct project management concepts. 'Scope creep' (Option B) is the uncontrolled expansion of project scope without adjustments to time, cost, and resources. Since the change was formally approved and the plan was updated, it's not scope creep. 'Gold plating' (Option C) is when the team adds extra features that were not requested by the client, which is not the case here. 'Re-planning' (Option A) is a general term, but 'Re-baselining' (Option D) is the specific, correct term for formally updating the project's performance measurement baseline (the original scope, schedule, and cost plan) to reflect an approved major change. After re-baselining, EVM metrics will be calculated against this new baseline.

While basic Gantt charts are excellent for visualizing schedules and dependencies (Task A must finish before Task B), they do not, by default, track resource allocation. The chart might show that four tasks can happen in parallel from a dependency standpoint, but it doesn't know that there are only three resources (developers) available to perform them. This leads to an unrealistic plan. Advanced project management tools can perform 'resource leveling' which adjusts the schedule shown on the Gantt chart to respect resource constraints, but this is an additional feature layered on top. The fundamental limitation of the chart itself is its lack of inherent resource management. Option A is true, but not what the scenario highlights. Option B is a common feature (progress bars). Option D is also a limitation, but not the one illustrated by the developer shortage scenario.

This question requires a comparative analysis of the two methods' applicability. Function Point analysis requires identifying and classifying data functions (Internal Logical Files, External Interface Files) and transactional functions (External Inputs, External Outputs, External Inquiries). This requires a relatively detailed understanding of the system's data model. In the early stages described, this information is not available. Use Case Points, however, are derived from use cases and actors, which represent user interactions and system boundaries. This information is available. Therefore, UCP is much better suited for estimation early in the lifecycle when requirements are captured as use cases but before detailed design. Option A is incorrect (UCP is not based on COCOMO). Option C is an overgeneralization; FP's suitability depends on the available information. Option D is incorrect; UCP has both a Technical Complexity Factor (TCF) and an Environmental Complexity Factor (ECF).

This question tests the precise definition of a key SCM term. A 'baseline' is a formally agreed-upon version of a configuration item (e.g., requirements document, code version) that serves as a reference point for further development. 'Baseline drift' specifically refers to the erosion of this reference point through a series of small, unapproved, or poorly documented changes. The primary cause is the failure to adhere to the formal change control process, where changes are proposed, reviewed, approved, and then incorporated to create a new baseline. Option B describes branch divergence, a related but different problem. Option A is about code quality, not configuration control. Option D describes a formal change request, which, if handled correctly, leads to re-baselining, not drift.

This is a common and subtle issue in GitHub Actions. When you have on: [push, pull_request], a commit pushed to a branch with an open PR triggers two events: the push event to the branch itself, and the pull_request synchronize event. This results in two workflow runs. The goal is typically to run tests for every PR commit, and also for every commit that lands on main.
Option D provides the most idiomatic and effective solution: it configures the workflow to run for pushes only to the main branch, and for any updates to pull requests that target the main branch. This eliminates the duplicate run on feature branches while maintaining CI coverage for both pre-merge and post-merge scenarios. Option B's complex if condition is a less clean way to achieve this and can have unintended side effects. Option C misdiagnoses the problem. Option A is incorrect; this is documented behavior.

This question requires a deep interpretation of EVM metrics, not just a superficial definition.

• SPI = EV / PV = 1.2. Since SPI > 1, it means Earned Value (EV) is greater than Planned Value (PV). The team has completed more work than was scheduled to be done by this point. The project is ahead of schedule.
• CPI = EV / AC = 0.8. Since CPI < 1, it means Earned Value (EV) is less than Actual Cost (AC). The project is spending more money than the value of the work it has accomplished. The project is over budget.
  Combining these two insights: the team is working faster than planned, but at a very high cost. This pattern is a classic indicator of 'crashing' the schedule—adding extra resources (e.g., overtime, more staff) to accelerate work, which gets the project ahead of schedule but at a cost premium. Option B captures this complex dynamic perfectly. Option A is wrong on budget. Option C is wrong on schedule.

This question tests the ability to correctly decompose a user interface into its fundamental transactional functions according to IFPUG rules. The key is that a transactional function is the smallest unit of activity that is meaningful to the user and leaves the business in a consistent state.

1. Viewing Data: The user initiates a request to see their profile. The system retrieves data from two different files (ILF and EIF) and presents it. This entire 'read' operation, even with multiple data sources, is typically counted as a single External Inquiry (EQ) because it's a single, user-initiated request for information. An EO requires derived data, which isn't specified here, making EQ the better fit for a direct retrieval and presentation.
2. Updating Data: The user's action of saving changes is a distinct business process that modifies an ILF. This is a classic External Input (EI).
   Therefore, the screen comprises two distinct transactional functions: one EQ for the initial data load/view, and one EI for the update action. Option C is a common mistake; EO is for derived data/reports, whereas EQ is for direct queries, which is more applicable here.

This question requires knowledge of the specific risk response strategies for positive risks (opportunities).

• Exploit is the most aggressive strategy, seeking to make the opportunity definitely happen. This is too risky as the project would be completely dependent on an external event it doesn't control.
• Mitigate is a strategy for negative risks (threats), not opportunities.
• Accept is a passive strategy. While valid, it's not the most appropriate proactive strategy.
• Enhance is the correct strategy here. It involves taking proactive steps to increase the probability and/or impact of the opportunity. By allocating a small amount of time for R&D and prototyping, the team isn't fully dependent on the library but is perfectly positioned to integrate it quickly and effectively if it becomes available, thus maximizing (enhancing) the potential benefit (reduced development time).