UNIT 2: SOFTWARE PROJECT MANAGEMENT & PROCESS ENGINEERING

1. SOFTWARE ECONOMICS

Concept: Study of financial and resource aspects of software development—costs, benefits, value, and economic decision-making throughout the project lifecycle.

Evolution Over Time:

Strategies for Enhancing Software Economics:

• Reuse: Leveraging existing components, code libraries, or patterns.

• COTS (Commercial Off-The-Shelf): Buying vs. building.

• Platform-Based Development: Building on established frameworks (e.g., .NET, Spring).

• Outsourcing/Offshoring: Strategic use of global talent pools.

• Agile & Iterative Methods: Reducing waste, delivering value incrementally.

• Automation: CI/CD, automated testing to reduce manual effort.

Important Trends:

• Shift from cost-centric to value-centric economics.

• Rise of subscription-based (SaaS) and pay-per-use models.

• Total Cost of Ownership (TCO) consideration beyond initial development.

• Technical Debt management as an economic factor.

Project Assessment Criteria:

Cost Estimating & Budgeting Improvement:

• Methods: Expert judgment, analogous estimating, parametric models (e.g., COCOMO), bottom-up estimating.

• Improvement: Use historical data, calibrate models, incorporate risk buffers, adopt rolling-wave planning.

[!TIP] Exam questions often ask for evolution and strategies. Structure answers chronologically for evolution and use bullet points for strategies.

2. MODERN SOFTWARE MANAGEMENT PRINCIPLES

Guiding Principles:

1. Value-Driven Delivery: Prioritize features delivering highest business value.

2. Iterative & Incremental Development: Break work into small, manageable increments.

3. Empowered, Self-Organizing Teams: Trust teams to decide "how."

4. Continuous Feedback & Adaptation: Regular inspection and adaptation.

5. Holistic View: Consider people, process, technology, and business together.

6. Risk-Driven Approach: Proactively identify and mitigate risks.

Conventional vs. Modern:

Role of Multidisciplinary Teams:

• Bring diverse skills (dev, QA, UX, ops, business) into one team.

• Reduces handoffs and communication delays.

• Enables faster, more informed decision-making at the team level.

• Fosters shared understanding of project goals and constraints.

3. SOFTWARE LIFECYCLE & PHASES (RUP/Iterative Model)

General Phases (with examples):

1. Inception: Example: Define vision, identify key stakeholders, draft business case for a new e-commerce platform.

2. Elaboration: Example: Plan architecture, resolve key technical risks (e.g., payment gateway integration), create baseline plan.

3. Construction: Example: Develop all features, conduct unit/integration testing, prepare for deployment.

4. Transition: Example: Beta release to users, training, bug fixing, final deployment to production.

Detailed Goals & Expectations:

Lifecycle Expectations & Rationale for Adaptation:

• Expectation: Each phase has specific, non-overlapping goals and exit criteria.

• Rationale for Adaptation: Real-world environments are dynamic. Requirements evolve, technologies change, market pressures shift. A rigid lifecycle leads to irrelevant products. Adaptation (e.g., through iterations within phases) manages uncertainty and ensures the final system remains useful.

Why Systems Must Change or Become Less Useful:

• Evolving Business Needs: Market conditions, regulations, and organizational strategies change.

• Technological Obsolescence: Underlying platforms, libraries, or hardware become outdated.

• Uncovered Defects & New Requirements: Post-deployment bugs and user requests accumulate.

• Technical Debt: Short-term compromises degrade maintainability over time.

Result: Without active maintenance and evolution, the system's effectiveness and value diminish.

4. SOFTWARE DEVELOPMENT PROCESS ELEMENTS

Workflow Stages (Process Flow):

1. Communication: Stakeholder interaction, requirements gathering.

2. Planning: Estimating, scheduling, risk analysis, creating project plan.

3. Modeling: Analysis & design (UML diagrams, data models).

4. Construction: Coding, unit testing, integration.

5. Deployment: Delivery to user, installation, training.

6. Operation & Maintenance: Support, bug fixing, enhancements.

Process Checkpoints (Milestones/Reviews):

• Purpose: Assess progress, quality, and alignment; decide on continuation.

• Key Reviews:

  • Inception Review: Is the project worth doing?

  • Elaboration Review: Is the architecture sound and risks manageable?

  • Construction Review: Is the software ready for transition?

  • Post-Mortem: Lessons learned after project completion.

Task Set in Software Engineering:

• Definition: A collection of tasks (work activities) required to accomplish a specific process framework for a project.

• Selection Steps:

  1. Identify Process Framework: Choose lifecycle model (e.g., Agile, Waterfall).

  2. Assess Project Characteristics: Size, complexity, criticality, team experience.

  3. Tailor the Framework: Adapt the generic process by including/excluding specific tasks from a task set library.

  4. Define Entry/Exit Criteria: For each task, specify what must be true to start/complete it.

Process Discriminants (Differentiating Factors):

• Process Scope & Granularity: How detailed is the process definition?

• Level of Rigor: Prescriptive vs. flexible.

• Degree of Automation: Manual vs. tool-supported.

• Primary Focus: Documentation, quality, speed, innovation?

• Stakeholder Involvement: Customer collaboration level.

Iterative Process Planning Approach:

• Concept: Plan the project in waves/iterations, not a single upfront plan. Each iteration delivers a subset of functionality.

• Steps:

  1. Define overall project vision & high-level requirements.

  2. Identify core, high-risk features for the first iteration.

  3. Plan iteration 1 in detail (tasks, resources, duration).

  4. Execute iteration 1, review results, adapt plan.

  5. Plan next iteration based on feedback and revised priorities.

• Example: In a mobile app project, Iteration 1 delivers user login & core dashboard (highest risk/value). Iteration 2 adds search functionality, etc.

5. ARTIFACTS IN SOFTWARE DEVELOPMENT

Definition: Tangible by-products, outputs, or documents produced during the software process.

Management Artifacts vs. Engineering Artifacts:

Pragmatics Artifacts:

• Artifacts that describe the operational context and deployment environment of the system.

• Examples: Hardware specifications, network diagrams, deployment scripts, user training materials, support procedures.

• Significance: Bridge the gap between the engineered system and its real-world operational use, ensuring the system is deployable, usable, and maintainable.

Role & Significance:

• Communication: Shared understanding among stakeholders.

• Planning & Estimation: Basis for effort/cost prediction.

• Control: Metrics for tracking progress and quality.

• Knowledge Transfer: Documentation for new team members or future maintenance.

• Legal/Contractual: Evidence of compliance, agreements (e.g., SRS).

6. SOFTWARE ARCHITECTURE & DESIGN

Model-Based Software Architecture:

• Concept: Representing the system's high-level structure, components, and their interactions using formal models (e.g., UML diagrams, architecture description languages).

• Explanation: Instead of textual descriptions, use standardized graphical or textual models (component diagrams, deployment diagrams, package diagrams) to define:

  • Key components and their responsibilities.

  • Connectors and communication protocols.

  • Configuration and topology.

  • Non-functional property mappings (performance, security).

• Benefit: Enables analysis, simulation, and clear communication before implementation.

Design Strategies:

Modular Design:

• Purpose: Decompose a system into discrete, manageable, and replaceable modules (components) with high cohesion and low coupling.

• Cohesion (Within a module): Degree to which elements of a module belong together.

  • High (Good): Functional cohesion (single, well-defined task).

  • Low (Bad): Coincidental cohesion (unrelated elements).

• Coupling (Between modules): Degree of interdependence between modules.

  • Low (Good): Data coupling (modules share data via parameters).

  • High (Bad): Content coupling (one module modifies another's internal data).

Programming Practices & Coding Standards:

• Importance: Directly impacts maintainability, readability, defect rates, and team productivity.

• Impact:

  • Reduces Complexity: Consistent naming, formatting.

  • Facilitates Debugging & Review: Predictable code structure.

  • Enables Collaboration: New developers understand code faster.

  • Improves Quality: Standards often include best practices for error handling, security.

  • Automation: Enables use of static analysis tools (linters, formatters).

7. PROJECT ORGANIZATION & TEAM MANAGEMENT

Structure & Roles:

• Functional Organization: Team members grouped by specialty (dev, QA). Project manager has limited authority.

• Projectized Organization: Team dedicated to project, project manager has full authority.

• Matrix Organization: Blend of both; individuals report to both functional and project managers.

• Key Roles:

  • Project Manager: Overall responsibility for planning, execution, control.

  • Team Lead/Senior Developer: Technical leadership, task coordination.

  • Stakeholders: Customers, sponsors, end-users.

  • Configuration Manager: Manages baselines and versions.

Responsibilities:

• Project Manager: Scope, time, cost, quality, risk, communication, stakeholder management.

• Team Members: Task completion, quality work, estimation, reporting.

• Sponsor: Provides funding, resources, champions project.

Software Management Team (Composition & Functions):

• Composition: Typically includes Project Manager, Lead Architect, Lead Developer, QA Lead, Configuration Manager, sometimes a Business Analyst.

• Functions:

  • Planning: Define approach, schedule, resources.

  • Monitoring & Control: Track progress against plan, manage changes.

  • Problem Solving: Remove impediments, resolve conflicts.

  • Communication: Liaison between stakeholders and technical team.

  • Quality Assurance: Ensure processes and standards are followed.

Organizing Stakeholders for Effective SE:

• Identify All Stakeholders: Users, customers, sponsors, developers, testers, ops, legal, etc.

• Analyze Interests & Influence: Power/Interest grid.

• Define Clear Roles & Responsibilities: Use RACI matrix (Responsible, Accountable, Consulted, Informed).

• Establish Communication Channels: Regular meetings, reports, collaboration tools.

• Create Shared Vision & Goals: Align all parties on project objectives.

8. PROCESS AUTOMATION & IMPROVEMENT

Process Automation:

• Definition: Use of software tools to execute, enforce, and monitor software development processes with minimal manual intervention.

• Structure: Typically a toolchain (e.g., Jira for tracking, Git for version control, Jenkins for CI/CD, SonarQube for quality).

• How it Works: Tools are configured to trigger actions based on events (e.g., code commit -> automated build -> automated test -> report).

Four Stages of Process Automation:

1. Manual: All steps performed by humans.

2. Automated Execution: Tools perform repetitive tasks (build, test).

3. Automated Enforcement: Tools enforce process rules (e.g., mandatory code review before merge).

4. Automated Management & Optimization: Tools analyze process data to suggest improvements (predictive analytics).

Need & Benefits (including Software Economics):

• Need: Reduce human error, accelerate feedback, ensure consistency, handle scale.

• Benefits:

  • Faster Delivery: CI/CD reduces cycle time.

  • Higher Quality: Automated testing catches regressions early.

  • Reduced Cost: Less manual effort, fewer defects in production.

  • Improved Economics: Shorter time-to-market, lower rework cost, better resource utilization.

  • Traceability & Compliance: Automated audit trails.

Examples:

• CI/CD Pipelines: Jenkins, GitLab CI, GitHub Actions.

• Automated Testing: Selenium, JUnit, pytest.

• Static Code Analysis: SonarQube, Checkstyle, ESLint.

• Infrastructure as Code (IaC): Terraform, Ansible.

• Automated Deployment: Kubernetes, Docker Swarm.

Improving Software Processes:

• Strategies:

  • Process Assessment: Use models like CMMI, ISO 15504 (SPICE) to identify gaps.

  • Tailoring: Adapt generic processes to project needs.

  • Piloting: Test changes on a small project/team first.

  • Training: Ensure team understands new processes.

  • Metrics & Feedback: Measure effectiveness (e.g., cycle time, defect density) and adjust.

  • Automation: As above, to enforce and streamline.

9. PROJECT CONTROL & RISK MANAGEMENT

Project Control Process (Four Steps & Instrumentation):

1. Plan: Establish baseline (scope, schedule, cost, quality).

2. Monitor: Collect performance data (e.g., % complete, actual cost, defect count).

3. Compare: Analyze variances (EV - PV, AC - EV) using Earned Value Management (EVM).

4. Correct: Take corrective or preventive actions (re-plan, re-allocate resources).

Instrumentation: Tools & techniques for monitoring (e.g., Gantt charts, burn-down charts, EVM metrics, issue trackers).

Success Factors in Project Control Systems:

• Clear, measurable objectives and baselines.

• Timely, accurate data collection.

• Regular, structured review meetings.

• Empowered project manager with authority to act.

• Transparent communication of status to stakeholders.

Problems in Project Control:

• Unrealistic baselines ("planning fallacy").

• Poor data quality or late reporting.

• Gold-plating (uncontrolled scope creep).

• Resistance to reporting bad news.

• Inadequate risk management.

Risk Identification, Monitoring & Management:

1. Identification: Brainstorming, checklists, SWOT analysis, expert judgment.

2. Analysis (Qualitative/Quantitative): Assess probability & impact; prioritize (Risk Matrix).

3. Planning: Strategies: Avoid, Mitigate, Transfer, Accept.

4. Monitoring: Track identified risks, identify new ones, review trigger conditions.

Warning Signs of Project Jeopardy & Corrective Actions:

10. SOFTWARE CONFIGURATION & MAINTENANCE

Software Configuration Management (SCM):

• Process: The management of changes to software artifacts (code, docs, models) throughout their lifecycle.

• Key Activities:

  1. Configuration Identification: What items are under control? (e.g., all source files, SRS).

  2. Configuration Control: Managing changes (change requests, approvals, versioning).

  3. Configuration Status Accounting: Recording and reporting status of changes.

  4. Configuration Audits: Verify integrity of baselines (formal audits, functional audits).

• Necessity: Without SCM, chaos ensues—lost versions, incompatible builds, inability to reproduce bugs, team conflicts. It provides traceability, reproducibility, and integrity.

Software Maintenance:

• Definition: Modification of a software product after delivery to correct faults, improve performance, or adapt to a changed environment.

• Types/Categories:

  1. Corrective Maintenance: Fixing defects/bugs.

  2. Adaptive Maintenance: Adapting to environment changes (OS, hardware, regulations).

  3. Perfective Maintenance: Enhancing functionality, performance, or maintainability (non-defect related).

  4. Preventive Maintenance: Proactively preventing future problems (code refactoring, updating documentation).

11. PROCESS MEASUREMENT & METRICS

Process Measurement Tools & Techniques:

• Metrics Collection: Automated (CI/CD tools, APM) vs. manual (timesheets, surveys).

• Data Analysis: Statistical process control, trend analysis, root cause analysis.

• Visualization: Dashboards, burn-up/down charts, control charts.

• Benchmarking: Comparing metrics against industry standards or past projects.

Key Management Indicators (KMIs) / Management Indicators:

• Schedule: Schedule Variance (SV), Schedule Performance Index (SPI).

• Cost: Cost Variance (CV), Cost Performance Index (CPI).

• Scope: Requirements volatility, scope change requests.

• Quality: Defect density, defect removal efficiency, test coverage.

• Team: Staff turnover, morale index, velocity (Agile).

• Customer: Customer satisfaction (CSAT), net promoter score (NPS).

12. SUPPORTING TOPICS

Project Environment (Factors Influencing Projects):

• Organizational: Structure, culture, maturity, resource availability.

• Technical: Technology complexity, tooling, legacy systems.

• Market/Stakeholder: Customer involvement, competitor actions, regulatory landscape.

• Team: Skills, experience, geographical distribution.

Requirements Analysis & Specification:

• Activities: Elicitation (interviews, workshops), Analysis (modeling, prioritization), Specification (writing SRS), Validation (reviews, prototyping).

• Characteristics of a Good SRS:

  • Correct & Complete.

  • Unambiguous (each requirement has one interpretation).

  • Verifiable (can be tested).

  • Consistent (no conflicting requirements).

  • Modifiable (well-structured, traceable).

  • Traceable (forward to design/code, backward to stakeholder need).

Importance of Software Project Planning:

• Foundation for Control: Establishes baseline for measuring progress.

• Risk Reduction: Identifies risks early, plans responses.

• Resource Optimization: Ensures right people/skills are available when needed.

• Stakeholder Alignment: Creates shared understanding of scope, schedule, cost.

• Improves Communication: Clear plan communicates expectations to all.

• Increases Probability of Success: "Failing to plan is planning to fail."