ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Presentación del tema: "ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS"— Transcripción de la presentación:

1 ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS
Sesión 1 : Ingeniería de software

2 Temario ... Presentación de Silabo Prueba de Entrada Introducción
Metodologías Mensaje Final Preguntas

3 Presentación del Silabo
PRIMERA UNIDAD Lunes Jueves 01 LA INGENIERIA DE SOFTWARE 25.Ago 28.Ago 02 PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE 01.Set 04.Set 03 PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE 08.Set 11.Set 04 REQUERIMIENTOS 15.Set 18.Set 05 CASOS DE USO 22.Set 25.Set 06 INTRODUCCION A LA ORIENTACION A OBJETOS 29.Set 02.Oct SEGUNDA UNIDAD Lunes Jueves 07 DOCUMENTACION DIAGRAMAS DE MODELOS DE DOMINIO 06.Oct 09.Oct 08 COMPORTAMIENTOS DE OBJETOS 13. .Oct 16.oCT 09 AQUITECTURA DE HW. Y SW. 20. .Oct 23.Oct 10 DIAGRAMA E CLASE Y DIAGRAMAS DE COLABORACION 27. .Oct 30.Oct 11 EXAMEN PARCIAL 03.Nov 06.Nov

4 Presentación del Silabo
TERCERA UNIDAD Lunes Jueves 12 MODELO DE DISEÑO 10.Nov 13.Nov 13 PRUEBAS 17.Nov 20.Nov 14 METRICAS 24.Nov 27.Nov 15 SUSTENTACION DEL PROYECTO 01.Dic 04.Dic 16 EXAMEN FINAL 08.Dic 11.Dic 17 EXAMEN DE REZAGADOS Y SUSTITUTORIO 15.Dic 18.Dic REFERENCIA BIBLIOGRAFICA 005.1 P93 PRESSMAN, Roger. Ingeniería de Software. 6ta Edición. México D.F.: McGraw-Hill, p ISBN: J88 JOYANES, Luis. Programación en C ++. Madrid.: McGraw-Hill Interamericana, p ISBN: X J99 JOYANES, Luis. Programación en C, C ++, Java y UML. México D.F.: McGraw-Hill, p ISBN:

5 Prueba de Entrada

6 Introducción ...

7 Ingeniería Software Conjunto de conocimientos y técnicas científicas
Conjunto de instrucciones que permite al Hardware desempeñar trabajo útil.

8 ¿Qué es Ingeniería de Software?
Es una disciplina o área de la informática o ciencia de la computación, que ofrece conocimientos, técnicas y métodos para desarrollar y mantener software de calidad que resuelva problemas de todo tipo.

9 ¿Qué es Software de Calidad?
Es la aptitud de un producto o servicio para satisfacer la necesidades del usuario. Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

10 Calidad de Producto – ISO 9126 Características

11 Capas de la Ingeniería de Software
La Ing.Software es una tecnología multicapa Enfoque de Calidad Proceso Métodos Herramientas

12 Capas de la Ingeniería de Software
PROCESOS Es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería de software. Asegurando un Producto Excelente

13 Capas de la Ingeniería de Software
METODOS Indican como construir técnicamente el software Abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. HERRAMIENTAS Uso de tecnologías para asistir el desarrollo del software y asegurar el cumplimiento de los objetivos del software Proporcionan un enfoque automático / semiautomático para el proceso y para las metodologías.

14 El estado de desarrollo de software
La mayoría de los proyectos de desarrollo de software fallan Qué significa fallar? No cumplir los cronogramas No cumplir el presupuesto No satisfacer la funcionalidad requerida Demasiados defectos una vez en producción Demasiado frágil a los cambios ...

15 ¿Qué tipo de Problemas Surgen?
Retrasos en los proyectos. Falta de calidad. Incumplimiento con la funcionalidad acordada. Desarrolladores innovadores. Exceso de requerimientos y funcionalidad. Falta de planificación. Motivación débil, Falta de participación. No existe gestión de riesgos. ALLSOFT, S.A.. de C.V., 2002

16 La gestión tradicional en la ing. de software

17 Planificar y Evaluar Proyectos ...
¿Podré cumplir con los plazos? ¿Estaré dentro de lo presupuestado? ¿El cliente quedará satisfecho? Las Metodologías pueden ser la ayuda que necesitamos, si podemos usarlas correctamente !!

18 Metodologías ...

19 ¿Qué es una Metodología ...
Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente.

20 Metodología Monumental
Metodologías ... Metodología Monumental Existen hace mucho tiempo, no han sido exitosas porque son muy burócratas, se han orientado al documento más que a los resultados.

21 Metodologías ... Es necesario establecer un enfoque disciplinado y sistemático para desarrollar un proyecto de software. “Conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas, documentación y aspectos de formación para los desarrolladores de sistemas de información.” - Maddison 1983 “Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.” Las Metodologías nos describen: Cómo se debe dividir un proyecto en etapas. Qué tareas se llevan a cabo en cada una Qué salidas se producen y cuándo Qué restricciones se aplican Qué herramientas se van a utilizar Cómo se gestiona y controla un proyecto

22 Clasificación de las Metologías según el Modelo de Proceso
Modelos Convencionales o Tradicionales Cascada Incremental Prototipado Evolutivo Espiral Modelos de Desarrollo AGILES

23 Modelo lineal o Cascada
El modelo lineal presenta una estructura secuencial (de ahí el nombre de Modelo en cascada) Formada por seis fases o etapas: Definición de Requerimientos Análisis y Diseño Implementación Prueba Mantenimiento El desarrollo de las fases, se produce de manera secuencial. El Modelo en cascada no permite retroceder, por lo que se hace estrictamente necesario que al final de cada fase el analista de sistemas verifique y valide todo el trabajo realizado.

24 Modelo de Cascada (gráfica)
Definición de Requerimientos Análisis y Diseño y del Sistema Implementación y Prueba de unidades Integración y Prueba del Sistema Operación y Mantenimiento

25 Modelo incremental El modelo incremental es una evolución del modelo de cascada; viene a suplir el problema de no poder retroceder en las fases de desarrollo del software. Comienza con el análisis de los requisitos, tras el cual se prepara un primer diseño. Este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc del software, que de no convencer al cliente (o al propio programador) es rechazado y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones como sean necesarias.

26 Modelo incremental Análisis y Diseño Desarrollo Validación Versión
Actividades Concurrentes Versión Inicial Análisis y Diseño Análisis de Requerimientos Desarrollo Versiones Intermedias Versión Final Validación

27 Modelo de construcción de prototipos
Este modelo no secuencial, basado en la construcción de simulaciones o modelos ejecutables de aplicaciones más extensos Persigue un objetivo principal: la participación directa del cliente en la construcción del software requerido. Las fases son similares a las del modelo en cascada. El diseño rápido del prototipo se mostrará al cliente para que evalúe el trabajo realizado. El prototipo es una versión reducida del programa completo. Tras recoger los requisitos tanto del cliente como del sistema, se comienza con el diseño rápido del prototipo; El diseño completo obedece al previo diseño de pequeños prototipos específicos para funciones individuales. Más tarde, estos diseños serán unidos en uno sólo. Después, se procede a la construcción del mismo.

28 Modelo de construcción de prototipos
En Ingeniería de software la construcción de prototipos pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado es que el desarrollador puede iniciar el verdadero desarrollo del software.

29 Modelo espiral Este modelo, también no secuencial, es algo más complejo que los anteriores, aunque incluye un elemento muy útil e importante en el desarrollo del software: análisis de riesgos. El modelo en espiral concreta cuatro fases: Definición de Objetivos Evaluación y reducción de riesgos Desarrollo y Validación Planificación Si ésta última fase es afirmativa, el modelo continúa con la estructura del Ciclo de vida Clásico. Si el cliente no está satisfecho con el resultado, se cubre otra banda de la espiral y se vuelve a la primera fase (de planificación).

30 Modelo de Proceso de Espiral
Análisis de riesgos Definición de objetivos Análisis de Riesgos Análisis de Riesgos Análisis de Riesgos Prototipo Operacional Prototipo 3 Análisis de Riesgos Prototipo 2 Proto tipo 3 REVISIÓN Simulaciones, modelos y benchmarks Plan de requerimientos Plan del ciclo de vida Concepto de Operación Requeri mientos de SW Analisis Producto Diseño Detallado Plan de Desarrollo Validación de Requerimientos Codificación Prueba de Unidades Plan de Integración y Prueba Diseño Prueba de Integración Prueba de Aceptación Planificación Desarrollo y Pruebas Servicio

31 Metodologías ... Metodología Ágil
Son la justa medida entre “ningún proceso” y “demasiado proceso”, proporcionando simplemente “suficiente proceso” para que el esfuerzo valga la pena !!!

32 Modelos Tradicionales vs Agiles
Las Metodologías Tradicionales se centran especialmente el control del proceso, mediante un rigorosa definición de roles, actividades, artefactos y herramientas y notaciones para el modelado y documentación detallada. Muy efectivas y necesarias para proyectos grandes. Las Metodologías Agiles dan mayor prioridad al individuo, a la colaboración con el cliente y al desarrollo incremental del software con interacciones muy cortas. Metodología Ágil Metodología Tradicional Preparados para el cambio durante el proyecto Cierta resistencia al cambio Pocos artefactos Más artefactos Pocos roles Más roles No existe un contrato tradicional o al menos es bastante flexible Existe un contrato prefijado El cliente es parte del equipo de desarrollo (además in-situ) El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio Grupos grandes Menos énfasis en la arquitectura La arquitectura es esencial

33 Costo de los Cambio en la Costrucción de SW
A medida que avanza el tiempo, el costo es exponencial en el caso de la construcción mediante una metodología tradicional a diferencia de la metodología tradicional.

34 Principios de la Metología Agil
Satisfacer al cliente a través de tempranos y continuos entregables Abrazar el cambio, ya que los requisitos cambian todo el tiempo Entregar con frecuencia software que funcione, de dos semanas a un par de meses Trabajar juntos diariamente en el proyecto tanto las personas del negocio como los desarrolladores. El método mas eficiente y eficaz para transmitir información a los integrantes de un equipo de desarrollo, es conversación cara a cara La medida principal de avance es el software que funciona Construir proyectos alrededor de individuos motivados Asumir simplicidad Promover el desarrollo sostenible

35 ¿Cuando un método es ágil?
El desarrollo de software es Incremental liberaciones pequeñas y ciclos rápidos. Cooperativo clientes y desarrolladores trabajando juntos. Simple y Directo el método es fácil de aprender y modificar. Adaptativo es posible realizar cambios de último momento.

36 Reflexión Highsmith & Cockburn 2001
“Lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino que reconozcan a las personas como primeros implicados en el éxito de un proyecto, además de un intenso foco en la efectividad y la manejabilidad. Esto genera una nueva combinación de valores y principios que definen una visión ágil del mundo.”

37 Las ágiles más conocidas ...
XP (Programación Extrema) La familia Cristal de Cockburn Código Abierto ASD (Desarrollo de Software Adaptable) SCRUM FFD (Desarrollo Manejado por Rasgos) DSDM (Método de desarrollo de sistema dinámico) RUP (Rational Unified Process)

38 Programación Extrema (XP)
12 April 2017 Programación Extrema (XP) Creado por Kent Beck Metodología ágil Diseñada para entornos dinámicos Pensada para equipos pequeños (hasta 10 programadores) Orientada fuertemente hacia la codificación Énfasis en la comunicación informal, verbal Basado en cinco valores Comunicación Eficaz: Colaboración estrecha pero informal (verbal) entre los clientes y los desarrolladores Simplicidad: XP restringe a los desarrolladores para que diseñen solo para las necesidades inmediatas. Retroalimentación: XP usa las pruebas unitarias como táctica principal de pruebas Coraje y Valentía: Permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. HP Confidential

39 Proceso de la Programación Extrema
12 April 2017 Proceso de la Programación Extrema XP es orientado a objetos Esta compuesto en 4 actividades estructurales Planeación: inicia con escuchar en las que se crean las historias de los usuarios, este es indizada, y el cliente le da un valor or prioridad, luego el equipo de desarrollo le da un costo, medido en semanas de desarrollo. Si tiene mas de 3 semanas se le pide al cliente que subdivida la historia. Diseño: Sigue el principio de Mantelo Sencillo, Estimula el uso de tarjetas CRC (Clase-Responsabilidad-Colaborador) los cuales identifican y organizan las clases orientadas a objetos. Las tarjetas CRC son el resultado del diseño , si encontramos diseños complicados xp recomienda la creación de un prototipo de diseño llamado soluciones en punto. HP Confidential

40 12 April 2017 SCRUM SCRUM es un termino de Rugby, es la agrupación de los miembros del equipo. De esta manera el equipo trata de recorrer la distancia hacia la meta como una unidad, pasándose la pelota entre ellos. Concebido por Jeff Sutherland y su equipo de desarrollo a principios de la década de 1990. ¿Rugby? No, no, no. Scrum es una metodología ágil que relaciona el desarrollo exitoso de productos con el juego del rugby en el que un equipo auto-organizado (auto-gestionado) y multi-funcional se mueve junto por el campo de desarrollo de productos. El termino "Scrum" (melé) y la relación con el rugby, nace en un articulo publicado en el Harvard Business Review en 1986, donde se habla de prácticas asociadas con grupos exitosos de desarrollo de productos. Hoy en día Scrum es usado por empresas de todos los tamaños tales como Yahoo!, Microsoft, Google, Motorola, SAP y Cisco. HP Confidential

41 ¿ Que es Scrum? ¿ Ciclo de Vida ?
12 April 2017 ¿ Que es Scrum? SCRUM es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo. Reduce al máximo la burocracia y actividades no orientadas a producir software que funcione y produce resultados en periodos muy breves de tiempo (cada 30 días), por medio de iteraciones o Sprints. Ideal para proyectos con un rápido cambio de requerimientos. ¿ Ciclo de Vida ? Todo el trabajo es realizado en Sprints (30 días) Durante el Sprint se realizan reuniones que constituyen la inspección empírica y las practicas de adaptación de Scrum. Todo el trabajo es realizado en Sprints (carreras). Cada sprint es una iteración de 30 días de calendario consecutivos. Cada sprint es iniciado con una reunión de planeamiento del sprint, donde el PO y el equipo se juntan y colaboran sobre que se hará para el próximo sprint. Seleccionando del punto con mas prioridad del product backlog, el PO le comunica al equipo que es deseable, y el equipo le comunica al PO cuanto de los que es deseable cree que se podrá transformar en una funcionalidad durante el próximo sprint. Las reuniones de planeamiento de Sprint no pueden durar mas de 8 horas, la meta es ponerse a trabajar, no pensar en el trabajo. La reunión de planeamiento del sprint tiene dos partes: En las primeras 4 horas el Product Owner presenta los puntos del Product Backlog con mayor prioridad. El equipo le pregunta sobre el contenido, propósito significado, e intenciones del product backlog. Cuando el equipo sabe lo suficiente, pero antes de que terminen las primeras 4 horas, el equipo selecciona cuanto mas pueda del product backlog de lo que crea que pueda transformarse en un incremento completo de un probable despacho de funcionalidad del producto para el final del sprint. El equipo se compromete con el PO a que va a hacer lo mejor posible. Durante las segundas 4 horas, el equipo planea el sprint. Ya que el equipo es responsable de administrar su propio trabajo, necesita un plan tentativo para comenzar el sprint. Las tareas que componen este plan son colocadas en el Sprint Backlog; las tareas en el sprint backlog emergen con la evolución del sprint. En el comienzo de la segunda parte de la reunión, el sprint ha comenzado y el reloj esta corriendo hacia el fin del periodo del sprint. Juntas, las reuniones de planeamiento del sprint, Daily Sprint, Sprint review, y sprint retrospective constituyen la inspección empírica y las practicas de adaptación de scrum. HP Confidential

42 Mensaje Final ...

43 Mensaje Final ... Las metodologías nos dan la posibilidad de hacer mejor las cosas y generar valor. El adoptar metodologías en una organización no es un proceso fácil y requiere de ayuda externa. Hay prácticas que son aplicables a cualquier tipo de proyecto que uno quiera emprender. Para romper paradigmas hay que tener la mente abierta.

44 Preguntas ...

45 Gracias ...