MCS-014 Systems Analysis and Design - Sample Paper Solved (BCA Syllabus)

1. (d) What are CASE Tools ? Explain the role of CASE Tools in technical and managerial aspects of software development process. List advantages and disadvantages of CASE Tools. (10 marks)

Answer:

CASE (Computer-Aided Software Engineering) Tools are software applications designed to assist and automate various activities throughout the System Development Life Cycle (SDLC)[citation:2][citation:4]. They provide a framework for organizing projects, supporting tasks like requirements analysis, system modeling, design, code generation, testing, and documentation[citation:2]. Their primary goal is to improve productivity, ensure consistency, reduce errors, and help develop high-quality, maintainable software[citation:2][citation:10].

Role in Technical Aspects:
→ Automation of Design & Modeling: Upper CASE tools help create precise Data Flow Diagrams (DFDs), Entity-Relationship Diagrams (ERDs), and UML models, ensuring they follow standard rules and are consistent[citation:2][citation:7].
→ Code Generation & Implementation: Lower CASE tools can automatically generate program code from design specifications, reducing manual coding effort and errors[citation:2][citation:8].
→ Quality Assurance: Tools provide features for automated testing, debugging, and code analysis, helping identify defects early in the development cycle[citation:3][citation:9].
→ Maintenance & Reverse Engineering: They assist in maintaining and updating systems, and can reverse-engineer existing code into design models for understanding legacy systems[citation:8].

Role in Managerial Aspects:
→ Project Planning & Tracking: CASE tools offer features for task scheduling, resource allocation, progress monitoring, and milestone tracking, aiding in effective project management[citation:3][citation:4].
→ Standardization & Control: They enforce a single design philosophy and consistent methodologies across development teams, improving coordination and control[citation:7][citation:8].
→ Documentation & Communication: Automated generation of consistent, up-to-date documentation (plans, reports, manuals) improves communication among stakeholders and supports knowledge management[citation:1][citation:3].
→ Risk Management: By providing better visibility into project status and potential issues early, CASE tools help managers identify and mitigate risks[citation:3].

Advantages of CASE Tools:
1. Increased Productivity: Automation of repetitive tasks (diagramming, coding, documentation) speeds up development[citation:1][citation:9].
2. Improved Software Quality: Early error detection, consistency checks, and adherence to standards lead to fewer defects[citation:1][citation:2].
3. Better & Consistent Documentation: Automatically generated documentation is accurate, consistent, and always current[citation:1][citation:4].
4. Enhanced Collaboration: A centralized repository and visual models improve communication between technical teams and non-technical stakeholders[citation:1][citation:4].
5. Reduced Maintenance Effort: Systematic development and good documentation make software easier to maintain and modify[citation:1][citation:8].

Disadvantages of CASE Tools:
1. High Cost: Significant investment is required for software licenses, training, maintenance, and potential hardware upgrades, often prohibitive for small organizations[citation:2][citation:4].
2. Steep Learning Curve: Tools can be complex, requiring substantial time and resources for training before teams become proficient[citation:2][citation:4].
3. Resistance to Change: Staff may resist using new tools due to fear of job displacement or preference for traditional methods[citation:7].
4. Unrealistic Expectations: Organizations may expect CASE tools to be a "silver bullet" for all development problems, leading to disappointment if not managed properly[citation:10].
5. Integration Issues: CASE tools may not integrate smoothly with existing tools, platforms, or databases, causing workflow disruptions[citation:4][citation:5].

2. (a) Prepare an outline of SRS for an “Online Examination System”. Make necessary assumptions. (10 marks)

Answer:

Assumptions: The system is for a university/college, supporting multiple-choice, true/false, and short answer questions. It includes roles for Administrator, Examiner, and Student. Features include timed exams, auto-submission, basic plagiarism checks, and immediate result generation for objective questions.

Software Requirements Specification (SRS) Outline for Online Examination System

1. Introduction
→ Purpose: This document defines all requirements for the Online Examination System.
→ Scope: Covers exam creation, scheduling, conduction, automated evaluation, and result publishing.
→ Definitions, Acronyms, Abbreviations: OES (Online Examination System), MCQ, Proctoring.
→ References: University examination guidelines, UGC norms.
→ Overview: Description of remaining SRS sections.

2. Overall Description
→ Product Perspective: Standalone web application; may integrate with institute's student database.
→ Product Functions: Core functions: User Management, Question Bank Management, Exam Scheduling, Live Exam Interface, Evaluation, Reporting.
→ User Classes and Characteristics:
• Administrator: Manages users, system configuration, overall oversight.
• Examiner/Teacher: Creates questions, schedules exams, evaluates subjective answers.
• Student: Takes exams, views results and feedback.
→ Operating Environment: Web-based (HTML5, CSS3, JavaScript), Backend (e.g., PHP/Node.js), Database (MySQL/PostgreSQL).
→ Design and Implementation Constraints: Must work on major browsers (Chrome, Firefox), support 500+ concurrent users.
→ Assumptions and Dependencies: Users have reliable internet; student data is pre-loaded.

3. Specific Requirements
→ External Interface Requirements:
• User Interfaces: Intuitive dashboards for each role; clean exam interface with timer.
• Hardware Interfaces: None specified.
• Software Interfaces: API for potential future integration with Learning Management System (LMS).
• Communication Interfaces: HTTPS for security.
→ Functional Requirements (System Features):
• FEAT-1: User Authentication & Authorization: Secure login/logout; role-based access control.
• FEAT-2: Question Bank Management: Create, edit, delete, categorize questions (MCQ, descriptive).
• FEAT-3: Exam Creation & Scheduling: Create exam from question bank, set timer, schedule date/time.
• FEAT-4: Live Examination: Display questions one-by-one/all; timer countdown; auto-submit; prevent browser back button.
• FEAT-5: Evaluation & Reporting: Auto-evaluate objective questions; interface for examiner to mark subjective answers; generate scorecards.
• FEAT-6: Result Analysis: Generate reports (student-wise, class-wise, question-wise analysis).
→ Non-Functional Requirements:
• Performance: Page load time > 3 seconds; support for concurrent users during peak exams.
• Security: Password encryption; secure session management; prevention of cheating (basic).
• Reliability: System availability > 99% during exam periods; auto-save answers periodically.
• Usability: Easy to learn; should not require extensive training for students.
• Portability: Responsive design for access via desktop, laptop, tablet.

4. Appendices
→ Glossary of Terms.
→ Use Case Diagrams.
→ Sample screen mockups.
→ Data Dictionary.

2. (b) What are the duties of a systems analyst ? Why technical and managerial skills are required for the job of systems analyst ? Explain. (10 marks)

Answer:

Duties of a Systems Analyst:
1. Problem Investigation & Requirement Elicitation: The analyst acts as an investigator to understand organizational problems. They interact with users and management through interviews, questionnaires, and observations to gather and define system requirements clearly and completely.
2. Systems Analysis & Feasibility Study: They analyze the current system, its processes, and data flows. They assess the technical, operational, and economic feasibility of proposed new systems to determine if they are viable solutions.
3. Systems Design & Specification: Translating requirements into a technical blueprint is a key duty. They design system architecture, database structures (using ERDs), process models (using DFDs), and user interface layouts, creating the System Design Specification.
4. Bridge Between Stakeholders: They act as a crucial liaison, interpreting user needs for technical developers and explaining technical constraints and solutions to non-technical management and users.
5. Implementation Support & Change Management: They oversee or assist in system implementation, coordinate testing (like User Acceptance Testing), help with data migration, and manage the organizational change, including user training and addressing resistance.
6. Evaluation & Maintenance: After implementation, they participate in reviewing the system's performance against objectives and plan for ongoing maintenance and enhancements.

Need for Technical Skills:
→ To Understand Possibilities & Limits: Technical knowledge (of databases, networks, programming concepts) allows the analyst to understand what technology can and cannot do, ensuring proposed solutions are realistic and well-designed[citation:7].
→ To Communicate Effectively with Developers: They must speak the language of the technical team to convey requirements precisely and evaluate technical proposals, designs, and timelines.
→ To Create Technical Specifications: Designing system models (DFDs, ERDs), data dictionaries, and interface specs requires solid technical and modeling skills.
→ To Assess Technology & Tools: They need to evaluate different hardware/software options and tools (like CASE tools) for suitability and cost-effectiveness.

Need for Managerial Skills:
→ Project Management: Analysts often manage parts of the project—estimating costs, defining scope, tracking progress, and managing resources—requiring planning and organizational skills.
→ Stakeholder Management: Dealing with diverse groups (users, management, IT staff) involves negotiation, conflict resolution, and expectation management to keep the project aligned with business goals.
→ Risk Management: Identifying potential risks (technical, schedule, user acceptance) and developing mitigation strategies is a managerial duty.
→ Leadership & Change Management: Guiding the organization through the changes a new system brings requires leadership to motivate and train users, overcoming resistance to ensure successful adoption.

In essence, the systems analyst's role is hybrid. Technical skills ensure the solution is correctly built, while managerial skills ensure it is the right solution, delivered effectively, and accepted by the organization. A lack in either area can lead to system failure.

3. (a) What is the need of feasibility study ? Explain any four issues involved in feasibility study. (10 marks)

Answer:

Need for Feasibility Study: A feasibility study is conducted early in the System Development Life Cycle (SDLC) to determine whether a proposed system project is viable and worth pursuing. It acts as a crucial "go/no-go" checkpoint before significant resources (time, money, effort) are committed. The primary need is to avoid failure by assessing if the project is practical, beneficial, and achievable within the organization's constraints. It ensures that the project aligns with business objectives, has a clear rationale, and identifies potential showstoppers early on.

Four Key Issues (Types of Feasibility) Involved:

1. Technical Feasibility: This assesses whether the required technology exists and is mature enough to implement the proposed system. It also evaluates if the organization has the necessary technical expertise (or can acquire it).
Issues Considered: Are the required hardware, software, and networking capabilities available? Is the technology reliable and scalable? Does the in-house IT staff possess the required skills, or is training/vendor support needed? Can the system be integrated with existing systems?

2. Economic Feasibility (Cost-Benefit Analysis): This is arguably the most critical issue for management. It involves identifying all costs associated with the system and weighing them against the tangible and intangible benefits.
Issues Considered: Costs: Development costs (salaries, tools), hardware/software purchase, training, implementation, and ongoing maintenance. Benefits: Increased revenue, cost savings (e.g., reduced labor), improved efficiency, better decision-making, competitive advantage. The study calculates metrics like Return on Investment (ROI) and Payback Period to determine if the project is financially justifiable.

3. Operational Feasibility: This evaluates whether the system, once developed, will be used effectively and accepted by the people in the organization. A technically sound system can fail if users resist it.
Issues Considered: Will the system meet the users' actual needs and solve their problems? How will it affect existing work procedures and job roles? What is the likely level of user resistance, and how can it be managed? Is management supportive? Is adequate user training planned?

4. Schedule Feasibility: This assesses whether the project can be completed within a reasonable and acceptable timeframe. An unrealistic schedule is a major risk factor for project failure.
Issues Considered: Is the proposed deadline realistic given the project's scope and complexity? Are the required resources (human, technical) available when needed? What are the potential risks that could cause delays? Can the project be broken into phases with deliverable milestones?

Analyzing these four issues provides a comprehensive view of the project's viability, helping stakeholders make an informed decision to proceed, modify, or abandon the project proposal.

3. (b) What is modularity in a system ? Explain the concepts of coupling and cohesion. Is there any relationship between coupling and cohesion ? Explain. (10 marks)

Answer:

Modularity is a fundamental design principle where a system is decomposed into smaller, manageable, and independent units called modules. Each module is designed to perform a specific, well-defined function. Think of it like building with Lego blocks. Benefits include: easier understanding, development, testing, and maintenance; parallel development by different teams; and reusability of modules in other systems.

Cohesion refers to the measure of how closely related and focused the responsibilities within a single module are. It describes the strength of the relationship between the elements (functions, code) inside the module.
High Cohesion (Good): A module where all elements work together to perform a single, well-defined task. (Example: A module named `CalculateEmployeeTax` that contains all functions needed only for tax calculation).
Low Cohesion (Bad): A module that performs multiple, unrelated tasks. (Example: A module named `Utilities` that contains functions for tax calculation, printing reports, and connecting to the database). High cohesion makes modules easier to understand, maintain, and reuse.

Coupling refers to the measure of interdependence between different modules. It describes how much one module relies on or knows about the internal workings of another module.
Low (Loose) Coupling (Good): Modules are largely independent and communicate through simple, well-defined interfaces. Changing one module has minimal impact on others. (Example: Module A passes simple data parameters to Module B).
High (Tight) Coupling (Bad): Modules are heavily dependent on each other's internal details. Changing one module forces changes in many others, making the system rigid and hard to maintain. (Example: Module A directly modifies internal variables of Module B). Low coupling promotes system flexibility and reduces the "ripple effect" of changes.

Relationship Between Coupling and Cohesion:
Yes, there is a strong and inverse relationship, which is a cornerstone of good software design. The goal is to create modules with high cohesion and low coupling.
Why they are related: When a module has high cohesion (focused on one task), it tends to need less interaction with other modules to get its job done, naturally leading to lower coupling. Conversely, a module with low cohesion (doing many things) will likely need to interact with many other modules in various ways, increasing coupling.
Design Heuristic: "Strive for loose coupling and high cohesion." A system designed this way is modular, robust, easier to test, and much simpler to modify and maintain over its lifetime. They are two sides of the same coin for achieving a well-structured system.

4. (a) Explain the following with an example for each : (i) Class diagram (ii) E-R diagram (2×5=10 marks)

Answer:

(i) Class Diagram (A UML Diagram)
A Class Diagram is a static structure diagram in Unified Modeling Language (UML) used in object-oriented analysis and design. It shows the system's classes, their attributes (data), methods (operations), and the relationships among the classes. It provides a blueprint for the system's structure.
Key Elements:
1. Class: Represented by a rectangle divided into three compartments: Class Name, Attributes (e.g., `- studentName: string`), and Operations/Methods (e.g., `+ calculateGrade()`). The `-` denotes private, `+` denotes public.
2. Relationships:
→ Association: A basic "uses" relationship (solid line).
→ Multiplicity: Indicates number of instances (e.g., 1, 0..*, 1..*).
→ Inheritance/Generalization: An "is-a" relationship (solid line with hollow arrowhead from child to parent).
→ Aggregation: A "has-a" relationship where part can exist without whole (solid line with hollow diamond at whole end).
→ Composition: A strong "has-a" where part cannot exist without whole (solid line with filled diamond at whole end).

Example: Simple Library System

(ii) E-R Diagram (Entity-Relationship Diagram)
An E-R Diagram is a conceptual data modeling tool used primarily in database design. It illustrates the entities (objects) in a system, their attributes (properties), and the relationships between these entities. It is independent of any database management system.
Key Elements:
1. Entity: A real-world object (e.g., Student, Course). Represented by a rectangle.
2. Weak Entity: An entity that cannot be uniquely identified without a relationship to another entity (double rectangle).
3. Attribute: A property of an entity (e.g., studentId, studentName). Represented by an oval.
→ Key Attribute (Underlined): Uniquely identifies an entity (e.g., studentId).
→ Composite Attribute: Can be divided into sub-parts (e.g., address into city, street).
→ Multivalued Attribute (Double Oval): Can have multiple values (e.g., phoneNumber).
4. Relationship: An association between entities. Represented by a diamond.
5. Cardinality: Defines the numerical relationship between entities.
→ One-to-One (1:1): One entity instance relates to one instance of another.
→ One-to-Many (1:M): One instance relates to many instances.
→ Many-to-Many (M:N): Many instances relate to many instances.

Example: University Course Enrollment System

Summary Difference: A Class Diagram models the logical structure of a software system (objects, behavior, interactions). An E-R Diagram models the data structure of a system, focusing on how data is stored and related in a database.

4. (b) What is SDLC ? Briefly explain all the seven phases of SDLC. (10 marks)

Answer:

The System Development Life Cycle (SDLC) is a structured, phased framework or process for planning, creating, testing, deploying, and maintaining an information system[citation:8]. It provides a set of activities, methods, and best practices to guide project teams in building systems that are efficient, cost-effective, and meet user requirements. A common traditional model is the Waterfall model, which consists of seven sequential phases[citation:8].

The Seven Phases of SDLC:

1. Planning and Feasibility Study: This is the initial phase where the project's scope, objectives, and viability are determined. Key activities include identifying the problem or opportunity, defining preliminary goals, and conducting a feasibility study (technical, economic, operational, schedule). The output is a project plan and a feasibility report that recommends whether to proceed.

2. Systems Analysis and Requirements Definition: This phase involves a detailed study of the current system and the needs of the end-users. Analysts gather requirements through interviews, observations, and documents. They model current processes (e.g., using DFDs) and define the functional and non-functional requirements for the new system. The key deliverable is the Software Requirements Specification (SRS) document.

3. Systems Design: In this phase, the logical "what" from analysis is translated into the physical "how". System architects and designers create the technical blueprint. This includes designing the system architecture, database (using ERDs), user interfaces, inputs/outputs, and processes. The output is the System Design Specification (SDS) document, which serves as a guide for programmers.

4. Implementation (Development): This is the actual construction phase where programmers write code according to the design specifications. The system is built in modules, and unit testing of individual components is performed. Activities include setting up the hardware/software environment, database creation, and writing program code.

5. Integration and Testing: After development, individual modules are integrated into a complete system. Rigorous testing is conducted to find and fix defects. This includes integration testing (checking if modules work together), system testing (testing the complete system against requirements), and sometimes performance/security testing. The goal is to ensure the system is reliable and error-free.

6. Acceptance, Installation, and Deployment: The system is presented to the end-users for User Acceptance Testing (UAT), where they verify it meets their requirements. Once accepted, the system is installed in the production environment. Data is migrated from the old system, users are trained, and the system goes "live". This phase marks the official deployment of the system.

7. Maintenance: This is the longest phase, spanning the system's operational life. After deployment, the system needs ongoing support. Activities include correcting discovered bugs (corrective maintenance), adapting the system to new environments (adaptive maintenance), and adding new features or improving performance (perfective maintenance). The cycle may restart with planning for a major upgrade.

This phased approach ensures discipline, allows for management checkpoints, and aims to deliver a quality system that meets user needs. However, modern methodologies like Agile often iterate through these activities in smaller cycles.

5. Write short notes on the following : (4×5=20 marks)
(a) Distributed Systems (b) Structure Charts (c) Internal and External Information (d) Risk Analysis

Answer:

(a) Distributed Systems
A Distributed System is a collection of independent, networked computers that coordinate their actions and appear to users as a single, coherent system. The hardware and software components are geographically dispersed but communicate and work together to achieve a common goal.
Key Characteristics:
→ Resource Sharing: Users can access and use hardware (printers, storage), software, and data located on other machines.
→ Concurrency: Multiple components operate simultaneously.
→ Scalability: The system can be easily expanded by adding more computers.
→ Fault Tolerance: If one machine fails, others can often take over, improving reliability.
→ Transparency: The distributed nature is hidden from users (location, access, migration transparency).
Examples: The Internet, cloud computing platforms (AWS, Azure), distributed databases, and online banking networks.
Challenges: Complexity of design, network latency, security concerns, and difficulty in managing consistency across nodes.

(b) Structure Charts
A Structure Chart is a top-down, hierarchical diagram used in structured system design to represent the modular structure of a program. It shows the breakdown of a system into submodules and the relationships (calls) between them.
Key Elements:
→ Modules: Represented by rectangles, each containing the module's name. A module is a functional unit (like a subroutine or function).
→ Connection Lines: Show the calling relationship between a parent (superordinate) module and its child (subordinate) modules.
→ Data Flow Arrows: Arrows along the connection lines show data passed between modules. An arrow with an empty circle denotes data (e.g., "Customer Record").
→ Control Flow Arrows: Arrows with a filled circle denote control flags or status information (e.g., "End-of-File Flag").
→ Library Modules: Represented with a double vertical line, indicating a reusable module.
Purpose: It emphasizes coupling (data passed between modules) and cohesion (function of each module), helping designers create well-structured systems with minimal interdependence.

(c) Internal and External Information
Information in an organization is categorized based on its source and primary use.
Internal Information: This is information generated within the organization, derived from its day-to-day operations and internal systems.
→ Characteristics: More accurate, reliable, and timely as it's controlled by the organization.
→ Examples: Employee payroll records, sales transaction data, inventory levels, production reports, minutes of internal meetings, and financial statements (like profit & loss).
→ Primary Use: For operational control, tactical planning, and internal decision-making by managers.
External Information: This is information about the environment outside the organization.
→ Characteristics: Less control over accuracy and timeliness; often requires collection and filtering.
→ Examples: Government policies and regulations, market trends, competitors' data, economic indicators, customer demographics from surveys, and industry reports.
→ Primary Use: For strategic planning, long-term decision-making, and adapting to external changes (e.g., launching a new product, entering a new market).
A good Management Information System (MIS) integrates both internal and external information to support all levels of management.

(d) Risk Analysis
Risk Analysis is a systematic process within project management (and SDLC) used to identify, assess, and prioritize potential risks that could negatively impact a project's objectives (scope, time, cost, quality). Its goal is proactive management to minimize threats and capitalize on opportunities.
Key Steps:
1. Risk Identification: Brainstorming all potential risks (e.g., technology failure, staff turnover, changing requirements, budget overruns).
2. Risk Assessment (Analysis): Evaluating each identified risk based on two factors:
→ Probability/Likelihood: Chance of the risk occurring (High, Medium, Low).
→ Impact/Severity: The negative effect on the project if it occurs (High, Medium, Low).
A common tool is a Risk Matrix that plots probability against impact to prioritize risks (High Probability/High Impact = Top Priority).
3. Risk Prioritization: Ranking risks based on their assessed level (e.g., High, Medium, Low) to focus efforts on the most critical ones.
4. Risk Response Planning: Developing strategies to deal with top-priority risks. Strategies include:
→ Avoidance: Changing plans to eliminate the risk.
→ Mitigation: Taking steps to reduce the probability or impact.
→ Transfer: Shifting risk to a third party (e.g., buying insurance).
→ Acceptance: Acknowledging the risk and having a contingency plan if it occurs.
Risk analysis is not a one-time activity but should be conducted regularly throughout the project lifecycle.