2009 

MET CS682 

Version 1.0 

Christian Reina, CISSP 

Mark Pelletier 

 

This document may be used only for informational, educational,  and noncommercial purposes. You are free to copy, distribute, publish and alter this document under the conditions that you give credit to the original authors. 2009 – Christian Reina, CISSP, Mark Pelletier. 

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

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

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

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)

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

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.

Module 3 –System

 & Requirem

ents 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.

Module 3 –System

 & Requirem

ents 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.

Module 3 –System

 & Requirem

ents 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.

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.

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.

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)

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.

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.

Module 6 – Object­Oriented 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.

Module 6 – Object­Oriented 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