Completed Activity 2

workbook.ipynb

@@ -89,6 +89,66 @@
     "\n",
     "In this course, we take an engineering view of software development, and, guided by Rogers' definition, will explore in some detail the constituent elements of software development, and the interrelations between these elements."
    ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## 2 Software Development Processes"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "With reference to Rogers' definition, a **software development process** is the practice of organising the design and construction of software and its deployment in context.\n",
+    "\n",
+    "Effective software development processes remain the holy grail of software development over the years many contenders have emerged and then gone out of fashion. These vary in the detail of what activities they prescribe, their related artefacts, how the activities should be carried out in relation to one another, and how often each activity should be revisited. There are, however, some fundamental development activities that are well understood and common to most approaches. In very broad terms:\n",
+    "\n",
+    "- **Analysis** involves understanding the problem which software is intended to solve, i.e., the requirements in context, with **validation** as the means to check that understanding.\n",
+    "- **Design** involves describing, conceptually, a software solution that meets the requirement of the problem.\n",
+    "- **Implementation** involves realising such a solution in software.\n",
+    "- **Testing** involves making sure that the solution has certain inherent qualities, with **verification** as a means to check its adequacy with respect to the specified requirements and **validation** as a means to check that the solution does address the problem.\n",
+    "- **Deployment** involves making the developed solution available in its context of operation and use.\n",
+    "\n",
+    "Note: **validation** and **verification** are sometimes confused. One way to understand the distinction is to think of **validation** as addressing the question 'Are we solving the right problem?' and **verification** as addressing the question 'Are we solving the problem right?'"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "> **Activity 2**\n",
+    ">\n",
+    "> If requirements are validated against the problem, and the implemented system is verified against those requirements, then the system should indeed be addressing the problem. Why then do we still need to validate the system against the problem during testing?"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "*As the requirement are only a surface level understanding of the problem, this can lead to an incomplete, misinterpreted, biased or even outdated viewpoint of the problem. This isn't the only reason why there is testing during the creation phase of the system. New edge cases could be found, data patterns that once worked, no longer do due to a change of workflow or either the software developer(s) or the end users have re-evaluated their goals against the system, its validation or its verification and may find that it no longer meets their needs. Also, during testing, it may be found that the software in question may have roadblocks that make it infeasible to carry on possibly due to performance issues or unexpected interactions either from the software in question or the software developer or the end user expecting the software to work one way when the software in question actually works antithetical to that.*"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### Discussion\n",
+    "\n",
+    "The core problem is that the system needs to satisfy the requirements *in its context of operation*. During software design and construction we rely on assumptions about the properties of that context – which might turn out to be inaccurate once the system is in operation, or we may discover that there are other critical properties which we have overlooked. The context of operation of a software system is often a complex place whose characteristics and behaviour are difficult to grasp and predict completely and accurately, even with the best engineering effort."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "While this course will focus primarily on software development activities, it is important to remember the process does not end with a deployed product. The full **software life-cycle** also includes:\n",
+    "\n",
+    "- **maintainance**: make sure that the deployed solution continues to address the problem throughout the time it is in operation, and handles its **decommissioning** at the end of the life-cycle.\n",
+    "\n",
+    "Note: although software maintenance is a well understood term, some authors prefer to talk about **software evolution**, meaning that software continually changes over its life-cycle, with changes often triggered by changes in context and in stakeholders' needs. As a consequence, software development activities typically carry on post-deployment as new releases of the software are developed and deployed."
+   ]
   }
  ],
  "metadata": {