Unit 6: Software Quality and Small Projects

I. Foundations of Software Quality

Software quality is the degree to which a software product satisfies stated requirements, implied user needs, and relevant professional standards within a specified context of use.

Defining properties:

• Fitness for purpose: The software performs the tasks for which it was developed.
• Conformance to requirements: Its behavior agrees with specifications, contracts, and acceptance criteria.
• User perspective: Quality includes usability, reliability, security, accessibility, and satisfaction.
• Engineering perspective: Internal qualities such as modularity, testability, and maintainability affect long-term performance.
• Context dependence: A quality level acceptable for a classroom application may be unacceptable for medical or aviation software.
• Continuous responsibility: Quality must be planned, built, measured, and improved throughout the life cycle.

A. Defining Software Quality

Software quality combines conformance, fitness for use, and freedom from unacceptable defects.

• Stated requirements: Explicit functions, constraints, and service levels provide measurable acceptance criteria; for example, “95% of requests shall complete within two seconds.”
• Implied requirements: Users reasonably expect the product to preserve data, reject unauthorized access, and fail predictably even when these expectations are not written.
• Internal quality: Properties of source code and architecture include low coupling, meaningful cohesion, controlled complexity, and compliance with coding rules.
• External quality: Observable behavior includes response time, failure frequency, accuracy, and compatibility during testing or operation.
• Quality in use: The product should help particular users achieve goals effectively, efficiently, safely, and satisfactorily in a real environment.
• Quality assurance and control:
  1. Quality assurance is preventive and process-oriented, using standards, reviews, audits, and defined procedures.
  2. Quality control is detection-oriented and product-focused, using inspection, static analysis, and testing.
• Measurement: Useful indicators include defect density, test coverage, mean time between failures, escaped defects, and customer-reported incident rates.

II. Standard Software Quality Models

Quality models divide the broad idea of quality into named characteristics that can guide requirements, evaluation, and trade-off decisions.

A. Software Quality: ISO9126

ISO/IEC 9126 provided a structured model for evaluating software product quality and helped establish a common quality vocabulary.

• Functionality: The software supplies appropriate and accurate functions, supports interoperability, protects information, and complies with functional rules.
• Reliability: Maturity, fault tolerance, and recoverability determine whether service is sustained under stated conditions.
• Usability: Understandability, learnability, operability, and attractiveness influence the effort required from users.
• Efficiency: Time behavior and resource utilization cover response time, throughput, processor use, memory, storage, and network consumption.
• Maintainability: Analyzability, changeability, stability, and testability determine the effort needed to diagnose and modify the product.
• Portability: Adaptability, installability, coexistence, and replaceability concern movement between environments.
• Evaluation structure: ISO/IEC 9126 distinguished internal quality, external quality, and quality in use, allowing evaluation from code construction through operational use.
• Historical significance: Its six-characteristic product model influenced later standards, but ISO/IEC 25010 replaced and expanded it.

B. ISO/IEC 25010 Quality Model

ISO/IEC 25010:2011, part of the SQuaRE standards family, expanded the product quality model to eight characteristics and supplied a separate quality-in-use model.

• Functional suitability: Functional completeness, correctness, and appropriateness show whether functions cover specified tasks and produce correct results.
• Performance efficiency: Time behavior, resource utilization, and capacity evaluate performance relative to resources and operating conditions.
• Compatibility: Coexistence and interoperability measure whether products share environments and exchange usable information.
• Usability: Appropriateness recognizability, learnability, operability, user-error protection, interface aesthetics, and accessibility shape interaction quality.
• Reliability: Maturity, availability, fault tolerance, and recoverability describe continuity of correct service.
• Security: Confidentiality, integrity, non-repudiation, accountability, and authenticity protect information and actions.
• Maintainability: Modularity, reusability, analyzability, modifiability, and testability support economical evolution.
• Portability: Adaptability, installability, and replaceability support transfer between hardware, software, or operational environments.
• Practical use: A team can convert characteristics into measurable requirements, such as availability of 99.9%, median response time below 300 milliseconds, or recovery within 15 minutes.

III. Quality Governance

Quality governance coordinates product objectives, development practices, and external obligations instead of treating testing as the sole quality activity.

A. Product versus process quality

Product quality concerns the software and its behavior, whereas process quality concerns how the software is planned, created, verified, and maintained.

1. Product quality:
   • Evidence: Test results, defect density, performance measurements, vulnerability reports, usability findings, and operational availability assess the deliverable.
   • Objective: The product must satisfy functional and non-functional requirements in its intended environment.
2. Process quality:
   • Evidence: Review records, traceability, configuration controls, build repeatability, audit findings, and compliance with a defined life cycle assess development work.
   • Objective: A capable, controlled process reduces variation and increases the probability of producing dependable software.

• Relationship: A strong process improves consistency but cannot guarantee a good product; final product verification remains necessary.
• Example: Mandatory peer review is a process-quality control, while the post-release defect rate measures product quality.

B. Management of external standards

Managing external standards means identifying applicable obligations, translating them into project controls, and maintaining evidence of compliance.

• Sources: Obligations may arise from ISO standards, legislation, customer contracts, industry regulations, platform rules, and organizational policy.
• Applicability analysis: A standards register should record the document, version, owner, affected components, mandatory clauses, and compliance evidence.
• Tailoring: Each requirement is mapped to activities and artifacts; a security rule may require threat modeling, access-control tests, and audit logs.
• Change control: Assigned owners monitor revisions and assess their effects on cost, architecture, schedules, suppliers, and existing certifications.
• Auditing: Internal audits identify gaps before customer or certification audits; corrective actions should have owners, deadlines, and closure evidence.
• Configuration management: Templates, procedures, test reports, approvals, and baselines must be version-controlled so that compliance is reproducible.

IV. Planning Small and Student Projects

Small projects use fewer people and shorter schedules, but still require explicit scope, ownership, risk management, and evidence of completion.

A. Problems with student projects

Student projects commonly fail because academic constraints amplify weaknesses in estimation, coordination, and validation.

• Unclear scope: Broad goals such as “build an intelligent portal” lack bounded features and measurable acceptance criteria.
• Unrealistic planning: Teams underestimate integration, testing, documentation, deployment, and learning time.
• Uneven participation: Work may concentrate around one programmer because responsibilities and progress are not visible.
• Technology-first decisions: Choosing unfamiliar frameworks for novelty can consume time without improving the required solution.
• Weak requirements: Limited stakeholder access leads to assumptions, frequent rework, and demonstrations that do not solve the intended problem.
• Late integration: Independently developed modules may use incompatible interfaces, schemas, or dependency versions.
• Insufficient quality work: Testing is postponed until the deadline, leaving little time to correct defects.
• Poor continuity: Missing repositories, issue records, meeting decisions, and setup instructions make work difficult to reproduce or hand over.

B. Content of project plan

A project plan establishes what will be delivered, how the work will proceed, and how progress and quality will be controlled.

• Purpose and scope: State the problem, objectives, boundaries, assumptions, constraints, and exclusions.
• Deliverables: Identify software increments, documentation, demonstrations, test evidence, and deployment packages with acceptance criteria.
• Work breakdown: Divide the project into estimable tasks, milestones, dependencies, and assigned owners.
• Schedule and resources: Record dates, effort estimates, team roles, tools, infrastructure, and budget.
• Technical approach: Describe architecture, technologies, data handling, interfaces, environments, and configuration strategy.
• Quality plan: Specify standards, reviews, test levels, entry and exit criteria, defect handling, and target metrics.
• Risk plan: Give each risk a probability, impact, owner, preventive action, and contingency response.
• Communication and control: Define meetings, status reports, repository practices, change approval, and escalation routes.

V. Establishing a New Company in India

Company incorporation creates a separate legal entity through registration with the Ministry of Corporate Affairs and the relevant Registrar of Companies.

A. Steps to be taken to incorporate a new Company

Incorporation proceeds from selecting the legal form to obtaining registration and completing post-incorporation controls.

• Choose the structure: Decide among a private company, public company, or One Person Company according to ownership, liability, capital, and compliance needs.
• Obtain digital signatures: Proposed subscribers and directors who sign electronic forms require valid Digital Signature Certificates.
• Reserve the name: Apply through the MCA’s SPICe+ service with names that satisfy availability, trademark, and naming rules.
• Prepare constitutional details: Define the registered office, capital, subscribers, directors, objects, and provisions of the Memorandum and Articles of Association.
• File incorporation forms: Submit SPICe+ and linked forms through the MCA portal with declarations, evidence, and prescribed fees or stamp duty.
• Receive registration: After scrutiny, the Registrar issues the Certificate of Incorporation containing the Corporate Identity Number.
• Complete follow-up work: Open the bank account, bring in subscribed capital, maintain statutory registers, appoint the auditor, and file applicable commencement or registered-office forms.

B. Documents Required

Incorporation documents establish the identity of participants, legality of the office, ownership commitments, and governance rules.

• Subscriber and director identity: PAN for Indian applicants and appropriate identity or passport evidence for foreign applicants.
• Address proof: Recent bank statement, utility bill, or other accepted proof matching the applicant’s declared address.
• Photographs and contact details: Required personal and communication information supports application records.
• Registered-office evidence: Ownership proof or lease/rent agreement, a recent utility bill, and an owner’s no-objection certificate where applicable.
• Constitutional documents: The Memorandum of Association states the company’s objects and capital; the Articles of Association state internal governance rules.
• Declarations and consents: Subscribers and proposed directors provide prescribed declarations, disclosures, and consent to act.
• Special approvals: A regulated name, foreign investment, sector-specific activity, or trademark-related name may require additional authorization.

VI. MSME Recognition

Indian micro, small, and medium enterprises obtain formal recognition through Udyam Registration under the Ministry of Micro, Small and Medium Enterprises.

A. Steps to register for MSME certificate

Udyam Registration is an online, paperless, self-declaration process linked to official identity and tax databases.

• Check classification: Enterprise classification uses the notified composite criteria of investment in plant and machinery or equipment and annual turnover.
• Access the portal: Use the official Udyam Registration portal; government registration itself does not require a fee.
• Authenticate Aadhaar: Enter and validate the Aadhaar details of the proprietor, managing partner, or authorized company representative, as applicable.
• Provide tax identifiers: Supply PAN and GSTIN where required; linked government records support verification of investment and turnover.
• Enter enterprise data: Record the organization type, address, bank details, activities, employment information, and relevant National Industrial Classification codes.
• Submit the declaration: Confirm accuracy and complete OTP-based submission.
• Receive the certificate: A permanent Udyam Registration Number and electronic certificate are issued after successful registration.
• Maintain accuracy: Enterprise information and classification may update through linked tax data; false declarations can attract legal consequences.

VII. Blockchain-Based Quality Governance

Blockchain can supplement conventional repositories and quality systems by preserving shared, tamper-evident records of selected development events.

A. Blockchain for Software Quality Management: Ensuring Traceability and Transparency in Software Development

Blockchain supports software quality management by linking signed records of requirements, code changes, builds, tests, approvals, and releases.

• Traceability: Transaction references can connect a requirement identifier to a commit hash, build artifact hash, test report, reviewer approval, and deployed release.
• Transparency: Authorized participants share a consistent history, reducing disputes among developers, customers, auditors, and suppliers.
• Immutability: Altering a recorded event changes its cryptographic hash and breaks the chain’s verification, making unauthorized modification detectable.
• Smart contracts: Rules can prevent release approval until required reviews, security scans, and acceptance tests have recorded successful outcomes.
• Artifact integrity: Large source files and reports remain in normal repositories, while their hashes are stored on-chain; recalculating a hash verifies that an artifact is unchanged.
• Permissioned operation: Enterprise systems commonly restrict participation and assign roles because public disclosure may expose code, defects, or personal information.
• Limitations: Blockchain cannot prove that an original input was truthful, correct defective tests, or replace configuration management and human review.
• Governance concerns: Adoption requires policies for identity, access, privacy, correction records, key recovery, data retention, interoperability, and operating cost.
• Illustrative flow:

Requirement ID -> Commit hash -> Build hash -> Test result hash -> Release approval

• Quality value: The chain provides auditable provenance, but software quality still depends on sound requirements, competent engineering, valid testing, and accountable decisions.