UNIVERSIDAD AMAZÓNICA DE PANDOAREA DE CIENCIAS Y TECNOLOGÍA

Programa de Ing. De Sistemas

1

Software Engineering: A Practitioner’s Approach, 6/e

Chapter 1Software and Software Engineering

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university levelwhen used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

2

Software’s Dual Role

Software is a product Delivers computing potential Produces, manages, acquires, modifies, displays, or transmits

information Software is a vehicle for delivering a product

Supports or directly provides system functionality Controls other programs (e.g., an operating system) Effects communications (e.g., networking software) Helps build other software (e.g., software tools)

3

What is Software?

4

Software is a set of items or objects that form a “configuration” that includes • programs • documents • data ...

What is Software?

software is engineered software doesn’t wear out software is complex

5

Wear vs. Deterioration

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

6

idealized curve

change

actual curve

Failurerate

Time

increased failurerate due to side effects

Software Applications system software application software engineering/scientific software embedded software product-line software WebApps (Web applications) AI software

7

Software—New Categories Ubiquitous computing—wireless networks Netsourcing—the Web as a computing engine Open source—”free” source code open to the computing

community (a blessing, but also a potential curse!) Also … (see Chapter 32)

Data mining Grid computing Cognitive machines Software for nanotechnologies

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

8

Legacy Software

software must be adapted to meet the needs of new computing environments or technology.

software must be enhanced to implement new business requirements.

software must be extended to make it interoperable with other more modern systems or databases.

software must be re-architected to make it viable within a network environment.

9

Why must it change?

Software Evolution Ley del cambio continuo (1974): Los sistemas de tipo electrónico

deben adaptarse en forma continua, de lo contrario se volveran menos satisfactorios a través del tiempo.

Ley de complejidad creciente (1974): Cuando un sistemade tipo electronico está en evolución, su complejidad se incrementa a menos que se realice el trabajo necesario para mantenerla o reducirla.

La ley de la autoregulación (1974): El proceso de evolucion de un sistema de tipo electrónico se autoregula con la distribución del producto y las mediciones del proceso cercanas a la normal.

La ley de la conservación de la escalabilidad organizacional (1980): La tasa de actividad global efectiva promedio en un sistema de tipo electrónico en evolución, no varía a lo largo del período de vida del producto.

10

Software Evolution La ley de la conservación de la familiaridad (1980): Cuando un sistema de tipo

electrónico está en evolución y se quiere un desarrollo satosfactorio, todos los involucrados con el sistema, como los desarrolladores, el personal de ventas y los usuarios, deben mantener el dominio sobre su contenido y comportamiento. El crecimiento excesivo disminuye ese dominio.

Ley del crecimiento contínuo (1980): El contenido funcional de los sistemas de tipo electrónico debe incremetarse en forma contínua para mantener la satisfacción del usuario a lo largo del período de vida del sistema.

Ley de la calidad decreciente(1996): La calidad de los sistemas de tipo electrónico debe incrementarse en forma contínua para mantener la satisfacción del usuario a lo largo del período de vida del sistema.

Ley del sistema de retroalimentación (1996): Los procesos de evolución de los sistemas de tipo electrónico constituyen sistemas de retroalimentación con niveles ciclos y agentes multiples y deben tratarse de forma que se obtengan mejorías significativas sobre cualquier base razonable.

11

Software Myths

Affect managers, customers and practitioners Are believable because they often have elements of truth, but … Invariably lead to bad decisions, therefore … Insist on reality as you navigate your way through software

engineering

12