ACI491 U5 Introduccion A La Ingenieria de Software

ACI491:
Ingeniería de Software
Unidad 5:
Introducción a la Ingeniería
de Software
 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy 1
Contenidos
• Importancia del software.
• Impacto del software en los productos
y servicios.
• Crisis del software: Problemas y
soluciones.
• Ciclo de vida del software: paradigmas
y fases genéricas.
• Planificación de proyectos de software.
Objetivos específicos
 Conocer la importancia que tiene el
software al interior de las organizaciones.
 Ser capaz de identificar problemas y
entregar las soluciones mas optimas para
estos.
 Identificar cuando es necesario una
solución informática (software) y cuando
no es necesaria.
 Ser capaz de planificar un software,
identificando claramente sus ciclo de vida.
Introducción
• Hoy en día el software tiene un doble papel: Es un
producto y, al mismo tiempo, el vehículo para
entregarlo.
• Como producto, hace entrega de la potencia informática
que incorpora el hardware informático o, más
ampliamente, una red de computadoras que es accesible
por hardware local.
• Si reside dentro de un teléfono celular u opera dentro de
una computadora central, el software es un
transformador de información, produciendo,
gestionando, adquiriendo, modificando, mostrando o
transmitiendo información que puede ser tan simple
como un solo bit, o tan complejo como una presentación
en multimedia.
• Como vehículo utilizado para hacer entrega del
producto, el software actúa como la base de control de
la computadora (sistemas operativos), la comunicación
de información (redes) y la creación y control de otros
programas (herramientas de software y entomos).
Preguntas claves
• ¿Por qué lleva tanto tiempo terminar
los programas?
• ¿Por qué son tan elevados los costes
de desarrollo?
• ¿Por qué no podemos encontrar todos
los errores antes de entregar el
software a nuestros clientes?
• ¿Por qué nos resulta difícil constatar el
progreso conforme se desarrolla el
software?
Tipos de software
Una clasificación (Pressman) puede ser:
• De sistema
• De tiempo real
• De gestión
• De ingeniería y científico
• Empotrado (embedded software)
• De computadoras personales
• Basado en la Web
• De inteligencia artificial
Crisis del software
• Muchos observadores de la industria han
caracterizado los problemas asociados con el
desarrollo del software como una «crisis».
• Más de unos cuantos libros han recogido el impacto
de algunos de los fallos mas importantes que
ocurrieron durante la década pasada.
• No obstante, los mayores éxitos conseguidos por la
industria del software han llevado a preguntarse si
el término (crisis del software) es aún apropiado.
• Robert Glass expone: «Puedo ver en mis ensayos
históricos de fallos y en mis informes de excepción,
fallos importantes en medio de muchos éxitos, una
copa que está [ahora] prácticamente llena.»
Crisis … (2)
• El conjunto de problemas encontrados en el
desarrollo del software de computadoras no se
limitan al software que “no funciona
correctamente”.
• El mal abarca los problemas asociados a cómo
desarrollar software, cómo mantener el volumen
cada vez mayor de software existente y cómo poder
esperar mantenemos al corriente de la demanda
creciente de software.
• Vivimos con esta aflicción desde este día - d e
hecho, la industria prospera a pesar de ello.
• Y así, las cosas podrán ser mejores si podemos
encontrar y aplicar un remedio.
Mitos
• Muchas de las causas de la crisis del
software se pueden encontrar en una
mitología que surge durante los
primeros años del desarrollo del
software.
• A diferencia de los mitos antiguos, que
a menudo proporcionaban a los
hombres lecciones dignas de tener en
cuenta, los mitos del software
propagaron información errónea y
confusión.
Mitos de gestión (1)
• Mito. Tenemos ya un libro que está lleno de
estándares y procedimientos para construir
software, ¿no le proporciona ya a mi gente
todo lo que necesita saber?
• Realidad. Está muy bien que el libro exista,
pero: ¿se usa?, ¿conocen los trabajadores
su existencia?, ¿refleja las prácticas
modernas de desarrollo de software?, ¿es
completo?, ¿está diseñado para mejorar el
tiempo de entrega mientras mantiene un
enfoque de calidad?
• En muchos casos, la respuesta a todas estas
preguntas es NO.
• Mito. Mi gente dispone de las herramientas
de desarrollo de software más avanzadas,
después de todo, les compramos las
computadoras más modernas.
• Realidad. Se necesita mucho más que el
último modelo de computadora grande o de
PC para hacer desarrollo de software de
gran calidad.
Las herramientas de ingeniería del software
asistida por computadora (CASE) son más
importantes que el hardware para conseguir
buena calidad y productividad, aunque la
mayoría de los desarrolladores del software
todavía no las utilicen eficazmente.
• Mito. Si fallamos en la planificación, podemos añadir
más programadores y adelantar el tiempo perdido (el
llamado algunas veces “concepto de la horda Mongol”).
• Realidad. El desarrollo de software no es un proceso
mecánico como la fabricación.
Añadir gente a un proyecto de software retrasado lo
retrasa aún más.
Al principio, esta declaración puede parecer un
contrasentido. Sin embargo, cuando se añaden nuevas
personas, la necesidad de aprender y comunicarse con el
equipo puede y hace que se reduzca la cantidad de
tiempo gastado en el desarrollo productivo.
• Puede añadirse gente, pero sólo de una manera
planificada y bien coordinada.
Mitos del cliente
• Un cliente que solicita una aplicación de software
puede ser una persona del despacho de al lado, un
grupo técnico de la sala de abajo, el departamento
de ventas o una compañía exterior que solicita un
software bajo contrato.
• En muchos casos, el cliente cree en los mitos que
existen sobre el software, debido a que los gestores
y desarrolladores del software hacen muy poco para
corregir la mala información.
• Los mitos conducen a que el cliente se cree una
falsa expectativa y, finalmente, quede insatisfecho
con el que desarrolla el software.
Mitos del cliente (2)
• Mito. Una declaración general de los objetivos es
suficiente para comenzar a escribir los programas.
Podemos dar los detalles más adelante…
• Realidad. Una mala definición inicial es la principal
causa del trabajo baldío en software.
Es esencial una descripción formal y detallada del
ámbito de la información, funciones,
comportamiento, rendimiento, interfaces, ligaduras
del diseño y criterios de validación.
Estas características pueden determinarse sólo
después de una exhaustiva comunicación entre el
cliente y el analista.
Mitos del cliente (3)
• Mito. Los requisitos del proyecto cambian
continuamente, pero los cambios pueden
acomodarse fácilmente, ya que el software
es flexible.
• Realidad. Es verdad que los requisitos del
software cambian, pero el impacto del
cambio varía según el momento en que se
introduzca.
• Si se pone cuidado al dar la definición inicial,
los cambios solicitados al principio pueden
acomodarse fácilmente.
• El cliente puede revisar los requisitos y
recomendar las modificaciones con
relativamente poco impacto en el coste.
Impacto del cambio (1)
Definición Desarrollo Después

de la entrega
Impacto del cambio (2)
• Cuando los cambios se solicitan durante el diseño
del software, el impacto en el coste crece
rápidamente. Ya se han acordado los recursos a
utilizar y se ha establecido un marco de trabajo del
diseño. Los cambios pueden producir trastornos que
requieran recursos adicionales e importantes
modificaciones del diseño; es decir, coste adicional.
• Los cambios en la función, rendimiento, interfaces u
otras características, durante la implementación
(codificación y prueba) pueden tener un impacto
importante sobre el coste.
• Cuando se solicitan al final de un proyecto, los
cambios pueden producir un orden de magnitud
más caro que el mismo cambio pedido al principio.
Mitos de los desarrolladores (1)
• Los mitos en los que aún creen muchos
desarrolladores se han ido fomentando durante 50
años de cultura informática.
Durante los primeros días del desarrollo del
software, la programación se veía como un arte.
Las viejas formas y actitudes tardan en morir.
• Mito. Una vez que escribimos el programa y
hacemos que funcione, nuestro trabajo ha
terminado.
• Realidad. Alguien dijo una vez: “cuanto más
pronto se comience a escribir código, más se
tardará en terminarlo”.
Los datos industriales indican que entre el 60 y el
80 por ciento de todo el esfuerzo dedicado a un
programa se realizará después de que se le haya
entregado al cliente por primera vez.
• Mito. Hasta que no tengo el programa
“ejecutándose”, realmente no tengo forma
de comprobar su calidad.
• Realidad. Desde el principio del proyecto se
puede aplicar uno de los mecanismos más
efectivos para garantizar la calidad del
software: la revisión técnica formal.
• La revisión del software es un “filtro de
calidad” que se ha comprobado que es más
efectivo que la prueba, para encontrar
ciertas clases de defectos en el software.
• Mito. Lo único que se entrega al terminar el
proyecto es el programa funcionando.
• Realidad. Un programa que funciona es
sólo una parte de una configuración del
software que incluye muchos elementos.
• La documentación proporciona el
fundamento para un buen desarrollo y, lo
que es más importante, proporciona guías
para la tarea de mantenimiento del
software.
Primeras conclusiones
• Muchos profesionales del software
reconocen la falacia de los mitos descritos
anteriormente.
• Lamentablemente, las actitudes y métodos
habituales fomentan una pobre gestión y
malas prácticas técnicas, incluso cuando la
realidad dicta un método mejor.
• El reconocimiento de las realidades del
software es el primer paso hacia la
formulación de soluciones prácticas para su
desarrollo.
Resumen (1)
• El software se ha convertido en el elemento
clave de la evolución de los sistemas y
productos informáticos.
• En los pasados 50 años, el software ha
pasado de ser una resolución de problemas
especializada y una herramienta de análisis
de información, a ser una industria por sí
misma.
• Pero la temprana cultura e historia de la
“programación” ha creado un conjunto de
problemas que persisten todavía hoy.
Resumen (2)
• El software se ha convertido en un factor
que limita la evolución de los sistemas
informáticos.
• El software se compone de programas,
datos y documentos.
• Cada uno de estos elementos componen una
configuración que se crea como parte del
proceso de la ingeniería del software.
• El intento de la Ingeniería del Software es
proporcionar un marco de trabajo para
construir software con mayor calidad.
Ejercicios (1)
1. El software es la característica que diferencia a muchos
productos y sistemas informáticos. Dé ejemplos de dos o tres
productos y de, al menos, un sistema en el que el software,
no el hardware, sea el elemento diferenciador.
2. En los años cincuenta y sesenta la programación de
computadoras era un arte aprendido en un entorno
básicamente experimental. ¿Cómo cree Ud. que ha afectado
esto a las prácticas de desarrollo del software hoy?
3. Muchos autores han tratado el impacto de la “era de la
información”. Dé varios ejemplos (positivos y negativos) que
indiquen el impacto del software en nuestra sociedad.
4. Seleccione una aplicación específica e indique:
(a) la categoría de la aplicación de software en la que encaje;
(b) el contenido de los datos asociados con la aplicación;
(c) la información determinada de la aplicación.
Ejercicios (2)
5. A medida que el software se difunde más, los riesgos para el
público (debido a programas defectuosos) se convierten en
una preocupación cada vez más significativa. Desarrolle un
escenario realista del juicio final (distinto a Y2K) en donde el
fallo de computadora podría hacer un gran daño (económico o
humano).
6. Lea detenidamente el grupo de noticias de Internet
comp.risk y prepare un resumen de riesgos para las
personas. Alternativa: Software Engineering Notes publicado
por la ACM.
7. Escriba un papel que resuma las ventajas recientes en una de
las áreas de aplicaciones de software principales. Entre las
selecciones potenciales se incluyen: aplicaciones avanzadas
basadas en Web, realidad virtual, redes neuronales
artificiales, interfaces humanas avanzadas y agentes
inteligentes.
8. Los mitos destacados en la presentación se están viniendo
abajo lentamente a medida que pasan los años. Pero otros se
están haciendo un lugar. Intente añadir un mito o dos mitos
“nuevos” a cada categoría.
¿Qué es Ingeniería del Software?
Una vuelta mas…
Según Pressman
• [La ingeniería del software] es el
establecimiento y uso de principios
robustos de la ingeniería a fin de
obtener económicamente software que
sea fiable y que funcione
eficientemente sobre máquinas reales.
Según Sommerville
Según IEEE
• El IEEE [IEE93] ha desarrollado una
definición completa:
Ingeniería del software:
(1) La aplicación de un enfoque
sistemático, disciplinado y
cuantificable hacia el desarrollo,
operación y mantenimiento del
software; es decir, la aplicación de
ingeniería al software.
(2) El estudio de enfoques como en (1).
¿Qué es?
• Cuando trabaja para construir un
producto o un sistema, es importante
seguir una serie de pasos predecibles:
un mapa de carreteras (roadmap) que
le ayude a obtener el resultado
oportuno de calidad.
• El mapa de carreteras a seguir es
llamado “proceso del software”.
El proceso del software (1)
• Como el software, al igual que el
capital, es el conocimiento
incorporado, y puesto que el
conocimiento está inicialmente
disperso, el desarrollo del software
implícito, latente e incompleto en gran
medida, es un proceso social de
aprendizaje.
• El proceso es un diálogo en el que se
reúne el conocimiento y se incluye en
el software para convertirse en
software.
El proceso del software (2)
• El proceso proporciona una interacción
entre los usuarios y los diseñadores,
entre los usuarios y las herramientas
de desarrollo, y entre los diseñadores
y las herramientas de desarrollo
[tecnología].
• Es un proceso interactivo donde la
herramienta de desarrollo se usa como
medio de comunicación, con cada
iteración del diálogo se obtiene mayor
conocimiento de las personas
involucradas.
¿Quién lo hace?
• Los ingenieros de software y sus
gestores adaptan el proceso a sus
necesidades y entonces lo siguen.
• Además las personas que han
solicitado el software tienen un papel a
desempeñar en el proceso del
software.
Importancia
¿Por qué es importante?
• Porque proporciona estabilidad, control y
organización a una actividad que puede, si
no se controla, volverse caótica.
¿Cuáles son los pasos?
• A un nivel detallado, el proceso que
adoptemos depende del software que
estamos construyendo.
• Un proceso puede ser apropiado para crear
software de un sistema de aviación,
mientras que un proceso diferente por
completo puede ser adecuado para la
creación de un sitio Web.
¿Cuál es el producto obtenido?
• Desde el punto de vista de un
ingeniero de software, los productos
obtenidos son:
–programas,
–documentos y
–datos
que se producen como consecuencia
de las actividades de ingeniería del
software definidas por el proceso.
Calidad
¿Cómo puedo estar seguro de que lo he
hecho correctamente?
• Hay una cantidad de mecanismos de
evaluación del proceso del software que
permiten a las organizaciones determinar la
“madurez” de su proceso del software.
• Sin embargo, la calidad, oportunidad y
viabilidad a largo plazo del producto que
está construyendo son los mejores
indicadores de la eficiencia del proceso que
estamos utilizando.
La Ingeniería del software es un
tecnología multicapa (1)
• El fundamento de la ingeniería del software
es la capa de proceso.
• El proceso de la ingeniería del software es la
unión que mantiene juntas las capas de
tecnología y que permite un desarrollo
racional y oportuno de la ingeniería del
software.
La Ingeniería del software -
tecnología multicapa (2) - proceso
• El proceso define un marco de trabajo para
un conjunto de áreas clave de proceso
(ACPs) que se deben establecer para la
entrega efectiva de la tecnología de la
ingeniería del software.
• Las áreas claves del proceso forman la base
del control de gestión de proyectos del
software y establecen el contexto en el que
se aplican los métodos técnicos, se obtienen
productos del trabajo (modelos,
documentos, datos, informes, formularios,
etc.), se establecen hitos, se asegura la
calidad y el cambio se gestiona
adecuadamente.
La Ingeniería del software - tecnología
multicapa (3) - métodos
• Los métodos de la ingeniería del software
indican “cómo” construir técnicamente el
software.
• Los métodos abarcan una gran gama de
tareas que incluyen análisis de requisitos,
diseño, construcción de programas, pruebas
y mantenimiento.
• Los métodos de la ingeniería del software
dependen de un conjunto de principios
básicos que gobiernan cada área de la
tecnología e incluyen actividades de
modelado y otras técnicas descriptivas.
La Ingeniería del software - tecnología
multicapa (4) - herramientas
• Las herramientas de la Ingeniería del
software proporcionan un enfoque
automático o semiautomático para el
proceso y para los métodos.
• Cuando se integran herramientas para que
la información creada por una herramienta
la pueda utilizar otra, se establece un
sistema de soporte para el desarrollo del
software llamado ingeniería del software
asistida por computadora (CASE).
Una visión general de la ingeniería
del software
• La ingeniería es el análisis, diseño,
construcción, verificación y gestión de
entidades técnicas (o sociales).
• Con independencia de la entidad a la
que se va a aplicar ingeniería, se
deben cuestionar y responder las
siguientes preguntas:
Preguntas
• ¿Cuál es el problema a resolver?
• ¿Cuáles son las características de la entidad
que se utiliza para resolver el problema?
• ¿Cómo se realizará la entidad (y la
solución)?
• ¿Cómo se construirá la entidad?
• ¿Qué enfoque se va a utilizar para no
contemplar los errores que se cometieron en
el diseño y en la construcción de la entidad?
• ¿Cómo se apoyará la entidad cuando
usuarios soliciten correcciones, adaptaciones
y mejoras de la entidad?
Fases – Fase de definición
• El trabajo que se asocia a la ingeniería del software
se puede dividir en tres fases genéricas, con
independencia del área de aplicación, tamaño o
complejidad del proyecto.
• Cada fase se encuentra con una o varias cuestiones
de las destacadas anteriormente.
• La fase de definición se centra sobre el qué. Es
decir, durante la definición, el que desarrolla el
software intenta identificar qué información ha de
ser procesada, qué función y rendimiento se desea,
qué comportamiento del sistema, qué interfaces
van a ser establecidas, qué restricciones de diseño
existen, y qué criterios de validación se necesitan
para definir un sistema correcto.
Continuación…
• Por tanto, han de identificarse los requisitos
clave del sistema y del software.
• Aunque los métodos aplicados durante la
fase de definición variarán dependiendo del
paradigma de ingeniería del software (o
combinación de paradigmas) que se aplique,
de alguna manera tendrán lugar tres tareas
principales:
– ingeniería de sistemas o de información,
– planificación del proyecto del software y
– análisis de los requisitos.
Fases – fase de desarrollo
• La fase de desarrollo se centra en el cómo. Es decir,
durante el desarrollo un ingeniero del software
intenta definir cómo han de diseñarse las
estructuras de datos, cómo ha de implementarse la
función dentro de una arquitectura de software,
cómo han de implementarse los detalles
procedimentales, cómo han de caracterizarse
interfaces, cómo ha de traducirse el diseño en un
lenguaje de programación (o lenguaje no
procedimental) y cómo ha de realizarse la prueba.
• Los métodos aplicados durante la fase de desarrollo
variarán, aunque las tres tareas específicas técnicas
deberían ocurrir siempre:
– diseño del software,
– generación de código y
– prueba del software.
Fases – Mantenimiento (1)
• La fase de mantenimiento se centra en el cambio
que va asociado a la corrección de errores, a las
adaptaciones requeridas a medida que evoluciona
el entorno del software y a cambios debidos a las
mejoras producidas por los requisitos cambiantes
del cliente.
• Durante la fase de mantenimiento se encuentran
cuatro tipos de cambios:
1. Corrección. Incluso llevando a cabo las mejores
actividades de garantía de calidad, es muy
probable que el cliente descubra los defectos en el
software. El mantenimiento correctivo cambia el
software para corregir los defectos.
2. Adaptación. Con el paso del tiempo, es probable
que cambie el entorno original (por ejemplo: CPU,
el sistema operativo, las reglas de empresa, las
características externas de productos) para el que
se desarrolló el software. El mantenimiento
adaptativo produce modificación en el software
para acomodarlo a los cambios de su entorno
externo.
3. Mejora. Conforme se utilice el software, el
cliente/ usuario puede descubrir funciones
adicionales que van a producir beneficios. El
mantenimiento perfectivo lleva al software más
allá de sus requisitos funcionales originales.
4. Prevención. El software de computadora
se deteriora debido al cambio, y por esto el
mantenimiento preventivo también llamado
reingeniería del software, se debe conducir
a permitir que el software sirva para las
necesidades de los usuarios finales.
En esencia, el mantenimiento preventivo
hace cambios en programas de
computadora a fin de que se puedan
corregir, adaptar y mejorar más fácilmente.
Actividades protectoras
• Las actividades de protección se aplican a lo
largo de todo el proceso del software:
– Seguimiento y control del proyecto de
software.
– Revisiones técnicas formales.
– Garantía de calidad del software.
– Gestión de configuración del software.
– Preparación y producción de documentos.
– Gestión de reutilización.
– Mediciones.
– Gestión de riesgos
• Las actividades de protección son independientes
de cualquier actividad del marco de trabajo y
aparecen durante todo el proceso.
• En los últimos años, se ha hecho mucho énfasis en
la “madurez del proceso”. El Software Engineering
Institute (SEI) ha desarrollado un modelo completo
que se basa en un conjunto de funciones de
ingeniería del software que deberían estar
presentes conforme organizaciones alcanzan
diferentes niveles de madurez del proceso.
• Para determinar el estado actual de madurez del
proceso de una organización, el SEI utiliza un
cuestionario de evaluación y un esquema de cinco
grados.
• El esquema de grados determina la
conformidad con un modelo de capacidad de
madurez (Capacity Maturity Model - CMM)
que define las actividades clave que se
requieren en los diferentes niveles de
madurez del proceso.
• El enfoque del SEI proporciona una medida
de la efectividad global de las prácticas de
ingeniería del software de una compañía y
establece cinco niveles de madurez del
proceso, que se definen de la forma
siguiente:
• Nivel 1: Inicial. El proceso del software se
caracteriza según el caso, y ocasionalmente
incluso de forma caótica. Se definen pocos
procesos, y el éxito depende del esfuerzo
individual.
• Representa una situación sin ningún
esfuerzo en la garantía de calidad y gestión
del proyecto, donde cada equipo del
proyecto puede desarrollar software de
cualquier forma eligiendo los métodos,
estándares y procedimientos a utilizar que
podrán variar desde lo mejor hasta lo peor.
• Nivel 2: Repetible. Se establecen los
procesos de gestión del proyecto para hacer
seguimiento del coste, de la planificación y
de la funcionalidad.
• Para repetir éxitos anteriores en proyectos
con aplicaciones similares se aplica la
disciplina necesaria para el proceso.
• Representa el hecho de que un desarrollador
de software ha definido ciertas actividades
tales como el informe del esfuerzo y del
tiempo empleado, y el informe de las tareas
realizadas.
• Nivel 3: Definido. El proceso del software de las
actividades de gestión y de ingeniería se documenta, se
estandariza y se integra dentro de un proceso de
software de toda una organización.
• Todos los proyectos utilizan una versión documentada y
aprobada del proceso de la organización para el
desarrollo y mantenimiento del software.
• En este nivel se incluyen todas las características
definidas para el nivel 2.
• Representa el hecho de que un desarrollador de software
ha definido tanto procesos técnicos como de gestión, por
ejemplo un estándar para la programación ha sido
detallado y se hace cumplir por medio de procedimientos
tales como auditorías.
• Este nivel es aquel en el que la mayoría de los
desarrolladores de software, pretenden conseguir con
estándares como el ISO 9001, y existen pocos casos de
desarrolladores de software que superan este nivel.
• Nivel 4: Gestionado. Se recopilan medidas
detalladas del proceso del software y de la
calidad del producto.
• Mediante la utilización de medidas
detalladas, se comprenden y se controlan
cuantitativamente tanto los productos como
el proceso del software.
• En este nivel se incluyen todas las
características definidas para el nivel 3.
• Comprende el concepto de medición y el uso
de métricas.
Métricas
• Una métrica es una cantidad insignificante
que puede extraerse de algún documento o
código dentro de un proyecto de software.
• Un ejemplo de métrica es el número de
ramas condicionales en una sección de
código de un programa.
• Esta métrica es significativa en el sentido de
que proporciona alguna indicación del
esfuerzo necesario para probar el código:
está directamente relacionado con el
número de caminos de prueba dentro del
código.
• Una organización del nivel 4 maneja numerosas
métricas.
• Estas métricas se utilizan entonces para supervisar
y controlar un proyecto de software, por ejemplo:
– Una métrica de prueba puede usarse para
determinar cuándo finalizar la prueba de un
elemento del código.
– Una métrica de legilibilidad puede usarse para
juzgar la legilibilidad de algún documento en
lenguaje natural.
– Una métrica de comprensión del programa puede
utilizarse para proporcionar algún umbral
numérico que los programadores no pueden
cruzar.
• Para que estas métricas alcancen este
nivel es necesario que todos los
componentes del nivel 3 CMM, en
castellano MCM (Modelo de Capacidad
de Madurez), estén conseguidos, por
ejemplo notaciones bien definidas para
actividades como la especificación del
diseño de requisitos, por lo que estas
métricas pueden ser fácilmente
extraídas de modo automático.
• Nivel 5: Optimización. Mediante una
retroalimentación cuantitativa del proceso,
ideas y tecnologías innovadoras se posibilita
una mejora del proceso.
• En este nivel se incluyen todas las
características definidas para el nivel 4.
• Es el nivel más alto a alcanzar.
• Hasta ahora, muy pocos desarrolladores de
software han alcanzado esta fase.
• Representa la analogía del software con los
mecanismos de control de calidad que
existen en otras industrias de mayor
madurez.
• El desarrollador del software en el nivel 5
puede predecir resultados como el número
de errores latentes en un producto basado
en la medición tomada durante la ejecución
de un proyecto.
• Además, dicho desarrollador puede
cuantificar el efecto que un proceso nuevo o
herramienta de manufacturación ha tenido
en un proyecto examinando métricas para
ese proyecto y comparándolas con
proyectos anteriores que no utilizaron ese
proceso o herramienta.
• El SEI ha asociado áreas claves del
proceso (ACPs) a cada uno de los
niveles de madurez.
• Las ACPs describen esas funciones de
la ingeniería del software (por
ejemplo: planificación del proyecto de
software, gestión de requisitos) que se
deben presentar para satisfacer una
buena práctica a un nivel en particular.
• Cada ACP se describe identificando las
características siguientes:
• Objetivos- los objetivos globales que
debe alcanzar la ACP
• Compromisos- requisitos (impuestos
en la organización) que se deben
cumplir para lograr los objetivos y que
proporcionan una prueba del intento
por ajustarse a los objetivos.
• Capacidades- aquellos elementos que
deben encontrarse (organizacional y
técnicamente) para permitir que la
organización cumpla los objetivos.
• Actividades- las tareas específicas que
se requieren para lograr la función
ACP.
• Métodos para supervisar la
implementación-la manera en que las
actividades son supervisadas conforme
se aplican.
• Métodos para verificar la
implementación- la forma en que se
puede verificar la práctica adecuada
para la ACP.
• Se definen dieciocho ACPs (descritas
mediante la estructura destacada
anteriormente) en el modelo de
madurez y se distribuyen en niveles
diferentes de madurez del proceso.
• Las ACPs se deberían lograr en cada
nivel de madurez de proceso:
Nivel 2 de Madurez del Proceso
1. Gestión de configuración del software
2. Garantía de calidad del software
3. Gestión de subcontratación del
software
4. Seguimiento y supervisión del
proyecto del software
5. Planificación del proyecto del
software
6. Gestión de requisitos
7. Revisiones periódicas
8. Coordinación entre grupos
9. Ingeniería de productos de software
10.Gestión de integración del software
11.Programa de formación
12.Definición del proceso de la
organización
13.Enfoque del proceso de la
organización
14.Gestión de calidad del software
15.Gestión cuantitativa del proceso

16.Gestión de cambios del proceso
17.Gestión de cambios de tecnología
18.Prevención de defectos
• Cada una de las ACPs se definen con un conjunto
de prácticas clave que contribuyen a cumplir estos
objetivos.
• Las prácticas clave son normas, procedimientos y
actividades que deben ocurrir antes de que se haya
instituido completamente un área clave de proceso.
• El SEI define a los indicadores clave como “aquellas
prácticas clave o componentes de prácticas clave
que ofrecen una visión mejor para lograr los
objetivos de un área clave de proceso”.
• Las cuestiones de valoración se diseñan para
averiguar la existencia (o falta) de un indicador
clave.
Modelos del proceso de software
• Para resolver los problemas reales de una industria, un
ingeniero del software o un equipo de ingenieros debe
incorporar una estrategia de desarrollo que acompañe al
proceso, métodos y capas de herramientas descritos y las
fases genéricas discutidas.
• Esta estrategia a menudo se llama modelo de proceso o
paradigma de ingeniería del software.
• Se selecciona un modelo de proceso para la ingeniería del
software según la naturaleza del proyecto y de la aplicación,
los métodos y las herramientas a utilizarse, y los controles y
entregas que se requieren.
• En un documento intrigante sobre la naturaleza del proceso
del software, L.B.S. Raccoon [RAC95] utiliza fractales como
base de estudio de la verdadera naturaleza del proceso del
software.
• Todo el desarrollo del software se puede
caracterizar como bucle de resolución de problemas
en el que se encuentran cuatro etapas distintas:
1. “status quo”: “representa el estado actual de
sucesos”
2. definición de problemas: identifica el problema
específico a resolverse,
3. desarrollo técnico: resuelve el problema a través
de la aplicación de alguna tecnología.
4. integración de soluciones: ofrece los resultados
(por ejemplo: documentos, programas, datos,
nueva función comercial, nuevo producto) a los que
solicitan la solución en primer lugar.
• Las fases y los pasos genéricos de ingeniería del
software definidos se dividen fácilmente en estas
etapas.
Resumen
• La ingeniería del software es una disciplina
que integra procesos, métodos y
herramientas para el desarrollo del software
de computadora.
• Se han propuesto varios modelos de
procesos para la ingeniería del software
diferentes, cada uno exhibiendo ventajas e
inconvenientes pero todos tienen una serie
de fases genéricas en común.
• En el resto de este curso se consideran los
principios, conceptos y métodos que
permiten llevar a cabo el proceso que se
llama ingeniería del software.
Fuentes de información
• Sommerville, I. “Ingeniería de Software”
7ma edición.
• Pressman, R. “Ingeniería de Software: Un
enfoque práctico” 5ta edición:
– cap 1 12p
– cap 2 22p
• Kendall, K.E. y Kendall, J.E. “Análisis y
diseño de sistemas” 6ta edición.

ACI491 U5 Introduccion A La Ingenieria de Software

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ACI491 U5 Introduccion A La Ingenieria de Software

Transféré par

Droits d'auteur :

Formats disponibles

ACI491:

Definición Desarrollo Después

Una vuelta mas…

Nivel 5 de Madurez del Proceso

Vous aimerez peut-être aussi