199 lines
12 KiB
Plaintext
199 lines
12 KiB
Plaintext
{
|
||
"cells": [
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# An introduction to software development"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"## Introduction"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"This OpenLearn free course is about software development, the discipline concerned with the methods, techniques and processes of building software artefacts: today's software development professional will need an in-depth knowledge of this discipline to be able to create software which best serves the needs of our digital economy and society. Software development is also a fast moving discipline, so that the software development professional also needs effective strategies for finding materials that track its leading edge.\n",
|
||
"\n",
|
||
"This OpenLearn course is an adapted extract from the Open University course [M813 *Software development*](http://www.open.ac.uk/postgraduate/modules/m813?LKCAMPAIGN=ebook_&MEDIA=ou)."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"## Learning outcome"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"After studying this course, you should be able to:\n",
|
||
"\n",
|
||
"- Appreciate the engineering nature of software development.\n",
|
||
"- Describe key activities in software development and the role of modelling.\n",
|
||
"- Explain key concepts in software development such as risk and quality.\n",
|
||
"- Explain the basics of an object-oriented approach to software development.\n",
|
||
"- Describe a simple workflow for interacting with the published literature on software development."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"## 1 Software development as engineering"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"G.F.C. Rogers, writing in the early 1980s, defined engineering as 'the practice of organising the design and construction of any artifice which transforms the physical world around us to meet some recognised need' (Rogers, 1983).\n",
|
||
"\n",
|
||
"Rogers was not a software developer, but an engineer specialising in thermodynamics and jet-engine development. Yet his definition captures the essence of engineering and has a wide applicability which extends to software. Much of our endeavour in software development is the design and construction of software to meet come recognised need – of people, organisations or society at large – with tangible effects on the real world."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"> **Activity 1**\n",
|
||
">\n",
|
||
"> Look at Rogers' definition of engineering. How would you relate elements of that definition to your understanding of software development?"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"*Even though I had to look up what \"artifice\" means to properly understand, it helped me understand that it means deception and trickery to achieve an end goal. While I personally don't agree with software development being trickery, we as software developers do tend to force the computer to do specific things to make it more usable or to add extra functionality.*"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"### Discussion\n",
|
||
"\n",
|
||
"*Organising design and construction* can be related to what is commonly referred to as a 'software development process': if you develop software in the context of a commercial organisation, it is highly likely that you and your team will follow one such process to coordinate the construction and deployment of software.\n",
|
||
"\n",
|
||
"The *physical world around us* can be related to the context in which the software will be deployed – the context could be the way an information system is organised, the device in the case of a software controller, or the internet for a web application.\n",
|
||
"\n",
|
||
"The *recognised need* in Rogers' definition relates to the problems the software is meant to solve – what we commonly capture as requirements in software development. These problems are the reason why the software should exist, and express how software should affect its context once in operation.\n",
|
||
"\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."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"> **Activity 3**\n",
|
||
">\n",
|
||
"> Do a web search for 'software development processes'. Name three such processes that recur in your search results. What are their key characteristics, and differences with references to the activities mentioned above?"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"Due to the significant decline in the quality and reliability of mainstream search engine results — dominated by SEO-driven content farms and sponsored junk — I’ve chosen to base this response on foundational software engineering knowledge and peer-reviewed principles, rather than raw search results.\n",
|
||
"1. Incremental Development\n",
|
||
"\n",
|
||
" - Key Characteristics: Development proceeds by breaking the system into smaller functional units. Each unit is fully specified, developed, and tested before the next is tackled.\n",
|
||
" - Differences: Allows feedback and testing at each stage; contrasts with monolithic models like Waterfall. Particularly useful when requirements evolve.\n",
|
||
"\n",
|
||
"2. Iterative Development\n",
|
||
"\n",
|
||
" - Key Characteristics: The system is developed through repeated cycles, refining the same components rather than starting fresh each time.\n",
|
||
" - Differences: Focus is on learning and refining over time. Unlike Incremental, changes are expected and welcomed even in previously “finished” parts.\n",
|
||
"\n",
|
||
"3. Throwaway Prototyping\n",
|
||
"\n",
|
||
" - Key Characteristics: Early versions of the software (prototypes) are built quickly to understand user requirements, then discarded.\n",
|
||
" - Differences: Prioritises early requirement clarification. Unlike Iterative or Incremental, the prototype is not part of the final system.\n",
|
||
"\n",
|
||
"Activities Reference\n",
|
||
"\n",
|
||
"Each process reorganises the core software development activities (requirements, design, implementation, testing, maintenance):\n",
|
||
"\n",
|
||
" - Incremental and Iterative blur the lines between these activities across cycles.\n",
|
||
" - Prototyping puts most weight early on requirements and partial implementation for feedback."
|
||
]
|
||
}
|
||
],
|
||
"metadata": {
|
||
"language_info": {
|
||
"name": "python"
|
||
}
|
||
},
|
||
"nbformat": 4,
|
||
"nbformat_minor": 2
|
||
}
|