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