1 / 25

Software Engineering CS321 Dr. Kinga Dobolyi

Software Engineering CS321 Dr. Kinga Dobolyi. Why are you here?. Alternatively, why are we teaching this course? Do you need a course in software engineering? How is writing the code for a 211 project different from software engineering (or is it)?

ordell
Download Presentation

Software Engineering CS321 Dr. Kinga Dobolyi

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 EngineeringCS321Dr. KingaDobolyi

  2. Why are you here? • Alternatively, why are we teaching this course? • Do you need a course in software engineering? • How is writing the code for a 211 project different from software engineering (or is it)? • What do you think we will be focusing on in this class?

  3. What is Software Engineering? • According to Wikipedia: “Software engineering (SE) is a profession dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build”

  4. What is Software Engineering? • What is the problem with the previous definition? • A better definition: “SE is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software” – IEEE • Have you been doing this in your classes so far? • Parnas (super famous CS guy) defined software engineering as the “multipersonconstruction of multiversionsoftware” • Your projects so far were (probably) neither multiperson nor multiversion

  5. Software is expensive to maintain • Maintenance activities consume 70-90% of the total lifecycle cost of software, summing to over $70 billion per year • We want to “get it right” the first time • But as we’ll see this is non-trivial

  6. Why is it so hard? • Lots of “parts”. Many more than mechanical devices • Dishwasher - 128 parts • Car - 14,000 parts • Space shuttle - 2.5 million parts • Red Hat Linux 7.1 - 30 million source lines of code (SLOC) • Mac Office - 30 million SLOC • Using 70 programmers = 428,000 SLOC / programmer • But those are big… what about “normal size programs”? • Average programmer SLOC (Source lines of code) / day = 100 • 5 days/week * 52 weeks/year = 26,000 SLOC / year • 15 programmer team = 390,000 SLOC / year

  7. Why is it so hard? (continued) • We’re a young field • ENIAC/ MARK-I in 1946 • FORTRAN - 1957 • But giant - As of 2004, the U. S. Bureau of Labor Statistics counts 760,840 software engineers holding jobs in the U.S.; for comparison, in the U.S. there are some 1.4 million practitioners employed in all other engineering disciplines combined. • Still more art than science • Everything we do is “new”. (We don’t build the exact same house 30 times.)

  8. The art of software development • Fred Brooks (another super famous CS guy): there are two kinds of challenges in software development • Accidental (can be solved by better tools and languages) • Essential (not helped by new tools) • Brooks argued that there is no single “silver bullet” for solving these essential problems • The “software crisis” was an observation (as Parnas points out) that software projects are/were continually late and over budget • This type of crisis cannot be fixed by better tools alone

  9. Why do projects fail? Question: • Unrealistic or unarticulated project goals • Inaccurate estimates of needed resources • Badly defined system requirements • Poor reporting of the project's status • Unmanaged risks • Poor communication among customers, developers, and users • Use of immature technology • Inability to handle the project's complexity • Sloppy development practices • Poor project management • Stakeholder politics • Commercial pressures • How many of these are caused by technical incompetence in your developers? • 0 • 5 • 8 • All of them

  10. Wear vs. Deterioration

  11. The big difference between software and hardware • Software, unlike hardware, can be easily changed • People often make the mistake that because software is malleable, it can (and should) be easily changed

  12. Software Quality Challenges • Correctness, reliability, robustness • Performance: an external quality based on requirements • Usability • Verifiability • Maintainability: corrective, adaptive, perfective • Repairability and evolvability • Reusability, portability, understandability • Interopability • Productivity, timeliness, visibility • How do we MEASURE these qualities?

  13. Software – True or False? • If we get behind schedule we can add more programmers to catch up • A general statement of objectives is sufficient to begin writing programs - we can fill in the details later • Project requirements change, but change can be easily accommodated because software is flexible • Once we write the program and get it working our job is done • Software engineering will make us create unnecessary documentation and will invariably slow us down

  14. Fixing the problem Software engineering! • Software engineering is really just a set of ideas and tools to use (when it makes sense) to give you a higher likelihood of success on a software project. • Will your project fail if you don’t use any software engineering techniques? No…. but you have a better chance at success if you do.

  15. A Generic Approach • Common problem in software engineering has been an emphasis on the product or the process, but not at the same time. • We package techniques and methods together into a methodology, based around basic principles: • Rigor and formality • Separation of concerns • Modularity • Abstraction • Anticipation of change • Generality • Incrementality

  16. A Generic Framework • Communication • Heavy collaboration with the customer, other stakeholders and encompasses requirements gathering and related activities • Planning • Establish a plan for the work. Technical task to be conducted, risks, needed resources, work products to be created, and a schedule • Modeling • Creation of models to allow the customer and the developer to better understand the requirements and design that will achieve those requirements • Construction • Combines code generation and testing required to uncover errors in the code • Deployment • The software (as a complete entity or partially complete increment) is delivered to the customer who evaluates it and provides feedback.

  17. Umbrella Activities • Software project management • Formal technical reviews • Software quality assurance • Software configuration management • Work product preparation and production • Reusability management • Measurement • Risk management

  18. The Process Model:Adaptability • The framework activities will always be applied on every project ... BUT • The tasks (and degree of rigor) for each activity will vary based on: • the type of project • characteristics of the project • common sense judgment; concurrence of the project team

  19. Question • Pick any one of the project types below and tell me which process activity would be emphasized or deemphasized and why • Framework Activities • Communication • Planning • Modeling • Analysis of requirements • Design • Construction • Code generation • Testing • Deployment • Project Types: • 1.Space Shuttle control system • 2.Web-based calendar • 3.Embedded controller in your refrigerator • 4.Automatic “daily fortune” text-messenger

  20. How to solve any problem • Polya 1945 • Understand the problem • Plan a solution • Carry out the plan • Examine the result for accuracy • Do these agree with our basic framework? communication, planning, modeling, construction deployment?

  21. The Waterfall Model • Do all process steps in the following order (this is generally thought of as the most basic model) 1998, the Standish Group analyzed 23,000 projects to determine failure factors. The top reasons for project failure, according to the report, were associated with waterfall practices. - http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf

  22. Different families of models Prescriptive Agile • Goal: Higher Quality Software • Philosophy: • Bring order to chaos • Provide repeatability/consistency • Provide ability to control • Provide ability to coordinate teams • Goal: Higher Quality Software • Philosophy: • Individuals and interaction over process and tools • Working software over large documentation • Customer collaboration over contract negotiation • Responding to change over following a plan Which is probably better for large teams? A. Prescriptive B. Agile C. Same Which is probably better for a web application? Which is probably better for Mars rover control system? Which is produces better software?

  23. Project • Team decisions due tomorrow/today (depending on section) • One member of the group post to blackboard a document containing your team name, and the names and emails of the members of your team • 4-5 students per team • I will then set up accounts for teams on XP-Dev; you will be emailed information

  24. Project • Every team member download, install, and get their open-source project running. • If you are choosing to work with Jtidy: • There is an example driver file that should run with no errors • You will be treating Jtidy as “version 1” of a software product you’re going to work on, in groups, over the semester • Part of this project will be to simulate working in the real world – it is your responsibility to read the documentation on the Jtidy website in order to get a working version installed. • You can ask anyone you want for help with this, but try to use the professor/TA as your last resort – Google is your friend!

  25. Homework • See the class schedule

More Related