Sunteți pe pagina 1din 55

INGENIERIA DE

SOFTWARE
1er semestre 2020

ING. NEHEMIAS ISRAEL VALLE PINEDA


INTRODUCION A LA INGENIERIA DE SOFTWARE
IS
Origen
IS Historia

• 1950 Aparecimiento del término


• 1960 – 1980 Crisis del Software
• 14 de noviembre 1984 fundación del Instituto de Ingeniería de
Software
• Finales de 1987 Nace el modelo CMMI
Crisis del Software 1960 – 1980

• La Crisis del software se refiere a los problemas que, desde sus


inicios, ha ido experimentando el software, muchas veces problemas
de gran magnitud, debido, principalmente, a la mínima eficacia que
presentan una gran cantidad de empresas al momento de realizar un
software. Sin embargo, no fue hasta 1968 cuando en la primera
conferencia elaborada por la OTAN (
Organización del Tratado del Atlántico Norte), Friedrich L. Bauer habló
por primera vez del conjunto de dificultades o errores ocurridos en la
planificación, estimación de los costos, productividad y calidad de un
software, o bien, lo que se conoce como la crisis del software, dicho
término se le atribuyó a F. L. Bauer aunque ya había sido utilizado por
Edsger Dijkstra en su libro The Humble Programmer. Para dar solución
a los problemas que se presentaban en esta conferencia se creó una
nueva rama de ingeniería, la ingeniería de software.1​
Referencias[editar]
1.↑ Dijkstra, Edger. The Humble Programmer.
Crisis del Software 1960 – 1980

• Costo y desbordamiento de presupuesto: el sistema operativo OS/360 fue


un ejemplo clásico. Este proyecto que duró una década [cita requerida] desde los
años 1960 finalmente produjo uno de los más complejos sistemas de
software de ese tiempo. El OS/360 fue uno de los primeros de grandes
proyectos de software (1000 programadores).[cita requerida] En el libro The
Mythical Man-Month, Fred Brooks afirma que cometió un error
multimillonario por no desarrollar una coherente arquitectura de software
antes de iniciar el desarrollo.
• Daños a la propiedad: Defectos de software pueden causar daños a la
propiedad. Escasa seguridad de software permite a hackers robar
identidades, costando tiempo, dinero y reputaciones.
• Vida y muerte: Defectos de software pueden matar. Algunos
sistemas embebidos en máquinas de radioterapia fallaron de una manera
tan catastrófica que administraron dosis letales de radiación a pacientes.
La más famosa de estas fallas es el incidente de Therac 25.
https://es.wikipedia.org/wiki/Historia_de_la_ingeniería_del_software
IS Concepto
La Ingeniería de Software Es una de las ramas de las ciencias de la
computación que estudia la creación de software confiable y de calidad,
basándose en métodos y técnicas de ingeniería. Brindando soporte
operacional y de mantenimiento, el estudio de las aplicaciones de la
ingeniería de software.1​Integra ciencias de la computación,
ciencias aplicadas y las ciencias básicas en las cuales se encuentra
apoyada la ingeniería.2​
Referencias[editar]
1.↑ SWEBOK executive editors, Alain Abran, James W. Moore; editors, Pierre Bourque, Robert Dupuis. (2004). Pierre Bourque and Robert Dupuis, ed.
Guide to the Software Engineering Body of Knowledge - 2004 Version. IEEE Computer Society. pp. 1-1. ISBN 0-7695-2330-7.
2.↑ ACM (2006). «Computing Degrees & Careers». ACM. Archivado desde el original el 17 de junio de 2011. Consultado el 23 de noviembre de 2010.

https://es.wikipedia.org/wiki/Ingeniería_de_software
IS Conceptos Alternos

• Ongeniería de software es el estudio de los principios y metodologías


para el desarrollo y mantenimiento de sistemas software (Zelkovitz,
1978).
• Ingeniería de software es la aplicación práctica del conocimiento
científico al diseño y construcción de programas de computadora y a
la documentación asociada requerida para desarrollar, operar y
mantenerlos. Se conoce también como desarrollo de software o
producción de software (Bohem, 1976).
• La ingeniería de software trata del establecimiento de los principios y
métodos de la ingeniería a fin de obtener software de modo
rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).

https://es.wikipedia.org/wiki/Ingeniería_de_software
ENFOQUE SISTEMICO
IS
Administración de proyectos

• La administración de proyectos es una


metodología usada a nivel mundial, por
empresas e instituciones para alcanzar objetivos
en un tiempo determinado. También significa
llevar una gestión equilibrando, separando las
urgencias de las tareas que realmente son
importantes para el cliente. El volumen de
trabajo, las variables y los requisitos cada vez
más complejos, han dado lugar a que cada vez
más empresas e instituciones administren su
trabajo por proyectos. De acuerdo al PMI (
Project Management Institute) 1​en todos los
proyectos existen 5 fases, 10 áreas de
conocimiento y 47 procesos.

https://www.lancetalent.com/blog/4-herramientas-gestion-de-proyectos-online/

https://es.wikipedia.org/wiki/Administración_de_proyectos
Fases de un proyecto

https://www.marcoteorico.com/curso/49/administracion-de-proyectos/374/fases-de-la-administracion-de-proyectos
Administración de proyectos
Componentes de un proyecto informático

PROGRAMAS

BASE DE DATOS

RED

EQUIPO
Administración de
proyectos
puntos de • Propósito del proyecto

consideración de •
Usuarios Finales
Fechas de entrega
planificación • Status Actual
• Antecedentes
• Ambiente
• Hardware
• Software
• Standares a seguir
• Componentes reutilizables
• Herramientas para desarrollo
Requerimientos
Requerimientos funcionales
• Un requisito funcional define una
función del sistema de software o sus
componentes. Una función es descrita
como un conjunto de entradas,
comportamientos y salidas. Los
requisitos funcionales pueden ser:
cálculos, detalles técnicos,
manipulación de datos y otras
funcionalidades específicas que se
supone, un sistema debe cumplir. Los
requisitos de comportamiento para
cada requisito funcional se muestran en
los casos de uso. Son complementados
por los requisitos no funcionales, que se
enfocan en cambio en el diseño o la
implementación.
• Como se define en la
ingeniería de requisitos, los requisitos
funcionales establecen los
comportamientos del software.

https://es.wikipedia.org/wiki/Requisito_funciona l
Requerimientos no funcionales

• Un requisito no funcional o
atributo de calidad es, en la
ingeniería de sistemas y la
ingeniería de software, un
requisito que sabe bien y
especifica criterios que
pueden usarse para juzgar
la operación de un sistema
en lugar de sus
comportamientos
específicos, ya que éstos
corresponden a los
requisitos funcionales.
Wikipedia
Antecedentes

• Nos ayuda a estabilizar el proyecto por medio de bases con


argumentos solidos. Los antecedentes son una referencia para
analizar o hablar sobre un tema en cuestión que influye en hechos
posteriores y sirve para juzgarlos, entenderlos, etc. Es una base que
nos sirve como ejemplo para un nuevo proyecto.28 jul. 2014
• https://prezi.com/f3r5jmbhqmue/los-antecedentes-de-un-proyecto-de-investigacion/
• DERCAS Documento de Especificaciones, Requerimientos y Criterios de Aceptación
de Software
• Análisis
• Antecedentes
• Matriz de requerimientos

Entregables • Reglas de negocio


• Diseño
• Componentes
• Estructuras
• Interfases
• Base de Datos
• Tiempo, costo y recurso
• Cronograma
• Términos
• Firmas de aceptación
• Manual técnico
• Componentes
• Administración de configuración
• Manual de Usuario
DERCAS

• Antecedentes
• Cobertura y limitaciones del proyecto
• Requerimientos
• Análisis de factibilidad
• Diseño
• Cronograma de Actividades
• Tiempo
• Costo
• Recurso humano
Manual técnico

• Descripción general del sistema


• Módulos
• Módulos principales
• Módulos operativos y no operativos
• Especificaciones de entrada
• Especificaciones de salida
• Especificaciones de datos
• Especificaciones de seguridad
Manual de Usuario

• Introducción a la operación del sistema


• Operación de los módulos principales
• Operación de los sub módulos
• Ingreso de información
• Salida de información
Cierre de proyectos

• Fase de control de calidad exitosa


• Fase de Auditoría de sistemas exitosa
• Fase prueba piloto exitosa
• Implementación en producción exitosa
• Operación real exitosa
• Firma de aceptación de cierre del
proyecto

https://es.123rf.com/photo_80924330_el-hombre-de-negocios-está-firmando-un-documento-legal-en-la-oficina.html
Equipo de trabajo, habilidades y conocimientos

• Desarrollo de proyectos
• Presentación a Usuarios
Finales
• Diseño de sistemas
• Administración de base de
datos
• Administración de redes
• Control de Estándares
• Administración de objetos
• Desarrollo de aplicaciones
• Documentación
• Diseño gráfico
• Control de Calidad
https://www.lancetalent.com/blog/4-herramientas-gestion-de-proyectos-online/
Reglas del equipo de trabajo

• Nadie tiene la razón


absoluta
• Escuchar primero
• Pedir la palabra
• Analizar antes de opinar
• Aprobar o desaprobar
Cronograma de actividades

• Elaboración
• Tareas
• Tiempo, costo y recurso
• Estimar 30% de imprevistos
• Definir línea base
• Aprobación
• Seguimiento, monitoreo y
control
• Registrar avance
• Comparar con línea base
• Calcular desviación real vs.
estimado.
• Cierre
Cronograma Fases principales
Cronograma (definir línea base)
Cronograma detalles
Analisis de riesgos
• https://www.youtube.com/watch?v=uU345FZoQvI
• https://www.youtube.com/watch?v=yTGpsWY6s4M
MODELOS DE DESARROLLO

• PROTOTIPOS
• CICLO DE VIDA
• INCREMENTAL
• EN ESPIRAL
• CONCURRENTES
• EN COMPONENTES
• DRA (DESARROLLO RAPIDO DE APLICACIONES)
• METODOLOGIAS AGILES
Modelo por PROTOTIPOS tradicional

ARMAR
PROTOTIPO

ENTREVISTA
NO HAY
ANALISIS
DISEÑO
NI DOCMENTACION

OPERAR NO ESTRUCTURADO
PROTOTIPO CRECE SIN ORDEN
Modelo CICLO DE VIDA Clásico
ANALISIS
PRELIMINAR

ANALISIS

DISEÑO

CONSTRUCCION

ASEGURAMIENTO
DE CALIDAD

IMPLEMENTACION

MANTENIMIENTO
CICLO DE VIDA clásico para software

A N A L IS IS D E D IS E Ñ O B A S E D E C O N S T R U C C IO N
DATO S D ATO S BD
PRUEBAS
A N A L IS IS
A S E G U R A M IE N
P R E L IM IN A R
T O D E C A L ID A D
A N A L IS IS D E D IS E Ñ O D E C O N S T R U C C IO N
PRO CESO S PRO CESO S PRO CESO S

IM P L E M E N T A C I
M A N T E N IM IE N T O
O N
INCREMENTAL
ANALISIS
FASE IV
PRELIMINAR

ANALISIS

DISEÑO

FASE III
CONSTRUCCION

ASEGURAMIENTO
DE CALIDAD

IMPLEMENTACION

ANALISIS
MANTENIMIENTO
PRELIMINAR

FASE II
ANALISIS

DISEÑO

CONSTRUCCION

ASEGURAMIENTO
DE CALIDAD
ANALISIS
PRELIMINAR IMPLEMENTACION

MANTENIMIENTO

FASE I ANALISIS

DISEÑO

CONSTRUCCION

ASEGURAMIENTO
ANALISIS DE CALIDAD
PRELIMINAR
IMPLEMENTACION

MANTENIMIENTO

ANALISIS

DISEÑO

CONSTRUCCION

ASEGURAMIENTO
DE CALIDAD

IMPLEMENTACION

MANTENIMIENTO
INCREMENTAL

IV PARA CUANDO A D
LA DOTACION
DE PERSONA
ES
III INSUFICIENTE A D C P I

II
A D C P I

I A D C P I

T
DRA PARA PROYECTOS
DE CORTO PLAZO

. MUCHO RECURSO HUMANO


. TECNICAS DE CUARTA GENERACION
. REUTILIZACION
. VARIOS EQUIPOS DE TRABAJO
MODELADO
GESTION

MODELADO
MODELADO DATOS
GESTION

MODELADO MODELADO MODELADO


DATOS PROCESOS
GESTION

MODELADO MODELADO GENERAR


PROCESOS APLICACION
DATOS

GENERAR PRUEBAS
MODELADO APLICACION ENTREGA
PROCESOS

PRUEBAS
GENERAR ENTREGA
APLICACION

PRUEBAS
ENTREGA

60 A 90 DIAS
EN ESPIRAL

PLANIFICACION

ANALISIS DE
COMUNICACION RIESGOS

INGENIERIA

EVALUACION
CASE
CONSTRUCCION
• Las solicitudes se van
atendiendo como van
llegando
• Casi no se documenta
mucho y el análisis es
breve y puntual
• Según la necesidad se
cambia de prioridad
• Es un método emergente
que se salta los
procedimientos normales
• Las soclicitudes
normalmente son
emergentes
• Un ejemplo de esto es el
manejo de incidentes que
Método de desarrollo necesitan solución rápida.

concurrente
Metodologías
Agiles

El Manifiesto
Agil
Pilares Herramientas
• Ciclo de vida incremental • Sprint
• Reuniones a lo largo del • Producto Back Log
proyecto • Sprint Back log
• Tablero de gestion
Scrum vision general
Historias de usuario

El objetivo es convertir las


necesidades de negocio del
cliente o usuario en historias
de usuario lo suficientemente
sencillas como para que se
puedan transformar
posteriormente en tareas de
desarrollo para el equipo.
Información de la historia de usuario
Product
Owner
Pila de producto
Sprint Log
Roles
Equipo de
trabajo
Tablero de
gestión
Reuniones a lo
largo del proyecto

• Reunión de Planificación
del Sprint (Sprint
Planning Meeting)
• Reunión diaria (Daily
Scrum)
• Reunión de Revisión del
Sprint (Sprint Review
Meeting)
• Retrospectiva del Sprint
(Sprint Retrospective)
XP eXtreme
Programming
Planning Game

Entregas pequeñas

XP
Buenas Metáfora (idea conceptual)

prácticas
Clientes On-Site

Programación Estándar
Ciclo de vida XP

• Ciclo de vida iterativo


incremental
• Una primera versión
rápida
• Versiones sucesivas
• Aceptación de cambios
constantes
• Tiempo de retiro
Lean

• Eliminar desperdicios (Eliminating Waste).


• Amplificar el aprendizaje (Amplifying Learning).
• Decidir lo más tarde posible (Deciding as Late as Possible
• Entregar lo más rápido posible (Delivering as Fast as
Possible).
• Capacitar y potenciar al equipo (Empowering the Team).
• Construir con calidad (Building Quality In). 
• Ver el todo (Seeing the Whole).
Kanban (tarjetas
visuales)

• kan significa visual, y ban tarjeta.


• 1- Visualizar el trabajo y las fases
del ciclo de producción, o flujo de
trabajo
• 2 – Determinar el límite de “trabajo
en curso”.
• 3 – Medir el tiempo en completar
una tarea.
Videos de apoyo

• Scrum
• https://www.youtube.com/watch?v=a33xOe9d_Dk
• https://www.youtube.com/watch?v=PlLHc60egiQ
• Lean
• https://www.youtube.com/watch?v=0SFIJuYUow4
• https://www.youtube.com/watch?v=_BCx5tHVEds
• KanBan
• https://www.youtube.com/watch?v=I-H-WXAX_oM
• Xp
• https://www.youtube.com/watch?v=3CYGOtk6uKc
• https://www.youtube.com/watch?v=J5gIg4ynBks

S-ar putea să vă placă și