BSc CSIT (TU) Science BIT Systems Analysis and Design (BIT253) – 4th Semester (Model) Question Paper 2079 Nepal

Why we need the SDLC

The System Development Life Cycle (SDLC) is a structured, phased framework for planning, building, deploying and maintaining an information system. We need it because:

• It provides a disciplined, repeatable process so projects are completed on time, within budget and to required quality.
• It improves communication and control between users, analysts, developers and management through clearly defined deliverables and milestones.
• It reduces risk by detecting errors early (each phase is reviewed before the next begins).
• It ensures the final system actually meets user requirements and is maintainable.

Phases of the SDLC

1. Planning (Project Identification & Selection) — Identify the business need or problem, define project scope and objectives, assess feasibility, and prepare a project plan with schedule and resources. Output: project plan / system request.
2. Analysis — Study the existing system and gather requirements through interviews, questionnaires, observation and document review. Model the requirements using DFDs, ER diagrams and process descriptions. Output: requirements specification / system proposal.
3. Design — Convert the what of analysis into the how. This covers logical and physical design: database design, input/output (forms and reports) design, interface design, architecture and program specifications. Output: design specification.
4. Implementation (Development / Construction) — Write and test the program code, build the database, and integrate components. Includes unit, integration and system testing. Output: tested, working system.
5. Deployment / Installation — Install the system in the production environment, convert data, train users, and choose a conversion strategy (direct, parallel, phased or pilot). Output: operational system in use.
6. Maintenance & Support — Correct defects (corrective), adapt to new environments (adaptive), enhance features (perfective) and prevent future problems (preventive). This is usually the longest and most costly phase. Output: an evolving, supported system.

Each phase ends with a review/sign-off, and the cycle may iterate as requirements change.

Feasibility study

A feasibility study is an evaluation, carried out during the analysis phase, that determines whether a proposed information system is worth developing — i.e. whether it is practical, achievable and beneficial within the available technical, financial, organisational and time constraints. Its goal is to decide go / no-go before major resources are committed.

Types of feasibility tests

1. Technical feasibility — Can the system be built with the available (or acquirable) technology, hardware, software and technical expertise? Assesses risk related to project size, technology familiarity and compatibility.
2. Economic feasibility (cost–benefit) — Do the expected benefits outweigh the costs? (Detailed below.)
3. Operational feasibility — Will the system work within the organisation and be accepted by users and management? Considers user attitudes, organisational changes and how well it solves the business problem.
4. Schedule (time) feasibility — Can the system be developed within the required time frame and deadlines?
5. Legal / political feasibility — Does the system comply with laws, regulations, contracts and organisational politics?

Measuring economic feasibility

Economic feasibility is measured through a cost–benefit analysis that compares all development and operating costs (hardware, software, personnel, training, maintenance) against the expected benefits (tangible: cost savings, increased revenue; intangible: better service, improved decisions). Common financial techniques are:

• Net Present Value (NPV):

where $B_t$ and $C_t$ are benefits and costs in year $t$ and $i$ is the discount rate. A positive NPV indicates economic feasibility.

• Return on Investment (ROI):

• Payback (break-even) period — the time taken for cumulative benefits to recover the initial investment; a shorter payback period is more favourable.

If NPV is positive, ROI is acceptable and the payback period is reasonable, the project is judged economically feasible.

Components of a Data Flow Diagram (DFD)

A DFD models how data moves through a system using four basic symbols:

1. Process (circle / rounded rectangle) — transforms incoming data into outgoing data. e.g. Process Sale. Labelled with a number and a verb-phrase.
2. Data flow (arrow) — represents movement of data between components; labelled with the data name. e.g. item details, receipt.
3. Data store (open-ended rectangle / two parallel lines) — where data is held for later use. e.g. Inventory, Sales Records.
4. External entity / source–sink (square) — a person, organisation or system outside the boundary that supplies or receives data. e.g. Customer, Supplier.

Context diagram (Level 0) for a retail store

A single process representing the whole system with its external entities:

  Customer  --(order / payment)-->  [ 0  Retail Store System ]  --(receipt / goods)-->  Customer
  Supplier  --(item supply)------>  [ 0  Retail Store System ]  --(purchase order)----> Supplier

External entities: Customer and Supplier. Single process: Retail Store System.

Level-1 Data Flow Diagram for the retail store

 Customer --item request--> ( 1 Process Sale ) --item details--> [ D1 Inventory ]
                            ( 1 Process Sale ) --payment-------> ( 2 Process Payment )
 ( 2 Process Payment ) --receipt--> Customer
 ( 1 Process Sale )    --sale record--> [ D2 Sales Records ]
 [ D1 Inventory ] --stock level--> ( 3 Manage Stock )
 ( 3 Manage Stock ) --purchase order--> Supplier
 Supplier --supplied items--> ( 3 Manage Stock ) --update--> [ D1 Inventory ]

Processes: (1) Process Sale, (2) Process Payment, (3) Manage Stock. Data stores: D1 Inventory, D2 Sales Records. External entities: Customer, Supplier.

When the customer requests an item, Process Sale checks the Inventory, records the sale in Sales Records, and passes the bill to Process Payment, which returns a receipt. Manage Stock monitors stock levels and raises purchase orders to the supplier, updating the inventory when goods arrive.

The spiral model, proposed by Barry Boehm, is a risk-driven, iterative software development approach that combines the iterative nature of prototyping with the systematic, controlled aspects of the waterfall model. Development proceeds in repeated loops (spirals), and each loop is divided into four quadrants:

1. Determine objectives — identify objectives, alternatives and constraints for the iteration.
2. Identify and resolve risks — evaluate alternatives, identify risks and reduce them, often by building a prototype.
3. Develop and test — design, code and test the product increment for that loop.
4. Plan the next iteration — review the results with stakeholders and plan the next spiral.

With each spiral the product grows more complete and the radius of the spiral represents the cumulative cost, while the angular dimension represents progress.

Advantages: strong emphasis on risk analysis, suitable for large, complex and high-risk projects, and accommodates changing requirements.

Disadvantages: costly, requires risk-assessment expertise, and may be overkill for small projects.

Project schedules show the tasks of a project, their durations, dependencies and the people responsible, so that progress can be planned and tracked. The two most common representation techniques are:

1. Gantt chart — a horizontal bar chart in which each task is a bar whose length represents its duration and whose position shows start and end dates. It clearly shows task overlap, current progress and milestones, but does not show task dependencies well.

2. PERT / CPM network diagram — a Program Evaluation and Review Technique / Critical Path Method network of nodes and arrows that shows tasks, their dependencies and the sequence of activities. It is used to estimate the project duration and to identify the critical path — the longest sequence of dependent tasks that determines the minimum project completion time. PERT also handles uncertainty in estimates using:

where $t_o$, $t_m$, $t_p$ are the optimistic, most-likely and pessimistic times.

Network rules identify earliest/latest start and finish times and the slack/float of each activity (activities on the critical path have zero slack).

In practice analysts combine both: a Gantt chart for an at-a-glance timeline and a PERT/CPM diagram for dependencies and the critical path.

Project initiation and planning (PIP) is the first phase of the SDLC, where a candidate project is assessed and a detailed plan is prepared. The main activities are:

1. Establish the project initiation team — form the team and define roles and reporting relationships.
2. Establish a relationship with the customer/users — build mutual understanding and trust with the business stakeholders.
3. Establish the project initiation plan — define scope, objectives and the approach for the project.
4. Establish management procedures — set up communication, reporting, change-control, budgeting and staffing procedures.
5. Establish the project management environment and workbook — set up tools, standards and a repository of project documentation.
6. Develop the project plan — describe activities, estimate resources and effort, and prepare the schedule (e.g. Gantt/PERT).
7. Assess project feasibility — perform technical, economic, operational, schedule and legal feasibility studies.
8. Build the baseline project plan and statement of work (SOW) — a baseline plan summarising scope, benefits, costs, risks and resources, and an SOW that is a contract-like description of deliverables, which are reviewed and approved before the analysis phase begins.

Joint Application Design (JAD) is a structured, collaborative technique for gathering information requirements in which key users, managers and systems analysts meet together in intensive, facilitated workshop sessions to jointly define and agree on system requirements — instead of the analyst interviewing each person separately.

Participants / roles:

• JAD facilitator — leads and manages the session, keeps it on track and neutral.
• Users and managers — provide and validate the business requirements.
• Systems analysts — learn the requirements and contribute technical input.
• Scribe / recorder — documents the discussion, decisions and requirements.
• Sponsor — a senior manager who champions and funds the project.

Process: sessions are held in a dedicated room (often off-site) over consecutive days, using agendas, whiteboards, CASE tools and prototypes to capture and immediately validate requirements.

Advantages: gathers requirements quickly, resolves conflicts on the spot, increases user ownership and acceptance, and reduces the time and cost of separate interviews.

Disadvantages: difficult to schedule everyone together, requires a skilled facilitator and can be expensive in people-time.

Why we need an ER diagram

An Entity–Relationship (ER) diagram is a conceptual data model that graphically shows the data requirements of a system — the entities, their attributes and the relationships among them. It is needed because it:

• Provides a clear, technology-independent picture of the data that both users and developers can understand and validate.
• Acts as a blueprint for database design; it is later mapped to relational tables with primary and foreign keys.
• Helps identify entities, attributes, keys and relationships (cardinality) early, reducing redundancy and design errors.
• Improves communication between analysts and stakeholders.

Example

For a college system, consider entities STUDENT and COURSE:

• STUDENT (attributes: Student_ID [key], Name, Address)
• COURSE (attributes: Course_ID [key], Title, Credit)
• Relationship: a student ENROLLS in courses.

 [STUDENT] ---<  ENROLLS  >--- [COURSE]
   M                              N

This is a many-to-many (M:N) relationship: one student can enrol in many courses and one course can have many students. When implemented, the M:N relationship becomes a separate ENROLLMENT table holding Student_ID and Course_ID as foreign keys. This shows how the ER diagram directly guides the database structure of the information system.

Importance of software testing

Software testing is the process of executing a system to find defects and verify that it meets requirements. It is important because it:

• Detects errors and defects before the software is delivered, improving reliability and quality.
• Verifies that requirements are met (the system does what users need).
• Reduces cost and risk — errors found early are far cheaper to fix than those found after deployment.
• Builds user confidence and ensures security, performance and correctness.

Three software testing techniques

1. Unit testing — each individual module/program component is tested in isolation, usually by the developer, to confirm it works correctly on its own.
2. Black-box (functional) testing — the tester examines inputs and outputs without knowledge of the internal code, checking the software against its functional specification (e.g. boundary value analysis, equivalence partitioning).
3. White-box (structural) testing — the tester uses knowledge of the internal logic and code structure to design test cases that exercise paths, branches and conditions (e.g. statement and branch coverage).

(Other valid techniques include integration testing, system testing and acceptance testing.)

Forms (used to enter/display a single record) and reports (used to present summarised business information) must be formatted so they are clear, usable and professional. General formatting guidelines are:

1. Meaningful titles and headings — every form/report should have a clear, descriptive title; reports should also show date, page number and report/run-time.
2. Logical and consistent layout — group related fields together, follow a natural reading order (left-to-right, top-to-bottom), and align labels and fields neatly.
3. Clear labels and captions — label each field unambiguously and indicate required fields and formats (e.g. date format).
4. Consistent use of fonts, colour and spacing — use highlighting (bold, colour, boxes) sparingly to draw attention, and leave adequate white space to avoid clutter.
5. Proper data formatting — align numbers to the right, use appropriate decimal places, currency and date formats, and use tables/columns with headings and totals in reports.
6. Navigation and usability — provide clear navigation, error/validation messages and default values on forms; reports should provide subtotals, grand totals and summaries.
7. Guidelines for reports specifically — meaningful sort order, control breaks/grouping, page breaks, and clear distinction between detail and summary lines.

Good formatting improves readability, reduces data-entry errors and makes information easier to interpret.

Benefits of an object-oriented database (OODB)

An OODB stores data as objects, the same way they are represented in an object-oriented programming language. Its benefits include:

1. Handles complex data — supports complex, nested and multimedia data types (graphics, audio, CAD, etc.) better than relational databases.
2. Seamless integration with OOP — objects map directly to program objects, eliminating the impedance mismatch between code and database and reducing the need for conversion.
3. Supports OO features — inheritance, encapsulation, polymorphism and reusability are supported, improving modelling power and reuse.
4. Improved performance for complex relationships — navigating object references can be faster than relational joins for highly interconnected data.
5. Easier maintenance and extensibility — real-world entities are modelled naturally, making schemas easier to understand and extend.

Object identity

Object identity is the property by which each object in an OODB is given a unique, system-generated identifier (OID) that distinguishes it from every other object, independent of its attribute values.

• The OID never changes during the object's lifetime, even if the object's attribute values change.
• Two objects can have identical attribute values yet still be different objects (they have different OIDs), and objects can reference one another through these identifiers.

This is different from relational databases, which identify rows by user-defined primary-key values rather than by an immutable system identity.

a. Object-Oriented Development

Object-oriented (OO) development is a system development approach in which the system is modelled as a collection of interacting objects rather than as separate data and processes. Each object combines data (attributes) and behaviour (methods) together (encapsulation). Key concepts are:

• Class & object — a class is a template; objects are instances of it.
• Encapsulation — hiding internal data behind a public interface.
• Inheritance — new classes reuse and extend existing ones.
• Polymorphism — the same operation behaves differently on different objects.

OO analysis and design use UML (use-case, class, sequence and state diagrams). Benefits: reusability, easier maintenance, and a natural mapping to real-world entities.

b. System Maintenance

System maintenance is the final and longest phase of the SDLC, covering all changes made to a system after it goes into operation, to keep it useful and error-free. Its main types are:

• Corrective maintenance — fixing errors/bugs discovered after deployment.
• Adaptive maintenance — modifying the system to work in a new or changed environment (hardware, OS, regulations).
• Perfective maintenance — enhancing performance or adding new features requested by users.
• Preventive maintenance — making changes to prevent future problems and improve maintainability.

Maintenance typically consumes the largest share of total system cost over the software's life.