1 / 52

Software Engineering

Software Engineering. Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL. Agenda. Team interactions OO Analysis and Design Dr. Reat. When do you focus on risk?. First the nature of the project dictates the level of risk management necessary

napua
Télécharger la présentation

Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL T. E. Potok - University of Tennessee

  2. Agenda • Team interactions • OO Analysis and Design • Dr. Reat T. E. Potok - University of Tennessee

  3. When do you focus on risk? • First the nature of the project dictates the level of risk management necessary • If the project has challenging requirements • Safety • Performance • Complexity • Size • A simple small project may not need much risk management T. E. Potok - University of Tennessee

  4. When to focus on risk • Next, are development concerns • Do you have the right people • Can you do the work within schedule and budget • Is the problem well understood • You may have a small simple project that your team is incapable of developing T. E. Potok - University of Tennessee

  5. Last resort • You believe that the challenger will explode • People will be killed • The space program will be crippled for years • What do you do? • Write a tersely worded memo to your manager? • Leave a voice mail with your manager’s manager? • Call the president of the company? • Call the president, the news papers, the TV stations? • If you know disaster is coming, and you don’t do everything within your power to prevent it, you have failed T. E. Potok - University of Tennessee

  6. Summary • Understanding the risks associated with a project is essential to the success of a project • The more aspects of a project that are not understood, the higher the chance that blind luck with guide the project T. E. Potok - University of Tennessee

  7. What is this? T. E. Potok - University of Tennessee

  8. The last picture taken from the Mars Lander • Mars Lander • … A software flaw probably caused the Mars Polar Lander to shut off its descent engines prematurely, sending it on a fatal plunge into the red planet, according to a report released Tuesday… • "There was inadequate software design and testing. The software should have been designed to prevent premature engine shutdown," he said. "In space, one strike and you're out." • The loss to taxpayers was approximately $165M. T. E. Potok - University of Tennessee

  9. THERAC-25 Radiation Therapy T. E. Potok - University of Tennessee

  10. Human Life • In 1986, two cancer patients at the East Texas Cancer Center in Tyler received fatal radiation overdoses from the Therac-25, a computer-controlled radiation-therapy machine. There were several errors, among them the failure of the programmer to detect a race condition (i.e., miscoordination between concurrent tasks). • 6 people in total received massive overdoses of radiation from the Therac-25 directly resulting in two deaths T. E. Potok - University of Tennessee

  11. Airbus 320, not an F-14 T. E. Potok - University of Tennessee

  12. 290 Die • The 1988 shooting down of the Airbus 320 by the US Vicennes was attributed to the cryptic and misleading output displayed by the tracking software where the plane was mistaken for an F-14. • 290 people die • US-Iranian relations worsen • Possibly resulting in increased terrorist attacks against US interests T. E. Potok - University of Tennessee

  13. Team Interaction T. E. Potok - University of Tennessee

  14. History • Most early software productivity studies focused on the software development team as the main factor in increasing productivity. • The goal of a project manager was to hire the people with the most experience, and best talent • However, that was at a time when experience was hard to come by, and there was little formal education T. E. Potok - University of Tennessee

  15. Current Situation • Computer science degrees are common • Software development experience is common • However, demand still out paces the availability of computer skills • Is the software development team still important? T. E. Potok - University of Tennessee

  16. Not to Some • Kitchenham, Lawrence, and Jeffery et al. show that many of the personnel related factors in earlier studies had no effect on productivity in their studies. T. E. Potok - University of Tennessee

  17. What is a team? • A collection of people with a common mission or purpose. • Traditional departmental focus: • Group similar skills on the same teams, architects with architects, programmers with programmers, testers with testers. • Based on mass production efficiency concepts • specialization of labor T. E. Potok - University of Tennessee

  18. Non-traditional Teams • Product focused: • The team is made up of members that can contribute to the completion of the project: • 1 architect • 6 programmers • 2 testers • The team is charged with successfully completing the project T. E. Potok - University of Tennessee

  19. Example • Most universities are organized around departments: • Computer science • Mathematics • Physics • Each department has faculty members who are experts in the department’s field T. E. Potok - University of Tennessee

  20. Example • What if you organized the departments around the students? • The Freshman Engineering Department may look like: • 4 Mathematicians • 2 Physicists • 2 Chemists • 4 English teachers T. E. Potok - University of Tennessee

  21. What drives a team • Locke and Latham’s“goal theory” reports that productivity increases with specific, challenging goals • There is a linear relationship between the degree of difficulty of a goal, and the performance required to achieve it. T. E. Potok - University of Tennessee

  22. Basic Experiment • Participants performing a group of tasks. • Some of the participants are given challenging goals, • others are told to “do their best.” • In most cases, the participants given hard goals significantly out performed the other participants. • This widely accepted theory supports the notion that programmer productivity can be strongly influenced by deadline “goals” set by a project schedule. T. E. Potok - University of Tennessee

  23. Leadership • Look at successful software development efforts and you will find a successful leader • Some characteristics of a leader (Maxwell): • A person of influence, not necessarily from title or position • A person of character • Has the ability to learn and grow • Has passion and discipline for the task • Has the ability to lead • “The 21 Irrefutable Laws Of Leadership Follow Them And People Will Follow You”by John Maxwell T. E. Potok - University of Tennessee

  24. More on Leadership • Covey’s Seven habits • Proactive • Begin with the end in mind • First things first • Think win-win • Understand, then be understood • Synergize • Sharpen the saw • “The 7 Habits of Highly Effective People” by Stephen R. Covey T. E. Potok - University of Tennessee

  25. Five Temptations of a CEO • Focus on career, not company success • Desire to be liked by staff • Desire for correctness over clarity • Desire for harmony • Desire to be invulnerable • “The Five Temptations of a CEO : A Leadership Fable” by Patrick M. Lencioni T. E. Potok - University of Tennessee

  26. Object-Oriented Analysis and Design T. E. Potok - University of Tennessee

  27. Quick Review • Gather requirements • Select a project life-cycle • Plan the project • Build a team • Then start the development of the software T. E. Potok - University of Tennessee

  28. Object-Oriented • Prior to OO was structured analysis • Keep function and data separate in analysis • Use data model for databases, functional models for software • OO combines data and function • Encapsulation • Inheritance • Polymorphism T. E. Potok - University of Tennessee

  29. Encapsulation • Provide a layer between the data of an object, and a calling method • This can insulate a calling method from having to be changed, in the initial data is changed T. E. Potok - University of Tennessee

  30. Example Person Age Weight Height healthIndex healthIndex := Age*(Weight/Height) Person Age (getAge(), setAge(int)) Weight (getWeight(), setWeight(int)) Height (getHeight(), setHeight(int)) healthIndex (getIndex(), setIndex(float)) setIndex(getAge()*(getWeight()/getHeight()) T. E. Potok - University of Tennessee

  31. Encapsulation Example • The setter methods can be used to put bounds on values, age can not be greater than 120, or less than 0 • The getter methods can be used to translate units, height from feet to meters • A change in the bounds, or units will require only a change to a few methods, not all the code that uses the attributes • For big changes, age to birth date, encapsulation does not help T. E. Potok - University of Tennessee

  32. Inheritance • The objects within an OO system can be organized in a class hierarchy • This hierarchy provides two means of inheritance • Method inheritance • Attribute inheritance T. E. Potok - University of Tennessee

  33. Method inheritance • An object can make us of any method that is defined higher in the class hierarchy • The code does not have to be copied, or rewritten, it just works • The method can be overridden if needed T. E. Potok - University of Tennessee

  34. Attribute Inheritance • Attributed from object higher in the hierarchy tree are also inherited • These attribute become available to the object, and do not have to be copied or defined • They can be overridden as well T. E. Potok - University of Tennessee

  35. Inheritance example Object Name Print Copy Collection Name Type Members Print Copy Sort Add(element) Delete(element) Bag Name Type Members Print Copy Sort (Overridden) Add(element) Delete(element) T. E. Potok - University of Tennessee

  36. Multiple Inheritance • Allows methods and attributes to be inherited for multiple object • Highlights the challenge of developing a class hierarchy • Has the potential for name collisions T. E. Potok - University of Tennessee

  37. Name collisions floorWax spread cakeIcing spread Fertilizer spread What spread method does fertilizer inherit from??? T. E. Potok - University of Tennessee

  38. Hierarchy Trees • Several ways to develop • Based on common functions or methods • With a many common methods, there is the opportunity for reuse • Based on common attributed • Common data can be an advantage particularly if you are using databases • Based on frequency of changes • Put stable methods higher in the hierarchy to lower the impact of change T. E. Potok - University of Tennessee

  39. Example • A hardware store can be laid out in a similar way • Based on functionality • Digging tools, cutting tools, hammering tools, ... • Based on data • Metal tools, wooden tools, plastic tools, ... • Based on frequency • Gum, nails, paint, rope, … • Based on domain • Gardening, household, garage, bedroom • No optimum way of doing so T. E. Potok - University of Tennessee

  40. Polymorphism • Calling similar methods in different class the same name • print • new • Not a new concept, used for arithmetic operations in other languages • Widely used in OO T. E. Potok - University of Tennessee

  41. OO Analysis • The development of an Analysis Model in the OO methodology converts: • User requirements • Into a high-level system model • In user terms not computer terms • This analysis is focused on • Defining objects and their interactions T. E. Potok - University of Tennessee

  42. More on OOA • OOA models may be done informally or more formally in object diagrams, ER diagrams, DFD diagrams, state-transition diagrams, or Petri nets • The OOA model consists of an object model, and may include a process model and a state model. • A process model describes the functional interaction of objects. This model is represented by the message paths among objects in an object model. • A state model can be used to determine the valid states for each object in the model. • An object state may change based on messages received from another object T. E. Potok - University of Tennessee

  43. Analysis Approaches • There are two main OO analysis methods used in the industry today • Booch • Rumbaugh NOT Rambaugh! • Booch tends to be less formal • Rumbaugh has close similarities to structure analysis T. E. Potok - University of Tennessee

  44. Booch Analysis • Booch’s methodology can be summarized with four basic steps [Booch (1991)]. • 1) Identify the classes and objects for a given level of abstraction. • 2) Identify the semantics of the objects and classes; • 3) Identify relationships among the classes and objects • 4) Design the classes and objects. T. E. Potok - University of Tennessee

  45. Identify Classes and Objects • Assumes that you are given a specification of the problem • From this specification you underline the nouns in the specification • Then the nouns are used to create a list of potential objects in the system • This list is refined to define the objects and attributes T. E. Potok - University of Tennessee

  46. Semantics of Objects and Classes • Once the objects are defined, then the verbs in the specification are underlined • The verbs are listed as potential methods • The methods are added to the appropriate classes to add meaning to the classes T. E. Potok - University of Tennessee

  47. Identify Relationships • Often CRC cards are used: • Class, Responsibilities, Collaborators • 3 x 5 Cards with class information are arranged based on how objects flow in the system • This allows for modeling of the system, and defines how objects relate to each other T. E. Potok - University of Tennessee

  48. Design Classes and Objects • Refine the analysis model converting from real-world terms to computer terms • Expand the objects to include necessary system objects T. E. Potok - University of Tennessee

  49. Booch Summary • The strength of Booch’s methodology is the underlying object model. • This model consists of five diagram types, • class, • object, • state, • process, • module. • The class, object, and state diagrams represent the logical structures. • The process and module diagrams represent physical structures. T. E. Potok - University of Tennessee

  50. Rumbaugh’s OMT • Rumbaugh et al. produced the Object Modeling Technique (OMT) which presents a view of object-oriented development in three parts: • an object model, based on a modified ER diagram that supports inheritance relationships. • dynamic model, a state model based on state transition diagrams • functional model, a data-flow diagram T. E. Potok - University of Tennessee

More Related