System Analysis and Design

Discounted payback period using NPV

Given: initial investment $= \text{Rs } 1{,}00{,}000$, annual cash inflow $= \text{Rs } 40{,}000$, discount rate $r = 10\%$.

The present value of the cash flow of year $t$ is

$PV_t = \frac{40{,}000}{(1.10)^t}$

The NPV is negative at the end of year 3 (Rs -525.92) and becomes positive during year 4, so the investment is recovered in year 4.

Fraction of year 4 needed:

$\frac{525.92}{27{,}320.54} = 0.0193$

$\text{Discounted payback period} = 3 + 0.0193 \approx 3.02 \text{ years}$

So the discounted payback period is about 3.02 years (a little over 3 years). The NPV at the end of year 4 is positive, so the project is acceptable.

Given: initial investment $I_0 =$ Rs 5,00,000; annual cash inflow $C =$ Rs 60,000; discount rate $r = 15\%$.

Method (NPV): the discounted payback period is the number of years $n$ for which the cumulative present value of inflows equals the investment:

$PV_n = C\cdot\frac{1-(1+r)^{-n}}{r} \ge 5{,}00{,}000$

Year-by-year discounting

Check with the limit. Even if the inflow continued forever, the present value is a perpetuity:

$PV_\infty = \frac{C}{r} = \frac{60{,}000}{0.15} = \text{Rs } 4{,}00{,}000$

Since Rs 4,00,000 < Rs 5,00,000, the cumulative present value never reaches the investment, whatever the value of $n$ (the equation would need $1-(1.15)^{-n} = 1.25$, which is impossible because $(1.15)^{-n}>0$).

Conclusion: the NPV stays negative for every year (it tends to $-$Rs 1,00,000), so the discounted payback period does not exist: the investment is never recovered at 15%. The project should be rejected unless the inflow is increased or the investment reduced. (For comparison, the simple, undiscounted payback is $500000/60000 \approx 8.33$ years, which is misleading because it ignores the time value of money.)

Waterfall model

The waterfall model is the classical, linear sequential model of the system development life cycle. The project moves through the phases one after another, and each phase must be completed and reviewed before the next begins, like water falling down steps:

1. Planning / requirements analysis
2. System design
3. Implementation (coding)
4. Testing
5. Deployment and maintenance

Feedback to the previous phase is limited, and the output (document) of one phase is the input of the next. It suits projects whose requirements are well understood and stable.

Prototyping model

In prototyping, a working but limited model of the system (the prototype) is built quickly so that users can see and try it, instead of fixing all requirements in advance. The steps are:

1. Identify basic requirements. Only the main input/output needs are collected.
2. Develop an initial prototype. A quick version is built, usually with the user interface and main functions.
3. Review by users. Users use the prototype and give feedback.
4. Revise and enhance. The prototype is changed according to the feedback; steps 3 and 4 repeat until users are satisfied.
5. Final system. The accepted prototype is either refined into the final system (evolutionary) or thrown away and the real system is built (throwaway prototype).

Requirements -> Quick design -> Build prototype -> User evaluation -> Refine (loop) -> Final system

Merits

• Misunderstandings between users and developers are found early.
• Users are actively involved, which increases satisfaction and acceptance.
• Requirements are clearer, especially when they are unclear at the start.
• Errors and missing functions are detected early, which reduces the cost of changes.
• Users get a working model quickly.

Demerits

• Users may think the prototype is the final product and expect fast delivery.
• Repeated changes can increase cost and time and cause scope creep.
• Poor documentation, because of quick changes.
• A quickly built prototype may have a weak design and poor performance, which is hard to maintain if it is reused.
• Developers may spend too much effort on the prototype and neglect overall analysis.

Feasibility

Feasibility is the measure of how suitable the development of a proposed system is for the organisation. A feasibility study, done at the start of a project, checks whether the system can be developed with the available resources and whether it will be worthwhile. It helps management decide to go ahead, change or stop the project.

Categories of feasibility

1. Technical feasibility. Can the system be built with the available or obtainable technology (hardware, software, network) and technical skill? It considers the maturity of the technology, compatibility with the existing systems, capacity and the experience of the team.
2. Economic feasibility. Do the benefits justify the costs? It is a cost-benefit analysis (see below).
3. Operational feasibility. Will the system work in the organisation, and will users and management accept and use it? It considers user resistance, fit with the business process and training needs.
4. Schedule feasibility. Can the system be completed within the time required? It checks the deadlines and realistic estimates.
5. Legal (and contractual) feasibility. Does the system comply with laws, regulations, copyright, licences and contracts?
6. Political / organisational feasibility (sometimes added). Will managers and stakeholders support it?

Measuring economic feasibility

Costs and benefits are identified and compared.

• Costs: development costs (staff, hardware, software, training, one-time) and operating costs (maintenance, supplies, staff, recurring).
• Benefits: tangible (reduced labour, lower errors, more sales, faster processing, which can be measured in money) and intangible (better service, morale, decision-making, which are hard to quantify).

The techniques use the time value of money. With discount rate $i$, the present value of an amount $F$ received after $n$ years is $PV = F/(1+i)^n$.

• Net present value: $NPV=\sum_{t=0}^{n}\dfrac{B_t-C_t}{(1+i)^t}$. Accept the project if $NPV>0$.
• Return on investment: $ROI=\dfrac{\text{total benefits}-\text{total costs}}{\text{total costs}}$.
• Break-even (payback) analysis: the year in which cumulative benefits equal cumulative costs. A shorter payback period is better.

Example: if a system costs Rs 5,00,000 and gives Rs 2,00,000 benefit a year, the simple payback is $5{,}00{,}000/2{,}00{,}000 = 2.5$ years. At 10% discount, PV of 5 years of benefits is $2{,}00{,}000\times 3.7908 =$ Rs 7,58,160, so $NPV = 7{,}58{,}160-5{,}00{,}000=$ Rs 2,58,160, which is positive, so the project is economically feasible.

Retail clothing store: selling system

Assumed entities: Customer, Manager, Supplier (who supplies stock) and Bank/payment processor. The store sells garments, takes payment and keeps stock records.

Context diagram

The whole system is one process, with its external entities and the data flows.

 Customer ----- product request / order ------->+---------------------+
          <---- bill / receipt, goods -----------|                     |
                                                 |                     |
 Bank / Payment <--- payment request ------------|         0          |
 processor      ---- payment confirmation ------>|   Clothing Store    |
                                                 |   Selling System    |
 Supplier <----- purchase order -----------------|                     |
          ------ goods / supplier invoice ------>|                     |
                                                 |                     |
 Manager  <----- sales / stock reports ----------|                     |
          ------ price & product updates ------->+---------------------+

Level-0 diagram

The system is decomposed into main processes, with data stores D1 Product/Stock, D2 Customer, D3 Sales and D4 Supplier/Purchase.

Customer --order--> (1.0 Process Sale / Billing) --bill/receipt--> Customer
   D1 Product/Stock --price, availability--> (1.0)
   (1.0) --sale record--> D3 Sales
   (1.0) --stock update--> D1 Product/Stock
   (1.0) --customer details--> D2 Customer

(1.0) --payment request--> Bank / Payment processor
Bank / Payment processor --confirmation--> (1.0)

D1 Product/Stock --low-stock items--> (2.0 Manage Inventory & Purchase) --purchase order--> Supplier
Supplier --goods / invoice--> (2.0) --stock update--> D1 ; (2.0) --purchase record--> D4 Supplier/Purchase

Manager --price / product updates--> (3.0 Maintain Product Data) --> D1 Product/Stock

D3 Sales, D1 Product/Stock, D4 Purchase --> (4.0 Generate Reports) --sales & stock reports--> Manager

Processes in the level-0 diagram:

1. Process sale and billing: checks the product and price, calculates the total and discount, takes payment, issues the receipt and records the sale.
2. Manage inventory and purchase: updates stock on sale and receipt of goods, issues purchase orders to suppliers when stock is low.
3. Maintain product data: the manager adds or changes products and prices.
4. Generate reports: daily/monthly sales, stock and purchase reports for the manager.

Balancing: the data flows in the level-0 diagram to and from the external entities match those of the context diagram (order, receipt, payment, purchase order, goods/invoice, reports, updates).

Modern approach to systems analysis and design

Traditional (structured) analysis separated data and processes, while the modern approaches to developing information systems are:

1. Object-oriented analysis and design. The system is seen as a set of interacting objects that combine data and behaviour (classes, inheritance, encapsulation, polymorphism). It is modelled with UML (use case, class, sequence diagrams) and supports reuse and easier maintenance. It follows the iterative and incremental Unified Process.
2. Rapid application development (RAD) and prototyping. Systems are built quickly with user participation, prototypes, CASE and code-generation tools, and time-boxed iterations.
3. Agile methods. Short iterations (sprints), working software delivered often, close collaboration with the customer, and acceptance of changing requirements (Scrum, XP).
4. CASE tools and component-based development. Computer-aided software engineering tools automate diagrams, documentation and code generation, and ready-made components are reused.
5. Joint application development (JAD) and participatory design. Users, analysts and managers work together in facilitated sessions.

Compared with the traditional approach, the modern approach is iterative rather than strictly sequential, stresses user involvement, quick delivery, reuse, visual modelling and flexibility to change.

Rapid application development (RAD)

RAD is a system development methodology that emphasises very fast development and delivery of a high-quality system through prototyping, iterative development, active user involvement and the use of tools, instead of long planning. A working system is usually delivered in 60 to 90 days.

Phases

1. Requirements planning. Users and analysts agree on the project scope, goals and main requirements, often in JAD workshops.
2. User design. Users work with analysts and use CASE tools to build prototypes of screens, reports and models. The prototypes are refined repeatedly in feedback loops.
3. Construction. The prototypes are turned into the working system with code generators and reusable components, with testing done as the work proceeds.
4. Cutover (implementation). Final testing, data conversion, user training and changeover to the new system.

Features

• Prototyping with continuous user feedback.
• Time-boxing, with fixed short schedules.
• Use of CASE tools, fourth-generation languages and reusable components.
• Small, skilled teams.

Merits: fast delivery, lower cost, reduced risk, high user satisfaction. Demerits: needs highly skilled developers and committed users; not suited to large, complex or safety-critical systems; quality and scalability can suffer, and documentation may be weak.

Project initiation

Project initiation is the first phase in project management and in the planning phase of the SDLC. It begins when a need or opportunity for an information system is identified and a project is formally started. Its purpose is to understand the scope, risks and value of the proposed project, and to decide whether it should proceed to detailed planning.

Activities during project initiation

1. Establish the project initiation team. A team of the sponsor, analysts and users is formed to start the project.
2. Establish a relationship with the customer. Contacts, roles and communication with the customer are set up to build trust and cooperation.
3. Establish the project initiation plan. The tasks, time and resources for the initiation work are defined.
4. Establish management procedures. Rules for team communication, reporting, change control and standards are fixed.
5. Establish the project management environment and project workbook. The tools, files and project repository (workbook) are set up to keep all documents and records.
6. Develop the project charter. A short document stating the project's title, objectives, scope, benefits, sponsor, assumptions, constraints and the main stakeholders. The sponsor approves it to begin the project.

Together with the identification of the problem, a preliminary feasibility check and a rough cost estimate are made, so that management can decide whether to approve the project.

Identifying and selecting information system development projects

Organisations have more requests for systems than resources, so projects must be identified and selected carefully. The process has two steps.

1. Identifying potential development projects

Projects originate from:

• Management and business units (top-down): strategic plans, competition and new opportunities.
• Steering committee / IS department: requests assessed for the organisation's goals.
• Users and staff (bottom-up): problems with the current systems or new needs.
• Information systems planning: a formal analysis of the organisation's present and future needs.

2. Classifying and ranking (selecting) projects

The proposals are evaluated against criteria:

• Value chain analysis, which shows how the system adds value to the activities.
• Strategic alignment with the organisation's goals.
• Potential benefit (tangible and intangible), resources required, project size and duration, technical difficulty and risk.
• Economic, technical and operational feasibility.

Projects are ranked and the committee selects those that best fit the goals, the budget and available staff. The selected projects go on to the project initiation and planning (feasibility, scheduling) stage; the rest are deferred or rejected.

Group interview

A group interview is a fact-finding technique in which the analyst interviews several people (users, managers or stakeholders) together at the same time about the system requirements, instead of one at a time. It is used when the persons have related roles and the topic needs discussion and agreement.

Benefits

• Saves time and effort, as many people are covered in one session.
• Participants hear each other's views, which can bring up new ideas and help reach agreement.
• Differences in opinion can be seen and resolved immediately.
• Gives the analyst a wider view of how the different parts of the organisation work.
• Participants can correct and complete each other's statements, so information is more reliable.

Drawbacks

• It is difficult to schedule a time when all people are available.
• Some members may dominate while shy or junior members stay quiet, particularly in front of their managers, so some views are missed.
• Confidential or sensitive matters cannot be discussed freely.
• Discussions may go off the topic or conflict, and the session needs a skilled moderator.
• It is harder to record the details, and the group may not give personal in-depth information.

Formatting forms and reports

Forms are used to enter data (input) and reports present information (output). Formatting means arranging the content, layout, fonts, colour, headings and spacing so the document is clear, usable and accurate. The designer decides the purpose, users, medium (paper or screen) and information to be shown, and then builds and tests a prototype layout with users.

General guidelines

1. Meaningful titles. Give clear, specific titles with the system or report name, date and page number, plus version and the author if needed.
2. Meaningful information. Show only the necessary and relevant information; avoid clutter and give no extra data. Data is arranged in a logical order (grouped, sequenced as the user needs).
3. Balanced screen/page layout. Use margins, white space and alignment evenly. Keep related items together and arrange them in the natural reading order (top to bottom, left to right).
4. Easy navigation and clear instructions. Give clear labels, prompts and help; mark mandatory fields. In forms, fields follow the order of the source document and tab order is logical.
5. Consistent design. Use the same terms, abbreviations, positions and style across all forms and reports.
6. Appropriate typography and colour. Use readable fonts and sizes, limited colours with good contrast, and highlighting (bold, boxes) only for important items. Use upper and lower case for text.
7. Data format. Use standard formats for dates, currency and units, align numbers right, and align text left.
8. Control and totals. Reports include headings, column labels, totals, subtotals and page numbers, with exception highlighting.
9. Accuracy, validation and usability testing. Include validation of input, and test with the users and the actual printer/screen.

Maintenance

Maintenance is the final phase of the SDLC, in which the system in operation is kept working, corrected and improved after delivery. It is usually the most costly part of a system's life.

Major activities of maintenance

• Obtaining maintenance requests (change requests, error reports).
• Transforming the requests into changes (analysis and design of the change).
• Designing the changes and coding/modifying the software.
• Testing the changes (including regression tests).
• Updating the documentation and manuals.
• Releasing the new version and training users.

Types of maintenance

1. Corrective maintenance. Fixes the faults (bugs) found in operation, such as logic errors or crashes. It is the repair of defects.
2. Adaptive maintenance. Modifies the system to suit changes in its environment, such as a new operating system, hardware, law or tax rule.
3. Perfective maintenance. Adds new features or improves the performance and usability of the system at the request of users, such as faster reports or a new function. It forms the largest share of maintenance work.
4. Preventive maintenance. Changes made to prevent future problems and improve maintainability, such as restructuring code, updating documentation and removing weaknesses.

Object-oriented development

Object-oriented (OO) development builds a system as a collection of interacting objects. An object combines data (attributes) and the operations (methods) on that data. Objects of the same kind are described by classes. The main concepts are encapsulation, abstraction, inheritance and polymorphism. Analysis and design use UML diagrams (use case, class, sequence, state), and the development is normally iterative and incremental.

Difference from structured development

1. Spiral model

The spiral model, proposed by Barry Boehm, is a risk-driven, iterative SDLC model combining prototyping with the control of the waterfall model. The project passes repeatedly through four quadrants in each loop (spiral):

1. Determine objectives, alternatives and constraints.
2. Identify and resolve risks (risk analysis and prototyping).
3. Develop and test the product of that iteration.
4. Plan the next iteration after customer evaluation.

The radius of the spiral stands for the cost so far, and the angle for the progress. Each loop gives a more complete version (concept, requirements, design, implementation).

Advantages: risk is handled early, good for large and complex projects, changes are allowed, and users give feedback often. Disadvantages: needs risk analysis expertise, costly, and complex to manage; not suitable for small projects.

2. Decision table

A decision table is a tabular method of describing the logic of a process that has several conditions and the actions that follow from them. It has four parts: condition stubs (the conditions), condition entries (rules, with Y/N values), action stubs and action entries (X marks the action to take).

Example (discount policy):

For $n$ conditions there are $2^n$ rules (here $2^2=4$). Decision tables are compact and complete, reveal missing or contradictory rules, and are easy to check. They become unwieldy when there are many conditions.

System development life cycle (SDLC)

The SDLC is a structured, phased process used to plan, create, test, deploy and maintain an information system. Each phase has defined activities and outputs (deliverables), which guide the project from the initial idea to the retirement of the system. It gives control over cost, time and quality. The usual phases are planning, analysis, design, implementation and maintenance.

Planning -> Analysis -> Design -> Implementation -> Maintenance
     ^__________________ feedback / next cycle __________________|

1. Planning (project identification and selection, initiation)

• Identify the problem or opportunity and the need for the system.
• Define the scope and objectives, and study feasibility (technical, economic, operational, schedule, legal).
• Estimate the resources, cost and time, and prepare the project plan and schedule, and the team.
• Output: the feasibility report, the project plan and the baseline project plan, and the management's decision to proceed.

2. Analysis

• Study the current system and determine what the new system must do.
• Collect requirements by interviews, questionnaires, observation, document review and JAD.
• Model the requirements: data flow diagrams, ER diagrams, use cases, data dictionary, process descriptions.
• Compare the alternatives and propose the best one.
• Output: the requirements specification (SRS) and the logical model of the system, approved by the users.

3. Design

• Logical design: describes what the system does independent of the technology.
• Physical design: specifies how it will be implemented.
  • Database design (tables, normalisation, keys).
  • Input and output design: forms, reports, screens.
  • Process/program design: algorithms, modules, structure charts.
  • Architecture, hardware, software and network, security and controls.
• Output: design specification documents and prototypes, ready for the programmers.

4. Implementation (coding, testing, installation)

• Coding: the design is converted into programs in a chosen language.
• Testing: unit, integration, system and acceptance tests verify that the system meets the requirements and find errors.
• Installation (conversion): changeover to the new system by direct, parallel, phased or pilot methods; data conversion.
• Training of the users and preparation of user and technical documentation.
• Output: the working system, test results and documentation.

5. Maintenance (and support)

• Operating the system and keeping it useful after delivery.
• Corrective (fixing errors), adaptive (changes in environment), perfective (new features, better performance) and preventive maintenance.
• Provide help-desk support, monitor performance, and finally decide to replace or retire the system, which starts a new cycle.

Remarks

The phases may be run sequentially (waterfall) or repeated in iterations (spiral, RAD, agile). Documentation and review at the end of each phase reduce errors and the cost of correcting them later.

The discount rate in the question is read as 12 percent (the "1!" is a misprint). Time 0 is the start, when the one-time development cost is paid; benefits and recurring costs fall at the end of years 1 to 5. Amounts are in Rs.

Discount factors at 12 percent: $1/(1.12)^t$

(Sum of the five factors = 3.6048.)

(a) Net present value

Benefits: 70,000 in year 1, rising by 10,000 each year (70,000; 80,000; 90,000; 100,000; 110,000).

Total PV of costs $=90{,}000+144{,}191=234{,}191$.

$NPV=316{,}305-234{,}191\approx \text{Rs } 82{,}114$

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

(b) Overall return on investment

$ROI=\frac{PV\text{ benefits}-PV\text{ costs}}{PV\text{ costs}}=\frac{316{,}305-234{,}191}{234{,}191}=\frac{82{,}114}{234{,}191}\approx 0.351=35.1\%$

(c) Breakeven analysis

Net cash flow each year (benefit minus recurring cost) is 30,000; 40,000; 50,000; 60,000; 70,000. Discount it and accumulate, starting from $-90{,}000$.

The cumulative figure turns positive during year 3. At the start of year 3 the shortfall is 31,326, and year 3 earns 35,589, so

$\text{Breakeven}=2+\frac{31{,}326}{35{,}589}\approx 2.88\text{ years}$

Breakeven occurs about 2.9 years (roughly 2 years 11 months) after the project starts, when the cumulative present value of benefits first covers the present value of all costs. The final cumulative value in year 5 equals the NPV of Rs 82,114, a useful cross-check.

Conceptual data model

A conceptual data model is a detailed, technology-independent model of the data an organization needs: the entities (things about which data is kept), their attributes, and the relationships and business rules between them. It is drawn in the analysis phase, usually as an entity-relationship (E-R) diagram, and describes the business as users see it, without reference to any DBMS, tables or storage. It is later converted into a logical and then a physical database design.

Gathering information for conceptual data modeling

1. Top-down approach: begin from the business context. Study the organization's strategic plans, business rules and the data needed by planned information systems, then derive entities and relationships from them.
2. Bottom-up (from existing documents): examine forms, reports, screens, invoices, files and existing databases to find data items, then group them into entities.
3. Interviews with managers and users about what data they keep and how they use it.
4. Questionnaires, observation and document analysis of day-to-day operations.
5. Joint Application Design (JAD) sessions and use of existing data-flow diagrams and data dictionary entries, since each data store in a DFD suggests entities.
6. Ask questions about each candidate entity: What are its attributes? What identifies it uniquely? How many of one relate to another (minimum and maximum cardinality)? What business rules (for example "a customer may place many orders, an order belongs to one customer") apply?

E-R diagram for a retail store in a mall

Entities and attributes:

• CUSTOMER (<u>CustomerID</u>, Name, Phone, Address)
• ITEM (<u>ItemCode</u>, Name, Price, QtyInStock)
• CATEGORY (<u>CategoryID</u>, CategoryName)
• SUPPLIER (<u>SupplierID</u>, Name, Contact)
• SALE (<u>SaleNo</u>, SaleDate, TotalAmount, PaymentMode)
• SALE_ITEM (associative entity: Quantity, UnitPrice), resolving the many-to-many relation between SALE and ITEM
• EMPLOYEE (<u>EmpID</u>, Name, Role), the cashier or salesperson

CUSTOMER ||--o{ SALE : places
EMPLOYEE ||--o{ SALE : handles
SALE     ||--|{ SALE_ITEM : contains
ITEM     ||--o{ SALE_ITEM : "sold in"
CATEGORY ||--o{ ITEM : classifies
SUPPLIER ||--o{ ITEM : supplies

Reading the relationships:

• One customer places zero or many sales; each sale is made by exactly one customer (1:M).
• One employee handles many sales; each sale is handled by one employee (1:M).
• A sale contains one or more items and an item appears in many sales, so SALE and ITEM are M:N, resolved through SALE_ITEM with Quantity and UnitPrice.
• A category classifies many items; each item belongs to one category (1:M).
• A supplier supplies many items; each item has one main supplier (1:M).

In the diagram, rectangles are entities, ovals are attributes, diamonds are relationships, and the underlined attribute in each entity is its identifier (primary key).

System analysis and design

System analysis and design (SAD) is the process of studying an organization's business problem or opportunity, specifying what a new or improved information system must do (analysis), and then deciding how the system will be built and will work (design). It follows a structured life cycle (SDLC): planning, analysis, design, implementation, and maintenance.

• Analysis answers what: study the current system, find problems and requirements, and model processes and data (DFDs, ER diagrams, use cases).
• Design answers how: specify the architecture, database, forms and reports, interface, and program logic that meet those requirements.

Why it is important

1. Meets real user needs: requirements are discovered and agreed before building, so the system solves the right problem.
2. Reduces cost and risk: errors found during analysis cost far less to fix than errors found after coding or deployment.
3. Provides a blueprint for programmers, testers and managers, so the team works to a common specification and documentation.
4. Improves quality and reliability by using proven models, standards, and testing plans.
5. Supports planning and control: time, budget and staff can be estimated and tracked against defined phases and deliverables.
6. Eases maintenance and future change, because well-documented, modular designs are easier to modify and extend.
7. Aligns IT with business goals through feasibility study and cost-benefit analysis before investing.

Without systematic analysis and design, projects tend to overrun budget and schedule, miss requirements, and fail on adoption.

Why CASE tools are needed

CASE (Computer-Aided Software Engineering) tools are software packages that automate activities of the systems development life cycle. They are needed because:

1. Productivity: drawing diagrams, generating code and producing documents by hand is slow; tools automate repetitive work.
2. Quality and consistency: tools check diagrams for errors, balancing and naming consistency (for example, DFD levels agree with each other).
3. Better documentation: all models and specifications are kept in one place and stay up to date.
4. Easier change and maintenance: a change made in the repository is reflected wherever the item is used.
5. Communication and standards: team members share the same notation and models, and standards are enforced.
6. Faster development: code generation and prototyping shorten delivery, and reverse engineering helps with maintenance of old systems.

Components of a CASE tool

1. Diagramming tools: create and edit data-flow diagrams, ER diagrams, UML diagrams and structure charts.
2. Central repository (data dictionary): stores all definitions of data, processes, entities, diagrams and project information, and is the core of the tool.
3. Documentation generators: produce standard reports and specification documents from the repository.
4. Analysis tools: check models for completeness, consistency and errors.
5. Screen and report design (prototyping) tools: build forms, menus and reports quickly.
6. Code generators: produce program code or database schemas from the design models.
7. Project management tools: schedule tasks, track resources and progress.
8. Reverse-engineering and testing tools: derive designs from existing code and support testing.

CASE tools are often grouped as upper CASE (planning, analysis, design), lower CASE (coding, testing, maintenance) and integrated CASE covering the whole life cycle.

Project management

Project management is the process of planning, organizing, staffing, directing and controlling a project's activities and resources so that the project is completed on time, within budget, and to the required scope and quality. A project is a temporary effort with a definite start and end that produces a unique result.

Activities of a project manager

1. Defining the scope and objectives of the project and what will be delivered.
2. Planning: breaking the work into tasks (work breakdown structure), sequencing them, and estimating time, effort and cost, usually shown on Gantt or PERT charts.
3. Staffing and organizing: selecting the project team and assigning roles and responsibilities.
4. Directing and leading the team, assigning work and resolving conflicts.
5. Monitoring and controlling: tracking progress against the baseline plan, managing changes, and taking corrective action on schedule and cost variance.
6. Risk management: identifying, assessing and reducing risks.
7. Communication with stakeholders: reporting status to management, clients and users.
8. Closing the project: delivering, obtaining sign-off, and recording lessons learned.

Skills of a project manager

• Leadership: motivating the team and setting direction.
• Communication: clear speaking, writing and listening with users, management and developers.
• Interpersonal and team-building skills: managing conflict and building cooperation.
• Technical knowledge of the development methods and technologies used.
• Organizational and planning skills, including time management.
• Negotiation and political skills for obtaining resources and agreement.
• Problem-solving and decision-making, and the ability to manage risk and change.

Initiating and planning an information system development project

Project initiation and planning is the first phase of the SDLC. Its aim is to decide whether a proposed system is worth pursuing and to prepare a plan for doing it. The main steps are:

1. Establish the project initiation team: a small team (the project manager, analyst, and user representatives) is formed to start the project and assess its value.
2. Establish a relationship with the customer: users and managers are involved from the beginning; roles and communication methods are agreed.
3. Establish the project initiation plan: a short plan defines the tasks, time and resources needed for initiation itself.
4. Establish management procedures: team roles, reporting, change control, and communication standards are set.
5. Establish the project management environment and project workbook: the project workbook (an electronic or paper file) holds all project documents, and CASE and other tools are chosen.
6. Develop the project charter: a short document stating the project's title, objectives, scope, benefits, customer, duration and assumptions.
7. Identify and assess risks, and determine feasibility: economic (cost-benefit), technical, operational, schedule and legal feasibility are studied.
8. Prepare the baseline project plan (BPP) and statement of work (SOW): the BPP records the detailed scope, schedule, budget and resources; the SOW states the work to be done and is reviewed with the customer.
9. Review and approval: management reviews the BPP, and a go or no-go decision is made before the analysis phase starts.

Thus initiation answers "should we do it?" and planning answers "how, when and at what cost?".

Prototyping for determining requirements

Prototyping is a repetitive process in which analysts build a working, partial model of the system quickly, let users try it, and refine it. It is especially useful when users cannot state requirements clearly, when requirements are unstable, or when the interface is important.

Using it for requirements:

1. Identify the basic requirements gathered so far (inputs, outputs, main functions).
2. Develop an initial prototype (screens, reports, simple navigation), often with a rapid development tool.
3. Users review and use the prototype and give feedback.
4. Analysts revise the prototype to add or correct requirements.
5. Repeat steps 3 and 4 until users accept; the accepted prototype's behaviour becomes the documented requirements.

Benefits: users see the system early, misunderstandings are found sooner, and user involvement and satisfaction increase. Risks: poor documentation, a tendency to skip full analysis, and unrealistic user expectations about speed.

Throwaway versus evolutionary prototyping

Purpose of database design

Database design converts the conceptual data model (entities and relationships) into a structure that a DBMS can implement efficiently. Its purposes are to:

1. Organize data so it is stored once and consistently (minimal redundancy through normalization).
2. Ensure data integrity and accuracy through keys, constraints and relationships.
3. Support the processing needs of users: fast retrieval and updates.
4. Provide security, backup and recovery, and allow future growth.
5. Produce specifications that programmers and database administrators can implement.

Logical design versus physical design

Logical database design turns the conceptual model into relations (tables) for a chosen type of DBMS (usually relational): transform the ER diagram into relations, choose primary and foreign keys, and normalize to third normal form. It is independent of the particular product and storage details.

Physical database design decides how the logical design will actually be stored in a particular DBMS to achieve good performance: field data types and sizes, indexes, file organization, denormalization, partitioning, and storage allocation.

Testing

Testing is the process of executing a program or system with test data to find errors and to check that it meets its requirements and works as intended. A good test case is one that has a high chance of finding an undiscovered error. Testing shows the presence of errors, not their absence.

Testing techniques

1. Black box testing (functional testing): the tester treats the program as a box whose inside is unknown, supplying inputs and checking outputs against the specification. Techniques include equivalence partitioning and boundary value analysis. It checks what the system does, not how, and does not need the code.

2. White box testing (structural or glass-box testing): tests are designed from knowledge of the internal code, so that every statement, branch, decision and loop path is executed at least once (statement, branch and path coverage). It is usually done by programmers.

3. Unit testing: each module or program is tested separately to find errors in its logic, often with stubs and drivers.

4. Integration testing: tested modules are combined step by step (top-down, bottom-up or big-bang) to find errors in the interfaces between them.

5. System testing: the complete integrated system is tested against the requirements, including performance, security, recovery and stress.

6. Acceptance testing: the users test the system with real data to decide if they accept it (alpha testing at the developer's site, beta testing at the user's site).

(Any four of these may be given; the first four listed are a typical answer.)

Class diagram

A class diagram is a UML structural diagram that shows the classes of a system, their attributes and operations, and the relationships among them. It is the main static model of object-oriented analysis and design and shows what objects exist and how they are associated, not how they behave over time.

Elements

A class is drawn as a rectangle in three compartments:

+---------------------+
| ClassName           |
+---------------------+
| - attribute : type  |
+---------------------+
| + operation()       |
+---------------------+

• Attributes describe the data held by the object; operations (methods) describe what it can do.
• Visibility: + public, - private, # protected.
• Relationships:
  • Association: a line between classes (for example Customer places Order), with multiplicity such as 1, 0..1, 1..*, and optional role names.
  • Aggregation: a "whole-part" relation where the part can exist independently (hollow diamond).
  • Composition: a stronger whole-part relation where the part cannot exist without the whole (filled diamond).
  • Generalization (inheritance): a subclass inherits from a superclass (hollow triangle arrow).
  • Dependency: a dashed arrow where one class uses another.

Example: order processing

+------------------+ 1       0..* +------------------+ 1..*     1 +------------------+
| Customer         |--------------| Order            |------------| Product          |
+------------------+   places     +------------------+  contains  +------------------+
| - custId         |              | - orderNo        |            | - prodCode       |
| - name           |              | - orderDate      |            | - name           |
| - address        |              | - total          |            | - price          |
+------------------+              +------------------+            +------------------+
| + placeOrder()   |              | + addItem()      |            | + getPrice()     |
| + updateProfile()|              | + calcTotal()    |            | + updateStock()  |
+------------------+              +------------------+            +------------------+
                                          ^
                                          | (generalization)
                                  +------------------+
                                  | OnlineOrder      |
                                  | - paymentMode    |
                                  +------------------+

Here a customer places zero or many orders, each order belongs to exactly one customer, and an order contains one or more products. OnlineOrder inherits the attributes and operations of Order and adds paymentMode.

(a) Agile development

Agile development is a group of iterative, incremental methods for building software in which requirements and solutions evolve through close collaboration between small, self-organizing, cross-functional teams and the customer. It was formalized by the Agile Manifesto (2001), which values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

Key features:

• Work is done in short iterations (sprints) of 1 to 4 weeks, each delivering a working increment.
• Continuous customer involvement and feedback; requirements may change at any time.
• Frequent communication (daily stand-up meetings), simple design, and continuous testing and integration.
• Examples of methods: Scrum, Extreme Programming (pair programming, test-driven development, refactoring), Kanban.

Advantages: early delivery of value, adaptability, and higher customer satisfaction. Limitations: weak documentation, difficult cost and schedule estimation for large fixed-price projects, and dependence on strong team discipline and user availability.

(b) Decision tree

A decision tree is a graphical tool for showing the logic of a decision: conditions and the actions that follow. It reads left to right. The root is the first condition, each branch is a possible value of that condition, and the leaves (right end) are the actions. It is easy for users to understand and is used in process specification and in decision analysis.

Example: discount policy.

                          Order > Rs 10,000?
                         /                  \
                      Yes                    No
                      /                        \
              Member customer?            No discount
               /          \
            Yes            No
             |              |
      15% discount     5% discount

Compared with a decision table, a tree shows the sequence of conditions clearly but becomes large when conditions are many; a table is more compact and better for checking completeness.

Black box versus white box testing

Stages of testing

1. Unit (module) testing: each program or module is tested alone to find logic and coding errors, using white box methods and stubs or drivers.
2. Integration testing: tested modules are combined step by step (top-down, bottom-up, or big-bang) to find errors in interfaces and data passed between them.
3. System testing: the whole integrated system is tested against the requirements, covering functionality, performance, security, volume, stress and recovery.
4. Acceptance testing: the customer or users test with real data and in the real environment to decide whether to accept the system. It includes alpha testing (at the developer's site, with developers observing) and beta testing (at users' sites).

Together these move from small parts to the full system; at every stage, errors found are corrected and the tests repeated (regression testing).

Why DFD is used

A data flow diagram (DFD) shows how data moves through a system: the external entities that supply or receive data, the processes that transform it, the data stores that hold it, and the data flows connecting them. It is used because:

1. It presents the system's processes graphically, which users and analysts both understand.
2. It shows the boundary of the system and its interfaces with the outside.
3. It breaks a complex system into levels (context diagram, level 0, level 1, ...), giving a top-down view.
4. It helps find missing, redundant or illogical processes and data during analysis.
5. It is the basis for the data dictionary, process specifications and later design.

Symbols (Yourdon/DeMarco): circle or rounded box = process, rectangle = external entity, open-ended rectangle = data store, arrow = data flow.

Context diagram: retail clothing store

                    order, payment                 sales receipt, bill
   +----------+ ----------------------> +-------------+ -----------------> +----------+
   | CUSTOMER |                         |  0          |                    | CUSTOMER |
   +----------+ <---------------------- |  CLOTHING   |                    +----------+
                receipt, product info   |  STORE      |
                                        |  SYSTEM     |
   +----------+   purchase order        |             |   stock report,
   | SUPPLIER | <---------------------- |             | ---------------> +------------+
   |          | ----------------------> |             |                  | MANAGER    |
   +----------+   goods, invoice        +-------------+ <--------------- +------------+
                                                         report request

Entities: Customer, Supplier, Manager. Single process: Clothing Store System.

Level 0 DFD

CUSTOMER --order--> (1.0 Process Sale) --bill/receipt--> CUSTOMER
                        |   ^
        sale details    |   | item price, availability
                        v   |
                 [D1 Sales]   [D2 Inventory] <---stock update---+
                                    ^                            |
                                    |                            |
SUPPLIER <--purchase order-- (2.0 Manage Stock) <--goods, invoice-- SUPPLIER
                                    |
                           low-stock alert
                                    v
                  (3.0 Generate Reports) <--report request-- MANAGER
                        ^        ^                     |
                 [D1 Sales]  [D2 Inventory]            +--sales/stock report--> MANAGER

Processes:

• 1.0 Process Sale: takes the customer's order, checks item price and availability in D2, records the sale in D1, prints the bill, and reduces stock.
• 2.0 Manage Stock: updates D2 on receipt of goods from the supplier, and issues purchase orders when stock is low.
• 3.0 Generate Reports: reads D1 and D2 and produces sales and stock reports for the manager.

Data stores: D1 Sales, D2 Inventory (and, if needed, D3 Customer). The data flows entering and leaving the three processes match the single context process, so the diagrams are balanced.

Structured development versus object-oriented development

Use case diagram

A use case diagram is a UML behavioural diagram showing the functions (use cases) a system offers and the actors that interact with them. Elements:

• Actor: a stick figure for a user or external system.
• Use case: an oval for one function that gives value to an actor.
• System boundary: a rectangle around the use cases.
• Relationships: association (actor to use case); include (a use case always uses another, dashed arrow); extend (optional extra behaviour); generalization.

Example: library system.

 +----------------------- Library System ---------------------+
 |                                                             |
 |  (Search Book) <------------------------+                   |
 |                                          |                  |
 |  (Borrow Book) --<<include>>--> (Check Membership)          |
 |                                                             |
 |  (Return Book) --<<extend>>--> (Pay Fine)                   |
 |                                                             |
 |  (Add Book)   (Register Member)                             |
 +-------------------------------------------------------------+
   Member -- Search, Borrow, Return        Librarian -- Borrow, Return, Add Book, Register Member

Member and Librarian are actors. Borrowing always includes checking membership; paying a fine extends returning a book only when the book is late.

Class diagram

A class diagram shows classes with their attributes and operations, and the relationships (association with multiplicity, aggregation, composition, generalization) between them. A class is a rectangle divided into name, attributes and operations (+ public, - private).

Example for the same system:

+----------------+ 1      0..*  +----------------+ 0..*   1 +----------------+
| Member         |--------------| Loan           |-----------| Book           |
+----------------+   makes      +----------------+  is of   +----------------+
| - memberId     |              | - loanDate     |          | - isbn         |
| - name         |              | - dueDate      |          | - title        |
+----------------+              +----------------+          | - author       |
| + borrow()     |              | + calcFine()   |          +----------------+
| + returnBook() |              +----------------+          | + isAvailable()|
+----------------+                                          +----------------+
        ^
        | generalization
+----------------+
| StudentMember  |
| - rollNo       |
+----------------+

A member makes zero or many loans; each loan is for one book; StudentMember inherits from Member. The use case diagram shows what the system does for users, whereas the class diagram shows the static structure that implements it.

Common skills of a project manager

1. Leadership: setting direction, motivating the team, and making decisions under pressure.
2. Communication: listening, speaking and writing clearly to users, management, and developers, and reporting status honestly.
3. Interpersonal skills: building trust, handling conflict, and getting cooperation from people.
4. Management and organizational skills: planning, scheduling, estimating, delegating, and controlling cost and time.
5. Technical skills: enough knowledge of systems development methods and tools to judge feasibility, estimates and quality.
6. Negotiation and political skills: obtaining resources, agreeing scope and schedule, and managing stakeholders.
7. Problem-solving and risk management: foreseeing problems and acting early.
8. Change management and adaptability: handling changing requirements without losing control.

Most important skill

The most important is communication, supported by leadership. Most project failures come from misunderstood requirements, unreported problems, and conflict between team and users, not from technical difficulty. A manager who communicates well keeps stakeholders informed, discovers risks early, resolves conflicts, and keeps the team aligned, and every other skill (planning, negotiation, leading) depends on it.

Project identification and selection

This is the first activity of the planning phase of the SDLC: finding possible systems projects and choosing those that best serve the organization.

1. Identifying potential projects

Ideas arise from:

• Top-down: strategic business plans and information systems plans set by senior management.
• Bottom-up: requests from departments and users for solving problems or taking opportunities.
• Other sources: customer, supplier and competitor pressure, government regulation, technology change, and IT staff proposals.

Each candidate project is recorded with its purpose, scope, and expected benefits (often in a system service request).

2. Classifying and ranking projects

Candidates are evaluated against criteria such as:

• Value chain and strategic alignment with goals
• Potential benefits (tangible and intangible) and cost
• Resource availability (people, money, time)
• Size, duration, technical difficulty and risk
• Urgency and the need to meet legal or competitive pressures

Methods include cost-benefit and feasibility analysis (economic, technical, operational, schedule, legal) and weighted scoring.

3. Selecting projects

A steering committee or management reviews the ranked list and chooses the projects to go ahead, considering the above criteria and the portfolio of other work. Selected projects pass into project initiation and planning; others are deferred or rejected, and their reasons are recorded.

Steps in project initiation and planning

Project initiation and planning decides whether a system is worth building and prepares a plan for it.

1. Establish the project initiation team: a small group (project manager, analysts, user representatives) assesses the project.
2. Establish a relationship with the customer: users and managers are involved from the start, and roles and communication are agreed.
3. Establish the project initiation plan: defines tasks, time and costs needed for initiation work itself.
4. Establish management procedures: team roles, reporting, change control, and communication rules.
5. Establish the project management environment and project workbook: tools are selected, and a project workbook is created to hold all documents.
6. Develop the project charter: a short document stating title, customer, objectives, scope, expected benefits, duration, and assumptions.
7. Identify risks and assess feasibility: economic (cost-benefit), technical, operational, schedule and legal feasibility are studied.
8. Develop the baseline project plan and statement of work: the baseline plan holds the detailed scope, schedule, budget and resources; the statement of work summarizes the work for the customer.
9. Review and approve: management reviews the plan and decides whether to continue to analysis.

Joint Application Design (JAD)

JAD is a structured process in which users, managers, analysts and other stakeholders meet together in a series of facilitated, focused workshops to define requirements and design the system. The sessions are led by a trained facilitator, last from a few days to a few weeks, and are held in a dedicated room with whiteboards, projectors and CASE tools.

Participants:

• Facilitator, who runs the session neutrally.
• Users and managers, who state requirements and approve decisions.
• Sponsor, who supports the project.
• Systems analysts and IT staff, who listen and ask questions.
• Scribe, who records decisions.

Typical steps: plan the session, hold the meetings (agenda, discussion, diagrams, prototypes), record decisions, and produce a document that all agree.

Why it is better than traditional methods

Traditional methods (individual interviews, questionnaires, observation) gather requirements separately, so conflicts and contradictions surface late and need repeated meetings.

• Faster: many views are collected at once, shortening the time to requirements.
• Conflicts resolved early: users and managers discuss and agree in the room.
• Better user involvement and ownership, so the system is more likely to be accepted.
• Fewer misunderstandings and omissions, because analysts and users talk directly.
• Higher quality of requirements, which reduces costly rework later.
• Simultaneous documentation and prototyping during the workshop.

Limitations: it requires heavy commitment of senior people's time, a skilled facilitator, and careful organization, and large groups may be dominated by a few members.

Conceptual data modeling

Conceptual data modeling is the analysis-phase activity of producing a technology-independent, detailed model of the organization's data: the entities, their attributes, and the relationships and business rules between them. The model is normally drawn as an entity-relationship (E-R) diagram. It shows what data is needed by the business, not how it will be stored. It is later converted into a logical and physical database design.

Process of conceptual data modeling

1. Gather information and understand the business: use interviews, JAD sessions, documents, forms, reports, existing DFDs and data dictionary, and business rules.
2. Identify entities: find the people, places, objects, events and concepts about which data must be stored (for example Customer, Order, Product).
3. Identify attributes of each entity, and choose an identifier (unique key) for it.
4. Identify relationships between entities, and state each in business terms (for example "a customer places orders").
5. Determine cardinality: the minimum and maximum number of occurrences on each side (one-to-one, one-to-many, many-to-many), and resolve many-to-many relationships with associative entities.
6. Draw the E-R diagram using a standard notation.
7. Add business rules and constraints: for example, allowed values and mandatory participation.
8. Review and refine: check the model against user requirements and normalization, with users and other analysts, and revise until it is accepted.
9. Document in the data dictionary/repository for use in logical design.

Form versus report

Process of designing forms and reports

1. Understand the users and purpose: who will use it, for what task, how often, and in what environment (screen, paper, mobile).
2. Gather requirements: who needs what data, from which sources, and the volume.
3. Prototype the layout: sketch or build a mock-up, using a CASE tool or form designer, and arrange fields in a logical order (top to bottom, left to right), grouped by meaning.
4. Apply design guidelines: meaningful titles, consistent terms and layout, clear labels, adequate white space, suitable fonts and colour, default values, prompts and help; for reports, add headers, footers, totals, page numbers and date.
5. Include validation and controls for forms: required fields, data type and range checks, and error messages.
6. Test usability: users try the prototype and give feedback.
7. Revise and finalize: make changes until users accept, then document the specification for programmers.

System maintenance

System maintenance is the modification of an information system after it has been delivered and put into operation, to correct errors, adapt it to change, and improve it. It usually consumes most of the total cost of a system's life.

Types:

• Corrective: fixing bugs found in use.
• Adaptive: changing the system for new environments, such as new hardware, software, or regulations.
• Perfective: improving performance or adding user-requested features.
• Preventive: restructuring to avoid future problems and improve maintainability.

Process of maintaining information systems

Maintenance follows a miniature SDLC:

1. Obtain a maintenance request: users submit a request or error report, which is logged and reviewed.
2. Analyze and decide: the request is studied for validity, effect, effort and cost, then approved, scheduled, or rejected by a change control board.
3. Design the change: the existing documents and code are reviewed, and the modification and its effect on other parts of the system are designed.
4. Implement the change: the code, database and documents are modified.
5. Test: the changed part and the rest of the system are tested (regression testing).
6. Release: the new version is installed, and users are trained and informed.
7. Update documentation and the configuration records so that versions can be traced.

Control of the process through version control and configuration management is needed so that changes do not damage the system.

(a) CASE tools

CASE (Computer-Aided Software Engineering) tools are software packages that automate and support activities of the systems development life cycle, from planning and analysis to design, coding, testing and maintenance.

Benefits: higher productivity, consistent and error-free diagrams, automatic documentation, easier maintenance, and better communication within the team.

Main components:

• Diagramming tools for DFDs, ER diagrams and UML models.
• A central repository (data dictionary) that stores all definitions and models.
• Documentation generators and report tools.
• Analysis tools to check consistency and completeness.
• Screen and report prototyping tools.
• Code generators.
• Project management tools.

They are grouped as upper CASE (early phases), lower CASE (implementation and maintenance) and integrated CASE (the full life cycle). Examples are Visible Analyst, Rational Rose, Enterprise Architect and StarUML.

(b) Baseline project plan

The baseline project plan (BPP) is the major deliverable of the project initiation and planning phase. It is a document that contains management's and the team's best estimate of the project's scope, benefits, schedule, costs, and resources, and it is the standard against which progress is measured during the project.

Contents:

• Introduction: project overview, recommendation and the scope.
• System description: alternative solutions and the one selected.
• Feasibility assessment: economic (cost-benefit), technical, operational, schedule, legal and political.
• Management issues: team composition, communication plan, project standards, and procedures.
• Schedule, cost and resource estimates.

The BPP is reviewed by management and users, and approval decides if the project proceeds to analysis. It is revised as new information is learned, but the baseline is retained for comparison.

Activities at the heart of the systems development process

The development of any system, whatever the method, is built around a small set of core activities that make up the SDLC:

1. Planning (project identification and initiation): decide whether the system should be built, assess feasibility, and plan the project.
2. Analysis: study the current system, gather requirements from users, and model processes and data.
3. Design: specify the architecture, database, forms and reports, interfaces, and program logic that satisfy the requirements.
4. Implementation: code, test, install, convert data, and train users.
5. Maintenance: support the system in operation, repair errors, and enhance it.

Methods differ in how they arrange these activities (waterfall, iterative, agile), but all of them analyze, design, build and support.

Problems with the traditional waterfall SDLC

In the waterfall model each phase must be finished and approved before the next starts, with little return to earlier phases. Problems:

1. Rigid and inflexible: changing requirements cannot be handled easily once a phase has closed.
2. Requirements must be fully known at the start, but users often cannot state them clearly until they see something working.
3. Late delivery of working software: users see the system only at the end, so mismatches are found very late and are costly to fix.
4. Late discovery of errors: testing takes place near the end, so design faults are expensive to correct.
5. Long development time: the system may be obsolete or the business changed by the time it is delivered.
6. Heavy documentation and sign-offs slow progress, with a risk of "analysis paralysis".
7. Little user involvement after requirements are signed off, which risks poor user acceptance.
8. High risk on large projects, as problems are not exposed until late.

Agile development in brief

Agile development is an iterative and incremental approach where software is built in short cycles (sprints of 1 to 4 weeks) that each deliver working functionality. The Agile Manifesto prefers individuals and interactions to processes and tools, working software to comprehensive documentation, customer collaboration to contract negotiation, and responding to change to following a plan.

Characteristics: small self-organizing cross-functional teams, continuous customer involvement, simple design, frequent testing and integration, daily stand-up meetings, and welcome for changing requirements. Methods include Scrum, Extreme Programming (pair programming, test-driven development, refactoring) and Kanban.

Strengths: early and frequent delivery, flexibility to change, and higher satisfaction. Weaknesses: less documentation, difficulty in estimating large projects, and a need for committed users and a disciplined team.

Balancing DFDs

Balancing means that the data flowing into and out of a process on a higher-level DFD must be the same as the data flowing into and out of the lower-level DFD that explains (decomposes) that process. Every input and output of the parent process must appear in the child diagram, and the child must not add or drop external flows. For example, if the context diagram has a flow "movie request" entering the system, level 0 must show "movie request" entering, and it must be consumed by the processes in the child diagram. The data stores and external entities connected to a parent process must also be consistent with its child. Balancing ensures the diagrams at different levels describe the same system.

(Child diagrams may add internal flows and data stores, but not new flows crossing the parent's boundary.)

Context diagram: online movie rental system

 +----------+  registration, login, search request,    +------------------+
 |          |  rental request, payment details          |                  |  movie file/stream,
 | CUSTOMER | ----------------------------------------> |   0              |  confirmation, receipt
 |          | <---------------------------------------- |   ONLINE MOVIE   | ----------------->  CUSTOMER
 +----------+  movie list, stream, receipt, notices     |   RENTAL SYSTEM  |
                                                         |                  |
 +----------+  movie files, details, license terms      |                  |  payment request
 | MOVIE    | ----------------------------------------> |                  | ------------------> +---------+
 | PROVIDER | <---------------------------------------- |                  | <------------------ | PAYMENT |
 +----------+  royalty report                           |                  |  payment status     | GATEWAY |
                                                         |                  |                     +---------+
 +----------+  movie management, report request         |                  |
 | ADMIN    | ----------------------------------------> |                  |
 |          | <---------------------------------------- +------------------+
 +----------+  rental and revenue reports

Level 0 DFD

Processes:

• 1.0 Manage Accounts: registers customers, validates login. Reads and writes D1 Customers. Receives registration and login details from Customer; returns login confirmation.
• 2.0 Browse and Search Movies: takes the search request, reads D2 Movies, returns the movie list and details to Customer.
• 3.0 Process Rental and Payment: receives rental request, checks the customer in D1, sends the payment request to Payment Gateway, receives payment status, records the rental in D3 Rentals, and issues the receipt.
• 4.0 Stream Movie: checks the valid rental in D3, reads the movie file from D2, and delivers the stream to Customer for the rental period.
• 5.0 Manage Movie Catalogue: receives movie files and details from Movie Provider and Admin, updates D2, and returns royalty reports.
• 6.0 Generate Reports: reads D3 and D2 and gives rental and revenue reports to Admin on request.

CUSTOMER --registration/login--> (1.0 Manage Accounts) <--> [D1 Customers]
CUSTOMER --search request--> (2.0 Browse/Search Movies) <-- [D2 Movies]
CUSTOMER <--movie list-------   (2.0)
CUSTOMER --rental request--> (3.0 Rental & Payment) --payment request--> PAYMENT GATEWAY
                              (3.0) <--payment status-- PAYMENT GATEWAY
                              (3.0) --rental record--> [D3 Rentals];  (3.0) --receipt--> CUSTOMER
CUSTOMER <--movie stream-- (4.0 Stream Movie) <-- [D3 Rentals], [D2 Movies]
MOVIE PROVIDER/ADMIN --movie files, details--> (5.0 Manage Catalogue) --> [D2 Movies]
(5.0) --royalty report--> MOVIE PROVIDER
ADMIN --report request--> (6.0 Generate Reports) <-- [D3 Rentals], [D2 Movies]
ADMIN <--rental and revenue reports-- (6.0)

The external entities and the flows that cross the boundary of the context diagram (registration, search, rental request, payment details, streams, receipts, movie files, reports) all reappear at level 0 and no extra ones appear, so the two levels are balanced.

Physical database design

Physical database design is the final step of database design. It takes the normalized relations produced by logical design and decides how they will be stored and accessed in a particular DBMS and on particular hardware, so that the database performs well and is secure and recoverable.

Main decisions:

1. Field (attribute) specification: data types, lengths, formats, default values, null rules and integrity controls (for example range checks).
2. Denormalization: deliberately combining or duplicating data to reduce joins when speed matters more than minimum redundancy.
3. File organization: sequential, indexed, or hashed storage for each table.
4. Indexes: choosing which columns to index (primary keys, foreign keys, frequently searched or sorted columns) to speed queries, balanced against slower updates and extra space.
5. Partitioning and clustering: splitting large tables or storing related records together.
6. Storage, security and backup: allocation of disk space, access rights, backup and recovery plans.

Inputs to this design are the normalized relations, the volume of data, the frequency of queries and updates, response-time expectations, and the DBMS's features.

Why it is important

1. It decides the speed of queries and transactions, which users notice directly.
2. It makes efficient use of storage and hardware.
3. It supports data integrity, security and recoverability.
4. It affects scalability, so the database can cope with growth in data and users.
5. A good logical design may still perform poorly if physical choices are bad; it reduces cost of tuning and rework later.

Logical versus physical database design

Project planning activities of the project manager

Project planning decides what will be done, by whom, when and at what cost. The project manager performs these activities:

1. Defining the scope and objectives. State the problem, the goals, the deliverables and the boundaries of the system, so that everyone agrees on what is included.
2. Identifying and organising the tasks. Break the work into a work breakdown structure (WBS) of phases, activities and tasks, and decide the order and dependencies among them.
3. Estimating effort, time and cost. Estimate person-hours, duration and money for each task using past projects, expert judgement or models such as function points and COCOMO.
4. Scheduling. Build a timetable using Gantt charts and network diagrams (PERT/CPM), find the critical path and set milestones.
5. Resource planning and staffing. Choose team members, assign roles and responsibilities, and arrange hardware, software, tools and facilities.
6. Budgeting. Convert the estimates into a budget and fix a cost baseline.
7. Risk analysis. Identify technical, schedule, cost and people risks, rate their likelihood and impact, and prepare mitigation and contingency plans.
8. Quality and communication planning. Define standards, review and testing activities, reporting formats, meeting schedules and change-control procedures.
9. Feasibility check and documentation. Confirm the plan is feasible, write it as a project plan (Baseline Project Plan) and get approval from the client and management.

The resulting plan is the baseline against which progress is monitored and controlled during execution.

Steps in corporate strategic planning

Corporate strategic planning sets the long-term direction of an organisation and decides how information systems will support it. The usual steps are:

1. Define mission, vision and objectives. State why the organisation exists, where it wants to be, and the measurable goals it will pursue.
2. Analyse the external environment. Study customers, competitors, technology, regulation and economic conditions to find opportunities and threats.
3. Analyse the internal environment. Assess strengths and weaknesses of resources, people, processes and existing systems (together with step 2 this gives a SWOT analysis).
4. Formulate strategies. Choose the strategies that use strengths to take opportunities and reduce weaknesses and threats, for example cost leadership, differentiation or focus.
5. Set strategic goals and critical success factors. Turn the strategy into specific goals, with the factors that must go right to achieve them.
6. Develop the information systems plan. Identify the information systems and applications needed to support the strategy and rank them as a portfolio of projects.
7. Implement the strategy. Allocate budget, assign responsibilities, and carry out projects and organisational changes.
8. Monitor, evaluate and revise. Compare results with goals using performance measures and update the plan as conditions change.

Feasibility study

A feasibility study is a preliminary investigation done early in a project to decide whether the proposed system is worth building. It checks whether the system is technically possible, economically justified, operationally acceptable and achievable in the available time, and so helps management decide to go ahead, change the scope or stop.

Economic feasibility

It asks whether the benefits of the system outweigh its costs. It is also called cost-benefit analysis.

• Costs: development costs (staff, hardware, software, training) and operating costs (maintenance, support, supplies). Some are one-time and some recurring.
• Benefits: tangible benefits that can be measured in money, such as reduced staff cost, fewer errors and more sales, and intangible benefits such as better service and customer satisfaction.
• Techniques: net present value (NPV), return on investment (ROI) and payback period, all with the time value of money considered.

The project is economically feasible if the NPV is positive, the ROI is acceptable and the payback period is short enough.

Schedule feasibility

It asks whether the project can be completed within the time that the organisation needs. The analyst estimates the duration of the tasks, considers deadlines, the availability of people and resources, dependencies and the chance of delays, and checks that the plan fits the required date. If the deadline is too tight, it can be extended, the scope reduced or more resources added.

Traditional methods for determining system requirements

1. Interviewing individuals
2. Interviewing groups
3. Observing workers
4. Studying business documents (document analysis)
5. Questionnaires and surveys

Observation of workers

The analyst watches people do their jobs in their normal workplace to see how the process really works.

Advantages

• Gives firsthand, accurate data about what is actually done, not what people say is done.
• Can check the data obtained from interviews and documents.
• Shows the physical environment, interruptions, informal procedures and workarounds that nobody mentions.
• Shows the real time taken by each task and the real volume of work.
• Is relatively inexpensive and needs little preparation.

Pitfalls

• People who know they are watched may change their behaviour (the Hawthorne effect), so the observation may not show typical work.
• The work observed may be unusual, for example during a slow or a peak period, and not representative.
• Observation is time consuming and the analyst can see only a small sample of the work.
• Some tasks are unpredictable, confidential or happen rarely, so they cannot be observed.
• The analyst may misunderstand what is seen, and workers may resent being observed.
• It reveals only current practice and not what the new system should do.

ER diagram for students, programs and courses

Assumptions: a student enrols in exactly one program, a program has many students, and a program contains many courses while a course can be offered in several programs. A student takes many courses and a course has many students, with the result recorded for each enrolment.

Entities and attributes

• STUDENT (<u>student_id</u>, name, address, phone, date_of_birth, program_id)
• PROGRAM (<u>program_id</u>, program_name, duration, department)
• COURSE (<u>course_code</u>, course_title, credit_hours)
• ENROLLMENT (<u>student_id</u>, <u>course_code</u>, semester, grade) resolves the many-to-many relationship between STUDENT and COURSE.
• PROGRAM_COURSE (<u>program_id</u>, <u>course_code</u>, semester_offered) resolves the many-to-many relationship between PROGRAM and COURSE.

Diagram (crow's foot notation)

 PROGRAM ||----o{ STUDENT          one program has many students (enrolls in)
 STUDENT ||----o{ ENROLLMENT       a student has many enrollments
 COURSE  ||----o{ ENROLLMENT       a course has many enrollments
 PROGRAM ||----o{ PROGRAM_COURSE   a program offers many courses
 COURSE  ||----o{ PROGRAM_COURSE   a course is part of many programs

 +---------+ 1      N +---------+ 1      N +------------+ N      1 +--------+
 | PROGRAM |----------| STUDENT |----------| ENROLLMENT |----------| COURSE |
 +---------+  enrolls +---------+  takes   +------------+  of      +--------+
      | 1                                                              | 1
      |                    +----------------+                          |
      +--------------------| PROGRAM_COURSE |--------------------------+
                         N  +----------------+  N

The underlined attributes are primary keys. student_id and course_code in ENROLLMENT, and program_id and course_code in PROGRAM_COURSE, are foreign keys, and program_id in STUDENT is a foreign key to PROGRAM.

Methods of interacting with the system (human-computer dialogue styles)

The interaction method is the way the user gives input and gets output from the system. The common methods are:

1. Command language. The user types commands with a fixed syntax, for example copy a.txt b.txt. It is fast and powerful for experts but needs memorising and is error prone for novices.
2. Menus. The user chooses from a list of options (pull-down, pop-up, cascading menus). It needs little training and reduces errors, but it can be slow for experts when the menus are deep.
3. Form interaction (fill-in forms). The screen looks like a paper form with labelled fields, which the user fills in. It is suited to data entry and is easy to understand.
4. Object-based or graphical (GUI) interaction. The user manipulates icons, windows and buttons with a mouse or touch (WIMP and direct manipulation). It is intuitive and easy to learn but needs more resources to build.
5. Natural language. The user speaks or writes ordinary sentences, as in chatbots and voice assistants. It is very natural but ambiguity makes it hard to implement accurately.
6. Question-and-answer (dialogue). The system asks questions and the user answers, as in wizards. It guides beginners but is slow for experienced users.
7. Other methods: touch and gesture, voice recognition, and pointing devices such as light pens.

The method is chosen according to the users' experience, the task, the frequency of use and the available hardware. Many systems combine several methods.

Major activities of system maintenance

Maintenance is the modification of an information system after it has been delivered, to correct problems, keep it useful and improve it. The major types of activity are:

1. Corrective maintenance. Finding and fixing errors (bugs) found after installation, such as wrong calculations or crashes.
2. Adaptive maintenance. Changing the system to work in a new or changed environment, for example a new operating system, hardware, database or government regulation.
3. Perfective maintenance. Adding new features or improving performance, usability and efficiency in response to user requests.
4. Preventive maintenance. Restructuring code, updating documentation and making changes to avoid future problems and make later maintenance easier.

Maintenance process (activities in each change)

• Obtaining a maintenance request from a user, recorded on a request form.
• Transforming the request into a change: analysing and understanding the request and the existing system, and planning the change.
• Designing the change and implementing it by modifying code, files and databases.
• Testing the modified system, including regression testing so nothing else breaks.
• Updating documentation and releasing the new version, with version and configuration control.

Maintenance usually consumes most of the cost of the system life cycle, so good documentation, modular design and change control are important.

Class diagram

A class diagram is a UML structural diagram that shows the classes of a system, their attributes and operations, and the relationships among them. It is the main static model of an object-oriented design and is used during analysis and design and as the basis for code.

Notation

A class is a rectangle with three compartments: name, attributes and operations. Visibility is shown as + public, - private, # protected.

Relationships

• Association: a plain line between classes, with multiplicity such as 1, 0.., 1...
• Aggregation: a "has-a" relationship in which the part can exist alone (hollow diamond).
• Composition: a strong whole-part relationship in which the part dies with the whole (filled diamond).
• Generalisation (inheritance): an "is-a" relationship (hollow triangle arrow).
• Dependency: a dashed arrow, where one class uses another.

Example: simple library system

+-------------------+  1      0..*  +--------------------+
| Member            |---------------| Loan               |
|-------------------| borrows       |--------------------|
| -memberId: int    |               | -loanDate: Date    |
| -name: String     |               | -dueDate: Date     |
|-------------------|               |--------------------|
| +borrowBook()     |               | +calculateFine()   |
| +returnBook()     |               +--------------------+
+-------------------+                        | 0..*
        ^                                    |
        |                                    | 1
+-------------------+               +--------------------+
| StudentMember     |               | Book               |
|-------------------|               |--------------------|
| -rollNo: int      |               | -isbn: String      |
+-------------------+               | -title: String     |
                                    |--------------------|
                                    | +isAvailable()     |
                                    +--------------------+

Here Member and Book are linked through Loan (association with multiplicities), and StudentMember inherits from Member (generalisation).

(a) Network diagram

A network diagram is a project scheduling tool that shows the tasks of a project as nodes (or arrows) joined by lines that show their dependencies and order. It is the basis of the PERT and CPM techniques.

• Each task has a duration, an earliest start and finish, and a latest start and finish.
• A forward pass gives the earliest times, and a backward pass gives the latest times.
• Slack (float) is the time a task can be delayed without delaying the project.
• The critical path is the longest path through the network, with zero slack; its length is the minimum project duration, and a delay in any task on it delays the whole project.

It helps the manager to see dependencies, find the critical tasks, estimate the completion time and allocate resources. Unlike a Gantt chart it shows the dependencies clearly.

(b) Structural and behavioral diagrams

UML diagrams are divided into two groups.

Structural diagrams show the static structure of the system, that is, the things it is made of and how they are related, regardless of time. They are:

• Class diagram
• Object diagram
• Component diagram
• Deployment diagram
• Package diagram
• Composite structure diagram

Behavioral diagrams show the dynamic behaviour: how the system acts and changes over time and how objects interact. They are:

• Use case diagram
• Activity diagram
• State machine diagram
• Interaction diagrams: sequence, communication, timing and interaction overview diagrams

Structural diagrams answer "what is the system made of?", and behavioral diagrams answer "what does the system do?"

Prototyping model

In the prototyping model, a working but incomplete model (prototype) of the system is built quickly from the initial, often vague, requirements. Users try it, give feedback, and the prototype is refined repeatedly until the users accept it. The accepted prototype is then either developed into the final system (evolutionary prototyping) or discarded and used as the specification for building the real system (throwaway prototyping). It is very useful when requirements are unclear or the user interface is important.

Phases (diagram)

   +----------------------+
   | Communication /      |
   | Requirements gathering|
   +----------+-----------+
              v
   +----------------------+
   | Quick design         |
   +----------+-----------+
              v
   +----------------------+
   | Build prototype      |<-----------+
   +----------+-----------+            |
              v                        |
   +----------------------+   not OK   |
   | User evaluation /    |------------+
   | feedback (refine)    |
   +----------+-----------+
              | accepted
              v
   +----------------------+
   | Develop final system |
   | (design, code, test) |
   +----------+-----------+
              v
   +----------------------+
   | Implementation &     |
   | maintenance          |
   +----------------------+

1. Requirements gathering: meet users and identify the known requirements and the areas that are unclear.
2. Quick design: a simple design of the visible parts, such as screens, inputs and outputs.
3. Build the prototype: build it quickly using rapid tools.
4. User evaluation: users try the prototype and comment.
5. Refinement: the prototype is modified, and steps 2-4 are repeated until it is accepted.
6. Engineering the final product: the final system is built, tested, deployed and maintained.

Advantages

• Users see a working model early, so misunderstandings are found early.
• Requirements become clearer, and the final system better matches the real needs.
• Users take part actively, which increases their satisfaction and acceptance.
• Missing functions and design errors are found early, when they are cheap to fix.
• Good for developing user interfaces and for unclear requirements.

Disadvantages

• Users may think the prototype is the finished system and may expect it quickly, putting pressure on the developers.
• Poor quality quick-and-dirty code may be carried into the final product.
• Repeated cycles can increase cost and time, and the scope may grow without control.
• Documentation is often neglected, and the project is hard to plan and estimate.
• Developers may get attached to the prototype and use poor design choices to save time.

Reduced decision table: music competition

Conditions

• C1: Age > 18?
• C2: Nationality is Nepalese?
• C3: Entry fee of Rs 5000 paid?
• C4: Plays an instrument for 3 minutes?
• C5: Has the highest points?

Actions

• A1: Reject the applicant (not selected)
• A2: Issue registration number
• A3: Disqualify the applicant
• A4: Give gift hamper
• A5: Declare winner and give cash prize of Rs 1,00,000

A full table with five conditions would have $2^5 = 32$ rules. Because many rules lead to the same action, they can be combined using "-" (irrelevant) entries, giving six rules:

Rule R1 covers 16 of the original rules, R2 covers 8, R3 covers 4, R4 covers 2, and R5 and R6 cover 1 each, so the six rules cover all 32 combinations.

A qualified applicant who is not the top scorer (R5) receives only the gift hamper, and the winner (R6) receives the cash prize and also the hamper since all qualified applicants get one.

Black box and white box testing

Testing process

1. Test planning: decide the scope, strategy, resources, schedule and the test environment from the requirements.
2. Test case design: prepare test cases, each with input data, the conditions and the expected result, using black box and white box techniques.
3. Unit testing: each module or component is tested alone (mostly white box) by the programmer, with stubs and drivers where needed.
4. Integration testing: the tested modules are combined step by step (top-down, bottom-up or big bang) and the interfaces among them are tested.
5. System testing: the complete system is tested against the requirements for functionality, performance, security, recovery and usability.
6. Acceptance testing: the users or customer test the system with real data (alpha testing in the developer's place and beta testing at the user's site) to decide whether to accept it.
7. Defect reporting and fixing: failures are recorded, the cause is found and corrected (debugging), and the tests are repeated (regression testing) to check that nothing else was broken.
8. Test closure: results and test reports are documented and the system is released when the exit criteria are met.

Phases of project management

Project management is usually divided into four phases (PMI describes them as initiating, planning, executing and closing, with monitoring and controlling running through them).

1. Initiating the project. The need is identified, a feasibility study is done, the scope and goals are set, the project manager and team are chosen and the project is authorised.
2. Planning the project. The detailed plan is made: tasks (WBS), estimates of time, effort and cost, schedule, resources and staffing, risk and quality plans, and communication plans. The result is the baseline project plan.
3. Executing the project. The plan is put into action, the team does the work, resources are directed, deliverables are produced, and progress is monitored and controlled by comparing actual results with the plan, handling changes, risks and problems.
4. Closing down the project. The work is completed and handed over, the system is accepted by the client, the contracts and the accounts are closed, the team is released, and a post-project review records the lessons learned.

CASE tools in the systems development life cycle

Computer-Aided Software Engineering (CASE) tools are software tools that automate and support the activities of system development. They improve productivity and quality, keep the analysis, design and code consistent through a central repository, and make documentation and maintenance easier. They are grouped as upper CASE (early phases), lower CASE (later phases) and integrated CASE.

Support in each SDLC phase

• Planning and feasibility: project management tools for scheduling, estimating, Gantt and PERT charts, and cost-benefit calculation.
• Analysis: diagramming tools for DFDs, ER diagrams and use cases, data dictionary and repository tools, requirements tracking, and checking of the models for completeness and consistency. Prototyping and screen painter tools are used to confirm requirements.
• Design: tools for structure charts, class diagrams, database design (schema generation from ER models), form and report generators, and prototyping of the interface.
• Implementation (coding): code generators that produce code from the design, compilers, debuggers, editors and reverse engineering tools.
• Testing: test data generators, test case management, automated test execution and coverage analysis tools.
• Maintenance: configuration and version control, change management, reverse engineering and re-engineering tools, and documentation generators.

Benefits: faster development, better quality and consistency, easier communication through standard diagrams, reuse of components, and up-to-date documentation. Limits: tool cost, training time and the effort of adapting to the tool.

Use case diagram: patient record system

Actors: Admin and User (patient). Doctor receives reports (secondary actor).

                 +--------------------------------------------+
                 |          Patient Record System             |
   +-------+     |                                            |
   | User  |-----|----(Login)<----------------+               |
   +-------+     |         ^  <<include>>      |               |
       |         |         |                   |               |
       +---------|----(View own records)       |               |
                 |                             |               |
   +-------+     |                             |               |
   | Admin |-----|----(Login)------------------+               |
   +-------+     |----(Update / manage records)               |
       |         |         |  <<include>>                      |
       |         |         +--> (Login)                        |
       +---------|----(Generate report)                        |
       |         |         |                                   |
       |         |----(Send report)----------+                 |
       |         |                           |                 |
       |         +---------------------------|-----------------+
       |                                     |
       |                                +--------+
       +--------------------------------| Doctor |
                                        +--------+

Use cases: Login (shared by Admin and User), View own records (User only, read only), Update/manage records (Admin only), Generate report (Admin), Send report to doctors and users (Admin; extends Generate report, with Doctor and User receiving it).

Class diagram

                 +---------------------+
                 |       Person        |
                 |---------------------|
                 | -id: int            |
                 | -name: String       |
                 | -username: String   |
                 | -password: String   |
                 |---------------------|
                 | +login()            |
                 | +logout()           |
                 +----------^----------+
                            |
              +-------------+-------------+
              |                           |
   +----------+---------+      +----------+-----------+
   |        User        |      |        Admin         |
   |--------------------|      |----------------------|
   | -patientNo: int    |      | -staffNo: int        |
   |--------------------|      |----------------------|
   | +viewRecord()      |      | +updateRecord()      |
   +----------+---------+      | +generateReport()    |
              | 1              | +sendReport()        |
              |                +----+------------+----+
              | owns                | manages    | generates
              | 0..*                | 0..*       | 0..*
   +----------+---------+ 1..* 1    |       +----+-----------+
   |       Record       |<----------+       |     Report     |
   |--------------------|                   |----------------|
   | -recordId: int     |                   | -reportId: int |
   | -diagnosis: String |                   | -content: Text |
   | -date: Date        |                   | -date: Date    |
   |--------------------|                   +----+-------+---+
   | +getDetails()      |                        | sent  | sent
   +--------------------+                        | to    | to
                                           1..*  |       | 0..*
                                     +-----------+--+  +-+------+
                                     |    Doctor    |  |  User  |
                                     |--------------|  +--------+
                                     | -doctorId    |
                                     | -name        |
                                     |--------------|
                                     | +receiveReport() |
                                     +--------------+

User and Admin inherit from Person. A User owns many Records and can only view them. An Admin manages (creates, changes) Records and generates Reports, and each Report is sent to Doctors and Users.

Designing effective interfaces

An effective interface is easy to learn, efficient to use and gives few errors. It can be designed by following these principles and steps.

Process

1. Know the users: study their skills, tasks and environment (user analysis, task analysis).
2. Prototype the interface and test it with real users (usability testing), then improve it repeatedly.
3. Evaluate against usability measures such as learning time, speed, error rate and satisfaction.

Design guidelines

• Consistency: the same terms, layout, colours, commands and behaviour everywhere.
• Simplicity and clarity: show only needed information, with clean layout and meaningful labels.
• Feedback: tell the user what the system is doing (messages, progress bars, confirmation).
• Error prevention and handling: validate input, give clear error messages that explain how to correct the error, and provide undo.
• User control and flexibility: shortcuts for experts, help for beginners, and the ability to cancel and go back.
• Minimise memory load: use menus, defaults, and recognition instead of recall.
• Visual design: logical grouping, alignment, readable fonts, good use of colour with sufficient contrast, and accessibility for all users.
• Appropriate dialogue style: menus, forms, commands or GUI chosen for the users and task.
• Good response time and good help and documentation.

An interface built on these principles and tested with users is effective, productive and satisfying.

Advantages of normalization

• Reduces data redundancy (the same data is not stored in many places).
• Avoids insertion, deletion and update anomalies.
• Improves data integrity and consistency.
• Saves storage space.
• Gives a clean, logical structure that is flexible and easy to extend and maintain.
• Makes each table describe one subject, which makes the design easier to understand.

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 that is in 1NF is automatically in 2NF.

Example

Relation ENROLL(<u>StudentID</u>, <u>CourseID</u>, StudentName, CourseTitle, Grade) with key (StudentID, CourseID).

Dependencies:

• $StudentID \rightarrow StudentName$ (partial dependency)
• $CourseID \rightarrow CourseTitle$ (partial dependency)
• $(StudentID, CourseID) \rightarrow Grade$ (full dependency)

The relation is not in 2NF. A student name is repeated for every course, causing update, insertion and deletion anomalies. To convert it to 2NF, remove the partial dependencies into separate relations:

• STUDENT(<u>StudentID</u>, StudentName)
• COURSE(<u>CourseID</u>, CourseTitle)
• ENROLL(<u>StudentID</u>, <u>CourseID</u>, Grade)

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

Disruptive technologies in determining requirements

Disruptive technologies are new technologies that change the way work is done and organisations operate. Analysts use them to gather requirements more effectively, and also to discover requirements that could not be seen with traditional methods. Examples:

1. Group support systems (GSS) and electronic meeting systems: participants enter their ideas anonymously and at the same time on computers, so everyone takes part, the ideas are recorded, and sessions such as JAD are faster, even over distance.
2. Video and web conferencing and collaboration tools: stakeholders at different locations can be interviewed or take part in workshops without travelling, saving time and cost.
3. Prototyping and CASE/rapid application tools: a working model is built fast, so users can react to a real system and clarify what they want.
4. Electronic questionnaires, online surveys and social media: large numbers of users and customers can be reached quickly, and the data is collected and analysed automatically.
5. Data analytics, process mining and logs: usage data, logs and analytics show how the present system is really used, which reveals needs that users do not state.
6. Mobile apps, cloud and AI/chatbots: user feedback, app-store reviews and chat transcripts are mined for requirements, and AI tools help to summarise interviews and documents.
7. Business process management and workflow tools: current processes are modelled and simulated, and bottlenecks and radical improvements are found (as in business process reengineering).
8. Electronic document repositories and wikis: requirements are kept in a shared place where stakeholders can read, comment and track changes.

These technologies make requirements determination faster, cheaper, more accurate and more participative, but need training and care for data privacy.

Process modeling and data modeling

Importance of data modeling

• It gives a clear, shared picture of the organisation's data and its business rules, and helps users and analysts to communicate.
• Data is more stable than processes, so a good data model lasts longer than the processes.
• It is the basis for designing the database, with correct tables, keys and relationships.
• It reduces redundancy and ensures integrity and consistency, since the structure is checked before building.
• It finds missing or inconsistent data requirements early, when changes are cheap.
• It supports integration, reporting, reuse of data and future growth, and makes maintenance easier.

1. PERT

The Program Evaluation and Review Technique (PERT) is a project scheduling method that uses a network diagram and probabilistic time estimates for tasks whose duration is uncertain. For each activity three estimates are made:

• optimistic time $a$
• most likely time $m$
• pessimistic time $b$

The expected time of the activity is

$t_e = \frac{a + 4m + b}{6}$

with variance $\left(\frac{b-a}{6}\right)^2$. The network shows activities as arrows or nodes with dependencies; by a forward and backward pass the earliest and latest times, the slack and the critical path (the longest path, with zero slack) are found. The sum of the expected times on the critical path gives the expected project duration, and the variances give the probability of finishing by a given date. PERT is useful for planning, finding critical tasks and controlling the schedule, but it needs good estimates and does not show resource use.

2. Deliverables

A deliverable is a tangible, verifiable product, document or service that a project must produce and hand over to the client (or that marks completion of a phase). Examples are the feasibility report, requirements specification, design documents, source code, the test report, user manual, training and the installed system. Deliverables are defined during planning in the project scope and work breakdown structure. They are linked to milestones and are reviewed and approved by the client, so they are used to measure progress, to make payments and to confirm that the work is complete and the quality is as agreed.

Phases of project management

1. Initiating the project
2. Planning the project
3. Executing the project (with monitoring and controlling)
4. Closing down the project

Steps in the first phase: initiating the project

In this phase the project manager and the team establish the groundwork so that the project can be planned properly. The steps are:

1. Establishing the project initiation team. A small team is organised to start the project, made of the project manager, analysts and representatives of the client, so that everyone is familiar with the aims of the project.
2. Establishing a relationship with the customer. Contact is made with the customer, who is the sponsor, and the roles, communication methods and expectations are set. This builds trust and cooperation.
3. Establishing the project initiation plan. A short plan is prepared that describes the tasks to be done during initiation, who does them, the time and the resources needed.
4. Establishing management procedures. The rules for how the team works are decided: team communication and reporting, project standards, procedures for change control, documentation and cost management.
5. Establishing the project management environment and project workbook. The tools, facilities and a project workbook (an online or physical repository of all project documents, plans and decisions) are arranged, so that team members and the client can find the information.
6. Developing the project charter. A short document is prepared that states the project's purpose, scope, objectives, deliverables, major assumptions, constraints, high-level risks, estimated cost and time, and the authority of the manager. When approved by the sponsor it formally authorises the project.

The outcome of the phase is a project that is formally approved and ready for detailed planning.

Observation and document analysis compared

Both are used together: documents show the formal system and observation shows the actual one, and the differences reveal what needs to be changed.

Radical methods for determining requirements

Radical methods are used when the existing system is not a good starting point and there must be a major change in the way of doing business. They are typically used in business process reengineering (BPR).

1. Business process reengineering (BPR). The fundamental rethinking and radical redesign of business processes to get dramatic improvements in cost, quality, service and speed. The analyst identifies the main business processes, then disruptive technology is used to design new ones and the old are eliminated instead of being automated.
2. Identifying processes to reengineer. Key business processes (the structured activities that give value to the customers) are found. Their relevance is judged through the study of the critical success factors and the customers' needs.
3. Disruptive technologies. The analyst looks at the technology (such as workflow, groupware, databases, the web and automation) that can allow the organisation to break the old rules and do things in a new way, and then assesses the impact.
4. Rapid prototyping / Joint Application Design (JAD) and group support systems are also used to produce and evaluate the new ideas quickly with users.

With radical methods the old procedures are not studied in detail, and attention is directed to the target process and the changes needed to reach it.

DFD: online pathology system

External entities: Patient, Doctor, Payment gateway (the online payment is made through it). Data stores: D1 Patient, D2 Test Schedule, D3 Payment, D4 Test Report, D5 Doctor Schedule.

Level 0 (context diagram)

  registration details,        login credentials, test date/time,
  login, test details,         payment receipt, notification,
  payment, report request      test report, doctor visit schedule
 +---------+ ------------------------------------> +-----------------------+
 | Patient |                                       |  0                    |
 |         | <------------------------------------ |  Online Pathology     |
 +---------+                                       |  System               |
                                                   |                       |
 +---------+  payment request / payment confirmation|                      |
 | Payment | <------------------------------------>|                      |
 | Gateway |                                       |                       |
 +---------+                                       |                       |
                                                   |                       |
 +---------+  report (email), doctor visit schedule|                       |
 | Doctor  | <-------------------------------------|                       |
 +---------+                                       +-----------------------+

Level 1 DFD

                    registration details
 +---------+ ----------------------------> (1.0 Register patient) ----> D1 Patient
 |         | <---- login credentials ------      
 |         |
 |         | login details --> (2.0 Validate login) <---- patient data ---- D1 Patient
 |         |                         | valid login
 |         |                         v
 |         | test details --> (3.0 Schedule test) ----> D2 Test Schedule
 |         | <-- test date and time --'
 | Patient |
 |         | payment details --> (4.0 Process payment) <--> [Payment Gateway]
 |         | <-- payment receipt --'          |
 |         |                                  v
 |         |                             D3 Payment
 |         |
 |         |        test result --> (5.0 Prepare report) ----> D4 Test Report
 |         | <-- notification ----'           (from lab, reads D2 Test Schedule)
 |         |
 |         | report request --> (6.0 Provide report) <---- report ---- D4 Test Report
 |         | <-- test report (download) --'
 |         |
 |         | <-- doctor visit schedule -- (7.0 Schedule doctor visit)
 +---------+                                  |  <---- D5 Doctor Schedule
                                              | doctor visit schedule + report (email)
                                              v
                                          +--------+
                                          | Doctor |
                                          +--------+

Explanation of processes

1. Register patient: the patient's registration details are stored in D1 and login credentials are returned.
2. Validate login: the entered credentials are checked against D1; only a valid login can proceed.
3. Schedule test: the entered test details are used to fix the test date and time, which are stored in D2 and returned to the patient.
4. Process payment: the patient pays online through the payment gateway; the payment is recorded in D3 and a receipt is returned.
5. Prepare report: after the test the report is saved in D4 and the patient is notified.
6. Provide report: on request the patient downloads the test report from D4.
7. Schedule doctor visit: if a doctor visit is required, the schedule from D5 is sent to the patient and the schedule and report are emailed to the doctor.

Agile methods and traditional methods: distinguishing factors

The critical factors that make agile different are therefore the acceptance of changing requirements, continuous customer collaboration, frequent working increments, the empowerment of small teams, and the preference for individuals and interactions over processes and tools, as in the Agile Manifesto.

The heart of the software development process is the System Development Life Cycle (SDLC), and within it the analysis-design-implementation core: turning the users' requirements into a working, maintainable system through a repeated, controlled cycle of activities.

Phases of the cycle

1. Planning (identification and selection): the problem or opportunity is identified, feasibility (technical, economic, operational, schedule) is studied, and a project plan is prepared.
2. Analysis: requirements are gathered through interviews, questionnaires, observation and document study, then modelled with DFDs, ER diagrams and use cases.
3. Design: logical design (what the system does) and physical design (how it is built): database, inputs/outputs, dialogue/user interface, architecture and program specifications.
4. Implementation: coding, testing, installation, user training and documentation.
5. Maintenance: the system is corrected, adapted and enhanced after delivery. Feedback from maintenance becomes input to a new cycle.

Planning -> Analysis -> Design -> Implementation -> Maintenance
   ^                                                     |
   +-----------------------------------------------------+

Why it is the heart: every other activity (project management, documentation, quality assurance, configuration control) exists to support these phases. The requirements-to-design-to-code flow decides whether the product meets user needs, and its iterative nature (feedback and refinement between phases) is what keeps the software correct and useful over its lifetime.

A dialogue is the sequence of interactions between the user and the system (menus, prompts, forms, commands, feedback). Dialogue design specifies this sequence so that the system is easy, consistent and efficient to use. A dialogue is designed in three stages: designing the dialogue sequence, building a prototype, and assessing usability.

Steps in the dialogue design process

1. Design the dialogue sequence: the analyst studies the use cases and DFD processes to find which screens/forms the user needs and in what order they appear. The sequence and its alternatives are drawn as a dialogue diagram, in which each box is a display (form/menu) with a unique number, a name and a description, and arrows show transitions between displays.
2. Layout the interface: for each display, the arrangement of fields, labels, menus, buttons, messages and help is defined, following standards (consistent position and terminology, logical grouping, meaningful error and confirmation messages, default values, minimum typing, and feedback).
3. Choose the interaction style: menu, command language, form fill-in, object-based/graphical or natural language, depending on the users' skill and the task.
4. Prototype the dialogue: a working model (screen mock-ups, storyboards or a quick prototype in a 4GL/GUI tool) is built so users can see and try the interface early.
5. Assess usability: users test the prototype against criteria such as ease of learning, speed of use, error rate and user satisfaction. Their comments are used to refine the design, and steps 1 to 4 are repeated until the dialogue is accepted.
6. Document the design: the final dialogue diagrams and screen specifications are passed on to the programmers.

Physical file and database design converts the logical (normalised relational) design into physical tables that the DBMS can store and access efficiently. The inputs are the normalised relations, the definitions of attributes, the expectations about volume and usage (queries, frequency, response time) and the DBMS features. The process involves the following steps.

1. Convert relations to tables: each normalised relation becomes a table, each attribute a column, and each primary/foreign key is declared.
2. Choose the data type of each field: select the type (integer, decimal, character, varchar, date, etc.) and size that represents the values, minimises storage, and gives data integrity.
3. Control data integrity: define default values, input formats (masks), range and value-set limits, null/not-null rules, referential integrity between tables, and other constraints and validation checks.
4. Handle missing data: decide how nulls are treated, or substitute a default value, so reports and calculations are not wrong.
5. Denormalise where justified: to speed access, tables may be combined or redundant fields kept (for example joining two one-to-one tables, or storing a derived total), accepting some redundancy in return for fewer joins. This is done only after weighing the cost of update anomalies.
6. Partition and arrange the data: large tables are split horizontally (by rows) or vertically (by columns) to improve performance and security, and records are placed in files so related ones are close together (clustering).
7. Select file organisation and indexes: choose sequential, indexed or hashed organisation according to usage, and create indexes on primary keys, foreign keys and fields frequently used for searching, sorting and joining. Too many indexes slow the updates, so they are selected carefully.
8. Estimate storage and tune: calculate the size of the tables, the growth and the access times, then adjust the design (block sizes, indexes, denormalisation) to meet the performance requirements. The result is documented as the physical table design.

Installation is the process of replacing the old system with the new one, including converting data, installing hardware and software, and moving users to the new system. The main types (conversion strategies) are as follows.

1. Direct (abrupt/cold-turkey) installation: the old system is switched off and the new one starts on a given date.

• Advantages: cheapest and fastest, no duplicated effort.
• Disadvantages: very risky; if the new system fails there is no fallback. It suits small, non-critical systems or when the old system is already unusable.

2. Parallel installation: the old and the new systems run together for a period and their outputs are compared. The old system is retired when the new one is trusted.

• Advantages: lowest risk; errors can be found and the old system serves as backup.
• Disadvantages: expensive (double the work, extra staff and resources), and users may become confused by running two systems. It suits critical systems such as banking and payroll.

3. Single-location (pilot) installation: the new system is installed completely at one site or department first (a pilot), and after problems are resolved, it is installed elsewhere.

• Advantages: the risk is confined to one place and the lessons help later rollouts; the site can be used for training.
• Disadvantages: different locations temporarily run different systems, which can cause communication and data-consistency problems.

4. Phased (staged) installation: the new system is introduced module by module or function by function (for instance, first inventory, then billing, then accounts) until it is complete.

• Advantages: lower risk and gradual user learning.
• Disadvantages: takes longer, and temporary interfaces are needed between the old and new parts.

A suitable strategy is chosen according to the risk, cost, size of the organisation and criticality of the system.

Maintenance effectiveness shows how well the maintenance work keeps the system correct, reliable and useful, relative to its cost. It is measured using several indicators, mostly collected from maintenance requests and logs.

1. Number of failures: a count of the failures of the system over a period. A good maintenance programme keeps the failures low and decreasing. A large number of failures suggests poor initial quality or poor maintenance.

2. Mean time between failures (MTBF): the average time the system operates before a failure occurs.

$MTBF = \frac{\text{total operating time}}{\text{number of failures}}$

A rising MTBF means that the maintenance is improving reliability.

3. Mean time to repair (MTTR) / time lag: the time between a problem being reported and its resolution. A shorter response and repair time indicates more effective maintenance.

4. Types and number of maintenance requests: tracking the requests as corrective, adaptive, perfective and preventive. A high proportion of corrective requests signals poor quality, while a rise in the number of requests for enhancements shows that users are actively using the system. The trend, the backlog and the number of requests resolved on time are checked.

5. Cost of maintenance: the cost per request or per module compared with the cost of development. Maintenance consuming a growing share of the budget indicates that the system is hard to maintain and may have to be replaced.

6. User satisfaction: surveys and feedback about response, quality of fixes, and whether the new changes cause new errors (rework rate).

A well-managed system shows few failures, a high MTBF, a low MTTR, controlled costs and satisfied users. Good records of every request, with its cause, effort and outcome, are needed to calculate these measures.

A sequence diagram shows the time-ordered messages exchanged between objects/actors for one scenario. Below is the main scenario of ordering food online and paying online.

Participants (lifelines): Customer, Web/App Interface, Order Controller, Restaurant, Payment Gateway (bank), Delivery Service.

Customer      Interface        OrderSystem      Restaurant     PaymentGateway    Delivery
   |              |                 |               |                |              |
   |--login------>|                 |               |                |              |
   |              |--authenticate-->|               |                |              |
   |<--menu list--|<--menu data-----|               |                |              |
   |--select items,place order----->|               |                |              |
   |              |--createOrder--->|               |                |              |
   |              |                 |--checkAvailability(items)----->|                |
   |              |                 |<--available/confirmed----------|                |
   |<--show bill/amount-------------|               |                |              |
   |--choose online payment, details>|              |                |              |
   |              |                 |--processPayment(amount, card)->|              |
   |              |                 |<--payment success/failure------|              |
   |   [alt: payment success]       |               |                |              |
   |              |                 |--confirmOrder->|               |              |
   |              |                 |--assignDelivery------------------------------>|
   |<--order confirmation + receipt-|               |                |              |
   |              |                 |               |--prepare food->|              |
   |              |                 |               |--ready-------------------------->|
   |<--delivery & status updates--------------------------------------------------------|
   |   [else: payment failed]       |               |                |              |
   |<--payment failed, retry/cancel-|               |                |              |

Explanation of the flow

1. The customer logs in, and the system authenticates and displays the menu.
2. The customer selects items and places the order; the order system creates the order and checks the item availability with the restaurant.
3. The bill is displayed, and the customer chooses online payment and enters the details.
4. The order system sends the payment request to the payment gateway, which returns success or failure.
5. Alt (success): the order is confirmed with the restaurant, a delivery person is assigned, and the customer receives a confirmation, a receipt and live status updates until delivery.
6. Alt (failure): the customer is told that the payment failed and may retry or cancel; the order is not sent to the restaurant.

(a) Integration testing

Integration testing is the testing in which individually tested units/modules are combined and tested as a group to detect faults in their interfaces and interactions (wrong data passing, mismatched parameters, timing and shared-data problems). It follows unit testing and precedes system testing.

Main approaches:

• Big-bang: all modules are combined at once and tested; simple but it is hard to locate faults.
• Top-down: testing starts with the top-level modules, and lower modules are replaced by stubs until they are added.
• Bottom-up: testing starts with the lowest-level modules, which are driven by drivers, moving upwards.
• Sandwich (hybrid): a combination of top-down and bottom-up.

Integration testing is incremental in most cases, so errors can be traced to the most recently added module.

(b) Relational model

The relational model, proposed by E. F. Codd, organises data as a collection of relations (tables). Each relation has rows (tuples), which are records, and columns (attributes), which are fields drawn from a domain.

Key features:

• Every relation has a unique name, each attribute a unique name, and the order of rows and columns is not significant.
• Each cell holds a single atomic value, and no two rows are identical.
• A primary key uniquely identifies each tuple; a foreign key is an attribute that refers to the primary key of another relation, linking the tables.
• Integrity rules: entity integrity (a primary key cannot be null) and referential integrity (a foreign key must match an existing primary key value or be null).
• Data is manipulated by relational algebra (select, project, join, union) and SQL, and the design is improved by normalisation (1NF, 2NF, 3NF) to remove redundancy.

Example: STUDENT(RollNo, Name, Address) and ENROLL(RollNo, CourseID, Grade), where RollNo in ENROLL is a foreign key to STUDENT.