VO Software Engineering

Transcription

1 Administrative Issues Univ.Prof. Dr. Peter Auer Chair for Information Technology Lecture Thursday 10:15 11:45 Project Lab Montag 16:00 19:00 Literature Helmut Balzert, Lehrbuch der Software-Technik (Band 1, 2. Auflage), Spektrum Verlag. Ian Sommerville, Software Engineering, 7th edition. 1 2 Projects and Grades Content of the lectures Software Engineering project Everyone is required to do a project. For petroleum engineers this might be done in connection with another course. This is a team project (up to 5 students). Grades 1. Oral examination (in groups by project teams) 2. Partially based on and accessing the contribution to the project The lecture should enable you to Analyze the requirements for a software system Specify a software system together with software experts Access the quality of a software system (will not be fully covered in this lecture). Emphasis on principles and methods for the specification and analysis of software systems and their requirements. Focused on an object oriented approach using UML

2 Importance of software Software and Software Engineering Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost. More and more systems are software controlled. Maintenance of software is often more expensive than its development. For systems with a long life, maintenance costs may be several times the development costs. Software engineering is concerned with methods and tools for professional and cost-effective software development and management. 5 6 What is software? What is software engineering? Computer programs and associated documentation such as requirements, design models and user manuals. Software is immaterial and hard to measure. New software can be created by developing new programs, configuring generic software systems or reusing existing software. Software engineering is an engineering discipline that is concerned with all aspects of software production: Systematic and organised approach Appropriate tools and techniques Includes Software development Software management Software quality assurance 7 8 2

3 Software vs. system engineering System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Complex relationships with organisational objectives: The extent to which the system supports organisational objectives does not just depend on the system itself. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system. Software engineering process Concerned with the services provided by the system, constraints on its construction and operation, and the ways in which it is used. Specification and analysis What the system should do and its development constraints Design and implementation Production of the software system Validation Checking that the software is what the customer wants Deployment Maintenance Changing the software in response to changing demands 9 10 Process models provide (1) Software Engineering Models Structured approaches to software development: Descriptions of (graphical) system models to be used; Rules: Constraints applied to system models; Recommendations and advice on good design practice; Process guidance: Sequence of activities

4 Process models provide (2) Non-process: Code-and-fix Simplified representations of software processes (presented from a specific perspective). Workflow perspective - sequence of activities; Data-flow perspective - information flow; Role/action perspective - who does what. Generic process models Waterfall model, Evolutionary development, Component-based software engineering. Write the program and find the bugs Problems: Hard to find errors (in particular those resulting from the interaction of different components) Design phase Software does not fit the customer s needs Specification and analysis phase Waterfall model The V process model

5 Waterfall and V-model Software is developed in phases Results from one phase are used in the next phase Feedback between the phases Better integration of quality assurance and testing in the V-model Drawbacks of the waterfall and V-model Completion of one phase is necessary for next phase Inflexibility Difficult to accommodate changing customer requirements Appropriate only when the requirements are well-understood and changes will be limited. Mostly used for large system developed at several sites Evolutionary development System is developed in several versions with increasing functionality Zeit Teilprodukt 1 bzw. Produkt (Version 0) (Ker n) Teilprodukt 2 Teilprodukt 1 + Teilprodukt 2 bzw. Produkt (Version 1) Teilprodukt 2 Teilprodukt 1 + Teilprodukt 2 + Teilprodukt 3 = Produkt bzw. Produkt (Version 2) Teilprodukt 3 Evolutionary development methods Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with wellunderstood requirements and add new features as proposed by the customer. Throw-away prototyping Objective is to understand the system requirements. Could start with poorly understood requirements and clarify the details later

6 Advantages of evolutionary development Software is developed step by step. Customer gets working versions with added functionality frequently. Well suited, if customer needs are not clear:»i can't tell you what I want, but I'll know it when I see it«user requirements are prioritised and the highest priority requirements are included in early increments. Code driven development: Building working versions. The highest priority services receive most testing. Lower risk/cost of overall project failure. Problems of evolutionary development Special skills (e.g. for rapid prototyping) may be required Poor structure (of process and system) System architecture might be not sufficiently flexible and extendible Start with a complete requirement specification, but design and implement only part of the requirements Well suited for Small or medium-size interactive systems or parts of large systems (e.g. the user interface) Short-lifetime systems Component-based software engineering Based on systematic reuse where systems are integrated from existing components or commercial-off-the-shelf systems. Process stages Requirement analysis; Component analysis; Requirements modification; System design with reuse; Development and integration. This approach is becoming increasingly used as component standards have emerged. Development process iteration System requirements evolve in the course of a project. Process iterations where earlier stages are reworked are always part of the process for large systems

7 The Rational Unified Process RUP phase model A modern process model derived from work on UML (Unified Modeling Language). Typically 3 perspectives: What: Static perspective shows process activities; When: Dynamic perspective shows phases over time; How: Practice perspective that suggests good practice. Inception: Establish the business case for the system. Elaboration: Develop an understanding of the problem domain and the system architecture. Construction: System design, programming and testing. Transition: Deploy the system in its operating environment RUP good practice Key points (software engineering models) Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software Software processes are the activities involved in producing and evolving a software system. General activities are specification, design, implementation, validation and evolution. Generic process models describe the organisation of software processes: Waterfall and V-model, evolutionary development, component-based software engineering, RUP

8 Requirement specification Software Requirements The process of establishing what services are required and the constraints on the system s operation and development. Two main perspectives: User requirements System requirements What is a requirement? User and system requirement example It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System requirements A structured document setting out detailed descriptions of the system s functions, services and operational constraints. Defines what should be implemented and thus may be part of a contract between client and contractor

9 Requirements and design Spiral process model Requirements engineering and system design are inextricably linked. Initial design may be necessary to structure the requirements. As you do design, you learn more about the requirements Organizations/people/systems Systems are intended to help deliver some organizational or business goal. If you do not understand the organizational environment where a system is used, the system is less likely to meet the real needs of the business and its users. Requirements problems Complex systems are usually developed to address wicked problems Problems that are not fully understood; They change as the system is being specified. Must anticipate developments over the lifetime of the system

10 Requirements readers User requirements definition Define overall organizational objectives for the system. Define functional requirements (in an abstract way). Define general non-functional system properties. Define undesirable characteristics and unacceptable system behaviour Functional requirements Describe system functionality or system services. How the system should react to particular inputs and how the system should behave in particular situations. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail. Non-functional requirements Define system properties and constraints e.g. reliability, response time and storage requirements. Software process requirements may also be specified, e.g. mandating a particular CASE system, programming language or development method. Possibly also external requirements e.g. interoperability requirements, legislative requirements, etc. Non-functional requirements may be critical. If these are not met, the system is useless

11 Example: LIBSYS (user requirement) A library system that provides a single interface to a number of databases of articles in different libraries. [Organizational objective] Users can search for, download and print these articles for personal study. [Functional requirement] Examples: LIBSYS (non-functional) The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets. The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95. The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system Domain requirements Derived from the application domain and describe system characteristics and features that reflect the domain. Domain requirements may be new functional or nonfunctional requirements. If domain requirements are not satisfied, the system may be unusable. Examples: LIBSYS: Because of copyright restrictions, some documents must be printed and deleted immediately on arrival. Specific calculations. Guidelines for writing requirements Invent a standard format and use it for all requirements. Use language/words in a consistent way. Example: image picture photo Use text highlighting to identify key parts of the requirement. Avoid the use of computer jargon

12 User requirements in natural language Structured language specifications Problems Lack of clarity Precision is difficult without making the document difficult to read. Requirements confusion Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation Several different requirements may be expressed together. Alternatives to natural language Structured language specification (forms) Graphical models Tables The freedom of the requirements writer is limited by a predefined template for requirements. All requirements are written in a standard way. The terminology used in the description may be limited. The advantage is that most of the expressiveness of natural language is maintained but a degree of uniformity is imposed on the specification Supplements to natural language Key points (Requirements) Graphical models Useful when you need to show state changes or when you need to describe a sequence of actions. Several different graphical models. Tabular specification Particularly useful when you have to define a number of alternatives. Requirements set out what the system should do and define constraints on its operation and implementation. Functional requirements define services the system should provide. Non-functional requirements constrain the system being developed or the development process. User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams