![ETIMOLOGIA
Software (pronunciaciónAFI:[ˈsɒftwɛəʳ])
es una palabra proveniente del inglés, que
en español no posee una traducción
adecuada al contexto, por lo cual se la
utiliza asiduamente sin traducir y así fue
admitida por la RealAcademia Española
(RAE).Aunque puede no ser estrictamente
lo mismo, suele sustituirse por
expresiones tales como programas
(informáticos) o aplicaciones
(informáticas) o soportes lógicos.](https://image.slidesharecdn.com/software-160721170835/85/Software-4-320.jpg)
Software
- 3. SOFTWARE El software evoluciona sencillamente por que se debe adaptar a los cambios del entorno, sean funcionales (exigencias de usuarios), operativos, de plataforma o arquitectura hardware El concepto de programas de computación en sus distintos estados: código fuente, binario o ejecutable; también su documentación, los datos a procesar e incluso la información de usuario
- 4. ETIMOLOGIA Software (pronunciaciónAFI:[ˈsɒftwɛəʳ]) es una palabra proveniente del inglés, que en español no posee una traducción adecuada al contexto, por lo cual se la utiliza asiduamente sin traducir y así fue admitida por la RealAcademia Española (RAE).Aunque puede no ser estrictamente lo mismo, suele sustituirse por expresiones tales como programas (informáticos) o aplicaciones (informáticas) o soportes lógicos.
- 5. MANTENIMIENTO DEL SOFTWARE 1 • es el proceso de control, mejora y optimización del software ya desarrollado e instalado 2 • De un buen diseño y documentación del desarrollo dependerá cómo será la fase de mantenimiento, tanto en costo temporal como monetario. Modificaciones realizadas a un software 3 • Durante el período de mantenimiento, es común que surjan nuevas revisiones y versiones del producto; que lo liberan más depurado, con mayor y mejor funcionalidad, mejor rendimiento, etc.
- 6. Tipos de cambios de mantenimiento del software Perfectivos : lleva una mejora calidad interna del software Correctivos : alteraciones necesarias para corregir cualquier tipo de error Adaptivos : modificaciones como cambios de configuración del hardware Evolutivos : agregados , modificaciones en el software
- 7. CLASIFICACION SOFTWARE DE SISTEMA El software de sistema le procura al usuario y programador adecuadas interfaces de alto nivel, controladores, herramientas y utilidades de apoyo que permiten el mantenimiento del sistema global SOFTWARE DE PROGRAMACION Es el conjunto de herramientas que permiten al programador desarrollar programas informáticos, usando diferentes alternativas y lenguajes de programación, SOFTWARE DEAPLICACIÓN : Es aquel que permite a los usuarios llevar a cabo una o varias tareas específicas, en cualquier campo de actividad susceptible de ser automatizado o asistido, con especial énfasis en los negocios
- 8. CODIFICACION DEL SOFTWARE • es el escrito directamente por los programadores en editores de texto, lo cual genera......PerfLogs el programa CODIGO FUENTE • : es el código binario o intermedio resultante de procesar con un compilador el código fuente. Consiste en una traducción completa y de una sola vez de éste último CODIGO OBJETO • : Es el código binario resultado de enlazar uno o más fragmentos de código objeto con las rutinas y bibliotecas necesarias. CODIGO EJECUTABLE
- 9. PROCESOS Se define como proceso al conjunto ordenado de pasos a seguir para llegar a la solución de un problema u obtención de un producto, en este caso particular, para lograr un producto software que resuelva un problema específico. El proceso de creación de software puede llegar a ser muy complejo, dependiendo de su porte, características y criticidad del mismo. Por ejemplo la creación de un sistema operativo es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo Existen varias metodologías para estimarlo, una de las más populares es el sistema COCOMO que provee métodos y un software (programa) que calcula y provee una aproximación de todos los costos de producción en un «proyecto software» (relación horas/hombre, costo monetario, cantidad de líneas fuente de acuerdo a lenguaje usado
- 10. Mantenimiento Instalación y paso a producción Pruebas (unitarias y de integración) Codificación Diseño Captura, e licitación , especificación y análisis de requisitos (ERS) EL proceso de desarrollo puede involucrar numerosas y variadas tareas, desde lo administrativo, pasando por lo técnico y hasta la gestión y el gerenciamiento. Pero, casi rigurosamente, siempre se cumplen ciertas etapas mínimas; las que se pueden resumir como sigue:
- 11. Modelo cascada • El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores; ello sólo podría ser aplicable a escasos y pequeños sistemas a desarrollar. Este, aunque es más comúnmente conocido como modelo en cascada es también llamado «modelo clásico», «modelo tradicional» o «modelo lineal secuencial».
- 12. Modelos evolutivos El software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estén diseñados para acomodarse a una evolución temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estén bien definidos a nivel detalle. En el modelo cascada y cascada realimentado no se tiene demasiado en cuenta la naturaleza evolutiva del software, se plantea como estático, con requisitos bien conocidos y definidos desde el inicio. Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación. Los modelos «iterativo incremental» y «espiral» (entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.
- 13. Modelo iterativo incremental La Figura muestra en forma muy esquemática, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final. Es decir, a medida que cada incremento definido llega a su etapa de operación y mantenimiento. Cada versión emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios.
- 14. Modelo espiral El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. El modelo se divide en un número de Actividades de marco de trabajo, llamadas «regiones de tareas». En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la Figura 6 se muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado más reciente.
- 15. Modelo espiral Win & Win •«Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan». •Las mejores negociaciones se fuerzan en obtener «Victoria & Victoria» (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. •El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral •Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren). •Determinación de «condiciones de victoria» de los directivos (saber qué necesitan y los satisface) •Negociación de las condiciones «victoria» de los directivos para obtener condiciones «Victoria & Victoria» (negociar para que ambos ganen). •(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organizacións i tiene éxito o criticado si no. Una variante interesante del Modelo Espiral previamente visto (Figura 6) es el «Modelo espiral Win-Win»7(Barry Boehm). El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.