3.Жизненный цикл
Жизненный цикл ПП определяется как совокупность последовательных состояний программного продукта и всех действий по его преобразованию, начиная с анализа возникшей потребности в автоматизации определенных функций обработки данных до их программной реализации и включения в программное обеспечение (ПО) конкретного применения.
Модели жизненного цикла программных продуктов.
Традиционно в жизненном цикле ПП принято выделять следующие этапы:
· анализ, посредством которого осуществляется формализованное специфицирование (описание) предъявляемых к автоматизированным системам обработки информации (АСОИ) требований, или иначе, целей ПП;
· проектирование, включающее разработку иерархической структуры разрабатываемого ПО, функциональные спецификации отдельных модулей и структуры данных БД;
· программирование или, иначе говоря, кодирование функциональных модулей;
· тестирование и отладка, в процессе которых выявляется соответствие ПП его спецификациям;
· эксплуатация и сопровождение, когда разработанное ПО функционирует в составе (или в качестве) АСОИ в конкретной области применения.
Под спецификацией понимается формальное описание требований, свойств и функций объекта.
В процессе проектирования важен критерий окончания этапов, при выполнении которого можно фиксировать окончание того или иного этапа и, главное, прогнозировать сроки окончания разработки. В качестве такого критерия может выступать готовность документов, в которых фиксируются все проектные решения выполненного этапа разработки. Приведем схему ЖЦ ПП с указанием всех промежуточных документов (рисунок 1.1).
Прежде чем рассматривать подробное содержание упомянутых на схеме ЖЦ ПП документов, поясним, что проектирование - это процесс, протекающий во времени, и, следовательно, имеющий временную диаграмму реализации. Временная последовательность этапов учитывается в модели ЖЦ ПП.
Модель ЖЦ ПП определяет перечень этапов преобразования программа -> программное средство -> программный продукт, порядок выполнения этапов, а также критерии перехода от этапа к этапу.
Традиционная модель ЖЦ ПО строится по каскадному принципу, суть которого в том, что переход на следующий этап происходит после окончания предыдущего /2/. Если по оси ординат отложить этапы ЖЦ, а по оси абсцисс – время
4.Постановка задачи и спецификация программ.
Постановка задачи – важнейший этап в разработке программы. Результатом должна быть спецификация программы. Программная спецификация – точное описание того результата, который необходимо получить с помощью программы. Это описание должно точно устанавливать, что должна делать программа, не указывая, как она должна это делать. Для программ, заканчивающих свою работу каким-либо результатом, программная спецификация может иметь форму спецификации ввода-вывода, которая описывает желаемое отображение множества входных величин и множества выходных величин. Для циклических программ, в которых нельзя указать точку завершения, невозможно дать спецификацию ввода-вывода, поэтому специфицируются отдельные функции, реализуемые программой в ходе циклических операций.
Способы записи алгоритмов.
Графический вид представлений, например, в виде блок-схемы, либо текстовый вид на псевдоязыке. Графическая форма наглядна, но громоздка и подходит только для понимания общего смысла алгоритма. Запись на псевдоязыке, в котором присутствует ограничение для алгоритмических конструкций, более предпочтительна для детализированных описаний. Такая запись называется псевдокод. При составлении псевдокода можно учитывать конструкции того языка программирования, на котором, скорее всего, будет производиться реализация.
ОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТА “ОПИСАНИЕ ПОСТАНОВКИ ЗАДАЧИ”
ГОСТ 24.204-80
Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления (кроме общегосударственного), и устанавливает требования к содержанию документа “Описание постановки задачи”.
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Документ “Описание постановки задачи” предназначен для описания характеристик комплекса задач (задачи), условий, необходимых для его решения, входной и выходной информации и совместно с “Техническим заданием” на создание АСУ определяет требования к видам обеспечения АСУ.
1.2. Содержание разделов должно охватывать все задачи комплекса.
1.3. В зависимости от назначения и специфических особенностей создаваемых АСУ допускается включать в документ дополнительные разделы и сведения, требования к содержанию которых не установлены настоящим стандартом.
2. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТА
2.1. Документ должен содержать следующие разделы:
- характеристики комплекса задач;
- выходная информация;
- входная информация.
Примечание. При объединении документа “0писание постановки задачи” с документом “Описание алгоритма” последний помещают после раздела “Входная информация”.
2.2. В разделе “Характеристика комплекса задач” следует при водить: цель, назначение, технико-экономическую (организационно-техническую) сущность комплекса задач и обоснование
целесообразности его решения (в частности для задач оптимизации — критерий управления и ограничения);
перечень объектов (технологических, объектов управления, подразделений, предприятий и т. д.), при управлении которыми решают комплекс задач, при необходимости, — описание структуры объектов управления и перечень показателей, характеризующих их состояние;
описание процедур использования выходной информации;
периодичность решения и ограничения по срокам выдачи выходной информации;
требования к организации сбора и передачи в обработку входной информации (с указанием сроков ее поступления), к порядку ее контроля и корректировки;
условия, при которых прекращается решение комплекса задач автоматизированным способом;
связи данного комплекса задач с другими комплексами (задачами) АСУ;
должности лиц и (или) наименования подразделений, определяющих условия и временные характеристики конкретного решения задачи (если они не определены общим алгоритмом функционирования системы);
распределение функций между персоналом и техническими средствами при различных ситуациях решения комплекса задач.
2.3. Раздел “Выходная информация” должен содержать:
перечень и описание выходных сообщений;
перечень и описание имеющих самостоятельное смысловое значение структурных единиц информации выходных сообщений: показателей, реквизитов и их совокупностей, сигналов управления.
2.3.1. В описании по каждому выходному сообщению следует указывать:
идентификатор;
форму представления сообщения (документ, видеограмма, сигнал управления) и требования к ней;
периодичность выдачи;
сроки выдачи;
получателей информации.
Состав описания допускается дополнять в зависимости от вида и особенностей сообщения.
2.3.2. В описании по каждой структурной единице информации следует указывать.
наименование;
идентификатор выходного сообщения, содержащего структурную единицу информации;
требования к точности и надежности вычисления (при необходимости).
2.4. Раздел “Входная информация” должен содержать:
перечень и описание входных сообщений;
перечень и описание структурных единиц информации входных сообщений.
2.4.1. В описании по каждому входному сообщению следует указывать:
идентификатор;
форму представления сообщения и частоту поступления.
2.4.2. В описании по каждой структурной единице информации входных сообщений следует указывать:
наименование;
требуемую точность ее числового значения (при необходимости);
источник информации (документ, видеограмма, устройство, кодограмма, информационная база на машинных носителях и т. д.)
идентификатор источника информации.
2.5. В приложение включают чертежи форм документов, видеограмм для входной и выходной информации, а также другие материалы по усмотрению разработчика (например, описания массивов).