Introduction to Software Engineering 1 Software Engineering Failures

Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches to constructing quality software with a limited budget and a given deadline in the context of constant change – Activities • Modeling activity • Problem-solving activity • Knowledge acquisition activity • Rationale-driven activity

Modeling • Focusing relevant details at each development stage • A model is an abstract representation of a system for answering questions about the system • Real world system: a set of phenomena • Problem model: a set of interdependent concepts describing those aspects of the real world relevant to the problem under consideration. • Model of problem domain vs. model of solution domain • OO methods: Problem D. model + Solution D. model 1 Objects and relationships in problem domain 2 Object and relationships in solution domain (extension from 1) • Software Development: identify and describe a system as a set of models to address the end user’s problem.

Problem Solving • Software engineering is an engineering activity • Rely empirical methods to evaluate the benefits of different alternatives represented as models • The engineering method: 1. Formulate the problem (requirements elicitation and 2. Analyze the problem analysis) 3. Search for solutions (system design and 4. Decide on the appropriate solution object design) 5. Specify the solution (implementation) • Activities: experimentation, pattern reuse, incremental evolution, reviews of problem and solution models

Knowledge Acquisition • In modeling application and solution domains – Data collection – Information organization – Knowledge formalization • Non-linear knowledge acquisition – Single piece of data can invalidate complete models – Linear software development process • Water fall model – Non-linear software process • Risk-based development – develop higher risks first • Issue-based development – Develop all issues in parallel

Rationale Driven • Rationale of the system – The context and rationale in which each design decision was made – To be captured and understood by software engineer – Represents a set of issue models with larger amount of information than the solution models – Not explicit (without explicitly evaluating different alternatives) – Enables software engineers to understand the implication of a proposed change when revising a decision. • Rationale management

3. Software Engineering Concepts • Participants and Roles – Role • • a set of responsibilities associated with a set of tasks assigned to a participant typical roles: end user, client, developer, project manager – Participant • any persons involved in the project • plays certain role(s) • Systems and Models – System: the underlying reality • example: ticket distributor for a train – Model: any abstraction of the reality • example: requirement, analysis, design, implementation models

• Work Products – Artifact produced during development – Internal work product • for the project’s internal consumption • any artifact not in the contract or requested by the client • example: test plan – Deliverable • for the client • defined prior to the start of the project and specified in the contract. • Activities, Tasks, and Resources – Activity or phases: a set of tasks for a special purpose such as requirement elicitation – Task: an atomic unit of work in terms of management, to be assigned to a developer. – Resources: assets to be used to accomplish work.

• Goals, Requirements and Constraints – Goals • • a high level principle to guide the project define the attributes of the system that are important primary goal and other goals of a project conflicting goals – Functional requirements • area of functionality that the system must support – Nonfunctional requirements • constraints on the operation of the system • examples: performance, reliability, security

• Notations, Methods, and Methodologies – Notation • a graphical or textual set of rules for representing a model • Example: UML for OO modeling, Z for system spec. – Method • A repeatable technique for solving a specific problem • Example: sorting algorithm, version control – Methodology • a collection of methods for solving a class of problems • decompose software process into activities • examples: Unified software development process, Object Modeling Technique, Catalysis.

4. Software Engineering Development Activities • Requirement elicitation (Client and Developer) – The client and developers define the purpose of the system – Result: description of actors and use cases for functional requirement – Example Use case name: Participating actor: Entry condition: Flow of events: Exit condition: Special requirements: Purchase. One. Way. Ticket Initialized by Traveler 1. Traveler stands in front of the ticket distributor at a station 2. Traveler selects the source and destination stations 3. Ticket. Distributor display the price of the ticket 4. Traveler inserts sufficient money 5. Ticket. Distributor issues the ticket and returns change 6. Traveler holds a valid ticket and the change If the transaction is not completed after 1 minute of inactivity, Ticket. Distributor returns all inserted money

– Nonfunctional requirements • Reliability: The ticket distributor should be available to traveler at least 95% of the time • Performance: The ticket distributor should provide feedback to the traveler within a second after the transaction has been selected. • Analysis (Developer) – produce a model of the system that is correct, complete, consistent, unambiguous, realistic, and verifiable. – transform the use cases into an object model that completely describes the system – discover ambiguities and inconsistencies

• System Design (Developer) – define the design goals – decompose the system into smaller subsystems that can be realized by individual teams. – Select strategies for building the system – results: • strategy descriptions • subsystem decomposition • deployment diagram • Object Design (developer) – define custom objects to bridge the gap between the analysis model and the system design platform • Implementation – translate the object model into source code

5. Managing Software Development • Communication – – – exchange models and documents report the status of work products provide feedback on the quality of work products raise and negotiate issues communicate decisions common convention and tool based • Rationale management – – – the problem addressed alternatives considered evaluation criteria used debate, consensus, and decision difficulty: update and maintenance

• Testing – find differences between the system and its models by execution with sample data – Unit testing • compare the object design model with each object and subsystem – Integration testing • compare the integrated subsystems with the system design – System testing • compare the system with the requirement model by running typical and exception cases

• Software Configuration Management – the process that monitors and controls changes in work products – Example changes • requirement changes – client new feature – development new/improved understanding • platform changes – new technology available • system changes – fault and repair – enable developer to track changes • configuration items to be individually revised • versions for evolution of configuration items and roll back – enable developers to control change • define baselines • assess and approve increments from the baselines

• Project management – oversight activities to ensure • the delivery of a high-quality system on time and within budget – plan and budget the project during negotiation with the client – hire developers and organize them into teams – monitor the status of the project – intervene when deviations occur • Software life Cycle – A general model of the software development process