Rural Technology & Community Development (CS-604) - Unit 5 Short Notes

1. Software Economics

Definition: Study of economic and financial aspects of software development, focusing on cost, value, productivity, and ROI.

Evolution of Software Economics

• Historical Shifts:

  • 1960s-70s: Hardware-centric. Software cost was a small fraction of total system cost; focus on hardware efficiency.

  • 1980s-90s: Software-centric. Software costs dominated (60-80% of total). Productivity became a key concern.

  • 2000s-Present: Value-centric. Emphasis on time-to-market, customer value, and total cost of ownership (TCO). Shift from cost estimation to value delivery.

• Changes in Cost Structures:

  • Early: High hardware costs, low software labor costs.

  • Modern: Low hardware costs (cloud/commodity), high skilled labor costs. Maintenance > development costs.

Strategies for Enhancing Software Economics

• Process Improvement: Adopt Agile/DevOps, CMMI, Lean to reduce waste and improve flow.

• Reuse: Leverage open-source components, libraries, and frameworks to avoid reinvention.

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

• Outsourcing/Offshoring: Access lower-cost skilled labor pools.

• Economic Metrics & ROI:

  • ROI = \(\frac{\text{Net Benefit}}{\text{Cost}} \times 100\)

  • NPV (Net Present Value), IRR (Internal Rate of Return) for project selection.

• Value-Based Delivery: Prioritize features by business value (e.g., MoSCoW method).

Important Trends

• Agile/DevOps: Shorter iterations, continuous delivery, faster feedback loops.

• Cloud Computing: OpEx model (pay-as-you-go) vs. CapEx; elastic scaling.

• Open-Source Leverage: Reduces licensing costs, accelerates development.

• Incremental Funding: Release in increments to generate early revenue and validate assumptions.

Project Assessment Criteria

1. Strategic Alignment: Does it support organizational goals?

2. Technical Viability: Feasibility with current tech stack, team skills.

3. Economic Impact Evaluation: Cost-benefit analysis, NPV, risk-adjusted ROI.

[!TIP] Exam Focus: Be ready to explain how each strategy (reuse, automation) improves economics—link to reduced effort, time, or increased quality.

2. Modern Software Management Principles

Core Principles

• Iterative Development: Build in small, usable increments; reduce risk via early feedback.

• Risk-Driven Approach: Tackle highest risks first (technical, requirements).

• Value-Based Prioritization: Deliver highest business value features earliest.

• People-Centricity: Empower self-organizing teams; focus on collaboration over rigid processes.

Comparison: Conventional vs. Modern

Guiding Principles (from Agile/Lean Frameworks)

• Continuous Improvement: Regular retrospectives to adapt process.

• Flexibility: Respond to change over following a plan.

• Stakeholder Collaboration: Daily/regular engagement with customers.

[!TIP] Common Pitfall: Don’t just list principles—explain why they matter (e.g., iterative development reduces "big bang" integration risk).

3. Software Lifecycle and Expectations

Phases of the Software Lifecycle (Unified Process/RUP Example)

Traditional Waterfall Phases: Requirements → Design → Implementation → Testing → Maintenance → Retirement.

Lifecycle Expectations

• Phase-Specific Goals: Each phase has clear entry/exit criteria (e.g., Elaboration exit: architecture validated, risks mitigated).

• Milestone Reviews: Lifecycle Objective Milestone (end of Elaboration), Lifecycle Architecture Milestone.

• Decision Points: Go/No-Go decisions based on milestone reviews.

System Adaptation Over Time (Why Change is Necessary)

• Environmental Shifts: New OS, hardware, regulations (e.g., data privacy laws).

• Bug Fixes: Correcting defects found post-deployment.

• Enhancement Needs: New features requested by users.

• Technology Obsolescence: Underlying platforms/frameworks become unsupported.

Result: Without adaptation, system effectiveness degrades → technical debt accumulates → maintenance costs soar.

4. Artifacts and Architecture

Management Artifacts vs. Engineering Artifacts

Pragmatic Artifacts

• Definition: Artifacts tailored to project’s specific context—no "one-size-fits-all".

• Example: A small rural project may use lightweight user stories instead of heavy SRS documents.

Model-Based Software Architecture

• Concept: Use models (UML, SysML, ADLs) to represent architecture at multiple levels of abstraction.

• Benefits:

  • Communication: Common visual language for stakeholders.

  • Analysis: Early simulation of performance, reliability.

  • Reuse: Architectural patterns (e.g., microservices for scalability).

• Tools: Enterprise Architect, IBM Rational, ArchiMate.

Design Strategies

• Top-Down: Start with high-level system decomposition → refine into modules.

  • Pros: Ensures holistic view, good for complex systems.

  • Cons: May miss low-level optimizations.

• Bottom-Up: Start with existing components/modules → integrate into larger system.

  • Pros: Leverages reusable code, good for integration projects.

  • Cons: Risk of suboptimal overall structure.

Modular Design: Cohesion & Coupling

• Purpose: Manage complexity, enable parallel development, ease maintenance.

• Cohesion (Within a module):

  • High Cohesion (Good): Module elements are closely related (e.g., CalculateInterest() in a Banking module).

  • Low Cohesion (Bad): Module performs unrelated tasks (e.g., PrintReport() and ValidateUser() together).

• Coupling (Between modules):

  • Loose Coupling (Good): Minimal dependencies; modules interact via well-defined interfaces.

  • Tight Coupling (Bad): Modules depend heavily on each other’s internal details → ripple effects from changes.

Rule: Aim for high cohesion, loose coupling.

5. Process Elements and Framework

Workflow Stages of the Software Process

Typical sequence (per SEI/ISO):

1. Communication: Elicit requirements from stakeholders.

2. Planning: Estimate, schedule, allocate resources.

3. Modeling: Analyze requirements, create design models.

4. Construction: Code, unit test.

5. Deployment: Deliver to users, provide support.

Note: Iterative processes cycle through these stages multiple times per increment.

Process Checkpoints

• Milestones: Pre-defined dates for review (e.g., "Requirements Complete").

• Reviews:

  • Technical Review: Evaluate work products (design, code).

  • Audit: Independent assessment for compliance.

• Decision Gates: Formal approval to proceed to next phase (e.g., Phase-Gate® model).

Task Set

• Definition: Collection of tasks, milestones, and work products for a specific project.

• Selection Criteria:

  • Project size (LOC, team size)

  • Criticality (safety-critical vs. informational)

  • Innovation level (novel tech vs. well-understood)

  • Team experience

Process Discriminants

Factors that differentiate one project’s process from another:

• Application domain (e.g., medical device vs. website)

• Team skill/experience

• Tools & technologies used

• Organizational culture (e.g., agile vs. plan-driven)

• Regulatory constraints

Process Measurement Tools

• Metrics:

  • Size: LOC, Function Points (FP), Story Points.

  • Effort: Person-months (PM).

  • Quality: Defect density = \(\frac{\text{Total defects}}{\text{Size (KLOC)}}\).

  • Schedule: On-time delivery rate.

• Key Performance Indicators (KPIs):

  • Schedule Variance (SV): \(SV = EV - PV\) (Earned Value - Planned Value)

  • Cost Variance (CV): \(CV = EV - AC\)

  • Productivity: \(\frac{\text{Size (FP)}}{\text{Effort (PM)}}\)

Key Management Indicators

• Cost Variance (CV)

• Schedule Variance (SV)

• Defect Density (defects/KLOC)

• Team Velocity (story points/iteration)

• Customer Satisfaction (survey scores)

6. Project Organization and Team Management

Project Organization Structures

Roles and Responsibilities

• Project Manager: Planning, monitoring, controlling, stakeholder communication.

• Team Lead/Scrum Master: Facilitate team processes, remove impediments.

• Developers: Design, code, unit test.

• QA/Test Engineers: Test planning, execution, defect tracking.

• Stakeholders/Customers: Provide requirements, accept deliverables.

Software Management Team

• Composition: PM, leads, architects, key domain experts.

• Functions:

  • Planning: Define scope, schedule, budget.

  • Monitoring: Track progress against plan.

  • Coordination: Resolve cross-team issues, manage dependencies.

Multidisciplinary Team in Project Planning

• Why Needed: Rural tech projects often involve domain experts (agriculture, finance), field staff, local community reps alongside technical staff.

• Integration: Ensure requirements are realistic, culturally appropriate, and technically feasible.

Organizing Stakeholders for Effective Engineering

• Communication Plan: Define who needs what information, when, how (e.g., weekly demos for villagers, monthly reports to funders).

• RACI Matrix: Assign Responsible, Accountable, Consulted, Informed for key tasks.

• Decision-Making Framework: Clarify who approves scope changes, budget reallocation.

7. Planning and Control

Iterative Process Planning

• Approach: Plan increments (e.g., 2-4 week iterations). Each increment delivers a subset of features.

• Planning Steps:

  1. Identify core architectural risks → plan early iterations to address them.

  2. Prioritize use cases by business value and risk.

  3. Define iteration goals and task breakdown.

• Example: For a rural health app:

  • Iteration 1: Offline patient registration (high risk: data sync).

  • Iteration 2: Basic diagnosis flow (high value).

Project Control and Process Instrumentation

Four-Step Process:

1. Measure: Collect data (effort, defects, schedule).

2. Evaluate: Compare actual vs. plan (Earned Value Analysis).

3. Adjust: Take corrective actions (replan, add resources, descope).

4. Report: Communicate status to stakeholders.

Success Factors in Project Control System

• Accurate data (automated tracking tools).

• Timely feedback (daily stand-ups, weekly reviews).

• Clear accountability (RACI).

• Realistic baselines (estimates based on historical data).

Common Problems in Project Control

• Inaccurate estimates: Optimism bias, missing requirements.

• Scope creep: Uncontrolled requirement additions.

• Resource conflicts: Shared resources, skill gaps.

• Poor communication: Silos, unclear reporting.

Risk Management

• Identification Techniques: Brainstorming, checklists, SWOT analysis, historical data review.

• Monitoring: Risk register, periodic reviews, trigger-based alerts.

• Mitigation Strategies:

  • Avoid: Change plan to eliminate risk.

  • Transfer: Outsource, insure.

  • Mitigate: Reduce probability/impact (e.g., prototyping).

  • Accept: Document, contingency plan.

Warning Signs of Project Jeopardy & Corrective Actions

Estimation Techniques

• Effort/Time/Cost Models:

  • COCOMO (Constructive Cost Model):

    \[ E = a \times (KLOC)^b \quad \text{(Effort in person-months)} \]

    \[ D = c \times (E)^d \quad \text{(Development time in months)} \]

    Where \(a, b, c, d\) are constants based on project type (Organic, Semi-detached, Embedded).

  • Function Points (FP): Measure functionality from user view. Convert to LOC via language-dependent factor.

• Project Budgeting:

  • Bottom-up: Estimate tasks → sum.

  • Top-down: Use historical data + adjust for size/complexity.

• Improvement Methods: Use historical databases, calibrate models, three-point estimation (PERT: \( \text{Estimate} = \frac{O + 4M + P}{6} \)).

8. Technical Practices and Standards

Programming Practices and Coding Standards

• Importance:

  • Quality: Reduces defects, improves readability.

  • Maintainability: Easier for new developers to understand.

  • Teamwork: Consistent style enables collaboration.

  • Knowledge Sharing: Code becomes documentation.

• Examples: Naming conventions (camelCase), indentation, comment standards, code review mandates.

Modular Design Deep Dive

• Achieving High Cohesion:

  • Group related functions (e.g., all file I/O in FileHandler module).

  • Avoid "god classes" that do everything.

• Achieving Loose Coupling:

  • Use interfaces/abstract classes.

  • Minimize shared data; pass parameters explicitly.

  • Dependency Injection to invert control.

• Impact:

  • Testing: Isolated modules easier to unit test.

  • Reuse: Loose coupling allows modules to be used in different contexts.

Software Configuration Management (SCM)

• Process:

  1. Version Control: Track changes (Git, SVN).

  2. Change Control: Review/approve changes (Change Request → CAB approval).

  3. Status Accounting: Record status of each change (who, when, why).

  4. Audits: Verify integrity of baselines (configuration audits).

• Necessity:

  • Traceability: Link requirements → design → code → tests.

  • Rollback Capability: Recover from faulty releases.

  • Collaboration Integrity: Prevent overwrites, manage parallel work.

  • Baseline Management: Freeze versions for release/audit.

9. Process Automation

Definition and Purpose

• Definition: Use of tools/scripts to execute repetitive software process tasks without manual intervention.

• Purpose:

  • Reduce manual effort & human error.

  • Ensure consistency and repeatability.

  • Enable continuous integration/delivery.

  • Provide real-time metrics.

Process Automation Structure

• Tools: Jenkins, GitLab CI, Ansible, Selenium.

• Scripts: Build scripts (Make, Ant), deployment scripts.

• Workflows: Defined sequence (e.g., commit → build → test → deploy).

• Integration Points: Link between tools (e.g., JIRA → Git → Jenkins).

How Process Automation Works (Example: CI/CD Pipeline)

1. Commit: Developer pushes code to repository.

2. Build: Automated build compiles code, runs static analysis.

3. Test: Automated unit/integration tests execute.

4. Deploy: If tests pass, deploy to staging/production.

5. Feedback: Notify team of build/test results.

Four Stages of Process Automation

1. Manual: All steps done by hand.

2. Automated: Repetitive tasks scripted (e.g., automated build).

3. Integrated: Tools chained together (CI/CD pipeline).

4. Intelligent (Adaptive): AI/ML for predictive analytics, auto-remediation (e.g., auto-scaling based on load).

Automation’s Impact on Software Economics

• Reduced Cycle Time: Faster time-to-market.

• Lower Defect Rates: Early detection via automated testing.

• Optimized Resource Use: Less time on repetitive tasks → more on high-value work.

• Improved Predictability: Consistent processes → reliable estimates.

10. Software Maintenance

Definition and Importance

• Definition: Modifications to software after delivery to correct faults, improve performance, or adapt to environment changes.

• Importance: Sustains system value; typically consumes 60-80% of total lifecycle cost.

Types of Maintenance Activities

Maintenance Challenges in Real-World Environments

• Legacy Systems: Outdated tech, lack of documentation, obsolete skills.

• Documentation Gaps: Missing design specs, comments.

• Evolving Requirements: Users request changes post-deployment.

• Resource Constraints: Maintenance often underfunded vs. new development.

• Knowledge Loss: Original developers leave.

11. Process Improvement

Improving Software Processes

• Frameworks:

  • CMMI (Capability Maturity Model Integration): 5-level model (Initial → Optimizing). Focus on process standardization.

  • Lean: Eliminate waste (Muda), optimize flow. Principles: amplify learning, decide late, deliver fast.

  • Six Sigma: DMAIC (Define, Measure, Analyze, Improve, Control) for defect reduction.

  • Agile Retrospectives: Regular team reflections to adapt process.

Process Measurement and Analysis

• Use Metrics to:

  • Identify bottlenecks: e.g., long test cycle time → automate testing.

  • Benchmark: Compare against industry averages (e.g., defect density).

  • Drive incremental change: Small, frequent improvements vs. big-bang changes.

• Key Metrics: Cycle time, lead time, escape defects, team happiness index.

• Analysis Tools: Control charts, Pareto analysis, root cause analysis (5 Whys).

[!TIP] Exam Strategy: When asked about process improvement, mention measurement first—"You can't improve what you don't measure." Link framework choice to project context (e.g., CMMI for large contracts, Agile for innovation).