Ћекции.ќрг


ѕоиск:




 атегории:

јстрономи€
Ѕиологи€
√еографи€
ƒругие €зыки
»нтернет
»нформатика
»стори€
 ультура
Ћитература
Ћогика
ћатематика
ћедицина
ћеханика
ќхрана труда
ѕедагогика
ѕолитика
ѕраво
ѕсихологи€
–елиги€
–иторика
—оциологи€
—порт
—троительство
“ехнологи€
“ранспорт
‘изика
‘илософи€
‘инансы
’ими€
Ёкологи€
Ёкономика
Ёлектроника

 

 

 

 


“ребовани€ к продукту и процессу. ƒл€ студентов гр. ј—” 4-го курса.




Ћекци€ 3.

ƒл€ студентов гр. ј—” 4-го курса.

ѕредмет: –азработка и эксплуатаци€ ј»—.

“ема: “ребовани€ в задаче внедрени€ ј»—.

÷ель: –азобратьс€ в особенност€х требований в задаче внедрени€ ј»—.

«адачи:

1. ѕрочитать, кратко законспектировать лекцию.

2. —оставить 20 (или более) вопросов к лекции по основным моментам, и на них же самосто€тельно ответить.

3. —делать выводы.

4.ќтправить вопросы с ответами в электронном варианте преподавателю.

–оль требований в задаче внедрени€ ј»—

 акие можно сделать выводы из рассмотренной классификации ј»—? ƒаже не говор€ о многообразии производителей ј»—, не рассмотренного в насто€щей лекции, на основании только сформулированных признаков становитс€ очевидным, что существует значительное количество ј»— и данные ј»— существенно различаютс€ между собой. —ледовательно, выбор ј»— дл€ предпри€ти€ - достаточно нетривиальна€ задача. ƒл€ того, чтобы успешно ее решить, необходимо хорошо знать объект внедрени€ (автоматизируемое предпри€тие), особенности его де€тельности, стратегию развити€ и многие другие аспекты, предопредел€ющие характеристики закупаемой ј»—. ”казанные знани€ в конечном итоге формализуютс€ в документе требований к ј»—, на основе которого и осуществл€етс€ выбор и последующа€ настройка ј»—. ¬ еще большей степени требовани€ к ј»— важны при разработке ј»— на заказ. ѕодробнее об этом - в следующих лекци€х.

ќпределение пон€ти€ требовани€

Ћ.Ќовиков в русской редакции нотации RUP приводит следующее определение: "“ребование - это условие или возможность, которой должна соответствовать система".

¬ IEEE Standard Glossary of Software Engineering Terminology (1990) данное пон€тие трактуетс€ шире. “ребование - это:

1. услови€ или возможности, необходимые пользователю дл€ решени€ проблем или достижени€ целей;

2. услови€ или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетвор€ть стандартам, спецификаци€м или другим формальным документам;

3. документированное представление условий или возможностей дл€ пунктов 1 и 2.

¬ведем еще одно определение. “ребовани€ - это исходные данные, на основании которых проектируютс€ и создаютс€ автоматизированные информационные системы. ѕервичные данные поступают из различных источников, характеризуютс€ противоречивостью, неполнотой, нечеткостью, изменчивостью. “ребовани€ нужны в частности дл€ того, чтобы –азработчик мог определить и согласовать с «аказчиком временные и финансовые перспективы проекта автоматизации. ѕоэтому значительна€ часть требований должна быть собрана и обработана на ранних этапах создани€ ј»—. ќднако собрать на ранних стади€х все данные, необходимые дл€ реализации ј»—, удаетс€ только в исключительных случа€х. Ќа практике процесс сбора, анализа и обработки раст€нут во времени на прот€жении всего жизненного цикла ј»—, зачастую нетривиален и содержит множество подводных камней; подробнее о процессе - в лекци€х 4 - 8.

 лассификаци€ требований

—уществует значительное количество различных методов классификации требований, наиболее существенные из которых будут рассмотрены в лекции.

“ребовани€ к продукту и процессу

“ребовани€ к продукту. ¬ своей основе требовани€ - это то, что формулирует заказчик. ÷ель, которую он преследует - получить хороший конечный продукт: функциональный и удобный в использовании. ѕоэтому требовани€ к продукту €вл€ютс€ основополагающим классом требований. Ѕолее подробно требовани€ к продукту детализируютс€ в следующих ниже классификаци€х.

“ребовани€ к проекту. ¬опросы формулировани€ требований к проекту, т.е. к тому, как –азработчик будет выполн€ть работы по созданию целевой системы, казалось бы, не лежат в компетенции «аказчика. Ѕез регламентации процесса «аказчиком легко можно было бы обойтись, если бы все проекты всегда выполн€лись точно и в срок. ќднако, к сожалению, мирова€ статистика результатов программных проектов говорит об обратном. «аказчик, вступа€ в договорные отношени€ с –азработчиком, несет различные риски, главными из которых €вл€етс€ риск получить продукт с опозданием, либо ненадлежащего качества. ќсновные меропри€ти€ по контролю и снижению риска - регламентаци€ процесса создани€ программного обеспечени€ и его аудит.

Ќасколько подробно «аказчику следует регламентировать требовани€ к проекту - вопрос риторический. ќтвет на него зависит от множества факторов, таких, как ценность конечного продукта дл€ «аказчика, степень довери€ «аказчика к –азработчику, сумма подписанного контракта, ув€зка срока сдачи продукта в эксплуатацию с бизнес-планами «аказчика и т.д. ќднако, со всей определенностью можно сказать следующее:

1. регламентаци€ процесса «аказчиком позвол€ет снизить его риски;

2. меропри€ти€ «аказчика по регламентации процесса привод€т к дополнительным накладным расходам. “ребуетс€ найти разумный компромисс между степенью контрол€ рисков и величиной расходов.

¬ качестве требований к проекту могут быть внесен регламент отчетов –азработчика, совместных семинаров по оценке промежуточных результатов, определены характеристики компетенций участников рабочей группы, исполн€ющих проект, их количество, указана методологи€ управлени€ проектом. Ќиже сформулирован пример формулировки требовани€ к оффшорному проекту («аказчик и –азработчик физически наход€тс€ в разных государствах) - в этой ситуации «аказчику требуетс€ жесткий контроль над –азработчиком.

1. –азработчик представл€ет «аказчику согласованный план работ c детализацией (WorkBreakdownStructure - WBS) с точностью до конкретных исполнителей.

2. –азработчик осуществл€ет ежедневные сборки, регрессионное тестирование компонент разрабатываемого продукта и тестирование продукта в целом.

3. ¬се управленческие и проектные артефакты, исходные коды и тестовые примеры размещаютс€ в режиме online в интегрированной среде разработки Rational ClearCase с возможностью дл€ «аказчика осуществлени€ online-мониторинга на базе web-технологий.

”ровни требований

¬недрение »— на предпри€тии всегда преследует конкретные бизнес-цели - такие, как, например, повышение прозрачности бизнеса, сокращение сроков обработки информации, экономи€ накладных расходов и т.д. —овременные информационные системы - это крупные программные системы, содержащие в себе множество модулей, функциональных, интерфейсных элементов, отчетов и т.д.  ак охватить единым взором такие разнородные вещи, как цели, преследуемые топ-менеджером предпри€ти€ «аказчика, описание интерфейса пользовател€ и характеристики модул€, осуществл€ющего расчет себестоимости издели€?

  счастью, человечество уже давно изобрело приемы борьбы со сложностью, широко примен€емые в моделировании сложных объектов - абстракцию и декомпозицию. ѕрименительно к дисциплине анализа требований к программным системам эти принципы работают следующим образом. “ребовани€ раздел€ютс€ по уровн€м. ”ровни требований св€заны, с одной стороны, с уровнем абстракции системы, с другой - с уровнем управлени€ на предпри€тии.

ќбычно выдел€ют три уровн€ требований.

Ј Ќа верхнем уровне представлены так называемые бизнес-требовани€ (business requirements). ѕримеры бизнес-требовани€: система должна сократить срок оборачиваемости обрабатываемых на предпри€тии заказов в три раза. Ѕизнес-требовани€ обычно формулируютс€ топ-менеджерами, либо акционерами предпри€ти€.

Ј —ледующий уровень - уровень требований пользователей (user requirements). ѕример требовани€ пользовател€: система должна представл€ть диалоговые средства дл€ ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. “ребовани€ пользователей часто бывают плохо структурированными, дублирующимис€, противоречивыми. ѕоэтому дл€ создани€ системы важен третий уровень, в котором осуществл€етс€ формализаци€ требований.

Ј “ретий уровень - функциональный (functional requirements). ѕример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

—уществуют объективные противоречи€ между требовани€ми различных уровней. “ак, очевидным бизнес-требованием €вл€етс€ требование о полноте информации, собираемой на рабочих местах пользователей в единую базу данных. „ем полнее информаци€ - тем глубже база дл€ анализа де€тельности и прин€ти€ решений. — другой стороны, конкретному пользователю системы вполне может быть достаточно использовани€ только той части информации, котора€ вли€ет на выполнение его основных функций.

¬ажные правила внедрени€ и использовани€ ј»— на предпри€тии - "ќдна точка сбора", "ƒанные собираютс€ там, где они по€вл€ютс€". »спользование этих правил позвол€ет избежать затрат на необоснованное дублирование информации и, что важнее - потерь от ошибок учета, неизбежно возникающих при дублировании точек ввода.

¬недрение ј»— на предпри€тии приводит к необходимости оснащени€ всех точек ввода информации автоматизированными рабочими местами (ј–ћ), обучению персонала и, зачастую, оптимизации и повышению уровн€ формализации рабочих процессов, выполн€емых персоналом. ѕоэтому внедрение ј»— - непростой процесс, часто требующий "перекройки человеческого материала" и встречающий сопротивление со стороны пользователей, которые не готовы, либо не хот€т работать по-новому.





ѕоделитьс€ с друзь€ми:


ƒата добавлени€: 2016-12-17; ћы поможем в написании ваших работ!; просмотров: 508 | Ќарушение авторских прав


ѕоиск на сайте:

Ћучшие изречени€:

—вобода ничего не стоит, если она не включает в себ€ свободу ошибатьс€. © ћахатма √анди
==> читать все изречени€...

628 - | 571 -


© 2015-2024 lektsii.org -  онтакты - ѕоследнее добавление

√ен: 0.013 с.