Conociendo el contexto del software
Base conceptual/Fundamentos teóricos del software
Software
se puede definir como el
que hacen funcionar y realizar tareas
específicas a una computadora
procedimientos
reglas
datos
pueden ir desde
un sistema operativo
hasta aplicaciones específicas
editores de texto
videojuegos
editores de imágenes
Para generar un producto de software
se requieren de métodos y
técnicas para que
el desarrollo sea de calidad
Algunos problemas identificados en la producción de software incluyen
Retrasos considerables en la entrega
Poca productividad
Elevados costos de producción y cargas de mantenimiento
Baja calidad y fiabilidad del producto
Gran dificultad en el mantenimiento
Ciclo de vida del software
se utiliza para estructurar las actividades
que se llevarán a cabo en el desarrollo de un producto
Existen varios modelos de ciclo de vida
dependiendo de esto serán
las etapas que lo componen
la forma en cómo se lleva a cabo el proyecto
Etapas en común dependiendo del modelo
Análisis
Diseño
Codificación
Pruebas
Mantenimiento
Herramientas CASE
conjunto de
utilidades, métodos y técnicas
empleadas por los profesionales del
desarrollo de software
facilitan y agilizan el ciclo de vida en un sistema
Es útil en tareas como
el diseño del proyecto
cálculo de costos
generación de código a partir del diseño
generación
automática de documentación
características y ventajas de las herramientas CASE
Permiten la comprobación de errores
en etapas tempranas del
desarrollo
Tienen soporte de reusabilidad
Aumentan la calidad del producto
Mejoran la productividad en el
desarrollo
mantenimiento
Reducen el tiempo y el costo de desarrollo
Facilitan el uso de las distintas metodologías
propias de la
Ingeniería del software
Técnicas de implementación de sistemas
La metodología es un
modo sistemático de producir software
Una metodología se puede definir
como
conjunto de procedimientos necesarios para llegar a un objetivo
Tipos de metodologías
Metodología estructurada
Metodología orientada a objetos
Metodología OMT
Metodología UML
Metodología utilizada
Estándares en la construcción del software
Hacen parte de la ingeniería del software
utilización de estándares y metodologías para
el diseño
programación
prueba y análisis
del software desarrollado
objetivo
ofrecer mayor confiabilidad
concordancia con los requisitos exigidos
Normas ISO/IEC
ISO 12207
Modelos de ciclos de vida del software
El estándar se concibe para los interesados en
adquisición de software
Desarrolladores
Proveedores
El estándar indica unos procesos que van
desde la recopilación
de requisitos
hasta la culminación
del software
En total son 17 procesos que se agrupan en
tres categorias
Principales
de apoyo
de organización
Norma ISO/IEC 9126
es la que evalúa los productos de software
esta indica
las características de la calidad y lineamientos para su uso
las características de la calidad y las métricas asociadas
puede ser útil para
evaluar el producto
definir los requerimientos de la calidad
esta definida bajo un marco conceptual basado en
factores como
calidad del proceso
calidad del producto del software
contribuye a
mejorar la calidad en uso
calidad en uso
Estándar ISO/IEC 1598
Es usado como base metodológica
para evaluar el producto del software
esta norma ofrece
métricas y requisitos
para los procesos de evaluación
características del proceso de evaluación
repetitividad
reproducibilidad
imparcialidad
objetividad
medidas concretas que participan
Análisis de los requisitos de evaluación
Evaluación de las especificaciones
Evaluación del diseño y definición del plan de evaluación
Ejecución del plan de evaluación
Evaluación de la conclusión
define el proceso para evaluar un producto del software
consta de seis partes
ISO/IEC 14598-1
Visión General
ISO/IEC 14598-2
Planeamiento y Gestión
ISO/IEC 14598-3
Proceso para desenvolvedores
ISO/IEC 14598-4
Proceso para adquirentes
ISO/IEC 14598-5
Proceso para avaladores
ISO/IEC 14598-6
Documentación de Módulos
Norma ISO/IEC 25000 (SquaRE)
es una nueva serie de normas que se basa en
ISO
9126
ISO 14598
Objetivo principal de la serie SQuaRE
coordinación y
armonización del contenido
de ISO 9126 y de ISO 15939:2002 (Measurement Information Model)
SQuaRE está formada por las divisiones
ISO/IEC 2500n
División de gestión de calidad.
ISO/IEC 2501n.
División del modelo de calidad.
ISO/IEC 2502n
División de mediciones de calidad
ISO/IEC 2503n
División de requisitos de calidad.
ISO/IEC 2504n
División de evaluación de la calidad.
ISO/IEC 25050–25099
Estándares de extensión SQuaRE.
Spice
Apoya el desarrollo de una Norma Internacional
para la
Evaluación de
Procesos de Software
Tiene tres objetivos principales
para
-desarrollar un proyecto de trabajo y generar un estándar
para la evaluación de procesos de software.
llevar a cabo los ensayos de la industria de la norma emergente
promover la transferencia de tecnología de la evaluación de procesos de software en la industria mundial del software a nivel mundial
Es creciente en número de métodos de evaluación disponibles
CMMI
Es un modelo de mejora de los procesos de construcción de software
Provee
elementos necesarios para determinar su
efectividad
puede ser utilizado como guía para mejorar las actividades de
un proyecto
área - organización
Nivel 0: Incompleto
El proceso no se realiza, o no se consiguen los objetivos
Nivel 1
Inicial o ejecutando
el proceso se ejecuta y
se logra su objetivo
Nivel 2 Repetible:
Se da cuando el éxito de los resultados obtenidos se puede repetir
Nivel 3
Definido:
la forma de desarrollar proyectos está
definida, establecida, documentada
existen métricas.
Nivel 4 Administrado:
se usan métricas para gestionar la organización
Nivel 5 Optimizado:
Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades
IEEE (Institute of Electrical and Electronics Engineers)
Su creación se remonta al año 1884
método de establecimiento y mejora del trabajo en equipo
para procesos software
su trabajo es promover
la creatividad
el desarrollo
y la integración
compartir y aplicar los avances en las
tecnologías de la información
produce más del 30%
de la literatura publicada en el mundo sobre ingeniería eléctrica
posee cerca de 900 estándares activos
Algunos de sus estándares son
VHDL
POSIX
IEEE 1394
IEEE 488
IEEE 802
IEEE 802.11
IEEE 754
PSP- Proceso personal del software
método de autoconocimiento
se concentra en las prácticas de trabajo de
los ingenieros en una forma individual
se caracteriza porque
se aplica a programas pequeños de menos de 10.000 líneas de código
sirve para producir software de calidad
TSP-Team Software Process
método de establecimiento y mejora del trabajo en equipo
para procesos de software
Es un
proceso para equipos de software
MOPROSOFT
Está dirigido a
empresas o áreas internas dedicadas al
desarrollo y/o mantenimiento de software
Es una norma Mexicana
sirve para estandarizar
operaciones
prácticas en gestión de ingeniería de software
Métricas de construcción y diseño
según el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE)
la métrica se define como
una medida cualitativa, del grado en que un sistema, componente o proceso posee un atributo determinado
Si se desea conseguí la calidad de un software la medición es esencial
Las métricas sirven para
evaluar
mejorar
clasificar el software final
se recopilan en el transcurso de todos
los proyectos
durante largos períodos
Tipos de métricas
Métricas a nivel de código fuente
conjunto de medidas de software
proporcionan a los programadores
mejor visión del código
se determinan examinando las
líneas de código de los módulos
se determinan examinando los
atributos de calidad
que se encuentran en las líneas de código
Métricas CK Chidamber y Kemerer
métricas orientadas a clases
individuales, herencia y colaboraciones
Es uno de los conjuntos de métricas
más referenciado
Métricas de Li Henry
consideran cinco de las métricas de Chidamber y Kemerer
WMC
DIT
NOC
RFC
LCOM
Métricas de Halstead
conjunto de medidas primitivas
determinan el tamaño del software asumiendo que el programa está compuesto por
un conjunto de elementos
clasificados en
operadores
operandos
Métricas de Lorenz y Kidd (1994)
dividen las métricas basadas en clases
en cuatro categorías
tamaño
herencia
valores internos
valores externos
Líneas de código
atributo más usado para interpretar
el tamaño de un programa
Métricas R. Martin (1994)
Ca: Afferent Couplings:
número de clases de otros paquetes que dependen de las clases del propio paquete
Ce: Efferent Couplings:
número de clases dentro del propio paquete que dependen de clases de otros paquetes
I: Instability = Ce / (Ca + Ce)
métrica comprendida entre [0,1], siendo 0 la máxima estabilidad y 1 máxima inestabilidad
Modelos de construcción de software
Ofrecen un marco de trabajo usado para
controlar el proceso de desarrollo de sistemas de información
Modelos y metodologías del desarrollo de software
Modelo en cascada o Clásico (modelo tradicional)
modelo en el cual se ordenan rigurosamente
las etapas del desarrollo del software
El inicio de una etapa de desarrollo debe esperar el fin de la etapa anterior
cualquier error detectado lleva al
rediseño del área de código afectado
aumentando el costo del desarrollo del proyecto
Modelo de prototipos
Pertenece a los modelos evolutivos
el prototipo debe de ser construido rápidamente
utilización escasa de recursos
El prototipo es construido para
mostrárselo al cliente
obtener criticas y retroalimentación
Las etapas de este modelo son
1. Plan rápido
2. Modelo
4. Entrega y retroalimentación
5. Comunicación
Modelo en espiral
las actividades se desarrollan en espiral
estas se realizan conforme se van seleccionando
de acuerdo al análisis de riesgo
tiene dos formas en las cuales se debe de planificar el proyecto
la forma angular
indica únicamente el avance del software dentro del proyecto
la forma radial
indica el aumento del costo dado que cada iteración conlleva más tiempo de desarrollo.
Desarrollo por etapas
Es similar al modelo por etapas
Al al momento de la crítica o retroalimentación
no se obtendrán completamente las características del software
estas se descubren en el proceso
del avance del software
fases del modelo
1. Especificación conceptual
2. Análisis de requisitos
3. Diseño inicial
4. Codificación y depuración
Desarrollo iterativo y creciente o Iterativo e Incremental
Resuelve los problemas encontrados en el modelo en cascada
ofrece entornos de trabajo con técnicas para su correcta utilización
Es esencial para el método de programación extrema
Se puede dividir en los siguientes procesos
1. Etapa de inicialización
construcción de un producto
obtener retroalimentación de parte del usuario final.
2. Etapa de iteración
análisis, rediseño e implementación del producto
3. Lista de control del proyecto.
Tareas que describen las partes que conforman el proyecto
RAD o desarrollo de aplicaciones rápidas
permite la construcción rápida de sistemas utilizables
compuesto por un grupo reducido de personas
incluye
desarrolladores
testers del sistema
toma en cuenta las características de
usabilidad
utilidad
rapidez de la ejecución de la aplicación
Desarrollo concurrente
Se conoce como ingeniería concurrente
Es utilizado en su mayoría para aplicaciones cliente servidor
Una de las características es
que está orientado a las necesidades del usuario
las decisiones de la gestión
los resultados de las revisiones
Ventajas
está orientado a grupos de trabajo independientes
Desventajas
necesita de grupos de trabajo
condiciones necesarias para su implementación.
Proceso Unificado
se distingue por la utilización de casos de uso
está centrado en la arquitectura y la utilización de iteraciones incrementales
puede ser implementado hacia otros proyectos de distintas organizaciones
es utilizado para evitar problemas legales con el método RUB
características
es iterativo e incremental
dirigido por casos de uso
centrado en la arquitectura
enfocado en los riesgos
RUP o proceso unificado relacional
Es propiedad de IBM
desarrollado por la empresa Rational Software
Es uno de los modelos más utilizado en el
análisis, diseño
e implementación de la documentación de sistemas orientados a objetos
principios básicos de este método
adaptar el proceso
equilibrar prioridades
demostrar valor iterativamente
colaboración entre equipos
elevar el nivel de abstracción
enfoque a la calidad
Mapa mental
Por: Jhoan Alexander García Soto