
- •Содержание работ по созданию ас
- •Iso/iec 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного по. Стандарт не содержит описания фаз, стадий и этапов.
- •3. Постановка автоматизируемых экономических задач Описание постановки задачи (комплекса задач) по рд 50-34-698-90 (п.2.6)
- •Постановка задачи контроля товарных запасов
- •Иллюстрация плохой постановки задачи заказчиком (экономистом, финансистом, менеджером, бухгалтером и др.) и ее реализации программистом
Информационные системы в экономике
Ивлиев М.К.
Основы создания АИС
1. Стадии, этапы создания автоматизированных систем
2. Жизненный цикл информационной системы
3. Постановка автоматизируемых экономических задач
4. Пример описания постановки и алгоритма решения задачи
1. Стадии, этапы создания автоматизированных систем
Процесс создания автоматизированных систем (АС) представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединённых в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям.
ГОСТ 34.601-90 Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. (Дата введения 01.01.1992 г.) устанавливает стадии и этапы создания автоматизированных систем.
Настоящий стандарт распространяется на автоматизированные системы, используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях.
Создание автоматизированных систем организаций, предприятий осуществляется также с учетом требований международных, отраслевых стандартов.
Создаваемые в организациях и на предприятиях для управления их деятельностью автоматизированные системы называют информационными системами (ИС), автоматизированными системами управления (АСУ), автоматизированными информационными системами (АИС), корпоративными информационными системами (КИС).
Стадии и этапы создания автоматизированных систем выделяются как части процесса создания по соображениям рационального планирования и организации работ, заканчивающихся заданным результатом.
Информационные системы (АИС, КИС) для управления организациями, предприятиями создаются преимущественно на основе типовых (тиражных) программных комплексов (информационных систем). Они обеспечивают автоматизацию решения типовых регламентированных (бухгалтерского, налогового, кадрового, складского учета и т.п.) и части нерегламентированных задач управления организациями, предприятиями.
Для автоматизации прогнозирования, планирования, оперативного учета, контроля, анализа, решения других нерегламентированных задач управления, определяемых особенностями, спецификой деятельности предприятия, выполняется доработка типового программного комплекса (информационной системы). Доработка осуществляется по ГОСТ 34.601-90, международным, отраслевым стандартам на основе требований к информационной системе конкретного предприятия.
В создании информационной системы принимают участие бухгалтеры, экономисты, финансисты, менеджеры, другие специалисты предприятия. Они, например, участвуют в разработке корпоративных (локальных) классификаторов информации, описании постановки, разработке алгоритмов решения специфических нерегламентированных задач управления.
Работы по развитию автоматизированных систем осуществляют по стадиям и этапам, применяемым для создания АС.
Стадии и этапы создания АС приведены в таблице
Стадии |
Этапы работ |
1. Формирование требований к АС |
1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания) |
2. Разработка концепции АС. |
2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе. |
3. Техническое задание. |
3.1. Разработка и утверждение технического задания на создание АС. |
4. Эскизный проект. |
4.1. Разработка предварительных проектных решений по системе и её частям. 4.2. Разработка документации на АС и её части. |
5. Технический проект. |
5.1. Разработка проектных решений по системе и её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. |
6. Рабочая документация. |
6.1. Разработка рабочей документации на систему и её части. 6.2. Разработка или адаптация программ. |
7. Ввод в действие. |
7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные, пусконаладочные работы, проведение предварительных испытаний. 7.5. Проведение опытной эксплуатации. 7.6. Проведение приёмочных испытаний. |
8. Сопровождение АС |
8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание. |
Стадии этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта.
Допускается исключить стадию “Эскизный проект” и отдельные этапы работ на всех стадиях, объединять стадии “Технический проект” и “Рабочая документация” в одну стадию “Технорабочий проект”. В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
Содержание работ по созданию ас
1. На этапе 1.1. “Обследование объекта и обоснование необходимости создания в АС” общем случае проводят:
а) сбор данных об объекте автоматизации и осуществляемых видах деятельности; б) оценку качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации; в) оценку (технико-экономической, социальной и т.д.) целесообразности создания АС.
2. На этапе 1.2. “Формирование требований пользователя к АС” проводят:
а) подготовку исходных данных для формирования требований АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы); б) формулировку и оформление требований пользователя к АС.
3. На этапе 1.3. “Оформление отчёта о выполненной работе и заявки на разработку АС (технико-технического задания)” проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого заменяющего её документа с аналогичным содержанием.
4. На этапах 2.1. “Изучение объекта” и 2.2. “Проведение научно-исследовательских работ” организация-разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчёты о НИР.
5. На этапе 2.3. “Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя” в общем случае, проводят разработку альтернативных вариантов концепции создаваемой АС и планов их реализации; оценку необходимых ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и недостатков каждого варианта; определение порядка оценки качества и условий приёмки системы; оценку эффектов, получаемых от системы.
6. На этапе 2.4. “Оформление отчёта о выполненной работе” подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии описания и обоснования предлагаемого варианта концепции системы.
7. На этапе 3.1. “Разработка и утверждение технического задания на создание АС” проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС.
8. На этапе 4.1. “Разработка предварительных проектных решений по системе и её частям” определяются: функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепция информационной базы, её укрупнённая структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств.
9. На этапе 5.1. “Разработка проектных решений по системе и её частям” обеспечивает разработку общих решений по системе и её частям, функционально-алгоритмической структуре системы, по функциям персонала и организационной структуре, по структуре технических средств, по алгоритмам решения задач и применяемым языкам, по организации и ведению информационной базы, системе классификации и кодирования информации, по программному обеспечению.
10. На этапах 4.2. и 5.2. “Разработка документации на АС и её части” проводят разработку, оформление, согласование и утверждение документации в объёме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС. Виды документов - по ГОСТ 34.201.
11. На этапе 5.3. “Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку” проводят: подготовку и оформление документации на поставку изделий для комплектования АС; определение технических требований и составление ТЗ на разработку изделий, не изготовляемых серийно.
12. На этапе 5.4 “Разработка заданий на проектирование в смежных частях проекта объекта автоматизации” осуществляют разработку, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС.
13. На этапе 6.1 “Разработка рабочей документации на систему и её части” осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение. Виды документов по ГОСТ 34.201.
14. На этапе 6.2 “Разработка или адаптация программ” проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101.
15. На этапе 7.1 “Подготовка объекта автоматизации к вводу АС в действие” проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в том числе: реализацию проектных решений по организационной структуре АС; обеспечение подразделений объекта управления инструктивно-методическими материалами; внедрение классификаторов информации.
16. На этапе 7.2 “Подготовка персонала” проводят обучение персонала и проверку его способности обеспечить функционирование АС.
17. На этапе 7.3 “Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)” обеспечивают получение комплектующих изделий серийного и единичного производства, материалов и монтажных изделий. Проводят входной контроль их качества.
18. На этапе 7.4 “Строительно-монтажные работы” проводят: выполнение работ по строительству специализированных зданий (помещений) для размещения технических средств и персонала АС; сооружение кабельных каналов; выполнение работ по монтажу технических средств и линий связи; испытание смонтированных технических средств; сдачу технических средств для проведения пусконаладочных работ.
19. На этапе 7.5 “Пусконаладочные работы” проводят автономную наладку технических и программных средств, загрузку информации в базу данных и проверку системы её ведения; комплексную наладку всех средств системы.
20. На этапе 7.6 “Проведение предварительных испытаний” осуществляют:
а) испытания АС на работоспособность и соответствие техническому заданию в соответствии с программой и методикой предварительных испытаний; б) устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний; в) оформление акта о приёмке АС в опытную эксплуатацию.
21. На этапе 7.7 “Проведение опытной эксплуатации” проводят: опытную эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку (при необходимости) программного обеспечения АС; дополнительную наладку (при необходимости) технических средств АС; оформление акта о завершении опытной эксплуатации.
22. На этапе 7.8 “Проведение приёмочных испытаний” проводят:
а) испытания на соответствие техническому заданию в соответствии с программой и методикой приёмочных испытаний; б) анализ результатов испытания АС и устранение недостатков, выявленных при испытаниях; в) оформление акта о приёмке АС в постоянную эксплуатацию.
23. На этапе 8.1 “Выполнение работ в соответствии с гарантийными обязательствами” осуществляются работы по устранению недостатков, выявленных при эксплуатации АС в течении установленных гарантийных сроков, внесению необходимых изменений в документацию по АС.
24. На этапе 8.2 “Послегарантийное обслуживание” осуществляют работы по:
а) анализу функционирования системы; б) выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений; в) установлению причин этих отклонений; г) устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС; д) внесению необходимых изменений в документацию на АС.
2. Жизненный цикл информационной системы
Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. М.: Интернет-университет информационных технологий. ИНТУИТ.РУ, 2008. Лекция: Жизненный цикл программного обеспечения ИС http://www.intuit.ru/department/se/devis/2/
Совокупность стадий и этапов, которые проходит ИС в своем развитии от момента принятия решения о создании системы до момента прекращения функционирования системы, называется жизненным циклом ИС.
Содержание жизненного цикла разработки ИС сводится к выполнению следующих стадий:
1. Планирование и анализ требований (предпроектная стадия) ─ системный анализ. Проводится исследование и анализ существующей информационной системы, определяются требования к создаваемой ИС, формируются технико-экономическое обоснование (ТЭО) и техническое задание (ТЗ) на разработку ИС;
2. Проектирование (техническое и логическое проектирование). В соответствии с требованиями формируются состав автоматизируемых функций (функциональная архитектура) и состав обеспечивающих подсистем (системная архитектура), проводится оформление технического проекта ИС;
3. Реализация (рабочее и физическое проектирование, кодирование). Разработка и настройка программ, формирование и наполнение баз данных, формулировка рабочих инструкций для персонала, оформление рабочего проекта;
4. Внедрение (опытная эксплуатация). Комплексная отладка подсистем ИС, обучение персонала, поэтапное внедрение ИС в эксплуатацию по подразделениям организации, оформление акта о приемо-сдаточных испытаниях ИС;
5. Эксплуатация ИС (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании ИС, исправление недоработок и ошибок, оформление требований к модернизации ИС и ее выполнение (повторение стадий 2-5).
Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов.
Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.
Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
В настоящее время известны и используются следующие модели жизненного цикла:
Каскадная модель (рис. 2.1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
Поэтапная модель с промежуточным контролем (рис. 2.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
Спиральная модель (рис. 2.3). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).
Рис. 2.1. Каскадная модель ЖЦ ИС
Рис. 2.2. Поэтапная модель с промежуточным контролем
Рис. 2.3. Спиральная модель ЖЦ ИС
На практике наибольшее распространение получили две основные модели жизненного цикла:
каскадная модель (характерна для периода 1970-1985 гг.);
спиральная модель (характерна для периода после 1986.г.).
В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.
Можно выделить следующие положительные стороны применения каскадного подхода:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении относительно простых ИС, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем.
Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ИС зафиксированы в виде технического задания на все время ее создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям.
Спиральная модель ЖЦ была предложена для преодоления перечисленных проблем. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.
Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем и решить главную задачу - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения вводятся временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Несмотря на настойчивые рекомендации компаний - вендоров и экспертов в области проектирования и разработки ИС, многие компании продолжают использовать каскадную модель вместо какого-либо варианта итерационной модели. Основные причины, по которым каскадная модель сохраняет свою популярность, следующие:
Привычка - многие ИТ-специалисты получали образование в то время, когда изучалась только каскадная модель, поэтому она используется ими и в наши дни.
Иллюзия снижения рисков участников проекта (заказчика и исполнителя). Каскадная модель предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Разработанная документация позволяет не только определить требования к продукту следующего этапа, но и определить обязанности сторон, объем работ и сроки, при этом окончательная оценка сроков и стоимости проекта производится на начальных этапах, после завершения обследования. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и на деле увеличивает риски, уменьшая лишь ответственность участников проекта. При формальном подходе менеджер проекта реализует только те требования, которые содержатся в спецификации, опирается на документ, а не на реальные потребности бизнеса. Есть два основных типа контрактов на разработку ПО. Первый тип предполагает выполнение определенного объема работ за определенную сумму в определенные сроки (fixed price). Второй тип предполагает повременную оплату работы (time work). Выбор того или иного типа контракта зависит от степени определенности задачи. Каскадная модель с определенными этапами и их результатами лучше приспособлена для заключения контракта с оплатой по результатам работы, а именно этот тип контрактов позволяет получить полную оценку стоимости проекта до его завершения. Более вероятно заключение контракта с повременной оплатой на небольшую систему, с относительно небольшим весом в структуре затрат предприятия. Разработка и внедрение интегрированной информационной системы требует существенных финансовых затрат, поэтому используются контракты с фиксированной ценой, и, следовательно, каскадная модель разработки и внедрения. Спиральная модель чаще применяется при разработке информационной системы силами собственного отдела ИТ предприятия.
Проблемы внедрения при использовании итерационной модели. В некоторых областях спиральная модель не может применяться, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т.д.). Поэтапное итерационное внедрение информационной системы для бизнеса возможно, но сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а управление проектом требует настоящего искусства. Предвидя указанные сложности, заказчики выбирают каскадную модель, чтобы "внедрять систему один раз".
Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в виде процессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Описание каждого процесса включает в себя перечень решаемых задач, исходных данных и результатов.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.
Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.
Среди наиболее известных стандартов можно выделить следующие: