Главная Учебники - Разные Лекции (разные) - часть 13
Внутрифирменная методология ведения проектов
Версия 1.0
ЗАО «Сигма», Москва 2001 г.
Содержание
2.1 Отечественные стандарты.. 6
2.1.1 ГОСТ 34.601-90 – Стадии создания АС.. 6
2.1.2 ГОСТ 34.602-89 – Техническое задание на создание АС.. 7
2.1.3 ГОСТ 34.602-89 – Виды испытаний АС.. 14
2.1.4 ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании АС 15
2.1.5 ГОСТ 19.101-77. Виды программ и программных документов. 15
2.2 Международные стандарты.. 16
2.2.1 IEEE Std 830-1993 – спецификации требований. 16
2.2.2 IEEE Std 1074-1991 – процессы ЖЦ ПО.. 17
2.2.3 ISO 12207:1995 - процессы ЖЦ ПО.. 17
2.3 Методологии зарубежных фирм.. 23
2.3.1 Методология DATARUN.. 23
2.3.2 Методология Oracle CDM/PJM.. 27
2.3.4 Методология фирмы SoftServe. 28
2.4 Другие международные стандарты.. 29
2.4.1 Список международных стандартов. 29
2.4.2 Стандарт IEEE Std 830-1993 (Спецификация требований к ПО) 30
2.4.3 Стандарт на Глоссарий. 33
2.4.4 Стандарт ISO 9000-3:1991 (Обеспечение качества) 33
3 Внутрифирменные методологии.. 35
3.1 Опыт аналитиков фирмы.. 35
3.2 Используемые стандарты и документы.. 35
3.3 Методология разработки новой системы.. 36
3.3.6 Сопровождение и развитие. 41
3.3.8 Оценка сроков работ.. 42
3.4 Методология развития существующей системы.. 46
3.4.2 Этапы и итоговые результаты.. 47
3.5 Договорная и приемо-сдаточная документация. 48
3.5.1 Договор на создание (развитие) системы.. 48
3.5.2 Договор о проведении обследования. 49
3.5.3 Соглашение о конфиденциальности. 49
3.5.5 Описание общих требований. 53
3.5.6 Календарный план работ.. 54
3.5.8 Акт приема-сдачи работ.. 55
3.6.2 Модель предметной области. 56
3.6.3 Обзорный документ по рынку систем.. 57
3.6.6 Модель процессов системы.. 58
3.6.7 Методики сбора и обработки исходных данных. 59
3.6.8 Программная архитектура. 59
3.6.9 Требования к аппаратному обеспечению.. 59
3.6.10 Спецификация на программирование. 60
3.7 Сопроводительная документация. 60
3.7.2 Руководство пользователя. 61
3.7.3 Руководство администратора. 61
4 Рекомендации по подготовке и участию в тендерах и презентациях.. 62
4.1 Подготовка документов и буклетов. 62
4.1.1 Оформление рекламного буклета. 62
4.1.2 Подготовка научно-технического обоснования проекта. 62
4.2 Подготовка презентаций и демо-версий. 62
4.2.1 Подготовка презентации системы.. 62
4.2.2 Подготовка демонстрационной версии системы.. 62
5 Внутрифирменные соглашения.. 63
5.1 Соглашения по проектированию.. 63
5.1.1 Описание бизнес-процессов. 63
5.1.2 Описание диаграмм «сущность-связь» (ERD) 63
5.1.3 Описание системных процессов. 63
5.1.4 Описание потоков работ (Workflow) 63
5.2 Соглашения по программированию серверной части. 63
5.2.1 Генерация экземпляра БД, табличных пространств и сегментов отката 63
5.2.2 Генерация таблиц и других объектов БД (DDL-скрипты) 64
5.2.3 Программирование на SQL (DML-скрипты) 64
5.2.4 Программирование на PL/SQL. 64
5.3 Соглашения по программированию клиентской части. 64
5.3.1 Программирование на Borland C++.. 64
5.3.2 Программирование на MS VC++.. 64
5.3.3 Программирование в Oracle Developer2000. 64
5.4 Методики тестирования программных продуктов. 64
5.4.1 Стратегии тестирования. 64
5.4.2 Инструменты тестирования. 64
5.4.3 Тестирование серверной части. 64
5.4.4 Тестирование клиентской части. 64
5.5 Рекомендации по оптимизации работы системы.. 64
5.5.1 Настройка сервера БД и объектов БД.. 64
5.5.2 Оптимизация выполнения запросов. 64
5.5.3 Настройка репликации. 65
6.2 Термины по защите информации. 68
Целью данного документа является разработка внутрифирменной методологии ведения проектов и выпускаемой документации на основе приведенного обзора международных, отечественных и внутрифирменных стандартов в этой области. В данном разделе приведен ряд наиболее важных стандартов, касающихся проектирования программных систем, в обзорном виде (с большей или меньшей степенью подробности). Вкратце, ЖЦП регламентируется следующим образом [6, 18]: Стадии Этапы работ 1. Формирование требований к АС 1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания) 2. Разработка концепции АС. 2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе. 3. Техническое задание. Разработка и утверждение технического задания на создание АС. 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. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний. 8. Сопровождение АС 8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88). Приведем наиболее важные положения стандарта, а именно – раздел 2 «Состав и содержание» [полностью см. в 7]. 2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы: 1) общие сведения; 2) назначение и цели создания (развития) системы; 3) характеристика объектов автоматизации; 4) требования к системе; 5) состав и содержание работ по созданию системы; 6) порядок контроля и приемки системы; 7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; 8) требования к документированию; 9) источники разработки. В ТЗ на АС могут включаться приложения. 2.2. В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ. В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом. 2.3. В разделе «Общие сведения» указывают: 1) полное наименование системы и ее условное обозначение; 2) шифр темы или шифр (номер) договора; 3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; 4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы; 5) плановые сроки начала и окончания работы по созданию системы; 6) сведения об источниках и порядке финансирования работ; 7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы. 2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов: 1) назначение системы; 2) цели создания системы. 2.4.1. В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать. Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов. 2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы. 2.5. В разделе «Характеристики объекта автоматизации» приводят: 1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию; 2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды. Примечание: Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования. 2.6. Раздел «Требования к системе» состоит из следующих подразделов: 1) требования к системе в целом; 2) требования к функциям (задачам), выполняемым системой; 3) требования к видам обеспечения. Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида. 2.6.1. В подразделе «Требования к системе в целом» указывают: требования к структуре и функционированию системы; требования к численности и квалификации персонала системы и режиму его работы; показатели назначения; требования к надежности; требования безопасности; требования к эргономике и технической эстетике; требования к транспортабельности для подвижных АС; требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; требования к защите информации от несанкционированного доступа; требования по сохранности информации при авариях; требования к защите от влияния внешних воздействий; требования к патентной чистоте; требования по стандартизации и унификации; дополнительные требования. 2.6.1.1. В требованиях к структуре и функционированию системы приводят: 1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы; 2) требования к способам и средствам связи для информационного обмена между компонентами системы; 3) требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.); 4) требования к режимам функционирования системы; 5) требования по диагностированию системы; 6) перспективы развития, модернизации системы. 2.6.1.2. В требованиях к численности и квалификации персонала на АС приводят: требования к численности персонала (пользователей) АС; требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков; требуемый режим работы персонала АС. 2.6.1.3. В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы ее назначению. Для АСУ указывают: степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления; допустимые пределы модернизации и развития системы; вероятностно-временные характеристики, при которых сохраняется целевое назначение системы. 2.6.1.4. В требования к надежности включают: 1) состав и количественные значения показателей надежности для системы в целом или ее подсистем; 2) перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, и значения соответствующих показателей; 3) требования к надежности технических средств и программного обеспечения; 4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами. 2.6.1.5. В требования по безопасности включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т. п.), по допустимым уровням освещенности, вибрационных и шумовых нагрузок. 2.6.1.6. В требования по эргономике и технической эстетике включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала. 2.6.1.7. Для подвижных АС в требования к транспортабельности включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам. 2.6.1.8. В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают: 1) условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания; 2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.; 3) требования по количеству, квалификации обслуживающего персонала и режимам его работы; 4) требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов; 5) требования к регламенту обслуживания. 2.6.1.9. В требования к защите информации от несанкционированного доступа включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика. 2.6.1.10. В требованиях по сохранности информации приводят перечень событий: аварий, отказов технических средств (в том числе - потеря питания) и т. п., при которых должна быть обеспечена сохранность информации в системе. 2.6.1.11. В требованиях к средствам защиты от внешних воздействий приводят: 1) требования к радиоэлектронной защите средств АС; 2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения). 2.6.1.12. В требованиях по патентной чистоте указывают перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей. 2.6.1.13. В требования к стандартизации и унификации включают: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1, общесоюзных классификаторов технико-экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов. 2.6.1.14. В дополнительные требования включают: 1) требования к оснащению системы устройствами для обучения персонала (тренажерами, другими устройствами аналогичного назначения) и документацией на них; 2) требования к сервисной аппаратуре, стендам для проверки элементов системы; 3) требования к системе, связанные с особыми условиями эксплуатации; 4) специальные требования по усмотрению разработчика или заказчика системы. 2.6.2. В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят: 1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации; при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях; 2) временной регламент реализации каждой функции, задачи (или комплекса задач); 3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов; 4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности. 2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы. 2.6.3.1. Для математического обеспечения системы приводят требования к составу, области применения (ограничения) и способам, использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке. 2.6.3.2. Для информационного обеспечения системы приводят требования: 1) к составу, структуре и способам организации данных в системе; 2) к информационному обмену между компонентами системы; 3) к информационной совместимости со смежными системами; 4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии; 5) по применению систем управления базами данных; 6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных; 7) к защите данных от разрушений при авариях и сбоях в электропитании системы; 8) к контролю, хранению, обновлению и восстановлению данных; 9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4). 2.6.3.3. Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога. 2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования: 1) к независимости программных средств от используемых СВТ и операционной среды; 2) к качеству программных средств, а также к способам его обеспечения и контроля; 3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ. 2.6.3.5. Для технического обеспечения системы приводят требования: 1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе; 2) к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы. 2.6.3.6. В требованиях к метрологическому обеспечению приводят: 1) предварительный перечень измерительных каналов; 2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов; 3) требования к метрологической совместимости технических средств системы; 4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики; 5) требования к метрологическому обеспечению технических и программных средств, входящих в состав измерительных каналов системы, средств, встроенного контроля, метрологической пригодности измерительных каналов и средств измерений, используемых при наладке и испытаниях системы; 6) вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию. 2.6.3.7. Для организационного обеспечения приводят требования: 1) к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию; 2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации; 3) к защите от ошибочных действий персонала системы. 2.6.3.8. Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.). 2.7. Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ. В данном разделе также приводят: 1) перечень документов, по ГОСТ 34.201-89, предъявляемых по окончании соответствующих стадий и этапов работ; 2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт); 3) программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости); 4) перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости). 2.8. В разделе «Порядок контроля и приемки системы» указывают: 1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему); 2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации; З) статус приемочной комиссии (государственная, межведомственная, ведомственная). 2.9. В разделе «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу АС в действие. В перечень основных мероприятий включают: 1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ; 2) изменения, которые необходимо осуществить в объекте автоматизации; 3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ; 4) создание необходимых для функционирования системы подразделений и служб; 5) сроки и порядок комплектования штатов и обучения персонала. Например, для АСУ приводят: изменения применяемых методов управления; создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ. 2.10. В разделе «Требования к документированию» приводят: 1) согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации; 2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД; 3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов. 2.11. В разделе «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы. 2.12. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие: 1) расчет ожидаемой эффективности системы; 2) оценку научно-технического уровня системы. Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы. Приведем наиболее важные положения стандарта [полностью см. в 8]. 1.3. Для АС устанавливают следующие основные виды испытаний: 1) предварительные (автономные и комплексные); 2) опытная эксплуатация; 3) приемочные. Примечания: 1. Допускается дополнительно проведение других видов испытаний АС и их частей. 3. Виды испытаний и статус приемочной комиссии устанавливают в договоре и (или) ТЗ. 1.4. В зависимости от взаимосвязей испытываемых в АС объектов испытания могут быть автономные или комплексные. Автономные испытания
охватывают части АС. Их проводят по мере готовности частей АС к сдаче в опытную эксплуатацию. Комплексные испытания
проводят для групп, взаимосвязанных частей АС или для АС в целом. 1.5. Для планирования проведения всех видов испытаний разрабатывают документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. 1.6. Программа и методика испытаний должны устанавливать необходимый и достаточный объем испытаний, обеспечивающий. заданную достоверность получаемых результатов. 1.7. Программа и методика испытаний может разрабатываться на AC в целом, на части АС. В качестве приложения могут включаться тесты (контрольные примеры). 1.8. Предварительные испытания
АС проводят для определения ее работоспособности и решения вопроса о возможности приемки AC в опытную эксплуатацию. 1.9. Предварительные испытания следует выполнять после проведения разработчиком отладки и тестирования поставляемых программных и технических средств системы и представления им соответствующих документов о их готовности к испытаниям, а также после ознакомления персонала АС с эксплуатационной документацией. 1.10. Опытную эксплуатацию АС
проводят с целью определения фактических значений количественных и качественных характеристик АС и готовности персонала к работе в условиях функционирования АС, определения фактической эффективности АС,. корректировке (при необходимости) документации. 1.11. Приемочные испытания АС
проводят для определения. соответствия АС техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки АС в постоянную эксплуатацию. 1.12. Приемочным испытаниям АС должна предшествовать ее опытная эксплуатация на объекте. Приведем наиболее важные положения стандарта (полностью см. в [10]). К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ. Виды программных документов и их содержание: · Спецификация
- состав программы и документации на нее. · Ведомость держателей подлинников
- перечень предприятий, на которых хранят подлинники программных документов. · Текст программы
- запись программы с необходимыми комментариями. · Описание программы
- сведения о логической структуре и функционировании программы. · Программа и методика испытаний
- требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля. · Техническое задание
- назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний. · Пояснительная записка
- схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений. · Эксплуатационные документы
- сведения для обеспечения функционирования и эксплуатации программы. Содержат: IEEE Std 830-1993 - IEEE Recommended Practice for Software Requirements Specifications (ANSI). «Рекомендации по разработке спецификаций требований программного обеспечения
». Стандарт IEEE 830 является признанным разработчиками как не только формально обязательный, но и практически полезный при разработке спецификаций (близко к ТЗ). Кратко основные полезные моменты стандарта. 1. Определены ключевые требования «хорошей спецификации»: · Unambiguous
(недвусмысленность) - отсутствие лексических, синтаксических и семантических ошибок. · Complete
(полнота) - должны быть описаны все значимые области требований. · Verifiable
(проверяемость) - должны содержаться только те требования, которые могут быть численно измерены. · Consistent
(целостность) -не должно быть конфликтов требований. · Modifiable
(модифицируемость)- спек должен быть легким в использовании и организации ссылок между требованиями. · Traceable
(трассируемость)- спек должен позволять пошагово отслеживать (трассировать) от требований до предудущих принятых решений, от документов расширяющих спек (проектировка и т.д.) к требованиям спека. · Usable
(возможность применения)- спек должен без излишних деталей описывать весь жизненный цикл системы. 2. Определено прототипирование как метод разработки требований к системе. 3. Даны образцы структуры спеков. Заметим, отсутствует описание спека от понятия use case, широко применяемого в UML. Близкое по смыслу описание дается от понятия stimulus (отписание от проблем и задач пользователя). IEEE Std 1074-1991 - IEEE Standard for Developing Software Life Cycle Processes (ANSI). «Процессы жизненного цикла для развития программного обеспечения
». Описывает этапы жизненного цикла программного обеспечения и соответствующие входы [и выходы, т.е. отчетные документы] для каждого этапа. На данный момент самой новой версией стандарта является IEEE Std 1074.1-1995. Стандарт охватывает полный жизненный цикл ПС, в котором выделяются шесть крупных базовых процессов. Эти процессы детализируются 16 частными процессами. В последних имеется еще более мелкая детализация в совокупности на 65 процессов-работ. Содержание каждого частного процесса начинается с описания общих его функций и задач и перечня действий (работ) при последующей детализации. Для каждого процесса в стандарте представлена входная и результирующая информация о его выполнении и краткое описание сущности процесса. В стандарте внимание сосредоточено преимущественно на непосредственном создании ПС и на процессах предварительного проектирования. В приложении представлены четыре варианта адаптации максимального состава компонентов ЖЦ ПС к конкретным особенностям типовых проектов. Хотя основные процессы близки к описанным в стандарте ISO 12207, общая архитектура и детализация частных процессов и работ в данном стандарте значительно отличается. Процессы непосредственного создания ПС и его поддержки в стандарте представлены наибольшим числом частных процессов (около 70%), начинающимся с разработки требований к ПС и завершающимся приемо-сдаточными испытаниями, проводимыми заказчиком или пользователем. ISO 12207:1995 – ISO Standard for Software life cycle processes [см. 13, 18]. Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы. По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ. Очень важное замечание стандарта: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.) В отличие от Oracle CDM стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации. В стандарте рассматриваются следующие этапы: Стандарт регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах: В стандарте расшифровано свыше 220 работ и комментариев к ним. Стандарт состоит из 7 разделов и 4 приложений. Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить услуги и задачи, включенные в процессы, не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт. Конкретность пользы стандарта в том, что он содержит наборы задач, характеристик качества, критериев оценки и др., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что: Далее, при выполнении анализа требований к ПО предусмотрено 11 классов характеристик качества, которые используются позже при гарантировании качества. При этом разработчик должен установить и документировать как требования к программному обеспечению: а) функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена; б) внешние связи (интерфейсы) с единицей программного обеспечения; в) требования квалификации; г) спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала; д) спецификации защищенности, включая спецификации, связанные с компрометированием точности информации; е) человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению; ж) определение данных и требований базы данных; з) установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации); и) документация пользователя; к) работа пользователя и требования выполнения; л) требования сервиса пользователя. Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО, но определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО. Основные этапы подготовки, эксплуатации и сопровождения ПС изложены в пятом разделе: В разделе 6 представлено около 70 технологических работ, поддерживающих ЖЦ ПС: Раздел 7 посвящен процессам организации ЖЦ ПС (25 работ): В приложении А (нормативное)
изложены основы преобразования и обобщения базовой структуры этого международного стандарта для конкретного проекта. Следует подчеркнуть необходимость реализации двух важнейших вариантов адаптации положений и рекомендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное)
содержит руководство по процессам адаптации и преобразования ЖЦ ПС для конкретного проекта, а также рекомендации по возможным изменениям ряда работ из разделов 5 и 6 стандарта в зависимости от характеристик объекта. Одной из наиболее распространенных в мире электронных методологий является методология DATARUN. В соответствии с методологией DATARUN ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен завершать план работ на следующую стадию [13]. Стадия формирования требований и планирования
включает в себя действия по определению начальных оценок объема и стоимости проекта. Должны быть сформулированы требования и экономическое обоснование для разработки ИС, функциональные модели (модели бизнес-процессов организации) и исходная концептуальная модель данных, которые дают основу для оценки технической реализуемости проекта. Основными результатами этой стадии должны быть модели деятельности организации (исходные модели процессов и данных организации), требования к системе, включая требования по сопряжению с существующими ИС, исходный бизнес-план. Стадия концептуального проектирования
начинается с детального анализа первичных данных и уточнения концептуальной модели данных, после чего проектируется архитектура системы. Архитектура включает в себя разделение концептуальной модели на обозримые подмодели. Оценивается возможность использования существующих ИС и выбирается соответствующий метод их преобразования. После построения проекта уточняется исходный бизнес-план. Выходными компонентами этой стадии являются концептуальная модель данных, модель архитектуры системы и уточненный бизнес-план. На стадии спецификации приложений
продолжается процесс создания и детализации проекта. Концептуальная модель данных преобразуется в реляционную модель данных. Определяется структура приложения, необходимые интерфейсы приложения в виде экранов, отчетов и пакетных процессов вместе с логикой их вызова. Модель данных уточняется бизнес-правилами и методами для каждой таблицы. В конце этой стадии принимается окончательное решение о способе реализации приложений. По результатам стадии должен быть построен проект ИС, включающий модели архитектуры ИС, данных, функций, интерфейсов (с внешними системами и с пользователями), требований к разрабатываемым приложениям (модели данных, интерфейсов и функций), требований к доработкам существующих ИС, требований к интеграции приложений, а также сформирован окончательный план создания ИС. На стадии разработки, интеграции и тестирования
должна быть создана тестовая база данных, частные и комплексные тесты. Проводится разработка, прототипирование и тестирование баз данных и приложений в соответствии с проектом. Отлаживаются интерфейсы с существующими системами. Описывается конфигурация текущей версии ПО. На основе результатов тестирования проводится оптимизация базы данных и приложений. Приложения интегрируются в систему, проводится тестирование приложений в составе системы и испытания системы. Основными результатами стадии являются готовые приложения, проверенные в составе системы на комплексных тестах, текущее описание конфигурации ПО, скорректированная по результатам испытаний версия системы и эксплуатационная документация на систему. Стадия внедрения
включает в себя действия по установке и внедрению баз данных и приложений. Основными результатами стадии должны быть готовая к эксплуатации и перенесенная на программно-аппаратную платформу заказчика версия системы, документация сопровождения и акт приемочных испытаний по результатам опытной эксплуатации. Стадии сопровождения и развития
включают процессы и операции, связанные с регистрацией, диагностикой и локализацией ошибок, внесением изменений и тестированием, проведением доработок, тиражированием и распространением новых версий ПО в места его эксплуатации, переносом приложений на новую платформу и масштабированием системы. Стадия развития фактически является повторной итерацией стадии разработки. Методология DATARUN опирается на две модели или на два представления: Методология DATARUN базируется на системном подходе к описанию деятельности организации. Построение моделей начинается с описания процессов, из которых затем извлекаются первичные данные (стабильное подмножество данных, которые организация должна использовать для своей деятельности). Первичные данные описывают продукты или услуги организации, выполняемые операции (транзакции) и потребляемые ресурсы. К первичным относятся данные, которые описывают внешние и внутренние сущности, такие как служащие, клиенты или агентства, а также данные, полученные в результате принятия решений, как например, графики работ, цены на продукты. Основной принцип DATARUN заключается в том, что первичные данные, если они должным образом организованы в модель данных, становятся основой для проектирования архитектуры ИС. Архитектура ИС будет более стабильной, если она основана на первичных данных, тесно связанных с основными деловыми операциями, определяющими природу бизнеса, а не на традиционной функциональной модели. Любая ИС представляет собой набор модулей, исполняемых процессорами и взаимодействующих с базами данных. Базы данных и процессоры могут располагаться централизованно или быть распределенными. События в системе могут инициироваться внешними сущностями, такими как клиенты у банкоматов или временные события (конец месяца или квартала). Все транзакции осуществляются через объекты или модули интерфейса , которые взаимодействуют с одной или более базами данных. Подход DATARUN преследует две цели: Объекты, формируемые на основании модели данных, являются объектами базы данных, обычно размещаемыми на серверах в среде клиент/сервер. Объекты интерфейса, определенные в архитектуре компьютерной системы, обычно размещаются на клиентской части. Модель данных, являющаяся основой для спецификации совместно используемых объектов базы данных и различных объектов интерфейса, обеспечивает сопровождаемость ИС. Для создания моделей, создаваемых в процессе разработки ИС используется CASE-средство Silverrun. Silverrun обеспечивает автоматизацию проведения проектных работ в соответствии с методологией DATARUN. Предоставляемая этими средствами среда проектирования дает возможность руководителю проекта контролировать проведение работ, отслеживать выполнение работ, вовремя замечать отклонения от графика. Каждый участник проекта, подключившись к этой среде, может выяснить содержание и сроки выполнения порученной ему работы, детально изучить технику ее выполнения в гипертексте по технологиям, и вызвать инструмент (модуль Silverrun) для реального выполнения работы. Информационная система создается последовательным построением ряда моделей, начиная с модели бизнес-процессов и заканчивая моделью программы, автоматизирующей эти процессы. Модели, создаваемые с помощью подхода DATARUN: BPM
Создаваемая ИС должна основываться на функциях, выполняемых организацией. Поэтому первая создаваемая модель - это модель бизнес-процессов
, построение которой осуществляется в модуле Silverrun BPM. Для этой модели используется специальная нотация BPM. В процессе анализа и спецификации бизнес-функций выявляются основные информационные объекты, которые документируются как структуры данных, связанные с потоками и хранилищами модели. Источниками для создания структур являются используемые в организации документы, должностные инструкции, описания производственных операций. Эти данные вводятся в том виде, как они существуют в деятельности организации. Нормализация и удаление избыточности производится позже при построении концептуальной модели данных в модуле Silverrun ERX. После создания модели бизнес-процессов информация сохраняется в репозитории проекта. PDS
В процессе обследования работы организации выявляются и документируются структуры первичных данных
. Эти структуры заносятся в репозиторий модуля BPM при описании циркулирующих в организации документов, сообщений, данных. В модели бизнес-процессов первичные структуры данных связаны с потоками и хранилищами информации. CDM
На основе структур первичных данных в модуле Silverrun ERX создается концептуальная модель данных
(ER-модель). От структур первичных данных концептуальная модель отличается удалением избыточности, стандартизацией наименований понятий и нормализацией. Эти операции в модуле ERX выполняются при помощи встроенной экспертной системы. Цель концептуальной модели данных - описать используемую информацию без деталей возможной реализации в базе данных, но в хорошо структурированном нормализованном виде. ISA
На основе модели бизнес-процессов и концептуальной модели данных проектируется архитектура
ИС. Определяются входящие в систему приложения, для каждого приложения специфицируются используемые данные и реализуемые функции. Архитектура ИС создается в модуле Silverrun BPM с использованием специальной нотации ISA. Основное содержание этой модели - структурные компоненты системы и навигация между ними. Концептуальная модель данных разбивается на части, соответствующие входящим в состав системы приложениям. ADM
Перед разработкой приложений должна быть спроектирована структура корпоративной базы данных. DATARUN предполагает использование базы данных, основанной на реляционной модели. Концептуальная модель данных после нормализации переносится в модуль реляционного моделирования Silverrun RDM с помощью специального моста ERX-RDM. Преобразование модели из формата ERX в формат RDM происходит автоматически без вмешательства пользователя. После преобразования форматов получается модель реляционной базы данных
. Эта модель детализируется в модуле Silverrun RDM определением физической реализации (типов данных СУБД, ключей, индексов, триггеров, ограничений ссылочной целостности). Правила обработки данных можно задавать как непосредственно на языке программирования СУБД, так и в декларативной форме, не привязанной к реализации. Мосты Silverrun к реляционным СУБД переводят эти декларативные правила на язык требуемой системы, что снижает трудоемкость программирования процедур сервера базы данных, а также позволяет из одной спецификации генерировать приложения для разных СУБД. SPM
С помощью модели системных процессов
детально документируется поведение каждого приложения. В модуле BPM создается модель системных процессов, определяющая, каким образом реализуются бизнес-процессы. Эта модель создается отдельно для каждого приложения и тесно связана с моделью данных приложения. Приложение состоит из интерфейсных объектов (экранных форм, отчетов, процедур обработки данных). Каждый интерфейс системы (экранная форма, отчет, процедура обработки данных) имеет дело с подмножеством базы данных
. В модели данных приложения (созданной в модуле RDM) создается подсхема базы данных для каждого интерфейса этого приложения. Уточняются также правила обработки данных, специфичные для каждого интерфейса. Интерфейс работает с данными в ненормализованном виде, поэтому спецификация данных, как ее видит интерфейс, оформляется как отдельная подсхема модели данных интерфейса
. IPM
Модель представления интерфейса
- это описание внешнего вида интерфейса, как его видит конечный пользователь системы. Это может быть как документ, показывающий внешний вид экрана или структуру отчета, так и сам экран (отчет), созданный с помощью одного из средств визуальной разработки приложений - так называемых языков четвертого поколения (4GL - Fourth Generation Languages). Так как большинство языков 4GL позволяют быстро создавать работающие прототипы приложений, пользователь имеет возможность увидеть работающий прототип системы на ранних стадиях проектирования. ISM
После создания подсхем реляционной модели для приложений проектируется детальная структура каждого приложения в виде схемы навигации экранов, отчетов, процедур пакетной обработки. На данном шаге эта структура детализируется до указания конкретных столбцов и таблиц базы данных, правил их обработки, вида экранных форм и отчетов. Полученная модель детально документирует приложение и непосредственно используется для программирования специфицированных интерфейсов
. Далее, с помощью средств разработки приложений происходит физическое создание системы: приложения программируются и интегрируются в информационную систему. Oracle CDM/PJM – метод сквозного создания и внедрения информационных систем с использованием Oracle Designer. Полная методология CDM изложена в отдельном документе и находится в архиве фирмы. В этом разделе приводятся наиболее важные ее моменты [см. также 18]. Oracle Custom Development Method (CDM
) — составная часть глобальной методологии разработки ИС — Oracle Method. Кроме CDM в Oracle Method входят метод разработки хранилищ данных (DWM
), метод внедрения готовых приложений (Aim
), метод управления проектом (PJM
) и ряд других. Поскольку решаемые в CDM задачи тесно связаны и переплетены с задачами руководителя проекта, то CDM наиболее сильно связан с методикой Oracle PJM по организации управления разработкой проекта. Цель PJM (Project Metod) – определить структуру, в рамках которой проекты в области информационных технологий можно было бы согласованно планировать, оценивать, контролировать и завершать. Этапы классического подхода в CDM: Процессы в CDM (в скобках – условные коды): По методологии Rational
unified
process (
RUP)
фирмы Rational Rose жизненный цикл системы состоит из следующих этапов: Фирма SoftServe Inc. (Virginia, U.S.) осуществляет консалтинговые услуги на всех этапах жизненного цикла разработки ПО, который, по ее представлению, состоит в следующем: В целом, при проектировании систем используются следующие международные стандарты IEEE и ISO [1,2]: Стандарт IEEE Std 830-1993 описывается как «IEEE Recommended Practice for Software Requirements Specifications (ANSI)», т.е. Рекомендации по разработке спецификаций требований программного обеспечения (далее - СТПО). Фактически, этот стандарт аналогичен Техническому заданию, потому что определяет форму описания и состав требований главных разделов ТЗ (1-3) в соответствии с отечественным стандартом ГОСТ 34.602-89 [2.1.2]. Приведем необходимые части СТПО в соответствии с этим стандартом: Это - часто самая большая и наиболее важная часть СТПО, поэтому необходимо применять следующие принципы: Глоссарий используется лишь как приложение к Спецификации требований к ПО (СТПО). Определения терминов – четкие и краткие, без «энциклопедических» обзоров. Назначение Глоссария – однозначность трактовок терминов, используемых в СТПО. Технология обеспечения качества в ЖЦ ПС представлена в стандарте ISO 9000-3:1991. Руководящие указания предназначены для унификации описания методов разработки и поставки ПС, а также способов контроля их качества, отвечающих требованиям заказчика. Этой унификации предлагается добиваться, предотвращая отклонения от стандарта на всех этапах ЖЦ - от начала разработки до технического обслуживания и ремонта. Предполагается, что в контракте будут особо оговорены важнейшие компоненты технологии проектирования и требования к техническим характеристикам ПС, иначе это делается в процессе разработки. Поставщик должен документально оформить цели, технологию и свои обязательства по обеспечению качества ПС. Необходимо определить ответственность, полномочия и взаимодействие всего руководящего, исполняющего работы и контролирующего персонала, который влияет на качество, надежность и безопасность применения создаваемого комплекса программ. Обеспечение и проверка качества проводится персоналом поставщика, независимым от специалистов, непосредственно ответственных за выполнение работ и создание изделий. Покупатель-заказчик назначает своего представителя, ответственного за сотрудничество с поставщиком в процессе создания ПС по данному контракту. В стандарте определена структура системы обеспечения качества и ее функции в жизненном цикле ПС. Эта деятельность предусматривает: Кроме того, рекомендуется по согласованию с заказчиком регламентировать правила и технологию копирования, поставки, инсталляции, технического обслуживания и ремонта ПС. Независимо от этапов работ в технологии и системе качества должна быть определена деятельность по: В целом, рекомендуется следующая последовательность этапов: При разработке внутрифирменной методологии ведения проектов были использованы, главным образом, опыт аналитиков фирмы и следующие стандарты: Кроме того, были учтены некоторые положения других, приведенных в данном документе (раздел 2), стандартов, а также использована полезная информация из следующих публикаций: Под разработкой новой системы понимается весь процесс создания информационной системы от системного обследования до внедрения. Этот процесс включает следующие этапы (по международному стандарту ISO 12207:1995): В результате сильного изменения бизнес-процессов предприятия, законодательства, появления новых информационных технологий и т.д. может потребоваться произвести развитие системы, т.е. сделать итерацию жизненного цикла системы с одного из ее этапов – реализации, проектирования или даже анализа. Поэтому фазу развития системы мы не будем выделять в отдельный этап ее жизненного цикла, однако описание особенностей этой фазы также включим в данный документ. Стратегия - этап определения назначения проекта, предварительного анализа предмета, планирования и оценки объема работ. На этом этапе Заказчик предоставляет Исполнителю краткие сведения о целях и объектах информатизации, на основе чего Исполнитель предоставляет Заказчику информацию об ориентировочных сроках и расходах по проекту. Более реальная оценка объема работ возможна лишь после детального обследования предметной области в фазе Анализа (в границах, определенных на этапе Стратегии). Поэтому на этом этапе составляется документ с общими требованиями к системе и определением границ предметной области, в рамках которой будет эксплуатироваться эта система. Затем определяется объем работ на этапе Анализа и заключается соглашение (договор) на проведение этих работ. Объемы по другим этапам также могут включаться, но оговаривается, что они носят ориентировочный характер. Только после проведения анализа определяется окончательный вариант Технического задания (ТЗ), календарный план (график) и калькуляция всех оставшихся работ, и составляется Договор по проекту. Возможен (и часто практикуется) также другой вариант, когда сроки и объем средств у Заказчика ограничены. В этом случае календарный план и калькуляция работ в окончательном виде определяются на этапе Стратегии, но состав и объем работ определяются на этапе Анализа, по окончании которого в Техническом задании фиксируются необходимые требования к системе, которые можно реализовать за эти сроки и сумму. Во время и по окончании этапа Стратегии разрабатываются следующие документы: Этап носит непродолжительный характер (около 2 недель) и минимальное количество участвующих лиц (кроме руководителей и главных бухгалтеров – по 1-3 экспертов с обеих сторон). Назначение этапа - обследование предметной области, обозначение границ и направлений проектирования системы, детальное планирование и уточнение объема будущих работ. При обследовании предметной области используются самые различные источники информации: научно-техническая документация, отраслевые стандарты, публикации в прессе и Интернете, но, главное, - корпоративные руководящие документы и информация экспертов, результаты иньтервьюирования которых являются отражением фактических (или желаемых) деловых операций (бизнес-процессов) на предприятии. При этом, в первую очередь, проводится анализ следующих аспектов (в скобках – условные коды подэтапов): Результаты интервьюирования экспертов оформляются в виде пакета протоколов, а результаты названных работ по анализу предметной области - в виде отдельных документов или разделов общего документа «Модель предметной области
». Далее (или одновременно) исследуется целесообразность использования какой-либо существующей информационной системы или разработки новой. При этом осуществляются и документируются (в виде разделов «Концепции
» или отдельных документов) следующие подэтапы: Затем уточняются системные требования, и на их основе определяются стратегические направления будущих работ. При этом проводятся и документируются (в виде разделов «Концепции
» или отдельных документов) следующие подэтапы: Таким образом, на этапе Анализа разрабатываются следующие выходные документы: Трудоемкость работ на этапе Анализа оценивается на основании указанных в п. 3.3.2.1 подэтапов, а также в соответствии с количеством экспертов, которых предполагается интервьюировать. Работы на этом этапе рекомендуется выполнять группе аналитиков – специалистов по исследуемой предметной области, по информационным технологиям, которые предполагается использовать в проекте, по методологиям обследования и проектирования (3-6 человек, при ограниченных сроках - больше). На этапе Проектирования создаются документы, на основании которых программисты будут разрабатывать компоненты системы, а затем внедрять готовую систему. На этом этапе разрабатываются следующие модели и методики: Назначением этапа является создание БД, кодирование, тестирование и документирование разработанной системы. 1. Разработка модулей системы в соответствии с требованиями ТЗ и проекта. 2. Разработка тестов. 3. Подготовка тестовой БД (заполнение системы минимально необходимым для стендовых испытаний набором данных). 4. Стендовое тестирование и доработка. 5. Опытная эксплуатация («пилотное» внедрение системы на реальном предприятии). Выходные документы: Этот этап включает в себя работы по инсталляции и настройке системы, обучению пользователей, оказанию консультаций на начальной фазе эксплуатации системы (в первую очередь, при вводе данных) и пр. 1. Сбор данных. 2. Создание справочников, классификаторов, кодификаторов. 3. Наполнение БД системы производственными и др. (например, географическими) данными. 4. Конфигурирование системы для решения задач предметной области (встраивание в бизнес-процессы). Выходные документы: Назначение этапа состоит в сопровождении промышленной эксплуатации системы (абонентском обслуживании), главным образом в устранении проблем при эксплуатации системы и ее развитие включает в себя следующие основные работы: Выходные документы: Назначение этапа состоит в развитии программного продукта в объемах, превосходящих задачи абонентского обслуживания системы. Фактически, этот этап является итерацией ЖЦ системы с какого-либо этапа (в основном – с этапа ее проектирования, а иногда даже обследования), в то время как доработка системы в рамках абонентского обслуживания – в основном, итерация с этапа ее реализации. В соответствии с указанной методологией, опытом нашей и ряда других фирм можно оценить долевую часть каждого этапа работ и их примерную продолжительность (для среднего проекта). По поводу распределения времени в проекте Брукс в своей книге «Мифический человеко-месяц» приводит следующие эмпирические данные для этапов разработки информационных систем: Таким образом, этап Реализации занимает 2/3 времени ЖЦ ПО, причем работы по тестированию – 50% времени ЖЦ ПО. Далее, условно будем считать, что: Для среднего проекта
оценка трудоемкости выглядит следующим образом: Итого, на анализ предметной области, проектирование и реализацию среднего проекта необходимо не менее 15 месяцев. Приведем более детальную схему работ по указанным этапам. Наглядное представления по этапам жизненного цикла нового ПО (на примере средних проектов), их результатам (отчетным документам), трудоемкости и продолжительности дает следующая таблица: №
Этапы и подэтапы
Документы (в скобках – трудоемкость разработки, ЧМ)
Трудо-ёмкость (ЧМ)
Продол-житель-ность (мес)
Персонал
1. Стратегия · Описание общих требований (0,5) · Календарный план НИР · Смета затрат по НИР · Соглашение о конфиденциальности · Договор о проведении обследования 1 0,5 3 (рук-тель, гл.бухгалтер, аналитик) 2. Анализ · Протоколы интервью (2-3) · Модель предметной области (3) · Концепция (3) · Техническое задание (1,5-2) · Календарный план (0,5) · Калькуляция работ (0,5) · Договор (0,5) 12 От 4 3 аналитика (и более) 3 Проекти-рование · Информационная модель (3) · Методика наполнения (1-2) · Функциональная модель (2) · Модель интерфейса (2) · Модель процессов (2) · Спецификация (2-3) · Методика встраивания в БП (1) 15 От 4 4 аналитика (и более) 4. Реализация · Описание системы (0,5) · Руководство пользователя (1) · Руководство администратора (1) · Отчеты о стендовых испытаниях и результатах пилотного внедрения (1) 20 От 7 4 (аналитик, прогр-сты) Итого по этапам 1-4 48 От 15 От 4 5. Внедрение · Отчет о наполнении системы данными. · Отчет о соответствии работы системы требованиям ТЗ. Около 1 мес. на 1 объект 2 (прогр-сты клиента и сервера или прогр-ст и оператор) Конечной целью развития (конфигурирования, адаптации) системы является создание геоинформационной системы, информационное и функциональное наполнение которой может формироваться и конфигурироваться самими ее эксплуатантами с минимальным участием в этом процессе разработчика. Для этого необходимо выполнить следующие работы: В итоге получим следующий перечень этапов и назовем необходимые выходные документы по каждому из них: 1. Обследование предметной области. Итоговые результаты: диаграммы бизнес-процессов; обзор предметной области; словарь терминов предметной области. Последний составляется как мини-энциклопедия, а не только с краткой интерпретацией термина, как в Глоссарии к Спецификации на программирование. 2. Проектирование: определение конфигурации системы и ее реализуемости имеющимися средствами архитектуры. Итоговые результаты: рабочая документация для программистов (см. п. 3.5). 3. Модификация «Комплекса/2000» и разработка новых подсистем в соответствии с требованиями ТЗ и проекта. Итоговые результаты: модифицированные серверная и клиентская части системы, новые подсистемы, новая техническая документация на них. 4. Создание иерархии прототипов (понятийной модели) объектов и отношений между ними. Итоговые результаты: ввод в проектируемую систему понятийной модели для предметной области заказчика. 5. Сбор и наполнение БД системы актуальными производственными данными. Результат: БД системы, заполненная минимально необходимым для стендовых испытаний набором реальных производственных данных по какому-либо подразделению заказчика. 6. Сбор и наполнение БД системы географическими данными. Итоговые результаты: БД системы, заполненная минимально необходимым для стендовых испытаний набором реальных общегеографических и тематических данных по зоне деятельности выбранного подразделения заказчика. 7. Конфигурирование системы для решения задач предметной области (встраивание в бизнес-процессы). Итоговые результаты: разработанные прикладные методы поддержки бизнес-процессов, определенные для стендовых испытаний по выбранному подразделению заказчика. 8. Тестирование, опытная эксплуатация и доработка. Итоговые результаты: отчет о тестировании и выявленных несоответствиях ТЗ, отчет по ликвидации ошибок и несоответствий ТЗ; предварительная версия системы. 9. Промышленная эксплуатация. Итоговые результаты: отчеты о результатах пилотных внедрений, отчет о направлениях дальнейшего развития системы; окончательная версия системы, прошедшая успешные испытания и отладку на одном или ряде пилотных внедрений. К данной группе документов относятся документы, которые оформляют договорные отношения, условия результаты выполнения договоров. Данный договор состоит из следующих разделов: «Договор о проведении обследования
». Документ является договором на выполнение работ по этапу Анализа предметной области (его можно также назвать «Соглашением»). В договоре можно определить состав и содержание результирующих документов. Можно также оговорить способ описания бизнес-диаграмм (стандарт IDEF0, средства Oracle или Rational Rose, ARIS и пр.). «Соглашение о конфиденциальности
». Данный документ, призван защитить Заказчика от возможной утечки конфиденциальной информации, полученной при обследовании предприятия. Составляется по инициативе Заказчика. Может оформляться как приложение к «Договору о проведении обследования
». Документ «Техническое задание
» содержит определение цели и границ проекта, функционального наполнения системы и требуемых ресурсов, этапов работ и выходных документов. За основу формы и содержания ТЗ взят отечественный стандарт ГОСТ 34.602-89 [см. 2.1.2]. Учтены также рекомендации международного стандарта IEEE Std 830-1993 (Спецификация требований к ПО), которые касаются второй, третьей и, частично, первой части ТЗ [см. 2.4.2]. ТЗ состоит из разделов: 1. Общие сведения. 2. Назначение и цели создания (развития) системы. 3. Требования к системе. 3.1. Требования к системе в целом. 3.2. Требования к функциям системы. 3.3. Требования к информационному обеспечению. 3.4. Требования к программному обеспечению. 3.5. Требования к техническому обеспечению. 3.6. Требования к организационному обеспечению. 3.7. Требования к методическому обеспечению. 4. Состав и содержание работ по созданию (развитию) системы. 5. Порядок контроля и приемки системы. 6. Описание состава работ и исполнителей по подготовке системы к внедрению. 7. Требования к документированию. 8. Источники разработки. 9. Приложения. Далее опишем эти разделы. Здесь указывается, главным образом, следующее: В разделе 2 определяются: Раздел 3 может содержать следующие пункты (состав пунктов определяется Исполнителем и Заказчиком): Раздел 4 содержит: Этот раздел может быть объединен с разделом 6 «Описание состава работ и исполнителей по подготовке системы к внедрению» в общий раздел «Состав и содержание работ». Раздел 5 содержит: Раздел 6 содержит: Раздел 7 содержит: Раздел 8 - необязательная часть ТЗ. Здесь перечисляются документы и информационные материалы, на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы, например: Приложения - необязательная часть ТЗ. В приложениях могут, например, содержаться: Документ «Описание общих требований
», по существу, является предварительной версией «Технического задания
». Основной целью документа является формирование границ проекта, т.е. выявление и описание общих требований. Форма документа может совпадать с формой «Технического задания
» [3.5.1], но со свободным составом разделов и подразделов. Далее опишем состав разделов документа (как один из вариантов). Раздел состоит, прежде всего, из следующих пунктов: В разделе определяется: Раздел может содержать следующие пункты (состав и содержание пунктов определяется Исполнителем и Заказчиком): Раздел может содержать следующие пункты (содержание пунктов определяется Исполнителем и Заказчиком): В разделе приводится перечень функций, которые должна обеспечить система с возможными дополнениями по этим пунктам (как это обеспечить, что нужно учитывать, какие-либо примечания и т.д.). В этом разделе приводится перечень и содержание этапов (решаемые задачи) по разработке или развитию системы. На основании этих сведений в дальнейшем составляется «Календарный план работ
». Раздел содержит: «Календарный план работ
» (или просто «Календарный план
» или «График работ
») предназначен для управления проектом на всех этапах и представляет собой перечень этапов и подэтапов с указанием по каждому из них следующих данных: «Календарный план
» составляется на основании сведений раздела 6 «Состав и содержание работ» [3.5.5.6] документа «Описание общих требований» или разделов 4 «Состав и содержание работ по созданию (развитию) системы» [3.5.4.4] и 6 «Описание состава работ и исполнителей по подготовке системы к внедрению» [3.5.4.6] «Технического задания». «Смета расходов
» (или просто «Смета
») предназначена для обоснования стоимости проекта и представляет собой перечень всех затрат по проекту. Также можно использовать название «Калькуляция работ
». Перечень затрат в смете удобно группировать по указанным в «Календарном плане
» этапам и подэтапам, а также по группам затрат. Также перечень затрат в смете может группироваться по каждой очереди работ по проекту. При этом под очередью понимается группа этапов или подэтапов, по окончании которых происходит выплата Заказчиком оговоренных сумм денег. Данный документ констатирует факт выполнения (частичного выполнения или невыполнения) Исполнителем своих обязательств по конкретному этапу и является основанием для выплаты Заказчиком установленной суммы денег за проведенные Исполнителем работы. Акт обязательно визируется обеими сторонами. В случае частичного выполнения или невыполнения Исполнителем своих обязательств, к Акту прилагается «Протокол испытаний
» [3.5.9] с выводами о неполном соответствии выполненных работ требованиям Заказчика. В документе фиксируется содержание испытаний, обнаруженные ошибки выполнения программы, несоответствия функциональности программы требованиям ТЗ и другие проблемы ее эксплуатации. Протокол служит основанием для отказа в выплате Заказчиком оговоренной суммы денег по закрываемому этапу или обоснованием ее частичной выплаты. Рабочей документацией будем считать внутрифирменную документацию, которую готовят сотрудники фирмы. В ее состав входит: Рабочая документация, в принципе, не является формой отчетности перед Заказчиком, но, тем не менее, он может потребовать ее предоставления, например, модель данных и отчеты по испытанию и внедрению (это оговаривается в Договоре). Документ «Протоколы интервью
» содержит протоколы интервьюирования экспертов по различным аспектам предметной области (главным образом, сотрудников предприятия-заказчика), выполненные по установленной форме, а также копии некоторых из предоставленных этими экспертами документов (например, телефонный справочник сотрудников, примеры технологических схем, легенды и пр.). Протоколы могут также оформляться как приложение к документу «Модель предметной области
». Рекомендуется следующая форма протокола: ИНТЕРВЬЮ Имя: Смирнов Валентин Петрович
Организация: АК «Трансгаз» Подразделение: Управление информационных технологий Должность: Начальник управления Дополнительно: Эксперт имеет 15-летний опыт работы в данной сфере
Интервьюер: Георгиев И.К. Дата/Время: 24.07.2001 Тема: Организационная структура компании
Тип интервью: Обзорное
|