System Analysis and Design

An ER diagram is converted into relations (tables) by mapping each entity, attribute and relationship to a relation using a fixed set of rules. This is the first step of logical database design.

Transformation rules

1. Strong entity becomes a relation. Its simple attributes become columns and the identifier becomes the primary key.
2. Composite attribute is replaced by its simple component attributes (for example Address becomes Street, City).
3. Multivalued attribute becomes a separate relation containing the owner's primary key plus the attribute. The key of the new relation is the combination of both.
4. Weak entity becomes a relation whose primary key is the owner's primary key combined with the weak entity's partial key. The owner's key is also a foreign key.
5. One-to-many (1:N) relationship: the primary key of the "one" side is placed as a foreign key in the relation of the "many" side.
6. One-to-one (1:1) relationship: the primary key of one side is placed as a foreign key in the other (preferably on the side with total participation).
7. Many-to-many (M:N) relationship: a new relation (associative relation) is created. Its primary key is the combination of the primary keys of both entities, and any attributes of the relationship become its columns.
8. Unary relationship: a foreign key referring to the same relation (1:N), or a new relation with two foreign keys of the same entity (M:N).
9. Ternary relationship becomes a new relation with the keys of all three entities.
10. Supertype/subtype: one relation per entity, with the subtype key being the same as the supertype key (a foreign key as well).

Example: College system

Entities: STUDENT(Roll_No, Name, Address(Street, City), Phone*), COURSE(Course_Id, Title, Credit), DEPARTMENT(Dept_Id, Dept_Name). Relationships: DEPARTMENT offers STUDENT (1:N); STUDENT enrolls COURSE (M:N) with attribute Grade. (* denotes multivalued.)

Resulting relations:

• DEPARTMENT(<u>Dept_Id</u>, Dept_Name)
• STUDENT(<u>Roll_No</u>, Name, Street, City, Dept_Id) where Dept_Id is a foreign key to DEPARTMENT (1:N rule) and the composite Address is split into Street and City.
• STUDENT_PHONE(<u>Roll_No, Phone</u>) for the multivalued attribute, Roll_No is a foreign key.
• COURSE(<u>Course_Id</u>, Title, Credit)
• ENROLLMENT(<u>Roll_No, Course_Id</u>, Grade) for the M:N relationship, both columns are foreign keys.

Thus five relations are produced from three entities, one multivalued attribute and two relationships. The relations are then normalised and implemented in a DBMS.

Information system

An information system (IS) is an organised combination of people, hardware, software, data, communication networks and procedures that collects, processes, stores and distributes information to support the operations, management and decision making of an organisation.

Types of information system

1. Transaction Processing System (TPS): records and processes the routine daily transactions of the business, such as sales, payroll, billing and bank deposits. It serves the operational level, handles large volumes of detailed data and is the base for other systems.

2. Management Information System (MIS): summarises the data of the TPS into regular, structured reports (sales summaries, inventory status, exception reports) for middle managers to monitor and control operations.

3. Decision Support System (DSS): interactive system that helps managers make semi-structured decisions, using data, analytical models and "what-if" analysis. Example: a loan approval or production planning model.

4. Executive Information System / Executive Support System (EIS/ESS): gives top managers summarised, easy-to-use views (dashboards) of internal and external data for strategic decisions.

5. Expert System (Knowledge-based system): captures the knowledge of human experts in a knowledge base and rules to give advice or diagnosis. Example: medical diagnosis.

6. Office Automation System (OAS): supports office work and communication, such as word processing, e-mail, scheduling and video conferencing.

7. Knowledge Management System (KMS): helps to create, share and use the organisation's knowledge.

Other examples are Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) systems.

An information system (IS) is an organised combination of people, hardware, software, data and procedures that collects, processes, stores and distributes information to support operations, management and decision making in an organisation. Information systems are classified by the level of the organisation they serve and the kind of work they support.

1. Transaction Processing System (TPS)

• Serves the operational level; records and processes the day-to-day routine transactions of the business.
• Input is raw transaction data; output is updated records, receipts and reports.
• Characteristics: high volume, repetitive, accuracy and speed are critical, uses batch or online processing.
• Examples: payroll, order entry, bank deposits and withdrawals, ticket reservation.

2. Management Information System (MIS)

• Serves middle management; summarises data from the TPS into periodic, structured reports for monitoring and control.
• Reports are routine, summary or exception reports (for example monthly sales by region, inventory status).
• Used for structured, well-understood problems.

3. Decision Support System (DSS)

• Serves middle and senior managers; helps with semi-structured and unstructured decisions.
• Combines data, analytical models and an interactive user interface for "what-if" analysis and simulation.
• Examples: production planning, break-even and budget analysis, loan evaluation.

4. Executive Information System (EIS) / Executive Support System (ESS)

• Serves top management at the strategic level.
• Presents a high-level, summarised view of internal and external data through dashboards, trend charts and drill-down.
• Examples: sales trend over five years, market and competitor position, key performance indicators.

5. Expert System (ES)

• Captures the knowledge of human experts in a knowledge base and uses an inference engine to give advice or diagnoses.
• Examples: medical diagnosis, credit approval, fault diagnosis of equipment.

6. Office Automation System (OAS)

• Supports office workers and communication: word processing, spreadsheets, email, calendars, video conferencing and document management.

7. Knowledge Management System (KMS)

• Supports knowledge workers in creating, sharing and distributing knowledge in the organisation (design tools, document repositories, intranets).

Summary by level

A feasibility analysis checks whether a proposed system is worth developing, before large resources are committed. Its steps are:

1. Form a project team and appoint a project leader: analysts, users and managers are assigned to the study.
2. Prepare system flowcharts / identify the current system: study the existing system and its problems, and describe the proposed one in outline (inputs, processes, outputs).
3. Enumerate the potential candidate systems: list alternative solutions, for example in-house development, buying a package, or outsourcing.
4. Describe and identify the characteristics of each candidate system: state what each can do and its requirements.
5. Determine and evaluate the performance and cost-effectiveness of each candidate: test each against the following feasibility criteria.
   • Technical feasibility: is the needed hardware, software and expertise available?
   • Economic feasibility: do the benefits exceed the cost (cost-benefit analysis, payback period, ROI)?
   • Operational feasibility: will users and the organisation accept and use the system?
   • Schedule feasibility: can it be completed in the required time?
   • Legal / social feasibility: does it follow laws, licences and policies?
6. Weigh the system performance and cost data: compare the candidates and select the best one.
7. Select the best candidate system.
8. Prepare and report the final project directive / feasibility report to management with the findings and a recommendation to proceed, modify or stop. Management then decides.

System: a system is an organised set of interrelated components (people, hardware, software, data and procedures) that work together to achieve a common goal or objective. Example: a college information system, a computer, or a bank.

Characteristics of a system

1. Organisation: components are arranged in a structured way with defined relationships and hierarchy.
2. Interaction: the components depend on and act upon each other, for example the processor and memory.
3. Interdependence: each part depends on the others; the failure of one affects the whole.
4. Integration: the parts are linked so that they work as one whole; the whole is greater than the sum of its parts.
5. Central objective: every system exists to achieve a goal, and all components contribute to it.
6. Boundary and environment: a boundary separates the system from its environment, which lies outside and interacts through inputs and outputs.
7. Inputs, processing and outputs: a system takes inputs, transforms them by processes, and produces outputs.
8. Feedback and control: output information is compared with the standard and used to correct the system.
9. Open or closed nature: an open system interacts with its environment; a closed one does not.
10. Subsystems and interfaces: a system is made of subsystems connected through interfaces.
11. Adaptability and entropy: the system adapts to changes in the environment; without maintenance, it tends to disorder.

Why it is difficult to determine user requirements

• Users often do not know exactly what they want, or cannot express it clearly.
• Requirements are complex, incomplete, ambiguous and may conflict between different users or departments.
• Users and analysts have different backgrounds and vocabulary, which leads to misunderstanding.
• Requirements change during the project as the business, technology or users' understanding changes.
• Users resist change, fear job loss, or are too busy to cooperate.
• Much knowledge is tacit: users perform tasks routinely and forget to mention exceptions and informal procedures.
• Poor documentation of the existing system, and lack of access to the right people.

Key strategies for eliciting requirements

1. Interviews: direct questioning of users and managers, structured or unstructured, to get detailed opinions.
2. Questionnaires: written questions sent to many users to collect information from a large group quickly.
3. Observation: watching users perform their work to see actual practice and problems.
4. Document and record review: studying forms, reports, manuals and files of the current system.
5. Joint Application Development (JAD) / workshops: structured group sessions of users and analysts to agree requirements.
6. Prototyping: building a working model so users can react to it and refine requirements.
7. Brainstorming and use cases / scenarios: generating ideas and describing user interactions with the system.
8. Sampling of existing forms and reports, and studying similar systems elsewhere.

A mixture of these methods is normally used, because each one reveals different kinds of requirements.

Documentation is the written description of an information system. It supports development, operation, use and maintenance.

Difference between system and user documentation

Documentation necessary for an information system

• System documentation is needed for every system, since it is required for maintenance and later enhancement: requirements specification, design documents, data dictionary, program documentation, test and change records.
• User documentation is needed for every system with human users: a user manual or tutorial for the day-to-day users, a quick reference for frequent tasks, online help, and training material.
• Operations / installation documentation is required for systems running in a computer centre or on a network: installation guide, backup and recovery procedures, schedules, security details.

The amount of each type depends on the size and complexity of the system: a small single-user application may need only a short user guide, while a large enterprise system needs all types in full.

Maintenance is the work done on a system after it is delivered, to keep it useful. Four types are recognised.

1. Corrective maintenance fixes faults found in operation, such as a wrong calculation, a crash or a data-handling bug. It is reactive and is triggered by error reports.

2. Adaptive maintenance modifies the system so that it keeps working when its environment changes, for example a new operating system, database version, tax rule or hardware platform. The functions stay the same.

3. Perfective maintenance improves or extends the system on user request: new reports, faster response, a better screen layout. It adds value beyond the original requirements and is usually the largest share of maintenance effort.

4. Preventive maintenance restructures or documents the software, cleans up code and updates components so that future faults and changes become easier and less likely. It is proactive.

Both are fact-finding techniques used in system analysis.

A relation is in 2NF if it is in 1NF and every non-key attribute depends on the whole of the primary key, so there is no partial dependency. A relation is in 3NF if it is in 2NF and no non-key attribute depends on another non-key attribute, so there is no transitive dependency.

Example: ORDER(OrderNo, ProductNo, ProductName, Qty). ProductName depends only on ProductNo, a partial dependency. Splitting gives ORDER(OrderNo, ProductNo, Qty) and PRODUCT(ProductNo, ProductName), which is 2NF.

Example: STUDENT(RollNo, Name, DeptCode, DeptName). RollNo → DeptCode → DeptName is transitive. Splitting gives STUDENT(RollNo, Name, DeptCode) and DEPARTMENT(DeptCode, DeptName), which is 3NF.

A project manager is responsible for planning, leading and controlling an information systems project so that it meets its scope, time, cost and quality targets.

Skills required: leadership and people management, communication, negotiation and conflict resolution, technical understanding, risk and time management, analytical and decision-making ability, and customer-handling skills.

(a) Project initiation

• Establish the project: understand the business need and define scope, objectives and deliverables.
• Form the project team and assign roles.
• Carry out feasibility study (technical, economic, operational, schedule).
• Identify stakeholders and establish good relations with the client.
• Establish management procedures such as reporting and change control, and prepare the project charter.
• Prepare initial cost and benefit estimates.

(b) Project execution

• Plan the work in detail: work breakdown, schedule (Gantt/PERT chart), budget and resources.
• Direct the team, assign tasks and keep it motivated.
• Monitor progress against plan and control scope changes.
• Manage risks, issues and quality, and keep the quality reviews running.
• Communicate with the sponsor, users and team; hold status meetings and give reports.
• Manage vendors and resources.

(c) Project close down

• Ensure all deliverables are completed and accepted by the client.
• Obtain sign-off and hand over the system, including training and documentation.
• Terminate contracts, release team members and resources, and settle the accounts.
• Conduct a post-project review and record lessons learned.
• Prepare the final project report and archive the project records.

Entities: Customer, Cafe staff (counter/kitchen), Delivery person (optional), Payment. The system is "Food Ordering System".

Context diagram (Level 0) (one process with its external entities)

Customer --order, payment--> [ 0  Food Ordering System ] --menu, bill, receipt--> Customer
Kitchen  <--order ticket---- [                         ] --ready notice--------> Kitchen
Manager  <--sales reports--- [                         ] <--menu update, price-- Manager

Level 1 DFD

Data stores: D1 Menu, D2 Orders, D3 Sales.

Level 2 DFD of Process 1.0 Take order

• 1.1 Show menu: reads D1 Menu, sends the menu list to Customer.
• 1.2 Receive order: Customer's item selections go in; an order record is created.
• 1.3 Validate order: checks item availability against D1; sends rejected items back to Customer.
• 1.4 Calculate total: computes the amount for the validated items and saves the order in D2 Orders.
• 1.5 Send to kitchen: forwards the order ticket to Process 2.0.

Level 2 of Process 3.0 Process payment

• 3.1 Generate bill: reads order from D2, produces the bill for Customer.
• 3.2 Receive payment: accepts cash, card or online payment from Customer.
• 3.3 Issue receipt and record sale: sends receipt to Customer and stores the sale in D3.

Balancing: the inputs and outputs of each level-2 diagram match those of its parent process in level 1.

Transforming an E-R diagram into relations

1. Strong entity: each becomes a relation; simple attributes become columns; the identifier becomes the primary key. Composite attributes are broken into their components. Example: STUDENT(RollNo, Name, Address).
2. Multivalued attribute: make a separate relation with the owner's key plus the attribute; the key is the combination. Example: STUDENT_PHONE(RollNo, Phone).
3. Weak entity: a relation with its own attributes plus the owner's primary key as foreign key; the primary key is owner key + partial key. Example: DEPENDENT(EmpID, DepName, Age).
4. One-to-many (1:N): put the primary key of the "one" side as a foreign key in the "many" side. Example: EMPLOYEE(EmpID, Name, DeptID), where DeptID references DEPARTMENT.
5. One-to-one (1:1): put the key of either side in the other as a foreign key (usually the side with total participation).
6. Many-to-many (M:N): create a new relation containing the keys of both entities (plus relationship attributes); the primary key is the combination. Example: ENROLL(RollNo, CourseID, Grade).
7. Unary relationship: a foreign key referring to the same relation (EMPLOYEE(EmpID, Name, ManagerID)); M:N unary needs a separate relation.
8. Ternary relationship: a new relation holding the keys of all three entities.

Bank interest rule

Conditions: C1 = deposit is Rs 50,000 or more; C2 = period is 5 years or more.

(a) Decision table

R3 and R4 give the same action, so they can be merged into one rule (C1 = N, C2 = indifferent).

(b) Decision tree

Deposit >= Rs 50,000 ?
 |-- Yes --> Period >= 5 years ?
 |            |-- Yes --> Interest = 15%
 |            |-- No  --> Interest = 12%
 |-- No  --> Interest = 10%  (any period)

A relation is in 2NF if it is in 1NF and every non-key attribute is fully functionally dependent on the whole primary key, so no partial dependency exists. A relation is in 3NF if it is in 2NF and no non-key attribute depends on another non-key attribute, so no transitive dependency exists.

Example (2NF): ENROLL(StudentID, CourseID, CourseName, Grade) has CourseID → CourseName, a partial dependency. Split into ENROLL(StudentID, CourseID, Grade) and COURSE(CourseID, CourseName).

Example (3NF): EMPLOYEE(EmpID, DeptID, DeptName) has EmpID → DeptID → DeptName. Split into EMPLOYEE(EmpID, DeptID) and DEPARTMENT(DeptID, DeptName).

(c) Transaction Processing Systems

A TPS records and processes the routine day-to-day transactions (sales, payroll, billing, orders) on which every organization depends. MIS, DSS and EIS use that data for management decisions.

(c) Formulation and planning various activities

The project life cycle covers initiation, planning (formulating the activities, schedule and resources), execution and closure. A word processor is only a tool, not part of the cycle, while scope and objectives are inputs to planning rather than phases.

(c) Risk Management

The spiral model combines iterative prototyping with the waterfall model and adds explicit risk analysis in every loop, which is its distinguishing feature.

(c) Design Specification Report

It describes the design of the new system: existing and proposed system, system flowcharts, modular design, print layouts and file designs. A feasibility report judges viability and a functional specification states requirements.

(b) System Analysis

In this phase requirements are studied, feasibility is assessed and the roadmap (project plan, schedule and process model) is decided. Coding and testing come later.

(d) pilot

In pilot conversion the new system is installed and tested in one location or department first. After it proves itself, it is rolled out to the rest of the organization. Phased conversion, in contrast, introduces the system in stages by function.

(b) Perfective maintenance

Perfective maintenance adds new features or improves performance beyond the original functional requirements, usually at user request. Corrective maintenance fixes errors and adaptive maintenance adjusts to environmental changes.

(b) Second Normal Form

2NF removes partial dependencies, where a non-key attribute depends on only part of a composite primary key. 3NF removes transitive dependencies.

(c) Multi-value attributes

In an E-R diagram an attribute that can hold more than one value for an entity (such as phone numbers) is drawn as a double oval. A single oval is an ordinary attribute.

(b) Stress testing

Stress testing drives the system beyond its normal operational capacity (heavy load, low resources) to see where and how it fails. Performance testing measures speed under expected load, and recovery testing checks restoration after failure.

A system is a set of interrelated components that work together toward a common goal by accepting inputs, processing them and producing outputs, with feedback and control. Examples: a banking system, a library system. A system has boundary, environment, inputs, processes, outputs and feedback.

SDLC (System Development Life Cycle) is the step-by-step process of developing an information system. Its phases are:

1. Planning / preliminary investigation: identify the problem or need, define scope and objectives, and study feasibility (technical, economic, operational, schedule).
2. System analysis: study the existing system and collect and analyse requirements through interviews, questionnaires and observation; model them with DFDs and E-R diagrams and prepare the requirements specification.
3. System design: design the new system's architecture, database, input/output forms, user interface and processes, and prepare the design specification.
4. Implementation / coding: programmers build the system from the design, then unit test the modules.
5. Testing: integration, system and acceptance testing to find and fix errors and verify that requirements are met.
6. Installation / deployment: convert to the new system (direct, parallel, pilot or phased), train users and prepare documentation.
7. Maintenance: correct errors, adapt to changes and enhance the system during its working life.

Planning is the process of deciding in advance what is to be done, how, when, by whom and with what resources, to achieve project objectives. In information system development, project planning defines the work and the way it will be managed and controlled.

Process of planning an information system development project

1. Define the scope and objectives: state the problem, expected outcome, boundaries and deliverables of the system.
2. Feasibility study: assess technical, economic, operational, legal and schedule feasibility to decide whether to proceed.
3. Identify tasks and build the work breakdown structure: divide the project into phases, activities and tasks.
4. Estimate effort, time and cost: use techniques such as expert judgement, analogy or COCOMO.
5. Schedule activities: sequence tasks, show dependencies and prepare Gantt and PERT/CPM charts, finding the critical path.
6. Allocate resources and staff: assign people, hardware, software and budget to tasks.
7. Risk planning: identify risks and prepare responses.
8. Quality and communication planning: set standards, review points, reporting and change control.
9. Prepare the project plan and get approval from management and the client.
10. Monitor and update: compare actual progress with plan and revise when needed.

Process modeling is the graphical representation of the processes of a system: how data are transformed by the activities of the system, from input to output. It shows what the system does, not how it is implemented. The main tool is the Data Flow Diagram.

Data Flow Diagram (DFD) shows the flow of data between external entities, processes and data stores.

Symbols:

• Process: circle or rounded box that transforms data.
• Data flow: arrow showing data moving, labelled with the data name.
• Data store: open rectangle holding data at rest (a file or table).
• External entity: rectangle for a source or destination outside the system.

DFDs are drawn in levels: the context diagram (level 0) shows the whole system as one process, and level 1 and lower decompose it into sub-processes.

Example: library book issue

• Context: Member sends "book request" to the Library System; the system returns "issued book / receipt".
• Level 1: 1.0 Verify member (reads D1 Members), 2.0 Check book availability (reads D2 Books), 3.0 Issue book (writes D3 Issue records and updates D2), producing a due-date slip for the Member.

Rules: every process must have at least one input and one output, data flows must go to or from a process, and a lower level must balance with its parent.

A project manager plans, organizes, leads and controls an information system project so that it is completed within scope, time, cost and quality.

Skills

• Leadership and team building.
• Communication (written, oral, listening) and negotiation.
• Conflict resolution and problem solving.
• Technical knowledge of systems development.
• Planning, estimation and time management.
• Risk management and decision making.
• Customer and stakeholder handling.

Responsibilities

• Define project scope, objectives and deliverables.
• Prepare the project plan, schedule (Gantt/PERT) and budget.
• Select, assign and motivate team members.
• Monitor progress, control cost and manage changes.
• Identify and manage risks and issues.
• Ensure quality through reviews and testing.
• Communicate and report to the client, sponsor and team.
• Manage resources and vendors.
• Ensure delivery, client acceptance, documentation and project closure with lessons learned.

An interface is how users interact with an e-commerce system, and a dialogue box is a window that asks the user for input or confirmation. Good design makes shopping easy, trustworthy and quick.

Interface guidelines

• Consistency: the same layout, terms, colours and navigation on every page.
• Simplicity: uncluttered pages, a clear search box, categories and few steps to checkout.
• Navigation: menus, breadcrumbs and a visible cart so users always know where they are and can go back.
• Feedback: confirm every action (item added, order placed) and show progress through checkout.
• Error prevention and handling: validate inputs, give clear messages and let users correct mistakes.
• Speed and responsiveness: fast loading and a layout that works on mobile and desktop.
• Accessibility: readable fonts, good contrast and alternative text for images.
• Trust and security: HTTPS, visible payment and privacy information, and clear return policy.

Dialogue box guidelines

• Use clear, short, polite wording that states the action required.
• Give meaningful buttons ("Place order", "Cancel") rather than "OK" only.
• Provide a safe default and an easy way to cancel or undo.
• Ask for only the necessary information, grouped logically, with required fields marked.
• Confirm risky actions such as payment or deletion.
• Do not overuse pop-ups, and keep the box small, centred and keyboard-friendly.

Applications

• System documentation lets a new programmer understand and modify the code, find the cause of faults and plan upgrades.
• User documentation helps a bank clerk or a student learn the software, use its features correctly and solve common problems without calling support.

Software testing is the process of executing a program with the intent of finding errors and checking that it meets its requirements. Common levels are unit, integration, system and acceptance testing.

Software quality assurance (SQA) is a set of planned activities that ensure the software and its development process meet defined quality standards. Its activities include:

1. Setting standards and procedures (such as ISO 9001) and a quality plan.
2. Formal technical reviews, walkthroughs and inspections of requirements, design and code to find defects early.
3. Testing: planning and performing unit, integration, system and acceptance tests.
4. Configuration and change management: controlling versions and changes.
5. Measurement and metrics: defect counts, complexity and reliability measures to monitor quality.
6. Audits to confirm that processes and standards are followed.
7. Record keeping and reporting of defects, and deviation handling.
8. Training of staff on quality practices and process improvement.

Agile methodologies (Scrum, XP, Kanban) develop software in short iterations with continuous customer collaboration. The Waterfall model is a linear sequence of phases: requirements, design, coding, testing, maintenance.

Why use agile

• Changing requirements are accommodated easily.
• Working software is delivered early and often, giving faster return on investment.
• Frequent customer feedback ensures the product meets real needs and raises satisfaction.
• Risk is reduced because problems are discovered early.
• Quality improves through continuous testing and review.
• Team communication and morale improve through daily meetings and shared ownership.
• Progress is transparent, and work can be prioritised so the most valuable features come first.

Importance of project management

Project management is the planning, organising, directing and controlling of resources to complete a project within scope, time and budget. It is important because:

• It gives a clear plan, schedule and deliverables, so everyone knows what is expected.
• It controls cost and time overruns, which are common in information system projects.
• It allocates people, tools and money efficiently and avoids conflicts for resources.
• It identifies and reduces risks early.
• It keeps quality under control and the system matches user requirements.
• It improves communication among users, analysts, managers and developers.
• It gives a basis (the baseline plan) for monitoring progress and for corrective action.

Integrated CASE tools

CASE (Computer-Aided Software Engineering) tools are software packages that automate the activities of the systems development life cycle. An integrated CASE (I-CASE) tool covers the whole life cycle. It combines upper-CASE tools (planning, analysis, design) and lower-CASE tools (code generation, testing, maintenance) around a shared central repository, so that information entered once is available in all phases.

Main components

• Central repository storing diagrams, data dictionary, specifications, screens, reports and code definitions.
• Diagramming tools for DFDs, ER diagrams, structure charts and UML.
• Form and report generators (prototyping) for screens and reports.
• Analysis tools that check consistency and completeness of the design.
• Code generators that produce program code and database definitions from the design.
• Documentation generators and project management tools.

Applications

• Drawing and automatically checking models (DFD, ERD) for errors and consistency.
• Rapid prototyping of screens and reports for user feedback.
• Generating source code and database schema directly from the design (forward engineering) and reverse engineering of existing code.
• Maintaining documentation and version control, which speeds up maintenance.
• Project scheduling, effort estimation and team coordination.

Benefits: higher productivity, better quality and consistency, easier maintenance and shorter development time. Limitations: high cost, training needs and difficulty fitting the tool to the organisation's method.

Organisations obtain software from several sources. The main ones are:

1. Information technology service firms (outsourcing / custom development) Firms develop custom systems or run them for the client, for example a consultancy building a hospital system. Advantages: expertise, tailor-made solution, the organisation can concentrate on its core business. Disadvantages: costly, loss of control, dependency on the vendor.

2. Packaged software producers Companies sell ready-made software, such as accounting or payroll packages. Advantages: lower cost, quick installation, proven and tested, vendor support. Disadvantages: may not fit exactly, customisation is limited, and the organisation may need to change its processes.

3. Enterprise solution software (ERP) Large integrated packages (SAP, Oracle) that cover most business functions on one database. Advantages: integration of departments, one source of data, best practices built in. Disadvantages: very expensive, long and complex implementation, heavy training, and it forces process change.

4. Cloud computing / Software as a Service (SaaS) Software hosted by a provider and used over the Internet on subscription (Google Workspace, Salesforce). Advantages: no installation or hardware, pay-per-use, automatic updates. Disadvantages: dependence on the Internet and the provider, data security and limited customisation.

5. Open source software Software with freely available source code (Linux, MySQL). Advantages: free of licence fee, can be modified, large community. Disadvantages: limited formal support, variable quality and documentation.

6. In-house development The organisation's own staff build the system. Advantages: full control and an exact fit to requirements. Disadvantages: needs skilled staff, takes more time and cost, and maintenance burden remains with the organisation.

Comparison

The choice depends on cost, time, functionality, vendor support and the organisation's technical skill.

A systems analyst studies the needs of users and designs information systems to meet them. A good analyst needs a combination of the following skills.

1. Analytical skills: understanding the organisation and its problems, identifying and defining the problem, collecting and analysing facts, and finding alternative solutions.

2. Technical skills: knowledge of computers, programming languages, databases, networks, operating systems and development tools, and the ability to follow new technology.

3. Management skills: managing projects, resources, time and risk; planning, scheduling, leading a team and handling change in the organisation.

4. Interpersonal (communication) skills: speaking and listening, interviewing users, writing clear reports and documents, presenting ideas, and working with people from different backgrounds. These are vital because analysts stand between users and programmers.

5. Business knowledge: understanding how the business functions (accounting, marketing, production) so that the system supports business goals.

6. Creativity and problem solving: finding new and practical solutions.

7. Ethics and personal qualities: honesty, confidentiality of data, patience, flexibility, tact and willingness to learn.

A good analyst therefore balances technical competence with people and business skills.

Corporate strategic planning is the long-range process of defining an organisation's mission, objectives and the strategies to reach them. Information systems planning is derived from it. The steps are:

1. Identify the mission: define the organisation's reason for existing, its products, markets and values.
2. Set objectives: state the specific, measurable goals to be achieved (market share, profit, growth, service level), normally over three to five years.
3. Analyse the environment and the organisation (SWOT): study internal strengths and weaknesses and external opportunities and threats such as competition, technology and regulation.
4. Formulate strategies: choose the competitive strategy (low cost, differentiation, focus) and the plan of action to reach the objectives, including how information systems will support them.
5. Develop the strategic plan: set the programmes, policies, resources, budgets, schedule and responsibilities.
6. Implement the plan: carry out the programmes in the organisation's departments.
7. Monitor, evaluate and revise: compare results with objectives, take corrective action and update the plan when conditions change.

The outcome is a corporate strategic plan, which guides the information systems plan and the selection of development projects.

A decision table is a tabular method of showing conditions, actions and the rules that link them. It is used to model complex logic in a compact and verifiable form.

Steps in creating a decision table

1. Identify all the conditions relevant to the decision and the actions that can result.
2. Calculate the number of rules. For $n$ binary conditions there are $2^n$ combinations.
3. Draw the table with four quadrants: condition stubs, condition entries, action stubs and action entries.
4. Fill the condition entries (Y/N or the values) so that every combination of conditions appears once.
5. Mark the actions (X) that apply to each rule.
6. Check for redundancy, contradiction and incompleteness.
7. Simplify the table and verify it with the users.

Reducing size and complexity

• Combine rules: if two rules lead to the same actions and differ in only one condition, merge them and put a dash ("-", indifferent) in that condition. Thus four rules of three conditions can collapse into one with two dashes.
• Remove impossible rules: delete combinations that cannot logically occur.
• Remove redundant rules: delete duplicates.
• Use an ELSE rule to cover all remaining combinations.
• Break into smaller linked tables: split a large table into sub-tables, with one table's action being "go to table X".
• Reduce the number of conditions by removing irrelevant ones, or by combining related conditions.

For example, "Order > Rs 5,000" and "Member": if both Y and N values of Member give the same action when Order > 5,000, the two rules merge into one with Member = "-".

Information gathering is the process of collecting facts about the existing system, its users, data, processes and problems, and about what users expect of the new system. It is carried out in the analysis phase. The common methods are interviews, questionnaires, observation, document/record review, joint application design (JAD) and prototyping.

Questionnaire

A questionnaire is a set of written questions answered by respondents (users, customers, staff) in order to collect information from many people. Questions can be:

• Open-ended (free response), useful to obtain opinions and ideas but harder to analyse.
• Closed-ended (yes/no, multiple choice, rating scales), quick to answer and easy to tabulate.

Good practice: keep it short and clear, use simple unambiguous words, group related questions, test it on a few people, and state the purpose.

Merits

• Can reach a large number of people in different places at low cost.
• Saves time of both analyst and respondent; respondents answer at their convenience.
• Responses are anonymous, so people are more frank.
• Answers are uniform and easy to tabulate and analyse statistically.
• Useful to verify facts found by other methods.

Demerits

• The response rate is often low and many forms are returned incomplete.
• No chance to clarify questions or probe the answers; misunderstandings may occur.
• Poor design gives poor or biased answers.
• Body language and feelings cannot be observed.
• Time-consuming to design and the respondent may not answer honestly.
• Not suitable for complex or detailed problems.

Software testing is the process of executing a program to find errors and to check that it meets the requirements. The different types are:

1. Static testing: examining code and documents without executing them, by walkthroughs, inspections and desk checking.

2. Dynamic testing: running the program with test data.

3. Levels of testing

• Unit (module) testing: each module is tested separately.
• Integration testing: tested modules are combined and the interfaces between them are checked. It may be top-down, bottom-up or big-bang.
• System testing: the complete integrated system is tested against the requirements, including performance, security and recovery.
• Acceptance testing: the user tests the system with real data to decide whether to accept it (alpha testing by the developer's site, beta testing at the customer's site).

4. Testing techniques

• Black-box testing: tests the functions without knowing the internal code, using inputs and expected outputs (equivalence partitioning, boundary value analysis).
• White-box testing: uses knowledge of the internal logic, to cover statements, branches and paths.

5. Other types: regression testing (re-testing after changes to make sure nothing else broke), stress and performance testing, usability testing and security testing.

Data: annual benefit = Rs 85,000; one-time cost = Rs 75,000; recurring cost = Rs 35,000 per year; discount rate $i = 12\%$; $n = 5$ years.

Discount factor for year $t$ is $\dfrac{1}{(1.12)^t}$. Sum of the factors for 5 years:

$\sum_{t=1}^{5}\frac{1}{1.12^t}=\frac{1-1.12^{-5}}{0.12}=3.6048$

(a) Net present value

PV of benefits = $85{,}000 \times 3.6048 =$ Rs 306,406 PV of recurring costs = $35{,}000 \times 3.6048 =$ Rs 126,167 PV of one-time cost = Rs 75,000

$NPV = 306{,}406 - 126{,}167 - 75{,}000 = \text{Rs }105{,}239$

The NPV is positive, so the project is economically worthwhile.

(b) Overall return on investment

$ROI = \frac{PV\text{ of benefits} - PV\text{ of costs}}{PV\text{ of costs}} = \frac{306{,}406 - 201{,}167}{201{,}167} = \frac{105{,}239}{201{,}167} \approx 0.523$

So ROI is about 52.3% over the five years.

(c) Break-even point

Net benefit per year is $85{,}000 - 35{,}000 = 50{,}000$. Cumulative discounted net cash flow:

Breakeven falls in year 2. Fraction of year 2 needed:

$\frac{75{,}000 - 44{,}643}{39{,}860} = 0.76$

Breakeven occurs after about 1.76 years (roughly 21 months) on a discounted basis.

Software maintenance

Software maintenance is the modification of an information system after it has been delivered and put into operation, in order to correct faults, improve performance and keep it useful in a changing environment. It is the last phase of the system development life cycle and usually consumes the largest share (often 60 to 80 percent) of the total cost of a system.

Types of maintenance

1. Corrective maintenance: fixing errors (bugs) found after delivery, for example correcting a wrong interest calculation in a banking program.
2. Adaptive maintenance: changing the system to work in a new or changed environment, such as a new operating system, hardware, law or tax rate. Example: updating a billing system for a new VAT rate.
3. Perfective maintenance: adding new features or improving performance and usability at the user's request. Example: adding a report or speeding up a search.
4. Preventive maintenance: restructuring or documenting the system to prevent future problems and make later maintenance easier. Example: re-writing messy code and updating documentation.

Process of maintaining an information system

The maintenance process resembles a small development cycle:

1. Obtain a maintenance request: users submit a request or error report using a standard form (a system service request).
2. Transform the request into changes: the request is analysed, its type, urgency and cost are determined and it is approved and prioritised by a change control board.
3. Design the changes: the analyst studies the existing system and documents, and designs the modification and the effect on other parts.
4. Implement the changes: programmers modify the code, database and documents.
5. Test the changes: unit, integration and regression tests make sure the change works and nothing else is broken.
6. Release the new version: install the revised system, train users, update the documentation and record the change in version control.

Example: A college fee system calculates a late fine wrongly (corrective). The request is logged, approved, the analyst finds the faulty rule, the programmer fixes it, regression tests are run, and the new version is installed with the change recorded.

Why we draw a DFD

A Data Flow Diagram (DFD) shows graphically how data moves through a system: from external entities into processes, through data stores and out again as outputs. We draw it because:

• It shows the system's processes and data flows clearly without technical details.
• It is easily understood by users and analysts, so it improves communication.
• It helps to define the system boundary, and to find missing, redundant or illogical processes.
• It supports top-down decomposition of a complex system into smaller parts.
• It forms the basis for design and documentation of the system.

Symbols (Yourdon/DeMarco): process (circle), data flow (arrow), data store (open rectangle) and external entity (rectangle).

Process of drawing a DFD

1. List the external entities, the inputs and outputs, the processes and the data stores from the problem description.
2. Draw the context diagram (level 0): one process for the whole system, with the external entities and the main data flows entering and leaving.
3. Expand it into the level 1 DFD by splitting the system into the main processes (usually 3 to 7), numbering them, and adding data stores and flows between them.
4. Decompose complex processes further into level 2 diagrams. Keep the numbering hierarchical (1.1, 1.2).
5. Label every process with a verb phrase, every flow and store with a noun, and check balancing: inputs and outputs of a parent process must equal those of its child diagram.
6. Review with the users and correct errors.

Example: Library system

Context diagram: the process "Library Management System" with the external entities Member and Librarian. Member sends the book request and receives issue slip; Librarian sends new book details and receives reports.

Level 1: process 1.0 Register Member, 2.0 Issue Book, 3.0 Return Book, 4.0 Generate Report. Data stores: D1 Member, D2 Book, D3 Issue record. Flows: member details go from Member to 1.0 and into D1; the book request goes to 2.0, which reads D1 and D2, writes D3 and sends the issue slip to Member; the returned book goes to 3.0, which updates D3 and D2; 4.0 reads the stores and sends the report to the Librarian.

I would choose the waterfall method (a plan-driven, sequential approach), possibly with limited iterative elements inside phases.

Reasons

• Requirements are stable and well known. An air traffic control system replaces an existing one, so functions, regulations and safety standards are defined in advance and change little.
• Safety critical. Failure can cost lives, so detailed specification, design reviews, formal documentation and verification at each phase are essential. Waterfall's phase-gate approvals fit this.
• Large, government project. Contracts, budgets, audits and regulatory certification require complete documentation, fixed milestones and clear accountability, which waterfall gives.
• Many teams and vendors. Hardware, radar, communication and software are developed together, so clear interfaces and a fixed design are needed early.
• Cost of late change is very high. Changing the design after coding is expensive in such a system; it is better to get the design right first.
• No working partial system can go live. Controllers cannot use half the system, so frequent incremental releases to production do not help (although prototypes and simulators can be used for training).

Limitations accepted: waterfall is inflexible and users see the product late. To reduce this, I would use early prototypes for the user interface, strong requirements review and risk analysis. Agile would suit projects with changing requirements and no safety constraints, such as a web application.

A software project manager is responsible for delivering the software product within time, budget and quality. The roles and responsibilities are:

1. Project planning: defining scope, objectives and deliverables, breaking the work into tasks (WBS), scheduling and estimating effort and cost.
2. Team formation and leadership: selecting, assigning and motivating team members, defining roles, and resolving conflicts.
3. Resource management: obtaining and allocating hardware, software, tools, people and money.
4. Risk management: identifying, assessing and planning to reduce risks (technical, schedule, staff turnover).
5. Monitoring and control: tracking progress against the plan, holding review meetings, controlling changes in scope and taking corrective action.
6. Quality management: setting standards, arranging reviews and testing so that the product meets requirements.
7. Communication and coordination: liaising with the client, users, top management and the team; reporting status and managing expectations.
8. Budget and cost control: tracking spending and avoiding overruns.
9. Configuration and documentation management: version control and project records.
10. Project closure: product delivery and acceptance, post-project review and lessons learned.

An ER schema is converted into relations by making each entity a relation, handling composite and multivalued attributes, and then applying the cardinality rules to each relationship.

Example

• Entity EMPLOYEE(<u>Emp_Id</u>, Name, Address(Street, City), Phone*). Address is composite and Phone (*) is multivalued.
• Entity DEPARTMENT(<u>Dept_Id</u>, Dept_Name).
• Entity PROJECT(<u>Proj_Id</u>, Title).
• Relationship WORKS_IN: DEPARTMENT 1 : N EMPLOYEE (one department has many employees; each employee belongs to one department).
• Relationship ASSIGNED_TO: EMPLOYEE M : N PROJECT, with the attribute Hours.

Conversion

1. Entities become relations. Composite attribute Address is replaced by its components Street and City.
2. Multivalued attribute Phone becomes its own relation, with Emp_Id as a foreign key.
3. 1:N relationship: the key of the "one" side (Dept_Id) is added to the "many" side (EMPLOYEE) as a foreign key.
4. M:N relationship becomes a new relation whose key is the combination of both keys, with the relationship's attribute.

Resulting relations

• DEPARTMENT(<u>Dept_Id</u>, Dept_Name)
• EMPLOYEE(<u>Emp_Id</u>, Name, Street, City, Dept_Id), with Dept_Id as foreign key
• EMP_PHONE(<u>Emp_Id, Phone</u>), with Emp_Id as foreign key
• PROJECT(<u>Proj_Id</u>, Title)
• ASSIGNMENT(<u>Emp_Id, Proj_Id</u>, Hours), both columns are foreign keys

Deliverable

A deliverable is a tangible, verifiable product or document produced at the end of a project phase or activity and handed over for review or to the client. Examples are a feasibility report, a project plan, a design document or a tested program. Deliverables mark milestones and show that the phase is complete.

Major deliverables of the planning phase

The planning phase answers whether the system should be built and how the project will be run. Its main deliverables are:

1. Project request / system service request: the initial statement of the need, problem or opportunity, and its business value.
2. Feasibility study (feasibility analysis): assesses the economic, technical, operational, schedule and legal feasibility, and compares alternatives.
3. Baseline project plan (BPP): the scope, schedule, resources, budget, staffing, risks and assumptions of the project.
4. Statement of work (SOW): a short document for the client describing the objectives, work, deliverables and the timeline.
5. Project schedule (Gantt/PERT charts) and work breakdown structure.
6. Cost-benefit analysis and budget and the risk assessment.
7. Project approval/go decision by the steering committee to proceed to the analysis phase.

Significance of normalization

Normalization is the process of organising the data in a relational database into well-structured relations by removing redundancy and undesirable dependencies. Its significance:

• It reduces data redundancy and saves storage.
• It removes insertion, deletion and update anomalies.
• It maintains data consistency and integrity.
• It gives a flexible, logical design that is easy to modify and extend.
• It makes each relation represent one subject, so queries are simpler and maintenance is easier.

Second Normal Form (2NF)

A relation is in 2NF if it is in 1NF (no repeating groups, atomic values) and every non-key attribute is fully functionally dependent on the whole primary key, that is, there is no partial dependency on part of a composite key. A relation with a single-attribute key is automatically in 2NF if it is in 1NF.

Example

ENROLL(Student_Id, Course_Id, Student_Name, Course_Title, Grade) with the composite key (Student_Id, Course_Id).

Dependencies:

• (Student_Id, Course_Id) → Grade (full dependency)
• Student_Id → Student_Name (partial dependency)
• Course_Id → Course_Title (partial dependency)

The partial dependencies cause redundancy (the student's name repeats for every course) and anomalies. To convert to 2NF, decompose:

• STUDENT(<u>Student_Id</u>, Student_Name)
• COURSE(<u>Course_Id</u>, Course_Title)
• ENROLL(<u>Student_Id, Course_Id</u>, Grade)

Now every non-key attribute depends on the whole key in each relation, so all are in 2NF.

Installation is the process of replacing the old system with the new one. The four approaches are:

1. Direct (abrupt/cutover) installation The old system is switched off and the new one is switched on at a specific date. It is simple and cheap, but very risky since any failure stops the operation and there is no fallback.

2. Parallel installation The old and new systems run together for a period, and outputs are compared. If the new system fails, the old one continues. It is the safest approach with low risk, but costly because two systems and double work (data entry, staff, operation) are needed. It is also tiring for the users.

3. Single-location (pilot) installation The new system is installed first at one site (a branch or department) as a pilot. Problems are found and fixed before roll-out to other places. Risk and cost are limited to one location, but different sites run different systems for a time.

4. Phased (staged) installation The new system is installed in stages, module by module or function by function, with each stage integrated with the old system. It lowers risk and allows learning, but takes longer and needs temporary interfaces between the old and new parts.

Most expensive and risky

Parallel installation is the most expensive because it duplicates effort and resources. Direct installation is the most risky, since there is no backup if the new system fails.

Given: installation cost = Rs 2,00,000; profit per year = Rs 50,000; interest rate = 6%.

Simple payback period

$\frac{200{,}000}{50{,}000}=4\text{ years}$

Payback period with time value of money (discounted payback)

Discount each year's profit at 6%: PV $= \dfrac{50{,}000}{1.06^t}$.

The cumulative PV exceeds Rs 2,00,000 during year 5. The fraction of year 5 needed:

$\frac{200{,}000-173{,}255}{37{,}363}=0.72$

So the discounted payback period is about 4.7 years (about 4 years and 9 months). Ignoring interest, it would be 4 years.

Rules for diagramming DFDs

1. Every process must have at least one input and at least one output data flow (no miracles, no black holes).
2. A process name is a verb phrase, and each process is uniquely numbered.
3. Data cannot flow directly between two external entities, between two data stores, or between an entity and a data store. A process must be in between.
4. Data flows are named with nouns, flow in one direction (or have clearly separate arrows) and are never named "data".
5. A data store must have at least one input and one output flow, and is named with a noun.
6. External entities are outside the system boundary and are shown as rectangles.
7. A DFD shows data, not control or flow-chart decisions, loops or time sequence.
8. The child diagram must balance with its parent: the inputs and outputs must be the same.
9. Avoid crossing lines and keep each diagram to about 7 plus or minus 2 processes.

Context diagram (Level 0)

                 application form (personal details, desired course)
   +---------+ ----------------------------------------> +-----------------+
   | STUDENT |                                           |    0            |
   |         | <---------------------------------------- |  Student        |
   +---------+  confirmation letter / rejection letter   |  Enrollment     |
                                                         |  System         |
   +-----------+  course availability, qualification     |                 |
   | UNIVERSITY| <-------------------------------------> |                 |
   | (registry)|        rules, enrollment record         +-----------------+
   +-----------+

External entities: Student and University (Admissions/Registry). The single process is the Student Enrollment System.

Top-level (Level 1) logical DFD

Processes:

• 1.0 Receive Application: takes the application form from the Student and records the applicant details in store D1.
• 2.0 Check Course Availability and Qualification: reads the applicant details from D1, the course details from D2 Course and the entry requirements, then produces the result (eligible/not eligible, available/unavailable).
• 3.0 Enroll Student: if the course is available and the student is qualified, writes the enrollment into D3 Enrollment, and updates the seats in D2.
• 4.0 Send Confirmation Letter: reads the enrollment from D3 and sends the confirmation letter to the Student.
• 5.0 Send Rejection Letter: for an unavailable course or non-qualified student, sends the rejection letter to the Student.

Data stores: D1 Applicant, D2 Course, D3 Enrollment.

Flows:

STUDENT --application form--> (1.0 Receive Application) --applicant record--> [D1 Applicant]
[D1 Applicant] --applicant details--> (2.0 Check Availability & Qualification) <--course details-- [D2 Course]
(2.0) --accepted application--> (3.0 Enroll Student) --enrollment record--> [D3 Enrollment]
(3.0) --enrollment details--> (4.0 Send Confirmation Letter) --confirmation letter--> STUDENT
(2.0) --rejected application--> (5.0 Send Rejection Letter) --rejection letter--> STUDENT
(3.0) --seat update--> [D2 Course]

The diagram balances with the context diagram: the only input is the application form and the only outputs are the confirmation and rejection letters, both exchanged with the Student.

Factors that influence the cost of maintenance

1. Number of latent defects: poorly tested or designed systems contain more errors to correct.
2. Number of customers / users: more users mean more requests, more training and support, and more installations to update.
3. Quality of system documentation: poor or outdated documents make understanding the system slow and costly.
4. Maintenance personnel: the experience, skill and turnover of the staff; new staff need time to learn the system.
5. Tools: use of CASE tools, version control and testing tools reduces effort.
6. Software structure and programming language: modular, well-structured code is cheaper to change than complex "spaghetti" code or old languages.
7. Database and platform: the type of database, the hardware and its changes.
8. Age and size of the system: older and larger systems cost more to maintain.
9. Stability of requirements and environment: frequent changes in business rules, laws or technology.
10. Relationship to other systems: more interfaces mean a change spreads to other systems.

Steps in the maintenance process

1. Obtain a maintenance request from a user (a standard request form).
2. Transform the request into changes: analyse, estimate, approve and schedule.
3. Design the changes: plan the modification and its effect.
4. Implement the changes: coding and database changes, documents updated.
5. Test and release: test the changes and regression, then install the new version.

Contrast with the system development life cycle (SDLC)

In effect, maintenance repeats the SDLC phases in a smaller scale, but the work is done within the limits of an existing system, which makes it harder to understand and riskier, and it adds the need to continue the production service during the change.

Qualities of a software tester

• Analytical and critical thinking, with the ability to find where a system may fail.
• Attention to detail and patience to repeat tests carefully.
• Curiosity and a questioning attitude ("break the system" mind-set).
• Good communication skills to report defects clearly and politely to developers.
• Technical knowledge of the application, programming basics, databases and testing tools.
• Domain knowledge and the user's viewpoint.
• Honesty, discipline and objectivity, with a sense of responsibility for quality.
• Creativity in designing test cases, and the ability to work in a team and under time pressure.

Deliverables

Types of software testing

1. Unit testing: each module is tested separately. White-box methods (statement, branch and path coverage) check the internal logic, and drivers and stubs are used.
2. Integration testing: modules are combined and the interfaces are tested. Approaches: top-down (using stubs), bottom-up (using drivers), sandwich and big-bang.
3. System testing: the whole system is tested against the requirements: functional, performance, stress, security, recovery and compatibility testing.
4. Acceptance testing: the users test the system with real data to confirm that it meets their needs. It includes alpha testing (by internal users) and beta testing (by selected external users).
5. Black-box testing: tests are derived from the specification, without knowledge of the code, using equivalence partitioning and boundary value analysis.
6. White-box testing: tests are derived from the code structure.
7. Regression testing: re-running earlier tests after a change to check that old functions still work.
8. Static testing: code inspection, walkthroughs and desk checking, which find errors without running the program.

Baseline Project Plan (BPP)

The baseline project plan is the major deliverable of the project initiation and planning phase. It is a document that contains the best estimate of the project's scope, benefits, costs, risks and resource requirements, after the feasibility study. It is the basis for approval by management and serves as the reference ("baseline") against which progress is measured through the project. It is updated as more information is obtained.

Major parts of the baseline project plan

1. Introduction: gives the overview of the project, its background and the recommended course of action.
2. System description: the outline of the possible alternative solutions and the one recommended.
3. Feasibility assessment: the economic (cost-benefit), technical, operational, schedule, legal and political feasibility of the project.
4. Management issues: the team configuration and roles, communication plan, project standards and procedures, and the project schedule (Gantt/PERT chart) and budget.
5. Project scope: the boundaries, objectives, deliverables, assumptions and constraints.
6. Risk analysis and resource plan: the risks and their effect, and the people, hardware, software and funds required.
7. Approval signatures of the sponsors.

An additional statement of work (SOW) is often prepared for the client.

Interactive methods are the techniques in which the analyst communicates directly with the users to collect requirements, in contrast to document review. The main ones are:

1. Interviews The analyst asks the user questions face to face. They may be structured (planned questions) or unstructured (free discussion). They give detailed information and allow follow-up questions. Example: the analyst interviews the librarian about how books are issued and returned.

2. Joint Application Design (JAD) A structured group workshop where users, managers, analysts and developers meet for a few days to define requirements and design the system, under a facilitator. Example: a one-week workshop with the finance, sales and IT departments to define an accounting system.

3. Questionnaires Written questions given to many users who answer on their own. Example: a survey of students on the features they want in a college web portal.

4. Observation The analyst watches users do their work in the real setting to see what actually happens. Example: watching the cashier at the counter to see how bills are processed.

5. Prototyping A working model of part of the system is built quickly and users react to it, which refines the requirements. Example: a mock-up of the screens of a hospital registration system.

6. Group Support Systems / brainstorming and focus groups Electronic or face-to-face sessions where participants contribute ideas anonymously or openly, such as a discussion group of customers for an online shop.

System testing

System testing is the testing of the complete, integrated software system (together with hardware, data and users' procedures) to check that it meets the specified requirements, and works correctly as a whole. It is done after integration testing and before acceptance testing, usually by an independent test team, as black-box testing.

Types of system tests

1. Functional testing: checks that each function behaves according to the requirement specification.
2. Performance testing: measures response time, throughput and resource use under expected load.
3. Stress (load) testing: loads the system beyond its normal limits (many users, large data) to see where and how it breaks.
4. Security testing: checks authentication, authorisation, data protection and resistance to attack.
5. Recovery testing: forces failures (power loss, crash) to check that the system recovers its data and operation correctly.
6. Usability testing: checks the ease of use, screens, help and the user interface.
7. Compatibility (configuration) testing: checks operation on different hardware, operating systems, browsers and networks.
8. Installation testing: checks that the system can be installed, upgraded and removed properly.
9. Regression testing: re-tests after modifications to ensure that existing functions are not damaged.
10. Documentation testing: checks that manuals and help match the system.

Documentation is the written record of what a system is meant to do, how it is built and how it is used. It supports every phase of the system life cycle, and a system without it is hard to build, review, use or change.

Role in system development

• Communication: analysts, designers, programmers, testers and users share one agreed description (requirement specification, DFDs, ER diagrams, design documents), which reduces misunderstanding.
• Continuity: when team members leave or join, documents carry the knowledge, so the project does not depend on memory.
• Guidance for design and coding: the specification and design documents tell programmers exactly what to build and how modules interact.
• Basis for testing: test plans and test cases are derived from the documented requirements.

Role in system review

• Auditors and reviewers compare the delivered system against the documented requirements and standards to judge whether it meets its objectives.
• Project records (schedule, cost, change requests) allow progress, cost and quality to be evaluated at each milestone.
• Review findings can be traced to the exact document and decision that caused a problem.

Role after delivery

• User documentation (manuals, help, training material) lets users operate the system without constant support.
• System documentation (data dictionary, program descriptions, database design) makes maintenance and enhancement faster and cheaper, because a maintainer can see what a change will affect.
• It is also evidence for legal, contractual and audit purposes.

Hence documentation is not a final chore but an ongoing activity; it makes development controlled and reviewable, and the system maintainable.

Maintenance is the modification of an information system after it has been delivered and put into operation, so that it continues to give correct and useful service.

Why it is important

• Errors that escape testing appear in real use and must be fixed.
• Business rules, laws, hardware and software platforms change, and the system must follow.
• Users ask for new features and better performance as they gain experience.
• Maintenance protects the large investment already made; for most systems it consumes more effort and cost than development itself.
• It keeps the system reliable, secure and useful for its whole life.

Types of maintenance

1. Corrective maintenance: diagnosing and fixing faults (bugs) found after delivery, such as a wrong calculation or a crash. It is usually urgent.
2. Adaptive maintenance: changing the system to suit a new environment, such as a new operating system, database version, hardware or government regulation (for example a changed tax rate).
3. Perfective maintenance: improving or extending the system without a fault, such as adding reports, making screens easier to use or speeding up queries. It is the largest share of maintenance.
4. Preventive maintenance: restructuring code, updating documentation or tightening security to avoid future problems and make later changes easier.

Normalization is the process of organising the attributes of a relational database into well-structured relations by removing redundancy and undesirable dependencies, using a series of normal forms (1NF, 2NF, 3NF, BCNF). Its aim is to give relations that store each fact only once.

• 1NF: every attribute holds a single atomic value; no repeating groups.
• 2NF: 1NF and no partial dependency of a non-key attribute on part of a composite key.
• 3NF: 2NF and no transitive dependency (a non-key attribute depending on another non-key attribute).

Major objectives of database design

1. Data integrity and accuracy: data must be consistent and correct; each fact is stored in one place so it cannot disagree with itself.
2. Minimum redundancy: duplicated data wastes storage and causes insertion, deletion and update anomalies. Normalization removes it.
3. Data independence: programs should not need to change when storage structure changes.
4. Fast and efficient retrieval: structure and indexes should give acceptable response time for the common queries and reports.
5. Ease of maintenance and flexibility: new data or requirements can be added with little restructuring.
6. Security and recovery: access is controlled and data can be restored after failure.
7. Support for all user views: the design must meet the information needs of every user and application.

Data Flow Diagram (DFD) is a graphical tool of structured analysis that shows how data moves through a system: where it comes from, which processes transform it, where it is stored and where it goes. It shows what the system does, not how or when.

Symbols: a process (circle or rounded box), a data flow (arrow), a data store (open rectangle) and an external entity (square).

Rules for drawing a DFD

1. Every process has a unique name (verb phrase) and number, and has at least one input and one output flow. No miracles (output with no input) and no black holes (input with no output).
2. Data cannot flow directly between two external entities, two data stores, or an entity and a store; a process must be in between.
3. Every data flow has a label (noun) describing the data it carries, and flows have direction.
4. Data stores and entities appear only where data is actually kept or exchanged; a store's name is a noun.
5. Parent and child diagrams must balance: inputs and outputs of a process must equal those of its child diagram.
6. Keep the diagram readable (about 7 +/- 2 processes per level), avoid crossing lines, and number processes hierarchically (1, 2; 1.1, 1.2).
7. Level 0 (context diagram) has one process for the whole system and no data stores.

DFD for Library Management System

Level 0 (context diagram)

 Member    --membership form, book request-->   +---------------+
 Member   <--issued book, fine receipt------   |  0 Library    |
 Librarian --book details, member updates--->  |  Management   |
 Librarian<--reports------------------------   |  System       |
 Supplier <--purchase order-----------------   +---------------+
 Supplier  --new books, invoice------------>

Level 1

Member --registration details--> [1 Manage Members] <--> D1 Member
Member --book request----------> [2 Search Books]  <---  D2 Book
Member --issue/return request--> [3 Issue and Return Books]
                                    |  reads/writes D2 Book, D1 Member
                                    |  writes D3 Issue Record
[3] --fine details--> [4 Calculate Fine] <--> D3 Issue Record
[4] --fine receipt--> Member
Librarian --new book details--> [5 Manage Books] <--> D2 Book
[5] --purchase order--> Supplier ;  Supplier --books, invoice--> [5]
D1, D2, D3 --> [6 Generate Reports] --reports--> Librarian

The six processes are: 1 Manage Members, 2 Search Books, 3 Issue and Return Books, 4 Calculate Fine, 5 Manage Books (acquisition), 6 Generate Reports. Data stores are D1 Member, D2 Book and D3 Issue Record.

(a) Guidelines for designing forms and reports

Forms (input and display)

• Give each form a meaningful title and keep the layout consistent across the system.
• Group related fields together and arrange them in a logical, natural order (left to right, top to bottom, matching the source document).
• Label every field clearly, show its length and format (for example DD/MM/YYYY) and mark mandatory fields.
• Provide default values, drop-down lists, check boxes and radio buttons to reduce typing.
• Validate input immediately (type, range, required, format) and give clear, polite error messages.
• Use colour, fonts and white space sparingly and consistently; keep the screen uncluttered.
• Provide help, a way to cancel or go back, and a clear confirmation of successful entry.

Reports (output)

• State the purpose, title, date and page number; identify the reader and what decisions the report supports.
• Show only the information the reader needs, with totals and sub-totals where useful.
• Arrange columns in a logical order, align numbers to the right and text to the left, and use consistent headings.
• Use summary, exception and detail reports as appropriate, and choose a suitable medium (screen, print, file).
• Keep it readable: adequate spacing, headings repeated on each page, and a sensible sort order.

(b) Types of system implementation (conversion)

1. Direct (abrupt) conversion: the old system is stopped and the new one starts on a given date. It is cheap and fast but the most risky.
2. Parallel conversion: old and new systems run together for a period and outputs are compared. It is safest but costly, because the work is done twice.
3. Pilot (location) conversion: the new system is installed first at one site or department, and rolled out to others after it proves successful.
4. Phased (staged) conversion: the new system is introduced module by module or function by function, replacing the old one gradually. It reduces risk and eases training but takes longer.

System requirements analysis is the phase in which the analyst finds out what the users and the organisation need from the new system. It involves collecting information about the current system and its problems, identifying what the new system must do (functional requirements) and the constraints it must meet (non-functional requirements such as performance, security and usability), and recording them in a requirements specification that is agreed by users and used for design.

Methods (types) of determining system requirements

1. Interviews: the analyst talks face to face with managers and users, using structured or unstructured questions. It gives detailed, flexible information and shows attitudes, but is time-consuming and depends on the interviewer.
2. Questionnaires: a set of written questions given to many people. It is cheap, reaches a large number of respondents and is easy to analyse, but responses may be shallow and not everybody replies.
3. Observation: the analyst watches users doing their work to see how tasks are really performed. It gives first-hand, accurate facts, though people may behave differently when watched.
4. Document (record) review: studying forms, reports, manuals, procedures, files and earlier system documents shows the data, rules and formal procedures in use.
5. Joint Application Development (JAD): a structured workshop in which users, managers and analysts together define requirements, led by a facilitator. It is fast and builds agreement.
6. Prototyping: a working model is built, shown to users and refined from their feedback, helping when users cannot state needs in advance.
7. Business process reengineering and Group Support Systems are other contemporary methods, rethinking processes or using electronic meeting tools.

In practice several methods are combined, because each reveals different information.

System is a set of interrelated components that work together in an organised way to achieve a common goal or objective. Examples are a computer system, a college or a banking system.

Components of a system

1. Input: data, energy or material entering the system for processing.
2. Processing: the activities that transform the input into output.
3. Output: the result produced by the system and passed to its environment.
4. Feedback: information about output that is returned to control or adjust the input and processing.
5. Control: mechanisms that monitor and regulate the system to keep it on target.
6. Boundary and environment: the boundary separates the system from its environment, which is everything outside that affects or is affected by it.
7. Interface: the point where the system connects with other systems or users.

Characteristics of a system

• Organisation: components are arranged in a structured way.
• Interaction and interdependence: the parts depend on and act upon one another.
• Integration: the parts work as one whole.
• Central objective: all parts work toward a single goal.
• Subsystems and hierarchy: a system is made of subsystems and is itself part of a larger system.
• Open or closed: open systems exchange with the environment; closed ones do not.
• Adaptability and equilibrium: the system adjusts to change to keep a stable state.

CASE tool (Computer-Aided Software Engineering tool) is a software tool that automates and supports activities of system development, such as drawing diagrams, keeping a data repository, checking consistency, and generating documents and code. It improves productivity, quality and consistency.

Types of CASE tools in the phases of SDLC

1. Upper CASE tools: used in the early phases (planning, analysis, design). They help to capture requirements and draw DFDs, ER diagrams, UML models and data dictionaries, and check them for completeness. Examples: Visible Analyst, Microsoft Visio, Rational Rose.
2. Lower CASE tools: used in later phases (implementation, testing, maintenance). They include code generators, compilers and debuggers, testing tools and tools for version control and re-engineering.
3. Integrated CASE (I-CASE) tools: cover the whole life cycle in one environment, sharing a common repository, so upper and lower tools exchange information.

By function

• Diagramming tools for modelling processes and data.
• Repository (dictionary) tools that store all system specifications centrally.
• Prototyping and screen/report generators for forms and reports.
• Code generators that produce program code from design specifications.
• Documentation generators that produce manuals and reports automatically.
• Analysis tools that check models for errors, inconsistencies and redundancy.
• Testing and project-management tools that run tests and track schedules and costs.

Information system planning (ISP) is the process of identifying, ranking and selecting the information systems projects an organisation should develop, so that its information systems match its business goals, resources and long-term strategy. It examines the current systems, defines the future information needs and prepares a plan with priorities, schedule and budget.

Top-down planning: begins at the highest level of management. Strategic business goals and the overall information needs are determined first, and from them the systems and projects needed are derived.

Bottom-up planning: begins at the operational level. Projects are proposed by individual departments or users to solve their own immediate problems, and are then collected and prioritised.

Top-down planning gives a coherent, strategic view, while bottom-up planning responds quickly to real needs; many organisations combine them.

JAD (Joint Application Development) is a structured group process, developed by IBM, in which users, managers, analysts and other stakeholders meet in facilitated workshop sessions to jointly define requirements and design the system, instead of the analyst interviewing people one by one. It shortens the requirements phase and reduces misunderstanding.

Contemporary requirements determining techniques

1. Joint Application Development (JAD): a facilitator leads a meeting with a scribe, users, managers and IT staff. Agreed requirements are recorded during the session, giving quick decisions and shared ownership.
2. Prototyping: a quick working model (screens, reports or processes) is built and shown to users, who comment, and it is revised repeatedly. It is useful when requirements are unclear, but may encourage incomplete analysis.
3. Group Support Systems (GSS): electronic meeting software lets participants enter ideas anonymously and at the same time, which encourages honest input from everyone.
4. CASE tools: the requirements are stored in a repository and models are drawn and checked automatically.
5. Business Process Reengineering (BPR): the analyst questions and radically redesigns existing business processes, looking for large improvements rather than only automating the old way.
6. Use cases and scenarios (and agile user stories): requirements are captured as interactions between users and the system.
7. Searching the Internet and existing software to learn from similar systems and standards.

Data modeling is the technique of organising and documenting the data of a system by identifying the entities, their attributes and the relationships among them. It produces a model (usually an ER diagram) that shows what data is stored and how it is connected, and it is the basis for database design.

Logical data model

A logical data model describes the data in detail and in a form independent of any particular DBMS and physical storage. It is derived from the conceptual model and is the step before the physical design.

Main elements

• Entities: all entities needed, with a primary key identifying each instance.
• Attributes: every attribute of each entity, with data type and domain.
• Relationships: the associations between entities with their cardinality (one-to-one, one-to-many, many-to-many) and participation. Many-to-many relationships are resolved by adding associative entities.
• Keys: primary keys, candidate keys and foreign keys that implement the relationships.
• Normalization: the model is normalised (normally to 3NF) to remove redundancy and anomalies.

Example: STUDENT(<u>RollNo</u>, Name, Address), COURSE(<u>CourseCode</u>, Title), ENROLLMENT(<u>RollNo, CourseCode</u>, Grade), where RollNo and CourseCode in ENROLLMENT are foreign keys.

Characteristics: it is more detailed than the conceptual model, uses no DBMS-specific details such as indexes or storage, is stable and reusable across DBMS choices, and is the foundation from which the physical model (tables, data types, indexes) is created.

A menu is a list of options from which the user selects an action. Different menu styles suit different levels of system complexity and user experience.

1. Menu bar (horizontal menu): a bar across the top of a window with the main categories (File, Edit, View, Help). It is always visible and familiar.
2. Drop-down menu: appears below an item in the menu bar when selected, and lists the commands in that category. It saves screen space.
3. Pop-up (context) menu: appears at the cursor, usually on right-click, and offers commands relevant to the selected object.
4. Cascading (nested) menu: selecting an item opens a submenu beside it. It organises many options hierarchically, but deep levels are hard to use.
5. Tabbed menu: a row of tabs, each opening a group of options or a page (as in settings dialogs).
6. Full-screen (single) menu: a numbered list of options filling the screen, common in text-based systems and ATMs. It is simple for novices.
7. Tree or hierarchical menu: an expandable folder-like list, useful when there are many levels.
8. Toolbar and icon menus: buttons with icons for the common commands, giving quick access to experienced users.
9. Command-line or hot-key menus: typed commands or keyboard shortcuts for expert users.

Design considerations: use clear, short, meaningful names; group related items; limit the number of choices and levels; keep order and wording consistent; and indicate unavailable options and shortcuts. Simple systems suit single menus, while complex systems need menu bars with drop-down or cascading menus.

Why software projects often fail

• Unclear, incomplete or frequently changing requirements, and poor user involvement.
• Unrealistic schedule and budget estimates.
• Weak project management, planning and risk control.
• Inadequate communication between users, analysts and developers.
• Poor design, lack of skilled staff or unsuitable technology.
• Insufficient testing, so errors reach the user.
• Lack of management support, and scope creep (uncontrolled added features).
• Resistance to change from users and poor training.

Types of software testing

1. Unit testing: each module or program is tested alone to find errors in its logic.
2. Integration testing: tested modules are combined and the interfaces between them are checked.
3. System testing: the complete integrated system is tested against the requirements, including performance, security and recovery.
4. Acceptance testing: users test the system with real data to decide whether to accept it. It has alpha testing (at the developer's site) and beta testing (at the user's site).
5. Black-box testing: tests functionality from inputs and outputs without looking at the code.
6. White-box testing: tests the internal structure, such as paths and branches, using knowledge of the code.
7. Regression testing: re-testing after changes to ensure that nothing that worked earlier has broken.

Phases of the Systems Development Life Cycle (SDLC)

1. Planning (preliminary investigation): the problem or opportunity is identified, the project is defined, and its feasibility (technical, economic, operational, schedule) is studied. The output is a project plan and a decision to proceed.
2. Analysis: the analyst studies the current system and collects requirements using interviews, questionnaires, observation and document review. Requirements are modelled (DFDs, ER diagrams) and documented in a requirement specification.
3. Design: the new system is specified in logical and physical terms: database, inputs and outputs (forms and reports), user interface, processes, hardware and software, and security. The output is the design specification.
4. Implementation (construction): programs are coded and tested, hardware and software are installed, data is converted, users are trained, documentation is prepared and the system is put into use (conversion).
5. Maintenance (support): after delivery the system is corrected, adapted to change and improved until it is retired or replaced.

Role of the Project Manager

• Planning: defines scope, objectives, tasks, schedule and budget, and estimates resources.
• Organising and staffing: forms the team, assigns roles and tasks, and arranges skills and training.
• Leading and communication: guides and motivates the team, and keeps clients, users and management informed.
• Controlling: monitors progress, cost and quality against the plan, and takes corrective action.
• Risk and change management: identifies risks early, and manages change requests to stop scope creep.
• Quality and delivery: ensures testing, documentation and acceptance, and that the project is delivered on time, within budget and to the requirements.

Process modeling is the technique of graphically representing the processes of a system: how data is input, transformed by activities and output. It describes what the system does with data, and the Data Flow Diagram (DFD) is the main tool, supported by structured English, decision tables and decision trees.

Why we need DFD

• It gives a clear, simple picture of the system that both users and analysts can understand, helping communication.
• It shows the flow of data between processes, stores and external entities, and thus the boundary of the system.
• It supports top-down decomposition: a complex system is broken into levels of increasing detail.
• It helps to find missing, duplicate or unnecessary processes and data in the current system.
• It is a basis for design and a useful part of the documentation.

DFD for Online Hotel Room Booking System

Level 0 (context diagram)

 Customer --search criteria, booking details, payment--> +-----------------+
 Customer <--room list, confirmation, receipt----------- |  0 Online Hotel  |
 Hotel Staff --room details, rates, check-in/out-------> |  Room Booking    |
 Hotel Staff <--booking list, reports------------------ |  System          |
 Payment Gateway <--payment request-------------------- +-----------------+
 Payment Gateway --payment status------------------------>

Level 1

Customer --registration/login--> [1 Manage Customer Account] <--> D1 Customer
Customer --search criteria-----> [2 Search Rooms] <--- D2 Room
[2] --available rooms--> Customer
Customer --booking details--> [3 Book Room] <--> D3 Booking ; reads D2 Room
[3] --payment request--> Payment Gateway --status--> [4 Process Payment] <--> D4 Payment
[3],[4] --confirmation, receipt--> Customer
Hotel Staff --room details, rates--> [5 Manage Rooms] <--> D2 Room
D3 Booking, D4 Payment --> [6 Generate Reports] --> Hotel Staff

Processes are: 1 Manage Customer Account, 2 Search Rooms, 3 Book Room, 4 Process Payment, 5 Manage Rooms, 6 Generate Reports. Data stores are D1 Customer, D2 Room, D3 Booking and D4 Payment.

Activities of the implementation phase

1. Coding (programming): the design specifications are turned into working programs in the chosen language, following standards.
2. Testing: unit, integration, system and acceptance testing find and remove errors before the system goes live.
3. Installation: hardware, software, network and the new system are installed and configured at the user site, and data is converted from old files to the new system.
4. Documentation: system documentation (for maintainers) and user documentation (manuals, help, quick guides) are prepared.
5. Training and supporting users: users and operators are taught to use the system, and a support service is arranged.
6. Conversion (changeover): the organisation moves from the old system to the new by direct, parallel, pilot or phased conversion.
7. Review and handover: the system is checked against requirements, accepted by the users and handed over to the support or maintenance team.

Methods of training and supporting users

Training methods

• Classroom (instructor-led) training: a trainer teaches a group; allows questions and discussion.
• One-to-one (on-the-job) coaching: an expert guides a user at the workplace.
• Computer-based and e-learning: self-paced tutorials, videos and simulations.
• Printed manuals and tutorials, and vendor or outside courses for specialised skills.
• Pilot or sandbox practice on a training copy of the system.

Support methods

• Help desk and hotline for questions and problem reports.
• Online help, FAQs, knowledge base and user forums.
• Information centre or power users in each department.
• On-site support from the project team during and just after changeover.
• Newsletters, updates and periodic refresher training.

Information system (IS) is an organised combination of people, hardware, software, data and procedures that collects, processes, stores and distributes information to support operations, management decision making and control in an organisation. Examples are a payroll system, a library system and a student management system.

Characteristics of an information system

• Purposeful: it is built to meet the information needs and objectives of the organisation.
• Input-process-output structure: it takes data as input, processes it and gives useful information as output, with feedback for control.
• Integrated: it combines people, hardware, software, data and procedures into one system.
• Accurate and reliable: it provides correct, consistent information.
• Timely: information is available when needed.
• Relevant and complete: it gives the right amount of information for the user's decisions.
• Accessible and secure: authorised users can reach it easily while unauthorised access is prevented.
• Storage and retrieval: it keeps data in a database so it can be retrieved quickly.
• Flexible and adaptable: it can be changed as needs change.
• Supports different levels: operational, tactical and strategic management use it.

Types of maintenance and when they are implemented

1. Corrective maintenance: fixes errors found in operation (wrong output, crashes, data corruption). It is done as soon as the fault is reported; critical faults need an immediate emergency fix, and minor ones are scheduled in the next release.
2. Adaptive maintenance: changes the system to fit changes in its environment, such as a new operating system, hardware, database, tax law or business rule. It is done when the external change is announced or becomes effective, so that the system keeps working.
3. Perfective maintenance: adds new features or improves performance and usability on user request, for example new reports or faster searches. It is planned and carried out in scheduled releases, after cost-benefit review and priority setting.
4. Preventive maintenance: restructures code, updates documentation and strengthens security so that future faults are avoided and later changes are easier. It is carried out periodically, when the system is quiet, or when signs of ageing appear (growing complexity, repeated faults).

Corrective and adaptive work is usually forced and urgent, while perfective and preventive work is optional and planned. Perfective maintenance normally takes the largest share of effort.

Interface is the point of contact through which the user interacts with the system, that is, the means by which the user gives input and receives output. A user interface includes screens, menus, forms, commands and devices, and a good one is easy to learn, efficient and pleasant.

Methods of interaction

1. Command language interaction: the user types commands (for example in the DOS or Linux shell). It is powerful and fast for experts but requires memorising syntax.
2. Menu interaction: the user chooses from a list of options. It needs little training and has few errors, but can be slow for experts.
3. Form interaction: the user fills fields on an electronic form, as in data entry screens. It resembles paper forms and suits data collection.
4. Object-based (graphical, GUI) interaction: the user manipulates icons, windows and buttons with a mouse or touch (point and click, drag and drop). It is intuitive and easy to learn but uses more resources.
5. Natural language interaction: the user types or speaks in ordinary language, as with voice assistants and chatbots. It is natural but can be ambiguous.
6. Touch, voice and gesture interaction: direct input through touch screens, speech or movement, used on mobile and kiosk systems.

Yes, I agree. Prototyping is an effective method of determining requirements, particularly when users cannot describe exactly what they need.

Prototyping means quickly building a working model of the system or a part of it (screens, reports, key functions), letting users try it, and refining it from their feedback until the requirements are clear.

Justification

• Users see and use something concrete: people find it easier to react to a working screen than to read a specification, so hidden and unstated requirements appear early.
• Early detection of misunderstanding: errors or missing features are found while change is still cheap.
• User involvement and acceptance: users take part actively, which increases satisfaction and reduces resistance.
• Suits unclear or changing requirements: the model evolves through repeated cycles of build, review and revise.
• Reduces risk and cost: it tests technical ideas and the user interface before full development.
• Faster: a first version is available quickly.

Limitations

• Users may think the prototype is the finished system and expect fast delivery.
• It may encourage skipping careful analysis, documentation and design.
• It can be hard to manage and to judge when to stop, and it is unsuited to very large or complex systems.

So prototyping is highly effective for clarifying requirements, if it is used together with other methods and managed carefully.

Cost benefit analysis (CBA) is a technique used in the feasibility study to judge whether a proposed system is economically worthwhile. It lists and quantifies all the costs (development: hardware, software, staff and training; operating: maintenance, supplies, power) and all the expected benefits, and compares them over the life of the system, using methods such as payback period, net present value (NPV) and return on investment (ROI). If benefits exceed costs, the project is economically feasible.

Benefits may be tangible (easily measured in money, such as reduced staff cost, lower inventory or higher sales) or intangible (hard to measure in money).

Areas of intangible benefits

• Improved decision making: more accurate and timely information.
• Better customer service and satisfaction: faster response, fewer errors.
• Improved organisational image and competitive position: a modern, reliable service.
• Increased employee morale and job satisfaction: less routine and boring work.
• Better quality of information and accuracy: consistent, reliable data.
• Greater flexibility and ability to respond to change.
• Improved planning and control: better management of resources.
• Enhanced security, communication and coordination among departments.

Intangible benefits are usually described in words, or estimated in money where possible, and weighed with the tangible ones in the final decision.

Outsourcing is the practice of turning over some or all of an organisation's information systems work (such as development, maintenance, hosting or help desk) to an external company that specialises in it, under a contract.

Advantages

• Cost saving: no need to invest in hardware, software and permanent staff; costs become predictable.
• Access to expertise and the latest technology that the organisation may not have.
• Focus on core business: management time goes to the main activities.
• Faster delivery: experienced vendors can start quickly with ready resources.
• Flexibility and scalability: resources can be increased or decreased as needed.
• Reduced risk, as the vendor takes responsibility under service-level agreements.

Disadvantages

• Loss of control over schedule, quality and decisions.
• Security and confidentiality risk, because sensitive data is shared with outsiders.
• Dependence on the vendor: switching is hard, and vendor failure harms the organisation.
• Hidden and rising costs, such as contract management and charges for changes.
• Loss of in-house skills and knowledge, and lower morale or job fear among staff.
• Communication problems because of distance, time zone or culture, and possible mismatch with business needs.

Forms are used to enter or show data and reports to present information, so their design strongly affects accuracy and usability. The main considerations are as follows.

For forms

• Meaningful titles and clear labels so the user knows the purpose and what to enter.
• Logical flow: group related fields and follow the natural order of the source document, top to bottom and left to right.
• Consistency of layout, terminology, colours and fonts across all forms.
• Ease of data entry: default values, drop-down lists, radio buttons and check boxes, auto-completion, and fields of the right size.
• Validation and clear error messages, with required fields marked and format hints (such as date format).
• Simplicity: avoid clutter, use white space and highlight important items sparingly.
• Help, navigation and confirmation, including the option to go back or cancel.

For reports

• Purpose and audience: include only the information the reader needs for their decisions.
• Clear heading, date, page number and column headings that repeat on each page.
• Logical sequence and sorting, with sub-totals and totals.
• Readable formatting: aligned numbers, suitable fonts and spacing, with charts where useful.
• Appropriate medium and timing: screen or print, and scheduled or on demand.
• Accuracy, and security for sensitive information.

Other considerations: accessibility for all users, cost, and compatibility with the hardware and software in use.

DFD symbols

There are two common notations (Yourdon/DeMarco and Gane-Sarson). The four elements are:

1. Process: a circle or rounded rectangle that transforms input data into output data. It is named with a verb phrase and numbered, for example "2 Process Order".
2. Data flow: an arrow showing the direction of movement of data between elements. It is labelled with a noun, for example "order details".
3. Data store: an open-ended rectangle (two parallel lines) representing data held at rest, such as a file or database table, for example "D1 Orders".
4. External entity (source or sink): a square representing a person, organisation or system outside the boundary that supplies data to or receives data from the system, for example "Customer".

DFD for a Food Ordering System

Assumed requirements: the customer browses the menu, places an order and pays; the restaurant confirms, prepares and delivers it; the manager gets reports.

Level 0 (context diagram)

 Customer <--menu, order confirmation, bill----- +------------------+
 Customer --registration, order, payment-------> |  0 Food Ordering  |
 Restaurant --menu updates, order status-------> |  System           |
 Restaurant <--order details-------------------- |                   |
 Delivery Staff <--delivery details------------- +------------------+
 Delivery Staff --delivery status------------------>
 Manager <--sales report------------------------

Level 1

Customer --registration--> [1 Manage Customer] <--> D1 Customer
Restaurant --menu items--> [2 Manage Menu] <--> D2 Menu
Customer --order request--> [3 Place Order] <-- D2 Menu ; <--> D3 Order
[3] --order details--> Restaurant ; Restaurant --accept/reject--> [3]
Customer --payment--> [4 Process Payment] <--> D4 Payment ; --bill--> Customer
[3] --delivery details--> [5 Deliver Order] <--> Delivery Staff ; updates D3 Order
D3 Order, D4 Payment --> [6 Generate Reports] --sales report--> Manager

Level 2 (decomposition of process 3 Place Order)

3.1 Browse Menu     : Customer --search/choice--> 3.1 <-- D2 Menu --> menu list --> Customer
3.2 Create Order    : Customer --selected items--> 3.2 --order record--> D3 Order
3.3 Calculate Total : 3.2 --items--> 3.3 <-- D2 Menu (prices) ; 3.3 --total, tax--> 3.2
3.4 Confirm Order   : 3.2 --order--> 3.4 --order details--> Restaurant
                      Restaurant --accept/reject--> 3.4 --confirmation--> Customer ; updates D3 Order

The level 2 diagram balances with level 1: process 3 receives "order request" from Customer and "accept/reject" from Restaurant, and gives "order details" to Restaurant and the confirmation to Customer.

Data modeling is the technique of identifying and documenting the data a system needs: entities, their attributes and the relationships between them. The result, usually an ER diagram plus a data dictionary, shows what data is stored and how it is connected, and is the basis for database design. It is done at three levels of detail.

1. Conceptual data model

• A high-level, business-oriented view that shows the main entities and the relationships among them, with few or no attributes.
• It is independent of any DBMS or technology, and is made with users to confirm that the main concepts are correct.
• Example: STUDENT enrolls in COURSE; TEACHER teaches COURSE.

2. Logical data model

• A detailed model of the data, still independent of a specific DBMS.
• It adds all attributes with their data types, primary keys and foreign keys, cardinalities, resolves many-to-many relationships through associative entities, and is normalised.
• Example: STUDENT(<u>RollNo</u>, Name), COURSE(<u>Code</u>, Title), ENROLL(<u>RollNo, Code</u>, Grade).

3. Physical data model

• Describes how the data is actually implemented in a chosen DBMS: tables, columns, exact data types and sizes, indexes, constraints, partitions, storage and security.
• It is tuned for performance and for the platform, such as CREATE TABLE ENROLL (RollNo INT, Code VARCHAR(10), Grade CHAR(2), PRIMARY KEY (RollNo, Code)).

Normalization up to 3NF

Normalization is the process of organising relations to remove redundancy and the insertion, update and deletion anomalies it causes.

Unnormalized example: ORDER(OrderNo, OrderDate, CustID, CustName, CustCity, {ItemNo, ItemName, Price, Qty}).

• 1NF: all values are atomic and there are no repeating groups. Put the repeating items in separate rows: ORDER(OrderNo, OrderDate, CustID, CustName, CustCity, ItemNo, ItemName, Price, Qty) with key (OrderNo, ItemNo).
• 2NF: 1NF and no partial dependency of a non-key attribute on part of the key. Here OrderDate, CustID, CustName, CustCity depend only on OrderNo, and ItemName, Price depend only on ItemNo. Split:
  • ORDER(<u>OrderNo</u>, OrderDate, CustID, CustName, CustCity)
  • ITEM(<u>ItemNo</u>, ItemName, Price)
  • ORDER_ITEM(<u>OrderNo, ItemNo</u>, Qty)
• 3NF: 2NF and no transitive dependency (non-key attribute determined by another non-key attribute). In ORDER, OrderNo → CustID and CustID → CustName, CustCity. Split:
  • ORDER(<u>OrderNo</u>, OrderDate, CustID)
  • CUSTOMER(<u>CustID</u>, CustName, CustCity)

The final 3NF relations are ORDER, CUSTOMER, ITEM and ORDER_ITEM; every non-key attribute depends on the key, the whole key and nothing but the key.