Реализация
рудно
давать советы по реализации кода модулей, потому что любой разраб имеет какие-то
привычки и собственный стиль разработки кода. При реализации проекта принципиально координировать
группу (группы) разрабов. Все создатели должны подчиняться твердым правилам
контроля начальных тестов. Группа разрабов, получив технический проект,
начинает писать код модулей, и в этом случае основная задачка заключается в том,
чтоб уяснить спецификацию. Проектировщик указал, что нужно создать, а
разраб описывает методы выполнения.
На шаге разработки осуществляется
тесное взаимодействие проектировщиков,
разрабов и групп тестеров. В случае
интенсивной разработки тестер практически «пристегивается»
к разрабу, практически являясь членом
группы разработки.
Проектировщик на данном шаге
делает функции «ходячего справочника»,
так как повсевременно отвечает на вопросцы
разрабов, касающиеся технической
спецификации.
Почаще всего на шаге разработки
изменяются интерфейсы юзера. Это
обосновано в том числе и тем, что модули
временами демонстрируются заказчику.
Значительно могут изменяться и запросы к
данным.
Необходимо подчеркнуть, что для сборки
всего проекта обязано быть выделенное
рабочее пространство. Конкретно эти модули передаются
на тестирование. Взаимодействие тестера и
разраба без централизованной
передачи частей проекта допустимо, но
лишь в случае, если нужно срочно
проверить какую-то правку. Весьма нередко шаг
разработки и шаг тестирования
взаимосвязаны и идут параллельно.
Синхронизирует деяния тестеров и
разрабов система bug
tracking.
При разработке должны быть
организованы повсевременно обновляемые
хранилища готовых модулей проекта и
библиотек, которые употребляются при сборке
модулей. Лучше, чтоб процесс
обновления хранилищ контролировал один
человек. Одно из хранилищ обязано быть
создано для модулей, прошедших
функциональное тестирование,
а другое — для модулей, прошедших
тестирование связей. 1-ое из их — это
черновики. 2-ое — то, из чего же уже можно
собирать дистрибутив системы и
показывать его заказчику для
проведения контрольных испытаний либо сдачи
каких-то шагов работ.
Документация создается в течение
всего процесса разработки. Как
модуль прошел тестирование связей, его
можно обрисовывать в документации. В случае
если модули меняются нередко, к описанию
приступают лишь тогда, когда модуль
становится наиболее либо наименее размеренным.
Обработка результатов проектирования
На шаге разработки, обычно, снова проверяется атомарность функций,
также отсутствие их дублирования.
Лучше, чтоб на шаге
проектирования уже была построена матрица
«функции-сущности». Это практически
формализованное представление того, что
компания пробует создать (функции) и какую
информацию требуется обработать для
заслуги результата (сути). Схожая
матрица дозволяет проверить последующие
моменты:
- имеет ли любая суть конструктор
— функцию, создающую экземпляры сути (create);
есть ли ссылки на данную суть,
другими словами употребляется ли где-либо данная суть (references);
имеют ли пространство конфигурации данной
сути (update);
имеет ли любая суть деструктор
– функцию, которая удаляет экземпляры сути (delete).
Нередко роль деструктора делает
набор программ архивирования данных.
Часто в информационных системах
информацию просто копят. Это
допустимо только в этом случае, если в течение
всего периода скопления инфы (а
практически в течение всей
жизнедеятельности информационной системы)
свойства ее производительности
удовлетворяют требованиям заказчика. На
практике это очень редчайшее стечение
событий. Соединено это в главном с
ростом обрабатываемых размеров инфы.
Необходимо подчеркнуть, что надежды в этом
случае лишь на мощность СУБД либо
аппаратного обеспечения недозволено, потому что
подобные экстенсивные способы увеличения
производительности дают маленький расчетный
прирост скорости. Практически задачка
реагирования системы либо отдельных ее
частей на рост размера обрабатываемых
данных является более возможной задачей
тестирования. В таком случае группа
тестирования делает модуль генерации (пусть
даже абстрактных) данных, выбирается набор
запросов, для которых скоростные
свойства критичны, дальше
выполняются замеры и строится зависимость
скорости выполнения от размера данных для
всякого из запросов. Такое обычное действие
дозволит избежать суровых ошибок и в
проектировании, и в реализации
информационной системы.
Спецификация модулей обязана быть
выполнена еще на шаге проектирования, чему
в настоящих проектах часто просто не
присваивают значения. И зря — ведь из-за
необмысленной реализации модулей любые
плюсы схемы базы данных могут быть
утрачены. Так, пренебрегая спецификациями
модулей, вы рискуете заложить в
информационную систему:
- неконтролируемый рост
размеров данных;
потоки запросов с вначале
высочайшей вероятностью конфликта либо потоки запросов, которые будут производиться
«вечно» (попытка выполнить поток, обнаружение конфликта и откат всех действий,
новенькая попытка и т.д.) из-за конфликтующих с ними потоков;
смешивание системных и
интерфейсных модулей;
дублирование модулей;
ошибки в размещении бизнес-логики;
отсутствие реализации
либо неполная реализация требуемых заказчиком функций системы.
Это далековато не
полный перечень заморочек, которые будут
обнаружены либо на шаге всеохватывающего
тестирования, либо при вводе системы в
эксплуатацию, а быть может, даже в процессе
эксплуатации системы (когда начнут реально
употребляться модули).
Не считая того, отсутствие спецификаций
модулей не дозволит буквально оценить
сложность всякого модуля и, как следствие,
найти последовательность сотворения
модулей и верно распределить нагрузку
персонала. Рядовая ситуация в схожем
случае —
«кто-то кого-либо ожидает», при всем этом процесс
сотворения информационной системы стоит на
месте.
Системные модули
Нередко приходится разглядывать
огромное количество обслуживающих либо
вспомогательных действий, которые
конкретно не соединены со
сформулированной бизнес-функцией. Как
правило, это системные функции, имеющиеся в
хоть какой информационной системе, такие как:
- диспетчер очередей либо
планировщик заданий;
диспетчер печати;
средства доступа к данным
и сотворения нерегламентированных запросов (нередко это генераторы отчетов);
управление каталогами
и другими ресурсами файловой системы;
автоматическое запасное
копирование;
автоматическое восстановление
опосля сбоя системы;
средства регламентирования
доступа юзеров к системе (состоящие из средства сотворения юзеров
и средства предназначения им льгот);
средство опции среды
для юзера информационной системы;
средство конфигурации юзером
собственных опций (в том числе и пароля);
средство управления приложениями;
среда админа информационной
системы.
Часть этих функций обязана делать
операционная система, но если она будет
работать в неоднородной среде, то нет
гарантии, что юзерам придется по
вкусу наличие разных интерфейсов в
различных операционных системах. В эталоне все
приложения-клиенты должны работать в одной
операционной системе, но на практике
разрабам нередко приходится
сталкиваться с целым «зоопарком» разных
рабочих станций у заказчика — итогом
нескольких попыток заавтоматизировать
бизнес. Цель разраба — довести
систему до очень однородного
состояния или создать схожими хотя бы
рабочие места конечных юзеров.
Задачка сотворения информационной
системы в разнородной среде значительно
увеличивает требования к разрабам кода и
к избираемому средству разработки.
В особенности это касается разработки системных
модулей. Следует уделить внимание модулям,
реализация кода которых зависит от
операционной системы. Подобные модули
должны быть выделены раздельно для каждой из
операционных систем в группы, к примеру Win98,
WinNT и т.д.
Модули каждой из групп обязаны иметь строгие
интерфейсы обмена — данные, которые они
передают и получают, строго определены,
хоть какое отклонение от спецификации наказуемо.
Ни один из модулей вне данной группы не может
применять никаких остальных вызовов, не считая
интерфейсов обмена. Таковым образом модули,
зависящие от операционнй системы,
изолируются от остальных модулей.
Совершенно говоря, практика
изолирования системных модулей
средством серьезной регламентации их
интерфейсов обмена значительно
минимизирует издержки по исправлению ошибок
и поддержке системы. Не считая того, это
упрощает и тестирование, а конкретно
детектирование ошибок и их отладку. Иная
сторона вопросца — требования к коду
интерфейса обмена системных модулей резко
увеличиваются. Это то, что отлаживается в
первую очередь и обязано работать весьма
верно.
Средства мониторинга информационной системы
Если информационная система велика, то следует разглядеть задачку ее администрирования
с одной рабочей станции. Нужно хлопотать не только лишь о конечном юзере
информационной системы, да и о персонале, который будет ее обслуживать. Особенное
внимание следует уделить мониторингу критичных участков информационной системы,
так как сбой часто проще предупредить, чем исправлять его последствия.
Мониторинг относится к тем задачкам, о необходимости решения которых заказчик,
обычно, не думает и которые обычно отсутствуют и в аналитическом
исследовании, и даже при проектировании. Потребность в средствах мониторинга
становится тривиальной только на шаге ввода системы в эксплуатацию, при этом потребность
эта тем выше, чем труднее система и чем больше в ней критичных участков.
Разрабам и проектироващикам
следует проводить оценку трудности системы.
Если принимается решение о написании
всеохватывающего средства администрирования и
мониторинга, не предусмотренного
техническим заданием, то в этом случае
следует поменять техническое задание, а не
идти на поводу у заказчика. В сложной
системе выслеживать критичные процессы
все равно придется. Внедрять подобные
средства в уже готовую систему весьма трудно,
так как начальные данные мониторы нередко
получают от системных модулей довольно
низкого уровня. Без конфигураций схемы базы
данных тут тоже навряд ли можно будет
обойтись, и нет никакой гарантии, что
схожее изменение не усугубит
производительность системы.
Разработка мониторов — это
достаточно специфичный класс задач: с одной
стороны, они должны обрабатывать
достаточный размер инфы, с иной — не
должны значительно влиять на работу остальных
компонент информационной системы. Это
принуждает разрабов с особенной
тщательностью подступать к проектированию
мониторов и весьма аккуратненько писать код их
модулей.
Интерфейсы
Интерфейсы конечного юзера — это то, что заказчик критикует в большей
степени, в силу того что конкретно эти части информационной системы он может наиболее
либо наименее грамотно оценить — обычно лишь их он и лицезреет. Это значит,
что интерфейсы являются более нередко изменяемым элементом информационной системы
конкретно на шаге реализации.
Нередко изменяемый компонент (составляющие)
информационной системы следует
изолировать от изредка изменяемых
компонент, чтоб одни конфигурации не тянули за
собой остальные. Один из приемов схожей
изоляции — изоляция запросов
к данным от интерфейса последующим
образом:
- любой из запросов кодируется
идентификатором либо «запирается» определенной системной функцией;
разраб интерфейса
не понимает о запросе к данным ничего, не считая характеристик атрибутов подборки — их
типа и, может быть, количества строк в выборке;
обработка ошибок в запросах
данных представляет собой отдельный модуль;
обработка ошибок в интерпретации
результата запроса также представляет собой отдельный модуль.
При обработке результатов запросов
данных следует также особенное внимание
уделить вопросцам соответствия типов
включающего языка и СУБД, в том числе
вопросцам точности числовых типов, потому что
представление их у различных СУБД значительно
различается. Не считая того, направьте внимание
на запросы к данным, которые употребляют
функции, зависящие от операционной системы,
к примеру функции работы с
б и словами значения атрибута (к примеру,
на Intel и SUN
SPARC эти
функции будут работать по-разному). Типы
данных могут быть приведены либо очевидно в
запросе функциями приведения cast
и встроенными в СУБД функциями, либо в
функции прикладной программки. Не для всех
СУБД неявное преобразование типов дает
один и этот же итог, потому если
информационая система употребляет данные из
нескольких баз данных под управлением
различных СУБД, то неявных преобразований
типов лучше избегать.
Следует также установить
довольно твердые правила для наружного
вида интерфейсов юзера. Обязано
создаваться воспоминание одного стиля для
всех компонент информационной системы.
Версии базы данных
Первую версию базы данных проекта почти всегда делают довольно
стремительно — это реализация вполне нормализованной структуры, которую получают
на шаге анализа. Главным предназначением данной базы данных является обеспечение
макетирования, демо показов, неких тестов разрабов
и проектировщиков.
Скрипты сотворения базы данных и
наполнения ее стартовыми данными — это
тоже начальный код информационной системы, и
на него распространяются правила контроля
версий. Необходимо подчеркнуть, что поддерживать
версии базы даных на уровне скриптов все таки
проще, чем на уровне средств выгрузки и
загрузки данных, предоставляемых самой
СУБД, потому что в подавляющем большинстве
случаев подобные средства не могут
предоставить несколько обычных, но
нужных функций:
- проконтролировать, какие
объекты данных и данные имеют пространство в объектах загрузки A и B, и загрузить
в базу данных лишь «разницу» A и B (произвести обновление версии);
проконтролировать, не
конфликтуют ли конфигурации, имеющие пространство в объектах выгрузки C и D, по сопоставлению
с объектом выгрузки A (произвести слияние версий).
CASE-инструменты
имеют средства контроля версий схемы базы
данных, некие имеют опции,
дозволяющие также надзирать и
стартовые данные. Это дает
возможность применять обозначенные
средства для обеспечения контроля версий
базы данных.
Контроль версий начального кода
триггеров, хранимых процедур надежнее
производить методом использования той же
системы контроля версий, что принята для
хранения начальных текстов самого проекта.
Размещение логики обработки
Одим из принципиальных вопросцев проектирования является метод размещения бизнес-логики
обработки данных: располагать ее (и какую часть) или на сервере в виде хранимых
процедур, пакетов, триггеров, других ограничений целостности конкретно на
сервере баз данных, или в виде функций на клиенте (в составе ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств) клиента). Местопребывание
правил интерфейса и правил данных задано буквально: 1-ые постоянно расположены на клиенте,
2-ые — на сервере. Правила бизнес-логики в современных СУБД могут быть расположены
как на клиенте, так и на сервере. Разглядим один из примеров простого бизнес-правила:
- Значение в поле экранной
формы вводится юзером, а не выбирается из перечня, но набор допустимых
значений строго ограничен (к примеру, два либо три разных значения).
С одной стороны, юзер
просит незамедлительной реакции системы на
ошибку ввода данных, с иной — недопустимы
значения в поле базы данных, хорошие от
данных (2-ух либо 3-х). По сути в
данной ситуации должны
быть реализованы два правила. Правило
данных в этом случае будет скооперировано в
виде ограничения check,
а правило интерфейса, запрещающее вводить
значения, хорошие от данных, будет в
точности повторять правило даных, но будет
реализовано на уровне интерфейса
юзера. Чудилось бы, реализация формы
со перечнем в этом случае является безупречным
решением, но большая часть операторов
предпочитают конкретно набор в форме, в особенности
если длина вводимого значения невелика.
Формы с огромным количеством списков
довольно трудны для обработки конечными
юзерами. В случае набора значений в
форме следует также позаботиться о
приведении регистров строк знаков (там,
где регистр не существенен) к верхнему либо
нижнему регистру, на уровне интерфейса
прикладной программки.
Шаблоны
Внедрение шаблонов и библиотек для построения «схожих» модулей — довольно
всераспространенная практика. Что применять в этом случае — объекты и классы
либо библиотеки — решает определенная группа разрабов. Диктовать метод разработки
почти всегда глупо, поэтому что разраб пишет код так, как
умеет либо как привык. Эти моменты обычно контролирует управляющий проекта.
В любом проекте запрещается
копирование кода, так как это ведет к
появлению разных версий 1-го и
такого же кода в различных фрагментах
прикладной программки и, как следствие, к
трудно детектируемым и исправляемым
ошибкам. Следует установить твердое
правило: употребляется вызов функции, а не
его копия в коде; хоть какое отклонение от
данного правила наказуемо.
Тестирование
ак
было сказано выше, группы тестирования могут привлекаться уже на ранешних стадиях
разработки проекта. Фактически всеохватывающее тестирование вправду следует
выделять в отдельный шаг разработки. Зависимо от трудности проекта тестирование
и исправление ошибок могут занимать третья часть, половину и больше времени разработки
всего проекта.
Чем труднее проект, тем больше будет
потребность в автоматизации системы
хранения ошибок — bug
tracking.
Схожая система обеспечивает последующие
функции:
- хранение сообщения о
ошибке (с неотклонимой информацией о том, к какому компоненту системы относится
ошибка, кто ее отыскал, как ее воспроизвести, кто отвечает за ее исправление
и когда она обязана быть исправлена);
система извещения о
возникновении новейших ошибок, о изменении статуса узнаваемых в системе ошибок (как
правило, это извещения по электрической почте);
отчеты о животрепещущих ошибках
по компонентам системы, по интервалам времени, по группам разрабов и
разрабам;
информация о истории
ошибки (в том числе отслеживание схожих ошибок, отслеживание повторного появления
ошибки);
правила доступа к ошибкам
тех либо других категорий;
интерфейс ограниченного
доступа к системе bug tracking для конечного юзера информационной системы,
который употребляется как интерфейс обмена информацией меж юзером
и службой технической поддержки системы.
Подобные системы снимают огромное количество
организационных заморочек, а именно
вопросцы автоматического извещения о
ошибках.
Фактически испытания систем можно
поделить на несколько категорий:
- автономные испытания модулей
— употребляются уже на шаге разработки компонент системы и разрешают выслеживать
ошибки отдельных компонент;
испытания связей компонент
системы — употребляются и на шаге разработки, и на шаге тестирования и разрешают
выслеживать корректность взаимодействия и обмена информацией компонент системы;
системный тест — является
главным аспектом приемки системы. Обычно, это группа тестов, включающая
в себя и автономные испытания, и испытания связей и модели. Данный тест должен воспроизводить
работу всех компонент и функций системы, его основная цель — внутренняя
приемка системы и оценка ее свойства;
приемо-сдаточный тест
— употребляется при сдаче системы заказчику. Тут создатели нередко занижают
требования к системе по сопоставлению с системным тестом, и в общем-то понятно,
почему это оправданно;
испытания производительности
и перегрузки — входят в системный тест, но достойны отдельного упоминания, так
как конкретно эта группа тестов является главный для оценки надежности системы.
В испытания каждой группы непременно
входят испытания моделирования отказов. Тут
проверяется реакция компонента, группы
компонент, системы в целом на отказы
последующего типа:
- отказ отдельного компонента
информационной системы;
отказ группы компонент
информационной системы;
отказ главных модулей
информационной системы;
отказ операционной системы;
«твердый» сбой (отказ
питания, твердых дисков).
Эти испытания разрешают оценить
свойство подсистемы восстановления
корректного состояния информационной
системы и служат главным источником
инфы для разработки стратегий
предотвращения негативных последствий
сбоев при промышленной эксплуатации. Как
правило, это тот класс тестов, которым
создатели третируют, а потом борются
с последствиями сбоев на промышленной
системе.
Еще одним принципиальным моментом программки
тестирования информационных систем
является наличие генераторов тестовых
данных. Они употребляются для проведения как
тестов функциональности системы, так и
тестов надежности системы, также тестов
производительности системы. Задачка оценки
черт зависимости
производительности информационной системы
от роста размеров обрабатываемой инфы
не быть может решена без генераторов данных.
Эксплуатация и сопровождение
пытная
эксплуатация перекрывает процесс тестирования. Обычно, система вводится
в эксплуатацию не вполне, равномерно.
Ввод в эксплуатацию проходит по
последней мере три фазы:
скопление инфы;
выход на проектную мощность.
Начальная загрузка инфы
инициирует достаточно узенький круг ошибок — в
основном это трудности рассогласования
данных при загрузке и собственные ошибки
загрузчиков, другими словами то, что не было
отслежено на тестовых данных. Подобные
ошибки должны быть исправлены как можно
резвее. Не поленитесь поставить
отладочную версию системы (если, естественно,
для вас дозволят развернуть весь комплекс
провождающего отладку информационной
системы ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств) на месте). Если отладку «на {живых}»
данных создавать нереально, то придется
моделировать ситуацию, при этом стремительно. Тут
требуются весьма квалифицированные тестеры.
В период скопления инфы
проявится наибольшее количество ошибок,
допущенных при разработке информационной
системы. Как
правило, это ошибки, связанные с
многопользовательским доступом. Нередко на
шаге тестирования таковым ошибкам не
уделяется подабающего внимания — видимо, из-за
трудности моделирования и накладности
средств автоматизации процесса тестирования информационной системы в
критериях многопользовательского доступа.
Некие ошибки поправить будет достаточно
трудно, потому что они являются ошибками
проектирования. Ни один самый неплохой
проект от их не застрахован. Это означает,
что на всякий вариант нужно резервировать
время на локализацию и исправление таковых
ошибок.
В период скопления инфы
можно столкнуться со известным «свалилась
база». При самом нехорошем раскладе окажется,
что СУБД не выдерживает потока инфы.
При неплохом — просто характеристики
конфигурации неверны. 1-ый вариант небезопасен,
потому что воздействовать на производителя СУБД
достаточно трудно, а заказчик весьма не любит
ссылок на службу технической поддержки
СУБД. Решать делему отказа СУБД придется
не производителю, а для вас — поменять схему,
снижать поток запросов, поменять сами запросы;
в общем — вариантов много. Отлично, если
время восстановления базы вписывается в
запланированное.
Выход системы на проектную мощность
при успешном стечении событий — это
исправление ряда маленьких ошибок, и время от времени –
ошибок суровых.
Остальные подходы к разработке приложений
ак
правило, конечные юзеры и управление считают, что процесс проектирования
не отдал никаких результатов, так как отсутствуют готовые составляющие,
которые можно было бы «пощупать». Часто заказчик настаивает на преждевременном
проведении шага реализации проекта, для того чтоб как можно резвее получить
некий итог и показать его. В таком случае существует большенный
соблазн избрать ускоренную разработку приложений (УРП) либо совместную разработку
приложений (СРП). Подобные способы предугадывают разработку рабочего макета
с следующей демонстрацией его юзерам. Юзеры отмечают, что им
нравится, а что — нет. Проектировщик дорабатывает макет с учетом изготовленных
замечаний, опосля чего же опять показывает то, что вышло. И так дальше. Процесс
повторяется до того времени, пока юзерам не понравится то, что они лицезреют,
а макет не станет рабочим приложением. Обычно устанавливается предел времени
и количество итераций, по другому юзеры будут улучшать макет вечно.
На теоретическом уровне это дозволяет получить ту систему, которая требуется юзерам.
На практике схожий подход к разработке приложений связан с суровыми неуввязками.
- Все внимание сконцентрировано
на экранных формах, а то, что касается правил обработки данных и системных
функций, остается за кадром. Есть соблазн начать работу с отчетов, в то время
как отчет является не стартовым, а производным продуктом информационной системы.
Юзеры считают, что если
вариант макета согласован, то модуль готов. По сути это быть может
всего только картина с набором «заглушек» для вызовов системных функций и взаимодействия
с иными модулями.
Модули проектируются изолированно
друг от друга (наверняка, большая часть из вас сталкивались с бухгалтерскими
программками, где любой АРМ является автономным и функции нередко дублируются).
Следствием этого являются противоречия модулей, дублирование функций и данных,
что быть может выявлено лишь при тестировании комплекса модулей.
Многофункциональные способности наращиваются
параллельно в нескольких направлениях, означает, структура базы данных обязана
контролироваться агрессивно. При УРП схема базы данных преобразуется в свалку,
где таблицы «лепятся» наспех, в итоге чего же имеет пространство набор противоречивых
и дублирующихся данных.
Документация при использовании
способа УРП, обычно, отсутствует, а точнее, о необходимости документировать
систему запамятывают, так как создается иллюзия, что юзер и без того
соображает, что происходит. Когда же приложение начинает работать не так, как
подразумевает юзер, возникает масса заморочек.
Обработка исключительных ситуаций
для всякого модуля делается своя.
Целостная система, обычно,
не выходит, быстрее всего, это будет некоторый набор автоматических рабочих
мест, наспех связанных меж собой.
Способы УРП и СРП
можно применять далековато не постоянно, а только
в этом случае, если:
- размер проекта и требования бизнеса
верно определены, не меняются, а сам проект невелик;
проект не зависит от остальных
средств автоматизации бизнеса, количество наружных интерфейсов, с которыми
придется иметь дело, ограниченно;
система нацелена на экранные
формы, обработка данных и системные функции составляют незначимую часть,
удобство экранных форм заходит в пятерку важных причин фуррора проекта;
юзеры имеют высшую квалификацию
и априори положительно оценивают идею сотворения новейшего ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств).
Тем не наименее
способом УРП лучше разрабатывать маленькие
и, лучше, автономные части проекта.
В истинное
время предпринята попытка представить еще
один метод резвого написания проекта — способ
экстремального программирования.
Ниже будут рассмотрены принципы
данного подхода.
Шаг планирования (planning game).
На основании оценок, изготовленных
программерами, заказчик описывает
многофункциональные способности и срок
реализации версий системы. Программеры
реализуют лишь те функции, которые
нужны для способностей, избранных на
данной итерации.
В итоге такового решения «за
кадром» остается развитие системы,
вследствие чего же при разработке возникает
необходимость строить «заглушки» и
переписывать код. Неясно, почему срок
реализации описывает заказчик, ведь на
самом деле это ровная обязанность группы
проектировщиков. Заказчик, совершенно говоря,
может только выразить свои пожелания по
поводу сроков («желаю, чтоб к такому-то
числу»), но найти срок может лишь
проектировщик («выполнимо не меньше чем за
такое-то время»).
Частая смена версий (small
releases). Систему запускают в эксплуатацию
уже через несколько месяцев опосля начала
реализации, не дожидаясь окончательного
разрешения всех поставленных заморочек.
Выпуск новейших версий может происходить с
периодичностью от каждодневного до
каждомесячного.
Все отлично, не считая 1-го:
протестировать за таковой срок наиболее либо
наименее непростой компонент нереально.
Заказчик практически выступает в роли бета-тестера.
В этом случае он может созидать, что
создатели трудятся и даже ошибки
исправляют. Но появляются резонные
вопросцы: стоит посвящать заказчика в
рабочий процесс и необходимо ли ставить
опыты на рабочей системе? В
дополнение к произнесенному нужно
отметить, что схожий принцип навряд ли
быть может реализован для частей проекта,
которые требуют работы в режиме 24×7.
Метафора (metaphor). Общий
вид системы определяется с помощью
метафоры либо набора метафор, над которыми
вместе работают заказчик и программеры.
С одной стороны, этот постулат
кажется хорошим, а с иной — имеет ли
смысл посвящать заказчика во внутренние
дела группы разрабов? То, что касается
вида (интерфейсы, отчеты и т.п.),
вправду может находиться в
компетенции заказчика,
но когда идет речь о особенностях
реализации тех либо других компонент,
заказчик навряд ли быть может полезен из-за
отсутствия у него нужных познаний.
Обычный
проект (simple design). В
любой момент времени разрабатываемая
система делает все испытания и поддерживает
все связи, определяемые
программером, не имеет дубликатов кода и
содержит мало вероятное количество
классов и способов. Это правило коротко можно
выразить так: «Каждую идея формулируй один
и лишь один раз».
Эта идея тоже
хороша, но она не полностью согласуется с
принципом резвого написания кода. Может
быть, стоит все-же поначалу помыслить, как
созодать тот либо другой модуль, группу модулей,
и только позже заняться написанием кода?
Испытания (tests).
Программеры повсевременно пишут испытания для
модулей (unit tests). Собранные вкупе, эти испытания
должны работать корректно. Для шагов в
итерации заказчики пишут многофункциональные
испытания (functional tests), которые
также должны работать верно. Но на
практике это не постоянно достижимо. Чтоб
принять правильное решение, нужно
осознать, во сколько обойдется сдача системы
с заблаговременно известным недостатком, и сопоставить
это с ценой задержки на исправление недостатка.
При написании тестов самими
программерами (в особенности в критериях
сверхурочных работ) эти испытания не
полнофункциональны, и уж тем наиболее не
учитывают особенностей
многопользовательской работы. На наиболее
продвинутые испытания у разрабов обычно
не хватает времени. Можно, естественно,
выстроить систему разработки так, что всем
будут заниматься одни и те же люди, но все-же
не стоит превращать проект в аналог
передачи «Сам для себя режиссер». К
произнесенному нужно добавить, что
тестирование системы совсем не
исчерпывается тестами компонент (units); не
наименее важны испытания взаимодействия меж
ними, это относится и к тестам надежности
работы. И тем не наименее способ экстремального
программирования не предугадывает
сотворения тестов данного класса. Это
разъясняется тем, что сами такие испытания могут
представлять довольно непростой код (в особенности
это касается тестов-имитаторов настоящей
работы системы). В данной технологии также
никак не учитывается очередной принципиальный класс
тестов — испытания поведения системы при росте
размеров обрабатываемой инфы. При
высочайшей скорости конфигурации версий
выполнить таковой тест технологически
нереально, так как его проведение
просит размеренного и постоянного кода
проекта, к примеру, в течение недельки.
Подобные сроки, совершенно говоря, не
гарантируются из-за нередкой смены версий. В
таком случае придется либо приостанавливать
разработку компонент, либо на время
проведения теста создавать параллельную
версию проекта, которая будет сохраняться
постоянной, тогда как 2-ая при всем этом будет
изменяться. Позже необходимо будет делать
процесс слияния кода. Но в этом случае тест
придется создавать опять, потому что способы
экстремального программирования просто не
предугадывают разработку средств,
позволяющих предсказывать поведение
системы при тех либо других конфигурациях.
Переработка системы (refactoring).
Архитектура системы повсевременно
эволюционирует. Текущий проект
трансформируется, при всем этом гарантируется
правильное выполнение всех тестов.
Вот тут-то и начинается самое
увлекательное. Экстремальное
программирование исходит из того, что
переработать постоянно можно, при этом без особенных
издержек. Но практика свидетельствует о
оборотном.
Программирование в паре (pair
programming). Весь код проекта пишут два
человека, которые употребляют одну
настольную систему.
Возникает вопросец: кто-либо лицезрел
2-ух совсем схожих
программистов, любой из которых к тому же в
конце рабочего денька успевал бы писать
документацию для напарника?
Можно ли отыскать таковых программистов-близнецов,
согласных во всем?
А основное, для чего нужна таковая пара
программистов? Причина, в общем-то, обычная:
не все выдерживают навязываемый при
экстремальном программировании высочайший
темп работ, неизбежен отток персонала.
Схожая пара может отдать некоторую страховку —
если уволится один, то, быть может, 2-ой
доведет дело до конца. Правда, оставшийся
попадет в еще наиболее твердые временные рамки
— ведь размер работ остается прежним же, а
дублера уже не будет, по последней мере некое
время. Дальше следует естественный процесс
передачи инфы новенькому дублеру, что
опять-таки просит времени. И так без конца.
Непрерывная интеграция (continuous
integration). Новейший код встраивается в
существующую систему не позже, чем через
несколько часов. Опосля этого система вновь
собирается в единое целое и прогоняются все
испытания. Если хотя бы один из их не
производится корректно, внесенные конфигурации
отменяются.
Этот постулат предоставляется по
наименьшей мере спорным, так как неясно,
кто будет исправлять ошибки, при этом не
лишь локальные, да и наведенные неверным кодом. Ведь проведение
всеохватывающих тестов не предполагается на
данном шаге, не считая того, конфигурации
остаются даже в этом случае, когда ошибка
детектирована. В то же самое время способ
экстремального программирования не
предугадывает наличия системы
отслеживания ошибок.
Коллективное владение (collective
ownership). Любой программер имеет
возможность в хоть какое время
усовершенствовать всякую часть кода в
системе, если сочтет это нужным.
Для вас это анархию не припоминает? Как в
этом случае находить создателя конфигураций?
Встречал ли кто-нибудь при разработке
огромного проекта такового «на все руки доку»
и сколько схожий «умелец»
смог бы выдержать на собственном рабочем
месте? Верно, не очень длительно.
Заказчик с
неизменным ролью (on-site customer). Заказчик,
который в период работы над системой
находится в команде разрабов.
Это, естественно, отлично, но непонятна
цель: или предназначить заказчика в сущность дела,
или создать его соавтором? Навряд ли лишь
у заказчика найдется настолько
высококвалифицированный спец.
40-часовая неделька (40-hour weeks).
Размер сверхурочных работ не может
превосходить по продолжительности одну рабочую
недельку. Даже отдельные случаи сверхурочных
работ, повторяющиеся очень нередко,
являются сигналом суровых заморочек,
которые требуют безотложного решения.
Как указывает практика внедрения
экстремального программирования (невзирая
на целый ряд положительных примеров,
приводимых сторонниками данного способа),
сверхурочные при таком подходе — это
правило, а не исключение, и борьба с
неуввязками в этом случае — явление
неизменное. Усиливается она в период подмены
текущей сырой версии продукта очередной,
снова же сырой, версией. Заказчик,
посвященный в процесс, испытывает все
красоты проявления ошибок работы системы
на для себя. Как вы думаете, навечно ли хватит у
заказчика терпения при таком положении дел?
Ему ведь нужно, чтоб система работала…
Открытое рабочее
место (open workspace). Команда
разрабов размещается в большенном
помещении, окруженном комнатами наименьшей
площади. В центре рабочего места
инсталлируются компы, на которых
работают пары программистов.
При этом все это, судя по предшествующим
принципам, обязано размещаться на
местности заказчика, раз он очень интенсивно
привлекается к процессу разработки.
Возникает вопросец: реально ли настолько удачное
стечение событий?
Не наиболее чем правила (just
rules). Члены коллектива, работающего по
технологии экстремального
программирования, обязуются делать
изложенные правила. Но это не наиболее чем
правила и команда может в хоть какой момент
поменять их, если ее члены достигнули
принципного соглашения по поводу
внесенных конфигураций.
Быть может, в конце концов и будет
выработано одно полезное правило: «поначалу
задумайся, позже сделай». В этом случае мы
будем иметь схему, очень похожую на «водопад».
Почему-либо сторонники экстремального
программирования убеждены, что при
использовании «водопада» и его клонов цикл
разработки непременно должен быть длинноватым.
Неясно, чем обоснована таковая
уверенность. Ведь не запрещено дробить
проект на этапы. Почему-либо считается, что
планирование непременно будет
разовым и постоянным, хотя на самом
деле это не соответствует правде, в том
числе и в случае «водопада».
В итоге мы получаем способ,
потенциально владеющий высочайшей
адаптируемостью к очень изменяющимся
требованиям к проекту, но в то же время не
вольный от ряда суровых недочетов.
Крайнее событие не дозволяет
советовать данный способ к применению
для проектов, требующих высочайшей либо как
минимум достаточной надежности работы.
КомпьютерПресс 2″2002
Выслать свою неплохую работу в базу познаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, юные ученые, использующие базу познаний в собственной учебе и работе, будут для вас весьма признательны.
Подобные документы
Индивидуальности проектирования информационных систем основанных на базах данных. Внедрение CASE-средств и описание бизнес действий в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и зрительное представление web-сайта.
курсовая работа , добавлен 25.04.2012
Сравнительный анализ гостиничных информационных систем. Анализ и выбор CASE-средств для моделирования бизнес-процессов. Зрительная и математическая модели предметной области, выбор архитектуры и платформы информационной системы, построение базы данных.
дипломная работа , добавлен 20.07.2014
Системы автоматического проектирования. Сравнительный анализ средств для проектирования автоматических информационных систем. Экспорт SQL-кода в физическую среду и {наполнение} базы данных содержимым. Этапы развития и черта Case-средств.
курсовая работа , добавлен 14.11.2017
Понятие CASE-средств как программных средств, которые поддерживают процессы сотворения и сопровождения информационных систем (ИС). Индивидуальности IDEF-технологии разработки ИС. Описание нотации IDEF0. Разработка многофункциональных моделей бизнес-процесса.
презентация , добавлен 07.04.2013
Обзор принципов построения и действенного внедрения систем управления базами данных, CASE-средств автоматизации проектирования. Анализ способностей методологии и инструментальных средств. Разработка модели бизнес-процессов гостиницы в среде All Fusion.
курсовая работа , добавлен 28.12.2012
Наличие экономической информационной системы. Матрица организационных проекций. Разработка системы базы данных. Современные CASE-средства. Главные этапы разработки информационных систем. Абсолютный показатель и индекс понижения стоимостных издержек.
курсовая работа , добавлен 14.03.2011
Базисные базы разработки программного обеспечения: его традиционный актуальный цикл, макетирование, стратегии конструирования, модели свойства действий разработки. Применение параллельных алгоритмов и CASE-системы, аспекты оценки их эффективности.
курсовая работа , добавлен 07.04.2015
Роль инструментальных средств проектирования в разработке информационной системы. Достоинства CASE-средств разработки Bpwin и Erwin, системы поиска, исправления ошибок модели данных Model Validator. Разработка модели действий документооборота компании.
контрольная работа , добавлен 24.06.2012
Внедрение корпоративной ИС, разработанной без помощи других либо полученной у поставщика, часто сопровождается ломкой (перепроектированием) имеющихся на предприятии бизнес-процессов. Приходится перестраивать их под требования эталонов и логику внедряемой системы. Отметим сходу, что внедрение ИС решает ряд управленческих и технических заморочек, но порождает трудности, связанные с человечьим фактором.
Внедрение информационной системы, обычно, существенно упрощает управление деятельностью компании, улучшает внутренние и наружные потоки инфы, ликвидирует узенькие места в управлении. Но опосля того как система удачно установлена, «обкатана» в работе и показала свою эффективность, у части служащих выявляется нежелание применять ИС в работе. В итоге проведенного реинжиниринга становится понятно, что некие сотрудники в большенный степени дублируют работу остальных либо совсем не необходимы. Не считая того, внедрение КИС сопровождается неотклонимым обучением, но, как указывает русский опыт, желающих переучиваться не настолько не мало. Ломка старенькых способностей и прививание новейших — длинный и тяжелый процесс!
Нужно верно осознавать, что корпоративная ИС призвана упростить управление организацией, сделать лучше процессы, усилить контроль и обеспечить сиим конкурентноспособные выгоды. Лишь с таковой точки зрения можно оценивать пользу от ее внедрения.
Следуя данной логике, становится ясно, что хотя корпоративная ИС предназначена в целом для обеспечения всех юзеров нужной информацией, управление разработкой и внедрение КИС является прерогативой высшего управления компании! Соображают ли это руководители?
Тут тоже приходится биться с жизнестойкими стереотипами. «Для чего мне корпоративная система, если дела на предприятии и так идут отлично?». «Для чего, что-то разламывать, если все работает?». Но ведь ломать-то почаще всего и не нужно. На первом шаге необходимо только хорошо и корректно формализовать и перенести идентифицированные процессы, в рамках которых живет предприятие, в корпоративную ИС. Схожая формализация только отточит, отшлифует удачные рекламные и производственные находки, улучшает процесс управления и контроля и дозволит в предстоящем проводить целенаправленные конфигурации.
Внедрение новейшей ИС — непростой процесс, длящийся от нескольких месяцев для маленьких ИС до пары лет для ИС огромных распределенных компаний с широкой номенклатурой товаров и огромным количеством поставщиков. Фуррор проекта по разработке (либо приобретению) и внедрению ИС почти во всем зависит от готовности компании к ведению проекта, личной заинтригованности и воли управления, настоящей программки действий, наличия ресурсов, обученного персонала, возможности к преодолению сопротивления на всех уровнях сложившейся организации.
К истинному времени сложился обычный набор приемов внедрения ИС. Основное правило: делать неотклонимые фазы поочередно и не пропускать ни одной из их.
Критически необходимыми для внедрения являются последующие причины:
· наличие верно сформулированных целей проекта и требований к ИС;
· наличие стратегии внедрения и использования ИС;
· проведение предпроектного обследования компании и построения моделей «Как есть» и «Как будет»;
· планирование работ, ресурсов и контроль выполнения плана внедрения;
· роль высшего управления во внедрении системы;
· проведение работ по внедрению ИС спецами по интегрированию систем вместе со спецами компании;
· постоянный мониторинг свойства выполняемых работ;
· резвое получение положительных результатов хотя бы в части внедренных модулей ИС либо в процессе ее опытнейшей эксплуатации.
Перед началом разработки проекта внедрения нужно:
· очень формализовать цели проекта внедрения ИС;
· оценить мало нужные издержки и статьи расхода;
· установить высочайший ценность проекта внедрения перед остальными текущими проектами;
· наделить управляющего проекта очень вероятными возможностями;
· провести массовую просветительскую работу с персоналом компании с целью довести до всякого значимость и необходимость грядущих преобразований;
· создать организационные меры для внедрения новейших информационных технологий;
· распределить индивидуальную ответственность по всем шагам внедрения и опытнейшей эксплуатации.
Нужно также найти многофункциональные сферы внедрения модулей информационной системы:
· организационное управление;
· организационно-административное обеспечение;
· управление бизнес-процессами;
· управленческий, планово-финансовый и бухгалтерский учет;
· управление персоналом;
· управление документацией;
· управление материально-техническим обеспечением;
· управление связями с клиентами и наружной средой.
Не считая того, что перечислено выше, нужно задать технологические требования к внедрению ИС:
· системная платформа — внедрение и адаптация готового решения от производителя либо разработка на заказ в согласовании с техническим заданием заказчика;
· интегрируемость — данные хранятся и обрабатываются в едином информационном пространстве; это обеспечивает их полноту, непротиворечивость, достоверность и возможность неоднократного использования; система может включать в себя вновь разработанные и уже применяемые технологии и приложения;
· адаптируемость — система настраивается в согласовании с требованиями заказчика и на индивидуальности информационного поля заказчика;
· распределенность — система может отлично работать в территориально удаленных подразделениях и филиалах компании;
· масштабируемость — система может производиться в виде каркаса, содержащего базисные модули, и дополняться в согласовании с требованиями изменяющейся наружной и внутренней среды.
Главные фазы внедрения информационной системы
Фаза «Подготовительные работы по подготовке проекта внедрения ИС». В процессе предпроектного обследования компании происходит сбор подробной инфы о структурном построении организации, многофункциональных связях, системе управления, о главных бизнес-процессах, о потоках снутри компании (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), нужной для построения соответственных моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.
Фаза «Подготовка проекта». Опосля окончания первой фазы осуществляется предварительное планирование и формирование процедур пуска проекта:
· формирование проектной и экспертной групп;
· распределение возможностей и ответственности;
· определение организационно-технических требований к процессу внедрения;
· уточнение спецификаций и ожиданий заказчика;
· обучение (педагогический процесс, в результате которого учащиеся под руководством учителя овладевают знаниями, умениями и навыками) группы внедрения, состоящей из профессионалов предприятия-заказчика.
Крайний, весьма принципиальный момент почему-либо нередко пропускается при составлении плана внедрения. А ведь от него в большой степени зависит фуррор всего проекта! Опосля начала финансирования проект считается запущенным к выполнению.
Фаза «Мировозренческая проработка проекта». В течение данной фазы:
· формируется и утверждается концептуальный проект;
· достигается непременное однозначное осознание целей всех участников проекта относительно внедряемой ИС;
· уточняются и конкретизируются цели и задачки проекта;
· определяются размеры макета системы;
· согласуются укрупненный план работы, последовательность шагов и условия опытнейшей эксплуатации, планово-финансовые и отчетные характеристики;
При всем этом все обозначенные деяния в неотклонимом порядке документируются, согласуются и утверждаются всеми заинтересованными и ответственными сторонами.
Фаза «Реализация проекта». Во время проведения главных работ по внедрению создается, устанавливается и изменяется системная среда, определяются процедуры системного администрирования, инсталлируются главные программно-аппаратные комплексы и приложения. В системе настраиваются организационно-штатные и организационно-функциональные структуры компании с внедрением таковых организационных единиц, как филиал, департамент, отдел, рабочая группа и т. д.
Осуществляется установка, конфигурирование и настройка сетевых и телекоммуникационных средств, делается перенос данных из прежних локальных систем и формирование интерфейсов с унаследованными и наружными системами. При всем этом все создаваемые модели, планы, рабочие программные продукты, документация помещаются в сквозной репозиторий проекта внедрения (рис. 3). Принципиальной частью этого репозитория является система документации, создаваемая в рамках проекта (рис. 4).
Отрабатываются системные вопросцы сохранности работы системы в многопользовательском режиме. Создаются приложения, шаблоны, отчеты, клиентские формы доступа, распределяются возможности юзеров. Проводится «прогонка» всех систем в «боевом режиме» с ролью всех заинтересованных сторон.
Опосля окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.
7. Причины фуррора и предпосылки неудачных внедрений ИС
моделирование информационный реинжиниринг бизнес
Согласно мировой статистике, лишь третья часть проектов разработки и внедрения информационных систем заканчиваются фуррором. О подобных исследовательских работах в Рф ничего не понятно, но представляется, что у нас дела обстоят еще ужаснее.
Удачный проект заканчивается в намеченный срок, укладывается в запланированный бюджет, и при всем этом достигаются намеченные результаты. А что происходит с остальными проектами? Они или тянутся намного подольше, чем ожидалось, требуя все новейшего и новейшего финансирования, или создается автоматическая система, которая никому не нужна, и никто не желает либо не может с ней работать.
Плохие проекты весьма похожи один на иной. Они, как как будто копируют друг дружку, проигрывая один и этот же сценарий. Долголетние наблюдения за грешной практикой побудили меня написать несколько правил для управляющих компаний, которые посодействуют им избежать более обычных ошибок при осуществлении автоматизации управления предприятием. Они идиентично отлично подступают для проектов автоматизации бюджетирования, управленческого учета, управления созданием и остальных областей корпоративного управления.
Необходимо выделить, что эти советы адресованы, до этого всего, высокому управлению организации, другими словами, собственнику либо генеральному директору компании, которые выступают?заказчиками? конфигураций в области корпоративного управления, и, в том числе, сотворения автоматических систем. Неверное осознание лицами?высшего эшелона? собственной роли в таковых проектах является главный предпосылкой неудач схожих начинаний.
1-ое. Обусловьте цель проекта
Согласно данным той же статистики, 70 процентов неудачных проектов стали такими вследствие неопределенности их целей. Иными словами, вначале не был верно определен конечный итог.
Пример из практики. Управляющий службы информационных технологий 1-го большого холдинга получает от генерального директора задание ввести автоматическую систему для обеспечения верхнего уровня корпоративного управления оперативной и достоверной информацией. Управляющий ИТ-службы в поисках программного обеспечения, пригодного для решения намеченных целей, обращается к консультантам. На наш вопросец о том, какие трудности побудили управление компании к внедрению автоматической системы, дается последующий ответ:
· отсутствие одного формата представления данных управленческого учета.
· отсутствие регламентов формирования управленческих отчетов.
· отсутствие единой информационной среды
Совсем ясно, что 1-ые две?трудности? не имеют дела к автоматизации, а крайняя не является неувязкой, так как наличие?единой информационной среды? {само по себе} никакой практической полезности не представляет.
Ознакомление с настоящим положением дел в компании привело к осознанию, что существует неувязка делегирования возможностей управляющего компании менеджерам бизнес-подразделений. Она обязана решаться при помощи контроллинга, основанного на постоянном планировании и управленческом учете, также правильной мотивации менеджеров. Иными словами, речь обязана идти сначала о постановке действий управления на корпоративном уровне, и лишь опосля этого? о автоматизации этих действий. Осознав это, руководители компании сберегли много средств, отказавшись от глупой автоматизации.
Глубочайшее осмысление целей проекта может привести к отказу от его воплощения либо перенесению его сроков в связи с пересмотром ценностей.
Цели автоматизации нужно формулировать не в определениях технических преимуществ, а исходя из убеждений интересов бизнеса. Они могут определяться, к примеру, таковым образом:
· сокращение припасов на складе за счет наиболее четкого планирования производства и закупок;
· сокращение дебиторской задолженности, за счет информационного обеспечения работы с дебиторами;
· выполнение большего числа вкладывательных проектов за счет исключения рутинных операций, выполняемых квалифицированными менеджерами.
Такое определение целей дозволит для вас осознать, для чего вы сиим занимаетесь, сколько вы готовы заплатить за решение этих заморочек и, что весьма принципиально, получить аспекты фуррора проекта, по которым можно оценивать конечные результаты.
2-ое. Откройте проект
Внедрение автоматической системы
— это стратегический проект компании. Он должен быть открыт приказом генерального директора. В приказе определяются цели и сроки проекта, назначается управляющий проекта.
Пример из практики. Управляющий 1-го большого банка дает поручение менеджеру денежного управления заняться внедрением системы бюджетирования. Невзирая на то, что с момента предназначения прошло уже более одного года, назначенный менеджер не соображает какие у него возможности в связи с сиим поручением, каких результатов и в какие сроки от него ждут. Проект как бы существует, но дело не движется.
Иными словами, необходимо ясно осознавать, что проект? это настоящая организационная структура, временно сделанная снутри организации для заслуги полностью определенных целей.
Назначенный генеральным директором управляющий сформировывает команду проекта. В нее должны войти руководители подразделений и спецы, заинтригованные в конечном итоге и компетентные в предметной области проекта. Так, если внедряется система бюджетирования, то команда проекта составляется из управляющих и профессионалов денежной и ИТ-служб, также представителей производственных и сбытовых подразделений. Управляющим проекта должен быть менеджер, занимающий в организационной структуре компании положение наиболее высочайшее, чем хоть какой член команды проекта.
Третье. Обеспечьте проект ресурсами
Главные ресурсы
— это средства и люди. Потому нужно утвердить бюджет проекта.
Оценка нужных ресурсов — сложная задачка, и все таки на шаге обоснования проекта принципиально осознать, какой бюджет считается применимым на развитие управленческих технологий и внедрение автоматической системы. Дело том, что решение хоть какой задачки — это треугольник: средства — время — итог. Если буквально определен хотимый итог, то можно высчитать время, нужное для его заслуги, и бюджет. Если же нет точного представления, что является «неплохим результатом» (другими словами, не определены буквально цели проекта), то можно идти от бюджета, и решать задачку в таком виде: какого наибольшего управленческого эффекта можно достигнуть, если проинвестировать определенную сумму на постановку действий управления и внедрение информационных технологий?
Не считая того, принципиально выделить часть рабочего времени людей занятых в проекте, на выполнение ими работы, связанной с внедрением системы. По другому?текучка? сгубит дело. Обширно всераспространенная практика такая, что сотрудниками поручают заниматься внедрением новейшей системы управления?факультативно?. Так как основная их перегрузка при всем этом не понижается, то к доборной работе они относятся или как к хобби, или как к обидной обузе, зависимо от степени их заинтригованности. Такое отношение является полностью закономерным, ведь управление компании, поручив им неоплачиваемую доп работу, показало собственное отношение к ней, как к чему-то второстепенному.
Управление человечьими ресурсами проекта подразумевает бюджетирование времени исполнителей. Учет практически потраченного времени нужен не только лишь для адекватной оплаты труда исполнителей, да и для правильной оценки издержек на воплощение проекта.
4-ое. Похлопочите о мотивации
Мотивация
— главный отран управления, потому следует кропотливо обмыслить схему мотивации исполнителей проекта. Не непременно это должны быть огромные премии за успешное внедрение системы.
Почаще всего внедрение новейшей системы управления содействует увеличению статуса участников данной работы, увеличивает их проф уровень. Это очень важные стимулы. Дело в том, что люди творческого склада разглядывают работу как средство увеличения собственного умственного капитала. Такие спецы представляют самую большую ценность для хоть какого дела, связанного с нововведениями.
Руководителю, формирующему команду проекта принципиально верно осознавать ожидания исполнителей, связанные с фуррором этого дела. Это быть может служебный рост, увеличение заработной платы, получение новейших познаний, достижение новейшей высоты в проф росте.
5-ое. Поддержка управления
Фуррор вероятен лишь в случае решительной поддержки проекта высшим управлением компании. Если генеральный директор считает, что внедрение автоматической системы
— это дело лишь ИТ-службы, то ничего неплохого из этого не выйдет.
Ввести информационные технологии — означает не попросту установить программки на рабочие места. Такие проекты соединены с конфигурацией рабочих и управленческих действий, перераспределением ответственности и возможностей. Эти конфигурации нередко вступают в конфликт (наиболее острый способ разрешения противоречий в интересах, целях, взглядах, возникающий в процессе социального взаимодействия) с интересами тех либо других управляющих подразделений и служащих. В итоге начинается саботаж либо открытое противодействие изменениям. Потому управляющий организации должен ясно показать на чьей он стороне и, в случае необходимости жесткой рукою подавить сопротивление, оказывая поддержку команде проекта.
Шестое. Разбейте проект на этапы
Долгий проект идеальнее всего
«разрезать на кусочки», и не приступать к следующему шагу, не убедившись, что задачки предшествующего шага вполне выполнены. Весьма принципиально найти, что обязано стать результатом всякого шага проекта.
Так, к примеру, если идет речь о разработке автоматической системы экономного управления, рекомендуется последовательность шагов, представленная на рисунке.
Перебегать к следующему шагу можно лишь опосля выполнения 3-х критерий:
· команда проекта выработала единое осознание результатов шага;
· это осознание оформлено в виде документа;
· результаты шага приняты заказчиком, другими словами управляющим компании.
Таковой подход дозволяет надзирать опасности проекта, двигаясь поступательно к поставленной задачи.
Седьмое. Управляйте целями и ожиданиями
Цели проекта могут корректироваться либо даже значительно изменяться в процессе работы. Это рядовая практика. Изменяется обстановка, изменяется наше осознание ситуации, и мы приходим к выводу, что прежние наши взоры устарели, либо были неверными. Потому необходимо часто (на любом шаге проекта) ворачиваться?к истокам? и критически разглядывать все начальные предпосылки.
И крайнее. Необходимо иметь мужество закрыть проект, если становится понятно, что он зашел в тупик. Управляющий проекта, выступивший с инициативой о прекращении безвыходного проекта заслуживает поощрения, как ответственный менеджер, предотвративший бесцельное расходование средств компании.
Обычно выделяют последующие этапы сотворения ИС:
1. формирование требований к системе,
2. проектирование,
3. реализация,
4. тестирование,
5. ввод в действие,
6. эксплуатация и сопровождение.
Исходным шагом процесса сотворения ИС, опосля определения цели сотворения системы, является моделирование бизнес-процессов – совокупы взаимосвязаны работ для решения определенной задачки, которые протекают в организации и реализующих ее цели и задачки. Модель организации, описанная в определениях бизнес-процессов и бизнес-функций, дозволяет сконструировать главные требования к ИС.
Целью исходных шагов сотворения ИС, выполняемых на стадии анализа деятельности организации, является формирование требований к ИС
, корректно и буквально отражающих цели и задачки организации-заказчика. Чтоб специфицировать процесс сотворения ИС, отвечающей потребностям организации, необходимо узнать и верно сконструировать, в чем заключаются эти потребности. Для этого нужно найти требования заказчиков к ИС и показать их на языке моделей в требования к разработке проекта ИС так, чтоб обеспечить соответствие целям и задачкам организации.
На шаге проектирования
до этого всего формируются модели данных. Проектировщики в качестве начальной инфы получают результаты анализа. Построение логической и физической моделей данных является главный частью проектирования базы данных. Приобретенная в процессе анализа информационная модель поначалу преобразуется в логическую, а потом в физическую модель данных.
Наряду с проектированием схемы базы данных производится проектирование действий, чтоб получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесновато соединены, так как часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Основная цель проектирования действий заключается в отображении функций, приобретенных на шаге анализа, в модули информационной системы. Конечными продуктами шага проектирования являются схема базы данных (на основании ER-модели, разработанной на шаге анализа) и набор спецификаций модулей системы (они строятся на базе моделей функций).
Не считая того, на шаге проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компов на различных аппаратных платформах и под управлением разных операционных систем. Не считая выбора платформы, на шаге проектирования определяются некие свойства архитектуры (файл-серверная либо клиент-серверная, централизованная БД либо распределенная, однородная БД либо нет, будут ли употребляться параллельные серверы БД для увеличения производительности). Шаг проектирования заканчивается разработкой технического проекта ИС.
На шаге реализации
осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.
Шаг тестирования
обычно оказывается распределенным во времени.
Опосля окончания разработки отдельного модуля системы делают автономный тест, который преследует две главные цели: обнаружение отказов модуля и соответствие модуля спецификации (наличие всех нужных функций, отсутствие излишних функций). Опосля того как автономный тест удачно пройдет, модуль врубается в состав разработанной части системы и группа сгенерированных модулей проходит испытания связей, которые должны отследить их обоюдное воздействие. Дальше группа модулей тестируется на надежность работы, другими словами проходят, во-1-х, испытания имитации отказов системы, а во-2-х, испытания выработки на отказ. Потом весь набор модулей проходит системный тест — тест внутренней приемки продукта, показывающий уровень его свойства. Сюда входят испытания функциональности и испытания надежности системы. Крайний тест информационной системы — приемо-сдаточные тесты. Таковой тест предугадывает показ информационной системы заказчику и должен содержать группу тестов, моделирующих настоящие бизнес-процессы, чтоб показать соответствие реализации требованиям заказчика.
2. Понятие «архитектура информационной системы»
Разглядим определение «архитектуры информационной системы», которое дают разные источники:
Архитектура
– это организационная структура системы.
АрхитектураИС
– теория, определяющая модель, структуру, выполняемые функции и связь компонент информационной системы.
Архитектура
– это базисная организация системы, воплощенная в ее компонентах, их отношениях меж собой и с окружением, также принципы, определяющие проектирование и развитие системы.
Архитектура
–
это набор важных решений по поводу организации системы программного обеспечения, набор структурных частей и их интерфейсов, с помощью которых компонуется система, вкупе с их поведением, определяемым во содействии меж этими элементами, сборка частей в равномерно укрупняющиеся подсистемы, также стиль архитектуры
, который направляет эту компанию – элементы и их интерфейсы, взаимодействия и компоновку.
Архитектура
– это структура организации и связанное с ней поведение системы. Архитектуру
можно рекурсивно разобрать на части, взаимодействующие средством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые ведут взаимодействие через интерфейсы, включают классы, составляющие и подсистемы.
Если все эти определения соединить, то получим последующее:
Архитектурой ИС
именуется принципная организация компонент ИС, связей меж ними и наружным окружением, также принципы и средства разработки и поддержки систем.
Под архитектурой программных систем будем осознавать совокупа решений относительно:
· организации программной системы;
· выбора структурных частей, составляющих систему и их интерфейсов;
· поведения этих частей во содействии с иными элементами;
· объединение этих частей в подсистемы;
· строительного стиля, определяющего логическую и физическую компанию системы: статические и динамические элементы, их интерфейсы и методы их объединения.
Архитектура
программной системы обхватывает не только лишь ее структурные и поведенческие нюансы, да и правила ее использования и интеграции с иными системами, функциональность, производительность, упругость, надежность, возможность повторного внедрения, полноту, экономические и технологические ограничения, также вопросец пользовательского интерфейса.
По мере развития программных систем все большее значение приобретает их интеграция вместе с целью построения одного информационного места компании.
Внедрение корпоративной ИС, разработанной без помощи других либо полученной у поставщика, часто сопровождается ломкой (перепроектированием) имеющихся на предприятии бизнес-процессов. Приходится перестраивать их под требования эталонов и логику внедряемой системы. Отметим сходу, что внедрение ИС решает ряд управленческих и технических заморочек, но порождает трудности, связанные с человечьим фактором.
Внедрение новейшей ИС — непростой процесс, длящийся от нескольких месяцев для маленьких ИС до пары лет для ИС огромных распределенных компаний с широкой номенклатурой товаров и огромным количеством поставщиков. Фуррор проекта по разработке (либо приобретению) и внедрению ИС почти во всем зависит от готовности компании к ведению проекта, личной заинтригованности и воли управления, настоящей программки действий, наличия ресурсов, обученного персонала, возможности к преодолению сопротивления на всех уровнях сложившейся организации.
К истинному времени сложился обычный набор приемов внедрения ИС. Основное правило: делать неотклонимые фазы поочередно и не пропускать ни одной из их
.
Критически необходимыми для внедрения являются последующие причины
:
· наличие верно сформулированных целей проекта и требований к ИС;
· наличие стратегии внедрения и использования ИС;
· проведение предпроектного обследования компании и построения моделей «Как есть» и «Как будет»;
· планирование работ, ресурсов и контроль выполнения плана внедрения;
· роль высшего управления во внедрении системы;
· проведение работ по внедрению ИС спецами по интегрированию систем вместе со спецами компании;
· постоянный мониторинг свойства выполняемых работ;
· резвое получение положительных результатов хотя бы в части внедренных модулей ИС либо в процессе ее опытнейшей эксплуатации.
Перед началом разработки проекта внедрения
нужно:
· очень формализовать цели проекта внедрения ИС;
· оценить мало нужные издержки и статьи расхода;
· установить высочайший ценность проекта внедрения перед остальными текущими проектами;
· наделить управляющего проекта очень вероятными возможностями;
· провести массовую просветительскую работу с персоналом компании с целью довести до всякого значимость и необходимость грядущих преобразований;
· создать организационные меры для внедрения новейших информационных технологий;
· распределить индивидуальную ответственность по всем шагам внедрения и опытнейшей эксплуатации.
Нужно также найти многофункциональные сферы внедрения модулей информационной системы:
· организационное управление;
· организационно-административное обеспечение;
· управление бизнес-процессами;
· управленческий, планово-финансовый и бухгалтерский учет;
· управление персоналом;
· управление документацией;
· управление материально-техническим обеспечением;
· управление связями с клиентами и наружной средой.
Не считая того, что перечислено выше, нужно задать технологические требования
к внедрению ИС:
· системная платформа
— внедрение и адаптация готового решения от производителя либо разработка на заказ в согласовании с техническим заданием заказчика;
· интегрируемость
— данные хранятся и обрабатываются в едином информационном пространстве; это обеспечивает их полноту, непротиворечивость, достоверность и возможность неоднократного использования; система может включать в себя вновь разработанные и уже применяемые технологии и приложения;
· адаптируемость
— система настраивается в согласовании с требованиями заказчика и на индивидуальности информационного поля заказчика;
· распределенность
— система может отлично работать в территориально удаленных подразделениях и филиалах компании;
· масштабируемость
— система может производиться в виде каркаса, содержащего базисные модули, и дополняться в согласовании с требованиями изменяющейся наружной и внутренней среды.
6.6.1 Главные фазы внедрения информационной системы
Фаза «Подготовительные работы по подготовке проекта внедрения ИС»
. В процессе предпроектного обследования компании (рис. 4) происходит сбор подробной инфы о структурном построении организации, многофункциональных связях, системе управления, о главных бизнес-процессах, о потоках снутри компании (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), нужной для построения соответственных моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.
Фаза «Подготовка проекта»
. Опосля окончания первой фазы осуществляется предварительное планирование и формирование процедур пуска проекта:
· формирование проектной и экспертной групп;
· распределение возможностей и ответственности;
· определение организационно-технических требований к процессу внедрения;
· уточнение спецификаций и ожиданий заказчика;
· обучение (педагогический процесс, в результате которого учащиеся под руководством учителя овладевают знаниями, умениями и навыками) группы внедрения, состоящей из профессионалов предприятия-заказчика.
Крайний, весьма принципиальный момент почему-либо нередко пропускается при составлении плана внедрения. А ведь от него в большой степени зависит фуррор всего проекта! Опосля начала финансирования проект считается запущенным к выполнению.
Фаза «Мировозренческая проработка проекта»
. В течение данной фазы:
· формируется и утверждается концептуальный проект;
· уточняются и конкретизируются цели и задачки проекта;
· определяются размеры макета системы;
· согласуются укрупненный план работы, последовательность шагов и условия опытнейшей эксплуатации, планово-финансовые и отчетные характеристики;
При всем этом все обозначенные деяния в неотклонимом порядке документируются, согласуются и утверждаются всеми заинтересованными и ответственными сторонами.
Фаза «Реализация проекта»
. Во время проведения главных работ по внедрению создается, устанавливается и изменяется системная среда, определяются процедуры системного администрирования, инсталлируются главные программно-аппаратные комплексы и приложения. В системе настраиваются организационно-штатные и организационно-функциональные структуры компании с внедрением таковых организационных единиц, как филиал, департамент, отдел, рабочая группа и т.д.
Набросок 12 — Примерное содержание репозитория проекта внедрения
Осуществляется установка, конфигурирование и настройка сетевых и телекоммуникационных средств, делается перенос данных из прежних локальных систем и формирование интерфейсов с унаследованными и наружными системами. При всем этом все создаваемые модели, планы, рабочие программные продукты, документация помещаются в сквозной репозиторий проекта внедрения (рис. 12). Принципиальной частью этого репозитория является система документации, создаваемая в рамках проекта (рис. 13).
Набросок 13 — Примерный состав документации по процессу внедрения информационной системы
Отрабатываются системные вопросцы сохранности работы системы в многопользовательском режиме. Создаются приложения, шаблоны, отчеты, клиентские формы доступа, распределяются возможности юзеров. Проводится «прогонка» всех систем в «боевом режиме» с ролью всех заинтересованных сторон.
Опосля окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.
Контрольные вопросцы
1. Что такое «открытая информационная система»? Перечислите главные характеристики открытых систем.
2. Охарактеризуйте сущность современного процессного подхода к управлению деятельностью компании и использования этого подхода при разработке ИС.
3. Какие модели и каким образом употребляются при проектировании информационных систем?
4. Какие программные средства употребляются для моделирования действий при разработке информационных систем?
5. На основании каких данных и инфы разрабатываются модели состояния AS IS и AS TO BE?
6. Кто в компании занимается вопросцами разработки, внедрения и развития ИС? Кто участвует в подготовке технического задания на разработку ИС?
7. Назовите главные этапы проектирования информационных технологий.
8. Перечислите этапы актуального цикла информационной системы.
9. На каком шаге разработки и внедрения ИС делается обучение (педагогический процесс, в результате которого учащиеся под руководством учителя овладевают знаниями, умениями и навыками) персонала компании?
10. Перечислите главные фазы внедрения ИС.
Источник: