3. Постановка задачи и спецификация программы

3.1. Какие типы программных продуктов можно выделить? Чем они различаются?

1. Системное программное обеспечение

Предназначено для выполнения различных вспомогательных функций: управление ресурсами ЭВМ; создание копий используемой информации; проверку работоспособности устройств ЭВМ; выдачу справочной информации о компьютере.

В состав системного программного обеспечения можно отнести: операционную систему; антивирусные программы; программы архивирования; программы обслуживания сети и др.

2. Пакеты прикладных программ - непосредственно обеспечивают выполнение необходимых пользователю работ.

Примеры прикладных программ: текстовые редакторы (Microsoft Word); системы машинной графики (учебные, научные, инженерные и др.); электронные таблицы (Microsoft Excel); системы управления базами данных (Microsoft Access); издательские системы; бухгалтерские программы (1С Бухгалтерия, Турбо Бухгалтер и др.); системы автоматизированного проектирования; экспертные системы; системы искусственного интеллекта (проверка орфографии, перевод, распознавание текста); браузеры; обучающие программы и др.

3. Инструментарий технологии программирования (облегчают процесс создания новых программ для ЭВМ на конкретном языке программирования).

 

Примеры систем программировани: Quck Basic; Turbo Basic; Visual Basic; Pascal; C++; Delphi и др.

3.2. Назовите основные эксплуатационные требования к программным продуктам.

• правильность - функционирование в соответствии с техническим заданием;

• универсальность - обеспечение правильной работы при любых допустимых данных и защиты от неправильных данных;

• надежность (помехозащищенность) - обеспечение полной повторяемости результатов, т. е. обеспечение их правильности при наличии различного рода сбоев;

• проверяем ость - возможность проверки получаемых результатов;

• точность результатов - обеспечение погрешности результатов не выше заданной;

• защищенность - обеспечение конфиденциальности информации;

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

• аппаратная совместимость - возможность совместного функционирования с некоторым оборудованием;

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

• адаптируемость - возможность быстрой модификации с целью приспособления к изменяющимся условиям функционирования;

• повторная входимость - возможность повторного выполнения без перезагрузки с диска;

• реентерабельность - возможность «параллельного» использования несколькими процессами. Правильность является обязательным требованием для любого программного обеспечения:

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

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

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

3.4. Из каких разделов состоит техническое задание? Какую информацию должны содержать разделы?

Основные разделы: введение, назначение и требования к программному продукту. В соответствии с этим стандартом техническое задание должно содержать следующие разделы: • введение

• основания для разработки

• назначение разработки

• требования к программе или программному изделию

• требования к программной документации

• технико-экономические показатели

• стадии и этапы разработки

• порядок контроля и приемки. Наиболее сложным, как правило, является четкое формулирование основных разделов

Общие сведения

полное наименование системы и ее условное обозначение;

Пример:

Полное наименование системы: Автоматизированная система "Управление" Условное обозначение: АСУ

шифр темы или шифр (номер) договора;

Пример:

Договор № ХХХ от ДД.ММ.ГГГГ

наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

Пример:

ЗАКАЗЧИК Наименование заказчика: ООО "МИР" Юридический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Почтовый адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Фактический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Телефон: +7 903 456 67 67 Факс: +7 903 453 34 54 Адрес электронной почты: Pro@mir.com ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО "БанкСтрой", г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423{{[[Шаблон:|]]}}400000000234

ИСПОЛНИТЕЛЬ Наименование исполнителя: ООО "ДЯТЕЛ" Юридический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Почтовый адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Фактический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Телефон: +7 495 345 63 63 Факс: +7 495 433 34 54 Адрес электронной почты: Gena@gizni.net ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО "БанкСтрой", г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423400000000234

перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

плановые сроки начала и окончания работы по созданию системы;

сведения об источниках и порядке финансирования работ;

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

Назначение и цели создания системы

Характеристика объекта автоматизации

краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

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

Требования к системе

Требования к системе в целом;

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

Требования к видам обеспечения.

Состав и содержание работ по созданию системы

перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;

вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);

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

перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организации-исполнителей (при необходимости).

Порядок контроля и приемки системы

виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

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

статус приемочной комиссии (государственная, межведомственная, ведомственная).

Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

изменения, которые необходимо осуществить в объекте автоматизации;

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

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

сроки и порядок комплектования штатов и обучения персонала.

Требования к документированию

согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и научно-технической документации отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;

требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

Источники разработки: документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

: введения, назначения и требований к программному продукту.

3.5. Какой раздел технического задания считают основным и почему? В чём основная сложность разработки технического задания?

Основные разделы: введение, назначение и требования к программному продукту.

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

3.6. Какие решения ранних этапов проектирования являются основными и почему?

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

• выбор типа пользовательского интерфейса и технологии работы с документами

• выбор подхода к разработке структурного или объектного

• выбор языка и среды программирования.

Что такое спецификация? Что включает первичная функциональная спецификация?

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — законченное описание поведения программы, которую требуется разработать.

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

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

В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».

3.7. Что включают внутренняя и внешняя функциональные спецификации?

Что понимают под типовыми элементами в программировании?

Под типовыми элементами, или «кубиками», понимаются какие-то отдельно изготовленные типовые части, из которых можно было бы собирать множество программ.

3.8. Какие механизмы использования типовых элементов предоставляют объектно-ориентированные языки программирования?