Software Design and Development

Software Engineering & The Software Crisis:

• Software Engineering: The systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software (IEEE definition); the application of engineering principles to software.
• The Software Crisis (Late 1960s): Emerged when software projects routinely exceeded budgets, slipped past delivery deadlines, caused catastrophic runtime failures, and proved impossible to maintain due to ad-hoc, undisciplined coding without formal specifications.

Functional vs. Non-Functional Requirements:

• Functional Requirements: Define specific behaviors, computations, data manipulation, and services the system must execute (e.g. “The system shall allow users to transfer funds between bank accounts via connectIPS”).
• Non-Functional Requirements: Specify quality attributes, system constraints, and operational standards (e.g. “The fund transfer API must process requests within 500ms under a load of 1,000 concurrent transactions, adhering to TLS 1.3”).

Software Requirements Specification (SRS):

A formal, structured document that describes the intended purpose, behavior, features, and constraints of a software system to be developed.

• Adheres to IEEE 830 standards ensuring requirements are correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable, and traceable.

User Story & INVEST Criteria:

A short, simple description of a feature told from the perspective of the end user:

“As a [role], I want [feature], so that [business benefit].”

• INVEST Criteria (Bill Wake):
  • I: Independent
  • N: Negotiable
  • V: Valuable
  • E: Estimable
  • S: Small (fits within a single sprint)
  • T: Testable

Verification vs. Validation (Boehm):

• Verification: “Are we building the product right?” Static evaluation of code, designs, and specifications through inspections, walkthroughs, and reviews to ensure conformance to requirements.
• Validation: “Are we building the right product?” Dynamic testing of the executing software to ensure it satisfies true user operational needs and expectations.

Waterfall Model vs. Spiral Model:

The Agile Scrum Framework:

[Product Backlog] ──► [Sprint Planning] ──► [Sprint Backlog]
                              │
                     [2-4 Week Sprint] ◄── [Daily Scrum (15 min)]
                              │
             ┌────────────────┴────────────────┐
             ▼                                 ▼
   [Sprint Review (Demo)]            [Sprint Retrospective]
             │
[Potentially Shippable Product Increment]

---

1. Scrum Roles:

• Product Owner (PO): Maximizes product value; owns and prioritizes the Product Backlog.
• Scrum Master (SM): Servant leader who coaches the team, removes impediments, and facilitates ceremonies.
• Developers: Cross-functional self-organizing team that builds the increment.

2. Scrum Artifacts:

• Product Backlog: Prioritized master inventory of all user stories and requirements.
• Sprint Backlog: Subset of user stories committed for completion in the current sprint.
• Increment: The sum of all backlog items completed during a sprint meeting the Definition of Done (DoD).

3. Scrum Ceremonies:

• Sprint Planning: Selects backlog items and creates the sprint goal.
• Daily Scrum: 15-minute daily sync: What did I do? What will I do? What are blockers?
• Sprint Review: Live demo of the completed increment to stakeholders.
• Sprint Retrospective: Internal team inspection: What went well? What can improve?

Requirements Elicitation Techniques:

1. Interviews (Structured vs Unstructured): Direct dialog with stakeholders. Effective for uncovering in-depth perspectives and operational nuances, though time-consuming.
2. Questionnaires / Surveys: Distributes standardized questions to hundreds of geographically dispersed users. Inexpensive and quantitative, but lacks qualitative depth and suffers non-response bias.
3. Joint Application Design (JAD) / FAST Workshops: Intensive structured sessions bringing developers, business analysts, and users together in a single room for 2–3 days with a neutral facilitator, rapidly resolving conflicting priorities.
4. Prototyping (Wireframes / Mockups): Building interactive Figma/UI models to help non-technical users visualize workflows and discover implicit requirements.
5. Observation (Ethnographic Job Shadowing): Analyst observes operators performing daily tasks in their real workplace, identifying unstated workarounds and ergonomic pain points.

Use Case Modeling & Include vs. Extend:

A Use Case captures a contract between system actors and the system, describing a sequence of actions that yields an observable result of value.

---

<<include>> vs. <<extend>> Relationships:

[Actor: User] ──► (Transfer Funds) ──<<include>>──► (Authenticate User)
                         ▲
                         │ <<extend>> (Condition: Insufficient Balance)
                         │
                 (Send SMS Alert)

1. <<include>> (Mandatory Dependency):
   • The base use case always executes the included use case as part of its normal execution flow.
   • Extracts common, reusable subroutines across multiple use cases.
   • Example: Both (Transfer Funds) and (View Statement) <<include>> (Authenticate User).
2. <<extend>> (Optional / Conditional Extension):
   • The extending use case is executed only conditionally when a specific extension point condition occurs.
   • The base use case is complete on its own without the extension.
   • Example: (Send Low Balance Alert) <<extend>> (Transfer Funds) only if account balance drops below minimum threshold.

Comprehensive Feasibility Analysis:

1. Technical Feasibility: Can we build it with available technology? Assesses technical risk, team skills, hardware availability, scalability, and system compatibility.
2. Economic Feasibility (Cost-Benefit Analysis): Will the system provide positive financial return?
   • Net Present Value (NPV): Discounted present value of future cash flows minus initial investment.
   • Return on Investment (ROI): $\frac{\text{Total Net Benefits}}{\text{Total Costs}} \times 100$.
   • Payback Period: Time required for cumulative net benefits to recover the initial capital expenditure.
3. Operational Feasibility: Will the system be accepted and adopted by end users in the organizational workflow? Analyzes human resistance to change and training needs.
4. Schedule Feasibility: Can the software be developed and deployed before critical business deadlines?
5. Legal & Contractual Feasibility: Ensures compliance with copyright laws, GDPR/data privacy acts, and Nepal’s Electronic Transactions Act 2063.

Extreme Programming (XP) Core Practices:

An agile software development methodology focused on high software quality and responsiveness to changing customer requirements.

---

Core Engineering Practices:

1. Pair Programming: Two developers work simultaneously at a single workstation. The Driver writes code while the Navigator reviews each line in real time, catching bugs, verifying architecture, and sharing knowledge.
2. Test-Driven Development (TDD): Follows the Red-Green-Refactor cycle:
   • Red: Write an automated unit test that fails.
   • Green: Write the minimum production code required to pass the test.
   • Refactor: Clean up and optimize the code without changing external behavior.
3. Refactoring: Continuously improving the internal design of working code to remove code smells and reduce technical debt without altering functional behavior.
4. Continuous Integration (CI): Developers integrate their code changes into the shared mainline branch multiple times daily, running automated regression tests on every commit.

UML Architectural Model for Online Mobile Banking System:

---

Part (a): Use Case Diagram

  [Customer]
      │
      ├───► (Login with Biometrics / PIN) ──<<include>>──► (Verify Credentials)
      │
      ├───► (View Account Summary)
      │
      ├───► (Transfer Funds via connectIPS) ──<<include>>──► (Generate & Verify OTP)
      │            │
      │            └──<<extend>>──► (Log Insufficient Balance Exception)
      │
      └───► (Pay Utility Bill: NEA / Khanepani)

  [connectIPS Gateway] ◄─── (Transfer Funds via connectIPS)
  [SMS Gateway]        ◄─── (Generate & Verify OTP)
  [Bank Admin]         ───► (Manage Limits & Block Accounts)

---

Part (b): Sequence Diagram (Transfer Funds via connectIPS)

• Key Architectural Features: The sequence diagram models ACID transaction safety: funds are placed on temporary hold, executed over connectIPS gateway, and committed only upon verified HTTP 200 confirmation, preventing ghost debit discrepancies.

COCOMO Software Estimation Numerical:

Given:

• Project Size: $KLOC = 40$
• Mode: Semi-Detached
• Constants: $a = 3.0, \; b = 1.12, \; c = 2.5, \; d = 0.35$
• Given Exponent Powers:
  • $(40)^{1.12} = 61.64$
  • $(184.92)^{0.35} = 6.24$
• Average Monthly Salary = NPR 85,000

---

Step (a): Effort Computation ($E$)

---

Step (b): Development Time Computation ($TDEV$)

---

Step (c): Average Staff Size ($SS$)

---

Step (d): Total Labor Cost

---

Step (e): Comparison of COCOMO Project Modes