Lecture Notes: Chapter 8 - Structuring System Data Require-

ments
Based on: Modern Systems Analysis and Design by Valacich & George

Overall Topic
This lecture focuses on how to understand, structure, and represent the data that an information system
needs to manage. It introduces conceptual data modeling, primarily using Entity-Relationship (E-R)
diagrams.

Summary
This chapter introduces Conceptual Data Modeling, a critical early step in designing information
systems. It’s about creating a high-level map (an Entity-Relationship Diagram or E-R Diagram) of
the important data within an organization or for a specific project, before worrying about the specific
database software that will be used. We learn how to identify key pieces of information (entities), their
characteristics (attributes), and how they connect (relationships). The lecture covers techniques for
gathering the necessary information, the standard symbols used in E-R diagrams, how to define different
types of entities and attributes (including special cases like supertypes/subtypes and associative
entities), and the importance of defining business rules to ensure data quality. Finally, it touches
upon using pre-existing database patterns as a starting point.

Key Definitions
1. Conceptual Data Modeling: The process of creating a detailed, high-level model showing the
structure of data in an organization, independent of specific database software or implementation
details.
2. Entity-Relationship (E-R) Model: A logical representation describing the main data objects
(entities), their connections (relationships), and their properties (attributes) within a business area.
3. Entity-Relationship (E-R) Diagram: A graphical picture or map representing an E-R model.
Uses standardized shapes and lines.
4. Entity Type: A category or collection of things (people, places, objects, events, concepts) that
share common characteristics and about which an organization needs to store data. (e.g., STU-
DENT, COURSE, ORDER). Represented by a rectangle.
5. Entity Instance: A single occurrence or example of an entity type (e.g., a specific student John
Doe, a specific course ’Intro to Basket Weaving’, a specific order #12345).
6. Attribute: A named property or characteristic of an entity type that is of interest (e.g., for a
STUDENT entity, attributes might be Student_ID, Name, Address, Major). Listed inside the
entity rectangle.
7. Identifier (Primary Key): An attribute (or combination of attributes) whose value uniquely
identifies each instance of an entity type (e.g., Student_ID for STUDENT). Usually underlined or
marked specifically in E-R diagrams.
8. Candidate Key: An attribute or set of attributes that could serve as the primary key because it
uniquely identifies instances. The chosen one becomes the Identifier/Primary Key.
9. Multivalued Attribute: An attribute that can hold more than one value for a single entity
instance (e.g., ’Skills’ for an EMPLOYEE, as one employee might have multiple skills). Often
requires special handling in modeling.
10. Relationship: An association or link between instances of one or more entity types that is im-
portant to the organization (e.g., a STUDENT registers for a COURSE). Represented by a line
connecting entities, often with a diamond or label.
11. Degree (of a Relationship): The number of different entity types participating in a relationship
(Unary=1, Binary=2, Ternary=3).
12. Cardinality: Rules that specify how many instances of one entity type can (or must) be associated
with each instance of another entity type in a relationship. Expressed using minimums and max-
imums (e.g., one-to-one, one-to-many, many-to-many). Indicated by symbols on the relationship
lines.

1
 13. Associative Entity (Gerund): An entity type created to represent a relationship that has its
own attributes or needs to be treated as an entity itself, typically arising from many-to-many
relationships.
14. Subtype: A subgrouping of entities within a broader entity type that has unique attributes or
relationships (e.g., OUTPATIENT and RESIDENT PATIENT might be subtypes of PATIENT).
15. Supertype: A generic entity type that includes one or more subtypes (e.g., PATIENT is the
supertype for OUTPATIENT and RESIDENT PATIENT).
16. Business Rules: Specifications or constraints that ensure the logical data model maintains data
integrity and reflects how the organization operates.
17. Domain: The set of all possible valid values (including data type, length, format) that an attribute
can have.
18. Triggering Operation (Trigger): A business rule (often automated) that specifies an action to
be taken when a certain data manipulation event (like insert, update, delete) occurs under specific
conditions.
19. Packaged Data Models (Database Patterns): Pre-defined, generic data models (often industry-
specific) that can be purchased or used as templates to speed up development.

Basic Concepts
1. Role of Conceptual Data Modeling in SDLC:
• Occurs during the Analysis phase of the Systems Development Life Cycle (SDLC).
• Focuses on understanding and structuring data requirements.
• It’s independent of how the data will eventually be stored (no specific database system is
assumed yet).
• The main output is an E-R Diagram and supporting documentation (definitions).
• This model serves as a blueprint for later database design stages (logical and physical design).
2. Information Gathering for Data Modeling:
• Top-Down: Starts with a broad understanding of the business and its functions to identify
major entities and relationships.
• Bottom-Up: Examines existing documents, forms, reports, and system specifications to find
data elements, then groups them into entities and relationships.
• Requires asking key questions about business subjects/objects (entities), unique identifiers
(primary keys), descriptive characteristics (attributes), data usage, time relevance, relation-
ships between objects, and special handling rules.
3. Core Components of E-R Models:
• Entities: The main "things" we need to track data about (e.g., Customer, Product, Order).
Represented by rectangles.
– Naming: Use singular nouns (e.g., "Customer" not "Customers"). Be descriptive and
concise.
– Defining: Clearly state what is included/excluded, the unique identifier, and lifecycle
events (creation/deletion).
• Attributes: The properties or details describing each entity (e.g., Customer Name, Product
Price). Represented inside the entity rectangle.
– Naming: Use nouns, be unique, follow standards.
– Defining: Explain meaning, source, constraints (required/optional, format).
– Types of Attributes:
∗ Identifier (Primary Key): Uniquely identifies an entity instance.
∗ Required vs. Optional: Must it have a value?
∗ Simple vs. Composite: Can it be broken down (e.g., Address into Street, City, Zip)?
∗ Single-Valued vs. Multivalued: Can it hold multiple values (e.g., Skills)?
∗ Stored vs. Derived: Is the value stored directly, or calculated from other attributes
(e.g., Age calculated from Birth Date)?
• Relationships: How entities are connected or associated (e.g., a Customer places an Order).
Represented by lines connecting entity rectangles, sometimes with a diamond shape for the
name.

2
 – Naming: Use verb phrases (e.g., "Places", "Assigned To").
– Defining: Explain the action, provide examples, specify rules.
– Degree: How many entity types involved? (Unary = 1, Binary = 2, Ternary = 3). Binary
is most common.
– Cardinality: Specifies the number of instances related. Uses minimum (0 or 1) and
maximum (1 or Many ’N’) constraints. Common types: 1:1, 1:N, M:N. Symbols like
crow’s feet notation indicate these constraints visually on the E-R diagram.
4. Advanced E-R Concepts:
• Associative Entities: Used to model relationships (especially M:N) that have attributes.
The M:N relationship itself becomes an entity. Example: If we track the Date_Completed
when an EMPLOYEE Completes a COURSE (an M:N relationship), we might create an associative
entity called CERTIFICATION with Employee_ID, Course_ID, and Date_Completed.
• Supertypes and Subtypes: Model generalization/specialization hierarchies. A generic
Supertype (e.g., PERSON) can have specialized Subtypes (e.g., EMPLOYEE, STUDENT, ALUMNUS).
This helps manage shared and specific attributes/relationships efficiently.
– Specialization Rules: Total (every supertype instance must be one of the subtypes) vs.
Partial (a supertype instance might not be any of the subtypes).
– Disjointness Rules: Disjoint (an instance can only be one subtype) vs. Overlap (an
instance can be multiple subtypes simultaneously).
5. Business Rules:
• Crucial for maintaining data quality and reflecting organizational policies.
• Captured during requirements gathering.
• Types:
– Entity Integrity: Primary keys must be unique and cannot be null (empty).
– Referential Integrity: Rules governing relationships, ensuring foreign keys link to valid
primary keys.
– Domains: Define valid values for attributes (data type, range, format).
– Triggering Operations: Other specific rules enforced via triggers (e.g., "If inventory level
drops below X, create a reorder request").
6. Packaged Data Models:
• Using pre-built generic or industry-specific data models can save time and leverage best prac-
tices.
• They provide a starting point that can be customized.

3
Lecture Notes: Chapter 9 - Designing Databases
Based on: Modern Systems Analysis and Design by Valacich & George

Overall Topic
This lecture transitions from the conceptual data model (Chapter 8) to the actual design of the database
that will be implemented using specific database software. It covers logical database design (using the
relational model and normalization) and physical database design (dealing with storage, efficiency, and
file structures).

Summary
This chapter focuses on the database design process, which follows conceptual modeling. It involves two
main stages: Logical Design and Physical Design. Logical design translates the conceptual E-R model
into a set of well-structured tables (relations) using the Relational Database Model. A key technique
here is Normalization, a process to reduce data redundancy and prevent errors by organizing attributes
according to specific rules (like Second Normal Form - 2NF and Third Normal Form - 3NF). We
learn how to represent entities and relationships as relations, including handling different relationship
types (1:1, 1:N, M:N, Unary). Physical Design then takes these logical relations and determines the
technical specifications for how they will actually be stored on computer hardware, considering data
types, file organizations, indexing, and performance optimization techniques like denormalization and
partitioning. The goal is an efficient and reliable database structure.

Key Definitions
1. Logical Database Design: The process of creating stable data structures (like tables in a re-
lational database) from the conceptual model, independent of the specific database software or
physical storage details. Uses a specific data model like the Relational Model.
2. Physical Database Design: The process of translating the logical database design into technical
specifications for storing data on physical media, considering performance, storage space, security,
and the specific database management system (DBMS).
3. Relational Database Model: A way of representing data using a collection of related two-
dimensional tables, called relations.
4. Relation: A named, two-dimensional table of data consisting of a set of named columns (at-
tributes) and an arbitrary number of unnamed rows (records or tuples). Must adhere to specific
properties (e.g., unique rows, simple atomic values in cells).
5. Well-Structured Relation: A relation that contains minimal data redundancy and allows users
to insert, delete, and update rows without causing data inconsistencies or errors (anomalies).
6. Primary Key (PK): An attribute or set of attributes whose value uniquely identifies each row
in a relation. Essential for relational integrity.
7. Normalization: The process of converting complex data structures (often derived directly from
user views or unnormalized data) into simpler, more stable relations by following a set of rules
(Normal Forms) to reduce redundancy and improve data integrity.
8. Normal Forms (NF): Standards or rules for relation structure:
• First Normal Form (1NF): All relations inherently are. Requires unique rows and no
multivalued attributes within a single cell (values must be atomic).
• Second Normal Form (2NF): Must be in 1NF AND every non-primary key attribute must
depend on the entire primary key (no partial dependencies). Primarily relevant for relations
with composite primary keys.
• Third Normal Form (3NF): Must be in 2NF AND no non-primary key attribute should
depend on another non-primary key attribute (no transitive dependencies).
9. Functional Dependency: A relationship between attributes where the value of one attribute (or
set of attributes) determines the value of another attribute (A → B means A determines B). The
foundation of normalization rules.
10. Foreign Key (FK): An attribute (or set of attributes) in one relation that serves as the primary
key for another relation. Used to link relations together and enforce referential integrity.

4
 11. Referential Integrity: A constraint ensuring that the value of a foreign key in one relation must
either match a primary key value in the related relation or be null (if allowed). Prevents "orphan"
records.
12. Field: The smallest unit of application data recognized by system software; the physical imple-
mentation of an attribute.
13. Data Type: A specification that tells the database system how to store data for a field (e.g., text,
number, date) and what operations can be performed on it.
14. Null Value: A special marker used in a field to indicate that the value is missing, unknown, or
not applicable. It’s distinct from zero or an empty string.
15. Denormalization: The process of intentionally combining data from normalized relations into
fewer tables to improve query performance, even though it increases redundancy and potentially
complicates updates. A trade-off made during physical design.
16. Partitioning: Splitting a large table into multiple smaller physical pieces (partitions), often based
on ranges of values or hashing, to improve manageability and performance.
17. File Organization: A technique for physically arranging the records (rows) of a file (table) on
secondary storage (like a hard disk).
18. Indexed File Organization: A file organization where records can be accessed directly (ran-
domly) using an index, rather than reading sequentially through the file.
19. Index: A separate data structure (often a table or tree) that allows the database to quickly find
rows in a table based on the values of specific columns (indexed columns). Speeds up queries but
slows down updates/inserts/deletes.

Basic Concepts
1. The Database Design Process:
• Follows conceptual modeling (Chapter 8).
• Logical Design:
– Choose a database model (typically Relational).
– Transform the E-R diagram into relations (tables).
– Apply Normalization rules (usually up to 3NF) to ensure relations are well-structured.
– Combine relations from different user views or E-R diagrams (View Integration), re-
solving issues like synonyms (different names, same meaning) and homonyms (same name,
different meaning).
– Result: A set of normalized relations.
• Physical Design:
– Select specific Data Types and sizes for each field (attribute).
– Decide on File Organizations (how rows are physically stored: sequential, indexed,
hashed).
– Create Indexes on primary keys, foreign keys, and frequently queried columns to speed
up data retrieval.
– Consider performance optimization: Maybe Denormalize some relations or use Parti-
tioning.
– Define integrity constraints (defaults, range checks, null handling, referential integrity
using foreign keys).
– Plan for Security and Backup/Recovery.
– Result: Technical specifications for database tables, ready for creation using SQL (Struc-
tured Query Language).
2. The Relational Model:
• Data is stored in tables (relations).
• Tables are linked via common attributes (Primary Key ↔ Foreign Key).
• Properties: Simple values in cells, columns hold same type of data, rows are unique (guaran-
teed by PK), column/row order doesn’t matter logically.
3. Normalization (Why and How):
• Goal: Reduce redundancy, avoid update/insert/delete anomalies (errors/inconsistencies), cre-
ate stable data structures.
• Based on: Functional Dependencies (how attributes determine each other).

5
 • 1NF: Base level - ensure atomic values, unique rows.
• 2NF: Fixes partial dependencies. If a non-key attribute depends only on part of a composite
PK, move that attribute and the determining part of the PK into a new relation.
• 3NF: Fixes transitive dependencies. If a non-key attribute depends on another non-key
attribute, move the dependent attribute and its determinant non-key into a new relation.
• Most business databases aim for 3NF.
4. Transforming E-R Diagrams to Relations:
• Entities: Each regular entity becomes a relation (table). The entity’s identifier becomes the
PK.
• Relationships:
– 1:N Binary: Add the PK of the ’1’ side entity as an FK in the ’N’ side relation.
– 1:1 Binary: Add the PK of one entity as an FK in the other (choice depends on specifics,
often placed on the more optional or "dependent" side).
– M:N Binary/Higher Degree: Create a new relation (associative/linking table). The PK
of this new table is a composite key formed from the PKs of all participating entities.
Any attributes of the relationship itself are placed in this new relation.
– Unary 1:N (Recursive): Add an FK to the same relation that refers back to its own PK
(e.g., ManagerID in EMPLOYEE table refers to EmployeeID).
– Unary M:N (Recursive): Create a new linking table with a composite PK consisting
of two FKs referencing the original entity’s PK (e.g., ITEM_STRUCTURE(ItemNumber,
ComponentNumber)).
5. Physical Design Considerations:
• Field Design: Choose appropriate data types (VARCHAR for variable text, CHAR for
fixed-length, NUMBER, DATE, etc.) balancing storage, valid values, integrity, and desired
operations. Define constraints (default values, range checks, null allowed?).
• Physical Tables: Normalized relations usually become physical tables.
• Denormalization: Sometimes necessary for performance. Combine tables if they are very
frequently joined and performance is critical (e.g., merge a 1:1, put non-key attributes in an
M:N linking table, embed reference data). Use cautiously.
• Partitioning: Break large tables into smaller physical units for faster access or easier man-
agement.
• File Organization: How are rows stored?
– Sequential: Simple, good for batch processing, bad for random access.
– Indexed: Most flexible. Allows fast random access via an index and can support sequen-
tial processing. Requires extra storage and maintenance for indexes. Most common in
relational databases.
– Hashed: Very fast random access based on a calculation (hash function), poor for sequen-
tial access or range queries.
• Indexing: Create indexes on PKs (usually automatic), FKs (important for joins), and
columns frequently used in WHERE clauses, ORDER BY, or GROUP BY to speed up queries.
Don’t over-index, as it slows down data modifications.
• Data Integrity and Controls: Implement constraints physically (NOT NULL, UNIQUE,
CHECK constraints, FOREIGN KEY constraints). Plan backup and recovery strategies.
Implement security measures (passwords, permissions, encryption).

6
Lecture Notes: Chapter 10 - Designing Forms and Reports
Based on: Modern Systems Analysis and Design by Valacich & George

Overall Topic
This lecture explores how to design effective forms (for data input) and reports (for data output) within
an information system, focusing on user needs and usability.

Summary
This chapter focuses on designing the documents and screens that users interact with to either enter data
(Forms) or view summarized/detailed information (Reports). It emphasizes a user-centered design
process, often using prototyping. Key topics include understanding the difference between forms and
reports, identifying various types of reports (like scheduled, exception, ad-hoc), and the steps involved
in the design process (requirements gathering, prototyping, evaluation). The lecture provides numerous
general guidelines for formatting, such as using meaningful titles, ensuring balanced layouts, and
providing easy navigation. It covers techniques for highlighting important information, the effective
use (and potential pitfalls) of color, and specific rules for displaying text, formatting tables, and
creating clear lists. Finally, the chapter discusses usability – how to assess if a form or report is easy
and effective to use – and touches upon specific design considerations for web-based systems, like using
lightweight graphics and stylesheets.

Key Definitions
1. Form: A business document or screen that contains predefined data and includes areas where
users can fill in additional information. Often used for data input related to a single record (e.g.,
an order form, a customer information screen).
2. Report: A business document or screen containing only predefined data, intended for reading or
viewing. Often summarizes or presents data from multiple records (e.g., a monthly sales report, a
list of overdue accounts).
3. Scheduled Report: Produced at regular time intervals (daily, weekly, monthly).
4. Key-Indicator Report: Summarizes critical information regularly.
5. Exception Report: Highlights data that falls outside normal operating ranges, drawing attention
to potential issues.
6. Drill-Down Report: Provides detailed data underlying a summary found in a key-indicator or
exception report.
7. Ad-hoc Report: Generated on demand to answer specific, unplanned questions.
8. Prototyping: An iterative design process involving creating a preliminary version (prototype) of
a form or report, having users evaluate it, and refining it based on feedback until it’s accepted.
9. Wireframe: A simple, basic visual guide (like a sketch) showing the placement and size of elements
on a screen or page without detailed formatting or graphics. Used early in design.
10. Design Specification: The formal deliverable from the design process, detailing the form or
report. Includes a narrative overview (users, tasks, environment), a sample design image, and
results from testing/usability assessment.
11. Usability: An overall measure of how effectively and efficiently a specific user can use a system
(or a form/report) to accomplish a specific task, and how satisfied they are with the experience.
12. Lightweight Graphics: Small, simple images used on web pages to minimize download time and
improve responsiveness.
13. Stylesheet-Based HTML: A web design technique (using technologies like CSS - Cascading Style
Sheets) that separates the content (HTML) from its formatting and presentation rules (stylesheets),
making maintenance and consistency easier.

Basic Concepts
1. Forms vs. Reports:
• Forms are for input (and often display existing data), typically focused on one main record
(e.g., one customer, one order).

7
 • Reports are for output only (passive viewing), often aggregating data from many records
(e.g., total sales for all customers).
2. The Design Process:
• User-Focused: Design must prioritize the needs and abilities of the intended users.
• Requirements Determination: Ask key questions: Who will use it? What is its purpose?
When/Where is it needed? How many users?
• Prototyping Cycle:
– Build an initial prototype (e.g., wireframe, then more detailed version).
– Have users review and provide feedback.
– Refine the design based on feedback.
– Repeat until users accept the design.
• Deliverable: The Design Specification document.
3. General Formatting Guidelines:
• Meaningful Titles: Clear, specific, include version/date if applicable.
• Meaningful Information: Include only necessary data; users shouldn’t need to look else-
where or calculate things themselves.
• Balanced Layout: Use whitespace effectively; organize information logically with clear mar-
gins and spacing. Don’t overcrowd.
• Easy Navigation: Clearly indicate how to move around (e.g., next/previous page, screen
sections) and the current location.
4. Highlighting Information:
• Purpose: Draw attention to errors, warnings, key fields, commands, or unusual data.
• Methods: Use sparingly and consistently. Options include color, intensity (bold), size dif-
ferences, different fonts, boxing, underlining, reverse video (white text on black), all caps,
blinking/sound (use with extreme caution - can be annoying).
5. Using Color:
• Benefits: Can make displays more visually appealing, group related items, subtly distinguish
information, emphasize logical structure, highlight warnings, evoke emotion.
• Problems: Poor color combinations can reduce readability or be unusable for color-blind
users; appearance can vary on different displays; doesn’t translate well to monochrome print-
ing. Use standard, tested color schemes.
6. Displaying Text:
• Case: Use mixed upper and lower case (like normal sentences) for better readability. Avoid
ALL CAPS except for short headings/labels.
• Spacing: Use double spacing or blank lines between paragraphs if space allows.
• Justification: Left-justify text (ragged right margin) is generally easiest to read.
• Hyphenation: Avoid hyphenating words at the end of lines.
• Abbreviations: Use only common, widely understood abbreviations that are significantly
shorter.
7. Designing Tables and Lists:
• Labels: All columns and rows need clear, meaningful labels. Use highlighting to separate
labels from data. Repeat labels on subsequent pages/screens.
• Formatting Data:
– Sort data meaningfully (e.g., alphabetically, numerically, chronologically).
– Use blank lines every ∼5 rows in long lists to aid visual tracking.
– Align numeric data right (often by decimal point); align text data left.
– Break long alphanumeric codes (e.g., credit card numbers) into smaller visual chunks.
• Typeface: Use a single, simple typeface for readability. Use variations (bold, italics) only for
emphasis. Avoid overly decorative fonts.
• Tables vs. Graphs:
– Use tables when users need specific individual values.
– Use graphs (line, bar, pie) to show summaries, trends, comparisons, patterns, or large
amounts of information quickly.
8. Assessing Usability:

8
 • Key Characteristics: Speed (efficiency), Accuracy (does it work as expected?), Satisfaction
(do users like it?).
• Success Factors: Consistency (in terminology, layout, behavior), Organization (logical flow),
Ease (self-explanatory), Format (appropriate display), Flexibility (user options).
• Consider: The specific User (experience, skills), Task (complexity, time pressure), System
(platform limitations), and Environment (physical/social context).
• Measures: Learnability (easy for novices?), Efficiency (fast for experts?), Error Rate (few
errors? easy recovery?), Memorability (easy to remember steps?), Satisfaction/Aesthetics
(enjoyable experience?).
9. Web Design Considerations (PVF Example):
• Lightweight Graphics: Use small images for fast loading.
• Forms & Integrity: Clear labels, examples, indicate required/optional fields, validation
rules.
• Stylesheet-Based HTML (CSS): Separates content from presentation for consistency and
easier maintenance.

9
Lecture Notes: Chapter 11 - Designing Interfaces and Dialogues
Based on: Modern Systems Analysis and Design by Valacich & George

Overall Topic
This lecture focuses on designing the way users interact with an information system, including the overall
interaction style (interface) and the sequence of interactions (dialogue).

Summary
This chapter delves into the design of interfaces (how users interact with the system) and dialogues
(the sequence or "conversation" between the user and the system). It emphasizes a user-focused, iterative
prototyping approach similar to forms and reports design. The lecture introduces various methods
of interaction, such as command line, menus, forms, object-based (icons), and natural language, along
with the associated hardware devices (keyboard, mouse, touch screen, etc.) and their usability consid-
erations. It provides guidelines for designing effective interfaces, including layout principles, structuring
data entry fields, techniques for validating user input to minimize errors, the importance of providing
clear feedback, and designing helpful system help. The concept of dialogue design is explored,
including mapping the flow of interaction using dialogue diagramming. Finally, specific issues related
to designing Graphical User Interfaces (GUIs) and interfaces for web-based e-commerce systems (like
using cookie crumbs for navigation) are discussed.

Key Definitions
1. Interface: The method or point of interaction between a user and an information system.
2. Dialogue: The sequence of interactions (like a conversation) between a user and a system to
accomplish a task.
3. Prototyping: An iterative design process: collect info → build prototype → assess usability →
make refinements → repeat.
4. Design Specification (for Interface/Dialogue): Includes narrative overview, sample designs
(multiple forms/screens), usability assessment, and the dialogue sequence.
5. Dialogue Sequence: Specifies the possible paths a user can take through the various displays
(screens/forms) of an interface.
6. Interaction Methods: Styles by which users interact with a system:
• Command Language Interaction: User types specific commands (e.g., copy file.txt).
Powerful but requires learning commands.
• Menu Interaction: User selects options from a list. Easy to learn. Types include pop-up
and drop-down menus.
• Form Interaction: User fills in blanks on a screen resembling a paper form. Intuitive for
data entry.
• Object-Based Interaction: User interacts with graphical symbols (Icons) representing
commands or functions (common in GUIs).
• Natural Language Interaction: User interacts using conversational language (spoken or
typed). Still largely experimental and challenging to implement robustly.
7. Icon: A graphical picture representing a specific function, object, or command.
8. Hardware Interaction Devices: Physical tools used for interaction (Keyboard, Mouse, Joystick,
Trackball, Touch Screen, Light Pen, Graphics Tablet, Voice input).
9. Data Entry Validation: Techniques used to check data entered by users for errors or inconsis-
tencies.
10. System Feedback: Information provided by the system to the user regarding status, required
actions, or errors. Types:
• Status Information: Keeps user informed (e.g., progress bar).
• Prompting Cues: Guides the user on what to do next.
• Error/Warning Messages: Informs the user about problems.
11. System Help: Information provided to assist users in understanding and using the system.

10
 12. Dialogue Diagramming: A formal technique using boxes and lines to visually represent the
sequence, branching (selection), and looping (iteration) of dialogues between screens.
13. Cookie Crumbs (Breadcrumbs): A website navigation technique showing the user’s path
through the site hierarchy (e.g., Home > Products > Laptops > Model X), allowing easy back-
tracking.

Basic Concepts
1. Interface and Dialogue Design Process:
• User-Focused: Design around the user’s capabilities, tasks, and environment.
• Prototyping: Iteratively build, test, and refine interface elements and dialogue flow.
• Deliverable: A detailed Design Specification including screen layouts, field definitions, and
dialogue sequence diagrams.
2. Methods of Interaction:
• Command Line: Efficient for expert users; high learning curve.
• Menu: Reduces learning; easier for novices; can be slow for experts if menus are deep.
Guideline categories: Wording, Organization, Length, Selection, Highlighting.
• Form: Good for structured data entry; intuitive link to paper counterparts.
• Object-Based (GUI): Relies on icons and direct manipulation (e.g., drag-and-drop); intu-
itive for many tasks.
• Natural Language: Potentially very easy if it works well, but technically difficult.
3. Hardware Devices & Usability:
• Different devices suit different tasks (e.g., mouse for pointing, keyboard for text entry).
• Consider usability issues: Visual Blocking (does hand/device obscure screen?), User Fatigue
(discomfort with prolonged use?), Movement Scaling (how device movement translates to
cursor movement?), Durability, Feedback provided by device, Speed, Pointing Accuracy.
4. General Interface Design Principles:
• Use standard layouts (like paper forms if applicable).
• Follow natural flow: Left-to-right, top-to-bottom.
• Structure common areas: Header, Body, Totals, Authorization, Comments.
5. Structuring Data Entry Fields:
• Entry: Don’t require data the system already knows or can compute.
• Defaults: Provide sensible default values.
• Units: Clearly label units (e.g., $, kg, lbs).
• Replacement: Use character masks (e.g., showing *** for passwords).
• Captioning: Place labels adjacent to fields.
• Format: Show examples of required format (e.g., YYYY-MM-DD).
• Justify: Automatically align data appropriately (numbers right, text left).
• Help: Provide context-sensitive help.
6. Controlling Data Input (Validation):
• Goal: Reduce errors (Appending, Truncating, Transcripting, Transposing).
• Techniques (Examples):
– Class/Composition: Check if data is numeric, alphabetic, etc.
– Combinations: Check if related fields make sense together (e.g., city and state).
– Expected Values: Check against a list of valid entries (e.g., valid product codes).
– Missing Data: Ensure required fields are filled.
– Pictures/Templates: Check if data matches a required format (e.g., phone number).
– Range: Check if numeric data is within acceptable limits.
– Reasonableness: Check if data is plausible (e.g., order quantity isn’t negative).
– Self-Checking Digits: Use algorithms (like Luhn for credit cards) to validate numbers.
– Size: Check for correct length.
– Values: Check against a predefined set (e.g., valid state codes).
7. Providing Feedback & Help:
• Feedback: Keep users informed! Use status info, prompts, and clear error messages.
• Help: Put yourself in the user’s shoes. Keep help simple, organized, and show examples or

11
 steps explicitly. Offer help on various topics (concepts, procedures, commands, etc.).
8. Designing Dialogues:
• Map out the user-system "conversation."
• Dialogue Diagramming: Uses boxes (Top=ID, Middle=Name/Description, Bottom=Links
to next displays) and lines (showing sequence, selection/branching, iteration/loops) to model
the flow.
• Guidelines: Be Consistent; provide Shortcuts for experts; give Feedback; provide Closure
(clear end points); handle Errors gracefully; allow Reversal (undo); give user Control; make
it Easy to use.
9. GUI and Web Design:
• GUI: Understand platform standards and available controls (buttons, checkboxes, etc.). Be
an expert user of the target environment.
• Web: Challenges include browser limitations, lack of standards, basic "click-to-act" model.
Use lightweight graphics, clear forms, stylesheets. Use techniques like cookie crumbs for
clear navigation in complex sites. Be aware of common web usability errors (e.g., breaking
the back button, complex URLs, orphan pages).

12
Lecture Notes: Chapter 12 - Designing Distributed and Internet
Systems
Based on: Modern Systems Analysis and Design by Valacich & George

Overall Topic
This lecture discusses the design considerations for systems that operate across multiple locations, focus-
ing on Local Area Networks (LANs), Client/Server architectures, Cloud Computing, and Internet-based
systems.

Summary
This chapter shifts focus to designing systems that aren’t confined to a single computer but are spread
out (distributed) across networks, particularly Local Area Networks (LANs) and the Internet.
It contrasts two common LAN setups: File Server architecture (where client computers do most of
the work) and Client/Server architecture (where work is split between clients and a central server).
The limitations of file servers and the advantages of client/server models, including more advanced
three-tiered structures and the role of middleware, are explained. The lecture then introduces mod-
ern trends like Virtualization and Cloud Computing, outlining its characteristics (like on-demand
service, elasticity), service models (IaaS, PaaS, SaaS), and management considerations. Service-
Oriented Architecture (SOA) and Web Services (using technologies like XML, JSON, SOAP,
REST) are presented as ways to build flexible, interoperable systems. Finally, specific design issues for
Internet systems are covered, emphasizing the importance of standards (like HTTP, HTML), site
consistency (using CSS, XSL), and effective site management to build customer trust and loyalty
(including personalization, customization, and using Content Management Systems - CMS).

Key Definitions
1. Distributed System: A system where processing, data, or user interface components are spread
across multiple locations connected by a network.
2. Local Area Network (LAN): A network connecting computers and devices within a confined
geographical area, like a building or campus.
3. File Server Architecture: A LAN setup where a central server stores files, but client computers
run the applications and request entire files from the server for processing.
4. Client/Server Architecture: A LAN setup where processing tasks are divided between client
computers (handling user interface and some application logic) and a central server (handling
database access and potentially some application logic). Only the results of requests are sent over
the network, not entire files.
5. Database Engine (Back-End): The server portion of a client/server system that manages
database storage, access, and query processing.
6. Client (Front-End): The user-facing portion of a client/server system, typically handling the
user interface and data manipulation functions.
7. Application Program Interface (API): Standardized software building blocks that allow dif-
ferent software components (like client applications and database servers) to communicate and
exchange data.
8. Three-Tiered Client/Server Architecture: An advanced client/server model separating the
system into three logical layers: Data Management (database), Data Analysis (business logic/application
server), and Data Presentation (user interface).
9. Middleware: Software and hardware that connect the different tiers (presentation, analysis, data
management) in a three-tiered architecture, enabling them to work together.
10. Virtualization: Creating virtual (software-based) versions of computing resources like hardware,
operating systems, or networks, allowing for more efficient resource sharing.
11. Virtual Machine (VM): A software emulation of a complete computer system (hardware and
OS).
12. Cloud Computing: Delivering applications and computing resources (processing, storage, net-
working) over the Internet on a pay-per-use or subscription basis, without requiring customers to

13
 own the underlying infrastructure.
13. Information Systems Infrastructure: The collective hardware, software, data, facilities, human
resources, and services supporting an organization’s operations and strategy.
14. Cloud Service Models:
• Infrastructure as a Service (IaaS): Provides basic computing infrastructure (servers, stor-
age, networks) over the cloud.
• Platform as a Service (PaaS): Provides infrastructure plus operating systems and tools,
allowing customers to deploy their own applications.
• Software as a Service (SaaS): Provides complete applications over the cloud (e.g., Google
Docs, Salesforce).
15. Service-Oriented Architecture (SOA): A software design approach where business processes
are broken down into reusable, independent components called "services" that can be combined to
build applications. Principles include Reusability, Interoperability, Componentization.
16. Web Service: A method for communication between electronic devices over a network, often used
to implement SOA. Enables different applications to interact regardless of programming language
or platform.
17. eXtensible Markup Language (XML): A text-based language using custom tags to structure
and transmit data, readable by both humans and machines.
18. JavaScript Object Notation (JSON): A lightweight, text-based data interchange format, often
used with web services, known for being easy for humans to read and computers to parse.
19. Simple Object Access Protocol (SOAP): A protocol (often using XML) for exchanging struc-
tured information in web services. Can be complex.
20. Representational State Transfer (REST): A simpler, often faster architectural style/protocol
(often using JSON) for web service communication.
21. Hypertext Transfer Protocol (HTTP): The fundamental communication protocol for the
World Wide Web.
22. Hypertext Markup Language (HTML): The standard language for creating the content and
structure of web pages.
23. Cascading Style Sheets (CSS): Rules defining how HTML elements should be displayed (layout,
colors, fonts), allowing separation of content from presentation for site consistency.
24. eXtensible Style Language (XSL): A language for transforming XML documents and specifying
their formatting, often used to generate HTML or other formats from XML data.
25. Personalization: Tailoring web content to individual users based on known information about
them (e.g., past purchases, preferences).
26. Customization: Allowing users to change the look or content of a website according to their
preferences.
27. Content Management System (CMS): Software used to create, manage, organize, and publish
content (text, images, etc.) on a website, often separating content from design templates.

Basic Concepts
1. Distributed vs. Single-Location Systems:
• Designing distributed systems is more complex due to multiple locations, reliance on networks,
and increased potential points of failure.
• Key concerns: Reliability (works correctly), Availability (is accessible when needed), Surviv-
ability (can withstand failures), Performance (responds quickly).
2. LAN Architectures:
• File Server:
– Clients do most processing (need powerful machines, full DBMS).
– Server simply stores shared files.
– Limitations: High network traffic (entire files moved), complex security/concurrency con-
trol (managed by clients).
• Client/Server:
– Processing load is split. Server handles database tasks, clients handle UI.
– Advantages: Reduced network traffic (only requests/results moved), centralized data con-
trol, leverages cheaper client hardware, facilitates GUIs, supports open systems.

14
3. Advanced Client/Server (Three-Tiered):
• Separates Presentation (UI), Analysis (Business Logic), and Data Management tiers.
• Allows tiers to be managed and scaled independently.
• Middleware is crucial for connecting these tiers.
• Promotes flexibility and maintainability (changes in one tier have less impact on others).
• Thin Clients rely heavily on the server for processing/storage, simplifying client manage-
ment.
4. Cloud Computing:
• Shifts IT infrastructure from owned assets to rented services delivered over the Internet.
• Characteristics: On-Demand Self-Service, Rapid Elasticity (scale up/down quickly), Broad
Network Access, Resource Pooling (shared infrastructure), Measured Service (pay for what
you use).
• Service Models: IaaS (basic building blocks), PaaS (platform to build/run apps), SaaS
(ready-to-use apps).
• Deployment: Public Cloud (shared infrastructure) vs. Private Cloud (dedicated infrastruc-
ture).
• Management Issues: Availability/Reliability, Scalability, Provider Viability, Security/Privacy/Compliance,
Offerings diversity, Openness (interoperability), Cost comparison.
5. Service-Oriented Architecture (SOA) & Web Services:
• SOA breaks applications into reusable "services".
• Web Services are the technology often used to implement SOA, enabling communication be-
tween services over networks.
• Key technologies: XML/JSON (data format), SOAP/REST (communication protocols).
• Promotes flexibility, reusability, and interoperability between different systems.
6. Designing Internet Systems:
• Leverages established standards (HTTP, HTML, IP) simplifying some aspects compared to
proprietary client/server systems.
• Key Design Issues:
– Adhering to standards.
– Separating content from presentation (using CSS, XSL) for consistency and easier updates.
– Planning for future evolution.
– Ensuring Site Consistency (look-and-feel, navigation, terminology) using tools like CSS.
Clear link descriptions are vital.
– Site Management:
∗ Building Customer Loyalty/Trust (Design Quality, Disclosure, Current Content, Links).
∗ Personalization and Customization.
∗ Managing Content (old pages may need to persist due to bookmarks/links).
∗ Balancing Security vs. Ease of Use (e.g., password handling, cookies).
∗ Using a CMS to streamline content collection, organization, and publishing.

15
Lecture Notes: Chapter 13 - System Implementation
Based on: Modern Systems Analysis and Design by Valacich & George

Overall Topic
This lecture covers the System Implementation phase of the Systems Development Life Cycle (SDLC),
focusing on coding, testing, installation, documentation, training, and support.

Summary
This chapter focuses on System Implementation, the phase where the system specifications created
during design are transformed into a working system. It covers the six main activities: Coding (writing
the software), Testing (finding errors), Installation (deploying the system), Documentation (creating
manuals and guides), Training (teaching users), and Support (providing ongoing help). The lecture
details various testing types (like unit, integration, system, alpha, beta testing) and strategies (static
vs. dynamic, manual vs. automated). It explains four main installation strategies (Direct, Parallel,
Single-location, Phased) used to switch from the old system to the new one. The importance of com-
prehensive documentation for both maintainers and users is highlighted, along with different methods
for user training and providing ongoing user support, often via a Help Desk. Finally, the chapter
discusses common reasons why implementation might fail and emphasizes the growing importance of
system security.

Key Definitions
1. System Implementation: The fourth phase of the SDLC, where the physical system specifica-
tions are converted into working software, documented, and users are trained and supported.
2. Coding: The process of translating physical design specifications into working computer code.
3. Testing: The process of executing software or examining code to find errors and ensure it meets
requirements.
4. Installation (Deployment): The organizational process of changing over from the current in-
formation system to a new one.
5. Documentation: Written or visual information describing the system’s design, functionality,
internal workings (System Documentation), and how to use it (User Documentation).
6. Training: The process of providing users with the knowledge and skills needed to use the new
system effectively.
7. Support: Providing ongoing educational and problem-solving assistance to users.
8. Test Plan: A document outlining the scope, approach, resources, and schedule of intended testing
activities.
9. Test Case: A specific scenario of transactions, queries, or navigation paths used to test the system,
covering typical, critical, or abnormal usage.
10. Static Testing: Testing that examines code or documentation without executing the program
(e.g., inspections, walkthroughs, desk checking).
11. Dynamic Testing: Testing that involves executing the program code with test data.
12. Manual Testing: Testing performed by humans.
13. Automated Testing: Testing performed using specialized software tools.
14. Inspection: A formal code review by participants looking for predictable, language-specific errors.
15. Walkthrough: A peer group review of any SDLC product (design, code, documentation) to find
errors or improvements.
16. Desk Checking: Manually simulating the execution of program code step-by-step.
17. Unit Testing: Testing individual modules or components in isolation.
18. Integration Testing: Testing the combination of modules to ensure they work together correctly.
19. System Testing: Testing the entire integrated system (all programs) to verify it meets require-
ments.
20. Stub Testing: Using placeholder code (stubs) to simulate subordinate modules during top-down
integration testing.
21. Refactoring: Restructuring existing computer code without changing its external behavior, often
to improve simplicity or maintainability after adding new features (common in XP).

16
 22. Acceptance Testing: Testing performed by actual users to determine if the system meets their
needs and is acceptable for deployment.
• Alpha Testing: User testing with simulated data in a controlled environment.
• Beta Testing: User testing with real data in the actual user environment.
23. Installation Strategies:
• Direct Installation (Big Bang): Turn off the old system, turn on the new one. Risky but
can be fast/cheap if it works.
• Parallel Installation: Run both old and new systems simultaneously for a period. Safe but
expensive and potentially confusing.
• Single-Location Installation (Pilot): Implement the new system in one site/department
first. Limits risk, experience gained informs wider rollout.
• Phased Installation: Implement the new system in stages or modules. Spreads risk and
training load over time.
24. System Documentation: Detailed technical information for system maintainers.
25. User Documentation: Guides and manuals explaining how to use the system for end-users.
26. Help Desk: A single point of contact for users seeking assistance with an information system.
27. Malware: Malicious software designed to harm or disrupt systems (e.g., viruses, worms, Trojan
horses).

Basic Concepts
1. Implementation Phase Overview:
• Follows the Design phase.
• Goal: Convert specifications into a working, reliable, documented, and supported system.
• Key Activities: Coding, Testing, Installation, Documentation, Training, Support.
2. Software Application Testing:
• Planning: Essential. Master test plan created in Analysis; unit, integration, system plans in
Design.
• Purpose: Confirm system meets requirements and find errors.
• Types:
– Static vs. Dynamic: Examining code vs. running code.
– Manual vs. Automated: People vs. tools.
– Levels: Unit (modules) → Integration (combined modules) → System (all programs) →
Acceptance (user validation).
• Acceptance Testing: Critical final check by users. Alpha (simulated data) and Beta (real
data/environment) testing. Specific alpha tests include Recovery, Security, Stress, and Per-
formance testing.
• Test Cases: Define specific scenarios (typical, critical, abnormal) to test. Document test
cases and results thoroughly for repeatability.
• Testing Harness: Automated tools to assist in testing.
• Refactoring: Improving code structure after adding functionality, often paired with testing
in agile methods like XP.
3. Installation:
• The process of switching from the old system to the new.
• Strategies:
– Direct: Abrupt switch-off/switch-on. High risk, low cost.
– Parallel: Run both systems together. Low risk, high cost.
– Single-Location (Pilot): Implement fully at one site first. Medium risk/cost, allows learn-
ing.
– Phased: Implement system piece by piece. Spreads risk/cost/effort.
• Planning Considerations: Data conversion (extracting, cleaning, loading data from old to
new), error correction, system shutdown timing, impact on business cycles.
4. Documentation:
• Two Audiences: System maintainers (need technical details) and end-users (need opera-

17
 tional instructions).
• System Documentation: Internal workings, design specs, functionality.
• User Documentation: How the system works, how to use it (e.g., User’s Guide, tutorials).
Often overlooked but crucial.
5. Training and Support:
• Training: Essential for users to adopt and use the system effectively. Can cover system
specifics, general computer skills, etc. Methods include resident experts, classroom training,
e-learning, blended learning, built-in help, vendor training.
• Support: Ongoing assistance post-implementation. Can be costly. Often handled by a
Help Desk requiring both technical and people skills. Automated support (online forums,
knowledge bases) is common. Analyst may be involved in various support tasks (handling
questions, backup/recovery planning, PC maintenance, newsletters, user groups).
6. Implementation Success & Failure:
• Common Failure Reasons: Lack of management support, insufficient user involvement are
key, but also crucial are commitment (to project and change) and thorough planning.
• Factors Influencing Use: User’s personal stake, system characteristics (usability, reliabil-
ity), user demographics, organizational support, system performance, user satisfaction.
7. Security Issues:
• A critical aspect of implementation and ongoing operation.
• Threats: Malware, physical theft, system penetration, denial of service attacks.
• Often, the user is the weakest link (e.g., weak passwords, clicking malicious links). Security
awareness and training are vital.

18
Lecture Notes: Chapter 14 - Maintaining Information Systems
Based on: Modern Systems Analysis and Design by Valacich & George

Overall Topic
This lecture covers the final and often longest phase of the Systems Development Life Cycle (SDLC):
System Maintenance. It discusses the types of maintenance, costs, management challenges, and tools
used.

Summary
This chapter explores System Maintenance, the process of modifying an information system after
its initial installation to correct faults, improve performance, adapt to a changed environment, or add
features. It’s often the longest and most expensive phase of the SDLC. The lecture identifies four types of
maintenance: Corrective (fixing bugs), Adaptive (adapting to new needs/tech), Perfective (adding
features/improving performance), and Preventive (avoiding future problems). It discusses factors af-
fecting the cost of maintenance, emphasizing the importance of system maintainability. Managing
maintenance involves organizing personnel (separate, combined, or functional structures), measuring
effectiveness (e.g., using Mean Time Between Failures - MTBF), controlling and prioritizing main-
tenance requests, and using Configuration Management to ensure only authorized changes are made.
The role of automated tools, including reverse engineering and reengineering, in aiding maintenance
is also covered, along with special considerations for maintaining web sites.

Key Definitions
1. Maintenance: Changes made to an information system after its initial installation to fix problems
or enhance its functionality.
2. Corrective Maintenance: Changes made to repair flaws (bugs) in design, coding, or implemen-
tation.
3. Adaptive Maintenance: Changes made to evolve the system’s functionality to meet changing
business needs or adapt to new technologies or regulations.
4. Perfective Maintenance: Changes made to add new features, enhance existing features, or
improve system performance (e.g., making it faster).
5. Preventive Maintenance: Changes made to avoid possible future problems (e.g., restructuring
code to make it easier to understand and modify later).
6. Maintainability: The ease with which software can be understood, corrected, adapted, and
enhanced. A key factor in maintenance cost.
7. Mean Time Between Failures (MTBF): A measure of system reliability, calculated as the
average time elapsed between system failures. Higher MTBF indicates better quality.
8. Configuration Management: The process of ensuring that only authorized changes are made
to a system and its components, tracking different versions and builds.
9. Baseline Modules: Software modules that have been tested, documented, and approved for
inclusion in a specific version of the system.
10. System Librarian: A person (or role) responsible for controlling the check-out and check-in of
baseline modules during development or maintenance.
11. Build Routines: Documented instructions or automated scripts used to compile and link baseline
source code modules to create an executable system.
12. Revision Control: A configuration management technique where each version of a module is
tracked, often "frozen" (unchangeable) once approved.
13. Source Code Control: A system (often tool-based) allowing programmers to check out, lock
(preventing simultaneous changes), and modify specific system modules, tracking changes.
14. Reverse Engineering: Using automated tools to analyze existing source code and generate rep-
resentations of design-level information (e.g., structure charts, data models) to aid understanding.
15. Reengineering: Using automated tools to analyze existing source code and then alter it (auto-
matically or interactively) to improve its quality (e.g., structure, documentation) or performance.

19
Basic Concepts
1. The Maintenance Process:
• Essentially involves repeating SDLC steps (analysis, design, implementation, testing) for re-
quested changes.
• Often the longest and most costly phase (consuming 60-80% of IS budgets).
• Major Activities: Obtaining requests → Transforming requests into change specifications →
Designing changes → Implementing changes.
2. Types of Maintenance:
• Corrective: Fixing bugs found after release. Reactive. Often seen as non-value-adding by
management but necessary. (Largest slice in older studies).
• Adaptive: Responding to external changes (business rules, government regulations, new
hardware/OS). Necessary for system survival.
• Perfective: Enhancing the system based on user requests (new features, better reports,
improved usability, faster performance). Can add value.
• Preventive: Proactive changes to improve maintainability or reliability and prevent future
issues.
• The proportion of effort spent on each type varies, but adaptive and perfective often represent
significant ongoing work.
3. Cost of Maintenance & Maintainability:
• High costs due to staff time and system complexity.
• Maintainability is key to controlling costs. Factors influencing it:
– Latent Defects: More hidden bugs mean more corrective maintenance.
– Number of Customers: More users lead to more (and potentially conflicting) requests.
– Documentation Quality: Poor documentation makes understanding and changing the
system very difficult.
– Personnel: Skilled programmers are needed. High turnover increases costs.
– Tools: Good automated tools can significantly help.
– Program Structure: Well-structured, modular code is easier to maintain.
4. Managing Maintenance Personnel:
• Organizational Structures:
– Separate: Maintenance team distinct from development. Pros: Better documentation/quality
focus. Cons: Maintenance team might lack deep system knowledge.
– Combined: Developers also maintain the systems they built. Pros: Deep knowledge.
Cons: Less focus on documentation, might prefer new development.
– Functional: Maintenance staff reside within business units. Pros: High user understand-
ing, vested interest. Cons: Limited technical resources/job mobility.
5. Measuring Maintenance Effectiveness:
• Track metrics like: Number of failures, Time between failures (MTBF), Type of failures.
• MTBF is a key indicator – ideally, it should increase over time as the system stabilizes after
initial bugs are fixed.
6. Controlling Maintenance Requests:
• A formal process is needed to handle potentially frequent requests.
• Requests are evaluated (feasibility) and prioritized based on type and urgency (e.g., corrective
often higher priority than perfective).
• A system priority board or similar group often makes final decisions.
7. Configuration Management:
• Essential for controlling changes in complex systems.
• Ensures only authorized changes are made.
• Uses baseline modules as the official, approved versions.
• Requires roles like system librarian and processes like build routines.
• Tools often provide revision control (version tracking) and source code control (check-
out/check-in/locking).
8. Role of Automated Tools (CASE/Design Recovery):

20
 • Traditional maintenance often focused on code changes first, documentation later (if at all).
• Modern tools facilitate a design-focused approach:
– Reverse Engineering: Understand existing code by generating design diagrams.
– Reengineering: Analyze and automatically restructure code for improvement.
• Allows changes to be made at the design level, code regenerated, and documentation kept
more current.
9. Web Site Maintenance:
• Special Challenges: Need for 24/7 availability makes taking sites offline difficult (locking
pages or using timestamps is an alternative).
• Specific Tasks: Regularly check for broken links, validate HTML code, re-register with search
engines if content changes significantly, plan for future editions and maintain consistency.

21