-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
671 lines (654 loc) · 84 KB
/
index.html
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
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<meta name="description" content="">
<meta name="author" content="">
<title>Bienvenido</title>
<link rel="icon"
href="img/favico.ico">
<!-- Bootstrap core CSS -->
<link href="vendor/bootstrap/css/bootstrap.min.css" rel="stylesheet">
<!-- Custom fonts for this template -->
<link href="https://fonts.googleapis.com/css?family=Saira+Extra+Condensed:500,700" rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=Muli:400,400i,800,800i" rel="stylesheet">
<link href="vendor/fontawesome-free/css/all.min.css" rel="stylesheet">
<!-- Custom styles for this template -->
<link href="css/resume.min.css" rel="stylesheet">
</head>
<body id="page-top">
<nav class="navbar navbar-expand-lg navbar-dark bg-primary fixed-top" id="sideNav">
<a class="navbar-brand js-scroll-trigger" href="#page-top">
<span class="d-block d-lg-none">Williams Geovanny Carrillo Fuentes</span>
<span class="d-none d-lg-block">
<img class="img-fluid img-profile rounded-circle mx-auto mb-2" src="img/logo.jpg" alt="">
</span>
</a>
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
<span class="navbar-toggler-icon"></span>
</button>
<div class="collapse navbar-collapse" id="navbarSupportedContent">
<ul class="navbar-nav">
<li class="nav-item">
<a class="nav-link js-scroll-trigger" href="#about">INTRODUCCIÓN</a>
</li>
<li class="nav-item">
<a class="nav-link js-scroll-trigger" href="#experience">CLASES IMPARTIDAS</a>
</li>
<a class="nav-link js-scroll-trigger" href="#awards">AUTOR</a>
</li>
<li class="nav-item">
</ul>|
</div>
</nav>
<li class="nav-item">
<div class="container-fluid p-0">
<section class="resume-section p-3 p-lg-5 d-flex align-items-center" id="about">
<div class="w-100">
<h1 class="mb-0">Introducción
<span class="text-primary">a Ingenieria de Software</span>
</h1>
<p class="lead mb-5"><p><strong>Sitio recopilatorio de las clases impartidas durante la estadía del primer parcial de la materia de introduccíon a Software.</strong></p>
<p><strong>Sobre la pagina:</strong></p>
<p><strong>Este sitio alojado en un repositorio de GitHub, tiene la finalidad de recopilar todo lo enseñado durante el primer parcial de la materia de Introducción a Software de la mano del Ing. Angel Cuenca.</strong></p>
<hr class="m-0">
<section class="resume-section p-3 p-lg-5 d-flex justify-content-center" id="experience">
<div class="w-100">
<h2 class="mb-5">Introducción a la ingenieria de Software</h2>
<div class="resume-item d-flex flex-column flex-md-row justify-content-between mb-5">
<div class="resume-content">
<h3 class="mb-0">FUNDAMENTOS A LA INGENIERÍA DE SOFTWARE</h3>
<div class="subheading mb-3">Definición de IS (continúa)</div>
<p><p><strong>Bohem, 1976</strong>: Ingeniería del Software es la aplicación practica<br />del conocimiento científico en el diseño y construcción de<br />programas de computadora y la documentación necesaria<br />requerida para desarrollar, operar (funcionar) y mantenerlos.</p><p><strong>Definición de IS</strong> (resumiendo)<br />La ingeniería de software es una aplicación práctica del<br />conocimiento cientifico para proveer metodologías y técnicas<br />que ayuden a desarrollar sistemas de software a tiempo y a su<br />vez que aseguren que el desarrollador cumpla con las<br />expectativas de calidad y permanezca dentro del presupuesto.</p><p><strong>Objetivos de la IS:</strong><br />Diseñar programas informáticos que se adecúen a las exigencias<br />de la sociedad.<br />Liderar y acoplar el desarrollo de programaciones complicadas.<br />Actuar en todas las fases del ciclo de vida de un producto.<br />Computar los costos de un proyecto y evaluar los 7empos de<br />desarrollo.<br />Realizar el seguimiento de costes y plazos.<br />Liderar equipos de trabajo de desarrollo software.</p>
<p><strong>Objetivos de la IS (continúa)</strong><br />Estructurar la elaboración de evidencias que comprueben el<br />perfecto funcionamiento de los programas y que se adaptan a<br />los requerimientos de análisis y diseño.<br />Diseñar, construir y administrar bases de datos.<br />Liderar y orientar a los programadores durante el desarrollo de<br />aplicaciones.<br />Incluir procesos de calidad en los sistemas, calculando métricas<br />e indicadores y chequeando la calidad del software producido.</p>
<p><strong>Origen de IS:</strong><br />Ingeniería del So-ware, es el término utlizado por Fritz Bauer en la<br />primera conferencia sobre desarrollo de so-ware patrocinada por el<br />Comité de Ciencia de la OTAN celebrada en Garmisch (Alemania), en<br />octubre de 1968, previamente había sido utilizado por el<br />holandés Edsger Dijkstra en su obra The Humble Programmer.<br />Puede definirse según Alan Davis como "la aplicación inteligente de<br />principios probados, técnicas, lenguajes y herramientas para la<br />creación y mantenimiento, dentro de un coste razonable, de sofware<br />que satisfaga las necesidades de los usuarios".</p>
<ul style="list-style-type: circle;">
<li><strong>Origen de IS (continúa)</strong><br />Su origen se debió a que el entorno de desarrollo de sistemas<br />software adolecía de:<br />Retrasos considerables en la planificación<br />Poca productividad<br />Elevadas cargas de mantenimiento<br />Demandas cada vez más desfasadas frente a las ofertas<br />Baja calidad y fiabilidad del producto<br />Dependencia de los realizadores</li><p>-Esto es lo que se ha denominado habitualmente "crisis del<br />software", que históricamente se generó en los siguientes<br />pasos:<br />-Primera Fase. Los albores (1945-1955)<br />-Programar no es una tarea diferenciada del diseño de una<br />máquina.<br />-Uso de lenguaje máquina y ensamblador.<br />-Segunda Fase. El florecimiento (1955-1965)<br />-Aparecen multitud de lenguajes<br />-Se pensaba que era posible hacer casi todo.</p>
<p>-Tercera Fase. La crisis (1965-1970)-Desarrollo inacabable de grandes programas<br />-Ineficiencia, errores, coste impredecible<br />-Nada es posible.<br />-Cuarta Fase. Innovación conceptual (1970-1980)<br />-Fundamentos de programación<br />-Verificación de programas<br />-Metodologías de diseño.</p>
<p>-Quinta Fase. El diseño es el problema (1980-?)<br />-Entornos de programación<br />-Especificación formal<br />-Programación automática.</p><p><strong>La evolución del software:</strong><br />El término “evolución” del software se utiliza desde los sesenta<br />para denominar la dinámica de crecimiento del software.<br />Una definición atribuida a Lehman y Ramil dice que la evolución<br />del software es “todas las actividades de programación que se<br />orientan a generar una nueva versión de un so-ware a partir de<br />una versión anterior operativa.</p>
<p><strong>La evolución del software (continúa)</strong><br />-Ned Chapin 1(1999) lo definió como “la aplicación de las<br />ac7vidades y procesos de mantenimiento del so-ware que<br />generan una nueva versión operativa de un software con una<br />funcionalidad de usuario o propiedades cambiadas a partir de<br />una versión anterior […] junto con los procesos y actividades de<br />garantia de calidad y con la gestión de esos procesos”. De estas<br />definiciones se desprende que la evolución cubre el ajuste a<br />funcionalidades adicionales.<br />-La guía SWEBOK2 considera que la causa del mantenimiento<br />está tanto en la necesidad de “cambios” como de “evolución”<br />en el software.</p>
<p><strong>La crisis del software:</strong><br />¿Cómo se define crisis?<br />-La palabra crisis se define en el diccionario como "un punto<br />decisivo en el curso de algo; momento, etapa, o evento decisivo<br />o crucial". Sin embargo para el software no ha habido ningún<br />punto crucial, sólo una lenta evolución.<br />-La crisis en la industria del software permanece durante<br />muchos años, lo cual parece una contradicción para el término.<br />Lo que si se podría decir es que hay un problema crónico en el<br />desarrollo de software.</p>
<p><strong>La crisis del software (continúa)</strong><br />-Formalismo y metodología<br />-Herramientas de soporte<br />-Administración eficaz</p>
<p><strong>La crisis del software</strong><br />Actualmente está surgiendo una gran expectativa ante la evolución de<br />la Ingeniería del Software, al ir apareciendo nuevos métodos y herramientas<br />formales que van a permitir en el futuro un planteamiento de ingeniería en<br />el proceso de elaboración de software.<br />Dicho planteamiento permitirá dar respuesta a los problemas de:<br />- Administración<br />- Calidad<br />- Productividad<br />- Fácil mantenimiento<br />Este último es uno de los grandes problemas, pues puede llegar a suponer<br />un importe superior al 60% del total del coste del software.</p>
<p><strong>¿Por qué se crea la IS?</strong><br />-La ingeniería de software se crea debido a las siguientes características:<br />-El producto debe ser confiable y realizar sólo las tareas especificadas en los<br />requerimientos.<br />-El producto debe ser robusto. Esto quiere decir que el software se comporta<br />de manera razonable, incluso en circunstancias no anticipadas desde el<br />principio.<br />-El producto de software debe ser lo más reutilizable posible, de manera tal<br />que pueda ser incorporado en otro producto de software si se requiere.<br />-El producto de software debe ser eficiente en el uso de los recursos del<br />sistema.</p>
<p><strong>¿Por qué se crea la IS? (continúa)</strong><br />-Se requiere desarrollar el software en una manera que lo haga evolutivo,<br />de forma tal que se pueda agregar funcionalidad adicional sin efectos<br />perjudiciales.<br />-El producto de software debe cumplir con los requerimientos de<br />rendimiento especificados, es decir, debe cumplir algunas de las restricciones<br />relacionadas al rendimiento.<br />-El producto de software tendrá mayor valor si es portable, es decir que<br />puede trabajar bajo diferentes plataformas de software y ambientes<br />(hardware, sistemas operativos, etc.).<br />-El producto de software debe ser utilizable, es decir, el aprendizaje de su<br />uso debe ser los suficientemente sencillo por parte de personas no<br />especialistas.</p>
<p><strong>El software en la actualidad:</strong><br />Las direcciones en las que evoluciona la ingeniería del so-ware<br />hoy en día pueden agruparse de la siguiente manera:<br />-Metodologías ágiles: métodos de desarrollo de so-ware<br />basados en procesos itera7vos e incrementales, donde los<br />requisitos y soluciones evolucionan durante la colaboración.<br />Metodologías como Scrum (1995), Extreme Programming<br />(1999) o DSDM (1995) fueron evolucionando hasta que en<br />Febrero del 2001 se publicó “Manifesto for Agile So-ware<br />Development” para definir la aproximación ahora conocida<br />como metodologías ágiles.</p>
<p><strong>El software en la actualidad (continúa)</strong><br />-Experimentación: es una rama de la ingeniería del software<br />interesada en realizar experimentos sobre software, recolectar<br />datos y deducir leyes y teorías de los mismos.<br />-Desarrollo dirigido por modelos: primero se desarrollan<br />modelos textuales gráficos del software a construir, y<br />posteriormente se construye el software.<br />-Líneas de productos software, en lugar de productos<br />individuales.</p><h3 class="mb-0">FACTORES DE CALIDAD DEL SOFTWARE</h3>
<p>- Concepto de Calidad: Conjunto de propiedades y de características de un producto o servicio, que le confieren aptitud para satisfacer una necesidad explícita o implícita (ISO 8402).</p>
<p>- Calidad del Software: Es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario.</p>
<p>- Factores que determinan la calidad del software.</p>
<p>- Se pueden clasificar en dos grandes grupos (Pressman):</p>
<p>-Medidas Directas: La medida o medición decimos que es directa, cuando disponemos de un instrumento de medida que nos muestra un resultado (generalmente numérico).</p>
<p>-Medidas Indirectas: Cuando hablamos de sistemas informáticos no siempre es posible realizar una medida directa, porque no disponemos del instrumento adecuado que nos permita realizar esa medición</p>
<h3 class="mb-0">MÉTRICAS DEL SOFTWARE</h3>
<p>Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.</p>
<p>Entre las métricas del software tenemos las siguientes:</p>
<p>1. Métricas técnicas: Se centran en las características del software. Aquí medimos la complejidad lógica y el grado de modularidad del sistema. Mide la estructura del sistema, el cómo está hecho.</p>
<p>2. Métricas de calidad: Son todas las métricas de software que definen de una u otra forma la calidad del software; tales como corrección, exactitud, integridad, facilidad de uso, estructuración o modularidad, pruebas, facilidad de mantenimiento, reusabilidad, cohesión del módulo, acoplamiento del módulo, etc.</p>
<p>Estas son los puntos críticos en el diseño, codificación, pruebas y mantenimiento.</p>
<p>Proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.</p>
<p>- Corrección: es el grado en que el software desempeña la función para la que fue creado y se mide en defectos por KLDC.</p>
<p>- Facilidad de Mantenimiento: es la sencillez con que un programa puede corregirse si se encuentra un error, al adaptarse si su entorno cambio o mejorar si el cliente cambia los requisitos y se mide en forma indirecta en TMC (Tiempo Medio de Cambio).</p>
<p>- Integridad: es la habilidad de un sistema para resistir ataques que requiere la definición de amenaza y seguridad y se calcula: integridad = 1 – (amenaza * (1 – seguridad)).Proceso de Ingeniería de software</p>
<p>Por ejemplo, dados los siguientes valores de un paquete de base de datos en dos proyectos, podemos calcular la integridad.</p><img src="img/Screenshot_1.png" width="600" height="150"><p>- Solución:</p>
<p>-Integridad para el proyecto 1:</p>
<p>__Integridad = 1 – 0.7 * (1 – 0) = 0.3</p>
<p>-Integridad para el proyecto 2:</p>
<p>__Integridad = 1 – 0.2 * (1 - 0.8) = 0.96</p>
<p>- Si la amenaza (probabilidad de que un ataque ocurrirá) es 0.25, y la seguridad (posibilidad de repeler un ataque) es 0.95, la integridad del sistema es 0.99 (muy elevada).</p>
<p>- Si por otra parte, la probabilidad de amenaza fuera 0.5 y la posibilidad de repeler un ataque es solo 0.25, la integridad del sistema es 0.63 (inaceptablemente baja).</p>
<p>- Facilidad de uso: Es el intento por cuantificar la sencillez de una aplicación al utilizarla.</p>
<p>3. Métricas de Productividad: Se centran en el rendimiento del proceso de la ingeniería del software. Es decir qué tan productivo va a ser el software que voy a diseñar. Se refiere a las características del software.</p>
<p>4. Métricas de costo: se centra en el costo total del sistema informático.</p>
<p>5. Métricas orientadas al tamaño: Esta nos permite conocer el tiempo en el que se terminará el software y cuántas personas se necesitan para su desarrollo, aquí medimos las variables con las que desarrollamos el software.</p>
<p>Si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño, como la que muestra la figura, que lista cada proyecto de desarrollo de software y las medidas correspondientes de cada proyecto</p><img src="img/Screenshot_2.png" width="600" height="150"><p>- Con los datos registrados durante la elaboración del proyecto podemos generar al final de dicho proyecto el siguiente conjunto de métricas:</p>
<p>-Productividad = KLDC /Esfuerzo</p>
<p>-Calidad = Errores / LDC</p>
<p>-Documentación = Pp.doc./LDC</p>
<p>-Costo = $(000)/LDC</p>
<p>6. Métricas orientadas a la función o puntos de función</p>
<p>- Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcular las líneas de código (LDC), las métricas de función se centran en la funcionalidad o utilidad del programa. Los puntos de función nos indican la medida de la productividad.</p>
<p>- Los puntos de función se obtienen utilizando una función empírica basado en medidas cuantitativas del dominio de información del software y valoraciones subjetivas de la complejidad del software.</p>
<h3 class="mb-0">PROBLEMAS EN EL DESARROLLO DE SOFTWARE</h3>
<p>¿Qué es un proyecto software?</p>
<p>Haciendo uso de la definición de proyecto de la guía del PMBOK, y adaptándola a un proyecto software, podríamos definirlo como: “Un proyecto software es un esfuerzo temporal que se lleva a cabo para crear un producto software, servicio TI o resultado único.”</p>
<p>¿Pero que es el software?</p>
<p>Según la definición del IEEE, "software es la suma total de los programas de ordenador, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo", y "un producto de software es un producto diseñado para un usuario".</p>
<p>El software puede dividirse en dos grandes categorías:</p>
<p>-Software de aplicaciones: se usan para proveer servicios a clientes y ejecutar negocios de forma más eficiente. El software de aplicaciones puede ser un sistema pequeño o uno grande integrado. Como ejemplos de este tipo de software estarían un sistema de cuentas, un sistema de planificación de recursos...</p>
<p>-Software de sistemas: El software de sistemas se usa para operar y mantener un sistema informático. Permite a los usuarios usar los recursos del ordenador directamente y a través de otro software. Algunos ejemplos de este tipo de software son los sistemas operativos, compiladores y otras utilidades del sistema.</p>
<p>Los proyectos software tienen características específicas que los hacen diferentes de otros proyectos de ingeniería.</p>
<p>La Ingeniería del Software es la rama de la ingeniería que crea y mantiene las aplicaciones de software usando tecnologías y prácticas de las ciencias de la computación, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros campos.</p>
<p>¿Por qué el software es diferente a cualquier otro proceso de fabricación? Podríamos identificar los siguientes motivos:</p>
<p>-El software se desarrolla, no se fabrica en el sentido clásico de la palabra. Ambas actividades se dirigen a la construcción de un "producto", pero los métodos son diferentes. Los costes del software se encuentran en la ingeniería, esto implica que los proyectos no se pueden gestionar como si lo fueran de fabricación.</p>
<p>-La juventud de la ingeniería del software con respecto a otras ingenierías, la mayoría del software se construye a medida, en vez de ensamblar componentes previamente creados. Aunque ya se están dando importantes pasos en esta dirección, que facilitaría en gran medida el desarrollo de aplicaciones informáticas.</p>
<p>-En el software, el recurso principal son las personas. No es siempre posible acelerar la construcción de software añadiendo personas porque la construcción de software requiere un esfuerzo en equipo. El equipo tiene que trabajar de forma coordinada y compartir un objetivo de proyecto común. Se necesita comunicación efectiva dentro del equipo.</p>
<p>-El software no se estropea, pero se deteriora. Durante su vida, el software sufre cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable que se introduzcan nuevos defectos, lo que hace que el software se vaya deteriorando debido a estos cambios.</p>
<h3 class="mb-0">VISIÓN GENERAL DEL PROCESO DE INGENIERÍA DEL SOFTWARE</h3>
<div class="subheading mb-3">DESARROLLO</div>
<p>¿Cómo construir el sistema?</p>
<p>* Se diseñan las estructuras de los datos y los programas.</p>
<p>-Como se caracterizan las interfaces.</p>
<p>-Como realizar el paso del diseño al lenguaje de programación.</p>
<p>-Como ha de realizarse la prueba.</p>
<p>* Se escriben y documentan los programas.</p>
<p>* Y se prueba el software construido.</p>
<div class="subheading mb-3">MANTENIMIENTO</div>
<p>* Comienza una vez construido el sistema.</p>
<p>* Se centra en el cambio.</p>
<p>* El software es sometido a reparaciones y modificaciones cada vez que se detecta un fallo o se necesita cubrir una nueva necesidad de los usuarios.</p>
<p>* En esta fase recae el mayor porcentaje del costo de un sistema.</p>
<p>* Un buen sistema no es sólo un conjunto de programas que funcionan bien => Debe ser fácil de mantener</p>
<p>Tipos de mantenimiento.</p>
<p>-Correctivo. El programa no funciona correctamente, hay que modificarlo.</p>
<p>-Perfectivo. Se modifica el programa para obtener más eficiencia o nuevas funcionalidades no especificadas en la definición del sistema.</p>
<p>-Adaptativo. Adaptar el programa a los cambios en su entorno (cambio de SO, de CPU, de legislación, …)</p>
<p>-Preventivo. El software se deteriora con los cambios, este mantenimiento hace cambios para que los programas se puedan corregir, adaptar y mejorar más rápidamente -> Reingeniería del SW.</p><img src="img/Screenshot_3.png" width="761" height="346"><h3 class="mb-0">ESPONSABILIDAD ÉTICA Y PROFESIONAL EN INGENIERÍA DEL SOFTWARE</h3>
<p>La IS se realiza dentro de un marco social y legal que limita la libertad de la gente que trabaja en dicha área.</p>
<p>Los ingenieros de software:</p>
<p>- Deben aceptar que su labor implica responsabilidades mayores que la simple aplicación de habilidades técnicas.</p>
<p>- Deben comportarse de forma ética y moralmente responsable para ser respetado como un ingeniero profesional.</p>
<p>Existen áreas donde los estándares de comportamiento aceptable no están acotados por las leyes, sino por la responsabilidad profesional, algunas de estas son:</p>
<p>- Confidencialidad. Respetar la confidencialidad de sus empleadores o clientes, independientemente de que se haya firmado un acuerdo formal de confidencialidad.</p>
<p>- Competencia. No debe falsificar su nivel de competencia, ni aceptar conscientemente trabajos que están fuera de su capacidad.</p>
<p>- Derechos de propiedad intelectual. Debe ser consciente de las leyes locales que gobiernan el uso de la propiedad intelectual, como las patentes el el copyright. Debe asegurarse de que la propiedad intelectual de los empleadores y clientes está protegida.</p>
<p>- Uso inapropiado de las computadoras. No debe emplear sus habilidades técnicas para utilizar de forma inapropiada las computadoras de otras personas. Desde los relativamente triviales (utilizar juegos en las maquina de un empleado, por ejemplo) hasta los extremadamente serios (difusión de virus).</p>
<h3 class="mb-0">CÓDIGO DE ÉTICA (ACM/IEEE)</h3>
<p>Los ingenieros de software deberán comprometerse consigo mismo en convertir el análisis, especificación, diseño, desarrollo, prueba y mantenimiento de software en una profesión respetable y beneficiosa.</p>
<p>De acuerdo con su compromiso con la salud, seguridad y bienestar del público, los ingenieros de software deberán apegarse a ocho principios.</p>
<div class="subheading mb-3">PRINCIPIOS DEL CÓDIGO</div>
<p>Público.- Los ingenieros de software deberán actuar consistentemente con el interés público.</p>
<p>Cliente y Empleador.- Los ingenieros de software deberán actuar de una forma determinada que esté en los mejores intereses de su cliente y empleador consistente con el interés público.</p>
<p>Producto.- Los ingenieros de software deberán asegurar que sus productos y modificaciones relacionadas logren el más alto estándar profesional posible.</p>
<p>Juicio.- Los ingenieros de software deberán mantener integridad e independencia al emitir su juicio profesional.</p>
<p>Gerencia.- Los gerentes y lideres de ingeniería de software deberán suscribirse y promocionar un enfoque ético para la gerencia de desarrollo y mantenimiento del software.</p>
<p>Profesión.- Los ingenieros de software deberán fomentar la integridad y reputación de la profesión consistente con el interés público.</p>
<p>Colegas.- Los ingenieros de software deberán ser justos y comprensivos con sus colegas.</p>
<p>Interés Propio. Los ingenieros de software deberán participar en el aprendizaje de por vida del ejercicio de su profesión y deberán promover un enfoque ético para el ejercicio de la misma.</p><div class="subheading mb-3"> </div>
<div class="subheading mb-3">CONCEPTO</div>
<p>Un sistema de información es un conjunto de elementos interrelacionados con el propósito de prestar atención a las demandas de información de una organización, para elevar el nivel de conocimientos que permitan un mejor apoyo a la toma de decisiones y desarrollo de acciones (Peña, 2006).</p>
<p>Conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. Teniendo muy en cuenta el equipo computacional necesario para que el sistema de información pueda operar y el recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema.</p>
<p>Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida de información (Peralta, 2008).</p>
<p>-Entrada de Información: Es el proceso mediante el cual el Sistema de Información toma los datos que requiere para procesar la información.</p>
<p>-Almacenamiento de información: El almacenamiento es una de las actividades o capacidades más importantes que tiene una computadora, ya que a través de esta propiedad el sistema puede recordar la información guardada en la sección o proceso anterior.</p>
<p>-Procesamiento de Información: Es la capacidad del Sistema de Información para efectuar cálculos de acuerdo con una secuencia de operaciones preestablecida. </p>
<p>-Salida de Información: La salida es la capacidad de un Sistema de Información para sacar la información procesada o bien datos de entrada al exterior. </p>
<p>Otro autor define que: Un sistema de información es el sistema de personas, registros de datos y actividades que procesa los datos y la información en cierta organización, incluyendo manuales de procesos o procesos automatizados. (s/a, 2008).</p>
<h3 class="mb-0">TIPOS DE SISTEMAS DE INFORMACIÓN</h3>
<p>Los sistemas de información, de manera general se pueden clasificar de tres formas según sus propósitos generales, en este sentido Peralta (2008) clasifica los sistemas de información en tres tipos fundamentales: (1) Sistemas transaccionales; (2) Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisión de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistema de Información para Ejecutivos y (3) Sistemas estratégicos.</p>
<p>• Sistemas transaccionales: Son Sistemas de Información que logran la automatización de procesos operativos dentro de una organización ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, entradas, salidas, etc.</p>
<p>• Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisión de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistema de Información para Ejecutivos: Son Sistemas de Información que apoyan el proceso de toma de decisiones.</p>
<p>• Sistemas Estratégicos: Son sistemas de información desarrollado en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información.</p>
<p>En dependencia del enfoque (tres en total), según reporta Peña (2006), los sistemas de información se pueden agrupar en una cierta clasificación, que brinda una idea esencial de su estructura y funcionamiento.</p>
<p>De acuerdo al elemento principal de proceso de la información, los sistemas de información pueden ser de tres tipos (Manual, Mecanizadas y Bath):</p>
<p>• Manuales: cuando el hombre auxiliado por cierto equipo (máquinas de escribir, sumadoras, archivos, etc.) realiza las principales funciones de recopilación, registro, almacenamiento, cálculo y generación de información.</p>
<p>• Mecanizadas: cuando cierta maquinaria realiza las principales funciones de procesamiento. Para los sistemas mecanizados que hacen uso de un computador, de acuerdo al tipo de interacción Hombre-Máquina, los sistemas de información pueden ser de dos tipos (Batch y en Línea]:</p>
<p>-Batch: el usuario proporciona los datos necesarios para la ejecución de un proceso y espera a que el computador termine la tarea para recibir los resultados;</p>
<p>-En Línea: existe un diálogo directo entre el usuario y el computador durante la ejecución de un proceso.</p>
<p>En cuanto a la organización física de los principales recursos de procesamiento de datos, los sistemas de información pueden ser de tipo:</p>
<p>• Procesos centralizados: los recursos se encuentran ubicados en un área física determinada, por lo que su acceso se realiza en las misma instalación o desde lugares retirados, mediante líneas de comunicación de datos (telefónicas, microondas, satélite, etc.).</p>
<p>• Proceso distribuido: los recursos se encuentran diseminados en diversos lugares de una zona territorial (ciudad, país, continente, etc.), por lo que el procesamiento se realiza en el propio lugar donde se originan los datos, existiendo la posibilidad de compartir información entre las diversas instalaciones, mediante la información de una “Red de Comunicación”.</p>
<h3 class="mb-0">ELEMENTOS DE UN SISTEMA DE INFORMACIÓN</h3>
<p>Los sistemas de información, según Peña (2006), tienen 5 elementos importantes, estos son:</p>
<p>• Financieros</p>
<p>• Administrativos</p>
<p>• Humanos</p>
<p>• Materiales</p>
<p>• Tecnológicos</p>
<p>Sin embargo otro autor (s/a, 2008a) menciona que un sistema de información consiste en 3 elementos: humano, tecnología y organización. En teoría de sistemas, un sistema de información es un sistema automatizado o manual que involucra personas, máquinas y/o métodos organizados de recolección, procesos, transmisión, clasificación y divulgación de datos.</p>
<p>Otro autor desconocido (s/a, 2008b) plantea que un sistema de información está compuesto por 6 elementos claramente identificables, tal y como se muestran en la siguiente figura:</p><img src="img/Screenshot_4.png" width="888" height="382"><p>- Base de Datos: Es donde se almacena toda la información que se requiere para la toma de decisiones. La información se organiza en registros específicos e identificables;</p>
<p>- Transacciones: Corresponde a todos los elementos de interfaz que permiten al usuario: consultar, agregar, modificar o eliminar un registro específico de Información;</p>
<p>- Informes: Corresponden a todos los elementos de interfaz mediante los cuales el usuario puede obtener uno o más registros y/o información de tipo estadístico (contar, sumar) de acuerdo a criterios de búsqueda y selección definidos.</p>
<p>Los restantes elementos de un sistema de información son:</p>
<p>- Procesos: Corresponden a todos aquellos elementos que, de acuerdo a una lógica predefinida, obtienen información de la base de datos y generan nuevos registros de información. Los procesos sólo son controlados por el usuario (de ahi que aparezca en línea de puntos);</p>
<p>- Usuario: Identifica a todas las personas que interactúan con el sistema, esto incluye desde el máximo nivel ejecutivo que recibe los informes de estadísticas procesadas, hasta el usuario operativo que se encarga de recolectar e ingresar la información al sistema y</p>
<p>- Procedimientos Administrativos: Corresponde al conjunto de reglas y políticas de la organización, que rigen el comportamiento de los usuarios frente al sistema. Particularmente, debieran asegurar que nunca, bajo ninguna circunstancia un usuario tenga acceso directo a la Base de Datos.</p>
</div>
</div>
</div>
</section>
<hr class="m-0" />
<section id="skills" class="resume-section p-3 p-lg-5 d-flex align-items-center">
<div class="w-100">
<h2 class="mb-5">PROCESO DEL SOFTWARE</h2>
<h3 class="mb-0">EL PROCESO DEL SOFTWARE</h3>
<p>- Conjunto de actividades necesarias para transformar las ideas iniciales del usuario, que desea automatizar un determinado trabajo, en software.</p>
<p>- Conjunto ordenado de actividades; una serie de pasos que involucran tareas, restricciones y recursos que producen una determinada salida esperada.</p>
<p>- Marco de trabajo de las tareas que se requieren para construir software de alta calidad.</p>
<p>- Un conjunto estructurado de actividades necesarias para desarrollar un sistema de software.</p>
<p>Muchos de los procesos de software son diferentes, pero todos implican:</p>
<p>-Especificación;</p>
<p>-Diseño e implementación;</p>
<p>-Validación;</p>
<p>-Evolución.</p>
<h3 class="mb-0">CARACTERÍSTICAS DEL PROCESO DE SW</h3>
<p>Cualquier proceso tiene las siguientes características:</p>
<p>- El proceso establece todas las actividades principales.</p>
<p>- El proceso utiliza recursos, está sujeto a una serie de restricciones y genera productos intermedios y finales</p>
<p>- El proceso puede estar compuesto de subprocesos que se encadenan de alguna manera. Puede definirse como una jerarquía de procesos organizada de modo que cada subproceso tenga su propio modelo de proceso</p>
<p>- Cada actividad del proceso tiene criterios de entrada y de salida, de modo que se conoce cuándo comienza y cuándo termina una actividad.</p>
<p>- Las actividades se organizan en secuencia de modo que resulta claro cuando una actividad se realiza en orden relativo a otras actividades.</p>
<p>- Todo proceso tiene un conjunto de principios orientadores que explican las metas de cada actividad.</p>
<p>- Las restricciones o controles pueden aplicarse a una actividad, recurso o producto</p>
<h3 class="mb-0">OTRAS CARACTERÍSTICAS DEL PROCESO DE SW</h3>
<p>- Comprensión</p>
<p>-Está definido y es comprensible</p>
<p>- Visibilidad</p>
<p>-Se visualizan los progresos externamente</p>
<p>*Soporte</p>
<p>-Está soportado por herramientas CASE</p>
<p>*Aceptación</p>
<p>-Es aceptable para todos los actores implicados</p>
<p>*Confianza</p>
<p>-Los errores del proceso se detectan antes de que se produzcan errores en el producto</p>
<p>*Robustez</p>
<p>-Se puede continuar a pesar de problemas inesperados</p>
<p>*Capacidad de mantenimiento</p>
<p>-Puede ajustarse a las necesidades de cambio de la organización</p>
<p>* Rapidez</p>
<p>-Con qué “velocidad” se producen los sistemas</p>
<p>*Adaptación</p>
<p>-Capacidad que tiene un usuario del mismo de adaptarlo a sus necesidades</p>
<h3 class="mb-0">IMPORTANCIA DEL PROCESO DE SW</h3>
<p>Un proceso software debe especificar:</p>
<p>* La secuencia de actividades a realizar por el equipo de desarrollo</p>
<p>-Flujo de actividades</p>
<p>* Los productos que deben crearse</p>
<p>-Resultados del trabajo (modelos, documentos, datos informes...)</p>
<p>- Qué y cuándo</p>
<p>*La asignación de tareas a cada miembro del equipo y al equipo como un todo</p>
<p>-Los criterios para controlar el proceso</p>
<p>- Se establece el control de gestión de los proyectos software</p>
<p>- Establecimiento de hitos</p>
<p>Las posibles heurísticas</p>
<p>- Facilita la gestión del proyecto</p>
<p>- Establece una división del trabajo</p>
<p>* Facilita la comunicación de los miembros del equipo</p>
<p>-Permite la reasignación y la reutilización de personal especializado</p>
<p>-Transferencia entre proyectos</p>
<p>* Mejora la productividad y el desarrollo</p>
<p>-El desarrollo es reproducible</p>
<p>* Establece el contexto en el que se aplican los métodos técnicos</p>
<p>* Gestiona el cambio adecuadamente</p>
<p>* Asegura la calidad</p>
<h2 class="mb-5">ESTÁNDARES RELACIONADOS CON EL PROCESO DE SW</h2>
<h3 class="mb-0">ESTÁNDAR ISO/IEC/IEEE 12207:2017</h3>
<p>- El estándar ISO/IEC/IEEE 12207:2017 [ISO/IEC/IEEE, 2017] relativo a los procesos del ciclo de vida del software</p>
<p>- Se aplica a la adquisición de sistemas de software, productos y servicios, al suministro, desarrollo, operación, mantenimiento y eliminación de productos de software o componentes de software de cualquier sistema, ya sea que se realice interna o externamente a una organización.</p>
<p>- Se incluyen aquellos aspectos de la definición del sistema necesarios para proporcionar el contexto de los productos y servicios de software.</p>
<p>- También proporciona procesos que pueden emplearse para definir, controlar y mejorar los procesos del ciclo de vida del software dentro de una organización o de un proyecto.</p>
<p>- Esta norma no fomenta o especifica ningún modelo concreto de ciclo de vida, gestión del software o método de ingeniería, ni prescribe cómo realizar ninguna de las actividades.</p><img src="img/Screenshot_5.png" width="586" height="748"><h2 class="mb-5">CICLO DE VIDA DEL SW</h2>
<p>* Cuando un proceso implica la construcción de algún producto, suele referirse al proceso como un ciclo de vida</p>
<p>-El proceso de desarrollo de software suele denominarse ciclo de vida del software</p>
<p>* La evolución del software representa el ciclo de ac7vidades involucradas en el desarrollo, uso y mantenimiento de sistemas software [Scacchi, 1987].</p>
<p>* Los proyectos software se desarrollan en una serie de fases.</p>
<p>-Van desde la concepción del software y su desarrollo inicial hasta su puesta en funcionamiento y posterior retirada por otra nueva generación de software</p>
<p>Estas fases pueden ser:</p>
<p>-Temporales.- Forman una secuencia en el tiempo</p>
<p>-Lógicas.- Cuando representan pasos o etapas que no constituyen una secuencia temporal</p>
<p>Se puede definir ciclo de vida del software como:</p>
<p>-Las distintas fases por las que pasa el software desde que nace una necesidad de mecanizar un proceso hasta que deja de utilizarse el software que sirvió para ese objetivo, pasando por las fases de desarrollo y explotación [Frakes et al., 1991]</p>
<p>-El período de tiempo que comienza cuando se concibe un producto software y finaliza cuando el producto pierde su utilidad. El ciclo de vida del software incluye las siguientes fases: fase de requisitos, fase de diseño, fase de realización, fase de pruebas, fase de instalación y aceptación, fase de operación y mantenimiento y, algunas veces, fase de retirada [AECC, 1986]</p>
<p>-Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de requisitos hasta la finalización de su uso [ISO/IEC, 2008]</p>
<p>-Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software IEEE Std 1074-1997 Standard for Developing Software Life Cycle Processes [IEEE, 1999b]</p>
<p>-El ciclo de vida del software consiste de las siguientes fases: análisis de requisitos, diseño, implementación, prueba y mantenimiento. El proceso de desarrollo tiende a una iteración de estas fases más que a un proceso lineal [CERN, 1996].</p>
<p>-El ciclo de vida del software usa el modelo de que un elemento software tiene vida. Un elemento software tiene una fase de concepción (una idea en una mente de un usuario potencial), después de una fase de gestación (la fase de desarrollo del software) hacia una fase de madurez (la revisión y corrección de errores, o fase de mantenimiento), y finalmente la fase de retirada [Leaney, 2004]</p>
<p>Se puede definir ciclo de desarrollo del software como:</p>
<p>-El período de tiempo que comienza con la decisión de desarrollar un producto software y finaliza cuando se ha entregado éste. Este ciclo incluye, en general, una fase de requisitos, una fase de diseño, una fase de implantación, una fase de pruebas, y a veces, una fase de instalación y aceptación [AECC, 1986]</p>
<h3 class="mb-0">ÁMBITO GENERAL DEL CICLO DE VIDA DEL SW</h3>
<p>Desde un punto de vista general puede considerarse que el ciclo de vida de un software tiene tres etapas claramente diferenciadas:</p>
<p>- Planificación: idearemos un planeamiento detallado que guíe la gestión del proyecto, temporal y económicamente.</p>
<p>- Implementación: acordaremos el conjunto de actividades que componen la realización del producto.</p>
<p>- Puesta en producción: nuestro proyecto entra en la etapa de definición, allí donde se lo presentamos al cliente o usuario final, sabiendo que funciona correctamente y responde a los requerimientos solicitados en su momento. Esta etapa es muy importante no sólo por representar la aceptación o no del proyecto por parte del cliente o usuario final sino por las múltiples dificultades que suele presentar en la práctica, alargándose excesivamente y provocando costos no previstos.</p>
<h3 class="mb-0">OBJETIVOS DE CADA ETAPA</h3>
<p>En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie de objetivos, tareas y actividades que lo caracterizan.</p>
<p>- Expresión de necesidades: esta etapa tiene como objetivo el armado de un documento en el cual se reflejan los requerimientos y funcionalidades que ofrecerá al usuario el sistema a implementar (qué, y no cómo, se va a implementar).</p>
<p>- Especificaciones: formalizamos los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta etapa.</p>
<p>- Análisis: determinamos los elementos que intervienen en el sistema a desarrollar, su estructura, relaciones, evolución temporal, funcionalidades, tendremos una descripción clara de qué producto vamos a construir, qué funcionalidades aportará y qué comportamiento tendrá.</p>
<p>- Diseño: ya sabemos qué hacer, ahora tenemos que determinar cómo debemos hacerlo (¿cómo debe ser construido el sistema en cuestión?; definimos en detalle entidades y relaciones de las bases de datos, seleccionamos el lenguaje que vamos a utilizar, el Sistema Gestor de Bases de Datos, etc.).</p>
<p>- Implementación: empezamos a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación o para un determinado sistema gestor de bases de datos. En muchos proyectos se pasa directamente a esta etapa; son proyectos muy arriesgados que adoptan un modelo de ciclo de vida de code & fix (codificar y corregir) donde se eliminan las etapas de especificaciones, análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto.</p>
<p>- Debugging: el objetivo de esta etapa es garantizar que nuestro programa no contiene errores de diseño o codificación. En esta etapa no deseamos saber si nuestro programa realiza lo que solicitó el usuario, esa tarea le corresponde a la etapa de implementación. En ésta deseamos encontrar la mayor cantidad de errores. Todos los programas contienen errores: encontrarlos es cuestión de tiempo. Lo ideal es encontrar la mayoría, si no todos, en esta etapa. También se pueden agregar testeos de performance.</p>
<p>- Validación: esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requerimientos expresados inicialmente por el cliente y que han dado lugar al presente proyecto. En muchos proyectos las etapas de validación y debugging se realizan en paralelo por la estrecha relación que llevan. Sin embargo, tenemos que evitar la confusión: podemos realizarlos en paralelo, pero no como una única etapa.</p>
<p>- Evolución: en la mayoría de los proyectos se considera esta etapa como Mantenimiento y evolución, y se le asigna, no sólo el agregado de nuevas funcionalidades (evolución); sino la corrección de errores que surgen (mantenimiento). En la práctica esta denominación no es del todo errónea, ya que es posible que aun luego de una etapa de debugging y validación exhaustiva, se filtren errores.</p>
<h3 class="mb-0">¿MODELO DE PROCESO DE SW?</h3>
<p>Hay varios modelos de procesos definidos en la bibliografía de Ingeniería del Software</p>
<p>Cada modelo de proceso representa un proceso desde una perspectiva particular, por lo que sólo ofrece una información parcial sobre dicho proceso.</p><h3 class="mb-0">¿MODELO DE PROCESO DE SW?</h3>
<p>Hay varios modelos de procesos definidos en la bibliografía de Ingeniería del Software</p>
<p>Cada modelo de proceso representa un proceso desde una perspectiva particular, por lo que sólo ofrece una información parcial sobre dicho proceso.</p>
<h3 class="mb-0">RAZONES PARA MODELAR UN PROCESO DE SW</h3>
<p>* Cuando se pone por escrito una descripción de un proceso, se da forma a una comprensión común de las actividades, recursos y restricciones relacionados con el desarrollo del software.</p>
<p>* Ayuda al equipo de desarrollo a encontrar las inconsistencias, las redundancias y las omisiones en el proceso y en las partes que lo constituyen.</p>
<p>* El modelo debe reflejar las metas del desarrollo. A medida que se construye el modelo el equipo de desarrollo evalúa las actividades candidatas por su adecuación para alcanzar dichas metas.</p>
<p>* Ayuda al equipo de desarrollo a comprender dónde debe adaptarse el proceso</p>
<p>* Los modelos de proceso de desarrollo de software incluyen los requisitos del sistema como entrada y un producto entregado como salida</p>
<h3 class="mb-0">MODELO GENERAL DE PROCESO EN INGENIERÍA</h3>
<p>* Especificación</p>
<p>Formulación de los requisitos y restricciones del sistema</p>
<p>* Diseño</p>
<p>Elaboración de un documento con el modelo del sistema</p>
<p>* Fabricación</p>
<p>Construcción del sistema</p>
<p>* Prueba</p>
<p>Comprobación de que el sistema cumple las especificaciones requeridas</p>
<p>* Instalación</p>
<p>Entrega del sistema al cliente y garantía de que es operativo</p>
<p>* Mantenimiento</p>
<p>Reparación de los fallos que aparecen en el sistema</p>
<p> </p>
<p>En el proceso de construcción de sistemas informáticos se pueden distinguir tres fases genéricas:</p>
<p>* Fase de definición</p>
<p>Se identifican los requisitos claves del sistema y del software</p>
<p>Se desarrolla</p>
<p>-Un Análisis de Sistemas</p>
<p>--Se define el papel de cada elemento en el sistema automatizado de información, incluyendo el que jugará el software</p>
<p>-Un Análisis de Requisitos</p>
<p>--Se especifican todos los requisitos de usuario que el sistema tiene que satisfacer</p>
<p>--Esta fase está orientada al QUÉ</p>
<p>---Qué información ha de ser procesada, qué función y rendimiento se desea, qué interfaces han de establecerse, qué ligaduras de diseño existen y qué criterios de validación se necesitan para definir un sistema correcto</p>
<p>Existe un paso complementario: la planificación del proyecto software:</p>
<p>-Se asignan los recursos</p>
<p>-Se estiman los costos</p>
<p>-Se planifican las tareas y el trabajo</p>
<p>* Fase de desarrollo</p>
<p>Fase orientada al CÓMO</p>
<p>El primer paso de esta fase corresponde al Diseño del Software</p>
<p>-Se trasladan los requisitos del software a un conjunto de representaciones que describen la estructura de datos, arquitectura del software y procedimientos algorítmicos que permiten la construcción física de dicho software.</p>
<p>Los otros dos pasos de la fase de desarrollo corresponden a la Codificación y a la Prueba del Software</p>
<p>* Fase de mantenimiento</p>
<p>-Mantenimiento correctivo</p>
<p>--Corrección de errores</p>
<p>-Mantenimiento adaptativo</p>
<p>--Adaptaciones requeridas por la evolución del entorno del software</p>
<p>-Mantenimiento perfectivo</p>
<p>--Las modificaciones debidas a los cambios de requisitos del usuario para mejorar el sistema</p>
<p>-Mantenimiento preventivo</p>
<p>--Mejora de las características internas del producto para hacer más mantenible</p><h2 class="mb-5">MODELO DE PROCESOS DE SOFTWARE</h2>
<div class="subheading mb-3">EL MODELO DE CASCADA</div>
<p>Modelo de Plan-impulsado. Fases separadas y distintas de especificación y desarrollo.</p>
<div class="subheading mb-3">EL DESARROLLO INCREMENTAL</div>
<p>Especificación, desarrollo y validación se intercalan. Puede ser el plan impulsado o ágil.</p>
<p> </p>
<p>Ingeniería de software orientado a reutilización</p>
<p>-El sistema se ensambla a partir de componentes existentes. Puede ser el plan impulsado o ágil.</p>
<p>En la práctica, la mayoría de los grandes sistemas se desarrollan mediante un proceso que incorpora elementos de todos estos modelos.</p>
<h3 class="mb-0">MODELO CASCADA</h3><img src="img/cascada.png" width="577" height="305"><p>Las fases están identificadas por separado:</p>
<p>• El análisis y definición de requerimientos</p>
<p>• Diseño del sistema y software.</p>
<p>• Pruebas de implementación de unidades</p>
<p>• Integración y pruebas del sistema</p>
<p>• Operación y mantenimiento</p>
<p>El principal inconveniente del modelo de la cascada es la dificultad de acomodar el cambio después de que está en marcha el proceso. En principio, una fase tiene que ser completada antes de pasar a la siguiente fase.</p>
<div class="subheading mb-3">PROBLEMAS DEL MODELO DE CASCADA:</div>
<p>• Inflexible división del proyecto en fases distintas hace que sea difícil responder a las necesidades cambiantes de los clientes.</p>
<p>• Por lo tanto, este modelo sólo es apropiado cuando los requisitos son bien entendidos y los cambios serán bastante limitados durante el proceso de diseño.</p>
<p>• Pocos sistemas tienen requisitos estables.</p>
<p>• El modelo de cascada se utiliza sobre todo para los grandes proyectos de ingeniería de sistemas en que un sistema se desarrolla en varios lugares</p><h3 class="mb-0">DESARROLLO INCREMENTAL</h3><img src="img/incremental.png" width="476" height="272"><div class="subheading mb-3">BENEFICIOS:</div>
<p>• El costo de atender las necesidades cambiantes de los clientes se reduce.</p>
<p>--La cantidad de análisis y la documentación que tiene que ser hecho de nuevo es mucho menor que la que se requiere con el modelo de cascada.</p>
<p>• Es más fácil obtener retroalimentación de los clientes en el trabajo de desarrollo que se ha hecho.</p>
<p>--Los clientes pueden hacer comentarios sobre las manifestaciones del software y ver cuánto se ha implementado.</p>
<p>• Más rápida entrega y despliegue de software de utilidad para el cliente es posible.</p>
<p>--Los clientes pueden usar y obtener valor a partir del software anterior que es posible con un proceso de cascada.</p>
<div class="subheading mb-3">PROBLEMAS:</div>
<p>• El proceso no es visible.</p>
<p>--Los gerentes necesitan entregas regulares para medir el progreso. Si se desarrollan rápidamente los sistemas, no es rentable para producir documentos que reflejen todas las versiones del sistema.</p>
<p>• Estructura del sistema tiende a degradarse a medida que se añaden nuevos incrementos.</p>
<p>--A menos tiempo y dinero que se gasta en la refactorización para mejorar el software, cambio regular tiende a corromper su estructura. La incorporación de nuevos cambios de software se vuelve cada vez más difícil y costoso.</p>
<h3 class="mb-0">ESPIRAL</h3><img src="img/espiral.png" width="700" height="400"><div class="subheading mb-3">DEFINICIÓN:</div>
<p>• Es un modelo de ciclo de vida desarrollado por Barry Boehm en 1988.</p>
<p>• Las actividades de este modelo son una espiral, cada bucle es una actividad.</p>
<p>• Las actividades no están fijadas a prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.</p>
<p>• En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos.</p>
<p>1. Determinar qué quieres lograr.</p>
<p>2. Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.</p>
<p>3. Seguir la alternativa seleccionada en el paso 2.</p>
<p>4. Establecer qué tienes terminado.</p>
<div class="subheading mb-3">PRINCIPIOS BÁSICOS:</div>
<p>• Decidir qué problema se quiere resolver antes de viajar a resolverlo.</p>
<p>• Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.</p>
<p>• Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.</p>
<p>• No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y</p>
<p>• Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.</p>
<p>El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo.</p>
<div class="subheading mb-3">ACTIVIDADES PRINCIPALES:</div>
<p>PRIMER PASO. Identificación de:</p>
<p>• Los objetivos de la parte del producto que está siendo elaborada (rendimientos, funcionalidad, adaptación al cambio, etc.).</p>
<p>• Las alternativas principales de la implementación de esta porción del producto (usar el diseño A, usar el diseño B, reutilizar el módulo X de la aplicación Z, comprar a un proveedor externo, etc.).</p>
<p>• Las restricciones impuestas para cada alternativa (costes, planificaciones, interfaces, etc.).</p>
<p>SEGUNDO PASO</p>
<p>• Evaluar las diferentes alternativas que se plantean teniendo en cuenta los objetivos a conseguir y las restricciones impuestas. Frecuentemente, este paso identifica las áreas de incertidumbre del proyecto con sus correspondientes riesgos.</p>
<p>• Si existen riesgos, lo siguiente es la formulación de una estrategia efectiva en coste (utilizando prototipos, simulación, bancos de prueba, cuestionario para los usuarios, modelización analítica o combinaciones de éstas y otras técnicas de resolución de riesgos) para resolver dichos riesgos.</p>
<p>TERCER PASO. Consiste en desarrollar, verificar y validar (probar):</p>
<p>• Tareas de la actividad propia y de prueba.</p>
<p>• Análisis de alternativas e identificación resolución de riesgos.</p>
<p>• Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc.</p>
<p>CUARTO PASO. Revisar todo lo hecho, evaluándolo, y con ello decidir si se continúa con las fases siguientes y planificar la próxima actividad.</p>
<div class="subheading mb-3">CARACTERÍSTICAS:</div>
<p>• En cada giro se construye un nuevo modelo del sistema completo.</p>
<p>• Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo).</p>
<p>• Mejor modelo para el desarrollo de grandes sistemas.</p>
<p>• El análisis de riesgo requiere la participación de personal altamente calificado.</p>
<div class="subheading mb-3">VENTAJAS:</div>
<p>• El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.</p>
<p>• Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.</p>
<p>• El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.</p>
<p>• El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.</p>
<p>• En la utilización de grandes sistemas a doblado la productividad.</p>
<h3 class="mb-0">DESARROLLO RÁPIDO DE APLICACIONES (DRA)</h3><img src="img/DRA.jpg" width="490" height="567"><div class="subheading mb-3">DEFINICIÓN:</div>
<p>• Es un modelo de proceso del ciclo de vida clásico que enfatiza un ciclo de vida de desarrollo extremadamente corto.</p>
<p>• El modelo DRA es una adaptación a alta velocidad del ciclo de vida clásico en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de períodos cortos de tiempo.</p>
<p>• Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:</p>
<p>--Modelado de gestión: El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesa?</p>
<p>--Modelado de datos: El flujo de información definido como parte de la fase de modelado de gestión refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características de cada uno de los objetos y relaciones entre estos objetos.</p>
<p>--Modelado de procesos: Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.</p>
<p>--Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.</p>
<p>--Prueba y entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.</p>
<p>--Prueba y entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.</p>
<div class="subheading mb-3">LIMITACIONES:</div>
<p>Las limitaciones de tiempo impuestas en un proyecto DRA demandan ámbito en escalas.</p>
<p>• Si una aplicación de gestión puede modularse de forma que permita completarse cada una de las funciones principales en menos de tres meses, es el candidato del DRA.</p>
<p>• Cada una de las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un solo conjunto.</p>
<div class="subheading mb-3">PROBLEMAS:</div>
<p>• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.</p>
<p>• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasarán.</p>
<p>• No todos los tipos de aplicaciones son apropiados para DRA.</p>
<p>• Si un sistema no puede modularizarse adecuadamente, la construcción de los componentes necesarios para DRA será problemático.</p>
<p>• Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistemas, el modelo DRA puede que no funcione.</p>
<p>• DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperatividad con programas de computadoras ya existentes.</p>
<p>• DRA enfatiza el desarrollo de componentes de programas reutilizables.</p>
<h3 class="mb-0">ORIENTADOS A LA REUTILIZACIÓN</h3><img src="img/orientados.png" width="700" height="300"><div class="subheading mb-3">DEFINICIÓN:</div>
<p>• Esta aproximación se basa en la existencia de un número significativo de elementos reutilizables. El proceso de desarrollo, se centra en la integración de estos elementos en un sistema, en lugar de desarrollarlo desde cero.</p>
<p>• Incorpora muchas características del modelo en espiral. Es evolutivo por naturaleza.</p>
<p>• El proceso tiende a estructurarse en dos subprocesos distintos y separados:</p>
<p>--El desarrollo para reutilización: construcción de elementos reutilizables dentro de un dominio concreto.</p>
<p>El desarrollo con reutilización: construcción de aplicaciones utilizando elementos reutilizables.</p>
<p>• Etapas del proceso</p>
<p>--Análisis de los componentes;</p>
<p>--Requisitos de modificación;</p>
<p>--Configuración del sistema con la reutilización;</p>
<p>--Desarrollo e integración.</p>
<p>• La reutilización es ahora el enfoque estándar para la construcción de muchos tipos de sistemas de negocio.</p>
<h3 class="mb-0">ORIENTADOS A OBJETOS</h3><img src="img/objetos.png" width="800" height="400"><div class="subheading mb-3">DEFINICIÓN:</div>
<p>• El modelo orientado a objetos utiliza el paradigma de la orientación a objetos para el desarrollo de software.</p>
<p>• Este enfoque realiza la construcción de modelos de un sistema por medio de la identificación y la especificación de un conjunto de objetos relacionados, que colaboran entre si de acuerdo a los requerimientos establecidos para el sistema de objetos.</p>
<p>• La definición del modelado orientado a objetos puede claramente dividir el enfoque en tres dimensiones:</p>
<p>--La dimensión estructural.</p>
<p>--La dimensión dinámica.</p>
<p>--La dimisión funcional.</p>
<p>• Este tipo de modelado implica la realización de las siguientes actividades:</p>
<p>1. Identificar las clases, modelos y objetos. (objetos y atributos).</p>
<p>2. Asociar estáticamente los objetos. (relaciones dependientes del dominio del problema).</p>
<p>3. Especificación del comportamiento de los objetos. (Definir como se comportaran los objetos).</p>
<p>4. Definir la jerarquía de herencia de las clases. (Definir la jerarquía de clases, para que el sistema quede lo más abstracto posible).</p>
<div class="subheading mb-3">CARACTERÍSTICAS:</div>
<p>• EL modelado Orientado a Objetos está basado en el paradigma orientado a objetos.</p>
<p>• Trata el almacenamiento de objetos (persistencia de los objetos).</p>
<p>• Define un lenguaje para le definición y manipulación de objetos.</p>
<p>• Incluye mecanismos para optimizar el acceso (Indexación y Clustering), el control de la concurrencia, seguridad y gestión de usuarios, facilidad de consulta y recuperación ante fallos.</p>
<p>• Debido a que es un esquema orientado a objetos incluye: Encapsulamiento, herencia, polimorfismo, etc.</p>
<p style="text-align: center;"><strong>ESTÁNDARES RELACIONADOS CON EL PROCESO SOFTWARE: IEEE/EIA</strong></p>
<p style="text-align: center;"><strong>(ISO/IEC) 12207, SWEBOK, CMMI, PMBOK)</strong></p>
<p style="text-align: center;">ISO/IEC 12207 </p>
<p style='margin-top:0cm;margin-right:0cm;margin-bottom:8.0pt;margin-left:0cm;text-indent:0cm;line-height:200%;font-size:15px;font-family:"Calibri",sans-serif;'><span style="font-size: 14px; line-height: 200%; font-family: Calibri, sans-serif;">El ISO/IEC 12207 es el estándar para los procesos de ciclo de vida del software de la organización ISO</span></p>
<p style='margin-top:0cm;margin-right:0cm;margin-bottom:8.0pt;margin-left:0cm;text-indent:0cm;line-height:200%;font-size:15px;font-family:"Calibri",sans-serif;'><span style="font-size: 14px;"><span style="font-family: Calibri, sans-serif;"><span style="line-height: 200%;">Este estándar se concibió para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. El estándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software.</span></span></span></p>
<p style='margin-top:0cm;margin-right:0cm;margin-bottom:8.0pt;margin-left:0cm;text-indent:0cm;line-height:200%;font-size:15px;font-family:"Calibri",sans-serif;'><span style="font-size: 14px;"><span style="font-family: Calibri, sans-serif;"><span style="line-height: 200%;">El estándar comprende 17 procesos lo cuales son agrupados en tres categorías:</span></span></span></p>
<ul style="list-style-type: disc;">
<li><span style="font-size: 14px;"><span style="font-family: Calibri, sans-serif;"><span style="line-height: 107%;">Principales</span></span></span></li>
<li><span style="font-size: 14px;"><span style="font-family: Calibri, sans-serif;"><span style="line-height: 107%;">De apoyo</span></span></span></li>
<li><span style="font-size: 14px;"><span style="font-family: Calibri, sans-serif;"><span style="line-height: 107%;">De organización</span></span></span></li>
</ul>
<p style='margin-top:0cm;margin-right:0cm;margin-bottom:8.0pt;margin-left:0cm;text-indent:0cm;line-height:200%;font-size:15px;font-family:"Calibri",sans-serif;text-align:center;'><span style="font-size: 14px;"><span style="font-family: Calibri, sans-serif;"><span style="line-height: 200%;"> </span></span></span></p>
<p style='margin-top:0cm;margin-right:0cm;margin-bottom:8.0pt;margin-left:0cm;text-indent:0cm;line-height:200%;font-size:15px;font-family:"Calibri",sans-serif;text-align:center;'><span style="font-size: 14px;"><span style="font-family: Calibri, sans-serif;"><span style="line-height: 200%;">Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro procesos organizativos. Cada proceso del ciclo de vida está divido en un conjunto de actividades; cada actividad se sub-divide a su vez en un conjunto de tareas. A continuación, se hace una introducción de cada proceso</span></span></span><span style="font-size: 14px; line-height: 200%; font-family: Calibri, sans-serif;">.</span></p>
<p style="text-align: center;"><br></p>
<p><br></p>
<p style="margin: 0cm 0cm 8pt; text-indent: 0cm; line-height: 200%; font-size: 15px; font-family: Calibri, sans-serif; text-align: justify;"><br></p>
<p><br></p>
<p></p>
<img src="img/iso.jpg" width="800" height="400">
<ul>
<li>Procesos Principales</li>
</ul>
<p>Los procesos principales del ciclo de vida son cinco el cual brinda servicio a las partes principales durante el ciclo de vida del software. Una parte principal es aquella que inicia o lleva a cabo el desarrollo, operación, o mantenimiento de los productos software. Estas partes principales son el adquiriente, el proveedor, el desarrollador, el operador y el responsable de mantenimiento de productos software. Los procesos principales son:</p>
<ul>
<li>Proceso de Adquisición</li>
</ul>
<p>Define las actividades del adquiriente, es decir, la organización que adquiere un sistema, producto software o servicio software</p>
<p> </p>
<ul>
<li>Proceso de Suministro</li>
</ul>
<p>Se relaciona con las actividades del proveedor, organización que proporciona sistema, producto o servicio software al adquiriente</p>
<p> </p>
<ul>
<li>Proceso de Desarrollo</li>
</ul>
<p>Define las actividades que tiene que llevar a cabo el desarrollador, organización que define y desarrolla el producto software</p>
<p> </p>
<ul>
<li>Proceso de Operación</li>
</ul>
<p>Define las actividades del operador, organización que proporciona el servicio, organización que proporciona el servicio de operar un sistema informático en su entorno real</p>
<p> </p>
<ul>
<li>Proceso de Mantenimiento</li>
</ul>
<p>Define las actividades del responsable de mantenimiento o la organización que se encarga de esta función, es decir, la gestión de las modificaciones al producto para mantenerlo actualizado y operativo.</p>
<p><a name="_Toc47641875"></a>SWEBOK<strong>:</strong></p>
<p>Contiene conceptos y conocimientos acerca de la ingeniería de software y de cómo debe de llevarse a cabo por un ingeniero de software, proporciona una visión general acerca del software de calidad y de las buenas prácticas de desarrollo, las áreas de conocimiento de han ido ampliando a través de las versiones.</p>
<ul>
<li><strong>Áreas principales:</strong></li>
</ul>
<p>Para SWEBOK, el conocimiento se ha agrupado en áreas, que son:</p>
<ul>
<li>Requisitos</li>
<li>Diseño.</li>
<li>Desarrollo</li>
<li>Pruebas</li>
<li>Mantenimiento</li>
<li>Gestión de configuración.</li>
<li>Gestión de software.</li>
<li>Proceso de ingeniería.</li>
<li>Herramientas y métodos de ingeniería.</li>
<li>Calidad de software</li>
</ul>
<img src="img/SWEBOK.jpg" width="700" height="500">
<p><strong>Requisitos:</strong> Interpreta las necesidades del cliente en una lista de objetivos a cumplir, cada uno se puede trasformar en un subsistema o sólo en una funcionalidad, si los requisitos no son interpretados correctamente, el sistema sufrirá consecuencias graves en el desarrollo y mantenimiento</p>
<img src="img/SWEBOK1.jpg" width="700" height="500">
<p><strong>Diseño:</strong> Define la arquitectura, interfaces, diagramas de flujo, entre otros del sistema; en esta etapa se analizan los requerimientos y se crean posibles soluciones gráficas a cada uno.</p>
<img src="img/SWEBOK2.jpg" width="700" height="500">
<p><strong>Desarrollo:</strong> Interpreta la arquitectura, esquemas y diagramas de flujo definidos en la etapa de diseño en codificación de un lenguaje de programación, interactuando también con el sistema operativo y algunas veces con los dispositivos de entrada y salida.</p>
<img src="img/SWEBOK3.jpg" width="700" height="500">
<p><strong>Pruebas:</strong> Evalúa la eficiencia y calidad del producto detectando las posibles mejoras o fallas.</p>
<img src="img/SWEBOK4.jpg" width="700" height="500">
<p><strong>Mantenimiento:</strong> Corrige las fallas y realiza las mejoras detectadas anteriormente.</p>
<img src="img/SWEBOK5.jpg" width="700" height="500">
<p><strong>Gestión de configuración</strong>: Identifica la configuración general del sistema para realizar posibles adaptaciones y configurar su ciclo de vida, detecta las características físicas y funcionales del sistema además del cumplimiento de sus objetivos.</p>
<img src="img/SWEBOK6.jpg" width="700" height="500">
<p><strong>Gestión de ingeniería:</strong> Verifica la infraestructura del proyecto, el control y la planeación del programa, asegura que el mantenimiento del producto sea adecuado.</p>
<img src="img/SWEBOK7.jpg" width="700" height="500">
<p><strong>Gestión del proceso:</strong> Valida todas las etapas del proceso, como las tareas que componen el proceso, funciones, mediciones, configuración, mantenimiento, entre otros.</p>
<img src="img/SWEBOK8.jpg" width="700" height="500">
<p><strong>Herramientas y proceso de ingeniería:</strong> son todos los recursos virtuales que nos ayudan a realizar tareas exhaustivas como, validar el producto, crear el diseño, realizar pruebas, detectar fallas, entre otros; pero es importante saber que estas herramientas sólo interpretan el resultado de la información que brindamos, si la información es errónea, el resultado puede llevarnos a una mala decisión.</p>
<img src="img/SWEBOK9.jpg" width="700" height="500">
<p><strong>Calidad de software:</strong> el conjunto de las actividades vistas anteriormente tiene como objetivo crear un producto de calidad, el cual pueda brindar al cliente la solución a los procesos que realiza o a la problemática que tiene, siendo eficaz, costeable, moldeable, y que pueda tener futuras implementación, éstas son algunas características de software de calidad.</p>
<img src="img/SWEBOK10.jpg" width="700" height="500">
<h2><a name="_Toc47641876"></a>CMMI (Capability Maturity Model Integration):</h2>
<p> </p>
<p><strong>¿Qué es?</strong></p>
<p>CMMI es un modelo que contiene las mejores prácticas y que provee a las organizaciones de aquellos elementos que son esenciales para que los procesos de negocio de las mismas sean efectivos.<br /> Dicho nombre, tanto como los cinco niveles de la representación por etapas, están inspirados en el modelo de madurez Manufacturing Maturity Model de Crosby.<br /> En principio el modelo CMM era aplicado en programas de defensa, pero lo cierto es que este ha logrado gran aceptación, tan es así que ha sido sometido a varias revisiones e iteraciones. El problema con esto, es que debido a la gran proliferación de modelos de desarrollo de software comenzaron a surgir confusiones, con el fin de crear un solo marco extensible para la ingeniería de sistemas, la ingeniería de software y el desarrollo de productos.</p>
<p>CMMI establece cinco niveles de ‘madurez’ de las organizaciones en función de si tienen o no una serie de características específicas. Las organizaciones pueden ser evaluadas y en función de dicha evaluación, se les puede otorgar un nivel de madurez; ésta se califica en una escala del 1 al 5, es decir, a través de CMMI podemos saber el grado de ‘madurez’ de los procesos que tiene una organización, de acuerdo a un modelo de buenas prácticas.</p>
<img src="img/CMMI.png" width="500" height="300">
<p><strong> </strong></p>
<p><strong> </strong></p>
<p><strong> </strong></p>
<p><strong>Niveles de madurez por etapas.</strong></p>
<ul>
<li>Nivel 1 (Inicial): El proceso es impredecible, es reactivo y pobremente controlado.</li>
<li>Nivel 2 (Administrado): En este nivel, el proceso es reactivo y se caracteriza por su aplicación a proyectos.</li>
<li>Nivel 3 (Definido): En este nivel, el proceso se vuelve proactivo y se ve a nivel de organización.</li>
<li>Nivel 4 (Administrado Cuantitativamente): Este proceso es medido y controlado.</li>
<li>Nivel 5 (Optimizado): El Proceso se enfoca a una mejora continua.</li>
</ul>
<p><strong>Niveles de madurez Continuo.</strong></p>
<ul>
<li>Nivel 0 (Incompleto): El proceso no se ejecuta o se hace de una manera parcial.</li>
<li>Nivel 1 (Ejecutado): El proceso se ejecuta y se producen productos basados en entradas identificadas.</li>
<li>Nivel 2 (administrado): El proceso es reactivo y se caracteriza por su aplicación en proyectos.</li>
<li>Nivel 3 (Definido): El proceso es proactivo y se visualiza a nivel de la organización.</li>
<li>Nivel 4 (Administrado Cuantitativamente): Este proceso es medido y controlado.</li>
<li>Nivel 5 (Optimizado): El Proceso se enfoca a una mejora continua.</li>
</ul>
<p> </p>
<p> </p>
<p><strong> </strong></p>
<h2><a name="_Toc47641877"></a>PMBOK (<strong>Project Management Institute</strong> (o PMI)):</h2>
<p> </p>
<p>El PMBOK es la Guía de Fundamentos para la dirección de proyectos y nos suministra las pautas, conocimientos y prácticas aplicables a diferentes clases de proyectos, algo que hay que tener claro es que este instrumento no es una metodología.<br /> El PMBOK ha sido diseñado por varios profesionales de esta disciplina y documenta la información necesaria para iniciar, planificar, ejecutar, supervisar, controlar y cerrar un proyecto, además establecen los grupos de procesos y áreas de conocimiento que se deben implementar en cada una de las etapas de un proyecto.<br /> El PMI ha diseñado este libro para ser aplicado por los directores de proyectos a nivel mundial y ha estandarizado diferentes exámenes y cursos que hacen que todos los Project manager hablen el mismo idioma.</p>
<p><strong>Alguno de los exámenes es:</strong></p>
<p>– Técnico certificado en dirección de proyectos (CAPM)<br /> –<strong> </strong>Profesional en dirección de proyectos (PMP)<br /> – Profesional en dirección de programas (PgMP)<br /> – Practicante de metodologías ágiles certificado por el PMI (PMI-ACP)<br /> – Profesional en gestión de riesgos (PMI-RMP)<br /> – Profesional en gestión de cronogramas (PMI-SP)</p>
<p><strong> </strong></p>
<p><strong> </strong></p>
<p><strong>Propósito del PMBOK:</strong><br /> </p>
<p>El propósito principal de este libro es la aplicación de conocimientos, procesos, habilidades, herramientas y técnicas que son de gran relevancia en el éxito de un proyecto.<br /> Establece códigos de ética y conducta a los profesionales que ejercen esta profesión, y deja claro las obligaciones que se tiene respecto a la responsabilidad, respeto, equidad, y honestidad.<br /> Todo profesional en esta materia deberá tener un amplio Léxico.<br /> Y el más importante de los propósitos es estandarizar todos los procesos que se llevan a cabo en la dirección de los proyectos y que todos los directores de proyectos tengan claros conocimientos desde el inicio hasta el final de un proyecto.</p>
<img src="img/PMBOK.jpg" width="400" height="400">
</section>
</div>
</section>
<hr class="m-0">
<section class="resume-section p-3 p-lg-5 d-flex align-items-center" id="awards">
<div class="w-100">
<h2 class="mb-5"><img src="img/Williams.jpg" width="760" height="756"><p>Williams Geovanny Carrillo Fuentes</h2>
<p><strong>INFORMACION:</strong></p>
<ul>
<li style="text-align: left;"><strong>Graduado en el Colegio Fiscal "Ancón" como ingeniero en sistemas</strong></li>
<li style="text-align: left;"><strong>Experiencia laboral como pasante en Netlife</strong></li>
<li style="text-align: left;"><strong>Conocimiento basico en C</strong></li>
<li style="text-align: left;"><strong>Actual estudiante de la Universidad De Guayaquil</strong></li>
</ul>
<div class="social-icons">
<a link href="https://github.com/WilliamsGTX">
<i class="fab fa-github"></i>
</a>
<a link href="https://www.instagram.com/will_geova/">
<i class="fab fa-instagram"></i>
</a>
<a link href="https://wa.me/593963784313">
<i class="fab fa-whatsapp"></i>
</a>
<a link href="https://www.facebook.com/guilliam.yobani.3">
<i class="fab fa-facebook-f"></i>
</a>
</div>
</div>
</section>
</div>
<!-- Bootstrap core JavaScript -->
<script src="vendor/jquery/jquery.min.js"></script>
<script src="vendor/bootstrap/js/bootstrap.bundle.min.js"></script>
<!-- Plugin JavaScript -->
<script src="vendor/jquery-easing/jquery.easing.min.js"></script>
<!-- Custom scripts for this template -->
<script src="js/resume.min.js"></script>
</body>
</html>