diff --git a/ch04packaging/05Process.ipynb b/ch04packaging/05Process.ipynb index 02615a78..03482cca 100644 --- a/ch04packaging/05Process.ipynb +++ b/ch04packaging/05Process.ipynb @@ -139,14 +139,7 @@ "The waterfall approach to software engineering comes from the engineering tradition applied to building physical objects,\n", "where Architects and Engineers design buildings, and builders build them according to the design.\n", "\n", - "Software is intrinsically different:\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "### Software is not made of bricks" + "Software is intrinsically different: **software is not made of bricks.**\n" ] }, { @@ -158,30 +151,20 @@ "Software systems differ in material respects from physical systems.\n", "Much of this has been rehearsed by Fred Brooks in his classic\n", "['No Silver Bullet'](http://ieeexplore.ieee.org/xpl/login.jsp?reload=true&tp=&arnumber=1663532&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1663532) paper.\n", - "First, complexity and scale are different in the case of software systems: relatively functionally simple software systems comprise more independent parts, placed\n", + ">\n", + ">First, complexity and scale are different in the case of software systems: relatively functionally simple software systems comprise more independent parts, placed\n", "in relation to each other, than do physical systems of equivalent functional value.\n", - "Second, and clearly linked to this, we do not have well developed components and composition mechanisms from which to build\n", + ">\n", + ">Second, and clearly linked to this, we do not have well developed components and composition mechanisms from which to build\n", "software systems (though clearly we are working hard on providing these) nor do we have a straightforward mathematical account that\n", - "permits us to reason about the effects of composition.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "### Software is not made of bricks" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "\n", + "permits us to reason about the effects of composition.\n", + ">\n", + ">\n", "> Third, software systems operate in a domain determined principally by arbitrary rules about information and symbolic communication whilst the\n", "operation of physical systems is governed by the laws of physics.\n", "Finally, software is readily changeable and thus is changed, it is used in settings where our uncertainty leads us to anticipate the need to change.\n", "\n", - "-- Prof. [Anthony Finkelstein](http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/), UCL Dean of Engineering, and Professor of Software Systems Engineering\n" + "-- Prof. [Anthony Finkelstein](http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/), UCL Dean of Engineering, and Professor of Software Systems Engineering" ] }, { @@ -231,7 +214,7 @@ "> limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other\n", "> Agile Methodologies as \"hackers\" are ignorant of both the methodologies and the original definition of the term hacker\n", "\n", - "-- Jim Highsmith.\n" + "-- Jim Highsmith\n" ] }, { @@ -366,17 +349,17 @@ "metadata": {}, "source": [ "\n", - "* Don't ignore design\n", - "* See if there's a known design pattern that will help\n", - "* Do try to think about how your code will work before you start typing\n", - "* Do use design tools like UML to think about your design without coding straight away\n", - "* Do try to write down some user stories\n", + "* Don't ignore design.\n", + "* See if there's a known design pattern that will help.\n", + "* Do try to think about how your code will work before you start typing.\n", + "* Do use design tools like UML to think about your design without coding straight away.\n", + "* Do try to write down some user stories.\n", "* Do maintain design documents.\n", "\n", "BUT\n", "\n", - "* Do change your design as you work, updating the documents if you have them\n", - "* Don't go dark -- never do more than a couple of weeks programming without showing what you've done to colleagues\n", + "* Do change your design as you work, updating the documents if you have them.\n", + "* Don't go dark -- never do more than a couple of weeks programming without showing what you've done to colleagues.\n", "* Don't get isolated from the reasons for your code's existence, stay involved in the research, don't be a Code Monkey.\n", "* Do keep a list of all the things your code needs, estimate and prioritise tasks carefully.\n", "\n"