13. Экономическая целесообразность разработки системы

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

- организовать обмен пользователями справочной информацией по разработке программного обеспечения в рамках локальной сети отдельно взятого предприятия.

При этом экономическую целесообразность и эффективность разработанной системы можно проиллюстрировать следующими цифрами:

Экономия финансовых и временных ресурсов на поиск необходимой информации по разработке программного обеспечения на 70%;

Увеличение повторного использования программного кода в проектах Заказчика и связанное с этим снижение себестоимости на 20-30%.

14. Сбор требований к разрабатываемой системе, выявление основных групп пользователей системы

На этапе анализа формировались требования к системе. Это происходило согласно следующему порядку.

Сначала выявлялись цели создания системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у команды, как исполнителей, не будет возможности контролировать соответствие разработанной системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;

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

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

Возвращаясь, к роли аналитиков при согласовании требований к системе EBIS, перечислим основные моменты, с которыми приходилось столкнуться:

1. Сформулировать требования заказчика понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований.

2. В некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика;

3. Проанализировать влияния новых требований на существующую архитектуру и функционал;

4. Задокументировать требования в виде документа или набора документов в требуемом виде. Затем согласовать их и утвердить.

5. Осуществлять верхнеуровневый контроль соответствия реализованного функционала требованиям;

6. Управлять изменениями требований;

7. Осуществлять все взаимодействие с заказчиками по вопросам требований;

Требования к системе, а также основные группы пользователей описаны в разделе 4.1 Технического Задания на систему EBIS.

15. Анализ рисков проекта, описание мер уменьшения их влияния на результат выполнения проекта

16. Описание угроз и возможностей, которые могут возникнуть в процессе работы над проектом

В ходе выполнения программного проекта могут возникнуть угрозы и возможности. К угрозам относятся следующие ситуации:

1. Необоснованная задержка согласования требований. Причина: несогласованные действия заказчика и исполнителя. Последствия: задержка начала разработки программного обеспечения.

15. Плохо определенные требования к проекту. Причина: несогласованные действия заказчика и исполнителя. Последствия: неверное функционирование продукта, увеличение сроков разработки в связи с коррекцией требований.

16. Непредсказуемое изменение/расширение требований со стороны заказчика. Причина: изменение внешних факторов на стороне заказчика. Последствия: увеличение сроков разработки.

17. Обнаружение ошибки в оценках трудоемкости. Причина: недостаточная квалификация людей, предоставляющих оценки или оценки на основе неточных данных. Последствия: увеличение сроков разработки.

18. Болезни, внеочередные отпуска, свадьбы, беременность, отгулы и пр. Причина: личная жизнь, здоровье сотрудников и иные обстоятельства. Последствия: увеличение сроков разработки или провал проекта.

19. Распад команды разработки. Причина: конфликты на стороне исполнителя. Последствия: провал проекта.

20. Отвлечение сотрудников от текущего проекта к работам с других проектов. Причина: нехватка времени на другие проекты. Последствия: увеличение сроков разработки или провал проекта.

21. Низкая продуктивность на ранних этапах. Причина: «синдром студента» - наличие впереди длительных сроков и отсутствие чувства срочности в работе. Последствия: потеря времени в начале проекта и увеличение сроков разработки.

22. Ненужная оптимизация и оттачивание деталей. Причина: перфекционизм разработчиков. Последствия: увеличение сроков разработки, неверное функционирование продукта.

23. Потеря исходных кодов проекта. Причина: технические сбои или квалификация персонала. Последствия: увеличение сроков разработки или провал проекта.

24. Продукт не прошел приемку у заказчика. Причина: неверное функционирование или неготовность продукта. Последствия: увеличение сроков разработки или провал проекта.

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

К возможностям можно отнести следующие риски:

1. Повторное использование кода. Причина: наработки разработчиков в похожих проектах и иные источники. Последствия: сокращение сроков разработки.

26. Помощь сторонних людей. Причина: желание третьих лиц поделиться опытом. Последствия: сокращение сроков разработки.