Examen Diagnostico ¿Qué es la Ingeniería de Software?

Presentación del tema: "Examen Diagnostico ¿Qué es la Ingeniería de Software?"— Transcripción de la presentación:

1 Examen Diagnostico ¿Qué es la Ingeniería de Software?
¿Cuántos tipos de sistemas conoce? ¿Cuál es el ámbito del software? ¿Qué es el Software? ¿Cuál es el ciclo de vida del software? ¿Cuántos tipos de software existen? ¿Cuál es la diferencia entre el software comercial y el hecho a la medida? ¿Por qué se gasta tanto tiempo y esfuerzo en el mantenimiento de los programas existentes? ¿Por qué es imposible encontrar todos los errores en el software antes de entregarlo a los clientes? ¿El software se “desgasta”? “El software se desarrolla o construye; no se manufactura en el sentido clásico. ¿Qué opina? ¿Cuáles son tus expectativas de aprendizaje y que piensas aportar al curso?

2 ¿Qué es la Ingeniería de Software?
¿Cuántos tipos de sistemas conoce? ¿Cuál es el ámbito del software? ¿Qué es el Software? ¿Cuál es el ciclo de vida del software? ¿Cuántos tipos de software existen? ¿Cuál es la diferencia entre el software comercial y el hecho a la medida? ¿Por qué se gasta tanto tiempo y esfuerzo en el mantenimiento de los programas existentes? ¿Por qué es imposible encontrar todos los errores en el software antes de entregarlo a los clientes? ¿El software se “desgasta”? “El software se desarrolla o construye; no se manufactura en el sentido clásico. ¿Qué opina? ¿Cuáles son tus expectativas de aprendizaje y que piensas aportar al curso?

3 Ingeniería de Software
Introducción 1.1 Evolución histórica de la ingeniería de software. 1.2 El software como producto y proceso. 1.3 Factores que intervienen en la ingeniería de software. 1.4 El ciclo de vida de desarrollo de sistemas. 1.5 El ámbito de la ingeniería de software.

4 Introducción Según la definición del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo". Según el mismo autor, "un producto de software es un producto diseñado para un usuario". [Lewis 1994] Lewis G "What is Software Engineering?" DataPro (4015). Feb pp

5 Introducción "la Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994]. [Cota 1994]Cota A "Ingeniería de Software". Soluciones Avanzadas. Julio de pp

6 Introducción: Tipos de software
Software de Sistemas Es una colección de programas escritos para servir a otros programas (compiladores, editores, y utilerías para la administración de archivos) Software de Aplicación Consiste en programas independientes que resuelven una necesidad de negocios específica (además del procesamiento de datos convencional, se utiliza para controlar las funciones de los negocios en tiempo real)

7 Introducción: Tipos de software
Software científico y de ingeniería Se caracterizaba por algoritmos “devoradores de números”, abarca desde la astronomía hasta la vulcanología, desde del análisis de la tensión automotriz hasta la dinámica orbital de los transbordadores espaciales, etc.. Software emportado Reside dentro de la memoria de sólo lectura del sistema y con él se implementan y controlan características y funciones para el usuario final y el sistema mismo (control de combustible, teclado de microondas, sistemas de frenado, etc..)

8 Introducción: Tipos de software
Software de línea de productos Diseñado para proporcionar una capacidad específica y la utilización de muchos clientes diferentes, se puede enfocar en un nicho de mercado limitado (productos para el control de inventarios) o masivo (multimedia, manejo de bases de datos, etc..) Aplicaciones basadas en Web Las WebApps, evolucionan hacia ambientes computacionales sofisticados que no sólo proporcionan características , funciones de cómputo y contenido independientes al usuario final, sino que están integradas a bases de datos corporativas y aplicaciones de negocios.

9 Introducción: Tipos de software
Software de inteligencia artificial Utiliza algoritmos no numéricos en la resolución de problemas complejos que es imposible abordar por medio de un análisis directo. Sus aplicaciones incluyen la robótica, los sistemas expertos, redes neuronales artificiales, la comprobación de teoremas y los juegos de computadora. Computación Ubicua El crecimiento rápido de las redes inalámbricas podría conducir pronto a la verdadera computación distribuida.

10 Introducción: Tipos de software
Alimentación de la red La World Wide Web se convierte con rapidez en un distribuidor computacional, así como en un proveedor de contenido. Fuente Abierta Existe la tendencia creciente que impulsa la distribución del código fuente para aplicaciones de sistemas, de forma que los clientes hagan modificaciones locales. La “nueva economía” El reto para los ingenieros de software es construir aplicaciones que faciliten la comunicación y la distribución de productos en masa mediante productos en formación

11 1.1 Evolución histórica de la ingeniería de software
La Ingeniería de Software es relativamente nueva ya que aparece a finales de los años sesenta y principios de los setenta, comenzando con las Técnicas de Programación Estructurada, incorporándolas a las fases del ciclo vital de software.

12 1.1 Evolución histórica de la ingeniería de software: Significados
Orígenes La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por el Comité de Ciencia de la OTAN celebrada en Garmish, Alemania, en octubre de 1968, puede definirse según Alan Davis como "la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios"...

13 1.1 Evolución histórica de la ingeniería de software
La ingeniería de software en nuestros días Económicamente  En los EEUU, el software contribuyó a 1/4 de todo el incremento del PIB durante los 90's (alrededor de 90,000 millones de dólares por año), y 1/6 de todo el crecimiento de productividad durante los últimos años de la década (alrededor de 33,000 millones de dólares por año). La ingeniería de software contribuyó a $1 billón de crecimiento económico y productividad en esa década. Alrededor del globo, el software contribuye al crecimiento económico en formas similares, aunque es difícil de encontrar estadísticas fiables.

14 1.1 Evolución histórica de la ingeniería de software
La ingeniería de software en nuestros días Socialmente  La ingeniería de software cambia la cultura del mundo debido al extendido uso de la computadora. El correo electrónico ( ), la WWW y la mensajería instantánea permiten a la gente interactuar en nuevas formas. El software baja el costo y mejora la calidad de los servicios de salud, los departamentos de bomberos, las dependencias gubernamentales y otros servicios sociales. Los proyectos exitosos donde se han usado métodos de ingeniería de software incluyen a Linux, el software del transbordador espacial, los cajeros automáticos y muchos otros.

15 1.1 Evolución histórica de la ingeniería de software
La Ingeniería de software es la rama de la ingeniería que crea y mantiene las aplicaciones de software aplicando tecnologías y prácticas de las ciencias computacionales, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros campos

16 1.1 Evolución histórica de la ingeniería de software: Significados
Como el término usual contemporáneo de un amplio rango de actividades que se solía llamar programación y análisis de sistemas; Como un término amplio de todos los aspectos de la práctica de la programación de computadoras, en oposición a la teoría, que es llamada ciencia computacional o computación; La ingeniería de software es "(1) la aplicación de un método sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, esto es, la aplicación de la ingeniería al software" y "(2) el estudio de los métodos de (1)", estándar IEEE

17 1.1 Evolución histórica de la ingeniería de software: Significados
Como el término usual contemporáneo de un amplio rango de actividades que se solía llamar programación y análisis de sistemas; Como un término amplio de todos los aspectos de la práctica de la programación de computadoras, en oposición a la teoría, que es llamada ciencia computacional o computación; La ingeniería de software es "(1) la aplicación de un método sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, esto es, la aplicación de la ingeniería al software" y "(2) el estudio de los métodos de (1)", estándar IEEE

18 1.1 Evolución histórica de la ingeniería de software
La Programación Estructurada fue seguida por otros métodos estructurados de análisis y también métodos estructurados de diseño. Además, comenzaron a usarse tecnologías orientadas a objetos. En un principio la programación era la tarea de oro de la Ingeniería de Software pero ahora la ingeniería y el diseño de requisitos son más importantes.

19 1.1 Evolución histórica de la ingeniería de software
En los años noventa la gerencia de proyecto ganó interés y llegó a ser un componente importante en la Ingeniería de Software. En la década pasada, los estándares de la Ingeniería de Software y la madurez de proceso han caracterizado la industria del software como una disciplina madura.

20 1.1 Evolución histórica de la ingeniería de software
En un nivel más técnico, la Ingeniería de Software comienza con una serie de tareas que hacen modelos y que resultan en una especificación completa de requisitos y una representación comprensiva de diseño del software que será construido. Se han desarrollado muchos métodos para hacer modelos de sistemas de información. Sin embargo, los métodos Orientados a Objeto (OO) van a llegar a ser el estándar.

21 1.1 Evolución histórica de la ingeniería de software
Para ciertos sistemas de información críticos, el uso de métodos formales es recomendado en el ciclo de vida del software, para producir sistemas con la integridad más alta. Los métodos formales confían en las técnicas matemáticas que expresan y modelan los requisitos de cualquier producto en el ciclo vital del software.

22 1.1 Evolución histórica de la ingeniería de software
El Desarrollo de Software Orientado a Objetos comenzó en los años ochenta como una etapa natural de los métodos estructurados. UML (Unified Modeling Language) ha emergido como una unificación de los diversos métodos orientados a objetos y se está convirtiendo en un estándar.

23 1.1 Evolución histórica de la ingeniería de software
Actualmente, la tecnología de componente es un método para desarrollar sistemas de información que está creciendo. A diferencia de los métodos tradicionales, la tecnología de componente los ensambla para formar una solución de software. Actualmente, hay dos estándares de componentes en competencia: JavaBeans por Sun y DCOM por Microsoft. Los componentes de software son materiales reusables para construir sistemas de software.

24 1.1 Evolución histórica de la ingeniería de software
La tecnología Component-Base (Basada en Componentes) es un método poderoso para la empresa de la ingeniería de sistemas de información porque es una tecnología que está reduciendo el conflicto entre sistemas de alta complejidad y de la búsqueda para la alta calidad y la productividad.

25 1.1 Evolución histórica de la ingeniería de software
En la Dirección de Sistemas se desarrolla Ingeniería de Software mediante la detección, evaluación, construcción y asesoría de sistemas de información y servicios de red, promoviendo además, una alta participación del cliente y usuario para lograr la más alta calidad de nuestros servicios, contribuyendo así al mejoramiento informático de las organizaciones, a través de la utilización de herramientas con tendencia tecnológica estratégica para el desarrollo de la informática en el país.

26 El software como producto y proceso
Cuando se presta un servicio o se crea un producto, ya sea el desarrollo de software, la preparación de un informe escrito o al realizar un viaje de negocios, siempre se sigue una secuencia de pasos para lograr una serie de tareas. Las tareas se realizan por lo general en el mismo orden todas las veces.

27 El software como producto y proceso
Un proceso es un conjunto de procedimientos organizado de tal modo que los productos se construyen para satisfacer un conjunto de metas o estándares. De hecho, el proceso puede sugerir que se seleccione entre varios procedimientos, con tal de que se cumpla la meta propuesta.

28 El software como producto y proceso
Podemos pensar al conjunto de tareas como un proceso; una serie de pasos que involucran actividades, restricciones y recursos que producen una determinada salida de esperada. Un proceso por lo común, involucra un conjunto de herramientas y técnicas.

29 El software como producto y proceso
Cualquier proceso tiene las siguientes características: El proceso establece a todas las principales actividades del proceso El proceso utiliza recursos, está sujeto a una serie de restricciones (tal como un calendario) y genera productos intermedios y finales. El proceso puede estar compuesto por subprocesos que se encadenan de alguna manera. El proceso puede definirse como una jerarquía de procesos organizada de modo que cada subproceso tenga su propio modelo de proceso. Cada actividad del proceso tiene criterios de entrada y de salida, de modo que se conoce cuándo comienza y cuándo termina una actividad. Las actividades se organizan en una secuencia de modo que resulta claro cuando una actividad se realiza en orden relativo a otras actividades. Todo proceso tiene un conjunto de principios orientadores que explican las metas de cada actividad. Las restricciones o controles pueden ser de aplicación a una actividad, recurso o producto. Por ejemplo, el presupuesto o la agenda pueden restringir la extensión del tiempo que puede tomar una actividad, o una actividad, o una herramienta puede limitar la manera en que puede utilizarse un recurso.

30 El software como producto y proceso
El desarrollo del software involucra las siguientes etapas: Análisis y definición de los requerimientos Diseño del sistema Diseño de programas Escritura de los programas (implementación de programas) Prueba unitaria Pruebas de integración prueba de sistema Entrega del sistema Mantenimiento. Cada etapa es en sí misma un proceso ( o una colección de procesos) que puede ser descrito como un conjunto de actividades. Y cada actividad comprende restricciones, salidas y recursos.

31 El software como producto y proceso
Herramientas Métodos Proceso Un enfoque de calidad La ingeniería de software es una tecnología estratificada, como se muestra en la figura, cualquier enfoque de ingeniería debe estar sustentado en la calidad. (gestión de calidad total, Seis Sigma y enfoques similares)

32 El software como producto y proceso
La base de la ingeniería de software es el estrato del proceso. El proceso de la ingeniería de software es el elemento que mantiene juntos los estratos de la tecnología y que permite el desarrollo racional y a tiempo del software de computadora EL proceso define un marco de trabajo que debe establecerse para la entrega efectiva de la tecnología de la ingeniería del software.

33 El software como producto y proceso
Los métodos de la ingeniería de software proporcionan los “cómo” técnicos para construir software. Los métodos abarcan un amplio espectro de tareas que incluyen la comunicación el análisis de requisitos, el modelado de diseño, la construcción del programa la realización de pruebas y soporte. Las herramientas de ingeniería de software proporcionan el soporte automatizado o semiautomatizado para el proceso y los métodos. Cuando las herramientas se integran de forma que la información que cree una de ellas puede usarla otra, se dice que se ha establecido un sistema para el soporte del desarrollo del software, que con frecuencia se denomina ingeniería del software asistida por computadora.

34 El software como producto y proceso
Marco del trabajo para el proceso: Un marco de trabajo establece la base para un proceso de software completo al identificar un número pequeño de actividades del marco de trabajo aplicables a todos los proyectos de software, sin importar su tamaño o complejidad. Además, el marco de trabajo del proceso abarca un conjunto de actividades sombrilla aplicables a lo largo del proceso del software.

35 El software como producto y proceso
Marco del trabajo para el proceso: El software como producto y proceso Proceso del Software Marco de trabajo del proceso Actividades sombrilla

36 Actividades sombrilla
Actividad del marco de trabajo # 1 Acción de la ingeniería de software #1.1 Conjunto de tareas . acción de la ingeniería de software #1.k Tareas del trabajo Productos del trabajo Puntos de aseguramiento de la calidad Fundamentos del proyecto Tareas del trabajo Productos del trabajo Puntos de aseguramiento de la calidad Fundamentos del proyecto Actividad del marco de trabajo # n Acción de la ingeniería de software #n.1 Conjunto de tareas . acción de la ingeniería de software #n.m Tareas del trabajo Productos del trabajo Puntos de aseguramiento de la calidad Fundamentos del proyecto Tareas del trabajo Productos del trabajo Puntos de aseguramiento de la calidad Fundamentos del proyecto

37 El software como producto y proceso
El siguiente marco genérico del proceso se puede aplicar en la inmensa mayoría de los productos del software: Comunicación Implica una intensa colaboración y comunicación con los clientes; además, abarca la investigación de requisitos y otras actividades relacionadas. Planeación Establece un plan para el trabajo de la ingeniería del software. Describe las tareas técnicas que deben realizarse, los riesgos probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un programa de trabajo. Modelado Esta actividad abarca la creación de modelos que permiten al desarrollador y al cliente entender mejor los requisitos de software y el diseño que lograra satisfacerlos. Construcción Esta actividad combina la generación del código (ya sea manual o automatizado) y la realización de pruebas necesarias para descubrir errores en el código. Despliegue El software (como una entidad completa o un incremento completado de manera parcial) se entrega al cliente, quien evalúa el producto recibido y proporciona información basada en su evaluación.

38 El software como producto y proceso
Evaluación del proceso La existencia de un proceso de software no es garantía de que este será entregado a tiempo, de que satisfará las necesidades del cliente, o de que mostrará las características técnicas que conducirán a características de calidad a largo plazo. Los patrones de proceso deben ir acompañados de una práctica sólida de la ingeniería de software

39 El software como producto y proceso
Evaluación del proceso Proceso del software Identifica modificaciones a Es examinado por Identifica capacidades y riesgos de Evaluación del proceso de software Conduce a Conduce a Mejoramiento del proceso de software Determinación de la calidad Motiva

40 El software como producto y proceso
Si el proceso es débil, sin duda el producto final sufrirá las consecuencias. Asimismo, una confianza excesiva en el proceso es peligrosa

41 El software como producto y proceso
La gente obtiene tanta (o más) satisfacción del proceso creativo que del producto final. El trabajo que realiza la gente de software cambiará en los años que siguen. La dualidad del producto y el proceso es un elemento importante para mantener a la gente creativa comprometida mientras finaliza la transición desde la programación hasta la ingeniería de software.

42 Factores humanos que intervienen en la ingeniería de software
El ámbito del software Describe las funciones y características que se entregarán a los usuarios finales, los datos que son entrada y salida, el “contenido” que se presenta a los usuarios como consecuencia de emplear software, así como el desempeño, las restricciones, las interfaces y la confiabilidad que acotan el sistema. El ámbito se define al usar una de las dos técnicas siguientes:

43 Factores humanos que intervienen en la ingeniería de software
El ámbito del software Después de una comunicación con todos los participantes se desarrolla una descripción narrativa del ámbito de software. Los usuarios finales desarrollan un conjunto de casos de uso.

44 Factores humanos que intervienen en la ingeniería de software
El ámbito del software Una vez identificado el ámbito (con la participación del cliente) es razonable preguntar: ¿Es posible construir software para satisfacer este ámbito? ¿El proyecto es factible? Con mucha frecuencia los ingenieros de software soslayan estas preguntas (o gestores o clientes impacientes presionan para hacerlo), solo para verse enredados en un proyecto condenado al fracaso

45 Factores humanos que intervienen en la ingeniería de software
Recursos La segunda tarea de la planificación es la estimación de los recursos necesarios para completar el esfuerzo de desarrollo del software La siguiente figura, muestra las tres grandes categorías de los recursos de ingeniería del software: personal, componentes de software reutilizables y el entorno de desarrollo (hardware y herramientas de software)

46 Factores humanos que intervienen en la ingeniería de software
Recursos Herramientas de software Número Habilidades Hardware Entorno Personal Ubicación Recursos de red Proyecto Cada recurso se especifica con cuatro características: descripción del recurso; un informe de disponibilidad; cuando se requerirá el recurso; tiempo durante el cual el recurso se aplicará. Software reutilizable Nuevos componentes Componentes OTS Componentes de experiencia parcial Componentes de Experiencia completa

47 Factores humanos que intervienen en la ingeniería de software
Recursos Humanos El planificador comienza evaluando el ámbito del software y seleccionando las habilidades requeridas para completar el desarrollo. Se especifican tanto la posición organizacional Por ejemplo, telecomunicaciones, base de datos, cliente/servidor)

48 Factores humanos que intervienen en la ingeniería de software
Recursos Humanos En proyectos relativamente pequeños (unos pocos persona-meses) un solo individuo puede realizar todas las tareas de ingeniería del software y consultar con especialistas conforme se requiera. En proyectos mayores el equipo de software puede estar geográficamente disperso en varios sitios. Aquí se especifica la ubicación de cada recurso humano

49 Factores humanos que intervienen en la ingeniería de software
Recursos de software reutilizables La ingeniería de software basada en componentes enfatiza la reutilización; es decir, la creación y reutilización de bloques de construcción de software. Tales bloques, deben catalogarse para consultarlos con facilidad, estandarizarse para facilitar su aplicación y validarse para integrarlos fácilmente

50 Factores humanos que intervienen en la ingeniería de software
Componentes ya desarrollados El software existente se puede adquirir de un tercero o se desarrollo internamente en un recurso previo. Componentes experimentados Especificaciones, diseños, código o datos de prueba existentes que se desarrollaron para proyectos previos son similares al software que se construirá para el proyecto actual.

51 Factores humanos que intervienen en la ingeniería de software
Componentes de experiencia parcial Especificaciones, diseños, código o datos de prueba existentes que se desarrollaron para proyectos previos están relacionados con el software que se construirá para el proyecto actual pero requerirán modificaciones sustanciales Componentes experimentados El equipo de software debe construir los componentes de software específicamente para las necesidades del proyecto actual

52 Factores humanos que intervienen en la ingeniería de software
Recursos del entorno El entorno que soporta un proyecto de software, con frecuencia denominado entorno de ingeniería del software (EIS), incorpora hardware y software. El hardware proporciona una plataforma que soporta las herramientas (software) con que se producen los productos de trabajo basados en una buena práctica de la ingeniería de software.

53 1.4 El ciclo de vida de desarrollo de sistemas.
Como se vio en el software como producto y proceso el desarrollo del software involucra las siguientes etapas: Análisis y definición de los requerimientos Diseño del sistema Diseño de programas Escritura de los programas (implementación de programas) Prueba unitaria Pruebas de integración prueba de sistema Entrega del sistema Mantenimiento.

54 1.4 El ciclo de vida de desarrollo de sistemas.
La construcción de un modelo de proceso y la discusión de los subprocesos ayuda al equipo a entender la brecha entre lo que debe ser y lo que es. Existen varias razones para el modelado de un proceso: Cuando un grupo pone por escrito una descripción de su proceso de desarrollo, da forma a una comprensión común de actividades, recursos y restricciones comprometidas con el desarrollo del software. La creación de un modelo de proceso ayuda al equipo de desarrollo a encontrar las inconsistencias, las redundancias y las omisiones en el proceso y en las partes que lo constituyen. El modelo debe reflejar las metas de desarrollo, como la construcción de software de alta calidad, la localización temprana de los defectos en el desarrollo y el cumplimiento de las restricciones del cronograma y del presupuesto.

55 1.4 El ciclo de vida de desarrollo de sistemas.
Todo proceso debe adaptarse a la situación en que será utilizado. La construcción de un modelo del proceso ayuda al equipo de desarrollo a comprender dónde debe hacerse la adaptación. Todo modelo del proceso de desarrollo del software incluye los requerimientos del sistema como entrada y un producto entregado como salida.

56 1.4 El ciclo de vida de desarrollo de sistemas.
Modelo en Cascada En este modelo las etapas se representan cayendo en cascada, desde una etapa hacia la siguiente, como se observa una etapa de desarrollo debe completarse antes de dar comienzo a la siguiente. Análisis de requerimientos Diseño del sistema Diseño del programa Codificación Pruebas Unitarias Y de integración Prueba del sistema Prueba de aceptación Operación y mantenimiento

57 1.4 El ciclo de vida de desarrollo de sistemas.
El modelo en cascada puede ser muy útil, ayudando a los desarrolladores a diagramar lo que necesitan hacer. Su simplicidad hace que sea fácil explicarlo a los clientes que no están familiarizados con el desarrollo de software: es más explicito en los productos intermedios que son necesarios a fin de comenzar la siguiente etapa de desarrollo

58 1.4 El ciclo de vida de desarrollo de sistemas.
El mayor problema con el modelo en cascada es que no refleja la manera en que realmente se hace el desarrollo del código. Excepto para los problemas perfectamente comprendidos, el software se desarrolla normalmente con un alto grado de repetición. De esta manera, si no se controlara el proceso real del software, este se vería como el de la figura. Análisis de requerimientos Operación y mantenimiento Diseño del sistema Prueba de aceptación Diseño del programa Prueba del sistema Codificación Pruebas Unitarias Y de integración

59 1.4 El ciclo de vida de desarrollo de sistemas.
El proceso de desarrollo del software puede ayudar a controlar los saltos de una tarea a otra incorporando actividades y subprocesos que refuercen la comprensión. El prototipado es un subproceso: Prototipo: es un producto parcialmente desarrollado que permite que clientes y desarrolladores examinen algunos aspectos del sistema propuesto y decidan si este es adecuado o correcto para el producto terminado.

60 1.4 El ciclo de vida de desarrollo de sistemas.
Validar Análisis de requerimientos Diseño del sistema Diseño del programa Verificar Codificación Pruebas Unitarias Y de integración Prototipado Prueba del sistema Prueba de aceptación Operación y mantenimiento

61 1.4 El ciclo de vida de desarrollo de sistemas.
La interfaz de usuario se construye y se prueba como un prototipo, de modo que los usuarios comprendan qué aspecto tendrá el nuevo sistema y los diseñadores se orientan correctamente sobre la forma en que el usuario quiere interactuar con el sistema Validación. Asegura que el sistema implantado todos los requerimientos, de tal modo que cada función del sistema puede ser rastreada hacia atrás hasta un requerimiento particular en la especificación. Verificación. Asegura que cada función trabaja correctamente; asegura que el desarrollador está construyendo el producto correcto y la verificación comprueba la calidad de la implementación.

62 1.4 El ciclo de vida de desarrollo de sistemas.
El modelo V Es una variación del modelo en cascada que demuestra cómo se relacionan las actividades de prueba con las de análisis y diseño. La codificación forma la punta de la V , con el análisis y el diseño a la izquierda y la prueba y el mantenimiento a la derecha. La prueba unitaria y de integración se ocupan de la exactitud de los programas . La vinculación entre los lados derecho e izquierdo del modelo V implica que, si se encuentran problemas durante la verificación y la validación, entonces el lado izquierdo de la V puede ser ejecutado nuevamente, para solucionar el problema y mejorar los requerimientos, el diseño y el código antes de retomar los pasos de prueba sobre el lado derecho.

63 1.4 El ciclo de vida de desarrollo de sistemas.
Operación y mantenimiento Validar los requerimientos Análisis de requerimientos Prueba de aceptación Diseño del sistema Prueba del sistema Verificar el diseño Diseño del programa Pruebas Unitarias Y de integración Codificación

64 1.4 El ciclo de vida de desarrollo de sistemas.
Modelo de Prototipos El modelo de prototipo permite que todo el sistema , o algunas de sus partes se construyan rápidamente para comprender o aclarar aspectos , tiene el mismo objetivo que un prototipo de ingeniería , donde los requerimientos o el diseño requieren la investigación repetida para asegurar que el desarrollador, el usuario y el cliente tengan una comprensión tanto de lo que se necesita como de lo que se propone como solución

65 1.4 El ciclo de vida de desarrollo de sistemas.
LISTA DE REVISIONES LISTA DE REVISIONES LISTA DE REVISIONES Revisar prototipo Revisión del usuario/cliente PROTOTIPAR LOS REQUERIMIENTOS PROTOTIPAR EL DISEÑO PROTOTIPAR EL SISTEMA PROBAR SISTEMA ENTREGADO REQUERIMIENTOS DEL SISTEMA (a veces informal o incompleto)

66 1.5 El ámbito de la ingeniería de software.
Que es un proyecto de Sistema o Software? Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimación, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software.

67 Objetivos de la Planificación del Proyecto
El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.

68 Actividades asociadas al proyecto de software.
Ámbito del Software Es la primera actividad llevada a cabo durante la planificación del proyecto de Software. En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación.

69 Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes. El Ámbito se define como un pre-requisito para la estimación y existen algunos elementos que se debe tomar en cuenta como es:       La Obtención de la Información necesaria para el software. Para esto el analista y el cliente se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de interés para su desarrollo.

70 Recursos de entorno. El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería de Software, incorpora Hardware y Software. El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniería del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estén disponibles. Muchas veces el desarrollo de las pruebas de validación de un proyecto de software para la composición automatizada puede necesitar un compositor de fotografías en algún punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software.

71 Estimación del proyecto de Software.
En el principio el costo del Software constituía un pequeño porcentaje del costo total de los sistemas basados en Computadoras. Hoy en día el Software es el elemento más caro de la mayoría de los sistemas informáticos. Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles: Base las estimaciones en proyectos similares ya terminados. Utilice técnicas de descomposición relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto. Desarrolle un modelo empírico para él calculo de costos y esfuerzos del Software.

72 La primera opción, aunque atractiva no es practica.
La Segunda opción puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son métodos viables para la estimación del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada una de ellas como comprobación de las otras.

73 Estimación basada en el Proceso
Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea. Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software

74 1 Los Modelos Empíricos:
Diferentes modelos de estimación 1 Los Modelos Empíricos: Donde los datos que soportan la mayoría de los modelos de estimación obtienen una muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia.

75 La jerarquía de modelos de Boehm esta constituida por los siguientes:
El Modelo COCOMO. Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce una jerarquía de modelos de estimación de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos de Boehm esta constituida por los siguientes:

76 Modelo I. El Modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo de Software en función del tamaño del programa, expresado en las líneas estimadas. Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de conductores de costos que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto. Modelo III. El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada caso (análisis, diseño, etc.) del proceso de ingeniería de Software.

77 Herramientas Automáticas De Estimación.
Las herramientas automáticas de estimación permiten al planificador estimar costos y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la selección del personal. Aunque existen muchas herramientas automáticas de estimación, todas exhiben las mismas características generales y todas requieren de una o más clases de datos.

78 A partir de estos datos, el modelo implementado por la herramienta automática de estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duración, y en algunos casos la planificación temporal de desarrollo y riesgos asociados. En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará implicada. Además el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado.