um4bgs.netlify.com

1. System Analysis And Design Pdf
2. Systems Analysis And Design Methods
3. User Training In System Analysis And Design
4. System Analysis And Design Questions

Welcome to the domain of system analysis, design, and development or, in the case of the scenar- ios above, the potential effects of the lack of System Engineering (SE). Everyday people acquire and use an array of systems, products, and services on the pretense. 100 Community Place, Crownsville, MD 21032. 300-301 West Preston Street, Baltimore MD 21201. 410-697-9700 - Dial 7-1-1 to place a call through Maryland Relay. Systems Analysis and Design/Introduction. From Wikibooks, open books for an open world. Planning the system requires the user to define what the problem is. Effective Systems Analysis & Design Guide Appendix C System Analysis & Design Report 1 1 SYSTEM ANALYSIS AND DESIGN REPORT (a) The System Analysis and Design (“SA&D”) phase signifies the commencement of system implementation. The objectives of this phase are: i) to investigate and understand the user and technical requirements. User Manual System Analysis And Design Pdf Glover Read/Download Power System Analysis and Design, Fifth Edition by J. Duncan Glover, Mulukutla S. Sarma, Thomas Overbye Textbook and Solution Manuals Free (PDF/ePUB). Yz250 user guide in digital format, so the resources that you find are reliable. (PDF) Power System Analysis And Design 5th.

• 3SDLC Phases
• 4Systems Development Methods

Information Systems Analysis and Design-Development Life Cycle[edit]

Businesses and organizations use various types of information systems to support the many processes needed to carry out their business functions. Each of these information systems has a particular purpose or focus, and each has a life of its own. This “life of its own” concept is called the systems development life cycle or SDLC, and it includes the entire process of planning, building, deploying, using, updating, and maintaining an information system. The development of a new information system involves several different, but related activities. These activities, or phases, usually include planning, analysis, design, implementation, and maintenance/support. In other words, SDLC is a conceptual model that guides project management in information system development.^[1]

According to author Harold Kerzner, Ph.D. there are sixteen points that will lead to project management maturity:

1. Adopt a project management method and use it consistently.
2. Implement a philosophy that drives the organization toward project management maturity and communicate it to everyone.
3. Commit to developing effective plans at the beginning of each project.
4. Minimize scope changes by committing to realistic objectives.
5. Recognize that cost and schedule management are inseparable.
6. Select the right person as a project manager.
7. Provide executives with project sponsor information and not project management information.
8. Strengthen involvement and support of all appropriate management.
9. Focus on deliverables rather than resources.
10. Cultivate effective communication, cooperation, and trust.
11. Share recognition for project success.
12. Eliminate nonproductive meetings.
13. Focus on identifying and solving problems early, quickly, and cost effectively.
14. Measure progress periodically.
15. Use project management software as a tool; Not as a substitute for effective planning or interpersonal skills.
16. Establish an all-employee training program with periodic updates based upon documented lessons learned.

Information Security in the Systems Development Life Cycle[edit]

As NIST (National Institute of Standards and Technology) points out, including security early in the SDLC will usually result in less expensive and more effective security than adding it to an operational system.The following questions should be addressed in determining the security controls that will be required for a system:

• How critical is the system in meeting the organization's mission?
• What are the security objectives required by the system, e.g., confidentiality, integrity, and availability (CIA)?
  • Confidentiality refers to limiting access to information to authorized users only-- 'the right people' -- and preventing access by unauthorized ones -- 'the wrong people.'
  • Integrity refers to the trustworthiness of information resources. It includes the concept of 'data integrity' -- namely, that data have not been changed inappropriately, whether by accident or deliberately malign activity. It also includes 'origin' or 'source integrity' -- that is, that the data actually came from the person or entity you think it did, rather than an impostor.
  • Availability refers to the availability of information resources. An information system that is not available when you need it is almost as bad as none at all.
• What regulations and policies are applicable in determining what is to be protected?
• What are the threats that are applicable in the environment where the system will be operational?

This section describes a number of security considerations that will help integrate information security into each phase of the SDLC.

Planning

During this first phase of the development life cycle, security considerations are key to diligent and early integration, thereby ensuring that threats, requirements, and potential constraints in functionality and integration are considered. At this point, security is looked at more in terms of business risks with input from the information security office. For example, an agency may identify a political risk resulting from a prominent website being modified or made unavailable during a critical business period, resulting in decreased trust by citizens. Key security activities for this phase include:

• Initial delineation of business requirements in terms of confidentiality, integrity, and availability;
• Determination of information categorization and identification of known special handling requirements to transmit, store, or create information such as personally identifiable information; and
• Determination of any privacy requirements.

Analysis

This section addresses security considerations unique to the second SDLC phase. Key security activities for this phase include:

• Conduct the risk assessment and use the results to supplement the baseline security controls;
• Analyze security requirements;
• Perform functional and security testing;
• Prepare initial documents for system certification and accreditation;

Although this section presents the information security components in a sequential top-down manner, the order of completion is not necessarily fixed. Security analysis of complex systems will need to be iterated until consistency and completeness is achieved.

Design

During this phase of SDLC, the security architecture is designed.

Implementation

During this phase, the system will be installed and evaluated in the organization’s operational environment. Key security activities for this phase include:

• Integrate the information system into its environment;
• Plan and conduct system certification activities in synchronization with testing of security controls; and
• Complete system accreditation activities.

Maintenance/Support

In this phase, systems are in place and operating, enhancements and/or modifications to the system are developed and tested, and hardware and/or software is added or replaced. The system is monitored for continued performance in accordance with security requirements and needed system modifications are incorporated. The operational system is periodically assessed to determine how the system can be made more effective, secure, and efficient. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs while maintaining an agreed-upon risk level. When necessary modifications or changes are identified, the system may reenter a previous phase of the SDLC. Key security activities for this phase include:

• Conduct an operational readiness review;
• Manage the configuration of the system ;
• Institute processes and procedures for assured operations and continuous monitoring of the information system’s security controls; and
• Perform reauthorization as required.

DisposalUsually, there is no definitive end to a system. Systems normally evolve or transition to the next generation because of changing requirements or improvements in technology. System security plans should continually evolve with the system. Much of the environmental, management, and operational information should still be relevant and useful in developing the security plan for the follow-on system. The disposal activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future, if necessary. Particular emphasis is given to proper preservation of the data processed by the system so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access. Key security activities for this phase include:

• Build and Execute a Disposal/Transition Plan;
• Archive of critical information;
• Sanitization of media; and
• Disposal of hardware and software.

SDLC Phases[edit]

Planning[edit]

Planning the system requires the user to define what the problem is. The planning may also include how the user would like to solve the problem. Defining the scope of the problem is also important in this stage as well. Defining the scope helps to prevent the project from scope creep. Once the problem is determined, and one or more solutions have been selected, planning to implement the solution begins. Multiple scenarios may be enacted to determine the best course of action for implementing the system.

Course of action should be well documented and take into consideration a schedule showing anticipated start and completion times of activities (milestones) leading to the objectives, knowing expenditures required to achieve objectives, scheduling regular status reviews (are we on course?), anticipating any organizational restructuring to accommodate the objectives, anticipating and planning for mitigation of risks that may hinder achievements, implementing policies and procedures for decision making, and defining a standard level of performance.

Within the planning according to the John Sazinger 'five of the main activities must exist' as he explain in his book the fives activities should include:

• Define the problem
• Produce the project schedule
• Confirm project feasibility
• Staff the project
• Launch the project^[3]

Why do plans fail? Some of the many reasons are:

• Goals/specifications are not understood.
• Objectives are too extensive for the time allotted.
• Budgets were not accurate.
• Project is understaffed or under skilled.
• Status reviews were not scheduled or insufficient.
• Poor morale (no commitment).

One of the most difficult decisions in planning is to know when to pull the plug on a project. This will require an effective control and monitoring system. If you cannot monitor a system you cannot control it. No organization wants to admit failure but there may come a point when a project can no longer be salvaged. This is especially critical with Information Technology projects because of rapidly changing technologies. Most managers are reluctant to prematurely terminate a project as careers and egos are at stake. The fallacy of sunk costs may play a role as well. The result is that projects continue beyond the point of no return. To avoid this problem, monitor and control systems must be put in place early during the planning stage. It is critical to define and enforce milestones where a project will be terminated if necessary. A saving grace is that because a project is terminated it doesn't make it a complete failure. Excessive cost are saved for the organization and management can walk away with lessons learned that can be applied to the next project.In general there are two types of monitoring 'INFORMAL' and 'FORMAL'. Informal are typically general meetings, email, and observing. The formal include status reports, scheduled milestones, audits, reviews, and benchmarks. The formal reviews are generally more costly and are used during system development processes. Both systems can be used in combination and involve the questions: 'what performance metrics to use' and 'how often do reviews occur'? Attention and energy must be focused on identifying and correcting out-of-control processes.

Analysis[edit]

The analysis phase involves gathering requirements for the system. At this stage, business needs are studied with the intention of making business processes more efficient. The system analysis phase focuses on what the system will do in an effort that views all stakeholders, as viable sources of information. In the analysis phase, a significant amount of time is spent talking with stakeholders and reviewing the stakeholder’s input. Common stakeholders for IT projects are:

• Architecture office
• Testing & certification office
• Records management team
• Application support group

Once stakeholders have been recognized, the gathering and analysis of the requirements can begin.Requirement gathering must be related to business needs or opportunities. Requirement analysis involves capturing requirements and analyzing requirements. Capturing requirements is communicating with stakeholders to agree on what the requirements are. Analyzing requirements is using standard tools to produce a baseline of the requirements. Once the stakeholders concur on the requirements, the baseline is created and becomes the formal requirement source.^[4]

Within this analysis phase, the analyst is discovering and fact finding. Along with meeting with stakeholders,the analyst must meet with end users to understand what the user's needs are and to learn about problems that affect the current system in order to assist with designing a new and more efficient system. There are several activities that must occur within the analysis phase:^[5]

• Gather Information
• Define the new system's requirements
• Build prototypes for the new system
• Prioritize requirements
• Evaluate alternatives
• Meet with management to discuss new options

Design[edit]

The design phase is concerned with the physical construction of the system. Included are the design or configuration of the network (hardware, operating system, programming, etc.), design of user interfaces (forms, reports, etc.), design of system interfaces (for communication with other systems), and security issues. It is important that the proposed design be tested for performance, and to ensure that it meets the requirements outlined during the analysis phase. In other words, the main objective of this phase is to transform the previously defined requirements into a complete and detailed set of specifications which will be used during the next phase. Some of the activities that need to take place during the design phase are:

• Design the application
• Design and integrate the network
• Design and integrate the database
• Create a contingency plan
• Start a Maintenance, Training and Operations plan
• Review the design
• Articulate the business processes and procedures
• Establish a transition strategy
• Deliver the System Design Document
• Review final design

Implementation[edit]

Initiating a project first requires the documenting of needs or requirements.Clear objectives should be developed from this study with reasons for selecting the objectives.Deliverables then need to be documented along with the project scope. Scope can be refined during this initialization process. Assumptions and constraints should also be documented. All stakeholders should be involved in this process. This information will become the projects charter and the basis for initiating the project. The project then follows the PLAN-DO CHECK-ACT cycle (as defined by Shewhart and modified by Deming, in the ASQ Handbook, pages 13-14, American Society for Quality, 1999). The results of each cycle will be linked to the next as input. This process should increase the likelihood of deliverable acceptance.

In order to achieve deliverable of acceptance and meeting of objectives, the new system being built must be tested. Aligned with this, the end users must be fully trained so the company will benefit from the new system. There are five activities that must be performed during the implementation phase: ^[6]

• Construct software components
• Verify and test
• Convert Data
• Training end users and document the system
• Install the system

Maintenance/Support[edit]

Maintenance and support covers all activities that are required once the system is in place. Activities include, but are not limited to:

• Phone support for users
• Physical onsite user support
• Resolving any issues that may arise with the new system
• Providing support materials/tools for users

The amount of support required may be determined based on the system. If it is a large system involving many different departments, maintenance and support may be needed for a longer time. If is a smaller system, maintenance and support may only be needed for a short time.

Systems Development Methods[edit]

This section discusses the most popular methods for developing computer-based information systems. A popular, traditional method is called structured analysis, but a newer strategy called object-oriented analysis and design also is used widely. Each method offers many variations.Some organizations develop their own approaches or adopt methods offered by software vendors or consultants. Most IT experts agree that no single, best system development strategy exists. Instead, a systems analyst should understand the alternative methods and their strengths and weaknesses.

Structured Analysis

Structured analysis is a traditional systems development technique that is time-tested and easy to understand. Because it describes the processes that transform data into useful information, structured analysis is called a process-centered technique. In addition to modeling the processes, structured analysis includes data organization and structure, relational database design, and user interface issues. Structured analysis uses a series of phases, called the systems development life cycle(SDLC) to plan, analyze, design, implement, and support an information system.Structured analysis relies on a set of process models that graphically describe a system. Process modeling identifies the data flowing into a process, the business rules that transform the data, and the resulting output data flow.

Basically, the structured analysis technique requires that the developer defines three things: 1) what processing the system needs to do, 2) what data the system needs to store, and 3) what inputs and outputs will be needed in order for the system to work as a whole. In order to see how all these functions work together, the data flow diagram (DFD) is needed to show the inputs, processes storage, and outputs. ^[7]

Object-Oriented Analysis

Whereas structured analysis regards processes and data as separate components, object-oriented analysis combines data and the processes that act on the data into things called objects. Object-oriented analysis defines the different types of objects that are doing the work and interacting with one another in the system and by showing user interactions, called use cases, are required to complete tasks. Systems analysts use O-O methods to model real-world business processes and operations. The result is a set of software objects that represent actual people, things, transactions, and events. Using an O-O programming language, a programmer then transforms the objects into reusable code and components.

O-O analysis uses object models to represent data, behavior, and by what means objects affect other objects, By describing the objects(data) and methods (processes) needed to support a business operation, a system developer can design reusable components that allow faster system implementation and decreased development cost.Many analysts believe that, compared with structured analysis, O-O methods are more flexible,efficient,and realistic in today`s dynamic business environment. The object-oriented approach has many benefits, they provide naturalness and reuse. The approach is natural because people tend to think about things in terms of tangible objects and because many systems within an organization uses the same objects (i.e. windows, dialog boxes, menus, and buttons) the classes can be used repeatably. ^[8]Also, O-O analysis provides an easy transition to popular O-O programming languages, such as Java and C++.

Other Development Strategies

In addition to structured analysis and O-O methods, there are other systems development techniques created by individual companies.For example, Microsoft has developed an approach called Microsoft Solutions Framework(MSF).Using MSF, you design a series of models, including a risk management model, a team model, model has a specific purpose and outputs that contribute to the overall design of the system.Although the Microsoft process differs from the SDLC phase-oriented approach, MSF developers do the same kind of planning,ask the same kinds of fct-finding questions,deal with the same kinds of design and implementation issues, and resolve the same kinds of problems. MSF uses O-Oanalysis and design concepts, but also examines a broader business and organizational context that surrounds the development of an information system^[9].

Ad Hoc[edit]

Ad hoc, is something that one can use to do a specific task but the process that was used cannot be used for another process. It's like doing some work on the fly no major planning is required. The whole project cannot run at that level. One can use a template to create a project but with Ad Hoc, it is not possible. As whole the term 'Ad hoc' means for this purpose only.

Structured / Waterfall[edit]

The waterfall model is a popular version of the systems development life cycle approach that is considered farthest to the left on the predictive/adaptive scale for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model (mostly predictive) describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Once a phase of development is completed, the development proceeds (drops over the waterfall) into the next phase and there is no turning back.

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. This pure waterfall model makes it very difficult because there is no room for error and that is virtually impossible when dealing with humans.

However, on the right side of the predictive/adaptive scale we are able to make modifications in different phases; this is called a modified waterfall model. In the modification waterfall model, phases of projects will overlap influencing and depending on each other. For instance, if the analysis phase is completed and the project moves into the design phase but something was left out in the requirements in the analysis phase making it hard to implement in the design phase then additional project management tasks need to be added causing an overlap.

Efficiency is another reason why overlapping might occur. Some activities depend on the results of prior work. In the project planning phase, there might be some additional project management tasks that need to be added, in the analysis phase, additional analysis activities may be added, and in the design phase, additional design activities may be added. Basically, the modified waterfall model is a more efficient model to use. Today, many information systems and projects are based on the modified waterfall model. ^[10]

Prototyping[edit]

Prototyping is the process of building a model of a system. In terms of an information system, prototypes are employed to help system designers build an information system that is intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle.

During this analysis phase, prototyping usually referred to as the discovery prototypes are very important because it is geared for understanding the users’ needs. ^[11] The prototypes are not built for full functionality but are built to see if the prototypes are feasible for what goals the business is trying to achieve. Sometimes, end users are trying to improve on the business processes or simplify a procedure. In any case, by using trial reports and screens will help analysts explain to end users’ how this can update and improve their business procedures. If the business decides to implement new technology, then discovery prototyping can help with whether to implement the new technology and to see if it will align with or will be feasible to the company’s business need.

Prototyping comes in many forms - from low tech sketches or paper screens(Pictive) from which users and developers can paste controls and objects, to high tech operational systems using CASE (computer-aided software engineering) or fourth generation languages and everywhere in between.
Advantages of prototyping include;

• Reduction of developments time and cost
• User involvement
• Quantifiable user feedback
• Facilitates system implementation
• Higher user satisfaction
• Exposure to potential future enhancements for developers

On the other hand disadvantages include;

• Insufficient analysis
• Expectation of ultimate system performance to be the same as the prototype by users
• The temptation of implementation before the final product
• Attachment to prototypes by developers
• Incomplete documentation

The best reason for prototyping is that it lets a programmer work with a client so that the system will satisfactorily meet the client's expectations. However this is a double edge sword. The problem is that most of the time a protype is a clunky, quick approach to solving a problem that will most often need major reconstruction and most programmers are hesitant at best to throw away their code for a new stream line approach. Consequently you end up with code associated with patch after patch that is difficult to maintain. Also the give and take with the client during prototyping may lead to scope creep within the project. Every time you think you are finished there will be some improvement or new functionality suggested. This will stop any sign off on the project. To avoid this make sure that there is a project plan with a noted number of iterations specified and a cut off date for adding new functionality.

Infineon-b 620887-001 user manual download. Local pick up is NOT available. Please leave a note if you want drop ship service.

Incremental/Iterative[edit]

Incremental approach is dividing the project in various [as much as possible] independent parts and developing these sub-parts at the same rate/ different rate and integrating them when ready. Example is development of a social networking website with parts like member registration, sign in, forgot password, member profile, search members, friends list, blog, blog search, photos, photo search and messaging. Depending on the product owners requirements, development team can start with member registration, sign in, member profile and search members.These can be completed and integrated into a common repository as they become ready. Once these parts are ready, next set is picked. It is also possible that all the parts can be simultaneously worked on and integrating them when ready in the central repository.^[13]
According to Alistair Cockburn, Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system.^[14]

Spiral Model[edit]

The spiral model is one of the newer adaptive approaches to the SDLC. Basically, an adaptive approach is a development approach which will include project activities such as plans and models that are adjusted as the project progresses. The spiral model includes several adaptive features that will cycle over and over through the development of the project until the completion of the project. ^[15]

The spiral life cycle is shown as a spiral model that begins with the planning phase first from the center (inward) of the spiral, eventually working its way outward, over and over again, until completion of the project. The planning phase will include activities such as feasibility study, a survey of user's requirements, overall design choice, generation of implementation alternative, and implementation strategy. The purpose of this phase is to have enough information to build a prototype.

Rapid Application Development (RAD)[edit]

Rapid Application Development makes use of tools to facilitate the development of systems to meet aggressive time lines.[1] The key emphasis is to reuse the created working models [prototypes/ models/ user interfaces/ wire-frames][2] Key objective is to reduce the time spent on analysis, this is achieved by use of working models for design

Agile Development Methods[edit]

Modeling[edit]

Modeling promotes better understanding of requirements. Visual Modeling helps us understand and organize complex endeavors. Notation plays an important part in any model. It has been said that if you can not document the artifacts of your work, you will probably fail. The Unified Modeling Language (UML) provides a very robust notation, which grows from analysis to design. It is a language used to specify, visualize, and document the artifacts of an object-oriented system under development. You can model just about any type of application running on any type of hardware, operating system, programming language, and network with UML. It is a natural fit for Oject-Oriented languages and environments but you can use it to model non Object-Oriented applications as well.

Object-Oriented Development[edit]

Before coding, there should be a understanding on pseudo, algorithm and the high level language(C, C++, C#, Java, etc.) you want to make use of. This will aid you to designing a system for a specific purpose. Modern programming usually requires an object oriented approach to software development. Object-oriented development attempts to use the classifications, relationships, and properties of objects to aid in program development. The object can be any item or concept. The objects contain both attributes and operations that interact to meet a specific need. Attributes are properties that relate to the object and operations are methods or actions that the object can perform to modify itself or data. Access to the data within an object is available only via the objects operation also known as the interface to the object. An object's functionality is bound to the data it uses. You can easily alter the details controlling how the object is implemented to improve performance , add new features, or fix bugs without changing the interface. This allows the other parts of the project to access the object and remain unaltered.

Goal[edit]

Overview[edit]

This book is organized in 5 major units:

Questions[edit]

What are the categories of technology requirements of an information system?

Key Terms[edit]

References[edit]

1. ↑Satzinger, J. W., Jackson, R. B., & Burd, S. (2007). Systems Analysis & Design In A Changing World, Fourth Edition. Boston: Thomson Course Technology.
2. ↑Kerzner, H. (2006). Project Management - A Systems Approach to Planning, Scheduling, and Controlling
3. ↑Systems Analysis & Design 5th Edition
4. ↑The Farm Service Agency Enterprise Architecture
5. ↑Satzinger, Jackson, Burd, Systems Analysis & Design In A Changing World; Fifth Edition
6. ↑Satzinger, Jackson, Burd, Systems Analysis & Design In a Changing World; Fifth Edition
7. ↑Satzinger, Jackson, Burd; Systems analysis & Design In a Changing World; fifth Edition
8. ↑Satzinger, Jackson, Burd; Systems analysis & Design In a Changing World; Fifth Edition
9. ↑Systems Analysis & Design 5th Edition
10. ↑Satzinger, Jackson, Burd, Systems Analysis and Design In A changing World; Fifth Edition
11. ↑Satzinger, Jackson, Burd; Systems Analysis & Design In A Changing World; Fifth Edition
12. ↑http://www.umsl.edu/~sauterv/analysis/prototyping/proto.html
13. ↑http://www.agilecollab.com/incremental-and-iterative-software-development
14. ↑http://alistair.cockburn.us/Incremental+versus+iterative+development#discussion
15. ↑Satzinger, Jackson, Burd; Systems Analysis & Design In A Changing Word; Fifth Edition

• System Analysis and Design Tutorial

• System Analysis & Design Resources

• Selected Reading

System design is the phase that bridges the gap between problem domain and the existing system in a manageable way. This phase focuses on the solution domain, i.e. “how to implement?”

It is the phase where the SRS document is converted into a format that can be implemented and decides how the system will operate.

In this phase, the complex activity of system development is divided into several smaller sub-activities, which coordinate with each other to achieve the main objective of system development.

Inputs to System Design

System design takes the following inputs −

• Statement of work

• Requirement determination plan

• Current situation analysis

• Proposed system requirements including a conceptual data model, modified DFDs, and Metadata (data about data).

Outputs for System Design

System design gives the following outputs −

• Infrastructure and organizational changes for the proposed system.

• A data schema, often a relational schema.

• Metadata to define the tables/files and columns/data-items.

• A function hierarchy diagram or web page map that graphically describes the program structure.

• Actual or pseudocode for each module in the program.

• A prototype for the proposed system.

Types of System Design

Logical Design

Logical design pertains to an abstract representation of the data flow, inputs, and outputs of the system. It describes the inputs (sources), outputs (destinations), databases (data stores), procedures (data flows) all in a format that meets the user requirements.

While preparing the logical design of a system, the system analyst specifies the user needs at level of detail that virtually determines the information flow into and out of the system and the required data sources. Data flow diagram, E-R diagram modeling are used.

Physical Design

Physical design relates to the actual input and output processes of the system. It focuses on how data is entered into a system, verified, processed, and displayed as output.

It produces the working system by defining the design specification that specifies exactly what the candidate system does. It is concerned with user interface design, process design, and data design.

It consists of the following steps −

• Specifying the input/output media, designing the database, and specifying backup procedures.

• Planning system implementation.

• Devising a test and implementation plan, and specifying any new hardware and software.

• Updating costs, benefits, conversion dates, and system constraints.

Architectural Design

It is also known as high level design that focuses on the design of system architecture. It describes the structure and behavior of the system. It defines the structure and relationship between various modules of system development process.

Detailed Design

It follows Architectural design and focuses on development of each module.

Conceptual Data Modeling

It is representation of organizational data which includes all the major entities and relationship. System analysts develop a conceptual data model for the current system that supports the scope and requirement for the proposed system.

The main aim of conceptual data modeling is to capture as much meaning of data as possible. Most organization today use conceptual data modeling using E-R model which uses special notation to represent as much meaning about data as possible.

Entity Relationship Model

It is a technique used in database design that helps describe the relationship between various entities of an organization.

Terms used in E-R model

• ENTITY − It specifies distinct real world items in an application. For example: vendor, item, student, course, teachers, etc.

• RELATIONSHIP − They are the meaningful dependencies between entities. For example, vendor supplies items, teacher teaches courses, then supplies and course are relationship.

• ATTRIBUTES − It specifies the properties of relationships. For example, vendor code, student name. Symbols used in E-R model and their respective meanings −

The following table shows the symbols used in E-R model and their significance −

Three types of relationships can exist between two sets of data: one-to-one, one-to-many, and many-to-many.

File Organization

It describes how records are stored within a file.

There are four file organization methods −

• Serial − Records are stored in chronological order (in order as they are input or occur). Examples − Recording of telephone charges, ATM transactions, Telephone queues.

• Sequential − Records are stored in order based on a key field which contains a value that uniquely identifies a record. Examples − Phone directories.

• Direct (relative) − Each record is stored based on a physical address or location on the device. Address is calculated from the value stored in the record’s key field. Randomizing routine or hashing algorithm does the conversion.

• Indexed − Records can be processed both sequentially and non-sequentially using indexes.

Comparision

File Access

One can access a file using either Sequential Access or Random Access. File Access methods allow computer programs read or write records in a file.

Sequential Access

Every record on the file is processed starting with the first record until End of File (EOF) is reached. It is efficient when a large number of the records on the file need to be accessed at any given time. Data stored on a tape (sequential access) can be accessed only sequentially.

Direct (Random) Access

Records are located by knowing their physical locations or addresses on the device rather than their positions relative to other records. Data stored on a CD device (direct-access) can be accessed either sequentially or randomly.

Types of Files used in an Organization System

Following are the types of files used in an organization system −

• Master file − It contains the current information for a system. For example, customer file, student file, telephone directory.

• Table file − It is a type of master file that changes infrequently and stored in a tabular format. For example, storing Zipcode.

• Transaction file − It contains the day-to-day information generated from business activities. It is used to update or process the master file. For example, Addresses of the employees.

• Temporary file − It is created and used whenever needed by a system.

• Mirror file − They are the exact duplicates of other files. Help minimize the risk of downtime in cases when the original becomes unusable. They must be modified each time the original file is changed.

• Log files − They contain copies of master and transaction records in order to chronicle any changes that are made to the master file. It facilitates auditing and provides mechanism for recovery in case of system failure.

• Archive files − Backup files that contain historical versions of other files.

Documentation Control

System Analysis And Design Pdf

Documentation is a process of recording the information for any reference or operational purpose. It helps users, managers, and IT staff, who require it. It is important that prepared document must be updated on regular basis to trace the progress of the system easily.

After the implementation of system if the system is working improperly, then documentation helps the administrator to understand the flow of data in the system to correct the flaws and get the system working.

Programmers or systems analysts usually create program and system documentation. Systems analysts usually are responsible for preparing documentation to help users learn the system. In large companies, a technical support team that includes technical writers might assist in the preparation of user documentation and training materials.

Advantages

• It can reduce system downtime, cut costs, and speed up maintenance tasks.

• It provides the clear description of formal flow of present system and helps to understand the type of input data and how the output can be produced.

• It provides effective and efficient way of communication between technical and nontechnical users about system.

• It facilitates the training of new user so that he can easily understand the flow of system.

• It helps the user to solve the problems such as troubleshooting and helps the manager to take better final decisions of the organization system.

• It provides better control to the internal or external working of the system.

Types of Documentations

When it comes to System Design, there are following four main documentations −

• Program documentation
• System documentation
• Operations documentation
• User documentation

Program Documentation

• It describes inputs, outputs, and processing logic for all the program modules.

• The program documentation process starts in the system analysis phase and continues during implementation.

• This documentation guides programmers, who construct modules that are well supported by internal and external comments and descriptions that can be understood and maintained easily.

Operations Documentation

Systems Analysis And Design Methods

Operations documentation contains all the information needed for processing and distributing online and printed output. Operations documentation should be clear, concise, and available online if possible.

It includes the following information −

• Program, systems analyst, programmer, and system identification.

• Scheduling information for printed output, such as report, execution frequency, and deadlines.

• Input files, their source, output files, and their destinations.

• E-mail and report distribution lists.

• Special forms required, including online forms.

• Error and informational messages to operators and restart procedures.

• Special instructions, such as security requirements.

User Training In System Analysis And Design

User Documentation

It includes instructions and information to the users who will interact with the system. For example, user manuals, help guides, and tutorials. User documentation is valuable in training users and for reference purpose. It must be clear, understandable, and readily accessible to users at all levels.

Hp color laserjet cp1518ni user manual. (HP Color LaserJet CP1518ni only) Enables direct connection of a compatible camera or camcorder to the product for direct printing of recorded images. Memory card slots (HP Color LaserJet CP1518ni only) The following memory cards are supported: CompactFlash (CF) Type 1 and Type 2 Memory Stick, Memory Stick PRO, and Memory Stick Duo. HP Color LaserJet CP1518ni manuals. 116 manuals in 38 languages available for free view and download. Dec 09, 2014  HP Color LaserJet CP1518ni user guide manual was written in English and published in PDF File (Portable Document Format). You can find helpful and important information or learn the basics of HP Color LaserJet CP1518ni manual with its user manual, user guide and instruction manual. Manuals or user guides for your HP Color LaserJet CP1518ni Printer. Use product model name: - Examples: laserjet pro p1102, DeskJet 2130; For HP products a product number. HP Color LaserJet CP1518ni Printer. Choose a different product, - Add this product to My Dashboard.

The users, system owners, analysts, and programmers, all put combined efforts to develop a user’s guide.

A user documentation should include −

• A system overview that clearly describes all major system features, capabilities, and limitations.

• Description of source document content, preparation, processing, and, samples.

• Overview of menu and data entry screen options, contents, and processing instructions.

• Examples of reports that are produced regularly or available at the user’s request, including samples.

• Security and audit trail information.

• Explanation of responsibility for specific input, output, or processing requirements.

• Procedures for requesting changes and reporting problems.

• Examples of exceptions and error situations.

• Frequently asked questions (FAQs).

• Explanation of how to get help and procedures for updating the user manual.

System Documentation

System documentation serves as the technical specifications for the IS and how the objectives of the IS are accomplished. Users, managers and IS owners need never reference system documentation. System documentation provides the basis for understanding the technical aspects of the IS when modifications are made.

System Analysis And Design Questions

• It describes each program within the IS and the entire IS itself.

• It describes the system’s functions, the way they are implemented, each program's purpose within the entire IS with respect to the order of execution, information passed to and from programs, and overall system flow.

• It includes data dictionary entries, data flow diagrams, object models, screen layouts, source documents, and the systems request that initiated the project.

• Most of the system documentation is prepared during the system analysis and system design phases.

• During systems implementation, an analyst must review system documentation to verify that it is complete, accurate, and up-to-date, and including any changes made during the implementation process.