System Development

SYSTEM DEVELOPMENT AND CAREER IN ORGANIZATION SYSTEM DEVELOPMENT A. Introduction  System development is a process that develops the information system.  Information System (IS) definition is a system that gathers information and gives the related output.  How to produce the process of gathering Information? The system will process the collection of data and verified it to produce the related output. The system will process by following the instructions or procedures.  Summary: o Process is one of the elements in system. o The information is generated by processing the collection of data. B. Types of IS  KBS – Knowledge Based System.  EIS – Executives Information System.  DSS – Decision Support System.  MIS – Management Information System.  OAS – Offices Automation System.  TPS / AIS – Transaction Processing System / Accounting Information System. C. IS Objectives  To reduce manpower costs. Computer-based systems, done by fewer staff.  To improve customer service. Allow organizations to serve customers more quickly or to provide them with additional services.  To improve management information. Decisions can only be as good as the information on which they are based, so many computer systems have been designed to produce more, or more accurate, or timelier information.  To secure or defend competitive advantage. It’s become a major justification for spending on information systems. D. IS Architecture Framework  Planning. o Why build the system? o How should the team go about building it?  Analysis. o Who use the system? o What will it do?

o Where and when will the system be used?  Design: How will the system work?  Implementation: When will the system be delivered? E. IS Users Involved  Individuals that uses IS for accessing information, update information, process information and generate the reports or done the transactions.  Users can divide into 4 categories: o System Owner. Create the scope of system. o Internal and external users. o System Designer. Design the system using the technology or follow the technology. o System Developer. Implementing system using the technical. F. IS Basic Blocks Component

CAREER IN ORGANIZATION A. The Role  Software Engineer: o Ensuring the system conforms to infrastructure standards. o Identifying infrastructure changes needed to support the system.  Systems Analyst: o Identifying how technology can improve business processes. o Designing the new business processes and IS. o Ensuring that the system conforms to IS standards.  System Designer: o Analyzing the key business aspects of the system. o Identifying how the system will provide business value. o Designing the new business processes and policies. B. System Analyst Career Path  The key individuals in the system development process.  Need 4 skills: o Analytical: understand the organization and its function, identify opportunities and problems, analyze and solve problem. o Management: manage projects, resources, risk and change. o Technical: understand the potential and the limitations of information technology, envision an IS and helps users solve problems that will guide the system’s design and development, work with programming









languages, various operating systems and computer hardware platform. o Interpersonal: work with end users, other system analysts and programmers, play major role as a liaison among users, programmers and other systems professionals, have effective written and oral communication including competence in leading meetings, interviewing and listening. Knowledgeable with business and organizations chart. o Known each of the position in the organization. o Known the needs of business. Excellent in problem solving. o Method of problem solving. o Uses the computer as tools in problem solving. Excellent in communication. o Effectiveness in communication at any level. o Knowledgeable in few method of communication. Knowledgeable and expertise in IT: o Internet. o Interface. o Object technology. o Distributed database and data relations. o Network and telecommunication. o Programming and client server.

SYSTEM DEVELOPMENT PROCESS AND PROJECT MANAGEMENT SYSTEM DEVELOPMENT PROCESS A. System Development Lifecycle (SDLC)  SDLC in 2 types of application: o System-based application.  Planning.  Analysis.  Design.  Implementation. o Web-based application.  Publish and Promotion.  Innovation. B. SDLC – System-based Application  Planning: o Why build the system? o Steps taken:  Identify opportunity.  Analysis feasibility.  Develop work plan.  Staff project.  Control and direct people.  Analysis: o Who, What, When, Where will the system be? o Produce System Proposal. o Steps taken:  Develop analysis strategy.  Determine business requirements.  Create use case.  Model processes.  Model data.  Design: o How will the system work? o Produce System Specification. o Steps taken:  Design physical system.  Design architecture.  Design interface.

 Design databases and files.  Design programs. Implementation: o System Delivery. o Steps taken:  Constructs.  Install system.  Maintain system.  Post-implementation. C. SDLC – Web-based Application  Publish and Promotion: o Handling all the public relations issues of a web; marketing strategies. o Steps taken:  Web principles.  Web techniques.  Web business models.  Innovation: o Improving the usability and quality of the web; meet user expectation. o Steps taken:  Monitor the user’s information environment.  Continuously improve quality. D. Principles Applied  Get the owner and users involved.  Use a problem-solving approach.  Establish phases and activities.  Establish standards.  Justify systems as capital investment.  Don’t be afraid to cancel or revise scope.  Divide and conquer.  Design systems for growth and change. E. Methodologies  Model Driven: o Structured:  Waterfall development. 

 Parallel development.



o Object-oriented. Rapid Application Development (RAD): o Phased development.

o Prototyping.

o Throwaway prototyping.



Computer-Aided System Engineering (CASE): o Example:  Oracle’s Designer 2000.  Platinum’s Erwin.  Rational Rose.  Popkin’s System Architecture.



 Sterling’s COOL product family.  Visible System’s Visible Analyst.  Visio’s Visio Enterprise. Hybrid: o Rapid architected development route:

o Multiple implementation route:

o Staged implementation route:



Maintenance and reengineering:

APPROPRIATE METHODOLOGY DEVELOPMENT SELECTION  Clarity of user requirements.  Familiarity with technology.  System complexity.  System reliability.  Short time schedules.  Schedule visibility. ENTITIES RELATIONSHIP DIAGRAMS A. Overview  Originally proposed by Peter Chen for the design of relational database systems and has been extended by others.  Although, the ERD is still used in some database design applications, UML notation is now more commonly used for data design.  To represent data objects and their relationships.  Set the stage for the design of databases later on in the SDLC.  Drawn in either Chen Model or in Crow’s Foot Model by various software.  First step: Need to define business rules collected. B. Business Rule  According to the Business Rules Group, business rules are each one of the following kinds: o Term: The application of a single definition to a word or phrase. o Fact: The attribution of something to describe a thing: a role it plays, or some other descriptor. o Derivation: An attribute that is derived from other attributes or system variables. o Constraint: A condition that determines what values an attribute or relationship can or must have.  Brief, precise, and unambiguous description of a policy, procedure, or principle within a specific organization’s environment.  Description of operations that help to create and enforce actions within that organization’s environment.  Describe characteristics of the data as viewed by the company.  There are 3 basic elements in ER models: o Entities are the “things” about which we seek information. o Attributes are the data we collect about the entities. o Relationships provide the structure needed to draw information from multiple entities.

C. Entities  Refers to the entity set and not to a single entity occurrence.  Corresponds to a table and not to a row in the relational environment.  In both the Chen and Crow’s Foot models, an entity is represented by a rectangle containing the entity’s name.  Entity name, a noun, is usually written in capital letters. D. Attributes  Characteristics of entities.  In the Crow’s Foot model, the attributes are simply written in the attribute box below the entity rectangle.  Primary key: o Underlined in the ER diagram. o Key attributes are also underlined in frequently used table structure shorthand. o Ideally composed of only a single attribute. o Possible to use a composite key (primary key composed of more than one attribute). E. Relationships  Association between entities.  Participants: Entities that participate in a relationship.  Relationships between entities always operate in both directions.  Relationship can be classified as 1:M.  Relationship classification is difficult to establish if you only know one side. F. Relationships Degree  Indicates number of associated entities or participants o Unary relationship: association is maintained within a single entity. o Binary relationship: two entities are associated. o Ternary relationship: three entities are associated. G. Recursive Relationships  Relationship can exist between occurrences of the same entity set.  Naturally found within a unary relationship. H. Connectivity and Cardinality  Connectivity: used to describe the relationship classification.  Cardinality: expresses the specific number of entity occurrences associated with one occurrence of the related entity.  Established by very concise statements known as business rules. I. Symbols

PROJECT MANAGEMENT  Process of planning and controlling the development of a system within a specified time frame at a minimum cost with the right functionality.  Project’s is successful if: o Resulting IS is acceptable to the customer. o The system was delivered on time and within budget. o The system development process had a minimal impact on ongoing business operations.  Project’s is a failure if: o Failure to establish upper-management commitment to the project. o Lack of organization’s commitment. o Taking shortcuts through/around system development methodology. o Poor expectation management. o Premature commitment to a fixed budget and schedule. o Poor estimating techniques. o Over optimism. o The mythical man-mouth. o Inadequate people management skills. o Failure to adapt to business change. o Insufficient resources. o Failure to “manage to the plan”. PROJECT MANAGEMENT LIFECYCLE  Identifying project size. o Size of the system (what it does). o Time to complete the project (when the project will be finished). o Cost of the project.







Creating and managing the work plan. o Identify tasks. o Project work plan. o Gantt chart. o PERT chart. o Refining estimates. o Time boxing. Staffing the project. o Staffing plan. o Motivation. o Handling conflict. Coordinating project’s activities. o CASE tools. o Standards. o Documentation. o Managing risks. o Gantt chart, PERT chart.

EARLY INVESTIGATION PHASE AND DEVELOPMENT LIFECYCLE EARLY INVESTIGATION PHASE – INTRODUCTION  First phase of classic system development process.  Other methodologies called initial study phase, survey phase or planning phase.  Answers the question, “Is this project worth looking at?” o Define scope. o Perceived problems, opportunities and directives the project.  Context of preliminary investigation phase. o System owners’ view of the existing system. o Decisions on resources for the whole project.  Tasks should be performed to complete the process: o List problems, opportunities and directives. o Negotiate preliminary scope. o Access project worth. o Plan the project. o Present the project. Tasks for the Preliminary investigation phase:

EARLY INVESTIGATION PHASE – ASSESSING PROJECT FEASIBILITY  Usually done after the need for the system and its business requirements have been defined.  Feasibility analysis used to: o Guide organizations to make decision. o Identifies risks associated with the project proposed.  Three techniques: o Technical feasibility: Can we build the system?  Familiarity with application and technology. Less familiarity generates more risk.  Project size. Large projects have more risk.  Compatibility. The harder to integrate the system with company’s existing technology, higher the risk. o Economic feasibility: Should we build the system?  Also called cost-benefit analysis.  More concern with costs:  Development costs.

 Annual operating costs.  Annual benefits (cost and revenues).  Intangible costs and benefits. o Organizational feasibility: Is the project strategically aligned with the business?  To understand how well the goals of the project align with business objectives. Strategic alignment (between project and business objectives).  Most affected groups in introduction new system:  Project champions.  Senior management.  Users.  Other stakeholders. Organizational feasibility – Stakeholders Category Role Champion  Initiates the project  Promotes the project  Allocates his/her time to the project  Provides resources Organizational  Know about the project Management  Budget enough money for the project  Encourage users to accept and use the system System Users  Make decisions that influence the system  Perform hands-on activities for the project  Determine whether the project success or not DEVELOPMENT LIFE CYCLES A. Structured Approach Analysis  Can be considered as a four-stage process. o Investigating and understanding the current physical system. o Listing out the logical functions carried out by the current system (current logical system). o Mapping the requirements for new system onto the current logical system (required logical system). o Developing the new system (required physical system). Structured System Life Cycle

Structured system analysis. o 3 general principles associated with the approach:  Modeling. Graphic models used to provide clear and unambiguously information system.  Partitioning. Breaking down system into smaller parts to make it easy to understand.  Iteration. Revisiting and amending the models of the system. B. Object-oriented Analysis  Is used to: o Study existing objects to see if they can be reused or adapted. o Define new or modified objects that will be combined with existing objects.  Best suited to projects that will implement systems using emerging object technologies: To construct, manage, assemble objects.  The O-O approach is centered around a technique referred to as object modeling (technique used to identify objects within the systems environment and the relationship between those objects).  The Unified Modeling Language (UML) is a set of modeling conventions that is used to specify or describe a software system in terms of objects.  Concepts need to be understood in O-O approach: Concepts Description Object something that is or is capable of being seen, touched, or otherwise sensed Attributes data that represent characteristics of interest about an object Behavior things that the object can do and which correspond to 

functions that act on the object’s data (or attributes) Class set of objects that share common attributes and behavior C. Methods of Design Development  In previous lectures, there are several methodologies which can be applied in an IS development.  In the early stage of development, one must do the study on which method is the best for the to-be IS.  Example: o Model Driven. o Rapid Application Development (RAD). o Computer-Aided System Engineering (CASE). o Hybrid. o Maintenance and Reengineering.

DETERMINING SYSTEM REQUIREMENTS INTRODUCTION TO ANALYSIS PHASE A. Key Definitions  As-Is system is the current system and may or may not be computerized.  To-Be system is the new system that is based on updated requirements.  System Proposal is the key deliverable from the Analysis Phase. B. Key Ideas  Goal of analysis phase: to truly understand the requirements of the new system and develop a system that addresses them or decide a new system isn’t needed.  Begins with requirements analysis.  Analysts will be looking for problems with the existing system and additional requirements that the replacement must have.  Particular challenge for the analysts: to think about ‘what’ the existing systems are doing rather than how they do it (look at the business needs rather than the technical implementation).  System Proposal: o Presented to the approval committee via a system walk-through. o Must be specified in sufficient detail to form a basis for development. The specification include:  Business requirements.  Technical platform and development path (all the specification must employed and the users formally agree the requirement before system design begins).  Systems analysis incorporates initial systems design.  Requirements determination is the single most critical step of the entire SDLC. C. Concepts  Oxford Dictionary defines analysis as follows: separation of a substance or business system into parts for study and interpretation; detailed examination.  Very important to know and understood: o Nature of the business. o The way it currently operates before we do the designing computer system.  Detailed examination: provides the design team with the specific data they require; to ensure that all the client’s requirements are fully met.  System analyst required to perform a number of different tasks in

carrying out the analysis phase of a development project.  As a result of discussion with practicing analysts, 5 areas have been identified: o Investigation. o Communication with customers. o Documentation. o Understanding. o Preparation and planning. D. Concepts – PARIS Model  Divided the process of analysis into 5 stages: o Planning the approach. o Asking questions and collecting data. o Recording the information. o Interpreting the information collected. o Specifying the requirement. PARIS MODEL A. Planning The Approach  First stages of system analysis.  First step taken by the system analyst should be to plan the approach carefully: ‘failure to prepare is prepare to fail’.  Plan the actions, consider few factors: o Objectives of the project. o What type of information is required? o What are the constraints on the investigation? o What are the potential problems that may make the task more difficult?  Plan the investigation. o Critical information you require before the investigation starts. o How you will get this information. o The fact-finding techniques that will be appropriate. o The danger areas for the project and for your company.  A part of the planning process, must ensure: o Understand the objectives and terms of reference agreed with the client. o Aware of constraints that affect the analysis process. o Plan the research, initial contact and other tasks to be completed during the investigation and manage time appropriately.

B. Objective And Terms Of Reference  Objectives the analysis: to understand about client’s expectations.  Key questions in beginning of analysis phase: o Who initiated the project? o What is their role in the organization? o What are their objectives for the project? o What are the company objectives?  Stated objectives of the client will usually be recorded in the terms of reference.  Scope use to summaries the main areas included in the terms of references. o System boundary:  Define the area of the organization under investigation.  May also specify the limit of any new system implemented as a result of the project. o Constraints:  Factors, including budget, timescale and technology, which may restrict the study, or the solution, in some way.  Will enable the analysis to determine which fact-finding methods are most appropriate to help them to put together a detailed plan for the investigation. o Objectives: an unambiguous statement of the expectations of those in the client’s organization who have initiated the project. These may be broken down by function or department. Well-defined objectives are clear and measurable. o Permission: this will indicate who in the client’s organization is responsible for the supervision of the project and, if permission needs to be granted. o End products: a description of the deliverable or end products of the investigation. These will usually the form of a written report and a supporting presentation to managers of the client organization. REQUIREMENTS – GATHERING TECHNIQUES A. Identify Requirements  Interview. o Most commonly used technique. o Basic steps:  Selecting Interviewees.  Based on information needs.

 Best to get different perspectives.  Managers.  Users.  Ideally, all key stakeholders.  Keep organizational politics in mind.  Designing Interview Questions.  Types of Questions.  Close-ended question.  Open-ended question.  Probing question.  Preparing for the Interview.  Interview Preparation Steps.  Prepare general interview plan. • List of question. • Anticipated answers and follow-ups.  Confirm areas of knowledge.  Set priorities in case of time shortage.  Prepare the interviewee. • Schedule. • Inform of reason for interview. • Inform of areas of discussion.  Conducting the Interview.  Appear professional and unbiased.  Record all information.  Check on organizational policy regarding tape recording.  Be sure you understand all issues and terms.  Separate facts from opinions.  Give interviewee time to ask questions.  Be sure to thank the interviewee.  End on time. Practical Tips  Take time to build rapport.  Pay attention.  Summarize key points.  Be succinct.







 Be honest.  Watch body language.  Post-Interview Follow-up.  Prepare interview notes.  Prepare interview report.  Have interviewee review and confirm interview report.  Look for gaps and new questions. Questionnaires o A set of written questions, often sent to a large number of people. o May be paper-based or electronic. o Select participants using samples of the population. o Design the questions for clarity and ease of analysis. o Administer the questionnaire and take steps to get a good response rate. o Questionnaire follow-up report. Good Questionnaire Design o Begin with non-threatening and interesting questions. o Group items into logically coherent sections. o Do not put important items at the very end of the questionnaire. o Do not crowd a page with too many items. o Avoid abbreviations. o Avoid biased or suggestive items or terms. o Number questions to avoid confusion. o Pretest the questionnaire to identify confusing questions. o Provide anonymity to respondents. Document Analysis o Study of existing material describing the current system. o Forms, reports, policy manuals, organization charts describe the formal system. o Look for the informal system in user additions to forms/report and unused form/report elements. o User changes to existing forms/reports or non-use of existing forms/reports suggest the system needs modification. Observation o Watch processes being performed. o Users/managers often don’t accurately recall everything they do. o Checks validity of information gathered other ways. o Be aware that behaviors change when people are watched.

o Be unobtrusive. o Identify peak and lull periods. B. Selecting the Appropriate Requirements  Type of information.  Depth of information.  Breadth of information.  Integration of information.  User involvement.  Cost.  Combining techniques.

SYSTEM REQUIREMENTS ANALYSIS INTRODUCTION  Requirements: o A text report that lists the functional and nonfunctional requirements. o To provide information needed by other deliverables in the analysis phase, which include use case, process models and data models. o To define the scope of the system. REQUIREMENTS  Functional requirements: related directly to a process the system has to perform or information it needs to contain.  Non-functional requirements: refer to the behavioral property that the system must have. o Operational: physical and technical environments in which the system will operate. o Performance: speed, capacity and reliability of the system. o Security: who has authorized access to the system under what circumstances. o Cultural and political: cultural, political factors and legal requirements that affect the system. MODELING SYSTEM BEHAVIOR A. Definition  A process of drawing out the underlying logic of the system and to map out the requirements for the new system.  A process to make sense of data that gathered during information gathering using certain techniques. A. Creating a Logical Model  3 different types of data flow model (DFM) produced: o Current physical DFM: Represent the current system. o Logical DFM: Produced by removing any duplicated or redundant processing or data. o New DFM: Shows how the new processing and data required are incorporated into the logical model. B. Modeling the Required System  A process of documented the new system during the analyst’s investigation.

Existing processes need to be automated in new system are carried over from the logical DFM to the required system DFM making sure that changes resulting from the new requirements are included.  New processes are modeled based on the information contained in the requirements and added to the DFD at the appropriate points with any new data flows, data stores and external entities that are needed.  Entities and their relationships in old DFD are carried over, added or removed to create the required entity model and the data dictionary is updated to reflect the changes to the model. C. Meeting Business Requirements  In securing an understanding between users and developers, things to consider: o The user has to be persuaded to read the specification. o The user must understand it in precisely the same way that the analyst intended: structured method offer advantages in that it is less easy to introduce ambiguity into a drawing than text. o The specification has to offer a practical solution. D. Presenting the Requirements  Proposed solutions need to be presented in a way that are: o Clear. o Intelligible. o Pitched at the correct level for the intended audience. E. Writing the Functional Specification  Contents. o System performance: response times, throughput, hardware and software failures. o Inputs to the system: sources, types, formats, procedures. o Outputs from the system: contents, format, layout. o Constraints: hardware, software, environment and operational. o Other aspect: system start-up and shut down, security procedures. 

IT SWOT ANALYSIS  Act as a structure and tool for marketing proposals and strategy development.  Identifies features of a proposal as follows: o Strengths. o Weaknesses. o Opportunities. o Threats.





SWOT analysis looks into two factors: o Internal factors.  Strengths.  Weaknesses. o External Factors.  Opportunities.  Threats. All these factors includes: o People (management / customers / suppliers). o Money. o Information. o Technology.

RECORDING THE INFORMATIONS A. Introduction  Information collected during requirement collection is to be converted to data models.  Two examples of data models are: o DFD. o ERD.  These data models are classified into 2 categories: o Physical data model. o Logical data model. B. Definition  Data Model is a formal way of representing the data that are used and created by a business system, and shows the people, places and things about which data is captured and the relationships among them.  Physical data model: Reflects how data will be stored in databases and files.  Logical data model: Shows the organization of data without indicating how it is stored, created, or manipulated. DATA FLOW DIAGRAM (DFD) A. How To Record Information About The System  Techniques Data Flow Diagram (DFD), entity modeling together with data dictionary to record information about the current system.  All of these activities are closely related and conducted in parallel during the early stages of requirements analysis. B. Data Flow Diagram

 

The most commonly used way of documenting the processing of current and required systems. A complete set of DFDs provides a compact top-down representation of a system, which makes it easier for users and analysts to envisage the system as a whole.

C. DFD Elements Elements Process 

Descriptions An activity or function performed for a specific business reason  Manual or computerized Data flow  A single piece of data or a logical collection of data  Always starts or ends at a process Data store  A collection of data that is stored in some way  Data flowing out is retrieved from the data store  Data flowing in updates or is added to the data store External entity  A person, organization, or system that is external to the system but interacts with it. D. Naming and Drawing DFD Elements

E. Depicting Business Processes with DFDs  Business processes are too complex to be shown on a single DFD.  Decomposition is the process of representing the system in a hierarchy of DFD diagrams: child diagrams show a portion of the parent diagram in greater detail.

F. Key Definition  Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD. G. Relationship Among DFD levels

DFD A. Context Diagram  First DFD in every business process.  Shows the context into which the business process fits.  Shows the overall business process as just one process (process 0).  Shows all the external entities that receive information from or contribute information to the system. B. Level 0 Diagram  Shows all the major processes that comprise the overall system – the internal components of process 0.  Shows how the major processes are interrelated by data flows.  Shows external entities and the major processes with which they interact.  Adds data stores. C. Level 1 Diagrams

Generally, one level 1 diagram is created for every major process on the level 0 diagram.  Shows all the internal processes that comprise a single process on the level 0 diagram.  Shows how information moves from and to each of these processes.  If a parent process is decomposed into, for example, three child processes, these three child processes wholly and completely make up the parent process. D. Level 2 Diagrams  Shows all processes that comprise a single process on the level 1 diagram.  Shows how information moves from and to each of these processes.  May not be needed for all level 1 processes.  Correctly numbering each process helps the user understand where the process fits into the overall system. 

CREATING DATA FLOW DIAGRAMS A. Integrating Scenario Descriptions  DFDs start with the use cases and requirements definition.  Generally, the DFDs integrate the use cases.  Names of use cases become processes.  Inputs and outputs become data flows.  “Small” data inputs and outputs are combined into a single flow. B. Steps in Building DFDs  Build the context diagram. o Draw one process representing the entire system (process 0). o Find all inputs and outputs listed at the top of the use cases that come from or go to external entities; draw as data flows. o Draw in external entities as the source or destination of the data flows.  Create DFD fragments for each use case o Each use case is converted into one DFD fragment. o Number the process the same as the use case number. o Change process name into verb phrase. o Design the processes from the viewpoint of the organization running the system. o Add data flows to show use to data stores as sources and destinations of data. o Layouts typically place:  Processes in the center.







 Inputs from the left.  Outputs to the right.  Stores beneath the processes. Organize DFD fragments into level 0 diagram. o Combine the set of DFD fragments into one diagram. o Generally move from top to bottom, left to right. o Minimize crossed lines. o Iterate as needed. DFDs are often drawn many times before being finished, even with very experienced systems analysts. Decompose level 0 processes into level 1 diagrams as needed; decompose level 1 processes into level 2 diagrams as needed; etc. o Each use case is turned into its own DFD. o Take the steps listed on the use case and depict each as a process on the level 1 DFD. o Inputs and outputs listed on use case become data flows on DFD. o Include sources and destinations of data flows to processes and stores within the DFD. o May also include external entities for clarity. o Input data flows shown on a parent DFD are often unbundled on the child diagram using splits. o Output data flows shown on a child DFD are often bundled using joins and shown as a larger data flow on the parent diagram. o When to stop decomposing DFDs? Ideally, a DFD has at least 3 processes and no more than 7-9. Validate DFDs with user to ensure completeness and correctness.

ENTITY RELATIONSHIP DIAGRAM (ERD) – A REVIEW A. ERD  A picture showing the information created, stored, and used by a business system.  Entities generally represent similar kinds of information.  Lines drawn between entities show relationships among the data.  High level business rules are also shown. B. Data Dictionary and Metadata  Metadata is information stored about components of the data model.  Metadata is stored in the data dictionary so it can be shared by developers and users throughout the SDLC.  A complete, shareable data dictionary helps improve the quality of the system under development.

C. ERD Elements

D. Balancing ERD with DFD  All analysis activities are interrelated.  Process models contain two data components: Data flows and data stores.  The DFD data components need to balance the ERD’s data stores (entities) and data elements (attributes).  Many CASE tools provide features to check for imbalance.  Check that all data stores and elements correspond between models. o Data that is not used is unnecessary. o Data that has been omitted results in an incomplete system.  Do not follow thoughtlessly – check that the models make sense! PHYSICAL VERSUS LOGICAL A. Physical Data Model  Contains the same components as the logical DFD.  The same rules pertaining to balance and decomposition apply.  Contains additional details describing how the system will be built. B. Steps to Create Physical Data Model  Add implementation references.  Draw a human-machine boundary.

 Add system-related data stores, data flows and processes.  Update data elements in the data flows.  Update the metadata in the CASE repository. C. Physical ERD  Contains the same components as the logical ERD.  The same rules pertaining to cardinality and modality apply.  Contains additional details describing how the data will be stored, in a file or database table.  Additional metadata content required.

SYSTEM DESIGN PHASE INTRODUCTION  PARIS model – frequently an overlap between analysis and design.  High-level design: o Begins during analysis. o Analysis continuing as part of design.  Final deliverables from system analysis: a document containing an unambiguous statement of clients’ requirement.  Functional specification: o States what the development project will have to deliver. o Written by analysis team and agreed and signed off by the client. o All the information must be precisely and accurately  will be the foundation for the design phase to begin.  Information systems design is defined as those tasks that focus on the specification of a detailed computer-based solution, also called physical design.  Systems design: emphasis on the technical or implementation concerns of the system. FEASIBILITY ANALYSIS  Feasibility is the measure of how beneficial or practical the development of an information system will be to an organization.  Feasibility analysis is the process by which feasibility is measured.  Creeping Commitment: An approach to feasibility proposes that feasibility should be measured throughout the life cycle. FEASIBILITY CHECKPOINTS  Systems analysis: o Preliminary investigation. o Problem analysis.  Systems design: decision analysis. FROM ANALYSIS TO DESIGN A. Bridging the Gap  Gaps exist between the information about the system documented by the analyst and the detailed technical task for the designers.  Logical models: o Must be integral to the process of systems development.

o To ease the transition between analysis and design.  Logical model describes what the system does.  Created by mapping the customer’s requirements for a new info system onto the current logical view.  Structured techniques used during analysis that provide the logical model include: o Data flow diagrams (DFD). o Entity model (ERD). o Data dictionary.  Designers will use, amend and develop these models to create design documentation.  Logical model support both the current system and the new system being developed – can be used to overcome the analysis/design gap: technique central to the process of analysis and design. B. Design Objectives and Constraints  Design objectives: o To design a system that delivers the functions required by the client to support the business objectives of their organization. o To make the system conform to the customers’ requirements. o To deliver the system in a way that meets clients’ expectations in terms of service.  Other objectives can also be considered a good design if the system delivered are: Flexible Future requirements able to be incorporated without too much difficulty Maintainable Easy to maintain with lower cost Portable Capable to being transferred from one machine environment to another, with the minimum amount of effort Easy to use User friendly, not difficult to learn how to use and straightforward to operate Reliable Secure against human error, deliberate misuse or machine failure and data will be stored without corruption Secure Protect the confidentiality of the data Cost-effective Delivers the required functionality, ease of use, reliability, security etc to the client in the most costeffective way  Constraints:

Time and cost Resources Client’s existing systems Procedures and methods Knowledge and skills

The available time and budget will limit the options available to designers The availability of resources to be used in delivering a solution to the client How to interface with the existing system in terms of hardware, software, manual that already exist and will continue to be used by the client Final design might also be constrained by internal or external procedures, methods or standards An internally or externally imposed constraint, the knowledge and skills of the development team may limit a designer’s options

C. Design Phase Steps  Present design alternatives: make, buy, or outsource.  Convert logical process and data models into physical models.  Design the architecture for the system.  Make hardware and software selections.  Design the system inputs and outputs.  Design the way data will be stored.  Design the programs for the underlying processes.  Create the system specification. D. Classical Design Mistakes  Reducing design time: abandon plan without re-planning.  Feature creep: a tendency for product or project requirements to increase during development beyond those originally foreseen, leading to features that weren’t originally planned and resulting risk to product quality or schedule.  Silver bullet syndrome: expectations on any SINGLE new tool or methodology to solve all its productivity problems.  Switching tools in mid-project. E. Design Strategies  Choose one of the three: o Custom development in-house: build from scratch. o Purchase software package: later to customize it. o Outsource development to third party. F. Custom Development Pros Cons  Allows flexibility and  Requires significant time and creativity effort

 

Consistent with existing technology and standards Builds technical skills and functional knowledge in-house

    

May exacerbate existing backlogs May require missing skills Often costs more Often takes more calendar time Risk of project failure

G. Selecting a Design Strategy  Consider each of the following when deciding what strategy to use: o Business need. o In-house experience. o Project skills. o Project management. o Time frame. Custom Packaged System Outsourcing Development The business need is The business need isThe business need Business unique common is not core to the need business In-house functional In-house functional In-house functional In-house and technical experience exists or technical experience experience exists experience does not exist Project Desire to build in- Skills are not Outsourcing is a skills house skills strategic strategic decision Have highly skilled Project manager can Highly skilled Project project manager and coordinate vendor’s project manager at management proven efforts appropriate methodology organizational level Time frame is Time frame is short Time frame is short Time frame flexible or flexible H. Moving from Logical to Physical Models  Physical process models and physical data models. o Show the implementation details and explain how the system will work, including:  Actual, specific technology.  Format of information.  Human interaction with system.  CRUD (create, read, update, delete) matrix: a technique to ensure that the data stores are associated with the right processes. I. Physical DFD

 Contains the same components as the logical DFD.  The same rules pertaining to balance and decomposition apply.  Contains additional details describing how the system will be built. Steps to Create  Add implementation references.  Draw a human-machine boundary.  Add system-related data stores, data flows and processes.  Update data elements in the data flows. J. Physical ERD  Contains the same components as the logical ERD.  The same rules pertaining to cardinality and modality apply.  Contains additional details describing how the data will be stored, in a file or database table.  Additional metadata content required. Steps to Create  Change entities to tables or files.  Change attributes to fields.  Add primary keys.  Add foreign keys.  Add system-related components. K. Information Security  Aims to preserve: o Confidentiality: Only authorized people can see certain data. o Integrity: There are limits on who can change the data. o Availability: Data are available at all times to authorized users. o Accountability: Should be possible to see discover after the event who has modified the data. SUMMARY  Set of logical models produced during analysis: emphasized and describes these models bridge the gap between analysis and design.  If analysis has been carried out thoroughly and documented in an unambiguously manner, it will increase the chance of delivering a quality product.  The process of design includes: o Controls. o Human-computer interfaces (input, output, and dialogues). o System interfaces.

o Data-logical models, files, databases and physical storage media. o Processes.

SYSTEM DESIGN: FILES AND DATABASES FILES A. Introduction  Files are an organized collection of related records.  How data is organized and accessed – effectiveness of computer system.  Data processing: input  process output. B. Data Types Master data Records that are relatively permanent Transaction data Records that describe business events/activities Output files Information for output from the system Transfer files Carry data from one stage of processing to another Security/Dump files Copies of data held in the computer at particular time Archive files Contain master and transaction data that have been deleted, audit purposes Library files Library routines Audit files Special records of updates to other files, tracing purposes C. File Organization  Serial organization. o Records are placed one after another each time stored, go to next available storage space. o Disadvantage: not cater for direct access to particular record.  Sequential organization. o Records are sequenced. o Batch processing environment. o Disadvantage: take too long for particular record if the files have to be read from beginning each time.  Indexed sequential organization. o Records are sequenced and index provided. o Can locate/point directly to particular record. o Disadvantage: records might be inserted into overflow areas  slow down access.  Random organization. o Stored with no regard to the sequence of key fields. o Only can be used with direct access devices.  Others. o Full index organization.

o Chained data. D. Access Methods  Key transformation algorithm. o Fastest access method to locate individual method. o Single calculation provides required record address. o Suitable for large datasets.  Database management software. o Use shared data. o Organization method based on requirements of all applications. DATABASE A. Introduction  Database is a single collection of structured data stored with minimum of duplication of data items.  Data contains sharable by all users who has authority to access.  3Is, facilities in DBMS: o Integration: allows applications to share data and avoids the need for data duplication and inconstancies this can cause. o Integrity: removals of duplication, inconsistencies that can arise when duplicated data is updated at different times are removed. o Independence: allows developer to modify the structure of the database without changing all the application programs that use it. B. Concepts

Distributed database:  Several nodes/machines linked together using a computer network.  Reduce response times, communication costs. C. Models  Types of DBMS: o File Management System.  Describe how data is physically stored sequentially.

 Disadvantage: no indication of relationships between data items, need to know exactly how data stored, not enforced for data integrity, etc. o Hierarchical Database Systems.  Organized as tree structure that originates from the root (parentchild concept).  Each class level called node, last node in series called leaf.  Advantage: more efficient and faster process for searching record.  Disadvantage: if parent-child relationship changed, entire structure must be rebuilt. o Network Database Systems.  Describes databases in many-to-many relationships exist.  Sets – relationships between different data items.  Advantage: become more faster if secondary indexes are available to point to physical records.  Disadvantage: if any changes to the sets, programmer needs to create entirely new structure. o Relational Database Systems.  Most commonly used, implement data in a series of 2-dimensional tables that related to one another via foreign key.  Table  columns  rows (Relation  fields/attributes  records)  Manipulate data using SQL, which supports complete database creation, maintenance and usage.  SQL basic syntax, SELECT statement: SELECT CUSTOMER.CUSTNO, CUSTOMER.CUSTNAME, CUSTOMER.ICNO FROM CUSTOMER WHERE CUSTOMER.CUSTNAME = ‘AHMOI’  SQL queries – joining tables (inner or outer joins) to create views of data drawn from different tables. D. RDBMS Design  7 basic rules for achieving a relational database design: o Translate:  Logical data structure.  Logical data integrity. o Tune:  For access requirements.

   

By adding secondary indexes. By introducing controlled redundancy. By redefining database structure. For special circumstances.

INFORMATION SYSTEMS ARCHITECTURE AND APPLICATION ARCHITECTURE AND MODELING SYSTEM DESIGN APPROACHES  Model-Driven. o Modern structured design.  Definition: is a process-oriented technique for breaking up a large program into a hierarchy of modules that result in a computer program that is easier to implement and maintain (change).  Synonyms (although technically inaccurate) are top-down program design and structured programming.  Software model derived from structured design is called a structure chart. o Information engineering.  Definition: is a model-driven and data-centered, but process-sensitive technique to plan, analyze, and design information systems.  Primary tool of IE is a data model diagram. o Prototyping.  Definition: is an iterative process involving a close working relationship between the designer and the users.  Key Benefits:  Prototyping encourages and requires active end-user participation.  Iteration and change are a natural consequence of systems development – thus, it accommodates end-users whom tend to change their minds.  Prototyping endorses the philosophy that end-users won’t know what they want until they see it.  An active, not passive, model that end-users can see, touch, feel, and experience.  Approved prototype is a working equivalent to a paper design specification, with one exception – errors can be detected much earlier.  Can increase creativity – quicker user feedback, lead to better solutions.  Accelerates several phases of the life cycle, possibly bypassing the programmer. o Object-oriented design.  Definition: is the newest design strategy and is an extension of objectoriented analysis.





 Are used to refine the object requirements definitions identified earlier during analysis, and to define design specific objects. Joint Application Development. o Definition: is a technique that complements other systems analysis and design techniques by emphasizing participative development among system owners, users, designers, and builders. o During the JAD sessions for systems design, the systems designer will take on the role of facilitator for possibly several full-day workshops intended to address different design issues and deliverables. Rapid Application Development. o Definition: is the merger of various structured techniques (especially the data-driven information engineering) with prototyping techniques and joint application development techniques to accelerate systems development. o Calls for the interactive use of structured techniques and prototyping to define the users’ requirements and design the final system. o Expedition of the design effort is enhanced through the emphasis on user participation in Joint application development (JAD) sessions.

INFORMATION SYSTEM ARCHITECTURE  Architecture design. o Plans for how the system will be distributed across computers. o What the hardware and software will be used for each computer.  Hardware and software specification: Describes the hardware/software components in detail to aid those responsible for purchasing those products. ARCHITECTURAL DESIGN PURPOSE  Determine what parts of the application software will be assigned to what hardware.  Hardware options: o Clients.  Input/output devices employed by users.  PCs, laptops, handheld devices, cell phones. o Servers.  Larger computers storing software.  Accessible by many users. ELEMENTS OF AN ARCHITECTURE DESIGN  Data storage.

  

Data access logic: processing required to access stored data. Application logic: processing logic of the application. Presentation logic: information display and user command processing.

ARCHITECTURE CHOICES  Server-based architecture.



Client-based architecture.



Client-server based architecture. o Two-tiered.

o Three-tiered.

o Four-tiered.

CLIENT-SERVER ATTRIBUTES  Benefits: o Scalable. o Works with multiple vendors/products through middleware. o Improved modularity of web-based systems. o No central point of failure.  Limitations: o Complexity. o New programming languages and techniques (adds stress for personnel). o More complex to update. CREATING AN ARCHITECTURE DESIGN  Lower costs often used to justify choice of client-server.  Recommended selection process:

o Expand nonfunctional requirement details. o Base architecture selection on the detailed nonfunctional requirements. DESIGNING THE ARCHITECTURE  Technical environment requirements, driven by business requirements, often define the application architecture.  If not, other nonfunctional requirements become important. HARDWARE AND SOFTWARE SPECIFICATION  Used if new hardware or software must be purchased.  Communicates project needs.  Actual acquisition of hardware and software usually left to a purchasing department – especially in larger firms.  Determine software needs: o OS, special purpose. o Training, warranty, maintenance, licensing needs.  Determine hardware needs: o Server(s), clients, peripherals, backup devices, storage components. o Minimum configuration needs. APPLICATION ARCHITECTURE  It’s specifies the technologies to be used to implement one or more (and possibly all) information systems in terms of DATA, PROCESS, and INTERFACE, and how these components interact across a network.  It serves as an outline or blueprint for detailed design and implementation. PHYSICAL DATA FLOW DIAGRAM (DFD)  It models the technical and human decisions to be implemented as part of an information system.  Communicate technical choices and other design decisions to those who will actually construct and implement the system. PHYSICAL PROCESSES  Definition: is either a processor (such as a computer or person), or a technical implementation of specific work to be performed (such as a computer program or manual process). o Logical processes may be assigned to physical processors such as PCs, servers, mainframes, people, or devices in a network. o A physical DFD would model that network structure.



Each logical process requires an implementation as one or more physical processes. Note that a logical process may be split into multiple physical processes: o To define those aspects that is performed by people or computers. o To define those aspects to be implemented by different technologies. o To show multiple implementations of the same process. o To add processes for exceptions and internal control (e.g. security).

PHYSICAL DATA FLOWS  A physical data flow represents any of the following: o The planned implementation of an input to, or output from a physical process. o A database command or action such as create, read, update, or 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 to modules or subroutines (represented as physical processes) in a program. PHYSICAL EXTERNAL AGENTS AND DATA STORES  Physical external agents are carried over from the logical DFD models: If scope changes, the logical models should be changed before the physical models are drawn.  A physical data store represents the planned implementation of one of: o A database. o A table in a database. o A computer file. o A tape or media backup of anything important. o A temporary file or batch. o Any type of non-computerized file. DATA ARCHITECTURES  Relational database. o Stores data in tabular form implemented as a table. o Each field is a column in the table. o Related records between two tables are implemented by intentionally duplicated columns in the two tables.  Distributed relational database: distributes or duplicates tables to multiple database servers located in geographically important locations.



Distributed relational database management system: is a software program that controls access to and maintenance of stored data in the relational format.

TYPES OF DATA OR DATABASE DISTRIBUTION  Data partitioning – distributes rows and columns of tables to specific database servers with little or no duplication between servers. o Vertical partitioning assigns different columns to different servers. o Horizontal partitioning assigns different rows to different servers.  Data replication – duplicates some or all tables (or parts of tables) on more than one database server. Database technology controls access to, and manages consistency of duplicated data across the servers. INTERFACE ARCHITECTURES  Batch inputs and outputs.  On-line inputs and outputs.  Remote batch.  Keyless data entry (and automatic identification).  Pen input.  Electronic Data Interchange (EDI).  Middleware. PROCESS ARCHITECTURES  A software development environment (SDE) is a programming language and tool kit for constructing information systems software applications. o SDEs exist for centralized computing. o SDEs exist for distributed presentation. o SDEs exist for two-tiered client/server. o SDEs exist for multi-tiered client/server. o SDEs exist for Internet and intranet client/server.  Many SDEs support clean layering, the requirement that the presentation, application, and data layers of an application be physically separated to allow components of each layer to be replaced or enhanced without affecting the other layers. APPLICATION ARCHITECTURE DESIGN STRATEGIES  The strategic or enterprise-oriented strategy: o Defines approved network, data, interface, and processing technologies and development tools.



o Defines a strategy for co-existence and/or integration of legacy systems and technologies. o Provides for an on-going process to review and improve the above. o Provides for a process to research and try emerging technologies that fall outside of the above. o Provides an approval process for variances from the above. The tactical or application-oriented strategy: o Defines architecture for each new system on an application-byapplication basis as needed. o Requires feasibility analysis for each application.

THE NETWORK ARCHITECTURE DFD  A network architecture is documented as a physical DFD that allocates processors (clients and servers) and possibly devices (machines and robots) across a network and establishes: o The connectivity between clients and servers. o Where users will interface with the processors.

SYSTEM DESIGN: INFORMATION SECURITY AND HUMANCOMPUTER INTERACTION INFORMATION SECURITY A. Introduction  Information Security aims to preserve: o Confidentiality. o Integrity. o Availability. o Accountability.  Control policy document guidelines: o Control context. o Controls in systems development and maintenance. o Controls in area of operation and maintenance. o Contingency planning measures. B. Hacking And Viruses  Organization connected to Internet vulnerable to hackers and viruses.  Advices: o Re-examine security policies. o Latest version of anti-virus software. o Upgrade access controls. o Carry out audits internally. C. Controls  Input. o Aim to ensure accuracy, completeness and reasonableness of data. o Input controls:  Format checks.  Limit checks.  Reasonable checks.  Check big numbers and data processing for online system.  Batch systems checking.  Batch control totals.  Hash totals.  Count number of items in the batch.  Output. o Ensure output is complete and accurate. o Gets to right people in a timely fashion. o Output controls:

 Control totals.  Spot checks.  Pre-numbering.  Others. o Processing controls: operation of an IS. o Storage controls.  Ensure no files damage.  Integrity of file data. o Audit controls.  Internal audit.  External audit. D. Contingency Planning  Steps: o Business impact analysis. o Preventive controls. o Recovery strategies. o Contingency plans. o Testing and training plan. o Regularly review and maintenance of the plan. HUMAN-COMPUTER INTERACTION A. Introduction  To communicate between user and computer system.  Outputs, inputs and dialogues forms.  Starting point to design: DFD of the system.  Designer proposes several options, users decide. Both should agree the system boundary. B. Input Design  Keyboard transcription from documents: data from forms, using keyboard/keypad.  Direct input from peripheral device: bar codes reader, OCR, pointing devices etc.  Direct entry through intelligent terminals: POS equipment has processing power, able to store data.  Input by speech: voice patterns as input. Validation  Types of validation: o Completeness check.

o o o o o

Format check. Range check. Check digit check. Consistency check. Database checks.

C. Output Design  Output technology: using printer, plotter, facsimile, speech.  Displaying information on a screen: needed content only, uncluttered and easy to read, information logically arranged.  Use of tables and graphics: detailed information, create graphs, pie charts, bar charts etc.  Specifying outputs: report generator which divide output into several sections; report and page header, footers etc. D. Dialogue Design  Website design. o Known user target, structure, site navigation. o Text, highlighting, color, animation used.  Dialogue types. o Prompt to user to get inputs etc. o Menus, Q and A, form-filling etc.  WIMP interfaces: Windows, Icons, Mouse, Pull-down menus.  User support. o If user has problems during selecting option. o Help document, manuals, training. E. Ergonomics  Ergonomics: o Study of physical and mental reactions people to their working environment. o Areas of study:  Anatomy: body dimensions, forces application.  Physiology: energy, effect to body.  Psychology: cognitive skills, perceptual-motor performance, behavior and interaction with others.  Not even with powerful technology, but meet business need, minimizing errors. F. Interface Design

 

Process of defining how the system will interact with external entities: customers, suppliers, other systems etc. Principles: o Layout. o Content awareness. o Aesthetics. o User experience. o Consistency. o Minimal user effort.

SYSTEM DESIGN: LOGICAL DATA DESIGN AND PHYSICAL DATA DESIGN LOGICAL DATA DESIGN A. Introduction  Data model provides a complete picture of data used by the organization.  Consists of: o Data entities. o Key fields for entities. o List of attributes for each entity. o Relationships between entities.  2 methods can be used to create logical data design in developing a system: o The Top-down view: entity modeling (Entity Relationship Diagram). o The Bottom-up view.  A process of normalizing a group of data.  Develop the logical data modeling using third normal form analysis.  Recommended to do both views. B. Top-down View: Entity Modeling  An entity must have the following properties: o It is of interest to the organization. o It occurs more than once. o Each occurrence is uniquely identified. o There is data to be held about the entity.  Entity. o Each entity has attributes. o An attribute is a data item that belongs to a data entity (a group of data items and can also be describes as a record). o Each entity also has a key that gives each occurrence of the entity a unique reference. o The key must be unique to uniquely identify each occurrence of data. o The key can be:  A simple key: if it consists of only one data item.  A complex key: if it consists of more than one field to uniquely identified the data.  3 possible relationships between entities: o One-to-one (1:1): modeled on a data structure.

o One-to-many (1:M). o Many-to-many (M:N).  Each entity shown on the data model.  Analyst: o Compiles the attributes. o Checks that the attributes support the relationships defined on the model.  Usually data model: o Produced in parallel with the process model. o Used to check the data stores accessed by the process model.  Logical data modeling provides a solid foundation for any system to be developed. C. Bottom-up View  Normalization of data is a process of: o Removing duplication between data. o Grouping related data to minimize interdependence between data groups.  Less interdependence that exists, less impact a data modification has.  To take data through third normal form analysis, we need to access all data stores in the system: o Can be done by collecting one copy of every type of form and report. o Screen printouts.  Forms – provide the input, reports – identify the output, screens – combination of the two.  Every data item that appears as input and output are listed.  Analyst must identify how these data items relate to each other.  Steps of modeling the data using third normal form. o Identify all system inputs and outputs.  List all data item and identify a unique key.  Remove repeating groups (first normal form).  Remove part-key dependences (second normal form).  Remove inter-data dependence (third normal form).  Label the relation. o Merge entities with the same key. o Apply third normal form tests. o Draw logical data model showing the relationships between entities. D. Merging Data Models  Final stage in logical data design.

Merges top-down view and bottom-up view. Identify any candidate data entities or relationships that need further investigation. E. Testing Data Models  To check it support business needs of organization.  Take each input to and output from system, copy of data model: draw onto data model the route through data structure required to produce each report and each input. F. Data Dictionary  To support a simple file-based system or complex database system.  Contains metadata – contains data about data.  

PHYSICAL DATA DESIGN A. Introduction  Logical data design and data model (implemented in physical design) are 2 different things: o Logical data design:  Constructed with no reference to physical constraints.  Provides a clear understanding of which data is important to an organization and how data is used to support business needs.  Physical data design is a process of modeling the data for the required physical system.  Used structured methods to differentiate between logical and physical data design.  Physical implementations might be: o A database. o A number of files.  Three main issues to look at before modeling the physical data starts: o Quantifying data in order to assess storage requirements. o Resolving any difficulties regarding the performances. o Collecting information on the hardware and software platforms to be used. B. Quantifying Data Storage Requirements  An assessment of the volume of data to be stored and transferred will have been made before choose the hardware.  Normal practice is to look at the current system: o Using hard facts about past growth and the present, coupled with strategic forecasts can produce initial storage volume estimates.

o Also can use an alternative source of data from within the system: existing data files and archives. C. Assessing Required System Performance  Performance will be define in terms of: o Transaction processing time. o Throughput for a volume of data.  Factors affecting system performance: o Quantity of data stored. o Number of users logged on. o Number of peripheral devices actives. o Speed of the network. o Volume of traffic.  Asking the users for initial estimates of the data volumes is a good starting to discuss system performances: involves the users in the process and get more feedback on functionalities they want.  The quantity of data stored.  Response time can be affected by: o Number of users. o The network speed and topology.  Ethernet.  Token ring. o Types of application.  Overheads: o Data-handling mechanisms. o Restart and recovery of the system. o Data integrity. o Maintaining audit trails. D. Choosing Hardware/Software Platform  Done after the required system performance is understood.  Physical data design objectives are to minimize: o Storage space. o Runtime processor usage. o Access times. o Development effort. o Reorganized data when modifying it.  3 questions need to be answer in investigating physical environment: o How much data can the system store and in what way? o How fast does the system transfer data?

o How is data handling affected by the programming language used?  Data storage: o Influenced by block or paged size used by the operating system. o Block or page size implementation depends on:  Operating system or DBMS used.  User group size.  CPU space the blocks or pages take up.  Data transfer: o Operating system’s data-handling mechanisms perform a physical data access during reading or writing data. o Hardware transfers the physical access (block). o Software access transfers the data (records in blocks).  Programming language: different language will take different lengths to perform the same instruction. E. Moving From Logical To Physical Design  Done after having resolved the hardware and software issues.  Inputs to the process are relevant information about the required system and the targeted hardware and software.  Process involved: o Creating a physical data design. o Data access diagrams. o Refining the physical data design.  Creating a physical data design. o The transformation steps:  File system: each entity (logical model) becomes a record type, each attribute of entity become data field and relationship maintained by identifying keys handled by application program.  Database system: each entity becomes a table and each attribute become a column and relationship between entities are maintained by using database pointers.  Data access diagrams: o A model to show how each transaction in a system access the database. o Starts with creating a logical access map that shows the path each transaction will take to obtain the data it requires. o Indicates the extent to which the tables need to be ‘de-normalized’ to improve the performance.  Refining physical data design:

o Main problem – optimizing one area can negatively affect another. o Solutions:  Packing the data.  Create two versions of file.  Change the accessing method.

SYSTEM IMPLEMENTATION CONSTRUCTION  Phases: o Build and test network. o Build and test database. o Install and test new software packages. o Write and test new programs. o Write documentation.



Designing tests: test planning. o Test data: contain both correct and error data. o Stub testing: test performed on a subset of program. o Test plan: detailed procedures; how, when, who and what.





Sequence of tests: o Unit tests.  Tests each module or program to assure that it performs its function.  Identify and eliminate errors.  2 approaches:  White-box testing: looks inside the module at actual code.  Black-box testing: focuses on whether the unit meets requirements stated in specification. o Integration tests.  Tests the interaction of 2 or more modules to assure that they work together.  4 approaches:  User interface testing.  Use scenario testing.  Data flow testing.  System interface testing. o System tests.  Requirements testing: ensures that integration did not cause new errors.  Usability testing: tests how easy and error-free the system is in use.  Security testing: assures that security functions are handled properly.  Performance testing: assures that the system works under high volumes of activity.  Documentation testing: analysts check the accuracy of documentation. o Acceptance tests.  To confirm that system is complete, should meets business needs that prompted the system to be developed and is acceptable to users.  2 types of acceptance tests:  Alpha testing: performed by users to assure they accept the system; frequently repeats earlier tests.  Beta testing: uses real data, not test data. Actual users monitor for errors or needed improvements. Documentation o System documentation: intended to help programmers and analysts understand and maintain the system after it is installed. o User documentation:  Intended to help users operate the system.  Three types:

 Reference documents.  Procedure manuals.  Tutorials. o Types of user:  Reference documents: to be used when user needs to learn how to perform specific function.  Procedure manuals: describe how to perform specific tasks.  Tutorials: teach people how to use major components of the system. o Topics:  Use the active voice.  Minimize use of “to be” verbs.  Use consistent terms.  Use simple language.  Use friendly language.  Use parallel grammatical structure.  Use steps correctly.  Use short paragraphs. IMPLEMENTATION A. Implementation Change

B. Conversion





Conversion style: o Direct conversion: the new system instantly replaces the old. o Parallel conversion: for a time both old and new systems are used. The old is abandoned when the new is proven fully capable. Conversion location:

o Pilot conversion: one or more locations are converted to work out bugs before extending to other locations. o Phased conversion: locations are converted in sets. o Simultaneous conversion: all locations are converted at the same time. 



Conversion modules: o Whole system conversion: all modules converted in one step. o Modular conversion: when modules are loosely associated, they can be converted one at a time. Factors to consider for conversion strategy’s selection: o Risk: seriousness of consequences of remaining bugs. o Cost:  Parallel requires paying for two systems for a period of time.  Simultaneous requires more staff to support all locations. o Time: parallel, phased, and modular require more time.

MAINTENANCE  Activities: o Provide support: assistance in using the system. o Provide maintenance:  Repair or fix discovered bugs or errors.  Add minor enhancements to provide added value. o Assess the project:  Analyze what was done well.  Discover what activities need improvement in the future.  Types of support: o On-demand training at time of user need. o Online support: frequently asked questions (FAQ). o Help desk:  Phone service for known issues.  Level 2 support.  System maintenance tasks:  Validate the problem.  Benchmark the program: a test script is a repository of test cases to be executed against all program revisions.  Study and debug the program to fix: • Poor program structure. • Unstructured (or poorly structured) logic.

• Prior maintenance (so-called “ripple” effects). • Dead code. • Poor or inadequate documentation.  Test the program: version control is a process whereby a librarian program keeps track of changes made to programs to facilitate backtracking.  System enhancement tasks:  Analyze enhancement request.  If appropriate, make quick fix.  Recover the existing physical system: • Database recovering and restructuring. • Program analysis, recovery, and restructuring. • Software metrics are mathematically proven measurements of software quality and productivity. • Measurement of control flow knots (complexity of logic). • Measurement of cycle complexity. • Code reorganization of modularity and/or logic. • Code conversion from one language to another. • Code slicing to create reusable software components or objects.  Repeat appropriate phases and tasks of the original development methodology.

WEB-BASED APPLICATION PUBLISH AND PROMOTION  Web: a place where businesses reach audiences.  Related with: o Web presence:  Involved ongoing commitment to making a web serve its audience.  May include spider databases, listings in indexes etc. o Customer service:  A powerful way to support customers in purchasing or using non-Web products and services.  Publish and Promotion. o Sponsorship: users gain benefits of this resource at no cost. o Special promotions: use direct promotions thru website. o Advertising: offers businesses a way to get their web in the attention field of potential customers. o Publishing:  Act of making work widely known and available.  More than printing – ensure quality, accuracy, timeliness and relevance to user needs. INNOVATION  Definition: is a creative, dynamic process, in monitoring and understanding user needs and developing web structures to meet those needs.  Continuous process, involve all team members.  Techniques: o Monitor user’s information environment.  Web developers:  Should be aware of audience’s professional societies, trade shows, conventions, periodicals, related Net resources, and changing interests.  Should be aware of how their users perceive the web. o Continuously improve quality.  Quality web information: correct, accessible, usable, understandable, and meaningful.  To increase quality based on: content, presentation, discovery, innovation, testing and evaluation, usability testing, feedback, iterative analysis.