Методические рекомендации для студентов специальностей 230105 Программное обеспечение вычислительной техники и автоматизированных систем (стр. 7 из 11)
· балансовый или расчетный метод контроля отдельных показателей;
· метод контроля с помощью контрольных сумм и любые другие возможные способы контроля.
«Описание выходной информации» включает операции по определению состава реквизитов выходной информации, расположению реквизитов выходной информации с отражением контрольного примера, описанию полей (реквизитов) выходного документа.
Определение состава реквизитов выходной информации зависит от поставленной перед задачей цели; состав реквизитов должен быть необходимым и достаточным для организации работы специалиста подразделения.
Последовательность расположения реквизитов определяется правилами распределения реквизитов по частям документа: заголовочной, содержательной, оформительской и отдельным зонам. Внутри зон реквизиты также располагаются по установленным правилам (удобство работы пользователя, специфика отражения итогов, акцентирование внимания на отдельных реквизитах и т.п.). В результате этой операции создается эскиз выходного документа с отображением контрольного примера. В контрольном примере дается логика расчета, при этом используются числа, легко подсчитываемые вручную.
Заключительной операцией этого процесса является описание полей (реквизитов) выходного документа, или иначе — представление структуры выходного документа. В таблице идентификация отражает короткое, легко запоминающееся название поля в латинском алфавите, указывается тип данных (текст, число, дата).
При проектировании выходного документа необходимо учитывать также влияние программных и технических средств (информационная емкость экрана, ширина печатающего устройства, возможность получения нескольких экземпляров и т.п.). На этом же шаге проектирования обобщается специфика выходной информации: рассматриваются состав потребителей информации, способы передачи, объемно-временные характеристики, особенности контроля данных.
Описание алгоритма решения задачи (последовательности действий и логики решения задачи):
· описание способов формирования результатной информации с указанием последовательности выполнения логических и арифметических действий;
· описание связей между частями, операциями, формулами алгоритма;
· требования к порядку расположения (сортировке) ключевых (главных) признаков в выходных документах, видеограммах, например, по возрастанию значений табельных номеров;
· алгоритм должен учитывать общий и все частные случаи решения задачи.
Примечание. При описании алгоритма следует использовать условные обозначения (идентификаторы) реквизитов, присвоенные при описании исходной и результатной информации; допускается текстовое описание алгоритма. Необходимо предусмотреть контроль вычислений на отдельных этапах, операциях выполнения алгоритма. При этом указываются контрольные соотношения, которые позволяют выявить ошибки.
Алгоритм решения задачи отвечает на вопрос:
«Каким образом, т.е. на основе каких алгоритмов расчета входная информация преобразуется в выходную информацию?» Разработка алгоритмов решения задачи связана с выполнением неформализованного и формализованного моделирования.
При неформализованном моделировании алгоритмы расчетов представляются в описательном виде.
Формализованное моделирование осуществляется по определенным правилам. Согласно правилам по каждому экономическому показателю выявляются реквизиты-признаки и реквизиты-основания. Им присваиваются условные обозначения: реквизитам-основаниям заглавные буквы, реквизитам-признакам строчные буквы. Экономический показатель выражается в виде совокупности обозначений. Взаимосвязи показателей представляются в виде формул. Совокупность формул отражает инфологическую модель решения задачи. Инфологическая модель не только позволяет четко выразить логику расчета, но и служит основой для реализации других видов моделей: матричной, функциональной зависимости, графосхем. Это позволяет проектировать базы данных по задачам, комплексам задач, функциональным подсистемам и системе в целом.
Созданием инфологической модели заканчивается технология постановки задачи
(справочное)
БЛОК-СХЕМА АЛГОРИТМА
Блок-схема – это графическое представление алгоритма в виде плоских геометрических фигур, соединённых линиями. Конфигурация элементов схем определена ГОСТом 19.701-90 «Схемы алгоритмов, программ, данных и систем».
Таблица 1. Основные элементы блок-схем
| Изображение элемента | Назначение |
 | Определяет процесс формирования новых значений. Может содержать любые тексты, представляющие элементы процесса обработки данных. (Размер «а» (в мм) должен выбираться, исходя из формулы: а=10+5*n, где n=1,2,…. Размер «b» определяется соотношением b=1,5*a или b=2*a.) |
 | Определяет выбор одной из двух альтернатив выполнения алгоритма в зависимости от условия разветвления |
 | Выбор одной из n альтернатив, где n>2 |
 | Вызов процедуры |
 | Ввод/вывод данных |
 | Начало/конец процесса обработки данных |
 | Соединитель элементов схемы, расположенной на одном и том же или на разных листах |
(справочное)
оценка затрат на разработку ПО
Оценка затрат на разработку ПО является одним из наиболее важных видов деятельности в процессе создания ПО, хотя она и не выделена в стандарте ISO 12207 как отдельный процесс. При отсутствии адекватной и достоверной оценки невозможно обеспечить четкое планирование и управление проектом.
Недооценка стоимости, времени и ресурсов, требуемых для создания программ, влечет за собой недостаточную численность проектной команды, чрезмерно сжатые сроки разработки и, как результат, утрату доверия к разработчикам в случае нарушения графика. С другой стороны, перестраховка и переоценка могут оказаться ничуть не лучше. Если для проекта выделено больше ресурсов, чем реально необходимо, причем без должного контроля за их использованием, то ни о какой экономии ресурсов говорить не приходится. Такой проект окажется более дорогостоящим, чем должен был быть при грамотной оценке, и приведет к запаздыванию с началом следующего проекта.
Оценка затрат на разработку ПО предполагает выполнение следующих четырех шагов:
- оценка размера разрабатываемого продукта. Для ПО в прежнее время основной мерой оценки являлось количество строк кода (LOC - Lines Of Code), а в настоящее время является количество функциональных точек (FPs - Function Points). Под функциональной точкой понимается любой из следующих элементов разрабатываемого продукта:
- входной элемент приложения (входной элемент или экранная форма);
- выходной элемент приложения (отчет, документ, экранная форма);
- запрос (пара «вопрос/ответ»);
- логический файл (совокупность записей данных, используемых внутри приложения);
- интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него)
Оценка размера проекта базируется на знании функциональных и нефункциональных требований к ПП. Для такой оценки существуют два основных способа:
- По аналогии. Если в прошлом приходилось иметь дело с подобным проектом и его оценки известны, то можно, отталкиваясь от них, приблизительно оценить свой проект.
- Путем подсчета размера по определенным алгоритмам на основании исходных данных – требований к ПП.
Оценка трудоемкости проекта выводится на основании его размера. Для такой оценки также существуют два основных способа:
- Самый лучший вариант — это использование накопленных исторических данных, позволяющих сопоставить трудоемкость вашего проекта с трудоемкостью предыдущих проектов аналогичного размера. Однако это возможно только при следующих условиях:
- в организации аккуратно документируются реальные результаты предыдущих проектов;
- по крайней мере, один из предыдущих проектов (а лучше, если несколько) имеет аналогичный характер и размер;
- жизненный цикл, используемые методы и средства разработки, квалификация и опыт проектной команды вашего нового проекта также подобны тем, которые имели место в предыдущих проектах.
Подобным же образом (как на основе исторических данных, так и с использованием формальных методов) оцениваются продолжительность и стоимость проекта.