The Nature and Building of Software: An Overview of Software Engineering - Prof. Amit Shes, Study notes of Software Engineering

Download The Nature and Building of Software: An Overview of Software Engineering - Prof. Amit Shes and more Study notes Software Engineering in PDF only on Docsity! What is Software Engineering and why must I learn about it? IT 326 The Nature of Software  First assignment in IT 275 last Fall  Two weeks  Individually completed  Approximately 150 LOC (written from scratch)  Two classes  First assignment in IT 356 last Fall  Two weeks  Individually completed  Approximately 250 LOC (written from scratch)  About five classes  Last submission in IT 385.14  Cumulative work of a semester  Group of two  28 classes  Approximate 3500 LOC (mostly written from scratch) The Nature of (Building) Software  Your group projects  2 person groups, semester’s effort  Will your software development styles match?  From structure right down to class names  If not, what will you do?  Now think 4-person groups  Now think small open-source project  Now think part of a small team in a company  Which is part of a bigger team…all for one product The Nature of (Building)Software  Understanding someone else’s work  Download your favorite open-source project’s code and try to read it  Documentation, howsoever vast, is always insufficient  What does that tell you about the effort required to create “good” documentation?  Each one of you will face this at the beginning of every job!  If you’re mean enough, you get to “give back” to the person replacing you before moving on The Ubiquity of Software  Application software  Pretty much any program that you use on your computer  Fulfills some “business” needs  Spreadsheets, word processing, etc.  Code development  Internet browsing  Gaming (that’s your own business)  A majority of all software that exists and is being created  Capable of harming files to giving you the “blue screen of death” The Ubiquity of Software  Web applications  Applications that run elsewhere, present results elsewhere  Anything from simple web pages to serious number-crunching  Your web page, Facebook, twitter  Google search, Youtube, Google Docs  Booking airline tickets, paying your bills, monitoring your cell phone usage, e-filing your taxes  Unavailable services, “the glitch in AA last year that caused reservation chaos”, “vulnerabilities to hackers” The Ubiquity of Software  Many applications are hybrid  Able to work offline and online  Microsoft Outlook managing email, calendars and tasks, syncing with mail servers, Exchange servers and RSS feeds  Google Earth, a desktop application downloading and streaming data from google servers on-the-fly as the user is using the application  Norton Antivirus that scans your hard-drive, auto- scans any external devices, scans as you visit web pages and also updates itself automatically using the internet How do they do it? Many teams in a software company, often geographically dispersed, work together to design, implement and deploy a software product. The product works efficiently, offers a good user interface and works in a collaborative setting of varying scales. After collecting information about how the product is working that the product collects itself, the same teams regularly patch, update and upgrade the product physically or remotely by adding and replacing components to remove bugs, enhance existing features and introduce new features by adding to the same code base and appending to the same design, while its architecture probably serves the product throughout its life… Why exactly do we need it?  Software is everywhere, doing everything  We better do it right and get it right  Needs evolve more often than we’d like  Getting it to work is hardly a feat  Good engineering minimizes having to repeating itself  Software makes the most difficult tasks simple  To accomplish this, its makers better know WHAT they’re doing, and WHAT those tasks are A Student’s Perspective (and also many “software engineers”)  “Let us get it to work, that’s all that matters”  True only in utopia  Most of the work on a software product is in maintaining it (the dull but sad truth about the software industry)  Coding is far more exciting if you know what you’re coding A Student’s Perspective (and also many “software engineers”)  “How will I know it is of good quality until I actually implement it?”  Only theoretically true  Think about what you will do if you discover it is of bad quality AFTER you have typed it and spent loads of sleep-less and caffeine-ful hours debugging it?  Analysis and design help to sidestep that landmine  They help avoid pitfalls that can be isolated and resolved before you start implementing The “rest of the world” perspective (users and management)  “All the standards and procedures can be found in our textbook, just apply them!”  But do we?  Do the same principles and activities apply to all projects across all software companies? The “rest of the world” perspective (users and management)  “The project is delaying? Let’s put two more guys on it!”  Let me try it midway through the semester…  “The bearing of a child takes nine months, no matter how many women are assigned.” —Fred Brooks “The Mythical Man-Month”  Time spent on familiarizing the “two more” guys eats into the productivity of the team  Software tasks simply cannot be completely parallelized  More people ≠ Increased productivity  Proof that a software engineer is more than a code monkey! The general principles of SE by David Hooker  Remember the reason it all exists  To provide value to the customer  Not so we programmers can feel good about ourselves  Not because it is so cool!  So do whatever it takes to make it a success The general principles of SE by David Hooker  What you produce, others will consume  Whatever you do, someone else is going to look at it and use it  So don’t analyze, design, and code just for yourself  Design with the developers in mind  Documents with future designers and maintainers in mind  Remember, YOU MAY BE THE “OTHERS” The general principles of SE by David Hooker  Be open to the future  Even the smartest software product must evolve  Technology and requirements change too fast for us to start from scratch every time  Make your software durable  Good, solid design based on sound engineering  Ample documentation to maintain it later  Clean, simple implementation  Plan for “what-if” scenarios to evaluate your own design The general principles of SE by David Hooker  Plan ahead for reuse  What is “reuse”?  Can you give me example of “reusable code”?  Reuse has almost nothing to do with writing code in terms of classes and objects  That alone will not get you anywhere  Reusable code is always a result of good design, not clever implementation Umbrella Activities in the Software Process  Software project tracking and control  Risk Management  Software Quality Assurance  Technical Reviews  Measurement  Software Configuration Management  Reusability Management  Work Product Preparation and Production Software Process Models  Different ways of performing the software process  Emphasizing on the different activities  Suitable in different settings