El Software

El software no es slo cdigo, sino tambin las especificaciones del diseo, los datos tratados y la documentacin que permite el
desarrollo, instalacin y mantenimiento.
Estrictamente, se puede definir como:
1) Instrucciones que, cuando se ejecutan, proporcionan la funcionalidad deseada.
2) Estructuras de datos que facilitan a las instrucciones manipular adecuadamente la informacin.
3) Documentos que describen el desarrollo, uso, instalacin y mantenimiento de los programas.

Caractersticas del Software
1. Es un elemento lgico, no fsico, en contraposicin con el hardware.
2. Se desarrolla, no se fabrica.
3. No se estropea, se deteriora, con el tiempo, el hardware se va estropeando por la presencia de componentes fsicos el
software, al carecer de ellos, se deteriora

Cualidades del Software
Correcto
Confiable
Robusto
Eficiente
Amigable
Verificable
Reusable
Portable
Interoperable
Productivo
A Tiempo
Visible
Coheso
Desacoplado
Comprensible
Mantenible


Ingeniera
Es la aplicacin sistemtica de conocimiento cientfico para la creacin y construccin de soluciones rentables a problemas prcticos al
servicio de la humanidad.

Ingeniera Del Software
La Ingeniera del Software es una disciplina que integra mtodos, tcnicas y herramientas para el desarrollo de software de
computadora.

Sus elementos son:
Herramientas: Programas que mecanizan los mtodos y las tcnicas.
Mtodos: Conjunto de tareas ordenadas para conseguir un fin. Los mtodos se desarrollaron para cada una de las fases del
desarrollo (anlisis, diseo, implementacin, etc.).
Tcnicas: Ayudan con las dificultades para llevar a cabo lo que se indica en los mtodos.

Objetivos de la ingeniera de software
mejorar la calidad de los productos de software
aumentar la productividad y trabajo de los ingenieros del software.
Facilitar el control del proceso de desarrollo de software.
Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.
Definir una disciplina que garantice la produccin y el mantenimiento de los productos software desarrollados en el plazo
fijado y dentro del costo estimado.

Concepto de Software: El software es un ingrediente indispensable
para el funcionamiento del computador. Est formado por una serie de
instrucciones y datos, que permiten aprovechar todos los recursos que
el computador tiene, de manera que pueda resolver gran cantidad de
problemas. Un computador en si, es slo un conglomerado de
componentes electrnicos; el software le da vida al computador,
haciendo que sus componentes funcionen de forma ordenada.
El software es un conjunto de instrucciones detalladas que controlan la
operacin de un sistema computacional.
1. Principales Cualidades del Software
2. Correcto Confiable Robusto Un software es correcto si se comporta de acuerdo a su especificacin El software se comporta de acuerdo con lo
esperado por el usuario. Un software es robusto si se comporta en forma razonable an en situaciones no anticipadas.
3. Eficiencia-Performance Amigable Verificable Un sistema de software es eficiente si usa sus recursos en forma econmica. Un software es
amigable si sus usuarios lo encuentran fcil de utilizar. El software es verificable si sus propiedades pueden ser comprobadas.
4. Reusable Portable Interoperable Software ya construido se usa con pocos o ningn cambio. Un software es portable si puede ejecutarse en
distintos ambientes (hardware, sistemas operativos, etc.) Un sistema es interoperable si puede coexistir y cooperar con otros sistemas.
El desarrollo de software se ha vuelto uno de los principales ejes de conocimiento y crecimiento profesional y empresarial en los ltimos aos, debido a la globalizacin y
aplanamiento del mundo en que vivimos. Todo se est haciendo en torno al software e Internet. Y es por estos motivos y miles ms, que el desarrollo de estos grandes
sistemas, debe ser casi perfecto, y se deben seguir ciertos factores de calidad que as lo aseguran. En este artculo trato de describir algunos de los ms importantes como lo
son la reusabilidad, legibilidad y seguridad, sus factores, mtricas y ejemplo de como se deben implementar.
Reusabilidad:
La necesidad de la reutilizacin surge de la observacin de que los sistemas software a menudo siguenpatrones similares; debera ser posible explotar esta similitud y evitar
reinventar soluciones a problemas que ya han sido encontradas con anterioridad. Capturando tal patrn, un elemento de software reutilizable se podr aplicar en muchos
desarrollos diferentes.
Reusabilidad Tipo de factor:
La reusabilidad es un factor de tipo externo, ya que es perceptible por los usuarios o clientes, por ejemplo al momento de ut ilizar partes de un software en otro diferente.
Tambin en el caso de los usuarios que son programadores, utilizar partes de cdigos creadas en otros desarrollos para su propio trabajo (libreras).
Reusabilidad Ejemplo: Ingeniera de software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y
mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicacin de la ingeniera al software.
1
Es la aplicacin de la ingeniera al
software, ya que integra matemticas, ciencias de la computacin y prcticas cuyos orgenes se encuentran en la ingeniera.
2

Se pueden citar otras definiciones enunciadas por prestigiosos autores:
Ingeniera de software es el estudio de los principios y metodologas para el desarrollo y mantenimiento de sistemas software (Zelkovitz,
1978)
Ingeniera de software es la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la
documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como desarrollo de software o produccin de
software (Bohem, 1976).
La ingeniera de software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable,
que sea fiable y trabaje en mquinas reales (Bauer, 1972).
En el 2004, en los Estados Unidos, la Oficina de Estadsticas del Trabajo (U. S. Bureau of Labor Statistics) cont 760.840 ingenieros de software
de computadora.
3
El trmino "ingeniero de software", sin embargo, se utiliza en forma genrica en el ambiente empresarial, y no todos los que se
desempean en el puesto de ingeniero de software poseen realmente ttulos de ingeniera de universidades reconocidas.
Algunos autores consideran que "desarrollo de software" es un trmino ms apropiado que "ingeniera de software" para el proceso de crear
software. Personas como Pete McBreen (autor de "Software Craftmanship") cree que el trmino IS implica niveles de rigor y prueba de procesos
que no son apropiados para todo tipo de desarrollo de software.
Indistintamente se utilizan los trminos "ingeniera de software" o "ingeniera del software"; aunque menos comn tambin se suele referenciar
como "ingeniera ensoftware".
4

5

6
En Hispanoamrica los trminos ms comnmente usados son los dos primeros.
La creacin del software es un proceso intrnsecamente creativo y la ingeniera del software trata de sistematizar este proceso con el fin de acotar
el riesgo del fracaso en la consecucin del objetivo, por medio de diversas tcnicas que se han demostrado adecuadas en base a la experiencia
previa.
La IS se puede considerar como la ingeniera aplicada al software, esto es, por medios sistematizados y con herramientas preestablecidas, la
aplicacin de ellos de la forma ms eficiente para la obtencin de resultados ptimos; objetivos que siempre busca la ingeniera. No es slo de la
resolucin de problemas, sino ms bien teniendo en cuenta las diferentes soluciones, elegir la ms apropiada.

Un ejemplo de la reusabilidad son las libreras.
Las libreras son mdulos de cdigos o un conjunto de subprogramas que son utilizados para el desarrollo de software.
por ejemplo la librera java.awt permite disponer de una cantidad de cdigos reutilizables a la hora de crear interfaces grf icas y todos sus componentes dentro de la
creacin de un proyecto de software.
Reusabilidad Mtrica:
la reusabilidad est dentro del contexto de las mtricas de calidad.
las mtricas de calidad son todas las mtricas de software que definen de una u otra forma la calidad delsoftware; tales como exactitud, estructuracin o modularidad,
pruebas, mantenimiento, reusabilidad, entre otras. Estas son los puntos crticos en el diseo, codificacin, pruebas y mantenimiento.
VISIN GENERAL DEL PROCESO DE DESARROLLO DE SOFTWARE

Es proceso es afectado por la creatividad y juicio de las personas involucradas. En el desarrollo de software hay una serie
de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Un proceso de desarrollo de software tiene como
propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente.

Es actividades requeridas para desarrollar un sistema de software de alta calidad y proporciona el marco de trabajo desde el
cual se puede establecer un plan detallado para el desarrollo del software. Actividades: Diseo, validacin, evolucin, especificacin.
EL PAPEL DEL USUARIO DENTRO DEL PROCESO DE DESARROLLO DE SOFTWARE
El rol que el usuario desempea dentro del desarrollo de un Sistema de Informacin es de suma importanci a, ya que los sistemas se construyen para
satisfacer las necesidades particulares del usuario, en funcin de los objetivos estratgicos de la organizacin y ninguna otra persona, incluyendo al analista
del sistema, conoce mejor que el usuario mismo, sus propios requerimientos; razn por la cual se dice que el usuario es el Dueo del Sistema. Sin embargo,
ste no es su nico papel, ya que existen una serie de funciones que el usuario debe asumir durante todo el desarrollo del proyecto, las cuales van exigiendo
una determinada categorizacin del usuario de acuerdo a la responsabilidad que tendr dentro del proyecto.

Deben comportarse de una forma tica y moral responsable. No basta con poseer estndares normales de honestidad e integridad. No debera utilizar su
capacidad y sus habilidades para comportarse de forma deshonesta o de forma que deshonre la profesin de la ingeniera del software. Existen reas donde
los estndares de comportamiento aceptable no estn acotados por las leyes, sino por la responsabilidad profesional. Algunas de stas son: Confidencialidad.
Respetar la confidencialidad de sus empleadores o clientes, independientemente de que se haya firmado un acuerdo formal de confidencialidad. Competencia.
No debe falsificar su nivel de competencia, ni aceptar conscientemente trabajos que estn fuera de su capacidad.
Responsabilidad y etica profesional
Responsabilidad profesional y tica

La ingeniera del software se lleva a cabo dentro de un marco legal y social
que limita la libertad de los ingenieros.

Los ISW deben aceptar que su trabajo comprende responsabilidades ms
amplias que simplemente la aplicacin de habilidades tcnicas.

Deben comportarse de una forma tica y moral responsable.

No basta con poseer estndares normales de honestidad e integridad.

No debera utilizar su capacidad y sus habilidades para comportarse de forma
deshonesta o de forma que deshonre la profesin de la ingeniera del software.

Existen reas donde los estndares de comportamiento aceptable no estn
acotados por las leyes, sino por la responsabilidad profesional.

Algunas de stas son:

Confidencialidad. Respetar la confidencialidad de sus empleadores o clientes,
independientemente de que se haya firmado un acuerdo formal de
confidencialidad.

Competencia. No debe falsificar su nivel de competencia, ni aceptar
conscientemente trabajos que estn fuera de su capacidad.

Derechos de propiedad intelectual. Debe ser consciente de las leyes locales
que gobiernan el uso de la propiedad intelectual, como las patentes y el
copyright. Debe asegurarse de que la propiedad intelectual de los empleadores
y clientes est protegida.

Uso inapropiado de las computadoras. No debe emplear sus habilidades
tcnicas para utilizar de forma inapropiada las computadoras de otras
personas. Desde los relativamente triviales (utilizar juegos en la mquina de
un empleado, por ejemplo) hasta los extremadamente serios (difusin de
virus).

Cdigo de tica (ACM/IEEE)

Los ingenieros de software debern comprometerse consigo mismos en
convertir el anlisis, especificacin, diseo, desarrollo, prueba y
mantenimiento de software en una profesin respetable y beneficiosa. De
acuerdo con su compromiso con la salud, seguridad y bienestar del pblico,
los Ingenieros de Software debern apegarse a Ocho Principios

Principios del cdigo

PBLICO - Los Ingenieros de Software debern actuar consistentemente con
el inters pblico.

CLIENTE Y EMPLEADOR - Los Ingenieros de Software debern actuar de
una forma determinada que est en los mejores intereses de su cliente y
empleador consistente con el inters pblico.

PRODUCTO- Los Ingenieros de Software debern asegurar que sus productos
y modificaciones relacionadas logren el ms alto estndar profesional posible.

JUICIO - Los Ingenieros de Software debern mantener integridad e
independencia al emitir su juicio profesional.



GERENCIA - Los gerentes y lderes de Ingeniera de Software debern
suscribirse y promocionar un enfoque tico para la gerencia de desarrollo y
mantenimiento de software.

PROFESIN - Los Ingenieros de Software debern fomentar la integridad y
reputacin de la profesin consistente con el inters pblico.

COLEGAS - Los Ingenieros de Software debern ser justos y comprensivos
con sus colegas.

INTERS PROPIO - Los Ingenieros de Software debern participar en el
aprendizaje de por vida del ejercicio de su profesin y debern promover un
enfoque tico para el ejercicio de la misma.

Ciclo de vida del software

El trmino ciclo de vida del software describe el desarrollo de software, desde la fase inicial
hasta la fase final. El propsito de este programa es definir las distintas fases intermedias que
se requieren para validar el desarrollo de la aplicacin, es decir, para garantizar que el
software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de
desarrollo: se asegura de que los mtodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se
detectan tarde dentro de la fase de implementacin. El ciclo de vida permite que los errores se
detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la
calidad del software, en los plazos de implementacin y en los costos asociados.

El ciclo de vida bsico de un software consta de los siguientes procedimientos:

Definicin de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
Anlisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del
cliente y examinar cualquier restriccin que se pueda aplicar.
Diseo general: requisitos generales de la arquitectura de la aplicacin.
Diseo en detalle: definicin precisa de cada subconjunto de la aplicacin.
Programacin (programacin e implementacin): es la implementacin de un lenguaje de
programacin para crear las funciones definidas durante la etapa de diseo.
Prueba de unidad: prueba individual de cada subconjunto de la aplicacin para garantizar que
se implementaron de acuerdo con las especificaciones.
Integracin: para garantizar que los diferentes mdulos se integren con la aplicacin. ste es el
propsito de la prueba de integracin que est cuidadosamente documentada.
Prueba beta (o validacin), para garantizar que el software cumple con las especificaciones
originales.
Documentacin: sirve para documentar informacin necesaria para los usuarios del software y
para desarrollos futuros.
Implementacin
Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las
actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos
procedimientos en el ciclo de vida de una aplicacin
dependen del tipo de modelo de ciclo de vida acordado
entre el cliente y el equipo de desarrolladores.
Introduccin[editar]
Una metodologa de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo
en sistemas de informacin.
A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados diferencindose por su fortaleza y debilidad.
El framework para metodologa de desarrollo de software consiste en:
Una filosofa de desarrollo de programas de computacion con el enfoque del proceso de desarrollo de software
Herramientas, modelos y mtodos para asistir al proceso de desarrollo de software
Estos frameworks son a menudo vinculados a algn tipo de organizacin, que adems desarrolla, apoya el uso y promueve la metodologa. La
metodologa es a menudo documentada en algn tipo de documentacin formal.
Historia[editar]
El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para desarrollar a gran escala funcional de sistemas de
negocio en una poca de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de informacin en
una muy deliberada, estructurada y metdica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de informacin en torno a las
actividades resueltas pesadas para el procesamiento de datos y rutinas de clculo.
Metodologas de Desarrollo de Software tiene como objetivo presentar un conjunto de tcnicas tradicionales y modernas de modelado de sistemas
que permitan desarrollar software de calidad, incluyendo heursticas de construccin y criterios de comparacin de modelos de sistemas.
Para tal fin se describen, fundamentalmente, herramientas de Anlisis y Diseo Orientado a Objetos (UML), sus diagramas, especificacin, y
criterios de aplicacin de las mismas. Como complemento se describirn las metodologas de desarrollo de software que utilizan dichas
herramientas, ciclos de vida asociados y discusin sobre el proceso de desarrollo de software ms adecuado para las diferentes aplicaciones
ejemplos que se presentarn. Principalmente, se presentar el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

Kendall y Kendall
I. Identificacin del problema, oportunidades y objetivos. II. Determinacin de los requerimientos de informacin. III. Anlisis de las necesidades del
sistema. IV. Diseo del sistema recomendado. V. Desarrollo y documentacion del software. VI. Pruebas y mantenimiento del sistema. VII.
Implantacin y evaluacin del sistema.
James Senn
I. Ciclo de vida y desarrollo del sistema. II. Desarrollo por anlisis estructurado III. Prototipo del sistema.
Llorens Fabregas
I. Requerimientos. II. Analisis/Diseo. III. Construccin. IV. Pruebas. V. Produccin y mantenimiento.
Jonas Montilva
I. Definir el proyecto. II. Anlisis del contexto. III. Definicin de los requerimientos. IV. Diseo preliminar. V. Diseo detallado.
Roger Pressman
I. Anlisis de los requerimientos del Software. II. Diseo. III. Genaracion de codigo. IV. Pruebas. V. Mantenimiento.
Metodologas de desarrollo de software[editar]
1970
Programacin estructurada sol desde 1969
Programacin estructurada Jackson desde 1975
1980
Structured Systems Analysis and Design Methodology (SSADM) desde 1980
Structured Analysis and Design Technique (SADT) desde 1980
Ingeniera de la informacin (IE/IEM) desde 1981
1990
Rapid application development (RAD) desde 1991.
Programacin orientada a objetos (OOP) a lo largo de la dcada de los 90's
Virtual finite state machine (VFSM) desde 1990s
Dynamic Systems Development Method desarrollado en UK desde 1995.
Scrum (desarrollo), en la ltima parte de los 90's
Rational Unified Process (RUP) desde 1999.
Extreme Programming(XP) desde 1999
Nuevo milenio
Enterprise Unified Process (EUP) extensiones RUP desde 2002
Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thrisson
Agile Unified Process (AUP) desde 2005 por Scott Ambler
Enfoques de desarrollo de software[editar]
Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para el desarrollo de software. Estos son los enfoques ms
generales, que se desarrollan en varias metodologas especficas. Estos enfoques son los siguientes:
1

Modelo en cascada: Framework lineal.
Prototipado: Framework iterativo.
Incremental: Combinacin de framework lineal e iterativo.
Espiral: Combinacin de framework lineal e iterativo.
RAD: Rapid Application Development, framework iterativo.
Modelo en cascada[editar]
Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a travs de las
fases de anlisis de las necesidades, el diseo, implantacin, pruebas (validacin), la integracin, y mantenimiento. La primera descripcin formal
del modelo de cascada se cita a menudo a un artculo publicado por Winston Royce W.
2
en 1970, aunque Royce no utiliza el trmino "cascada" de
este artculo.
Los principios bsicos del modelo de cascada son los siguientes:
1

El proyecto est dividido en fases secuenciales, con cierta superposicin y splashback aceptable entre fases.
Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y ejecucin de todo un sistema de una sola vez.
Un estricto control se mantiene durante la vida del proyecto a travs de la utilizacin de una amplia documentacin escrita, as como a
travs de comentarios y aprobacin / signoff por el usuario y la tecnologa de la informacin de gestin al final de la mayora de las fases
antes de comenzar la prxima fase.
Prototipado[editar]
El prototipado permite desarrollar modelos de aplicaciones de software que permiten ver la funcionalidad bsica de la misma, sin necesariamente
incluir toda la lgica o caractersticas del modelo terminado. El prototipado permite al cliente evaluar en forma temprana el producto, e interactuar
con los diseadores y desarrolladores para saber si se est cumpliendo con las expectativas y las funcionalidades acordadas.
Incremental[editar]
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos
para el futuro.
Los principios bsicos son:
Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una
pequea parte de los sistemas, antes de proceder a la prxima incremental.
Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del
sistema.
El concepto inicial de software, anlisis de las necesidades, y el diseo de la arquitectura y colectiva bsicas se definen utilizando el
enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalacin del prototipo final.
Espiral[editar]
Los principios bsicos son:
La atencin se centra en la evaluacin y reduccin del riesgo del proyecto dividiendo el proyecto en segmentos ms pequeos y
proporcionar ms facilidad de cambio durante el proceso de desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y con un peso
de la consideracin de la continuacin del proyecto durante todo el ciclo de vida.
Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes bsicos: (1) determinar objetivos, alternativas, y desencadenantes de la
iteracin; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteracin, y (4) plan de la
prxima iteracin.
3

Cada ciclo comienza con la identificacin de los interesados y sus condiciones de ganancia, y termina con la revisin y examinacin.
3

Rapid Application Development (RAD)[editar]
El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de software, que implica el desarrollo iterativo y la construccin de
prototipos. El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de
software introducido por James Martin en 1991.
Principios bsicos:
Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversin.
Intenta reducir el riesgos inherente del proyecto partindolo en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el
proceso de desarrollo.
Orientacin dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteracin por prototipos (en
cualquier etapa de desarrollo), promueve la participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas
herramientas pueden incluir constructores de Interfaz grfica de usuario (GUI), Computer Aided Software Engineering (CASE) las
herramientas, los sistemas de gestin de bases de datos (DBMS), lenguajes de programacin de cuarta generacin, generadores de cdigo,
y tcnicas orientada a objetos.
Hace especial hincapi en el cumplimiento de la necesidad comercial, mientras que la ingeniera tecnolgica o la excelencia es de menor
importancia.
Control de proyecto implica el desarrollo de prioridades y la definicin de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace
hincapi en la reduccin de requisitos para el ajuste, no en el aumento de la fecha lmite.
En general incluye Joint application development (JAD), donde los usuarios estn intensamente participando en el diseo del sistema, ya
sea a travs de la creacin de consenso estructurado en talleres, o por va electrnica.
La participacin activa de los usuarios es imprescindible.
Iterativamente realiza la produccin de software, en lugar de enfocarse en un prototipo.
Produce la documentacin necesaria para facilitar el futuro desarrollo y mantenimiento.
Otros enfoques de desarrollo de software[editar]
Metodologas de desarrollo Orientado a objetos, Diseo
SELECCIN DEL MODELO APROPIADO SEGN LAS CARACTERISTICAS DE LOS
PROYECTOS DE SOFTWARE
Cuando se gestiona un proyecto exitoso, es necesario entender que este puede llegar a fracasar. Segn John Reel, existen 10 razones por las cuales un
proyecto puede fracasar:

1. El personal de software no entiende las necesidades del los clientes.
2. El mbito del producto est mal definido.
3. Los cambios se gestionan mal.
4. La tecnologa elegida cambia.
5. Las necesidades comerciales cambian.
6. Los plazos de entrega no son realistas.
7. Los usuarios se resisten a la utilizacin del software.
8. Se pierde el patrocinio.
9. El equipo del proyecto carece de personal con las habilidades apropiadas.
10. Los gestores evitan las mejores prcticas y las lecciones aprendidas.

Para tener xito en la consecucin de un proyecto es necesario comenzar con pie derecho, esto se lo logra trabajando duro para entender el problema y dar
una solucin adecuada. Se debe rastrear el proyecto conforme se elabora el producto y se aprueba por parte del grupo de control de calidad. Es importante
que el gestor del proyecto tome decisiones inteligentes para no poner en riesgo el desarrollo de la solucin. Por ltimo, se debe analizar los resultados
obtenidos para obtener la experiencia necesaria en la construccin de otros proyectos.
Publicado por Humberto Castillo en 5:32
Proceso para el desarrollo de software
Un proceso para el desarrollo de software, tambin denominado ciclo de vida del
desarrollo de software es una estructura aplicada al desarrollo de un producto
de software. Hay varios modelos a seguir para el establecimiento de un proceso para el
desarrollo de software, cada uno de los cuales describe un enfoque diferente para
diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un
modelo de ciclo de vida un trmino ms general que un determinado proceso para el
desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software
especficos que se ajustan a un modelo de ciclo de vida de espiral.
FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETOS.
Fundamentos del Enfoque orientado a Objetos.

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen
la base de todo desarrollo orientado a objetos. Estos principios son: la Abstraccin, el
Encapsulamiento, la Modularidad y la Herencia.

Fundamento 1: Abstraccin

Es el principio de ignorar aquellos aspectos de un fenmeno observado que
no son relevantes, con el objetivo de concentrarse en aquellos que si lo son.Una
abstraccin denota las caractersticas esenciales de un objeto (datos y operaciones),
que lo distingue de otras clases de objetos. Decidir el conjunto correcto de
abstracciones de un determinado dominio, es el problema central del diseo orientado
a objetos.
Los mecanismos de abstraccin son usados en el EOO para extraer y definir del
medio a modelar, sus caractersticas y su comportamiento. Dentro del EOO son muy
usados mecanismos de abstraccin: la Generalizacin, la Agregacin y la clasificacin.
La generalizacin es el mecanismo de abstraccin mediante el cual un
conjunto de clases de objetos son agrupados en una clase de nivel superior
(Superclase), donde las semejanzas de las clases constituyentes (Subclases) son
enfatizadas, y las diferencias entre ellas son ignoradas. En consecuencia, a travs de
la generalizacin, la superclase almacena datos generales de las subclases, y las
subclases almacenan slo datos particulares.La especializacin es lo contrario de la
generalizacin. Por ejemplo; La clase Mdico es una especializacin de la clase
Persona, y a su vez, la clase Pediatra es una especializacin de la superclase
Mdico.
La agregacin es el mecanismo de abstraccin por el cual una clase de objeto
es definida a partir de sus partes (otras clases de objetos). Mediante agregacin se
puede definir por ejemplo un computador, por descomponerse en: la CPU, la ULA, la
memoria y los dispositivos perifricos. El contrario de agregacin es la
descomposicin.
La clasificacin consiste en la definicin de una clase a partir de un conjunto
de objetos que tienen un comportamiento similar. La ejemplificacin es lo contrario a la
clasificacin, y corresponde a la instanciacin de una clase, usando el ejemplo de un
objeto en particular.
Pgina principal
Temas Variados
Las competencias: su clasificacin caractersticas y aplicabilidad para el
trabajo escolar.
Regstrese para
acceso completo a ensayos
Enviado por y4r4, mayo 2010 | 16 Pginas (3870 Palabras) | 11 Visitas
|
4
.5
1

2

3

4

5

|
Denunciar
|
SI QUIERES TENER SUERTE, HAZ CLICK TRES VECES...
Enviar



Las competencias: su clasificacin caractersticas y aplicabilidad para el trabajo escolar.

Hay tres tipos decompetencias: la competencia ACADMICA, la competencia LABORAL y la competencia PROFESIONAL. Las
competencias acadmicas sonresponsabilidad de las instituciones educativas; las competencias laborales es el aprendizaje
con independencia del lugar en donde fueadquirido, muchos mexicanos ni siquiera tuvieron la oportunidad determinar la
primaria y a una edad temprana se incorporaronal mundo del trabajo o, como en algunos tiempos, cuando uno era un inquieto,
un travieso y todo, el sistema lo expulsaba,porque decan que era un nio grosero, malcriado, inquieto y entonces llegaba la
mam con el maestro carpintero o el del tallermecnico y les deca "aqu le dej a mi hijo para qu haga de el un hombre" y lo
quitaban del sistema educativo. Ahora lellamamos TDAH, trastorno por dficit de atencin por hiperactividad, pero seguimos
sin entender que todos los seres humanostenemos capacidades diferentes. No nos podemos comportar de la misma forma en
ningn lugar, porque todos somos diferentes, todospercibimos diferentes, somos nicos e irrepetibles, imagnense qu
maravilla...
Componentes, tipos, caracteristicas y reusabilidad de componentes


Tipos de componentes y caratersticas
Componentes de despliegue o distribucin (Deployment)
Estos componentes se usan para formar un sistema ejecutable. Un ejemplo de tal componente es la librera de enlace dinmico y los
archivos ejecutables. Otros ejemplos son los componentes COM+, Enterprise Java Beans, componentes CORBA y objetos de base de
datos.

Componentes de Producto de Trabajo
Estos componentes son parte del proceso de desarrollo que es esencial para el sistema. Algunos ejemplos de componentes de producto
de trabajo son los archivos fuente, archivos de datos y tablas. Ellos son los archivos fuente y archivos de datos que se usan para crear
los componentes de distribucin como AgenteAnalizado.Java y AnalizadorDatos.txt.

Componentes de Ejecucin
Estos componentes son el resultado de un sistema que se est ejecutando. Cuando un DLL es instanciado como un componente
COM+, es un ejemplo de un componente de ejecucin.


Caractersticas

La caracterstica fundamental de un componente es la habilidad de definir interfaces.
Es una unidad ejecutable que puede ser implantada independientemente.
Puede ser sujeto de composicin por terceras partes, es decir, una compaa o un desarrollador puede llegar y tomar el
componente y agregarlo a lo que est haciendo, o sea hara una composicin de componentes.
Un componente no tiene estado.
Se puede tomar a los componentes de software como una analoga a los componentes electrnicos.

Reusabilidad de componentes.

Una vez que una clase ha sido escrita, creada y depurada, se puede distribuir a otros programadores para utilizar en sus
propios programas. Esta propiedad se llama reusabilidad o reutilizacin. Su concepto es similar a las funciones incluidas en las
bibliotecas de funciones de un lenguaje procedimental como C que se pueden incorporar en diferentes programas. En C++, el concepto
de herencia proporciona una extensin o ampliacin al concepto de reusabilidad.

Un programador puede considerar una clase existente y sin modificarla, aadir competencias y propiedades adicionales a
ella. Esto se consigue derivando una nueva clase de una ya existente. La nueva clase heredar las caractersticas de la clase antigua,
pero es libre de aadir nuevas caractersticas propias.

La facilidad de reutilizar o rehusar el software existente es uno de los grandes beneficios de la POO: muchas empresas
consiguen con la reutilizacin de clase en nuevos proyectos la reduccin de los costes de inversin en sus presupuestos de
programacin. Las propiedades comunes de varias clases slo necesitan ser implementadas una vez y slo necesitan modificarse una
vez si es necesario.
Proceso para el desarrollo de software
Un proceso para el desarrollo de software, tambin denominado ciclo de vida del
desarrollo de software es una estructura aplicada al desarrollo de un producto
de software. Hay varios modelos a seguir para el establecimiento de un proceso para el
desarrollo de software, cada uno de los cuales describe un enfoque diferente para
diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un
modelo de ciclo de vida un trmino ms general que un determinado proceso para el
desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software
especficos que se ajustan a un modelo de ciclo de vida de espiral.
Documentacin y Artefactos


La documentacin no es ms que la debilidad ms frecuente en productos e instalaciones
informticos. Cabe mencionar que los actores que intervienen en el ciclo de vida del software
desempean diversos roles. Arquitectos, diseadores, analistas, programadores,
implementadores, administradores o auditores son quienes explicitan distintos aspectos de los
productos y procesos.

Un artefacto es una pieza de informacin que es producida o utilizada por procesos. Los
artefactos son los elementos son los elementos tangibles de un proyecto, elementos que el
proyecto produce o usa mientras se trabaja en busca del producto final. stos, pueden tomar
varias formas y formatos, como por ejemplo:

Un documento, tal como la visin o la lista de riesgos.
Un modelo, por ejemplo un diagrama de casos de uso o el modelo de diseo.
Un elemento dentro de un modelo, tal como una clase, un caso de uso o un subsistema.
Ejecutables, por ejemplo el ejecutable del prototipo.
Cdigo fuente.

Las actividades tienen artefactos como entrada y salida. Los roles usan artefactos para ejecutar
actividades y producen artefactos durante la ejecucin de sus actividades. Los artefactos son la
responsabilidad sencilla del rol, creando responsabilidades fciles de identificar y entender,
promoviendo la idea de que cada pieza de informacin producida en un proceso de desarrollo
requiere un conjunto apropiado de habilidades. Aunque un rol puede ser el propietario de un
artefacto, otros roles pueden hacer uso de ste, incluso podran actualizar el artefacto si el rol
que va a hacerlo, tiene permiso para hacerlo.
En RUP se encuentran conjuntos de artefactos que agrupan artefactos relacionados con el
modelo de negocio, los requerimientos, el anlisis y diseo, la implementacin, las pruebas, la
configuracin y administracin de cambios, el ambiente de desarrollo, entre otros.
Metodologa empleada
La realizacin de este proyecto se ha llevado a cabo conforme al siguiente plan de trabajo:


Planificacin del estudio
Personal de IBV, Obra Social de la CAM y del Servicio de Prevencin de Riesgos Laborales de la CAM,mantuvieron reuniones de trabajo para la seleccin del mbito
del proyecto, as como para la correcta definicin de los puestos de trabajo tipo sobre los cuales se centrara el estudio.
Revisin documental
El objetivo de esta fase, fue la realizacin de una amplia revisin bibliogrfica con la finalidad de obtener informacin del sector (descripcin de los puestos de trabajo,
problemas ergonmicos ms frecuentes, buenas prcticas, recomendaciones sobre integracin laboral, experiencias anteriores, metodologas existentes, etc).
Estudio de campo
Para la obtencin de informacin de los puestos de trabajo objeto de estudio (resumen de la tarea, elementos y equipos utilizados, tiempo, etc) se realiz un estudio de
campo en entidades de la CAM.
Durante el estudio de campo, se realizaron entrevistas a personal de los diferentes puestos de trabajo con la finalidad de identificar las demandas tanto fsicas, psquicas
como sensoriales as como las condiciones del entorno requeridas para el desarrollo de la actividad.
Asimismo, se recogi informacin y experiencias de trabajadores con discapacidad que llevan a cabo su trabajo en oficinas de la CAM.

Mapa de posibilidades de integracin
A partir de la informacin recopilada en las fases anteriores se elabor un perfil de puestos de trabajo tipo, as como el desglose de las demandas de las tareas de cada
puesto. Posteriormente, se compararon estas demandas con perfiles de usuarios con discapacidad, obteniendo un mapa de posibil idades de integracin a travs de la
valoracin de la situacin de cada combinacin puesto-perfil de discapacidad
El procedimiento de anlisis utilizado para el estudio de las posibilidades de integracin laboral se bas en el mtodo ErgoDis/IBV de adaptacin ergonmica de puestos de
trabajo para personas con discapacidad.
Elaboracin del material de difusin y comunicacin
La fase final del proyecto ha consistido en la elaboracin de materiales divulgativos especficos que faciliten la insercin laboral de las personas con discapacidad, as como
el diseo y desarrollo de la campaa de comunicacin. Como material de difusin desarrollado en el mbito del proyecto cabe destacar:
Elaboracin del presente portal de internet con los resultados del proyecto
Elaboracin de un folleto informativo en el que se recopila informacin general del proyecto: explicacin del proyecto, qu se ha realizado y dnde se puede
encontrarse la informacin completa de los resultados obtenidos.
Plan de difusin en medios de comunicacin (prensa general, especializada, diferentes medios de comunicacin, etc).
Jornadas de presentacin de los resultados del proyecto.
Proceso Unificado de Rational
El Proceso Unificado de Rational (Rational Unified Process en ingls, habitualmente
resumido como RUP) es un proceso de desarrollo de software desarrollado por la
empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje
Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el
anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin.
Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que
incluye informacin entrelazada de diversos artefactos y descripciones de las diversas
actividades. Est incluido en el Rational Method Composer (RMC), que permite la
personalizacin de acuerdo con las necesidades.
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y
una especificacin ms detallada, el Rational Unified Process, que se vendiera como
producto independiente...
ndice
[ocultar]
1 Principios de desarrollo
o 1.1 Adaptar el proceso
o 1.2 Equilibrar prioridades
o 1.3 Demostrar valor iterativamente
o 1.4 Colaboracin entre equipos
o 1.5 Elevar el nivel de abstraccin
o 1.6 Enfocarse en la calidad
2 Ciclo de vida
3 Principales caractersticas
4 Fases
5 Artefactos
6 Un poco de historia
7 Comentarios sobre Metodo
8 Enlaces externos
Principios de desarrollo[editar]
El RUP est basado en 6 principios clave que son los siguientes:
Adaptar el proceso[editar]
El proceso deber adaptarse a las necesidades del cliente ya que es muy importante
interactuar con l. Las caractersticas propias del proyecto. El tamao del mismo, as como
su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se
deber tener en cuenta el alcance del proyecto en un rea subnormal.
Equilibrar prioridades[editar]
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o
disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de
todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente[editar]
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada
iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se
refina la direccin del proyecto as como tambin los riesgos involucrados.
Colaboracin entre equipos[editar]
El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber
una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes,
resultados, etc.
Elevar el nivel de abstraccin[editar]
Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del
software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto
evita que los ingenieros de software vayan directamente de los requisitos a la codificacin
de software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de
la mejor manera los requisitos y sin comenzar desde un principio pensando en la
reutilizacin del cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre
diversos niveles y soluciones arquitectnicas. stas se pueden acompaar por las
representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
Enfocarse en la calidad[editar]
El control de calidad no debe realizarse al final de cada iteracin, sino en todos los
aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente.
Ciclo de vida[editar]


Esfuerzo en actividades segn fase del proyecto.
El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones
en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en
las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las
disciplinas segn la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la
comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la
eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la
arquitectura.
Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado
del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la
arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la
arquitectura.
En la fase de construccin, se lleva a cabo la construccin del producto por medio de una
serie de iteraciones.
Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su anlisis y diseo
y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada
ciclo. Se realizan iteraciones hasta que se termine la implementacin de la nueva versin
del producto.
En la fase de transicin se pretende garantizar que se tiene un producto preparado para su
entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo
de la fase el esfuerzo dedicado a una disciplina vara.
Principales caractersticas[editar]
Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y
cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental,
estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son
los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el
cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado
momento, una persona puede desempear distintos roles a lo largo del proceso).
Fases[editar]
Establece oportunidad y alcance
Identifica las entidades externas o actores con las que se trata
Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:
'Proceso': Las etapas de esta seccin son: (Revise nuevamente la grfica)
Modelado de negocio
Requisitos
Anlisis y Diseo
Implementacin
Pruebas
Despliegue
Soporte: En esta parte nos encontramos con las siguientes etapas:
Gestin del cambio y configuraciones
Gestin del proyecto
Entorno
La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo
fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas
anteriormente:
Inicio (tambin llamado Incepcin o Concepcin).
Elaboracin.
Desarrollo (tambin llamado Implementacin, Construccin).
Cierre (tambin llamado Transicin).
Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con
los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy
general de la arquitectura de software y producir el plan de las fases y el de iteraciones
posteriores.
Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que
permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza
la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del
problema, se disea la solucin preliminar.
Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema,
para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo
a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.
Fase de Transicin: El propsito de esta fase es asegurar que el software est disponible
para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe
verificar que el producto cumpla con las especificaciones entregadas por las personas
involucradas en el proyecto.
Artefactos[editar]
RUP en cada una de sus fases (pertenecientes a la estructura dinmica) realiza una serie
de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del
sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio:
Documento Visin
Diagramas de caso de uso
Especificacin de Requisitos
Diagrama de Requisitos
Elaboracin:
Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lgica
Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)
Vista de Implementacin
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin
Vista Conceptual
Modelo de dominio
Vista fsica
Mapa de comportamiento a nivel de hardware.
Diseo y desarrollo de casos de uso, o flujos de casos de uso arquitectnicos
Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura
documentada responde adecuadamente a requerimientos funcionales y no
funcionales.

Construccin:
Especificacin de requisitos faltantes
Diseo y desarrollo de casos de uso y/o flujos de acuerdo con la planeacin iterativa
Pruebas de los casos de uso desarrollados, y pruebas de regresin segn sea el caso
Transicin:
Pruebas finales de aceptacin
Puesta en produccin
Estabilizacin
Un poco de historia[editar]
Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la
investigacin. En 1995 Rational Software compr una compaa sueca llamada Objectory
AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los
mtodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de
una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory
AB). El primer resultado de esta fusin fue el Rational Objectory Process, la primera
versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe
Kruchten.
El primer libro para describir el proceso fue titulado "The Unified Software Development
Process (ISBN 0-201-57169-2)" El Proceso Unificado de Desarrollo de Software (ISBN 0-
201-57169-2), y publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh.
Comentarios sobre Metodo[editar]
Por otro lado, en lo que se refiere a la metodologa esta comprende tres principios claves:
Dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental.
En lo referente a dirigido por los casos de uso, significa que los requerimientos estn
enfocado a dar valor al cliente y que el proceso debe garantizar que todo el desarrollo,
pruebas, planeacin, documentacin etc, est orientado a cubrir estas expectativas del
cliente y asegurar que los requerimientos de valor se ponen en produccin.
En lo referente a centrado en arquitectura, significa que hay un nfasis a disear una
arquitectura de calidad, y es la arquitectura tambin la que gua la forma cmo se debe
planear y hacer el desarrollo.
En lo referente a iterativo e incremental, significa que el proyecto se divide en varios ciclos
de vida (llamadas iteraciones) que deben dar como resultado un ejecutable. Por cada una
de las iteraciones se va agregando requerimientos y sobre todo valor al cliente; por este
motivo es incremental.
Fundamentos de los procesos Agiles de desarrollo


FUNDAMENTOS DE LOS PROCESOS GILES DE DESARROLLO
El auge de la tecnologa, y el objetivo de agilizar y automatizar los procesos en
el desarrollo de software, llevan a la necesidad de implantar Metodologas de
Desarrollo de Software que ayuden a entregar un producto de calidad en tiempo y
costo estimados, las metodologas giles de desarrollo de software han despertado
inters gracias a que proponen simplicidad y velocidad para crear sistemas. Entre los
Elementos claves de los procesos giles de desarrollo tenemos:
-Anlisis como una actividad constante
-Simplicidad
-Poca documentacin
-Testeos diarios
-Integraciones
-Diseo evolutivo
Algunos mtodos giles de desarrollo de software:
Crystal Clear
Proceso Unificado de Rational (RUP)
Essential Unified Process (EssUP)
Feature Driven Development (FDD)
Introduccin al Modelado:
El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es
un lenguaje grfico para visualizar, especificar y documentar cada una de las partes
que comprende el desarrollo de software.
El Proceso Unificado es un marco de desarrollo de software que se caracteriza
por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e
incremental.
Caractersticas:
-Iterativo e Incremental
-Dirigido por los casos de uso
-Enfocado en los riesgos
-Centrado en la arquitectura
El Lenguaje de Modelado Unificado (UML)
Una exigencia de la gran mayora de instituciones dentro de su Plan Informtico
estratgico, es que los desarrollos de software bajo una arquitectura en Capas, se
formalicen con un lenguaje estndar y unificado.
Es decir, se requiere que cada una de las partes que comprende el desarrollo de todo
software de diseo orientado a objetos, se visualice, especifique y documente con
lenguaje comn.
Se necesitaba un lenguaje que fuese grfico, a fin de especificar y documentar un
sistema de software, de un modo estndar incluyendo aspectos conceptuales tales
como procesos de negocios y funciones del sistema.
Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el
cual cuenta con una notacin estndar y semnticas esenciales para el modelado de
un sistema orientado a objetos.
El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos
para expresar un diseo. El proceso indica los pasos que se deben seguir para llegar a
un diseo. La estandarizacin de un lenguaje de modelado es invaluable, ya que es la
parte principal del proceso de comunicacin que requieren todos los agentes
involucrados en un proyecto informtico. Si se quiere discutir un diseo con alguien
ms, ambos deben conocer el lenguaje de modelado y no as el proceso que se sigui
para obtenerlo.





Una de las metas principales de UML es avanzar en el estado de la integracin
institucional proporcionando herramientas de interoperabilidad para el modelado visual
de objetos. Sin embargo para lograr un intercambio exitoso de modelos de informacin
entre herramientas, se requiri definir a UML una semntica y una notacin.
La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del
lenguaje de modelado. Por ejemplo, la notacin del diagrama de clases define como
se representan los elementos y conceptos como son: una clase, una asociacin y una
multiplicidad.
El lenguaje est dotado de mltiples herramientas para lograr la especificacin
determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:
Moldeamiento de Clases
Casos de Uso
Diagrama de Interaccin



Un Diagrama es una representacin grfica de una coleccin de elementos de
modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vrtices
(otros elementos del modelo). Un diagrama no es un elemento semntico, un
diagrama muestra representaciones de elementos semnticos del modelo, pero su
significado no se ve afectado por la forma en que son representados.
Diagramas de UML:
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware,
Y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar
sistemas.
Diagramas de Casos de Uso para modelar los procesos business.
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboracin para modelar interacciones entre objetos.
Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos de Uso,
objetos u operaciones.
Diagramas de Clases para modelar la estructura esttica de las clases en el sistema.
Diagramas de Objetos para modelar la estructura esttica de los objetos en el
sistema.
Diagramas de Componentes para modelar componentes.
Moldeamiento de Clases
Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
contenimiento.
Un diagrama de clases est compuesto por los siguientes elementos:
Clase: atributos, mtodos y visibilidad.
Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.
Elementos
Clase
Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto
es una instancia de una clase). A travs de ella podemos modelar el entorno en
estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres divisiones:




En donde:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a
la Clase (pueden ser prvate, protected o public).
Inferior: Contiene los mtodos u operaciones, los cuales son la forma como
interacta el objeto con su entorno (dependiendo de la visibilidad: private, protected o
public).
Ejemplo:
Una Cuenta Corriente que posee como caracterstica:
Balance
Puede realizar las operaciones de:
Depositar
Girar
y Balance
El diseo asociado es





Atributos y Mtodos:
Atributos:
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que
definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son:
o public (+): Indica que el atributo ser visible tanto dentro como fuera de
la clase, es decir, es accesible desde todos lados.
o prvate (-): Indica que el atributo slo ser accesible desde dentro de la
clase (slo sus mtodos lo pueden accesar).
o protected (#): Indica que el atributo no ser accesible desde fuera de la
clase, pero si podr ser accesado por mtodos de la clase adems de las subclases
que se deriven (ver herencia).
Mtodos:
Los mtodos u operaciones de una clase son la forma en cmo sta interacta con su
entorno, stos pueden tener las caractersticas:
o Public (+): Indica que el mtodo ser visible tanto dentro como fuera de
la clase, es decir, es accesible desde todos lados.
o prvate (-): Indica que el mtodo slo ser accesible desde dentro de la
clase (slo otros mtodos de la clase lo pueden accesar).
o protected (#): Indica que el mtodo no ser accesible desde fuera de la
clase, pero si podr ser accesado por mtodos de la clase adems de mtodos de las
subclases que se deriven (ver herencia).
Relaciones entre Clases:
Ahora ya definido el concepto de Clase, es necesario explicar cmo se pueden
interrelacionar dos o ms clases (cada uno con caractersticas y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en
cada extremo de la relacin y stas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
nmero fijo: m (m denota el nmero).
nmero fijo: m (m denota el nmero).
i.Herencia (Especializacin/Generalizacin):
Indica que una subclase hereda los mtodos y atributos especificados por una Sper
Clase, por ende la Subclase adems de poseer sus propios mtodos y atributos,
poseer las caractersticas y atributos visibles de la Sper Clase (public y protected),
ejemplo:




En la figura se especifica que Auto y Camin heredan de Vehculo, es decir, Auto
posee las Caractersticas de Vehculo (Precio, VelMax, etc) adems posee algo
particular que es Descapotable, en cambio Camin tambin hereda las caractersticas
de Vehculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado,
Tara y Carga.
Cabe destacar que fuera de este entorno, lo nico "visible" es el mtodo
Caractersticas aplicable a instancias de Vehculo, Auto y Camin, pues tiene
definicin pblica, en cambio atributos como Descapotable no son visibles por ser
privados.
Agregacin:
Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer
objetos que son instancias de clases definidas por el desarrollador de la aplicacin,
tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del
objeto incluido est condicionado por el tiempo de vida del que lo incluye. Este tipo de
relacin es comnmente llamada Composicin(el Objeto base se construye a partir
del objeto incluido, es decir, es "parte/todo").
Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida
del objeto incluido es independiente del que lo incluye. Este tipo de relacin es
comnmente llamada Agregacin (el objeto base utiliza al incluido para su
funcionamiento).
Un Ejemplo es el siguiente :



En donde se destaca que:
Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee
las referencias).
Cuando se destruye el Objeto Almacn tambin son destruidos los objetos
Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
La composicin (por Valor) se destaca por un rombo relleno.
La agregacin (por Referencia) se destaca por un rombo transparente.
La flecha en este tipo de relacin indica la navegabilidad del objeto referenciado.
Cuando no existe este tipo de particularidad la flecha se elimina.
Asociacin:
La relacin entre clases conocida como Asociacin, permite asociar objetos que
colaboran entre s. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de
vida de un objeto no depende del otro.
Ejemplo:





Un cliente puede tener asociadas muchas rdenes de Compra, en cambio una orden
de compra solo puede tener asociado un cliente.
Dependencia o Instanciacin (uso):
Representa un tipo de relacin muy particular, en la que una clase es instanciada (su
instanciacin es dependiente de otro objeto/clase). Se denota por una flecha
punteada.
El uso ms particular de este tipo de relacin es para denotar la dependencia que
tiene una clase de otra, como por ejemplo una aplicacin grafica que instancia una
ventana (la creacin del Objeto Ventana est condicionado a la instanciacin
proveniente desde el objeto Aplicacin):



Cabe destacar que el objeto creado (en este caso la Ventana grfica) no se almacena
dentro del objeto que lo crea (en este caso la Aplicacin).
Casos Particulares:
Clase Abstracta:




Una clase abstracta se denota con el nombre de la clase y de los mtodos con letra
"itlica". Esto indica que la clase definida no puede ser instanciada pues posee
mtodos abstractos (an no han sido definidos, es decir, sin implementacin). La nica
forma de utilizarla es definiendo subclases, que implementan los mtodos abstractos
definidos.

Clase parametrizada:




Una clase parametrizada se denota con un subcuadro en el extremo superior de la
clase, en donde se especifican los parmetros que deben ser pasados a la clase para
que esta pueda ser instanciada. El ejemplo ms tpico es el caso de un Diccionario en
donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y
elementos pueden ser genricos.
Herramientas CASE
Son aplicaciones de tecnologa informtica a las actividades, las tcnicas y las
metodologas propias de desarrollo, su objetivo es acelerar el proceso para el que han
sido diseadas.

FUNDAMENTOS SOBRE LAS HERRAMIENTAS CASE
Trabajo en Grupo
Generador de Cdigo

Algunas Herramientas CASE
LucidChart, IdeogramicUML, SDMetrics, Visual UML, Web SequenceDiagrams, Dzine
Visio, With, Class
Herramientas CASE
De acuerdo con Kendall y Kendall la ingeniera de sistemas asistida por ordenador es
la aplicacin de tecnologa informtica a las actividades, lastcnicas y las
metodologas propias de desarrollo, su objetivo es acelerar el proceso para el que han
sido diseadas, en el caso de CASE para automatizar o apoyar una o mas fases
del ciclo de vida del desarrollo de sistemas.
Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de vida
de las aplicaciones de bases de datos, tambin se puede escoger una herramienta
CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de
tareas del modo ms eficiente y efectivo posible. Una herramienta CASE suele incluir:
Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin de
bases de datos.
Herramientas de diseo para dar apoyo al anlisis de datos.
Herramientas que permitan desarrollar el modelo de datos corporativo, as como los
esquemas conceptual y lgico.
Herramientas para desarrollar los prototipos de las aplicaciones.
Breve Introduccion al modelo OSI
Debido a un enorme de crecimiento en el ultimo siglo se han desarrollado nuevos tipos de HardWare y SoftWare, po rel
incansable y constante crecimiento de las redes en el mundo. Los nuevo SoftWare y HardWare son el resultado de la
incompatibildad de las redes antiguas, esto causaba que hubiera interferencias y pesima comunicacion entre ellas. Los
quesolucionaron este problema fueron la (iso) Organizacion Internacional para la Normalizacion, ellos realizaron y
esquematizaron las redes y poco a poco se fueron dando cuenta que era necesario crear una nueva topologia y un nuevo
modelo. Necesitaban un modelo que ayudara a los diseadores de redes y a las mismas redes a trabajar juntas trabajar en
grupo, de aqui salen todo lo que es la ayudan entre si mismode las capas del modelo OSI. En fin el modelo nace en el ao de
1984 con el nombre que tiene ahorita, es decir modelo OSI.

El modelo OSI lo que hace es permitir ver a todos los usuarios de la red ver el funcionamiento entre capa y capa, esto hace
que de tal manera nos facilite el conocimiento y de esta forma aprender como viaja todo dentro una red, las maneras de
comunicacion en ellas etx...Ademas de esto esl modelo OSI sirve para visualizar los datos, desde programas basicos de
aplicacion que usamos a diario atravez de una red.

Parecidos y No Parecidos del Modelo TCP/IP y Modelo OSI.

Uno de los pocos parecidos que conozco yo es que 4 de las capas del modelo TCP/IP llevan el mismo nombre de las capas del
Modelo Osi.
Capa de Red
Capa de Aplicacion
Capa de Internet
Capa deTransporte

Muchos novatos en el modelo OSI y el modelo TCP/IP las confunden, y esto no deberia de suceder, ya que las capas en el
modelo OSI trabajan en conjunto ayudandose la una a la otra de la la capa 7 a la capa 1. Mientras que en el modelo TCP/IP es
cada quien por si sola .
Otro parecido podria ser que ambos modelos son dividos en capas, apesar de que el modelo OSI tenga mas capas
que [continua] Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje
de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un
lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema
(modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un
sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el
modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodologa de desarrollo de software (tal como el
Proceso Unificado Racional o RUP), pero no especfica en s mismo qu metodologa o proceso usar.
UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se
diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la
orientacin a objetos, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para
lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
Diagramas
Diagramas de Gantt y Pert USO DE GRAFICAS DE GANTT PARA LA PROGRAMACION DE PROYECTOS. Una grfica de Gantt es
una forma fcil para calendarizar tareas. Es esencialmente una grfica en donde las barras representan cada tarea o actividad. La
longitud de cada barra representa la longitud relativa...
3726 Palabras15 Pginas
Simbologia diagramas de flujo
SIMBOLOGIA BASICA DIAGRAMAS DE FLUJO DIAGRAMA DE FLUJO: Un diagrama de flujo, es una representacin grfica de un
algoritmo. Su finalidad, es que se asimilen fcilmente, el proceso de flujo de los datos, la comprensin de problemas, y nos permite
realizar de forma breve la funcionalidad...
411 Palabras2 Pginas
Diagramas
Un circuito elctrico es una serie de elementos o componentes elctricos, tales como resistencias, inductancias, condensadores y
fuentes, o electrnicos, conectados elctricamente entre s con el propsito de generar, transportar o modificar seales elctricas.
Circuito elctrico es la t...
Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida porComputadora) son diversas aplicaciones
informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en trminos de tiempo y
de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de
realizar un diseo del proyecto, clculo de costos, implementacin de parte del cdigo automticamente con el diseo dado, compilacin
automtica, documentacin o deteccin de errores entre otras. Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje y por lo tanto un
producto que analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en cuestin
se denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem
Statement Analyzer).
Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos informticos, la primera herramienta CASE fue
Excelerator que sali a la luz en el ao 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM haba conseguido una alianza con la empresa
de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de
vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto
completamente abriendo el mercado de diversas herramientas ms especficas para cada fase del ciclo de vida del software.
El concepto de complejidad del case mix
El concepto de complejidad de la casustica parece muy sencillo a primera vista. Sin embargo, los mdicos, los directivos de hospitales y los responsables de la
Administracin sanitaria han asociado distintos significados a este concepto, dependiendo de sus experiencias previas y sus objetivos. El trmino de complejidad
del case mix se ha utilizado para referirse a un conjunto interrelacionado pero bien distinto de atributos de los pacientes que incluyen la gravedad de la enfermedad, su
pronstico, dificultad de tratamiento, necesidad de actuacin mdica e intensidad de consumo de recursos. Cada uno de estos atributos tiene un significado muy
preciso que describe un aspecto particular del case mix de un hospital.
La gravedad de la enfermedad se refiere al nivel relativo de prdida de funcin y/o ndice de mortalidad de los pacientes con una enfermedad determinada.
El pronstico se refiere a la evolucin probable de una enfermedad, incluyendo la posibilidad de mejora o deterioro de la gravedad de la misma, las posibilidades de
recada y la estimacin del tiempo de supervivencia.
La dificultad de tratamiento hace referencia a los problemas de atencin mdica que representan los pacientes que padecen una enfermedad en particular. Dichos
problemas de tratamiento se asocian a enfermedades sin un patrn sintomtico claro, enfermedades que requieren procedimientos sofisticados y tcnicamente difciles,
y enfermedades que necesitan de un seguimiento y supervisin continuados.
Necesidad de actuacin mdica se refiere a las consecuencias en trminos de gravedad de la enfermedad que podran derivarse de la falta de una atencin mdica
inmediata o continuada.
Intensidad de los recursos se refiere al nmero y tipos de servicios diagnsticos, teraputicos y de enfermera utilizados en el tratamiento de una enfermedad
determinada.
Cuando los mdicos utilizan el concepto complejidad de la casustica, se estn refiriendo a uno o a varios aspectos de la complejidad clnica. Para los mdicos, una
mayor complejidad del case mix significa una mayor gravedad de la enfermedad, mayor dificultad de tratamiento, peor pronstico o una mayor necesidad de actuacin
asistencial. Por lo tanto, desde un punto de vista mdico, la complejidad del case mix hace referencia a la situacin de los pacientes tratados y a la dificultad del
tratamiento asociada a la asistencia mdica.
Por otro lado, los directivos de hospitales y los responsables de la Administracin sanitaria suelen utilizar el concepto de complejidad del case mix para indicar que los
pacientes tratados precisan de ms recursos, lo que se traduce en un coste ms alto de la asistencia mdica. Por lo tanto, desde el punto de vista de los directivos y
administradores, la complejidad del case mix refleja la demanda de consumo de recursos que el paciente hace a una institucin.
Si bien estas dos interpretaciones de la complejidad del case mix estn a menudo muy relacionadas, pueden llegar a ser muy distintas para determinado tipo de
pacientes. Por ejemplo, los pacientes afectados por una neoplasia en fase terminal estn gravemente enfermos y tienen un mal pronstico, pero precisan de pocos
recursos hospitalarios ms all de unos cuidados de enfermera bsicos. Ningn sistema de medicin de la complejidad delcase mix puede ser totalmente eficaz a la
hora de considerar todos los diferentes aspectos de la complejidad de la casustica.
En tiempos pasados ha habido confusin con respecto al uso e interpretacin de los GRD puesto que el aspecto de la complejidad del case mix medido por los GRD no
se haba entendido bien. La finalidad de los GRD es relacionar la casustica del hospital con la demanda de recursos y costes asociados incurridos por el hospital. Por lo
tanto, un hospital que tenga una casustica ms compleja, desde el punto de vista de los GRD, significa que el hospital trata a pacientes que precisan de ms recursos
hospitalarios, pero no necesariamente que el hospital trate pacientes con enfermedades ms graves, con mayor dificultad de tratamiento, de peor pronstico o con una
mayor necesidad de actuacin mdica.
Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida porComputadora) son diversas aplicaciones
informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en trminos de tiempo y
de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de
realizar un diseo del proyecto, clculo de costos, implementacin de parte del cdigo automticamente con el diseo dado, compilacin
automtica, documentacin o deteccin de errores entre otras. Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje y por lo tanto un
producto que analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en cuestin
se denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem
Statement Analyzer).
Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos informticos, la primera herramienta CASE fue
Excelerator que sali a la luz en el ao 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM haba conseguido una alianza con la empresa
de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de
vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto
completamente abriendo el mercado de diversas herramientas ms especficas para cada fase del ciclo de vida del software.