Unidad I

Sistema de informacin.
Un sistema de informacin (SI) es un conjunto de elementos orientados al tratamiento y
administracin de datos e informacin, organizados y listos para su uso posterior, generados para
cubrir una necesidad u objetivo. Dichos elementos formarn parte de alguna de las siguientes
categoras:

Personas
datos
actividades o tcnicas de trabajo

Recursos materiales en general (generalmente recursos informticos y de comunicacin, aunque

no necesariamente).
Todos estos elementos interactan para procesar los datos (incluidos los procesos manuales y
automticos) y dan lugar a informacin ms elaborada, que se distribuye de la manera ms
adecuada posible en una determinada organizacin, en funcin de sus objetivos.
Habitualmente el trmino se usa de manera errnea como sinnimo de sistema de informacin
informtico, en parte porque en la mayor parte de los casos los recursos materiales de un sistema
de informacin estn constituidos casi en su totalidad por sistemas informticos. Estrictamente
hablando, un sistema de informacin no tiene por qu disponer de dichos recursos (aunque en la
prctica esto no suela ocurrir). Se podra decir entonces que los sistemas de informacin
informticos son una subclase o un subconjunto de los sistemas de informacin en general.

Ciclo de vida de los Sistemas de Informacin.

Existen pautas bsicas para el desarrollo de un SI para una organizacin:
Conocimiento de la Organizacin: analizar y conocer todos los sistemas que forman parte de la
organizacin, as como los futuros usuarios del SI. En las empresas (fin de lucro presente), se
analiza el proceso de negocio y los procesos transaccionales a los que dar soporte el SI.
Identificacin de problemas y oportunidades: el segundo paso es relevar las situaciones que
tiene la organizacin y de las cuales se puede sacar una ventaja competitiva(Por ejemplo: una
empresa con un personal capacitado en manejo informtico reduce el costo de capacitacin de los
usuarios), as como las situaciones desventajosas o limitaciones que hay que sortear o que tomar
en cuenta(Por ejemplo: el edificio de una empresa que cuenta con un espacio muy reducido y no
permitir instalar ms de dos computadoras).

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Determinar las necesidades: este proceso tambin se denomina e licitacin de requerimientos. En

el mismo, se procede identificar a travs de algn mtodo de recoleccin de informacin (el que
ms se ajuste a cada caso) la informacin relevante para el SI que se propondr.
Diagnstico: En este paso se elabora un informe resaltando los aspectos positivos y negativos de
la organizacin. Este informe formar parte de la propuesta del SI y, tambin, ser tomado en
cuenta a la hora del diseo.
Propuesta: contando ya con toda la informacin necesaria acerca de la organizacin es posible
elaborar una propuesta formal dirigida hacia la organizacin donde se detalle el presupuesto,
relacin costo-beneficio, presentacin del proyecto de desarrollo del SI.
Diseo del sistema: Una vez aprobado el proyecto, se comienza con la elaboracin del diseo
lgico del SI; la misma incluye el diseo del flujo de la informacin dentro del sistema, los procesos
que se realizarn dentro del sistema, etc. En este paso es importante seleccionar la plataforma
donde se apoyar el SI y el lenguaje de programacin a utilizar.
Codificacin: con el algoritmo ya diseado, se procede a su reescritura en un lenguaje de
programacin establecido (programacin), es decir, en cdigos que la mquina pueda interpretar y
ejecutar.
Implementacin: Este paso consta de todas las actividades requeridas para la instalacin de los
equipos informticos, redes y la instalacin del programa generado en el paso anterior.
Mantenimiento: proceso de retroalimentacin, a travs del cual se puede solicitar la correccin, el
mejoramiento o la adaptacin del SI ya creado a otro entorno. Este paso incluye el soporte tcnico
acordado anteriormente.

Tipos de sistemas de informacin.

Debido a que el principal uso que se da a los SI es el de optimizar el desarrollo de las actividades
de una organizacin con el fin de ser ms productivos y obtener ventajas competitivas, en primer
trmino, se puede clasificar a los sistemas de informacin en:

Sistemas Competitivos
Sistemas Cooperativos
Sistemas que modifican el estilo de operacin del negocio

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Esta clasificacin es muy genrica, y en la prctica no obedece a una diferenciacin real de

sistemas de informacin reales, ya que en la prctica podramos encontrar alguno que cumpla
varias (dos o las tres) de las caractersticas anteriores. En los sub apartados siguientes se hacen
unas clasificaciones ms concretas (y reales) de sistemas de informacin.

Desde un punto de vista empresarial en tipo de Sistema de Informacin.

La primera clasificacin se basa en la jerarqua de una organizacin y se llam el modelo de la
pirmide.4 Segn la funcin a la que vayan destinados o el tipo de usuario final del mismo,5 los SI
pueden clasificarse en:
Sistema de procesamiento de transacciones (TPS).- Gestiona la informacin referente a las
transacciones producidas en una empresa u organizacin, tambin se le conoce como Sistema de
Informacin operativa.
Sistemas de informacin gerencial (MIS).- Orientados a solucionar problemas empresariales en
general.
Sistemas de soporte a decisiones (DSS).- Herramienta para realizar el anlisis de las diferentes
variables de negocio con la finalidad de apoyar el proceso de toma de decisiones.
Sistemas de informacin ejecutiva (EIS).- Herramienta orientada a usuarios de nivel gerencial, que
permite monitorizar el estado de las variables de un rea o unidad de la empresa a partir de
informacin interna y externa a la misma. Es en este nivel cuando los sistemas de informacin
manejan informacin estratgica para las empresas.
Estos sistemas de informacin no surgieron simultneamente en el mercado; los primeros en
aparecer fueron los TPS, en la dcada de los 60, sin embargo, con el tiempo, otros sistemas de
informacin comenzaron a evolucionar. Los primeros proporcionan informacin a los siguientes a
medida que aumenta la escala organizacional.
Sistemas de automatizacin de oficinas (OAS).- Aplicaciones destinadas a ayudar al trabajo diario
del administrativo de una empresa u organizacin.
Sistema Planificacin de Recursos (ERP).- Integran la informacin y los procesos de una
organizacin en un solo sistema.
Sistema experto (SE).- Emulan el comportamiento de un experto en un dominio concreto.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Los ltimos fueron los SE, que alcanzaron su auge en los 90 (aunque estos ltimos tuvieron una
tmida aparicin en los 70 que no cuaj, ya que la tecnologa no estaba suficientemente
desarrollada).
Desarrollo en espiral
El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por
Barry Boehm en 1986,1 utilizado generalmente en la Ingeniera de software. Las actividades de
este modelo se conforman en una espiral, en la que cada bucle o iteracin representa un conjunto
de actividades. Las actividades no estn fijadas a ninguna prioridad, sino que las siguientes se
eligen en funcin del anlisis de riesgo, comenzando por el bucle interior.

Ciclos o Iteraciones
En cada vuelta o iteracin hay que tener en cuenta:

Los Objetivos: qu necesidad debe cubrir el producto.

Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde
diferentes puntos de vista como pueden ser:
1. Caractersticas: experiencia del personal, requisitos a cumplir, etc.
2. Formas de gestin del sistema.
3. Riesgo asumido con cada alternativa.
Desarrollar y Verificar: Programar y probar el software.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral

tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:
1. Angular: Indica el avance del proyecto del software dentro de un ciclo.
2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteracin
se pasa ms tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la
creacin de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno de los aspectos
fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y
habilidad para detectar y catalogar correctamente los riesgos.
Tareas
Para cada ciclo habr cuatro actividades:

Determinar Objetivos.
o Fijar tambin los productos definidos a obtener: requerimientos, especificacin,
manual de usuario.
o Fijar las restricciones.
o Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.
o Hay una cosa que solo se hace una vez: planificacin inicial o previa.
Anlisis del riesgo.
o Se lleva a cabo el estudio de las causas de las posibles amenazas y probables
eventos no deseados y los daos y consecuencias que stas puedan producir.
Planificacin.
o Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con
las fases siguientes y planificamos la prxima actividad.

Desarrollar y probar.
o

Tareas de la actividad propia y de prueba.

Anlisis de alternativas e identificacin resolucin de riesgos.

Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo

para el desarrollo, el que puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada. As si por ejemplo si los riesgos en la interfaz de
usuario son dominantes, un modelo de desarrollo apropiado podra ser la
construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal
consideracin, un desarrollo basado en transformaciones formales podra ser el
ms apropiado.
Profesor: Claudio Castillo.
Ingeniera de Software.

Unidad I

Ventajas
El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los
restantes modelos.

Reduce riesgos del proyecto

Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento.

Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la
metodologa, ya que este ciclo de vida no es rgido ni esttico.
Desventajas

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso
Requiere experiencia en la identificacin de riesgos

Desarrollo en cascada
En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada, es el
enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de
software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa
anterior.
Un ejemplo de una metodologa de desarrollo en cascada es:

Anlisis de requisitos.
Diseo del Sistema.
Diseo del Programa.
Codificacin.
Pruebas.
Implantacin.
Mantenimiento.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce

necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del
desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el
esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto.

Fases del modelo.

Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu
objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin
de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar
en detalles internos.
Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del sistema y
ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a
mitad del proceso de elaboracin del software.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Diseo del Sistema

Descompone y organiza el sistema en elementos que puedan elaborarse por separado,
aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de
Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la
especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se
combinan unas con otras.
Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero
de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha
descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar
asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo
define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin.
Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los
requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas
usar en la etapa de Codificacin.
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de
pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes
reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho
ms rpido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que
funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.
Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya
realizaron exhaustivas pruebas para comprobar que el sistema no falle.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Mantenimiento
Una de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del
Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras
expectativas.
Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la
que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema
final este libre de fallos.
Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala
implementacin del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de
prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione
bien.
Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y
nueva programacin del cdigo afectado, aumentando los costos del desarrollo.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

METODOLOGIA RUP
El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniera de
software que suministra un enfoque para asignar tareas y responsabilidades dentro de una
organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad que
satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una
metodologa de desarrollo iterativo enfocada hacia los casos de uso, manejo de riesgos y el
manejo de la arquitectura.
El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin
importar su responsabilidad especfica acceda a la misma base de datos de conocimiento. Esto
hace que todos compartan el mismo lenguaje, la misma visin y el mismo proceso acerca de cmo
desarrollar software.

En el ciclo de vida RUP veremos una implementacin del desarrollo en espiral. Con el ciclo de vida
se establecen tareas en fases e iteraciones. El RUP maneja el proceso en cuatro fases, dentro de
las cuales se realizan varias iteraciones en nmero variable.
Profesor: Claudio Castillo.
Ingeniera de Software.

Unidad I

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 base de inicio.
FASES
FASE DE INICIO: Durante esta fase de inicio las iteraciones se centran con mayor nfasis en las
actividades de modelamiento de la empresa y en sus requerimientos
FASE DE ELABORACIN: Durante esta fase de elaboracin, las iteraciones se centran al desarrollo
de la base de la diseo, encierran ms los flujos de trabajo de requerimientos, modelo de la
organizacin, anlisis, diseo y una parte de implementacin orientada a la base de la
construccin
FASE DE CONSTRUCCIN: Durante esta fase de construccin, se lleva a cabo la construccin del
producto por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de Uso, se
redefine su anlisis y diseo y se procede a su implantacin y pruebas. En esta fase se realiza una
pequea cascada para cada ciclo, se realizan tantas iteraciones hasta que se termine la nueva
implementacin del producto.
FASE DE TRANSICIN: Durante esta fase de transicin busca garantizar que se tiene un producto
preparado para su entrega al usuario.
PRINCIPALES CARACTERISTICAS

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).

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Especificacin de las 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:

Modelado de negocio
Requisitos
Anlisis y Diseo
Implementacin
Pruebas
Despliegue

Soporte: En esta parte nos conseguimos con las siguientes etapas:

Gestin del cambio y configuraciones

Gestin del proyecto
Entorno

La estructura dinmica de RUP es la que permite que este sea un proceso de desarrollo
fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

Inicio(Tambin llamado Incepcin)

Elaboracin
Desarrollo(Tambin llamado Implementacin, Construccin)
Cierre (Tambin llamado Transicin)

Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de
artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema estos
artefactos son los siguientes:
Inicio:

Documento Visin
Especificacin de Requerimientos

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Elaboracin:

Diagramas de caso de uso

Construccin:

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.

Implementacin del RUP para el proyecto

La metodologa RUP es ms apropiada para proyectos grandes (Aunque tambin pequeos), dado
que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En
proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de
profesionales necesarios.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Programacin extrema
La programacin extrema es una metodologa reciente (tiene alrededor de 5 aos) en el desarrollo
de software. La filosofa de X.P es satisfacer al completo las necesidades del cliente, por eso lo
integra como una parte ms del equipo de desarrollo.
X.P fue inicialmente creada para el desarrollo de aplicaciones dnde el cliente no sabe muy bien lo
que quiere, lo que provoca un cambio constante en los requisitos que debe cumplir la aplicacin.
Por este motivo es necesaria una metodologa gil como X.P que se adapta a las necesidades del
cliente y dnde la aplicacin se va re-evaluando en periodos cortos de tiempo.
X.P est diseada para el desarrollo de aplicaciones que requieran un grupo de programadores
pequeo, dnde la comunicacin sea ms factible que en grupos de desarrollo grandes. La
comunicacin es un punto importante y debe realizarse entre los programadores, los jefes de
proyecto y los clientes.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

FASES PROGRAMACION XTREMA

1 Fase: Planificacin del proyecto.
Historias de usuario: El primer paso de cualquier proyecto que siga la metodologa X.P es definir
las historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que los
casos de uso pero con algunas diferencias: Constan de 3 4 lneas escritas por el cliente en un
lenguaje no tcnico sin hacer mucho hincapi en los detalles; no se debe hablar ni de posibles
algoritmos para su implementacin ni de diseos de base de datos adecuados, etc. Son usadas
para estimar tiempos de desarrollo de la parte de la aplicacin que describen. Tambin se utilizan
en la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia de
usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los
desarrolladores se renen para concretar y detallar lo que tiene que hacer dicha historia. El
tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3 semanas.
Release planning*: Despus de tener ya definidas las historias de usuario es necesario crear un
plan de publicaciones, en ingls "Release plan", donde se indiquen las historias de usuario que se
crearn para cada versin del programa y las fechas en las que se publicarn estas versiones. Un
"Release plan" es una planificacin donde los desarrolladores y clientes establecen los tiempos de
implementacin ideales de las historias de usuario, la prioridad con la que sern implementadas y
las historias que sern implementadas en cada versin del programa. Despus de un "Release
plan" tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son
principalmente las historias que se deben desarrollar en cada versin), el tiempo que tardarn en
desarrollarse y publicarse las versiones del programa, el nmero de personas que trabajarn en el
desarrollo y cmo se evaluar la calidad del trabajo realizado. (*Release plan: Planificacin de
publicaciones).
Iteraciones Todo proyecto que siga la metodologa X.P. se ha de dividir en iteraciones de
aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los clientes deben
seleccionar las historias de usuario definidas en el "Release planning" que sern implementadas.
Tambin se seleccionan las historias de usuario que no pasaron el test de aceptacin que se
realiz al terminar la iteracin anterior. Estas historias de usuario son divididas en tareas de entre
1 y 3 das de duracin que se asignarn a los programadores.
Velocidad del proyecto: La velocidad del proyecto es una medida que representa la rapidez con la
que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar el nmero de historias
de usuario que se pueden implementar en una iteracin; de esta forma, se sabr el cupo de
historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto
controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

iteracin. Es conveniente reevaluar esta medida cada 3 4 iteraciones y si se aprecia que no es

adecuada hay que negociar con el cliente un nuevo "Release Plan".
Programacin en pareja: La metodologa X.P. aconseja la programacin en parejas pues
incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja involucra a
dos programadores trabajando en el mismo equipo; mientras uno codifica haciendo hincapi en la
calidad de la funcin o mtodo que est implementando, el otro analiza si ese mtodo o funcin
es adecuado y est bien diseado. De esta forma se consigue un cdigo y diseo con gran calidad.
Reuniones diarias. Es necesario que los desarrolladores se renan diariamente y expongan sus
problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y todo el
mundo tiene que tener voz y voto.
2 Fase: Diseo.
Diseos simples: La metodologa X.P sugiere que hay que conseguir diseos simples y sencillos.
Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseo fcilmente
entendible e implemntable que a la larga costar menos tiempo y esfuerzo desarrollar.
Glosarios de trminos: Usar glosarios de trminos y un correcta especificacin de los nombres de
mtodos y clases ayudar a comprender el diseo y facilitar sus posteriores ampliaciones y la
reutilizacin del cdigo.
Riesgos: Si surgen problemas potenciales durante el diseo, X.P sugiere utilizar una pareja de
desarrolladores para que investiguen y reduzcan al mximo el riesgo que supone ese problema.
Funcionalidad extra: Nunca se debe aadir funcionalidad extra al programa aunque se piense que
en un futuro ser utilizada. Slo el 10% de la misma es utilizada, lo que implica que el desarrollo de
funcionalidad extra es un desperdicio de tiempo y recursos.
Refactorizar: Refactorizar es mejorar y modificar la estructura y codificacin de cdigos ya creados
sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos cdigos para procurar
optimizar su funcionamiento. Es muy comn rehusar cdigos ya creados que contienen
funcionalidades que no sern usadas y diseos obsoletos. Esto es un error porque puede generar
cdigo completamente inestable y muy mal diseado; por este motivo, es necesario refactorizar
cuando se va a utilizar cdigo ya creado.
Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration) permiten al
programador centrarse y apreciar el desarrollo orientado a objetos olvidndose de los malos
hbitos de la programacin procedural clsica.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se puede escribir en la
parte de arriba de la tarjeta, en una columna a la izquierda se pueden escribir las
responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las clases que colaboran
con cada responsabilidad.
3 Fase: Codificacin.
Como ya se dijo en la introduccin, el cliente es una parte ms del equipo de desarrollo; su
presencia es indispensable en las distintas fases de X.P. A la hora de codificar una historia de
usuario su presencia es an ms necesaria. No olvidemos que los clientes son los que crean las
historias de usuario y negocian los tiempos en los que sern implementadas. Antes del desarrollo
de cada historia de usuario el cliente debe especificar detalladamente lo que sta har y tambin
tendr que estar presente cuando se realicen los test que verifiquen que la historia implementada
cumple la funcionalidad especificada.
La codificacin debe hacerse ateniendo a estndares de codificacin ya creados. Programar bajo
estndares mantiene el cdigo consistente y facilita su comprensin y escalabilidad.
Crear test que prueben el funcionamiento de los distintos cdigos implementados nos ayudar a
desarrollar dicho cdigo. Crear estos test antes nos ayuda a saber qu es exactamente lo que tiene
que hacer el cdigo a implementar y sabremos que una vez implementado pasar dichos test sin
problemas ya que dicho cdigo ha sido diseado para ese fin. Se puede dividir la funcionalidad que
debe cumplir una tarea a programar en pequeas unidades, de esta forma se crearn primero los
test para cada unidad y a continuacin se desarrollar dicha unidad, as poco a poco
conseguiremos un desarrollo que cumpla todos los requisitos especificados.
Como ya se coment anteriormente, X.P opta por la programacin en pareja ya que permite un
cdigo ms eficiente y con una gran calidad.
X.P sugiere un modelo de trabajo usando repositorios de cdigo dnde las parejas de
programadores publican cada pocas horas sus cdigos implementados y corregidos junto a los test
que deben pasar. De esta forma el resto de programadores que necesiten cdigos ajenos
trabajarn siempre con las ltimas versiones. Para mantener un cdigo consistente, publicar un
cdigo en un repositorio es una accin exclusiva para cada pareja de programadores.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

X.P tambin propone un modelo de desarrollo colectivo en el que todos los programadores estn
implicados en todas las tareas; cualquiera puede modificar o ampliar una clase o mtodo de otro
programador si es necesario y subirla al repositorio de cdigo. El permitir al resto de los
programadores modificar cdigos que no son suyos no supone ningn riesgo ya que para que un
cdigo pueda ser publicado en el repositorio tiene que pasar los test de funcionamiento definidos
para el mismo.
La optimizacin del cdigo siempre se debe dejar para el final. Hay que hacer que funcione y que
sea correcto, ms tarde se puede optimizar.
X.P afirma que la mayora de los proyectos que necesiten ms tiempo extra que el planificado para
ser finalizados no podrn ser terminados a tiempo se haga lo que se haga, aunque se aadan ms
desarrolladores y se incrementen los recursos. La solucin que plantea X.P es realizar un nuevo
"Release plan" para concretar los nuevos tiempos de publicacin y de velocidad del proyecto.
A la hora de codificar no seguimos la regla de X.P que aconseja crear test de funcionamiento con
entornos de desarrollo antes de programar. Nuestros test los obtendremos de la especificacin de
requisitos ya que en ella se especifican las pruebas que deben pasar las distintas funcionalidades
del programa, procurando codificar pensando en las pruebas que debe pasar cada funcionalidad.
4 Fase: Pruebas.
Uno de los pilares de la metodologa X.P es el uso de test para comprobar el funcionamiento de los
cdigos que vayamos implementando.
El uso de los test en X.P es el siguiente:
Se deben crear las aplicaciones que realizarn los test con un entorno de desarrollo especfico para
test.
Hay que someter a tests las distintas clases del sistema omitiendo los mtodos ms triviales.
Se deben crear los test que pasarn los cdigos antes de implementarlos; en el apartado anterior
se explic la importancia de crear antes los test que el cdigo.
Un punto importante es crear test que no tengan ninguna dependencia del cdigo que en un
futuro evaluar. Hay que crear los test abstrayndose del futuro cdigo, de esta forma
aseguraremos la independencia del test respecto al cdigo que evala.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Como se coment anteriormente los distintos test se deben subir al repositorio de cdigo
acompaados del cdigo que verifican. Ningn cdigo puede ser publicado en el repositorio sin
que haya pasado su test de funcionamiento, de esta forma, aseguramos el uso colectivo del cdigo
(explicado en el apartado anterior).
El uso de los test es adecuado para observar la refactorizacin. Los test permiten verificar que un
cambio en la estructura de un cdigo no tiene porqu cambiar su funcionamiento.
Test de aceptacin. Los test mencionados anteriormente sirven para evaluar las distintas tareas en
las que ha sido dividida una historia de usuario. Para asegurar el funcionamiento final de una
determinada historia de usuario se deben crear "Test de aceptacin"; estos test son creados y
usados por los clientes para comprobar que las distintas historias de usuario cumplen su cometido.
Al ser las distintas funcionalidades de nuestra aplicacin no demasiado extensas, no se harn test
que analicen partes de las mismas, sino que las pruebas se realizarn para las funcionalidades
generales que debe cumplir el programa especificado en la descripcin de requisitos.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Modelos evolutivos
El software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar
conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea
posible esperar a poner en el mercado un producto absolutamente completo, por lo que se
aconsejable introducir una versin funcional limitada de alguna forma para aliviar las presiones
competitivas.
En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estn
diseados para acomodarse a una evolucin temporal o progresiva, donde los requisitos centrales
son conocidos de antemano, aunque no estn bien definidos a nivel detalle.
En el modelo cascada y cascada realimentado no se tiene demasiado en cuenta la naturaleza
evolutiva del software, se plantea como esttico, con requisitos bien conocidos y definidos desde
el inicio.
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y
complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de
operacin.
Los modelos iterativo incremental y espiral (entre otros) son dos de los ms conocidos y
utilizados del tipo evolutivo.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

Modelo iterativo incremental

modelos iterativos e incrementales los cuales disminuyen riesgos y nos ayudan a tener un mejor
desarrollo de software ya que estos modelos se basan en la retroalimentacin por lo que nos
ayudan a tener una mejor arquitectura del software y son muy tiles cuando el usuario tiene ms
requerimientos. En este modelo aparecen las versiones. Gracias a las versiones nosotros podemos
aumentar o modificar el software si se necesita.

Profesor: Claudio Castillo.

Ingeniera de Software.

Unidad I

El modelo incremental: Este modelo mantiene la funcin anterior y aumenta otra, ya que puede
ser que el primer incremento no hubiera tenido todos los requerimientos que necesitaba el
proyecto.
El modelo iterativo: Este modelo en cambio mejora cada versin es decir mejora la funcin que
tiene la versin.
Entre las ventajas de estos modelos tenemos que disminuyen riesgos, tambin en estos modelos
nosotros podemos fcilmente cambiar los requerimientos pues como nos basamos en una versin
a esta la aumentamos o la modificamos. Tambin reduce costos pues si algo sale mal solo
volvemos a la antigua versin y comenzamos de nuevo. Otra ventaja es que al usuario se le
entrega parte del producto es decir una versin con la cual l puede trabajar.
Pero como nada es perfecto tambin tiene desventajas como que no todo proyecto puede tener
versiones entonces nosotros deberamos saber en que proyectos usar este modelo; adems estos
necesitan una gran planeacin.

Cuestionario de Investigacin.
a. Qu entiende por Sistema de Informacin?
b. Disee un esquema con las etapas del ciclo de vida del SIA, Defina Brevemente cada una
de ellas.
c. Seale las caractersticas del paradigma o modelo Espiral.
d. Identifica 2 diferencias entre los modelos Cascada y Prototipo.
e. Describa 2 aplicaciones o programas donde puede implementar un sistema Utilizando la
metodologa Espiral.
f. Realizar un esquema donde describa las etapas del modelo Prototipo.
g. A su juicio Cul es la importancia de realizar un sistema o aplicacin Utilizando una
metodologa de desarrollo de Software?
h. Describa dos escenarios donde NO utilizara el modelo de prototipo.
i. Disee una entrevista para conocer el proceso de la compra y ventas de frmacos y drogas
al interior de una Farmacia.
j. Cul es la diferencia entre la modelo Espiral y RUP?
k. Seala 2 caractersticas del modelo RUP.
l. Qu es lo que propone XP?

Profesor: Claudio Castillo.

Ingeniera de Software.