Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Анализ требований к продукту

Читайте также:
  1. I Рамочная проблемно-ориентированную методика анализа и решения организационно-экономических задач
  2. I. Анализ воспитательной работы за прошлый год
  3. I. Анализ инженерно-геологических условий площадки строительства
  4. II Когнитивный анализ
  5. II. ИЗУЧЕНИЕ ЛИТЕРАТУРЫ, ЕЕ АНАЛИЗ И СОСТАВЛЕНИЕ БИБЛИОГРАФИЧЕСКОГО СПИСКА
  6. II. Комплексный анализ эпического произведения
  7. III Когнитивная структуризация знаний об объекте и внешней среде на основе PEST-анализа и SWOT-анализа

Предисловие

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

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

Действия в процессе разработки программного обеспечения

Анализ требований к продукту

Самая важная задача при создании программного продукта — это выработка требований, или анализ требований к продукту. Заказчик чаще всего представляет весьма размытую идею о том, каким должен быть конечный результат, и не имеет представления о том, как должна работать программа. Незаконченные, нелепые, а иногда противоречащие друг другу требования распознаются хорошими инженерами на этой стадии. Частая демонстрация живого кода может уменьшить риск того, что начальные требования были не верны. Один из методов нахождения проблем такого рода — это анализ элементов программного обеспечения.

Когда общие требования получены от клиента, их необходимо уточнить и отобразить в документе. Реализованная функциональность может отличаться от определённой, в результате высокой стоимости разработки и/или непонятных требованиях к продукту. Если разработка проводится вне фирмы заказчика, то данный документ может использоваться для разрешения споров связанных с функциональностью продукта.

Анализ области работы часто является первой ступенью лестницы проектирования нового фрагмента программного обеспечения, вне зависимости от того, является ли он добавлением к уже существующему приложению или новым приложением, подсистемой или совершенно новой системой. Принимая, что разработчики (так же как и аналитик) не являются в начале достаточно образованными в области знаний нового программного обеспечения, первая задача — это собственно исследование этой самой области знаний. Чем лучше разработчики знают область, в которой работают, тем меньше потом возникает работы. Также её проводят для того, чтобы позже не появлялось путаницы в терминологии и понимании того, что делает эта программа. Если аналитик использует неверную терминологию, то опять же возможны недопонимания, в результате того, что программа будет делать не то, что нужно.


Дата добавления: 2015-07-19; просмотров: 67 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
Решение.| Распространение и поддержка

mybiblioteka.su - 2015-2024 год. (0.006 сек.)