Выбор между покупкой и разработкой ИС

На сегодняшний день ни одна из стандартных ИС, ERP систем не обходится без дополнительной доработки под соответствующего заказчика. Тем не мене и в таком случае она дешевле. Технологически прозрачнее ми проще во внедрении и поддержке, чем сопоставимая по масштабам система, разработанная самостоятельно. Просто в одних случаях готовое решение достаточно лишь слегка подкорректировать, а в других требуются значительные изменения. Однако. Если бизнес компании нетипичен для тиражируемых ИС, то стоимость доработок может существенно превысить стоимость разработки своими силами.

В процессе выбора между покупкой и разработкой заказчик проходит 4 этапа:

1. Анализ бизнес- процессов к5омпании «как есть». (для получения ответа на вопрос: какие БП существуют в компании на данный момент)

2. Проектирование БП «как надо»(цель: понять, какими заказчик хочет видеть БП после оптимизации, т.е. что он получит на выходе)

3. Выработка требований к системе, которая будет автоматизировать БП «как надо»

4. Выбор поставщика (разработчика) ПО

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

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

4.Организация анализа требований к информационной системе (перепечатать)

Свойства требований:

Однако, в практике разработки программных систем накопились определённые представления о том, какими свойствами должны обладать требования к программной системе. Это:

 полнота;

 ясность;

 корректность;

 согласованность;

 верифицируемость;

 необходимость;

 полезность при эксплуатации;

 осуществимость;

 модифицируемость;

 трассируемость;

 упорядоченность по важности и стабильности;

 наличие количественной метрики.

Полнота. Как известно из теории искусственного интеллекта, неполнота – одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками ещё несуществующей системы. Надо понимать, что свойство полноты – это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта. Свойство полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований. Полнота отдельного требования – свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нём предусмотрены все необходимые нюансы, особенности и детали данного требования. Полнота системы требований – свойство, которое означает, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает всё то, что требуется от разрабатываемой системы.

Ясность (недвусмысленность, определённость, однозначность спецификаций). Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается, в том числе, и в процессе консультаций, в ходе которых происходит «выравнивание тезаурусов» совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.

Корректность и согласованность (непротиворечивость). Корректность – одно из важнейших свойств требований. К. Вигерс в [2] вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определённой степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер (абсолютная полнота представляет недостижимый идеал, к которому можно приближаться), то свойство корректности носит оценочный характер и задаёт дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит – как минимум одно из них некорректно. В иерархии требований (см. материалы лекции 2) можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям «родительского» уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования – требованиям пользователя.

Верифицируемост. Так, свойство верифицируемости существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемым участниками процесса создания информационной системы, причём оно является полным, т.е. ни одна из важных для реализации деталей не упущена, – значит, это требование можно проверить. При этом в ходе проверки у сторон (принимающей и сдающей работу) не должно возникнуть неразрешимых противоречий в оценках. Методы верификации требований будут рассмотрены в 12-Проверка требований. Так как хорошо сформулированные требования составляют основу успешного создания системы – роль верифицируемости трудно переоценить. Требования к системе представляют основу контракта между Заказчиком и Исполнителем, и если данные требования нельзя проверить – значит, и контракт не имеет никакого смысла, следовательно, успех или неудача проекта будут зависеть только от эмоциональных оценок сторон и их способности договориться, а это – слишком шаткая основа для осуществления работ.

Необходимость и полезность при эксплуатации. Одни из самых субъективных и трудно проверяемых свойств требований. Данные требования формулируют первые лица, представляющие Заказчика, и вряд ли кто-нибудь лучше них сможет сказать, каким условиям должна соответствовать создаваемая информационная система, чтобы соответствовать бизнес-целям предприятия. Тем не менее, если у представителя Исполнителя возникают сомнения в необходимости того или иного бизнес-требования, вызванные интуитивными соображениями либо опытом внедрения информационных систем на аналогичных предприятиях, он должен проявить инициативу и собрать совместное совещание сторон. Необходимость требований пользователя может вытекать из соответствующих бизнес- требований. Кроме того, требования пользователя могут мотивироваться эргономичностью продукта и особенностями функционирования его отдела (подразделения), недостаточно полно раскрытыми на предыдущем уровне иерархии требований. Большинство функциональных требований вытекают из требований первых двух уровней. Другие функциональные требования могут лежать вне сферы компетенции Заказчика (который, вообще говоря, не обязан быть экспертом в области IT), и их должен сформулировать Исполнитель. Более слабой, чем «необходимость», формулировкой обладает свойство «полезность при эксплуатации». Разграничение между данными свойствами можно провести следующим образом. Необходимыми следует считать свойства, без выполнения которых невозможно либо затруднено выполнение автоматизированных бизнес-функций пользователей; полезными при эксплуатации следует считать любые свойства, повышающие эргономические качества продукта.

Осуществимость (выполнимость). В принципе никто не мешает сформулировать требование, выполнимость которого ограничивается сегодняшним уровнем развития техники и технологии, хотя многое из того, что было невыполнимо десять лет назад, вполне выполнимо сегодня. С точки зрения науки управления требованиями, далеко не все из них являются осуществимыми. Выполнимость требования на практике определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами. Так, если стоимость контракта на разработку информационной системы составляет $10000, а затраты на выполнение нового требования, возникшее в момент, когда проект выполнен наполовину, оцениваются в $4000, является ли оно невыполнимым? Скорее всего, да, если Исполнитель докажет Заказчику новизну требования (требование не входило в согласованные спецификации) и сложность его исполнения. Но, если требование является критически важным, необходимым, но выпало из поля зрения при подписании контракта, и Заказчик готов выделить дополнительно финансирование, а Исполнитель – трудовые ресурсы, – значит, требование выполнимо. Таким образом, требование осуществимости в ряде случаев также следует считать субъективным, а критерии его оценки лежат в области договорённостей между Заказчиком и Исполнителем. Модификация спецификации станет гораздо легче, если вы составите содержание документа и указатель. Сохранение спецификации в базе данных коммерческого инструмента управления требованиями сделает их пригодными для повторного использования (конец цитаты).

Трассируемость. Трассируемость требования определяется возможностью отследить связь между ним и другими артефактами информационной системы (документами, моделями, текстами программ и пр.). Отдельная траса представляет собой направленное бинарное отношение, заданное на множестве артефактов ИС, где первый элемент отношения представляет соответствующее требование, а второй – артефакт, зависимый от данного требования. На практике трассировки анализируются при посредстве графовых либо табличных моделей. Процесс трассировки позволяет, с одной стороны, выявить уже на стадии проектирования системы проектные артефакты, к которым не ведёт связь ни от одного из артефактов, описывающих TT3 1 Tтребования, с другой – артефакты, которые описывают требования, не связанные с проектными артефактами. Другая цель трассировки – повысить управляемость проектом: при изменении отдельно взятого требования становится понятно, какие из проектных, рабочих и других артефактов подлежат изменению.

⇐ Предыдущая45678910111213Следующая ⇒

Поделиться: