
ec93ca8356149f97faaac0102cdf5aed.ppt
- Количество слайдов: 147
Введение в программную инженерию По мотивам Ian Sommerville "Software Engineering" 1
Содержание n n n Что такое программная инженерия? Стандарты SE Программные требования Модели систем Прототипы Архитектура ПО Дизайн интерфейса ПО Совершенствование процессов Управление изменениями Конфигурационное управление RUP 2
Что такое программная инженерия 3
Программная инженерия n Экономика ВСЕХ развитых стран зависит от n n программного обеспечения (ПО) Все больше систем управляются программно Программная инженерия изучает теории, методы и средства профессиональной разработки ПО Расходы на разработку ПО составляют значительную часть ВНП всех развитых стран Стоимость ПО зачастую составляет наиболее значительную часть стоимости систем. 4
FAQ о программной инженерии n Что такое программное обеспечение? n Что такое программная инженерия? n В чем разница между программной инженерией и информатикой? n В чем разница между программной инженерией и системной инженерией? n Что такое программный процесс? n Что такое модель программного процесса? 5
FAQ о программной инженерии n Из чего складывается стоимость программных продуктов? n Что такое методы программной инженерии? n Что такое CASE (Computer-Aided Software Engineering)? n Каковы свойства хороших программ? 6
Что такое программное обеспечение? n Компьютерные программы и связанная с ними документация n Программные продукты могут разрабатываться для конкретного заказчика или для обобщенного рынка n Программные продукты могут быть Коробочными (generic products, shrinkwrapped software), т. е. разработанными для продажи многим различным заказчикам n Заказными (custom), т. е. разработанными для одного покупателя по его спецификациям n 7
Что такое программная инженерия? n Программная инженерия — это инженерная дисциплина, которая связана со всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию. n Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО. 8
В чем разница между программной инженерией и информатикой? n Информатика занимается теорией и методами компьютерных и программных систем. n Программная инженерия занимается практическими проблемами создания ПО. n Естественно, инженер-программист обязан в каком-то объеме знать информатику (точно так же, как электрический инженер должен в каком-то объеме знать физику). n В идеале, вся программная инженерия должна быть поддержана какими-то теориями информатики, но практике все значительно сложнее. Инженеры зачастую применяют первые попавшиеся методы, а элегантные теории информатики не всегда могут быть применены к реальным большим системам. 9
В чем разница между программной инженерией и системной инженерией? n Системная инженерия (а точнее — компьютерная системная инженерия, computer-based systems engineering, CBSE) занимается всеми аспектами создания и эволюции комплексных систем, в которых ПО играет заметную роль. Таким образом, программная инженерия является частью системной инженерии, наряду с созданием аппаратных платформ, созданием архитектуры, системной интеграцией и т. п. n В системной инженерии основной упор приходится именно на системные вопросы (спецификация системы, проектирование архитектуры, интеграция и внедрение), а не на составные части системы. n Системная инженерия значительно старше программирования как дисциплина — люди уже очень давно производят сложные индустриальные системы, такие как поезда, химические заводы и т. п. 10
Что такое программный процесс? n Программный процесс — это набор действий и связанных с ними результатов, приводящих к созданию программного продукта. Мы будем выделять четыре основных фазы программного процесса: n n Создание спецификации ПО – что система должна делать и ограничения на разработку Разработка ПО – производство программной системы Тестирование ПО (включает в себя validation и verification) – проверка того, что клиент хочет именно того, что прописано в спецификации, и что система соответствует спецификации Развитие или эволюция ПО (software evolution) – 11 изменение ПО в ответ на изменение внешних требований
Что такое модель программного процесса? n Модель программного процесса — это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модели всегда являются упрощениями: all models are wrong; some models are useful (E. Deming). n Некоторые примеры типов моделей программного процесса: n n n Модель технологического процесса (workflow model) — показывает последовательность действий, наряду со входами, выходами и зависимостями. Действия в этой модели представляют собой действия людей. Модель потоков данных (data flow or activity model) — представляет процесс в виде набора действий, каждый из которых выполняет некоторое преобразование данных. В этой модели действия могут быть более низкого уровня, чем в предыдущей модели (например, какие-то действия может выполнять компьютер). Модель роль/действие (role/action model) — показывает роли людей, участвующих в программном процессе, а также действия, за которые они отвечают. 12
Традиционные модели разработки ПО n Водопадная модель (Waterfall) n Эволюционное развитие (в двух вариантах — с доработкой прототипа и с выбрасыванием, т. е. переписыванием) n Формальные преобразования — основан на создании математических моделей системы и их дальнейшим преобразованиями, сохраняющими корректность n Сборка из повторно используемых компонент — предполагает, что части системы уже существуют, и процесс концентрируется скорее на интеграции, чем на разработке 13
Из чего складывается стоимость программных продуктов? n Структура стоимости ПО может сильно отличаться для различных типов проектов и различных методологий. Для типичного проекта, распределение стоимости выглядит приблизительно следующим образом: 60% - стоимость разработки, 40% - стоимость тестирования. Для заказного ПО стоимость эволюции может превосходить стоимость разработки n Чем больше система, и чем выше ее критичность, тем больший процент будет забирать тестирование. n Стоимость эволюции системы очень сильно варьируется в зависимости от размера системы и сроком ее жизни. Во многих случаях стоимость сопровождения превосходит стоимость разработки в 3– 4 раза. n Наконец, при создании коробочных продуктов стоимость создания спецификации исчезающе мала (около 5%), на разработку (обычно эволюционным способом) уходит около 30 -35% времени проекта, а все остальное — тестирование системы на всевозможных конфигурациях. Для коробочных продуктов особенно трудно оценить стоимость эволюции — обычно процесс создания новой версии не имеет четко выраженного начала, и, кроме того, чаще всего из маркетинговых соображений новая версия подается не 14 как модифицированный продукт, уже купленный пользователем, а как продукт абсолютно новый (хотя и совместимый со старыми)
Что такое методы программной инженерии? n Метод программной инженерии — это структурный подход к созданию ПО, нацеленный на создание эффективного продукта наиболее прибыльным (рентабельным, cost-effective) путем n Тема развивается с 1970 х: структурный анализ Тома Де. Марко (1978), JSD Джексона (1983). Эти и другие методы тех времен были ориентированы на идентификацию основных функций системы; функционально-ориентированные методы до сих пор популярны. Как это ни смешно, очень часто их применяют неосознанно. n В 1980 х гг. эти методы были дополнены всякой объектностью: Буч (1994), Рамбо (1991). Со временем эти методы были объединены в UML (книги начиная с 1997 г). n Практически все методы построены на идее создания графических моделей системы с последующим использованием этих моделей в качестве спецификации или архитектуры системы. 15
Что такое CASE (Computer-Aided Software Engineering)? n Понятие CASE включает в себя широкий комплекс программ, предназначенных для поддержки процессов создания программного продукта, включая анализ требований, моделирование, отладку и тестирование. Большинство современных методов поддержаны соответствующими CASE-средствами. n Любопытное разделение: CASE-средства, поддерживающие анализ и проектирование, иногда называют CASE-средствами верхнего уровня (upper. CASE tools), а средства, поддерживающие реализацию и тестирование, такие как отладчики, средства анализа системы, генераторы тестов и редакторы 16 программ, называют средствами нижнего уровня (lower -CASE tools).
Некоторые свойства программ n Сопровождаемость (maintainability). Система должна быть написана с расчетом на дальнейшее развитие. Это критическое свойство системы, т. к. изменения ПО неизбежны вследствие изменения бизнеса. n Надежность (dependability). Надежность включает в себя отказоустойчивость, безопасность и защищенность. Надежное ПО не должно приводить к физическому или экономическому ущербу в случае сбоя системы. n Эффективность (efficiency). ПО не должно впустую тратить системные ресурсы, такие как память или процессорное время. Поэтому эффективность включает в себя отзывчивость, время процессора, утилизацию памяти и т. п. n Удобство использования (usability). ПО должно быть легким в использовании, причем именно тем типом пользователей, на которых рассчитано приложение. Это включает в себя интерфейс пользователя и адекватную документацию 17
Профессиональная и этическая ответственность n Системное программирование подразумевает больше ответственности, чем простое применение технических навыков n Системные программисты должны вести себя этически и морально ответственным образом, так как во многих областях стандарты приемлемого поведения не регулируются законами, но определяются более тонким понятием профессиональной ответственности. 18
Этический кодекс ACM/IEEE n Профессиональные общества в США объединились для создания этического кодекса программистов n Члены этих организаций принимают этот кодекс в момент вступления в организацию n Кодекс содержит восемь Принципов, связанных с поведением и решениями, принимаемыми профессиональными программистами, включая практиков, преподавателей, менеджеров и руководителей высшего звена n Кодекс распространяется также на студентов и «подмастерьев» , изучающих данную профессию 19
Основные моменты n Программная инженерия – это инженерная дисциплина, которая связана со всеми аспектами производства ПО n Программные продукты состоят из разработанных программ и связанной с ними документации. Важными атрибутами продукта являются сопровождаемость, надежность, эффективность и удобство использования n Программный процесс состоит из действий, необходимых для разработки программного продукта. Основными действиями являются спецификация, разработка, тестирование и эволюция n Методы представляют собой организованные способы разработки ПО. Они включают в себя рекомендации по следованию процессу, нотации, используемые в методе, правила описания системы и руководства по применению 20
Основные моменты n CASE-средства представляют собой программные системы, разработанные для поддержки типовых действий в программном процессе, таких как редактура проектировочных диаграмм, проверка целостности этих диаграмм и отслеживание запущенных программных тестов n Программные инженеры несут ответственность перед своей профессией и соответствующими обществами. Эта ответственность не сводится к техническим вопросам. n Профессиональные общества публикуют кодексы поведения, в которых устанавливаются стандарты поведения, ожидаемые от членов общества 21
Стандарты программной инженерии 22
Стандарты Software Engineering n ISO/IEC 12207 -95 “Software Lifecycle Processes” (1995) = ГОСТ Р ИСО/МЭК 12207 -99 (1999) n Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 (Руководство к своду знаний по программной инженерии) n Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering (IEEE+ACM) n ACM/IEEE-CS Code of Ethics and Professional Practice 23
Сертификационная программа 24
Структура SWEBOK: 10 основных областей знаний n n n n n Software requirements – программные требования Software design – дизайн (архитектура) Software construction – конструирование ПО Software testing – тестирование Software maintenance – эксплуатация (поддержка) ПО Software configuration management – конфигурационное управление Software engineering management – управление в ПИ Software engineering process – процессы ПИ Software engineering tools and methods – инструменты и методы ПИ Software quality – качество ПО 25
SWEBOK: смежные области знаний n Computer engineering n Computer science n Management n Mathematics n Project management n Quality management n Systems engineering 26
Программные требования 27
Программные требования n Требования и спецификации системы - описание системных сервисов и ограничений Функциональные и нефункциональные требования n Пользовательские требования n Системные требования n Документ, описывающий требования n 28
Типы спецификаций n Спецификации на естественном языке n Структурированные спецификации n Графические нотации n Математические спецификации 29
Структура документа, описывающего требования n Введение n Глоссарий n Определение требований пользователя n Архитектура системы n Системные спецификации n Модели системы n Эволюция системы n Приложения 30
Описание сценариев n Состояние системы в начале выполнения n n n сценария Нормальный поток событий в сценарии Неправильный поток событий и его обработка Другие параллельные действия Состояние системы в конце выполнения сценария Use-cases (сценарии использования) основаны на технике UML когда определяются актеры и их взаимодействие друг с другом 31
Lending use-case 32
Library use-cases 33
Проверка требований n Валидность. Выполняет ли система то, что нужно заказчику n Непротиворечивость. Есть ли конфликт требований n Полнота. Все ли необходимые функции включены в систему? n Реализм. Можно ли создать систему в соответствии с требованиями в рамках заданного бюджета и технологий n Верифицируемость. Можно ли проверить выполнение требований 34
Управление требованиями Идентификация требований n Управление изменениями n Отслеживание выполнения n CASE инструменты n 35
System Models 36
System models n Abstract descriptions of systems whose requirements are being analysed 37
Topics covered n Context models n Behavioural models n Data models n Object models n CASE workbenches 38
Model types n Data processing model showing how the data is n n processed at different stages Composition model showing how entities are composed of other entities Architectural model showing principal sub-systems Classification model showing how entities have common characteristics Stimulus/response model showing the system’s reaction to events 39
Process models n Process models show the overall process and the processes that are supported by the system n Data flow models may be used to show the processes and the flow of information from one process to another 40
Behavioural models n Behavioural models are used to describe the overall behaviour of a system n Two types of behavioural model are shown here Data processing models that show data is processed as it moves through the system n State machine models that show the systems response to events n n Both of these models are required for a description of the system’s behaviour 41
Data-processing models n Data flow diagrams are used to model the system’s data processing n These show the processing steps as data flows through a system n Intrinsic part of many analysis methods n Simple and intuitive notation that customers can understand n Show end-to-end processing of data 42
Data flow diagrams n DFDs model the system from a functional perspective n Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system n Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment 43
Semantic data models n Used to describe the logical structure of data processed by the system n Entity-relation-attribute (ERA) model sets out the entities in the system, the relationships between these entities and the entity attributes n Widely used in database design. Can readily be implemented using relational databases n No specific notation provided in the UML but objects and associations can be used 44
Object models n Object models describe the system in terms of object classes n An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object n Various object models may be produced Inheritance models n Aggregation models n Interaction models n 45
The Unified Modeling Language n Devised by the developers of widely used object- oriented analysis and design methods n Has become an effective standard for object-oriented modelling n Notation n Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section Relationships between object classes (known as associations) are shown as lines linking objects Inheritance is referred to as generalisation and is shown ‘upwards’ rather than ‘downwards’ in a 46 hierarchy
Key points n A model is an abstract system view. Complementary types of model provide different system information n Context models show the position of a system in its environment with other systems and processes n Data flow models may be used to model the data processing in a system n State machine models model the system’s behaviour in response to internal or external events 47
Key points n Semantic data models describe the logical structure of data which is imported to or exported by the systems n Object models describe logical system entities, their classification and aggregation n Object models describe the logical system entities and their classification and aggregation n CASE workbenches support the development of system models 48
Software Prototyping 49
Software Prototyping n Rapid software development to validate requirements 50
Topics covered n Prototyping in the software process n Prototyping techniques n User interface prototyping 51
System prototyping n Prototyping is the rapid development of a system n In the past, the developed system was normally thought of as inferior in some way to the required system so further development was required n Now, the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach 52
Prototyping process 53
Prototyping benefits n Improved system usability n Closer match to the system needed n Improved design quality n Improved maintainability n Reduced overall development effort 54
Approaches to prototyping 55
Rapid prototyping techniques n Various techniques may be used for rapid development Dynamic high-level language development n Database programming n Component and application assembly n n These are not exclusive techniques - they are often used together n Visual programming is an inherent part of most prototype development systems 56
Component and application assembly n Prototypes can be created quickly from a set of reusable components plus some mechanism to ‘glue’ these component together n The composition mechanism must include control facilities and a mechanism for component communication n The system specification must take into account the availability and functionality of existing components 57
Reusable component composition 58
Visual programming n Scripting languages such as Visual Basic support visual programming where the prototype is developed by creating a user interface from standard items and associating components with these items n A large library of components exists to support this type of development n These may be tailored to suit the specific application requirements 59
User interface prototyping n It is impossible to pre-specify the look and feel of a user interface in an effective way. prototyping is essential n UI development consumes an increasing part of overall system development costs n User interface generators may be used to ‘draw’ the interface and simulate its functionality with components associated with interface entities n Web interfaces may be prototyped using a web site editor 60
Key points n A prototype can be used to give end-users a concrete impression of the system’s capabilities n Prototyping is becoming increasingly used for system development where rapid development is essential n Throw-away prototyping is used to understand the system requirements n In evolutionary prototyping, the system is developed by evolving an initial version to the final version 61
Key points n Rapid development of prototypes is essential. This may require leaving out functionality or relaxing nonfunctional constraints n Prototyping techniques include the use of very highlevel languages, database programming and prototype construction from reusable components n Prototyping is essential for parts of the system such as the user interface which cannot be effectively pre -specified. Users must be involved in prototype evaluation 62
Architectural Design 63
Architectural Design n Establishing the overall structure of a software system 64
Software architecture n The design process for identifying the sub- systems making up a system and the framework for sub-system control and communication is architectural design n The output of this design process is a description of the software architecture 65
Architectural models n Different architectural models may be produced during the design process n Each model presents different perspectives on the architecture 66
Architectural models n Static structural model that shows the major system components n Dynamic process model that shows the process structure of the system n Interface model that defines sub-system interfaces n Relationships model such as a data-flow model 67
CASE toolset architecture 68
Key points n The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model n Large systems rarely conform to a single architectural model n System decomposition models include repository models, client-server models and abstract machine models n Control models include centralised control and event-driven models 69
Key points n Modular decomposition models include data- flow and object models n Domain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models 70
User Interface Design 71
Topics covered n User interface design principles n User interaction n Information presentation n User support n Interface evaluation 72
Graphical user interfaces n Most users of business systems interact with these systems through graphical interfaces although, in some cases, legacy text-based interfaces are still used 73
GUI characteristics 74
User interface design process 75
Interaction styles n Direct manipulation n Menu selection n Form fill-in n Command language n Natural language 76
Control panel interface 77
Menu systems n Users make a selection from a list of possibilities presented to them by the system n The selection may be made by pointing and clicking with a mouse, using cursor keys or by typing the name of the selection n May make use of simple-to-use terminals such as touchscreens 78
Form-based interface 79
Command interfaces n User types commands to give instructions to the system e. g. UNIX n May be implemented using cheap terminals. n Easy to process using compiler techniques n Commands of arbitrary complexity can be created by command combination n Concise interfaces requiring minimal typing can be created 80
Natural language interfaces n The user types a command in a natural language. Generally, the vocabulary is limited and these systems are confined to specific application domains (e. g. timetable enquiries) n NL processing technology is now good enough to make these interfaces effective for casual users but experienced users find that they require too much typing 81
Multiple user interfaces 82
Help and message system 83
User documentation n As well as on-line information, paper documentation should be supplied with a system n Documentation should be designed for a range of users from inexperienced to experienced n As well as manuals, other easy-to-use documentation such as a quick reference card may be provided 84
Key points n Interface design should be user-centred. An interface should be logical and consistent and help users recover from errors n Interaction styles include direct manipulation, menu systems form fill-in, command languages and natural language n Graphical displays should be used to present trends and approximate values. Digital displays when precision is required n Colour should be used sparingly and consistently 85
Key points n Systems should provide on-line help. This should include “help, I’m in trouble” and “help, I want information” n Error messages should be positive rather than negative. n A range of different types of user documents should be provided n Ideally, a user interface should be evaluated against a usability specification 86
Process Improvement 87
Process Improvement n. Understanding, Modelling and Improving the Software Process 88
Topics covered n Process and product quality n Process analysis and modelling n Process measurement n The SEI process maturity model n Process classification 89
Process improvement n Understanding existing processes n Introducing process changes to achieve organisational objectives which are usually focused on quality improvement, cost reduction and schedule acceleration n Most process improvement work so far has focused on defect reduction. This reflects the increasing attention paid by industry to quality n However, other process attributes can be the focus of improvement 90
Process attributes 91
The process improvement process 92
Process and product quality n Process quality and product quality are closely related n A good process is usually required to produce a good product n For manufactured goods, process is the principal quality determinant n For design-based activity, other factors are also involved especially the capabilities of the designers 93
Principal product quality factors 94
Process measurement n Wherever possible, quantitative process data should be collected n Process measurements should be used to assess process improvements 95
The SEI process maturity model 96
Maturity model levels n Initial n Essentially uncontrolled n Repeatable n Product management procedures defined and used n Defined n Process management procedures and strategies defined and used n Managed n Quality management strategies defined and used n Optimising n Process improvement strategies defined and used 97
The CMM and ISO 9000 n There is a clear correlation between the key processes in the CMM and the quality management processes in ISO 9000 n The CMM is more detailed and prescriptive and includes a framework for improvement n Organisations rated as level 2 in the CMM are likely to be ISO 9000 compliant 98
Key points n Process improvement involves process analysis, standardisation, measurement and change n Process models include descriptions of tasks, activities, roles, exceptions, communications, deliverables and other processes n Measurement should be used to answer specific questions about the software process used n The three types of process metrics which can be collected are time metrics, resource utilisation metrics and event metrics 99
Key points n The SEI model classifies software processes as initial, repeatable, defined, managed and optimising. It identifies key processes which should be used at each of these levels n The SEI model is appropriate for large systems developed by large teams of engineers. It cannot be applied without modification in other situations n Processes can be classified as informal, managed, methodical and improving. This classification can be used to identify process tool support 100
Software Change 101
Topics covered n Program evolution dynamics n Software maintenance n Architectural evolution 102
Software change strategies n Software maintenance n Changes are made in response to changed requirements but the fundamental software structure is stable n Architectural transformation n The architecture of the system is modified generally from a centralised architecture to a distributed architecture n Software re-engineering n No new functionality is added to the system but it is restructured and reorganised to facilitate future changes n These strategies may be applied separately or together 103
Types of maintenance n Maintenance to repair software faults n Maintenance to adapt software to a different operating environment n Maintenance to add to or modify the system’s functionality 104
Distribution of maintenance effort 105
Spiral maintenance model 106
Development/maintenance costs 107
Evolutionary software n Rather than think of separate development and maintenance phases, evolutionary software is software that is designed so that it can continuously evolve throughout its lifetime 108
The maintenance process 109
Change requests n Change requests are requests for system changes from users, customers or management n In principle, all change requests should be carefully analysed as part of the maintenance process and then implemented n In practice, some change requests must be implemented urgently Fault repair n Changes to the system’s environment n Urgently required business changes n 110
Change implementation 111
Emergency repair 112
Key points n Software change strategies include software maintenance, architectural evolution and software re-engineering n Lehman’s Laws are invariant relationships that affect the evolution of a software system n Maintenance types are Maintenance for repair n Maintenance for a new operating environment n Maintenance to implement new requirements n 113
Key points n The costs of software change usually exceed the costs of software development n Factors influencing maintenance costs include staff stability, the nature of the development contract, skill shortages and degraded system structure n Architectural evolution is concerned with evolving centralised to distributed architectures n A distributed user interface can be supported using screen management middleware 114
Configuration Management 115
Topics covered n Configuration management planning n Change management n Version and release management n System building n CASE tools for configuration management 116
Configuration management n New versions of software systems are created as they change For different machines/OS n Offering different functionality n Tailored for particular user requirements n n Configuration management is concerned with managing evolving software systems System change is a team activity n CM aims to control the costs and effort involved in making changes to a system n 117
Concurrent development and testing n A time for delivery of system components is agreed n A new version of a system is built from these components by compiling and linking them n This new version is delivered for testing using pre-defined tests n Faults that are discovered during testing are documented and returned to the system developers 118
Configuration management planning n All products of the software process may have to be managed Specifications n Designs n Programs n Test data n User manuals n n Thousands of separate documents are generated for a large software system 119
The CM plan n Defines the types of documents to be managed and a document naming scheme n Defines who takes responsibility for the CM procedures and creation of baselines n Defines policies for change control and version management n Defines the CM records which must be maintained 120
The CM plan n Describes the tools which should be used to assist the CM process and any limitations on their use n Defines the process of tool use n Defines the CM database used to record configuration information n May include information such as the CM of external software, process auditing, etc. 121
Change management n Software systems are subject to continual change requests From users n From developers n From market forces n n Change management is concerned with keeping managing of these changes and ensuring that they are implemented in the most cost-effective way 122
Change request form 123
Change tracking tools n A major problem in change management is tracking change status n Change tracking tools keep track the status of each change request and automatically ensure that change requests are sent to the right people at the right time. n Integrated with E-mail systems allowing electronic change request distribution 124
Version and release management n Invent identification scheme for system versions n Plan when new system version is to be produced n Ensure that version management procedures and tools are properly applied n Plan and distribute new system releases 125
Versions/variants/releases n Version An instance of a system which is functionally distinct in some way from other system instances n Variant An instance of a system which is functionally identical but non-functionally distinct from other instances of a system n Release An instance of a system which is distributed to users outside of the development team 126
Version identification n Procedures for version identification should define an unambiguous way of identifying component versions n Three basic techniques for component identification Version numbering n Attribute-based identification n Change-oriented identification n 127
Version numbering n Simple naming scheme uses a linear derivation e. g. V 1, V 1. 2, V 2. 1, V 2. 2 etc. n Actual derivation structure is a tree or a network rather than a sequence n Names are not meaningful. n Hierarchical naming scheme may be better 128
Release management n Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes n They must also incorporate new system functionality n Release planning is concerned with when to issue a system version as a release 129
System releases n Not just a set of executable programs n May also include n Configuration files defining how the release is configured for a particular installation n Data files needed for system operation n An installation program or shell script to install the system on target hardware n Electronic and paper documentation n Packaging and associated publicity n Systems are now normally released on CD-ROM or as downloadable installation files from the web 130
System building n The process of compiling and linking software components into an executable system n Different systems are built from different combinations of components n Invariably supported by automated tools that are driven by ‘build scripts’ 131
System building 132
CASE tools for configuration management n CM processes are standardised and involve applying pre-defined procedures n Large amounts of data must be managed n CASE tool support for CM is therefore essential n Mature CASE tools to support configuration management are available ranging from stand-alone tools to integrated CM workbenches 133
Change management tools n Change management is a procedural process so it can be modelled and integrated with a version management system n Change management tools Form editor to support processing the change request forms n Workflow system to define who does what and to automate information transfer n Change database that manages change proposals and is linked to a VM system n 134
Version management tools n Version and release identification n Systems assign identifiers automatically when a new version is submitted to the system n Storage management. n System stores the differences between versions rather than all the version code n Change history recording n Record reasons for version creation n Independent development n Only one version at a time may be checked out for change. Parallel working on different versions 135
System building n Building a large system is computationally expensive and may take several hours n Hundreds of files may be involved n System building tools may provide A dependency specification language and interpreter n Tool selection and instantiation support n Distributed compilation n Derived object management n 136
Key points n Configuration management is the management of system change to software products n A formal document naming scheme should be established and documents should be managed in a database n The configuration data base should record information about changes and change requests n A consistent scheme of version identification should be established using version numbers, attributes or change sets 137
Key points n System releases include executable code, data, configuration files and documentation n System building involves assembling components into a system n CASE tools are available to support all CM activities n CASE tools may be stand-alone tools or may be integrated systems which integrate support for version management, system building and change management 138
Методология RUP (Rational Unified Process) - основные принципы n Итеративная разработка n Управление требованиями n Компонентная архитектура n Визуальное моделирование n Управление изменениями n Постоянный контроль качества 139
RUP: фазы ЖЦ и процессы (дисциплины) 140
RUP: 4 фазы жизненного цикла n Inception – начало проекта (эскизное проектирование) n Elaboration – детализация системы (разработка технического задания) n Construction – создание системы (рабочее проектирование) n Transition – внедрение системы (приемосдаточные испытания) 141
RUP: фазы ЖЦ и процессы n Каждая фаза может быть разбита на итерации (итеративный подход). Каждая итерация завершается выпуском работающего прототипа конечной системы. Это позволяет правильно оценивать риски проекта и эффективно снижать или устранять их на ранних стадиях разработки. n На вертикальной оси диаграммы представлена статическая структура RUP - процессы жизненного цикла типового проекта или дисциплины RUP 142
RUP: процессы n Основные процессы RUP: n Бизнес моделирование n Управление требованиями n Анализ и проектирование n Реализация n Тестирование n Развертывание n Вспомогательные процессы RUP: n Конфигурационное управление изменениями n Управление проектом n Управление средой разработки 143
Особенности RUP n Для каждого процесса разработки методология RUP определяет ролевой состав проектной команды и описывает регламент действий, потоки событий и получаемые результаты и документы (артефакты процесса). Интегральная интенсивность этих действий в зависимости от времени показана на диаграмме RUP для всех основных и вспомогательных процессов. n В отличие от каскадной модели в методологии RUP все процессы выполняются практически во всех фазах жизненного цикла проекта. Однако в зависимости от фазы меняются текущие цели проекта и, соответственно, соотношение между объемами работ, соответствующих различным 144 процессам.
Инструменты коллективной разработки IBM Rational 145
Rational Suite: инструменты n n IBM Rational Clear. Case – лучшее в своем классе средство конфигурационного управления IBM Rational Clear. Quest - средство для управления запросами на изменения проекта и n IBM Rational Project. Console – средство управления проектом, представляет метрики проекта в виде наглядного Web-сайта IBM Rational Purify. Plus – набор средств отладки программного кода IBM Rational Rapid Developer – среда быстрой разработки приложений на платформе J 2 EE для многозвенной архитектуры n n отслеживание дефектов в проекте n n IBM Rational Requisite. Pro – коллективное средство управления требованиями проекта IBM Rational Robot – средство для автоматизированного функционального тестирования n IBM Rational Rose - CASE-средство визуального проектирования информационных систем, n IBM Rational Rose Real. Time – средство визуального моделирования и проектирования встроенных систем и систем реального времени n IBM Rational So. DA – автоматизация разработки и обновления проектной документации n IBM Rational Team. Test – средство для автоматизированного функционального и нагрузочного тестирования приложений IBM Rational Test. Real. Time – набор средств для автоматизированного тестирования и отладки встроенных систем и систем реального времени n n n приложений позволяющее моделировать как бизнес процессы, так и различные компоненты ПО IBM Rational Test. Manager – средство управления задачами функционального и нагрузочного тестирования IBM Rational Unified Process – практическое Web-руководство по методологии программной инженерии и обобщению лучшего мирового опыта в области промышленной разработки ПО. 146
Наборы инструментов Rational Suite n IBM Rational Suite Analyst Studio – бизнес-анализ n n n предметной области, управление требованиями, проектирование структуры баз данных IBM Rational Suite Development Studio – проектирование, разработка и отладка исходного кода ПО IBM Rational Suite Development Studio Real. Time – проектирование, разработка и отладка встроенных приложений IBM Rational Suite Test. Studio – функциональное, регрессионное и нагрузочное тестирование IBM Rational Suite Enterprise – полный набор инструментов для универсалов (не включает продукты семейства Rational XDE) IBM Rational Suite Team. Unifying. Platform – набор инструментов, объединяющих проектную команду, является основой всех перечисленных выше ролевых наборов. 147