Conceptos Generales de Ingeniería del Software Educativo Parte II

5/10/2018 Conceptos Generales de Ingenier a del Software Educativo Parte II - slidepdf.com

http://slidepdf.com/reader/full/conceptos-generales-de-ingenieria-del-software-educativo-pa

Ingeniería del Software Educativo FEI – IE – 2S - 2010

Conceptos Generales de Ingeniería del Software Educativo

jueves 5 de agosto de 2010

JAMS – EAVV

Índice

4 REQUERIMIENTOS DEL SOFTWARE ...............................................................................................1

4.1 REQUERIMIENTOS FUNCIONALES .......................................................................................................1 4.2 REQUERIMIENTOS NO FUNCIONALES ...................................................................................................1 4.3 REQUERIMIENTOS DEL DOMINIO........................................................................................................1

5 METODOLOGÍA O EL CICLO DE VIDA DEL SOFTWARE. ...................................................................1

5.1 INTRODUCCIÓN .............................................................................................................................1 5.2 CICLO DE VIDA DEL SOFTWARE ..........................................................................................................2 5.3 ELEMENTOS DEL CICLO DE VIDA DEL SOFTWARE .....................................................................................3 5.4 METODOLOGÍA LINEAL ....................................................................................................................4 5.5 METODOLOGÍA EN CASCADA ............................................................................................................4 5.6 METODOLOGÍA EN V ......................................................................................................................5 5.7 METODOLOGÍA ITERATIVA ...............................................................................................................6 5.8 METODOLOGÍA POR PROTOTIPOS ......................................................................................................7 5.9 METODOLOGÍA EVOLUTIVA..............................................................................................................8 5.10 METODOLOGÍA INCREMENTAL......................................................................................................8

5.11 METODOLOGÍA EN ESPIRAL ..........................................................................................................9 5.12 METODOLOGÍA ORIENTADA A OBJETOS ........................................................................................ 11

6 BIBLIOGRAFÍA ............................................................................................................................. 11




1

4 Requerimientos del software

Los requerimientos para un sistema son la descripción de los servicios proporcionados

por el sistema y sus restricciones operativas. Estos requerimientos reflejan lasnecesidades de los clientes de un sistema que ayude a resolver algún problema comoel control de un dispositivo, hacer un pedido o encontrar información. El proceso dedescubrir, analizar, documentar y verificar estos servicios y restricciones se denominaingeniería de requerimientos.

El termino requerimientos no se utiliza de una forma constante en la industria desoftware. En algunos casos, un requerimiento es simplemente una declaraciónabstracta de alto nivel de un servicio que debe proporcionar el sistema o unarestricción de éste. El otro extremo es una definición detallada y formal de una función

del sistema.Algunos de los problemas que surgen durante el proceso de ingeniería derequerimientos son resultado de no hacer una clara separación entre estos diferentesniveles de descripción.

4.1 Requerimientos funcionales

Son declaraciones de los servicios que debe proporcionar el sistema, de manera enque éste debe reaccionar a entradas particulares y de cómo se debe comportar ensituaciones particulares. En algunos casos, los requerimientos funcionales del sistema

también pueden declarar explícitamente lo que el sistema no debe hacer.

4.2 Requerimientos no funcionales

Son restricciones de los servicios o funciones ofrecidas por el sistema. Incluyerestricciones de tiempo, sobre el proceso de desarrollo y estándares. Losrequerimientos no funcionales a menudo se aplican al sistema en su totalidad.Normalmente se aplican a características o servicios individuales del sistema.

4.3 Requerimientos del dominio

Son requerimientos que provienen del dominio de aplicación del sistema y que reflejanlas características y restricciones de ese dominio. Pueden ser funcionales o nofuncionales.

5 Metodología o El ciclo de vida del software.

5.1 Introducción

Cuando surgió la necesidad de adaptar los sistemas informáticos a las exigencias delmercado, el programador realizaba un relevamiento de las solicitudes de quien

necesitaba cierto programa o producto de software, y con aquellos requerimientosbajo el brazo comenzaba la dura tarea de codificar. Esta tarea no estaba administrada,




2

supervisada o gestionada de ningún modo, por lo que se iba corrigiendo a medida quesurgían los errores, tanto lógicos provenientes de la codificación, como los derequerimientos solicitados por el cliente o usuario final.

En la década de 1970 los programas fueron creciendo en complejidad, por lo que la

antigua técnica de code&fix (codificar y corregir) terminó quedando obsoleta. Estatécnica se basaba en requerimientos ambiguos y sin especificaciones puntuales. Al noseguir normas para el proyecto, el cliente o usuario solo impartían especificacionesmuy generales del producto final. Se programaba, se corregía y se volvía a programassobre la misma marcha del proyecto. El ciclo de vida de este tipo de proyectosfinalizaba cuando se satisfacían las especificaciones, no sólo las primeras por las cualesnación la necesidad del programa, sino también todas aquellas que fueron surgiendosobre la marcha.

Esta técnica tiene las ventajas de no gastar recursos en análisis, planificación, gestiónde recursos, documentación, etc., y bien sabemos que es muy cómoda y muchas vecesrecomendable cuando el proyecto es muy pequeño y es llevado adelante por uno odos programadores. Por otro lado, cuando el sistema no es pequeño o es máscomplejo de lo creído (tengamos en cuenta que no hubo análisis) nos trae desventajasen lo que se refiere a costo de recursos, que siempre será mayor del previsto;aumentara el tiempo de desarrollo y la calidad del código será bastante dudosa.

5.2 Ciclo de vida del software

Norma ISO 12207

“El ciclo de vida de un software es un marco de referencia que contiene lasactividades y las tareas involucradas en el desarrollo, la explotación y elmantenimiento de un producto software, abarcando desde la definición hastala finalización de su uso”

Un proyecto de ingeniería tiene fines ligados a la obtención de un producto, proceso oservicio que es necesario generar a través de diversas actividades. Algunas de estasactividades pueden agruparse en fases porque globalmente contribuyen a obtener unproducto intermedio, necesario para continuar hacia el producto final y facilitar lagestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de

vida”. Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tiposde productos intermedios que se generan, etc. pueden ser muy diferentesdependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas.

La definición de un ciclo de vida facilita el control sobre los tiempos en que esnecesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) alproyecto. El control de calidad también se ve facilitado si la separación entre fases sehace corresponder con puntos en los que ésta deba verificarse (mediantecomprobaciones sobre los productos parciales obtenidos).




3

De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vidapara situaciones muy diversas permite que nos beneficiemos de la experienciaadquirida utilizando el enfoque que mejor se adapte a nuestros requerimientos.

5.3 Elementos del ciclo de vida del software

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas portareas panificables. Según el modelo de ciclo de vida, la sucesión de fases puedeampliarse con bucles de realimentación, de manera que lo que conceptualmente seconsidera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto,recibiendo en cada pasada de ejecución aportaciones de los resultados intermediosque se van produciendo (realimentación).

Para un adecuado control de la progresión de las fases de un proyecto se hacenecesario especificar con suficiente precisión los resultados evaluables, o sea,productos intermedios que deben resultar de las tareas incluidas en cada fase.

Normalmente estos productos marcan los hitos entre fases.

A continuación presentamos los distintos elementos que integran un ciclo de vida:

Fases: Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollodel proyecto. Se construye agrupando tareas (actividades elementales) que puedencompartir un tramo determinado del tiempo de vida de un proyecto. La agrupacióntemporal de tareas impone requisitos temporales correspondientes a la asignación derecursos (humanos, financieros o materiales).

Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en ladefinición de las fases para que el contenido de cada una siga siendo manejable. Deesta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí

mismo, compuesto por un conjunto de micro-fases.

Otro motivo para descomponer una fase en fases menores ( subfases) puede ser elinterés de separar partes temporales del proyecto que se subcontraten a otrasorganizaciones, requiriendo distintos procesos de gestión.

Cada fase viene definida por un conjunto de elementos observables externamente,

como son las actividades con las que se relaciona, los datos de entrada (resultados dela fase anterior, documentos o productos requeridos para la fase, experiencias deproyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior,experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de lafase.

Entregables ("deliverables")

Son los productos intermedios que generan las fases. Pueden ser materiales(componentes, equipos) o inmateriales (documentos, software). Los entregables

permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación




4

o no a los requisitos funcionales y de condiciones de realización previamenteestablecidos.

5.4 Metodología lineal

Es el más sencillo de todos los modelos. Consiste en descomponer la actividad globaldel proyecto en etapas separadas que son realizadas de manera lineal, es decir, cadaetapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapasiguiente. Con un ciclo de vida lineal es muy fácil dividir las tareas, y prever los tiempos(sumando linealmente los de cada etapa).

Las actividades de cada una de las etapas mencionadas deben ser independientesentre sí, es decir, que es condición primordial que no haya retroalimentación entreellas, aunque si pueden admitirse ciertos supuestos de la realimentación correctiva.Desde el punto de vista de la gestión, requiere también que se conozca desde elprimer momento, con excesiva rigidez, lo que va a ocurrir en cada una de las distintas

etapas antes de comenzar. Esto último minimiza, también, las posibilidades de erroresdurante la codificación y reduce al mínimo la necesidad de requerir información delcliente o del usuario.

Se destaca como ventaja la sencillez de su gestión y administración tanto económicacomo temporal, ya que se acomoda perfectamente a proyectos internos de unaempresa para programas muy pequeños de ABM (sistemas que realizan Altas, Bajas yModificaciones sobre un conjunto de datos). Tiene como desventaja que no es aptopara Desarrollos que superen mínimamente requerimientos de retroalimentaciónentre etapas, es decir, es muy costoso retomar una etapa anterior al detectar algunafalla.

Es válido tomar este ciclo de vida cuando algún sector pequeño de una empresanecesita llevar un registro de datos acumulativos, sin necesidad de realizar procesossobre ellos más que una consulta simple.

5.5 Metodología en cascada

Este modelo fue propuesto por Winston Royce en el año 1970. Es un ciclo de vida queadmite iteraciones, contrariamente a la creencia de que es un ciclo de vida secuencialcomo el lineal. Después de cada etapa se realiza una o varias revisiones paracomprobar si se puede pasar a la siguiente. Es un modelo rígido, poco flexible, y con

muchas restricciones, aunque fue uno de los primeros pioneros, y sirvió de base parael resto de los modelos de ciclo de vida.




5

Una de sus ventajas, además de su planificación sencilla, es la de proveer un productocon un elevado grado de calidad sin necesidad de un personal altamente calificado. Se

pueden considerar como inconvenientes: la necesidad de contar con todos losrequerimientos (o la mayoría) al comienzo del proyecto, y si se han cometido errores yno se detectan en la etapa inmediata siguiente, es costoso y difícil volver atrás pararealizar la corrección posterior.

Además, los resultados no los veremos hasta que no estemos en las etapas finales delciclo, por lo que, cualquier error detectado nos trae retrasos y aumenta el costo deldesarrollo en función del tiempo que consume la corrección de éstos.

5.6 Metodología en V

Este ciclo fue diseñado por Alan Davis, y contiene las mismas etapas que el ciclo devida en cascada. A diferencia de aquél, a éste se le agregaron dos subetapas deretroalimentación entre las etapas de análisis y mantenimiento, y entre las de diseño ypruebas.

Mantenimiento

Pruebas

Codificación

Diseño

Análisis

N i v e l d e

a b s t r a c c i ó n

Tiempo

Validación

Verificación

Mantenimiento

Pruebas

Codificación

Diseño

Análisis




6

Las ventajas y desventajas de este modelo son las mismas del cicloanterior, con el agregado de los controles cruzados entre etapas paralograr una mayor corrección.

Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si

bien son simples (pequeñas transacciones sobre bases de datos porejemplo), necesitan una confiabilidad muy alta.

5.7 Metodología Iterativa

También derivado del ciclo de vida en cascada, este modelo busca reducir el riesgo quesurge entre las necesidades del usuario y el producto final por malos entendidosdurante la etapa de solicitud de requerimientos.

Es la iteración de varios ciclos en cascada. Al final de cada iteración se le entrega alcliente una versión mejorada con mayores funcionalidades del producto. El cliente es

quien luego de cada iteración, evalúa el producto y lo corrige o propone mejoras. Estasiteraciones se repetirán hasta obtener un producto que satisfaga al cliente.

Se suele utilizar en proyectos en los que los requerimientos no están claros de partedel usuario, por lo que se hace necesaria la creación de distintos prototipos parapresentarlos y conseguir la conformidad del cliente.

Podemos adoptar el modelo mencionado en aplicaciones medianas a grandes, en lasque el usuario o cliente final no necesita todas las funcionalidades desde el principiodel proyecto. Quizás una empresa que debe migrar sus aplicaciones hacia otraarquitectura, y desea hacerlo paulatinamente, es un candidato ideal para este tipo demodelo de ciclo de vida.




7

5.8 Metodología por prototipos

El uso de programas prototipo no es exclusivo del ciclo de vida iterativo. En la prácticalos prototipos se utilizan para validad los requerimientos de los usuarios en cualquierciclo de vida.

Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles sonlas especificaciones de forma precisa, suele recurrirse a definir especificacionesiniciales para hacer un prototipo, o sea, un producto parcial y provisional. En estemodelo, el objetivo es lograr un producto intermedio, antes de realizar el productofinal, para conocer mediante el prototipo como responderán las funcionalidadesprevistas para el producto final.

Antes de adoptar este modelo debemos evaluar si el esfuerzo por crear un prototipovale realmente la penda adoptarlo.

Se utiliza mayoritariamente en desarrollo de productos con innovaciones importantes,o en el uso de tecnologías nuevas o poco probadas, en las que la incertidumbre sobrelos resultados a obtener, o la ignorancia sobre el comportamiento, impiden iniciar unproyecto secuencial.

La ventaja de este ciclo se basa en que es el único apto para desarrollos en los que no

se conoce a priori sus especificaciones o la tecnología a utilizar. Como contrapartida,por este desconocimiento, tiene la desventaja de ser altamente costoso y difícil para laadministración temporal.

EspecificacionesIncompletas

Especificacionescompletas

Selección del

Prototipo

Desarrollo del

Prototipo

Evaluación

del Prototipo

Sub-ciclo dePrototipo




8

5.9 Metodología Evolutiva

Este modelo acepta los requerimientos del usuario pueden cambiar en cualquiermomento.

La práctica nos demuestra que obtener todos los requerimientos al comienzo delproyecto es extremadamente difícil, no solo por la dificultad del usuario de transmitirsu idea, sino porque estos requerimientos evolucionan durante el desarrollo y de estamanera, surgen nuevos requerimientos a cumplir. El modelo de ciclo de vida evolutivoafronta este problema mediante una iteración de ciclos requerimientos-desarrollo-evaluación.

Resulta ser un modelo muy útil cuando desconocemos la mayoría de losrequerimientos iniciales o estos requerimientos no están completos.

5.10 Metodología Incremental

Este modelo de ciclo de vida se basa en la filosófica de construir incrementando lasfuncionalidades del programa.

Se realiza construyendo por módulos que cumplen las diferentes funciones delsistema. Esto permite ir aumentando gradualmente las capacidades del software. Esteciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipodesarrollar un modulo particular en el caso de que el proyecto sea realizado por unequipo de programadores.

Es una repetición del ciclo de vida en cascada, aplicándoles este ciclo en cadafuncionalidad del programa a construir. Al final de cada ciclo le entregamos una




9

versión al cliente que contiene una nueva funcionalidad. Este ciclo de vida nos permiterealizar una entrega al cliente antes de terminar el proyecto.

El modelo de ciclo de vida incremental genera algunos beneficios tales como:

Construir un sistema pequeño es menos riesgoso que construir un sistemagrande.

Como se desarrollan independientemente las funcionalidades, es más fácil

relevar los requerimientos del usuario. Si se detecta un error grave, solo desechamos la última iteración. No es necesario disponer de los requerimientos de todas las funcionalidades en

el comienzo del proyecto y además facilitar la labor del desarrollo con laconocida filosofía de divide yconquistaras.

Este modelo de ciclo de vida no está pensado para cierto tipo de aplicaciones, sino queestá orientado a cierto tipo de usuario o cliente. Se puede utilizar este modelo de ciclode vida para casi cualquier proyecto, pero será verdaderamente útil cuando el usuarionecesite entregas rápidas, aunque sean parciales.

5.11 Metodología en espiral

El modelo se basa en una serie de ciclos repetitivos para ir ganando madurez en elproducto final. Toma los beneficios de los ciclos de vida incremental y por prototipos,pero se tiene más en cuenta el concepto de riesgo que aparece debido a lasincertidumbres e ignorancias de los requerimientos proporcionados al principio delproyecto o que surgirán durante el desarrollo.

A medida que el ciclo se cumple (el avance del espiral) se van obteniendo prototipos

sucesivos que van ganando la satisfacción del cliente o usuario, que en la mayoría de




10

las oportunidades no sabe con perfección todas las funcionalidades que debe tener elproducto.

En este modelo hay cuatro actividades que envuelven las etapas:

Planificación: relevamiento de requerimientos iniciales o luego de una iteración.Análisis de riesgo: de acuerdo con el relevamiento de requerimientos decidimos sicontinuamos con el desarrollo.

Implementación: desarrollamos un prototipo basado en los requerimientos.

Evaluación: el cliente evalúa el prototipo, si da su conformidad, termina el proyecto.En caso contrario, incluimos los nuevos requerimientos solicitados por el cliente en lasiguiente iteración.

La ventaja más notoria de este modelo de desarrollo de software es que puedecomenzarse el proyecto con un alto grado de incertidumbre, se entiende tambiéncomo ventaja el alto riesgo de retraso en caso de detección de errores, ya que sepuede solucionar en la próxima rama del espiral.

Algunas de las desventajas son: el costo temporal que suma cada vuelta del espiral, ladificultad para evaluar los riesgos y la necesidad de la presencia o la comunicacióncontinua con el cliente o usuario.

Se observa que es un modelo adecuado para grandes proyectos internos de unaempresa, en donde no es posible contar con todos los requerimientos desde elcomienzo y el usuario esta en nuestro mismo ambiente laboral.




11

5.12 Metodología orientada a Objetos

Esta técnica fue presentada en la década del 90, tal vez como una de las mejoresmetodologías a seguir para la creación de producto de software.

Puede considerarse como un modelo pleno a seguir, así también como una alternativadentro de los modelos anteriores.

Al igual que la filosofía del paradigma de la programación orientada a objetos, en estametodología cada funcionalidad, o requerimiento solicitado por el usuario esconsiderado como un objeto. Los objetos están representados por un conjunto depropiedades, a los cuales denominamos atributos, por otra parte al comportamientoque tendrán estos objetos los denominamos métodos.

La característica general de este modelo es la abstracción de los requerimientos delusuario, por lo que este modelo es mucho más flexible que los restantes, que sonrígidos en requerimientos y definición.

La abstracción es lo que nos permite analizar y desarrollar las características esencialesde un objeto (requerimiento), despreocupándonos de lo menos relevante.

Favorece la reducción de la complejidad del problema que deseamos abordar y

permite el perfeccionamiento del producto.

6 Bibliografía

Galvis, A. (2001). Ingeniería del Software Educativo (3 ed.). Colombia:Ediciones Unidas.

Sommerville, I. (2005). Ingeniería del Software (7 ed.). Madrid:PearsonEducation.

Conceptos Generales de Ingeniería del Software Educativo Parte II

Documents

Transcript of Conceptos Generales de Ingeniería del Software Educativo Parte II