Cualidades del Software
- -Correctitud: Un sistema es correcto
cuando se comporta de acuerdo a los requerimientos del cliente. En otras
palabras, un sistema es correcto si resuelve el problema real que causó su
desarrollo. La correctitud es una propiedad matemática que establece la
igualdad entre el software y su especificación, por lo que cuanto más
específica haya sido en las instrucciones, más precisa y sistemática podrá
ser su evaluación. Posteriormente se verá que la correctitud puede ser
valorada mediante diversas técnicas, algunos de enfoque experimental como
las pruebas, otros de enfoque analítico como verificación formal de la
correctitud.
- Confiabilidad: El software es
confiable si se comporta de acuerdo a los requerimientos del usuario. En
otros términos, es la calidad que se puede esperar de una aplicación que
lleve a cabo las operaciones establecidas y con la claridad requerida.
Pueden tenerse aplicaciones correctas diseñadas para requerimientos
“incorrectos”, por lo que la correctitud del software puede no ser
suficiente para garantizar al usuario que el software se comporta como “es
esperado”.
- Robustez: Un programa es robusto si
se comporta en forma razonable aún en situaciones que no fueron
pronosticadas en la descripción de los requerimientos. La robustez es
igual a la distancia del caos, es decir, mientras menor es la distancia al
caos, mayor solidez posee el sistema.
- Performance: Se puede medir la eficiencia del sistema de acuerdo a dos dimensiones: Los recursos necesarios que abarcan la construcción y desarrollo del software, y los recursos necesarios que comprende la ejecución de la aplicación. Cabe destacar, que un sistema es eficiente cuando se utilizan los equipos computacionales en forma económica. Por ejemplo, si es muy lento reduce el entendimiento de los usuarios, si usa demasiado espacio de disco puede ser muy costoso de ejecutar, si utiliza demasiada memoria puede afectar al resto de las aplicaciones que se están ejecutando mientras el sistema operativo intenta balancear el uso de la memoria.
- Amigabilidad: Un sistema es amigable
cuando el usuario encuentra la interfaz fácil de manejar. La amigabilidad
está dada por la habilidad con que el sistema puede configurarse y
ajustarse al ambiente de hardware. Un sistema que produce respuestas
erróneas no es amigable sin importar lo “atractiva” que sea la interfaz de
usuario, del mismo modo que un sistema que produce respuestas más tardías
de lo que requiere el usuario no es amigable aunque estas respuestas sean
desplegadas en colores.
- Verificabilidad: Un software es
verificable si sus propiedades pueden ser verificadas sencillamente.
Ejemplo, la correctitud o la performance de un sistema son propiedades que
concierne comprobar. La verificabilidad es en general una cualidad interna
pero a veces puede ser externa, por ejemplo, en muchas aplicaciones de
seguridad crítica, el cliente solicita la verificación de algunas propiedades.
- Mantenimiento: Es la
forma fácil de corregir y remediar fallas que pueda tener algún
software. El mantenimiento también puede aplicarse a la reparación los
problemas que surgen en la aplicación después de la liberación o agregarle
al producto que no estaban en las especificaciones originales. El
mantenimiento abarca un grupo amplio de actividades que tiene que ver con
las modificaciones de un software existente la lograr una mejora. Existen
tres tipos de mantenimiento:
-El
mantenimiento correctivo: El mantenimiento correctivo es la eliminación de
errores excedentes presentes en el producto al ser liberado así como errores
implantados al software durante su mantenimiento.
-Mantenimiento
adaptativo: Involucra el ajuste de la aplicación a ajustes en el entorno, por
ejemplo la creación de hardware o del sistema operativo. En este asunto la
necesidad de cambios al software no puede ser atribuida a una particularidad
del software en sí mismo como la inhabilidad de prestar cierta
funcionalidad demandada por el usuario o errores residuales, sino que se
producen debido a cambios en su entorno.
-El
mantenimiento perfectivo: Implica cambios en el software para
perfeccionar sus cualidades, los cuales se deben a la necesidad de
cambiar las funciones brindadas por el software, añadir nuevas funciones,
renovar la performance, facilitar su manejo, entre otras. Estos cambios pueden
ser producidos tanto por el ingeniero de software para perfeccionar el estatus
del producto en el mercado, como por el cliente debido a nuevos requerimientos.
- La reusabilidad: Se refiere a que una
aplicación puede utilizarse en otras aplicaciones. Es complicado lograr
reusabilidad, se debe examinar el instante de desarrollar los componentes
del software; un modo para conseguir reusabilidad es la manejo de diseño
orientado a objetos. Diferentes metodologías de software pueden
verse como tentativas de reutilizar el mismo proceso para la construcción
de productos diferentes, y los modelos de ciclo de vida también son
intentos de reutilizar procesos de alto nivel.
- Portabilidad: Se refiere a la
manera en que los clientes pueden acceder a los productos ya que un
software portable es mucho más fácil de obtener por los clientes
dado que pueden acceder a dicho software. El software es portable si
puede ser desarrollado en distintos ambientes, refiriéndose este último
tanto a plataformas de hardware como a ambientes de software como puede
ser determinado sistema operativo.
- Comprensibilidad: Algunos sistemas de
software son más cómodos de comprender que otros, ciertas tareas son
sustancialmente más complicadas que otras. La comprensibilidad es una
cualidad interna del producto y ayuda a lograr muchas de las otras
cualidades como evolucionabilidad y verificabilidad. La comprensibilidad
no es más que ejecute su función de acuerdo a lo que el usuario predice.
- Interoperabilidad: Es la destreza que
posee un sistema para coexistir e interactuar con otros, por ejemplo, la
habilidad de un procesador de texto de incluir gráficas producidas por un
paquete de gráficos.
- La productividad: Es una cualidad del
proceso de producción de software, calcula la eficiencia del proceso. Un
proceso eficiente resulta en una entrega más rápida del producto. Los
ingenieros originan software individualmente a cierta tasa, la cual puede
alterarse considerablemente entre individuos con habilidad distinta.
Cuando los individuos forman un equipo, la productividad de éste es alguna
función de las productividades individuales, y en general esta
productividad combinada es menor que la suma de las partes.
- Oportunidad: La oportunidad es una cualidad del proceso que se refiere a la habilidad de liberar el software a tiempo. Esto puede ser un arma de doble filo ya que muchos procesos fracasan en alcanzar los resultados a tiempo. La oportunidad en sí misma no es una cualidad útil, aunque llegar tarde puede llevar a perder oportunidades en el mercado, entregar un producto a tiempo que carece de otras cualidades como confiabilidad o performance, no tiene sentido. Entregar un producto a tiempo requiere una agenda planeada cuidadosamente, con un trabajo de estimación acertado y puntos de revisión especificados claramente y verificables.
VISIÓN GENERAL DEL PROCESO DE DESARROLLO DE SOFTWARE
Es proceso es afectado por la creatividad
y juicio de las personas involucradas.
En el desarrollo de software hay una serie de desafíos adicionales, relativos
esencialmente a la naturaleza del producto obtenido. Un proceso de desarrollo
de software tiene como propósito la producción eficaz y eficiente de un
producto software que reúna los requisitos del cliente.
Es actividades requeridas para desarrollar
un sistema de software de alta calidad y proporciona el marco de trabajo desde
el cual se puede establecer un plan detallado para el desarrollo del software.
Actividades: Diseño, validación, evolución, especificación.
EL
PAPEL DEL USUARIO DENTRO DEL PROCESO DE DESARROLLO DE SOFTWARE
Todos
sabemos que cuanto mayor sea la ayuda de los usuarios en un proyecto de
desarrollo de software, mayores serán las probabilidades de éxito que tenga el
mismo.
No
obstante es importante hacer algunas matizaciones:
1)
El proyecto no se hace sólo, porque incluso existiendo una gran ayuda por parte
de los usuarios, si no se consigue interpretar con precisión lo que quieren y
no se dinamiza un feedback continuo de los mismos durante todo el proceso de
desarrollo, se incrementarán las posibilidades de que algún requisito funcional
no se haya recogido adecuadamente o de que se haya realizado un software con
una usabilidad incómoda para los usuarios.
Estas
circunstancias son fuente de innumerables problemas en las fases finales del
proyecto y provocan retrasos, sobrecostes y grandes dificultades para cerrar el
proyecto, además de crear conflictos con el cliente que pueden perjudicar las
relaciones futuras con el mismo. Esto hace que sea fundamental el papel que
desempeñan tanto el jefe de proyectos, como el equipo de analistas funcionales
y analistas programadores.
2)
Es importante que entre el grupo usuarios asignados al proyecto haya usuarios
que vayan a estar implicados en el futuro uso del sistema de información, es
decir, no es suficiente que el equipo de usuarios esté formado por “ideólogos”
o “teóricos” que se nutrirán del resultado del trabajo de la herramienta, sino
que es fundamental que participen usuarios que después se tengan que poner el
mono de trabajo y vayan a trabajar con el software. Es importante conseguir la
combinación de ambos tipos de usuarios (tampoco es positivo que en el grupo de
usuarios no participen usuarios directores, ya que pueden existir conflictos
entre usuarios que éstos deben solucionar y también es recomendable que el
software no sólo se diseñe para el corto plazo, sino que sirva para tareas de
gestión, planificación, etc… y esta visión la proporcionan principalmente los
usuarios directores), por lo que el jefe de proyectos debe poner en
conocimiento del cliente esta necesidad, como es lógico explicando los riesgos
de que no se aplique esta estrategia.
3)
Los analistas están para ayudar y para colaborar con los usuarios en la
especificación y diseño de la solución, pero no están para “dar lecciones” a
los usuarios y enseñarle cómo deben hacer su trabajo. Si los usuarios hacen su
trabajo de una determinada manera, aunque no sea la más ortodoxa, siempre
tendrá una justificación que sólo se entendería si realmente estuviéramos
haciendo su trabajo durante un tiempo y viéramos los problemas con los que se
enfrentan cotidianamente. La clave por tanto está en la colaboración y en el
diálogo, es decir, se pueden proponer cosas al usuario, se le pueden dar ideas,
pero no se le puede dar una vuelta al calcetín de cómo hacen sus tareas, salvo
que ellos mismos lo soliciten y procurando en estos casos y en consenso con los
usuarios que los cambios sean tranquilos.
4)
Es fundamental documentar el proyecto, en primer lugar con la documentación que
se especifique en las normativas de desarrollo de la organización para la que
se realiza el servicio, con las matizaciones que indique el Director del
Proyecto, en segundo lugar con la documentación que establezcan las normativas
internas de calidad de tu organización (no requerirá un sobreesfuerzo, ya que
en la mayor parte de los casos coincidirá) y a todo lo anterior sumarle toda la
documentación de trabajo que sea necesaria para trabajar con los usuarios, que
no tienen por qué entender de modelos de datos, de diagramas de casos de uso,
etc…, es más, es un error trabajar con los usuarios utilizando dichas
herramientas, ya que estas son de utilidad técnica y no hablan el mismo
lenguaje de los usuarios. Este tipo documentación, por tanto, no tiene por qué
tener los formalismos de la técnica y tiene como objetivo que el usuario capte
lo que el analista está interpretando y se pueda ir perfilando a partir de
esto, tanto requisitos, como casos de uso, interfaces, etc… Es muy importante
trabajar todo esto, ya que comenzar demasiado pronto con la construcción, es
algo muy arriesgado, ya que los costes de modificar algo en las distintas fases
de la construcción pueden ser muy importantes y provocar que se tengan que
reconstruir varias veces distintas funcionalidades de la aplicación.
RESPONSABILIDAD
PROFESIONAL Y ÉTICA
La ingeniería del software se lleva a cabo
dentro de un marco legal y social que limita la libertad de los ingenieros. Los
ISW deben aceptar que su trabajo comprende responsabilidades más amplias que
simplemente la aplicación de habilidades técnicas. Deben comportarse de una
forma ética y moral responsable, no basta con poseer estándares normales de
honestidad e integridad. No debería utilizar su capacidad y sus habilidades
para comportarse de forma deshonesta o de forma que deshonre la profesión de la
ingeniería del software.
Existen áreas donde los estándares de
comportamiento aceptable no están acotados por las leyes, sino por la
responsabilidad profesional, algunas de estas son:
Confidencialidad.
Respetar la confidencialidad de sus empleadores o clientes, independientemente
de que se haya firmado un acuerdo formal de confidencialidad.
Competencia.
No debe falsificar su nivel de competencia, ni aceptar conscientemente trabajos
que están fuera de su capacidad.
Derechos
de propiedad intelectual. Debe ser consciente de las leyes locales que
gobiernan el uso de la propiedad intelectual, como las patentes el el
copyright. Debe asegurarse de que la propiedad intelectual de los empleadores y
clientes está protegida.
Uso
inapropiado de las computadoras. No debe emplear sus habilidades técnicas para
utilizar de forma inapropiada las computadoras de otras personas. Desde los
relativamente triviales (utilizar juegos en las máquina de un empleado, por
ejemplo) hasta los extremadamente serios (difusión de virus).
Código
de ética (ACM/IEEE)
Los ingenieros de software deberán
comprometerse consigo mismo en convertir el análisis, especificación, diseño,
desarrollo, prueba y mantenimiento de software en una profesión respetable y
beneficiosa. De acuerdo con su compromiso con la salud, seguridad y bienestar
del público, los ingenieros de software deberán apegarse a ocho principios.
Principios
del código
Público:
Los ingenieros de software deberán actuar consistentemente con el interés
público.
Cliente
y Empleador: Los ingenieros de software deberán actuar de una forma determinada
que esté en los mejores intereses de su cliente y empleador consistente con el
interés público.
Producto:
Los ingenieros de software deberán asegurar que sus productos y modificaciones
relacionadas logren el más alto estándar profesional posible.
Juicio:
Los ingenieros de software deberán mantener integridad e independencia al
emitir su juicio profesional.
Gerencia:
Los gerentes y lideres de ingeniería de software deberán suscribirse y
promocionar un enfoque ético para la gerencia de desarrollo y mantenimiento del
software.
Profesión:
Los ingenieros de software deberán fomentar la integridad y reputación de la
profesión consistente con el interés público.
Colegas:
Los ingenieros de software deberán ser justos y comprensivos con sus colegas.
Interés Propio: Los ingenieros de software deberán participar en el aprendizaje de por vida del ejercicio de su profesión y deberán promover un enfoque ético para el ejercicio de la misma.
CICLO DE VIDA DEL SOFTWARE
Al
igual que en otros sistemas de ingeniería, los sistemas de software requieren
un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso
por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que
se detecta la necesidad de construir un sistema de software hasta que este es
retirado, se identifican varias etapas que en conjunto se denominan el ciclo de
vida del software y en cada caso, en función de cuales sean las características
del proyecto, se configurará el ciclo de vida de forma diferente. Usualmente se
consideran las etapas: especificación y análisis de requisitos, diseño del
sistema, implementación del software, aplicación y pruebas, entrega y
mantenimiento. Un aspecto esencial dentro de las tareas del desarrollo del
software es la documentación de todos los elementos y especificaciones en cada
fase. Dado que esta tarea siempre estará influida por la fase del desarrollo en
curso, se explicará de forma distribuida a lo largo de las diferentes fases
como un apartado especial para recalcar su importancia en el conjunto del
desarrollo del software.
Tal
como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo
de vida son:
Análisis:
Construye un modelo de los requisitos
Diseño: A partir
del modelo de análisis se deducen las estructuras de datos, la estructura en la
que descompone el sistema y la interfaz de usuario.
Codificación:
Construye el sistema. La salida de esta fase es código ejecutable.
Pruebas: Se comprueba
que se cumplen criterios de corrección y calidad.
Validación: Es el
proceso de comprobar que lo que se ha especificado es lo que el usuario
realmente quería.
Mantenimiento: En
esta fase, que tiene lugar después de la entrega se asegura que el sistema siga
funcionando y adaptándose a nuevos requisitos.
MODELOS DE
DESARROLLO DE SOFTWARE
Hay varios modelos para perfilar el proceso
de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto
debería escoger el más apropiado para sus necesidades. En ocasiones puede que
una combinación de varios modelos sea apropiado.
Modelo de cascada
El modelo de cascada muestra un proceso
donde los desarrolladores han de seguir las siguientes fases de forma sucesiva:
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.
Desarrollo iterativo e
incremental
El desarrollo iterativo recomienda la
construcción de secciones reducidas de software que irán ganando en tamaño para
facilitar así la detección de problemas de importancia antes de que sea
demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del
diseño en el caso de clientes que no saben cómo definir lo que quieren.
Desarrollo ágil
El desarrollo ágil de software utiliza un
desarrollo iterativo como base para abogar por un punto de vista más ligero y
más centrado en las personas que en el caso de las soluciones tradicionales.
Los procesos ágiles utilizan retroalimentación en lugar de planificación, como
principal mecanismo de control. La retroalimentación se canaliza por medio de
pruebas periódicas y frecuentes versiones del software.
Hay muchas variantes de
los procesos ágiles:
En el caso de la programación extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un día o en una semana, en lugar de los meses o años de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al desarrollo. Después se programa el código, que será completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabrían como mejorar el conjunto de pruebas necesario. El diseño y la arquitectura emergen a partir de la refactorización del código, y se da después de programar. El diseño lo realizan los propios desarrolladores del código. El sistema, incompleto, pero funcional se despliega para su demostración a los usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de más importancia.
Modelo
de Codificación y corrección
El desarrollo de codificación y corrección
(en inglés "Code and fix") es, más que una estrategia predeterminada,
el resultado de una falta de experiencia o presión que se ejerce sobre los
desarrolladores para cumplir con una fecha de entrega.2 Sin dedicar tiempo de
forma explícita para el diseño, los programadores comienzan de forma inmediata
a producir código. Antes o después comienza la fase de pruebas de software (a
menudo de forma tardía) y los inevitables errores que se encuentran han de
eliminarse antes de poder entregar el software.
Modelos
de mejora de procesos
El Capability Maturity Model Integration
(CMMI), en español «Integración de Modelos de Madurez de Capacidades» es uno de
los modelos líderes basados en mejores prácticas. Son evaluaciones
independientes las que confirman el grado con el que una organización siguen
sus propios procesos, que no evalúa la calidad de los procesos o del software
que se produce. CMMI ha reemplazado a CMM y tiene un ámbito global, no sólo en
procesos destinados al desarrollo del software.
ISO
9000
ISO 9000 describe estándares para un
proceso organizado formalmente para resultar en un producto y los métodos de
gestión y monitoreo del progreso. Aunque este estándar se creó inicialmente
para el sector de producción, los estándares de ISO 9000 también se han
aplicado al desarrollo del software. Al igual que CMMI, que una organización
está certificada con el ISO 9000 no garantiza la calidad del resultado final,
sólo confirma que se ha seguido los procesos establecidos.
ISO
15504
ISO 15504, también conocido como Software Process Improvement Capability Determination (SPICE), en español «Determinación de la Capacidad de Mejora del Proceso de Software» es un marco para la evaluación de procesos de software. Este estándar tiene como objetivo un modelo claro para poder comparar procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar, controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza entonces para medir lo que una organización o proyecto hace durante el desarrollo del software. Esta información se analiza para identificar puntos débiles y definir acciones para subsanarlos. También identifica puntos fuertes que pueden adoptarse en el resto de la organización.
MÉTODOS
EN EL PROCESO DE DESARROLLO DE UN SOFTWARE.
Los métodos formales son soluciones
matemáticas para resolver problemas de software y hardware a nivel de
requisitos, especificación y diseño. Ejemplos de métodos formales incluyen el
Método B, la red de Petri, la demostración automática de teoremas, RAISE y el
VDM. Hay varias notaciones de especificaciones formales, tales como el lenguaje
Z. Más generalmente, se puede utilizar la teoría de autómatas para aumentar y
validar el comportamiento de la aplicación diseñando un sistema de autómata finito.
Las metodologías basadas en los autómatas
finitos permiten especificación de software ejecutable y evitar la creación
convencional de código.
Los métodos formales se suelen aplicar en
software de aviación, especialmente si es software de seguridad crítico. Los
estándares de aseguramiento del software de seguridad, tales como DO178B
demandan métodos formales en el nivel más alto de categorización (Nivel A).
La formalización del desarrollo de
software está ganando en fuerza poco a poco, en otros ámbitos, con la
aplicación del lenguaje de especificación OCL2.0 (y especializaciones tales
como Java Modeling Language) y particularmente con Model-driven Architecture,
que permite la ejecución de diseños, incluso especificaciones.
Otra tendencia que está surgiendo en el
desarrollo de software es la redacción de especificaciones en algún tipo de
lógica (normalmente una variación de FOL), para acto seguido ejecutar esa
lógica como si se tratase de un programa. El lenguaje OWL, basado en lógica
descriptiva, es un buen ejemplo. También se está trabajando en enlazar un
idioma natural de forma automática con lógica, lógica que puede ejecutarse.
Ejemplo en este campo es el Attempto Controlled English, una lógica de negocios
de Internet, que no busca controlar el vocabulario o la sintaxis. Una
características de los sistemas que apoyan el vínculo bidireccional
inglés-lógica y ejecución directa de la lógica es que pueden explicar sus
resultados en inglés en un nivel de negocios o científico.
METODOLOGÍAS
PARA EL DESARROLLO DEL SOFTWARE
Un proceso de software detallado y
completo suele denominarse “Metodología”. Las metodologías se basan en una
combinación de los modelos de proceso genéricos (cascada, evolutivo,
incremental, etc.). Adicionalmente una metodología debería definir con
precisión los artefactos, roles y actividades involucrados, junto con prácticas
y técnicas recomendadas, guías de adaptación de la metodología al proyecto,
guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el
término “método” para referirse a técnicas, notaciones y guías asociadas, que
son aplicables a una (o algunas) actividades del proceso de desarrollo, por
ejemplo, suele hablarse de métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.
ACTIVIDADES EN EL PROCESO DEL DESARROLLO DEL SOFTWARE
- Planificación.
- Implementación.
- Pruebas del software.
- Documentación.
- Entrenamiento.
- Despliegue
- Mantenimiento del software.
HERRAMIENTAS PARA EL
DESARROLLO DE SOFTWARE
Las Herramientas de Ayuda al Desarrollo de
Sistemas de Información, surgieron para intentar dar solución a los problemas
inherentes a los proyectos de generación de aplicaciones informáticas: plazos y
presupuestos incumplidos, insatisfacción del usuario, escasa productividad y
baja calidad de los desarrollos. Algunas de estas herramientas se dirigen
principalmente a mejorar la calidad, como es el caso de las herramientas CASE
(Computer Aided Software Engineering-Ingeniería de Software Asistida por
Ordenador). Otras van dirigidas a mejorar la productividad durante la fase de
construcción, como es el caso de los lenguajes de cuarta generación (4GL-Fourth
Generation Language).
Herramientas para diseñar
software
• Existe al menos 20
herramientas libres para diseñar software totalmente libres.
• Todas utilizan la
notación UML
• El nivel de avance
entre una y otra es notable, casi todas ofrecen como funcionalidad:
Diagramas de caso de uso.
Diagramas de clases.
Diagramas de secuencia.
• Generación de código en
java, c++, python y php.
• Algunas
entidad-relación (pero ninguna lo suficientemente avanzada)
• Pocas herramientas
permiten ingeniería reversa, y si lo hacen solo es de lenguajes tipo java o
c++.
SELECCIÓN DEL MODELO APROPIADO
Para seleccionar el
modelo apropiado es necesario seguir los siguientes paso:
- Análisis de los requisitos y su
viabilidad: Recopilar, examinar y formular los requisitos del cliente y
examinar cualquier descripción que se pueda aplicar.
- Diseño general: Requisitos generales
de la arquitectura de la aplicación.
- Diseño en detalle: Definición precisa
de cada subconjunto de la aplicación.
- Programación: Implementación de un
lenguaje de programación para crear las funciones definidas durante la
etapa de diseño.
- Prueba de unidad: Prueba individual
de cada subconjunto de la aplicación para garantizar que se implementara
de acuerdo con las especificaciones.
- Integración: Para garantizar los
diferentes módulos se integren con la aplicación.
- Prueba o validación: Para garantizar
que el software cumple con las especificaciones originales.
- Documentación: Sirve para documentar
información necesaria para los usuarios del software y para desarrollos
futuros.
- Implementación: Poner en producción.
- Mantenimiento: Para todos los
procedimientos correctivos y las actualizaciones secundarias del software
(Mantenimiento continuo).
