Коллективная разработка программного обеспечения

Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими особенностями:

• мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
• интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки информационной системы;
• использование специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ПО) содержит следующие компоненты:
• репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
• графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели информационной системы;
• средства разработки приложений, включая языки 4GL и генераторы кодов;
• средства конфигурационного управления;
• средства документирования;
• средства тестирования;
• средства управления проектом;
• средства реинжиниринга.

Все современные CASE-средства можно классифицировать по типам и категориям. Классификация  по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла информационных систем (toolkit) и полностью интегрированные средства, поддерживающие весь жизненный цикл информационных систем и связанные общим репозиторием. Помимо этого CASE-средства можно классифицировать по применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

Классификация по типам в основном совпадает  с компонентным составом CASE-средств  и включает:

• средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
• средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
• средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE).Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
• средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично — в Silverrun;
• средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

• средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
• средства конфигурационного управления (PVCS (Intersolv));
• средства тестирования (Quality Works (Segue Software));
• средства документирования (SoDA (Rational Software)).

Ввиду разнообразной  природы CASE-средств было бы ошибочно делать какие-либо утверждения относительно реального удовлетворения тех или иных ожиданий от их внедрения. Можно перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств:

• широкое разнообразие качества и возможностей CASE-средств;
• относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;
• широкое разнообразие в практике внедрения различных организаций;
• отсутствие детальных метрик и данных для уже выполненных и текущих проектов;
• широкий диапазон предметных областей проектов;
• различная степень интеграции CASE-средств в различных проектах.

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

• Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;
• Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;
• Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

Для того чтобы  принять взвешенное решение относительно инвестиций в CASE-технологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и  противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных «подводных камней» использования CASE-средств. Среди наиболее важных проблем выделяют следующие:

• достоверная  оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО; 
• внедрение CASE-средств может представлять длительный процесс и не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения; 
• отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, что используются в данной организации, может привести к дополнительным трудностям; 
• CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми разнообразными средствами, так и проблемами передачи данных и управления от одного средства к другому; 
• некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте, тем не менее, можно извлечь выгоду из той дисциплины, к которой обязывает их применение; 
• негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

Но все же грамотное, продуманное и обоснованное использование CASE-технологии способно принести следующие выгоды:

• высокий уровень технологической поддержки процессов разработки и сопровождения ПО;
• положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;
• приемлемый уровень отдачи от инвестиций в CASE-средства.

 

Тестирование программ

1. Пошаговое и монолитное тестирование.

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

Пошаговый метод  состоит в том, что каждый модуль для тестирования подключается к  набору ранее отсортированных модулей.

Рассмотрим  пример:

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

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

Заглушка - программа, имитирующая работу модуля нижнего уровня. Она может не содержать ничего, кроме сообщения о том, что произошел вход в этот модуль, и возврата управления.

Выводы:

-      Монолитное тестирование требует больших затрат труда.

-       При пошаговом тестировании раньше обнаруживаются ошибки в межмодульных связях.

-     При пошаговом тестировании ошибки в межмодульных связях обнаруживаются легче.

-     Монолитный способ применяется чтобы ускорить сроки сдачи программы.

-     При монолитном  - меньше расход машинного времени.

Категории тестов системных испытаний.

1.     Тестирование удобства использования. Сравниваются цели с содержанием пользовательской документации.

2.      Тестирование на предельных объемах.

3.      Тестирование на предельных нагрузках. Означает поступление пикового объема данных в течение короткого интервала времени.

4.     Тестирование удобства эксплуатации:

-        Справка

-       Значимость входных сообщений программы

-       Понятна ли диагностика ошибок

-      Единообразие стиля пользовательских интерфейсов

-        Содержит ли система опции, число которых чрезмерно или использование которых маловероятно

-       Выдает ли система какие-либо подтверждения на все входные сообщения

5.      Тестирование защиты (от несанкционированного доступа).

6.      Тестирование производительности.

7.      Тестирование требований к памяти.

8.      Тестирование конфигураций оборудования.

9.      Тестирование удобства установки (настройки, инсталляции).

10.  Тестирование надежности.

11.  Тестирование восстановления.

12.  Тестирование удобства обслуживания.

13. Тестирование документации.

14. Тестирование процедур.

15. Выполнение проверки системы непрограммистами.

2. Принципы тестирования.

1. Тестирование - это процесс выполнения программ с целью обнаружения ошибок.
2. Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.
3. Удачным считается тест, который обнаруживает еще не выявленную ошибку.
4. Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора.
5. Следует избегать тестирования программы ее автором.
6. Тесты для неправильных и непредусмотренных входных данных следует разрабатывать также тщательно как для правильных и предусмотренных.
7. Необходимо проверять не тол<span class="dash041e_0431_044b_0447_043d_044b_0439__Char" style=" font-family: 'Times New Roman', 'Arial'; font-size