1) Ciclo de vida de un sistema.

Son los pasos a seguir desde que se comienza con la necesidad de un sistema hasta
que el mismo es sustituido.
Fases
1.-Requerimientos

Esta fase es fundamental para que la estrategia informtica encaje dentro de las
metas de la empresa, ya que en ella se cumplen las funciones del modelaje del
negocio y planificacin de sistemas; esto con el fin de proyectar las estrategias del
negocio y determinar de esta forma sus requerimientos de informacin.
Durante esta fase se desarrolla un modelo del rea estudiada, donde se representa,
los procesos que se llevan a cabo, la informacin utilizada por ellos y las reglas
polticas y prcticas de la empresa relacionada con estos procesos.
El Plan de Sistemas debe contener:
Los sistemas que requiere el rea del negocio, as como sus bases de
datos y la informacin que intercambiaran o compartieran.
Descripcin detallada de cada sistema y aplicacin incluyendo sus
objetivos funcionales y sus bases de diseo.
Todo hardware y software que sern utilizados para el funcionamiento
requerido por el rea de negocio.
Mtodos de desarrollo para cada sistema como lo es adquisicin de
paquetes, nuevo desarrollo o actualizaciones
Esquema de los problemas actuales del rea de negocio y de las posibles
mejoras que se puedan realizar en cada sistema
Anlisis de los beneficios que se espera derivar de los sistemas que
conforman la arquitectura

El plan de sistemas de informacin es uno de los factores ms importantes para el
departamento de informtica o sistemas ya que constituye la gua para emprender
los proyectos que requiera el cliente, reclutar y adiestrar al personal necesario y la
adquisicin e instalacin de hardware y software necesarios.

2.- Anlisis / Diseo
Desarrollar el diseo de los sistemas, utilizando los requerimientos obtenidos en la
primera fase. En el diseo arquitectnico se engloban dos componentes: los datos y
los procesos, los cuales sern analizados y diseados desde una perspectiva
conceptual a una fsica, dentro de las cuatros actividades que se encuentran en esta
fase.
Analizar y Disear Proceso: Las operaciones del negocio y los
requerimientos de funcionamiento definidos en la primera fase, se toman
en cuenta con el propsito de determinar la forma en que debe funcionar
el sistema.
Analizar y Disear Los Datos: Con los requerimientos de informacin
definidos en la fase I se debe organizar los distintos modelos de datos
que nos ayuden a disear la base de datos que hagan falta para que el
sistema funcione de acuerdo al modelo de funcionamiento.
Disear y Organizar Los Componentes Fsicos: Todo componente fsico
como (pantallas, base de datos) que hagan posible el funcionamiento del
sistema de acuerdo al modelo de funcionamiento.
Planificar El Desarrollo De Los Componentes Fsicos: actividad en la cual
planificamos la forma en que pueden ser construidos e implementados
los componentes fsicos de una forma rpida y productiva.

En esta fase de anlisis / diseo puede incluirse una sub.-fase de evaluacin de
paquetes. Esta se pudiese realizar si en los requerimientos se estableci adquirir un
paquete de aplicaciones en lugar de completar un diseo arquitectnico.
3.- Construccin
Dentro de esta fase de construccin existen actividades separadas en cinco sub.-
fases:
Desarrollo De Infraestructura. Durante esta fase se desarrollar y
organizar la infraestructura que permita cumplir las tareas de
construccin en la forma ms productiva posible.
Adaptacin De Paquete. Conocer al mximo detalle posible el
funcionamiento del paquete que ser utilizado con el mximo provecho,
para el negocio, como de la utilizacin de recursos.

Desarrollo De Unidades De Diseo Interactivas. Son procedimientos que
se cumple o se ejecutan a travs de un dialogo usuario sistema.
Las actividades de esta sub-fase tienen como objetivo central:
Especificar en detalle las tareas que debe cumplir la unidad de diseo
Desarrollar componentes
Realizar las pruebas unitarias y las pruebas de integracin a nivel de la
unidad de diseo.
Desarrollo De Unidades De Diseo Batch. Son especificaciones hechas utilizando
una combinacin de tcnicas como flujogramas, diagramas de estructuras, tablas
de decisiones etc. Tiene que ser clara y que logre el propsito de que el
programador comprenda y pueda programar y probar los programas
correspondientes.
Desarrollo De Unidades De Diseo Manuales. Desarrolla todos los
procedimientos administrativos que rodearn y gobernarn la utilizacin de los
componentes computarizados desarrollados en la fase de diseo detallado y
construccin.
4.- Pruebas
Esta fase, da inicio luego de que las diferentes unidades de diseo han sido
desarrolladas y probadas por separado. Durante su desarrollo, el sistema se
emplea de forma experimental para asegurar que el software no falle, es decir que
funcione de acuerdo a sus especificaciones y a la manera que los usuarios esperan
que lo haga, y de esta forma poder detectar cualquier anomala, antes de que el
sistema sea puesto en marcha y se dependa de l. Para evaluar el desenvolvimiento
del sistema, en esta fase se llevan a cabo varios niveles de prueba:
Funcional: Prueba desde el punto de vista de los requerimientos
funcionales.
De Sistema: Prueba desde el punto de vista de los niveles de calidad del
sistema y de desempeo.
De Integracin: Prueba de interfaces.
De Aceptacin Tcnica: Prueba de manejo de condiciones extremas.

Si el Sistema cumple de forma satisfactoria con estos niveles mencionados
anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas
del nuevo sistema, para de esta forma dar inicio al proceso de aceptacin final,
durante el cual, el sistema comenzar a funcionar bajo la responsabilidad del
departamento de operaciones y del usuario, por un lapso determinado de tiempo
llamado Periodo de Aceptacin.
Finalizado el Periodo de Aceptacin, se le dar al sistema la aprobacin final, para
que pase a ser el sistema oficial.
5.- Produccin / Mantenimiento
Una vez que un sistema pasa a formar parte de la vida diaria de la empresa, cada
programa, cada procedimiento y cada estructura de datos se convierte en una
pieza del negocio que, como tal, deber funcionar en forma constante, exacta y
confiable. La operacin del negocio ahora depender del funcionamiento del
sistema, por lo que las tareas de mantenimiento cobran vital importancia.
Durante la fase de mantenimiento, se ponen en prctica todas las polticas y los
procedimientos destinados a garantizar la operacin continan de los de los
sistemas y a asegurar su uso efectivo, con el fin, de que stos se constituyan en una
verdadera herramienta de apoyo al logro de los objetivos estratgicos de la
empresa
2) Atributos de un software
Dentro de los atributos del software se tiene que mencionar la calidad ya que es de
importancia dentro de sus caractersticas y aplicaciones.
La calidad del software es el conjunto de cualidades que lo caracterizan y que
determinan su utilidad y existencia, es sinnimo de eficiencia, flexibilidad,
correccin, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e
integridad y es medible ya que vara de un sistema a otro o de un programa a otro.
Factores externos
Facilidad de mantenimiento. De fcil evolucin para adaptarse a las necesidades
de cambio de los clientes.
Confiabilidad. No debe causar daos fsicos o econmicos en el caso de fallo del
sistema, Fiabilidad, seguridad y proteccin
Eficacia. Hacer efectivo el propsito del software
Usabilidad. Debe tener una interfaz de usuario apropiada y una documentacin
adecuada
Reusabilidad. Capacidad de que un software pueda utilizarse en un contexto
diferente al de su creacin
Portabilidad. Facilidad de transferir productos software a diferentes plataformas
Factores internos
Facilidad de traza Legibilidad
Modularidad Facilidad de expansin
Tolerancia a fallos Independencia del sistema
Eficiencia de ejecucin Independencia del hardware
Eficiencia de almacenamiento Estandarizacin de datos
Autodescripcin Estandarizacin de comunicaciones

3) Modelos de proceso de un software
Si un Proceso de Software es un conjunto de actividades y resultados asociados,
que generan un producto, entonces haciendo un modelo de este realizamos un
proceso que nos muestre un diseo de algo real.
Enfoque de Cascada
Ha sido el ms utilizado y en la actualidad, pese a la aparicin de metodologas
giles, sigue siendo la solucin predominante, si bien, en cada organizacin o en
cada de proyecto se puede llevar a cabo con ciertas variantes.
Anlisis: Esta fase comprendera desde la posible obtencin de unos objetivos o
requisitos iniciales para determinar la viabilidad del sistema y escrutar las distintas
alternativas de solucin.
Diseo: El anlisis describe el sistema sin entrar en caractersticas propias de la
implementacin, es en esta fase donde se adapta ese anlisis generalista a la
solucin concreta que se quiere llevar a cabo.
Codificacin: En esta fase se realiza la construccin del sistema de informacin y
las pruebas relacionadas con dicho proceso, como son las unitarias, integracin y
de sistema.
Pruebas: En esta etapa se realizara la instalacin del sistema en un entorno de
pruebas lo ms parecido posible al de produccin (entorno de preproduccin)
donde se realizaran las pruebas de implantacin (que verifican principalmente
aspectos no funcionales) y las de aceptacin.
Mantenimiento: Una vez que el sistema se encuentra en produccin, se realizarn
sobre el mismo diversas tareas de mantenimiento, que en funcin de su naturaleza
se clasifican en correctivos, evolutivos, adaptativos y perfectivos.
El principal inconveniente que se le ha achacado siempre a este tipo de ciclo de
vida es que los usuarios tardan demasiado en ver los resultados, lo que hace que el
tiempo transcurrido desde que se define el sistema hasta que est disponible sea lo
suficientemente amplio como para que hayan ocurrido muchas cosas
Desarrollo Evolutivo
Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente
para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza
con las partes del sistema que se comprenden mejor. El sistema evoluciona
agregando nuevos atributos propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es
comprender los requerimientos del cliente y entonces desarrollar una definicin
mejorada de los requerimientos para el sistema. El prototipo se centra en
experimentar con los requerimientos del cliente que no se comprenden del todo.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer
ms ventajas en comparacin con un enfoque en cascada ya que el sistema se va
ajustando a las necesidades del cliente, a la vez que l mismo entiende mejor sus
propios requerimientos
Desarrollo Formal
Se usa para referirse a cualquier actividad relacionada con representaciones
matemticas del software, incluyendo la especificacin formal de sistemas, anlisis
y demostracin de la especificacin, el desarrollo transformacional y la verificacin
de programas. Todas estas actividades dependen de una especificacin formal del
software.
Una especificacin formal del software es una especificacin expresada en un
lenguaje cuyo vocabulario, sintaxis y semntica estn formalmente definidos. Esta
necesidad de una definicin formal significa que los lenguajes de especificacin
deben basarse en conceptos matemticos cuyas propiedades se comprendan bien.
La rama de las matemticas usada es la de matemtica discreta, y los conceptos
matemticos provienen de la teora de conjuntos, la lgica y el lgebra.
Ventajas
o Se comprende mejor el sistema.
o La comunicacin con el cliente mejora ya que se dispone de una
descripcin clara y no ambigua de los requisitos del usuario.
o El sistema se describe de manera ms precisa.
o El sistema se asegura matemticamente que es correcto segn las
especificaciones.
o Mayor calidad software respecto al cumplimiento de las
especificaciones.
o Mayor productividad
Desventajas
o El desarrollo de herramientas que apoyen la aplicacin de mtodos formales
es complicado y los programas resultantes son incmodos para los usuarios.
o Los investigadores por lo general no conocen la realidad industrial.
o Es escasa la colaboracin entre la industria y el mundo acadmico, que en
ocasiones se muestra demasiado dogmtico.
o Se considera que la aplicacin de mtodos formales encarece los productos y
ralentiza su desarrollo.

Desarrollo basado en la reutilizacin
Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento
entre componentes, el desarrollador es libre de actualizar y/o agregar
componentes segn sea necesario, sin afectar otras partes del sistema.
Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organizacin, la calidad de una aplicacin basada
en componentes mejorar con el paso del tiempo.