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

Agile Development Methodology

Agile is an iterative and incremental approach to software development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Rather than delivering the complete system at the end, software is built and delivered in small, frequent increments (iterations/sprints), typically lasting 1–4 weeks.

Core values (Agile Manifesto)

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Key principles / characteristics

• Customer involvement: customers are closely involved throughout and provide continuous feedback.
• Incremental delivery: software is developed in increments; the customer specifies requirements for each increment.
• Embrace change: the system is designed to accommodate changing requirements.
• People, not process: team skills and self-organization are valued over rigid process.
• Maintain simplicity: focus on simplicity in both the software and the process.

Popular agile methods include Scrum, Extreme Programming (XP), Kanban, and Feature-Driven Development (FDD).

Plan-Driven vs Agile Approaches

In a plan-driven approach, all process activities (specification, design, implementation, testing) are planned in advance and progress is measured against this plan. In an agile approach, planning is incremental and it is easier to change the process to reflect changing customer requirements.

In practice most projects use a mix of both, e.g. an overall plan-driven structure with agile development inside increments.

Architectural Design Process

Software architecture is the fundamental organization of a system: its components, their relationships, and the principles governing its design. Architectural design is the process of identifying the sub-systems making up a system and the framework for sub-system control and communication. It is the critical link between requirements engineering and detailed design.

Key design decisions (questions to answer)

• Is there a generic application architecture that can act as a template?
• How will the system be distributed across processors?
• What architectural patterns/styles are appropriate?
• What will be the fundamental approach used to structure the system?
• How will the structural components be decomposed into sub-components?
• How will the architecture be documented (using views)?

Architecture in use

The design is usually documented using several architectural views: logical, process, development, and physical (the 4+1 view model). Good architecture affects the system's non-functional properties: performance, security, safety, availability, and maintainability.

Common Architectural Patterns

1. Layered (N-tier) Architecture

Organizes the system into layers, each providing services to the layer above (e.g., presentation, business logic, data access).

• Advantages: supports incremental development; layers can be replaced independently; portability (only the lowest layer changes for a new platform).
• Disadvantages: clean separation is often hard; performance overhead as requests pass through many layers.

2. Repository (Data-centred) Architecture

All shared data is held in a central repository accessed by all components.

• Advantages: components are independent; consistent data management; easy to share large volumes of data.
• Disadvantages: single point of failure (the repository); data evolution is difficult and costly; may be a performance bottleneck.

3. Client–Server Architecture

Functionality is organized into services, with servers providing services and clients consuming them over a network.

• Advantages: distribution of data and processing is straightforward; servers can be added or upgraded easily.
• Disadvantages: each service is a single point of failure; performance depends on the network; management can be complex if servers are owned by different organizations.

4. Pipe-and-Filter Architecture

Data flows through a sequence of processing components (filters) connected by pipes; each transforms its input.

• Advantages: easy to understand; supports transformation reuse; matches many business processes; easy to add new transformations.
• Disadvantages: common data format must be agreed by all filters; not suited to interactive systems.

5. Model-View-Controller (MVC)

Separates presentation/interaction (View, Controller) from the system data (Model).

• Advantages: data can be changed independently of its representation; supports multiple views of the same data.
• Disadvantages: can add extra code and complexity for simple data models.

Software Project Management

Software project management is the set of activities concerned with ensuring that software is delivered on time, within budget, and to the required quality while meeting organizational goals. It is needed because software is intangible, projects are often one-off, and software processes are variable and organization-specific.

Main management activities

• Project planning – estimating effort, cost, and schedule; defining tasks.
• Risk management – identifying and mitigating risks.
• People management – team selection and motivation.
• Reporting – communicating progress to stakeholders.
• Proposal writing – describing objectives and how work will be carried out.

Project Scheduling

Project scheduling is the process of deciding how the work of a project will be organized as separate tasks (activities), and when and how these tasks will be executed. The manager estimates the time and resources required to complete activities and organizes them into a coherent sequence.

Scheduling steps:

1. Split the project into tasks and estimate the time and resources for each.
2. Identify dependencies between tasks (which must finish before others start).
3. Allocate people to tasks.
4. Create charts showing the schedule.
5. Set milestones (end-points of process activities) and deliverables (project results delivered to the customer).

Bar Charts (Gantt Charts)

A bar chart shows the project calendar and the start/end dates of activities. Each task is drawn as a horizontal bar whose length is proportional to its duration, positioned against a time axis. It clearly shows which tasks run in parallel, the slack/float time, and overall project duration. It is excellent for communicating the schedule and tracking progress.

Activity Networks

An activity network (e.g., PERT/CPM chart) shows the task dependencies and the critical path through the project. Tasks are shown as nodes (or edges) linked by arrows indicating precedence.

• It identifies the critical path – the longest path of dependent activities, which determines the minimum project duration. Any delay on a critical-path task delays the whole project.
• Tasks not on the critical path have slack time.

Relationship: the activity network is used to compute the critical path and earliest/latest start times; this information is then displayed on a bar (Gantt) chart for scheduling and progress monitoring.

Black-box testing (functional / behavioural testing) tests the software without any knowledge of its internal code or structure. Test cases are derived from the specification/requirements: given certain inputs, the tester checks that the outputs are correct. Techniques include equivalence partitioning and boundary value analysis. It is usually done by testers and validates what the system does.

White-box testing (structural / glass-box testing) tests the software with full knowledge of the internal code, logic, and structure. Test cases are designed to exercise specific paths, branches, and statements so as to achieve high code coverage. Techniques include statement, branch, and path coverage. It is usually done by developers and validates how the system works.

Reuse-based software engineering is a software development approach in which the process is geared toward reusing existing software assets rather than developing everything from scratch. Reusable assets include functions, objects, components, patterns, frameworks, libraries, COTS (commercial off-the-shelf) systems, and entire application product lines. This is now the standard approach for building many types of business systems.

Benefits of reuse

• Increased dependability / reliability: reused software has already been tried and tested in working systems, so it is more reliable.
• Reduced process risk: the cost of existing software is already known, reducing uncertainty in estimates.
• Effective use of specialists: experts develop reusable components instead of repeating the same work on each project.
• Standards compliance: reusing components that embody standards (e.g., a common UI) improves consistency and usability.
• Accelerated / faster development: less software to write means systems are delivered sooner, reducing development time and cost.

Problems (briefly)

Increased maintenance costs if source is unavailable, lack of tool support, the not-invented-here syndrome, and the cost of finding, understanding, and adapting reusable components.

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 of how to solve a problem that can be used in many different situations. Patterns capture the experience and best practices of expert object-oriented designers, making designs more flexible, reusable, and maintainable. They were popularized by the Gang of Four (GoF).

Elements of a pattern

1. Name – a meaningful reference (e.g., Observer).
2. Problem – the situation in which the pattern applies.
3. Solution – the design elements and their relationships.
4. Consequences – the results and trade-offs of applying it.

Patterns are grouped into Creational (e.g., Singleton, Factory), Structural (e.g., Adapter, Facade), and Behavioural (e.g., Observer, Strategy).

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 notified and updated automatically. It decouples the state of an object from its display.

Use case: a spreadsheet where the same data is shown as a table and a chart. When the underlying data (subject) changes, both views (observers) update automatically without the data object knowing the details of each view.

Subject  --> attach(observer), notify()
Observer --> update()  // each view implements update()

This avoids tight coupling between the data and its multiple presentations.

Software Quality Assurance (SQA)

Software Quality Assurance is a set of planned and systematic activities carried out throughout the software process to ensure that the software conforms to its requirements and quality standards. SQA focuses on the process (preventing defects) as well as the product, defining the standards, procedures, and methods to be used and checking that they are followed.

SQA activities include defining quality standards, conducting reviews and inspections, testing, auditing the process, measuring quality metrics, and reporting.

Importance of SQA

• Ensures conformance to requirements and customer expectations, increasing customer satisfaction.
• Detects defects early, reducing the much higher cost of fixing them later.
• Improves reliability and maintainability of the delivered software.
• Reduces overall cost and rework by preventing defects rather than only correcting them.
• Builds confidence and reputation, ensuring the product meets standards and is delivered on time.
• Provides a measurable, repeatable process that can be continuously improved.

Note: QA (prevention, process-oriented) differs from QC/testing (detection, product-oriented).

Verification and validation (V&V) are the two complementary processes used to check and analyse software to ensure it is correct and fit for purpose.

• Verification: "Are we building the product right?" It checks whether the software conforms to its specification and that each phase's output meets the conditions imposed at the start of that phase. It is done without executing the code, mainly through reviews, inspections, and walkthroughs.

• Validation: "Are we building the right product?" It checks whether the software actually meets the customer's real needs and expectations. It is done by executing the software, mainly through testing the final product.

Waterfall Model

The waterfall model is the classical, plan-driven (sequential) software process model in which development flows steadily downwards through a fixed series of phases, like a waterfall. Each phase must be completed and signed off before the next begins, and the output of one phase becomes the input to the next.

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 phases are sequential; in practice there is some feedback to earlier phases, but iteration is costly.

Limitations

• Inflexible to change: difficult and expensive to accommodate changing requirements once a phase is complete, since the plan is fixed early.
• Requirements frozen too early: the customer must state all requirements upfront, which is rarely realistic.
• No working software until late: a usable product appears only near the end of the life cycle, delaying feedback.
• High risk and uncertainty: errors made early are detected only in later phases, making them costly to fix.
• Poor for complex / long projects and not suitable where requirements are unclear or volatile.
• Limited customer involvement during development.

It is best suited only for projects with stable, well-understood requirements.

Software Re-engineering

Software re-engineering is the process of examining, understanding, and modifying an existing legacy system to reconstitute it in a new form, and then re-implementing that new form, in order to improve its structure, maintainability, and quality without changing its core functionality. It restructures or rewrites part or all of a legacy system, making it easier and cheaper to maintain.

Why re-engineer?

• Reduced risk and cost compared to redeveloping the system from scratch.
• To remove the problems of poorly structured, hard-to-maintain legacy code.
• To preserve business value captured in the existing system.

Typical activities (re-engineering process)

1. Source code translation – convert code to a newer language/version.
2. Reverse engineering – analyse the program to understand and recover its design/documentation.
3. Program structure improvement – restructure code for readability.
4. Program modularisation – reorganise the program structure into modules.
5. Data re-engineering – clean up and restructure the system's data.

Advantages: lower risk and cost, preserves functionality. Disadvantages: practical limits — re-engineered systems are usually less maintainable than newly built ones, and architectural problems cannot always be fixed.

Requirements for a Library Management System

Functional requirements describe what the system should do — the services, functions, and behaviour it provides. Non-functional requirements describe constraints and quality attributes on those services (how well the system performs), often relating to the system as a whole.

Functional Requirements (what the system does)

• The system shall allow a member to search the catalogue by title, author, or ISBN.
• The system shall allow a member to issue/borrow a book if copies are available.
• The system shall record returns and update the book's availability status.
• The system shall calculate and apply fines for books returned after the due date.
• The librarian shall be able to add, update, and delete book and member records.
• The system shall allow members to reserve a book that is currently issued.
• The system shall generate reports (issued books, overdue books, member lists).
• The system shall support user authentication/login for members and librarians.

Non-Functional Requirements (qualities/constraints)

• Performance: a catalogue search shall return results within 2 seconds.
• Reliability/Availability: the system shall be available 99% of working hours.
• Security: passwords shall be stored encrypted; only authorized staff can modify records.
• Usability: the interface shall be simple enough for a new member to issue a book without training.
• Scalability: the system shall support at least 10,000 members and 50,000 book records.
• Portability: the system shall run on standard web browsers.
• Maintainability: the system shall be modular to allow easy updates.

Role of CASE Tools

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

Classification

• Upper-CASE tools: support early phases — requirements analysis and design (e.g., diagramming/modelling tools, data dictionaries).
• Lower-CASE tools: support later phases — implementation, testing, and maintenance (e.g., code generators, debuggers, test tools).
• Integrated (I-CASE): combine both across the whole life cycle.

Roles / functions of CASE tools

• Diagramming/modelling — draw UML, DFDs, ER diagrams and system models.
• Analysis and design support — check models for consistency and completeness.
• Code generation — automatically generate code from design models.
• Documentation — produce and maintain consistent documentation.
• Project management — support estimation, scheduling, and tracking.
• Configuration and version management — control changes and versions.
• Testing and debugging — automate test execution and defect detection.

Benefits

Increased productivity, improved quality and consistency, reduced cost and time, better standardisation, and easier maintenance.