Está en la página 1de 72

Ingeniería de Software

Capitulo 1. Introducción a la ingeniería de


Software
Profesor: Cristian Pérez C.
Primer Semestre 2010
Planificación
Evaluaciones:

 1 trabajo grupal con disertación


 3 Certámenes

Camilo, Katty = Tema actualidad informática 5 minutos cada uno


Objetivos del curso
 Entender el concepto de ingeniería de software.
 Comprender la diferencia entre producto y proceso.
 Comprender los conceptos relacionados con las
etapas del desarrollo del software, de manera que el
alumno tenga la flexibilidad para participar dentro un
proyecto en cualquiera de ellas .
 Comprender conceptualmente algunas metodologías
utilizadas para el desarrollo del software .
Contenidos
 Introducción a la Ingeniería de Software.
 Proceso del software.
 Toma de Requerimientos y Análisis del Sistema.
 Diseño de un Sistema.
 Implementación de un Sistema.
 Prueba de un Sistema.
 Liberación y Mantención del producto de
software.
Introducción – Rol del Ingeniero de Software
 Porque la Ingeniería de Software?
 Error Y2K
 Importancia de hoy en día del software
 Afecta en todas las áreas del ser humano
 Elaborar un producto sólido

 Tiene que tener una buena comunicación con el cliente y


presentar el problema.
 Traducir las ideas de los usuarios, es decir, traducir los
problemas en
 especificaciones precisas.
 Tiene que conocer las diferentes metodologías de
modelado.
Introducción – Rol del Ingeniero de Software

 Debe tener conocimientos de algoritmos y


estructuras de datos.
 Ser capaz de trabajar en pequeño (solo) y en
grande (equipo).
 Debe ser capaz de resolver problemas.
 Utilizar la menor cantidad de recursos.
 Debe ser buen programador.
 Debe tomar decisiones.
Historia de la ingeniería de Software

 Los primeros años (años 50´s – mediados 60´s)


 Orientación por lotes (batch)
 Distribución limitada
 Software a la medida
 Segunda era (mediados 60’ s – mediados 70´s)
 Sistemas multi – usuario
 Sistemas en tiempo real
 Uso de bases de datos
 Productos de software
Historia de la ingeniería de Software
 Tercera era (70´s – 80´s)
 Sistemas distribuidos.
 Incorporación de inteligencia.
 Hardware de bajo costo.
 Cuarta era (90´s – )
 Sistemas personales potentes.
 Tecnologías orientadas a objetos.
 Sistemas expertos.
 Redes Neuronales Artificiales.
 Computación en paralelo.
 Redes de computadoras.
¿Qué es Software?

 “Código fuente más todos aquellos


productos de trabajo (o artefactos)
asociados que se han generado
durante el desarrollo y mantención”.
¿Que es la Ingeniería?
 “Arte de aplicar los conocimientos
científicos a la invención y
perfeccionamiento de la técnica
industrial”.
Ingeniería de Software
 “Es una disciplina que comprende todos los
aspectos de la producción de software desde
las etapas iniciales de la especificación del
sistema, hasta el mantenimiento de éste
después de que se utiliza”. [Sommerville 2002]

 “La ingeniería de software es una disciplina de


diseño y desarrollo de software de alta calidad”.
[Pfleeger 2002]
¿Porqué nace la ingeniería del
SW?
 No nos hemos tomado el tiempo para recolectar
datos durante el proceso de diseño de software.
 Generalmente hay descontento en los usuarios.
 Casi no hay calidad en el diseño del software.
 El software existente es muy difícil de
mantener.
Tipos de Software
 Software de Sistemas. Programas que sirven a otros programas.
Ejemplo: compiladores, editores, librerías, etc.
 Software de tiempo real. Mide, controla y/o analiza sucesos
conforme ocurren.
 Software administrativo o de Gestión.
 Software de ingeniería y científico.
 Software empotrado. Reside en memorias de “solo lectura” y se
utiliza para controlar productos. Ejecuta funciones muy limitadas.
 Software de computadoras personales. Procesadores de texto,
hojas de cálculo, etc.
 Software basado en Web.
 Software de Inteligencia Artificial.
Áreas informáticas relacionadas
con la Ingeniería de SW
 Sistemas Operativos: Los primeros sistemas
complejos que existieron fueron los sistemas
operativos.
 Base de Datos: En este campo la Ingeniería de
software se relaciona en el diseño del modelo
de datos.
 Inteligencia Artificial: Para crear los modelos
matemáticos y lógicos se necesita realizar un
análisis del problema y luego diseñar la
solución.
Ciclo de Vida del Software
 Todo producto de Software tiene un ciclo:
Ciclo de Vida del Software
 Un producto de software nace cuando surge una
necesidad.
 La necesidad se transforma en producto de
SW.
 Luego se usa y explota.
 Cuando llega un momento donde es más difícil
agregar nuevas cosas que crear otro nuevo.
Con esto se llega a la muerte del sistema.
Trabajo de Investigación : El
proceso de Software
 Contenido del Trabajo
 Tapa:
Título del Trabajo
Nombres Integrantes del Grupo
Nombre Profesor
Fecha Entrega
Índice:
Índice del Trabajo
 Introducción:
Propósito:Establecer el propósito de este trabajo y los temas que se abordarán en
él.
Alcance:Breve descripción del objetivo principal del trabajo, dejando bien en claro
cual es el tema que se va a abordar y que es lo que no se tratará en el trabajo.
Definiciones, Acrónimos y Abreviaciones: Esta subsección contiene las
definiciones de todos los términos, acrónimos y abreviaciones necesarias para realizar
una correcta interpretación de este documento.
Contenido del Trabajo

Desarrollo de la Investigación:
En esta parte del trabajo se desarrolla el tema
principal del trabajo. Para esto se pueden hacer
referencia a cualquier tipo de documentación. Esto
con el fin de ponernos en el contexto y luego se
DEBE desarrollar una idea de lo antes referenciado.

Conclusiones:
En esta parte se debe expresar lo aprendido en
el trabajo. Dando opiniones personales según lo
descrito en el punto “Desarrollo de la investigación”.
Contenido del Trabajo
 Referencias:
Esta parte debe contener una lista completa de todos los
documentos que son referenciados en alguna parte al interior
del trabajo. En el trabajo se debe señalar de la siguiente
manera:
[CPC-06] : Cristian Pérez Cortés, “Trabajo de Investigación:El
proceso de Software” , 2006.

 Anexos:
Información complementaria del trabajo, que puede servir
para ayudar a explicar algún tema que esté relacionado con el
objetivo del trabajo.
Formato del Trabajo
 Fuente Trabajo: Arial 12
 Fuente Títulos: Arial 14
 Tamaño Hoja: Carta
 Interlineado:1.5
 Texto :Justificado
 Cabecera logo institución
Definición de Grupos de Trabajo
(máx 3 personas)
1. Marambio, Leiva, budini
2. Castillo, villena
3. Del Valle, Rosales
4. Valenzuela, Malhue
5. Avendaño, Carrasco
6. Gajardo, Valdenegro, Ortiz
7. Bahamondes, Soto
8. González, Fonseca
9. Loyola, Alarcón
10. Velasquez, González Castro
11. O.Vasquez, d. Gibbs
12. J Gomez, Candia
13. Hector Campos, b isla
14. Jose chiple, Dinamarca
Tema Trabajo: El proceso de
Software
 Tema 1:Modelo Cascada (Lineal Secuencial): 6-
7 -13
 Tema 2:Modelo Evolutivo: 5-8 -14
 Tema 3:Prototipado (construcción de
prototipos): 4-9
 Tema 4:Transformación formal (Métodos
formales) : 3-10
 Tema 5:Desarrollo Basado en Reutilización: 2-
11
 Tema 6:Desarrollo Orientado Objetos: 1-12
Ingeniería de Software

Capítulo 2:
Software : naturaleza y calidades
Proceso / Producto
 La relación proceso-producto, no es 100% directa.
 Para llegar a un buen producto hay que tener una
buena materia prima.
 El producto de software es muy maleable, es decir, muy
fácil de modificar, por esto se le ponen restricciones.
 El producto de SW es el resultado de una actividad muy
“intensiva”, esto en la actividad humana sería la materia
gris.
 El producto de SW es el resultado del trabajo “intensivo”
del ingeniero de SW.
 El trabajo del ingeniero de SW resuelve problemas del
mundo real.
Calidad del software
Existen calidades internas y externas.

 Calidad interna: Es aquella calidad que les preocupa a


los desarrolladores.
 Calidad externa: Es aquella calidad que les es visibles a
los usuarios finales.

En lo que respecta a las calidades, la más


importante es la externa.
Lo más fácil de manejar para el ingeniero de SW es
la calidad interna.
Calidades Representativas
Representa lo más importante en
calidad, tanto producto y proceso.

 Correctitud: El software debe entregar los


resultados correctos.
 Confiabilidad: Es un concepto más amplio, tiene
que ver con lo que se espera del software.
 Robustez: Apunta a que el sistema no se cae,
incluso bajo condiciones extremas.
Calidades Representativas
 Representa lo más importante en calidad, tanto
producto y proceso.
 Correctitud: El software debe entregar los
resultados correctos.
 Confiabilidad: Es un concepto más amplio, tiene
que ver con lo que se espera del software.
 Robustez: Apunta a que el sistema no se cae,
incluso bajo condicionesextremas.
Correctitud
 A estas tres ideas se les asocia que yo espero
un cierto funcionamiento.
 Un sistema es funcionalmente correcto si se
comporta de acuerdo con las especificaciones
de las funcionalidades que debe proveer.
(Especificación de Requerimientos funcional).
 Además se asume que el software debe estar
siempre disponible.
 La correctitud debe ser entregada de manera
no ambigua.
Correctitud
 En la mayoría de los sistemas de software no existe
esta especificación.
 La correctitud es una característica deseada en un
producto de software.
 Es un problema no contar con ella.
 La correctitud es una propiedad matemática, que
establece la equivalencia entre el producto de software y
la especificación de requerimientos.
 La correctitud es solo aplicable cuando la especificación
de requerimientos está formalmente especificada.
Confiabilidad
 Informacionalmente, el SW es confiable si el usuario puede confiar en él.
 La confiabilidad va a estar dada por la probabilidad de que el software
opere como se espera dentro de un tiempo determinado.
 La correctitud es una seguridad absoluta, es una propiedad binaria, “está
 bien o está mal”.
 En cambio la confiabilidad es “relativa”, porque si en el sistema existe un
error, pero no es muy serio, el sistema sigue siendo confiable.
 La confiabilidad también es una propiedad deseable en un sistema de SW.
 Los productos no confiables tiendes generalmente a desaparecer
rápidamente del mercado, porque un producto no confiable no es
comprado.
Confiabilidad
 El tema de la confiabilidad en los Productos de SW es menos
exigente que en otros tipos de productos físicos, claramente,
dependiendo del ámbito del software.

El dibujo indica que un sistema correcto tiene que ser confiable y


también que correctitud implica confiabilidad, pero no viceversa.
Robustez
 Un sistema es robusto si se comporta
razonablemente, en otras palabras, se comporta
como uno espera que se comporte.
 Un sistema robusto se tiene que comportar
razonablemente, incluso en situaciones no
definidas o anticipadas anteriormente en la
especificación de requerimientos.
Performance (Rendimiento)
 A menudo, en lo que se refiere a ingeniería de
SW, se trata de igual manera a la eficiencia con
los recursos.
 Si se utiliza un buen uso de los recursos se
dice que el sistema es eficiente (rinde bien).
 El tiempo y el espacio son unos de los recursos
importantes que representan al performance.
 El performance es importante porque afecta a
la viabilidad del proyecto.
Performance (Rendimiento)
 La eficiencia afecta a la escalabilidad del
sistema.
 La escalabilidad es la capacidad de utilizar
software a mayor escala.
 La performance de un sistema se puede
evaluar de diferentes formas:
 Viendo la eficiencia de un algoritmo.
 Haciendo una simulación del sistema.
 Pruebas de estrés.
Amistocidad con el usuario
 Un sistema de SW es amistoso con el usuario, si los
usuarios humanos que usan el SW lo encuentran fácil
de usar.
 El grado de amistocidad con el usuario de un SW, va a
depender de la experiencia del usuario.
 Algo que es básico para la amistocidad con el usuario
es la “Interfáz”, existen distintos tipos de interfaces
(mouse, teclado, pantalla, voz, etc.).
 Viendo la eficiencia de un algoritmo.
 Haciendo una simulación del sistema.
Facilidad de verificación
 Un sistema de software es verificable, si sus
propiedades pueden ser verificadas fácilmente
(correctitud, performance, etc).
 La correctitud y la performance como
propiedades, nos gustaría poder verificarlas
antes de que el software sea utilizado.
 Es usualmente una calidad interna, es el
desarrollador el que ve si el software está
correcto.
TRABAJO PRACTICO
 1. Introducción
 El objetivo del trabajo es la aplicación de los conceptos presentados en la teoría
relacionados principalmente con la fase de análisis de requerimientos del proceso de
 desarrollo de software.
 A partir de las descripciones entregadas, cada grupo deberá realizar las tareas
 solicitadas
 1.1 Descripción del problema.
 La tienda DvdHome se dedica a la arriendo y venta de películas en formato dvd
 actualmente tiene toda la información del negocio de manera manual (inventario de
 películas, clientes y proveedores).Lamentablemente la tienda ha sufrido constantes
 pérdidas de productos, atrasos en la entregas de los arriendos por parte de los
 clientes, pérdidas de fichas de clientes, pérdidas de información de los proveedores,
 problemas con el inventario de la tienda y multas impagas.
 El objetivo de la tienda es implementar un sistema que integre toda la información
 relacionada con el negocio de arriendo y venta de películas.
 Objetivos de negocio.
 Con el fin de superar los problemas y limitaciones de la situación actual, los
 responsables de DvdHome han llegado a la conclusión de que es necesario
 desarrollar un sistema de información que le aporte los siguientes
beneficios:
 1. Integrar todo el proceso de negocio en un único sistema de información,
accesible y comprensible para todo el personal involucrado.
 2. Mejorar la eficacia y la fiabilidad de las diferentes actividades del proceso
de negocio, garantizando que la información del inventario se encuentra
permanentemente actualizada.
 4. Integrar la información generada por el proceso de negocio, eliminando
 redundancias e inconsistencias en la misma.
 5. Garantizar que solamente los usuarios autorizados acceden a
información sensible.
 Requerimientos funcionales
 El presente documento propone la informatización del sistema de gestión de la tienda DvdHome.
Se pretende diseñar e implementar este sistema en el que:
 · El administrador de la tienda es el encargado de realizar pedidos a los proveedores
consultando si es necesario, las fichas de los productos.
 · Se pueda mantener las diferentes películas que adquiere la tienda.
 · Se realice el mantenimiento de la información de los proveedores de la tienda.
 · Se realice el mantenimiento de la información de los clientes de la tienda.
 · Se gestionen las entradas de los productos en la tienda y su salida hacia los diferentes clientes
que posee la tienda(inventario de películas).
 · Se debe llevar un control sobre los arriendos de cada cliente (tiempo de arriendo, multas,
compras de películas).
 Información anexa
 Las películas que son estrenos son arrendadas pro 24 hrs, pasado ese tiempo se aplicará multa
de $1000 por día de atraso.
 Las películas que no son estrenos son arrendadas por 48 hrs pasado ese tiempo se aplicará
multa de $1000 por día de atraso.
 Los clientes que posean multas vigentes no podrán acceder a arrendar películas
 Tareas a realizar
 · Identificar módulos del sistema(subsistemas)
 · Identificar los usuarios del sistema(actores) y sus objetivos(roles)
 · Realizar una descripción (textual) de cada funcionalidad que debería tener
el sistema definiendo las entradas y salidas de datos según los
requerimientos funcionales definidos anteriormente.
 Observaciones
 · Los datos que debe manejar el sistema para cada funcionalidad, deberán
ser definidos por los alumnos en base a la información relevante que
considere que deba manejar el sistema, por ejemplo si existe el concepto
producto, este debiera tener datos tales como id del producto, descripción
del producto, cantidad, etc.(no es necesario definir tipos de datos) · Cada
trabajo debe entregarse impreso, no se aceptarán trabajos manuscritos,
con hojas sueltas y sin la debida identificación de la asignatura a la
corresponde, profesor y nombre de los alumnos.

También podría gustarte