1.- INGENIERIA DE SOFTWARE La inge ingeni nier ería ía de soft softwa ware re es una una disc discip iplilina na form formad ada a por por un conj conjun unto to de méto método dos, s, herramienta herramientass y técnicas que se utilizan en el desarrollo desarrollo de los programas informáticos informáticos (software software), ), es la aplicación de un enfoque sistemático, disciplinado y cuantificale al desarrollo, operación y mantenimiento de software, La ingeniería de software, incluye el análisis pre!io de la situación, el dise"o del proyecto, el desa desarr rrol ollo lo del del soft softw ware, are, las las prue pruea ass nece necesa sari rias as para para conf confir irma marr su corr correc ecto to funcionamie funcionamiento nto y la implementación implementación del sistema sistema## $na !ez que se completa el ciclo del software, software, entra en juego el mantenimiento mantenimiento del software# software# %e trata de una fase de esta ingeniería donde ingeniería donde se solucionan los errores descuiertos (muchas !eces ad!ertidos por los propi propios os usua usuari rios os)) y se inco incorp rpora oran n actu actual aliz izac acio ione ness para para hace hacerr fren frente te a los los nue! nue!os os requisitos#
2.- MODELOS DE DESARROLLO DE SOFTWARE. &ara el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final, un modelo de desarrollo estalece el orden en el que se harán las cosas en el proyecto, pro!ee de requisitos de entrada y de salida para cada una de las acti!idades, por ello es necesario el modelo de desarrollo#
MODELO CASCADA
Llamado tamién Lineal secuencial# &roporciona una simple !isión del desarrollo del %oftware# ' los procesos los representa como fases separadas y secuenciales en tiempo# ada etapa produce documentos que son la entrada a la siguiente, para desarrollar una etapa dee concluirse la anterior#
Faces Del modelo cascada
Inge Ingeni nie e!a !a " An#l An#lis isis is del del Sis$ Sis$em emaa % 'nálisis y de dise"o de todos los componentes del sistema computacional An#lisis de los Re&'isi$os% Se dee conocer que necesita el usuario para saer que necesidades deemos curir# Dise(o% n esta fase se realizan los algoritmos necesarios para que se cumplan los requerimientos del usuario así como tamién los análisis necesarios para saer que herramientas usar en la etapa de odificación# %e di!iden en* +ise"o de 'lto i!el o 'rquitectónico +ise"o +etallado • •
•
Codi)icaci*n% s la fase de programación propiamente dicha# +'e,a% Las componentes una !ez programadas, se ensamlan para formar el sistema y se demuestra que traaja correctamente antes de ser puesto en práctica por el usuario# -isten !arios tipos de &rueas* . &rueas de unidad . &rueas de integración . &rueas de sistema# . &rueas de aceptación Man$enimien$o% l software necesitará camios después de la entrega# Los tipos de mantenimiento son* . /antenimiento &re!enti!o y &erfecti!o . /antenimiento orrecti!o . /antenimiento !oluti!o
en$aas% • • •
• •
&lanificación sencilla# $na plantilla estructurada para ingeniería de software# +isminuye el efecto ola de nie!e al reducir el mantenimiento considerando que se tienen unas especificaciones completas y correctas# La cantidad de recursos necesarios para implementar este modelo es mínimo# La documentación se produce en cada etapa del desarrollo del modelo de cascada#
/ Des0en$aas% •
• • •
proceso de creación del software tarda mucho tiempo ya que dee pasar por el proceso de pruea y hasta que el software no esté completo no se opera# !olución de los 0equisitos# 0esultados al final# proceso de creación del software tarda mucho tiempo ya que dee pasar por el proceso de pruea y hasta que el software no esté completo no se opera#
MODELO DE ES+IRAL.
l /odelo en spiral es un modelo de proceso de software e!oluti!o donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal y secuencial La meta del modelo espiral del proceso de producción del software es proporcionar un marco para dise"ar tales procesos, dirigido por los ni!eles de riesgo en el proyecto actual#
Cada 0'el$a en la esial se di0ide en sec$oes%
•
•
•
•
•
Com'nicaci*n con el Clien$e * Las tareas requeridas para estalecer comunicación entre el desarrollador y el cliente# +lani)icaci*n o +laneaci*n% Las tareas requeridas para definir recursos, el tiempo, determinación de los ojeti!os, alternati!as y restricciones, y otra información relacionada con el proyecto# An#lisis de Riesgos% Las tareas requeridas para e!aluar riesgos técnicos y de gestión, análisis de alternati!as e identificación1resolución de riesgos# Ingenie!a% Las tareas requeridas para construir una o más representaciones de la aplicación, desarrollo del producto hasta 2el siguiente ni!el2# Cons$'cci*n " Acci*n* Las tareas requeridas para construir, proar, instalar y proporcionar soporte al usuario (por ejemplo, documentación y práctica)#
Di)eencias en$e modelo en esial " modelos $adicionales
0econocimiento e-plícito de las diferentes alternati!as# 3dentificación de riesgos para cada alternati!a desde el comienzo# 'l di!idir el proyecto en ciclos, al final de cada uno e-iste un acuerdo para los camios que hay que realizar en el sistema# l modelo se adapta a cualquier tipo de acti!idad adicional
en$aas. 4 ' diferencia del modelo de proceso clásico que termina cuando se entrega el software el modelo en espiral puede adaptarse y aplicarse a lo largo de la !ida del software de computadora# 4 omo el software e!oluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los ni!ele e!oluti!os# 4 l modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de e!olución del producto# 4 l modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente dee reducir los riesgos antes de que se con!iertan en prolemas# 4 n la utilización de grandes sistemas ha dolado la producti!idad# 4 s un enfoque realista para el desarrollo de software y de sistemas a gran escala#
Des0en$aas.
4 5enera mucho tiempo en el desarrollo del sistema 4 /odelo costoso 4 0equiere e-periencia en la identificación de riesgos 4 0esulta difícil con!encer a grandes clientes de que el enfoque e!oluti!o es controlale 4 +eido a su ele!ada complejidad no se aconseja utilizarlo en peque"os sistemas
MODELO DE DESARROLLO R+IDO DE A+LICACI3N 4 RAD
+esarrollo rápido de aplicaciones o 0'+ (acrónimo en inglés de rapid application development ) es un proceso de desarrollo de software, desarrollado inicialmente por 6ames /aslow en 789:# l método comprende el desarrollo interacti!o, la construcción de prototipos y el uso de utilidades '% (omputer 'ided %oftware ngineering)# ;radicionalmente, el desarrollo rápido de aplicaciones tiende a engloar tamién la usailidad, utilidad y la rapidez de ejecución#
Caac$e!s$icas
/odelo secuencial lineal con tiempos cortos de desarrollo
n cada etapa de lieración, los productos parciales son integrados, proados lierados
El en)o&'e RAD $iene las sig'ien$es )ases% 7# Modelado de Ges$i*n * se modela el flujo de información entre las funciones de gestión# =# Modelado de Da$os% se refina el flujo de información como un conjunto de ojetos de datos necesarios para apoyar la empresa# %e definen las características de cada uno de los ojetos y sus relaciones# ># Modelado del +oceso* se definen las transformaciones (a"adir, modificar, suprimir o recuperar) sore los ojetos del modelo de datos para lograr los flujos de información de cada función de gestión# ?# Geneaci*n de Alicaciones* codificación de una función de gestión# @# +'e,as " en$ega* pruea de los componentes y entrega del programa que realiza una función de gestión#
La cla0e del modelo RAD es$# en los cam,ios en las e$aas de codi)icaci*n " 'e,as% / Codi)icaci*n# l modelo 0'+ asume la utilización de técnicas de cuarta generación# n lugar de crear software con lenguajes de programación de tercera generación, se traaja para !ol!er a utilizar componentes de programas ya e-istentes (cuando es posile) o a crear componentes reutilizales (cuando sea necesario)# n todos los casos se utilizan herramientas para facilitar la construcción de software# / +'e,as# omo se enfatiza la reutilización, ya se han comproado muchos de los componentes de los programas# sto reduce en muchos casos el tiempo de prueas, aunque se deen proar todos los componentes nue!os y se deen ejercitar todas las interfaces a fondo en$aas% A nfatiza ciclos de desarrollo e-tremadamente cortos A ;iene las !entajas del modelo clásico A %e asegura de que el producto entregado cumple las necesidades del cliente
Des0en$aas%
A %olo se puede aplicar si el sistema se puede modularizar de forma que permita completarse cada una de las funciones principales en menos de tres meses A &ara proyectos grandes puede requerir muchos equipos de traajo distintos A 0equiere clientes y desarrolladores comprometidos en las rápidas acti!idades necesarias A o resulta adecuado cuando los riesgos técnicos son ele!ados A %e pueden tener prolemas con la aceptación del prototipo %e requiere mBltiples desarrolladores
MODELO DE DESARROLLO 5+
La programación e-trema es una disciplina de desarrollo de software Crelati!amenteD nue!a#
Caac$e!s$icas • •
/etodología para un ágil desarrollo de software# &rogramación asada en los deseos del cliente#
•
l equipo lo conforman los jefes de proyecto, desarrolladores y el cliente#
•
%e rige por !alores y principios
aloes de 5+ • •
Com'nicaci*n* rear software requiere de sistemas comunicados# Simlicidad* mpezar con lo necesario y requerido y traajar desde ahí#
•
Re$oalimen$aci*n* +el sistema, del cliente, y del equipo#
•
alen$ia% &rograma para hoy y no para ma"ana#
•
Rese$o* l equipo dee traajar como uno, sin hacer decisiones repentinas#
en$aas
&rogramación organizada# /enor taza de errores#
%atisfacción del programador
%olución de errores de programas
3mplementa una forma de traajo donde se adapte fácilmente a las circunstancias#
Des0en$aas
o e-iste documentación del proyecto 3mposile pre!er todo antes de programar
+emasiado costoso e innecesario
5asta demasiado tiempo
recursos en camiar la documentación de la planificación para que se parezca al código
MODELO EOL6TIO
Los e!oluti!os son modelos iterati!os, permiten desarrollar !ersiones cada !ez más completas y complejas, hasta llegar al ojeti!o final deseadoE incluso e!olucionar más allá, durante la fase de operación# Los modelos C3terati!o 3ncrementalD y CspiralD (entre otros) son dos de los más conocidos y utilizados del tipo e!oluti!o# La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, e-ponerla a los comentarios del usuario, refinarla en !ersiones hasta que se desarrolle el sistema adecuado
E7is$en dos $ios de desaollo e0ol'$i0o% •
•
Desaollo E7loa$oio* l ojeti!o de este enfoque es e-plorar con el usuario los requisitos hasta llegar a un sistema final# l desarrollo comienza con las partes que se tiene más claras# l sistema e!oluciona conforme se a"aden nue!as características propuestas por el usuario# En)o&'e '$ili8ando o$o$ios% l ojeti!o es entender los requisitos del usuario y traajar para mejorar la calidad de los requisitos# ' diferencia del desarrollo e-ploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para e-perimentar con ellos# l prototipo ayuda a terminar de definir estos requisitos#
en$aas •
•
•
La especificación puede desarrollarse de forma creciente# Los usuarios y desarrolladores logran un mejor entendimiento del sistema# sto se refleja en una mejora de la calidad del software# s más efecti!o que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente#
Des0en$aas •
•
•
+oceso no isi,le* Los administradores necesitan entregas para medir el progreso# %i el sistema se necesita desarrollar rápido, no es efecti!o producir documentos que reflejen cada !ersión del sistema# Sis$emas o,emen$e es$'c$'ados% Los camios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento# Se e&'ieen $9cnicas " :eamien$as* &ara el rápido desarrollo se necesitan herramientas que pueden ser incompatiles con otras o que poca gente sae utilizar#
MODELO INCREMENTAL
l /odelo 3ncremental comina elementos del /odelo Lineal %ecuencial con la filosofía interacti!a de onstrucción de &rototipos, ada secuencia lineal produce un incremento del software# l primer incremento generalmente es un producto esencial denominado nBcleo# l modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesi!os incrementos funcionales# ada incremento tiene su propio ciclo de !ida y se asa en el anterior, sin camiar su funcionalidad ni sus interfaces# $na !ez entregado un incremento, no se realizan camios sore el mismo, sino Bnicamente corrección de errores# +ado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo#
En 'na 0isi*n gen9ica; el oceso se di0ide en < a$es% 'nálisis +ise"o • •
•
ódigo
•
&ruea
Caac$e!s$icas%
•
%e e!itan proyectos largos y se entrega 2algo de !alor2 a los usuarios con cierta frecuencia# l usuario se in!olucra más#
•
+ifícil de e!aluar el costo total#
•
•
+ifícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo#
•
0equiere gestores e-perimentados#
•
Los errores en los requisitos se detectan tarde#
•
l resultado puede ser positi!o#
en$aas% •
•
•
•
on un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial# ;amién pro!ee un impacto !entajoso frente al cliente, que es la entrega temprana de partes operati!as del software# l modelo proporciona todas las !entajas del modelo en ascada realimentado, reduciendo sus des!entajas sólo al ámito de cada incremento# 0esulta más sencillo acomodar camios al acotar el tama"o de los incrementos#
Des0en$aas%
•
l modelo incremental no es recomendale para casos de sistemas de tiempo real, de alto ni!el de seguridad, de procesamiento distriuido y1o de alto índice de riesgos# 0equiere de mucha planeación, tanto administrati!a como técnica#
•
0equiere de metas claras para conocer el estado del proyecto#
MODELO DE +ROTOTI+O
•
;amién conocido como desarrollo con prototipación o modelo de desarrollo e!oluti!o, se inicia con la definición de los ojeti!os gloales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición# ste modelo se utilizan para dar al usuario una !ista preliminar de parte del software# ste
modelo es ásicamente pruea y error ya que si al usuario no le gusta una parte del prototipo significa que la pruea fallo por lo cual se dee corregir el error que se tenga hasta que el usuario quede satisfecho 'demás el prototipo dee ser construido en poco tiempo, usando los programas adecuados y no se dee utilizar mucho dinero pues a partir de que este sea aproado nosotros podemos iniciar el !erdadero desarrollo del software# &ero eso si al construir el prototipo nos asegura que nuestro software sea de mejor calidad, además de que su interfaz sea de agrado para el usuario# $n prototipo podrá ser construido solo si con el software es posile e-perimentar#
E$aas
•
0ecolección y refinamiento de requisitos /odelado, dise"o rápido
•
onstrucción del &rototipo
•
+esarrollo, e!aluación del prototipo por el cliente
•
0efinamiento del prototipo
•
&roducto de 3ngeniería
•
Para que sea efectivo •
+ee ser un sistema con el que se pueda e-perimentar +ee ser comparati!amente arato(menor que el 7:F)
•
+ee desarrollarse rápidamente
•
Gnfasis en la interfaz de usuario
•
quipo de desarrollo reducido
•
Herramientas y lenguajes adecuadas
•
Tipos de Modelo de Prototipos •
•
Modelo de +o$o$ios #ido * /etodología de dise"o que desarrolla rápidamente nue!os dise"os, los e!alBa y prescinde del prototipo cuando el pró-imo dise"o es desarrollado mediante un nue!o prototipo# Modelo de +o$o$ios e'$ili8a,le% ;amién conocido como 2!olutionary &rototyping2E no se pierde el esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados para construir el producto real# /ayormente es utilizado en el desarrollo de software, si ien determinados productos de hardware pueden hacer uso del prototipo como la ase del dise"o de moldes en la faricación con plásticos o en el dise"o de carrocerías de automó!iles#
•
•
•
•
•
Modelo de +o$o$ios Mod'la% ;amién conocido como &rototipado 3ncremental (3ncremental prototyping)E se a"aden nue!os elementos sore el prototipo a medida que el ciclo de dise"o progresa# Modelo de +o$o$ios =oi8on$al% l prototipo cure un amplio nBmero de aspectos y funciones pero la mayoría no son operati!as# 0esulta muy Btil para e!aluar el alcance del producto, pero no su uso real# Modelo de +o$o$ios e$ical* l prototipo cure sólo un peque"o nBmero de funciones operati!as# 0esulta muy Btil para e!aluar el uso real sore una peque"a parte del producto# Modelo de +o$o$ios de >aa-)idelidad% l prototipo se implementa con papel y lápiz, emulando la función del producto real sin mostrar el aspecto real del mismo# 0esulta muy Btil para realizar tests aratos# Modelo de +o$o$ios de Al$a-)idelidad% l prototipo se implementa de la forma más cercana posile al dise"o real en términos de aspecto, impresiones, interacción y tiempo#
Tipos de prototipos . •
•
El desec:a,le% nos sir!e para eliminar dudas sore lo que realmente quiere el cliente además para desarrollar la interfaz que más le con!enga al cliente# El e0ol'cionaio* es un modelo parcialmente construido que puede pasar de ser prototipo a ser software pero no tiene una uena documentación y calidad#
Ventajas • •
o modifica el flujo del ciclo de !ida 0educe el riesgo de construir productos que no satisfagan las necesidades de los usuarios
•
0educe costo y aumenta la proailidad de é-ito
•
-ige disponer de las herramientas adecuadas
•
•
ste modelo es Btil cuando el cliente conoce los ojeti!os generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida# ;amién ofrece un mejor enfoque cuando el responsale del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptailidad de un sistema operati!o o de la forma que deería tomar la interacción humanoI máquina#
Desventajas •
+eido a que el usuario !e que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se !a a desarrollar el software#
•
l desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene con el cliente
MODELO DE DESARROLLO CONC6RRENTE
l modelo oncurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las acti!idades de la 3ngeniería del software# +urante las primeras etapas del dise"o, no se contempla una inconsistencia del modelo de análisis# sto genera la corrección del modelo de análisis de sucesos, que disparará la acti!idad de análisis del estado hecho al estado camios en espera# ste modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente1ser!idor#
Caac$e!s$icas% A %e puede e-presar de manera esquematizada A Las acti!idades lle!an procesos concurrentes A s aplicale a todo tipo de desarrollo de software A s un módulo aplicale para cliente so"ador A stá dirigido por las necesidades del usuario A es aplicale al cliente ser!idor en$aas •
•
-celente para proyectos en los que se conforman grupos de traajo independientes# &roporciona una imagen e-acta del estado actual de un proyecto#
Des0en$aas %i no se dan las condiciones se"aladas no es aplicale# %i no e-isten grupos de traajo no se puede traajar en este método • •
MODELO DESARROLLADO EN COM+ONENTES
l modelo de desarrollo asado en componentes incorpora muchas de las características del modelo espiral# s e!oluti!o por naturaleza y e-ige un enfoque interacti!o para la creación del software# %in emargo, el modelo de desarrollo asado en componentes configura aplicaciones desde componentes preparados de software (clases)# l modelo de desarrollo asado en componentes conduce a la reutilización del software, y la reutilización proporciona eneficios a los ingenieros de software
en$aas% 7# 0eutilización del software# os lle!a a alcanzar un mayor ni!el de reutilización de software# =# %implifica las prueas# &ermite que las prueas sean ejecutadas proando cada uno de los componentes antes de proar el conjunto completo de componentes ensamlados# ># %implifica el mantenimiento del sistema# uando e-iste un déil acoplamiento entre componentes, el desaollador es lire de actualizar y1o agregar componentes segBn sea necesario, sin afectar otras partes del sistema# ?# /ayor calidad# +ado que un componente puede ser construido y luego mejorado continuamente por un e-perto u organización, la calidad de una aplicación asada en componentes mejorará con el paso del tiempo Des0en$aas
•
• •
Los CcompromisosD en los requisitos son ine!itales, por lo cual puede que el software no cumpla las e-pectati!as del cliente# ALas actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema# %i no se dan las condiciones se"aladas no es aplicale %i no e-isten grupos de traajo no se puede traajar en este método
?.- MODELOS DESCRI+TIOS DE DESARROLLO DE SOFTWARE Modelo en cascada l modelo en cascada a !eces llamado ciclo de !ida clásico, sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y a!anza a tra!és de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado# Hay !eces que los requerimientos para cierto prolema se comprenden ien* cuando el traajo desde la comunicación hasta el despliegue fluye en forma razonalemente lineal# sta situación se encuentra en ocasiones cuando deen hacerse adaptaciones o mejoras ien definidas a un sistema ya e-istente (por ejemplo a un sistema de contailidad que es oligatorio hacer deido a camios en las regulaciones guernamentales)#
Modelos de oceso Incemen$al l modelo incremental comina elementos de los flujos de proceso lineal y paralelo# este modelo incremental aplica secuencias lineales en forma escalonada a medida que a!anza el calendario de acti!idades, cada secuencia lineal produce incrementos de software susceptiles de entregarse de manera paralela a los incrementos producidos en el flujo del proceso e!oluti!o, cuando se utiliza el modelo incremental, es frecuente que el primer incremento sea el producto fundamental, es decir, se aordan los requerimientos ásicos, pero no se proporcionan muchas características suplementarias (algunas conocidas y otras no)# l cliente usa el producto fundamental (o lo somete a una e!aluación detallada)# como resultado del uso y1o e!aluación, se desarrolla un plan para el incremento que sigue# l plan incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionalidades# ste proceso se repite después de entregar cada incremento, hasta terminar el producto final#
<.- MANTENIMIENTO DE SOFTWARE
El Se0icio de man$enimien$o de so)$@ae es 'na de las ac$i0idades en la Ingenie!a de So)$@ae " es el oceso de meoa " o$imi8a el so)$@ae deslegado e0isi*n del ogamaB; as! como $am,i9n emedia los de)ec$os. l mantenimiento de software es tamién una de las fases en el iclo de
•
•
•
•
•
/an$enimien$o e0en$i0o. onsiste en la re!isión constante del software para detectar posiles focos de prolemas que puedan surgir en el futuro# Man$enimien$o edic$i0o# !alBa el flujo de ejecución del programa para predecir con certeza el momento en el que se producirá la falla, y así determinar cuándo es adecuado realizar los ajustes correspondientes# Man$enimien$o coec$i0o. orrige los defectos encontrados en el software, y que originan un comportamiento distinto al deseado# stas fallas pueden ser de procesamiento, rendimiento (por ejemplo, uso ineficiente de los recursos de hardware), programación (inconsistencias en la ejecución), seguridad o estailidad, entre otras# Man$enimien$o ada$a$i0o. %i se requiere camiar el entorno de uso de la aplicación (que incluye al sistema operati!o, a la plataforma de hardware o, en el caso de las aplicaciones we, al na!egador), puede ser indispensale modificarla para mantener su plena funcionalidad en estas nue!as condiciones# Man$enimien$o e0ol'$i0o# s un caso especial donde la adaptación resulta prácticamente oligatoria, ya que de lo contrario el programa quedaría osoleto con el paso del tiempo# &or ejemplo, el camio de !ersión en un na!egador (muchas !eces impuesto sin el consentimiento del usuario) suele oligar a realizar ajustes en plugins y aplicaciones we# Man$enimien$o e)ec$i0o# &or distintas razones, el usuario puede solicitar el agregado de nue!as funcionalidades o características no contempladas al momento de la implementación del software# l mantenimiento perfecti!o adapta la aplicación a este requerimiento#
.- MODELO ES+IRAL E0al'aci*n del iesgo onsiste en e!aluar las diferentes alternati!as que se plantean teniendo en cuenta los ojeti!os a conseguir y las restricciones impuestas# Jrecuentemente, este paso identifica las áreas de incertidumre del proyecto con sus correspondientes riesgos# s el estudio
de las causas de las posiles amenazas y proales e!entos no deseados y los da"os y consecuencias que éstas puedan producir# %i e-isten riesgos, lo siguiente es la formulación de una estrategia efecti!a en coste (utilizando prototipos, simulación, ancos de pruea, cuestionario para los usuarios, modelización analítica o cominaciones de éstas y otras técnicas de resolución de riesgos) para resol!er dichos riesgos#
.- GESTION DE +ROECTOS MODELO C+M R6TA CRTICA l método &/ o 0uta rítica (equi!alente a la sigla en inglés ritical &ath /ethod) es frecuentemente utilizado en el desarrollo y control de proyectos# l ojeti!o principal es determinar la duración de un proyecto, entendiendo éste como una secuencia de acti!idades relacionadas entre sí, donde cada una de las acti!idades tiene una duración estimada# $na ruta es una trayectoria desde el inicio hasta el final de un proyecto# n este sentido, la longitud de la ruta crítica es igual a la la trayectoria más grande del proyecto# ae destacar que la duración de un proyecto es igual a la ruta crítica#
E$aas de C+M 7# +efinir el proyecto con todas sus acti!idades o partes principales# =# stalecer relaciones entre las acti!idades# +ecidir cuál dee comenzar antes y cuál dee seguir después# ># +iujar un diagrama conectando las diferentes acti!idades en ase a sus relaciones de precedencia# ?# +efinir costos y tiempo estimado para cada acti!idad# @# 3dentificar la trayectoria más larga del proyecto, siendo ésta la que determinará la duración del proyecto (0uta rítica)# K# $tilizar el diagrama como ayuda para planear, super!isar y controlar el proyecto#
en$aas cm 1.
2.
3.
nse"a una disciplina lógica para planificar y organizar un programa detallado de largo alcance# &roporciona una metodología %tandard de comunicar los planes del proyecto mediante un cuadro de tres dimensiones (tiempo, personalE costo)# 3dentifica los elementos (segmentos) más críticos del plan, en que prolemas potenciales puedan perjudicar el cumplimiento del programa propuesto#
?# frece la posiilidad de simular los efectos de las decisiones alternati!as o situaciones impre!istas y una oportunidad para estudiar sus consecuencias en relación a los plazos de cumplimiento de los programas# @# 'porta la proailidad de cumplir e-itosamente los plazos propuestos# K# n otras palaras* &/ es un sistema dinámico, que se mue!e con el progreso del proyecto, reflejando en cualquier momento el %;';$% presente del plan de acción#
Limi$aciones del cm l &/ fue desarrollado para el complejo pero los proyectos astante rutinarios con incertidumre mínima en los tiempos de la terminación del proyecto# &ara menos proyectos de la rutina hay más incertidumre en los tiempos de la terminación, y límites de esta incertidumre la utilidad del modelo determinista del &/# $na alternati!a al &/ es el modelo del planeamiento del proyecto del &0;, que permite que una gama de duraciones sea especificada para cada acti!idad#
MODELO DE GANTT l diagrama de 5';; es una herramienta que le permite al usuario modelar la planificación de las tareas necesarias para la realización de un proyecto# s una popular herramienta gráfica cuyo ojeti!o es mostrar el tiempo de dedicación pre!isto para diferentes tareas o acti!idades a lo largo de un tiempo total determinado# ' pesar de que, en principio, el diagrama de 5antt no indica las relaciones e-istentes entre acti!idades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias# n gestión de proyectos, el diagrama de 5antt muestra el origen y el final de las diferentes unidades mínimas de traajo y los grupos de tareas (llamados summary elements en la imagen) o las dependencias entre unidades mínimas de traajo (no mostradas en la imagen)# Másicamente el diagrama está compuesto por un eje !ertical donde se estalecen las acti!idades que constituyen el traajo que se !a a ejecutar, y un eje horizontal que muestra en un calendario la duración de cada una de ellas#
Características
.
ada acti!idad se representa mediante un loque rectangular cuya longitud indica su duraciónE la altura carece de significado#
.
La posición de cada loque en el diagrama indica los instantes de inicio y finalización de las tareas a que corresponden#
.
Los loques correspondientes a tareas del camino crítico acostumran a rellenarse en otro colo
en$aas N %u construcción no requiere de gran planificación# N 0esultan muy eficaces en las etapas iniciales de la planificación# N %on adecuados para la planificación de acti!idades relati!amente simples# 0epresenta un instrumento de ajo costo y e-trema simplicidad en su utilización Des0en$aas N o permite optimizar el desarrollo de un programa# N +espués de iniciada la ejecución de la acti!idad y cuando comienza a efectuarse modificaciones, el gráfico tiende a !ol!erse confuso# N o ofrece condiciones para el análisis de opciones
>I>LIOGRAFIA http*11es#wiOipedia#org1wiOi1/antenimientoPdePsoftware
MATERIA
:
DESARROLLO DE SIST. DE INFORMACIÓN CONTABLE
NOMBRE
:
ARANIBAR PACIFICO, ROSA MARIA
SEMESTRE
:
OCTAVO A-1
FECHA
:
10 DE SEPTIEMBRE DE 2013
LA PAZ-BOLIVIA
