{"id":18,"date":"2023-09-04T18:38:59","date_gmt":"2023-09-04T18:38:59","guid":{"rendered":"https:\/\/libraryresources.nse.org.ng\/setextbook\/front-matter\/introduction\/"},"modified":"2023-09-04T18:38:59","modified_gmt":"2023-09-04T18:38:59","slug":"introduction","status":"publish","type":"front-matter","link":"https:\/\/libraryresources.nse.org.ng\/setextbook\/front-matter\/introduction\/","title":{"raw":"Introduction","rendered":"Introduction"},"content":{"raw":"
\"Chapter<\/a><\/div>\n

Introduction<\/h2>\nI won\u2019t tell you how to be a software engineer; you\u2019ll learn that over time by doing it.\n\nInstead, this book is about software engineering methods<\/strong>\u2014ways people achieve specific objectives in [pb_glossary id=\"783\"]software engineering[\/pb_glossary]\u2014that can save your project. My hope is that after reading this book (or parts of it), you\u2019ll feel better equipped for software engineering.\n

What\u2019s Software Engineering?<\/h1>\nThe definition of software engineering<\/strong> we will use is:\n
\u201cSystematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software.\u201d (International Organization for Standardization et al., [pb_glossary id=\"1324\"]2017[\/pb_glossary]<\/span>)<\/div>\nThe definition was agreed upon by the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and the Institute of Electrical and Electronics Engineers (IEEE) and published in their glossary of systems and software engineering vocabulary (International Organization for Standardization, 2017). The 500+ page document is meant to be internationally applicable to the field of information technology.\n

What's the Purpose of Software Engineering?<\/h1>\nSoftware engineering can help people create sustainable, extensible programs that solve problems people care about. [pb_glossary id=\"784\"]Sustainable[\/pb_glossary] means it\u2019s feasible for the program to grow, exist, and be maintained. [pb_glossary id=\"785\"]Extensible[\/pb_glossary] means it\u2019s feasible to add more features.\n

What\u2019s the Philosophy Behind This Book?<\/h1>\nMy beliefs about software engineering influenced how I wrote this book. Some of my strongest beliefs about software engineering are described below.\n

Software Engineering Is Not Black and White<\/h2>\nThroughout the book, I explain how software engineering is a gray area of computer science. \u201cRight\u201d answers can be hard to find and may not be reproducible in different contexts. Software engineering as a field also keeps changing as research scientists gather new findings, engineers develop new technologies, visionaries define new [pb_glossary id=\"787\"]methods[\/pb_glossary], and the outside world changes (e.g., a pandemic happened while I was writing the first edition of this book, and that changed how software engineering teams collaborate). Whereas in programming you might ask, \u201cIs this algorithm correct?\u201d questions in software engineering are more like, \u201cHow does my team know this software is ready to release?\u201d or \u201cPeople keep misinterpreting my code; how do I shift it toward better understandability and maintainability?\u201d\n

It\u2019s Not Necessary to Study Every Detail of Software Engineering<\/h2>\nI\u2019m not going to tell you everything about software engineering because (1) what you need to know can be drastically different depending on context; (2) if I tried to, this book would be thousands of pages and possibly useless; and (3) many topics are best learned on the job. Instead, I\u2019ll introduce a set of software engineering methods that are known to be useful across multiple contexts, give guidance on when and why to use them, and point to resources for when you want more information.\n

Agile Isn\u2019t Perfect, But I Really Like It (and Other People Do, Too)<\/h2>\nThis book is geared toward [pb_glossary id=\"788\"]Agile[\/pb_glossary] software development. That\u2019s because Agile development environments have become extremely popular\u2014and because I like Agile. It matches how I think and has been appropriate for nearly all the projects I\u2019ve worked on. But you\u2019re not me, and Agile isn\u2019t the be-all and end-all, so I\u2019m planning to incorporate more from other software process models in the future.\n

What\u2019s This Book Like?<\/h1>\nThis book was written iteratively (\u201cDo something. Do it again, but better\u201d) and incrementally (\u201cDo a little more\u201d). Lots of software is written the same way.\n\nIt has eight major topics<\/strong>:\n
    \n \t
  1. Agile<\/strong>: Collaboration-oriented philosophy of creating software that values doing over comprehensive planning and documentation.<\/li>\n \t
  2. Project Management and Teamwork<\/strong>: Working in an organized way\u2014and with other people.<\/li>\n \t
  3. Requirements<\/strong>: Being clear about what\u2019s expected of the software.<\/li>\n \t
  4. Unified Modeling Language Class and Sequence Diagrams<\/strong>: A couple types of diagrams useful for communicating how your code works (or should work).<\/li>\n \t
  5. Monolith versus Microservice Architectures<\/strong>: Two contrasting high-level ways to organize code.<\/li>\n \t
  6. Paper Prototyping<\/strong>: Creating a good user interface design before coding it.<\/li>\n \t
  7. Inclusivity Heuristics<\/strong>: Guidelines for making software work well for people who are not like you.<\/li>\n \t
  8. Code Smells and Refactoring<\/strong>: Making your code nicer to work with.<\/li>\n<\/ol>\nThis book is short<\/strong> and meant to be readable<\/strong>.\n