Top Banner

Click here to load reader

of 24

1 ANDRES PICO USE SLIDESHOW OR PRESS F5 FOR BETTER EXPERIENCE! GIFS USED!

Jan 18, 2018

Download

Documents

Noel Norris

3 And sometimes we take if for granted..
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript

1 ANDRES PICO USE SLIDESHOW OR PRESS F5 FOR BETTER EXPERIENCE! GIFS USED! 2 SOFTWARE In the 21 st century software is found everywhere, almost every aspect of life in this century requires software engineering! From our breakfast when we retrieve food from the fridge that uses code from an embedded chip To fulfill our duties like work, homework, classes, paying debts 3 And sometimes we take if for granted.. 4 Now software is so complex that we even have self driving cars! But every day it keeps evolving.. Less than two decades ago we had boring phones that didnt have colored screens 2000s NOKIA 3310!!! 5 Problem solving But there is something crucial we mustnt forget! Not every problem we will face out in the industry will be as easy as the ones confronted in our programming concepts class. From time to time we will find very hard to solve problems that will require lots of thought. 6 For this reason, it is always great to have a good approach when solving problems. A first good step is to apply the process of analysis. Which is very similar to a well known concept in our career: Divide and Conquer -During the analysis process we must divide the problem into smaller pieces. -Then we solve the subproblems, which eventually help us to solve the big problem. 7 But solving a problem does not stop there, as the process of synthesis is quite challenging.. The process of synthesis consists on bringing all the pieces together(remember the subproblems you solved in the analysis process?). This requires lots of thought and planning. 8 Lucky for us, there are problem solving tools that make our job easier. For example: A specific compiler or programming language that meets our systems needs. This would be known as a tool. Or the use of functions and classes as procedures to keep consistency in the way we do something. Nonetheless, there is not an absolute best tool or approach, there are specific tools that are best for some specific tasks. This is known as the paradigm. 9 Software Engineering Computer science and Software Engineering may be related but there are certainly some differences we should remember. Computer science deals with theories, algorithms, the creation of new tools. While software engineering has to do with the efficient use of the computer as a tool to create software solutions to problems. A software engineer is a person with the skill, understanding, and experience to develop and maintain code in the most robust, simple, and efficient way possible. But just as any other person (YOU!), software engineers also make mistakes. NASAs 1999 orbiter project is an example of such. The orbiter was worth 327 million dollars and crashed upon arriving into Mars. The reason? English metrics were used by the programmer The IRS lost millions of dollars for several years after obtaining an inadequate tax form processing system. 10 Good Quality Software As any other product, quality is certainly expected in software systems. The factors that determine the quality of the product varies according who you ask, and what the functionality of the system is. The quality of the process can also affect the quality of the product, as this is the moment when mid-project decisions and changes are made. It is good to keep in mind that although some software engineers might determine quality by a programs technical attributes, the customers in the business environment determine it in a return on investment way(ROI). At the same time it is very hard to agree on the qualities that define the return on investment. The ROI varies from client to client. Some consider clients satisfaction as the ROI, others consider return of capital, maintenance costs, saved time. 11 As stated before, software engineers might measure quality of technical attributes. The picture below shows many of the common attributes that software engineers look for. 12 Participants in the Software Process The process of generating software comprehends 3 types of entities: Customer: The person or group of people that pay for and request the product. User: The person or group of people that will use the product. Developer: The person or group of people that develops the product and does software engineering. At the same time the developers can hire subcontractors which will provide them with tools to make their work easier 13 A Systems Approach We have met with the term software system a few times, but what is a system in the systems approach? A system is a collection of things or set of activities with defined borders. An activity is an action of something that happens in the system, and it is composed of objects. An object is an element that the activity uses. For example if a table in a database is created, that is an activity. Then each record found in the table would be an element. The postal office system can be used of an example: Letters and packages come in They are processed They are sent to delivery to the right addresses 14 Interrelated Systems We should keep in mind though that when we refer to a system, in many occasions it is a small piece of a bigger system. Still, wed rather work with the smaller systems of a bigger systems sometimes to make the task easier and simpler for us. This is why we must define boundaries correctly. Not only when creating systems this approach is useful but when modifying them. Lets consider incremental development for instance. Incremental development consists of marking stages of changes, that slowly are incorporated one by one. Keep in mind that each stage must be fully incorporated to the system before considering the next stage. With time, the different stages incorporated one at a time will result in the desired new system. It may be a relatively slow process, but it reduces bugs and failures when done correctly. 15 Incremental development example USF used to work with blackboard a few semesters ago. -Teachers inputted grades, files, and assignments to the software system. -Then, students had access to them. USF then made the decision to work with canvas. So USF decided to make the transition in stages(Similar to incremental development). -Before removing blackboard, it added canvas. -Then, it allowed one semester for professors and staff to familiarize with canvas. -Professors then had to transport things to canvas. -After making sure that canvas could be fully integrated and that it would replace blackboard successfully. -It proceeded to remove blackboard, resulting in the same systems functionality but with a different tool. A great change overall, but accomplished in stages. 16 The Engineering Approach In the production of a system software there are some crucial steps that must occur to achieve success: Establish requirements with the clients based on their needs. Design of the system software based on the requirements agreed. Documentation and outline of components to be made (planning phase). Building of components. Integration of components (Joining all the pieces together). Changes in design which may occur at any time during the production. Maintenance of product. Of course success could not be achieved without a good development team. There are some key roles that must be fulfilled in order to be as effective as possible: Requirement analysts: determines requirements of the project. Designers: determines where changes should be made. Programmers: implement the designs. Testers: make sure system runs properly. Trainers: explain users the systems functionality 17 Change in Software Development As software engineers we must be very susceptible to change. It is not an uncommon case to have the client making changes in the design in the middle of the production. And when this happens, the initial requirements and tools that were established for use might not be the best. Although this may be unpleasant sometimes, because our clients may not fully understand what they want. Experience has shown that it is better to make these changes while the system software is being produced than when it has been finished. Programming tools themselves change from time to time(upgrades) to provide more features than before. And these new features will help us most of the times to generate better quality products. For this reason, we must be familiarized with both the past, and the future to make the best choices when mid-production changes occur. 18 But what drives these unending software changes? Many factors in fact. -Object Oriented Design that simplifies the problem solving challenges -Waterfall effect -Time to market and the race software companies face with each other -Economics -Friendly user interfaces that allow easier access to users -Network securities, speeds, and constraints -Desktop computing capabilities and limitations 19 Discipline of Software Engineering Abstraction View of the problem in a more general, understandable way. (Ex: Object Oriented Design) Analysis methods and notation Consistency in notation results in better communication. User interface prototyping Small similar examples of what the product will look like at the end. Software architecture Software architecture should be the easiest to change: modularity and individualism of elements are a good approach. The software process Not set in stone.. It depends on the situation. Small to large scale software development Large scale systems require more tools, testing, and analysis. Software reuse Reuse previously made software when beneficial. Measurements: quantifying design We need measurable quantities to be able to set new goals for the product. Tools and integrated environments Understand the interoperability and capabilities of our tools is crucial for designing systems. 20 Is There a Software Crisis? Although software errors have been underestimated for their consequences, they can certainly produce disastrous outcomes and even claim lives. These systems are best known as safety critical systems. Which are systems that can injure or kill people when malfunctioning. In 1995 there was a nitrogen leak killed 2 engineers. The leak was determined to happen due to software errors. The Therac-25 is another example of a safety critical system error. A software error caused the machine to give high doses of radiation to clients that didnt need them, causing their death. So with this in mind, what is the best software practice? It really depends, once again there is not such thing as a best practice But a good software practice may be to apply the engineering approach which we discussed in slide# 15. 21 Examples Databases can be thought of as simple software systems: Its boundaries keep communication with the developers(modify them), users(use the data), and clients(provide the data). It receives inputs to add, modify and delete records mostly. And outputs them to the users as they need them. Lastly, we should not conclude without talking about context diagrams for system boundaries. These context diagrams are high level views of the system at hand, and the relationship it maintains with external entities. These are very useful to keep in mind the systems purpose. 22 THE END 23 SOURCES PPT1:https://38.media.tumblr.com/0192e36a0033bb7cfa97378adefa27b5/tumblr_inline_nsfurjmqoI1t2sort_500.gif PPT2:PPT3: https://upload.wikimedia.org/wikipedia/commons/3/31/Nokia_3310_blue.jpgPPT4: https://36.media.tumblr.com/4644c15dcfc7d305cacfa7e9f77a32ea/tumblr_nwsmv8cBla1rhkrwho2_1280.png PPT6: https://49.media.tumblr.com/0fc f5aadb461bfcaabdec/tumblr_mluggehwS61r5zq6ao1_r1_400.gif PPT10: https://msritse2012.files.wordpress.com/2013/01/mccalls-11-quality-factor-hierarchy.jpg PPT11:638.jpg?cb= 24 PPT12: PPT16: https://41.media.tumblr.com/tumblr_maejdbEfih1ruvvwlo1_500.jpg PPT17:638.jpg?cb= PPT20:PPT21: https://45.media.tumblr.com/363e645bc4dcf8759ec22b5b92120b83/tumblr_nt15tijRuF1rl1484o2_400.gif MAIN IDEAS SOURCE: Software Engineering 4 th edition, Shari Lawrence & Joanne Atlee.