LOS SISTEMAS INFORMATICOS O SISTEMAS DE INFORMACION

1. DEFINICIN PREVIA SISTEMA

Un sistema es aquel que est compuesto por varios elementos que interactan entre s para llegar a un objetivo, como ejemplos pueden ser el proceso de creacin de un Software, un hardware, una impresora, nuevas tecnologas, un libro, etc., algunas definiciones de sistema. "Un sistema es un conjunto de componentes que interaccionan entre s para lograr un objetivo comn" "Sistema es una coleccin organizada de hombres, mquinas y mtodos necesaria para cumplir un objetivo especfico".
2. DEFINICIN SISTEMA DE INFORMACION

"Un conjunto integrado de procesos, principalmente formales, desarrollados en un entorno usuario-ordenador, que operando sobre un conjunto de datos estructurados (BD) de una organizacin, recopilan, procesan y distribuyen selectivamente la informacin necesaria para la operatividad habitual de la organizacin y las actividades propias de la direccin de la misma. "Un sistema de informacin es un conjunto de elementos interrelacionados con el propsito de prestar atencin a las demandas de informacin de una organizacin, para elevar el nivel de conocimientos que permitan un mejor apoyo a la toma de decisiones y desarrollo de acciones." Un sistema de informacin es el conjunto de componentes que se interrelacionan en un negocio entre el hardware, software y el personal y que realiza operaciones tales como registros de datos y actividades, que procesa los datos y la informacin dentro de una organizacin. Por lo tanto se puede decir que un sistema de informacin dentro del rea informtica es aquel en donde un usuario se interrelaciona con la computadora haciendo uso de un software para almacenar, procesar y poner la informacin a disposicin de quienes la necesiten para fines especficos.

3. FINALIDAD DE LOS SISTEMAS DE INFORMACIN

La finalidad de un sistema de informacin dentro de una organizacin es llevar una administracin y control del flujo de informacin utilizada, esto desde que se procesa la entrada de informacin, mantener archivos de datos relacionados con la organizacin y producir informacin es decir informes, estadsticas, reportes.
4. OBJETIVOS

Respaldar las operaciones empresariales. Respaldar la toma de decisiones gerenciales. Respaldar la ventaja competitiva estratgica. Contribuir a la automatizacin de actividades y procesos en las empresas. Llevar la informacin de manera oportuna y adecuada a las instancias de la empresa que as lo requieran. Proporcionar un diagnstico de la empresa en un momento dado.
5. ESTRUCTURA DE UN SI

Los sistemas informticos suelen estructurarse en subsistemas. Subsistema fsico: asociado al hardware. Incluye entre otros elementos la CPU, memoria principal, la placa base, etc. Subsistema lgico: asociado al software y la arquitectura. Incluye al sistema operativo, el firmware, las aplicaciones y las bases de datos. Recursos humanos: hace referencia al personal que est relacionado con el sistema. Especialmente usuarios y tcnicos (analistas, diseadores, programadores, operarios, mantenedores, etc.)
6. ELEMENTOS Y/O COMPONENTES DE LOS SISTEMAS DE INFORMACIN

Los sistemas de informacin dependen de otros subsistemas componentes para poder llevar a cabo las actividades de entrada, proceso, salida, almacenamiento y control que convierten recursos de datos en productos de informacin. Estos subsistemas incluyen personas, hardware, software, procedimientos y datos. En lo que sigue se detalla sobre cada uno de ellos.

Personas: Un sistema de cmputo involucra una variada gama de personas relacionadas con el mismo, puesto que su construccin, mantenimiento y uso representan una labor con cierto grado de complejidad. Se pueden dividir en dos grandes grupos: Los usuarios finales y los especialistas o profesionales. Los usuarios finales son aquellos que operan o interaccionan directamente con el sistema a travs de una estacin de trabajo o incluso, quienes reciben reportes e informacin generada por el sistema. Entre los profesionales se encuentran: Los analistas de los sistemas de informacin, encargados de idear soluciones cuando se requiere un nuevo sistema, actualizarlo, modificarlo o reconstruirlo; los programadores, que crean los programas de cmputo que forman parte de los sistemas de informacin; los administradores del sistema, encargados de mantener el sistema en buenas condiciones; los capacitadores, que instruyen y preparan a los usuarios para la utilizacin del sistema. Hardware: Consiste en los equipos, dispositivos y medios necesarios que constituyen la plataforma fsica mediante la cual, el sistema de informacin puede funcionar. Se incluyen aqu, por supuesto, los que permiten las comunicaciones y los enlaces de red. Estos recursos son, por ejemplo, computadoras, monitores, impresoras, disquetes o componentes de almacenamiento de informacin externos, disco ptico, papel de impresin, cableado de red, y otros. Software o programas: Son el componente lgico, es decir, los programas, las rutinas e instrucciones que conforman el sistema de informacin. Se les suele denominar aplicacin de sistema de informacin. Es as como los sistemas de informacin pueden tener aplicaciones particulares, por ejemplo, para el rea de ventas, de contabilidad, de personal o de compras. La aplicacin que conforma un sistema de informacin completo contiene subconjuntos de programas que se encargan de apoyar las distintas actividades propias de la organizacin.

Cuando se habla de sistema de informacin, las personas suelen pensar que se refiere slo a la aplicacin, al conjunto de programas que la constituye. En general este es el uso convencional y aceptado, pero realmente es slo una parte, un componente o subsistema como se ha explicado.

Datos: Unidades de informacin que son almacenadas y generadas en el transcurrir de la labor de la empresa. Los datos son almacenados en las denominadas bases de datos o bases de conocimiento.

7. FUNCIONAMIENTO DE LOS SISTEMAS DE INFORMACIN

Todo sistema de informacin est dividido en una serie de cuatro funciones o etapas principales conocidas como actividades bsicas, estas son: 1. Entrada de informacin. 2. Almacenamiento de Informacin. 3. Procesamiento de informacin. 4. Salida de informacin.
Actividades Bsicas

Entrada de information La entrada es el proceso mediante el cual el sistema de informacin toma los datos que requiere para procesar la informacin. Las entradas pueden ser manuales o automticas. Almacenamiento de informacin. El almacenamiento es una de las actividades o capacidades ms importantes que tiene una computadora, ya que a travs de esta propiedad el sistema puede recordar la informacin guardada en la sesin o Proceso anterior. Procesamiento de informacin. Es la capacidad del sistema de informacin para efectuar clculos de acuerdo con una secuencia de operaciones preestablecidas. Salida de Informacin La salida es la capacidad del sistema de informacin para sacar la informacin procesada o bien datos de entrada al exterior. Es importante aclarar que la salida de un sistema de informacin puede constituir la entrada a otro sistema de informacin o modulo.

8. Esquema de un SI

9. Clasificacin de los SI

Evolucin de los sistemas de informacin a lo largo del tiempo.

Debido a que el principal uso que se da a los SI es el de optimizar el desarrollo de las actividades de una organizacin con el fin de ser ms productivos y obtener ventajas competitivas, en primer trmino, se puede clasificar a los sistemas de informacin en:

Sistemas Competitivos Sistemas Cooperativos Sistemas que modifican el estilo de operacin del negocio

Esta clasificacin es muy genrica, y en la prctica no obedece a una diferenciacin real de sistemas de informacin reales, ya que en la prctica podramos encontrar alguno que cumpla varias (dos o las tres) de las caractersticas anteriores. En los subapartados siguientes se hacen unas clasificaciones ms concretas (y reales) de sistemas de informacin. Clasificacin Desde un punto de vista empresarial Segn la funcin a la que vayan destinados o el tipo de usuario final del mismo, los SI pueden clasificarse en:

Sistema de procesamiento de transacciones (TPS).- Gestiona la informacin referente a las transacciones producidas en una empresa u organizacin. Sistemas de informacin gerencial (MIS).- Orientados a solucionar problemas empresariales en general. Sistemas de soporte a decisiones (DSS).- Herramienta para realizar el anlisis de las diferentes variables de negocio con la finalidad de apoyar el proceso de toma de decisiones. Sistemas de informacin ejecutiva (EIS).- Herramienta orientada a usuarios de nivel gerencial, que permite monitorizar el estado de las variables de un rea o unidad de la empresa a partir de informacin interna y externa a la misma. Sistemas de automatizacin de oficinas (OAS).- Aplicaciones destinadas a ayudar al trabajo diario del administrativo de una empresa u organizacin. Sistema experto (SE).- Emulan el comportamiento de un experto en un dominio concreto. Sistema Planificacin de Recursos (ERP).- Integran la informacin y los procesos de una organizacin en un solo sistema.

Estos sistemas de informacin no surgieron simultneamente en el mercado; los primeros en aparecer fueron los TPS, en la dcada de los 60, y los ltimos fueron los SE, que alcanzaron su auge en los 90 (aunque estos ltimos tuvieron una tmida aparicin en los 70 que no cuaj, ya que la tecnologa no estaba suficientemente desarrollada). Clasificacin de Sistemas de Informacin Estratgicos Un Sistema de Informacin Estratgico puede ser considerado como el uso de la tecnologa de la informacin para soportar o dar forma a la estrategia competitiva de la organizacin, a su plan para incrementar o mantener la ventaja competitiva o bien reducir la ventaja de sus competidores. Su funcin primordial no es apoyar la automatizacin de los procesos operativos ni proporcionar informacin para apoyar a la toma de decisiones (aunque puede llevar a cabo dichas funciones), sino crear una diferencia con respecto a los competidores de la organizacin (o

salvar dicha diferencia) que hagan ms atractiva a sta para los potenciales clientes. Por ejemplo, en la banca, hace aos que se implantaron los cajeros automticos, pero en su da, las entidades que primero ofrecieron este servicios disponan de una ventaja con respecto a sus competidores, y hoy da cualquier entidad que pretenda ofrecer servicios bancarios necesita contar con cajeros automticos si no quiere partir con una desventaja con respecto al resto de entidades de este sector. En este sentido, los cajeros automticos se pueden considerar sistemas de informacin estratgicos. Su funcin es lograr ventajas que los competidores no posean, tales como ventajas en costos y servicios diferenciados con clientes y proveedores. Apoyan el proceso de innovacin de productos dentro de la empresa. Suelen desarrollarse dentro de la organizacin, por lo tanto no pueden adaptarse fcilmente a paquetes disponibles en el mercado. Entre las caractersticas ms destacables de estos sistemas se pueden destacar:

Cambian significativamente el desempeo de un negocio al medirse por uno o ms indicadores clave, entre ellos, la magnitud del impacto. Contribuyen al logro de una meta estratgica. Generan cambios fundamentales en la forma de dirigir una compaa, la forma en que compite o en la que interacta con clientes y proveedores.

Otra clasificacin, segn el entorno de aplicacin

Entorno transaccional: Una transaccin es un suceso o evento que crea/modifica los datos. El procesamiento de transacciones consiste en captar, manipular y almacenar los datos, y tambin, en la preparacin de documentos; en el entorno transaccional, por tanto, lo importante es qu datos se modifican y cmo, una vez ha terminado la transaccin. Los TPS son los SI tpicos que se pueden encontrar en este entorno. Entorno decisional: Este es el entorno en el que tiene lugar la toma de decisiones; en una empresa, las decisiones se toman a todos los niveles y en todas las reas (otra cosa es si esas decisiones son estructuradas o no), por lo que todos los SI de la organizacin deben estar preparados para asistir en esta tarea, aunque tpicamente, son los DSS los que se encargan de esta funcin. Si el nico SI de una compaa preparado para ayudar a la toma de decisiones es el DSS, ste debe estar adaptado a todos los niveles jerrquicos de la empresa.

10. ARQUITECTURA DE LOS SI Centralizados Descentralizados Distribuidos

(04) Trabajo taller 01: Propuesta de Sistema de Informacin a desarrollar como trabajo prctico de semestre Ejemplificacin de Sistemas de Informacin de acuerdo a la clasificacin de los SI. ARQUITECTURA DE LOS SI (desarrollar archivo diseo y creacin de SI pdf.) 11. Centralizados 12. Descentralizados 13. Distribuidos 14. Ventajas y Desventajas de c/u. LA EMPRESA 15. Caractersticas generales 16. Procesos que se llevan a cabo en las empresas 17. Conceptos relacionados. Trabajo taller 02: Determinacin de la arquitectura del Sistema de Informacin propuesto. Necesidades de informacin de las empresas Identifique y detalle cada uno de los procesos que se llevan a cabo en la empresa propuesta. (04) El ANALISIS DE SISTEMAS Y EL ANALISTA DE SISTEMAS (ARCHIVO AYDS01.PDF) 18. La informacin como un recurso de las organizaciones. 19. Conceptos De Anlisis Y Diseo De Sistemas 20. El Papel De El Analista De Sistemas 21. Funciones del Analista de Sistemas 22. Ciclo de vida de los sistemas de informacin 23. Uso de herramientas case (04) COMPRENSION DE LOS ESTILOS ORGANIZACIONALES Y SU IMPACTO SOBRE LOS SISTEMAS DE INFORMACION 24. Fundamentos Organizacionales 25. La Organizaciones como Sistemas 26. La Informacin como Activo de las Organizaciones y las empresas Trabajo taller 03: Identificacin de los Niveles de Administracin, Cultura organizacional y el diseo de la organizacin o empresa propuesta para el desarrollo de software del curso. Proponga el rol a cumplir como analista de sistemas en la empresa propuesta para el desarrollo de software del curso. (04)

EL PROCESO DE DESARROLLO DE SOFTWARE Definicin Actividades Fundamentales en el Proceso de Desarrollo de Software 27. Especificacin de software 28. Diseo e implementacin 29. Validacin 30. Evolucin

Elementos del Proceso de Desarrollo de Software y sus relaciones ACTIVIDAD TALLER Despus de la investigacin realizada y el anlisis sobre modelos de software, estraiga Ud. Los ms interesante de cada modelo y proponga Ud. un modelo de desarrollo segn su propio criterio, considerando fases y/o etapas, descripcin de cada fase.

METRICA 3 TALLER 01: PLANIFICACION DEL DESARROLLO DE INFORMACION 31. Actividad N 1: Inicio del Plan de Sistemas de Informacin 32. Anlisis de las Necesidades de 33. SISTEMAS DE

MODELOS DEL PDS

34. Codificar y corregir (Code-and-Fix) 1. Modelo en cascada 2. Desarrollo evolutivo 3. Desarrollo basado en reutilizacin 4. Desarrollo e integracin. 5. Procesos iterativos b. Desarrollo incremental c. Desarrollo en espiral METODOLOGAS DE DESARROLLO DE SOFTWARE a) Metodologas estructuradas b) Metodologas orientadas a objetos c) Metodologas tradicionales (no giles) d) Metodologas giles PROCESO UNIFICADO DE RATIONAL 35. Principios de desarrollo 36. Ciclo de vida 37. Principales caractersticas LENGUAJE DE MODELAMIENTO UNIFICADO UML 38. Caractersticas de UML i. Los Diagramas en UML

39.

40.

PROCESO DE DESARROLLO DE SOFTWARE

Proceso de negocio, o caso de uso de negocio, de un negocio de desarrollo de software. Conjunto total de actividades necesarias para transformar los requisitos de un cliente en un conjunto consistente de artefactos que representan un producto software y en punto posterior en el tiempo para transformar cambiso en dichos requisitos en nuevas versiones del producto. El proceso de desarrollo de software puede definirse como un conjunto de herramientas, mtodos y prcticas que se emplean para producir software. Como cualquier otra organizacin, las dedicadas al desarrollo de software mantienen entre sus FIN: la produccin de software de acuerdo con la planificacin inicial realizada, adems de una constante mejora y/o evolucin del software OBJETIVOS: alta calidad en la produccin de softwware bajo costo, en el mnimo tiempo. La mayora de estas funciones y tcnicas de gestin y control empleadas, se han importado de otras industrias de produccin que desarrollaron estos mtodos a principios de siglo.

Proceso de Desarrollo de Software: Proceso de negocio, o caso de uso de negocio, de un negocio de desarrollo de software. Conjunto total de actividades necesarias para transformar los requisitos de un cliente en un conjunto consistente de artefactos que representan un producto software y en punto posterior en el tiempo para transformar cambiso en dichos requisitos en nuevas versiones del producto. 1. Lenguaje Unificado de Modelado (UML): Lenguaje estandar para el modelado de software lengauje para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. Lenguaje usado por el Proceso Unificado. Lenguaje que permite a los desarrolladores visualizar el producto de su trabajo (Artefactos) en esquemas o diagramas estandarizados. 2. Proceso Unificado de Desarrollo de Software (PUDS): Proceso de desarrollo de software basado en el Lenguaje Unificado de Modelado y que es iterativo, centrado en la arquitectura y dirigido por los casos de uso y los riesgos. Proceso que se organiza en cuatro fases: inicio, elaboracion, construccion y transicion, y que se estructura en torno a cinco flujos de trabajo fundamentales: recopilacion de requisitos, analisis, diseo, implementacion y pruebas. Proceso que se describe en terminos de un modelo de negocio, el cual esta a su vez estructurado en funcion de tres bloques de construccion primordiales trabajadores, actividades y artefactos. 3. Requisitos: Flujo de trabajo fundamental cuyo proposito esencial es orientado al desarrollado hacia el sistema correcto. Esto se lleva a cabo mediante la descripcion de los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entre el cliente(incluyendo los usuarios) y los desarrolladores del sistema, acerca de lo que el sistema debe hacer y lo que no. 4. Analisisis: Flujos de trabajo fundamental cuyo proposito principal es analizar los requisitos descritos en la captura de requisitos, mediante su refinamiento y estructuracion. El objetivo de esto es (1) lograr una comprension mas precisa de los requisitos, y (2) obtener una descripcion de los requisitos que sea facil de mantener y que nos ayude a dar estructura al sistema en su conjunto incluyendo su arquitectura. 5. Diseo: Flujo de trabajo fundamental cuyo proposito principal es la de formular modelos que se centran en los requisitos no funcionales y el dominio de la solucion y que prepara para la implementacion y pruebas del sistema. 6. Implementacion: Flujo de trabajo fundamental cuyo proposito esencial es implementar el sistema en terminos de componentes, es decir codigo fuente guiones, ficheros binarios, ejecutables, et. 7. Prueba: Flujo de trabajo fundamental cuyo proposito esencial es comprobar el resultado de la implementacion mediante las pruebas de cada construccion, incluyendo tanto construcciones internas como intermedias, asi como las versiones finales del sistema que van a ser entregadas a terceras personas. 8. Fase de Inicio: Primera fase del ciclo de vida del software, en la que la idea inicial para el desarrollo es refinada hasta el punto de quedar lo

suficientemente bien establecida como para garantizar la entrada en la base de elaboracion. 9. Fase de Elaboracion: Segunda fase del ciclo de vida, en la que se define la arquitectura. 10. Fase de Construccion: Tercera fase del ciclo de vida del software, en la que el software es desarrollado a partir de una linea base de la arquitectura ejecutable, hasta el punto en el que se esta listo para ser transmitido a las comunidades de usuarios. 11. Fase de Transicion: Cuarta fase del ciclo de vida del software es puesto en manos de la comunidad de usuarios. 12. Arquitectura: Conjunto de desiciones significativas, acerca de la organizacion de un sistema software, la seleccion de los elementos estructurales apartir de los cuales se compone el sistema y las interfaces entre ellos, junto con su comportamiento, tal y como se especifica en las colaboraciones entre estos elementos, la composicion de estos elementos estructurales y de comportamiento de subsistemas progresivamente mayores, y el estilo arquitectonico que guia esta organizacion, estos elementos y sus interfaces, sus colaboraciones y su composicion. La arquitectura de software se interesa no solo por la estructura y el comportamiento, sino tambien por las restricciones y compromisos de uso, funcionamiento, flexibilidad al cambio, reutilizacion, comprension, economia y tecnologia, asi como aspectos esteticos. 13. Vista Arquitectonica del Modelo de Casos de Uso: Vista de la arquitectura de un sistema abarcando los casos de uso significativos desde un punto de vista arquitectonico. 14. Vista Arquitectonica del Modelo de Analisis: Vista arquitectonica de un sistema, abarcando las clases, paquetes y realizaciones de casos de uso del analisis, vista que fundamentalmente aborda el refinamiento y estructuracion de los requisitos del sistema. La estrucutra de esta vista se preserva en la medida de lo posible cuando se disea e implementa la arquitectura del sistema. 15. Vista Arquitectonica del Modelo de Diseo: Vista de la arquitectura de un sistema, abarcando las clases , subsistemas, interfaces y realizaciones de casos de uso del diseo que forman el vocabulario del dominio de la solucion del sistema, vista que abarca tambien los hilos y procesos qeu establecen la concurrencia y mecanismos de sincronizacion del sistema, vista que aborda los requisitos no funcionales, incluyendo los requisitos de rendimiento y capacidad de crecimiento de un sistema. 16. Vista Arquitectonica del Modelo de Despliege: Vista de la arquitectura de un sistema abarcando los nodos que forman la topologia hardware sobre la que se ejecuta el sistema, vista que aborda la distribucion, entrega e instalacion de las partes que constituyen el sistema fisico. 17. Vista Arquitectonica del Modelo de Implementacion: Vista arquitectonica de un sistema, abarcando los componentes usados para el ensamblado y lanzamiento del sistema fisico, vista que aborda la gestion de la configuracion de las versiones del sistema, constituida por

componentes independientes que pueden ser ensambladas de varias formas para producir un sistema ejecutable

(i) Anlisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software. La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aun no est formalizada, ya se habla de la Ingeniera de Requisitos. La IEEE Std. 830-1998 normaliza la creacin de las Especificaciones de Requisitos Software (Software Requirements Specification).

(ii) Diseo y arquitectura

Se refiere a determinar como funcionar de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementacin tecnolgica, como el hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizar el sistema, y se transforman las entidades definidas en el anlisis de requisitos en clases de diseo, obteniendo un modelo cercano a la programacin orientada a objetos.

(iii) Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de software, pero no es necesariamente la porcin ms larga. La complejidad y la duracin de esta etapa est intimamente ligada al o a los lenguajes de programacin utilizados.

(iv) Pruebas
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificacin. Una tcnica de prueba es probar por separado cada mdulo del software, y luego probarlo de forma integral,para as llegar al objetivo. Se considera una buena practica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un area de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como estn descritas. El segundo enfoque es tener un area de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en que condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara.

(v) Documentacin
Todo lo concerniente a la documentacin del propio desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales tcnicos, etc; todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

(vi) Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniera de software tiene que ver con dar mantenimiento. Una pequea parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniera civil, arquitectura y trabajo de construccin es dar mantenimiento.

(b) Proceso de creacin de software

Se define como Proceso al conjunto ordenado de pasos a seguir para llegar a la solucin de un problema u obtencin de un producto, en este caso particular, para lograr la obtencin de un producto software que resuelva un problema. Ese proceso de creacin de software puede llegar a ser muy complejo, dependiendo de su porte, caractersticas y criticidad del mismo. Por ejemplo la creacin de un sistema operativo es una tarea que requiere proyecto, gestin, numerosos recursos y todo un equipo disciplinado de trabajo. En el otro extremo, si se trata de un sencillo programa (ejemplo: resolucin de una ecuacin de segundo orden), ste puede ser realizado por un solo programador (incluso aficionado) fcilmente. Es as que normalmente se dividen en tres categoras segn su tamao (lneas de cdigo) y/o costo: de Pequeo, Mediano y Gran porte. Existen varias metodologas para estimarlo, una de las ms populares es el sistema COCOMO que provee mtodos y un software (programa) que calcula estimadamente todos los costos de produccin en un "proyecto software" (relacin horas/hombre, costo monetario, cantidad de lneas fuente de acuerdo a lenguaje usado, etc.). Considerando los de gran porte, es necesario realizar tantas y tan complejas tareas, tanto tcnicas, de gerenciamiento, fuerte gestin y anlisis diversos (entre otras) que toda una ingeniera hace falta para su estudio y realizacin: es la Ingeniera de Software. En tanto que en los de mediano porte, pequeos equipos de trabajo (incluso un avesado analistaprogramador solitario) puede realizar la tarea. Aunque, siempre en casos de mediano y gran porte (y a veces tambin en algunos de pequeo porte, segn su complejidad), se deben seguir ciertas etapas que son necesarias para la construccin del software. Tales etapas, si bien deben existir, son flexibles en su forma de aplicacin, de acuerdo a la metodologa o Proceso de Desarrollo escogido y utilizado por el equipo de desarrollo o analista-programador solitario (si fuere el caso). Los "procesos de desarrollo de software" poseen reglas preestablecidas, y deben ser aplicados en la creacin del software de mediano y gran porte, ya que en caso contrario lo ms seguro es que el proyecto o no logre concluir o termine sin cumplir los objetivos previstos y con variedad de fallos inaceptables (fracasan, en pocas palabras). Entre tales "procesos" los hay giles o livianos (ejemplo XP), pesados y lentos (ejemplo RUP) y variantes intermedias; y normalmente se aplican de acuerdo al tipo y porte y tipologa del software a desarrollar, a criterio del lder (si lo hay) del equipo de desarrollo. Algunos de esos procesos son Extreme Programming (XP), Rational Unified Process (RUP), Feature Driven Development (FDD), etc. Cualquiera sea el "proceso" utilizado y aplicado en un desarrollo de software (RUP, FDD, etc), y casi independientemente de l, siempre se debe aplicar un "Modelo de Ciclo de Vida". Se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificaciones que lo retrazan y un 26% son totalmente exitosos. Cuando un proyecto fracasa, rara vez es debido a fallas tcnicas, la principal causa de fallos y fracasos es la falta de aplicacin de una buena metodologa o proceso de desarrollo. Entre otras, una fuerte tendencia, desde hace pocas dcadas, es mejorar las metodologas o procesos de desarrollo, o crear nuevas y concientizar a los

profesionales en su utilizacin adecuada. Normalmente los especialistas en el estudio y desarrollo de estas reas (metodologas) y afines (tales como modelos y hasta la gestin misma de los proyectos) son los Ingenieros en Software, es su orientacin. Los especialistas en cualquier otra rea de desarrollo informtico (analista, programador, Lic. en Informtica, Ingeniero en Informtica, Ingeniero de Sistemas, etc.) normalmente aplican sus conocimientos especializados pero utilizando modelos, paradigmas y procesos ya elaborados. Es comn para el desarrollo de software de mediano porte que los equipos humanos involucrados apliquen sus propias metodologas, normalmente un hbrido de los procesos anteriores y a veces con criterios propios. El proceso de desarrollo puede involucrar numerosas y variadas tareas, desde lo administrativo, pasando por lo tcnico y hasta la gestin y el gerenciamiento. Pero casi rigurosamente siempre se cumplen ciertas etapas mnimas; las que se pueden resumir como sigue:

Captura (elicitacin) y Especificacin de requisitos (ERS) Anlisis Diseo Codificacin Pruebas (unitarias y de integracin) Instalacin y paso a Produccin Mantenimiento

En las anteriores etapas pueden variar ligeramente sus nombres o ser ms globales, por ejemplo indicar como una nica fase (a los fines documentales e interpretativos) el Anlisis y el Diseo; o indicar como "Implementacin" lo que est dicho como "Codificacin"; pero en rigor, todas existen e incluyen, bsicamente,las mismas tareas especficas.