Заказать разработку
Отправить заявку
MKDG - автоматизация логистики,автоматизация торговли,разработка erp систем,разработка по,разработка программного обеспечения,создание программ,электронный документооборот Разработка программного обеспечения
Москва, Варшавское шоссе д.42, Бизнес-центр «На Варшавке».
Главная / Публикации /

Как избежать ошибок при разработке ТЗ

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

 Пример 1. Чрезмерная детализация интерфейса.

…На вкладке должно быть наименование страницы, для того что бы человек видел на какой он странице сейчас находится. На форме должны быть размещены: кнопка «Назад» размещена слева, с ней в одной строке, но по правому краю размещены кнопки (ссылки):  кнопка с выпадающем меню «Действия с объявлением» - Сохранить в закладках, Редактировать, Удалить, Поднять в списке,  при нажатии на них система запросит ввода пароля и логина,  после успешной авторизации пользователь будет иметь возможность редактировать, удалять,  сделать заявку на статус VIP, подымать объявление; кнопки (ссылки) «Предыдущий», «Следующий» (для пролистывания товаров данной категории) и счетчик просмотров текущего объявления с количеством просмотров в целом и за текущую дату. Вид счетчика -  текстовый, «Просмотров: сегодня – [число просмотров], всего – [число просмотров]». Затем ниже слева предоставлена фотография товара с выбором до 3 др. фотографий…

 В приведенном в качестве примера техническом задании содержалось 16(!) разделов по 3-7 пунктов с каждом, описывающих, как должны выглядеть кнопки, стрелки, вкладки и т.п., - и практически ни одного, описывающего структуру АС и требуемый функционал.

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

  Пример 2. Противоречивые технические требования

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

3.8. Сайт должен обладать возможностью перспективы развития, модернизации системы.  

3.17. Сайт должен работать на всех популярных операционных системах, таких как: Windows и Unix-системах. 

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

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

 Пример 3. Расплывчатые формулировки.

п.3.8 Информационная совместимость со смежными системами должна быть на уровне базы данных.

3.14 Программа должна обладать системой защиты от ошибок и человеческого фактора.

Данные фрагменты, взятые из разных ТЗ (синтаксис и орфография сохранены), наглядно иллюстрируют то, что можно назвать расплывчатыми формулировками.

Если мы рассмотрим первый пункт примера, сразу возникает как минимум два вопроса: Какие системы будут являться смежными? Обмен какими данными будет проводиться со смежными системами? ГОСТ34-602-89 четко определяет:

- п.2.6.1.1. В требованиях к структуре и функционированию системы приводят: 3) Требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (курсив авт.)

 То же самое можно сказать и о втором пункте примера. Когда оператор системы вводит в поле «фамилия» дату рождения, пытается создать бухгалтерскую проводку на сумму  большую, чем сумма на счете, пишет в названии «КрИативный дЕзайн», или вносит в категорию «товары для дома» колесный асфальтоукладчик АСФ-К-4-01 -  все это ошибки, определяемые «человеческим фактором». И если защита от ошибок первого и второго рода  - это отличительная особенность любой грамотно спроектированной системы, и проверку правописания при необходимости можно реализовать, то уж последняя ошибка не имеет никакого отношения к правильной работе программы.

Пример 4. «Два в одном»

Средством связи для регистрации программы является специальный сайт, а в случае отсутствия Интернета, телефон.

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

a) Целиком на информационную систему, включающую в себя как непосредственно распространяемую программу, так и систему ее регистрации.

б) На две смежных системы.

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

Недопустимо использование формулировок, косвенно подразумевающих в рамках проекта создание дополнительных смежных систем или модулей, по сложности и затратам не уступающим основной системе.

 Пример 5. Разное…

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

В принципе, при разделении этого примера на несколько отдельных пунктов каждый из них, несмотря на некоторую неопределенность, в целом будет корректным и соответствовать положениям  ГОСТ34-602-89, а именно:

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

Но сами по себе, эти пункты требуют дополнительного разъяснения.

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

 Под термином свободное ПО подразумевается программное обеспечение, распространяемое под лицензией GNU GPL (General Public License)  и совместимых с ней лицензий (BSD, Lesser GPL, X11 и др.). При некоторых отличиях основными позициями этих лицензий являются следующие требования:

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

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

Следует понимать, что свободное ПО необязательно подразумевает его бесплатность. GNU GPL позволяет разработчику устанавливать любую цену на приобретение/скачивание программного обеспечения. GNU GPL лишь обязывает предоставить «эквивалентный доступ» к загрузке исходных кодов наряду с проприетарными версиями программного обеспечения, а так же запрещает требовать оплаты или уведомления от всех, кто получил программу. При этом GNU GPL не запрещает свободно модифицировать и распространять данную программу.

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

Программное обеспечение с закрытым исходным кодом может распространяться по EULA – End User License Agreement  - и быть платным, бесплатным (freeware) или условно-бесплатным (shareware). В последнем случае может предоставляться бесплатный пробный период или устанавливаться иное ограничение на коммерческую эксплуатацию программного продукта.

Комментарии (0)


Разрешённые теги: <b><i><br>Добавить новый комментарий:


© 2005—2017 «MKDG Group» Разработка программного обеспечения Пресс-центрПреимуществаКарта сайта