It is the fuel of modern life Business are run Government rule Scientists Industries Education However, building and maintaining software is hard and getting harder

The name “Software Engineering” was noticed in 1968 There is a problem in every software project: delivering the product on time, within budget, as the product owner’s expectations

Yes, normal engineers for buildings and bridges for example, have faced similar examples, risks, solutions. But we are not so lucky So what is the problem, really? Complexity Change

Inaccurate understanding of customer needs Inability to deal with changing requirements Modules that do not fit together Software that are hard to maintain/extend Poor Quality Testing….normally should cost 40% Unacceptable performance Technology change and team- member change over time in long period projects

It is an engineering discipline that is concerned with all aspects of software production

Good software should: Deliver the required functionality Efficient: does not waste voluble resources, response time Usable Dependable: reliable, secure, and safe. Maintainable Within budget and time

Software Engineers need to understand the environment in which the system has to operate They only need to know the application domain concepts relevant to the system They need to build a model of the application domain

Then they need to understand the system they want to build They need to build a model of the solution domain We will discuss modelling in more detail in chapter 2 using UML

Engineers search for solutions often by trial and error and with limited resources 1. Formulate the problem 2. Analyse the problem 3. Search for solutions 4. Decide on appropriate solution 5. Specify solution

Requirements elicitation Requirements analysis System Design Object design Implementation

It is not linear Avoid the mistakes in Water Fall process Risk-Based development IID UP RUP XP

Assumptions that developers make about a system change constantly Sometimes, new changes are triggered for solution domain To incorporate these new changes, we need to understand the context for each design decision made.

Participant: all persons involved in a project Role: set of responsibilities System: collection of interconnected parts Model: abstraction of the system Goto figure 1-1

Requirements specify a set of features that the system must have. A functional requirement is a specification of a function that the system must support, Nonfunctional requirement: is a constraint on the operation of the system that is not related directly to a function of the system.

The user must be able to purchase tickets The user must be able to access tariff information The user must be provided feedback in less than one second The colors used in the interface should be consistent with the company LOGO System should be easy to use since users could be of different ages

Other nonfunctional requirements may include: using specific hardware platform for the system, security requirements, how the system should deal with failures and faults, and how to provide backward compatibility with an old system that the client is unwilling to retire.

Notation: a graphical or textual set of rules for representing a model (UML) Method: a repeatable technique that specifies the steps involved in solving a specific problem (Sorting Algorithm) Methodology: a collection of methods for solving a specific set of problems.