Unit5 - Subjective Questions

Software Project Management is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored, and controlled.

The 4 P's of the management spectrum are:

1. People: The most important element. It includes recruiting, selecting, performance management, training, compensation, career development, organization, and work design for the software team.
2. Product: The software to be built. Before a project can be planned, product objectives and scope must be established, alternative technical solutions should be considered, and technical and management constraints should be identified.
3. Process: The framework of activities and tasks used to build the software. The project manager must select the appropriate process model (e.g., Agile, Waterfall) that fits the people and the product.
4. Project: The actual work required to produce the product. It involves planning, monitoring, and controlling the budget, schedule, and quality to ensure success.

COCOMO (Constructive Cost Model) is an algorithmic software cost estimation model developed by Barry Boehm. It uses a basic regression formula with parameters derived from historical project data and current project characteristics.

Three Modes of Basic COCOMO:

1. Organic Mode:

   • Small teams with good experience working with less rigid requirements.
   • Formula: and

2. Semi-Detached Mode:

   • Intermediate projects (mixed team experience, mixed requirements rigidity).
   • Formula: and

3. Embedded Mode:

   • Complex projects with tight constraints (hardware/software/operational) and large teams.
   • Formula: and

Where is Effort in Person-Months, is Development Time in Months, and is Kilo Lines of Code.

The differences between PERT and CPM are as follows:

Function Point (FP) Analysis is a method used to estimate the size of a software project based on the functionality provided to the user, rather than the lines of code. It is independent of the programming language used.

Five Information Domain Characteristics:

1. External Inputs (EIs): Data coming from outside the application boundary (e.g., login screen, input forms). They update internal logical files.
2. External Outputs (EOs): Data leaving the system boundary (e.g., reports, error messages). These are derived data.
3. External Inquiries (EQs): Input/output combinations where input results in an immediate output (e.g., search query). No internal file is updated.
4. Internal Logical Files (ILFs): Groups of logically related data residing entirely within the application boundary (e.g., database tables managed by the system).
5. External Interface Files (EIFs): Groups of logically related data residing external to the application but referenced by the application (e.g., data from another system).

Calculation:

Software Configuration Management (SCM) is a set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.

Primary SCM Activities:

1. Configuration Identification: Identifying items to be controlled (SCIs - Software Configuration Items) like code, documents, and test cases.
2. Version Control: Managing different versions of the software and ensuring the correct version is being used (e.g., using Git).
3. Change Control: The process of evaluating and approving/rejecting changes via a Change Control Board (CCB).
4. Configuration Status Accounting: Recording and reporting the status of components and change requests (e.g., "What changes were made to file X?").
5. Configuration Auditing: Ensuring that the SCM integrity is maintained and that the released software matches the documentation.

GitHub Actions is a CI/CD (Continuous Integration/Continuous Deployment) platform that allows developers to automate their build, test, and deployment pipeline directly within GitHub.

Key Components:

• Workflows: A configurable automated process that runs one or more jobs. Workflows are defined by a YAML file checked into the repository (usually in .github/workflows). A workflow is triggered by an event (like a push or pull_request).
• Jobs: A set of steps in a workflow that execute on the same runner (server). By default, a workflow with multiple jobs runs them in parallel. Dependencies can be set to run them sequentially.
• Steps: An individual task within a job. Steps can run commands (shell scripts) or setup actions (reusable extensions). Since steps in the same job run on the same runner, they can share data with each other.
• Runners: The server that runs the workflow (e.g., Ubuntu, Windows, or self-hosted).

Use Case Points (UCP) is a software estimation technique used to forecast the software size and effort based on Use Case diagrams. It is an extension of the Function Point method specifically for Object-Oriented systems.

Calculation Steps:

1. Unadjusted Use Case Weight (UUCW): Calculated by classifying use cases as Simple (1-3 transactions), Average (4-7 transactions), or Complex (>7 transactions).
2. Unadjusted Actor Weight (UAW): Calculated by classifying actors as Simple (API), Average (Protocol), or Complex (GUI).
3. Unadjusted Use Case Points (UUCP):
   
4. Technical Complexity Factor (TCF): Derived from 13 technical factors (e.g., performance, reusability).
5. Environmental Complexity Factor (ECF): Derived from 8 environmental factors (e.g., team motivation, experience).
6. Final UCP:
   

A Gantt Chart is a type of bar chart that illustrates a project schedule. It was invented by Henry Gantt. It maps tasks against time.

Structure:

• Vertical Axis: Lists the tasks or activities to be performed.
• Horizontal Axis: Represents the time scale (days, weeks, months).
• Bars: Horizontal bars represent the duration of each task. The position of the bar shows the start and end dates.

Usage in Project Monitoring:

1. Visualizing Schedule: It provides a clear visual timeline of when tasks start and finish.
2. Tracking Progress: By shading a portion of the bar, managers can show the percentage of work completed versus the planned duration.
3. Dependencies: Modern Gantt tools show dependencies (arrows connecting bars) to highlight how delays in one task affect others.
4. Resource Allocation: It helps in identifying overlapping tasks which might require resource leveling.

CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). It represents a culture and method to bridge the gap between development and operation activities by enforcing automation in building, testing, and deploying applications.

Components:

1. Continuous Integration (CI): Developers frequently merge their code changes into a central repository. Automated builds and tests are run to validate the code. This detects integration errors early.
2. Continuous Delivery: An extension of CI where code changes are automatically prepared for a release to production. The deployment to production is manual (click of a button).
3. Continuous Deployment: Every change that passes all stages of the production pipeline is released to customers automatically, with no human intervention.

Importance:

• Faster Time to Market: Automating the pipeline reduces manual overhead.
• Reduced Risk: Smaller, frequent updates make it easier to isolate and fix bugs.
• Improved Quality: Automated testing ensures regressions are caught immediately.

In PERT (Program Evaluation and Review Technique), we use a weighted average to calculate the expected duration and variance.

1. Expected Time ()

The formula is:

Substituting the values:

2. Standard Deviation ()

The formula is:

Substituting the values:

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

Structure:

• Level 1: The entire project.
• Level 2: Major phases or deliverables.
• Level 3+: Smaller components, breaking down until Work Packages (the lowest level) are reached.

Significance in Planning:

1. Scope Definition: It clearly defines what is in scope and what is out of scope (100% rule: WBS includes 100% of the work defined by the project scope).
2. Cost Estimation: Costs can be estimated more accurately for smaller work packages and aggregated upwards.
3. Scheduling: It forms the basis for defining activities, sequencing them, and assigning resources.
4. Responsibility Assignment: Tasks can be assigned to specific teams or individuals based on work packages.

In Software Configuration Management (SCM), a Baseline is a formally approved version of a software configuration item (SCI), regardless of media, at a specific time during the software life cycle.

Key Characteristics:

• Reference Point: It serves as a basis for further development. For example, once the Requirement Specification is approved, it becomes the "Requirements Baseline."
• Change Control: Once a baseline is established, it can only be changed through a formal Change Control procedure. Casual editing is not allowed.
• Milestone: Baselines usually correspond to major milestones (e.g., Release 1.0, Alpha, Beta).

Examples:

1. Functional Baseline: The approved requirements documentation.
2. Development Baseline: The code and design at the end of an iteration.
3. Product Baseline: The final software ready for delivery.

The Change Control Process ensures that changes to the software are introduced in a controlled and coordinated manner to prevent chaos. The typical steps are:

1. Change Request (CR): A user or developer identifies a defect or an enhancement and submits a formal Change Request.
2. Impact Analysis: The project team analyzes the request to determine the technical impact, cost, and schedule implications.
3. CCB Review: The Change Control Board (CCB) reviews the analysis. They can Approve, Reject, or Defer the change.
4. Implementation: If approved, the engineering team checks out the necessary configuration items, implements the change, and tests it.
5. Verification: QA verifies the fix/change.
6. Baseline Update: The changed items are checked back in, and a new baseline (or version) is created. The CR is closed.

Critical Path:
The Critical Path is the longest sequence of dependent activities in a project network diagram that must be completed on time for the project to finish by its deadline. It determines the shortest possible time to complete the project.

• If any activity on the critical path is delayed, the entire project is delayed.
• A project can have more than one critical path.

Slack Time (Float):
Slack time is the amount of time that a task can be delayed without causing a delay to subsequent tasks (Free Slack) or the project completion date (Total Slack).

• Relation: Activities on the Critical Path have Zero Slack (Float = 0). This means there is no room for error or delay in these tasks.

Comparison between LOC and FP:

GitHub CI/CD Workflows are defined in YAML (Yet Another Markup Language) files stored in the .github/workflows/ directory. The syntax relies on indentation to define structure.

Basic Structure:

1. name: The name of the workflow (e.g., Build and Test).

2. on: The trigger event.
   yaml
   on:
   push:
   branches: [ "main" ]

3. jobs: Defines the jobs to run.
   yaml
   jobs:
   build-job: # Job ID
   runs-on: ubuntu-latest
   steps:

   • uses: actions/checkout@v3 # Check out code
   • name: Run a script
     run: echo "Hello, World!"

Key elements include defining the runs-on environment (runner) and listing steps which can use pre-built actions (uses) or shell commands (run).

For an Organic project in Basic COCOMO, the formulas are:

• Effort () = (Person-Months)
• Development Time () = (Months)

Given: Size () = 32

1. Calculate Effort ():

2. Calculate Development Time ():

(Note: Values for exponents are standard COCOMO constants)

Risk Management involves identifying, analyzing, and responding to project risks to minimize the likelihood and impact of negative events.

Steps in Risk Management:

1. Risk Identification: Brainstorming potential risks (e.g., Technology risk, People risk, Requirement risk). Creating a Risk Item Checklist.
2. Risk Analysis (Projection): Assessing each risk based on:
   • Probability: How likely is it to happen?
   • Impact: How bad will it be if it happens?
3. Risk Prioritization: Ranking risks (usually Probability Impact).
4. Risk Planning (RMMM): Developing a Risk Mitigation, Monitoring, and Management plan.
   • Avoidance: Changing plans to stop the risk.
   • Mitigation: Reducing the impact.
   • Contingency: Having a backup plan if the risk occurs.
5. Risk Monitoring: Tracking identified risks throughout the project.

Advantages of Function Points (FP):

1. Language Independent: FP can be used to compare projects written in different languages (e.g., Java vs. C++).
2. Early Estimation: Can be calculated from the requirements specification or design, before any code exists.
3. User Focus: Measures the value delivered to the user (screens, reports) rather than technical bulk.

Disadvantages of Function Points:

1. Subjectivity: Counting Function Points involves judgment (e.g., rating complexity as Low, Average, High). Different estimators might produce different counts.
2. Complexity: Requires more training and effort to calculate compared to simply counting lines of code.
3. Not Direct: It is a proxy for effort; conversion to person-hours requires historical data (productivity rates).

Earned Value Analysis (EVA) is a quantitative technique used to measure project performance and progress. It combines measures of scope, schedule, and cost.

Key Terms:

1. Planned Value (PV): Also known as Budgeted Cost of Work Scheduled (BCWS). It is the authorized budget assigned to scheduled work.

   • "How much work should have been done by now?"

2. Earned Value (EV): Also known as Budgeted Cost of Work Performed (BCWP). It is the measure of work performed expressed in terms of the budget authorized for that work.

   • "How much work is actually done?"

3. Actual Cost (AC): Also known as Actual Cost of Work Performed (ACWP). It is the realized cost incurred for the work performed.

   • "How much did the work actually cost?"

By comparing these, we can calculate variances like Cost Variance () and Schedule Variance ().