BSc CSIT (TU) Science Software Engineering (BSc CSIT, CSC364) Question Paper 2078 Nepal

Configuration Management

Software Configuration Management (SCM) is the set of activities and tools used to manage and control the evolving versions of a software system and its components. As a system is developed and maintained, many different versions of components and the whole system are created. SCM ensures that changes are made in a controlled, traceable way so that the project does not become unmanageable.

The main goals of SCM are to identify configuration items, control changes to them, track their status, and audit the configuration.

1. Version Management (Version Control)

Version management keeps track of the different versions of software components and supports teams working in parallel.

• A version control system (VCS) (e.g., Git, Subversion) stores every version of a component in a repository.
• Developers check out a copy, make changes in their working area, and check in / commit the changes back, creating a new version.
• It supports branching (parallel lines of development) and merging (combining branches), allowing several developers to work without overwriting each other's work.
• It records who changed what and when, providing an audit trail and the ability to roll back to an earlier version.

2. System Building

System building is the process of assembling program components, data, and libraries and compiling/linking them into an executable system for a target platform.

• Automated build tools (e.g., Make, Maven, Gradle, Ant) read a build configuration and produce the executable.
• The build process must ensure the correct versions of all components are used (consistency with the VCS).
• Continuous Integration (CI) automatically builds and tests the system whenever changes are committed, detecting integration problems early.

3. Change Management

Change management is the systematic process of proposing, evaluating, approving, implementing, and tracking changes to a system after it is in use.

• A Change Request Form (CRF) is submitted describing the required change.
• A Change Control Board (CCB) assesses the cost, impact, and benefit of the change and decides whether to accept or reject it.
• Approved changes are scheduled, implemented, tested, and recorded.
• This avoids uncontrolled, ad-hoc modifications and keeps the system stable and traceable.

Conclusion

Together, version management, system building, and change management provide a disciplined framework that controls evolution of software, prevents confusion among multiple versions, and ensures the right components are built and released.

Software Process Model

A software process is a set of related activities that lead to the production of a software product. A software process model is an abstract, simplified representation of a software process, presented from a particular perspective. It describes the activities, their ordering, and how they fit together. Examples of process models include the Waterfall model, Incremental development, Spiral model, and Reuse-oriented (integration and configuration) model.

A process model is useful because it gives a common framework that teams can follow, plan, and manage.

The Four Fundamental Process Activities

Almost all software processes include four common activities:

1. Software Specification (Requirements Engineering)

The process of understanding and defining what services are required and identifying the constraints on the system's operation and development.

• Sub-activities: feasibility study, requirements elicitation and analysis, requirements specification, and requirements validation.
• Example: For an online banking app, gathering requirements such as "a user must be able to transfer funds" and "the system must respond within 2 seconds."

2. Software Design and Implementation

The process of converting the specification into an executable system.

• Design defines the software structure (architecture, interfaces, components, data models); implementation is coding.
• Example: Designing the database schema and class structure for the banking app, then writing the code in Java.

3. Software Validation (Verification and Validation)

The process of checking that the system conforms to its specification and meets the customer's needs.

• Includes component testing, integration testing, system testing, and acceptance testing.
• Example: Testing that a fund transfer correctly debits one account and credits another, and that invalid transfers are rejected.

4. Software Evolution (Maintenance)

The process of modifying the software to meet changing requirements after delivery.

• Includes fixing defects, adapting to new environments, and adding new features.
• Example: Updating the banking app to support a new currency or to comply with a new regulation.

Conclusion

Different process models organise these four activities in different ways (sequentially, iteratively, etc.), but every model must address specification, design/implementation, validation, and evolution.

UML Models for an Online Book Recommendation System

Below the three diagrams are described in words (since they cannot be drawn here) with their key elements; a student should draw them using standard UML notation.

1. Use Case Diagram

Actors: User/Reader, Administrator, and an external Recommendation Engine (or system).

Use cases (ovals) connected to actors:

• User: Register/Login, Search Books, View Book Details, Rate/Review Book, Get Recommendations, Add to Wishlist.
• Administrator: Manage Book Catalogue, Manage Users, View Reports.
• Get Recommendations <<include>> View Reading History (recommendations are based on history/ratings).

Notation: actors as stick figures on the outside; use cases as ovals inside the system boundary rectangle labelled "Book Recommendation System".

  (Register/Login)
  (Search Books)
User --- (Rate Book)
  (Get Recommendations) --<<include>>--> (View History)
  (Manage Catalogue)
Admin --- (Manage Users)

2. Class Diagram

Key classes with attributes and key associations:

Relationships:

• User 1 ---- * Rating (a user gives many ratings)
• Book 1 ---- * Rating (a book receives many ratings)
• RecommendationEngine produces Recommendation for a User based on Rating and Book.
• Recommendation * ---- * Book (a recommendation lists books).

3. Sequence Diagram (Scenario: "Get Recommendations")

Lifelines: User, UI/System, RecommendationEngine, Database.

Message sequence (top to bottom):

1. User → UI: requestRecommendations()
2. UI → RecommendationEngine: getRecommendations(userId)
3. RecommendationEngine → Database: fetchUserRatings(userId)
4. Database → RecommendationEngine: returns ratings/history
5. RecommendationEngine → RecommendationEngine: computeRecommendations()
6. RecommendationEngine → Database: fetchBooks(bookIds)
7. Database → RecommendationEngine: returns book list
8. RecommendationEngine → UI: returns recommended books
9. UI → User: displayRecommendations()

Notation: vertical dashed lifelines with activation bars; solid arrows for calls and dashed arrows for return messages.

Conclusion

The use case diagram captures what the system does, the class diagram captures its static structure, and the sequence diagram captures the dynamic interaction for the recommendation scenario.

Black-Box vs White-Box Testing

Black-Box Testing (Functional Testing): The system is tested without knowledge of its internal structure or code. Test cases are derived only from the specification — the tester provides inputs and checks whether the outputs match the expected results. It focuses on what the software does.

• Techniques: Equivalence partitioning, Boundary value analysis, Decision tables, State transition testing.
• Example: Testing a login form by trying valid and invalid username/password combinations without seeing the code.

White-Box Testing (Structural / Glass-Box Testing): The system is tested with full knowledge of its internal logic and code. Test cases are designed to exercise paths, branches, statements, and conditions in the code. It focuses on how the software works.

• Techniques: Statement coverage, Branch/decision coverage, Path coverage, Condition coverage.
• Example: Designing tests so that every if-else branch in a function is executed at least once.

Key Differences

Reuse-Based Software Engineering

Reuse-based (reuse-oriented) software engineering is an approach in which software is built by reusing existing software assets — such as components, libraries, frameworks, design patterns, or whole systems (COTS) — rather than developing everything from scratch. Reuse can occur at different levels: the abstraction level (design patterns), object/component level, and system level (configuring an off-the-shelf system).

The typical process is: outline requirements → search for and evaluate reusable components → adapt requirements to fit available components → develop and integrate the system using these components.

Benefits of Reuse

1. Increased reliability — reused components have already been tested and used in working systems.
2. Reduced development cost — less new code has to be written.
3. Faster delivery (reduced time to market) — development is quicker.
4. Reduced process risk — cost of existing components is known, lowering uncertainty.
5. Effective use of specialists — expert knowledge is packaged once in a reusable component and used by many.
6. Standards compliance — standards (e.g., UI standards) can be embedded in reusable components.

Limitations (brief)

Increased maintenance cost if source is unavailable, lack of tool support, and the "not-invented-here" syndrome.

Design Patterns

A design pattern is a general, reusable solution to a commonly occurring problem in software design within a given context. It is not finished code but a description or template that can be applied in many situations. Patterns capture the experience of expert designers and provide a common vocabulary.

The "Gang of Four" classified design patterns into three categories:

• Creational patterns – object creation (e.g., Singleton, Factory, Builder).
• Structural patterns – composition of classes/objects (e.g., Adapter, Composite, Facade).
• Behavioural patterns – interaction and responsibility (e.g., Observer, Strategy, Iterator).

A pattern is usually described by four essential elements: name, problem, solution, and consequences.

Example: Observer Pattern

The Observer pattern defines a one-to-many dependency so that when one object (the Subject) changes state, all its dependents (Observers) are automatically notified and updated.

Scenario: In a spreadsheet, a data model is the Subject, and a bar chart, pie chart, and table are Observers. When the data changes, all the views update automatically.

Subject
  + attach(Observer)
  + detach(Observer)
  + notify()   // calls update() on all observers
Observer
  + update()

This decouples the subject from its observers, so new views can be added without changing the subject. Design patterns thus improve reusability, flexibility, and maintainability of designs.

Software Quality Assurance (SQA)

Software Quality Assurance is the set of planned and systematic activities applied throughout the software process to ensure that the software product and the process used to build it conform to defined standards and requirements. SQA is process-oriented and preventive — it focuses on improving the process so that defects are avoided, rather than just finding defects after the fact (which is the role of quality control/testing).

SQA activities include: defining standards and procedures, conducting reviews and audits, process monitoring, configuration management, and verification & validation.

Importance of SQA

1. Ensures the product meets requirements and satisfies the customer.
2. Reduces cost by detecting and preventing defects early, when they are cheaper to fix.
3. Improves reliability and maintainability of the product.
4. Builds confidence and trust of customers and stakeholders.
5. Ensures compliance with standards (e.g., ISO 9001, CMMI), aiding consistency.
6. Improves the process continuously, leading to better products over time.

Verification vs Validation

Verification: "Are we building the product right?" Verification checks whether the software conforms to its specification — i.e., the output of a phase meets the requirements/conditions set at the start of that phase. It checks consistency between products of successive phases.

Validation: "Are we building the right product?" Validation checks whether the software meets the customer's actual needs and expectations — i.e., that the implemented system does what the user really wants.

Key Differences

Both together are called V&V, and both are essential to deliver a correct and useful system.

Waterfall Model

The Waterfall model is the classic, linear-sequential software process model in which the development is divided into distinct phases that are carried out one after another, with the output of each phase flowing down into the next (like a waterfall). A phase should ideally be completed and signed off before the next begins.

Phases

1. Requirements Analysis and Definition
2. System and Software Design
3. Implementation and Unit Testing
4. Integration and System Testing
5. Operation and Maintenance

In principle, one phase must be completed before moving to the next, though limited feedback to earlier phases is sometimes allowed.

Limitations

1. Inflexible to change — it is difficult and costly to accommodate changes once a phase is complete, because requirements are frozen early.
2. Late working software — a working product is not available until late in the life cycle, so errors are found late and are expensive to fix.
3. Poor for unclear requirements — it assumes requirements are fully known at the start, which is rarely true in practice.
4. High risk and uncertainty for large, long, ongoing projects.
5. No early customer feedback, increasing the chance of building the wrong product.

Suitability

It is appropriate only when requirements are stable, well-understood, and unlikely to change, e.g., some embedded or safety-critical systems.

Software Re-engineering

Software re-engineering is the process of examining, analysing, and restructuring an existing legacy system to reconstitute it in a new form and subsequently maintaining or implementing that new form. The goal is to improve the system's structure, understandability, and maintainability without changing its external functionality.

Re-engineering is applied to legacy systems that are still business-critical but have become difficult and expensive to maintain due to ageing, poor documentation, and degraded structure. It is generally cheaper and less risky than rewriting the system from scratch.

Typical Re-engineering Activities

1. Source code translation — converting code to a newer language/version.
2. Reverse engineering — analysing the program to recover its design and documentation.
3. Program structure improvement — restructuring control logic for clarity.
4. Program modularisation — reorganising related parts into modules.
5. Data re-engineering — cleaning up and restructuring the system's data.

Benefits

• Reduced risk and cost compared to redevelopment, and improved maintainability while preserving existing business knowledge embedded in the system.

Requirements for a Library Management System

Functional Requirements

These describe what the system should do — the specific services/functions provided.

1. The system shall allow a librarian to add, update, and delete book records.
2. The system shall allow members to search the catalogue by title, author, ISBN, or subject.
3. The system shall allow a member to issue (borrow) a book and record the due date.
4. The system shall allow return of books and calculate fines for late returns.
5. The system shall support member registration, login, and management.
6. The system shall allow reservation of books that are currently issued.
7. The system shall generate reports (e.g., issued books, overdue list, inventory).

Non-Functional Requirements

These describe how well the system performs — constraints and quality attributes.

1. Performance: A catalogue search should return results within 2 seconds.
2. Security: Only authenticated and authorised users (librarian/member) can access their permitted functions; passwords stored encrypted.
3. Reliability/Availability: The system should be available 99% of the time during library hours.
4. Usability: The interface should be simple enough for a new member to issue a book without training.
5. Scalability: The system should support at least, say, 10,000 members and 50,000 books.
6. Portability/Compatibility: It should run on standard web browsers.

Note

Functional requirements define services, while non-functional requirements define quality constraints on those services.

Role of CASE Tools in Software Engineering

CASE (Computer-Aided Software Engineering) tools are software applications that support and automate the activities of the software development process, from requirements through to maintenance. They increase productivity, improve quality, and reduce manual, error-prone effort.

Classification

• Upper CASE tools support early phases — planning, requirements analysis, and design (e.g., diagramming and modelling tools).
• Lower CASE tools support later phases — coding, testing, and maintenance (e.g., debuggers, code generators, test tools).
• Integrated CASE (I-CASE) tools support the whole life cycle with shared repositories.

Roles / Functions of CASE Tools

1. Modelling and diagramming — drawing UML, DFDs, ER diagrams (e.g., enforcing notation rules and consistency).
2. Requirements management — capturing and tracing requirements.
3. Code generation — generating skeleton/source code from design models.
4. Reverse engineering — producing design models from existing code.
5. Documentation — automatically generating and maintaining documents.
6. Project management — scheduling, estimation, and tracking.
7. Testing and debugging support, and configuration/version management.

Benefits

Improved productivity and quality, better consistency and documentation, easier maintenance, and reduced development time and cost. Examples include Rational Rose, Enterprise Architect, and Visual Paradigm.