Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
РСПСИТ.doc
Скачиваний:
2
Добавлен:
02.09.2019
Размер:
116.22 Кб
Скачать
  1. Сущность и принципы структурного подхода, основные понятия и примеры.

Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции (бизнес‑процес­сы): сис­тема разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, а они – на задачи, и так до конк­рет­ных процедур. При этом автоматизируемая система сохра­няет целостное представление, в котором все составляющие компо­ненты взаимоувязаны.

Базовыми принципами структурного подхода являются:

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

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

  • принцип абстрагирования – выделение существенных аспектов сис­те­мы и отвлечение от несущественных;

  • принцип формализации – необходимость строгого методическо­го под­хо­да к решению проблемы;

  • принцип непротиворечивости – обоснованность и согласован­ность эле­ментов;

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

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

  • DFD (Data Flow Diagrams) – диаграммы потоков данных (процессов);

  • SADT (Structured Analysis and Design Technique) – модели и соот­ветству­ющие функциональные диаграммы;

  • ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь».

  1. Стандарты жизненного цикла пс. Iso/iec 12207, гост 19.102-77

Модель жизненного цикла ПС (ЖЦ ПС) – структура, содержащая про­цессы, дей­ст­вия и задачи, которые осуществляются в ходе разработки, функциони­ро­ва­ния и сопровождения программного средства в течение всей жизни системы, от определения требований до завершения ее использования (прил. 2.1).

ЖЦ ПС формулируется стандартами:

ISO/IEC 12207 (ГОСТ Р ИСО/МЭК 12207) – современный международный стандарт (прил. 2.1);

ГОСТ 19.102-77 ЕСПДустаревший стандарт;

ГОСТ 34.601-90. – стандарт для автоматизированной системы.

Стандарт ISO/IEC 12207 (ГОСТ Р ИСО/МЭК 12207) не предписывает конкрет­ную модель ЖЦ или метод разработки ПС, но определяет, что стороны-участницы использования стандарта ответственны за выбор модели ЖЦ для проекта ПС, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПС, за выполнение действий и задач, подходящих для проекта ПС.

Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПС. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте. Степень адаптивности – максимальная

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

Каждый процесс ЖЦ разделен на набор процессов, каждый процесс – на набор процедур. Очень важное отличие ISO: каждый процесс или процедура инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям процессов и процедур и т.п.).

В стандарте ISO 12207 описаны:

Основные процессы ЖЦ ПС

  1. Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПС.

  2. Процесс поставки. Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПС.

  3. Процесс разработки. Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт. Анализ требований к системе. Устанавливаются функции систе­мы, ус­ловия внешней среды, качество и требования к характеристикам, тре­бования к интерфейсам и к сопряжению аппаратных и программных средств. Проектирование системы. Требования к системе преобразуются в архи­тектуру системы, производится распределение функций и компонент меж­ду ап­паратурой и программами, а также ручными операциями, что оформляется до­кументом первичных требований к системе, компонентам и интерфейсам. Анализ требований к программному средству. Устанавливаются и доку­ментируются функции и предварительные спецификации требо­ваний к програм­мным и информационным компонентам, их качество и фи­зи­ческие характеристи­ки, необходимые ресурсы компьютера, требования к базе дан­ных и интерфейсам, к средствам обеспечения отладки и сопро­вож­дения. Проектирование архитектуры программного средства. Разра­батываются структура ПС и интерфейсы компонент, согласуются функ­ции и технические требования к компонентам, методы и стандарты проек­ти­рования, а также от­четные документы по процессам и объектам разработки. Детальное проектирование программного средства. Проводится детальная разработка спецификаций каждой компоненты, интерфейса между ними и кон­фигурации ПС, разрабатываются требования к тестам и план интегрирования компонент. Программирование компонент. Раз­ра­баты­ваются текст програм­мных модулей и описаний данных, процедуры и данные для их тести­ро­ва­ния, документы результатов тестирования, доку­менты процедур и данных для интеграции ПС.

  4. Процесс функционирования. Определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (а не только ПС) в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности. Эксплуатация системы и программного средства. Заказчик или пользо­ватель системы использует ее в соответствии с документацией, подготавливает отчеты о выявленных ошибках, а также о желательных модификациях и раз­витии системы и программного средства. Поддержка пользователей системы и программного средства. Осуществ­ляются обучение и консультация пользователей, накапливаются и обрабатыва­ются отчеты и рекомендации пользователей по совер­шенствованию системы; пользователи информируются об изменениях системы и ПС. Прекращение эксплуатации конфигурации системы и/или программного средства. Обоснование и извещение пользователей о прек­ращении поддержки версии системы, архивация версии и ее документации, предложение пользова­телям доступных вариантов для замены системы и/или программного средства.

  5. Процесс сопровождения. Определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия на вычислительной системе. Анализ ошибок и предложений на модификацию программного сред­ства. Исследуются спрос на модификацию, степень изменения прог­рамм и необ­ходимые затраты, риск и возможные альтернативы, подготав­ли­ваются решения на изменения и тесты для проверки. Реализация модификации программного средства. Корректиров­ка про­грамм, данных и интерфейсов, разработка необходимых модулей и ком­понент, повторение тестирования и испытания версии программного средства и системы. Приемка, установка, настройка и опытная эксплуатация новой версии системы в реальной среде.

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

ГОСТ 19.102–77 ЕСПД. Стадии разработки.

1. Техническое задание (стадия)

Обоснование необходимости разработки программы (этап). Постановка зада­чи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и ка­чества разрабатываемой программы. Обос­нова­ние необходимости проведения науч­но‑ис­следовательских работ

Научно‑исследовательские работы. Определение структуры входных и выход­ных данных. Предварительный выбор методов решения задач. Обоснование целесооб­раз­ности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи.

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