2. Module 1 – Introduction & Process Possible values and benefits of information systems:
Increased business profit
Reduced Business Cards
Costs and Benefits of the System
Increased Market Share
Improved Customer Relations
Increased Efficiency
Improved Decision Making
Better Compliance with Regulations
Fewer Mistakes
Improved Security
Greater Capacity
Role of a System Analyst
Initiate change within an organization
“Problem solver”
Skills of a System Analyst
Working knowledge of information technologies
Computer programming experience and expertise
General knowledge of business processes and terminology
General problem-solving skills
Good interpersonal communication skills
Good interpersonal relations skills
Flexibility and adaptability
Character and ethics
Technology Drivers for an Information System
Networks and the Internet
o xHTML and XML
o Scripting
o Java, Cold Fusion
o Intranets
o Extranets
o Portals
o Web Services
Mobile and Wireless Technologies
o HP iPaq
o Blackberry
o Cell Phone
o Bluetooth
Object Technologies
o C++
o Java
o Smalltalk
o Visual Basic .NET
Collaborative Technologies
Enterprise Applications
Business Drivers for an Information System
Globalization of the economy
Electronic commerce and business
Security and privacy
Collaboration and partnership
Knowledge asset management
Continuous improvement
Total quality management
Business process redesign
System Development Process
Identify the problem
Analyze and understand the problem
Identify the solution
Identify alternative solutions and choose the best course of
action
Design the chosen solution
Implement the chosen solution
Evaluate the results
Classes of Information System Applications
Transaction Processing Systems (TPS)
Management Information System (MIS)
Decision Support System (DSS)
Executive Information System (EIS)
Expert System
Communication and Collaboration System
Office Automation System
Classes of Information System Applications
System owners and System users focus on three common
goals
Improve business knowledge
Improve business processes
Improve business communications
System designers and builders focus on three common goals
Database technologies that support business accumulation
and use of knowledge
Software technologies that automate and support business
processes and services
Interface technologies that support business communications and
collaboration
Communication Improvements in Information Systems are
directed toward 2 goals
Information systems must provide effective and efficient
communication interfaces to the system’s users. These
interfaces should promote teamwork and coordination of
activities
Information systems must interface effectively and efficiently
with other information systems – both with those within the
business and increasingly with other business’s information
systems
Vocabulary
Agile Development: A systems development strategy wherein the
system developers are given the flexibility to select from a variety
of appropriate tools and techniques to best accomplish the tasks
at hand. Strike an optimal balance between productivity and
quality for systems development
B2B: Business to business electronic commerce is the real future.
This is the most complex form of electronic commerce and could
ultimately evolve into electronic business, the complete,
paperless, and digital processing of all business transactions that
occur within and between businesses
B2C: Business to consumer electronic commerce attempts to offer
new, web-based channels of distribution for traditional products
and services. Example amazon.com
Business Process: Tasks that respond to business events.
Business processes are the work, procedures, and rules required
to complete the business tasks independent of any information
technology used to automate or support them
Business Process Redesign: The study, analysis, and redesign of
fundamental business processes to reduce costs and improve
value added to the business
Continuous Process Improvement (CPI): The continuous
monitoring of business processes to effect small but measurable
improvements in cost reduction and value added
Customer Relationship Management (CRM): A software
application that provides customers with access to a business's
processes from initial inquiry through post sale service support
Data: Raw facts about people, places, events, and things that are
of importance in an organization. Each fact is, by itself relatively
meaningless
3. Module 1 – Introduction & Process Electronic Business: The user of the internet to conduct and
support day to day business activities
Electronic Commerce: The buying and selling of goods and
services by using the internet
Enterprise Application Integration (EAI): The process and
technologies used to link applications to support the flow of data
and information between those applications. EAI solutions are
based on middleware
Enterprise Resource Planning (ERP): A software application that
fully integrates information systems that span most or all of the
basic, core business functions(including transaction processing
and management information for those business functions)
Information: Data that has been processed or reorganized into a
more meaningful form for someone. Information is formed from
combinations of data that hopefully have meaning to the recipient
Information System: An arrangement of people, data, processes,
and information technology that interact to collect, process, store,
and provide as output the information needed to support an
organization
Information System - Communications and Collaboration System:
An information system that enables more effective communication
between workers, partners, customers, and suppliers to enhance
their ability to collaborate
Information System - Decision Support System: An information
system that either helps to identify decision making opportunities
or provides information to help make decisions
Information System - Execute Information System: An information
system that support the planning and assessment needs of
executive managers
Information System - Expert System: An information system that
captures the expertise of workers and then simulates that
expertise to the benefit of non-experts
Information System - Management Information System: An
information system that provides for management-oriented
reporting based on transaction processing and operations of the
organization
Information System - Office Automation System: An information
system that supports the wide range of business office activities
that provide for improved work flow between workers
Information System - Transaction Processing System: An
Information system that captures and processes data about
business transactions
Information Worker: Any person whose job involves creating,
collecting, processing, distributing, and using information
Knowledge: Data and information that are further refined based
on the facts, truths, beliefs, judgments, experiences, and expertise
of the recipient. Ideally information leads to wisdom.
Middleware: Software (usually purchased) used to translate and
route data between different applications
Mobile User: A user whose location is constantly changing but
who requires access to information systems from any location
Object Technology: A software technology that defines a system
in terms of objects that consolidate data and behavior. Objects
become reusable and extensible components for the software
developers
Object-Orientated Analysis and Design: A collection of tools and
techniques for systems development that will utilize object
technologies to construct a system and its software
Process Management: The ongoing activity that defines,
improves, and coordinates the use of an organizations chosen
methodology and standards for all system development projects
Project Management: The activity of defining, planning, directing,
monitoring, and controlling a project to develop an acceptable
system within the allotted time and budget
Remote Users: A user who is not physically located on the
premises but who still requires access to information systems
Stakeholders: Any person who has an interest in existing or
proposed information system. Stakeholders may include both
technical and non-technical workers as well as internal and
external workers
Stakeholders - External Service Providers A systems analyst,
system designer, or system builder who sells his or her expertise
and experience to other businesses to help those businesses
purchase, develop, or integrate their information systems
solutions; may be affiliated with a consulting or services
organization
Stakeholders - Project Manager An experienced professional who
accepts responsibility for planning, monitoring, and controlling
projects with respect to schedule, budget, deliverables, customer
satisfaction, technical standards, and system quality
Stakeholders - Systems Analyst A specialist who studies the
problems and needs of an organization to determine how people,
data, processes, and information technology can best accomplish
improvements for the business
Stakeholders - Systems Builders - Applications Programmers
Specialists who convert business requirements and statements of
problems and procedures into computer languages. They
develop and test computer programs to capture and store data
and to locate and retrieve data for computer applications
Stakeholders - Systems Builders - Database Programmers
Specialists in database languages and technology who build,
modify, and test database structures and the programs that use
and maintain them
Stakeholders - Systems Builders - Network Administrators
Specialists who design, install, troubleshoot, and optimize
computer networks
Stakeholders - Systems Builders - Security Administrators
Specialists who design, implement, troubleshoot, and manage
security and privacy controls in a network
Stakeholders - Systems Builders - Software Integrators
Specialists who integrate software packages with hardware,
networks, and other software packages
Stakeholders - Systems Builders - Systems Programmers
Specialists who develop, test, and implement operating systems
level software, utilities, and services. Increasingly, they also
develop reusable software components for use by applications
programmers
Stakeholders - Systems Builders - Webmasters Specialists who
code and maintain web servers
4. Module 1 – Introduction & Process Stakeholders - Systems Design - Technology Specialists Experts
in the application of specific technologies that will be used in a
system (e.g. a special commercial software package or specific
type of hardware)
Stakeholders - Systems Designer A technical specialist who
translates system users' business requirements and constraints
into technical solutions. She or he designs the computer
databases, inputs, outputs, screens, networks, and software that
will meet the system users' requirements
Stakeholders - Systems Designer Database Administrators,
Network Architects, Web Architects, Graphic Artists, Security
Experts, Technology Specialists
Stakeholders - Systems Designer - Database Administrator
Specialists in database technologies who design and coordinate
changes to corporate database
Stakeholders - Systems Designer - Graphic Artists Relatively new
in today’s IT worker mix, specialists in graphics technology and
methods used to design and construct compelling and easy-to-
use interfaces to systems, including interfaces to PCs, the Web,
handhelds, and smart phones
Stakeholders - Systems Designer - Network Architects Specialists
in networking and telecommunications technologies who design,
install, configure, optimize, and support local and wide area
networks, including connection to the internet and other external
networks
Stakeholders - Systems Designer - Security Experts Specialists in
the technology and methods used to ensure data and network
security and privacy
Stakeholders - Systems Designer - Web Architects Specialists
who design complex Web Sites for organizations, including public
Web sites for the Internet, internal Web sites, for organizations
and private B2B Web sites (extranet)
Stakeholders - Systems Owners An information system's sponsor
and executive advocate, usually responsible for funding the
project of developing, operating, and maintaining the information
system
Stakeholders - Systems Users A "customer" who will use or is
affected by an information system on a regular basis - capturing,
validating, entering, responding to, storing, and exchanging data
and information
Stakeholders - Systems Users Internal Systems Users - Clerical
and service workers, Technical and Professional staff,
Supervisors, middle managers, and executive managers
Stakeholders - Systems Users External Systems Users -
Customers, Suppliers, Partners, Employees "Remote Users"
Supply Chain Management (SCM): A software application that
optimizes business processes for raw material procurement
through finished product distribution by directly integrating the
logistical information systems of organizations with those of their
suppliers and distributors
System: A group of interrelated components that function
together to achieve a desired result
System Analysis: The study of a business problem domain to
recommend improvements and specify the business requirements
and priorities for the solution
System Design: The specification or construction of a technical
computer based solution for the business requirements indentified
in a system analysis
System Development: Process A set of activities, methods, best
practices, deliverables and automated tools that stakeholders use
to develop and maintain information systems and software
System Implementation: The construction, installation, testing,
and delivery of a system into production
System Initiation: The initial planning for a project to define initial
business scope, goals, schedule and budget
Systems Integration: The process of building a unified information
system out of diverse components of purchase software, custom-
built software, hardware, and networking
Total Quality Management (TQM): A comprehensive approach to
facilitating quality improvements and management within a
business
Front-Office Information System: An information system that
supports business functions that extend out to the organizations
customers
Back-Office Information System: An information system that
supports internal business operations of an organization, as well
as reaches out to suppliers
Information Systems Architecture: A unifying framework into which
various stakeholders with different perspectives can organize and
view the fundamental building blocks of information systems
Data Requirement A representation of users' data in terms of
entities, attributes, relationships, and rules.
Business Function: A group of related processes that support the
business. Functions can be decomposed into other sub functions
and eventually into processes that do specific tasks
Cross Functional Information System: A system that supports
relevant business processes from several business functions
without regard to traditional organizational boundaries such as
divisions, departments, centers, and offices
Process Requirements: A user's expectation of the processing
requirements for a business process and its information system
Policy: A set of rules that govern a business process
Procedure: step by step set of instructions and logic for
accomplishing a business process
Work Flow: The flow of transactions through business processes
to ensure appropriate checks and approvals are implemented
Software Specifications: The technical design of business
processes to be automated or supported by computer programs to
be written by system builders
Application: Program A language-based, machine-readable
representation of what a software process is supposed to do or
how a software process is supposed to accomplish its task
Prototyping: A technique for quickly building a functioning but
incomplete model of the information system using rapid
application development tools
Interface Specifications: Technical designs that document how
system users are to interact with a system and how a system
interacts with other systems
User Dialogue: A specification of how the user moves from
window to window or page to page, interacting with the application
programs to perform useful work
5. Module 2 – System Development Processes
“Consistent adherence to moderately rigorous methodology
guidelines can provide 70 percent of system development
organizations with a productivity improvement of at least 30%
within 2 years.”
CMM Framework
1.Initial: Inconsistent methods
2.Repeatable: Consistent project management
3.Defined: Consistent process used
4.Managed: Process managed and measured
5.Optimized: Continuous process improvement
A systems development methodology is the standard process to
build and maintain that system and all other information systems
through their life cycle and is consistent with the CMM by ensuring
the following:
• Consistency
• Risk reduction
• Documentation
• Resource allocation (stakeholders)
• Job rotation and proper flow
Principles for Systems Development
1.Get the System User Involved.
2.Use a problem solving approach
a. Study and understand (context / impact)
b. Define the requirements
c. Identify candidate solutions and select
d. Design/implement
e. Observe/evaluate
3.Establish Phases and Activities
4.Document: Value of documentation and the effort to produce it.
5.Establish standards:
a. Database technology
b. Software technology
c. Interface technology
6.Manage the process and projects
7.Justify information systems as capital investments
8.Don’t be afraid to cancel or revise scope: At each checkpoint,
the analyst should consider:
a. Cancel the project
b. Reevaluate and adjust
c. Reduce the scope
9.Divide and conquer: divide system into subsystems
10.Design systems for growth and change.
Framework for Classifying Problems
P – Performance
I – Information (and data)
E – Economics, controls costs, increase profits
C – Control or security
E – Efficiency
S – Service
FAST Methodology
1.Scope definition: Problem statement, constraints, baseline,
statement of work
2.Problem analysis:
3.Requirements analysis: prioritize; identify needs and priorities;
Does not specify any technical possibilities or solutions
4.Logical design: data flow diagram, “technology independent”,
RUP, IE, Structured analysis and design. Prevent analysis
paralysis.
5.Decision analysis: Transition from analysis to design. System
proposal is a key deliverable and it may produce an application
architecture. Candidate solutions have been identified and
evaluated by the following criteria:
a. Technical feasibility: practical?
b. Operational feasibility: fulfill user’s
requirements?
c. Economic feasibility: cost-effective?
d. Schedule feasibility: Acceptable time period?
e. Risk feasibility: probability for success?
6.Physical design and integration: Represents a specific technical
solution.
a. Design by specification
b. Design by prototyping
7.Construction and testing: build, test, and implement the
interfaces between the new system and existing systems.
8.installation and delivery:
System Operation and Maintenance: provide system support for
the remainder of its useful, productive life time.
Classic Phase
1.Project initiation: Scope / Problem analysis
2.System Analysis: Problem analysis/Requirements/Logical
design
3.System Design: Physical design and integration/Construction
and testing
4.System implementation: Construction and testing/Installation
and delivery
Cross life-cycle activities
Multiple phases that overlap the system development process.
• Fact-finding
• Documentation and presentation
• Feasibility analysis
• Process and project management
Alternative Strategies
Sequential vs. Iterative development: Incremental development
until all iterations are completed or a waterfall approach.
Model-driven development: Software development using pictures
• Process modeling
• Data modeling
• Object modeling
Advantages: better documentations and requirements,
easier to validate using pictures, systems can be
constructed more correctly the first time.
Disadvantages: time-consuming, models only as good
as the user’s understanding, Users become passive
participants, Rigidity is impractical and inflexible
Product-driven development: software development by writing
code.
• Prototyping
o Rapid Application Development (RAD)
Advantages: encourages active user and
management participation, higher visibility due
to user participation, errors detected in
advance, testing and training becomes a
natural process
Disadvantages: Increase costs to maintain
and repair, problem analysis tends to be
ignored, discourages other technical
alternatives, impact on quality
• Writing code (extreme programming)
6. Module 2 – System Development Processes
Commercial Application Package Implementation Strategy: This
methodology is not intended for ERP projects. This is a software
application that could be customized to meet business needs.
Commercial Off-the-shelf System (COTS)
1.Determine need in the problem analysis phase
2.Technology market research
3.Request of Proposal/Request for Quotation
4.Proposals/Quotations
5.Contract and order
6.Baseline Commercial Application software and documentation
7.Features and capabilities: Redesigned business process
8.Add-on software requirements: Gap analysis to determine
what’s missing
9.Customized commercial application: implementation
10.add-ons are constructed to meet requirements
Advantages: No extensive programming required, in-
house development is costly, vendors can improve
products, vendor assumes responsibility
Disadvantages: Depends to how successful the vendor
is, purchased solution does not reflect the ideal solution,
resistance to change process for new purchased
product
System Maintenance
1. Feedback
2. System Change Request
3. Software bugs
4. Design flaw
5. Technical requirement
6. Business requirement
7. Business problem
8. Updated or improved system
Automated Tools and Technology
1. Computer Assisted Systems Engineering (CASE):
a. CA’s Erwin
b. Oracle’s Designer 2000
c. Popkin’s System Architect
d. Rational ROSE
e. Visible Systems’ Visible Analyst
2. Application Development Environments (ADEs):
Programming languages or interpreters with powerful debugging,
interface construction tools, middleware, testing tools, version
control, help authoring tools, repository links
a. IBM’s Websphere (java)
b. Borland’s J Builder (java)
c. Cold Fusion
d. .NET
e. Oracle’s Developer
f. Sybase’s Powerbuilder
3. Process and Project Managers:
a. MS project
b. Niku’s Open Workbench and Project
Manager.
Project Management
Success
• Acceptable to the customer
• On time
• Within budget
• Minimal impact on operations
Failure:
• No management support
• No commitment to systems development methodology
• Taking shortcuts
• Scope creep, feature creep
• Premature commitment to a fixed budget
• Poor estimating techniques
• Over-optimism
• Mythical man-month: adding more personnel when it’s
not going to work.
• Inadequate management skills
• Failure to adapt to business change
• Insufficient resources
• Failure to manage the plan
Project Management Body of Knowledge
PMI was created as a professional society to guide the
development and certification of professional project managers.
Project manager competencies:
o Business achievement competencies
Business awareness
Business partner orientation
Commitment to quality
o Problem-Solving Competencies
Initiative
Information gathering
Analytical thinking
Conceptual thinking
o Influence competencies
Interpersonal awareness
Organizational awareness
Anticipation of impact
Resourceful use of influence
o People Management competencies
Motivating others
Communication skills
Developing others
Monitoring and controlling
o Self-management competencies
Self-confidence
Stress-management
Concern for credibility
Flexibility
Project Management Functions
o Scoping
o Planning
o Estimating
o Scheduling
o Organizing
o Directing
o Controlling
o Closing
Project Management Tools and Techniques (PERT and
Gantt
o PERT chart: Project Evaluation and Review
Technique is a graphical network model used to
depict the interdependencies between a project’s
tasks:
o Gantt chart: A simple horizontal bar chart that
depicts projects tasks against a calendar. Offer the
advantage of clearly showing overlapping tasks.
Project Management Software:
o Niku’s project manager
o Artemis International Solutions Corporation’s 9000
o CA’s AllFusion Process Management Suite
o Microsoft Project
o Primavera’s Project Planner and Project Manager
o C/S Solutions’ Risk+
Project Management Life Cycle
1. Activity 1: Negotiate Scope: Most important
prerequisite. Product, Quality, Time, Cost, Resources.
a. The deliverable is an agreed-on statement of
work
2. Activity 2: Identify Tasks:
a. Work Breakdown Structure (WBS) is like
breaking the project into phases. Special
tasks are called milestones.
3. Activity 3: Estimate Task Durations:
a. OD, PD, ED, D
i. Decomposition: decomposed into
manageable pieces
ii. COCOMO: Parameters from
previous projects help determine
new project estimations
iii. Function points: Measured based
on the complexity of input, output,
files, and queries.
4. Activity 4: Specify Intertask Dependencies
a. Finish to Start (FS): Finish one to start the
next one
b. Start to Start (SS): Start of one triggers the
start of another
c. Finish to Finish (FF): Two tasks must finish at
the same time
d. Start to Finish (SF): Start of one means
another finished
5. Activity 5: Assign Resources:
a. People
b. Services
c. Facilities and equipment
d. Supplies and materials
e. Money
6. Activity 6: Direct the team effort:
7. Activity 7: Monitor and Control Progress
a. Progress Reporting: Verbal or written, but
honest and accurate
b. Change management: Collection of
procedures for documenting a change
request and defines the necessary steps.
Managing the expectations of the
stakeholders
7. Module 2 – System Development Processes
c. Expectations management: Understanding
the dynamics and impact of changing the
parameters of a project.
d. Critical Path Analysis: Emphasis should be
placed on the critical path tasks, and if
necessary, resources might be temporarily
diverted from tasks with slack time to help get
critical tasks back on schedule.
8. Activity 8: Assess project results and experiences:
Contribute improvements to specific project milestones,
processes, or tasks.
Vocabulary
Systems Development Process: Activities, methods, best
practices, and automated tools that stakeholders use to develop
and improve information systems and software.
Capability Maturity Model (CMM): Framework for assessing the
maturity level of an organization’s information systems
development and management processes and products.
System development methodology: formalized approach to the
systems development process; a standardized process that
includes the activities, methods, best practices, deliverables, and
automated tools to be used for information systems development.
RAD: Architected Rapid Application Development
DSDM: Dynamic Systems Development Methodology
JAD: Joint Application Development
IE: Information Engineering
RAD: Rapid Application Development
RUP: Rational Unified Process
Structured Analysis and Design
XP: eXtreme Programming
System life cycle: build it, use it, and maintain it. Then cycle it
back to redevelopment.
Conversion: System cycles from development to operation and
maintenance
Obsolescence: System cycles from operation and maintenance to
redevelopment
FAST: Framework for the Application of Systems Thinking.
Hypothetical methodology.
Process management: Document, oversee, improve chosen
process (Methodology)
Project management: Process of scoping, planning, staffing,
directing and controlling a project to develop an information
system.
Cost-effectiveness: Balance between developing, maintaining,
and operating and the benefits
Strategic information systems plan: Building and improving an
information technology infrastructure
Strategic enterprise plan: Defines mission, vision, goals,
strategies, benchmarks, and measure of progress and
achievement.
Creeping Commitment: Feasibility and risks are continuously
reevaluated throughout a project.
Entropy: natural and inevitable decay of all systems over time.
PIECES: Framework developed by James Wetherbe
Steering Committee: Prioritizes and approves candidate system
development projects
Backlog: lower priority projects
Problem statement: Preliminary study and feasibility assessment.
Problems, opportunities, directives; may include constraints and
initial vision
Constraint: limitation
Scope creep: Expectations and requirements increase w/o regard
to cost and deadlines
Statement of work: defines vision, scope, constraint, high level
requirements, schedule, and budgets. Protect charter, plan, and
service level agreement.
System model: Words into pictures. Data flow diagrams
Analysis paralysis: excessive system modeling
Application architecture: a decision analysis step that proposes a
high level blueprint for the approved solution.
RFP: Request For System Proposal. Recommendation to
purchase the solution rather than building it.
Fact-finding: Techniques to collect information about system
problems, requirements and preferences. Information gathering
Feasibility analysis: how feasibility is assessed.
Prescriptive methodology: touch all bases; follow all the rules
Adaptive methodology: change as needed within some guidelines
Process modeling: Data flow diagrams, structure charts,
flowcharts
Data modeling: Diagrams to capture business data requirements
and translate to database design.
Object modeling: Merge data and process concerns into objects
RFQ: Request for Quotation. Formal document stating technical
and support requirements for a single vendor.
CASE: Tools that provide prototyping and code generation
CASE repository: database to store system models and other
products of system development. Data dictionary
Forward engineering: Generate code from system models
Reverse engineering: Initial system models from software or
database code.
Project: temporary sequence of unique, complex, and connected
activities that have one goal or purpose and that must be
completed by a specific time, within budget, and according to
specification.
Scope creep: unexpected growth of requirements
Feature creep: uncontrolled addition of technical features to a
system
JPP: Joint Project Planning Technique is a strategy where
stakeholders attend an intensive workshop aimed at reaching
consensus on project decisions.
Primitive task: does not consist of other tasks. Part of the work
breakdown structure (WBS)
Summary task: consist of other tasks (phases and activities)
OD: Optimistic Duration estimates the minimum amount of time to
complete a task
PD: Pessimistic duration estimates that maximum amount of time
to complete a task
ED: Expected Duration estimates amount of time to complete a
task
D: Most likely Duration estimates amount of time to complete a
task based on averages of OD, PD, and ED.
Forward Scheduling: Start date and then follow from that date
Reverse Scheduling: Establish deadline to figure out the schedule
Resource Leveling: Correcting resource overallocations
Critical path: sequences of dependent tasks w/o any slack time
which combined determine completion date
Slack time: time to delay a project between start and completion
time.
8. Module 3 –System & Requirements Analysis Requirements Discovery
Requirements discovery and management correctly identify the
knowledge, process, and communication requirements for the
users of a new system. They must meet the following criteria:
Consistent
Complete
Feasible
Required
Accurate
Traceable
Verifiable
Requirement Discovery Process
1. Problem discovery and analysis: Ishikawa diagram is a
graphical tool that helps identify 3 to 6 main categories
that encompass all possible areas of causes for a
particular problem.
2. Requirements discovery: Information gathering, data
collection, fact-finding
3. Documenting and analyzing requirements: Provide
direction for the modeling techniques the systems
analyst will use to analyze the requirements and
determine the correct requirements for the project.
a. Documenting the draft requirements:
i. Uses cases
ii. Decision tables
iii. Requirements tables
b. Analyzing requirements: Fact-finding and
requirements analysis activities are very
closely associated with each other and in fact
are often interwoven.
c. Formalizing requirements: Using
requirements definition document to formally
communicate the requirements of a proposed
system.
i. Introduction
1. Purpose
2. Background
3. Scope
4. Definitions, acronyms,
abbreviations
5. References
ii. General project description
1. Functional requirements
iii. Requirements and constraints
1. Functional requirements
2. Non functional
requirements
iv. Conclusion
1. Outstanding issues
4. Requirements management
Fact-finding Techniques
Analysts must take great care to protect the security and privacy
of any facts or data with which they have been entrusted.
1. Sampling of Existing Documentation, Forms, and Files
a. Describe a problem: suggestion box, minutes,
complaints, accounting records, IS project
requests
b. Describe a business function: Mission
statement, formal objectives, policy manuals,
manual and computerized screens and
reports
2. Research and site visits: Perform site visits with
companies that had similar problems, computer trade
journals, reference books, internet.
3. Observation of the work environment: Sometimes
analyst performs the role of the user for a short period
of time, called “living the system”.
a. Advantages:
i. Reliable
ii. Complex tasks are easier to
understand
iii. Inexpensive
iv. Work measurements
b. Disadvantages:
i. Performance may vary when being
observed
ii. Level of difficulty or volume may
vary
iii. Scheduling inconvenience
iv. Interruptions
v. False sense of proper step by step
procedures since people will
change their behavior when being
observed.
4. Questionnaires:
a. Advantages:
i. Time
ii. Inexpensive
iii. Anonymity
iv. Quick analysis
b. Disadvantages
i. Low number or respondents
ii. No guarantee about the content of
a response
iii. Inflexible
iv. No opportunity for clarification
v. Difficult to prepare
5. Interviews:
a. Advantages
i. Opportunity to allow for open
responses
ii. Allow for more feedback
iii. Adapt and reword questions
iv. Analyze non-verbal communication
b. Disadvantages:
i. Time consuming
ii. Success varies depending on skill
iii. Impractical due to location
c. How to Conduct an Interview
i. Select Interviewees
ii. Prepare interview
iii. Conduct interview
iv. Follow up on the interview
v. Listening
vi. Body language and proxemics
6. Discovery prototyping:
a. Advantages
i. Allow for experimentation
ii. Aids in determining feasibility
iii. Training mechanism
iv. Helps to build test plans
v. May minimize fact-finding
b. Disadvantages
i. Developers need training
ii. Users may develop unrealistic
expectations
iii. Increase cost and schedule
7. Joint Requirements Planning (JRP):
a. Participants: Sponsor, Facilitator,
Users/Managers, Scribe(s), IT Staff
b. Benefits:
i. Users/Managers take ownership of
the project
ii. Reduce time to develop system
iii. Prototyping benefits from JRP
Fact-finding Strategy
1. Learn from existing documents, forms, reports, and files
2. If appropriate, observe the system in action
3. Distribute questionnaires
4. Conduct interviews
5. (optional) build discovery prototypes
6. Follow up using appropriate fact-finding techniques.
9. Module 3 –System & Requirements Analysis Use-Case Modeling
Use-Case modeling has proved to be a valuable aid in meeting
the challenges of determining what a system is required to do
from a user and stakeholder perspective.
System Concepts for Use-Case Modeling
1. Use Cases: Describe the system functions from the
perspective of external users and in a manner and
terminology they understand.
2. Actors: Anything that interacts with the system
a. Primary business actor: stakeholder that
benefits from the execution of the use case.
b. Primary system actor: stakeholder that
directly interacts with the system
c. External server actor: stakeholder that
responds to a request from the use case
d. External receiver actor: stakeholder that is not
the primary actor receives something from the
use case.
3. Relationships
a. Associations: Bidirectional or unidirectional
relationships between actor and a use case
b. Extends: Relationship between extension use
case and a use case.
c. Uses (or includes): Relationship between
abstract use case and a use case.
d. Depends on: Relationship between Use-
Cases determining their sequence.
e. Inheritance: Relationships between actors. It
is best to use a common behavior and assign
it to a “abstract actor”
The Process of Requirements Use-Case
Modeling
Analyze enough requirements information to prepare a model that
communicates what is required from a user perspective but is free
of specific details about how the system will be built and
implemented.
Steps:
1. Identify Business Actors
2. Identify Business Requirements Use Cases: Captures
the interactions with the user in a manner that is free of
technology and implementation details.
3. Construct Use-Case Model Diagram
4. Document Business Requirements Use-Case
Narratives: First document at a high level and then
expand it to a fully documented business requirement
narrative.
a. Documenting the Use-Case Course of
Events: step by step description.
Use Cases and Project Management
1. Ranking and Evaluating Use Cases: Based on the
following six criteria (scale 1-5)
1) Significant impact on the architectural design
2) Easy to implement but contains significant
functionality
3) Includes risky, time-critical, or complex
functions
4) Involves significant research or new or risky
technology
5) Includes primary business functions
6) Will increase revenue or decrease costs.
2. Identifying Use-Case Dependencies: Use-case
dependency diagram is a graphical depiction of the
dependencies among use cases.
Vocabulary
System requirement: property or function of the information
system.
Functional requirement: something the information system must
do.
Nonfunctional requirement: property of quality the system must
have.
Performance: response time
Information: content, timeliness, accuracy, and format
Economy: costs
Control (and security): privacy requirements
Efficiency: Reduce waste
Service: reliable, flexible, and expandable
Ishikawa diagram: case-and-effect diagram, fishbone diagram
Requirements definition document: Formal document that
communicates the requirements of a proposed system to the
stakeholders.
Requirements management: Managing change to the
requirements.
Sampling: Collecting a representative sample of documents,
forms, and records.
Randomization: No predetermined pattern
Stratification: Spread out sampling by using a formula
Observation: A fact-finding technique.
Free-format questionnaire: Offers greater latitude in the answer.
Fixed-format questionnaire: Selecting an answer from predefined
available responses. (multiple choice, rating, ranking)
Interview: a fact-finding technique through face to face interaction
Unstructured interview: Few questions. Relies on interviewee to
drive the conversation.
Structured interview: Specific set of questions
Open-ended question: Response varies
Closed-ended question: Restricts answers to specific choices.
User-centered development: Understanding the needs of the
stakeholders and the reasons why the system should be
developed.
Use-Case diagram: Depicts the interactions between the system
and external systems and users.
Functional decomposition: Act of breaking a system into
subcomponents.
Temporal Event: a system event that is triggered by time.
Extension use case: Steps extracted from a more complex use
case in order to simplify things.
Abstract use case: Combining common steps between two use
cases.
10. Module 3 –System & Requirements Analysis Requirements
The process of understanding what's wanted or needed in an
application. Requirements begin as a generalized description of a
customer need as a customer vision or a mission or context
statement. Requirements begin to define the “what” in a bit more
detail. This detail is usually focused on the business aspects of
the system operations and in many organizations is identified as
“Business Requirements.” As analysts gather more and more
information about customer wants and needs and develop the
next iteration of requirements, these requirements then begin to
get more detailed in explaining the function of the “what” the
customer wants or needs in more detail. These types of details
are usually called functional requirements.
C & D Requirements
For this reason we often divide requirements documents into two
versions: C-requirements and D-requirements. In some
organization, this division is roughly equivalent to the division
between business requirements and functional requirements. The
first part of a requirements document is an overview that is
especially suited to customers. These are sometimes called the
C-requirements (“C” stands for “customer”).The second part of a
requirements document (or a separate document when the
system being described is a large one) consists of the details of
system operations. These details are especially useful for
developers who need to know precisely what the application must
do. These are sometimes called the D-requirements (“D” stands
for “detailed” or for “developer”).
Document Maintenance and Traceability
Linking artifacts is a good way to attain traceability. Key links are
the associations between each requirement and (a) the design
element that accommodates it, (b) the code that implements it, (c)
the inspection that verifies it, and (d) the test that validates it. The
following shows relationships between the artifacts, based on a
single requirement.
Functional vs. Non-Functional Requirements
A functional requirement specifies something that the application
allows the user to accomplish. All other requirements are non-
functional. Some non-functional requirements are performance
requirements.
Customer-Oriented Requirements
The main purpose of customer-oriented C-requirements is to
provide you with a good idea of the application by omitting details.
C-requirements are usually divided into sections including
"Overview," "Main Functions" and "GUI concepts." The overview
is intended to allow readers to quickly understand the main
purpose of the intended application. Following an overview
section, C-requirements usually list the major functions such as
"enter new video," "rent video," etc. Since users usually utilize
applications through a relatively small number of common back-
and-forth interactions, this can be a good way to summarize
functionality. These interactions are termed "use cases."
Applications typically involve multiple GUIs. The C-requirements
describe the required mouse actions that take the user from one
GUI to another.
Detailed Requirements
The purpose of detailed requirements (“D-requirements”) is to
specify all of the details required of the application. There is
nowhere else for the team to state exactly what is required. The
purpose of detailed requirements (“D-requirements”) is to specify
all of the details required of the application. There is nowhere else
for the team to state exactly what is required.
Functional Requirements
The functional requirements are the heart of the requirements
because they describe what the application is intended to do.
They can be organized by Function, Use Case, GUI, or Class.
Domain Classes (Business Objects)
Classes derived from the business requirements are known as
domain classes or business objects.
A common first step in identifying domain classes is to gather the
nouns or their equivalent used in the C-requirements.
The second step is to eliminate duplicates as well as
questionable or vague entries.
The third step is to ensure that both individuals and aggregates
appear.
The last step is to inspect the list to ensure that the set of
paragraphs describing these entities adequately covers the
functional requirements.
Non-Functional Requirements
Any requirement that does not specify functionality (behavior)
provided by the application is non-functional. Major non-functional
categories are: external interfaces (hardware, software, and
communication), error conditions, system attributes (reliability,
availability, security, maintainability, performance in terms of
speed and storage for different loads and other quality attributes.
Constraints: A constraint on an application is a
requirement that limits it. Some examples of constraints
are shown below.
Standards and Regulatory Compliance
External Interface Requirements:Applications are
frequently required to interface with other systems.
Error Condition Requirements
Steps for Developing User Interfaces
Step 1 - Know Your User
Step 2 - Understand the Business Function
Step 3 - Understand the Principles of Good Screen Design
Step 4 - Select the Appropriate Kind of Windows
Step 5 - Develop System Menus
Step 6 - Select the Appropriate Device-Based Controls
Step 7 - Select the Appropriate Screen-Based Controls
Step 8 - Organize and Lay Out Windows
Step 9 - Choose Appropriate Colors
Data Flow Diagrams for Customer
Communication
Some requirements are naturally described as the flow of data
among processing elements. These processing elements
transform data from one form to another as the result of
computations performed by these processing elements.
State Transition Diagrams for Customer
Communication
State Transition Diagrams for Customer Communication
States are sometimes called "phases" or "stages." The idea is to
divide the behavior of the application into states so that the
application is always in one of these states.
11. Module 4 – Modeling with UML System Concepts for Process Modeling
External Agents: external to the system being analyzed.
Represented by a square (external entity). Singular
nouns.
Data Stores: There should be one data store for each
data entity on an entity relationship diagram.
Represented by the open ended box. (file, database,
data at rest). Plural of the entity name: CUSTOMER >
customers (data store)
Process: work performed by a system in response to
incoming data flows or conditions (transform).
Represented by a rounded rectangle.
o Process decomposition: break down of a
process into activities and tasks
o Logical process: work or action that must be
performed. Can be implemented as one or
more physical processes. Perform
computations, Make decisions, Sort, Filter,
Organize data, Trigger other processes, Use
stored data.
Function: ongoing activities. Nouns
Event: must be completed as a
whole. (transactions) General
names.
Elementary processes:
detailed activities
(primitive process).
Strong action verb.
Data Flows: input/output. Data in motion. Data should
travel together like a packet. Represented by an arrow.
Control flow is a condition or nondata event that triggers
a process and it is represented by a dotted arrow.
Singular descriptive nouns and use adjectives or
adverbs to help describe (APPROVED ORDER).
o Data structures: sequence, selection,
repetition
o Domains: Two properties required for each
attribute. Data type is what class of data can
be stored and domain is the legitimate value
for an attribute.
o Divergent and Convergent flows: Splits into
multiple data flows or merges into a single
data flow.
Process of Logical Process Modeling
Strategic systems planning: Business areas and
functions are mapped to an enterprise process model.
Process modeling for business process redesign (BPR):
A cross between data flow diagrams and flow charts.
Diagrams tend to be very physical.
Process modeling during Systems Analysis: modern
structured analysis focus on the logical model of the
target system.
o Event partitioning: structured analysis where
a system is divided into subsystems:
Context data flow diagram
Functional decomposition diagram
Even-response/use-case list
Event handler
Event diagram
System diagrams
Primitive diagrams
Structured English and/or
decision table
Data structure
Fact-finding and information gathering for process
modeling
CASE for process modeling:
Constructing process models
Context data flow diagram: Document scope of a
system (environmental model)
The functional decomposition diagram
Event-response or Use-case list:
o External events: Initiated by external agents
o Temporal events: when these happen, an
input control flow occurs.
o State events: Illustrated as control flow.
Event decomposition diagrams: one process per use
case
Event diagrams: context diagram for a single event.
Most contain a single process.
System diagram: The system diagram shows either all
the events for the system on a single diagram or all the
events for a single subsystem on a single diagram.
Primitive diagrams: Event processes requiring more
details.
Structured English
Structured English is not pseudo code. It is natural English and
the syntax of structured programming.
A sequence of simple, declarative sentences
A conditional or decision structure.
An iteration or repetition
Restrictions:
Only strong, imperative verbs
Only names that have been defined in the project
dictionary.
Clear formulas
No undefined adjectives or adverbs
Readability over programmer preferences.
Decision Table
Set of conditions and actions represented in a tabular format.
Condition stubs: Actions/conditions that will affect the
decision/policy
Action stubs: possible policy actions/decisions
Rules: Specific combination of conditions define an
action
Synchronizing of System Models
Data and Process model synchronization: data to
process CRUD matrix: Create Read Update Delete
Process distribution: Process to location association
matrix.
Object Oriented Analysis (OOA) & UML
An approach used to study existing objects to see if they can be
reused or adapted for new uses and define new or modified
objects that will be combined with existing objects into a useful
business computing application.
Unified Modeling Language (UML) is a set of modeling
conventions that is used to specify or describe a software system
in terms of objects.
System Concepts for Object Modeling
Object, attributes, methods, and encapsulation
Classes, Generalization, and specialization: gen/spec is
a technique of grouping common attributes/methods of
object classes into one unique object class called
supertype)
Object class relationships
Messages and Message sending: Object invokes
another object’s behavior for some action. CUSTOMER
requests order status ORDER details display.
Polymorphism: Objects respond to the same message
in different ways.
UML Diagrams
Use case: Depicts interactions between the system and
external systems and users. In other words it
graphically describes who will use the system and in
what ways the user expects to interact with the system.
The use-case narrative is used in addition to textually
describe the sequence of steps of each interaction.
Activity: Depicts sequential flow of activities of a use
case or business process. It can also be used to model
logic with the system.
Class: Depicts the system's object structure. It shows
object classes that the system is composed of as well
as the relationships between those object classes.
Object: Similar to a class diagram, but instead of
depicting object classes, it models actual object
instances with current attribute values. The object
diagram provides the developer with a "snapshot" of the
system's object at one point in time.
State machine: Models how events can change the
state of an object over its lifetime, showing both the
various states that an object can assume and the
transitions between those states.
Composite Structure: Decomposes internal structure of
class, component, or use case.
Sequence: Graphically depicts how objects interact with
each other via messages in the execution of a use case
or operation. It illustrates how messages are sent and
received between objects and in what sequence.
12. Module 4 – Modeling with UML
Communication: (Collaboration diagram in UML 1.X)
Depicts interaction of objects via messages. While a
sequence diagram focuses on the timing or sequence of
messages, a communication diagram focuses on the
structural organization of objects in a network format.
Interaction Overview: Combines features of sequence
and activity diagrams to show how objects interact
within each activity of a use case.
Timing: Another interaction diagram that focuses on
timing constraints in the changing state of a single
object or group of objects. Especially useful when
designing embedded software for devices.
Component: Depicts the organization of programming
code divided into components and how the components
interact.
Deployment: Depicts the configuration of software
components within the physical architecture of the
system's hardware "nodes."
Package: Depicts how classes or other UML constructs
are organized into packages (corresponding to Java
packages or C++ and .NET namespaces) and the
dependencies of those packages.
Process of Object Modeling
Modeling the functional description of a system
o Constructing the Analysis use-case model
Identify, define, and document new
actors
Identify, define, and document new
use cases
Identify any reuse possibility
Refine the use case model diagram
(optional)
Document system analysis use
case narratives
o Modeling the use case activities: an activity
diagram can be used to graphically depict the
flow of a business process, the steps of a use
case, or the logic of an object behavior
o Guidelines for constructing activity diagrams
Start w one initial node
Add partitions
Add an action for each major step
Add flows from each action to
another action, decision point, or
end point
Add decisions where flows diverge
and connect them back.
Add forks and join where activities
are performed in parallel
End with a single notation for
activity final
o System sequence diagram: depicts the
interaction between an actor and the system
for a use case.
o Guidelines for constructing system sequence
diagrams:
Identify which scenario
Draw a rectangle representing the
system
Identify each actor
Examine the use case narratives
Add frames to indicate optional
messages with conditions
Confirm the sequence
Finding and identifying objects
o Find the potential objects
o Select the proposed objects
Organizing objects and identifying relationships
o Identify associations and multiplicity
o Identify gen/spec
o Identify aggregation/composition
o Prepare class diagram
Classes in UML
Classes in UML diagrams are represented by rectangles
containing from one to three segments depending on the desired
level of detail.
Attributes describe data components that belong to objects of this
class.
Operations describe the behavior of objects of a class – actions
that an object can perform on behalf of the code that uses that
object.
Class relationships in UML
Packages: UML packages can contain any materials
associated with an application, including source code,
designs, documentation, etc. The example below shows
the UML notation for packages and sub-packages. The
package myPackage has three components; the
package mySubPackage and two classes, MyFirstClass
and MySecondClass. The package mySubPackage has
only one component, MyClass.
Inheritance: Inheritance is a relationship between
classes that we use to stress the fact that the two
classes have common attributes and/or operations.
The added benefit of the design with inheritance is that
subclass objects may be used anywhere where
superclass objects could be expected. This allows the
programmers to write so called polymorphic algorithms
that could be applied to objects of any subclass in the
inheritance hierarchy. In UML inheritance is indicated
with an open triangle.
Aggregation: Aggregation indicates the structural
inclusion of objects of one class by an object of another
class. On UML diagrams, this relationship is denoted
with a hollow diamond. It is usually implemented by
means of a containing class (the aggregate) having an
attribute whose type is the included (aggregated) class.
Unlike inheritance, this is a relationship among objects,
not among classes. Composition is a stronger form of
aggregation in which the aggregated object exists only
during the lifetime (and for the benefit of) the composing
object: No other object may reference it.
Dependency: Dependency, denoted with a dotted line
arrow, means that an object of one class depends upon
an object of another class in the sense that if the object
at arrow's end were to change its state or the values of
its data attributes, then this would affect the behavior of
the dependent object.
Association: Association, denoted with a solid line
between two classes, commonly means that objects of
each class is somehow associated with objects of the
other class in a structural manner. One-way
associations are aggregations and compositions, which
we have already covered. Two-way associations are
problematical because we need to be sure that both
ends of the implied information are kept consistent.
Vocabulary
Logical model: nontechnical pictorial representation that depicts
what a system is or does
Physical model: what the system is or does and how the system
is implemented.
Process modeling: technique to organize and document a
system's processes
Control flow: a condition or nondata event that triggers a
process.
Data conservation: ensuring data flow contains only data needed
by the receiving process.
Data attribute: the smallest piece of data that has a meaning to
the users and the business
Balancing: a concept that requires that data flow diagrams at
different levels of detail reflect consistency and completeness
Object: something that is or is capable of being seen.
Attribute: characteristics of an object
Behavior: what the object can do. (method, operation, or service)
Object class: set of objects that share attributes and behaviors
(class)
Inheritance: methods/attributes inhereted from class to class
Supertype: parent class, abstract
Subtype: child class or concrete class if at the lowest level
Multiplicity: min/max occurrences of one object calss for a single
occurrence of the related object class
Aggregation: Computer contains CPU, memory, etc.
Composition: If you cancel the order, all items are removed from
the ORDER.
Override: child class uses its own attribute rather than the
inherited one.
Class diagram: depiction of a system's static object structure
showing classes and relationships
Persistent class: Describes object that outlives the execution of
the program
Transient object class: describes object that is created
temporarily by the program and lives only during the program's
execution.
13. Module 5 – System Architectures
Systems Design
The specification of a detailed computer-based solution. Also
called, “physical design” because it focuses on the technical or
implementation concerns of the system.
Design Approaches
Model-Driven Approaches: A system design approach that
emphasizes drawing system models to document technical
and implementation aspects of a system.
o Modern Structured Design: A system design
technique that decomposes the system’s
processes into manageable components. It is
considered a process-oriented technique also
known as, “top-down program design and
structured programming”. It must be highly
cohesive and loosely coupled. Structured design is
performed during systems design. The software
model derived from structured design is called a
structure chart.
o Information Engineering (IE): Model-driven and
data-centered, but process-sensitive, technique for
planning, analyzing, and designing information
systems.
o Prototyping: An interactive process involving a
close working relationship between the designer
and the users.
Pros: End user participation, Iteration
and change, active, errors can detected
earlier, accelerates several phases of
the life cycle
Cons: “Code, implement, repair”, it is
only a complement, issues can be
forgotten, out of control, slower
performance than their 3rd
generation
language counterparts
o Object-oriented design: an attempt to eliminate the
separation of concerns about DATA and
PROCESS.
Rapid Application Development (RAD): a merger of various
structured techniques with prototyping techniques and join
application development techniques to accelerate systems
development.
FAST Systems design strategies: integrates all the popular
approaches introduced in the book.
“Build” Solution
Task 5.1 – Design the Application Architecture: This first
design task is to specify application architecture. This task is
accomplished by analyzing the data models that were initially
created during requirements analysis using a physical data
flow diagram (PDFD). The analyst may involve a number of
system designers and system users. (DBAs, network
admins, engineers, and application admins.) Inputs are facts,
recommendations, and opinions. Principal deliverable is the
application architecture and distribution analysis.
Task 5.2 – Design the System Database(s): Prepare
technical design specifications for a database that will be
adaptable to future requirements and expansion. Analyze
how programs will access the data in order to improve
performance. Record size and storage volume. Proper
security and DR techniques. (DBAs, System Builders). Input
is the previous task. Deliverable is the database schemas.
Task 5.3 – Design the System Interface: Work closely with
system users to develop input, output, and dialog
specifications. Internal controls. Format and layout of the
outputs. Editing controls. Various screen designs.
Task 5.4 – Package Design Specifications: Final design
phase that depends on responsibilities of a designer and
programmer, and whether the methodology and solution
calls for the design of the overall program structure. Systems
analyst w/ some aid from the system designer usually
completes this task. Audit staff is involved. Inputs of this task
are the various database, input and output specifications.
Task 5.5 – Update the Project Plan: The system analysts
and system owners are the key individuals in this phase.
Reevaluate project feasibility and update the project plan.
“Buy” Solution
The most notable differences between the buy and the in-house
development projects is the inclusion of a new procurement phase
and a special decision analysis phase. They do the following:
1. Identify and research specific products
2. Solicit, evaluate, and rank vendor proposals
3. Select and recommend
4. Contract with vendor to obtain product
Task 4.1 – Research Technical Criteria and Options: This
task is facilitated by the project manager. System Designers
are responsible for the completion of this task.
Task 4.2 – Solicit Proposals or Quotes from Vendors: This
task is facilitated by the project manager. The systems
designer is also responsible for completing this activity.
Request for Quotations (RFQs) or Request for Proposals
(RFPs).
Task 5A.1 – Validate Vendor Claims and Performances:
System Designers are responsible for the completion of this
activity. The key outputs of this task are those vendor
proposals that proved to be validated proposal or claims and
other whose claims were not validated.
Task 5A.2 – Evaluate and Rank Vendor Proposals: System
Designers are responsible for the completion of this activity.
The ability to perform a feasibility assessment is an
extremely important skill requirement for completing this
task. This approach awards the contract.
Task 5A.3 – Award Contract and Debrief Vendors: Negotiate
contact and inform losing vendors. System Designer must
make and defend the recommendation.
Application Architecture
Specifies the technologies to be used to implement one or more
information systems. Communicates the following design
decisions:
Degree to which the information system will be
centralized or distributed.
The distribution of stored data across a network
Programming language and tools
Integration of any COTS
Technology for interface
Physical Data Flow Diagrams
Model the technical and human design decisions to be
implemented as part of an information system.
Physical Processes
o Logical processes are frequently assigned to
specific physical processors (PCs, servers,
mainframes, people, or other devices)
o Each logical process must be implemented as one
or more physical processes
o If a logical process is to be implemented partially
by people and software, it must be split into
separate processes and appropriate data flow
must be added between the physical processes.
o Number of physical processes on a physical DFD
will almost always be greater than the number of
logical processes of the logical DFD to reflect data
collection, filtering, forwarding, preparation, or
quality checks.
Physical Data Flows:
o The planned implementation of an input to or
output from a physical process
o A database command or actions such as create,
read, update, delete
o The import of data from or the export of data to
another information system across a network
o The flow of data between two modules or
subroutines within the same program.
Physical External Agents: Unchanged from the logical DFD
Physical Data Stores:
o Database
o Table in a database
o A computer file
o Tape or media backup
o Temporary file
o Any type of non-computerized file
Information Technology Architecture
Distributed Systems: a system in which components are
distributed across multiple location sand computer networks.
o Layers
Presentation layer: the actual user
interfaces
Presentation logic layer: processing that
must be done to generate the
presentation. (editing input data and
formatting output data)
14. Module 5 – System Architectures
Application Logic layer: All logic and
processing to support the business
application. (Data analysis, calculations)
Data Manipulation layer: all commands
and logic required to store and retrieve
data in a database
Data layer: Stored data in a database
o Architectures
File server architecture: Practical for
small database with small number of
users. Disadvantages are large amounts
of data move between client/server,
client PC must be robust, database
integrity.
Client / Server architecture: client/server
computing or client/server system is a
distributed solution in which the
presentation, presentation logic,
application logic, data manipulation, and
data layers are distributed between a
client PC and one or more servers. They
can use thin or fat clients. (database
servers, transaction servers, application
servers, messaging/groupware, web
servers
Client/Server distributed
presentation: system in which
presentation and presentation
logic are shifted from the
server to reside on the client.
Client/Server distributed data:
a two-tiered client/server
computing is a system in
which the data and data
manipulation layers are placed
on servers and other layers
are placed on clients.
Database server is
fundamental to this
architecture. (Oracle, MS
SQL)
Client/Server distributed Data
and Application: Data and
data manipulation layers are
placed on their own servers,
application logic is placed on
its own server, presentation
logic and presentation are
placed on the client. Also
called, three-tiered, n-tiered,
client/server computing.
Drawbacks are complexity
and design partitioning.
Internet-Based computing architecture: a
network computing system is a multi-
tiered solution where presentation and
presentation logic run on browsers using
downloaded content.
Data Architectures – Distributed Relational Databases: A
relational database stores data in a tabular form. Related
records between two tables are duplicated. A distributed
relational database distributes or duplicates tables to multiple
database servers. Sometimes called a client/server database
management system. (SQL, Oracle, DB2, Sybase)
o Data partitioning: Different columns on different
databases (vertical). Rows on different database
servers (horizontal)
o Data replication: duplicates on more than one
database server.
Interface Architectures – Inputs, Outputs, and Middleware
(pg 496-500):
o Batch inputs or outputs: For inputs, the logical
name is singular, but the batch name is plural. The
batch goes in to a temporary data store which is
read by a process triggered by a date. For outputs,
a plural name for batch processing.
o Online inputs or outputs: Output can be in HTML
format or MAPI E-mail.
o Remote batch
o Keyless data entry (and Automatic Identification):
Bar code technology, OCR, OMR (Optical Mark
Reading)
o Pen input: Palm OS, Windows Mobile
o Electronic Messaging: Exchange, Lotus notes
o Electronic data interchange (EDI): Standardized
electronic flow of business transactions or data
between businesses.
o Imaging and Document Interchange
o Middleware: Utility software that enables
communication between different processors in a
system.
Presentation: HTTP allows
communication to a web browser
through API.
Application: Remote Procedure Calls
(RPC), message queues, ORBs
Database: ODBC, JDBC
Process Architectures – The software development
environment (SDE): Software languages and tools that will
be used to develop the business logic and application
programs for the process.
o SDEs for Centralized Computing and Distributed
Presentation: COBOL to write programs, CICS to
manage any online transactions and terminal
screens, VSAM or DB2 to manage stored data
o SDEs for two-tier client/server: Sybase
PowerBuilder, Visual Studio, Borland’s Delphi
RAD for developing GUIs
Automatic generation fo the template
code for the GUI
Programming language compiled for
replication and execution on client
Sophisticated code testing and
debugging
o SDEs for Multi-tier Client/Server: (Dynasty’s
Dynasty, IBM’s VisualAge) Additional capabilities
like:
Strong emphasis on reusability
Tools to help analysts and programmers
partition application components
between the client and servers
Ability to automatically scale the
application to larger and different
platforms
Sophisticated software version control
o SDEs for Internet and Intranet Client/Server:
HTML, XML, CGI, Java
Application Architecture Strategies for System
Design
Enterprise Application Architecture Strategy
o Approved network, data, interface, and processing
technologies and development tools
o Strategy for integrating legacy and technologies
o Ongoing process for continuously reviewing the
application
o Ongoing process for researching emerging
technologies and making recommendations
o Process for analyzing requests for variances from
approved application architecture.
Tactical Application Architecture Strategy: Each project must
define its own architecture for the information system being
developed
o Technical feasibility: Technology maturity,
suitability to the application being designed, or
ability to work with other technologies.
o Operational feasibility: How comfortable
management, users, technology managers, and
support is with the technology
o Economic feasibility: cost-effectiveness.
Modeling the Application Architecture of an
Information System
Drawing Physical Data Flow Diagram:
o A physical DFD should be developed for the
network architecture: each class of clients is
represented by a single processor
o Each processor requires a physical DFD to show
the event processes
o Design unit is a self-contained collection of
processes, data stores, and data flows that share
similar design attributes.
Prerequisites: Logical data model (entity relationship
diagram), logical process models (DFD). Some constraints
are:
o Architectural standards, project objectives, and
feasibility.
15. Module 5 – System Architectures
The Network Architecture: the first physical DFD that
allocates processors (client/servers) and devices (machines,
robots) to a network and establishes the connectivity and
where users will interact with the processors (usually only the
clients).
Data Distribution and Technology Assignments: Required
logical data stores from logical DFDs or as entities on the
logical ERDs.
o Store all data on a single server
o Store specific tables on different servers
o Store subsets of specific tables on different
servers
o Replicate (duplicate) specific tables or subsets on
different servers
Process Distribution and Technology Assignments:
o For two-tiered client/server systems, all the logical
event diagrams are assigned to the client
o For three-tiered client/server and network
computing systems, you need to partition. Each
physical DFD for a partition corresponds to a
design unit for a given business event.
The Person/Machine Boundaries: Separate manual and
computerized processes.
Goals of System Architectures and Designs
Sufficiency: Handles the requirements: Design sufficiency is
closely related to correctness, modularity, understandability
and readability.
Cohesion within a module is the degree to which the
module's components belong together. Coupling describes
the degree to which modules communicate with other
modules. To modularize effectively, we maximize cohesion
and minimize coupling.
Robustness: Can deal with a wide variety of correct and
incorrect input. A design or implementation is robust if it is
able to handle unusual conditions.
Reusability: Can use parts of the design and implementation
in other applications. An application has high usability if
users find it easy to use. Usability is attained through human
interface design, discussed previously in this course.
Reliability: Acceptable failure rate. An application is reliable if
it is relatively defect-free. Metrics make this quantifiable,
such as the average time between failures.
Efficiency: Executes within acceptable limits of time, space,
and any other applicable resources. Efficiency refers to the
use of available machine cycles, memory, communication
bandwidth, storage, and other resources.
Flexibility: Can be readily modified to handle changes in
requirements. We design so that parts of our own
applications can be reused by others and ourselves in similar
or even in different projects.
o Object code (or equivalent)
Example: sharing DLLs between word
processor and spreadsheet
o Classes - in source code form
Example: Customer class extended and
used by several applications
o Assemblies of Related Classes
Example: the java.awt package contains
classes for implementing GUI with
standard GUI controls (butons, text
fields, etc.)
o Design Patterns of Class Assemblies
Example: the Strategy Pattern, the
Façade Pattern, etc. can be used in a
variety of applications
Integrating Design Models
Use Case Model
o The business use cases
o regular use cases
o Sequence diagrams
o Scenarios
Class Models: Classes are the building blocks—more
precisely, the types of building blocks -- of designs.
Data Flow Models: shows specific processes and the types
of data flowing between them.
State Models: State models reflect reactions to events.
Events include mouse actions and changes in variable
values. Events are not described in class models or
component models, but they do occur in use case models.
Frameworks
A framework, sometimes called a library, is a collection of
software artifacts usable by several different applications. These
artifacts are typically classes, together with additional software
required to utilize them.
A framework is a kind of common denominator for a family of
applications. Alternatively, as we will see below, a framework may
feel like a generic application that we customize by inserting our
own parts.
The main benefit of using frameworks is to provide reusability of
components common to the family of applications, such that other
developers designing another application of the same family do
not have to re-create the same types of components.
System Architectures
Create Domain Classes from requirements analysis: The
classes in the architecture are arrived at by evaluating your
system as a whole and identifying the supporting classes
required in addition to your domain classes. The rest of the
classes are added to complete the design
Architectural Trade-off Analysis Method (ATAM): The ATAM
methodology focuses on how a system architecture and
design will meet the quality attributes and non-functional
requirements defined by the stakeholders of the system.
ATAM is a risk analysis identification methodology and a
means of detecting potential risk within a software system.
o (a) identify quality attribute that might affect the
choice of architecture
o (b) identify applicable architectures
o (c) evaluate whether each architecture satisfies the
quality requirements.
QFD or Quality Function Deployment: QFD is focused on the
transformation of stakeholder requirements into ensuring that
quality is engrained within the creation of the components or
sub-systems being created.
Architecture Types
Data Flow Architectures
o Pipe and Flow Architectures: In these
architectures, data processing elements (referred
to as “filters”) accept streams as inputs at any time
and produce output streams. The name “filter”
implies that the output stream is derived from the
input stream through a process similar to filtering.
o Batch Sequential Data Flow: One can think of the
operations as occurring only once per batch of
data and the next operation starts only when the
previous one is complete.
Independent Components
o Tiered and Client/Server Architecture:
Client/server architectures have subsequently
become more sophisticated and more varied.
Some are now designed as three-tier architectures
instead of the original two tiers (client and server).
The middle tier lies between the client and the
database, providing a useful level of indirection.
o The Parallel Communicating Processors
Architecture: This architecture is characterized by
several processes executing at the same time.
o Event Systems Architectures and the State Design
Pattern: If a system has complex responses that
depend on what has happened before, especially if
it also has a limited set of inputs, consider
designing it as an Event System using a State
design pattern.
Virtual Machines: we design an interpreter which accepts
user's command in this scripting language. This interpreter
serves as an intermediate layer between the operating
system and the application.
Repository Architectures: The word "repository" is often used
in industry to denote an application that provides a unified
view of a collection of databases. Blackboard architectures,
developed for artificial intelligence applications, are
repositories which behave in accordance with posting rules.
Layered Architectures: Building applications layer by layer
can greatly simplify the process. Some layers, such as
frameworks, can serve several applications. This design
improves productivity, decreases development time, and
improves software quality. Layered architectures are
common in operating systems and network communications.
Service-Oriented Architectures: Service-Oriented
Architectures (SOAs) are combinations of services:
components that provide functionality according to an
interface specification.
16. Module 6 – ObjectOriented Designs The Design of an Object Oriented System
The application works by having classes send and receive
messages from other classes. The goal of Object-Oriented Design
(OOD) is to specify the objects and messages of the system.
OOD is an approach used to specify the software solution in terms
of collaborating objects, their attributes, and their methods.
Entity Classes: an object class that contains business-related
information and implements the analysis classes
Interface Classes: an object class that provides the means
by which an actor can interface with the system. Sometimes
classed boundary class.
Control Classes: an object class that contains application
logic. They coordinate messages between interface classes
and entity classes in which the messages occur.
Persistence Classes: an object class that provides
functionality to read and write persistent attributes in a
database.
System Classes: An object class that handles operating
system-specific functionality.
Design Relationships:
o Dependency relationships: association between
two classes in two instances
To indicate that when a change occurs
in one class, it may affect the other class
To indicate the association between a
persistent class and a transient class
(Interface window and handler class)
o Navigability: Limit messages between classes from
bidirectional to only one direction
Attribute and Method Visibility: The level of access an
external object has to an attribute or method
o Public (+)
o Protected (#)
o Private (-)
Object Responsibilities: In design, we focus on identifying the
behaviors a system must support and, in turn, designing the
object methods for performing those behaviors. Along with
behaviors, we determine the object’s responsibilities. A class
responsibility is implemented by the creation of one or more
methods that may have to collaborate with other classes and
methods.
The Process of Object-Oriented Design
1. Refining the Use-Case Model
a. STEP 1- Transforming the “analysis” use cases to
“design” use cases:
i. Use-case type: System Design
ii. Window Controls: icons, links, buttons
iii. Window Names
iv. Navigation instructions: How the user
navigates the user interface should be
specified
b. STEP 2- Updating the use-case model diagram
and other documentation to reflect any new use
case: Update to reflect new information.
2. Modeling Class Interactions, Behaviors, and States that
support the Use-Case Scenario.
a. STEP 1 – Indentify and Classify Use-Case Design
Classes:
i. Interface Classes: This column contains
a list of classes mentioned in the use
case. There should be at least one
interface class
ii. Controller Classes: This column
contains that encapsulate application
logic or business rules.
iii. Entity Classes: This column contains a
list of classes that correspond to the
business domain classes whose
attributes were referenced in the use
case
b. STEP 2 – Identify Class Attributes:
c. STEP 3 – Identify Class Behaviors and
Responsibilities
i. Analyze the use cases to identify
required system behaviors
ii. Associate behaviors and responsibilities
with classes
iii. Model classes that have complex
behavior
iv. Examine the class diagram for additional
behaviors
v. Verify classifications
d. STEP 4 – Model Object States: Object state is a
condition of the object at one point in its lifetime. A
state is triggered by a state transition even which
is an occurrence through the updating of one or
more of the object’s attributes values.
i. State machine diagram: A UML diagram
that depicts the combination of states
that an object can assume during its
lifetime, the events that trigger
transitions between states, and the rules
governing the objects transition. Also
called statechart or state transition
diagram.
3. Updating the Object Model to Reflect the Implementation
Environment: A design class diagram depicts classes that
correspond to software components that are used to build
the software application. The steps to convert a class
diagram from OOA to OOD are the following:
a. Add design objects to diagram: entity, interface,
control objects
b. Add attributes and attribute-type information to
design objects
c. Add attribute visibility: public, protected, private
d. Add methods to design objects: referred to as
“setters” and “getters”.
e. Add method visibility
f. Add association navigability between classes
g. Add dependency relationships
Object Reusability
Cohesion: the degree to which the attributes and
behaviors of a single class are related to each other
Coupling: the degree to which one class is connected to
or relies upon other classes
Design Patterns
A common solution to a given problem in a given context, which
supports reuse of proven approaches and techniques.
Advantages are:
a. They allow use to design information system with
the experiences of those who came before us
rather than having to reinvent the wheel.
b. They provide designers a short-hand notation for
discussing design issues.
The Strategy Pattern: Behavioral category. Define each
algorithm in a separate class with a common interface.
The Adapter Pattern: Structural category. Add a class that
acts as an adapter to convert the interface of a class into
another interface that the client classes expect.
Object framework: a set of related, interacting objects that provide
a well-defined set of services for accomplishing a task.
Component: A group of objects packaged together into one unit.
Example: dynamic link library (DLL) or executable file
Additional UML Design and Implementation Diagrams
Communication diagram: models the interaction of objects
via messages, focusing on the structural organization of
objects in a network format. Called Collaboration diagram
Component diagram: depicts the organization of
programming code divided into components and how the
components interact.
Deployment diagram: depicts the configuration of software
components within the physical architecture of the system’s
hardware “nodes”.
Relating Use Cases, Architecture, and Detailed Design
1. In step 1, use cases are specified as part of the
requirements
2. In step 2, these, together with other sources, are
used to identify the business objects (domain
classes).
3. In step 3, we develop the system architecture,
4. In step 4, verify that the architecture and detailed
design support the required use cases
We verify that the classes and their methods specified by the
detailed design include all necessary algorithms and supporting
data fields and hence are capable of executing the required use
cases.
17. Module 6 – ObjectOriented Designs
A Typical Road Map for the “Detailed Design” Process
Detailed design starts with the results of the architecture phase
and ends with a complete blueprint for the programming phase.
The blueprint would include details about the classes, their
relationships, data fields, and methods. It is advisable to start the
detailed design process with those aspects of the design that
present the most risk.
1. Step 1: Begin with architectural models for platforms,
software, and communication:
a. class model: domain and architectural
classes
b. Overall state model
c. Overall data flow model, including platforms
d. Use-case model
2. Step 2: Introduce classes and design patterns which
connect the architecture classes with the domain
classes
3. Step 3: Refine models, make consistent, ensure
complete
4. Step 4: Specify class invariants
5. Step 5: Specify methods with pre and post conditions,
activity diagrams, and pseudo code.
6. Step6: sketch unit test plans
7. Step 7 Inspect test plans and design
8. Step 8: Release for integration and implementation
Design in the Unified Development Process
Analysis:
Conceptual and abstract
Less formal
Less expensive to develop
Outlines the design
Relatively unconstrained
Less focus on sequence diagrams
Few layers
Design:
Concrete: implementation blueprint
More formal
More expensive to develop (+/- 5x)
Manifests the design
Constrained by the analysis and architecture
More focus on sequence diagrams
Many layers
The Unified process encourages three kinds (“stereotypes”) of
classes: entity, boundary, and control classes.
1. Entity classes roughly correspond to what we
call business entities, business classes, or
domain classes
2. Boundary classes handle user
communication with entity objects, and their
design depends on the details of the use
cases
3. Control classes contain methods that pertain
to the entity objects, but are typically special
to the application in which the entity class is
being used
Designing Against Interfaces
"Interface" means a set of methods that a class
provides to other classes in the application.
The method signature includes the data types of
method parameters, preconditions and post conditions
Reusing Components
Frameworks are packages of components designed for reuse. We
developed frameworks to support application architectures, and
so they are effectively reusable.
Sequence and Data Flow Diagrams for Detailed Design
Sequence Diagrams
o Begin with the sequence diagrams
constructed for detailed requirements and/or
architecture (if any) corresponding to the use
cases
o Introduce additional use cases, if necessary,
to describe how parts of the design typically
interact with the rest of the application
o Provide sequence diagrams with complete
details
Be sure that the exact objects and
their classes are specified
Select specific function names in
place of natural language
o (calls of one object to another to perform an
operation which the first object needs)
Data FlowDiagrams
o Gather data flow diagrams (DFDs)
constructed for detailed requirements and/or
architecture (if any)
o Introduce additional DFDs, if necessary, to
explain data and processing flows
o Indicate what part(s) of the other models the
DFDs correspond to.
e.g., "the following DFD is for each
Account object"
o Provide all details on the DFDs
Indicate clearly the nature of the
processing at each node
Indicate clearly the kind of data
transmitted
Expand processing nodes into
DFDs if the processing description
requires more detail
Specifying Platforms, Classes, Functions and Algorithms
Platforms: A design must specify in complete detail the
platforms on which the system is intended to run. This
includes client platforms and software, server platforms
and software, communications platforms, and software,
and database platforms and software.
Classes:
o Gather the attributes listed in the SRS
This can be done more easily if the
SRS is organized by class
o Add additional attributes required for the
design
o Name a method corresponding to each of the
requirements for this class:
Again, this is easy if the SRS is
organized by class
o Name additional methods required for the
design
o Show the attributes and methods on the
object model
o State class invariants and method
preconditions and postconditions (see next
section)
Advantages of Pseudo code and Flowcharts
o Provide documentation that helps clarify complex
algorithms
o Impose increased discipline on the process of
documenting detailed design
o Provide additional level at which inspection can be
performed
o Help to trap defects before they become code
o Increase product reliability
o May decrease overall costs
Disadvantages of Pseudo code and Flowcharts
o When design and/or code changes, they have to be
maintained to be consistent
o Introduce error possibilities in translating to code
o May require a tool to extract pseudo code and facilitate
drawing flowcharts
