-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathIngSoft2.tex
1840 lines (1414 loc) · 99.2 KB
/
IngSoft2.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
%
% untitled
%
% Created by Julian Sackmann on 2012-07-24.
% Copyright (c) 2012 __MyCompanyName__. All rights reserved.
%
\documentclass[]{article}
% Use utf-8 encoding for foreign characters
\usepackage[utf8]{inputenx}
% Setup for fullpage use
\usepackage{fullpage}
% Uncomment some of the following if you use the features
%
% Running Headers and footers
\usepackage{fancyhdr}
\usepackage{lastpage}
% Multipart figures
%\usepackage{subfigure}
% More symbols
\usepackage{amsmath}
\usepackage{amssymb}
%\usepackage{latexsym}
% Surround parts of graphics with box
\usepackage{boxedminipage}
% Package for including code in the document
\usepackage{listings}
% If you want to generate a toc for each chapter (use with book)
\usepackage[nohints]{minitoc}
% This is now the recommended way for checking for PDFLaTeX:
\usepackage{ifpdf}
\usepackage{indentfirst}
\usepackage{footnote}
\usepackage{multicol}
\usepackage{mathtools}
\usepackage{algorithm2e}
\ifpdf
\usepackage[pdftex]{graphicx}
\else
\usepackage{graphicx}
\fi
\title{Teóricas de Ingeniería del Software II}
\author{ Julián Sackmann }
\date{10 de Septiembre de 2012}
\pagestyle{fancy}
\thispagestyle{fancy}
\addtolength{\headheight}{12pt}
\addtolength{\headsep}{0.3cm}
\lhead{Ingeniería del Software II}
\rhead{Julián Sackmann}
\cfoot{P\'agina \thepage\ de \pageref{LastPage}}
\renewcommand{\footrulewidth}{0.4pt}
\setcounter{page}{0}
\begin{document}
\ifpdf
\DeclareGraphicsExtensions{.pdf, .jpg, .tif}
\else
\DeclareGraphicsExtensions{.eps, .jpg}
\fi
%\setcounter{secnumdepth}{5}
\setcounter{tocdepth}{4}
\newcommand{\ig}[2]{
\begin{center}
\includegraphics[scale=#1]{images/#2}
\end{center}}
\newcommand{\subsubsubsection}[1]{\paragraph{#1}~\newline
\indent }
\newcommand{\subsubsubsubsection}[1]{\subparagraph{#1}}
\newcommand{\partir}[4]{
\begin{minipage}[b]{#1\linewidth}\centering\begin{center}#3\end{center}\end{minipage}\begin{minipage}[b]{#2\linewidth}\centering\begin{center}#4\end{center}\end{minipage}
}
\newcommand{\flecha}[1]{\xrightarrow{\hspace*{0.3cm} #1 \hspace*{0.3cm}}}
\newcommand{\Flecha}[1]{\xRightarrow{\hspace*{0.3cm} #1 \hspace*{0.3cm}}}
\newcommand{\caja}[2]{\begin{center}
\fbox{
\parbox{#1\linewidth}{
#2
}
}
\end{center}}
\renewcommand\contentsname{Índice}
\begin{titlepage}
\newcommand{\HRule}{\rule{\linewidth}{0.5mm}} % Defines a new command for the horizontal lines, change thickness here
\center % Center everything on the page
%----------------------------------------------------------------------------------------
% HEADING SECTIONS
%----------------------------------------------------------------------------------------
\textsc{\LARGE Universidad de Buenos Aires}\\[1.5cm] % Name of your university/college
\textsc{\Large Facultad de Ciencias exactas y Naturales}\\[0.5cm] % Major heading such as course name
\textsc{\large Licenciatura en Ciencias de la computación}\\[0.5cm] % Minor heading such as course title
%----------------------------------------------------------------------------------------
% TITLE SECTION
%----------------------------------------------------------------------------------------
\HRule \\[0.4cm]
{ \huge \bfseries Teóricas de Ingeniería del Software II}\\[0.4cm] % Title of your document
\HRule \\[1.5cm]
%----------------------------------------------------------------------------------------
% AUTHOR SECTION
%----------------------------------------------------------------------------------------
%
% \begin{minipage}{0.4\textwidth}
% \begin{flushleft} \large
% \emph{Autor:}\\
% Julián \textsc{Sackmann} % Your name
% \end{flushleft}
% \end{minipage}
% ~
% \begin{minipage}{0.4\textwidth}
% \begin{flushright} \large
% \emph{} \\
% \textsc{} % Supervisor's Name
% \end{flushright}
% \end{minipage}\\[4cm]
% If you don't want a supervisor, uncomment the two lines below and remove the section above
\Large \emph{Autor:}\\
Julián \textsc{Sackmann}\\[2cm] % Your name
%----------------------------------------------------------------------------------------
% DATE SECTION
%----------------------------------------------------------------------------------------
{\large 10 de Septiembre de 2012}\\[2cm] % Date, change the \today to a set date if you want to be precise
%----------------------------------------------------------------------------------------
% LOGO SECTION
%----------------------------------------------------------------------------------------
\begin{minipage}[t]{\textwidth}
\begin{minipage}[t]{.55 \textwidth}
\includegraphics{logo_uba.jpg}
\end{minipage}%%
\begin{minipage}[b]{.45 \textwidth}
\textbf{\textsf{Facultad de Ciencias Exactas y Naturales}} \\
\textsf{Universidad de Buenos Aires} \\
{\scriptsize %
Ciudad Universitaria - (Pabell\'on I/Planta Baja) \\
Intendente G\"uiraldes 2160 - C1428EGA \\
Ciudad Aut\'onoma de Buenos Aires - Rep. Argentina \\
Tel/Fax: (54 11) 4576-3359 \\
http://exactas.uba.ar \\
}
\end{minipage}
\end{minipage}%
%\includegraphics[scale=1]{logo_uba.jpg}\\[1cm] % Include a department/university logo - this will require the graphicx package
%\includegraphics{logo_uba.jpg}\\[1cm] % Include a department/university logo - this will require the graphicx package
%----------------------------------------------------------------------------------------
\vfill % Fill the rest of the page with whitespace
\end{titlepage}
%\maketitle
\thispagestyle{fancy}
\tableofcontents
\newpage
\section{Introducción: ¿Qué es la Ingeniería del Software?}
Existen dos corrientes contrapuestas de lo que es la ingeniería del software:
\subsubsubsection{Dijkstra}
Una, que tiene como cabeza a Dijkstra afirma que la ingeniería del software es ``aquello que hacemos porque no sabemos programar bien''. Dijkstra llama a la ingeniería del software \emph{``the doomed discipline''}: está perdida porque sus objetivos son contradictorios. Dijkstra plantea que el enfoque correcto a la programación (y particularmente a su enseñanza) es el de ver a los programas como fórmulas matemáticas y el trabajo del programador es derivar esa fórmula mediante la manipulación de símbolos. Tiene que ser un curso en matemática formal. Incluso opina que debería cambiarse el nombre a \texttt{VLSAL}: ``\texttt{V}ery \texttt{L}arge \texttt{S}cale \texttt{A}pplication of \texttt{L}ogic''.
La principal crítica que se le puede realizar a esta visión es que es demasiado academicista. No siempre es aplicable la visión de un programa como una fórmula matemática (menos aún cuando se trata de un proyecto grande). Del mismo modo, si bien no siempre es factible \textbf{demostrar} la correctitud de un programa, tiene valor intentar hacerlo (incluso escribirlos de forma de que sea posible su demostración).
\subsubsubsection{Yourdon}
La otra visión, encabezada por Yourdon, en la que se plantea una dicotomía fuerte entre la ciencia y la ingeniería. Según Yourdon, la construcción de software dista mucho de las fórmulas matemáticas y las demostraciones que plantea Dijkstra, sino que son ``un conjunto de métodos prácticos que traten con la naturaleza propesa a errores del personal de proyecto, los encargados de matenimiento, los usuarios, etc''.
Esta visión fue llevada al extremo por Fred Brooks, que plantea si realmente el trabajo de un computador es el de \emph{hacer ciencia}: tanto un ingeniero como un científico construyen, pero su propósito esencial es distinto: el ingeniero \emph{aprende para construir}, mientras que el científico \emph{construye para aprender}.
Brooks opina que cuando una profesión comienza, es habitual confundir las herramientas que uno usa con hacer ciencia y que ``computer science'' tiene poco que ver con la computadora. Siguiendo esta misma línea, Zemanek opina que la computación es la ``ingeniería de los objetos abstractos''.
\subsection{Ingeniería}
La definición de ``ingeniería'' (no acotada la software) es crear soluciones eficientes a problemas prácticos, aplicando conocimiento científico construyendo cosas al servicio de la humanidad. ``Es ciencia con un propósito''. Permite a la gente común hacer cosas que antes requerían virtuosos.
\subsubsection{Evolución de una Ingeniería}
\ig{0.4}{01_ing_evolucion.png}
Según Shaw, toda ingeniería pasa por una serie de etapas hasta convertirse en tal:
\begin{itemize}
\item Comienza siendo un \emph{\textbf{craft}} (``habilidad''). En esta etapa se construyen cosas en base a intuición y prueba y error. No existen métodos formales para la construcción. Se construyen cosas con el objeto de \textbf{usarlas}.
\item Cuando se inyecta la veta de producción a esto, se transforma en algo \textbf{comercial}. Se comienza a tener más habilidad y regularidad en la construcción (procesos más establecidos), pero aún sin formalismos. Se construyen cosas con el objeto de \textbf{vender}.
\item A medida que esto avanza, la ciencia se involucra por los métodos de construcción y se forma la \textbf{ingeniería profesional}, con profesionales educados en la ciencia, formalismos, análisis, teorías, etc. Se segmenta el conocimineo.
\end{itemize}
La aparición de modelos y teorías es clave para alimentar el ciclo que nos llevará a la verdadera disciplina de ingeniería: es un circuito retroalimentado:
\ig{0.4}{02_ing_circuito.png}
Cuando uno está construyendo sistemas, aparecen problemas nuevos (ejemplo actual: \emph{Big Data}) a las que se van encontrando soluciones ad-hoc. Eso genera un cierto ``folklore'' sobre esas soluciones ad-hoc hasta que en algún momento se hacen modelos y teorías para solucionarlo. Pero esto a su vez hace aparecer nuevos problemas, con lo que se crean nuevas soluciones...
\subsection{Ingeniería... de software}
\subsubsection{Definición}
Según la \texttt{IEEE}, la ingeniería del software es ``la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, mantenimiento y operación de sistemas de software''. Coloquialmente, hace referencia a la \textbf{aplicación de prácticas ingenieriles para la construcción de software}.
La ingeniería trata con:
\begin{itemize}
\item Requerimientos.
\item Diseño (soluciones técnicas).
\item Construirlo.
\item Testearlo.
\item Mantenimiento.
\item Gestión
\begin{itemize}
\item de configuración.
\item de proyecto.
\end{itemize}
\item Procesos.
\end{itemize}
Un problema de la ingeniería del software es que el desarrollo no existe en el éter, sino en un marco de \emph{deadlines} temporales, económicos.
\subsubsection{Negación de la ingeniería}
Existe gente que cree que la ingeniería del software en realidad ``no existe''. Sus argumentos suelen venir de tres vertientes:
\begin{itemize}
\item Falta formalidad en la ``ciencia'' que está por detrás. Todavía está demasiado inmadura. Esta ingeniería podría existir alguna vez, pero por ahora es sólamente un conjunto de prácticas.
\item El enfoque ``ingenieril'' está errado desde el vamos: escribir software es más similar a un arte que a una ingeniería.
\item El software es algo abstracto y la ingeniería se ocupa de cosas concretas.
\end{itemize}
\subsubsection{Ciencias de la computación vs Ingeniería del software}
Cuando hablamos de \textbf{ciencias de la computación} nos referimos a las \textbf{teorías y los fundamentos}.
Cuando hablamos de \textbf{ingeniería de software}, hablamos de \textbf{aspectos prácticos de desarrollar y entregar software útil}. Observemos que la ingeniería del software se nutre de la ciencia de la computación.
Observemos que la ingeniería en sistemas ($\neq$ ``de software'') trata sobre la conctrucción de sistemas que combinan hardware y software.
% FALTA TODO LO DE HISTORIA.
\subsubsection{Church vs Turing}
\begin{itemize}
\item Turing tiene una idea más mecanicista, en la que para programar se toman decisiones de diseño basados en los problemas intrínsecos de la máquina donde corren. Ej: \texttt{C/C++}.
\item Church tiene una idea más algebráica, basada en lambda cálculo, en la que se intenta obtener un análisis de forma más ``pura'' del problema de la realidad. Ej: \texttt{Lisp}.
\end{itemize}
~\newline
La ingeniería del software:
\begin{itemize}
\item Trabaja con algo muy complejo.
\item Que trata con una problemática muy amplia.
\item Que tiene dificultades esenciales.
\item Está evolucionando.
\end{itemize}
\newpage
\section{Modelos de ciclo de vida}
Un modelo de desarrollo de software se define como \textbf{un marco de trabajo usado para estructurar, planear y controlar el proceso de desarrollo de un sistema de información}. Sirve para \textbf{planificar}, \textbf{organizar} y \textbf{ejecutar} un proyecto.
Los modelos de ciclo de vida tratan el tema de cómo organizar un proceso de desarrollo de software en cuanto a su estructura:
\begin{itemize}
\item Etapas de un proyecto.
\item Orden relativo.
\item Criterios de transición entre etapas.
\end{itemize}
Cambiando entre distintos modelos de ciclos de vida se obtienen \emph{tradeoffs} entre:
\begin{itemize}
\item Velocidad de desarrollo.
\item Calidad del producto.
\item Visibilidad del proyecto.
\item Posibilidad de implementar versiones intermedias.
\item Carga de trabajo administrativo y de gestión.
\item Documentación (tipo y cantidad).
\item Exposición al riesgo.
\item Relación con el cliente.
\end{itemize}
\subsection{Code \& Fix}
\ig{0.4}{03_codeAndFix.png}
Es la ausencia de ciclo de vida. Se suele utilizar bastante en proyectos de desarrollo chicos. Programación, arregla, emparcha. El principal problema de este método es que no escala bien: con un proyecto de tamaño grande ya se vuelve caótico e inusable.
\subsection{Modelo en cascada}
\ig{0.4}{04_modeloEnCascada.png}
En su versión clásica, postulada por Royce, el proceso de desarrollo de software consta de etapas:
\begin{itemize}
\item Analizar los requerimientos del sistema.
\item Extraer los requerimientos.
\item Analizarlos.
\item Diseñar.
\item Codificar.
\item Testear.
\item Desplegar.
\end{itemize}
Una de las premisas más fuertes que tiene este modelo es que uno ya sabe lo que está haciendo con el software. El programador ya es experto del dominio.
El criterio de transición entre etapas del modelo en cascada es \textbf{documental}: sólo se pasa a la siguiente etapa cuando toda la documentación referida a la etapa actual está terminada.
\subsubsection{Problemas}
Este modelo trae aparejados varios problemas:
\begin{itemize}
\item Idealista pensar en identificar correctamente todos los requerimientos al principio.
\item No permite implementaciones parciales.
\item Usuario sólo involucrado al principio y al final.
\item Se retrasa la detección de problemas críticos.
\item En el caso de encontrarlos, es difícil volver para atrás para arreglarlos.
\item Lo que se aprende en una etapa no se vuelve a revisar.
\end{itemize}
Jackson critica el primer punto de esto haciendo una analogía con el principio de incertidumbre de Heisenberg: ``cualquier actividad de desarrollo de software intevitablemente cambia el entorno del cual surgió la necesidad del software''.
En la práctica, de cada etapa siempre se termina volviendo (con dificultad) a una anterior.
\subsubsection{Mejoras}
\subsubsection{Diseño preliminar}
\ig{0.4}{05_waterfallPreliminar.png}
Una posible mejora consiste en hacer un análisis preliminar antes de comenzar la etapa de análisis. De esta forma se pueden detectar problemas que pueden surgir en el diseño en forma temprana e impactan el análisis.
Esta técnica si bien presenta una mejora ante el modelo en cascada clásico, es más un parche que un cambio de base.
\subsubsubsection{Sashimi}
\ig{0.4}{06_sashimi.png}
El modelo en cascada \textbf{sashimi} (o ``de fases superpuestas'') intenta atacar el problema de la dificultad intrínseca del modelo en cascada clásico a la hora de volver a una etapa anterior. Para eso, flexibiliza el criterio y permite que se superpongan parcialmente dos etapas consecutivas. De este modo, se simplifica el proceso de volver a la anterior en el caso de encontrarse un problema.
\subsubsubsection{Subproyectos}
\ig{0.4}{07_waterfallSubproyectos.png}
El modelo en cascada \textbf{con subproyectos} plantea seguir el modelo en cascada clásico hasta la parte de diseño general. De ahí en adelante se continúa con varias alternativas durante las etapas de \textbf{diseño detallado}, \textbf{codificación} y \textbf{testeo}. Concluidas esas etapas
se comparan los resultados obteniddos y se continúa, unificadamente con una etapa de testeo global del sistema.
\subsubsubsection{Prototipos}
\ig{0.4}{08_waterfallPrototipo.png}
La idea del modelo de \textbf{prototipos} (o ``de reducción de riesgo'') es hacer un diseño preliminar antes de empezar el análisis real: cuando uno identifica los requerimientos iniciales, presenta al usuario con un prototipo de lo ``visible'' para el usuario y/o partes críticas. De este modo se obtiene una validación de parte del cliente de la correctitud de la idea.
Esto, en proyectos chicos funciona bien, pero no escala.
~\newline
\section{Modelo iterativo incremental}
El Modelo \textbf{iterativo incremental} (también llamado ``evolutivo'') es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. Su nombre se origina de:
\begin{itemize}
\item \textbf{Iterativo}: se hace varias veces lo mismo.
\item \textbf{Incremental}: el producto ``aumenta'' a medida que avanzamos.
\end{itemize}
\ig{0.4}{09_iterativoIncremental.png}
Los modelos iterativos incrementales constan de las siguientes etapas:
\begin{itemize}
\item \textbf{Identificación de requerimientos iniciales} (el nivel de detalle de esto depende del \textbf{método}, no del \textbf{modelo}).
\item \textbf{Selección de un subconjunto de requerimientos}: el criterio depende del método. Algunos posibles son:
\begin{itemize}
\item Lo más visible para el cliente.
\item Lo que más rápido determine viabilidad del proyecto.
\item Lo más crítico.
\item Lo más rápido de terminar.
\end{itemize}
\item \textbf{Desarrollo de los requerimientos elegidos}: se puede realizar mediante un pequeño método en cascada, mediante \texttt{TDD} (\emph{test driven development}) u otras técnicas.
\item \textbf{Seleccionar otro subconjunto de requerimientos e iterar}.
\end{itemize}
\subsection{Ventajas y desventajas}
\partir{0.5}{0.5}{\underline{Ventajas:}
\begin{itemize}
\item El usuario ve resultados rápidamente.
\item \emph{Feedback} rápido.
\item Se piensa en la calidad del sistema desde el inicio.
\item Se pueden atacar más fácilmente los riesgos.
\item Los ciclos van mejorando con las experiencias de los anteriores.
\item Minimizan la cantidad de funciones que se desarrollan y no se usan.
\end{itemize}
}{\underline{Problemas:}
\begin{itemize}
\item Requiere un cliente involucrado durante todo el proceso de desarrollo.
\item Se asume que todos los programadores tienen alto \emph{seniority}.
\item No son prácticos en proyectos donde los requerimientos están muy establecidos desde el principio.
\end{itemize}}
\subsection{Variaciones}
Un modelo iterativo incremental requiere ser instanciado con un método. Los distintos métodos que siguen el modelo iterativo incremental presentan diferencias en numerosas características. Por ejemplo:
\begin{itemize}
\item Duración de las iteraciones.
\item Transición de etapas.
\item Existencia o no de \textbf{tipos} de iteraciones (iteraciones más orientadas a una actividad que a otra).
\item Cantidad de esfuerzo dedicada a la elicitación inicial de requerimientos.
\item Actitud defensiva ante cambios en los requerimientos.
\end{itemize}
\subsection{Métodos}
Un \textbf{método de desarrollo} es una descripción de qué, como y cuándo hay que hacer algo. Que perfiles deben hacerlo, cómo se hace el testing, cómo se documenta, etc.
\subsubsection{Modelo en Espiral}
Propuesto por Boehm. El gráfico atrae mucho, pero nunca fue demasiado popular. El riesgo es el que guía la elección de funcionalidad.
\ig{0.4}{10_espiralBoehm.png}
Se concibe el desarrollo de software como una espiral infinita y creciente en donde cíclicamente se alternan períodos de \textbf{análisis}, \textbf{evaluación}, \textbf{desarrollo} y \textbf{planeamiento}.
\subsubsection{RUP}
\ig{0.4}{11_RUP.png}
Su nombre viene de \emph{``Rational Unified Proces''}.
Plantea que el software se desarrolla en iteraciones, luego de cada una de las cuales tengo un pedazo del sistema, cada vez más grande. Las iteraciones son distintas (y tienen distinto nombre): primero hay una etapa de iteración inicial donde uno no entiende los requerimientos ni el dominio. Entonces la mayor parte del tiempo va a ser entender esas cosas.
Cuanto más avanzo en las iteraciones más conocimiento tengo del dominio y más voy a dedicar a diseñar. Luego hay iteraciones de diseño, construcción, transición, etc.
\subsubsection{SCRUM (Introducción)}\label{scrum_intro}
Es un método ágil que usa el ciclo de vida iterativo incremental. Propone definir una lista de requerimientos (\textbf{\emph{backlog}}), seleccionar algunos, descomponerlo en tareas (de 1 a 4 semanas) y realizar iteraciones con chequeos diarios generando incremento de producto.
En teoría, no hay distinción de tipo de iteraciones, son todas iguales. En la práctica sin embargo, suele haber iteraciones más enfocadas a investigación, a implementación, a testeo, etc. Sin embargo, en todas las iteraciones se hace ``un poco de todo''. Por ejemplo:
\begin{itemize}
\item Inestabilidad de requerimientos / novedad del producto / Innovación $\Rightarrow$ Mayor peso al enfoque evolutivo.
\item Posibilidad concreta de partir el desarrollo $\Rightarrow$ Iteraciones más cortas.
\item Arquitectura más compleja o tecnología no conocida $\Rightarrow$ Enfoque de atacar riesgos desde el inicio, cuidado con la ``self emergence''.
\item Mayor complejidad del negocio $\Rightarrow$ No descuidar la especificación.
\end{itemize}
\subsubsubsection{Co-evolución}
El concepto de \textbf{co-evolución} fue presentado por Fred Brooks. Posulta que \emph{el espacio del problema evoluciona a medida que el espacio de la solución evoluciona al ser explorado}.
\ig{0.4}{12_coevolucion.png}
Los ciclos de vida deben ser co-evolutivos: arrancar con un problema y se le encuentra una solución. Con el problema original y esta solución, sale un nuevo problema. El espacio del problema evoluciona a medida que el espacio de la soluciones evoluciona al ser explorado.
\section{Métodos Ágiles}
Los métodos ágiles son un conjunto de métodos que implementan modelo iterativo incremental.
\subsubsection{Agile Manifesto}
El \textbf{ágile manifesto} es un documento que surge como reacción de la comunidad de desarrollo ante la crisis del software. En ese momento se creía que era un mero problema organizativo y de gestión. El remedio que se quiso aplicar es armar un marco de gestión muy importante, agregando mucha formalidad y abundancia de documentación al proceso de desarrollo. Esto se dio mediados y fines de los \'80 y casi todos los \'90.
El problema es que hubo una sobrecarga de esta burocracia, lo que impuso un movimiento para el otro lado. Cambiar la tendencia de desarrollo de software proponiendo métodos de desarrollo que valoren más cosas como:
\begin{itemize}
\item \textbf{Individuos e interacciones sobre procesos y herramientas}: se decía de no confiar en un proceso de desarrollo con demasiadas herramientas y procesos. Confiemos más en la gente y dejémosla interactuar.
\item \textbf{Software que funciona sobre documentación exhaustiva}: en esa época todos los procesos de desarrollo tenían mucha documentación. Esta gente propuso dejar de hacer tanta documentación, lo único imprescindible para tener un sistema andando es el software, no la documentación.
\item \textbf{Colaboración con el cliente sobre negociación de contratos}: cuando uno hace un contrato llave en mano, por los cambios a requerimientos y cosas que uno no pudo prever la cosa nunca termina siendo como se querían. Esto generaba una serie de tensiones. Todos esos procesos del estilo de ``esto es lo que hay que hacer y cualquier otra cosa es un desvío'' son lo que se intenta cambiar.
\item \textbf{Responder ante el cambio sobre seguimiento de un plan}: esto viene de la mano de lo anterior. En computación los planes son algo que cambia demasiado a diferencia de otras áreas.
\end{itemize}
Todos los métodos ágiles siguen estos lineamientos, que son bastante básicos. Proveen un marco básico desde donde empezar a trabajar y confían mucho en la gente para que se avance.
\subsubsection{Conceptos}
Los métodos ágiles introdujeron varios conceptos:
\subsubsubsection{Time Boxing}
El \emph{\textbf{time boxing}} consiste en tratar de ajustar las cosas en un período de tiempo acotado. Esto se plantea en contraposición al \emph{feature boxing} de la planificación tradicional, en la que se hace un plan concreto para cumplir un objetivo.
Informalmente, \emph{time boxing} se pregunta: ``tengo este período de tiempo y estos recursos, ambos acotados. ¿Qué puedo encajar acá?''. Se intenta priorizar la duración sobre el alcance. La limitación estricta de tiempo estimula a mantener el foco. Esto hace que se genere un ritmo de desarrollo constante al que la gente se acostumbra. Se aplica esto a todo: iteraciones, reuniones, tareas grupales, individuales, etc.
\subsubsubsection{Desarrollo Incremental}
El sistema va creciendo como consecuencia de la integración de nuevas funcionalidades. Cada funcionalidad que se agrega está testeada en forma unitaria, y también se prueba integrada al resto de la aplicación.
\subsubsubsection{Desarrollo Iterativo}
El proyecto se divide en \textbf{iteraciones}, que el equipo encara como mini-proyectos en si mismos. Idealmente, al final de cada una de estas iteraciones se debe obtener como resultado un producto andando con una porción de la funcionalidad requerida ya diseñada, implementada, testeada, etc. Debería estar listo para usarse si ese fuera el último requerimiento.
En la práctica, esto no se suele aplicar en forma estrícta, pero se respeta la idea general de que al finalizar una iteración no debería haber ``pedazos'' de código hecho ``a medias''. Esto se diferencia muy notablemente del paradigma tradicional, en donde la integración era el último paso en el desarrollo de un sistema: acá se va integrando
\subsubsection{Principios}
Los métodos ágiles introdujeron varios principios:
\begin{itemize}
\item \textbf{\texttt{DRY}}: \emph{Don't Repeat Yourself}. No crear código, herramientas o infraestructura duplicadas.
\item \textbf{\texttt{KISS}}: \emph{Keep It Simple Stupid!}. Evitar la complejidad no esencial.
\item \textbf{Do The Simplest Thing That Could Possibly Work}. Evitar la anticipación injustificada y las generalizaciones prematuras. Hay que mantener un balance entre generalizaciones que útiles y productivas y generalizaciones innecesarias y sin sentido.
\item \textbf{\texttt{YAGNI}}: \emph{You Ain't Gonna Need It}. Hace referencia a funcionalidades que el usuario cree que va a necesitar, pero realmente no lo va a necesitar.
\item \textbf{\texttt{DOGBITE}}: \emph{Do it, Or it's Gonna Bite you In The End}. Algunas cosas hay que hacerlas con anticipación (y suelen ser las menos atractivas).
\item \textbf{\texttt{SOC}}: \emph{Separation of Concerns}. Evitar el solapamiento de funcionalidad entre las diversas características o módulos de un programa.
\item \textbf{Done-Done-Done}: ser sincero sobre el estado de terminación de una tarea o unidad de entrega.
\item \textbf{Refactoring}: permanentemente reestructurar el código, el diseño, el proceso de desarrollo, etc.
\item \textbf{Shipping is a feature, and your product must have it}: el producto de una iteración debería ser instalable por el cliente.
\end{itemize}
..y algunos anti-principios (un patrón organizacional de implementación o diseño que es popular pero contraproducente):
\begin{itemize}
\item \textbf{\texttt{BDUF}}: \emph{Big Design Up Front}. Tiende a oponerse a \texttt{YAGNI} y \texttt{KISS}.
\item \textbf{Optimización prematura} sin tener métricas que la justifiquen.
\item \textbf{Bug Driven Development}: los requerimientos se completan en forma de bugs.
\end{itemize}
\subsubsection{Diferencias principales con métodos tradicionales}
\begin{itemize}
\item Tamaño: los métodos ágiles conviene aplicarlos con equipos chicos, entre 5 y 9 integrantes. Para equipos más grandes, conviene apegarse a métodos tradicionales.
\item Ubicación: los métodos ágiles requieren mucha comunicación y un equipo muy cohesivo. Si el equipo está disperso por muchos lugares geográficamente diversos, conviene quedarse con un método.
\item Estabilidad: los métodos tradicionales son mejores para equipos altamente fluctuantes. Los métodos ágiles requieren un equipo de gente estable.
\item Seniority del equipo: si el equipo es muy variado en cuanto a su nivel de seniority, conviene usar métodos tradicionales.
\item Cultura corporativa: los métodos ágiles son mejores en contextos de alto espíritu emprendedor (ej. programar un juego para iPhone).
\item Cambios a requerimientos: si los requerimientos son altamente cambiantes, conviene utilizar métodos ágiles, con iteraciones cortas.
\item Nivel de criticidad del software: hace referencia a las pérdias por bug. Para software de alto nivel de criticidad, conviene usar métodos más tradicionales porque son más estables y seguros.
\end{itemize}
\section{Scrum}
Como se mencionó en la sección \ref{scrum_intro}, \textbf{Scrum} es un método ágil que implementa el ciclo de vida iterativo incremental para el desarrollo de software.
\subsection{¿En qué proyectos conviene utilizarlo?}
El siguiente diagrama presenta en forma gráfica un lineamiento de cuándo conviene usar scrum y cuándo conviene usar métodos tradicionales, en función de algunas variables del proyecto. Cuánto más cerca se está del centro más conviene usar scrum.
\ig{0.4}{13_usingScrum.png}
\subsubsection{Costo de cambio}
El costo de cambiar cosas en el código sigue una función exponencial en el tiempo:
\ig{0.6}{costoEnTiempo.png}
Hoy en día esta curva es un poco más aplanada porque los avances tecnológicos simplificaron mucho el cambiar código en producción. Sin embargo en esencia sigue siendo cierta.
\subsection{Roles}
Una de las principales características de scrum es la presencia de \textbf{roles} para la organización del personal. Scrum define 3 roles:
\subsubsubsection{Product Owner}
El \textbf{\emph{product owner}} es un rol individual que representa al cliente o usuario final del producto. Su principal función es la de definir las prioridades de negocio. Es el encargado de escribir los documentos con los que se guiará el equipo para desarrollar el proyecto. En general en scrum estos documentos se llaman \emph{\textbf{user stories}}. El \emph{product owner} prioriza las \emph{user stories}, les asigna un valor y las agrega al \emph{\textbf{product backlog}}
Una de las críticas más fuertes que tiene el método scrum concierne con el rol del \emph{product owner}: el hecho de que todo ese concimiento y responsabilidades recaiga en una sola persona es irreal e inaplicable. En la realidad, no existe una sola persona que concentre el rol del \emph{product owner}, lo que redunda en problemas con los que tiene que lidiar el equipo de desarrollo, tales como información cruzada, retrasos en obtención de información.
\subsubsubsection{Scrum Master}
La persona con rol de \emph{\textbf{scrum master}} es la que actúa bajo una suerte de lider facilitador o \emph{coach} del equipo: su trabajo involucra remover cualquier impedimento que impida o retrase la productividad del equipo. Además, se ocupa de que se sigan los lineamientos de scrum durante el desarrollo. No se ocupa del manejo de personal ni de organizar al equipo de desarrollo. Concentra lo poco que quedó de los roles de gestión de los métodos tradicionales.
\subsubsubsection{Equipo}
El \textbf{equipo} en scrum consiste de un grupo \textbf{auto-organizado} de entre 5 y 9 individuos que tiene la responsabilidad de entregar el producto. Este equipo no consta sólo de programadores sino que es inter-disciplinario: involucra programadores, analistas, diseñadores, especialistas en bases de datos, en interfaz de usuario, testers, etc.
El rol de equipo también es objeto de críticas al método scrum. Se requiere que todos los individuos del equipo tengan un nivel de seniority elevado y parejo.
\subsection{Diagrama general}
\ig{0.3}{14_scrum.png}
\subsection{Producto y Product backlog}
Se define el \textbf{producto} como el resultado del proceso de desarrollo definido por el product owner. Para obtenerlo producto, el equipo parte del \textbf{product backlog}: una lista de items que describen funcionalidades y características que el proyecto debe tener:
\begin{itemize}
\item Involucra cosas pedidas por el usuario así como cosas propuestas por el equipo.
\item Debe expresar los requerimientos funcionales y no funcionales.
\item Es conveniente que incluya las características internas, no visibles al usuario (arquitectura, escalabilidad, uso de herramientas de desarrollo, etc).
\item Pueden agregarse o quitarse ítems, o cambiar las estimaciones o la prioridad en cualquier momento.
\item No hay un formato definido para los items – suelen ser \emph{user stories}.
\item Siempre hay un sólo \emph{product backlog}.
\end{itemize}
Cada uno de los items del \emph{product backlog} consta de:
\begin{itemize}
\item \textbf{Estado}. Puede ser:
\begin{itemize}
\item Terminado: ya se hizo en un \emph{sprint} anterior.
\item En el \emph{sprint}: se está haciendo en este \emph{sprint}.
\item Listo: está listo para agregarse a un \emph{sprint}.
\item No listo: no puede agregarse a un \emph{sprint} aún (por ejemplo, falta alguna dependencia).
\end{itemize}
\item \textbf{Valor}. Representa cuánto estima el usuario que esa funcionalidad vale para el proyecto.
\item \textbf{Esfuerzo}. Representa cuánto estima el equipo que va a costar hacer esa funcionalidad. Para determinar esfuerzo no se usa una escala absoluta sino relativa: se asigna 1 a la tarea más simple y se escala con eso como base (si una tarea tiene dificultad 3 es porque es 3 veces más difífcil que la más fácil).
\item \textbf{Prioridad}. Es una función del valor y del esfuerzo, usado para ordenar los items en el \emph{product backlog}.
\end{itemize}
Los valores y los esfuerzos suelen estar limitados y se utiliza la serie de Fibonacci para asignarles valor. Particularmente para el esfuerzo se busca consenso en el equipo.
\subsubsubsection{Ejemplo de product backlog}
\ig{0.4}{15_productBacklog.png}
\subsection{User Stories}
Una \textbf{user story} es un pequeño documento que especifica qué hay que hacer, evitando especificar cómo hacerlo. Estructuralmente, es similar a un caso de uso:
\begin{center}
``As a [user role] I want to [goal] so that [benefit]''
\end{center}
A las \emph{user stories} pueden agregarse detalles breves así como información adicional que ayude a definir el contexto. Además, es conveniente incluir los \textbf{criterios de aceptación} para esa \emph{user story}: conjunto de condiciones que, si se satisfacen, esa \emph{user story} se considera cumplida.
Uno de los principales beneficios de las \emph{user stories} es que ayudan a pensar desde la perspectiva del usuario.
\subsubsection{INVEST}
Es conveniente que las \emph{user stories} del \emph{product backload} cumplan una serie de características:
\begin{itemize}
\item \textbf{\emph{Independent}}. Deben ser tan independiente de otras stories como sea posible
\item \textbf{\emph{Negotiable}}. Demasiados detalles en una \emph{story} inhiben la comunicación Equipo-Owner-Cliente.
\item \textbf{\emph{Valuable}}. Deben tener valor para el usuario y/o para quien paga el desarrollo.
\item \textbf{\emph{Estimable}}. Legibles para el equipo y no demasiado grandes.
\item \textbf{\emph{Small}}. Menos de 3 semanas-hombre.
\item \textbf{\emph{Testable}}. Los criterios de aceptación deben ser tan objetivos como sea posible.
\end{itemize}
\subsubsection{Ejemplo de user story}
\ig{0.4}{16_userStory.png}
\subsection{Inicio de un proyecto}
Para iniciar un proyecto con scrum, se debe seguir la siguiente lista de pasos:
\begin{itemize}
\item Conseguir el apoyo del sponsor para usar scrum.
\item Capacitar en Scrum a todos los involucrados (\emph{product owner}, equipo, cliente final, etc).
\item Planificación:
\begin{itemize}
\item Definir la duración inicial de los \emph{sprints} (1 a 4 semanas).
\item El \emph{product owner} debe definir la visión inicial del producto.
\item El \emph{product owner} debe crear el \emph{product backlog} inicial y priorizar los ítems iniciales (al menos como para dos \emph{sprints}).
\begin{itemize}
\item Los ítems para los dos próximos \emph{sprints} deben cumplir con \texttt{INVEST}.
\item Los ítems menos prioritarios pueden ser sólo un título (epic).
\end{itemize}
\item El equipo debe estimar los ítems más prioritarios.
\begin{itemize}
\item La estimación suele hacerse en forma relativa, en \emph{story points}.
\end{itemize}
\item Definición de los releases previstos y la funcionalidad que se espera entregar en cada uno.
\item Evaluación de riesgos.
\end{itemize}
\end{itemize}
\subsection{Sprints}
Un \emph{\textbf{sprint}} (o iteración) es una unidad básica de desarrollo. Por el principio de \emph{time boxing} de los métodos ágiles, consta de una longitud fija de tiempo, que no se extiende por ninguna circunstancia (incluso si el trabajo correspondiente a esa iteración no fue concluido).
Antes de comenzar cada iteración, el equipo decide qué elementos del \emph{product backlog} entrarán en función de, entre otras cosas, la prioridad de los mismos. Es conveniente que cada \emph{sprint} tenga un objetivo particular (por ejemplo, ``implementación básica de validador de datos''). En general, este objetivo y un ``alcance deseado'' del sprint son presentados por el \emph{product owner} y se da una etapa de negociación en la que el equipo, \emph{scrum master}, \emph{product owner} y \emph{stakeholders} debaten si esas stories van a entrar o no. El equipo realiza una estimación de cuántos puntos de esfuerzo puede cumplir por iteración. Esta medida se llama \textbf{velocity}. Las \emph{stories} que entraron en la iteración forman la \emph{sprint list}.
Concluido esto, el equipo se reune (junto con el \emph{scrum master} y el \emph{product owner} para responder dudas) para realizar el \textbf{plan detallado} del \emph{sprint}, que consiste en descomponer cada \emph{user story} en \textbf{tareas}. A cada tarea se le estima una cantidad de horas que tomará su realización. Como regla general, una tarea no puede tardar más de 8hs (una jornada laboral). Si eso ocurre, se la subdivide en tareas más pequeñas. A esta reunión se la llama \textbf{Sprint Planning Meeting}.
Durante las iteraciones, el equipo se reune diariamente en una \textbf{\emph{daily scrum meeting}}, donde se realiza un seguimiento del progreso. Se comenta qué se estuvo haciendo, a qué paso se viene avanzando, qué se planea hacer hasta la reunión siguiente, si hubo algún problema o retraso, etc.
Una vez que termina cada iteración, el equipo revisa los resultados con el \emph{product owner} y los \emph{stakeholders} y hace una demo. El resultado de un \emph{sprint} debería ser un incremento en la funcionaliad, integrado y testeado. Además, el equipo con el \emph{scrum master} se reunen a hacer una retrospectiva para ver cómo fue la metodología de trabajo, qué se puede mejorar, qué se puede cambiar, etc.
Esta metodología con sus muchas reuniones colaboran mucho con la \textbf{visibilidad} de scrum.
\subsection{Herramientas}
\subsubsection{Pizarra}
El método scrum utiliza una \textbf{pizarra} para agrupar las tareas de la iteración actual de acuerdo con su estado:
\begin{itemize}
\item \emph{Not Yet Started}.
\item \emph{In Progress}.
\item \emph{Completed}.
\item \emph{Blocked}.
\end{itemize}
A la hora de actualizar una tarea en la pizarra conviene que se haga inmediatamente. Cada tarea lleva su estimación de horas restantes, que debe ser actualizada antes o durante la reunión diaria.
La pizarra no es un elemento estático: las horas restantes de una tarea pueden crecer, así como la cantidad de tareas. Si surge una tarea inesperada se agrega a la pizarra, con su estimación. Nadie debe trabajar en tareas que no estén en la pizarra.
\subsubsection{Mediciones}
Para medir cuán productiva una iteración, el método scrum propone dos gráficos:
\subsubsubsection{Product burndown chart}
Es un gráfico de días que faltan en función de la fecha. Da una indicación de que tan rápido el equipo está terminando los requerimientos del \emph{product backlog} en cada \emph{sprint}.
\subsubsubsection{Story burndown chart}
Es un gráfico de horas restantes en función de días del \emph{sprint}. Da una indicación de que tan rápido el equipo está terminando \emph{stories} o ``bajando horas'' en un \emph{sprint}. Muestran comportamientos disfuncionales.
\subsection{Problemas de scrum}
\begin{itemize}
\item Simplificación del \emph{product owner}.
\item Requiere un \emph{product owner} involucrado durante todo el proceso de desarrollo.
\item Se asume que todos los programadores tienen alto \emph{seniority}.
\end{itemize}
\newpage
\section{Gestión de proyectos}
Cuando un software crece, existen dos tipos de desafíos:
\begin{itemize}
\item De gestión: complicaciones en la logística del trabajo, tales como coordinación entre equipos, colaboración, diálogo, etc.
\item Técnicos: complicaciones de escalabilidad, seguridad, portabilidad, soporte, etc.
\end{itemize}
\subsection{¿A qué se dedica un gerente?}
Se ocupa de comunicar a las personas. Tiene un rol de coordinación. Entre la gente no se pueden comunicar, porque son muchos. Además, ayuda a facilitar el trabajo de la gente. Toma decisiones de rumbo. Determina algún curso de acción. Planificación.
En general, las funciones de gerenciamiento involucran:
\begin{itemize}
\item \textbf{Planificar}: es la fijación de objetivos y predeterminación de un curso de acción para lograrlos.
\item \textbf{Organizar}: es la asignación de objetivos o tareas a roles.
\item \textbf{\emph{Staffing}}: asignación de personas concretas a cada uno de los roles que acabo de definir en la organización.
\item \textbf{Liderar}: es el conjunto de tareas que tiene como objetivo crear un clima de trabajo en el cual la gente pueda hacer sus tareas motivada, en equipo y sin inconvenientes.
\item \textbf{Controlar}: tiene que ver con el delta entre la realidad y el plan. Se debe analizar si ese delta es muy grande, considerar acciones correctivas (tales como reasignación de recursos, cambio de plan, de \emph{staffing}, etc).
\end{itemize}
\subsubsection{Identificación de Stakeholders}
Otra de las tareas clave de un gerente es la identificación de \emph{stakeholders}. El gerente debe claramente identificar:
\begin{itemize}
\item Para quién se desarrollará el producto.
\item Quién lo pagará.
\item Quién lo usará.
\item Quién es el factor de decisión esencial.
\item Quién tiene el \emph{know-how} (conocimiento de dominio, de formas, etc).
\item Quién (y cómo) aceptará el producto terminado.
\end{itemize}
Algunos \emph{stakeholders} clave son:
\begin{itemize}
\item Sponsor: es el que impulsa y le interesa que el proyecto avance.
\item Lider usuario: es el que tiene más \emph{know-how}.
\item Usuarios directos e indirectos.
\end{itemize}
\subsubsection{Determinación de factores críticos}
Otra de las tareas de un gerente es la determinación de \textbf{factores críticos}. Es necesario determinar qué cosa es importante para el proyecto dado:
\begin{center}
\emph{``Puede ser bueno, lo puedo entregar rápido o puede ser barato. Elija dos.''}
\end{center}
En general podemos hablar de cinco dimensiones de la calidad en un proyecto de software:
\begin{itemize}
\item Funcionalidad.
\item Calidad.
\item Recursos.
\item Costo.
\item Plazo.
\end{itemize}
Cada uno de estos puede ser un \emph{driver} (motivador), restricción (cota) o tener grados de libertad. Una forma de graficar esto es asignar un puntaje a cada uno de estas 5 dimensiones y graficarlo en un pentágono:
\begin{figure}[!htb]
\minipage{0.32\textwidth}
\includegraphics[width=\linewidth]{images/17_ej1_infoInterno.png}
\caption{Sistema de información interno}
\endminipage\hfill
\minipage{0.32\textwidth}
\includegraphics[width=\linewidth]{images/17_ej2_appComercial.png}
\caption{Aplicación comercial competitiva}
\endminipage\hfill
\minipage{0.32\textwidth}%
\includegraphics[width=\linewidth]{images/17_ej3_qualityDriven.png}
\caption{``Quality Driven''}
\endminipage
\end{figure}
\subsubsection{Identificación preliminar de requerimientos}
Otra de las tareas de un gerente es la identificación preliminar de requerimientos. Es un paso necesario para hacer la planificación, dado que inicialmente se usan para la estimación. Este paso involucra no solo requerimientos funcionales, sino también \textbf{atributos de calidad}.
\subsubsection{Otros}
Otras tareas importantes a realizar antes de comenzar un proyecto involucran:
\begin{itemize}
\item Elección de un modelo de ciclo de vida.
\item Definición de un proceso para el proyecto.
\item Definición de relación gente / duración y curva de \emph{staffing} (cuidado con el ``mito hombre hora''\footnote{El \textbf{mito hora hombre} afirma que es falso que las horas y los hombres son intercambiables. \emph{Por muchas mujeres que ponga a la tarea, no voy a tener un bebé en menos de 9 meses}.} y la ``zona imposible''\footnote{La \textbf{zona imposible} es el momento en el cual, por más que agregue más gente, no puedo comprimir más el tiempo del proyecto.}).
\end{itemize}
\subsection{WBS}
Un (\texttt{WBS}) (\emph{Work Breakdown Structure}) es un gráfico que muestra la división de un proyecto o el producto en partes más pequeñas y manejables, hasta el nivel en que será ejecutado el control. Es el primer paso del armado de un cronograma.
Para realizar un \texttt{WBS}, es necesario, en primer lugar, definir su propósito (ej: poder estimar o asignar tareas) e identificar el nodo raíz. Luego, se subdivide cada componente en $7\pm2$ subcomponentes hasta que se cumpla con el propósito.
\subsubsection{Tipos de WBS}
Existen tres tipos de \texttt{WBS}:
\subsubsubsection{WBS de proceso}
\begin{itemize}
\item La raíz identifica el nombre del proyecto.
\item El segundo nivel identifica elementos mayores - Planificación, organización, análisis de requerimientos, diseño, iteraciones, etc.
\item Partición de un proceso en subprocesos hasta obtener tareas individuales (1 o 2 personas) a desarrollar en poco tiempo (1 a 2 semanas).
\end{itemize}
\subsubsubsection{WBS de producto}
\begin{itemize}
\item Altamente relacionado con la arquitectura del producto.
\item Identifica componentes e interfaces del producto.
\item Identifica hardware, software y datos.
\item La raíz identifica el nombre del producto.
\item Los otros elementos son ítems discretos e identificables de hardware, software y datos.
\end{itemize}
\subsubsubsection{WBS híbrido}
\begin{itemize}
\item Combina elementos de los dos tipos anteriores.
\item La raíz es un proceso, alternando elementos de proceso y producto.
\item La idea es que los procesos producen productos y los subproductos requieren procesos para su desarrollo.
\item Utilizado por managers que quieren priorizar la estimación y control precisos de cada elemento de producto.
\end{itemize}
\subsubsection{Dependencias}
Para poder optimizar la asignación de recursos es necesario entender las \textbf{dependencias} entre las tareas. Una dependencia es una relación entre dos o más tareas. Esta relación puede ser:
\begin{itemize}
\item Fin a comienzo.
\item Fin a fin.
\item Comienzo a fin.
\item Comienzo a comienzo.
\end{itemize}
A la hora de armar un plan, la fecha de comienzo de tareas debe ser dinámicamente establecida en función de sus dependencias.
\subsubsubsection{Tareas especiales}
Se usa el recurso de \textbf{tarea hito}: es una tarea que tiene duración 0 que tiene un entregable asociado. Se utiliza como punto de control donde confluyen muchas tareas. Suelen tener alguna actividad relacionada.
Además, es necesario considerar e inlcuir \textbf{puntos de revisión y ajuste}, que suelen generar ciclos de tareas.
\subsubsubsection{Dependencias externas}
Es esencial considerar no sólo dependencias entre tareas internas al proyecto sino también dependencias con otros proyectos. Esto involucra no sólo tareas técnicas, sino también de negocios.
Además, no sólo hay que tener en cuenta proyectos ``propios'' sino también proyectos existentes en la organización con impacto en el propio.
Al final se agregan dependencias por contención de recursos: no tiene que ver con la esencia de las tareas, sino con que no tengo gente para hacer todas esas tareas en paralelo.
\subsubsection{Camino crítico}
Un \textbf{camino crítico} en un \texttt{WBS} es una secuencia de tareas en el \texttt{DAG} del proyecto cuyo atraso provoca atrasos en el fin del proyecto.
Toda camino tiene asociado un \emph{\textbf{slack}} (margen): una cantidad de tiempo que se puede atrasar esa rama sin que se atrase todo el proyecto. Un camino es crítico si su \emph{slack} es 0.
\ig{0.3}{18_wbsDag.png}
~\newline
Es importante tener en cuenta los caminos críticos porque, lógicamente, es donde debe ir el mayor esfuerzo, más recursos, más atención, etc. Es lo que tengo que acortar si quiero acortar todo el proyecto. Además es crucial en la estimación: un análisis del plan para comprimir cronogramas debe comenzar por las tareas críticas.
El \emph{\textbf{lag}} es el atributo de una arista que determina el tiempo mínimo que tiene que pasar entre que termino una tarea y puedo empezar la siguiente.
\subsubsection{Diagrama de Gantt}
Un \textbf{diagrama de Gantt} es un gráfico que me muestra el ordenamiento de las tareas a lo largo del tiempo. Muestra tareas con responsables, fechas, secuencia de ejecución y costos directos. Sirve fundamentalmente como referencia para la ejecución y control del proyecto. Para presentaciones se suelen usar sólo diagramas de hitos o de componentes de alto nivel, sin incluir la descripción detallada de actividades.
\ig{0.4}{19_gant.png}
\subsubsection{Otras definiciones}
\begin{itemize}
\item \textbf{Línea de base}: Es una versión estable de mi plan que se usa como base para hacer el seguimiento. Es contra lo que voy a comparar la planificación actual.
\item \textbf{Programación por valor acumulado}: tiene que ver con la medición del progreso. Para medir avance se usa la fórmula de valor acumulado: definición de pesos a los entregables de los hitos, para medir avance (no esfuerzo). Informalmente, se asocian entregables a cada hito. Esos esos entregables tienen un peso que voy acumulando a medida que voy logrando.
\end{itemize}
\subsection{Gestión de riesgos}
En el contexto de gestión de proyectos, se define un \textbf{riesgo} como un problema que todavía no ocurrió. Un \textbf{problema} es un riesgo que se manifestó.
Los riesgos tratan sobre posibles eventos en el futuro y están caracterizados por:
\begin{itemize}
\item \textbf{Probabilidad} de que el riesgo se manifieste.
\item \textbf{Impacto} si lo hace.
\end{itemize}
Se define la \textbf{exposición} a un riesgo como $probabilidad\ \times\ impacto$. Uno de los principales problemas de la ingeniería del software es que no hay forma exacta de cuantificar estas medidas. Se suelen trabajar ``artesanalmente''.
Estas dos caracterizaciones definen las dos principales formas de atacar un riesgo: reducir la probabilidad de que ocurra o su impacto negativo si ocurre.
Una \textbf{fuente de riesgo} es algo que me indica que un riesgo está presente.
\subsubsection{Sistematización}
Para sistematizar el tratamiento de riesgos, la \texttt{IEEE} propone realizar ciclos de:
\begin{itemize}
\item Identificación de riesgo.
\item Análisis de riesgo.
\item Planificación.
\item Seguimiento del plan.
\item Aplicación de medidas de control.
\end{itemize}
\ig{0.5}{20_sistematizacionRiesgos.png}
\subsubsection{Identificación de riesgos}
Existen numerosos métodos para identificar riesgos:
\begin{itemize}
\item Brainstorms.
\item Reporte periódico de riesgos.
\item Cuestionario de identificación taxonómica. Es un cuestionario de 194 preguntas si/no. Es obsoleto.
\item Reportes voluntarios de riesgos.
\item Listas de riesgos comunes,
\end{itemize}
\subsubsection{Documentación}
Dado que los riesgos son algo inevitable e inherente del desarrollo de software, es importante que queden bien documentados. Para esto se recomienda usar la representación de Gluch:
\begin{center}
``\textbf{Dado que} [condiciones], \textbf{entonces, posiblemente, } [consecuencias]''
\end{center}
~\newline
Para categorizar los riesgos se los ordena en una matriz de probabilidad $\times$ impacto llamada \textbf{matriz de magnitudes}:
\ig{0.4}{21_categoriaRiesgo.png}
Otro aspecto de la documentación involucra la definición de prioridades. Una vez categorizados los riesgos en la matriz de magnitudes, ordenamos los riesgos según la matriz de magnitudes, ignorando los riesgos de baja magnitud. Para los riesgos de igual magnitud ponemos primero los que requieran acciones correctivas con más urgencia y/o impacto.
Siempre tratamos de quedarnos con los 5 o 10 riesgos con mayor exposición.
\subsubsection{Planificación}
Un \textbf{plan de contingencia} es el conjunto de medidas que han de tomarse si un riesgo se manifiesta. Es muy importante que los planes de contingencia estén bien documentados incluyendo, entre otros en qué circunstancias y quién aplica el plan de contingencia. Además, debe ser implementable.
\subsection{Plan de gestión de proyecto}
Armar un plan de proyecto es más complejo que simplemente armar un cronograma. Incluye cosas como:
\begin{itemize}
\item Organización del proyecto.
\item Definición de la estructura interna.
\item Modelo de ciclo de vida
\item Infraestructura.
\item Roles y responsabiliaddes.
\item Gestión de configuración.
\item QA.
\item Gestión de calidad.
\item Comienzo del proyecto.
\item Plan de trabajo / cronograma.
\item Plan de control.
\item Gestión de riesgos.
\item Cierre del proyecto.
\item Organización de planes de proceso.
\end{itemize}
El \textbf{plan de gestión de proyecto} es un documento consistente y coherente para guiar la ejecución y el control del proyecto. Su uso está reglamentado en un estándar de la \texttt{IEEE}.
\newpage
\section{Atributos de calidad}
La \textbf{ingeniería de requerimientos} es una forma disciplinada y sistemática de llegar desde las necesidades de los usuarios hasta una especificación. Para definir correctamente una arquitectura, es imprescindible conocer tres elementos del software:
\begin{itemize}
\item Funcionalidad ``de negocio'' (requerimientos funcionales).
\item Atributos de calidad (requerimientos no-funcionales).
\item Restricciones.
\end{itemize}
Un proyecto de software no se compone enteramente de su funcionalidad \textbf{de negocio}. También existen los \textbf{atributos de calidad} (``ilities''), que referencian características específicas que debe tener el sistema. Antiguamente se llamaban requerimientos no-funcionales. Existen numerosos atributos de calidad, los tratados en la materia son:
\begin{itemize}
\item Performance.
\item Disponibilidad.
\item Testeabiliad.
\item Modificabilidad.
\item Usabilidad
\item Seguridad.
\end{itemize}
(\emph{Sugerencia: un acrónimo para recordarlos es \textbf{PeDiTe MoUsSe}.})
Es importante notar que estos problemas no son completamente independientes, sino que se afecan mucho entre si. Es común que una medida que se tome para mejorar uno de estos atributos de estos de calidad vaya en detrimento de otra. Por ejemlo, una mejora en seguridad suele empeorar la usabilidad de un sistema.
Según la \texttt{IEEE}, la \textbf{calidad} ``\emph{La calidad de un software es el grado en el que un software tiene una combinación deseada de atributos}''.
~\newline
Para atacar los atributos de calidad, se usan \textbf{tácticas} de arquitectura (ver \ref{tacticas}). Estos no son objetivos en si mismos, sino formas de alcanzar atributos de calidad.
\subsection{Generales vs Concretos}
\partir{0.5}{0.5}{\underline{Generales:}
\begin{itemize}
\item Son independientes de un sistema específico y por lo tanto pueden, potencialmente, pertenecer a cualquier sistema.
\item Son una guía para saber qué preguntar o pensar en escenarios candidatos.
\item Están ordenados por atributo de calidad.
\end{itemize}
}{\underline{Concretos}
\begin{itemize}
\item Son específicos a un sistema, instanciando cada uno de sus atributos.
\end{itemize}}
\subsection{Los 6 atributos}
\subsubsection{Disponibilidad}
El atributo de calidad de \textbf{disponibilidad} está relacionado con las fallas (\emph{failures}) que puede tener el sistema y sus consecuencias asociadas. Se considera que ocurre una \textbf{falla} (\emph{failure}) un sistema no entrega más un servicio de acuerdo con su especificación. Estas fallas (\emph{failures}) son observables por los usuarios.
La disponibilidad es la probabilidad de que un sistema esté disponible cuando se lo necesite. Un sistema se dice \textbf{tolerante a fallas} si puede seguir operando en presencia de fallas.
Es importante entender la distinción entre los siguientes conceptos:
\begin{itemize}
\item \emph{\textbf{Fault}}: un paso, proceso o definción incorrecta en un sistema que causa que el programa no responda en la forma esperada. Es una debilidad inherente al proceso de desarrollo de software que redunda en un \emph{failure}.
\item \emph{\textbf{Failure}}: la incapacidad de un sistema o componente de realizar sus funciones requeridas por su especificación.
\item \emph{\textbf{Error}}: una diferencia entre el valor observado o medido por un cómputo y el valor ``correcto'', especificado por la teoría.
\end{itemize}
Se define el \textbf{tiempo de reparación} como el tiempo hasta que la falla no es más observable.
\subsubsubsection{Tipos de fallas}
\begin{itemize}
\item Crash faliure: el sistema funciona perfectamente hasta que ocurre un error inesperado.
\item Omission faliure: el sistema falla recibiendo requerimientos, enviando o recibiendo mensajes.
\item Timing faliure: el sistema responde fuera de los tiempos esperados.
\item Response faliure: respuesta del sistema incorrecta o se desvía del flujo de control correcto.
\end{itemize}