Análisis, diseño y construcción de Software

Transcription

1 Análisis, diseño y construcción de Software Dizan Vasquez 1/38

2 Presentación Profesor / ITESM Mexico - Consultor Postdoc / ETH Zurich Doctorado / INPG France DEA (Master)/ INPG France Master / ITESM México Industria / México ISC / ITESM México 2/38

3 Políticas del curso Documentos en formato PDF. Tareas: por mail a dichodaemon@gmail.com Por favor, apaga tu celular, computadora, phaser, etc. Si no asistes a clase, eres responsable de informarte de lo dicho en ella. Si requieres asesoría, por favor avísame con al menos un día de anticipación. 3/38

4 Evaluación Parciales: Calificación Final: Examen: 30% Tareas y proyectos: 70% Primer parcial: 20% Segundo parcial: 20% Tercer parcial: 20% Proyecto final: 40% Nota Nota La La fecha fecha de de entrega entrega del del proyecto proyecto coincide coincide con con el el final final de de clases. clases. 4/38

5 Bibliografía Craig Larman. Applying UML and patterns. 3a edición. Addison Wesley, Johanna Rothman. Manage it!. Pragmatic Bookshelf, Martin Fowler. UML Distilled. 3a edición. Addison Wesley, Joel Spolsky. The best software writing. Apress, Jarred Richardson and William Gualtney Jr. Ship it!. Pragmatic Bookshelf, /38

6 Software Engineering 6/38

7 software = problems NASA space shuttle program: Cost: 10,000,000,000 USD. Time: 3 years late. First Columbia launch delayed due to a single bug. Introduced 2 years ago (a parameters was changed from 50 to 70 ms.). Undetected after thousands of hours of tests. Astronauts received a booklet: known software problems. 7/38

8 Typical problems Bugs in systems. Systems do not comply with user requirements. Release delays and cancelation. Development exceed projected costs. Systems are difficult to maintain an expand. 8/38

9 Context All industrialized economies are highly dependent on software. Every day, more systems are controlled by software. Industrialized countries spend a very significant part of their budget addressing software development issues. 9/38

10 Software engineering Software engineering is a systematic approach to develop, operate, maintain and retire software Software engineering is the application of science and mathematics thanks to which computing capacities become useful through programs, procedures and documentation Blah, blah, blah 10/38

11 What's the goal? To produce low-cost, high-quality software on time. Cost Quality Time 11/38

12 Two perspectives 1) Software as a product. 2)Software as a process. 12/38

13 Product: what's software? Programs Documentation Processes Data 13/38

14 Product: features Usability Maintainability Reliability Efficiency Note Note software software product product <> <> programming programming programming programming is is a a means, means, not not an an end end 14/38

15 Product: client Provides resources, expects results. Defines requirements. Client satisfaction is your PRIMARY goal! 15/38

16 Process: what? A set of activities aiming to develop or evolve software 16/38

17 Process: activities Specification. Design. Development. Validation. Deployment. Evolution/maintenance. 17/38

18 Process: development models Simplified representations of the software process presented from a specific perspective: Perspective examples: Workflow: activity sequence. Dataflow: information flow. Roles and actions: who does what.. 18/38

19 Process: model examples Waterfall Evolutionary Spiral Iterative Agile 19/38

20 Process: costs Typical values are: 60 % Development 40 % Tests/validation But they vary with the system and development model 20/38

21 Methods Structured methodologies include the following: Development models. Notation: documents, graphics, etc. Rules: restrictions to apply to models. Recommendations: best practices, errors, case studies. Bottom Bottom line line Software Software engineering engineering is is more more an an art art than than a a science. science. 21/38

22 Software lifecycles 22/38

23 Exercise What is a software process. Which software process models have you used? Tools? Examples? Uses? Strengths and weaknesses? Observations? 23/38

24 Software development process A structured set of activities to develop a software system. Activities: Requirements. Design. Development. Test. Maintenance. Software process model: An abstract, prescriptive representation of a process. 24/38

25 Software process types 25/38

26 Software process types 26/38

27 Serial model: waterfall 27/38

28 Serial model: waterfall Drawbacks: Inflexible partitioning on stages. Relies on perfect hindsight. Cannot adapt to changing requirements,or incorporate new knowledge. Only appropriate when the requirements are well understood. Example: replicating existing system s functionality 28/38

29 Iterative model: spiral 29/38

30 Iterative model: spiral Advantages: Copes with schedule risk. Prototyping allows learning. Drawbacks: Users treat the prototype as the product. Specification is left to the designer/developer. Not clear how to analyze risk. Lack or process visibility. 30/38

31 Incremental development 31/38

32 Incremental development Advantages System functionality is available earlier. Early increments may work as prototypes. Handles schedule risk. Highest priority functionality receives the most testing. Drawbacks Unable to deal with architecture changes. 32/38

33 Agile methodologies Examples: XP (Extreme Programming), Scrum, Kanban. New approach to development based on the development and delivery of very small increments of functionality. Relies on constant code improvement and user involvement in the development team. 33/38

34 Agile methodologies Advantages Evolutive. Mesurable. Predictive. Drawbacks Unstructured. Incomplete. 34/38

35 Formal models Based on the transformation of a mathematical specification through different representations to an executable program. Transformations are correctness-preserving so it is straightforward to show that the program conforms to its specification. Embodied in the Cleanroom approach to software development. 35/38

36 Formal models Drawbacks Need for specialised skills and training to apply the technique. Difficult to formally specify some aspects of the system such as the user interface. Changes require new transformations and proofs. Hard to scale. 36/38

37 The bottom, bottom line There is no perfect model, the best one depends on the project and the team. 37/38

38 Assignment Read the following two articles How many Microsoft employees does it take to change a Light Bulb and Great Hackers then write a two-page essay on your opinion about them. 38/38

39 Acknowledgements for today's lecture Jeremy R. Cooperstock. Human-computer Interaction. Lecture Notes. Karon MacLean. Physical user interface design. Course material. 39/38