А вот вопрос: какие «специфические знания» с вашей точки зрения необходимы? Насколько я помню, был у нас как-бы веб-дизайнер. С кнопочками как раз у нее все было хорошо, и с CSS тоже неплохо, а вот с дизайном интерфейса никак. А именно был проект, по которому надо было старую CRM систему перевести на новые технологии и с расширением функционала, интерфейс планировался — веб вместо java-приложения (десктоп). Максимум, что сделал веб-дизайнер, так это задал цветовую гамму и стиль шрифта. Вся компоновка (по-моему, порядка 29 составных экранов, каждый из которых делится еще на несколько более простых, и таким образом более сотни кранов) была произведена менеджером, а не веб-дизайнером, который показал полную несостоятельность в данном вопросе. Оно и понятно, если мы говорим об интерфейсах сложных приложений (простенькие или представительские веб-сайты я не беру в рассмотрение и надеюсь автор комментария не их имел в виду), так как дело не в эстетике, не в цветовой палитре, а в компоновке элементов интерфейса, в удобстве расположения функциональных элементов, которые пляшут от требуемой функциональности, от специфики и стиля работы пользователя, от его требований и т.д. А с этим как раз работает менеджер (или аналитик, или… не важно как этот человек в каждой компании называется), тот, кто бок о бок работает с клиентом, практически живет в его компании, ощущает эту компанию. Передать это невозможно, а таскать дизайнера — глупо, так так тогда надо таскать пол команды.
Поэтому на практике мы выработали следующий подход: структуру интерфейса, элементы, отклики и пр. создает менеджер плотно работающий с клиентом на проекте. Эти интерфейсы отдаются дизайнеру (в компании есть дизайнер и есть верстальщик, это разные люди), который достаточно быстро стилизует интерфейсы, можно в той же программе. Если интерфейсы приняты и уже не требуют изменений, переходим к реализации — подключению к системе, здесь работает верстальщик и отчасти программист. Что мы выигрываем: время и терпение клиента (а это не мало, особенно на больших проектах), качество интерфейса, собственно время менеджера (как ни странно — объяснять по несколько раз дизайнеру, потом показывать клиенту, потом опят объяснять дизайнеру, потом опять клиент, снова дизайнер, клиент… и т.д. — это значительно больше, чем по указанной выше схеме), общее время, скорость разработки. Кстати про CRM: клиент был очень доволен интерфейсами, и все они были приняты с минимальными корректировками.
аа… речь, если я правильно понимаю, идет о выдаче лицензии на осуществление деятельности, связанной с конкретными сертифицированными шифровальными средствами в соответствии с ФЗ РФ «О лицензировании отдельных видов деятельности» (N 158-ФЗ от 25 сентября 1998 года). Да, здесь дело не в стандарте, а исходно в законе, который в свою очередь в части алгоритма криптования ссылается на конкретный стандарт. В таком случае такой стандарт в КОНКРЕТНОЙ ситуации (в связке с данным законом) становится обязательным.
Но тем не менее этот вид лицензирования (по ЗАКОНУ) вам потребуется если вы: а) захотите создавать вышеуказанные средства или б) быть владельцем такого средства. Это вопросы безопасности. Стандарт здесь вторичен.
Кстати, если вы просто хотите что-то криптовать, например свои фотографии, то здесь выбирайте любой понравившийся алгоритм криптования.
Мы как раз на данный момент практически закончили для одной компании разработку системы удостоверяющего центра. В качестве средства защиты информации использовался VipNet от компании Инфотекс (имеет лицензию), которое мы встроили в свою систему, осуществляющую организацию самого процесса создания, согласования и подписания документов и их хранения, получили отдельный продукт. Владелец этого продукта также прошел лицензирование в ФАПСИ, так как является держателем сертификатов и предоставляет такой сервис, нам (так как работаем со средствами криптографии как с черным ящиком) такая сертификация не нужна. Сертифицирован должен был быть только отдельный модуль, которым и является VipNet.
Аналогично решается ситуация, когда есть система и надо иметь разрешения и лицензии на хранение например персональных данных. Зачем сертифицировать свою систему (кстати все, что пройдет сертификацию менять нельзя, иначе все надо проходить заново), когда хранение данных можно вынести в отдельный модуль под управлением стороннего сертифицированного ПО и радоваться жизни :) Кстати нам это сами сертифицирующие органы подсказали. Иначе можно разориться так как расчет стоимости такого удовольствия идет в пересчете на строки кода, что в нашем случае по скромным подсчетам составляло порядка 1,5 млн рублей. А если учесть, что мы обновляем наше ПО 4 раза в год, то это нам встанет в 6 млн рублей. А зачем?
Так что дело тут не в стандартах и потом всегда можно найти красивый и правильный выход. Если я не так поняла ваш вопрос, то задайте более конкретный с описанием вашей ситуации, возможно что и подскажу полезного :)
Давайте разберемся: что за сертификация ПО? вернее на соответствие чему? с какой целью?
работать нельзя где, или с кем, или в чем? Что значит в криптографии? провайдером или?
Вопрос неточен или даже возможно содержит несколько вопросов. Будьте добры точнее сформулируйте.
Я не чувствую себя профессионалом, так как всегда есть то, что я не знаю :) Такая уж быстро меняющаяся эта отрасль. По поводу отметенных стандартов — так сперва и я думала, что мне нужен только шаблон, а остальное ненужная вода, но со временем поняла, что многие вопросы я не могу без правильного процесса осветить, даже не так, не то, что не могу, просто много времени занимают и тяжко все как-то получается. Поэтому занялись процессами. Что и вам желаю. Но если в текущей ситуации вам кажется, что это не надо — видимо так оно и есть :)) честно :)
Не люблю писать комментарии, но тут решила встрять. 1-ое расстраивает полное непонимание системы стандартизации как таковой.
1. Стандарт потому и платный, что он не правила дорожного движения, соблюдать которые положено всем. Это рекомендация – хочешь, пользуйся, а хочешь — нет, твое дело, как в случае применения внутри компании, так и в случае предъявления требований к поставщикам. Короче дело личное. Ну а если ты поставщик, то будешь плясать под дуду заказчика и производитель стандартов тут не при чем. Обязательные стандарты — это директивы там или регламенты у нас, но их настолько мало (в России порядка 20) и к сфере IT они вообще никакого отношения не имеют. Так что можно расслабиться на эту тему.
2. Разочарую — не только за рубежом, но и у нас стандарты разрабатываются не государством, а частными компаниями (комитеты состоят из представителей частных компаний). И именно последние за них платят. Разработка 1 стандарта с нуля стоит организации порядка 2 миллионов рублей, не считая последующей поддержки обновлений. Наше государство само ничего не разрабатывает и денег выделяет только под организационные (процессные) вопросы. Теперь надеюсь понятно почему у нас так мало «свежих» и актуальных гостов и все они как правило — нефть и газ :(
3. Стандарты, во всяком случае зарубежные, разрабатываются группой, в которую входят представители всех заинтересованных сторон, поэтому он не преследует интересы только одной стороны и именно поэтому он и есть соглашение. Количество экспертов, принимающих участие в разработке 1 стандарта, достаточно велико (кстати, их фамилии можно всегда найти или запросить — это открытая как правило информация), в связи с чем стандарт — это сконцентрированный на бумаге опыт работы многих экспертов и многих компаний. Такой опыт самим за короткое время не обрести и не изложить для дальнейшего применения.
2-ое раз уже браться за изучение вопросов написания документации, то подойти к этому надо было как-то шире.
Стандартов на эту тему больше, чем указано. Ко всем приведеным в обсуждения можно добавить стандарты по организацию процесса создания документации, от этого отчасти зависит и качество и полнота — ISO/IEC TR 9294:2005 Information technology — Guidelines for the management of software documentation содержит рекомендуемые стратегии, процедуры, ресурсы и планы, которыми должны заниматься руководители проектов при создании комплекта документов) и
ISO/IEC 15910:1999 Information technology — Software user documentation process — кстати одноименный гост указан в статье — это как раз калька с международного стандарта, правда с заменой многих терминов на вкус переводчика на наши совдеповские, что затрудняет прочтение, поэтому предпочитаю читать в оригинале и вам советую
ISO/IEC TR 12182:1998 Information technology — Categorization of software — здесь можно подчерпнуть под какие типы ПО какие шаблоны документов применимы, т.е. какая структура должна быть у документации вашего ПО
Если вы производите коробочное ПО, то прояснить, что надо писать в этом случае вам поможет ISO 9127:1988 Information processing systems — User documentation and cover information for consumer software packages — старенький, но не потерявший актуальности. И если вы так любите стандарты ISO, то надо ко всем вышеперечисленным еще почитать ISO/IEC 12207:2008 Systems and software engineering — Software life cycle processes, на него ссылаются все ранее указанные стандарты, так как все описанные в них процессы являются частью ЖЦ ПО
Но можно обратиться к другому разработчику — IEEE, у которого не менее богатый набор стандартов:
IEEE 1063-2001 уже указанный является основным, как документ по общим требованиям (минимальным) к пользовательской документации на программные средства широкого применения.
НО еще надо почитать IEEE 829-2008 — IEEE Standard for Software and System Test Documentation, IEEE 730-2002 — IEEE Standard for Software Quality Assurance Plans, IEEE 1012-2004 — IEEE Standard for Software Verification and Validation, IEEE 1028-2008 — IEEE Standard for Software Reviews and Audits и IEEE 830-1998 — IEEE Recommended Practice for Software Requirements Specifications — последние стандарты позволят собрать полную картину по документации.
А есть книга гос. Липаева В.В. ДОКУМЕНТИРОВАНИЕ СЛОЖНЫХ ПРОГРАММНЫХ СРЕДСТВ, которую автор по запросу совершенно официльно отдает в электронном формате. В данной книге есть обзор практически всех указанных стандартов и ряда дополнительных, правда некоторые уже отменены, тем не меннее в ней есть так желаемые всеми шаблоны и рекоммендации и все это в связке со стандартами. Можно начать с нее, потом определиться, какие стандарты вам нужны и покупать только их.
Так что читайте стандарты и применяйте из них только то, что понятно и применимо в вашей компании на вашем уровне развития по принципу разумной достаточности, остальное освоите позже.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Поэтому на практике мы выработали следующий подход: структуру интерфейса, элементы, отклики и пр. создает менеджер плотно работающий с клиентом на проекте. Эти интерфейсы отдаются дизайнеру (в компании есть дизайнер и есть верстальщик, это разные люди), который достаточно быстро стилизует интерфейсы, можно в той же программе. Если интерфейсы приняты и уже не требуют изменений, переходим к реализации — подключению к системе, здесь работает верстальщик и отчасти программист. Что мы выигрываем: время и терпение клиента (а это не мало, особенно на больших проектах), качество интерфейса, собственно время менеджера (как ни странно — объяснять по несколько раз дизайнеру, потом показывать клиенту, потом опят объяснять дизайнеру, потом опять клиент, снова дизайнер, клиент… и т.д. — это значительно больше, чем по указанной выше схеме), общее время, скорость разработки. Кстати про CRM: клиент был очень доволен интерфейсами, и все они были приняты с минимальными корректировками.
Но тем не менее этот вид лицензирования (по ЗАКОНУ) вам потребуется если вы: а) захотите создавать вышеуказанные средства или б) быть владельцем такого средства. Это вопросы безопасности. Стандарт здесь вторичен.
Кстати, если вы просто хотите что-то криптовать, например свои фотографии, то здесь выбирайте любой понравившийся алгоритм криптования.
Мы как раз на данный момент практически закончили для одной компании разработку системы удостоверяющего центра. В качестве средства защиты информации использовался VipNet от компании Инфотекс (имеет лицензию), которое мы встроили в свою систему, осуществляющую организацию самого процесса создания, согласования и подписания документов и их хранения, получили отдельный продукт. Владелец этого продукта также прошел лицензирование в ФАПСИ, так как является держателем сертификатов и предоставляет такой сервис, нам (так как работаем со средствами криптографии как с черным ящиком) такая сертификация не нужна. Сертифицирован должен был быть только отдельный модуль, которым и является VipNet.
Аналогично решается ситуация, когда есть система и надо иметь разрешения и лицензии на хранение например персональных данных. Зачем сертифицировать свою систему (кстати все, что пройдет сертификацию менять нельзя, иначе все надо проходить заново), когда хранение данных можно вынести в отдельный модуль под управлением стороннего сертифицированного ПО и радоваться жизни :) Кстати нам это сами сертифицирующие органы подсказали. Иначе можно разориться так как расчет стоимости такого удовольствия идет в пересчете на строки кода, что в нашем случае по скромным подсчетам составляло порядка 1,5 млн рублей. А если учесть, что мы обновляем наше ПО 4 раза в год, то это нам встанет в 6 млн рублей. А зачем?
Так что дело тут не в стандартах и потом всегда можно найти красивый и правильный выход. Если я не так поняла ваш вопрос, то задайте более конкретный с описанием вашей ситуации, возможно что и подскажу полезного :)
работать нельзя где, или с кем, или в чем? Что значит в криптографии? провайдером или?
Вопрос неточен или даже возможно содержит несколько вопросов. Будьте добры точнее сформулируйте.
1. Стандарт потому и платный, что он не правила дорожного движения, соблюдать которые положено всем. Это рекомендация – хочешь, пользуйся, а хочешь — нет, твое дело, как в случае применения внутри компании, так и в случае предъявления требований к поставщикам. Короче дело личное. Ну а если ты поставщик, то будешь плясать под дуду заказчика и производитель стандартов тут не при чем. Обязательные стандарты — это директивы там или регламенты у нас, но их настолько мало (в России порядка 20) и к сфере IT они вообще никакого отношения не имеют. Так что можно расслабиться на эту тему.
2. Разочарую — не только за рубежом, но и у нас стандарты разрабатываются не государством, а частными компаниями (комитеты состоят из представителей частных компаний). И именно последние за них платят. Разработка 1 стандарта с нуля стоит организации порядка 2 миллионов рублей, не считая последующей поддержки обновлений. Наше государство само ничего не разрабатывает и денег выделяет только под организационные (процессные) вопросы. Теперь надеюсь понятно почему у нас так мало «свежих» и актуальных гостов и все они как правило — нефть и газ :(
3. Стандарты, во всяком случае зарубежные, разрабатываются группой, в которую входят представители всех заинтересованных сторон, поэтому он не преследует интересы только одной стороны и именно поэтому он и есть соглашение. Количество экспертов, принимающих участие в разработке 1 стандарта, достаточно велико (кстати, их фамилии можно всегда найти или запросить — это открытая как правило информация), в связи с чем стандарт — это сконцентрированный на бумаге опыт работы многих экспертов и многих компаний. Такой опыт самим за короткое время не обрести и не изложить для дальнейшего применения.
2-ое раз уже браться за изучение вопросов написания документации, то подойти к этому надо было как-то шире.
Стандартов на эту тему больше, чем указано. Ко всем приведеным в обсуждения можно добавить стандарты по организацию процесса создания документации, от этого отчасти зависит и качество и полнота — ISO/IEC TR 9294:2005 Information technology — Guidelines for the management of software documentation содержит рекомендуемые стратегии, процедуры, ресурсы и планы, которыми должны заниматься руководители проектов при создании комплекта документов) и
ISO/IEC 15910:1999 Information technology — Software user documentation process — кстати одноименный гост указан в статье — это как раз калька с международного стандарта, правда с заменой многих терминов на вкус переводчика на наши совдеповские, что затрудняет прочтение, поэтому предпочитаю читать в оригинале и вам советую
ISO/IEC TR 12182:1998 Information technology — Categorization of software — здесь можно подчерпнуть под какие типы ПО какие шаблоны документов применимы, т.е. какая структура должна быть у документации вашего ПО
Если вы производите коробочное ПО, то прояснить, что надо писать в этом случае вам поможет ISO 9127:1988 Information processing systems — User documentation and cover information for consumer software packages — старенький, но не потерявший актуальности. И если вы так любите стандарты ISO, то надо ко всем вышеперечисленным еще почитать ISO/IEC 12207:2008 Systems and software engineering — Software life cycle processes, на него ссылаются все ранее указанные стандарты, так как все описанные в них процессы являются частью ЖЦ ПО
Но можно обратиться к другому разработчику — IEEE, у которого не менее богатый набор стандартов:
IEEE 1063-2001 уже указанный является основным, как документ по общим требованиям (минимальным) к пользовательской документации на программные средства широкого применения.
НО еще надо почитать IEEE 829-2008 — IEEE Standard for Software and System Test Documentation, IEEE 730-2002 — IEEE Standard for Software Quality Assurance Plans, IEEE 1012-2004 — IEEE Standard for Software Verification and Validation, IEEE 1028-2008 — IEEE Standard for Software Reviews and Audits и IEEE 830-1998 — IEEE Recommended Practice for Software Requirements Specifications — последние стандарты позволят собрать полную картину по документации.
А есть книга гос. Липаева В.В. ДОКУМЕНТИРОВАНИЕ СЛОЖНЫХ ПРОГРАММНЫХ СРЕДСТВ, которую автор по запросу совершенно официльно отдает в электронном формате. В данной книге есть обзор практически всех указанных стандартов и ряда дополнительных, правда некоторые уже отменены, тем не меннее в ней есть так желаемые всеми шаблоны и рекоммендации и все это в связке со стандартами. Можно начать с нее, потом определиться, какие стандарты вам нужны и покупать только их.
Так что читайте стандарты и применяйте из них только то, что понятно и применимо в вашей компании на вашем уровне развития по принципу разумной достаточности, остальное освоите позже.