CUADERNO DE TÉCNICAS DE DESARRROLLO DE SISTEMAS.

¿QUÉ ES UN BUEN SISTEMA DE INFORMACIÓN?

 Útil y Aprovechable.

Un buen software (sw) hace la vida de los usuarios más fácil y mejor.

 Fiable.

Un buen Software (sw) tiene pocos errores.

 Flexible.

Las necesidades de los usuarios cambian a lo largo del tiempo, incluso mientras el sw se está
desarrollando, de manera que es importante poder realizar cambios en el mismo más tarde. Todos
los cambios que se hacen en el sw después de entregado, se llama mantenimiento.

 Accesible.

Tanto para la compra y el mantenimiento.

Los costos de manos de obra son el elemento más significativo dentro de los costes de sw, de
manera que si este se reduce quiere decir que es relativamente sencillo fácil de desarrollar y
mantener.

 Disponible.

De otro modo, ¡No importa lo bueno que sea!

Se debe considerar 2 aspectos:

o El sw tiene que poder ejecutarse en el hardware (hw) disponibles, con el sistema

operativo (so) disponible.
o El sw debe ser lo primero que exista. De forma que un proyecto de sw debe
completarse con éxito y entregar el sw prometido.

¿Se tiene buenos sistemas?

 Problemas.
o Fallo, muchos programas no cumplen con los requisitos de los usuarios y/o tienen
fallos técnicos.
o Las necesidades de los usuarios se pierden en la captura de requisitos, varían
durante el desarrollo del sistema lo que hace que el sistema entregado no cumpla
con las necesidades de los usuarios.
o La mayoría de los usuarios esperan que las aplicaciones e incluso los sistemas
operativos fallen, se cuelguen o funcionen mal con cierta regularidad.
o La falta de Flexibilidad resulto evidente con el problema del milenio y la adecuación
de los procesos viejos a procesos de negocios cambiantes.
 o La accesibilidad, se relaciona mucho con la fiabilidad y flexibilidad ya que el coste
de ajuste de errores y el mantenimiento des el mayor conste en el que se incurre al
buscar sistemas de alta calidad.

06/11/2015

INGENIERIA DE SOFTWARE.
Veremos estándares relacionados con el proceso software.

 SEI’s CMM (Software Enginering Intitute – Capability Maturity Model)

 ISO 9000
 IEEE 1074 – IEEE 1998

PROCESO DE SOFTWARE.

Conjunto de actividades, acciones y resultados conocidos que producen un producto software,

adaptables a las necesidades del proyecto, basado en normas y estándares.

¿Qué es un proceso software?

 Es un conjunto de actividades y resultados asociados que producen un producto de

software.
 Es uno de los componentes de un método de desarrollo de software.
 Existen 4 actividades fundamentales de proceso, comunes para todos los procesos de
software.
o Especificación de requisitos software.
o Desarrollo de Software. (Análisis, diseño y pruebas)
o Validación de software. (Pruebas 1.- Caja Negra. 2.- Caja negra)
o Evolución del software. (Dar mantenimiento)
 Distintos procesos de software organizan las actividades de diferentes formas, y las
describen con diferente nivel de detalle.
o El tiempo de cada actividad varía, así como los resultados.
o Organizacionales diferentes usan procesos diferentes para producir el mismo
producto.
 Sin embargo, para algunos tipos de aplicación, algunos procesos son más convenientes que
otros.

Ciclo de Vida.

Sucesión de etapas por las que atraviesa un producto software a lo largo de su existencia
(durante su desarrollo y explotación).

Ciclo de Vida ≠ Ciclo de Desarrollo.

Ciclo de Vida:

Toda la vida del sistema des la concepción hasta el fin de uso.

 Ciclo de Desarrollo:

Desde el análisis hasta la entrega d usuario.

Estándares en Ingeniería del software.

Estándar: Es un conjunto de criterios aprobados, documentados y disponibles para determinar
la adecuación de una acción o de un objeto.

Guía: Conjunto de criterios bien definidos y documentados que encaminan una actividad o
tarea. (Es más flexible que el estándar)

¿Por qué usar estándares en Ingeniería del Software?

o Agrupan lo mejor y más apropiado de las buenas prácticas y uso del desarrollo de
software.
o Engloban los “conocimientos” que son patrimonio de una organización.
o Proporcionan un marco para implementar procedimientos de aseguramiento de la
calidad.
o Proporcionan continuidad entre el trabajo de distintas personas.

Tipo Estándares:

Estándares para dato: Desde aignar nombres a los datos y especificar longitud y tipo.

Codificación

Estructurales.

EJEMPLO:

o IEEE Std. 610.12-1990, Para manejar glosarios.

o IEEE Std. 829-1993, Para testeos.
o IEEE Std. 830-1992 o IEEE 1233-1998, Para especificación de requerimientos de software. *
o IEEE Std. 1045-1992, Para métricas que producen software.
o IEEE Std. 1062-1987, Para adquirir un software.
o IEEE Std. 1063-1987, Para documentación de software.
o IEEE Std. 1074-1997, Ciclos para el desarrollo del proceso software.
o IEEE Std. 12207-1996, Industria de software.
o IEEE Std. 1219-1992, Para mantenimiento de software.
o IEEE Std. 2001-2002, Para trabajar en entorno Web. *

Proceso de Software (PS) Efectivo.

Habilita a la organización a incrementar su productividad al desarrollar software.

o Permite estándar esfuerzos, proveer reusó, repetición y consistencia entre proyectos.

o Provee la oportunidad de introducir mejores prácticas de la industria.
o Permite entender que las herramientas debe ser utilizadas para soportar un proceso.
o Establece la base para una mayor consistencia y mejoras futuras.
 Proceso de Software (PS) Mejora.
Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

o Define cómo manejar los cambios y liberaciones a sistemas de software existentes.

o Define como lograr la transición del software a la operación, y cómo ejecutar los
esfuerzos de operación y soporte.

Elementos típicos de PS.

Actividad: Define las acciones que se llevan a cabo en un momento dado del desarrollo de software.

Flujo de Trabajo: Colección estructurada de actividades y elementos asociados (artefactos y roles),

que producen un resultado de valor.

Rol: Son responsables del proceso, pueden ser personas o herramientas.

Producto o Artefacto: Son las entradas y salidas de las actividades, pueden ser de diferentes tipos,
como documentos, modelos, componentes, planes, reportes, etc.

Disciplina: Conjunto integrado por actividades relativas a una rama particular de conocimiento. Ej.
Análisis y diseño.

Modelos de PS.

Modelo Genéricos: Abarcan los procesos relacionados con el desarrollo de software.

CMM: Modelo de madurado de capacidades – estándar de facto.

CMMI: Modelo mejorado del CMM.

ISO 900-2000: Sistemas para administración de la calidad – estándar.

ISO/IEC 15504: Marco para evolución de procesos de software.

MoProSoft: Modelo de proceso para la industria de software en México.

Modelos Específicos: Enfocados a la ingeniería de productos de software.

UP

RUP

PSP

TCP

Métodos de Evaluación SEI’s CMM.

Proporciona una medida de la eficacia global de las prácticas de ingeniería de sw de una compañía
y establece para ellos, cinco niveles de madurez del proceso.
CMM describe 5 niveles de madures: Inicial, Repetible, definido, gestionado y optimizado.

Inicial: El éxito depende de esfuerzos heroicos y personales más que de procesos.

Repetible: Se establecen políticas y procedimientos para llevar a cabo un proyecto. Una función y
criterios de calidad que deba cumplir.

Definidor: Se adopta un proceso sw. Estándar, y se adapta a cada proyecto.

Gestionado: La calidad del producto y del proceso es medida, predecible y cuantificable. Poniendo
métricas del software.

Optimizado: El proceso es continuamente mejorado usado las medidas obtenidas de procesos

anteriores.

ESTANDARES IEEE 1074-1998. Ciclo de Vida para desarrollo del Software.

 Actividades que se constituyen los procesos para el desarrollo y mantenimiento de

software.
 Procesos de gestión y soporte del ciclo de vida del software.
 Ciclo de Vida: Una aproximación lógica a la adquisición, el suministro, el desarrollo, la
explotación y el mantenimiento del software.
 El estándar da la pauta pero yo elijo que estándar seguir.
 El seguimiento prescribe los procesos del ciclo de vida, ósea, que pasos realizar.

Sección Título Procesos

2 Procesos de modelo de ciclo de Modelo del ciclo de vida del software.
vida del software.
3 Proceso de gestión del proyecto. Inicio del proyecto. Monitorización y control del
proyecto. Gestión de la calidad del software.
4 Proceso del Pre-Desarrollo Exploración de conceptos. Asignación del
sistema.
5 Proceso de Desarrollo Requisitos. Diseño. Implementación.
6 Proceso Post-Desarrollo Instalación. Operación y soporte.
Mantenimiento. Fin de Uso.
7 Proceso integrales. Verificación y Validación. Gestión de la
configuración e software. Desarrollo de la
documentación. Entrenamiento.

 Dentro de este estándar existen 2 procesos: Divididos en actividades (Obligatorias y

opcionales.):
 Información de entrada.
 Descripción.
 Información de salida.
 Antes de empezar un proyecto, revisar las actividades para ver si son aplicables, y establecer
un orden.
 Conformidad con el estándar. Realización de todas las actividades obligatorias.
 Establece un marco común para los procesos de ciclo de vida.
  Emplea términos bien definidos.
 Describe el ciclo de vida.
o Desde la definición de requerimientos hasta el fin de uso y contiene procesos para
adquirir y suministrar productos y servicios de software.

ESTANDAR IEEE/EIA (ISO/IEC) 12207

 Un marco de referencias que contiene los procesos, las actividades y las tareas involucradas
en el desarrollo, la explotación y el mantenimiento de un producto software, abarcando la
vida del sistema.
o Proceso: Conjunto de actividades.
o Actividad: Conjunto de tareas.
o Tarea: Acción que transforma las entradas en salidas.
 Proporciona procesos para definir, controlar y mejorar los procesos de ciclo de software.
PROCESOS DE ESTE ESTANDAR.
 Procesos principales.
o Procesos de Suministros: Actividades y tareas que el comprador, el cliente o el
usuario realizan para adquirir u sistema de productos (servicio) software:
 Preparación u publicación de una solicitud de ofertas.
 Selección del suministrador del software.
 Gestión de los procesos para adquirir.
 Actividades y tareas que realiza el suministrador.
o Procesos de Desarrollo e Implementación del proceso: Contiene las actividades y
tareas realizadas por el desarrollador.
 Si no está especificado en el contrato, el desarrollador definirá un modelo
del ciclo de vida, así como el lenguaje a utilizar, etc.
o Procesos de Desarrollo - Análisis de procedimiento de software.
 IEE 830-1998
 DI-IPSC- 81433
o Procesos de Desarrollo - Diseño detallado del software.
 Diseño detallado de componentes, interfaces y BD.
o Procesos de Desarrollo – Actividades Finales.
 Prueba del sistema.
 Instalación del software.
 Integración del software.
 Prueba del software.
 Integración del sistema.
 Prueba del sistema.
 Instalación del software.
 Soporte del proceso de aceptación del software.
o Proceso de Explotación: Se explota el software y el proceso, debe ser operado de
acuerdo a la documentación.
o Proceso de mantenimiento: El software o la documentación necesita ser
modificado, debido a problemas o a necesidades de mejora o adaptación:
 Nuevos errores detectados.
  Cambios en la legislación.
 Cambios en el entorno.
 Necesidad de mejoras.
 Migración a un nuevo entorno operativo.
 Se va a terminar con su uso.
 Procesos de soporte.
o Sirven de apoyo al resto.
o Contribuyen al éxito y calidad del proyecto software.
o Se aplica en cualquier parte del ciclo de vida.
o Sirve de apoyo al resto de procesos.
o Se aplican en cualquier momento del ciclo de vida.
 Documentación: Registrar información producida por cualquier proceso y
gestiona los documentos necesarios para todas las personas involucradas
en el proceso de software.
 Gestión de la configuración: Saber las últimas actualizaciones.
 Resolución de los problemas.
 Procesos de la organización (procesos generales):
o Objetivo: Establece, implementar y mejorar.
 Proceso de adaptación.
o Permite adaptar a cada proyecto y organización.
o Factores que influyen en adquirir, desarrollar, explotar o mantener un sistema:
 Tamaño y complejidad del proyecto.
 Requisitos para sistema.
 Métodos de desarrollo.
 Variaciones en las políticas y procedimientos de la organización.

CICLO DE VIDA
Ciclo de Vida: Es el que da lineamiento y fases para desarrollo de software.

Metodología: Esta basado en el ciclo de vida. ¿Qué? ¿Cómo se realizara?

La madurez del proceso de Software se relaciona con estos 2 Puntos anteriores.

Modelos de Procesos.
La ingeniería de software establece y se vale de una serie de modelos que instauran y muestran las
distintas etapas y estados por los que pasa un producto software, desde su concepción inicial,
pasando por su desarrollo, puesto en marcha y posterior mantenimientos, hasta la retirada del
producto.

Modelos Tradicionales.

Formados por un conjunto por un conjunto de fases o actividades en las que no tienen en cuenta la
naturaleza evolutiva del software.

 Clásico, lineal o en cascada.

 Estructurado.
  Basado en prototipos.
 Desarrollo rápido de aplicaciones. (RAD)

Modelos Evolutivos.

Son modelos que se adaptan a la evolución que sufren los requisitos del sistema en función del
tiempo.

 En espiral.
 Evolutivo.
 Incremental.
 Modelo de desarrollo concurrente.

Modelos orientados a la reutilización.

 Basado en componentes.
 Proceso Unificado.

Modelos para sistemas Orientado a Objetos.

 De agrupamiento.
 Fuente.
 Basados en componentes.
 Proceso Unificado.

Procesos ágiles.

 Programación extrema (XP).

 Desarrollo de software adaptativo.
 Scrum, Crystal..

Modelos para sistemas web.

 UML- Based Web Engineering.

Modelo Clásico, Lineal o en Cascada.

 Es el modelo más antiguo, propuesto por Winston Royce en 1970
 Basado en la mentalidad de línea de ensamblaje (cartesiano).
 Es sencillo y fácil de entender.
 El proyecto pasara a través de algunas fases.
 Al final de cada fase verifican las tareas de trabajos y productos. (DESVENTAJA)

Requisitos. Diseño. Implementación. Prueba. Mantenimiento.

Ventajas.
 Es para proyectos estables donde sus requisitos no son cambiantes.
 También para proyectos pequeños donde los requisitos están bien entendidos.
 Modelo bien estructurado donde no se mesclan las fases.
 Necesita los requisitos en macro.
 Inconvenientes.
 Un proyecto raramente sigue una secuencia lineal.
 Un cliente va a estableces al principio todos los requisitos necesario, provocando que puede
ser cambiante los requisitos.
 Los resultados no son visibles en cada fase del modelo.
 En caso de que se cambien los requisitos, es necesario volver a la fase de requisitos.
 Muchas veces se considera un modelo pobre para proyectos largos, complejos, orientado a
objetos y por su puesto en aquellos en que los requisitos son cambiantes.

MODELO V.
 Las pruebas es necesario que se apliquen lo más pronto posible.
 Integra cada fase en pruebas (Verificación, validación), se pueden integran en cada fase del
ciclo de vida. Sus pruebas son aplicables más en las etapas tempranas del modelo.
 La parte izquierda de la V representa la descomposición de los requisitos y la creación de las
especificaciones del sistema, el lado derecho representa la integración de partes y
verificación y la V validación y verificación.
Ventajas.
 Simple y fácil de ocupar.
 En cada una de las fases hay entregables específicos.
 Tiene una oportunidad de éxito sobre el modelo cascada.
 Es un modelo que puede funcionar para proyectos pequeños donde los requisitos
entendidos.
Inconvenientes.
 Es un modelo muy rígido.
 Poca flexibilidad.
 El software se desarrolla en la durante de implementación.

MODELO INCREMENTAL.
 Modelo derivado de los ciclos de vida de cascada.
 Surge entre las necesidades del usuario y permite mejorar los malos entendidos del usuario
durante la etapa de recogida de requisitos.
 Consiste en varios ciclos de vida en cascada. El cliente es después de cada interacción evalúa
el producto.
 Este modelo se suele utilizar en proyectos en los que los requisitos no están claros por parte
del usuario.
 Realiza “n” iteraciones hasta que el usuario quede satisfecho.
Ventajas:
 No hace falta que los requisitos estén totalmente definidos.
 Realiza el desarrollo en pequeños ciclos gestionan mejor los riesgos y entregas.
Inconvenientes:
 La primera de las desventajas que ofrece este modelo, el no tener los requisitos definidos
desde el principio.
 MODELO DE CICLO DE VIDA EN ESPIRAL.
Por Barry Boehm en 1985.

 Consiste en una serie de ciclos que se repiten.

 Es parecido al modelo incremental, la diferencia es que tiene en cuenta el concepto de
riesgos.
 Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con
los requisitos establecidos, también se verifica que funciona correctamente. El propio
cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el
proyecto y cuando empieza la fase de mantenimiento.
 Se especializa en proyectos largos, caros y complicados.
 Es el primer modelo en explicar las iteraciones.
 Consiste en una serie de ciclos que se repiten en forma espiral, comenzando desde el centro.
Ventajas:
 El análisis de riesgos se hace de forma explícita y clara. Une los mejores elementos de los
restantes modelos. Entre ellos:
o Reduce riesgos de proyecto
o Incorpora objetivos de calidad.
o Integra el desarrollo con el mantenimiento.
 Se utilizan en proyectos largos de emisión crítica.
Inconvenientes:
 Existe un alto nivel de experiencia y cierta habilidad en los analistas de riesgos.
 Esto puede llevar a que sea un modelo costoso. Además, no es un modelo que funcione bien
para proyectos pequeños.
Comparación con otros modelos.
 La distinción más destacada entre el modelo de espiral y otros modelos es la tarea explicada
de evolución de riesgos.
 La diferencia es que el incremental se parte de que no hay incertidumbre en los requisitos
iniciales; en este, en cambio, se es consistente de que se comienza con un alto grado de
incertidumbre.