Академический Документы
Профессиональный Документы
Культура Документы
"Ingeniera de Sistemas es la aplicacin de las ciencias matemticas y fsicas para desarrollar sistemas que utilicen econmicamente los materiales y fuerzas de la naturaleza para el beneficio de la humanidad.
IEEE Standard Dictionary of Electrical and Electronic Terms
Ingeniera de Sistemas es un conjunto de metodologas para la resolucin de problemas mediante el anlisis, diseo y gestin de sistemas.
Hall, Wymore y M'Pherson
"Ingeniera de Sistemas es la aplicacin de esfuerzos cientficos y de ingeniera para: (1) transformar una necesidad de operacin en una descripcin de parmetros de rendimiento del sistema y una configuracin del sistema a travs del uso de un proceso iterativo de definicin, sntesis, anlisis, diseo, prueba y evaluacin; (2) integrar parmetros tcnicos relacionados para asegurar la compatibilidad de todos los interfaces de programa y funcionales de manera que optimice la definicin y diseo del sistema total; (3) integrar factores de fiabilidad, mantenibilidad, seguridad, supervivencia, humanos y otros en el esfuerzo de ingeniera total a fin de cumplir los objetivos de coste, planificacin y rendimiento tcnico.
Estndar militar de las fuerzas areas estadounidenses
Definicin de Requerimientos
6
6
Una definicin reconocida es la de Clements [Cle96a]: La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema.
La vista arquitectnica es una vista abstracta, aportando el ms alto nivel de comprensin y la supresin o diferimiento del detalle inherente a la mayor parte de las abstracciones.
IEEE 610.12.1990
8
La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y evolucin.
IEEE Std 1471-2000
La aplicacin de una estrategia sistemtica, disciplinada y cuantificable al desarrollo, aplicacin y mantenimiento del software; esto es, la aplicacin de la ingeniera al software.
IEEE 610.12.1990
Como Ingeniero de Sistemas estars en capacidad de ocupar cargos como: Lder de proyectos de Ingeniera de Software Es la persona que participa en un grupo de desarrollo de proyectos informticos, en cualquiera de las etapas del ciclo de vida de una aplicacin.
Ingeniero consultor de proyectos Es el encargado de asesorar las organizaciones en la implantacin de proyectos relacionados con la informtica.
10
Auditor e interventor de proyectos con aplicacin de tecnologa Posee las bases tericas y prcticas para desempearse en el control de sistemas de una organizacin.
Ingeniero de planeacin informtica Es capaz de trabajar en una organizacin a nivel de planeacin estratgica de sistemas.
Ingeniero de soporte en informtica Resuelve los problemas operativos y tcnicos que surgen de la utilizacin de la informtica en cualquier medio.
11
El papel del profesional de sistema no es nicamente construir el prototipo sino tambin debe: - Crear el clima adecuado al usuario para que este se exprese sin temor alguno - Familiarizar al usuario con el prototipo - Crear el plan para el desarrollo del prototipo - Construir la versin inicial - Evaluar las reacciones del usuario y plasmar las modificaciones en una nueva versin
12
El papel del usuario con el Sistema puede resumirse en compromiso y honestidad. -Inicialmente debe saber transmitir las necesidades al Ingeniero de sistemas o encargado del anlisis de requerimientos. Si carece de compromiso pocos son los motivos para desarrollar un prototipo, ya que el usuario es el pivote del proceso de desarrollo y evaluacin. Los usuarios interactan con el prototipo teniendo las siguientes responsabilidades: - Utilizar y evaluar el prototipo las veces que sea necesario - Identificar mejoras - Sugerir las caracterstica no deseadas - Describir los requerimientos de datos 13 - Describir la salida deseada
14
15
16
17
18
21
CONCEPTO DE SOFTWARE ANALISIS DE REQUERIMIENTOS DISEO GLOBAL DISEO DETALLADO CODIFICACION Y DEPURACIN
1. Mtodo de cascada
22
CONCEPTO DE SOFTWARE
1. Mtodo de Cascada
Investigacin Preliminar
Aclaracin de solicitud
Tcnica Econmica
Operacional
23
* Concepto de software. * Anlisis de requerimientos. * Diseo Global. * Diseo detallado. * Codificacin y depuracin. (Construccin). * Pruebas del sistema.
Realiza una revisin al final de cada etapa.
24
VENTAJAS. Funciona bien para desarrollo de productos o mejoras de los mismos que tienen una estructura estable. (No estn sujetos a constantes cambios). Permite la localizacin de errores en las etapas ms tempranas, en las que es menos costoso corregirlos.
25
DESVENTAJAS.
puede incrementar el costo y el tiempo de desarrollo del producto y aumentar la frustracin en etapas subsiguientes.
La vuelta hacia etapas anteriores en el mtodo es posible, pero costosa, se toma la decisin de si es factible devolverse, o quedar mal con algn requerimiento.
Genera pocos signos visibles de progreso; el producto se ve funcionando, hasta sus etapas finales.
26
27
27
28
Como mtodo, su seleccin no es explcita. (Aunque en algunos casos justificados podra serlo).
29
30
Resulta altamente peligroso para proyectos de software voltiles con poca estabilidad- y a la vez grandes.
No proporciona medios de evaluacin de la calidad, o de identificacin de riesgos. Propenso a tener que rehacer trabajo de construccin cuando se detectan errores.
32
El Mtodo de Espiral se encuentra en el lado opuesto extremo del Mtodo de Codificar y Corregir.
El modelo de ciclo de vida en espiral, divide el proyecto en subproyectos y es un modelo orientado al manejo del riesgo. Cada subproyecto se centra en uno o ms riesgos.
33
El concepto riesgo se abarca y define ampliamente en este mtodo y considera: requerimientos poco definidos o no completamente entendidos, arquitecturas de diseo no bien definidas, entendidas o incompletas, problemas de construccin importantes y delicados, aspectos de rendimiento, tratamiento de las tecnologas que convivirn con el producto final esperado y con las cuales ste tendr interaccin.
34
35
36
(Continuacin).
Las primeras iteraciones sern menos costosas. Deber ser ms sencillo desarrollar la forma en la que debe de operar el sistema de software que llevar a cabo el diseo.
El Mtodo en Espiral permite la incorporacin de otros ciclos de vida, para continuar o finalizar el proyecto, una vez que se ha logrado un nivel apropiado de consideracin del riesgo, eliminacin o disminucin de ste, a niveles no problemticos.
38
An cuando el costo sube, el riesgo baja. Conforme se utilice el tiempo y los recursos adecuados en la consideracin de los riesgos, stos lograrn controlarse correctamente, lo cual es un requisito para un desarrollo ms rpido, con control apropiado del riesgo y ms eficiente, con un mucho mejor resultado esperado del producto.
Al ser la base del mtodo la consideracin del riesgo, permitir brindar en iteraciones tempranas, atencin a aquellos que se presenten difciles de superar, permitiendo determinar si es viable continuar o no, en momentos en que los costos no son excesivamente altos.
39
3. Mtodo de Espiral.
41 41
El Mtodo en Cascada plantea su principal desventaja en cuanto al tratamiento estrictamente secuencial de sus etapas.
Si se introducen modificaciones al Mtodo en Cascada, puede lograrse una mayor funcionalidad y mayores posibilidades de utilizacin, para diferentes tipos de proyectos.
42
CONCEPTO DE SOFTWARE
ANALISIS DE REQUERIMIENTOS
traslapadas
DISEO GLOBAL
43
Si se logra obtener continuidad en el desarrollo del proyecto en cuanto al grupo de participantes, la documentacin y rigurosidad de la misma impuesta al final de cada etapa por el Mtodo en Cascada, puede reducirse con iguales buenos resultados.
44
DESVENTAJAS.
La comunicacin es un factor que si no se maneja apropiadamente, puede inducir a la prdida de funcionalidad que se busca con cascada con fases traslapadas.
46
Este mtodo constituye una variante ms al mtodo original de cascada. Hay proyectos de desarrollo de sistemas para los cuales, ciertas partes bien delimitadas de los mismos son conocidas y no presenta problemas serios la consideracin de ellas. Por qu no considerar el desarrollo de las partes bien conocidas, mientras las partes que pueden presentar problemas siguen un estudio mayor?.
47
DISEO DETALLADO
CODIFICACION Y DEPURACION
DISEO DETALLADO
La consideracin de interfases entre los subproyectos es objeto de anlisis importante. Especialmente aquellas interfases que exhiban poca claridad en su definicin, relaciones y construccin.
49
CARACTERISTICAS.
(Continuacin).
La fase de anlisis de requerimientos, debe proceder consistentemente y dar paso a un buen diseo global que permita la divisin en subproyectos.
50
51
52
Modelo de Ciclo de Vida en el que se desarrolla el concepto y las caractersticas del producto, a medida que se avanza con el desarrollo. Parte, considerando el desarrollo de un prototipo con los aspectos ms visibles del producto de software. (Ej: la
interfaz de usuario; algunas transacciones bsicas que deba soportar).
53
Se presenta este prototipo a los clientes y se continua el desarrollo del producto de software sobre ste, con la retroalimentacin que se recibe.
54
55
55
En algn punto del trabajo, con el desarrollo del prototipo, hay un acuerdo con relacin al estado de la funcionalidad includa ya al producto dentro del prototipo y a su comportamiento. En este punto entonces se completa cualquier trabajo adicional y se entrega el prototipo, como producto final.
56
Puede utilizarse cuando los requerimientos cambian con rapidez. Cuando el cliente es difcil para especificar requerimientos, no sabe cmo hacerlo. Cuando no hay mucha claridad en cuanto a los requerimientos que la aplicacin debe considerar y la forma de considerarlos.
57
Refinar el prototipo hasta que sea Completar el protoaceptado tipo y entregarlo como producto final
58
59
Cuando la aplicacin de sistemas que se tenga en mente, no permita determinar con claridad al comienzo del proyecto, cundo se va a terminar el trabajo con la obtencin de un producto de software bueno. En muchas oportunidades, no se puede determinar el nmero de iteraciones a realizar sobre el prototipo y el momento en el que se debe decidir sobre ste, como producto siquiera aceptable. Si no se siguen procedimientos metodgicos ordenados de desarrollo y documentacin de los elementos resultantes del trabajo con el prototipo, se puede caer en un desarrollo Code and Fix.
60
61
Este Modelo de Ciclo de Vida de Entrega por Etapas, se conoce tambin como Modelo de Implementacin Incremental. A partir de un diseo global (arquitectura de la aplicacin de sistemas), se procede al diseo detallado, codificacin-depuracin, prueba y entrega de cada una de las etapas definidas. Cada etapa entrega una versin del producto, que se ampla incrementalmente en la etapa sucesiva, hasta la etapa final n planeada.
62
Anlisis de Requerimientos
Diseo Global Etapa 2: Diseo detallado, Codificacin-depuracin, Prueba y Entrega. Etapa 1: Diseo detallado, Codificacin-depuracin, Prueba y Entrega.
64
Hay que realizar una buena planificacin para asegurar que las etapas que se proponen, son de valor para el cliente y los usuarios. El trabajo a realizar en cada etapa debe asignarse de tal manera que se pueda cumplir con todos los tiempos estimados para la etapa. Al determinar las etapas en las que se constituir el producto, hay que asegurar el que se hayan tenido en cuenta, todas las relaciones de dependencia, entre los componentes de cada etapa y entre los componentes entre etapas, para que en una etapa no hayan sorpresas de necesitar un componente cuyo desarrollo est planificado en una etapa posterior.
65
Este Mtodo de Ciclo de Vida de Diseo por Planificacin, es similar al mtodo de Entrega por etapas. La planificacin del producto de software a desarrollar y su entrega, se planea por etapas. Aqu, el elemento distintivo, para uso de este mtodo, estriba en que no se conoce al principio, si se tendr oportunidad de tener el producto terminado para una fecha lmite de entrega del mismo, o, si el presupuesto asignado realmente alcanzar.
66
Este mtodo, utilizando una buena planificacin de las etapas del producto de software a desarrollar, que incorpore la funcionalidad del producto a las mismas, segn las prioridades de dicha funcionalidad, debe permitir tener siempre algo que entregar al final de la fecha lmite establecida, o a la terminacin del presupuesto asignado, que debe ser de valor importante como producto de software.
67
Requisito entonces, para un uso efectivo de este mtodo, es establecer con claridad las prioridades de la funcionalidad que el producto de software debe satisfacer. Estas prioridades se deben incorporar en la etapas correspondientes planeadas, de tal forma que la funcionalidad con mayor prioridad, quede incorporada en las primeras etapas a desarrollar y a entregar y, as sucesivamente, para el resto de la funcionalidad de menor prioridad, definida para el producto.
68
(Continuacin).
Al llegarse a la fecha final de entrega, o a la terminacin del presupuesto establecido, no es aceptable, no haber incorporado ya al producto, la funcionalidad crtica que ste requiere, por haber gastado tiempo y recursos desarrollando funcionalidad que no es crtica para el producto.
69
Diseo Global
Alta Prioridad: Diseo detallado,...
Entr ega
70
Garantiza la entrega de un producto al final del plazo establecido o, del presupuesto asignado.
Permite manejar de forma ms controlada, la incertidumbre en el desarrollo de productos de software, para los que se tiene una fecha de terminacin impostergable, y/o, un presupuesto dado que no admite variaciones.
71
72
73
Con la versin inicial del producto, se inicia el ciclo de iteraciones de refinamiento del mismo.
74
El proceso iterativo de refinamiento del producto, puede realizarse hasta alcanzar la fecha ltima esperada de terminacin, hasta alcanzar el presupuesto asignado, , en el mejor de los casos, hasta que se est satisfecho con el nivel del producto obtenido.
75
Entregar la versin
76
Considera el desarrollo de la funcionalidad central (ncleo) para el producto desde la etapa o iteracin inicial.
Dentro del proceso iterativo de refinamiento de la versin inicial del producto, es posible tener buenos productos en iteraciones intermedias, aunque no se haya alcanzado o incorporado toda la funcionalidad.
77
Este Mtodo de Diseo por herramientas, considera el incluir una funcionalidad a un producto de software, slo si las herramientas de software disponibles, permiten su incorporacin directamente.
Lo anterior se plantea en virtud de que en la actualidad, la existencia en el mercado de estructuras de sistemas de aplicacin completas, entornos de programacin visuales, reutilizacin de componentes,..., permite considerar el desarrollo de productos de software con base en estas piezas de software ya construidas.
79
Slo se incluye a un producto de software, la funcionalidad que est directamente soportada por herramientas y componentes de software, ya disponibles, que soporten tal funcionalidad directamente.
La funcionalidad propuesta entonces, para un producto de software, que no est directamente soportada por piezas de software existente, se deja por fuera.
80
Puede perderse control sobre el producto deseado de software. Puede que no sea posible incorporar toda la funcionalidad que se desea para el producto. Puede que la funcionalidad que se incorpore, no se realice en exactamente la forma en la que se requiere. Puede que falte capacidad para manejar los diferentes componentes y herramientas de software disponibles.
83