Цели и задачи программной инженерии. Понятие программного обеспечения

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Типы программного обеспечения

 

Тип ПО может быть следующим:

• Разрабатывающееся вновь;
• Имеющееся в готовом виде;
• Программно-аппаратное (встроенное);
• Автономное.

Вновь разрабатываемое. Такое  ПО вступает в процесс Разработки с самого начала и для него должны быть рассмотрены все требования этого процесса. 
Имеется в готовом виде.

Готовое ПО может использоваться одним из следующих способов. 
Использование ПО точно в том виде как оно есть. Такое ПО уже спроектировано, закодированное и тестируемое. Дополнительное тестирование может потребоваться с учетом таких факторов как критичность и история использования. Это ПО входит в процесс Разработки не позднее квалификационного тестирования. Полный процесс Разработки может оказаться лишним. Должны быть оценены работоспособность, документация, права собственности и дальнейшей поддержки ПО.

Использование готового ПО без модификации, но с изменением параметров конфигурации приложения (например, формата даты, валюты или размера  страницы). Такое ПО входит в процесс  Разработки, когда компоненты ПО тестируются  и интегрируются после соответствующего изменения параметров. Полный процесс  Разработки может оказаться лишним. Должны быть оценены работоспособность, документация, права собственности  и дальнейшей поддержки ПО.

Модификация готового ПО (например, изменение формата отчетов или  доработка документации). В процесс  Разработки входит на этапе кодирования  и тестирования ПО. Должны быть оценены работоспособность, документация, права собственности и дальнейшей поддержки ПО.

Встроенное ПО.

ПО или программно-аппаратные средства встраиваются в систему. Поскольку  такое ПО является частью большой  системы, все действия уровня системы  в процессе Разработки должны быть учтены. Если программное или программно-аппаратные средства не требуют дальнейшей модификации, то надо тщательно исследовать вопрос об объеме необходимой документации. 
Автономное ПО. Поскольку такое ПО не является частью системы, все действия уровня системы с процесса Разработки могут быть исключены. Необходимо рассмотреть потребности в документации, особенно для сопровождения системы.

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

Чем больше система зависит  от того, правильно ли работает ПО и  окончена его разработка вовремя, тем  больше гласности и контроля необходимо. С другой стороны чрезмерный контроль в тех случаях, когда в нем  нет необходимости, является неэффективным.

Разработка ПО может быть соединена с техническим риском. Если используется незрелая технология разработки, если разрабатываемое ПО не имеет прецедентов или очень  сложное, если к ПО подаются специфические  требования по безопасности, защищенности, тогда требуются очень тщательные спецификации, проектирования, тестирования и оценка. В этом случае могут  быть важны независимая верификация  и валидация.

5. Общие требования  к программным системам

 

5.1. Максимум удобств пользователя:

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

5.2. Адаптируемость ПО - приспособляемость к функционированию в различных условиях

5.3. Гибкость - возможность  легко вводить изменения, дополнения  и исправления в ПО

5.4. Мобильность - переносимость  на различные вычислительные  платформы и операционные среды

5.5. Масштабируемость, расширяемость  и модифицируемость

5.6. Эффективность работы

 

 

 

 

 

6. Принципы построения  программного обеспечения

 

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

6.2. Интеллектуальность ПО - наличие знаний о предметной  области и умение использовать  их при решении задач.

6.3. Черный ящик - ПО должно  скрывать от пользователей сложный  механизм организации и взаимодействия  программ.

6.4. Умолчание - умолчание  однажды заданных параметров, если  они имеют смысл в других  аналогичных задачах.

7. Критические вопросы процесса разработки программного обеспечения

Качество

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

Если контроль качества в  организации ослаблен, требуется  запланировать в самом процессе разработки ряд инспекций проектной  документации и инспекций кодов, разрабатывая планы качества, систему  измерений, программу тестирования, т.е. более интенсивную работу по Подтверждению качества программного обеспечения (Software Quality Assurance).

Продуктивность технологии.

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

Нестабильность (изменчивость) требований.

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

Существуют три основных типа изменений требований.

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

Нестабильные требования. В то время как общие требования известны, частности продолжают "плавать". В бортовых системах, для которых  hardware и software часто проектируется одновременно, изменения в hardware приводят к изменению требований к программному обеспечению. Изменение hardware, диктуемое программными изменениями, является нонсенсом, аналогичным требованиям поменять фундамент при постройке здания. Тем не менее, с данным явлением можно бороться путем предвидения нестабильностей и изоляции их.

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

Сложность.

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

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

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

 

 

 

 

 

 

 

 

Вывод

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

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

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

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

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

 

 

 

 

 

 

Справочная литература

1. http://ru.wikipedia.org/wiki/%C8%ED%E6%E5%ED%E5%F0%E8%FF_%EF%F0%EE%E3%F0%E0%EC%EC%ED%EE%E3%EE_%EE%E1%E5%F1%EF%E5%F7%E5%ED%E8%FF

 

2. http://abiturient.ru/speciality/15139