Разработка ПО Стадии разработки ПО Технологии Разработка баз данных ПО собственной разработки Наши лицензии Контакты Наши крупные заказчики по внедрению  IT-проектов ГУП «Петербургский метрополитен» Министерство транспорта Российской Федерации ФГУП "ЗащитаИнфоТранс" Оставить отзыв Отзывы клиентов Стадии разработки ПО (программного обеспечения) При разработке программного обеспечения мы используем Государственные стандарты, которые определяют не только состав документации, но стадийность разработки программного обеспечения. Формирование Технического задания Специалисты ООО «М-ТЕ» учитывают всю важность грамотной постановки задачи на этапе создания Технического задания и считают этот процесс неотъемлемой частью разработки, которая может занимать достаточно много времени. Разработка Технического задания (ТЗ), как правило, проводится при плотном взаимодействии с Заказчиком. В результате этого этапа (разработка ТЗ) создается документ «Техническое задание». «Техническое задание» может быть достаточно объемным и должно отражать всю функциональность будущего программного приложения или системы. Но, тем не менее, предусмотреть всю функциональность в рамках Технического задания (ТЗ) бывает достаточно сложно. Этот факт обязательно учитывается и предусматривается возможность внесения изменений в Техническое задание на последующих этапах разработки. До начала выполнения работ, необходимо определиться с их стоимостью и временем выполнения. Поэтому специалисты ООО «М-ТЕ» еще до заключения договора изучают поставленную задачу. Для формирования коммерческого предложения нам необходимо сформировать Технические требования (ТТ), где будут отражены основные возможности программного обеспечения (Комплекса задач, системы). Уже после этого специалисты М-ТЕ имеют представление об объекте автоматизации, логике работы будущего программного обеспечения (бизнес-процессах), методах автоматизации и других аспектах процесса разработки. Разработка базы данных Большинство разработок не обходится без создания базы данных (БД). Современные платформы баз данных (MS SQL, ORACLE, DB2) предназначены не только для хранения информации и выполнения примитивных операций SELECT, UPDATE, DELETE, INSERT, но и способны задавать логику обработки информации. В результате, программное обеспечения клиента (АРМ – автоматизированное рабочее место) несет только функциональную нагрузку по вводу значений (параметров) и отображению данных. Этот подход снижает требования к аппаратной части клиентских ПЭВМ, а все «тяжелые» операции выполняются на сервере баз данных (БД). В зависимости от качества спроектированной базы данных (таблицы, ключи, уникальные поля, связи, хранимые процедуры, функции, триггеры и т.д.) напрямую зависит будущее программного приложения. При разработке базы данных обязательно учитывается возможность ее вертикального и горизонтального масштабирования и, при не грамотном проектировании БД, вносить изменения в уже существующий программный продукт достаточно трудно. Так же важно учитывать при разработке БД объемы обрабатываемых данных. При больших объемах данных и сложных логических операциях, обусловленных требованиями бизнес-процессов, выполнение транзакций может занимать неприемлемо большое время (например, при обработке входных данных полученных с использованием автоматизированных устройств таких как, сканер штрих кодов, электронная карта). Поэтому мы уделяем большое внимание этапу разработки базы данных (БД). При проектировании БД специалисты М-ТЕ используют принципы нормализации БД с применением обоснованной денормализации с целью сокращения времени выполнения операций, требуемого Вашими бизнес-процессами. Разработка сервера приложений Иногда целесообразна разработка сервера приложений. Сервер приложений является промежуточным звеном между конечным клиентом и базой данных (БД). Несмотря на использование современных платформ баз данных, часть логической обработки (в основном не данных, а действий оператора) возлагается на программное приложение. Перенос этой функциональности со стороны клиента на сервер приложений дает ряд преимуществ, а сама технология называется «тонкий клиент». Перечислим эти преимущества: внутрипрограммная логика работы заложена централизовано, а значит, при изменении логики не требуется обновления клиентских приложений; клиент действительно предназначен только для ввода параметров и отображения данных, что фактически сводит требования к аппаратной части ПЭВМ к требованиям функционирования операционной системы (ОС); серьезно повышается безопасность использования автоматизированного рабочего места (АРМ) использующего приложение (систему, комплекс задач), за счет осуществления работы с назначением определенного порта обмена данными. серьезно повышается безопасность хранения данных на сервере БД, за счет возможности размещения сервера приложений в демилитаризованной зоне информационной инфраструктуры предприятия. К технологии «тонкого» клиента относится и использование WEB доступа. В этом случае, в качестве сервера приложений выступает сервис IIS (Internet Information Services), но функциональность Web-браузера обычно гораздо больше, чем требуется Вашему приложению. К недостаткам можно отнести и меньшую защищенность и зависимость разметки элементов в области отображения браузера от его производителя. Неоспоримым плюсом использования WEB-доступа является возможность подключения с любого ПЭВМ имеющего выход в общедоступную сеть (Internet) и Web-браузер. Однако, эта возможность является и минусом: достаточно знать имя пользователя и пароль что бы воспользоваться доступом к Вашим данным. Для исключения этой ситуации необходимо применение дополнительных средств защиты от несанкционированного доступа (таких как использование электронных ключей, внедрение центра сертификации и др.). Разработка приложения (комплекса задач, системы) Разработке клиентского приложения предшествует проектирование визуального интерфейса приложения. В основу проектирования визуальной части специалисты «М-ТЕ» закладывают два принципа: визуальный интерфейс должен быть интуитивно понятен пользователю; должен быть осуществлен принцип преемственности; Часто, перед принятием решения о ведении собственной разработки программного обеспечения организация уже использует некую автоматизированную среду (построенную с использованием MS Access, разрозненные общедоступные утилиты по различным видам учета и т.д.), а значит, у пользователя уже приобретены некоторые навыки работы с ней. С целью сокращения периода «привыкания» к работе с новой программой иногда имеет смысл использовать уже привычные визуальные формы. К моменту написания исходных кодов уже имеется: Техническое задание; Спроектированная база данных (БД); Определена необходимость разработки сервера приложений, при ее необходимости определен протокол обмена данными между клиентским приложением и сервером приложений; Разработана визуальная составляющая; На основании имеющегося Технического задания (ТЗ) и проекта визуальных форм закладывается логика работы в Ваш программный продукт. Тестирование Этот этап работы имеет не менее важное значение, чем остальные. В рамках тестирования определяется: соответствие требованиям Техническому заданию и проекту визуальных форм; возможность выполнения на различных операционных системах (ОС); устойчивость программного продукта к внешнему воздействию (попытка задания некорректных условий, подмена программных модулей, удаление модулей, изменение конфигурации и др.); стабильность работы во времени и другие характеристики; В рамках этого этапа формируется карта тестирования, которая определяет проведение всех необходимых тестов программного продукта. По результатам тестирования формируется список замечаний и предложений разработчикам. Практически, по результатам тестирования возникает ряд вопросам по логике работы к Заказчику. Обычно, на этом этапе и выявляются вопросы, не рассмотренные в Техническом задании (ТЗ), осуществляется его корректировка. Разработка документации От качества документации зависит грамотная эксплуатация и обслуживание Вашего программного обеспечения. Разрабатываемая нами документация соответствует требованиям ГОСТов (34 и 19 серии), но обычно, разрабатывается и дополнительная документация для конечных пользователей с целью более легкого ее восприятия и сокращения этапа обучения. Перечень разрабатываемой документации определяется Техническим заданием. К «стандартной» (определенной ГОСТом) документации, прилагаемой к программному обеспечению, относится: Техническое задание; Пояснительная записка; Описание программы; Программа и методика испытаний; Руководство оператора; Руководство программиста; Спецификация; Можно увидеть в приведенном списке, что отсутствует некоторая документация, определенная ГОСТом (текст программы, руководство системного программиста, описание языка и т.д.). Предлагаемый нами перечень «стандартной» документации частично включает недостающие, согласно требованиям ГОСТа, документацию (например: руководство системного программиста включено в руководство программиста), а частично исключает (например: описание языка – это большие книги, которые можно купить в магазине технической литературы, но Заказчику, как правило, это не нужно). В любом случае, состав документации обязательно согласуется с Заказчиком. Приемо-сдаточные испытания К моменту приемо-сдаточных испытаний нельзя говорить о готовности программного обеспечения к вводу в промышленную эксплуатацию. Обоснование этого проведем ниже. Приемо-сдаточные испытания проводятся с участием Заказчика и Исполнителя. Со стороны Заказчика обычно присутствуют подразделения эксплуатирующие и сопровождающие программный продукт (систему, комплекс задач), а разработка ведется под непосредственным контролем сопровождающего подразделения (ИТ подразделения). При проведении приемо-сдаточных испытаний используется документ «Программа и методика испытаний» и учитываются пожелания пользователей. К приемо-сдаточным испытаниям имеется согласованный с Заказчиком набор документов, программный продукт, проверенный специалистами сопровождающего подразделения в рамках их должностных обязанностей, но без учета мнения конечных пользователей, в результате чего, возникают дополнительные пожелания. Кроме того, необходимо учитывать, что разработанная программа (комплекс задач, система) на момент испытаний разворачивается непосредственно на оборудовании и внутри информационной инфраструктуры Заказчика, что может вызвать несовместимость с уже функционирующими задачами (например: иногда возникает необходимость установки конкретных региональных настроек операционной системы для существующей задачи, что негативно сказывается на внедряемой задаче или настройки монитора не позволяют отобразить всю выводимую информацию с читабельным шрифтом). Все тонкости условий эксплуатации, безусловно, должны быть отражены в Техническом задании, но разработка Технического задания ведется специалистами нашей организации совместно со специалистами Заказчика (ГОСТ предусматривает разработку ТЗ только Заказчиком) и, как уже говорилось, предусмотреть все нюансы невозможно. Мы готовы к этому и ведем доработку программного обеспечения и документации по результатам приемо-сдаточных испытаний. По завершению приемо-сдаточных испытаний составляется протокол, который отражает все недочеты в работе программного обеспечения и делается заключение о возможности ввода в опытную эксплуатацию или проведению повторных испытаний. Опытная эксплуатация Опытная эксплуатация – последний этап перед вводом в промышленную эксплуатацию. На этом этапе Исполнитель отрабатывает замечания, полученные в рамках приемо-сдаточных испытаний, и ведет постоянный контроль над функционированием системы. Обычно, для проведения опытной эксплуатации выбирается «пилотная» зона. Мы рекомендуем делать выбор пилотной зоны исходя из следующих принципов: возможные ошибки в работе программного обеспечения не приведут к серьезным нарушениям в работе предприятия в целом; разнообразие программных и аппаратных средств максимально. Естественно, что на этапе опытной эксплуатации все выявленные недочеты в программном обеспечении будут устранены, все дополнительные пожелания пользователей будут выполнены. После окончания опытной эксплуатации осуществляется ввод в промышленную эксплуатацию и тиражирование, теперь уже готового, Вашего программного продукта. Заключение Как видно, процесс создания программного обеспечения длителен и трудоемок. Но эффективность от готового программного продукта, автоматизирующего Ваши бизнес-процессы, может превзойти все ожидания! Подумайте: это сейчас поставлена на поток и реализовано в виде лицензионного программного обеспечения продажа с использованием штрих-кодов, а раньше стоимость товара вводили операторы и учет продаж вели ежедневно. Автоматизация этого процесса позволила сократить расходы фонда оплаты труда и увеличить скорость обслуживания покупателей у тех организаций, которые внедрили эту технологию. А если для Ваших целей еще нет или Вам не подходит лицензионное программное обеспечение – сколько Вы теряете в материальном выражении? По всем вопросам разработки и внедрения программного обеспечения обращайтесь в наш отдел продаж по т. (812) 933-69-51; 336-20-51, 336-20-55.