Что такое кейс и зачем им нужно управлять
Слово кейс (от англ. case) означает случай, дело. В деловой лексике к понятию «кейс» принято относить описание конкретной ситуации и способа ее разрешения, включая описание исходной ситуации, решения и пути выбранные участниками, их действия, материалы, относящиеся к делу, ну и конечно, полученный результат. На кейсах давно тренируют студентов бизнес-школ, разбирая их и моделируя разные сценарии развития ситуаций.
Задачи, возникающие в нашей жизни, могут быть условно разделены на определенные (сразу точно извесно, что они из себя представляют и что с ними делать) и неопределенные (на старте не достаточно информации, чтобы точно определить как их решать). Определенные задачи часто описаны должностными инструкциями, к ним есть карты процессов и регламенты. Это – часто повторяющиеся ситуации, для которых шаблон поведения описан и он легко может быть запрограммирован в информационной системе. Но как только ситуация не вписывается в шаблон – возникает неопределенная ситуация или кейс. Необходимо анализировать, принимать решения, делать выбор, конструировать новый шаблон. Вот этот процесс и называется управлением кейсами.
Кейсы тоже могут повторяемыми или похожими. В этом случае, на основе уже решенного кейса создается шаблон кейса, который может быть использован многократно, как основа для решения новых, похожих ситуаций. При этом, конечно, этот шаблон может быть изменен, улучшен, дополнен. Когда система позволяет учиться на прошлых ситуациях и формировать “лучшие практики”, такая система управления кейсами называется адаптивной.
Термин адаптивный кейс-менеджмент (Adaptive Case Management, ACM) был впервые предложен в 2010 году Workflow Management Coalition. АСМ – это технология, позволяющая гибко управлять процессом решения поставленной задачи, в зависимости от развития ситуации.
Кейс в ACM — это некое «дело», куда «подшивается» вся информация о задаче – участники кейса (люди), материалы (документы, видео/аудио/фото, схемы и чертежи, показатели и др.), обсуждения задач кейса, бизнес-процессы, которые выполнялись в ходе решения задачи, а также, взаимосвязи всех этих элементов.
Немного истории
Кейс, собственно, когда-то и был просто папкой, содержащей всю информацию относящуюся к конкретному случаю.
С развитием технологии, на рынке стали появляться информационные системы, поддерживающие ACM и объединяющие возможности систем различных типов – управления бизнес-процессами (Business Process Management, BPM) и управления корпоративным контентом (Enterprise Content Management, ECM).
Появились шаблоны (наиболее удачные решения), управление правами доступа (владелец кейса может определять кто и в каком качестве подключится к задачам и данным кейса. Из BPM-систем пришли задачи (процессы), которые можно назначать участникам, прикрепив необходимый контент (указав ссылку на место его хранения), а затем проконтролировать результат. Системы управления корпоративным контентом (ECM) дали мощные инструменты работы с большими объемами неструктурированной информации, возможность классифицировать контент, отслеживать версии документов, разграничивать права доступа и журналировать события.
Сегодня ACM системы стоят на стыке классических корпоративных приложений:
Помимо этого, АСМ привносит в корпоративные системы элементы социальных сетей, где каждый может легко создавать свои страницы и управлять ими без помощи администраторов или программистов. Теперь каждый может создавать свои процессы прямо на ходу, определять состав команды, имеющей доступ к задаче или проекту, назначать роли, вводить свои правила.
В чем преимущества
АСМ ставит в центр событий самого человека, давая ему возможность и право решать, как будет развиваться каждый кейс.
Если раньше считалось, что неформализованные бизнес-процессы автоматизировать невозможно, то теперь концепция ACM опровергает это.
Еще одна прелесть адаптивного кейс-менеджмента заключается в том, что теперь можно здорово сэкономить на аналитиках и разработчиках, решая задачу автоматизации своих процессов. Теперь вы сами адаптируете свою систему (прежде всего – бизнес-процессы) к изменениям внешней и внутренней среды.
Как это работает
Как только ситуация начинает принимать «кейсовый оборот» (вы видите, что описанные, жесткие бизнес-процессы вам не помогут), начинается следующий жизненный цикл:
Фазы 3 и 4 (исследование и исполнение) могут многократно повторяться циклически, если неопределенность велика и за одну итерацию не виден финальный результат. Также, кейсы могут порождать дочерние кейсы, выстраиваясь в иерархию.
Как понять что перед нами – кейс?
Все ли неструктурироанные задачи являются кейсами? Нет. Оформлять в виде кейса имеет смысл только ту ситуацию, решение которй имеет практический смысл, полезный для кого-либо в дальнейшем.
Признаки кейса:
1. Объект управления – проблема (задача), а не процесс;
2. Объединяет участников, бизнес-процессы, контент;
3. В ходе исполнения происходят (или вероятны) изменения процессов, подзадач, участников;
4. Высокий уровень неопределенности задач, недостаточно информации на старте;
5. В ходе выполнения происходит накопление полезных и применимых в дальнейшем знаний (история решений, лучшие практики, шаблоны), эти знания и информацию можно передать другим.
Как выглядит современная ACM-система
Из сказанного, в общем, становится понятно что должна уметь ACM сегодня:
• Объединять контент, участников и бизнес-процессы в новую сущность – кейс. Органично интегрироваться в BPM и ECM системы;
• Управлять пользователями – участниками кейса, их правами и ролями;
• Уведомлять о событиях кейса, иметь инструменты коммуникации команды;
• Хранить связи, последовательность и результаты выполнения задач, историю кейса, журналировать все события;
• Иметь развитую систему тегирования, поиска, фильтров;
• Уметь искать, создавать, сохранять, использовать, изменять шаблоны кейсов.
Существует мнение, что наличие ACM-функционала в информационной системе свидетельствует о высокой зрелости системы.
Где можно применить
ACM сегодня начинает активно применяться в следующих областях:
• Оказание сложных услуг: обработка обращений граждан, ведение клиентских дел (досье), оказание юридических, финансвых, информационных, медицинских услуг и др.;
• Управление проектами: целевые программы, стройка, НИОКРы, разработка сложных продуктов, проведение маркетинговых кампаний;
• Специализированная деятельность: судебные дела, законотворчество, общественные инициативы и т.д.
ACM, как уже ясно из сказанного, идеально подходит для тех организаций, где нет четких регламентов, где формализация процессов затруднена по ряду причин (частые изменения, нет ресурсов и др.). В этом случае, ACM может не только помочь в текущей работе, но и стать тем инструментом, который позволит лучше разобраться в собственных процессах, выделить те, которые поддаются формализации, обеспечить постоянные улучшения.
Это, конечно, не исчерпывающий перечень. Посмотрите вокруг себя и вы найдете кейсы, с которыми сталкиваетесь ежедневно.
CASE-технологии
CASE-техноло́гии [Разработка программного обеспечения при помощи компьютеров; от англ. Сomputer Aided Software Engineering – CASE], методы и инструментальные программные средства, программные инструменты для разработки программного обеспечения (ПО). CASE-технологии по своему назначению аналогичны инструментам автоматизированного проектирования , которые используются для проектирования микропроцессоров , только CASE-технологии используются для проектирования и разработки программных систем. CASE-технологии призваны повышать производительность разработчиков и способствовать повышению надёжности , упрощению модернизации и сопровождения созданных при помощи CASE-технологий программных систем. CASE-технологии часто связывают со средствами разработки информационных систем , имеющих в своём составе базы данных , хотя спектр типов программного обеспечения, для которых создаются и используются CASE-технологии, значительно шире.
В англоязычной литературе термин «CASE» используется без второй части «-технологии». Возможно, это связано с различием значений термина «технология» в русском и английском языках. В русском языке под программной технологией понимается процесс, построенный на определённой концепции (методологии) и поддержанный программными инструментами. В англоязычной литературе технологией часто называют конкретный программный продукт, обычно обеспечивающий инфраструктурные функции, или, как говорят, платформу. Примером такой технологии является .Net – технология, которая предоставляет поддержку времени исполнения (англ. run-time support) для программных продуктов, разработанных, например, на C# или Visual Basic.
CASE-средством называется некоторый программный продукт (комплекс инструментов), поддерживающий некоторую CASE-технологию. Так, имеется широкий набор CASE-средств для поддержки CASE-технологий объектно-ориентированной разработки программ на основе унифицированного языка моделирования (англ. Unified Modeling Language – UML). В состав CASE-средства может входить несколько различных инструментов, например графический редактор и генератор программ на каком-либо языке программирования или генератор тестов. Вместе с тем нередко само CASE-средство называется инструментом (англ. CASE tool).
История появления CASE-технологий
Одним из первых CASE-средств называют комплекс программ для проектирования и оптимизации информационных систем (англ. ISDOS), работа над которым началась в 1968 г. в Мичиганском университете , хотя термина «CASE» в то время ещё не было. Уже в начале 1990 г. ( PC Magazine. 1990 ) более 100 компаний предлагали почти 200 различных CASE-средств. В СССР CASE-технологии в основном разрабатывались для систем реального времени и встроенных систем. Прообразами CASE-средств были специализированные комплексы разработки и интеграции программ, которые создавались в интересах военно-промышленного комплекса, например система автоматизированной разработки ПО ПРОТВА.
Можно назвать следующие виды ПО, для разработки которого уже первые CASE-средства были успешно внедрены в практику:
системы реального времени – Statemate/IBM Rational Raphsody (iLogix, IBM), SCADE (Telelogic, Esterel Technology, Ansys), Rational Rose RealTime Edition (IBM), RealTime Software Technology – RTST-технология (Терком), ГРАФИТ (ИПМ АН СССР и НИИ АП), ГРАФИТ-ФЛОКС (НПЦ АП);
компоненты стека телекоммуникационных протоколов: Telelogic Tau for SDL/MSC/TTCN (Telelogic, IBM);
информационные системы уровня предприятия: SILVERRUN (Computer Systems Advisors), ERwin/Bpwin (Logic Works, Erwin, Inc.);
программное обеспечение, построенное в парадигме объектно ориентированного программирования , в частности бизнес-приложения, включающие в себя базы данных: IBM Rational Rose (IBM).
В большей степени известны применения CASE-технологий в области построения информационных систем предприятия ( ERP -систем), где они одновременно являются инструментами анализа, моделирования и оптимизации бизнес-процессов и информационных потоков. CASE-технологии в инженерии большей частью используются в крупных организациях – разработчиках сложных и уникальных программных и программно-аппаратных систем, таких как Ericcson, Motorola, Boeing , Lockheed Martin , Thales Group, Airbus , Bosch и др.
Языки и средства моделирования
CASE-технологии можно рассматривать как реализацию концепции разработки программ на основе моделей (англ. Model Driven Development – MDD), а многие CASE-средства, базирующиеся на UML или SDL, согласуются с подходом к проектированию архитектуры систем на основе моделей (англ. Model Driven Architecture – MDA). Под моделями в данном случае понимают описание архитектуры или поведения программы в графической нотации. В UML, например, имеется несколько типов диаграмм, имеющих различное назначение. Так, диаграммы классов показывают модульную структуру программы и связи между такими программными сущностями, как классы и объекты. Связи между сущностями, в свою очередь, могут быть разной природы (например, связь по наследованию). Диаграммы деятельности или диаграммы состояний предназначены для описания поведения программы.
Использование графической нотации упрощает понимание описания программных систем. Особенно это важно, когда требования к системе и её основные характеристики приходится обсуждать со специалистами в проблемных областях без опыта в программировании.
Многие из работ по развитию, стандартизации и повышению интероперабельности языков и средств моделирования важных для CASE-технологий координировались консорциумами OMG , развивающим UML и MDA, и OASIS, развивающим стандарты для моделирования бизнес-процессов BPEL, UBL, OSLC, TOSCA.
Сферы применения CASE-технологий
Задача-максимум CASE-технологий – интегрировать все инструменты и процессы разработки, организовать «бесшовные» связи между инструментами и потоками информации в рамках жизненного цикла разработки, а в пределе – эксплуатации и модернизации программных систем, и в конечном итоге получить полный контроль над процессами разработки и эксплуатации программных систем. К сожалению, прямолинейное решение такой глобальной задачи всегда приводит к чрезмерно сложному программному продукту и сложным процессам обучения персонала, поддержки и др. По этой причине все удачные CASE-средства ограничивают область своего применения тем или иным образом.
Области применения различаются:
фазами жизненного цикла, на поддержку которых нацелена CASE-технология, видами процессов этого жизненного цикла;
базовым слоем программной или программно-аппаратной платформы [ архитектура ЭВМ , языки программирования, тип системы управления базами данных , технологии реализации пользовательского (графического) интерфейса ];
типом разрабатываемого ПО (информационные системы на основе баз данных, системы реального времени, бизнес-приложения, например CRM-системы, бухгалтерские системы и т. д.).
Основные фазы жизненного цикла, где возможности CASE-средств наиболее востребованы, – это анализ требований, эскизное проектирование систем, обратная инженерия (англ. reverse-engineering) унаследованного ПО (англ. legacy). Вместе с тем некоторые CASE-средства также поддерживают фазы разработки, тестирования и развёртывания. Детальная модель разрабатываемой системы может служить исходной информацией для генерации исходного кода программной реализации на языке программирования, эта же модель может служить исходными данными для генерации тестов и/или оценки полноты тестового покрытия.
Современные CASE-средства объединяют в себе средства для моделирования и разработки программных систем и управления процессами разработки. К задачам управления примыкают задачи конфигурационного управления, автоматизированной сборки и интеграции компонентов программной системы. Наиболее известны в этой области средства по поддержке т. н. совместной разработки (англ. lifecycle collaboration), непрерывной разработки (англ. Continuous Integration and Continuous Delivery/Deployment tools – CI/CD), а также классические средства управления проектами для составления графиков работ, планирования ресурсов, сетевого планирования и др.
Иногда термин «CASE» трактуется расширенно как Computer Aided System Engineering или Computer Aided Software and System Engineering, что указывает на особое внимание к анализу и учёту общесистемных требований, включая организацию деятельности предприятия в целом, выделения ролей персонала и т. д. CASE-средства такой направленности в основном помогают на предпроектных фазах разработки собственно программного обеспечения, когда важно понять текущую структуру информационных потоков, схемы принятия решений, выявить критические звенья в системе управления предприятием. Такие CASE-средства могут включать специфические инструменты, например средства автоматического построения моделей бизнес-процессов (англ. process mining) на основе журналов событий, которые накапливаются в информационной системе.
Помимо создания чисто программных решений CASE-средства используются для моделирования, анализа и разработки программно-аппаратных систем управления (например, систем авионики) и для систем, включающих в себя не только компьютерные и сетевые составляющие, но и реальные физические или механические объекты, например реальные двигатели или крылья самолётов, радары и т. д. В первом случае используются средства системного или архитектурного моделирования. Основными языками моделирования здесь являются SysML (специализированный диалект UML) и AADL (англ. Architecture Analysis & Design Language). При наличии в целевой системе физических объектов говорят о моделировании киберфизических систем. В этой области пока нет общепринятых лидеров, хотя исследования и разработки CASE-средств для киберфизических систем активно ведутся.
Перечисленные выше CASE-средства в первую очередь нацелены на высокоуровневое моделирование, вместе с тем иногда к CASE-средствам относят и собственно средства разработки программ, которые также интегрируют в себе поддержку нескольких процессов разработки, например написания программного кода и его отладки. К этому классу относятся такие инструментальные средства, как интегрированные среды разработки (англ. Integrated Development Environment – IDE) и наборы инструментов для разработки программного обеспечения (англ. Software Development Kit – SDK). Помимо таких традиционных компонентов IDE, как интерактивный редактор, компилятор , редактор связей , загрузчик и отладчик, современные IDE предоставляют средства, реализующие навигацию в программном проекте, возможности автопродолжения с настройкой на язык программирования, средства разработки графических пользовательских интерфейсов, средства статического и динамического анализа, поддержку инструментации кода. Высшим достижением является поддержка согласованных графических и текстовых представлений программ, когда изменения в одном из представлений автоматически производят аналогичное изменение в другом. Однако эта технология чрезмерно сложна и практически ни один из современных разработчиков её не поддерживает в полной мере.
Преимущества CASE-технологий
После того как выбрано адекватное CASE-средство, персонал обучен и процессы жизненного цикла отлажены, CASE-средства начинают демонстрировать свои преимущества: производительность разработчиков значительно возрастает, удаётся существенно сократить сроки и расходы на создание модификаций разрабатываемых программных продуктов и на поддержку процессов верификации и валидации . В случае когда целевой программный продукт должен проходить сложную процедуру сертификации (например, при создании систем авионики), обойтись без некоторых CASE-средств просто невозможно, т. к. в сертификационный комплект документации необходимо включить свидетельства о качестве и надёжности разработанной программы, которые невозможно составить вручную.
Проблемы внедрения CASE-технологий
Недостатки CASE-средств и факторы риска при их внедрении связаны со сложностью выполнения перечисленных выше условий: CASE-средство может оказаться неадекватным классу решаемых задач, квалифицированный и обученный персонал трудно удержать в течение длительного времени, процессы жизненного цикла нелегко отладить, в частности сложно наладить мониторинг эффективности использования CASE-средств и оперативную поддержку пользователей, включая оперативное устранение проблем, выявляемых в ходе использования CASE-средств. Кроме того, внедрение CASE-средств ставит компанию-разработчика в зависимость от поставщика CASE-средства, что также является дополнительным фактором риска, т. к. переход с одного CASE-средства на другое крайне сложен.
Без учёта перечисленных факторов риска можно оказаться в плену неоправданных ожиданий, и инвестиции, вложенные в приобретение и внедрение CASE-средств, окажутся неэффективными. Вероятно, невнимание к этим вопросам в начале 2000-х гг. сначала породило прогнозы о тотальном внедрении CASE-средств, в частности на основе UML, а затем интерес к этой теме упал.
CASE-технологии продолжают развиваться, чему способствует как заинтересованность разработчиков ПО, так и развитие новых языков и новых программных технологий в целом. Активное распространение техник итеративной разработки (т. н. Agile -методов) привело к понижению интереса к CASE-средствам как средствам полной интеграции инструментов разработки в единое целое. Основное внимание в таких методологиях разработки ПО, как непрерывное развёртывание (англ. Сontinuous Deployment or Delivery – DevOps или CD), уделяется интеграции процессов жизненного цикла разработки программ.
Вместе с тем следует ожидать, что на смену «деинтеграции» через некоторое время придут подходы, ведущие к консолидации не только процессов, но и технологий и инструментов разработки программ. В настоящее время такая консолидация наблюдается в сфере разработки защищённого и надёжного ПО и создания технологий, нацеленных на обеспечение кибербезопасности и надёжности ПО ответственного назначения. В англоязычной литературе эти технологии часто называются Security Development Lifecycle (SDL), в России известны как технологии поддержки разработки доверенного ПО. Ещё одной новой волной в развитии CASE-технологий является распространение технологических платформ для «разработки программ без программирования» (англ. low-code/no-code platforms). Необходимым условием для расширения использования CASE-технологий является стандартизация интерфейсов между различными инструментами поддержки жизненного цикла. Широкое распространение принципов «совместной разработки» и «непрерывной разработки» уже позволило стандартизовать эти интерфейсы в значительной мере, т. е. возврат интереса к CASE-технологиям на новой технологической базе уже происходит.
Почему и как нужно адаптировать тест-кейсы перед автоматизацией тестирования
Или как сохранить деньги, время и нервы, ускорив при этом выпуск новых фич.
Фото: Martin Barraud / Getty Images
Компании ежегодно увеличивают затраты на обслуживание IT-инфраструктуры и инвестируют в сотрудников. Что неудивительно: ведь ожидания потребителей от сервисов постоянно растут и все новинки нужно тщательно тестировать.
И здесь на помощь приходит автоматизация, важную роль в которой играют тест-кейсы. Анастасия Леонтьева из SimbirSoft рассказала, как адаптировать их перед автоматизацией, и поделилась примером подготовленного кейса.
Анастасия Леонтьева
Руководитель направления тестирования и обеспечения качества в SimbirSoft. Имеет степень MBA, Six Sigma Yellow Belt, опыт работы в IT более шести лет.
Очевидные плюсы от автоматизации тестирования
Автоматизация тестирования может повысить скорость проверки качества продукта, что оборачивается для команды и бизнеса следующими выгодами:
- Снижаются затраты на тестирование.
- Снижается вероятность пропуска ошибки из-за человеческого фактора.
- Увеличивается скорость доставки новых фич.
Согласно исследованию practitest.com, более 45% респондентов утверждают, что автоматизация снизила их затраты на тестирование в два раза. Эта статистика подтверждается и нашей практикой. Однако автоматизировать следует тест-кейсы только по той функциональности, в которой не планируется глобальных изменений. Иначе есть риск, наоборот, повысить затраты — так как придётся переписывать автотесты.
Важно помнить, что автотесты запускаются на основе проведённых до этого ручных тестов с проверенными сценариями (чек-листы, пользовательские сценарии и так далее). На основе сценариев, покрытых кодом, в будущем можно будет проводить нагрузочное тестирование. Подробная и адаптивная тестовая документация позволит сократить время на погружение в задачу нового специалиста и увеличить эффективность тестирования в целом.
Как учесть ожидания SDET‑специалистов при подготовке тест‑кейсов
Представим, что к действующему долгосрочному проекту подключается SDET‑специалист . До того как начнётся написание автотестов, у него могут возникнуть вопросы к QA-инженерам: про объём тестов для автоматизации, приоритеты выбора проверок, набор доступов и так далее.
При этом QA-инженер может не обладать навыками автоматизации и опытом проектирования соответствующих тест-кейсов. Представления о построении качественных кейсов, адаптированных для автоматизации, в таком случае могут различаться.
Поэтому при подготовке тест-кейса для автоматизации важно проработать следующие моменты:
1. Последовательно, полно и понятно расписать тест-кейсы в рамках согласованной структуры. В этом случае новый специалист, только что пришедший в команду, без дополнительных вопросов сможет разобраться, какую именно функциональность необходимо проверить и каким образом.
2. Подробно указывать путь «до места назначения»: если нужно протестировать некую форму, важно расписать все шаги до её открытия. Часть описания можно вынести в предусловие.
3. Рационально подходить к процессу передачи тест-кейсов под автоматизацию. Нужно чётко понимать, что можно реализовать, а что нет. Если же возникли вопросы, то лучше заранее проконсультироваться со SDET-специалистом.
4. Включить в тест-кейс все необходимые данные. А именно: информацию об окружении, специфике тестирования на разных платформах, параметры настройки, а также необходимое время для применения в системе тех или иных настроек, если это требуется.
5. Если для выполнения кейса нужно определённое состояние системы или если кейс меняет его, напишите, как этого состояния достичь и что нужно сделать после проведения теста. Например, если производятся манипуляции над сущностью, должно быть понятно, где эту сущность взять и как потом вернуть на место, чтобы соблюсти идемпотентность .
6. Обращать внимание на тестовые данные. Если, например, требуется авторизация и учётные записи имеют разные уровни доступа, обязательно нужно прикрепить информацию о необходимом уровне доступа или сразу указать данные учёток, в которых уже есть необходимые сведения (документы, поля и прочее).
7. Отражать в кейсах тестовые сценарии использования системы. То есть последовательность запросов и ответов API, в которой заложен путь пользователя, а также чётко прописать ожидаемый результат.
8. Подробно расписать ожидаемый результат. Он должен быть точным и окончательным: один кейс — один результат. В этом поможет подробное описание и хорошие тестовые данные. Если возможен другой результат (сразу несколько изменений системы), необходимо вынести его в другой кейс. В ожидаемом результате важно точно указать, к чему привязаться автоматизатору, например к названию страницы или названию формы/кнопки.
9. Если рассматривать мобильную UI-автоматизацию, в тест-кейсе нужно включить моки и скриншоты для snapshot-тестов.
10. Чётко обозначить в тест-кейсе приоритетные проверки, критичные для корректной и стабильной работы системы.
Лишние действия, уточнения и разногласия специалистов, участвующих в тестировании одной фичи (или смежных, взаимозависимых), как правило, приводят к потере времени. В дальнейшем это может отразиться на сроках релиза.
Чтобы прийти к совместному решению, необходимо определить правила взаимодействия, зафиксировать их и продемонстрировать команде.
Тест-кейс: до и после адаптации
Давайте на примере разберём, как можно улучшить кейсы под автоматизацию. Возьмём интернет-магазин, у которого есть API для совершения CRUD-операций с карточкой товара:
- Создание.
- Просмотр.
- Редактирование.
- Удаление.
Мы будем использовать открытый API shop.bugred.ru. Предварительно в нём необходимо будет авторизоваться. Это можно вынести в предусловие, так как оно не требует описания шагов или тела запроса, а лишь указывает на необходимость того или иного действия перед выполнением шагов. Ссылку на документацию, а также доступы можно найти на главной странице.
Несколько допущений в рамках нашего тест-кейса:
- Мы будем рассматривать только взаимодействие через API.
- В базу данных вынесены настройки, позволяющие включать или отключать возможность создания товара пользователем.
- В системе может быть несколько тестовых сред со своей базой данных.
А вот, собственно, и сценарий: пользователь (например, менеджер) заходит в административную панель магазина, создаёт товар, обновляет информацию о нём (правит цвет, размер и так далее), проверяет, что данные изменились, и потом удаляет товар.
9.4.1. Case-технологии
CASE(Computer-AidedSoftware/SystemEngineering) как новое направление в программировании сформировалось за последние 10-15 лет.
CASE-технологии применяются при создании сложных информационных систем, обычно требующих коллективной реализации проекта, в котором участвуют различные специалисты: системные аналитики, проектировщики и программисты. Основное достоинство CASE-технологии — поддержка коллективной работы над проектом за счет возможности работы в локальной сети разработчиков, экспорта/импорта любых фрагментов проекта, организационного управления проектом.
CASE-технология представляет собой совокупность методологического анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом программных средств автоматизации. Это инструментарий для системных аналитиков, разработчиков и программистов, который позволяет автоматизировать процесс проектирования и разработки ПО. В настоящее время практически ни один серьезный зарубежный программный продукт не осуществляется без использования CASE-средств. Известная методология структурного системного анализа SADT (точнее ее подмножество IDEFO) принята в качестве стандарта на разработку ПО Министерством обороны США.
Основная цель CASE состоит в том, чтобы отделить проектирование ПО от его кодирования и последующих этапов разработки. Чем больше деятельности будет вынесено в проектирование из кодирования, тем лучше.
Инструментальные средства CASE-технологий применяются на всех этапах жизненного цикла системы (от анализа и проектирования до внедрения и сопровождения), значительно упрощая решение возникающих задач.
CASE-технология позволяет отделить проектирование информационной системы от собственно программирования и отладки: разработчик системы занимается проектированием на более высоком уровне, не отвлекаясь на детали. Это позволяет не допустить ошибок уже на стадии проектирования и получить более совершенные программные продукты.
Эта технология изменяет все стадии разработки ИС, более всего отражаясь на этапах анализа и проектирования
Нередко применение CASE-технологии выходит за рамки проектирования и разработки ИС. Технология дает возможность оптимизировать модели организационных и управленческих структур компаний и позволяет лучше решать такие задачи, как планирование, финансирование, обучение. Таким образом, CASE-технология позволяет произвести радикальное преобразование деятельности компании, направленное на оптимальную реализацию того или иного проекта или повышение общей эффективности бизнеса.
Коллективная работа над проектом предполагает обмен информацией, контроль выполнения задач, отслеживание изменений и версий, планирование, взаимодействие и управление. Фундаментам реализации подобных функций чаще всего служит общая база данных проекта, которую обычно называют репозитарием. По существу, репозитарий — это информационный архив, где хранятся сведения о процессах, данных и связях объектов в разрабатываемом приложении.
В большинстве современных CASE-системах применяются методологии структурного анализа и проектирования, которые основаны на наглядных диаграммах. При этом для описания модели проектируемой системы используются графы, диаграммы, таблицы и схемы. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы. Оно начинается с общего обзора системы, затем детализируется, приобретая иерархическую структуру.
CASE-технологии успешно применяются для построения практически всех типов ПО, как системного и управляющего, так и прикладного. Ключевым признаком CASE-средства является поддержка методологий структурного системного анализа и проектирования.
С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурных методологий проектирования 60-70-х годов (сложности понимания, большой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.п.) за счет автоматизации поддерживающих средств. Т.о., CASE-технологии не могут считаться самостоятельными методологиями, они только развивают структурные методологии и делают более эффективным их применение за счет автоматизации.
Помимо автоматизации структурных методологий CASE обладают следующими основными достоинствами:
улучшение качества создаваемого ПО за счет средств автоматического контроля;
создание за короткое время прототипа будущей системы, что позволяет на ранних этапах оценить ожидаемый результат;
ускорение процесса проектирования и разработки;
освобождение разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части проекта;
поддержка развития и сопровождения разработки.
В настоящее время CASE-технологии — одно из наиболее динамично развивающихся отраслей информатики, объединяющие сотни компаний. Из имеющихся на рынке CASE-технологий можно выделить: Application Development Workbench (ADW) фирмы Knowlegge Ware, BPwin (Logic Works), CDEZ Tods (Oracle), Clear Case (Alria Softwere), Composer (Texas Instrument), Discover Development Information System (Software Emancipation Technology).
Современные CASE-технологии успешно применяются для создания ИС различного класса для банков, финансовых корпораций, крупных фирм. Они обычно имеют достаточно высокую стоимость и требуют длительного обучения и кардинальной реорганизации всего процесса создания ИС. Тем не менее экономический эффект применения CASE-технологий весьма значителен, и большинство серьезных программных проектов осуществляется именно с их помощью.
Средства CASE-технологий делятся на две группы:
встроенные в систему реализации — все решения по проектированию и реализации привязаны к выбранной системе управления базами данных (СУБД);
независимые от системы реализации — все решения по проектированию ориентированы на унификацию начальных этапов жизненного цикла и средств их документирования, обеспечивают большую гибкость в выборе средств реализации.
Некоторые CASE-технологии ориентированы только на системных проектировщиков и представляют собой специальные графические средства для изображения различного вида моделей:
диаграммы потоков данных (DFD — data dfow diagrams) совместно со словарями данных и спецификациями процессов;
диаграммы «сущность-связь» (ERD — entity relationship diagrams), являющиеся инфологической моделью предметной области;
диаграммы переходов состояний (STD — state transition diagrams), учитывающие события и реакцию на них системы обработки данных.
Другой класс CASE-технологий поддерживает только разработку программ, включая:
автоматическую генерацию кодов программ на основании их спецификаций;
проверку корректности описания моделей данных и схем потоков данных;
документирование программ согласно принятым стандартам и актуальному состоянию проекта;
тестирование и отладку программ.
Кодогенерация программ выполняется двумя способами: создание каркаса программ и создание полного продукта. Каркас программы служит для последующего ручного варианта редактирования исходных текстов, обеспечивая возможность вмешательства программиста; полный продукт не редактируется вручную.
Большинство специалистов считают, что хорошее инструментальное средство CASE должно обладать следующими качествами:
наличие выбора из различных методов проектирования (разработчик может оперативно переключаться с одного метода на другой);
простота использования в сочетании с мощными функциями;
поддержка коллективной работы;
удобный просмотр иерархии классов;
возможность «нелинейной» разработки программ;
ввод программного кода в диаграмму с последующим ее обновлением;
наличие функции контроля версий;
распечатка больших диаграмм на стандартных страницах;
гибкость построения диаграмм, позволяющая пользователю каждый раз видеть то, что ему требуется;
наличие анимации, с помощью которой можно наглядно моделировать поведение системы;
наличие хороших средств контроля ошибок, в том числе проверку на наличие логических ошибок;
разделение компонентов объектной модели по категориям выполняемых функций;
применение методов «обратного проектирования»: использование в разработке алгоритмов существующего кода либо построение логической модели по уже имеющейся базе данных;
Возможность генерации кода;
при наличии неоднородной вычислительной среды поддержка нескольких платформ;
возможность включения в модель элементов проверки и фильтрации данных;
поддержка сложных моделей, в частности моделей финансовых потоков, деловой и производственной активности;
Классификация CASE-средств по типам отражает их функциональную ориентацию в технологическом процессе.
Анализ и проектирование, создание спецификаций системы поддерживают следующие системы: CASE. Аналитик; Excelerator (Index Technology); Design-Aid (Nastec); Analist/Designer (Yourdon); Design/IDEF (Meta Software); SELECT (Select Software Tools); System Architech (Software&Systems) и др. На выходе продуцируются спецификации компонентов системы и интерфейсов, связывающих эти компоненты, а также предварительная архитектура системы; детальная проработка проекта, включающая алгоритмы и определение структур данных.
Проектирование баз данных и файлов предполагает использование следующих CASE-средств: ERWin (Logic Works); S- Designer (SDR), Designer/2000 (Oracle), Silverrun (Computer, Systems Advisers и др. Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в 3НФ, автоматическую генерацию схем БД и описание форматов файлов на уровне программного кода.
Программирование. Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полную документированную выполняемую программу: СOBOL 2/Workbench (MicroFocus); DECASE (DEC); NETRON/CAP (Netron), APS (Sage Software). Помимо диаграммеров различного назначения и средств поддержки работы с репозитарием, в эту группу средств включены и традиционные генераторы кодов, анализаторы кодов (как в статике, так и динамике), генераторы наборов тестов, анализаторы покрытия тестами, отладчики.
Сопровождение и реинжинеринг. К таким средствам относятся документаторы, анализаторы программ, средства реконструирования и реинжениринга: Adpac CASE Tools (Adpac), Scan/COBOL & Super Structure (Computer Data Systems), Inspector/Recoder (Language Technology). Их целью является корректировка, изменение, анализ, приобретение и реинжениринг существующей системы.
Мобильность системы обеспечивается в CASE-средствах средствами миграции и реинжениринга. К средствам миграции относятся трансляторы, конверторы, макрогенераторы и др., позволяющие обеспечить перенос существующей системы в новое операционное или аппаратное окружение. Средства реинжениринга включают:
статистические анализаторы для продуцирования схем системы ПО из ее кодов, оценки влияния модификаций (например, «эффект ряби»- внесение изменений с целью исправления ошибок порождает новые ошибки);
динамические анализаторы (обычно компиляторы и интерпретаторы с встроенными отладочными возможностями);
документаторы, позволяющие автоматически получать обновленную документацию при изменении кода;
редакторы кодов, автоматически изменяющие при редактировании и все предшествующие коду структуры (например, спецификации);
средства доступа к спецификациям, их модификации и генерации нового (модифицированного кода);
средства реверсного инжиниринга, транслирующие коды в спецификации.
Окружение. Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам Multi/Cam (AGS Management Systems), Sylva Foundry (Cagware).
Управление проектом – средства, поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов: Project Workbench (Applied Business Technology).
CASE-средства классифицируются также по категориям. Такая классификация определяет уровень интегрированности по выполняемым функциям и включает:
вспомогательные программы (tools) — решают небольшую автономную задачу, принадлежащую проблеме более широкого масштаба;
пакеты разработчика (toolkit) — представляют собой совокупность интегрированных программных средств, обеспечивающих помощь для одного из классов программных задач (использует репозитарий для всей технической и управляющей информации о проекте, концентрируясь при этом на поддержке, как правило, одной фазы или одного этапа разработки ПО;
интегрированные программные средства (workbench) — поддерживают системный анализ, проектирование и разработку ПО. По сравнению с toolkit обладают более высокой степенью интеграции выполняемых функций, большей самостоятельностью и автономностью использования; наличием тесной связи с системными и техническими средствами аппаратно-вычислительной среды, на которой workbench функционирует.
Пакет CASE-Аналитик
Пакет CASE-Аналитик является единственной отечественной разработкой, доведенной до рынка, который относится к CASE-средствам первой генерации. В основе пакета лежит методология структурного системного анализа Гейне-Сарсоне. Пакет обеспечивает:
“принудительный” хороший стиль;
предоставление разработчику машинно-реализованных средств формального описания системы и, прежде всего, в графической нотации, понятной заказчику создаваемой системы, вовлекаемого, таким образом, в разработку системы на ее ранней стадии, когда еще можно что-либо менять без особых затрат;
предоставление доступа к любой части проекта;
контроль полноты и непротиворечивости каждой части системных требований, при помощи встроенных средств контроля.
Результат работы в среде проекта — информационно-логическая модель анализируемой системы. Эта модель представляется в виде иерархии диаграмм потоков данных и структурограмм данных. Когда дальнейшая детализация логических функций перестает быть полезной, то переходят к выражению внутренней логики процессов при помощи миниспецификаций – алгоритмов преобразования входных потоков в выходные.
В состав пакета входят:
База данных проекта, в которой CASE. Аналитик хранит всю информацию о модели системы – как о топологии и иерархии диаграмм, так и о структурных компонентах. При этом пользователю предоставляется графический интерфейс с базой данных и возможность получения разнообразных отчетов по проекту. В CASE. Аналитик используется БД в формате СУБД Paradox. БД доступа для программ, работающих с форматом Paradox. В этом смысле она является открытой. БД включает контекстные диаграммы, диаграммы потоков данных, диаграммы управляющих потоков, структуры данных, описание логики процессов, спецификации элементов данных, сигналов и структурных объектов, а также исходные данные о системе, проекте, причастных лицах и организациях, разработчиках и т.п.
Графические редакторы потоков диаграмм и структурограмм данных. Все действия над диаграммами при редактировании отображаются на экране в графических видах. При вводе элементов диаграмм и их редактировании осуществляется контроль корректности вводимой информации и ее совместимости с остальными частями проекта. Введенная (измененная) информация запоминается в БД проекта автоматически и по запросу пользователя.
Средства вывода экранных и печатных форм – для контроля и анализа проекта и его презентации. Предусмотрены следующие экранные и печатные формы – контекстная диаграмма, диаграмма потоков данных, диаграмма потоков управления, структурограмма данных, перечни объектов словаря данных, отсортированных и выбранных различными способами, содержание элементов словаря данных, миниспецификации логики процесса, протоколы верификации проекта, отчеты проекта.
Документатор. Состав и содержание документов проекта системы регламентируется комплексами стандартов и руководящих материалов. CASE. Аналитик поддерживает следующие стандарты и руководящие документы:
Информационная технология. Комплекс стандартов и руководящих материалов на автоматизированные системы. М.: Госстандарт СССР, 1991 г., — ГОСТы 34.ххх;
ЕСПД – ГОСТы 19.ххх.
Кроме того, оформление диаграмм при печати может быть выполнено в соответствии с требованиями ЕСПД: автоматически генерируется рамка и надписи.
Верификатор. Принципиальные решения по верификации проекта делает пользователь-аналитик. Эти решения аналитик принимает по результатам простых, но очень трудоемких процедур контроля и верификации, которые CASE. Аналитик выполняет автоматически по запросу. CASE. Аналитик предоставляет следующие средства верификации:
автоматический контроль выполнения формальных правил построения модели при вводе и редактировании;
автоматическая поддержка согласованности при детализации подсистем, процессов и данных, т.е. при переходе с уровня на уровень;
верификация (по запросу) согласованности модели;
вывод на дисплей и печать разнообразных отчетов, которые могут быть использованы для верификации.
К основным функциям пакета относят следующие:
Построение и редактирование потоковых диаграмм.
Навигация по диаграммам – навигация по горизонтали с использованием специального окна навигации и навигацию по вертикали (вглубь, наверх), а также выбор и загрузку любой диаграммы с использованием дерева диаграмм проекта.
Редактирование структурограмм – имеются возможности передвижения элементов структурограмм, их удаления с автоматической поддержкой целостности, ввода и редактирования спецификаций данных, а также погружения вглубь структуры.
Навигация по данным – включает передвижение по структурограмме как наверх, так и вглубь, а также выбор и загрузку любой структурограммы по дереву структур данных.
Описание логики процессов – позволяет вводить и редактировать миниспецификации процессов с использованием структурированного естественного языка.
Навигация по БД проекта – позволяет осуществлять доступ к спецификации любого объекта модели, используя списки и перечни объектов, поиск по имени, а также доступ из диаграмм и структурограммам.
Верификация проекта на полноту исходных данных, полноту диаграмм, полноту данных, согласованность накопителей и информационных каналов, а также анализ нагрузки информационных каналов и анализ объекта накопителей данных.
Печать диаграмм – режимы: качественная печать, быстрая печать, пропорциональная, печать для презентаций.
Генерация отчетов и документов – средства позволяют генерировать 12 отчетов по проекту в соответствии с вышеперечисленными стандартами, а также отчеты по спецификациям объектов (13 типов объектов), перечням объектов (11 отчетов) и верификации (6 отчетов).
Экспорт/импорт – благодаря этой функции возможно взаимодействие аналитиков, работающих на автономных рабочих местах. Руководитель проекта ведет центральную БД проекта и экспортирует для проработки другим аналитикам части (поддеревья) иерархической информационно-логической модели системы.