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.
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 s, 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, deben 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 cmo se deben implementar.
Reusabilidad: La necesidad de la reutilizacin surge de la observacin de que los
sistemas software a menudo siguen patrones 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 utilizar 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 grficas 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 importancia, 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 tica 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
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
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
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
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
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
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
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
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)
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
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 caracterstica 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 de competencias: la competencia ACADMICA, la competencia
LABORAL y la competencia PROFESIONAL. Las competencias acadmicas son
responsabilidad de las instituciones educativas; las competencias laborales es el
aprendizaje con independencia del lugar en donde fue adquirido, muchos mexicanos ni
siquiera tuvieron la oportunidad determinar la primaria y a una edad temprana se
incorporaron al 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 taller mecnico y les deca "aqu le dej a mi hijo para qu haga de el un hombre" y
lo quitaban del sistema educativo. Ahora le llamamos TDAH, trastorno por dficit de
atencin por hiperactividad, pero seguimos sin entender que todos los seres humanos
tenemos capacidades diferentes. No nos podemos comportar de la misma forma en
ningn lugar, porque todos somos diferentes, todos percibimos diferentes, somos
nicos e irrepetibles, imagnense qu maravilla...
Componentes, tipos, caractersticas y reusabilidad de componentes


Tipos de componentes y caractersticas
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 Agente Analizado. 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 posibilidades 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...

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
El RUP est basado en 6 principios clave que son los siguientes: Adaptar el
proceso 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
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
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
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
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
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


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
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
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
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
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
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:
Public (+): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.
prvate (-): Indica que el mtodo slo ser accesible desde dentro de la clase (slo
otros mtodos de la clase lo pueden accesar).
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.