Business process redesign (BPR)

One of the most interesting contemporary applications of systems analysis methods is business process redesign. Business process redesign (also called business process reengineering) is the application of Systems analysis (and design) methods to the goal of dramatically changing and improving the fundamental business processes of an Organization, independent of information technology.

The interest in BPR was driven by the discovery that most current information systems and applications have merely automated existing and inefficient business processes. Automated bureaucracy is still bureaucracy; it does not contribute value to the business and may actually subtract value from the business. BPR is one of many types of projects triggered by the trend we call total quality management (TQM).

BPR projects focus almost entirely on noncomputer processes. Each process is studied and analyzed for bottlenecks, value returned, and opportunities for elimination or streamlining. Once the business processes have been redesigned, most BPR projects conclude by examining how information technology might best be applied to the improved business processes. This creates new application development projects to which the other techniques described in this section might be applied. Business process redesign is a subject that deserves its own course and book.

 

3.Translate the text below.

КОНТЕЙНЕР СЕРВІСІВ EveREST

Для організації віддаленого доступу до проблемно-орієнтованих обчислювальних ресурсів, службовцям для вирішення певних класів наукових та прикладних задач може бути використаний сервіс-орієнтований підхід. Даний підхід дозволяє реалізувати уніфікований механізм доступу до зазначеного виду ресурсів і забезпечити зручність їх інтеграції в довільні програми. Для спрощення повторного використання і композиції сервісів в рамках різних додатків потрібна уніфікація механізму віддаленого доступу до сервісів на рівні протоколів і форматів даних. Зокрема, був запропонований уніфікований інтерфейс доступу до проблемно-орієнтованих обчислювальних сервісів на основі технологій Web і підходу REST. Сервер EveREST є контейнером проблемно-орієнтованих обчислювальних сервісів, що дозволяє швидко перетворювати широкий спектр існуючих додатків в віддалено доступні Web-сервіси. EveREST реалізований на базі бібліотеки Jersey, що є в свою чергу відкритою еталонною реалізацією специфікації JAX-RS (Java API for RESTful Web Services).

Взаємодія з клієнтами здійснюється за допомогою вбудованого Web-сервера Jetty. Вхідні HTTP- запити передаються бібліотеці Jersey і, потім, реалізації EveREST. Сполучення між Jersey і EveREST здійснюється за допомогою чотирьох Java-класів (ServerResource, ServiceResource, JobResource і FileResource), які є реалізаціями відповідних ресурсів з уніфікованого REST-інтерфейсу.

EveREST здійснює обробку запитів клієнтів відповідно до конфігураційної інформацією. Компонент ServiceManager надає доступ до списку сервісів, розміщених на сервері, і їх конфігурації. Дана інформація зчитується при запуску сервера з конфігураційного файлу. Конфігурація кожного сервісу складається з двох частин:

• зовнішній опис сервісу (текстова анотація сервісу, опису вхідних і вихідних параметрів);

• внутрішня конфігурація сервісу, що містить інформацію про те, який компонент реалізує сервіс і яким чином відбувається передача параметрів між сервером і реалізацією сервісу.

 

 

UNIT 8

1. Read the text and find answers to the following questions.

a. What is the main advantage of object- oriented techniques?

b. What's the use of FAST methodology?

c. What is the difference between roles and job titles?

 

OBJECT-ORIENTED ANALYSIS (OOA)

Object-oriented analysis is the new kid on the block. The concepts behind this exciting new strategy (and technology) are introduced here.

For the past 30 years, most systems development strategies have deliberately separated concerns of DATA from those of PROCESS. The COBOL language, which dominated business application programming for years, was representative of this separation-the DATA DIVISION

was separated from the PROCEDURE DIVISION. Most systems analysis (and design) techniques similarly separated these concerns to maintain consistency with the programming technology. Although most systems analysis and design methods have made significant attempts to synchronize data and process models, the results have been less than fully successful.

Object technologies and techniques are an attempt to eliminate the separation of concerns about DATA and PROCESS. Instead, data and the processes that act on that data are combined or encapsulated into things called objects. The only way to create, delete, change, or use the data in an object (called properties) is through one of its encapsulated processes (called methods). The system and software development strategy is changed to focus on the "assembly" of the system from a library of reusable objects. Of course, those objects must be defined, designed, and constructed. Thus, in the early part of the Systems development process, we need to use objectoriented analysis techniques.

Object-oriented analysis (OOA) techniques are used to (1) study existing objects to see if they can be reused or adapted for new uses, and to (2) define new or modified objects that will be combined with existing objects into a useful business computing application.

Object-oriented analysis techniques are best suited to projects that will implement systems using emerging object technologies to construct, manage, and assemble those objects into useful computer applications. Examples include Smalltalk C++, Delphi and Visual BASIC.

Today, most computer Operating Systems use graphical user interfaces (GUIs) such as Microsoft Windows and IBM's OS/2 Presentation Manager. GUIs are built with object-oriented (or object-like) technologies. The development of GUI applications can be based on libraries of reusable objects (sometimes called components) that exhibit the same behaviors in all applications. For example, Delphi and Visual BASIC contain all the necessary objects (called components) to

assemble the desired GUT screens for any new application (without programming!).

FAST SYSTEMS ANALYSIS STRATEGIES

The FAST methodology used by SoundStage Entertainment Club does not impose a single technique on system developers. Instead, it integrates all the popular techniques: structured analysis (via process modeling), information engineering (via data modeling), prototyping (via rapid application development), and joint application development (for all methods). Progressive FAST developers can use object-oriented analysis in conjunction with object technology for prototyping to fully exploit the object paradigm.

Finally, the FAST methodology supports different types of projects including: (1) application development, (2) information strategy planning, (3) business area analysis, (4) decision support system development, and (5) business process redesign. The SoundStage case study will demonstrate application development, a typical first assignment for a systems analyst.

FAST analysis techniques are applied within the framework of (1) your information system building blocks, (2) the FAST phases, and (3) FAST activities. Given this overview of Systems analysis scope and strategy, we can now explore the systems analysis activities. Each FAST phase will be described in terms of your information system building blocks and the activities that constitute that phase. For each activity, we will examine the following methodology elements:

- Purpose (self-explanatory).

- Roles. All FAST activities are completed by individuals who are assigned to roles. Roles are not the same as job titles. One person can play many roles in a project. Conversely, one role may require many people to adequately fulfill that role. For example, a system user role may require several users in order to adequately represent the interests of an entire System. FAST roles are assigned to the following role groups: system owner roles, system user roles, systems analyst roles, system designer roles, and system builder roles.

Notice that these groups correspond with the perspectives in your information system framework.

Every activity is described with respect to:

- Prerequisites and inputs (to the activity).

- Deliverables and outputs (produced by the activity).

- Applicable techniques - which techniques (from the previous section) are applicable to this phase.

- Steps - a brief description of the Steps required to complete this activity. In the spirit of continuous improvement, all FAST steps are fully customizable for each organization.

Furthermore, all roles, inputs, outputs, techniques, and steps are presented with the following designations:

- (REQ) indicates that the role, input, output, technique, or step is REQuired.

- (REC) indicates that the role, input, output, technique, or step is RECommended but not

required.

- (OPT) indicates that the role, input, output, technique, or step is OPTional but not required.”

 

2. Make a written translation the text that follows.