Ingeniería de Software

Presentación del tema: "Ingeniería de Software"— Transcripción de la presentación:

1 Ingeniería de Software
M en TI María de Lourdes Salinas Callejas

2 Orden del día Actividad Presentación Encuadre de la materia
Criterios de evaluación Proyectos a realizar Bibliografía a utilizar Definir canales de comunicación Formar equipos de trabajo Calendario de actividades Examen Diagnostico Tema 1 ¿Qué es ingeniería del software? Actividad Debate

3 Actividad de presentación

4 Encuadre de la Materia Ingeniería del SW Avanzada Gestión de SW
Problemas y Soluciones

5 Criterios de Evaluación
% DE CONCEPTUAL % DE PROEYCTO % DE PROCEDIMENTAL % 30 40 100 EXAMEN TRABAJO EN CLASE, PRACTICAS,EXPOSICIONES (PRESENTACION,VIDEO,EXAMEN,EVALUACION INTERNA),TRABAJO PROYECTO INVESTIGACION

6 Investigación Resistencias o Fallas
Proyectos a Realizar Ingeniería de SW Desarrollo de un SI Investigación Resistencias o Fallas Revistas ISBN / ISSN Congreso virtual y /o presencial

7 Bibliografía a utilizar
Rinaudo, G. P.-L. (2014). Ingenieria de Software. Buenos Aires: Alfaomega. Sommerville, I. (2011). Ingenieria de Software. Mexico : Person. CMMI

8 Definir Canales de Comunicación
Pagina Web: informaticatesci.wikispaces.com Celular:

9 Formar equipos de trabajo

10 Examen Diagnostico

11 Ingeniería de Software

12 Introducción SI ¿QUÉ ES UN SISTEMA DE INFORMACIÓN?
Es el conjunto de recursos disponibles para la resolución de problemas mediante el uso de las ciencias de la computación. Esto incluye: Los equipos informáticos: ordenadores (computadoras), periféricos... El software (programas) de dichos equipos: sistemas operativos, aplicaciones... Los usuarios y administradores: las personas que utilizan dicho sistema y las que se encargan de que funcione. Las relaciones entre todos estos elementos: esto incluye las políticas de uso, procesos.. SI

13 Breve historia de la Ingeniería e Software

14 ERRORES QUE OCURREN CON MAYOR FRECUENCIA
Planificaciones demasiado optimistas Expectativas no realistas (o pedirle a un proyecto algo imposible) Excesivas tareas (cuando, por ejemplo, los desarrolladores están en muchos proyectos a la vez) Insuficiente aseguramiento de la calidad Oficinas ruidosas Incorporación de características (por ejemplo, introducir nuevos requisitos a mitad de proyecto) Hacerse ilusiones (por ejemplo, cerrar los ojos a lo que se nos viene encima) Gestión del riesgo insuficiente Confundir estimaciones con objetivos (cuando por ejemplo el objetivo es tener el software en 3 meses, y de ahí se fija que el desarrollo serán 3 meses) Omitir tareas relacionadas con la estimación (no guardar históricos para realizar mejores estimaciones, al estimar obviar tareas como son las reuniones, etc.

15 ERRORES QUE OCURREN CON MENOR FRECUENCIA
Cambio de herramientas en mitad del proyecto Falta de control automatizado del código fuente Desarrollo dirigido por la investigación Convergencia prematura o muy frecuente (forzar el cierre de una versión antes de que sea posible) Estimar obviando el uso de nuevas herramientas o métodos (obviando, por ejemplo, el coste de aprendizaje) Negociaciones y el “tira y afloja” (entre, por ejemplo, desarrollo y comerciales) El síndrome de la bala de plata Errores en la subcontratación Llevar al equipo en la oscuridad (cuando, por ejemplo, los jefes de proyecto ocultan al equipo el avance y plan de proyecto) Problemas con el equipo

16 ERRORES QUE PROVOCAN PROBLEMAS DE MAYOR IMPACTO
1.    Expectativas no realistas (o pedirle a un proyecto algo imposible) 2.    Equipo poco preparado 3.    Planificaciones demasiado optimistas 4.    Hacerse ilusiones (por ejemplo, cerrar los ojos a lo que se nos viene encima) 5.    Insuficiente aseguramiento de la calidad 6.    Diseño inadecuado 7.    Falta de apoyo al proyecto 8.    Confundir estimaciones con objetivos (cuando por ejemplo el objetivo es tener el software en 3 meses, y de ahí se fija que el desarrollo serán 3 meses) 9.    Excesivas tareas (cuando, por ejemplo, los desarrolladores están en muchos proyectos a la vez) 10.    Falta de involucración del usuario

17 ¿QUÉ ES INGENIERÍA DEL SOFTWARE?
Es una disciplina o área de la Informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Existen varias definiciones sobre esta ciencia de la computación que permiten describir este proceso.

18 Actividad

19 Planeación Unidad Tema Mes 1 Ingeniería de requerimientos Septiembre 2
Administración de proyectos de software Octubre 3 Calidad y medición de los sistemas de software Noviembre 4 Proceso, Diseño y validación de software Diciembre 5 Ingeniería de Software avanzada Enero Presentación de Proyecto Final Febrero

20 Productos Investigar revistas y congresos para participar
Estado del arte Implementación de Ing. de SW en el desarrollo de un proyecto Productos

21 Ingeniería de requerimientos
Objetivo Ayudar a los clientes a describir claramente lo que se desea obtener mediante un cierto software Ayudar a los desarrolladores a entender qué quiere exactamente el cliente Servir de base para desarrollos de estándares de ERS particulares para cada organización

22 Tipos de Requerimientos
Requerimientos del Usuario Son enunciados en un lenguaje natural junto con diagramas, acerca de que servicios esperan los usuarios del sistema y de las restricciones con las cuales este debe operar. Requerimientos del Sistema Son descripciones mas detalladas de las funciones, los servicios y las restricciones operacionales del sistema de software. El documento de requerimientos del sistema (llamado en ocasiones especificación funcional) tiene que definir con exactitud lo que se implementara.

23 Ejemplo Requerimientos del Usuario
Un sistema de administración de pacientes para apoyar la atención a la salud mental: Requerimientos del Usuario El Hospital del Ayuda Mental elabora mensualmente informes administrativos que revelen el costo de los medicamentos prescritos por cada clínica durante este mes.

24 Requerimientos del Sistema
1.1 En el ultimo día laboral de cada mes se redactara un resumen de los medicamentos prescitos, su uso y las clínicas que los prescriben. 1.2 El sistema elaborará automáticamente el informe que se imprimirá después de las 17:30 del ultimo día laboral del mes. 1.3 Se realizara un reporte para cada clínica junto con los nombre de cada medicamento, el numero de prescripciones, las dosis prescritas y el costo total de los medicamentos prescritos. 1.4 Si los medicamentos están disponibles en diferentes unidades de dosis (por ejemplo 10mg, 20 mg) se harán informes por separado para cada unidad de dosis. 1.5 El acceso a los informes de costos se restringirá a usuarios autorizados en la lista de control de acceso administrativo.

25 Lectores de Diferentes tipos de especificación de requerimientos
Gerentes del cliente Usuarios finales del sistema Ingenieros del cliente Gerentes de los contratistas Arquitectos del sistema Requerimientos del Usuario Usuarios finales del sistema Ingenieros del cliente Arquitectos del sistema Desarrolladores del software Requerimientos del Sistema

26 Requerimientos Funcionales
Son enunciados acerca de servicios que el sistema debe proveer, de como debería reaccionar el sistema a entradas particulares y de como debería comportarse el sistema en situaciones especificas. En algunos casos, los requerimientos funcionales también explican lo que no debe hacer el sistema. Requerimientos No Funcionales Son limitaciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso de desarrollo, como impuestas por los estándares. Los requerimientos no funcionales se suelen aplicar al sistema como un todo, mas que a características o a servicios individuales del sistema. Producto Organización Externos

27 Requerimiento no funcional
Requerimiento del producto Requerimiento de la organización Requerimiento Externo Req. Ambientales Req. Legales Req. De Eficiencia Req. De Usabilidad Req. De Confiabilidad Req. De Seguridad Req. Operacionales Req. Desarrollo Req. Regulatorios Req. Éticos Contables Protección/Seguridad Rendimiento Espacio

28 El documento de requerimientos de software
(Especificación de requerimientos de software o SRS) Es un comunicado oficial de lo que deben de implementar los desarrolladores del sistema, incluye los requerimientos del usuario para un sistema, como una especificación detallada de los requerimientos del sistema. Son esenciales los documentos de requerimientos cuando un contratista externo diseña el sistema de software Los requerimientos cambian tan rápidamente que se vuelve obsoleto Resulta útil escribir el documento de requerimientos como apoyo inicial.

29

30 La información que se incluya en un documentos de requerimientos depende del tipo de software que se va a desarrollar y del enfoque para el desarrollo que se use

31 Proceso de Ingeniería de Requerimientos
Incluyen cuatro actividades de alto nivel: Nivel 1 Estudio de factibilidad. Se enfoca en valorar si el sistema es útil para la empresa. Nivel 2 Adquisición y Análisis. Descubrir requerimientos. Nivel 3 Especificación . Convertir dichos requerimientos en una forma estándar Nivel 4 Validación. Comprobar que los requerimientos definan realmente el sistema que quiere el cliente.

32

33 Administración de requerimientos
Durante el proceso de software, la comprensión que los participantes tienen de los problemas cambian constantemente, entonces, los requerimientos del sistema también deben evolucionar para reflejar esa visión cambiante del problema. La administración de requerimientos es “El proceso de comprender y controlar los cambios en los requerimientos del sistema”. Requerimientos Individuales y mantener los vínculos entre los requerimientos dependientes. Evolución de los requerimientos

34 Planeación de requerimientos
Durante la etapa de administración de los requerimientos, se tiene que establecer: Identificación de requerimientos Un proceso de administración del cambio Políticas de seguimiento Herramientas de apoyo Contar con herramientas de apoyo (automatización ) Almacenamiento de requerimientos Administración del cambio Administración del seguimiento

35 Administración del cambio de Requerimientos