TRABAJO INVESTIGATIVO #2

INGENIERIA DE SOFTWARE
Descripcin breve
El trabajo consiste en realizar una investigacin rigurosa sobre los diferentes
elementos que se deben tener en cuenta en el desarrollo de un producto de
software.

Julin David Mrquez Fuentes

20122078213

INTRODUCCION

La ingeniera de software es una disciplina formada por un conjunto de

mtodos, herramientas y tcnicas que se utilizan en el desarrollo de los
programas informticos.
Esta disciplina trasciende la actividad de programacin, que es el pilar
fundamental a la hora de crear una aplicacin. El ingeniero de software se
encarga de toda la gestin del proyecto para que ste se pueda desarrollar en
un plazo determinado y con el presupuesto previsto.
La ingeniera de software, por lo tanto, incluye el anlisis previo de la situacin,
el diseo del proyecto, el desarrollo del software, las pruebas necesarias para
confirmar su correcto funcionamiento y la implementacin del sistema.
Cabe destacar que el proceso de desarrollo de software implica lo que se
conoce como ciclo de vida del software, que est formado por cuatro etapas:
concepcin, elaboracin, construccin y transicin.
La concepcin fija el alcance del proyecto y desarrolla el modelo de negocio; la
elaboracin define el plan del proyecto, detalla las caractersticas y fundamenta
la arquitectura; la construccin es el desarrollo del producto; y la transicin es
la transferencia del producto terminado a los usuarios.
Una vez que se completa este ciclo, entra en juego el mantenimiento del
software. Se trata de una fase de esta ingeniera donde se solucionan los
errores descubiertos (muchas veces advertidos por los propios usuarios) y se
incorporan actualizaciones para hacer frente a los nuevos requisitos. El
proceso de mantenimiento incorpora adems nuevos desarrollos, para permitir
que el software pueda cumplir con una mayor cantidad de tareas.

CONCEPTOS
Ingeniera de Software
La Ingeniera de Software es aquella disciplina que se ocupa del desarrollo, la
operacin y el mantenimiento del software o programas informticos.
Cabe destacarse que es preciso estudiar tanto los principios como las
metodologas para llevar a cabo estas acciones mencionadas, en tanto, la
disposicin de ese conocimiento es lo que permitir el diseo y la construccin
de programas informticos con los cuales se pueda operar de modo
satisfactorio en las diversas computadoras personales.
Entonces, la ingeniera de software implica un trabajo integral, es decir, se
produce un anlisis del contexto, se disea el proyecto, se desarrolla el
correspondiente software, se efectan las pruebas para asegurar su correcto
funcionamiento y finalmente se implementa el sistema.

El proceso de desarrollo de un software se denomina formalmente como ciclo

de vida del software, en tanto, se encuentra conformada por cuatro estadios:
concepcin (en esta se fijan los objetivos y se desarrolla el modelo),
elaboracin (en este paso se establecen las caractersticas y cmo ser la
arquitectura del mismo y porqu), construccin (implica el desarrollo del
programa) y transicin (es el momento en el cual se transfiere el producto final
al usuario).
Una vez que el software est activo y funcionando es donde cobrar relevancia
el mantenimiento de este mismo. Generalmente, suelen aparecer errores en al
disear el programa, por este caso, es el mantenimiento el que permitir
solucionarlos cuando los usuarios lo reporten. Normalmente se proponen
actualizaciones y se desarrollan nuevos elementos con la misin de reparar los
errores aparecidos.
Al individuo que se desempea profesionalmente en esta rea se lo denomina
como ingeniero de software. La primera y principal tarea que tienen estos
profesionales es el estudio de todas las condiciones que deber observar un
programa antes de su desarrollo para de esta manera satisfacer las demandas
de los consumidores pero sin olvidarse de las posibilidades con las que cuenta
la compaa desarrolladora.

Objetivos de la ingeniera de software

mejorar la calidad de los productos de software

aumentar la productividad y trabajo de los ingenieros del software.

Facilitar el control del proceso de desarrollo de software.

Dar a los desarrolladores, las bases para construir software de alta

calidad en una forma eficiente.

Definir una disciplina que garantice la produccin y el mantenimiento de

los productos software desarrollados en el plazo fijado y dentro del costo
estimado.
PROYECTO DE SOFTWARE

Es el proceso de gestin para la creacin de un sistema o software, la cual

encierra un conjunto de actividades, una de las cuales es la estimacin;
estimacin es una actividad importante que no debe llevarse a cabo de forma
descuidada. Existen tcnicas tiles para la estimacin de costes de tiempo. Y
dado que la estimacin es la base de todas las dems actividades de
planificacin del proyecto y sirve como gua para una buena Ingeniera de
Sistemas y Software.
Al estimar hay que tomar en cuenta no solo el procedimiento tcnico a utilizar
en el proyecto sino que se toma en cuenta los recursos costos y planificacin.
El tamao del proyecto es otro factor importante que puede afectar las
estimaciones. A medida que el tamao aumenta, crece rpidamente la
interdependencia entre varios elementos del software.
Objetivos de la Planificacin del Proyecto
Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones
razonables de recursos costos y planificacin temporal. Estas estimaciones se
hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de
software, y deberan actualizarse regularmente a medida que avanza el
proyecto.
Tareas de Planificacin:

mbito del Software: En esta etapa se deben evaluar la funcin y el

rendimiento que se asignaron al software. El mbito se define como un
pre-requisito para la estimacin.

Recursos: Es la segunda tarea de la planificacin del desarrollo de

Software es la estimacin de los recursos requeridos para acometer el
esfuerzo de desarrollo de Software.

Cada recurso queda especificado mediante 7 caractersticas:

Descripcin del recurso

Informes de disponibilidad
Fecha cronolgica en la que se requiere el recurso
Tiempo durante el que ser aplicado el recurso
Recursos Humanos: La cantidad de personas requeridas para el
desarrollo de un proyecto de software solo puede ser determinado
despus de hacer una estimacin del esfuerzo del desarrollo.
Recursos de Componentes de Software Reutilizables: Cualquier estudio
sobre recursos de software estara incompleto sin estudiar la reutilizacin,
esto es la creacin y reutilizacin de bloques de construccin de software.
Recursos de Entorno: El entorno es donde se apoya el proyecto de
software, llamado a menudo entorno de Ingeniera de Software, incorpora
software y hardware.

Modelos de Estimacin

Modelos Empricos Donde los datos que soportan la mayora de los

modelos de estimacin obtienen una muestra limitada de proyectos. Por
esta razn el modelo de estimacin no es el adecuado para todas las
clases de software.

El Modelo COCOMO:

Modelo Constructivo de Costos

Modelo I: El modelo COCOMO bsico calcula el esfuerzo y el costo de
desarrollo de software en funcin del tamao del programa expresado en
las lneas estimadas.
Modelo II: El modelo COCOMO intermedio calcula el esfuerzo del
desarrollo de software en funcin del tamao del programa y de un
conjunto de conductores de costos que incluyen la evaluacin subjetiva
del producto, del hardware, del personal y de los atributos del proyecto.

Modelo III: Modelo COCOMO avanzado:

Incorpora las caractersticas de la versin intermedia y lleva a cabo una
evaluacin del impacto de los conductores de costos en cada caso anlisis
diseo y otros del proceso de ingeniera de software.

Caractersticas del Software:

Las mtricas del software se refieren a un gran rango de medidas para
el software de computadoras dentro del contexto de la planificacin del
proyecto de software, las mtricas de calidad pueden ser aplicadas a
organizaciones, procesos y productos los cuales directamente afectan a
la estimacin de costos, estas mtricas son las siguientes:

Mtricas de Productividad: Se centran en el rendimiento del proceso de

la Ingeniera de Software.

Mtricas de Calidad: Proporcionan una indicacin de cmo se ajusta el

software, a los requerimientos implcitos y explcitos del cliente.
Mtricas Tcnicas: Se centran en el carcter del software ms que en el
proceso, a travs del cual el software ha sido desarrollado.

Mtricas Orientadas al Tamao: Son utilizadas para obtener medidas

directas del resultado y la calidad de la ingeniera del software.
Mtricas Orientadas a la Funcin: Son medidas indirectas del software y
del proceso por el cual se desarrollar; se centran en la funcionalidad o
utilidad del programa los llamados puntos de funcin.
Mtricas Orientadas a las Personas: Consiguen informacin sobre la
forma en que la gente desarrolla software de computadora y sobre el
punto de vista humano de la efectividad de las herramientas y mtodos.

MODELO
Modelo En Cascada:
ste toma las actividades fundamentales del proceso de especificacin,
desarrollo, validacin y evolucin y las representa como fases separadas del
proceso.
El modelo en cascada consta de las siguientes fases:
1. Definicin de los requisitos: Los servicios, restricciones y objetivos son
establecidos con los usuarios del sistema. Se busca hacer esta definicin en
detalle.
2. Diseo de software: Se particiona el sistema en sistemas de software o
hardware. Se establece la arquitectura total del sistema. Se identifican y
describen las abstracciones y relaciones de los componentes del sistema.
3. Implementacin y pruebas unitarias: Construccin de los mdulos y unidades
de software. Se realizan pruebas de cada unidad.
4. Integracin y pruebas del sistema: Se integran todas las unidades. Se
prueban en conjunto. Se entrega el conjunto probado al cliente.
5. Operacin y mantenimiento: Esta es la fase ms larga. El sistema es puesto
en marcha y se realiza la correccin de errores descubiertos. Se realizan
mejoras de implementacin. Se identifican nuevos requisitos.
Una fase no comienza hasta que termine la fase anterior y generalmente se
incluye la correccin de los problemas encontrados en fases anteriores.

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.
Modelo Evolutivo:
La idea detrs de este modelo es el desarrollo de una implantacin del sistema
inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta
que se desarrolle el sistema adecuado. En la Figura se observa cmo las
actividades concurrentes: especificacin, desarrollo y validacin, se realizan
durante el desarrollo de las versiones hasta llegar al producto final.

Ventaja: es que es ideal para sistemas que no tiene bien definidos los
requerimientos, es decir, para la mayora de los sistemas que se desarrollan. El
cliente desde el principio tiene una idea de los requerimientos de su sistema,
pero no estn claros hasta el ltimo detalle. Aun as podemos basarnos en lo
ya entendido como cliente y desarrollador, trabajar con esta informacin, y
mientras se vayan creando prototipos, el cliente detallar sus especificaciones.
Desventaja: es que es difcil distinguirlo del proceso "codifica y corrige", pues
en cierta medida son parecidos, la diferencia est que en la prctica se
requiere que al construir el prototipo se aplique el anlisis y el diseo pero slo
a una parte de los requerimientos ya entendidos, que se documente y se
codifique, logrndose con todo esto, un poco de disciplina heredada del modelo
en cascada, de esta manera, la desventaja no lo es tanto. La caracterstica de
este modelo es que est enfocado a la produccin de prototipos.
Modelo Incremental:
Es una forma de reducir la repeticin del trabajo en el proceso de desarrollo y
dar oportunidad de retrasar la toma de decisiones en los requisitos hasta
adquirir experiencia con el sistema. Es una combinacin del Modelo de
Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da la oportunidad
para retrasar las decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de
cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los
requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por
cascada, si es dudoso, es mejor el evolutivo.

Modelo Espiral:
El modelo en espiral fue desarrollado por Boehm, quien lo describe as:
El modelo de desarrollo en espiral es un generador de modelo de proceso
guiado por el riesgo que se emplea para conducir sistemas intensivos de
ingeniera de software concurrente y a la vez con muchos usuarios.

Caractersticas

Un enfoque cclico para el crecimiento incremental del grado de

definicin e implementacin de un sistema, mientras que disminuye su
grado de riesgo.

Un conjunto de puntos de fijacin para asegurar el compromiso del

usuario con soluciones de sistema que sean factibles y mutuamente
satisfactorias.

Principios bsicos:

Decidir qu problema se quiere resolver antes de empezar a resolverlo.

Examinar mltiples alternativas de accin y elige una de las ms

convenientes.

Evaluar qu se tiene realizado y qu se ha aprendido despus de hacer

algo.

No ser tan ingenuo para pensar que el sistema que ests construyendo
ser "EL" sistema que el cliente necesita.

Conocer los niveles de riesgo, que habra que tolerar.

Determinar o fijar objetivos

Fijar tambin los productos definidos a obtener: requerimientos,

especificacin, manual de usuario.

Fijar las restricciones.

Identificacin de riesgos del proyecto y estrategias alternativas para

evitarlos.

Hay una cosa que solo se hace una vez: planificacin inicial o previa.

Anlisis del riesgo

Se estudian todos los riesgos potenciales y se seleccionan una o varias
alternativas propuestas para reducir o eliminar los riesgos.
Desarrollar, verificar y validar (probar)

Tareas de la actividad propia y de prueba.

Anlisis de alternativas e identificacin resolucin de riesgos.

Planificar
Se Revisa todo lo hecho, evalundolo, y con ello decidimos si continuamos
con las fases siguientes y planificamos la prxima actividad.
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, etc.

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

HISTORIA DE LA INGENIERA DE SOFTWARE

LINEA DEL TIEMPO

1979

1980

1982

1989 1992

1983

1995 1998-1999 2002

1990 1993 1996

2001

Osborne
1979
Describi una nueva revolucin industrial
Tofler
1980
Llam al surgimiento de la microelectrnica parte de la tercera ola de cambio
en la historia de la humanidad.
Naisbitt
1982
Predijo la transformacin de una sociedad industrial en una sociedad de la
informacin.
Feigenbaum y McCorduck
1983
Sugirieron que la informacin y el conocimiento (controlados por
computadoras) seran el punto de enfoque para el poder en el siglo XXI.
Stoll
1989
Argument que la comunidad electrnica creada por redes y software era la
clave del intercambio de conocimiento alrededor del mundo.

2003

HOY

Toffler
1990
Describo un cambio de poder en el que todas las viejas
estructuras (gubernamentales, educativas, industriales, militares) se
desintegraran a medida que las computadoras y el software condujeran a una
democratizacin del conocimiento.
Yourdon
1992
Se preocupaba de que las compaas estadounidense pudieran perder su
margen competitivo en negocios relacionados con el software y predijo la
declinacin y cada del programador estadounidense.
Hammer y Champy
1993
Argumentaban que las tecnologas de la informacin representaran un papel
primordial en la reingeniera de corporacin.
James Brook, Lain Boal, Stephen Talbot
1995
Satanizabana la computadora al enfatizar inquietudes legtimas, pero
ignorando los grandes beneficios que ya se haban obtenido.
Yourdon
1996
Evalu de nuevo a los candidatos de software y sugiri el surgimiento y
resurreccin del programador estadounidense.
Y2K
1998-1999
Bomba de tiempo. Sus populares escritos acarrearon la permanencia del
software en la vida de los seres humanos.
Johnson
2001
Explic el poder del surgimiento como un fenmeno que explica lo que
sucede cuando interconexiones presentes en entidades relativamente simples
resultan en un sistema que se autorganiza para formar un comportamiento
ms adaptable e inteligente.
Yourdon
2002
Retom los trficos sucesos del 11 de septiembre de 2001 en NY
para
explicar el impacto continuo del terrorismo global en la comunidad informtica.

Wolfram
2002
Present un nuevo tratado sobre un nuevo tipo de ciencia sobre simulaciones
de software.
Daconta y sus colegas
2003
Explicaron la evolucin de la red semntica y como esto cambiar el
modo en que la gente interacta a travs de las redes globales.
En la actualidad
Una enorme industria del software se ha convertido en un factor dominante en
la economa del mundo industrializado. El programador solitario ha sido
cambiado por equipos especialistas en software, donde cada uno se enfoca en
una parte de la tecnologa requerida para desarrollar una aplicacin compleja.

ROLES DE UN EQUIPO DE DESARROLLO DE SOFTWARE

Por qu formar equipo en el desarrollo del software?

Debido a su complejidad. A la necesidad de personas con habilidades
distintas. El aporte de todas las capacidades necesarias dentro de un equipo
llevar al cumplimiento del objetivo. Es posible que no se requieran todos los
roles en un desarrollo, Eso depender del tamao y del tipo del desarrollo.
Roles:

Coordinador general (project leader);

Administrador de Base de Datos (ABD);

Modelador;

Desarrollador;

Evaluador (Reviewer);

Stakeholder;

Docmaster (y Asistente de Docmaster);

Aparte de sus responsabilidades al asumir un rol, todos los miembros de una

empresa tienen ciertas responsabilidades comunes.

Coordinador General
El principal objetivo del Coordinador General es dirigir un equipo efectivo. Sus
principales responsabilidades son:

Estimular a los miembros del equipo a comportarse en forma motivada,

productiva, colaboradora, proactiva, respetuosa y disciplinada en el
proyecto.

Coordinar la elaboracin del plan de trabajo. El plan debe determinar de

manera completa y precisa las tareas y actividades a realizar por el
equipo, el responsable de cada tarea y la fecha de inicio y culminacin
prevista para cada tarea, as como sus holguras.

Hacerle seguimiento al plan para que se logre la entrega oportuna del

proyecto. Esta actividad involucra recoger las hojas de registro semanal,
determinar el avance logrado, reportar las estadsticas pertinentes al
gerente de desarrollo (es decir, al profesor del curso), analizar las
desviaciones del plan y coordinar las acciones que se deriven de ese
anlisis.

Escuchar las observaciones de los dems miembros relacionadas con el

funcionamiento del equipo y manejar no ms de cinco riesgos
relacionados con el equipo.

Redactar y publicar la agenda de las reuniones del grupo.

Concertar y coordinar las reuniones del grupo.

Mantener oportunamente informado al profesor/gerente del estado de

avance, riesgos que se presentan y retrasos que pudieran surgir.

Velar para que se cumplan las metas del producto.

Coordinar la elaboracin del anlisis post-hoc del proceso de desarrollo.

Administrador de Base de Datos

El Administrador de Base de Datos (ABD) trabaja en colaboracin con los
miembros del equipo para disear, probar, permitir la evolucin y soportar los)
esquemas de base de datos de la aplicacin.
Modelador
El Modelador crea y actualiza los modelos que evolucionan de manera
colaborativa con los miembros del equipo.
Desarrollador
El Desarrollador escribe, prueba y construye software.
Evaluador
El Evaluador evala los productos del proyecto (en progreso) y le provee
feedback o retroalimentacin al equipo.

Stakeholder
Un usuario directo que trabaja en otros sistemas que se integran o interactan
con el software en desarrollo, o profesionales de mantenimiento potencialmente
afectados por el desarrollo y puesta en marcha del software.
Docmaster
El principal objetivo del Docmaster es lograr calidad y completitud en los
documentos del desarrollo. Sus responsabilidades son:

Mantener actualizado y de calidad el sitio web de la empresa;

Hacerle el seguimiento a la elaboracin y fechas de entregas de los

documentos generados por el equipo;

Lleva el registro de las reuniones generales (asistentes, decisiones,

justificaciones, acciones a tomar y sus responsables), as como elaborar
y publicar oportunamente sus avances;

Elaborar y mantener los manuales asociados al desarrollo.

Definir y velar por los estndares que deben cumplir los documentos, en
cuanto a organizacin, redaccin, ortografa y consistencia de
presentacin.

Coordinar la elaboracin del material de apoyo a las presentaciones del

equipo y velar por su calidad.

Manejar no ms de cinco riesgos asociados con la documentacin.

En el pasado se ha encontrado ms conveniente separar este rol en dos: Editor

Tcnico y Webmaster. Para esto se prev el rol de Asistente al
Docmaster. El Docmaster elegir qu responsabilidades quiere delegar en su
asistente.
Miembro de equipo
El principal objetivo de cada miembro del equipo es contribuir a la efectividad
de su equipo. Sus responsabilidades incluyen:

Colaborar proactivamente en el logro de las metas del equipo;

Entregar oportunamente los artefactos que le fueran encomendados;

Cumplir oportuna y disciplinadamente con las tareas que le designen, de

diseo, programacin, prueba, documentacin, instalacin,
entrenamiento, revisin, administracin de herramientas o sitios web;

Participar para lograr un desarrollo exitoso, un ambiente productivo y un

clima armonioso donde las diferencias de opinin se aprovechan para
enriquecer el trabajo;

Llevar y entregar oportunamente las estadsticas y registros

correspondientes;

Asistir puntualmente a las reuniones convocadas (planifique al menos

una reunin semanal hasta el fin del trimestre).

Cumplir con los estndares de codificacin, proceso y artefactos

asociados al desarrollo.

Respetar los estndares de trabajo del equipo.

FASES O ETAPAS DE UN PROYECTO DE SOFTWARE

Los proyectos se dividen en etapas para facilitar su gestin y control. Como

tales, suelen tener cierto grado de incertidumbre debido a que requieren la
realizacin de tareas y actividades no realizadas con anterioridad. El conjunto
de etapas que componen un proyecto desde que se inicia hasta que concluye
se llama Ciclo de Vida del Proyecto.
En esta nota hablaremos de cules son las etapas tpicas en que podemos
estructurar un proyecto de implantacin de enlatados y las actividades ms
importantes que stas contienen. Es importante aclarar que hablamos de
implantacin y no de desarrollo de software, ya que en este ltimo caso, las
etapas varan. No obstante, es normal que, por necesidades propias del
negocio de la empresa, se hagan arreglos o interfaces. Se describir un
modelo considerando que los hay.
No representan un Plan de Trabajo, aunque pueden usarse como gua para
armar uno. No se profundiza en los procedimientos de control de las etapas,
aunque los mismos estn presentes durante todo el ciclo de vida del proyecto.
Desde un punto de vista general de la gestin de proyectos, la primera etapa
siempre es el Estudio de Factibilidad. En esta etapa se evalan alternativas,
proveedores, funciones disponibles, costos y, finalmente, se decide la compra
del software. Est explicacin se referir a las actividades posteriores a lo
consiguiente.
PLANIFICACIN
1. Definicin del alcance: Hasta dnde va a llegar exactamente el proyecto?,
Qu se quiere lograr con el proyecto?
2. Definicin de actividades: Qu tareas son necesarias para llevar el proyecto
adelante?
3. Estimacin de tiempos: Qu duracin pueden tener las tareas,
individualmente y en conjunto?

4. Estimacin de costos: Cunto costar el proyecto?

Hay una serie de actividades auxiliares a los puntos mencionados, que siempre
deben existir en la planificacin. Se realizan en forma intermitente y ayudan a la
gestin. Son:
- Definicin del equipo del proyecto: Quines y con qu roles y
responsabilidades gestionarn el proyecto?
-Identificacin y cuantificacin de contingencias: Qu factores pueden afectar
el normal desenvolvimiento del proyecto? En cunto pueden afectarlo?
5. Aseguramiento de la calidad: Al final de la etapa se verifica que se hayan
cumplido los objetivos propuestos en forma satisfactoria y se evala si es
factible pasar a la etapa siguiente, Si bien parecen muchos puntos, no son
necesariamente complicados ni extensos. Su complejidad depende del tamao
del proyecto. Como ya se dijo, el resultado de todos estos procesos es un
documento llamado Plan General del Proyecto o Definicin del Proyecto.
Podemos dividir esta etapa en las siguientes actividades:
1. Anlisis del negocio o relevamiento: Consiste en comenzar a charlar con los
usuarios que sufrirn la implantacin del software y preguntar cules son las
operaciones habituales que realizan. Cuando nos referimos a usuario, el
concepto puede incluir desde el presidente de una empresa. hasta el asistente.
Si se usan cuestionario claros y concisos se reduce el tiempo de esta tarea y
se obtiene informacin ms valiosa.
2. Definicin de requerimientos funcionales: Se describen ordenadamente las
funciones crticas del sistema existente (sin las cuales no es posible arrancar),
las secundarias y las nuevas funciones que desean los usuarios.
3. Preparacin e instalacin de entorno standard para capacitacin: Se provee
todo el hardware y el software de base necesario para instalar el enlatado en
su versin estndar. Es recomendable que todos los integrantes del equipo de
trabajo tengan acceso al uso del mismo.
4. Modelizacin o diseo preliminar: Con la informacin de los puntos 2 y 3 se
arma un prototipo conceptual que cubra la mayor parte posible de procesos
relevados, sin usar arreglos de ningn tipo. Para esto deben explorarse todas
las alternativas factibles, aunque impliquen el cambio de procedimientos y
formas de trabajo existentes.
5. Diseo final: Se documenta el diseo final, basado en el resultado del punto
4.

6. Aseguramiento de la calidad: Al final de la etapa se verifica que se hayan

cumplido los objetivos propuestos en forma satisfactoria y se evala si es
factible pasar a la etapa siguiente.
Las actividades ms importantes de esta etapa son:
- Definicin de polticas de backup: Se define el conjunto de procedimientos de
backup necesarios para garantizar la recuperacin de la informacin en caso
de falla.
- Instalacin de entorno de prueba: Se instala una versin del enlatado en una
o varias bases de datos creadas para hacer las pruebas de los desarrollos.
- Parametrizacin preliminar: Parametrizar es indicar al enlatado que polticas
debe utilizar para operar. Se definen las polticas que sean posibles (ya que
pueden faltar arreglos e interfaces).
- Pruebas y ajustes de customizaciones e interfaces: Se hacen las pruebas de
las customizaciones y se determinan sus correcciones o modificaciones. El
proceso de pruebas puede subdividirse en subetapas, si el desarrollo es muy
complejo.
- Pruebas de migracin de archivos maestros: Se debe confirmar que la
informacin transferida pas ntegramente al enlatado.
- Simulacin preliminar del enlatado en produccin: Se simula la operacin del
da a da, tratando de generar la mayor cantidad de variantes posibles de
operacin. Dependiendo su complejidad y cantidad, es conveniente hacer una
lista de todas las operaciones que se van a probar indicando cual es el
resultado esperado para cada una, para poderlo con el obtenido.
- Desarrollo de programas para migracin de archivos de movimientos: De no
existir una aplicacin que permita migrar la informacin del sistema existente al
enlatado, ser preciso desarrollar alguna.
- Capacitacin de usuarios finales: Es conveniente entrenar a los usuarios
finales cerca del perodo de arranque, para que retengan la mayor cantidad de
informacin posible. Nuestra experiencia nos indica que capacitar a los
usuarios finales al inicio del proyecto es, la mayora de las veces, una prdida
de tiempo y dinero. En esta capacitacin s debe analizarse a fondo la
operatoria de la empresa. Si todos los usuarios finales tuvieron participacin
directa, o bien indirecta a travs de los usuarios clave, de este entrenamiento
slo deberan salir mejoras menores.
- Prctica de usuarios finales: Se arma un plan de prctica para los usuarios
finales. Con las mismas se refuerzan los conocimientos en el uso del enlatado
y se agiliza la velocidad de operacin.

- Migracin de la configuracin: Se migran archivos maestros, customizaciones

y datos de la parametrizacin al entorno de produccin.
- Adelanto de operaciones: Este punto puede existir o no. Se trata de adelantar
todas las operaciones que sea posible (pagos, cobros, emisin de informes)
previendo que el punto siguiente demore ms de lo previsto.
- Migracin de archivos de movimientos: Se procede a migrar movimientos
contables, facturacin, cobranzas, pagos, saldos pendientes de pago, cobro,
bodega, rdenes de produccin, etc.
- Control de la migracin: Se controla la informacin transferida contra el viejo
sistema o contra la documentacin respaldatoria. Se prueban los informes. Los
usuarios deben participar de esta tarea.

POST-IMPLEMENTACIN
1. Asistencia sistemtica a usuarios: Cualquier cambio genera dudas e
incertidumbre, por lo que es preciso asistir a los usuarios en forma sistemtica
durante un tiempo, para asegurar la fluidez de las operaciones. El lapso de
asistencia necesario depende del nfasis que se haya puesto en una correcta
capacitacin y de haber dedicado tiempo suficiente a las prcticas y la
simulacin.
2. Deteccin de nuevos requerimientos o necesidades de informacin: Es
normal que en desarrollo de las operaciones de la empresa vayan surgiendo
inquietudes para mejorar el sistema o se quiera obtener ms y mejor
informacin. Esto puede dar lugar a nuevos desarrollos. Dependiendo de su
amplitud, podemos estar en presencia de nuevos proyectos.

DESCRIPCION DE LOS COMPONENENTES DE UN PROYECTO DE

SOFTWARE

Los componentes del desarrollo de software permiten reutilizar varias piezas de

cdigo que ya han sido elaborados, esto con el fin de reducir tiempo, costos,
mejorar la calidad del proyecto. Un componente de software est compuesto
por un conjunto de interfaces y un conjunto de requisitos especficos. Los
proyectos de software basados en componentes constan de los siguientes
pasos:

Especificacin

Anlisis

Diseo

Implementacin

Pruebas

Las componentes de software estn dados por las siguientes caractersticas:

-

Debe tener una identificacin que permita acceder de una manera rpida
a su clasificacin.

Un componente no debe requerir la utilizacin de otros componentes

para poder realizar la funcin para el cual fue diseado.

Debe ser adaptable al cambio, esto quiere decir que debe mejorar
continuamente para cubrir nuevas necesidades.

Debe tener acceso solamente a travs de su interfaz.

Sus servicios no pueden variar.

Debe estar bien documentado.

Sus servicios deben servir para varias aplicaciones.

Debe permitir que sea cargado en tiempo de ejecucin bien sea de una
aplicacin o del proyecto como tal.

Debe ser independiente de la plataforma sobre la cual se est

manejando.

El desarrollo de software cuenta con beneficios como:

-

Nos lleva a tener un nivel mayor de reutilizacin de software.

Permite realizar las pruebas en cada uno de los componentes

ensamblados.

Simplifica el mantenimiento del sistema, es decir, que el equipo de

trabajo puede aadir ms componentes si el proyecto se torna dbil o
con molestias.

Tiene una mayor calidad, debido a que un componente permite ser

mejorado con el paso del tiempo.

Ciclos de desarrollo ms cortos.

Funcionalidad mejorada.

ESTANDARES PARA EVALUAR LA CALIDAD DE UN PROYECTO DE

SOFTWARE

En la actualidad, los proyectos de software estn presentes en casi todos los

mbitos de la cotidianidad de una empresa u organizacin. Es por esto que
debe ser avalado por unos estndares que confirmen su calidad para su
posterior uso. A continuacin presentare algunos de los estndares de calidad
ms sobresalientes en un proyecto de software:
Norma ISO/IEC 14598: se define al modelo de calidad como un conjunto de
caractersticas que conforman la base para especificar requerimientos de
calidad y evaluar la calidad. Esta norma consta de las siguientes caractersticas
principales:
-

La visin trascendental que puede ser reconocida pero no definida.

La visin del usuario como la adecuacin al propsito del usuario.

La visin del productor como conformidad con la especificacin.

La visin del producto basada en las caractersticas observables del

producto.

La visin basada en el valor que el cliente est dispuesto a pagar por

ella.

Norma ISO/IEC 9126: presenta el concepto de calidad en uso, la calidad

externa y la calidad interna que corresponden con la visin del usuario, del
productor y del producto. Tomaremos el siguiente grafico para entender un
poco mejor sobre que trata la norma:

NORMA ISO/IEC 9126: La norma ISO/IEC 9126 presentan dos modelos de

calidad, el primero referido a la calidad interna y externa y el segundo modelo
referido a la calidad en uso.

Calidad interna y externa

La norma ISO/IEC 9126 define la calidad interna como la totalidad de las
caractersticas del producto software desde una perspectiva interna, es medida
y evaluada en base a los requerimientos de calidad interna. Consta de un
conjunto de caractersticas que son:
-

Funcionabilidad: Capacidad del producto software para proveer las

funciones que satisfacen las necesidades explcitas e implcitas cuando
el software se utiliza bajo condiciones especficas.

Fiabilidad: Capacidad del producto software para mantener un nivel

especificado de funcionamiento cuando se est utilizando bajo
condiciones especificadas

Usabilidad: Capacidad del producto software de ser entendido,

aprendido usado y atractivo al usuario, cuando es usado bajo las
condiciones especificadas

Eficiencia: Capacidad del producto software para proveer un desempeo

apropiado, de acuerdo a la cantidad de recursos utilizados y bajo las
condiciones planteadas.

Mantenimiento: Capacidad del producto software para ser modificado.

Las modificaciones pueden incluir correcciones, mejoras o adaptacin
del software a cambios en el entorno, en requerimientos y
especificaciones funcionales

Portabilidad: Capacidad del producto software de ser trasladado de un

entorno a otro.

Calidad en uso
La norma ISO/IEC 9126 define la calidad en uso como la perspectiva del
usuario de la calidad del producto software cuando ste es usado en un
ambiente especfico y un contexto de uso especfico. ste mide la extensin
para la cual los usuarios pueden conseguir sus metas en un ambiente
particular, en vez de medir las propiedades del software en s mismo. Consta
de las siguientes caractersticas:
-

Efectividad: La capacidad del producto software para permitir a los

usuarios lograr las metas especificadas con precisin y completitud en
un contexto de uso especfico.

Productividad: La capacidad del producto software para permitir a los

usuarios emplear cantidades apropiadas de recursos en relacin a la
efectividad lograda en un contexto de uso especfico.

Integridad: La capacidad del producto software para lograr niveles

aceptables de riesgo de dao a las personas, negocio, software,
propiedad o entorno en un contexto de uso especfico.

Satisfaccin: La capacidad del producto software para satisfacer a los usuarios

en un contexto de uso especfico.

CONCLUSIONES

Como se pudo observar el desarrollo de un software es altamente complicado,

ya que es muy difcil lograr obtener un software confiable, es decir, que cumpla
todas las expectativas que el usuario requiere, para ello el diseo, anlisis y
otras etapas son sumamente importantes, ya que nos permite el mejor margen
de error para la solucin del problema.
El software se ha convertido en el elemento clave de la evolucin de los
sistemas y productos informticos. En las pasadas cuatro dcadas, el software
ha pasado de ser una resolucin de problemas especializadas y una
herramienta de anlisis de informacin, a ser una industria por s misma. Pero
la temprana cultura e historia de la programacin ha creado un conjunto de
problemas que persisten todava.
El software se ha convertido en un factor que limita la evolucin de los sistemas
informticos. El software se compone de programas, datos y documentos.
Cada uno de estos elementos compone una configuracin que se crea como
parte del proceso de la Ingeniera del Software. El intento de la Ingeniera del
Software es proporcionar un marco de trabajo para construir software con
mayor calidad.

Bibliografa
1. https://books.google.es/books?hl=es&lr=lang_es&id=_tKTpr4Ah88C&oi=
fnd&pg=PA15&dq=ingenieria+de+software&ots=RvHSo0CDwL&sig=yTi2
yOM1RxeoX0g9QHj5xoyvwCo#v=onepage&q&f=false
2. https://books.google.es/books?hl=es&lr=lang_es&id=gQWd49zSut4C&oi
=fnd&pg=PA1&dq=ingenieria+de+software&ots=s647uoswxc&sig=pzBX
ZKH0wUBwcU8vva64tNqA364#v=onepage&q&f=false

3. http://www.monografias.com/trabajos5/inso/inso.shtml
4. http://www.slideshare.net/vdaniel20/metodologas-y-ciclos-de-vida

5. http://seeri.etsu.edu/Codes/SpanishVersionSECode.htm
6. http://datateca.unad.edu.co/contenidos/301569/AVA_2014_II__301569/AVA_ESTANDARES_Y_MODELOS_DE_CALIDAD_DEL_SOF
TWARE.pdf

7. http://blogs.sld.cu/alejandro/2014/10/23/roles-y-responsabilidades-delequipo-web/

8. INGENIERA DEL SOFTWARE UN ENFOQUE PRCTICO, Quinta

edicin; Roger S. Pressman.