INSTITUTO TECNOLOGICO DE

CHIHUAHUA II

Tarea 3. Resumen metodologas del

Software
Anlisis y modelado de sistemas de
informacin
Prof. : M.S.I. Miriam Abigail Garca
Por: Mitchel Alberto Acosta
Martnez
Moiss R. Martnez Mndez
Mnica Liliana Barrio Pacheco
Cynthia Abigail Delgado
Salvatierra
Jess Manuel Vega Salas
5 Ing. Informtica

NDICE
Chihuahua, Chih. Septiembre 2016

Introduccin2
Modelos para el desarrollo de software..6
Metodologa Kendall & Kendall.9
Conclusiones.16
Recomendaciones.16
Bibliografa...16

INTRODUCCIN

La metodologa es un conjunto de procedimientos, tcnicas, herramientas y un soporte documental

que ayuda a los desarrolladores a realizar un nuevo software. Puede seguir uno o varios modelos de
ciclo de vida, es decir, el ciclo de vida indica qu es lo que hay que obtener a lo largo del desarrollo
del proyecto pero no cmo hacerlo.
La metodologa indica cmo hay que obtener los distintos productos parciales y finales. Finalmente
depender de la metodologa utilizada los productos del proyecto, por esta razn es necesario,
conocer a fondo cada una de ellas y poder diferenciar entre una y otra, para de este modo saber
elegir la correcta en el momento de desarrollar un nuevo software, de otra manera el producto no
ser el mejor e incluso puede ser intil. Un sistema informtico est compuesto por hardware y
software. En cuanto al hardware, su produccin se realiza sistemticamente y la base de
conocimiento para el desarrollo de dicha actividad est claramente definida. La fiabilidad del
hardware es, en principio, equiparable a la de cualquier otra mquina construida por el hombre. Sin
embargo, respecto del software, su construccin y resultados han sido histricamente cuestionados
debido a los problemas asociados, entre ellos podemos destacar los siguientes:
Los sistemas no responden a las expectativas de los usuarios.
Los programas fallan con cierta frecuencia.
Los costes del software son difciles de prever y normalmente superan las estimaciones.
La modificacin del software es una tarea difcil y costosa.
El software se suele presentar fuera del plazo establecido y con menos prestaciones de las
consideradas inicialmente.
Normalmente, es difcil cambiar de entorno hardware usando el mismo software.
El aprovechamiento ptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no
suele cumplirse.

Segn el libreo PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE (RUP)

Qu es un sistema software?
2

Un sistema software es el cdigo mquina. Los ejecutables lo es, por supuesto, pero qu es el
cdigo mquina? Es una descripcin! Una descripcin en forma binaria que puede "ser leda"" y
'"ser comprendida"' por un computador. Un sistema software es el cdigo fuente? Es decir es una
descripcin escrita por programadores que puede leer y comprender un compilador'' S. Puede que
sta sea la respuesta. Podernos seguir de esta forma hacindonos preguntas similares sobre el diseo
de un sistema software en trminos de subsistemas. Clases, diagramas de interaccin (Apndice A),
diagramas de estados (Apndice AJ. y otros artefactos. Son ellos el sistema S, son parte de l.
Qu hay de los requisitos, pruebas, venta, produccin, instalacin y operacin'' Son el sistema? S
tambin son parte del sistema. un sistema es todos los artefactos que se necesitan para representarlo
en una forma comprensible por mquinas u hombres, para las mquinas, los trabajadores y los
interesados. Las mquinas son las herramientas, compiladores, u ordenadores destinatarios. Entre
los trabajadores tenernos directores, arquitectos, desarrolladores, ingenieros de prueba, personal de
marketing, administradores. Los interesados son los inversores, usuarios, comerciales, jefes de
proyecto, directores de lnea de producto, personal de produccin, agencias de regulacin, etc.
Artefactos
Es un trmino general para cualquier tipo de informacin creada. Producida, cambiada o utilizada
por los trabajadores en el desarrollo del sistema. Sin embargo el desarrollo de software tambin
requiere artefactos de gestin. Varios de estos artefactos tienen un tiempo de vida corto - slo
duran lo que dure la vida del proyecto. A este conjunto pertenecen artefactos como el anlisis del
negocio, el plan de desarrollo (incluyendo el plan de versiones e iteraciones), un plan para la
asignacin de personas conectadas a trabajadores (es decir a diferentes puestos o responsabilidades
en el proyecto), y el diseo de las actividades de los trabajadores en el plan.
Un sistema posee una coleccin de modelos
El tipo de artefacto ms interesante utilizado en el Proceso Unificado es el modelo. Cada trabajador
necesita una perspectiva diferente del sistema. Cuando diseamos el Proceso Unificado,
identificamos lodos los trabajadores y cada una de las perspectivas que posiblemente podran
necesitar. La construccin de un sistema es por tanto un proceso de construccin de modelos,
utilizando distintos modelos para describir todas las perspectivas diferentes del sistema.

El Proceso Unificado proporciona un conjunto de modelos cuidadosamente seleccionado con el cual

comenzar. Este conjunto de modelos hace claro el sistema para todos los trabajadores, incluyendo a
los clientes, usuarios y jefes de proyecto.
Qu es un modelo?
Los modelos son abstracciones del sistema que construyen los arquitectos y desarrolladores. Por
ejemplo, los trabajadores que modelan los requisitos funcionales piensan en el sistema con los
usuarios fuera de l y con los casos de uso en su interior. Los trabajadores que construyen el diseo
piensan en los elementos estructurales como subsistemas y clases; piensan en trminos de como
esos elementos funcionan en un contexto dado y cmo colaboran para proporcionar los casos de
uso. Comprenden cmo funcionan esos elementos abstractos, y poseen en sus mentes una
interpretacin particular.
Cada modelo es una vista auto contenida del sistema
La mayora de los modelos de ingeniera se definen mediante un subconjunto de UML
cuidadosamente seleccionado. Por ejemplo, el modelo de casos de uso comprende a los casos de
uso y los actores. Esto es bsicamente lo que un lector necesita para comprenderlo. Tanto el modelo
de casos de uso como el modelo de diseo describen dos interpretaciones, diferentes pero
mutuamente consistentes, de lo que el sistema har dado un conjunto de estmulos externos
provenientes de los actores. Son diferentes debido a que estn pensados para ser utilizados por
diferentes trabajadores con diferentes tareas y objetivos. El modelo de casos de uso es una vista
externa del sistema, el modelo de diseo es una vista interna. El modelo de casos de uso captura los
usos del sistema, mientras que el modelo de diseo representa la construccin del sistema.
Dentro de un modelo
Un modelo siempre identifica el sistema que est modelando. Este elemento del sistema es por
tanto el contenedor de los dems elementos. El subsistema de ms alto nivel representa al sistema
en construccin. En el modelo de casos de uso, el sistema contiene casos de uso; en el modelo de
diseo, contiene subsistemas, interfaces y clases
Relaciones entre modelos
Un sistema contiene todas las relaciones (Apndice AJ y restricciones entre elementos incluidos en
diferentes modelos. Por tanto un sistema no es slo la coleccin de sus modelos sino que contiene
tambin las relaciones entre ellos.
El hecho de que los elementos en dos modelos estn conectados no cambia lo que hacen en los
modelos a los que pertenecen, Las relaciones de traza entre elementos en modelos distintos no
aaden informacin semntica para ayudar a comprender los propios modelos relacionados;
simplemente los conectan. La posibilidad de crear trazas es muy importante en el desarrollo de
software por razones como la comprensibilidad y la propagacin de los cambios.

MODELOS PARA EL DESARROLLO DE SOFTWARE

un modelo para el desarrollo de software es una representacin abstracta de un proceso. Cada
modelo representa un proceso desde una perspectiva particular y as proporcione informacin
parcial sobre el proceso. stos modelos generales no son descripciones definitivas de los procesos
del software ms bien son abstracciones de los procesos que se pueden utilizar para el desarrollo del
software. Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser adaptados
para crear procesos ms especficos. Los modelos que mencionaremos en este punto son:
1) El modelo en cascada. Considera las actividades fundamentales del proceso especificacin,
desarrollo, validacin y evolucin. Los representa como fases separadas del proceso, tales como la
especificacin de requerimientos, el diseo del software, la implementacin, las pruebas, etctera.
5

2) El modelo de desarrollo evolutivo (espiral). Este enfoque entrelaza las actividades especificacin,
desarrollo y validacin. Es decir surge de un sistema inicial que se desarrolla rpidamente a partir
de especificaciones abstractas. Basndose en las peticiones del cliente para producir un sistema que
satisfaga
sus
necesidades.
3) El modelo de desarrollo basado en componentes. ste enfoque se basa en la existencia de un
nmero significativo de componentes reutilizables. El proceso de desarrollo se enfoca en integrar
estos componentes en el sistema ms que en desarrollarlos desde cero. Estos tres modelos se
utilizan ampliamente en la prctica actual de la ingeniera del software, no se excluyen mutuamente
y a menudo se utilizan juntos especialmente para el desarrollo de grandes sistemas.
El modelo en cascada
Segn Royce (1970), el modelo de cascada se deriv de procesos de sistemas ms generales. ste
modelo se muestra en la figura 2.22 y sus principales etapas se transforman en actividades
fundamentales del desarrollo:
1) Anlisis y definicin de requerimientos. Los servicios restricciones y metas del sistema se
definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven de manera
especfica al sistema.
2) Diseo del sistema y del software. El proceso de diseo del sistema divide los requerimientos en
sistemas ya sea hardware Soto. Establece una arquitectura completa del sistema, el diseo del
software identifique describe los elementos abstractos que son fundamentales para el software y sus
relaciones.
3) Implementaciones prueba de unidades. Durante esta etapa el diseo del software se lleva a cabo
como un conjunto de unidades de programas, la prueba de unidades implica verificar que cada una
cumpla con su funcin especfica.
4) Integracin y prueba del sistema. Los programas o las unidades individuales de programas se
integran y se prueban como un sistema completo para as asegurar que se cumplan los
requerimientos
del
software,
despus
se
entrega
al
cliente.
5) Funcionamiento y mantenimiento. En esta fase el sistema se instala y se pone en funcionamiento
prctico el mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo
de vida, mejorar la implementacin de las unidades del sistema y resaltar los servicios del sistema
una vez que se descubren en nuevos requerimientos.
B. El modelo de desarrollo evolutivo (espiral) El modelo en espiral que Boehm propuso es un
modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construccin de
prototipos con los aspectos controlados y sistemticos del modelo en cascada. Cuando se aplica este
modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Cada una de las
actividades del marco de trabajo representan un segmento de la ruta en espiral.
6

Este modelo se basa en la idea de desarrollar una implementacin inicial, exponindola a los
comentarios del usuario y refinndola a travs de las diferentes versiones que se generan hasta que
se desarrolle un sistema adecuado.
Las actividades de especificacin, desarrollo y validacin se entrelazan en vez de separarse, con una
rpida retroalimentacin entre estas. Existen dos tipos de desarrollo evolutivo:
1) Desarrollo exploratorio, en este caso 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, el objetivo de este proceso de desarrollo evolutivo es comprender los
requerimientos del cliente para as desarrollar una definicin mejorada de los requerimientos para el
sistema. El prototipo se centra en experimentar los requerimientos del cliente que no se comprenden
del todo.
Haciendo referencia a la produccin del software, un enfoque evolutivo suele ser ms efectivo que
el enfoque en cascada, ya que satisface las necesidades inmediatas de los clientes. La ventaja de un
software que se basa en un enfoque evolutivo es que las especificaciones se pueden desarrollar de
forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema,
esto se puede reflejar en el software. Sin embargo, desde la perspectiva de ingeniera y de gestin,
el enfoque evolutivo tiene dos problemas:
1) El proceso no es visible. Esto significa que los administradores tienen que hacer entregas
regulares para medir el progreso del producto. Si los sistemas se desarrollan rpidamente, no es
rentable
producir
documentos
que
reflejen
cada
versin
del
sistema.
2) A menudo los sistemas tienen una estructura deficiente. Esto hace referencia que los cambios
continuos tienden a corromper la estructura del software. Incorporar cambios en l se convierte cada
vez ms en una tarea difcil y costosa.
Para sistemas pequeos y de tamao medio (hasta 500,000 lneas de cdigo), el enfoque evolutivo
de desarrollo es el mejor. Los problemas del desarrollo evolutivo se hacen particularmente agudos
para sistemas grandes y complejos con un perodo de vida largo, donde diferentes equipos
desarrollan distintas partes del sistema. Es difcil establecer una arquitectura del sistema usando este
enfoque, ya que hace difcil integrar las contribuciones de los equipos. Para sistemas grandes se
recomienda un proceso mixto es decir que incorpore las mejores caractersticas del modelo en
cascada y del desarrollo evolutivo. Esto implica desarrollar un prototipo desechable, utilizando un
enfoque evolutivo para resolver incertidumbres en la especificacin del sistema. Puede entonces no
implementarse utilizando un enfoque ms estructurado.

C.
El
modelo
de
desarrollo
basado
en
componentes
En la mayora de los proyectos de desarrollo de software existe la reutilizacin. Por lo general esto
sucede informalmente cuando las personas conocen diseos o cdigos similares al requerido. Los
buscan, los modifican segn lo creen necesario y los incorporan en un nuevo sistema. El enfoque
evolutivo, la reutilizacin es indispensable para el desarrollo ms gil de un sistema. Esta
reutilizacin es independiente del proceso de desarrollo que se utilice. Sin embargo, en los ltimos
aos ha surgido un enfoque de desarrollo de software denominado " ingeniera de software basada
en componentes", el cual se basa en la reutilizacin. Este enfoque se basa en la reutilizacin y se
compone de una gran base de componentes de software que son reutilizables.
Aunque la etapa de especificacin de requerimientos y la revalidacin son comparables con otros
procesos, las etapas intermedias en el proceso orientado a la reutilizacin son diferentes. Estas
etapas son:
1) Anlisis de componentes. En esta se buscan los componentes para implementar los con base en
su especificacin. Por lo general, no existe una concordancia exacta y los componentes que se
utilizan slo proporcionan parte de la funcionalidad requerida.
2) Modificacin de requerimientos. En esta etapa los requerimientos se analizan utilizando
informacin acerca de los componentes que se han descubierto. Entonces dichos componentes se
modifican para reflejar los componentes disponibles, la actividad de anlisis de componentes se
puede llevar a cabo para buscar soluciones alternativas.
3) Diseo del sistema con reutilizacin. En esta fase los diseadores tienen en cuenta los
componentes que se reutiliza y que se organizan el marco de trabajo para que los satisfaga. Si
dichos componentes no estn disponibles se puede disear nuevos software.
4) Desarrollo e integracin. El software que no se puede adquirir externamente se desarrolla y se
integra a los componentes. En este modelo, la integracin del sistema es parte del proceso de
desarrollo, ms que una actividad separada.
El modelo de desarrollo de software basado en componentes creado por Boehm (1988), tiene la
ventaja de reducir la cantidad de software que se debe desarrollar y por ende reduce los costos y los
riesgos. Tambin permite una entrega ms rpida del software. Sin embargo, los compromisos a los
requerimientos son inevitables y esto da lugar a un sistema que no cumpla con las necesidades
reales de los usuarios. Pressman (2006), detecto que:
El software de computadoras moderno se caracteriza por el cambio continuo, los tiempos de
entrega son muy reducidos y una necesidad intensa de satisfacer al cliente/usuario. En muchos
casos, el tiempo de llegada al mercado es el requisito de gestin ms importante. Si se pierde una
ventana del mercado, el mismo proyecto de software puede perder su significado.

METODOLOGA KENDALL & KENDALL.

El ciclo de vida del desarrollo de sistemas es un enfoque por fases para el anlisis y el diseo cuya
premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de
actividades del analista y el usuario. (Kendall & Kendall) Segn la metodologa de Kendall &
Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificacin del
problema, la segunda identificacin de requisitos de informacin, la tercera es el anlisis de las
necesidades del sistema, la cuarta es el diseo del sistema recomendado, la quinta desarrollo y
documentacin del sistema, la sexta prueba y mantenimiento y la ltima implementacin y
evaluacin. Cada fase se explica por separado pero nunca se realizan como pasos aislados, ms bien
es posible que algunas actividades se realicen de manera simultnea, y algunas de ellas podran
repetirse.
FASE I: Identificacin de problemas, oportunidades y objetivos.
Observacin directa del entorno.
Aplicacin de entrevista para recolectar informacin.
Sintetizar la informacin recolectada para construir objetivos.
Estimar el alcance del proyecto.
Identificar si existe una necesidad, problema u oportunidad argumentada.
Documentar resultados.
Estudiar los riesgos del proyecto.
Presentar un informe de vialidad.
En la primera fase el analista es el encargado de identificar los problemas de la organizacin,
detallarlos, examinar, evaluar las oportunidades y objetivos.
El analista debe identificar y evaluar los problemas existentes en la organizacin de manera crtica y
precisa. Mayormente los problemas son detectados por alguien ms y es cuando el analista es
solicitado a fin de precisarlos. Las oportunidades son situaciones que el analista considera
susceptibles de mejorar utilizando sistemas de informacin computarizados, lo cual le da mayor
seguridad y eficacia a las organizaciones adems de obtener una ventaja competitiva. El analista
debe identificar los objetivos, es decir, el analista debe averiguar lo que la empresa trata de
conseguir, se podr determinar si algunas funciones de as aplicaciones de los sistemas de
informacin pueden contribuir a que el negocio alcance sus objetivos aplicndolas a problemas u
oportunidades especficos. Los usuarios, los analistas y los administradores de sistemas que
coordinan el proyecto son los involucrados en la primera fase. Las actividades de esta fase son las
entrevistas a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar
el alcance del proyecto y documentar los resultados. El resultado de esta fase en un informe de
viabilidad que incluye la definicin del problema y un resumen de los objetivos. La administracin
debe decidir si se sigue adelante o si se cancela el proyecto propuesto.

FASE II: Determinacin de los requerimientos de informacin.

Revisin de los objetivos.
Identificar el dominio.
Investigar la razn por la cual se implementa el sistema actual.
Recolectar informacin sobre los procedimientos y operaciones que se desempean actualmente.
Detallar especficamente: Quines son los involucrados, cul es la actividad, regla y restricciones
del negocio, entorno de desarrollo de las actividades, momentos oportunos de desarrollo de cada
funcin, la manera en que se desempean los procedimientos actuales.
Elaborar una lista detallada y organizada de todos los procedimientos.
10

Separar requerimientos funcionales y no funcionales. Adicionar al informe de la primera fase, esta

nueva informacin.

En esta fase el analista se esfuerza por comprender la informacin que necesitan los usuarios para
llevar a cabo sus actividades. Entre las herramientas que se utilizan para determinar los
requerimientos de informacin de un negocio se encuentran mtodos interactivos como las
entrevistas, los muestreos, la investigacin de datos impresos y la aplicacin de cuestionarios;
mtodos que no interfieren con el usuario como la observacin del comportamiento de los
encargados de tomar las decisiones y sus entornos e oficina, al igual que mtodos de amplio alcance
como la elaboracin de prototipos.
Esta fase es til para que el analista confirme la idea que tiene de la organizacin y sus objetivos.
Los implicados en esta fase son el analista y los usuarios, por lo general los trabajadores y gerentes
del rea de operaciones.
El analista necesita conocer los detalles de las funciones del sistema actual:
El quin (la gente involucrada), el qu (la actividad del negocio), el dnde (el entorno donde se
desarrollan las actividades), el cundo (el momento oportuno) y el cmo (la manera en que se
realizan los procedimientos actuales) del negocio que se estudia.
Al trmino de esta fase, el analista debe conocer el funcionamiento del negocio y poseer
informacin muy completa acerca de la gente, los objetivos, los datos y los procedimientos
implicados.
FASE III: Anlisis de las necesidades.
Evaluar las dos fases anteriores.
Modelar las entradas, los procesos y las salidas de las funciones ya identificadas.
Elaborar diccionario de datos y sus especificaciones.
Elaborar diagramas de procesos de cada funcin.
Elaborar propuesta del sistema con todos los diagramas de operaciones y de procesos.
Realizar el anlisis del riesgo sobre el realizado en las fases anteriores, tomando en cuenta el
aspecto econmico, tcnico y operacional (estudio de factibilidad)
Estimar en un diagrama de Gantt el tiempo que tomar desarrollar el sistema.
11

En esta fase el analista evala las dos fases anteriores, usa herramientas y tcnicas como el uso de
diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del
negocio en una forma grfica estructurada.
A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los
datos utilizados en el sistema as como sus respectivas especificaciones.
El analista prepara en esta fase, una propuesta de sistemas que sintetiza sus hallazgos, proporciona
un anlisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que
se debe hacer.
FASE IV: Diseo del sistema recomendado.
Evaluar las tres fases anteriores.
Realizar el diseo lgico de todo el sistema.
Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de
informacin.
Elaborar el diseo de la base de datos.
Disear las diferentes interfaces de usuarios de cada operacin, procedimiento y/o funcin.
Disear controles y procedimientos de respaldos que protejan al sistema y a los datos.
Producir los paquetes especficos de programas para los programadores.
Elaborar una lista de las funciones genricas y de las que ser obligatorio crear.
En esta fase el analista utiliza la informacin recopilada en las primeras fases para realizar el diseo
lgico del sistema de informacin.
El analista disea procedimientos precisos para la captura de datos que aseguran que los datos que
ingresen al sistema de informacin sean correctos.
Facilita la entrada eficiente de datos al sistema de informacin mediantes tcnicas adecuadas de
diseo de formularios y pantallas.
La concepcin de la interfaz de usuario forma parte del diseo lgico del sistema de informacin.
La interfaz conecta al usuario con el sistema y por tanto es sumamente importante.
Tambin incluye el diseo de archivos o bases de datos que almacenarn gran parte delos datos
indispensables para los encargados de tomar las decisiones en la organizacin.
En esta fase el analista interacta con los usuarios para disear la salida (en pantalla o impresa) que
satisfaga las necesidades de informacin de estos ltimos.
Finalmente el analista debe disear controles y procedimientos de respaldo que protejan al sistema y
a los datos y producir paquetes de especificaciones de programa para los programadores.
Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y
detalles del procesamiento.

12

FASE V: Desarrollo y documentacin del software.

Evaluar los procedimientos que va a ser desarrollados por el programador.
Mostrar y explicar cada procedimiento, funcin y operacin al programador.
Elaborar manuales de procedimientos internos del sistema.
Elaborar manuales externos de ayuda a los usuarios del sistema.
Elaborar demostraciones para los usuarios y la interaccin con distintas interfaces.
Elaborar actualizaciones para los diferentes procedimientos. Elaborar un informe con el tiempo que
se llev construir cada procedimiento.

En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera conjunta con los
programadores para desarrollar cualquier software original necesario. Entre las tcnicas
estructuradas para disear y documentar software se encuentran los diagramas de estructuras, los
diagramas de Nassi-Shneiderman y el pseudocdigo.
Durante esta fase el analista trabaja con los usuarios para desarrollar documentacin efectiva para el
software, como manuales de procedimientos, ayuda en lnea y sitios web que incluyan respuestas a
preguntas frecuentes en archivos lame que se integrarn al nuevo software.
La documentacin indica a los usuarios cmo utilizar el sistema y qu hacer en caso de que surjan
problemas derivados de este uso. Los programadores desempean un rol clave en esta fase porque
disean, codifican y eliminan errores sintcticos de los programas de cmputo.

FASE VI: Prueba y mantenimiento del sistema.

Realizar la programacin de las pruebas del sistema.
Realizar un instrumento para evaluar el sistema de informacin.
El programador deber elaborar un resumen de las pruebas del sistema.
El analista deber realizar un informe de sus pruebas y discutirlo con el programador.
13

Elaborar la planificacin de las horas del mantenimiento del sistema. Elaborar la lista de las
operaciones que pudieran sufrir modificaciones de cdigos.
Antes de poner en funcionamiento el sistema es necesario probarlo es mucho menos costoso
encontrar los problemas antes que el sistema se entregue a los usuarios.
Una parte de la pruebas la realizan los programadores solos, y otra la llevan a cabo de manera
conjunta con los analistas de sistemas. Primero se realizan las pruebas con datos de muestra para
determinar con precisin cules son los problemas y posteriormente se realiza otra con datos reales
del sistema actual.
El mantenimiento del sistema de informacin y su documentacin empiezan en esta fase y se llevan
de manera rutinaria durante toda su vida til.

FASE VII: Implementacin y evaluacin del sistema.

Planificar gradualmente la conversin del sistema anterior.
Instalar los equipos de hardware necesarios para el funcionamiento del software creado.
Capacitar por medio de talleres a los usuarios en el manejo de equipos y software creados.
Evaluar la adaptabilidad de los usuarios al sistema.

Esta es la ltima fase del desarrollo de sistemas, y aqu el analista participa en la implementacin
del sistema de informacin. En esta fase se capacita a los usuarios en el manejo del sistema. Parte
de la capacitacin la imparten los fabricantes, pero la supervisin de sta es responsabilidad del
analista de sistemas.
14

Se menciona la evaluacin como la fase final del ciclo de vida del desarrollo de sistemas
principalmente en reas del debate. En realidad, la evaluacin se lleva a cabo durante cada una de
las fases.
El trabajo de sistemas es cclico, cuando un analista termina una fase del desarrollo de sistemas y
pasa a la siguiente, el surgimiento de un problema podra obligar a regresar a la fase previa y
modificar el trabajo realizado.

15

CONCLUSIONES
El desarrollo del software y la programacin es uno de los pilares fundamentales de la informtica y
al cual se dedican muchas horas de esfuerzos en empresas, colegios, academias y universidades.
Conforme a la tecnologa va avanzando, van apareciendo nuevas soluciones, nuevas formas de
programacin, nuevos lenguajes y un sin fin de herramientas que intentan realizar el trabajo del
desarrollador un poco ms fcil.
La programacin orientadas a objetos o los compiladores basados en mquinas virtuales (en muchos
casos, multiplataforma), tambin a sus puestos unas renovacin en la manera de programar.
Microsoft como empresa desarrolladora de software, es consciente de lo importante que es hacer
buenos desarrollos y lo complicado que es; por eso, intenta aportar las mejores soluciones
al mercado. En la actualidad la sociedad se encuentra en una poca de transicin, que se encamina
hacia un nuevo estilo de programacin basada en estndares y para ello Microsoft propone la
plataforma .NET.

RECOMENDACIONES
Excepto en casos singulares, el software nunca es propiedad del usuario. La adquisicin del
programa es en realidad la adquisicin solamente del derecho de uso del programa, la licencia, bajo
termino definidos por el fabricante. El uso de software fuera de esos trminos constituye
un delito contra la propiedad intelectual.
Debe instalarse solamente el software necesario para las funciones esperadas del equipo. En la
mayora de los casos, eso se limita al software bsicos sistemas operativos
(usualmente Windows 95), aplicativos de oficina y navegacin (usualmente Office 97, Internet
Explorer 4.01) y el cliente de red (BackOffice 4). Todo computador adquirido para
la universidad debe contar con licencias para software mencionado (o su equivalente en plataformas
Macintosh o Unix), en esas versiones o ms recientes. Las licencias deben corresponder a las
versiones, ya que no se pueden instalar una versin ms reciente con una licencia de versiones
anteriores.

BIBLIOGRAFA
http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm
16

Grady Booch, lvar Jacobson y James Rumbaugh. El proceso unificado de desarrollo de software.
Series Editors. S. A. Madrid, 2000 Pginas 19-21
KENDALL, E. (2011). Anlisis y Diseo de Sistemas. (8 Ed.). Mxico: Pearson Educacin.
Pginas

http://mundoinformatico321.blogspot.mx/2012/11/metodologia-kendall-kendall.html?m=1

17