ВКР (1197993), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

В соответствии с методическими указаниями к лабораторному практикуму по предмету «Проектирование информационных систем» по направлению 09.03.03.62 – Прикладная информатика Донецкого национального университета, разработка ИС должна включать в себя следующие этапы:

– изучение предметной области и постановка задачи: описание предметной области, информационных потоков, процессов обработки информации и управления, требующих автоматизации;

– обзор и критический анализ существующих программных продуктов, выполняющих аналогичные функции, их достоинств и недостатков;

– обоснование необходимости разработки новой информационной системы согласно поставленной в работе задаче исследования;

– эмпирическая постановка и математическая формализация задач, требующих решения с помощью искомой информационной системы: формализация математических моделей, описание возможных методов решения поставленных задач и алгоритмов, реализующий выбранный метод решения. При выборе метода решения определяется целесообразность использования объектно-ориентированного или структурного подхода, способов и форм представления данных, промежуточных и окончательных результатов, использования конкретных инструментальных средств и платформ;

– проектирование информационной системы: архитектура и информационная структура системы, описание функциональных возможностей и логики соответствующих подпрограмм и интерфейсов; разработка алгоритмов обработки данных;

– реализация информационной системы: назначение режимов работы, описание категорий пользователей, разграничения прав доступа, описание последовательности пользовательских интерфейсов, реализующих каждую функцию информационной системы, описание входных и выходных данных, методов их защиты, технические характеристики системы (тип и минимально необходимые аппаратные ресурсы вычислительной системы, требуемое программное обеспечение и т. п.);

– отладка и тестирование информационной системы: проверка корректности работы системы во всех предусмотренных режимах и для всех типов пользователей, проверка адекватного реагирования системы на некорректный ввод данных пользователем, описание инструкции пользователя системы, анализ достоверности результатов проводимых расчетов;

– анализ разработанной информационной системы: области применения, эффективность решения поставленных в работе задач, достоинства и недостатки по сравнению с рассмотренными в работе аналогами, описание возникших в процессе разработки проблем и их причин, направления дальнейшего развития информационной системы.

Как можно увидеть, данные рекомендации хоть и описывают порядок создания ИС и определенные шаги, необходимые для их реализации, являются недостаточно подробными, описаны расплывчато и сжато.

Данные методологические указания давались для разработки ИС в рамках дипломной работы, для которой являются достаточными. Однако, для проектирования ИС, нацеленной на активное применение на предприятии или просто большим количеством пользователей, их будет недостаточно. Существует вероятность разночтения.

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

Государственный стандарт РФ ГОСТ Р ИСО/МЭК 12207 Информационная технология. Процессы жизненного цикла программных средств.

Настоящий стандарт определяет процессы, работы и задачи, которые используются: при приобретении системы, содержащей программные средства, или отдельно поставляемого программного продукта; при оказании программной услуги, а также при поставке, разработке, эксплуатации и сопровождении программных продуктов. Понятие программных средств также охватывает программный компонент программно-аппаратных средств.

В соответствии с данным стандартом задача должна быть выражена в виде требования, самообъявления, рекомендации или допустимого действия. С этой целью в ГОСТ Р ИСО/МЭК 12207 тщательно отобраны некоторые вспомогательные глаголы для выделения различий между видами задач:

– глагол «должна (shall)» использован для выражения соглашения между двумя или более сторонами;

– глагол «будет (will)» выражает объявление цели или намерения одной из сторон;

– глагол «следует (should)» выражает рекомендацию из имеющихся возможных вариантов;

– глагол «может (may)» указывает образ действий, допустимый в рамках ГОСТ Р ИСО/МЭК 12207.

ГОСТ Р ИСО/МЭК 12207 описывает набор процессов, используемых для больших или сложных программных проектов. Однако ГОСТ Р ИСО/МЭК 12207 может быть применен к программному проекту любого типа, меньшего размера и сложности. Этот стандарт также может быть использован для программных средств, являющихся самостоятельными объектами или частями общей системы.

Процессы, работы и задачи в ГОСТ Р ИСО/МЭК 12207 описаны в наиболее общей естественной позиционной последовательности. Эта последовательность не предопределяет последовательность реализации модели жизненного цикла. Описанная последовательность предназначена для того, чтобы в проекте создания программного средства выбрать, упорядочить, применить и повторить присущие проекту или подходящие для него процессы, виды деятельности и задачи.

В рамках одного проекта ГОСТ Р ИСО/МЭК 12207 может быть использован многократно и выборочно.

Вышеуказанный стандарт определяет, что процесс разработки включает работы по анализу требований, проектированию, программированию, сборке, тестированию, вводу в действие и приемке программных продуктов. В данный процесс могут быть включены работы, связанные с разработкой системы, если это оговорено в договоре.

Данный процесс состоит из следующих работ:

– подготовка процесса:

1. разработчик должен определить или выбрать модель жизненного цикла программных средств, соответствующую области реализации, величине и сложности проекта;

2. разработчик должен выбрать, адаптировать и использовать те стандарты, методы, инструментарий, языки программирования (если они не установлены в договоре), которые документально оформлены и приняты в организации разработчика;

3. разработчик должен разработать планы проведения работ в процессе разработки. Планы должны охватывать конкретные стандарты, методы, инструментарий, действия и обязанности, связанные с разработкой и квалификацией всех требований, включая безопасность и защиту;

4. непоставляемые изделия могут применяться при разработке или сопровождении программного продукта. Однако должно быть обеспечено, чтобы эксплуатация и сопровождение поставленного программного продукта (после его поставки заказчику) не зависели от данных изделий, иначе они должны рассматриваться как комплектующие (поставляемые) изделия;

– анализ требований к системе:

1. разработчик должен выполнить анализ области применения разрабатываемой системы с точки зрения определения требований к ней. Технические требования к системе должны охватывать: функции и возможности системы; коммерческие и организационные требования; требования пользователя; требования безопасности и защиты; эргономические требования; требования к интерфейсам; эксплуатационные требования; требования к сопровождению; проектные ограничения и квалификационные требования. Требования к системе должны быть документально оформлены;

2. требования к системе должны быть оценены с учетом следующих критериев: учет потребностей заказчика; соответствие потребностям заказчика; тестируемость; выполнимость проектирования системной архитектуры; возможность эксплуатации и сопровождения;

– проектирование системной архитектуры:

1. должна быть определена общая архитектура системы. В архитектуре должны быть указаны объекты технических и программных средств и ручных операций;

2. системная архитектура и требования к объектам архитектуры должны быть оценены с учетом следующих критериев: учет требований к системе; соответствие требованиям к системе; соответствие используемых стандартов и методов проектирования; возможность программных объектов архитектуры выполнять установленные для них требования; возможности эксплуатации и сопровождения;

– анализ требований к программным средствам:

1. разработчик должен установить и документально оформить требования к программным средствам, включая технические требования к характеристикам качества;

2. разработчик должен оценить требования к программным средствам в соответствии с установленными критериям;

– проектирование программной архитектуры:

1. разработчик должен трансформировать требования к программному объекту в архитектуру, которая описывает общую структуру объекта и определяет компоненты программного объекта. Должно быть обеспечено распределение всех требований к программному объекту между его компонентами и дальнейшее их уточнение с точки зрения облегчения технического проектирования;

2. разработчик должен разработать и документально оформить общий (эскизный) проект внешних интерфейсов программного объекта и интерфейсов между компонентами объекта;

3. разработчик должен разработать и документально оформить общий (эскизный) проект базы данных;

4. разработчик должен разработать и документально оформить предварительные версии документации пользователя;

5. разработчик должен определить и документально оформить предварительные общие требования к испытаниям программного объекта и график сборки программного продукта;

6. разработчик должен оценить архитектуру программного объекта и эскизные проекты интерфейсов и базы данных по строго определенным критериям.

– техническое проектирование программных средств:

1. разработчик должен разработать технический проект для каждого компонента программного объекта. Компоненты программного объекта должны быть уточнены на уровне программных модулей, которые можно программировать (кодировать), компилировать и тестировать независимо;

2. разработчик должен разработать и документально оформить технический проект внешних интерфейсов программного объекта, интерфейсов между компонентами программного объекта и между программными модулями;

3. разработчик должен разработать и документально оформить технический проект базы данных;

4. разработчик должен, при необходимости, уточнить документацию пользователя;

5. разработчик должен определить и документально оформить требования к испытаниям и программе испытаний программных модулей. Требования к испытаниям должны определять воздействие на программный модуль в пределах установленных к нему требований;

6. разработчик должен уточнить общие требования к испытанию и программе сборки программных средств;

7. разработчик должен оценить технический проект и требования к тестированию по строго определенным критериям;

– программирование и тестирование программных средств:

1. разработчик должен разработать и документально оформить каждый программный модуль и базу данных, а также процедуры испытаний и данные для тестирования;

2. разработчик должен протестировать каждый программный модуль и базу данных, гарантируя, что они удовлетворяют установленным требованиям;

3. разработчик должен оценить запрограммированные элементы программного объекта и результаты их тестирования по следующим критериям: учет требований к программному объекту и проекту объекта в целом; внешнее соответствие требованиям и проекту программного объекта; внутреннее соответствие между требованиями к программным модулям; тестовое покрытие всех модулей; соответствие методов программирования и используемых для них стандартов; возможность сборки и тестирования; возможность эксплуатации и сопровождения;

– сборка программных средств:

1. разработчик должен разработать план сборки для объединения программных модулей и компонентов в программный объект. План должен включать требования к испытаниям, процедуры тестирования, контрольные данные, обязанности исполнителя и программу испытаний. План должен быть документально оформлен;

2. разработчик должен собрать программные модули и компоненты и протестировать их как продукты, разработанные в соответствии с планом сборки;

3. разработчик должен разработать и документально оформить для каждого квалификационного требования к программному объекту – набор тестов, контрольных примеров, процедуры испытаний для проведения квалификационных испытаний программных средств;

4. разработчик должен оценить план сборки, проект, запрограммированный программный объект, проведенные испытания, результаты тестирования и документацию пользователя по строго определенным критериям;

– квалификационные испытания программных средств:

1. разработчик должен проводить квалификационные испытания на соответствие квалификационным требованиям к программному объекту. При проведении испытаний должно быть обеспечено, чтобы реализация каждого установленного требования к программному объекту была проверена на соответствие;

2. разработчик должен оценить проект, запрограммированный программный объект, проведенные испытания, результаты испытаний и документацию пользователя по следующим критериям: тестовое покрытие требований к программному объекту; соответствие ожидаемым результатам; возможность сборки и тестирования системы при их проведении; возможность эксплуатации и сопровождения;

3. разработчик должен обеспечить проведение аудиторской проверки в соответствии с установленными нормативами;

4. после успешного завершения аудиторских проверок, если они проводились, разработчик должен: доработать (при необходимости) и соответствующим образом подготовить поставляемый программный продукт к сборке системы; определить состояние конфигурации проекта;

– сборка системы:

1. объекты программной конфигурации должны быть собраны в единую систему вместе с объектами технической конфигурации, ручными операциями и, при необходимости, с другими системами. Собранная система должна быть испытана на соответствие установленным требованиям;

2. для каждого квалификационного требования к системе должны быть разработаны и документально оформлены: состав испытаний и контрольных примеров; процедуры проведения квалификационных испытаний системы;

3. собранная система должна быть оценена в соответствии со следующим критериями: тестовое покрытие требований к системе; соответствие методов тестирования и используемых стандартов; соответствие ожидаемым результатам; выполнимость квалификационных испытаний системы; возможность эксплуатации и сопровождения;

– квалификационные испытания системы:

1. квалификационные испытания системы должны быть проведены в соответствии с квалификационными требованиями, установленными к системе. Должно быть обеспечено, чтобы реализация каждого требования к системе была испытана на соответствие установленным значениям и чтобы система была готова к поставке;

2. система должна быть оценена по следующим критериям: тестовое покрытие требований к системе; соответствие ожидаемым результатам; возможность эксплуатации и сопровождения;

3. разработчик должен обеспечить проведение аудиторской проверки;

4. после успешного завершения аудиторских проверок, если они проводились, разработчик должен: доработать и подготовить поставляемый программный продукт для обеспечения приемки и ввода его в действие; определить состояние конфигурации проекта и программ каждого объекта программной конфигурации;

– ввод в действие программных средств:

1. разработчик должен разработать план по вводу в действие программного продукта в среде эксплуатации. Должны быть определены и иметься в наличии ресурсы и информация, необходимые для ввода в действие программного продукта. Разработчик должен в соответствии с договором помогать заказчику в работах по установке программного продукта. В том случае, если устанавливаемый программный продукт заменяет существующую систему, разработчик должен обеспечить проведение любых параллельно выполняемых работ, обусловленных договором;

2. разработчик должен ввести в действие программный продукт в соответствии с планом по вводу его в действие;

– обеспечение приемки программных средств:

1. разработчик должен обеспечить проведение заказчиком оценки готовности к приемке и приемочным испытаниям программного продукта;

2. разработчик должен укомплектовать и поставить программный продукт заказчику, соблюдая условия договора;

3. разработчик должен, соблюдая условия договора, обеспечить первоначальное и непрерывное обучение и поддержку персонала заказчика.

Данный стандарт крайне подробно описывает стадии любого процесса, связанного с каждым этапом жизненного цикла программного обеспечения. В нём даются исчерпывающие указания по работе в любой момент цикла. Он имеет четкую и упорядоченную структуру.

Характеристики

Список файлов ВКР