ТехЗадание_образец1. Методические указания к лабораторной работе 1 Разработка технического задания на программное средство и автоматизированную систему
 Скачать 0.78 Mb.
|
|
Эксплуатационное назначение Программа должна эксплуатироваться в подразделениях заказчика. Пользователями программы должны являться сотрудники подразделений заказчика. Требования к программе или программному изделию Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы: 1. требования к функциональным характеристикам; 2. требования к надежности ; 3. условия эксплуатации ; 4. требования к составу и параметрам технических средств ; 5. требования к информационной и программной совместимости ; 6. требования к маркировке и упаковке ; 7. требования к транспортированию и хранению ; 8. специальные требования. Если существуют стандарты, содержащие общие (технические) требования к программе, системе или изделию , к примеру, «ГОСТ 12345-67. Автоматизированные информационно- измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание. Требования к функциональным характеристикам В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных , временным характеристикам и т. п. [из п. 2.4.1 ГОСТ 19.201-78] Требования к составу выполняемых функций Программа должна обеспечивать возможность выполнения следующих функций: создания нового файла; открытия существующего файла; редактирования файла путем ввода, замены , удаления содержимого файла с применением стандартных устройств ввода ; функции редактирования текущего файла с применением буфера обмена операционной системы ; сохранения файла с исходным именем ; сохранения файла с заданным именем; вывода оперативных справок (подсказок); интерактивной справочной системы ; отображения названия программы, версии программы, копирайта и комментариев разработчика. Требования к организации входных данных Входные данные программы должны быть организованы в виде отдельных файлов формата rtf, соответствующих RFC... Файлы указанного формата должны размещаться ( храниться ) на локальных или съемных носителях , отформатированных согласно требованиям операционной системы. Любой файл иного формата , но с расширением rtf, открываться не должен. Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Требования к организации выходных данных Требования те же, что и к организации выходных данных. Тот самый случай, когда следует объединить оба пункта технического задания. Требования к временным характеристикам Требования к временным характеристикам программы не предъявляются. Следует уточнить, предъявляет ли заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Если заказчик укажет конкретные цифры, следует подстраховаться и заложить в требованиях к составу и параметрам технических средств суперкомпьютер стоимостью от $2500. Правда, такую сумму придется обосновывать. Если временные характеристики для заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам, см. формулировку выше. Требования к надежности В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования , контроль входной и выходной информации, время восстановления после отказа и т.п.) Надежность – штука тонкая и очень опасная. Но перечень функций и видов их отказов , согласно п. 1.3.2. ГОСТ 24.701-86 , обязан составить заказчик и согласовать с исполнителем. Скорее всего, дождаться от заказчика чего-либо вразумительного не удастся. Стоит разъяснить заказчику, что надежное функционирование программы зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы , а также предложить заказчику ряд жестких мер для повышения надежности и устойчивости функционирования программы Требования к обеспечению надежного (устойчивого) функционирования программы Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже: организацией бесперебойного питания технических средств; использованием лицензионного программного обеспечения; регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»; регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютеpных виpусов К списку можно добавить еще несколько десятков нормативно-технических документов . В ходе первичного согласования технического задания заказчик, скорее всего, начнет проявлять склонность к компромиссу. Возможен более гуманный подход. Под надежностью (правда, системы, по тому же ГОСТу) можно считать безотказное выполнение некой i-той функции в течение конкретного интервала времени. Предложим заказчику считать критерием надежной работы программы следующий показатель: заказчик в течение часа 100 раз открывает и закрывает файл. Если в указанном интервале времени программа не даст сбоев , требования по надежности считаются выполненными. Если заказчик, наконец, убедился, что надежность зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы, и махнул рукой – в разделе обязательно следует написать такую фразу: Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются. Время восстановления после отказа Время восстановления после отказа , вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать стольких-то минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. Перечень аварийных ситуаций ситуаций также составляет заказчик и согласовывает с исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств. Отказы из-за некорректных действий оператора Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу пользователя без предоставления ему административных привилегий Условия эксплуатации программы В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации ( температура окружающего воздуха , относительная влажность и т.п. для выбранных типов носителей данных ), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания , необходимое количество и квалификация персонала [из п. 2.4.3 ГОСТ 19.201-78] Очень опасный подраздел для тех, кто делает первые шаги в разработке технического задания. Климатические условия эксплуатации Климатические условия эксплуатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации. Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90 % и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но как только в техническом задании окажется конкретика и задание будет утверждено, заказчик получает отличный шанс заставить исполнителя провести климатические испытания в полном объеме за счет исполнителя. Примечание от 10.02.2011 г. - По иронии судьбы специалисты «Технической документации» не так давно снова «попали на климатику», а точнее - провели разработку программы и методики испытаний на воздействие внешних факторов , по данным и результатам испытаний подготовили протокол испытаний , открыв для себя еще одно направление деятельности . Не зря говорят, что история развивается по восходящей спирали... Требования к видам обслуживания Программа не требует проведения каких-либо видов обслуживания Виды обслуживания следует позаимствовать из подраздела «Требования к обеспечению надежного (устойчивого) функционирования». Если заказчик в ходе согласования технического задания сошлется на отсутствие ресурсов или желание проводить все виды обслуживания собственными силами, имеет смысл предложить разработку технического задания на сопровождение программного изделия за отдельные деньги отдельным договором. Откажется – следует считать программу необслуживаемой Требования к численности и квалификации персонала Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц – системный администратор и пользователь программы – оператор. Системный администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить: задача поддержания работоспособности технических средств; задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы; задача установки (инсталляции) программы. Пользователь программы (оператор) должен обладать практическими навыками работы с графическим пользовательским интерфейсом операционной системы. Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием). При отсутствии самой ключевой фразы в утвержденном техническом задании заказчик вправе затребовать от исполнителя разработку руководства по эксплуатации графического пользовательского интерфейса операционной системы, мотивируя тем, что оператор «не справляется» с программой. Требования к составу и параметрам технических средств В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик Следует подбирать технику не хуже той, на которой будет производиться разработка. Логично затребовать, чтобы технику предоставил заказчик не позднее указанного срока. Речь идет, разумеется, о компьютере. В состав технических средств должен входить IBM-совместимый персональный компьютер, включающий в себя: процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее; материнскую плату с FSB, - 5 ГГц, не менее; оперативную память объемом, Тб - 10, не менее; и так далее… Требования к информационной и программной совместимости В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам , языкам программирования и программным средствам , используемым программой. При необходимости должна обеспечиваться защита информации и программ Требования к информационным структурам и методам решения Информационная структура файла должна включать в себя текст, содержащий разметку , предусмотренную спецификацией формата rtf. или Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются. Требования к исходным кодам и языкам программирования Исходные коды программы должны быть реализованы на языке C++. В качестве интегрированной среды разработки программы должна быть использована среда Borland C++ Buider. Требования к программным средствам, используемым программой Системные программные средства , используемые программой, должны быть представлены лицензионной локализованной версией операционной системы такой-то. Допускается применение пакета обновления такого-то. Требования к защите информации и программ Требования к защите информации и программ не предъявляются. Подобных требований следует избегать, если нет особого желания разработать что-то вроде концепции обеспечения информационной безопасности согласно ГТК РФ. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения Обеспечить некоторый уровень защиты информации и программ возможно, обеспечить безопасность невозможно. Заказчик, скорее всего, это осознает и проявлять настойчивость не станет. Требования к маркировке и упаковке В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия , варианты и способы упаковки [из п. 2.4.6 ГОСТ 19.201-78] Программа поставляется в виде программного изделия - на дистрибутивном (внешнем оптическом ) носителе (компакт-диске). Речь идет, разумеется, о маркировке и упаковке дистрибутивного носителя данных Требование к маркировке Программное изделие должно иметь маркировку с обозначением товарного знака компании- разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера сертификата соответствия Госстандарта России (если таковой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74. Качество маркировки проверяется самыми изощренными способами – сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача исполнителя - прикрыться сертификатом соответствия (затребовать сертификат у полиграфистов). Требования к упаковке Упаковка программного изделия должна осуществляться в упаковочную тару предприятия- изготовителя ( поставщика ). Именно предприятия-изготовителя (поставщика). Исполнитель не может и не должен нести ответственность большую, чем предприятие-изготовитель (поставщик) тары. Условия упаковывания Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде. Заказчик получит программное изделие надлежащего внешнего вида. В случае возврата программного изделия (по рекламации ) в ненадлежащем виде (наличие царапин, трещин и прочих дефектов ) исполнитель сможет предъявить претензии в части нарушения заказчиком условий упаковывания и не принять программное изделие. Порядок упаковки Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 7933- 89) согласно чертежам предприятия-изготовителя тары. Программное изделие упаковывается с применением чехлов из водонепроницаемой пленки с обязательным наличием химически неагрессивных влагопоглотителей (силикагеля). Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта. Эксплуатационная документация должна быть уложены в потребительскую тару вместе с программным изделием. На верхний слой прокладочного материала укладывается товаросопроводительная документация - упаковочный лист и ведомость упаковки. Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87. Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги. В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88. Габариты грузового места должны быть не более 1250 • 820 • 1180 мм. Масса НЕТТО - не более 200 кг. Масса БРУТТО - не более 220 кг. Приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Требования к транспортированию и хранению В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования , места хранения , условия хранения, условия складирования, сроки хранения в различных условиях В подразделе приведены условия транспортирования и хранения из ранее разработанного документа на какие-то технические средства. Это касается и требований к порядку упаковки. Выглядит несколько необычно в контексте программного изделия. Заказчик не вправе нарушать условий транспортирования и хранения. Исполнитель сможет отказать заказчику в возврате программного изделия, утверждая, что ненадлежащий внешний вид программного изделия является следствием несоблюдения условий транспортирования и хранения. Условия транспортирования и хранения Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный. При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания пыли и атмосферных осадков . Не допускается кантование программного изделия. Климатические условия транспортирование приведены ниже: температура окружающего воздуха, °С - от плюс 5 до плюс 50; атмосферное давление , кПа - такое-то; относительная влажность воздуха при 25 °С - такая-то. |