Historia Procesos de Sw

Breve historia del surgimiento de las
tecnologías, metodologías y
procesos de sw
Rubby Casallas
Maestría en Ingeniería de Sofware
MISO
Tecnologías
70s
80s
90s
00s
10s
Metodologías
Procesos de Sw
Exigencias /
Requerimientos
TECNOLOGÍA
1970
In 1979, Relational
Software, Inc. (now
Oracle) introduced the
first commercially
available
implementation of SQL
1976
Peter Chen
Merging the networks and creating the
Internet
1982 – TCP/IP protocol suite formalized
1982 – Simple Mail Transfer Protocol (SMTP)
1983 – Domain Name System(DNS)
1985 – First .COM domain name registered
1988 – OSI Reference Modelreleased
1991 – World Wide Web(WWW)
1993 – Mosaic web browserreleased
Commercialization, privatization, broader
access leads to the modern Internet:
1995 – New Internet architecture with
commercialISPs
1995 – IPv6 proposed
1999 – IEEE 802.11b wireless networking
2000 – Dot-com bubble bursts
2001 – New top-level domain names activated
2006 – First meeting of the Internet
Governance Forum
2010 – First internationalized country code
top-level domainsregistered
Examples of popular Internet services:
1990 – IMDb Internet movie database
1995 – Amazon.com online retailer
1995 – eBay online auction and shopping
1996 – Hotmail free web-based e-mail
1997 – Babel Fish automatic translation
1998 – Google Search
METODOLOGÍAS
“Crisis de software” acuñado en 1968, en la primera conferencia organizada por
la OTAN sobre desarrollo de software, de la cual nació formalmente la rama de
la ingeniería de software
• Los proyectos no terminaban en plazo.
• Los proyectos no se ajustaban al presupuesto inicial.
• Baja calidad del software generado.
• Software que no cumplía las especificaciones.
• Código inmantenible que dificultaba la gestión y
evolución del proyecto.
Go To Statement Considered Harmful
Edsger W. Dijkstra
Communications of the ACM, Vol. 11, No. 3,
March 1968, pp. 147-148. Copyright © 1968,
Association for Computing Machinery, Inc.
"No Silver Bullet — Essence and Accidents of
Software Engineering") es un documento
ampliamente discutido sobre ingeniería del
software escrito porFred Brooks en 1986.
1975
SIMULA 1970
Smalltalk 70s
C++ 1980
…
Java 1995
CORBA 2.0 in 1997
Bjarne Stroustrup
SIMULA 1970
Smalltalk 70s
C++ 1980
…
Java 1995
CORBA 2.0 in 1997
The object-modeling technique (OMT) is
an object modeling approach
for software modeling and designing. It was
developed around 1991 by Rumbaugh,
El método desarrollado por Ivar Jacobson
OOSE ha sido llamado “un enfoque para el
manejo de casos de uso”, en este enfoque el
modelo de casos de uso sirve como un modelo
central del cual todos los otros modelos son
derivados. Un modelo de casos de uso
describe la funcionalidad completa del
sistema, identificando como, todo lo que esta
fuera del sistema, interactúa con él.
PROCESOS DE SOFTWARE
• Waterfall
• Espiral
• CMMI
• PSP/TSP
• RUP
• Ágiles
• Lean
Royce, Winston (1970), "Managing the
Development of Large Software
Systems", Proceedings of IEEE
WESCON 26 (August): 1–9
“… the implementation described above is
risky and invites failure.”
1986
http://www.softwaremetrics.com/Articles/history.htm
http://www.softwaremetrics.com/Articles/history.htm
1981
2001
Barry Boehm in his 1986
1979
1989
The Capability Maturity Model was originally developed
as a tool for objectively assessing the ability of government
contractors' processes to perform a contracted software
project.
The model is based on the process maturity framework first
described in the 1989 book Managing the Software
Process by Watts Humphrey. It was later published in a report
in 1993 and as a book by the same authors in 1995.
ALENDARIO DE ADJUDICACIÓN
Última actualización: 28/01/2014
ACTIVIDAD
FECHA
Apertura convocatoria
Cierre de convocatoria
27 de Enero de 2014
10 de Marzo de 2014
Evaluación
11 de marzo al 14 de marzo de 2014
Reunión Junta Administradora para
adjudicar créditos
17 de marzo de 2014
Publicación resultados
18 de Marzo de 2014
Legalización de créditos
18 de Marzo al 11 de Abril de 2014
Proceso de capacitación y certificación
Del 11 de Abril al 15 de Julio
Disciplinas y Actividades
• Cada disciplina puede tener asociada varias
actividades (Steps)
• Cada actividad se describe como un flujo de
trabajo (Workflow)
• Cada flujo de trabajo describe:
– el qué: los entregables o artefactos
– el cómo: las tareas
– el quién: los roles
Ejemplo de un flujo de trabajo
56
Se expresa en un diagrama
de actividades UML
Tomado de: http://www-128.ibm.com/developerworks/rational/library/5383.html
Ejemplo de un flujo de trabajo
57
Se expresa en un diagrama
de actividades UML
Tomado de: http://www-128.ibm.com/developerworks/rational/library/5383.html
Ejemplo de un flujo de trabajo detallado
58
Tomado de: http://www-128.ibm.com/developerworks/rational/library/5383.html
Ejemplo de un flujo de trabajo detallado
Artefactos
Roles
Tareas
59
Roles
• Analyst
– Business-Process
Analyst
– Business Designer
– Business-Model
Reviewer
– Requirements Reviewer
– System Analyst
– Use-Case Specifier
– User-Interface Designer
• Developer
– Architect
– Architecture Reviewer
– Capsule Designer
– Code Reviewer
– Database Designer
– Design Reviewer
– Designer
– Implementer
– Integrator
60
2006
Roles on the Contractor s Software
Development Team
On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch
mountains of Utah, seventeen people met to talk, ski, relax, and try to find
common ground and of course, to eat. What emerged was the Agile Software
Development Manifesto.
Representatives from Extreme Programming, SCRUM, DSDM, Adaptive
Software Development, Crystal, Feature-Driven Development, Pragmatic
Programming, and others sympathetic to the need for an alternative to
documentation driven, heavyweight software development processes convened.
Now, a bigger gathering of organizational anarchists would be hard to find, so
what emerged from this meeting was symbolic a Manifesto for Agile Software
Development signed by all participants.
Principios del Manifiesto Ágil
• Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software con
valor
• Aceptamos que los requisitos cambien, incluso en
etapas tardías del desarrollo. Los procesos Ágiles
aprovechan el cambio para proporcionar ventaja
competitiva al cliente
• Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo
de tiempo más corto posible
67
Principios del Manifiesto Ágil (2)
• Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo el
proyecto
• Los proyectos se desarrollan en torno a
individuos motivados. Hay que darles el entorno y el
apoyo que necesitan, y confiarles la ejecución del trabajo
• El método más eficiente y efectivo de
comunicar información al equipo de desarrollo y entre
sus miembros es la conversación cara a cara
• El software funcionando es la medida principal
de progreso
68
Principios del Manifiesto Ágil (3)
• Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante de
forma indefinida
• La atención continua a la excelencia técnica y al
buen diseño mejora la agilidad
• La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial
• Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados
69
Principios del Manifiesto Ágil (4)
• A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia
70
eXtreme Programming XP: 12
Prácticas
72
1.
2.
3.
4.
5.
6.
7.
Eliminate waste
Amplify learning
Decide as late as possible
Deliver as fast as possible
Empower the team
Build integrity in
See the whole