Добавлен: 23.11.2023
Просмотров: 58
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
которых должны концентрироваться усилия, а также указано, какие элементы должны быть доработаны для завершения текущего контрольной точки процесса разработки. Здесь же должен предоставляться список наиболее значимых факторов риска или факторов, которые необходимо исследовать для разрешения соответствующих проблем.
Архитектура приложения и соответствующие диаграммы состояний. Эта информация отражает технические аспекты плана. Для мобильных приложений этот раздел должен содержать соответствующие диаграммы состояний, описывающие дискретные состояния, в которых может находиться приложение, и связь этих состояний с объемами памяти и ресурсов, которые будут в ней храниться. (Далее об этом будет говориться более подробно.) Такой раздел фактически играет роль соглашения между всеми участниками группы разработчиков, в котором они обязуются придерживаться в своих реализациях установленных в нем требований. Если вы выступаете в роли единственного разработчика, то этот документ даст вам возможность оставаться честным перед самим собой; у каждого, кому довелось хотя бы однажды самостоятельно разрабатывать крупный проект, наверняка иногда возникало желание срезать тот или иной угол, чтобы добиться работоспособности средства, пусть даже это и будет в ущерб разумным принципам проектирования. Срезоть углы гораздо сложнее, если перед вашими глазами находится соглашение, в котором указано, что вы должны в явной виде формулировать все свои предложения по ускорению работы над проектом. Этот раздел не должен быть чрезмерно длинным или сложным, ибо в противном случае выполнять его требования будет трудно, и им будут просто пренебрегать. В нем должно быть сформулировано, что необходимо сделать для того, чтобы проект удерживался в организационном русле, и, что еще важнее, в нем должны оперативно учитываться любые согласованные изменения проекта.
План разработки с указанием отдельных контрольных точек. Еще более важную, чем календарный график, роль играет взвешенный план, устанавливающий дискретный набор контрольных точек проекта, которые должны проходиться по мере приближения проекта к завершению. По самому своему определению контрольные точки позволяют оценивать прогресс, достигаемый на пути к определенной конечной цели. Каждая контрольная точка представляет собой точку покоя, в которой вы можете остановиться, чтобы оценить состояние работ, подчистить код, который не был своевременно приведен в порядок, и при необходимости скорректировать проект. По мере выполнения проектных работ цели могут меняться, что влечет за собой необходимость корректировки контрольных точек; это допускается. В соответствии с эволюцией проекта может меняться его архитектура, что, в свою очередь, может потребовать внесения изменений в модель состояний; и это нормально. Можно почти не сомневаться, что пользовательский интерфейс также будет несколько раз переделываться.
Основными чертами типовых проектных решений (ТПР) их объединяющими являются следующие:
· Типовые проектные решения ориентированы на автоматизацию деятельности множества однородных объектов (путем настройки под конкретные особенности каждого из них).
· Основная цель применения ТПР – уменьшение трудоемкости и стоимости проектирования и/или разработки ИС.
· Создание ТПР возможно только после тщательного и всестороннего изучения предметной области и предполагает обобщение накопленного в частных случаях опыта (путем классификации, типизации, абстрагирования, унификации и т.п.).
Типовые решения бывают простыми или комбинированными. Простые ТПР охватывают только какой-либо один вид обеспечения ИС, комбинированные – два и более. Примеры простых ТПР: Классификаторы (информационное обеспечение), прикладные программы общего и специального назначения (программное обеспечение), инструктирующие руководства по управлению бизнес-процессами (организационное обеспечение), рекомендации по составлению ТЗ (методическое обеспечение) и т.п. Из простых ТПР может быть сформировано комбинированное решение, например, решающее одну из функциональных задач.
Требования, выдвигаемые к типовым проектным решениям:
· Возможность использования для создания новой ИС при минимальном участии разработчиков ТПР;
· Соответствие требованиям положений и стандартов, распространяемых на информационную системe в целом или ее часть.
· Способность удовлетворять максимально возможному числу потребностей в рамках своего функционального назначения.
· Возможность адаптации к конкретным условиям проекта путем изменения параметров.
Приведенная ниже классификация методов формирования ТПР основана на уровне декомпозиции системы. Выделяются следующие методы ТПР:
1. Элементные ТПР (создается решение для отдельного элемента системы) - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному).
В качестве типового элемента используются простые ТПР, относящиеся к отдельной задаче ИС. В этом случае ИС комплектуется как множество ТПР по отдельным разрозненным задачам. Дополнительные элементы, для которых отсутствуют ТПР, разрабатываются вручную. Обычно рассматривают три группы элементных ТПР:
o Типовые проектные решения, относящиеся к основным задачам ИС (алгоритмы решения задач,
описание входных и выходных данных, программные модули общего и специального назначения и т.д.) – ТПР – задача;
o Типовые проектные решения, обеспечивающие оптимальный выбор и организацию технических средств- ТПР – техника;
o Типовые проектные решения, описывающие должностные инструкции всех категорий работников, связанных с проектированием и функционированием ИС – ТПР - персонал.
Существенный недостаток метода: между отдельными ТПР, как правило, отсутствует информационная/техническая/программная совместимость (проблема «лоскутной автоматизации»).
2. Подсистемные ТПР (создается решение для отдельной функциональной подсистемы системы) Типовыми элементами выступают пакеты прикладных программ (ППП), которые применяются для автоматизации отдельных функциональных подсистем ИС. ППП должны обладать следующими свойствами:
o Функциональная полнота;
o Минимизация внешних информационных связей;
o Параметрическая настраиваемость;
o Полная интеграция внутри ППП и более высокий (хотя и не полный) уровень интеграции с другими пакетами и отдельными программными продуктами.
С точки зрения проектировщика ИС ППП представляет собой «черный ящик», который преобразует входные информационный и параметрический потоки в выходной поток результатов. В схеме ППП можно выделить следующие элементы:
Информационный поток – исходные данные в электронном или бумажном виде, предназначенные для обработки пакетом;
Результаты работы – представляются в виде отчетов, графиков или документов (в электронном или бумажном виде);
Блок функционирования – содержит алгоритм обработки исходных данных.
Параметрический поток – содержит информацию, необходимую для настройки пакета на конкретные условия функционирования. Изменяя параметры, можно включать и выключать какие-либо модули или влиять на режим их работы. Обычно параметрическая информация предоставляется пользователю в виде справочников и/или конфигурационных таблиц.
Блок обработки параметров – интерпретирует значения параметров и переносит их непосредственно в прикладные программы.
Блок адаптации – позволяет пользователю адаптировать существующие типовые решения путем доработки существующих или добавления новых модулей ИС. В блок адаптации обычно включаются такие средства как генераторы отчетов, генераторы форм, встроенные макроязыки и т.п.
В зависимости от принципа использования параметрического потока выделяют два способа привязки ППП к конкретным условиям системы:
· Принцип генерации (на его основе специальная программа-генератор генерирует ППП, настроенный под конкретные условия);
· Принцип интерпретации (поглощается самим ППП, что видно на рис.12).
ППП включает в себя следующие рабочие блоки: функционирования, обработки параметров, адаптации.
Сущность применения метода типового проектирования на основе параметрической настройки заключается в определении критериев оценки ППП, оценке множества ППП претендентов, выбору и закупке ППП с наивысшей совокупной оценкой по сформулированным критериям, настройке параметров и возможной доработке закупленного ППП.
Рисунок 1. Совокупность рабочих блоков в ППП
Основные группы критериев оценки пакета прикладных программ:
• назначение и возможности пакета,
• отличительные признаки и свойства пакета,
• требования к техническим и программным средствам,
• документация пакета,
• особенности установки пакета,
• особенности эксплуатации пакета,
• помощь поставщика по внедрению и поддержанию пакета,
• оценка качества пакета и опыт его использования,
• перспективы развития пакета.
Пример ППП: «1С: Бухгалтерия».
Недостаток: недостаточный уровень совместимости различных ППП в рамках единой корпоративной ИС.
3. Объектные ТПР.
Идея метода заключается в создании и повторном использовании законченного (т.е. с полным набором функциональных и обеспечивающих подсистем) типового проекта для автоматизации управления объектом определенной отрасли. Например, ИС школы, ИС больницы, ИС товарного склада и т.п. Сложность применения объектного метода заключается в огромном разнообразии различных объектов, что требует от разработчиков необходимости предусматривать все возможные варианты. Современные типовые проекты должны обладать следующими свойствами:
o Ориентированы для применения на объектах с высоким уровнем стабильности;
o Открытость архитектуры (возможность использования на различных программно-технических платформах);
o Высокий уровень масштабируемости;
o Высокий уровень адаптивности (возможность конфигурирования в широких пределах).
Объектный метод по определению обеспечивает полную программную совместимость компонентов системы.
Каждое типовое решение предполагает, кроме собственно функциональных элементов (программных или аппаратных), еще и наличие:
· документации с детальным описанием ТПР
· и процедур настройки в соответствии с требованиями разрабатываемой системы.
Архитектура приложения и соответствующие диаграммы состояний. Эта информация отражает технические аспекты плана. Для мобильных приложений этот раздел должен содержать соответствующие диаграммы состояний, описывающие дискретные состояния, в которых может находиться приложение, и связь этих состояний с объемами памяти и ресурсов, которые будут в ней храниться. (Далее об этом будет говориться более подробно.) Такой раздел фактически играет роль соглашения между всеми участниками группы разработчиков, в котором они обязуются придерживаться в своих реализациях установленных в нем требований. Если вы выступаете в роли единственного разработчика, то этот документ даст вам возможность оставаться честным перед самим собой; у каждого, кому довелось хотя бы однажды самостоятельно разрабатывать крупный проект, наверняка иногда возникало желание срезать тот или иной угол, чтобы добиться работоспособности средства, пусть даже это и будет в ущерб разумным принципам проектирования. Срезоть углы гораздо сложнее, если перед вашими глазами находится соглашение, в котором указано, что вы должны в явной виде формулировать все свои предложения по ускорению работы над проектом. Этот раздел не должен быть чрезмерно длинным или сложным, ибо в противном случае выполнять его требования будет трудно, и им будут просто пренебрегать. В нем должно быть сформулировано, что необходимо сделать для того, чтобы проект удерживался в организационном русле, и, что еще важнее, в нем должны оперативно учитываться любые согласованные изменения проекта.
План разработки с указанием отдельных контрольных точек. Еще более важную, чем календарный график, роль играет взвешенный план, устанавливающий дискретный набор контрольных точек проекта, которые должны проходиться по мере приближения проекта к завершению. По самому своему определению контрольные точки позволяют оценивать прогресс, достигаемый на пути к определенной конечной цели. Каждая контрольная точка представляет собой точку покоя, в которой вы можете остановиться, чтобы оценить состояние работ, подчистить код, который не был своевременно приведен в порядок, и при необходимости скорректировать проект. По мере выполнения проектных работ цели могут меняться, что влечет за собой необходимость корректировки контрольных точек; это допускается. В соответствии с эволюцией проекта может меняться его архитектура, что, в свою очередь, может потребовать внесения изменений в модель состояний; и это нормально. Можно почти не сомневаться, что пользовательский интерфейс также будет несколько раз переделываться.
Основными чертами типовых проектных решений (ТПР) их объединяющими являются следующие:
· Типовые проектные решения ориентированы на автоматизацию деятельности множества однородных объектов (путем настройки под конкретные особенности каждого из них).
· Основная цель применения ТПР – уменьшение трудоемкости и стоимости проектирования и/или разработки ИС.
· Создание ТПР возможно только после тщательного и всестороннего изучения предметной области и предполагает обобщение накопленного в частных случаях опыта (путем классификации, типизации, абстрагирования, унификации и т.п.).
Типовые решения бывают простыми или комбинированными. Простые ТПР охватывают только какой-либо один вид обеспечения ИС, комбинированные – два и более. Примеры простых ТПР: Классификаторы (информационное обеспечение), прикладные программы общего и специального назначения (программное обеспечение), инструктирующие руководства по управлению бизнес-процессами (организационное обеспечение), рекомендации по составлению ТЗ (методическое обеспечение) и т.п. Из простых ТПР может быть сформировано комбинированное решение, например, решающее одну из функциональных задач.
Требования, выдвигаемые к типовым проектным решениям:
· Возможность использования для создания новой ИС при минимальном участии разработчиков ТПР;
· Соответствие требованиям положений и стандартов, распространяемых на информационную системe в целом или ее часть.
· Способность удовлетворять максимально возможному числу потребностей в рамках своего функционального назначения.
· Возможность адаптации к конкретным условиям проекта путем изменения параметров.
Приведенная ниже классификация методов формирования ТПР основана на уровне декомпозиции системы. Выделяются следующие методы ТПР:
1. Элементные ТПР (создается решение для отдельного элемента системы) - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному).
В качестве типового элемента используются простые ТПР, относящиеся к отдельной задаче ИС. В этом случае ИС комплектуется как множество ТПР по отдельным разрозненным задачам. Дополнительные элементы, для которых отсутствуют ТПР, разрабатываются вручную. Обычно рассматривают три группы элементных ТПР:
o Типовые проектные решения, относящиеся к основным задачам ИС (алгоритмы решения задач,
описание входных и выходных данных, программные модули общего и специального назначения и т.д.) – ТПР – задача;
o Типовые проектные решения, обеспечивающие оптимальный выбор и организацию технических средств- ТПР – техника;
o Типовые проектные решения, описывающие должностные инструкции всех категорий работников, связанных с проектированием и функционированием ИС – ТПР - персонал.
Существенный недостаток метода: между отдельными ТПР, как правило, отсутствует информационная/техническая/программная совместимость (проблема «лоскутной автоматизации»).
2. Подсистемные ТПР (создается решение для отдельной функциональной подсистемы системы) Типовыми элементами выступают пакеты прикладных программ (ППП), которые применяются для автоматизации отдельных функциональных подсистем ИС. ППП должны обладать следующими свойствами:
o Функциональная полнота;
o Минимизация внешних информационных связей;
o Параметрическая настраиваемость;
o Полная интеграция внутри ППП и более высокий (хотя и не полный) уровень интеграции с другими пакетами и отдельными программными продуктами.
С точки зрения проектировщика ИС ППП представляет собой «черный ящик», который преобразует входные информационный и параметрический потоки в выходной поток результатов. В схеме ППП можно выделить следующие элементы:
Информационный поток – исходные данные в электронном или бумажном виде, предназначенные для обработки пакетом;
Результаты работы – представляются в виде отчетов, графиков или документов (в электронном или бумажном виде);
Блок функционирования – содержит алгоритм обработки исходных данных.
Параметрический поток – содержит информацию, необходимую для настройки пакета на конкретные условия функционирования. Изменяя параметры, можно включать и выключать какие-либо модули или влиять на режим их работы. Обычно параметрическая информация предоставляется пользователю в виде справочников и/или конфигурационных таблиц.
Блок обработки параметров – интерпретирует значения параметров и переносит их непосредственно в прикладные программы.
Блок адаптации – позволяет пользователю адаптировать существующие типовые решения путем доработки существующих или добавления новых модулей ИС. В блок адаптации обычно включаются такие средства как генераторы отчетов, генераторы форм, встроенные макроязыки и т.п.
В зависимости от принципа использования параметрического потока выделяют два способа привязки ППП к конкретным условиям системы:
· Принцип генерации (на его основе специальная программа-генератор генерирует ППП, настроенный под конкретные условия);
· Принцип интерпретации (поглощается самим ППП, что видно на рис.12).
ППП включает в себя следующие рабочие блоки: функционирования, обработки параметров, адаптации.
Сущность применения метода типового проектирования на основе параметрической настройки заключается в определении критериев оценки ППП, оценке множества ППП претендентов, выбору и закупке ППП с наивысшей совокупной оценкой по сформулированным критериям, настройке параметров и возможной доработке закупленного ППП.
Рисунок 1. Совокупность рабочих блоков в ППП
Основные группы критериев оценки пакета прикладных программ:
• назначение и возможности пакета,
• отличительные признаки и свойства пакета,
• требования к техническим и программным средствам,
• документация пакета,
• особенности установки пакета,
• особенности эксплуатации пакета,
• помощь поставщика по внедрению и поддержанию пакета,
• оценка качества пакета и опыт его использования,
• перспективы развития пакета.
Пример ППП: «1С: Бухгалтерия».
Недостаток: недостаточный уровень совместимости различных ППП в рамках единой корпоративной ИС.
3. Объектные ТПР.
Идея метода заключается в создании и повторном использовании законченного (т.е. с полным набором функциональных и обеспечивающих подсистем) типового проекта для автоматизации управления объектом определенной отрасли. Например, ИС школы, ИС больницы, ИС товарного склада и т.п. Сложность применения объектного метода заключается в огромном разнообразии различных объектов, что требует от разработчиков необходимости предусматривать все возможные варианты. Современные типовые проекты должны обладать следующими свойствами:
o Ориентированы для применения на объектах с высоким уровнем стабильности;
o Открытость архитектуры (возможность использования на различных программно-технических платформах);
o Высокий уровень масштабируемости;
o Высокий уровень адаптивности (возможность конфигурирования в широких пределах).
Объектный метод по определению обеспечивает полную программную совместимость компонентов системы.
Каждое типовое решение предполагает, кроме собственно функциональных элементов (программных или аппаратных), еще и наличие:
· документации с детальным описанием ТПР
· и процедур настройки в соответствии с требованиями разрабатываемой системы.