You are on page 1of 21

Chapter – 6 (Design)

 Good Systems Analyst Characteristics:


1. Impertinence—question everything
2. Impartiality—consider all issues to find the best organizational solution
3. Relax constraints—assume anything is possible
4. Attention to details—every fact must fit
5. Reframing—challenge yourself to new ways
 Deliverables for Requirements Determination:
→ From interviews and observations-
interview transcripts, observation notes, meeting minutes

→ From existing written documents -


mission and strategy statements, business forms, procedure manuals, job
descriptions, training manuals, system documentation, flowcharts

→ From computerized sources -


Joint Application Design session results, CASE repositories, reports from existing
systems, displays and reports from system prototype
 Traditional Methods for Determining Requirements
1. Interviewing individuals
2. Interviewing groups
3. Observing workers
4. Studying business documents

 Guidelines for Effective Interviewing


1. Plan the interview -
Prepare interviewee: appointment, priming questions.
Prepare - agenda, checklist, questions.
1. Listen carefully and take notes (tape record if permitted).
2. Review notes within 48 hours.
3. Be neutral.
4. Seek diverse views (বিবিন্ন মতামত অনুসন্ধান )
 Choosing Interview Questions
→ Open-ended questions: questions that have no pre-specified answers
→ Closed-ended questions: questions that have to be chosen from within a set of a
particular answers.

 Interviewing Guidelines
1. Don’t include phrases to question in a way that implies a right or wrong answer.
2. Listen very carefully.
3. Type interview notes within 48 hours after the interview.
4. Don’t set expectations about the new system unless you know these will be
deliverables.
5. Seek a variety of perspectives from the interviews.

 Drawbacks to individual interviews:


1. Contradictions and inconsistencies between interviewees
2. Follow-up discussions are time consuming
3. New interviews may arrive new questions that require additional interviews with
those interviewed earlier

 Interviewing several key people together (Group interview)


a. Advantages
i. More effective use of time
ii. Can hear agreements and disagreements at once
iii. Opportunity for adjustments
b. Disadvantages
i. More difficult to schedule than individual interviews
 What is the NGT (Nominal Group Technique) ?
A facilitated process that supports idea generation by groups
→ Process:
Members come together as a group, but initially work separately.
Each person writes ideas.
Facilitator reads ideas out loud, and they are written on a blackboard or flipchart.
Group openly discusses the ideas for clarification.
Finally, Ideas are prioritized, combined, selected, reduced.
NGT used to complement of group meetings or as part of JAD effort

 Potential Problems with Procedure Documents:


1. May involve duplication of effort
2. May have missing procedures
3. May be out of date
4. May contradict information obtained through interviews
 Formal Systems: the official way where a system works as described in organizational
documentation (i.e. work procedure)
 Informal Systems: the way a system actually works (i.e. interviews, observations)
Observation vs. Document Analysis

Characteristic Observation Document Analysis


Information Richness High (many channels) Low (passive) and old
Time Required Can be extensive Low to moderate
Expense Can be high Low to moderate
Chance to follow up and Good : probing and Limited : probing is possible
probing clarification questions can be if only if original author is
ask during observation or available.
after observation
Confidentiality Observee is known to Depends of nature of
interviewer. May change documents, does not change
behavior when observe simply by reading.
Contemporary Methods for Determining System Requirements:
 Joint Application Design (JAD) [important]
JAD is a methodology of application development in which the client or end user and
the whole developer team are in continuous contact with each other and the
development process has a crucial involvement of the end user in it.
 Brings together key users, managers, and systems analysts
 Purpose: collect system requirements simultaneously from key people
 Intensive group-oriented requirements determination technique
 Team members meet in isolation for an extended period of time
 Highly focused
 Resource intensive
 Started by IBM in 1970s

 JAD Participants:
1. Session Leader: organizes and runs JAD session
2. Users: active, speaking participants
3. Managers: active, speaking participants
4. Sponsor: high-level champion, limited participation
5. Systems Analysts: should mostly listen
6. Writer/Scribe: record session activities
7. IS Staff: should mostly listen

 CASE tools [definition]


A computer-aided software engineering (CASE) tool is a software packages that provides
support for the design and implementation of information systems.
 CASE Tools During JAD
1. Diagramming and form-building CASE tools are used
2. Enables analysts to enter system models directly into CASE during the JAD session
3. Screen designs and prototyping can be done during JAD and shown to users

 System prototypes [definition]


In software development, a system prototype is a rudimentary (preliminary) working
model of a product or information system.
 Using Prototyping During Requirements Determination
→ Prototyping – an iterative process of systems development in which requirements
are converted to a working system model that is continually revised through close
collaboration between an analyst and users.
→ Quickly converts requirements to working version of system
→ Once the user sees requirements converted to system, will ask for modifications
or will generate additional requests
Lecture-7 (Design)
Database Design *
Database design occurs in two steps.

Logical Model - This stage is primarily concerned with developing a model based on the
proposed requirements. The entire model is designed on paper without any implementation
or adopting DBMS considerations.

Physical Model - The physical model is concerned with the practices and implementations of
the logical model.

A logical database model can be designed using the following approach:


1. Specify all the entities with primary keys.
2. Specify concurrent relationships between different entities.
3. Figure out each entity attributes
4. Resolve many-to-many relationships.
5. Carry out the process of normalization.

While designing a physical data model, the following points should be taken into
consideration:
1. Convert the entities into tables.
2. Convert the data attributes into columns.
3. Convert the defined relationships into foreign keys.
4. Modify the data model constraints based on physical requirements.
The Process of Database Design (Cont.)
Four key steps in logical database modeling and design *:
1. Develop a logical data model for each known user interface for the application using
normalization principles.
2. Combine normalized data requirements from all user interfaces into one consolidated
logical database model (view integration).
3. Translate the conceptual E-R data model for the application into normalized data
requirements.
4. Compare the consolidated logical database design with the translated E-R model and
produce one final logical database model for the application.
Deliverables and Outcomes
Logical database design
Must account for every data element on a system (input or output)
■ Normalized relations are the primary deliverable.
Physical database design
Converts relations into database tables
■ Programmers and database analysts do code the definitions of the database.
■ Written in Structured Query Language (SQL)

Relational Database Model


1. Relational database model: data represented as a set of related tables or relations
2. Relation: a named, two-dimensional table of data; each relation consists of a set of
named columns and an arbitrary number of unnamed rows

Well-Structured Relation and Primary Keys


■ Well-Structured Relation (or table)
A relation that contains a minimum amount of redundancy
Allows users to insert, modify, and delete the rows without errors or
inconsistencies
■ Primary Key
An attribute whose value is unique across all occurrences of a relation
An attribute of a relation, whose value identify a record uniquely
■ Foreign Key:
A foreign key is a column or group of columns in a relational database table that
provides a link between data in two tables
■ All relations have a primary key.
This is how rows are ensured to be unique.
A primary key may involve a single attribute or be composed of multiple
attributes.
Normalization and Rules of Normalization
■ Normalization:
The process of converting complex data structures into simple, stable data structures
The result of normalization is that every nonprimary key attribute depends upon the whole
primary key.
■ First Normal Form (1NF) *
◻ Unique rows, no multivalued attributes
◻ All relations are in 1NF
■ Second Normal Form (2NF) *
◻ Each nonprimary key attribute is identified by the whole primary key (called full
functional dependency)
◻ No Partial dependency
■ Third Normal Form (3NF)
◻ Nonprimary key attributes do not depend on each other (i.e. no transitive
dependencies)

Functional Dependency:
A particular relationship between two attributes
◻ For a given relation, attribute B is functionally dependent on attribute A if, for every
valid value of A is uniquely determines the value of B.
◻ The functional dependence of B on A is represented by A→B.
◻ Functional dependency is not a mathematical dependency.

Second Normal Form (2NF)


■ A relation is in second normal form (2NF) if any of the following conditions apply:
◻ The primary key consists of only one attribute.
◻ No Partial dependency exist in the relation.
◻ Every nonprimary key attribute is functionally dependent on the full set of
primary key attributes. Means must be 1NF
◻ To convert a relation into 2NF, decompose the relation into new relations using
the attributes, called determinants, that determine other attributes.
◻ The determinants are the primary keys of the new relations.

Binary 1:N and 1:1Relationships *


■ Binary 1:N Relationship represents when you are creating a relationship between two
entities where there are multiple records from one entity associated with a single
record from another entity.
■ Binary 1:N Relationship is represented by adding the primary key of the entity that on
the one side of the relationship as a foreign key in the another relation that is on the
many side of the relationship.
■ Binary or Unary 1:1 Relationship is represented by any of the following choices:
◻ Add the primary key of A as a foreign key of B.
◻ Add the primary key of B as a foreign key of A.
◻ Both of the above
Unary Relationships *
■ Unary 1:N Relationship
Foreign key is added to the relation that references the primary key values of that
same relation.
■ Recursive foreign key: a foreign key in a relation that references the primary key
values of that same relation

Selecting a data type balances four objectives * :


1. Minimize storage space.
2. Represent all possible values of the field.
3. Improve data integrity of the field.
4. Support all data manipulations desired on the field.

Designing Physical Tables *


■ Physical Table: a named set of rows and columns that specifies the fields in each row
of the table
■ Denormalization: the process of splitting or combining normalized relations into
physical tables based on affinity of use of rows and fields.
■ Partitioning: splitting a table into different physical files, perhaps stored on different
disks or computers.

Three types of table partitioning:


1. Range partitioning: partitions are defined by non-overlapping ranges of values for a
specified attribute
2. Hash partitioning: a table row is assigned to a partition by an algorithm and then maps
the specified attribute value to a partition
3. Composite partitioning: combines range and hash partitioning by first segregating data
by ranges on the designated attribute, and then within each of these partitions
Chapter – 8 (Design)
 Form:
A business document that contains some predefined data and may include some areas
where additional data are to be filled in.
An instance of a form is typically based on one database record.
 Report:
A business document that contains only predefined data
It is a passive document used only for reading or viewing data.
A report typically contains data from many unrelated records or transactions

 The Process of Designing Forms and Reports:


It is a user-focused activity.
Follows a prototyping approach.
First steps are to gain an understanding of the who is the users and what is task
objectives by collecting initial requirements during requirements determination.
Making Wireframe
A simple design to show the placement of information elements on a screen.

A coding sheet is an “old” tool for designing forms and reports, usually associated with
text-based forms and reports for mainframe applications.
Visual Basic and other development tools provide computer-aided GUI form and report
generation.

 Requirements determination:
1. Who will use the form or report?
2. What is the purpose of the form or report?
3. When is the report needed or used?
4. Where does the form or report need to be delivered and used?
5. How many people need to use or view the form or report?
 Prototyping
1. Initial prototype is designed from requirements.
2. Users review prototype design and either accept the design or request
changes.
3. If changes are requested, the construction-evaluation-refinement cycle is
repeated until the design is accepted.

 Formatting Forms and Reports


General Guidelines -
1. Meaningful titles — use clear & specific - title, version information, and
current date
2. Meaningful information — include only necessary information, with no need
to modify
3. Balanced layout — use enough spacing, margins, and clear labels
4. Easy navigation system — show how to move forward and backward, and
where you are currently

Chapter – 9 (Implementation)
 Six major activities:
1. Coding
2. Testing
3. Installation
4. Documentation
5. Training
6. Support

 The Process of Coding, Testing, and Installation –

Coding
Physical design specifications are turned into working computer code.
Testing
Tests are performed using various strategies.
Testing is performed in parallel with coding.
Installation
The current system is replaced by a new system.

 Seven Different Types of Tests (Summary) -

Static or dynamic techniques


Static testing means that the code being tested is not executed.
Dynamic testing involves execution of the code.
Test is automated or manual
Automated means computer conducts the test.
Manual means that people complete the test.
 Seven Different Types of Tests -
1. Inspection: a testing technique where participants examine program code for
predictable language-specific errors
2. Walkthrough: a peer group review of any product created during the systems
development process, including code.
3. Desk checking: a testing technique where the program code is sequentially executed
manually by the reviewer
4. Unit testing: each module is tested alone in an attempt to discover any errors in its
code
5. Integration testing: the process of bringing together all of the modules that a
program integrated for testing purposes -
Modules are typically integrated in a top-down incremental fashion.
6. System testing: the bringing together of all of the programs that a system integrated
for testing purposes-
Programs are typically integrated in a top-down, incremental fashion.
7. Stub testing: a technique used in testing modules, especially where modules are
written and tested in a top-down fashion, where a few lines of code are used to
substitute for subordinate modules

 What is the test case ?


Test case is a specific scenario of transactions, queries or navigation paths

 Test cases represent either:


 Typical system use
 Critical system use, or
 Abnormal system use.

 Acceptance Testing by Users


the process whereby actual users test a completed information system, the end result of
which is the users’ acceptance of it.
 Alpha testing: user testing of a completed information system using simulated data
 Beta testing: user testing of a completed information system using real data in the
real user environment

 Types of Alpha Test:


1. Recovery testing — verify that recovery is properly performed in order to
forces software (or environment) to fail.
2. Security testing — verifies that protection mechanisms built into the system
will protect it from improper penetration
3. Stress testing — tries to break the system
4. Performance testing — determines how the system performs on the range of
possible environments in which it may be used
 Installation:
the organizational process of changing over from the current information system to a
new one.

 Four installation strategies:


1. Direct Installation
2. Parallel Installation
3. Single-location installation
4. Phased Installation

Direct installation: changing over from the old system to a new one by turning off the
old system when the new system is turned on. Very risky

Parallel installation: running the old information system and the new one at the same
time until management decides the old system can be turned off. Less risky system.
Single-location installation: trying out the new information system at one site and using
the experience and decide if and how the new system should be deployed throughout
the organization. Also known as location or pilot installation

Phased Installation: changing from the old information system to the new one
incrementally, starting with one or a few functional components and then gradually
extending the installation to cover the whole new system
 Types of Training Methods:
1. Resident expert/Internal Expert
2. Traditional instructor-led classroom training
3. E-learning, distance learning
4. Blended learning (instructor plus e-learning)
5. Software help components
6. External sources (e.g. vendors)

 Project Close-Down:
1. Notify all affected parties that the development project is ending and that you are
switching to operation and maintenance mode.
2. Evaluate team: Reassign members to other projects.
3. Conduct post project reviews.
4. Close out customer contract: Formal signoff

Chapter-10 (Maintenance)

 The Process of Maintaining Information Systems:


Process of returning to the beginning of the SDLC and repeating development steps
focusing on system change until the change is implemented
Maintenance is the longest phase in the SDLC.
 Four major activities:
1. Obtaining maintenance requests
2. Transforming requests into changes
3. Designing changes
4. Implementing changes
 What is the maintenance?
changes made to a system to fix or enhance its functionality

 Types of System Maintenance:


1. Corrective maintenance: changes made to a system to repair flaws in its
design, coding, or implementation
2. Adaptive maintenance: changes made to a system to evolve (enhancement)
its functionality to changing business needs or technologies
3. Perfective maintenance: changes made to a system to add new features or to
improve performance
4. Preventive maintenance: changes made to a system to avoid possible future
problems

The Cost of Maintenance:


 Factors influencing maintainability
1. Latent defects: unknown errors after installation (increases corrective maintenance).
2. No. of system customers: more customers  more (and conflicting) maintenance
requests
3. Quality of system documentation: lack of documentation makes maintenance
harder
4. Maintenance personnel: high quality programmers required for maintenance
5. Tools: automated documentation and code tools
6. Well-structured programs: good quality of code makes maintenance easier
 Managing Maintenance Personnel
 Three possible organizational structures:
1. Separate — maintenance group consists of different personnel than development
group
2. Combined — developers also maintain systems
3. Functional — maintenance personnel work within the functional business unit

Maintenance Advantages Disadvantages


Organization
Type
Separate Improved system and Ignorance of critical
documentation quality undocumented
information
Combined Maintenance group Less emphasis on good
knows all about system documentation
Functional Personnel have vested Limited job mobility and
interest human or technical
resources

You might also like