Higher Technological Institute Centla ING.

COMPUTER SYSTEMS SYSTEMS FUNDAMENTALS OF TEACHER DEVELOPMENT: Students: Potenciano WILVER MORALES Jovan Tzec CHRISTIAN HERNANDEZ 1 CONTENTS • • • • • INTRODUCTION ======================= ================= WATERFALL MODEL • DESCRIPTION ======================= ======================== • STRUCTURE • FE ATURE ===================== == ======================= • ADVANTAGES • DISADVANTA GES ===== ======================== ================ • SPIRAL MODEL • DESCRIPTION • ===== ======================== ================= STRUCTURE • FEATURES ======= =================== ==================== • ADVANTAGES • DISADVANTAGES ========= ======================== ============ • INCREMENTAL MODEL • • DESCRIPTION ===== ================== === ==================== STRUCTURE ==== • 4 5 6 7 10 11 12 13 14 15 19 20 21 22 23 24 2 • • • • • • • • • • • • • • • • • • • • • • • • • • ADVANTAGES ============================ • UNIFIED DEVELOPMENT PROCESS DESCRIPTIO N ========== ==== • • STRUCTURE • ============== ========================= ===== == FEATURES ============= • PERSONAL SOFTWARE PROCESS DESCRIPTION ============== ========== === • • PRINCIPLES = • OBJECTIVES ======================= =========== ============== === • • ADVANTAGES DISADVANTAGES =================== ============ ============ • LEVELS • ============================= ========= ======== CONCLUS ION ======================== ================= • BIBLIOGRAPHY • 25 26 27 28 32 33 34 36 37 38 39 40 42 43 3 INTRODUCTION As in other systems engineering, software systems require considerable time and effort for development and remain in use for a much longer period. During this t ime of development and use, since it detects the need to build a software system until this is removed, it identifies several stages which together are called t he software life cycle and in each case, depending on which Whatever the nature of the project, set up the cycle of life differently. An essential part of the t asks of software development is the documentation of all elements and specificat ions for each phase. Since this task is always influenced by the current phase o f development will be explained in a distributed along the different phases as a special section to emphasize its importance in the overall software development . 4 5 DESCRIPTION This model allows the possibility of iterations, that is for the changes made in the maintenance you can see for example the need to change something in the design, which means it will make the necessary changes in the coding and wil

l have to perform the tests again, that is, if you have to re- previous stage to the maintenance you have to take back the rest of the stages. After each step is a review to see if it can move to the next. 6 Cascade Model Structure (Bennington 1956) The best known, is based on a conventional cycle engineering, life cycle paradig m includes the following activities: System Engineering and Analysis Requirements Analysis Design Coding Test Maintenance 7 • System Engineering and Analysis: Because the software is always part of a larger system the begins by establishing the requirements of all elements of the system and then a llocating some subset of these requirements to software. • Analysis of software requirements: the process of gathering requirements and foc uses intensified especially in the software. The software engineer must understand th e scope of software information, as well as function, performance and interfaces required. • Design: the software design focuses on four distinct attributes of the program: data structure, software architecture, procedural detail and the characterizatio n of the interface. 8 • Coding: the design must be translated into a machine-readable form. Coding step performs this task. • Test: The test focuses on the internal logic of the software, and external funct ions, by

tests to ensure that defined input produced the results that really are required . • Maintenance: The software will undergo changes after they are delivered to the c ustomer. The changes occur because they have found mistakes, that software should adapt to changes in the e xternal environment (operating system or other peripheral devices), or because t he customer requires functional extensions or performance. 9 FEATURES • It is the most used. • It is a vision of software development process as a sequence of steps that produ ce intermediate. • For the project to be developed to succeed in all phases. • The steps continue until the objectives have been met. • If you change the order of the phases, the final product will be of inferior qua lity. 10 ADVANTAGES • The planning is simple. • The resulting product quality is high. • Allows unskilled work. 11 DISADVANTAGES • • • not really reflect the software development process takes a long time to g o through the cycle perpetuates the failure of the software industry in its comm unication with the end user • • • Maintenance was done in the source code

The reviews of projects of great complexity are very difficult to impose a proje ct management structure 12 13 DESCRIPTION First proposed by Boehm in 1988. • Development cyclic (iterative) where in each cycle is performed four tasks: - Determination of objectives, alternatives and constraints - Evaluation of alternatives, analysis and risk control. - Development and testi ng of the product. - Planning for the next cycle (phase). • Each cycle corresponds to a phase of the project. . 14 A typical representation of this structure: 15 16 In each iteration Boehm recommends gathering the following list of information: • • Objectives: We do interviews with customers, makes them questionnaires, etc. Alt ernatives: Are the different possible ways to achieve the objectives. Considered from two views - Product Features. - Ways to manage the project. • Restrictions: - From the point of view of the product: Interfaces of this or that way, perform ance, etc. - From an organizational perspective: costs, time, personnel, etc. 17 • • • Risks: List of identified risks. Resolution of risks: The most widely used technique is to build prototypes. Resu lts are what really happened after the resolution of risks. •

• Plans: What is going to do in the next phase. Commitment: Management Decisions on how to continue. At the end of an iteration is found that what has been done effectively meet the requirements, we are also working properly. The customer evaluates the product. There is a clear difference between when the project ends and when it begins the maintenance phase. When you have to make a change, this may be a new cycle. 18 FEATURES • • • At every turn we build a new model of the entire system. This model can be combined with other models of development process (waterfall, evolutionary) Best model for the development of large systems. • Risk analysis requires the participation of highly qualified personnel. 19 ADVANTAGES • • • You do not need a full definition of the requirements to start working. By delivering products since the end of the first iteration is easier to validat e the requirements. The overall risk is lower, because if everything is bad, jus t has lost time and resources invested in an iteration (the previous iterations are fine). • The risk of delay is less, and that identifying problems early is time to addr ess them. 20 DISADVANTAGES • • • It is difficult to assess the risks. Needs the continued involvement by the client. When subcontracts are to be produ ced before a full specification of what is needed, and this takes time. 21 22 DESCRIPTION • • • It combines elements of the linear model with the philosophy of prototyping.

The first increment is often a product essential (core). From the evaluation pla n the next increment and so on. • • • It is interactive in nature It is useful when staff is not sufficient for full implementation 23 Graphic representation: 24 ADVANTAGES • • • You can fund the project parties Suitable for large projects of long duration is not needed to start both persona lly and for a complete implementation 25 26 DESCRIPTION The unified process known as RUP is a software model that allows the development of large-scale software, in a continuous process of testing and feedback, ensuring compliance with certain quality standards. The development process is a methodological framework defined in terms of goals strategic objectives, activities and artifacts (documents) required at each stag e of development. This allows you to focus efforts of human resources in terms of skills,€competen cies and capabilities to assume specific roles well defined responsibilities. 27 Structure of the life cycle of the unified development process: Phases Each cycl e has four phases: initiation, development, construction and transition. 28 Each stage is divided into iterations. In each iteration takes place in sequence a set of disciplines or workflows. 29 Disciplines Each discipline is a set of related activities (workflows) linked to a specific area within the overall project. The most important are: Requirements, Analysis, Design, Coding, and Testing. The clustering of activities in disciplines is pri marily an aid to understanding the project from the traditional cascade. 30

Each discipline is associated with a set of models developed. These models are c omposed of artifacts. The most important artifacts are models made by each disci pline: use case model, design model, deployment model and test model. 31 FEATURES It is iterative and incremental Led by the use cases focused on architecture Focus on risks 32 33 DESCRIPTION • In 1995, the PSP was proposed by Watts Humphrey, this originally was intended for students. • In 1997 with the launch of the book "An Introduction to the Personal Software Process" on PSP was intended for engineers. • • PSP focuses on the work practices of engineers in an individual. The PSP is characterized is for personal use and is applied to small programs with less tha n 10,000 lines of code. 34 • The PSP is to produce quality software, where each engineer must work on the nee d for quality work. • The PSP is focused on time management and quality management through early elimination of defects. • The PSP aims to provide a framework for the personnel involved in the developmen t process software. • PSP demonstrates how to manage quality from the beginning of work. 35 PRINCIPLES OF THE PSP • • Each engineer is essentially different (Each is responsible for their work). To continuously improve its performance, engineers must use personally well-defi ned processes and measured.

• The engineers must feel personally committed to the quality of their products, t his improve quality. • The earlier you detect and correct defects will require less effort. • • It's more effective to avoid the defects identified and corrected. Work well is always the fastest and cheapest way of working. 36 OBJECTIVES FOR PSP • • • Achieving a discipline of continuous improvement in the development process. Measure, estimate, plan, monitor and control the development process. Improving the quality of the development process. • In general, PSP provides quality and productivity. - The time saved in testing based on a better quality saves between 20-40% of de velopment ... 37 DISADVANTAGES OF APPLYING PSP • • • The time required to meet The emotional cost to maintain discipline the ego of the change in customs 38 ADVANTAGES OF APPLYING PSP • • • The idea of having won in talent and ability Stimulation for new ideas A structure-improvement work • • • • Take control of own work The feeling of achieving a better basis for group work (TSP) The conviction that the best thing you can do 39 PSP LEVELS

• The PSP defines five framework activities: - PLANNING. - HIGH-LEVEL DESIGN - REVIEW OF HIGH-LEVEL DESIGN - DEVELOPMENT - ANALYSIS OF RESULTS 40 PSP LEVELS 2.1 3 PSP PSP PSP 2 Design-Review-Review of design templates code (framework and lists) Verification of design tasks PSP 1.1 PSP 1-Ability to estimate size. -Testing Report -Planning-Planning Task times PSP 0.1 PSP 0 "Current practices development. -Maintain records of time worked on a project. " Record-Record defects found types of defects. -Establish coding standards (Defin e Lines of Code "), propose ways to improve development process-Perform measurem ents 41 CONCLUSION After explaining some of the models most widely used life cycle, must be an inqu iry which will give a precise answer and concrete. What life cycle model to choose? and my conclusion and my answer would be that w e should choose the model that best suits the project we develop. We can look to guide us when choosing the complexity of the problem, the time available to us to the final delivery,€or if the user or customer wants partial delivery, commun ication between development team and the user and finally that we have certain r equirements set by the user are incorrect or complex. 42 BIBLIOGRAPHY www.slideshare.net www.lsi.ugr.es/ ~ MVEG / docis / respsp.pdf www.utvm.edu.mx/O rganoInformativo/orgJul07/RUP www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/ no de10 www.es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3 www.biblioteca .co.cr/pdf/unidad12-4.pdf www.alarcos.inf-cr.uclm.es/doc / ISOFTWAREI/Tema03.pdf www.scribd.com/doc/11468082/CICLO-DE-VIDA-Y-MODELO-EN-CASCADA 43