Skip to content

Instantly share code, notes, and snippets.

@SheepTester
Last active May 18, 2023 21:53
Show Gist options
  • Select an option

  • Save SheepTester/d9dae2eab3ecf42ef04c869b66febb6c to your computer and use it in GitHub Desktop.

Select an option

Save SheepTester/d9dae2eab3ecf42ef04c869b66febb6c to your computer and use it in GitHub Desktop.
CSE 110 Content Map (craft.do is annoying)

CSE 110 Content Map

This document serves as a table of contents and map to UC San Diego’s CSE 110 - Software Engineering as taught by Thomas Powell for Spring 2023. Offerings by other instructors may vary in emphasis and content so use this material with extreme caution if somehow you have gained access to it outside the course.

This is a work in progress. I'll change this update statement when I make a major change

Week 1 - Introduction and Definitions


Summary Notes: https://www.craft.do/s/BEtiGoivUaqXO5
Backup and Detail Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F051EGK394P/1_-_se_introduction-23.pdf

Week 2 - Growing Individual Software Engineers


Summary Notes: https://www.craft.do/s/fWTsrhQJjFDYl7

Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F05283V7HB4/2_-_making_a_software_engineer.pdf

Week 3 - Creating Groups of Software Engineers, Project Prompt


Summary Notes: https://www.craft.do/s/22hg03hlJlPkBG

Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F053P8DNEM7/3_-_on_groups.pdf

Extra Item: Goofus and Gallant Cartoon Stories - this had some small tips about good and bad behaviors.

Extra Item: Animal Friends Introduction - this used vidid images from animals to show encouraged behaviors for teams. It was meant to show the commonalities of teams before we introduced the topic formally.

Week 4 - Design Engineering & Process Models


User Centered Thinking
Summary Notes: https://www.craft.do/s/7zdiANnydceeYS

Design Process
Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F056UQG7132/5_-_design_process.pdf


Project Reveal

Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F053VUQ1C83/4_-project_reveal_and_process_problem_preview-_sp23.pdf (Note these concepts are inherent and are not tested in a direct manner, though many of the aspects of your project, Fortune Telling, LLMs / AI, etc. may be useful to you as examples. The decks are placed here solely for completeness.


Extra Item: Life of Chad Example for User Thinking

Extra Item: In class break down of thinking patterns and process models

Week 5 - Process Models, Design Engineering, Specifications, and Requirements


Process Model

Summary Notes: https://www.craft.do/s/bzm9y0vVAxD6w9
Process Model Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F0560PXFMK2/6_-_process_model_intro.pdf

Specs and Reqs

Summary Notes: https://www.craft.do/s/2L4dXsINIk9SO4
Specs and Reqs Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F056HPT6RTM/9-specs_and_reqs.pdf

Week 6 - Architecture, Agile Up Close, Process Engineering, Building Practices


Architecture
Summary Notes: https://www.craft.do/s/9xvtpmwdyKidIs
Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F057Q3S2PLP/10_-_architecture.pdf

Agile Up Close
Summary Notes: https://www.craft.do/s/4sENC8e2F6IvuR
Slides: https://cse110-spring2023.slack.com/files/U04UPM79ZBK/F0574BWC4CD/8_-_agile_methods.pdf
Extra Item: In class exercises on Agile

Week 7 - Process Engineering, Building Practices, Midterm


Building and Dev Part 1

Week 8 - Process Engineering, Building Practices Contd, Testing Intro

Week 9 - Testing Conclusion, Distribution and Ops

Week 10 - Closing the Loop to Repeat, Guest Speakers, Conclusions and Review

Final Presentation and Conclusion


{
const ID = 'BEtiGoivUaqXO5'
const escape = s => s.replaceAll('&', '&amp;').replaceAll('<', '&lt;').replaceAll('>', '&gt;').replaceAll('"', '&quot;').replaceAll('\n', '<br>')
const { blocks, rootBlockId } = await fetch(`https://www.craft.do/api/share/${ID}?enablePagination=true`).then(r => r.json())
// const blockBetter = Object.fromEntries(blocks.map(({blocks,style, content,id}) => [id, {blocks,style:JSON.parse(style)}]))
const blocksMap = Object.fromEntries(blocks.map(({blocks,style, content,id,type,rawProperties}) => [id, {content,blocks,style:JSON.parse(style),type,rawProperties:JSON.parse(rawProperties)}]))
for (const block of Object.values(blocksMap)) {
block.blocks = block.blocks.map(a => blocksMap[a])
}
console.log(Object.fromEntries(blocks.map((block) => [block.id, {content:block.content,...block}])))
const { content: title, blocks: cblocks } = blocksMap[rootBlockId]
// new Set(Object.values(blocksMap).filter(b => b.style.textStyle !== 'body'))
let output = `# ${title}\n\n`
let indentLevel = 0
for (const {content, style:{_runAttributes = [],indentationLevel,listStyle}, type, rawProperties} of cblocks) {
while (indentLevel > indentationLevel) {
indentLevel--
// output += '</details>\n\n'
}
if (type === 'image') {
//console.log(content, rawProperties)
output += `<img src="${escape(content)}" width="${rawProperties.previewImageWidth}">\n\n`
continue
}
if (listStyle === 'toggle') {
// output += `<details open>\n\n<summary><h${indentationLevel + 1}>`
output += `<h${indentationLevel + 2}>`
}
else output += '<p>'
let last = 0
for (const {isBold,isCode,isItalic,isStrikethrough,range:[start,len],linkURL} of _runAttributes.sort((a, b) => a.range[0] - b.range[0])) {
// NOTE: there can be overlappng runattributes. not dealing with them
if (start < last) continue
const end = start + len
output += escape(content.slice(last, start))
if (isBold) output += '<strong>'
if (isItalic) output += '<em>'
if (isStrikethrough) output += '<del>'
if (linkURL) output += `<a href="${escape(linkURL)}">`
if (isCode) output += '<pre>'
output += escape(content.slice(start, end))
if (isCode) output += '</pre>'
if (linkURL) output += `</a>`
if (isStrikethrough) output += '</del>'
if (isItalic) output += '</em>'
if (isBold) output += '</strong>'
last = end
}
output += escape(content.slice(last))
if (listStyle === 'toggle') {
output += `</h${indentationLevel + 2}>`
// output += `</h${indentationLevel + 2}></summary>\n\n`
indentLevel = indentationLevel
} else output += '</p>\n\n'
}
while (indentLevel > 0) {
indentLevel--
// output += '</details>\n\n'
}
console.log(window.output = output)
}

Lecture Notes - SE Intro - Demystification, Definition, and Defiance

Premise - First We Must Understand Our Definition and Biases

Software Engineering is defined in numerous ways. It is quite interesting that for a discipline focused on engineering precision and a scientific process it is a bit problematic there is such variability. The goal here when introducing SE is to show you the variability, create our own working definition and most importantly explore our pre-existing biases about the topic. Very often for those of us learning computer science and programming first in an academic setting we have a strong belief that the activity called Software Engineering is primarily code focused when in reality it is more a socio-technical process which code is maybe 30-40% of the emphasis. Breaking that bias down and understanding the essence of engineering beyond SE is a key point of the introduction.

Key Support Points and Ideas

Why So Much Fail and Worry?

A number of statements from various important SE folks like Alan Cooper, Fred Brooks and others show that even the most advanced SEs are more than a bit worried that our engineering rigor and ability to find constant rules are more than a bit lacking.

Cooper is cynical enough to think success is almost an accident.

Numeric costs of trillions of wasted dollars are cited just for the US alone

The Professor has personally seen organization spends millions for things that can be accomplished for a thousands. Further we have seen that even successful projects are lacking engineering formalism even in some of the most financially successful companies. Given the security failures, data leakages, and out right crashes it isn’t difficult to see the fail.


The question that is open is why do many people with significant experience worry and why is there so much observable fail? This cannot be settled in this course, but the aim is to arm us with tools to find our answers and get on a path towards more rigor and less luck.

Definitions Vary

Per Wikipedia: Software Engineering is the study an application of engineering to design, development and maintenance of software.

Per the definition above Engineering is key to understand.


Engineering is defined as a creative application of scientific principles to design or develop software with awareness of the design, to perform intended functions and understand and forecast the behavior of the system under specific conditions with some emphasis on economics and safety.

More simply put - use science to build something that we know why/how it was done, can reason about it under normal conditions, it does what it should and is done economically and safely!


Other definitions try to be a bit simpler

Parnas: SE is the multi-person construction of multi-version programs


Farley: Software engineering is the application of empirical, scientific approach to finding efficient, economic solutions to practical problems in software.

Also Farley States (Paraphrased): Software Engineering = Design Engineering + Production or Process Engineering


I tend to prefer Farley’s break-up and the alternative view above as it shows the more creative side and more constructive side of the pursuit as quite different. The production engineering tends to share more rigor and process like other engineering disciplines while the design portions tends to follow more design thinking and creative processes. The actual mixture of emphasis is likely to vary depending on project and situation. For example, start-up heavier on design engineering, critical and mature system more on production engineering.

Testing and interview wise you should be able to succinctly define SE in your own manner hitting some of these points. Also you must accept that clearly if so many luminaries can’t agree on a definition it might be quite a bit fuzzer that some sort of “physics of programming” I personally want a very concrete definition, but that lack of is a key problem for why we often don't succeed in SE as what matters varies from person to person, organization to organization.

The Topic is Huge

A significant reason we have definitional trouble is that the topic is broad and deep. Compare SE to say Skyscraper construction. In a large scale construction project we have physics and structural engineering, materials, architectural, economics, various subsystems from electrical, hvac, etc., project management, regulations, safety, interior design, and much more. Software is just as varied and each of the knowledge areas (KA)s a total of 15 of them is a massive topic

It is unrealistic to expect to master SE in a short period of time like a quarter or semester. This is likely a career level process and some individuals may only focus on a particular knowledge area as they are that broad. I purposefully expose you to this in the course because I think being more constrained and focused absolutely sets you up for a certainty you simply shouldn’t have so early in your study of the topic.

Test Note: Please be able to roughly identify these topics. Two of them Computing Foundations and Mathematics are not covered in the course and are assumed knowledge at a basic level. Engineering Foundations is weaved in constantly as opposed to a specific topic. The other topics are touched on in varying degrees as the class unfolds with the most emphasis on Requirements, Design, Testing, Process and Methods, Professional Practices, Quality and Testing.

Beyond Test: Note that the field is simply too expansive to be a deep expert in ALL aspects of SE.

SE >>> Coding

The previous section on SWEBOK should clearly show that coding is just a portion of the SE activity. The amount varies depending on your role and the organization, but coding generally makes up below 50% of the activity and often far less in complex systems.

This shouldn’t be debatable really, but our biases with significant learning emphasis on coding may clang with this thought. A few examples of large organizations that state this reality were provided by Google to dispell some idea that it is different if you just get to some fabled land of engineering.

SE is Less Technical and More People Oriented

Following along the SE != Coding idea, SE deeply focuses on people issues be it end user or team focused. Amongst senior engineers this is not at all debatable, amongst junior engineers it can be quite triggering to the point of completely disbelieved. Plenty of folks have said this over the year such as DeMarco (Peopleware) and many others. A few supporting statements are provided to show this reality goes far beyond the Professor who subscribes to this so much that I believe that is the true cause of why software projects fail.

Embracing Our Biases

If previous iterations of SE courses is a guide some of these introduction points can be quite troubling to those who want a precision and predictability implied by the coding tasks they have encountered in an academic setting as well as what the word engineering implies.

I believe that if you understand that you may have biases about what you believe the topic to include you’ll find your way to a good definition and emphasis that serves you well. Moving from a fixed mindset to more of an open growth mindset is useful.

As mature engineers we should have strong opinions, but also hold them weakly especially if new information changes our view.

Are SEs Really Engineers?

We read a paper about the loose application of engineer to the activities we perform and professional posture we preform them under. I would agree that the essence of engineering is often missing and many with the SE title are actually just coders. A professionalization of the SE space may be required to address our failings and improve our industry. I am hopefully that may happen, but for now we start with just admitting at least some of the criticisms leveled at SEs are at least partially true.

To address this challenge we performed an “Individual Engineer Statement” activity to define what our SE aims are and take more formal control over our working definition and exceptions about engineering. Likely that definition will evolve over your career or even in the class itself.

Test or not you should have a short version of your working definition of what engineering means to you and what you are planning on doing to improve yourself to live that defintion.

Conclusion

It is hard to talk reasonably about a topic if the definition is unclear. Sadly the definition of SE is in fact somewhat unclear and I posit it is still evolving. We spent some time defining the topic the best we can, seeing the overlaps, and admitting that it is a bit of a moving target. We can say that SE is certainly much greater than coding. However, its’ size is also a significant part of the definition problem is the sheer size of the topic - it’s huge (15 areas!). We also need to acknowledge our biases that grow both in how we experience learning about computing as well as social media or industry beliefs. Being aware of our biases and being willing to think about strong opinions and humorous criticisms may serve as a useful inoculation against a dogmatic view of the topic.

Epilogue - Why the Memes Matter

If we can’t poke fun at ourselves and our industry we are unlikely to be able to have the safe conversations necessary to take a hard look both at what we are doing well and quite poorly. The Meme portion of the introduction lecture had numerous examples of fails and absurdities about SE and learning SE in an academic setting. The vast majority of these were NOT MADE BY THE PROFESSOR. While I certainly collected them I make this point explicitly as it shows you than quite a number of people seem to encounter the more than occasional SE absurdity and they made Memes as a way to cope or share their frustrations and add a little levity into a challenging environment. In general that is a useful tactic and being able to take yourself a bit less serious especially as things go wrong can be a valuable skill. In conclusion these ideas are not very unusual and if you feel they are wrong you might want to use them as a tool to reflect upon your own biases and beliefs.

TL;DR - the memes matter and may remind you of key ideas or failings, but they are more to prompt you than to be studied for a test or class project.

Test Questions

Defining Software Engineering in Your Own Words

As there appears to be no exacting definition of SE, please attempt to explain it yourself using common definitions and how you understand it. Try to include the ideas from the class, Wikipedia, etc. for full credit.

Why So Many Definitions?

Now that you have defined SE in your own words and acknowledge the varying definitions explain why there are so many variations. Hint: Consider breadth of topics, type of projects, risk & impact, practitioner background, and more.

To Professionalize or Not?

We read a provocative paper about if Software Engineers are engineers or not. This prompted us to write a personal statement and make a plan to understand what we wanted to be, but in this question we meet this professional engineer point head on. Do you think it is useful for us to professionalize, to have certification, standards and practices, and so on? Explain why you think this is a good idea and bad idea. The best answers may argue both sides to show deep consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment