Unit 6: Software Quality and Small Projects - Subjective Questions

Software quality is the degree to which a software product satisfies stated and implied requirements, conforms to applicable standards, and meets the needs of users under specified conditions.

Software quality can be evaluated from the following perspectives:

• User perspective: The software should be useful, reliable, easy to learn, efficient, and suitable for its intended purpose.
• Developer perspective: The software should conform to specifications, design rules, coding standards, and maintainability requirements.
• Product perspective: Quality is assessed through measurable product attributes such as defect density, response time, complexity, and availability.
• Process perspective: Quality depends on the effectiveness of development, testing, review, configuration management, and maintenance processes.
• Value-based perspective: Quality is evaluated by balancing benefits, cost, schedule, business value, and stakeholder expectations.

Therefore, software quality is not limited to the absence of defects. It also includes fitness for use, conformance to requirements, maintainability, security, performance, and stakeholder satisfaction.

Software quality management ensures that quality is planned, built into the product, evaluated, and continuously improved throughout the software development life cycle.

Its importance includes:

• Requirement quality: Reviews help identify ambiguous, incomplete, inconsistent, or untestable requirements.
• Design quality: Architecture and design evaluations detect structural problems before implementation.
• Implementation quality: Coding standards, static analysis, code reviews, and unit testing reduce defects.
• Testing effectiveness: Systematic test planning verifies functional and non-functional requirements.
• Risk reduction: Early defect detection reduces the probability of failures, security incidents, and costly rework.
• Customer satisfaction: Reliable and usable software improves user confidence and acceptance.
• Maintainability: Documentation, modular design, and configuration control simplify future changes.
• Compliance: Quality management provides evidence that contractual, regulatory, and organizational standards have been followed.

A common quality principle is that the cost of preventing or detecting a defect early is normally lower than the cost of correcting it after deployment.

The ISO 9126 model defines six main software product quality characteristics:

• Functionality: The ability of the software to provide functions that satisfy stated and implied needs. Its sub-characteristics include suitability, accuracy, interoperability, security, and compliance.
• Reliability: The ability to maintain a specified level of performance under specified conditions. It includes maturity, fault tolerance, and recoverability.
• Usability: The effort required to understand, learn, operate, and use the software. It includes understandability, learnability, operability, and attractiveness.
• Efficiency: The relationship between software performance and the resources used. It includes time behavior and resource utilization.
• Maintainability: The effort required to analyze, modify, test, and stabilize the software after a change. It includes analyzability, changeability, stability, and testability.
• Portability: The ability of the software to be transferred from one environment to another. It includes adaptability, installability, co-existence, and replaceability.

These characteristics provide a structured basis for specifying requirements, evaluating products, and defining software quality metrics.

ISO 9126 distinguishes among internal quality, external quality, and quality in use.

• Internal quality concerns attributes that can be assessed without executing the software. Examples include source-code complexity, modularity, documentation quality, and compliance with coding standards.
• External quality concerns the behavior of the executing software. Examples include response time, failure rate, accuracy, and resource consumption.
• Quality in use concerns the effect of the software when used by specified users in a specified context.

The ISO 9126 quality-in-use characteristics are:

• Effectiveness: Accuracy and completeness with which users achieve their goals.
• Productivity: Resources consumed in relation to the effectiveness achieved.
• Safety: Acceptable levels of risk to users, business operations, property, or the environment.
• Satisfaction: The degree to which the software meets user expectations and produces a satisfactory experience.

Internal attributes influence external behavior, while external behavior influences quality in use. For example, well-structured code may improve reliability, which in turn helps users complete tasks effectively.

The ISO/IEC 25010 product quality model defines eight characteristics:

• Functional suitability: The product provides functions that meet stated and implied needs. It includes functional completeness, correctness, and appropriateness.
• Performance efficiency: The product provides suitable performance relative to resources used. It includes time behavior, resource utilization, and capacity.
• Compatibility: The product can exchange information and operate with other products in a shared environment. It includes co-existence and interoperability.
• Usability: Specified users can use the product effectively, efficiently, and satisfactorily. It includes learnability, operability, user-error protection, accessibility, and interface aesthetics.
• Reliability: The product performs specified functions under specified conditions for a specified period. It includes availability, fault tolerance, maturity, and recoverability.
• Security: The product protects information and data. It includes confidentiality, integrity, non-repudiation, accountability, and authenticity.
• Maintainability: The product can be effectively modified. It includes modularity, reusability, analyzability, modifiability, and testability.
• Portability: The product can be transferred to another environment. It includes adaptability, installability, and replaceability.

The model helps convert broad quality expectations into measurable and testable requirements.

ISO/IEC 25010 evolved from ISO 9126 and provides a broader, more current framework for evaluating software-intensive systems.

Major differences include:

• ISO 9126 has six product quality characteristics, whereas ISO/IEC 25010 has eight.
• ISO/IEC 25010 introduces compatibility as a separate characteristic. In ISO 9126, interoperability was mainly associated with functionality.
• ISO/IEC 25010 introduces security as a separate characteristic. ISO 9126 treated security as a sub-characteristic of functionality.
• ISO/IEC 25010 renames functionality as functional suitability and emphasizes completeness, correctness, and appropriateness.
• ISO/IEC 25010 renames efficiency as performance efficiency and explicitly includes capacity.
• ISO/IEC 25010 expands usability by including accessibility and user-error protection.
• ISO/IEC 25010 expands maintainability with concepts such as modularity and reusability.
• The ISO 9126 quality-in-use model has four characteristics, while ISO/IEC 25010 defines five: effectiveness, efficiency, satisfaction, freedom from risk, and context coverage.

Thus, ISO/IEC 25010 better addresses modern concerns such as cybersecurity, accessibility, interoperability, multiple usage contexts, and system-wide quality.

Product quality describes the attributes of the software and related deliverables, whereas process quality describes the capability and effectiveness of the activities used to produce them.

Product quality:

• Focuses on the final software product and intermediate deliverables.
• Includes functionality, reliability, usability, performance, security, maintainability, and portability.
• Is measured using indicators such as defect density, response time, test coverage, availability, and customer-reported failures.
• Example: A web application returns correct results, responds within two seconds, and protects user data.

Process quality:

• Focuses on requirements, design, coding, testing, release, and maintenance processes.
• Includes repeatability, compliance, review effectiveness, traceability, and continuous improvement.
• Is measured using indicators such as review coverage, defect-removal efficiency, rework rate, and process compliance.
• Example: Every code change undergoes peer review, automated testing, security scanning, and approval before release.

A capable process generally increases the probability of producing a high-quality product, but it does not guarantee it. Product measurements and validation are still necessary.

Process quality and product quality are strongly related because disciplined processes reduce variation, expose defects early, and support consistent engineering decisions.

A good process contributes to product quality through:

• Clear and traceable requirements.
• Formal design and code reviews.
• Configuration and change control.
• Repeatable testing and defect management.
• Risk management and quality audits.
• Collection of metrics for continuous improvement.

However, a good process cannot guarantee a good product. A process may be followed correctly while requirements are wrong, the design is unsuitable, measurements are misleading, or users' actual needs are misunderstood. Similarly, a small skilled team may occasionally produce a good product through an informal process, although this approach is difficult to repeat and scale.

Quality management should therefore use both:

• Process assurance, to verify that appropriate methods are followed.
• Product control, to review, test, measure, and validate the resulting software.

The strongest evidence of quality comes from combining a capable process with objective product measurements and user validation.

External standards are rules, models, specifications, or guidelines developed outside the project organization. They may be issued by international bodies, governments, regulators, industry associations, customers, or technology vendors.

Examples include ISO/IEC quality standards, information-security standards, accessibility requirements, data-protection laws, safety standards, and customer-mandated development procedures.

An organization should manage external standards through the following steps:

• Identify obligations: Determine legal, contractual, regulatory, domain, and customer requirements.
• Assess applicability: Map each standard or clause to the project scope, product, technology, and deployment region.
• Establish ownership: Assign a compliance owner for interpretation and implementation.
• Tailor internal processes: Convert applicable clauses into policies, procedures, checklists, controls, and acceptance criteria.
• Train the team: Ensure that team members understand the controls relevant to their roles.
• Maintain evidence: Preserve review records, test results, approvals, traceability records, and audit logs.
• Monitor revisions: Track changes to standards and evaluate their impact.
• Audit compliance: Conduct internal assessments and resolve non-conformities.

Standards should be applied according to documented applicability and risk, rather than treated as an isolated documentation exercise.

A systematic procedure for incorporating an external quality standard is as follows:

1. Define scope: Identify the products, teams, locations, and life-cycle stages to which the standard applies.
2. Obtain the authoritative version: Record the standard's title, edition, publication date, and source.
3. Perform a gap analysis: Compare current practices and evidence with each applicable requirement.
4. Classify gaps: Prioritize gaps according to compliance importance, quality risk, implementation cost, and urgency.
5. Create an implementation plan: Assign owners, resources, milestones, deliverables, and acceptance criteria.
6. Update organizational assets: Revise policies, process descriptions, templates, checklists, tools, and definition-of-done criteria.
7. Train personnel: Provide role-specific guidance and verify competency where necessary.
8. Pilot the changes: Apply the revised process to a controlled project and collect feedback.
9. Deploy and monitor: Roll out the process and track compliance and outcome metrics.
10. Audit and improve: Record non-conformities, perform root-cause analysis, take corrective action, and review changes to the standard.

A requirements-to-evidence matrix should link every applicable clause to its control, owner, implementation artifact, and verification evidence.

Student software projects commonly face the following problems:

• Unclear or excessive scope: Teams select ambitious features without considering time and skills. The remedy is to define a minimum viable scope and prioritize requirements.
• Weak requirements: Informal discussions produce ambiguous expectations. Teams should document requirements, acceptance criteria, and prototypes.
• Unrealistic scheduling: Work is postponed until the deadline. Milestones, weekly deliverables, and progress tracking should be used.
• Unequal participation: One or two members may perform most of the work. Responsibilities, task ownership, and contribution records should be maintained.
• Insufficient technical knowledge: Teams underestimate unfamiliar tools. Early feasibility studies and technical prototypes reduce this risk.
• Poor version control: Files are exchanged manually and overwritten. A shared repository, branching rules, and frequent commits are required.
• Inadequate testing: Testing is left until the end. Unit, integration, and acceptance tests should be planned from the beginning.
• Communication failures: Decisions and changes are not recorded. Teams should hold short reviews and maintain issue and decision logs.
• Weak documentation: Reports are prepared after development. Documentation should be updated incrementally.
• Lack of risk management: Dependencies and team availability are ignored. A risk register should be reviewed regularly.

Student projects can be improved by applying lightweight but disciplined management practices.

Project planning:

• Define the problem, objectives, scope, assumptions, and constraints.
• Divide work into small tasks with clear completion criteria.
• Establish milestones for requirements, design, prototypes, testing, and submission.
• Maintain a risk register and reserve time for integration and correction.

Team organization:

• Assign clear roles such as coordinator, developer, tester, and documentation owner.
• Allocate tasks according to skills while rotating work to promote learning.
• Record decisions and review progress regularly.
• Use issue tracking to make responsibilities and status visible.

Configuration management:

• Store code and documents in version control.
• Use meaningful commits, branches, reviews, and release tags.
• Define naming conventions and maintain a stable baseline.
• Control requirement changes and record their impact.
• Back up repositories and protect access credentials.

Together, these practices reduce last-minute integration problems, lost work, duplicated effort, unclear ownership, and uncontrolled changes.

A software project plan normally contains:

• Project overview: Background, business need, objectives, and expected outcomes.
• Scope: Features included, exclusions, boundaries, assumptions, and constraints.
• Deliverables: Software releases, documents, training material, and acceptance evidence.
• Stakeholders and organization: Sponsor, customer, project manager, team structure, roles, and responsibilities.
• Development approach: Life-cycle model, methods, tools, environments, and technical strategy.
• Work breakdown structure: Decomposition of deliverables into manageable activities and tasks.
• Schedule: Task sequence, dependencies, milestones, estimates, and deadlines.
• Resource and cost plan: Personnel, hardware, software, services, budget, and effort.
• Quality plan: Standards, reviews, testing levels, quality metrics, and acceptance criteria.
• Risk plan: Identified risks, probability, impact, owners, responses, and contingencies.
• Communication plan: Meetings, reports, escalation paths, and stakeholder communication.
• Configuration and change plan: Version control, baselines, change requests, approvals, and releases.
• Monitoring plan: Progress indicators, reporting frequency, corrective actions, and project closure criteria.

A practical plan for a small project can be developed through these steps:

1. Clarify objectives and success criteria: Agree on the expected outcome and measurable acceptance conditions.
2. Define scope: Document included features, exclusions, assumptions, constraints, and interfaces.
3. Identify deliverables: Specify software increments, documents, test evidence, and deployment items.
4. Create a work breakdown structure: Divide deliverables into small tasks that can be estimated and assigned.
5. Estimate effort and duration: Use expert judgment, analogous projects, or task-based estimation.
6. Identify dependencies and resources: Determine task order, skills, tools, and team availability.
7. Build the schedule and budget: Set milestones and include reasonable contingency for risk.
8. Plan quality and risk activities: Define reviews, tests, standards, metrics, risk responses, and owners.
9. Review with stakeholders: Resolve unrealistic assumptions and obtain agreement.
10. Establish the baseline: Approve the scope, schedule, and cost versions used for performance comparison.
11. Control changes: Assess the impact of proposed changes before updating the baseline.

For a small project, the plan should remain concise but must still provide ownership, visibility, and control.

The principal steps for incorporating a company in India under the Companies Act framework are generally as follows:

1. Select the company type: Decide whether the entity will be a private company, public company, One Person Company, or another permitted form.
2. Choose subscribers and directors: Verify eligibility and collect identification, address, and consent documents.
3. Obtain digital signatures: Proposed signatories require Digital Signature Certificates for electronic filings.
4. Reserve the name: Select a distinctive name that complies with naming rules and does not conflict with existing names or trademarks.
5. Define the registered office and objects: Determine the official address and lawful business activities.
6. Prepare constitutional documents: Draft the Memorandum of Association and Articles of Association.
7. File the integrated incorporation application: Submit the prescribed forms and linked registrations through the Ministry of Corporate Affairs portal.
8. Pay fees and stamp duty: Amounts depend on authorized capital, company type, and state rules.
9. Respond to examination queries: Correct defects or provide clarifications requested by the Registrar of Companies.
10. Receive incorporation approval: The Registrar issues the Certificate of Incorporation and Corporate Identity Number.
11. Complete post-incorporation requirements: Open a bank account, bring in subscribed capital, maintain statutory registers, appoint the auditor, and complete applicable tax, labor, and commencement filings.

Exact forms and portal procedures may change, so current official MCA guidance must be checked.

Documents and information generally required for company incorporation in India include:

• Identity proof of subscribers and directors: Permanent Account Number for Indian applicants, or passport and other prescribed proof for foreign applicants.
• Address proof: Recent bank statement, utility bill, or another accepted document.
• Photographs and contact details: Passport-size photographs, email addresses, and mobile numbers where required.
• Digital Signature Certificates: For subscribers and proposed directors signing electronic forms.
• Director consent and declarations: Consent to act as director and declarations concerning eligibility and legal compliance.
• Registered-office proof: Ownership document or rent or lease agreement.
• Owner's no-objection certificate: Required when the registered office is not owned by the company.
• Recent utility bill: Used to verify the registered-office address.
• Name and business details: Proposed names, significance of the name, principal objects, and business activity classification.
• Capital and ownership details: Authorized capital, subscribed capital, number of shares, and subscriber allocation.
• Constitutional documents: Memorandum of Association and Articles of Association.
• Regulatory approval: Sectoral approval or trademark-owner consent where applicable.

Foreign documents may require notarization, apostille, consular authentication, and certified translation according to applicable rules.

MSME recognition in India is generally obtained through Udyam Registration on the official government portal.

The usual steps are:

1. Verify eligibility: Confirm that the enterprise falls within the current micro, small, or medium classification based on applicable investment and turnover limits.
2. Keep identification details ready: The proprietor's Aadhaar is generally used for a proprietorship. The authorized signatory's Aadhaar is used for entities such as companies, partnerships, LLPs, societies, or trusts, as applicable.
3. Keep tax and business details ready: Permanent Account Number, Goods and Services Tax details where applicable, enterprise type, address, bank details, and activity information may be required.
4. Visit the official Udyam portal: Select the option for a new entrepreneur who is not already registered.
5. Validate Aadhaar: Enter the required details and complete one-time-password verification.
6. Validate PAN and organization details: The portal verifies relevant information through connected government databases.
7. Complete the application: Provide the enterprise name, location, bank information, major activity, and employment details.
8. Submit the declaration: Verify the information and complete final authentication.
9. Receive registration: A permanent Udyam Registration Number is generated, and the electronic certificate can be obtained from the portal.

Registration should be performed only through the official portal. Requirements and classifications should be verified against current government notifications.

Information commonly required for Udyam Registration includes:

• Aadhaar details of the proprietor or authorized signatory, as applicable.
• Permanent Account Number and Goods and Services Tax identification where applicable.
• Legal name and type of enterprise.
• Address, email address, and mobile number.
• Bank account number and bank routing details.
• Date of commencement and previous registration details, if any.
• Major activity, such as manufacturing or services.
• National Industrial Classification activity codes.
• Number of persons employed.
• Investment and turnover information, generally obtained or verified through linked government records.

Important benefits may include:

• Formal recognition as a micro, small, or medium enterprise.
• Eligibility to apply for specified government schemes and incentives.
• Access to certain credit-support or guarantee programs, subject to scheme conditions.
• Protection under applicable provisions relating to delayed payments.
• Eligibility for benefits in public procurement where government rules provide them.
• Possible support for technology, quality certification, intellectual property, or market development under relevant schemes.

The certificate does not automatically grant every benefit. Each loan, subsidy, tender preference, or incentive has separate eligibility requirements.

Blockchain can provide a shared, tamper-evident record of important software engineering and quality events.

A blockchain-based quality system may record hashes and metadata for:

• Approved requirements and requirement changes.
• Design-review decisions and approvals.
• Source-code commits and build outputs.
• Test cases, execution results, and defect records.
• Security-scan and compliance reports.
• Release approvals, deployment events, and software bills of materials.

Traceability improves because records can link a requirement to its change request, implementation commit, build, test evidence, approval, and release. Each event has an identity, timestamp, and cryptographic reference.

Transparency improves because authorized stakeholders share a consistent history of events rather than relying on separate records that may conflict. The append-only ledger also makes unauthorized retrospective alteration easier to detect.

Blockchain should usually store hashes, identifiers, signatures, and selected metadata. Large files and confidential artifacts should remain in controlled off-chain storage, with their hashes recorded on-chain. Blockchain proves that a particular record existed and has not been changed; it does not prove that the original record was correct.

A practical blockchain-based software quality framework can include the following components:

• Permissioned blockchain: Developers, testers, auditors, suppliers, customers, and release managers participate using controlled identities.
• Off-chain artifact repository: Requirements, source code, binaries, reports, and test evidence are stored in existing secured repositories.
• On-chain evidence: The ledger stores artifact hashes, timestamps, versions, ownership, approvals, and links among life-cycle records.
• Integration layer: Continuous integration, issue tracking, version control, and test tools automatically submit signed quality events.
• Smart contracts: Rules require specified reviews, successful tests, security checks, and approvals before a release status can be recorded.
• Access and governance controls: Policies define who may submit, validate, view, and correct records.

Benefits:

• End-to-end traceability from requirements to deployment.
• Tamper-evident audit evidence.
• Shared visibility across organizational boundaries.
• Automated enforcement of selected quality gates.
• Improved accountability and provenance.

Limitations and required controls:

• Incorrect input remains incorrect, even when immutably recorded.
• Privacy laws may conflict with permanent storage, so personal and confidential data should remain off-chain.
• Key loss or theft requires identity-recovery and revocation procedures.
• Smart-contract defects require review, testing, and controlled upgrade mechanisms.
• Performance, cost, governance, and interoperability must be assessed.
• Authorized correction transactions must supersede erroneous records without deleting audit history.

Blockchain is most justified when multiple parties require shared evidence but do not fully trust a single record owner.