REPBLICA BOLIVARIANA DE VENEZUELA

ALDEA UNIVERSITARIA
REPUBLICA ARGENTINA
CUMAN-EDO-SUCRE

Ingeniera Del Software

Integrantes:
Mrquez Fanny
Andrades Gnesis

Cuman, Junio de 2015

INTRODUCCIN
La Ingeniera del Software es la rama de la ingeniera que crea y mantiene
las aplicaciones de software usando tecnologas y prcticas de las ciencias de la
computacin, manejo de proyectos, ingeniera, el mbito de la aplicacin, y otros
campos. Hay quienes opinan que este proceso debera de llamarse "Desarrollo del
Software" frente a Ingeniera del Software. "software es la suma total de los
programas de ordenador, procedimientos, reglas, la documentacin asociada y los
datos que pertenecen a un sistema de cmputo" y "un producto de software es un
producto diseado para un usuario".
Su origen se debi a que el entorno de desarrollo de sistemas software
adoleca de:
o Retrasos considerables en la planificacin
o Poca productividad
o Elevadas cargas de mantenimiento
o Demandas cada vez ms desfasadas frente a las ofertas
o Baja calidad y fiabilidad del producto
o Dependencia de los realizadores

EL SOFTWARE
Estos son los programas informticos que hacen posible la realizacin de
tareas especficas dentro de un computador. Por ejemplo Word, Excel,
PowerPoint, los navegadores web, los juegos, los sistemas operativos, etc.
Se considera que el software es el equipamiento lgico e intangible de
un ordenador. En otras palabras, el concepto de software abarca a todas
las aplicaciones informticas, como los procesadores de textos, las planillas de
clculo y los editores de imgenes.
El software es desarrollado mediante distintos lenguajes de
programacin, que permiten controlar el comportamiento de una mquina. Estos
lenguajes consisten en un conjunto de smbolos y reglas sintcticas y semnticas,
que definen el significado de sus elementos y expresiones. Un lenguaje de
programacin permite a los programadores del software especificar, en forma
precisa, sobre qu datos debe operar una computadora.

CUALIDADES DEL SOFTWARE

Las cualidades del software son: Robustez, correccin, eficiencia,
amabilidad,extensibilidad, claridad,flexibilidad,mantenibilidad,consistencia, simplici
dad, completud, escalabilidad, encapsulamiento, abstraccin, generosidad,
reusabilidad, seguridad, utilidad.

Un software es robusto cuando funciona en forma razonable an en

situaciones no anticipadas.

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 eficiente si usa sus recursos en forma econmica.

Un software es amigable si sus usuarios lo encuentran fcil de utilizar.

Un software es extensible cuando pueden incorporarse nuevas

caractersticas al mismo sin mayor impacto sobre las caractersticas actuales.

Un software es flexible cuando tiene la capacidad para reflejar cambios

percibidos en el dominio de una manera simple y sencilla.

Un software es ms mantenible cuanto menor esfuerzo requiere para que

el sistema siga funcionando en condiciones distintas a las originales e incluso en
las originales.

Un software es consistente cuando sistema se comportar siempre de la

misma manera ante un mismo evento y las tareas similares deben poder
realizarse siguiendo pasos similares.

Un software es simple cuando tanto como en la interfaz como en la

implementacin es simple. Es ms importante la simplicidad en la interfaz que en
la implementacin.

Un software es completo cuando cuando contempla todas las posibles

situaciones a darse en la prctica.

Un software practica el encapsulamiento para poder agrupar unidades

funcionales me permite que el sistema sea cohesivo, reduciendo la complejidad
del sistema y aumentando en cierta forma su flexibilidad.

Un software es con escalabilidad da facilidad de un sistema pensando

originalmente en una carga determinada. Puede ser adaptado para soportar una
carga mayor.

FACTORES DE CALIDAD DEL SOFTWARE

La calidad del software. La obtencin de un software con calidad implica la
utilizacin de metodologas o procedimientos estndares para el anlisis, diseo,
programacin y prueba del software que permitan uniformar la filosofa de trabajo,
en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a
la vez que eleven la productividad, tanto para la labor de desarrollo como para el
control de la calidad del software.

Los requisitos del software son la base de las medidas de calidad. La falta
de concordancia con los requisitos es una falta de calidad.
Los estndares o metodologas definen un conjunto de criterios de
desarrollo que guan la forma en que se aplica la ingeniera del software. Si no se
sigue ninguna metodologa siempre habr falta de calidad.
Existen algunos requisitos implcitos o expectativas que a menudo no se
mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un
buen mantenimiento) que tambin pueden implicar una falta de calidad.
La poltica establecida debe estar sustentada sobre tres principios bsicos:
tecnolgico, administrativo y ergonmico.
El principio tecnolgico define las tcnicas a utilizar en el proceso de
desarrollo del software.
El principio administrativo contempla las funciones de planificacin y control
del desarrollo del software, as como la organizacin del ambiente o centro de
ingeniera de software.
El principio ergonmico define la interfaz entre el usuario y el ambiente
automatizado.
La adopcin de una buena poltica contribuye en gran medida a lograr la
calidad del software, pero no la asegura. Para el aseguramiento de la calidad es
necesario su control o evaluacin.
A partir del siguiente grfico se observa la interrelacin existente entre la
Gestin de la Calidad, el Aseguramiento de la Calidad y el Control de la Calidad.

Los factores que determinan la calidad del software se clasifican en tres

grupos:
o
Operaciones del producto: caractersticas operativas

Correccin: Grado en que un programa satisface sus especificacin y

logra los objetivos marcados por el usuario. (Hace lo que se le pide?).

Fiabilidad: Grado en que se puede esperar que un programa lleve a cabo

las funciones esperadas con la precisin requerida. (Lo hace de forma fiable todo
el tiempo?).

Eficiencia: Cantidad de recursos de computadoras y de cdigo requeridos

por el programa para realizar sus funciones con los tiempos de respuesta
adecuados. (Qu recursos hardware y software necesito?).

Integridad: Grado en que puede controlarse el acceso al software o a los

datos por usuarios no autorizados. (Puedo controlar su uso?).

Facilidad de uso: Esfuerzo necesario para aprender, utilizar, preparar las

entradas e interpretar las salidas de un programa. (Es fcil y cmodo de
manejar?).

Revisin del producto: capacidad para soportar cambios.

Facilidad de mantenimiento: Esfuerzo requerido para localizar y arreglar

un error en un programa. (Puedo localizar los fallos?).

Flexibilidad: Esfuerzo requerido para modificar un programa. (Puedo

aadir nuevas opciones?).

Facilidad de prueba: Esfuerzo requerido para probar un programa de

forma que se asegure que realiza la funcin requerida. (Puedo probar todas las
opciones?).

Transicin del producto: adaptabilidad a nuevos entornos.

Portabilidad: Esfuerzo requerido para transferir un programa desde un

entorno HW y/o SW a otro. (Podr usarlo en otra mquina?).

Reusabilidad: Grado en que un programa o componente SW se puede

reutilizar en otras aplicaciones. (Podr utilizar alguna parte del software en otra
aplicacin?).

Interoperatividad: Esfuerzo requerido para acoplar un sistema con otras

aplicaciones o sistemas. (Podr comunicarse con otras aplicaciones o sistemas
informticos?).

INGENIERA DEL 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. Integra matemticas, ciencias
de la computacin y prcticas cuyos orgenes se encuentran en la ingeniera.

VISIN GENERAL DEL PROCESO DEL DESARROLLO DEL 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

Todos sabemos que cuanto mayor sea la ayuda de los usuarios en un

proyecto de desarrollo de software, mayores sern las probabilidades de xito que
tenga el mismo.
No obstante es importante hacer algunas matizaciones:
1) El proyecto no se hace slo, porque incluso existiendo una gran ayuda por parte
de los usuarios, si no se consigue interpretar con precisin lo que quieren y no se
dinamiza un feedback continuo de los mismos durante todo el proceso de
desarrollo, se incrementarn las posibilidades de que algn requisito funcional no
se haya recogido adecuadamente o de que se haya realizado un software con una
usabilidad incmoda para los usuarios.
Estas circunstancias son fuente de innumerables problemas en las fases
finales del proyecto y provocan retrasos, sobrecostes y grandes dificultades para
cerrar el proyecto, adems de crear conflictos con el cliente que pueden perjudicar
las relaciones futuras con el mismo. Esto hace que sea fundamental el papel que
desempean tanto el jefe de proyectos, como el equipo de analistas funcionales y
analistas programadores.
2) Es importante que entre el grupo usuarios asignados al proyecto haya usuarios
que vayan a estar implicados en el futuro uso del sistema de informacin, es decir,
no es suficiente que el equipo de usuarios est formado por idelogos o
tericos que se nutrirn del resultado del trabajo de la herramienta, sino que es
fundamental que participen usuarios que despus se tengan que poner el mono de
trabajo y vayan a trabajar con el software. Es importante conseguir la combinacin
de ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios no
participen usuarios directores, ya que pueden existir conflictos entre usuarios que
stos deben solucionar y tambin es recomendable que el software no slo se
disee para el corto plazo, sino que sirva para tareas de gestin, planificacin,
etc y esta visin la proporcionan principalmente los usuarios directores), por lo
que el jefe de proyectos debe poner en conocimiento del cliente esta necesidad,
como es lgico explicando los riesgos de que no se aplique esta estrategia.
3) Los analistas estn para ayudar y para colaborar con los usuarios en la
especificacin y diseo de la solucin, pero no estn para dar lecciones a los
usuarios y ensearle cmo deben hacer su trabajo. Si los usuarios hacen su
trabajo de una determinada manera, aunque no sea la ms ortodoxa, siempre
tendr una justificacin que slo se entendera si realmente estuviramos
haciendo su trabajo durante un tiempo y viramos los problemas con los que se
enfrentan cotidianamente. La clave por tanto est en la colaboracin y en el

dilogo, es decir, se pueden proponer cosas al usuario, se le pueden dar ideas,

pero no se le puede dar una vuelta al calcetn de cmo hacen sus tareas, salvo
que ellos mismos lo soliciten y procurando en estos casos y en consenso con los
usuarios que los cambios sean tranquilos.
4) Es fundamental documentar el proyecto, en primer lugar con la documentacin
que se especifique en las normativas de desarrollo de la organizacin para la que
se realiza el servicio, con las matizaciones que indique el Director del Proyecto, en
segundo lugar con la documentacin que establezcan las normativas internas de
calidad de tu organizacin (no requerir un sobreesfuerzo, ya que en la mayor
parte de los casos coincidir) y a todo lo anterior sumarle toda la documentacin
de trabajo que sea necesaria para trabajar con los usuarios, que no tienen por qu
entender de modelos de datos, de diagramas de casos de uso, etc, es ms, es
un error trabajar con los usuarios utilizando dichas herramientas, ya que estas son
de utilidad tcnica y no hablan el mismo lenguaje de los usuarios. Este tipo
documentacin, por tanto, no tiene por qu tener los formalismos de la tcnica y
tiene como objetivo que el usuario capte lo que el analista est interpretando y se
pueda ir perfilando a partir de esto, tanto requisitos, como casos de uso,
interfaces, etc Es muy importante trabajar todo esto, ya que comenzar
demasiado pronto con la construccin, es algo muy arriesgado, ya que los costes
de modificar algo en las distintas fases de la construccin pueden ser muy
importantes y provocar que se tengan que reconstruir varias veces distintas
funcionalidades de la aplicacin.

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 estas
son:

Confidencialidad. Respetar la confidencialidad de sus empleadores o

clientes, independientemente de que se haya firmado un acuerdo formal de
confidencialidad.
o Competencia. No debe falsificar su nivel de competencia, ni aceptar
conscientemente trabajos que estn fuera de su capacidad.
o Derechos de propiedad intelectual. Debe ser consciente de las leyes
locales que gobiernan el uso de la propiedad intelectual, como las patentes
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 las mquina de un empleado,
por ejemplo) hasta los extremadamente serios (difusin de virus).
o

Cdigo de tica (ACM/IEEE)

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

en
de
su
de

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 del
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

Al igual que en otros sistemas de ingeniera, los sistemas de software
requieren un tiempo y esfuerzo considerable para su desarrollo y deben
permanecer en uso por un periodo mucho mayor. Durante este tiempo de
desarrollo y uso, desde que se detecta la necesidad de construir un sistema de
software hasta que este es retirado, se identifican varias etapas que en conjunto
se denominan el ciclo de vida del software y en cada caso, en funcin de cuales
sean las caractersticas del proyecto, se configurar el ciclo de vida de forma
diferente. Usualmente se consideran las etapas: especificacin y anlisis de
requisitos, diseo del sistema, implementacin del software, aplicacin y pruebas,
entrega y mantenimiento. Un aspecto esencial dentro de las tareas del desarrollo
del software es la documentacin de todos los elementos y especificaciones en
cada fase. Dado que esta tarea siempre estar influida por la fase del desarrollo
en curso, se explicar de forma distribuida a lo largo de las diferentes fases como
un apartado especial para recalcar su importancia en el conjunto del desarrollo del
software.
Tal como ya hemos mencionado, las etapas principales a realizar en cualquier
ciclo de vida son:

Anlisis: Construye un modelo de los requisitos

Diseo: A partir del modelo de anlisis se deducen las estructuras de datos, la
estructura en la que descompone el sistema y la interfaz de usuario.
Codificacin: Construye el sistema. La salida de esta fase es cdigo ejecutable.
Pruebas: Se comprueba que se cumplen criterios de correccin y calidad.
Validacin: es el proceso de comprobar que lo que se ha especificado es lo que
el usuario realmente quera.
Mantenimiento: En esta fase, que tiene lugar despus de la entrega se asegura
que el sistema siga funcionando y adaptndose a nuevos requisitos.
PRINCIPIOS
MODELOS,
MTODOS,
METODOLOGA,
TCNICAS,
ACTIVIDADES Y HERRAMIENTAS EN EL PROCESO DE DESARROLLO DEL
SOFTWARE
MODELOS DE DESARROLLO DE SOFTWARE
Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las
cuales cuenta con pros y contras. El proyecto debera escoger el ms apropiado
para sus necesidades. En ocasiones puede que una combinacin de varios
modelos sea apropiado.

Modelo de cascada
El modelo de cascada muestra un proceso donde los desarrolladores han
de seguir las siguientes fases de forma sucesiva:

Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza

una fase, comienza la otra. En ocasiones se realiza una revisin antes de iniciar la
siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un
proceso de control formal de cambio). Las revisiones tambin se utilizan para
asegurar que la fase anterior ha sido totalmente finalizada; los criterios para
completar una fase se conocen frecuentemente con el trmino ingls "gate"
(puerta). Este modelo desaconseja revisitar y revisar fases que ya se han
completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente
de crtica de los defensores de modelos ms flexibles.
Modelo De Espiral
La principal caractersticas del modelo en espiral es la gestin de riesgos de
forma peridica en el ciclo de desarrollo. Este modelo fue creado en 1988 por
Barry Boehm, combinando algunos aspectos clave de las metodologas del
modelo de cascada y del desarrollo rpido de aplicaciones, pero dando nfasis en
un rea que para muchos no jug el papel que requiere en otros modelos: un
anlisis iterativo y concienzudo de los riesgos, especialmente en el caso de
sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a travs de algunas
iteraciones con el diagrama de los cuatro cuadrantes representativos de las
siguientes actividades:
Crear planes con el propsito de identificar los objetivos del software,
seleccionados para implementar el programa y clarificar las restricciones en el
desarrollo del software; Anlisis de riesgos: una evaluacin analtica de programas
seleccionados, para evaluar cmo identificar y eliminar el riesgo; la
implementacin del proyecto: implementacin del desarrollo del software y su

pertinente verificacin; Modelo de espiral con nfasis en los riesgos, haciendo

hincapi en las condiciones de las opciones y limitaciones para facilitar la
reutilizacin de software, la calidad del software puede ayudar como una meta
propia en la integracin en el desarrollo del producto. Sin embargo, el modelo en
espiral tiene algunas limitaciones, entre las que destacan:
El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes
que acepten este anlisis y acten en consecuencia. Para ello es necesaria
confianza en los desarrolladores as como la predisposicin a gastar ms para
solventar los temas, por lo cual este modelo se utiliza frecuentemente en
desarrollo interno de software a gran escala.
Si la implementacin del riesgo de anlisis afectar de forma esencial los
beneficios del proyecto, no debera utilizarse este modelo.
Los desarrolladores de software han de buscar de forma explcita riesgos y
analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la bsqueda de un plan para conseguir los objetivos con
las limitaciones del proyecto para as buscar y eliminar todos los riesgos
potenciales por medio de un cuidadoso anlisis, y si fuera necesario incluyendo la
fabricacin de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha
de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los
riesgos. Por ltimo, se evalan los resultados y se inicia el diseo de la siguiente
fase.

Desarrollo Iterativo E Incremental

El desarrollo iterativo recomienda la construccin de secciones reducidas
de software que irn ganando en tamao para facilitar as la deteccin de
problemas de importancia antes de que sea demasiado tarde. Los procesos

iterativos pueden ayudar a desvelar metas del diseo en el caso de clientes que
no saben cmo definir lo que quieren.
Desarrollo gil
El desarrollo gil de software utiliza un desarrollo iterativo como base para
abogar por un punto de vista ms ligero y ms centrado en las personas que en el
caso de las soluciones tradicionales. Los procesos giles utilizan retroalimentacin
en lugar de planificacin, como principal mecanismo de control. La
retroalimentacin se canaliza por medio de pruebas peridicas y frecuentes
versiones del software.
Hay muchas variantes de los procesos giles:
En el caso de la programacin extrema (XP), las fases se realizan en pasos
muy cortos (o "continuos") con respecto al anterior. El primer paso
(intencionalmente incompleto) por los pasos puede ocurrir en un da o en una
semana, en lugar de los meses o aos de cada paso completo en el modelo en
cascada. En primer lugar, se crean pruebas automatizadas para proveer metas
concretas al desarrollo. Despus se programa el cdigo, que ser completo
cuando todas las pruebas se superan sin errores, y los desarrolladores ya no
sabran cmo mejorar el conjunto de pruebas necesario. El diseo y la arquitectura
emergen a partir de la refactorizacin del cdigo, y se da despus de programar.
El diseo lo realizan los propios desarrolladores del cdigo. El sistema,
incompleto, pero funcional se despliega para su demostracin a los usuarios (al
menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto,
los profesionales comienzan a escribir las pruebas para la siguiente parte del
sistema de ms importancia.

Modelo De Codificacin Y Correccin

El desarrollo de codificacin y correccin (en ingls "Code and fix") es, ms
que una estrategia predeterminada, el resultado de una falta de experiencia o
presin que se ejerce sobre los desarrolladores para cumplir con una fecha de

entrega.2 Sin dedicar tiempo de forma explcita para el diseo, los programadores
comienzan de forma inmediata a producir cdigo. Antes o despus comienza la
fase de pruebas de software (a menudo de forma tarda) y los inevitables errores
que se encuentran han de eliminarse antes de poder entregar el software.
Modelos De Mejora De Procesos
El Capability Maturity Model Integration (CMMI), en espaol Integracin de
Modelos de Madurez de Capacidades es uno de los modelos lderes basados en
mejores prcticas. Son evaluaciones independientes las que confirman el grado
con el que una organizacin siguen sus propios procesos, que no evala la calidad
de los procesos o del software que se produce. CMMI ha reemplazado a CMM y
tiene un mbito global, no slo en procesos destinados al desarrollo del software.
ISO 9000
ISO 9000 describe estndares para un proceso organizado formalmente
para resultar en un producto y los mtodos de gestin y monitoreo del progreso.
Aunque este estndar se cre inicialmente para el sector de produccin, los
estndares de ISO 9000 tambin se han aplicado al desarrollo del software. Al
igual que CMMI, que una organizacin est certificada con el ISO 9000 no
garantiza la calidad del resultado final, slo confirma que se ha seguido los
procesos establecidos.
ISO 15504
ISO 15504, tambin conocido como Software Process Improvement
Capability Determination (SPICE), en espaol Determinacin de la Capacidad de
Mejora del Proceso de Software es un marco para la evaluacin de procesos de
software. Este estndar tiene como objetivo un modelo claro para poder comparar
procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para
gestionar, controlar, guiar y monitorear el desarrollo del software. Este modelo se
utiliza entonces para medir lo que una organizacin o proyecto hace durante el
desarrollo del software. Esta informacin se analiza para identificar puntos dbiles
y definir acciones para subsanarlos. Tambin identifica puntos fuertes que pueden
adoptarse en el resto de la organizacin.
MTODOS EN EL PROCESO DE DESARROLLO DE UN SOFTWARE.
Los mtodos formales son soluciones matemticas para resolver problemas
de software y hardware a nivel de requisitos, especificacin y diseo. Ejemplos de
mtodos formales incluyen el Mtodo B, la red de Petri, la demostracin

automtica de teoremas, RAISE y el VDM. Hay varias notaciones de

especificaciones formales, tales como el lenguaje Z. Ms generalmente, se puede
utilizar la teora de autmatas para aumentar y validar el comportamiento de la
aplicacin diseando un sistema de autmata finito.
Las metodologas basadas en los autmatas finitos permiten especificacin
de software ejecutable y evitar la creacin convencional de cdigo.
Los mtodos formales se suelen aplicar en software de aviacin,
especialmente si es software de seguridad crtico. Los estndares de
aseguramiento del software de seguridad, tales como DO178B demandan
mtodos formales en el nivel ms alto de categorizacin (Nivel A).
La formalizacin del desarrollo de software est ganando en fuerza poco a
poco, en otros mbitos, con la aplicacin del lenguaje de especificacin OCL2.0 (y
especializaciones tales como Java Modeling Language) y particularmente con
Model-driven Architecture, que permite la ejecucin de diseos, incluso
especificaciones.
Otra tendencia que est surgiendo en el desarrollo de software es la
redaccin de especificaciones en algn tipo de lgica (normalmente una variacin
de FOL), para acto seguido ejecutar esa lgica como si se tratase de un programa.
El lenguaje OWL, basado en lgica descriptiva, es un buen ejemplo. Tambin se
est trabajando en enlazar un idioma natural de forma automtica con lgica,
lgica que puede ejecutarse. Ejemplo en este campo es el Attempto Controlled
English, una lgica de negocios de Internet, que no busca controlar el vocabulario
o la sintaxis. Una caractersticas de los sistemas que apoyan el vnculo
bidireccional ingls-lgica y ejecucin directa de la lgica es que pueden explicar
sus resultados en ingls en un nivel de negocios o cientfico.
METODOLOGAS PARA EL DESARROLLO DEL SOFTWARE
Un proceso de software detallado y completo suele denominarse
Metodologa. Las metodologas se basan en una combinacin de los modelos de
proceso genricos (cascada, evolutivo, incremental, etc.). Adicionalmente una
metodologa debera definir con precisin los artefactos, roles y actividades
involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin
de la metodologa al proyecto, guas para uso de herramientas de apoyo, etc.
Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y
guas asociadas, que son aplicables a una (o algunas) actividades del proceso de
desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo.

La comparacin y/o clasificacin de metodologas no es una tarea sencilla

debido a la diversidad de propuestas y diferencias en el grado de detalle,
informacin disponible y alcance de cada una de ellas. A grandes rasgos, si
tomamos como criterio las notaciones utilizadas para especificar artefactos
producidos en actividades de anlisis y diseo, podemos clasificar las
metodologas en dos grupos: Metodologas Estructuradas y Metodologas
Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo,
aquellas metodologas con mayor nfasis en la planificacin y control del proyecto,
en especificacin precisa de requisitos y modelado, reciben el apelativo de
Metodologas Tradicionales (o peyorativamente denominada Metodologas
Pesadas, o Peso Pesado). Otras metodologas, denominadas Metodologas
giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de
desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi
en aspectos humanos asociados al trabajo en equipo e involucran activamente al
cliente en el proceso.

ACTIVIDADES EN EL PROCESO DEL DESARROLLO DEL SOFTWARE

o

Planificacin.

Implementacin.

Pruebas del software.

Documentacin.

Entrenamiento.

Despliegue

Mantenimiento del software.

HERRAMIENTAS PARA EL DESARROLLO DE SOFTWARE
Las Herramientas de Ayuda al Desarrollo de Sistemas de Informacin,
surgieron para intentar dar solucin a los problemas inherentes a los proyectos de

generacin de aplicaciones informticas: plazos y presupuestos incumplidos,

insatisfaccin del usuario, escasa productividad y baja calidad de los desarrollos.
Algunas de estas herramientas se dirigen principalmente a mejorar la calidad,
como es el caso de las herramientas CASE (Computer Aided Software
Engineering-Ingeniera de Software Asistida por Ordenador). Otras van dirigidas a
mejorar la productividad durante la fase de construccin, como es el caso de los
lenguajes de cuarta generacin (4GL-Fourth Generation Language).
Herramientas Para Disear Software
Existe al menos 20 herramientas libres para disear software totalmente libre.
Todas utilizan la notacin UML
El nivel de avance entre una y otra es notable, casi todas ofrecen como
funcionalidad:
Diagramas de caso de uso.
Diagramas de clases.
Diagramas de secuencia.
Generacin de cdigo en java, c++, python y php.
Algunas entidad-relacin (pero ninguna lo suficientemente avanzada)
Pocas herramientas permiten ingeniera reversa, y si lo hacen solo es de
lenguajes tipo java o c++.

TCNICAS PARA EL DESARROLLO DE SOFTWARE

o

La recoleccin de datos es una tcnicas y herramientas que pueden ser

utilizadas por el analista para desarrollar los sistemas de informacin, los cuales
pueden ser la entrevistas, la encuesta, el cuestionario, la observacin, el diagrama
de flujo y el diccionario de datos.

El anlisis de costo-beneficio es una tcnica analtica que enumera y

compara el costo neto de una intervencin con los beneficios que surgen como
consecuencia de aplicar dicha intervencin. Para esta tcnica, los costos y los
beneficios de la intervencin se expresan en unidades monetarias.

SELECCIN DEL MODELO APROPIADO SEGN LAS CARACTERSTICAS 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 de 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.

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 s 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.
o
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.
o

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.
Fundamento 2: Encapsulamiento
Es la propiedad del EOO que permite ocultar al mundo exterior la
representacin interna del objeto. Esto quiere decir que el objeto puede ser
utilizado, pero los datos esenciales del mismo no son conocidos fuera de l. La
idea central del encapsulamiento es esconder los detalles y mostrar lo relevante.
Permite el ocultamiento de la informacin separando el aspecto correspondiente a
la especificacin de la implementacin; de esta forma, distingue el "qu hacer" del
"cmo hacer". La especificacin es visible al usuario, mientras que la
implementacin se le oculta. El encapsulamiento en un sistema orientado a objeto
se representa en cada clase u objeto, definiendo sus atributos y mtodos con los
siguientes modos de acceso:

Pblico (+): Atributos o Mtodos que son accesibles fuera de la clase.

Pueden ser llamados por cualquier clase, aun si no est relacionada con ella.

Privado (-): Atributos o Mtodos que solo son accesibles dentro de la

implementacin de la clase.

Protegido (#): Atributos o Mtodos que son accesibles para la propia

clase y sus clases hijas (subclases).
Los atributos y los mtodos que son pblicos constituyen la interfaz de la
clase, es decir, lo que el mundo exterior conoce de la misma. Normalmente lo
usual es que se oculten los atributos de la clase y solo sean visibles los mtodos,
incluyendo entonces algunos de consulta para ver los valores de los atributos. El
mtodo constructor (Nuevo, New) siempre es Pblico.
Fundamento 3: Modularidad
Es la propiedad que permite tener independencia entre las diferentes partes
de un sistema. La modularidad consiste en dividir un programa en mdulos o
partes, que pueden ser compilados separadamente, pero que tienen conexiones
con otros mdulos. En un mismo mdulo se suele colocar clases y objetos que
guarden una estrecha relacin. El sentido de modularidad est muy relacionado
con el ocultamiento de informacin.
Fundamento 4: Herencia
Es el proceso mediante el cual un objeto de una clase adquiere
propiedades definidas en otra clase que lo preceda en una jerarqua de
clasificaciones. Permite la definicin de un nuevo objeto a partir de otros,
agregando las diferencias entre ellos (Programacin Diferencial), evitando
repeticin de cdigo y permitiendo la reusabilidad.
Las clases heredan los datos y mtodos de la superclase. Un mtodo
heredado puede ser sustituido por uno propio si ambos tienen el mismo nombre.
La herencia puede ser simple (cada clase tiene slo una superclase) o mltiple
(cada clase puede tener asociada varias superclases). La clase Docente y la clase
Estudiante heredan las propiedades de la clase Persona (superclase, herencia
simple). La clase Preparador (subclase) hereda propiedades de la clase Docente y
de la clase Estudiante (herencia mltiple).
Fundamento 5: Polimorfismo
Es una propiedad del EOO que permite que un mtodo tenga mltiples
implementaciones, que se seleccionan en base al tipo objeto indicado al solicitar la

ejecucin del mtodo. El polimorfismo operacional o Sobrecarga operacional

permite aplicar operaciones con igual nombre a diferentes clases o estn
relacionados en trminos de inclusin. En este tipo de polimorfismo, los mtodos
son interpretados en el contexto del objeto particular, ya que los mtodos con
nombres comunes son implementados de diferente manera dependiendo de cada
clase.
Por ejemplo, el rea de un cuadrado, rectngulo y crculo, son calculados
de manera distinta; sin embargo, en sus clases respectivas puede existir la
implementacin del rea bajo el nombre comn rea. En la prctica y
dependiendo del objeto que llame al mtodo, se usar el cdigo correspondiente.
Ejemplos:
Superclase: Clase Animal
Subclases: Clases Mamfero, Ave, Pez.
Se puede definir un mtodo Comer en cada subclase, cuya implementacin
cambia de acuerdo a la clase invocada, sin embargo el nombre del mtodo es el
mismo.
Mamifero.Comer Ave.Comer Pez.Comer
Otro ejemplo de polimorfismo es el operador +. Este operador tiene dos
funciones diferentes de acuerdo al tipo de dato de los operandos a los que se
aplica. Si los dos elementos son numricos, el operador + significa suma
algebraica de los mismos, en cambio si por lo menos uno de los operandos es un
String o Carcter, el operador es la concatenacin de cadenas de caracteres.
CARACTERSTICAS DEL ENFOQUE ORIENTADO A OBJETOS.

Las caractersticas siguientes son las ms importantes:

Abstraccin: Denota las caractersticas esenciales de un objeto, donde se
capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de
un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y
"comunicarse" con otros objetos en el sistema sin revelar cmo se implementan
estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin
ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para
ampliar una abstraccin. El proceso de abstraccin permite seleccionar las
caractersticas relevantes dentro de un conjunto e identificar comportamientos
comunes para definir nuevos tipos de entidades en el mundo real. La abstraccin
es clave en el proceso de anlisis y diseo orientado a objetos, ya que mediante
ella podemos llegar a armar un conjunto de clases que permitan modelar la
realidad o el problema que se quiere atacar.
Encapsulamiento: Significa reunir a todos los elementos que pueden
considerarse pertenecientes a una misma entidad, al mismo nivel de abstraccin.

Esto permite aumentar la cohesin de los componentes del sistema. Algunos

autores confunden este concepto con el principio de ocultacin, principalmente
porque se suelen emplear conjuntamente.

Modularidad: Se denomina Modularidad a la propiedad que permite

subdividir una aplicacin en partes ms pequeas (llamadas mdulos), cada una
de las cuales debe ser tan independiente como sea posible de la aplicacin en s y
de las restantes partes. Estos mdulos se pueden compilar por separado, pero
tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes
soportan la Modularidad de diversas formas.

Principio de ocultacin: Cada objeto est aislado del exterior, es un

mdulo natural, y cada tipo de objeto expone una interfaz a otros objetos que
especfica cmo pueden interactuar con los objetos de la clase. El aislamiento
protege a las propiedades de un objeto contra su modificacin por quien no tenga
derecho a acceder a ellas, solamente los propios mtodos internos del objeto
pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar
el estado interno de un objeto de maneras inesperadas, eliminando efectos
secundarios e interacciones inesperadas. Algunos lenguajes relajan esto,
permitiendo un acceso directo a los datos internos del objeto de una manera
controlada y limitando el grado de abstraccin. La aplicacin entera se reduce a un
agregado o rompecabezas de objetos.

Polimorfismo: Comportamientos diferentes, asociados a objetos distintos,

pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizar el
comportamiento correspondiente al objeto que se est usando. O dicho de otro
modo, las referencias y las colecciones de objetos pueden contener objetos de
diferentes tipos, y la invocacin de un comportamiento en una referencia producir
el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto
ocurre en "tiempo de ejecucin", esta ltima caracterstica se llama asignacin
tarda o asignacin dinmica. Algunos lenguajes proporcionan medios ms
estticos (en "tiempo de compilacin") de polimorfismo, tales como las plantillas y
la sobrecarga de operadores de C++.

Herencia: Las clases no estn aisladas, sino que se relacionan entre s,

formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el
comportamiento de todas las clases a las que pertenecen. La herencia organiza y
facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser
definidos y creados como tipos especializados de objetos preexistentes. Estos
pueden compartir (y extender) su comportamiento sin tener que volver a
implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases
y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un
objeto hereda de ms de una clase se dice que hay herencia mltiple.

Recoleccin de basura: La recoleccin de basura o garbage collector es la

tcnica por la cual el entorno de objetos se encarga de destruir automticamente,
y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin
ninguna referencia a ellos. Esto significa que el programador no debe preocuparse
por la asignacin o liberacin de memoria, ya que el entorno la asignar al crear
un nuevo objeto y la liberar cuando nadie lo est usando. En la mayora de los
lenguajes hbridos que se extendieron para soportar el Paradigma de
Programacin Orientada a Objetos como C++ u Object Pascal, esta caracterstica
no existe y la memoria debe desasignarse manualmente.
COMPONENTES
OBJETOS.

FUNDAMENTALES

DEL

ENFOQUE

ORIENTADO

Clase: Definiciones de las propiedades y comportamiento de un tipo de

objeto concreto. La instanciacin es la lctura de estas definiciones y la creacin de
un objeto a partir de ellas.

Herencia: (Por ejemplo, herencia de la clase C a la clase D) Es la facilidad

mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones
de C, como si esos atributos y operaciones hubiesen sido definidos por la misma
D. Por lo tanto, puede usar los mismos mtodos y variables publicas declaradas
en C. Los componentes registrados como "privados" (private) tambin se heredan,
pero como no pertenecen a la clase, se mantienen escondidos al programador y
slo pueden ser accedidos a travs de otros mtodos pblicos. Esto es as para
mantener hegemnico el ideal de OOP.

Objeto: Entidad provista de un conjunto de propiedades o atributos (datos)

y de comportamiento o funcionalidad (mtodos) los mismos que
consecuentemente reaccionan a eventos. Se corresponde con los objetos reales
del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una
instancia a una clase.

Mtodo: Algoritmo asociado a un objeto (o a una clase de objetos), cuya

ejecucin se desencadena tras la recepcin de un "mensaje". Desde el punto de
vista del comportamiento, es lo que el objeto puede hacer. Un mtodo puede
producir un cambio en las propiedades del objeto, o la generacin de un "evento"
con un nuevo mensaje para otro objeto del sistema.

Evento: Es un suceso en el sistema (tal como una interaccin del usuario

con la mquina, o un mensaje enviado por un objeto). El sistema maneja el evento
enviando el mensaje adecuado al objeto pertinente. Tambin se puede definir
como evento, a la reaccin que puede desencadenar un objeto, es decir la accin
que genera.

Mensaje: Una comunicacin dirigida a un objeto, que le ordena que ejecute

uno de sus mtodos con ciertos parmetros asociados al evento que lo gener.

Propiedad o atributo: Contenedor de un tipo de datos asociados a un

objeto (o a una clase de objetos), que hace los datos visibles desde fuera del
objeto y esto se define como sus caractersticas predeterminadas, y cuyo valor
puede ser alterado por la ejecucin de algn mtodo.

Estado interno: Es una variable que se declara privada, que puede ser
nicamente accedida y alterada por un mtodo del objeto, y que se utiliza para
indicar distintas situaciones posibles para el objeto (o clase de objetos). No es
visible al programador que maneja una instancia de la clase.

Componentes de un objeto: Atributos, identidad, relaciones y mtodos.

Identificacin de un objeto: Un objeto se representa por medio de una
tabla o entidad que est compuesta por sus atributos y funciones
correspondientes.

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.

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:
o Un documento, tal como la visin o la lista de riesgos.
o Un modelo, por ejemplo un diagrama de casos de uso o el modelo de
diseo.
o Un elemento dentro de un modelo, tal como una clase, un caso de uso o un
subsistema.
o Ejecutables, por ejemplo el ejecutable del prototipo.
o 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.

METODOLOGAS EMPLEADOS

Desde la ya antigua metodologa Waterfall hasta las modernas tcnicas

giles, SOFTENG ha ido adaptando sus procesos internos basndose en la
experiencia y el conocimiento, viendo los defectos que planteaba cada
metodologa y para minimizarlos. Esta forma de trabajar nos llev a adaptar de
manera natural una forma de trabajar gil muy similar a la metodologa Scrum. El
siguiente paso lgico era formar a los equipos de trabajo y potenciar la figura del
Scrum Master mediante certificaciones oficiales. Como resultado, podemos afirmar
que SOFTENG fue una de las primeras empresas del mbito nacional en
implementar esta metodologa, obteniendo una mayor satisfaccin por parte de
nuestros clientes, unos mejores resultados en los proyectos de desarrollo de
software y un gran ambiente de trabajo en nuestros equipos, caldo de cultivo de
xitos.
PROCESO UNIFICADO DE DESARROLLO (UP DEL INGLS UNIFIED
PROCESS) FASES DEL DESARROLLO, DISCIPLINAS
El Proceso Unificado no es simplemente un proceso, sino un marco de
trabajo extensible que puede ser adaptado a organizaciones o proyectos
especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un
marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un
refinamiento particular del proceso ha sido derivado del Proceso Unificado o del
RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un
mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genrico
que incluye aquellos elementos que son comunes a la mayora de los
refinamientos existentes. Tambin permite evitar problemas legales ya
que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde
su compra de Rational Software Corporation en 2003). El primer libro sobre el
tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de
Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady
Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del
UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que
publican libros sobre el tema y que no estn afiliados a Rational utilizan el
trmino Proceso Unificado, mientras que los autores que pertenecen a Rational
favorecen el nombre de Proceso Unificado de Rational.

FASES DE DESARROLLO.
Fase De Inicio.
Es la fase ms pequea del proyecto e, idealmente, debe realizarse
tambin en un periodo de tiempo pequeo (una nica iteracin).

El hecho de llevar a cabo una fase de inicio muy larga indica que se est
realizando una especificacin previa excesiva, lo que responde ms a un modelo
en cascada.
Objetivos:

Establecer una justificacin para el proyecto.

Establecer el mbito del proyecto.

Esbozar los casos de uso y los requisitos clave que dirigirn las decisiones
de diseo.

Esbozar las arquitecturas candidatas.

Identificar riesgos.

Preparar el plan del proyecto y la estimacin de costes.

El hito de final de fase se conoce como Hito Objetivo del Ciclo de Vida.
Fase de Elaboracin.
Durante esta fase se capturan la mayora de los requisitos del sistema.
Los objetivos principales de esta fase sern la identificacin de riesgos y
establecer y validar la arquitectura del sistema.

Base de Arquitectura Ejecutable:

La arquitectura se valida a travs de la implementacin de una Base
de Arquitectura Ejecutable: se trata de una implementacin parcial del sistema
que
incluye
los
componentes
principales
del
mismo.
Al final de la fase de elaboracin la base de arquitectura ejecutable debe
demostrar que soporta los aspectos clave de la funcionalidad del sistema y que
muestra la conducta adecuada en trminos de rendimiento, escalabilidad y coste.

Al final de la fase se elabora un plan para la fase de construccin.

El hito arquitectura del ciclo de vida marca el final de la fase.

Fase De Construccin.
Es la fase ms larga de proyecto.

El sistema es construido en base a lo especificado en la fase de

elaboracin.

Las caractersticas del sistema se implementan en una serie de

iteraciones cortas y limitadas en el tiempo.

El resultado de cada iteracin es una versin ejecutable de software.

El hito de capacidad operativa inicial marca el final de la fase.
Fase de transicin.
En esta fase el sistema es desplegado para los usuarios finales.

La retroalimentacin recibida permite incorporar refinamientos al sistema en

las sucesivas iteraciones.

Esta iteracin tambin cubre el entrenamiento de los usuarios para la

utilizacin del sistema.

El hito de lanzamiento del producto marca el final de la fase.

DISCIPLINAS.
Modelado del negocio.
El objetivo es establecer un canal de comunicacin entre los ingenieros del
negocio y los ingenieros del software.

Los ingenieros del software deben conocer la estructura y dinmica de la

organizacin objetivo (el cliente), los problemas actuales y sus posibles mejoras.

Se plasma en la identificacin del modelo del dominio en el que se

visualizan los aspectos bsicos del dominio de aplicacin.

Requisitos.
El objetivo es describir que es lo que tiene que hacer el sistema y poner a
los desarrolladores y al cliente de acuerdo en esta descripcin.
Anlisis y diseo.
Describe como el software ser realizado en la fase de implementacin.

Se plasma en un modelo de diseo que consiste en una serie de clases

(agrupadas en paquetes y subsistemas) con interfaces bien definidos.

Tambin contiene descripciones de cmo los objetos colaboran para

realizar las acciones incluidas en los casos de uso.

Implementacin.
Se implementan las clases y objetos en trminos de componentes (ficheros
fuentes, binarios, ejecutables, entre otros).
Prueba.
Se comprueba que el funcionamiento es correcto analizando diversos
aspectos: los objetos como unidades, la integracin entre objetos, la
implementacin de todos los requisitos, entre otros.

Despliegue.
Se crea la versin externa del producto, se empaqueta, se distribuye y se
instala en el lugar de trabajo. Tambin se da asistencia y ayuda a los usuarios.
Gestin De Configuraciones Y Cambios.

Gestiona aspectos como los sistemas de control de versiones.

Controla las peticiones de cambios clasificndolas segn su estado (nueva,

registrada, aprobada, asignada, completa, entre otros).

Los datos se almacenan en una base de datos y se pueden obtener

informes peridicos.

Herramientas como Rational ClearQuest o Bugzilla.

Gestin del proyecto.

Encargada de definir los planes del proyecto global, los planes de fase y
los planes de iteracin.

Entorno.
Se centra en las actividades necesarias para configurar el proceso de un
proyecto.

El objetivo es proveer a la organizacin de desarrollo software de un

entorno de trabajo (que incluye procedimientos y herramientas) que soporten al
equipo de desarrollo.
INTRODUCCIN
FUNDAMENTOS

LOS

PROCESOS

AGILES

DE

DESARROLLO.

Introduccin a los Procesos giles de Desarrollo.

El desarrollo gil de software es un marco de trabajo conceptual de la
ingeniera de software que promueve iteraciones en el desarrollo a lo largo de todo
el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo gil; la
mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo.
El software desarrollado en una unidad de tiempo es llamado una iteracin,
la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida
incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y
documentacin. Una iteracin no debe agregar demasiada funcionalidad para
justificar el lanzamiento del producto al mercado, pero la meta es tener un demo

(sin errores) al final de cada iteracin. Al final de cada iteracin el equipo vuelve a
evaluar las prioridades del proyecto.
Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la
documentacin. La mayora de los equipos giles estn localizados en una simple
oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en ingls).
La oficina debe incluir revisores, escritores de documentacin y ayuda,
diseadores de iteracin y directores de proyecto. Los mtodos giles tambin
enfatizan que el software funcional es la primera medida del progreso. Combinado
con la preferencia por las comunicaciones cara a cara, generalmente los mtodos
giles son criticados y tratados como "indisciplinados" por la falta de
documentacin tcnica.
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 dedesarrollo de software han despertado inters gracias a que proponen
simplicidad y velocidad para crear sistemas.
INTRODUCCIN AL MODELADO
El modelado de sistemas software es una tcnica para tratar con la
complejidad inherente a estos sistemas. El uso de modelos ayuda al ingeniero de
software a "visualizar" el sistema a construir. Adems, los modelos de un nivel de
abstraccin mayor pueden utilizarse para la comunicacin con el cliente.

CARACTERSTICAS DEL MODELADO

Abstracto
Enfatiza los elementos importantes y oculta los irrelevantes
Comprensible
Fcil de comprender por los observadores
Preciso
Representa de forma fiel el sistema que modela
Predictivo
Se pueden usar para deducir conclusiones sobre el sistema que
modela
Barato

Mucho ms barato y sencillo de construir que el sistema que modela

Los modelos de ingeniera eficaces deben satisfacer todas estas
caractersticas
CONCLUSIN

Hoy en da el software tiene un doble papel. Es un producto, pero

simultneamente es el vehculo para hacer entrega de un producto. Como
producto permite el uso del hardware, ya sea, por ejemplo, un ordenador personal
o un telfono mvil celular. Como vehculo utilizado para hacer entrega del
producto, acta como base de control, por ejemplo un sistema operativo, o un
sistema gestor de redes. El software hace entrega de lo que se considera como el
producto ms importante del siglo veintiuno, la informacin.
El software transforma datos personales para que sean ms tiles en un
entorno local, gestiona informacin comercial para mejorar la competitividad,
proporciona el acceso a redes a nivel mundial, y ofrece el medio de adquirir
informacin en todas sus formas.
Actualmente se considera la Ingeniera del Software como una nueva rea
de la ingeniera, y la profesin de ingeniero informtico es una de las ms
demandadas, aunque en Espaa los salarios suelen ser bajos para la cualificacin
de estos profesionales. La palabra ingeniera tiene una connotacin de prestigio
que provoca que muchas ramas del conocimiento tiendan a autodenominarse as.
Actualmente existe sobredemanda de profesionales altamente cualificados,
sucede principalmente en las grandes industrias, como Google, Facebook, Twitter
y otras grandes compaas que ms que competir, combaten entre s para captar
a los valiosos egresados de las principales universidades.

BIBLIOGRAFA
http://www.gcfaprendelibre.org/tecnologia/curso/informatica_basica/empezando_a
_usar_un_computador/2.do
http://definicion.de/software/
http://ingenieriadelsoftwareigenesis.blogspot.com/2012/11/cualidades-delsoftware.html
http://www.monografias.com/trabajos59/calidad-software/calidad-software2.shtml
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
http://softwarelibre-informatica.blogspot.com/2013/04/seleccion-del-modeloapropiado-segun.html
http://procesodedasarrolo.blogspot.com/2011/11/fundamentos-del-enfoqueorientado_10.html
http://brfranciscoosunaiuty.blogspot.com/2012/07/documentacion-y-artefactos.html
http://informatica-iutll.blogspot.com/2013/03/proceso-unificado-de-desarrollo.html
http://procesodedasarrolo.blogspot.com/2011/11/introduccion-los-procesos-agilesde.html