Рубрика: Документирование и сертификация

Процесс разработки (development process) предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПС и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации; подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т. д.

Подготовительная работа начинается с выбора модели ЖЦ ПС, соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбрать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ.

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

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

ГОСТ 34 — Комплекс стандартов на автоматизированные системы.

Единая система программной документации — комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.

Единая система конструкторской документации — комплекс государственных стандартов, устанавливающих взаимосвязанные правила, требования и нормы по разработке, оформлению и обращению конструкторской документации, разрабатываемой и применяемой на всех стадиях жизненного цикла изделия.

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

Цель процесса поставки заключается в обеспечении приобретающей стороны продукцией или услугой, удовлетворяющей согласованным требованиям.

В результате успешного осуществления процесса поставки:

• определяется приобретающая сторона для продукта или услуги;
• дается ответ на заявку приобретающей стороны;
• заключается соглашение между приобретающей стороной и поставщиком на разработку, сопровождение, применение, упаковку, распределение и инсталляцию продукта и (или) услуги;
• разрабатывается продукт и (или) услуга, удовлетворяющие согласованным требованиям;
• продукт и (или) услуга поставляются приобретающей стороне в соответствии с согласованными условиями поставок и
• продукт инсталлируется в соответствии с согласованными требованиями.

Процесс приобретения (acquisition process) состоит из действий и задач заказчика, приобретающего программное средство.

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

В результате успешного осуществления процесса приобретения:

• определяются потребности в приобретении, конечные цели, критерии приемки продукта и (или) услуги и стратегии приобретения;
• разрабатывается соглашение, которое ясно выражает ожидания, ответственность и обязательства как приобретающей стороны, так и поставщика;
• выбирается один или несколько поставщиков;
• приобретается продукт и (или) услуга, которые удовлетворяют заданным потребностям приобретающей стороны;
• приобретение контролируется таким образом, чтобы удовлетворялись заданные ограничения, такие как, например, ограничения по стоимости, срокам и качеству;
• принимаются продукты и (или) услуги от поставщиков;
• по всем идентифицированным открытым позициям получены удовлетворительные заключения, согласованные приобретающей стороной и поставщиком.

Жизненный цикл (life cycle) — развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения.

Программный продукт (software product) — совокупность компьютерных программ, процедур и, возможно, связанных с ними документации и данных.

Процесс (process) — совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы и выходы.

Состав процесса:

• наименование – передает область применения процесса как целого;
• цель – описывает конечные цели выполнения процесса;
• выходы – представляют собой наблюдаемые результаты, ожидаемые при успешном выполнении процесса.

Классификация процессов:

• соглашения (приобретение + поставка);
• организационного обеспечения проекта (модель ЖЦ + инфраструктура + портфель проекта + людские ресурсы + качество);
• проекта (планирование + оценка проекта + решения + риски + конфигурации + информация + измерения);
• технические (требования правообладателей + анализ системных требований + архитектура системы + реализация + комплексирование системы + тестирование системы + инсталляция программных средств (ПС) + приемка ПС + функционирования ПС + сопровождение ПС + прекращение прим. ПС);
• реализации программных средств (реализация + требования + проектирование архитектуры + детальное проектирование ПС + конструирование ПС + комплексирование ПС + тестирование ПС);
• поддержка программных средств (программная документация + конфигурация + гарантии качества ПС + верификация ПС (подтверждение соответствия) + валидация ПС (подтверждение путем экспертизы) + ревизия + аудит (проверка финансовой деятельности) + решение проблем в ПС);
• повторное применение программных средств (проектирование доменов + повторное применение программ + повторное применение активов).

Создание программной документации — важный этап, так как пользователь начинает свое знакомство с программным продуктом именно с документации. Для чего предназначен программный продукт, как установить программный продукт, как начать с ним работать — вот одни из первых вопросов, на которые должна отвечать программная документация (Installation Guide, Getting Started). Составлением программной документации обычно занимаются специальные люди — технические писатели (иногда программную документацию пишут сами программисты или аналитики). Этот этап является самым неприятным и тяжелым в программистской работе. К сожалению, обычно этому либо не учат совсем, либо в лучшем случае не обращают на качество получаемых документов должного внимания. Тем не менее владение этим искусством является одним из важнейших факторов, определяющих качество программиста.

Умение создавать программную документацию определяет профессиональный уровень программиста. Заказчик не будет вникать в тонкости и особенности даже самой замечательной программы. Заказчик будет сначала читать документацию. Большую роль играет в этом и психологический фактор.

Грамотно составленный (точнее, созданный) пакет программной документации избавит вас от многих неприятностей. В частности, избавиться от назойливых вопросов и необоснованных претензий можно, просто отослав пользователя к документации. Это касается прежде всего важнейшего документа — Технического задания. Можно напомнить о многомиллионном иске к компании IBM, который предъявило одно крупноеиздательство, не удовлетворенное качеством вычислительной техники и программного обеспечения. IBM суд выиграла только благодаря тому, что предъявила подписанное обеими сторонами Техническое задание. Было это давно, еще в 70-х годах 20 века, однако сути дела это не меняет. На Западе важность программной документации поняли давно, вместе с программным обеспечением поставляется целый пакет документации.

Вообще программную документацию можно разделить по отношению к пользователю на внутреннюю и внешнюю.

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

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы:

• Что должно быть сделано, кроме собственно программы?
• Что и как должно быть оформлено в виде документации?
• Что передавать пользователям, а что — службе сопровождения?
• Как управлять всем этим процессом?
• Что должно входить в само задание на программирование?

На эти и другие вопросы когда-то отвечали государственные стандарты на программную документацию — комплекс стандартов 19-й серии ГОСТ ЕСПД.

Но уже тогда у программистов была масса претензий к этим стандартам. Что-то требовалось дублировать в документации много раз (как оказалось — неоправданно), а многое не было предусмотрено, как, например, отражение специфики документирования программ, работающих с интегрированной базой данных.

Прошло много лет, программирование происходит в среде совершенно новых технологий, многие программисты, работая в стиле drag-and-drop, могут годами не видеть текстов своих программ. Это не значит, что исчезла необходимость в их документировании. Вопросы о наличии хоть какой-то системы, регламентирующей эту сторону создания программных средств, продолжают задавать постоянно.

Это вообще разные понятия. Очень очень краткий ответ за этот вопрос:

Спецификация — это документ.

Стандартизация — это правила.