You are on page 1of 42

TRABAJO INVESTIGATIVO 01

INGENIERIA DE SOFTWARE

Presenta
Camilo Andrs Frontado Escobar
Erik Alexis Valderrama
Alejandro Jimnez Mateus
Harold Jhovany Lpez Medina

Docente
Juan Carlos Guevara B.

Asignatura
Ingeniera de software

Universidad Distrital Francisco Jos de Caldas


Tecnologa en Sistematizacin de datos
Facultad Tecnolgica
Bogot D.C Colombia - 14 de Febrero de 2016

CONTENIDO

2. Introduccin.2
3. Ingeniera de software...3
3.1. Definicin.....3
3.2. Objetivos.............3
3.3. Caractersticas....4
3.4. Historia............4
4. Modelos de ciclo de vida del software...5
5. Metodologas de desarrollo de software ....13
6. Estndares para garantizar la calidad de software....29
7. Modelos de evaluacin de calidad de software......35
8. Elementos de un proyecto de desarrollo de software.......39
9. Conclusiones....40
10. Bibliografa..41

2. INTRODUCCION

Los ingenieros enfocados hacia el desarrollo de software siempre han tenido


que enfrentarse con la realidad de una responsabilidad al entregar software de
calidad, para ello tienen que adaptarse a las peticiones que requiere el cliente,
llevndolas a un lenguaje en donde pueda establecer una simplificacin de la
realidad, proveyndose de herramientas creadas por los estndares
desarrollados por la ISO y la IEEE.
A su vez de acuerdo a su propia perspectiva en base a los conocimientos
adquiridos en su experiencia en la realizacin de proyectos sistematizacin de
informacin, establece reglas de comportamiento que provean una metodologa
organizacional que le permite entregar su trabajo en el menor tiempo posible, el
menor costo entre los rangos establecidos y en las mejores condiciones, para
que los procesos a ser llevados por el usuario tengan tareas simples de
entender para un funcionamiento adecuado del sistema creado.

3. INGENIERA DE SOFTWARE
3.1. Definicin

El IEEE cumputer society define la ingeniera de software como:

Aplicacin de un enfoque sistemtico, disciplinario y cuantificable al


desarrollo, operacin y mantenimiento del software, es decir, la
aplicacin de la ingeniera al software.

Ingeniera de software es la aplicacin prctica del conocimiento


cientfico al diseo y construccin de programas de computadora y a la
documentacin asociada requerida para desarrollar, operar y
mantenerlos. Se conoce tambin como desarrollo de software o
produccin de software (Bohem, 1976).

El estudio de los mtodos en la Aplicacin de un enfoque sistemtico,


disciplinario y cuantificable al desarrollo, operacin y mantenimiento del
software, es decir, la aplicacin de la ingeniera al software.

3.2. Objetivos

Dirigir y coordinar el desarrollo de aplicaciones complejas.


Intervenir en todas las fases del ciclo de vida de un producto.
Estimar los costes de un proyecto y determinar los tiempos de
desarrollo.
Hacer el seguimiento de costes y plazos.
Dirigir equipos de trabajo de desarrollo software.
Organizar la realizacin de pruebas que verifiquen el correcto
funcionamiento de los programas y que se ajustan a los requisitos de
anlisis y diseo.
Disear, construir y administrar bases de datos.
Dirigir y asesorar a los programadores durante el desarrollo de
aplicaciones.
Introducir procedimientos de calidad en los sistemas, evaluando
mtricas e indicadores y controlando la calidad del software producido.
Organizar y supervisar el trabajo de su equipo de los tcnicos de
mantenimiento y los ingenieros de sistemas y redes.

3.3. Caractersticas
-

el software no se crea, se desarrolla.


El software no se descompone, se desactualizada.
El software se hace a la medida

Uso de Metodologas y herramientas para un buen desarrollo de


software.
Estar enfocado en cumplir las diferentes normas de calidad en cada
proceso del ciclo de vida puestas por el IEEE o ISO.

3.4. Historia

Cuando aparecieron las primeras computadoras digitales en la dcada de


1940, el desarrollo de software era algo tan nuevo que era casi imposible hacer
predicciones de las fechas estimadas de finalizacin del proyecto y muchos de
ellos sobrepasaban los presupuestos y tiempo estimados. Los desarrolladores
tenan que volver a escribir todos sus programas para correr en mquinas
nuevas que salan cada uno o dos aos, haciendo obsoletas las ya existentes.
El trmino Ingeniera del software apareci por primera vez a finales de la
dcada de 1950. La Ingeniera de software fue estimulada por la crisis del
software de las dcadas de entre 1960 y 1980. La Ingeniera del software viene
a ayudar a identificar y corregir mediante principios y metodologas los
procesos de desarrollo y mantenimiento de sistemas de software.
Aparte de la crisis del software de las dcadas de entre 1960 y 1980, la
ingeniera de software se ve afectada por accidentes que conllevaron a la
muerte de tres personas; esto sucedi cuando la mquina de radioterapia
Therac-25 emite una sobredosis masiva de radiacin y afecto contra la vida de
estas personas. Esto remarca los riesgos de control por software, afectando
directamente al nombre de la ingeniera de software.

A principios de los 1980, la ingeniera del software ya haba surgido como una
genuina profesin, para estar al lado de las ciencias de la computacin y la
ingeniera tradicional. Antes de esto, las tareas eran corridas poniendo tarjetas
perforadas como entrada en el lector de tarjetas de la mquina y se esperaban
los resultados devueltos por la impresora.
Debido a la necesidad de traducir frecuentemente el software viejo para
atender las necesidades de las nuevas mquinas, se desarrollaron lenguajes
de orden superior. A medida que apareci el software libre, las organizaciones
de usuarios comnmente lo liberaban.
Para la dcada de 1980, el costo de propiedad y mantenimiento del software
fue dos veces ms caro que el propio desarrollo del software, y durante la
dcada de 1990, el costo de propiedad y mantenimiento aument 30 % con
respecto a la dcada anterior. En 1995, muchos de los proyectos de desarrollo
estaban operacionales, pero no eran considerados exitosos. El proyecto de
software medio sobrepasaba en un 50 % la estimacin de tiempo previamente
realizada, adems, el 75 % de todos los grandes productos de software que

eran entregados al cliente tenan fallas tan graves, que no eran usados en lo
absoluto o simplemente no cumplan con los requerimientos del cliente.
Algunos expertos argumentaron que la crisis del software era debido a la falta
de disciplina de los programadores.
Cada nueva tecnologa y prctica de la dcada de 1970 a la de 1990 fue
pregonada como la nica solucin a todos los problemas y el caos que llev a
la crisis del software. Lo cierto es que la bsqueda de una nica clave para el
xito nunca funcion. El campo de la ingeniera de software parece un campo
demasiado complejo y amplio para una nica solucin que sirva para mejorar la
mayora de los problemas, y cada problema representa slo una pequea
porcin de todos los problemas de software.
El auge del uso del Internet llev a un vertiginoso crecimiento en la demanda
de sistemas internacionales de despliegue de informacin en la World Wide
Web. Los desarrolladores se vieron en la tarea de manejar ilustraciones,
mapas, fotografas y animaciones, a un ritmo nunca antes visto, con casi
ningn mtodo para optimizar la visualizacin y almacenamiento de imgenes.
Tambin fueron necesarios sistemas para traducir el flujo de informacin en
mltiples idiomas extranjeros a lenguaje natural humano, con muchos sistemas
de software diseados para uso multilenguaje, basado en traductores
humanos.
La ingeniera de software contribuyo alrededor de 90,000 millones de dlares
por ao ya que entra en juego el Internet; esto hace que los desarrolladores
tuviesen que manejar imgenes mapas y animaciones para optimizar la
visualizacin/almacenamiento de imgenes (como el uso de imgenes en
miniatura). El uso de los navegadores y utilizacin de lenguaje HTML cambia
drsticamente la visin y recepcin de la informacin.
Despus de una fuerte y creciente demanda surge la necesidad de crear
soluciones de software a bajo costo, esto conlleva al uso de metodologas ms
simples y rpidas que desarrollan software funcional. Cabe sealar que los
sistemas ms pequeos tenan un enfoque ms simple y rpido para poder
administrar el desarrollo de clculos y algoritmos de software.

4. MODELOS DE CICLO DE VIDA DEL SOFTWARE


4.1. NOMBRES
La definicin de un modelo de ciclo de vida del software est dada por el
estado de las fases por las cuales se desarrolla un proyecto de software, estas
fases desde la inicial hasta la final permiten la validacin del desarrollo de la
aplicacin, gracias a esto se garantiza que el software cumpla con los
requisitos de aplicacin y verificacin de los procedimientos de desarrollo,
existen diferentes modelos de ciclo de vida del software los cuales han sido

diseados con el fin de rectificar errores, seguir lineamientos y estndares


bsicos en cuanto a desarrollo de software se refiere, mejoramiento en la
calidad del software, cumplimientos de plazos de implementacin y reduccin
de costos asociados.
A continuacin, mencionaremos los principales modelos de ciclo de vida del
software:

MODELO EN CASCADA: El modelo de ciclo de vida en cascada, es el


ms bsico de todos los modelos, y sirve como bloque de construccin
para los dems modelos de ciclo de vida.
MODELO EN V: El modelo de ciclo de vida en V proviene del principio
que establece que los procedimientos utilizados para probar si la
aplicacin cumple las especificaciones ya deben haberse creado en la
fase de diseo.
MODELO EN ESPIRAL: El modelo de ciclo de vida en espiral, es aquel
donde el esfuerzo es iterativo, tan pronto como se completa una fase de
desarrollo se comienza la otra.
MODELO DE DESARROLLO CONCURRENTE: El modelo de ciclo de
vida de desarrollo concurrente, define una serie de acontecimientos que
dispararn transiciones de estado a estado para cada una de las
actividades de la ingeniera del software.
MODELO DE DESARROLLO INCREMENTAL: El modelo de ciclo de
vida de desarrollo incremental, es aquel donde el proceso de
construccin se basa en el incremento de subconjuntos de
requerimientos del sistema. Tpicamente, un documento de
requerimientos es escrito al capturar todos los requerimientos para el
sistema completo.
MODELO DE DESARROLLO EVOLUTIVO: Consta del desarrollo de
una versin inicial que luego de exponerse se va refinando de acuerdo
de los comentarios o nuevos requerimientos por parte del cliente o del
usuario final.

4.2. EXPLICACIN DEL FUNCIONAMIENTO


MODELO EN CASCADA: En el modelo en cascada se presenta una estructura
secuencial, La visin del modelo en cascada es muy simple, se dice que el
desarrollo de software puede ser a travs de una secuencia simple de fases.
Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro
de una fase contribuyen a la satisfaccin de metas de esa fase o quizs a una
subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin
entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia
atrs representan la retroalimentacin. Est formado por las siguientes fases o
etapas:
- Anlisis del Sistema

- Anlisis de Requisitos de Software


- Diseo
- Codificacin
- Prueba
- Mantenimiento
El desarrollo de las fases, como se ha mencionado antes, se produce de
manera secuencial. Una vez se produce el anlisis del sistema y de los
requisitos del software demandado por el cliente, (fases en las que la
intervencin del cliente es absolutamente necesaria), se procede a la fase de
diseo de la arquitectura global del software.

Modelo en cascada
MODELO EN V: En el modelo en V o tambin conocido como modelo de 4
niveles, se basa en el modelo de cascada pura a diferencia de que contiene
dos sub etapas adicionales, El modelo de ciclo de vida V proviene del principio
que establece que los procedimientos utilizados para probar si la aplicacin
cumple las especificaciones ya deben haberse creado en la fase de diseo.

Modelo en V
La anterior figura muestra como cada una de las fases de desarrollo (izquierda
de la imagen), se alinean con la fase de testeo.
-

Lado Izquierdo: Especificaciones de los requerimientos del servicio hasta


el detalle del diseo del servicio.
Lado Derecho: Se focaliza en las actividades de validacin que se llevan
a cabo en contra de las especificaciones definidas a la izquierda.
A cada uno de los pasos de la izquierda, hay implicacin directa con la
parte equivalente en el lado derecho.
Dentro de cada uno de los ciclos del desarrollo repetitivo se pueden
aplicar los conceptos del Modelo V sobre requerimientos de aprobacin
de estabilidad contra el diseo, con cada diseo repetitivo considerado
para el grado de integridad y competencia que justificara el lanzamiento
al cliente para juicio y valoracin.

MODELO EN ESPIRAL: El modelo en espiral, es un modelo de proceso de


software evolutivo que conjuga la naturaleza iterativa de construccin de
prototipos con los aspectos controlados y sistemticos del modelo lineal
secuencial. Proporciona el potencial para el desarrollo rpido de versiones
incrementales del software.
En el modelo espiral, el software se desarrolla en una serie de versiones
incrementales. Durante las primeras iteracciones, la versin incremental podra
ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se
producen versiones cada vez ms completas del sistema diseado.
El modelo en espiral se divide en un nmero de actividades de marco de
trabajo, tambin llamadas regiones de tareas. Generalmente, existen entre tres
y seis regiones de tareas.

Modelo en espiral
-

Comunicacin con el cliente: Las tareas requeridas para establecer


comunicacin entre el desarrollador y el cliente.

Planificacin: Las tareas requeridas para definir recursos, el tiempo y


otra informacin relacionadas con el proyecto.

Anlisis de riesgos: Las tareas requeridas para evaluar riesgos tcnicos


y de gestin.

Ingeniera: Las tareas requeridas


representaciones de la aplicacin.

Construccin y entrega: Las tareas requeridas para construir, probar,


instalar y proporcionar soporte al usuario (por ejemplo: documentacin y
prctica)

Evaluacin del cliente: Las tareas requeridas para obtener la reaccin


del cliente segn la evaluacin de las representaciones del software
creadas durante la etapa de ingeniera e implementada durante la etapa
de instalacin.

para

construir

una

ms

MODELO DE DESARROLLO CONCURRENTE: El Modelo de Desarrollo


Concurrente, se puede representar en forma de esquema como una serie de
actividades tcnicas importantes, tareas y estados asociados a ellas.
Este modelo se utiliza a menudo la arquitectura de desarrollo de aplicaciones
cliente/servidor.

Provee una meta-descripcin del proceso del software. El modelo concurrente


tiene la capacidad de describir las mltiples actividades del software ocurriendo
simultneamente.
La mayora de los modelos de procesos de desarrollo del software son dirigidos
por el tiempo; cuanto ms tarde sea, ms atrs se encontrar en el proceso de
desarrollo. Un modelo de proceso concurrente est dirigido por las necesidades
del usuario, las decisiones de la gestin y los resultados de las revisiones.
El modelo de proceso concurrente define una serie de acontecimientos que
dispararn transiciones de estado a estado para cada una de las actividades de
la ingeniera del software. Durante las primeras etapas del diseo, no se
contempla una inconsistencia del modelo de anlisis. Esto genera la correccin
del modelo de anlisis de sucesos, que disparar la actividad de anlisis del
estado hecho al estado cambios en espera.
Esto genera la correccin del modelo de anlisis de sucesos, que disparar la
actividad de anlisis del estado hecho al estado cambios en espera. Es un
modelo de tipo de red donde todas las personas actan simultneamente o al
mismo tiempo.

Modelo de desarrollo concurrente


Un sistema cliente/servidor se compone de un conjunto de componentes
funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso
concurrente define actividades en dos dimensiones:
1. Dimensin de sistemas.
2. Dimensin de componentes.
Los aspectos del nivel de sistema se afrontan mediante tres actividades:
diseo, ensamblaje y uso.
En realidad, el modelo de proceso concurrente es aplicable a todo tipo de
desarrollo de software y proporciona una imagen exacta del estado actual de
un proyecto.

MODELO DE DESARROLLO INCREMENTAL: El Modelo Incremental


combina elementos del MLS con la filosofa interactiva de construccin de
prototipos.
En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo,
Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el
principio de trabajo en cadena, utilizado en muchas otras formas de
programacin. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento.
Es el mismo cliente el que incluye o desecha elementos al final de cada
incremento a fin de que el software se adapte mejor a sus necesidades reales.
El proceso se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros mtodos de modelado, el Modelo Incremental es de
naturaleza interactiva, pero se diferencia de aquellos en que al final de cada
incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente til cuando no se cuenta con una
dotacin de personal suficiente. Los primeros pasos los pueden realizar un
grupo reducido de personas y en cada incremento se puede aadir personal,
de ser necesario. Por otro lado, los incrementos se pueden planear para
gestionar riesgos tcnicos.

Modelo Incremental
Las caractersticas del modelo incremental son las siguientes:
-

Se evitan proyectos largos y se entrega algo de valor a los usuarios con


cierta frecuencia.

El usuario se involucra ms.

Difcil de evaluar el coste total.

Difcil de aplicar a los sistemas transaccionales que tienden a ser


integrados y a operar como un todo.

Requiere gestores experimentados.

Los errores en los requisitos se detectan tarde.

El resultado puede ser muy positivo.

MODELO DE DESARROLLO EVOLUTIVO: El Modelo de desarrollo evolutivo


consta del desarrollo de una versin inicial que luego de exponerse se va
refinando de acuerdo de las recomendaciones o nuevos requerimientos por
parte del cliente o del usuario final. Las fases de especificacin, desarrollo y
validacin se entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo:
-

Desarrollo exploratorio: Es aquel donde el objetivo del proceso es


trabajar con el cliente para explorar sus requerimientos y entregar un
sistema final. El desarrollo empieza con las partes del sistema que se
comprenden mejor. El sistema evoluciona agregando nuevos atributos
propuestos por el cliente.

Prototipos desechables: Es aquel donde el objetivo del proceso de


desarrollo evolutivo es comprender los requerimientos del cliente y
entonces desarrollar una definicin mejorada de los requerimientos para
el sistema. El prototipo se centra en experimentar con los requerimientos
del cliente que no se comprenden del todo.

Modelo de desarrollo evolutivo

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele


traer ms ventajas en comparacin con un enfoque en cascada ya que el
sistema se va ajustando a las necesidades del cliente, a la vez que l mismo
entiende mejor sus propios requerimientos. Sin embargo, el enfoque evolutivo

desde una perspectiva de ingeniera y gestin suele tener dos grandes


problemas:

El proceso no es visible. Los administradores tienen que hacer entregas


regulares para medir el progreso. Si los sistemas se desarrollan
rpidamente, no es rentable producir documentos que reflejen cada
versin del sistema.

A menudo los sistemas tienen una estructura deficiente. Los cambios


continuos tienden a corromper la estructura del software. Incorporar
cambios en l se convierte cada vez ms en una tarea difcil y costosa.

Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado


para sistemas pequeos y medianos. En los sistemas grandes, los constantes
cambios en el desarrollo solo dificultan la estabilidad y la integracin de los
avances de los distintos grupos de trabajo que puedan existir. La mayora de
las empresas que desarrollan grandes sistemas usan un modelo mixto que usa
las mayores fortalezas de los enfoques evolutivos y de cascada.

5. METODOLOGIAS DE DESARROLLO DE SOFTWARE


5.1. NOMBRES
SCRUM: Scrum es una metodologa gil y flexible para gestionar el desarrollo
de software, cuyo principal objetivo es maximizar el retorno de la inversin para
su empresa (ROI). Se basa en construir primero la funcionalidad de mayor
valor para el cliente y en los principios de inspeccin continua, adaptacin,
auto-gestin e innovacin.
RATIONAL UNIFIED PROCESS (RUP): Es una metodologa cuyo fin es
entregar un producto de software. Se estructura todos los procesos y se mide
la eficiencia de la organizacin, en este proceso de desarrollo de software se
utiliza el lenguaje unificado de modelado UML, el cual constituye la
metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos.
STRUCTURED ANALYSIS AND DESIGN TECHNIQUE (SADT): Es una
tcnica de anlisis y diseo de sistemas que ha sido ampliamente utilizada
para la definicin de sistemas, el anlisis de requisitos de software y el diseo
de sistemas/software consiste en un conjunto de procedimientos que permiten
al analista descomponer las funciones del software (o del sistema)

EXTREME PROGRAMMING (XP): Es una metodologa gil centrada en


potenciar las relaciones interpersonales como clave para el xito en desarrollo

de software, promoviendo el trabajo en equipo, preocupndose por el


aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo.
ENTERPRISE UNIFIED PROCESS (EUP): La metodologa Enterprise Unified
Process, EUP, se basa en la extensin de la metodologa Rational Unified
Process, RUP. Esta extensin se da en dos fases ms y una seccin de
disciplinas de soporte que agrega cuatro disciplinas ms a las que ya cuenta la
metodologa RUP.
AGILE UNIFIED PROCESS (AUP): La metodologia AUP aplica tcnicas giles
incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD),
Modelado gil, Gestin de Cambios gil, y Refactorizacin de Base de Datos
para mejorar la productividad.

5.2. ETAPAS Y ACTIVIDADES


SCRUM: Es una metodologa de desarrollo muy simple, que requiere trabajo
duro porque no se basa en el seguimiento de un plan, sino en la adaptacin
continua a las circunstancias de la evolucin del proyecto.
Scrum es una metodologa gil, y como tal:
-

Es un modo de desarrollo de carcter adaptable ms que predictivo.


Orientado a las personas ms que a los procesos.
Emplea la estructura de desarrollo gil: incremental basada en
iteraciones y revisiones.
Se comienza con la visin general del producto, especificando y dando
detalle a las funcionalidades o partes que tienen mayor prioridad de
desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve
(normalmente de 30 das).
Cada uno de estos periodos de desarrollo es una iteracin que finaliza
con la produccin de un incremento operativo del producto.
Estas iteraciones son la base del desarrollo gil, y Scrum gestiona su
evolucin a travs de reuniones breves diarias en las que todo el equipo
revisa el trabajo realizado el da anterior y el previsto para el da
siguiente.

Que se requiere para aplicar correctamente la metodologa Scrum:


Actores:
-

Product Owner: Representa la voz del cliente. Escribe historias de


usuario, las prioriza, y las coloca en el Product Backlog.
Scrum Master: Protege al equipo de distracciones y de otros elementos
externos (presiones no razonables). Elimina obstculos que alejen al
grupo de la consecucin de objetivos del sprint. No es el lder del grupo,
ya que el grupo se autogestiona.
Equipo: Tiene la responsabilidad de entregar el producto.

Scrum, propone tres herramientas o "artefactos" para mantener organizados


nuestros proyectos. Estos artefactos, ayudan a planificar y revisar cada uno de
los Sprints, aportando medios ineludibles para efectuar cada una de las
ceremonias que veremos en un siguiente captulo.
Describiremos ahora, cada uno de los artefactos, su definicin e importancia
para Scrum:
Backlog de Producto: Es un listado dinmico y pblicamente visible para
todos los involucrados en el proyecto.
En l, el Dueo de Producto, mantiene una lista actualizada de requerimientos
funcionales para el software. Esta lista, representa "qu es lo que se pretende"
pero sin mencionar "cmo hacerlo", ya que esta ltima, como vimos en el
captulo anterior, ser tarea del Scrum Team.
El Backlog de Producto, es creado y modificado nicamente por el Dueo de
Producto. Durante la ceremonia de planificacin, el Scrum Team obtendr los
tems del producto, que deber desarrollar durante el Sprint. Formato del
Backlog de Producto
El Backlog de producto, es una lista de tems que representan los
requerimientos funcionales esperados para el software.
Para cada uno de estos tems, ser necesario especificar:
-

El grado de prioridad
Esfuerzo que demanda
Granulidad
Criterios de aceptacin

Backlog de Sprint: Es la recopilacin sinttica de items del Backlog de


Producto, negociados entre el Dueo de Producto y el Scrum Team en la
ceremonia de planificacin, reunin que se realiza al comienzo del Sprint.
Esta recopilacin, que durante la planificacin ha sido propuesta por el Dueo
de Producto y ya negociada, es aquella que el Scrum Team se compromete a
construir durante el Sprint en curso.
El Backlog de Sprint, generalmente, se visualiza mediante tableros fsicos
tambin llamados Scrum Taskboard que hacen visible el proceso de
construccin, a toda persona que ingrese al rea de desarrollo.
Para armar el Backlog de Sprint, el Scrum Team, divide los items en tareas
tasks de que no demanden una labor superar a una jornada de trabajo. Es
decir, que una tarea, no debera superar las 8 horas de trabajo.
Estas tareas, sern divididas en pendientes, en curso y terminadas y cada una
de ellas, debe permitir visualizar, como mnimo, el esfuerzo que demanda su
construccin y el nombre del miembro del equipo que se ha asignado dicha
tarea.

Es muy frecuente, a la vez de ser una prctica recomendada, que cada tarea
sea a la vez, "etiquetada", diferenciando, por ejemplo, cuando representa un
bug, una tarea de diseo, un test, etc.
Incremento de Funcionalidad: Es el que el equipo entrega al finalizar el
Sprint. El mismo debe asemejarse a un "software funcionando", permitiendo
implementarse operativamente sin restricciones en un ambiente productivo.

RATIONAL UNIFIED PROCESS (RUP): El RUP es un conjunto de


metodologas adaptables al contexto y necesidades de cada organizacin.
Describe cmo aplicar enfoques para el desarrollo del software, llevando a
cabo unos pasos para su realizacin.
Se centra en la produccin y mantenimiento de modelos del sistema.
Sus principales caractersticas son:
-

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).
Ciclo de vida del RUP: El ciclo de vida RUP es una implementacin del
Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias
semi-ordenadas. El ciclo de vida organiza las tareas en 4 fases e iteraciones:
1. Fase de Inicio: Esta fase tiene como propsito definir y acordar el
alcance del proyecto con los patrocinadores, identificar los riesgos
asociados al proyecto, proponer una visin muy general de la
arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
2. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos
de uso que permiten definir la arquitectura base del sistema y se
desarrollaran en esta fase, se realiza la especificacin de los casos de
uso seleccionados y el primer anlisis del dominio del problema, se
disea la solucin preliminar.
3. Fase de Desarrollo: El propsito de esta fase es completar la
funcionalidad del sistema, para ello se deben clarificar los
requerimientos pendientes, administrar los cambios de acuerdo a las
evaluaciones realizados por los usuarios y se realizan las mejoras para
el proyecto.
4. Fase de Cierre: El propsito de esta fase es asegurar que el software
est disponible para los usuarios finales, ajustar los errores y defectos
encontrados en las pruebas de aceptacin, capacitar a los usuarios y
proveer el soporte tcnico necesario. Se debe verificar que el producto
cumpla con las especificaciones entregadas por las personas
involucradas en el proyecto.
La metodologa RUP est constituida por 6 principios claves estos son:
1.
2.
3.
4.
5.
6.

Adaptacin del proceso.


Balancear prioridades.
Colaboracin entre equipos.
Demostrar valor iterativamente.
Elevar el nivel de abstraccin.
Enfocarse en la calidad.

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 (entre otros). Estos artefactos (entre otros) son los
siguientes:

Inicio:
-

Documento Visin
Especificacin de Requerimientos

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

STRUCTURED ANALYSIS AND DESIGN TECHNIQUE (SADT): La


metodologa SADT engloba un conjunto de herramientas automticas de
soporte para los procedimientos de anlisis y un mtodo organizativo bien

definido mediante el que se aplican las herramientas. Quedan especificadas


revisiones y puntos de referencia que permiten una validacin de la
comunicacin entre el cliente y el desarrollador.
Etapas De La Planeacin Estratgica De Sistemas
Para llevar a cabo una planeacin de sistemas se requiere de 3 pasos:
-

Establecer las metas de los sistemas,


Determinar y asignar prioridades a las solicitudes de proyectos de
sistemas.
Evaluar los recursos y la capacidad de los sistemas.

Establecer las metas de los sistemas: Este paso implica la revisin de la


dimensin de las operaciones de la organizacin, las polticas de sistemas y el
plan de la empresa. El objetivo principal es establecer las metas de la
organizacin y enlazarlas con las metas de los sistemas. A partir de esto
empiezan a surgir ideas de proyectos en sistemas para dar soporte a estas
metas. Para dar forma a las ideas de proyectos, se recopila informacin de
entrada de los miembros del equipo, incluyendo informacin de otras personas
que puedan contribuir al proceso de planeacin como consultores y auditores
internos. El proceso de planeacin deber alinear sus actividades con la
estrategia de la empresa, enfocando los proyectos hacia las metas estratgicas
de la compaa e identificando las reas en las que probablemente se
encontraran oportunidades con altos beneficios. A partir de este proceso de
investigacin se plantean metas generales de sistemas de informacin. Estas
metas pueden proponerse como:
-

Diseo e implementacin de sistemas que apoyen a las metas


organizacionales,
Aprovechar las oportunidades de negocios proporcionadas por las
nuevas tecnologas informticas y seguir una metodologa de desarrollo
de sistemas que interacte con los usuarios y proporcione el estado de
los sistemas.

Determinar y asignar prioridades a las solicitudes de proyectos de sistemas.


Durante el paso anterior se tiene una gran comunicacin entre los usuarios y el
personal de sistemas.
A partir de esta interaccin empiezan a formalizarse los proyectos, formado por
algunas ideas de los usuarios como ideas provenientes por el personal de
sistemas. Siendo, en cualquier caso, se producen solicitudes de proyectos de
sistemas y se realiza en un intercambio libre de ideas. Para ello ninguna
compaa, ni su sistema de informacin cuentan con los recursos necesarios
para atender a las solicitudes de proyectos de sistemas, ni todas las solicitudes
son buenas.
El resultado final es un conjunto de diagramas que contienen las actividades
del proceso, cuidadosamente coordinados y organizados en niveles, que
empiezan por el diagrama de nivel ms general y terminan por los de detalle.
Cualquier actividad compleja puede subdividirse en actividades ms detalladas.

Los flujos que interconectan actividades se clasifican en cuatro tipos de


acuerdo a su significado:
-

Entrada: hace referencia a la informacin que se utilizar para producir


las salidas de la actividad. La entrada es transformada por la actividad.
Salida: se trata de informacin que se produce en la actividad.
Control: se trata de restricciones que afectan a una actividad. Regula la
produccin de las salidas a partir de las entradas, pudiendo indicar cmo
y cuando se producen las salidas.
Mecanismo: normalmente se refiere a maquinas, personas, recursos o
sistemas existentes que ejecutan la actividad. Es importante incluir
aquellos mecanismos que sern diferentes en el entorno actual y en el
entorno futuro.

Al incorporar controles que regulan las actividades, los flujos de salida de una
actividad pueden actuar como controles e incluso mecanismos en la actividad
precedente o dependiente.
Los diagramas SADT requieren una serie de puntos de partida:
-

Concretar el tema a tratar.


Asumir un punto de vista determinado.
Fijar un objetivo.

El primero permite definir el mbito dentro y fuera de la organizacin y el


segundo proporciona una gua al construir el modelo. Por ltimo, el objetivo
ayuda a decidir cundo se finaliza en la construccin del modelo.

EXTREME PROGRAMMING (XP): La metodologa de Programacin Extrema


es una de las llamadas Metodologas giles de desarrollo de software ms
exitosas de los tiempos recientes, nace como nueva disciplina de desarrollo de
software.

La programacin extrema se basa en la simplicidad, la comunicacin y el


reciclado continuo de cdigo, para algunos no es ms que aplicar una pura
lgica.
Los Valores originales de la programacin extrema son: simplicidad,
comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor, respeto,
fue aadido en la segunda edicin de Extreme Programming Explained. Los
cinco valores se detallan a continuacin:
-

La Simplicidad: Es la base de la programacin extrema. Se simplifica el


diseo para agilizar el desarrollo y facilitar el mantenimiento. Un diseo
complejo del cdigo junto a sucesivas modificaciones por parte de
diferentes desarrolladores hace que la complejidad aumente
exponencialmente.
La Comunicacin: Se realiza de diferentes formas, para los
Programadores el cdigo comunica mejor cuanto ms simple sea. Si el
cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo
auto-documentado es ms fiable que los comentarios ya que stos
ltimos pronto quedan desfasados con el cdigo a medida que es
modificado. Debe comentarse slo aquello que no va a variar, por
ejemplo, el objetivo de una clase o la funcionalidad de un mtodo.
Las Pruebas Unitarias: son otra forma de comunicacin ya que
describen el diseo de las clases y los mtodos al mostrar ejemplos
concretos de cmo utilizar su funcionalidad. Los programadores se
comunican constantemente gracias a la programacin por parejas. La
comunicacin con el cliente es fluida ya que el cliente forma parte del
equipo de desarrollo. El cliente decide qu caractersticas tienen
prioridad y siempre debe estar disponible para solucionar dudas.
Retroalimentacin feedback: Al estar el cliente integrado en el
Proyecto, su opinin sobre el estado del proyecto se conoce en tiempo
real. Al realizarse ciclos muy cortos tras los cuales se muestran
resultados, se minimiza el tener que rehacer partes que no cumplen con
los requisitos y ayuda a los programadores a centrarse en lo que es ms
importante. Considrense los problemas que derivan de tener ciclos muy
largos. Meses de trabajo pueden tirarse por la borda debido a cambios
en los criterios del cliente o malentendidos por parte del equipo de
desarrollo. El cdigo tambin es una fuente de retroalimentacin gracias
a las Herramientas de desarrollo.
Coraje o valenta: Los puntos anteriores parecen tener sentido comn,
entonces, por qu coraje? Para los gerentes la programacin en
parejas puede ser difcil de aceptar, porque les parece como si la
productividad se fuese a reducir a la mitad ya que solo la mitad de los
programadores est escribiendo cdigo.

Las Cuatro Actividades Bsicas

Ahora que tenemos nuestros cuatro valores estamos preparados para construir
una Disciplina de Desarrollo de software. Qu tareas debemos de llevar a
cabo para desarrollar un buen software?
Codificar: Es la nica actividad de la que no podremos prescindir. Sin cdigo
fuente no hay programa, aunque hay gente que cuenta que existe software en
produccin del que se perdi el cdigo fuente. Por tanto, necesitamos codificar
y plasmar nuestras ideas a travs del cdigo. En una programacin en PX en
pareja el cdigo expresa tu interpretacin del problema, as podemos utilizarlo
para comunicar, para hacer mas tus ideas, y por tanto para aprender y mejorar.
Hacer pruebas: Las caractersticas del software que no pueden ser
demostradas mediante pruebas simplemente no existen. Las pruebas me dan
la oportunidad de saber si lo que implement es lo que en realidad yo pensaba
que haba implementado. Las pruebas nos indican que nuestro trabajo
funciona, cuando no podemos pensar en ninguna prueba que pudiese originar
un fallo en nuestro sistema entonces has acabado por completo.
Escuchar: Los programadores no lo conocemos todo, y sobre todo muchas
cosas que las personas de negocios piensan que son interesantes. Si ellos
pudieran programarse su propio software para qu nos querran? Si vamos a
hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos
que preguntar a quin necesita la informacin.
Disear: El Diseo crea una estructura que organiza la lgica del sistema, un
buen diseo permite que el sistema crezca con cambios en un solo lugar. Los
diseos deben de ser sencillos, si alguna parte del sistema es de desarrollo
complejo, divdela en varias. Si hay fallos en el diseo o malos diseos, estos
deben de ser corregidos cuanto antes.
A continuacin, describimos los artefactos de Xp, entre los que se encuentran:
Historias de Usuario, Tareas de Ingeniera y Tarjetas CRC.
Historias de Usuario
Representan una breve descripcin del comportamiento del sistema, emplea
terminologa del cliente sin lenguaje tcnico, se realiza una por cada
caracterstica principal del sistema, se emplean para hacer estimaciones de
tiempo y para el plan de lanzamientos, reemplazan un gran documento de
requisitos y presiden la creacin de las pruebas de aceptacin.
Estas deben proporcionar slo el detalle suficiente como para poder hacer
razonable la estimacin de cunto tiempo requiere la implementacin de la
historia, difiere de los casos de uso porque son escritos por el cliente, no por
los programadores, empleando terminologa del cliente. "Las historias de
usuario son ms "amigables" que los casos de uso formales".

Tareas de Ingeniera: La siguiente es una breve descripcin de la tarjeta que


contiene los datos mnimos que contiene una tarea de ingeniera.

Tarjetas CRC (Clase - Responsabilidad Colaborador): Estas tarjetas se


dividen en tres secciones que contienen la informacin del nombre de la clase,
sus responsabilidades y sus colaboradores. En la siguiente figura se muestra
cmo se distribuye esta informacin.

ENTERPRISE UNIFIED PROCESS (EUP): La metodologa Enterprise Unified


Process, EUP, se basa en la extensin de la metodologa Rational Unified
Process, RUP. Esta extensin se da en dos fases ms y una seccin de
disciplinas de soporte que agrega cuatro disciplinas ms a las que ya cuenta la
metodologa RUP. La diferencia terica entre RUP y EUP es que la
metodologa RUP se enfoca nicamente en el ciclo de vida del desarrollo de
software, en cambio el EUP cubre el ciclo de vida de la tecnologa de
informacin, es decir, abarca una visin ms amplia que el desarrollo de
software enfocndose en las etapas siguientes a la elaboracin del software,
etapas como por ejemplo la insercin del nuevo sistema en una empresa
donde se cuenta con otro sistema antiguo, para esto se deber de decidir si los
dos sistemas van en paralelo o si uno se retira por completo o en otro caso si
se complementan. Esta descripcin es un pequeo ejemplo de los temas que
se deben de tomar en cuenta fuera de nicamente la elaboracin del software.
Describiendo las fases agregadas por EUP, se podr tener una compresin
ms clara de este tema. Las dos nuevas fases son: La fase de Produccin,
cuyo objetivo principal es mantener un sistema en perfecto estado, permitiendo
que el sistema se encuentre accesible y utilizable por todos los usuarios;
adems, brinda ayuda a usuarios para el manejo del sistema en caso este
presente algn desperfecto, siendo as se recopila esta informacin para poder
preparar una nueva versin del sistema. La fase de Retiro, es la segunda fase
cuyo objetivo es remover el sistema actual implementado en un entorno

empresarial de tal manera que se minimicen los impactos que les puedan
brindar a los usuarios para que continen con sus operaciones empresariales
de una manera normal.
Las disciplinas agregadas por EUP son: La disciplina de Modelamiento de
Negocio Empresarial, la que aparte de modelar el negocio del proyecto en
general se basa en especificar las actividades y procesos empresariales de los
cuales se puede extraer informacin que ayuda para saber que nuevos
procesos o actividades, que no se han tomado en cuenta, se pueden
automatizar.
La disciplina de Administracin del Portafolio se basa en organizar los
pequeos componentes de software, que muchas veces se realizan por
separado, con el fin de unificarlos y administrarlos segn los objetivos que cada
uno de estos tengan. La disciplina de Arquitectura Empresarial est relacionada
a modelos que demuestran cmo funcionan los diferentes tipos de arquitectura,
prototipos y buenas prcticas.
Dentro de esta disciplina se toman en cuenta las arquitecturas de negocio,
aplicacin, datos y red; esto organiza el proyecto a un mayor nivel ya que
dentro de cada arquitectura se especifican diferentes tipos de documentos
asociados a estas cuatro ramas que todo software debe contener.
La disciplina de Estrategia de Re-uso, se basa en reutilizar componentes de
software que son necesitados en ms de un proceso, se toma en cuenta su
documentacin y organizacin por cada proceso empresarial.
La Administracin de Recursos Humanos es una disciplina que apoya a la
organizacin de planes, actividades y calendarios segn responsabilidades al
momento del desarrollo de software, a su vez se toma en cuenta las
interacciones entre los colaboradores del proyecto, es decir formacin de
grupos de trabajo.
La disciplina de Administracin Empresarial se basa en el objetivo principal de
definir cmo una organizacin crea, mantiene y administra informacin fsica
del proyecto a realizar. Finalmente, la ltima disciplina aadida por EUP es la
disciplina Mejora de Procesos de Software, sta asegura que la organizacin
pueda definir, implementar y envolver ms de un proceso apropiado brindando
ayuda para conocer las metas finales de tu proyecto determinadas en base a
tus necesidades de negocio.

AGILE UNIFIED PROCESS (AUP): El Proceso Unificado Agil de Scott Ambler


o Agile Unified Process (AUP) en ingls es una versin simplificada del Proceso
Unificado de Rational (RUP). Este describe de una manera simple y fcil de
entender la forma de desarrollar aplicaciones de software de negocio usando
tcnicas giles y conceptos que an se mantienen vlidos en RUP. El AUP
aplica tcnicas giles incluyendo Desarrollo Dirigido por Pruebas (test driven
development - TDD), Modelado Agil, Gestin de Cambios Agil, y
Refactorizacin de Base de Datos para mejorar la productividad.
El proceso unificado (Unified Process o UP) es un marco de desarrollo software
iterativo e incremental. A menudo es considerado como un proceso altamente
ceremonioso porque especifica muchas actividades y artefactos involucrados
en el desarrollo de un proyecto software. Dado que es un marco de procesos,
puede ser adaptado y la ms conocida es RUP (Rational Unified Process) de
IBM.
AUP se preocupa especialmente de la gestin de riesgos. Propone que
aquellos elementos con alto riesgo obtengan prioridad en el proceso de
desarrollo y sean abordados en etapas tempranas del mismo. Para ello, se
crean y mantienen listas identificando los riesgos desde etapas inciales del
proyecto. Especialmente relevante en este sentido es el desarrollo de
prototipos ejecutables durante la base de elaboracin del producto, donde se
demuestre la validez de la arquitectura para los requisitos clave del producto y
que determinan los riesgos tcnicos.

El proceso AUP establece un Modelo ms simple que el que aparece en RUP


por lo que rene en una nica disciplina las disciplinas de Modelado de
Negocio, Requisitos y Anlisis y Diseo. El resto de disciplinas
(Implementacin, Pruebas, Despliegue, Gestin de Configuracin, Gestin y
Entorno) coinciden con las restantes de RUP.
CICLO DE VIDA DEL PROCESO UNIFICADO AGIL (AUP):

Al igual que en RUP, en AUP se establecen cuatro fases que transcurren de


manera consecutiva y que acaban con hitos claros alcanzados:

Inception(Concepcin): El objetivo de esta fase es obtener una


comprensin comn cliente-equipo de desarrollo del alcance del nuevo
sistema y definir una o varias arquitecturas candidatas para el mismo.
Elaboracin: El objetivo es que el equipo de desarrollo profundice en la
comprensin de los requisitos del sistema y en validar la arquitectura.
Construccin: Durante la fase de construccin el sistema es desarrollado
y probado al completo en el ambiente de desarrollo.
Transicin: el sistema se lleva a los entornos de preproduccin donde se
somete a pruebas de validacin y aceptacin y finalmente se despliega
en los sistemas de produccin.

Las disciplinas se llevan a cabo de manera sistemtica, a la definicin de las


actividades que realizan los miembros del equipo de desarrollo a fin de
desarrollar, validar, y entregar el software de trabajo que responda a las
necesidades de sus interlocutores. Las disciplinas son:
1. Modelo. El objetivo de esta disciplina es entender el negocio de la
organizacin, el problema de dominio que se abordan en el proyecto, y
determinar una solucin viable para resolver el problema de dominio.

2. Aplicacin. El objetivo de esta disciplina es transformar su modelo (s) en


cdigo ejecutable y realizar un nivel bsico de las pruebas, en particular, la
unidad de pruebas.
3. Prueba. El objetivo de esta disciplina consiste en realizar una evaluacin
objetiva para garantizar la calidad. Esto incluye la bsqueda de defectos,
validar que el sistema funciona tal como est establecido, y verificando que se
cumplan los requisitos.
4. Despliegue. El objetivo de esta disciplina es la prestacin y ejecucin del
sistema y que el mismo este a disposicin de los usuarios finales.
5. Gestin de configuracin. El objetivo de esta disciplina es la gestin de
acceso a herramientas de su proyecto. Esto incluye no slo el seguimiento de
las versiones con el tiempo, sino tambin el control y gestin del cambio para
ellos.
6. Gestin de proyectos. El objetivo de esta disciplina es dirigir las actividades
que se lleva a cabo en el proyecto. Esto incluye la gestin de riesgos, la
direccin de personas (la asignacin de tareas, el seguimiento de los
progresos, etc), coordinacin con el personal y los sistemas fuera del alcance
del proyecto para asegurarse de que es entregado a tiempo y dentro del
presupuesto.
7. Entorno. El objetivo de esta disciplina es apoyar el resto de los esfuerzos por
garantizar que el proceso sea el adecuado, la orientacin (normas y
directrices), y herramientas (hardware, software, etc) estn disponibles para el
equipo segn sea necesario.

INCREMENTO Y DESARROLLO DE AUP:


Los equipos de AUP suelen ofrecer versiones de desarrollo al final de cada
iteracin en preproduccin rea (s). Una versin de desarrollo de una
aplicacin es algo que podran ser liberados en la produccin si se ponen a
travs de su pre-produccin de garanta de calidad (QA), las pruebas y los
procesos de despliegue. La primera produccin de liberacin a menudo toma
ms tiempo para entregar versiones posteriores.
La primera produccin de liberacin puede tomar doce meses para entregar la
segunda versin de nueve meses, y luego otras liberaciones se entregan cada
seis meses. Una de las primeras se centra en cuestiones de despliegue, no
slo permite evitar los problemas, sino que tambin permite tomar ventaja de
sus experiencias durante el desarrollo. Por ejemplo, cuando despliegue un
software en su rea deber tomar notas de lo que funciona y lo que no, toma
nota de que puede servir como la columna vertebral de su instalacin de
scripts.

PRINCIPIOS DE LA AUP:
La AUP es gil, porque est basada en los siguientes principios:
1. El personal sabe lo que est haciendo. La gente no va a leer detallado el
proceso de documentacin, pero algunos quieren una orientacin de alto nivel
y / o formacin de vez en cuando. La AUP producto proporciona enlaces a
muchos de los detalles, si usted est interesado, pero no obliga a aquellos que
no lo deseen.
2. Simplicidad. Todo se describe concisamente utilizando un puado de
pginas, no miles de ellos.
3. Agilidad. gil ARRIBA El ajuste a los valores y principios de la Alianza gil.
4. Centrarse en actividades de alto valor. La atencin se centra en las
actividades que se ve que son esenciales para el de desarrollo, no todas las
actividades que suceden forman parte del proyecto.
5. Herramienta de la independencia. Usted puede usar cualquier conjunto de
herramientas que usted desea con el gil UP. Lo aconsejable es utilizar las
herramientas que son las ms adecuadas para el trabajo, que a menudo son
las herramientas simples o incluso herramientas de cdigo abierto.
6. Adaptacin de este producto para satisfacer sus propias necesidades. La
AUP producto es de fcil acomodo comn a travs de cualquier herramienta de
edicin de HTML. No se necesita comprar una herramienta especial, o tomar
un curso, para adaptar la AUP.

6. ESTANDARES
6.1 IEEE-STD-830: ESPECIFICACIONES DE REQUERIMIENTOS DEL
SISTEMA
La IEEE 830 se centra en el anlisis y desarrollo de requerimientos, es un
documento en el cual se integran los requerimientos del sistema desde
cualquier punto de vista (usuario, cliente y desarrollador), se crea con la base
fundamental de no caer en errores que permitan poner en peligro el proyecto,
incurriendo en coste o impidiendo la entrega estimada de dicha solucin.
Se debe considerar que el ERS (Especificaciones de requerimientos del
sistema) debe comprender la totalidad de los requerimientos funcionales y no
funcionales, estableciendo un acuerdo entre el cliente y el desarrollador, es una
base fundamental en el desarrollo del software. Es decir el desarrollador exige
detalladamente que debe hacer el software, exigiendo paramtricamente Qu
debe hacer el programa?, Cules son los parmetros de entrada y de salida
que intervienen en el proceso?, En qu maquina van a ser ejecutados los
procesos? y Qu tipos de usuarios directa o indirectamente intervendrn en el
sistema?; todas estas preguntas determinan que la satisfaccin del cliente se
adapte a lo que exigi al principio.
Un ejemplo de aplicacin, se puede considerar que en la documentacin de las
tesis de grado para las carreras enfocadas a los sistemas de informacin, la
mayora de universidades exigen una documentacin en donde se analizan los
requerimiento de la empresa cuando se habla de una pasanta en donde se va
a la etapa de levantamiento de informacin en donde se solicita los
requerimientos que se darn para las pautas de la solucin final.
Para ms claro un ejemplo de una tesis de grado de Cedeo Lolima en donde
se especifican los requisitos funcionales y no funcionales para un sistema de
automatizacin de los servicios administrativos en el rea de medicina de la
Universidad de Oriente- Ncleo Monagas.

Requisitos Funcionales del Sistema

Requisitos No funcionales del Sistema


Tomado de https://docs.google.com/viewer?
a=v&pid=sites&srcid=dWRvLmVkdS52ZXxhZHNpfGd4OjE5MDRjYmQxNjFiZjY4OTI

6.2 SPICE/ISO/IEC15504: DETERMINACIN DE LA CAPACIDAD DE


MEJORA DEL PROCESO DE SOFTWARE
La norma ISO 15504 es utilizada para mejorar la capacidad y madurez de los
procesos, en donde se evalan los actividades primarias, de soporte y de
organizacin que intervienen en un software, gestionando los recursos y
dimensionando la capacidad al momento de la evaluacin con el fin de llegar a
una optimizacin accediendo a diferentes niveles de madurez.
Aplicando estas tcnicas estandarizadas se obtienen ventajas que aportan a
las empresas un buen desarrollo y mantenimiento.
Componentes
Esta norma se conforma por un conjunto de actividades que interviene en el
proceso completo de desarrollo de un software, desde la definicin y
entendimiento del problema a automatizar hasta la entrega y demostracin del
mismo.

Niveles de madurez establecidos en la Norma ISO 15504

Aplicacin
Un ejemplo de la aplicacin se puede ver en el documento Una aplicacin de
la norma ISO/IEC 15504 para la evaluacin por niveles de madurez de Pymes
y pequeos equipos de desarrollo, desarrollado por Javier Garzas, Carlos
Manuel Fernandez y Mario Piatinni en la Universidad Autnoma del Estado de
Mxico, en donde se buscaba minimizar los problemas que en la actualidad
PYMEs y pequeos grupos tienen para la bsqueda de mejorar los proceso
con las organizaciones asociadas a procesos de software indexadas.
El documento completo se puede encontrar
http://www.redalyc.org/articulo.oa?id=92217153012 .

en

la

siguiente

url:

6.3 ISO/IEC 12207: CICLO DE VIDA DEL PROCESO DEL SOFTWARE


La norma 12207 est orientada a los procesos de ciclo de vida del software,
establece actividades que se aplican desde la definicin de requisitos hasta la
finalizacin del uso del servicio del sistema, su objetivo principal es esclarecer
un lenguaje de uso comn para todo tipo de individuo que intervenga en la
solucin final.
Componentes
Este estndar fue concebido a partir del inters de la adquisicin de software,
el software indica una serie de procesos, entre la recoleccin de requisitos
especficos del sistema hasta la culminacin del software, estos procesos se
agrupan en tres categoras:
-

Procesos principales: Son los promotores para mejorar las funciones en


el ciclo de vida.

Procesos de apoyo: Identifica una necesidad, prepara la solicitud y


selecciona un proveedor
Procesos organizativos: Determina procesos y recursos para gestionar
el proyecto.

Vista General de los procesos y subdivisin de procesos en el ciclo de vida de software

Aqu se entiende la estructura general de subdivisin de un proceso. El cada


proceso de ciclo vida, el cual est dividido en un con junto de actividades, en el
cual cada uno est conformado por un conjunto de tareas para ser llevadas a
cabo secuencialmente. Su estructura se basa en el principio de modularidad,
que pretende establecer procesos con un mnimo de acoplamiento y una
mxima cohesin y de responsabilidad, el cual busca establecer un grupo para
cada proceso, facilitando la aplicacin de propiedades, en los cuales pueden
intervenir uno o ms individuos.
Aplicacin
Aunque la mayora de veces esta norma se aplica a los diferentes proyectos
uno lo plasman Francisco J. Pino, Flix Garca, Francisco Ruiz, Mario Piattini
en el artculo Adaptacin de las Normas ISO/IEC 12207:2002 e ISO/IEC
1504:2003 para la Evaluacin de la Madure de Procesos Software en Pases
en Desarrollo, en donde se especifica un modelo para motivar a las micro,

pequea y medianas empresas del sector encargado para la produccin de


software y en general al gremio computo-informtico, a mejorar sus procesos
de desarrollo con el objetivo de garantizar para ellas misma un nivel de
madurez en sus procesos internos de divisin de plan de trabajo, y de forma un
poco especifica esclarecer un modelo de calidad que les permita mantener un
reconocimiento que les permita una mejor competencia internacional, por lo
cual es de vital importancia esclarecer sus mejores caractersticas y
compararlas con modelos internacionales que reconocidos por tu optimizacin
hacia el mejoramiento, evaluacin y calidad.
6.4 IEEE STD 730 PLAN DE ASEGURAMIENTO DE LA CALIDAD DEL
SOFTWARE
Es el proceso por el cual se desarrolla un plan de calidad para desarrollar un
proyecto determinado, esto define la calidad del software y describe como
valorarla. Aunque medir la calidad del software es difcil por la complejidad que
lleva se desarrollaron pautas que nos hacen asegurar la calidad del software.
Este estndar es una recomendacin, para aplicar la SQA (Saber, Querer
Saber y Aprendido), verificando el coste que puede desvariar en componentes
que permiten asegurar:
-

La minimizacin de errores en la ejecucin por parte del usuario


Satisfaccin del cliente
Cumplimiento de los requisitos extrnsecos, expresos e intrnsecos
La cercana a la visin de todo tipo de usuario

Para esto tenemos que basarnos en diagramas de adaptacin de series de


pasos, que permiten establecer procesos que aseguren la calidad de software
(Plan SQA)

Diagrama general de asegurar la calidad del software

Componentes
Propsito: Se debe especificar con claridad cul es el propsito del plan en el
desarrollo del proyecto especfico analizado la ubicacin del proyecto, la
organizacin y los estndares que se usaran.
Referencias: Es donde se establecen las referencias que se usaran en el
proyecto, implica la documentacin que se us en el desarrollo de un buen
escrito, hacer un llamado a los estndares que se estn usando a su vez
informacin adicional que se utiliz de manera implcita.
Roles y Responsabilidades: Identifica personas responsables de cada uno de
los procesos, indicando nombres el rol que poseen y una especificacin de las
actividades de las cuales son responsables dentro del proyecto.
Documentacin: En esta parte se especificada de manera clara y objetiva
toda la informacin que se generara en cada fase del proyecto, esto nos ayuda
a especificar en cada parte del proyecto la informacin que se est generando.
Estndares, prcticas, convenciones y mtricas: Se especifican los
estndares que se usaran, definir las mtricas y la forma en la cual se
obtendrn, tambin solamente se especifican como se usara cada estndar en
cada parte.
Revisiones y auditorias: Se indica el momento y los elementos que se
estarn revisando durante el proyecto, aqu es donde verificamos por los
cuales aseguramos la calidad y verificar los roles que son los encargados uno a
uno.
Reporte de problemas: Especificar los problemas de calidad y la persona
indicada para reportarlos, adems de especificar un mecanismo de resolucin,
aqu se puede verificar de manera preventiva ayudando la calidad del producto,
las personas encargadas y como trabajan.
Tcnicas, herramientas y metodologas: Especifican la metodologa que se
usaran dentro del proyecto, mirando un plan de trabajo. Se indican las
herramientas que se usaran junto con las tcnicas que ayudaran para el
cumplimiento de la metodologa del trabajo.
Mecanismo de control: Indica los mecanismos para asegurar que cada etapa
se lleva a cabo en el tiempo previsto, se verifican las especificaciones de cada
proceso.
Aplicacin
La revista de la Escuela de Administracin de Negocios describi en 1999 una
seccin en donde Saulo Ernesto Rojas Salamanca especificaba la Calidad del
Software en la Industria de la Informtica, donde se ha especificado las
caractersticas del Plan de Aseguramiento de Calidad para intervenir con las
tcnicas de ingeniera, para complementar los modelos para el mejoramiento
de la teora de software.
7. MODELOS DE EVALUACIN DE CALIDAD DE SOFTWARE

7.1. MODELO DE McCALL


Fue el primer modelo, presentado en el 1977 y se origin motivado por
Air Forc y Dod. Este modelo se focaliza en el producto final identificando
atributos claves desde el punto de vista del cliente, a su vez estos atributos se
denominan factores de calidad y son normalmente atributos externos pero
tambin se incluyen algunos atributos internos.
Los factores de calidad son demasiados abstractos para ser medidos
directamente, por lo que por cada uno de ellos se introduce atributos de bajo
nivel denominados criterios de calidad, para los cuales, algunos son atributos
internos, lo cual refleja la creencia de McCall que el atributo interno tiene un
efecto directo en el atributo externo correspondiente.
El modelo de McCall organiza los factores de calidad en tres perspectivas, ver
figura 1, desde los cuales el usuario puede contemplar la calidad de un
producto:

Revisin del producto, habilidad para ser cambiado.


Transicin del producto, adaptabilidad al nuevo ambiente.
Operacin del producto, caractersticas de operacin.

Figura 1. Estructura modelo de McCall, tomada de http://vanevargas.jimdo.com/m


%C3%B3dulos/modelos/modelo-de-mccall/

La revisin del producto incluye los siguientes factores de calidad:

Mantenibilidad: Esfuerzo requerido para localizar y corregir fallas, McCall


incluye en el factor de mantenibilidad criterios como la consistencia,
simplicidad, concisidad, auto-descripcin y la modularidad.

Flexibilidad: Facilidad de realizar cambios, el cual incluye factores como


la expansibilidad, generalidad, auto-descripcin y modularidad.

Testeabilidad: Facilidad para realizar el testing, para asegurarse que el


producto no tiene errores y cumple con la especificacin. Este factor
incluye criterios como la simplicidad y la instrumentacin.

La transicin del producto incluye los siguientes factores de calidad:

Portabilidad: Esfuerzo requerido para transferir entre distintos ambientes


de operacin. Contiene criterios como la auto-descripcin, modularidad,
independencia de la mquina y del sistema operativo.

Reusabilidad: Facilidad de reusar el software en diferentes contextos,


este factor contiene los mismos criterios de la portabilidad.

Interoperabilidad: Esfuerzo requerido para acoplar el producto con otros


sistemas. Sus criterios son la modularidad, la interoperabilidad en
comunicacin y en los datos.

La operacin del producto incluye los siguientes factores:

Correctitud: Grado en el que el producto cumple con su especificacin.


Cuenta con criterios como la trazabilidad, completitud y la consistencia.

Confiabilidad: Habilidad del producto de responder ante situaciones no


esperadas. Contiene criterios como la tolerancia a errores, la
consistencia, simplicidad y exactitud.

Eficiencia: Uso de los recursos tales como tiempo de ejecucin y


memoria de ejecucin. Sus criterios son la eficiencia en tiempo y
espacio.

Integridad: Proteccin del programa y sus datos de accesos no


autorizados. Cuenta con criterios de control de acceso y auditoria de
acceso.

Usabilidad: Facilidad de operacin del producto por parte de los


usuarios. Contiene criterios como la operabilidad, entrenamiento,
comunicacin, volumen de E/S y tasa de E/S.

7.2. MODELO DE BOEHM

Es el segundo modelo de calidad ms conocido, fue presentado por Barry


Boehm en 1978, este modelo introduce caractersticas de alto nivel,
caractersticas de nivel intermedio y caractersticas de bajo nivel, ver Figura 2,
cada una de las cuales contribuye al nivel general de calidad.
Utilidad
Mantenibilidad
Utilidad general

Alto nivel

Modelo de
Boehm

Nivel
intermedio

Bajo nivel

Portabilidad, }
Confiabilidad,
Eficiencia, Usabilidad,
Testeabilidad, Facilidad de
entendimiento, flexibilidad
Independencia, Autocontencin, Auto-contencin
Exactitud, Completitud,
Consistencia,
Robustez/integridad,
Accesibilidad, Eficiencia,
Comunicacin, Auto
descripcin, Estructuracin,
Legibilidad, Aumentabilidad

Figura2. Estructura modelo de Boehm

Las caractersticas de alto nivel representan requerimientos generales de uso,


los cuales pueden ser:

Utilidad per-se: cuan (usable, confiable, eficiente) es el producto en s


mismo.
Mantenibilidad: cuan fcil es modificarlo, entenderlo y retestearlo.
Utilidad general: si puede seguir usndose si se cambia el ambiente.

Las caractersticas de nivel intermedio representan los factores de calidad de


Boehm:

Portabilidad (utilidad general)


Confiabilidad (utilidad per-se)
Eficiencia (utilidad per-se)
Usabilidad (utilidad per-se)
Testeabilidad (mantenibilidad)
Facilidad de entendimiento (mantenibilidad)
Modificabilidad o flexibilidad (mantenibilidad)

El nivel ms bajo corresponde a caractersticas directamente asociadas a una o


dos mtricas de calidad.
De portabilidad:

Independencia de dispositivos
Auto-contencin

De confiabilidad:

Auto-contencin
Exactitud
Completitud

Consistencia
Robustez/integridad

De eficiencia

Accesibilidad
Eficiencia de uso de dispositivos

De usabilidad

Robustez/integridad
Accesibilidad
Comunicacin

De testeabilidad

Comunicacin
Auto descripcin
Estructuracin

De entendibilidad

Consistencia
Estructuracin
Concisidad
Legibilidad

De modificabilidad

Estructuracin
Aumentabilidad

8. ELEMENTOS DE UN PROYECTO DE DESARROLLO DE SOFTWARE

Programas: que cuando se ejecutan realizan una o varias funciones con


el rendimiento esperado.
Documentacin: que describe el funcionamiento, la estructura,
operacin y uso de los programas.
Estructura de datos:
que permiten que los programas manipulen
adecuadamente la informacin.
Personas: las encargadas de ejecutar y desarrollar cada una de las
etapas del proyecto de software.
Tiempo: encargado de delimitar los lapsos de cada uno de las etapas
del ciclo de vida, tareas y la totalidad del proyecto.
Dinero: el cual proveer para cada uno de los gastos de las personas, y
cubrir los riesgos a lo largo de cada etapa del proyecto.

9. CONCLUSIONES

Para entender mejor la ingeniera de software primero es necesario


analizar cada parte de lo que se quiere llevar a cabo y las razones de
porque la calidad interviene en la cuantificacin del proyecto, el
desarrollo de la aplicacin y el manteniendo de un software.

La calidad de un producto ya no est centrada solo en la satisfaccin del


cliente, la evolucin de la calidad ahora nos permite y exige tener un
producto de calidad debido a un proceso y una gestin que es necesario
llevar a cabo. La calidad debe estar implcita en cada rea y proceso de
la empresa y no as solo en el producto final.

Para lograr que las empresas produzcan productos de calidad deben


regirse a normas y estndares a nivel mundial, para ello hay
organizaciones dedicadas a elaborar modelos y parmetros que
permiten lograr una mayor calidad para la empresa. Una de ellas son las
normas ISO, reconocidas internacionalmente y estn siempre en un
proceso de mejora continua para garantizar que las empresas
certificadas por dichas normas ofrezcan al usuario final un producto o
servicio de calidad.

10. BIBLIOGRAFIA
http://www.cc.uah.es/drg/b/HispaSWEBOK.Borrador.pdf
http://www.etsisi.upm.es/estudios/grados/software/objetivos
http://ingenieriasoftbejarano.blogspot.com.co/2012/10/caracteristicas-y-tiposde-software.html
https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software#Historia
http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarrollo
%20software.pdf
http://vanevargas.jimdo.com/m%C3%B3dulos/modelos/modelo-de-mccall/
http://www.cs.uns.edu.ar/~prf/teaching/SQ07/clase6.pdf
http://image.slidesharecdn.com/iso15504web-101229173148phpapp01/95/isoiec-15504-introduccin-a-la-norma-de-evaluacin-de-procesosde-software-13-728.jpg?cb=1293643937
https://es.wikipedia.org/wiki/Modelo_de_evaluaci
%C3%B3n_de_procesos_software_ISO_15504_SPICE
https://prezi.com/jiybg8h9q3mx/estandares-ansiieee-730-1984-y-983-1986/
http://www.radikewl.com/5055484.html
http://www.ati.es/gt/calidad-sftware/presentacion.htm
http://www.ceisufro.cl/investigacion/lineas-de-investigacion/
http://www.ecured.cu/ISO_15504
http://www.iso15504.es/
http://juanmarcosteoria2.blogspot.com.co/2008/01/normas-iso-12207.html
http://es.slideshare.net/oprbguitar/norma-tecnica-peruana-iso-12207
http://unfviso12207.webcindario.com/index.php?mod=proceso_organizativos
http://es.ccm.net/contents/223-ciclo-de-vida-del-software
http://html.rincondelvago.com/el-ciclo-de-vida-del-software.html
http://www.ecured.cu/Modelo_Espiral
http://ingenieraupoliana.blogspot.com.co/2010/10/modelo-de-desarrolloconcurrente.html
http://tema3isoftware.blogspot.com.co/p/modelos-de-desarrollo-tecnicas-y.html
https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologiascrum.html
https://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
http://e.exam-10.com/doc/10444/index.html?page=7
http://ingenieriadesoftware.mex.tl/63758_AUP.html
http://www.monografias.com/trabajos6/sista/sista.shtml
http://www.desarrolloweb.com/articulos/artefactos-scrum.html
http://www.ecured.cu/Programaci%C3%B3n_Extrema_(XP)
http://es.slideshare.net/joseluisdifu/proceso-unificado-gil-aup-17171038
https://prezi.com/24dgrrbjbn91/norma-iso-12207/
https://prezi.com/8ohm8mnwrujq/norma-internacional-iso-iec-122072008/
http://www.monografias.com/trabajos99/articulo-ntp-iso-iec-12207/articulo-ntpiso-iec-12207.shtml
http://tecnomaestros.awardspace.com/estandares_iso.php

http://seispice.blogspot.com.co/2012/05/spiceiso-iec-15504-norma-spiceisoiec.html
http://www.redalyc.org/articulo.oa?id=92217153012
http://geekswithblogs.net/dthakur/archive/2004/09/02/10570.aspx
http://ieee730.blogspot.com.co/
https://standards.ieee.org/findstds/standard/730-2014.html
https://prezi.com/jiybg8h9q3mx/estandares-ansiieee-730-1984-y-983-1986/
http://es.slideshare.net/Juan_Tapias/formato-ieee830srs-lleno
http://www.academia.edu/6647065/Especificaci
%C3%B3n_de_Requisitos_Software_seg%C3%BAn_el_est
%C3%A1ndar_de_IEEE_830
http://es.slideshare.net/mrcordova/ciclo-de-vida-del-software-ieee12207-2011
http://pfsanchez.blogspot.com.co/2007/01/ingeniera-de-software-estndaresdel.html
http://ocw.uc3m.es/ingenieria-telematica/software-decomunicaciones/transparencias/introduccion-a-la-ingenieria-del-software
http://www.monografias.com/trabajos5/inso/inso.shtml
http://es.slideshare.net/soreygarcia/introduccin-a-la-ingenieria-de-software14023309
http://www.siigroup.es/pfw_files/cma/Website/Site_ESP/nuestra_actividad/sprint
.png
http://humanos.uci.cu/wp-content/uploads/2010/03/RUP.png
http://www.opentrends.net/image/image_gallery?uuid=6eeb5c22-26ef-4a1e9f41-299ab942e964&groupId=10156&t=1361534289835
https://lh4.googleusercontent.com/aNCCbl6q23ANOXaakUSLVS9GLperwEuRe
glpkVw23-GijbUaw9EY9l89IuwoG4jloIKRJUJ9ZFghEg95ed41oCQkB3h51eHhw2e-0LURqy9_g_dtjKzqJ3c
https://www.youtube.com/watch?v=8iL-U1ONFJ8
https://www.youtube.com/watch?v=rwTrlieEcuQ