Software development: Difference between revisions
Pat Palmer (talk | contribs) m (Text replacement - "United States of America|American" to "American") Tag: Reverted |
mNo edit summary |
||
(One intermediate revision by one other user not shown) | |||
Line 7: | Line 7: | ||
Now that computers run much of the developed world's economies and businesses, and many [[Science|scientific]] and [[Technology|technological]] projects, that software development is [[Project management|well-managed]] and reduces the potential for user error. Software that comes out of a good development process tends to be [[Software testing|well-tested]], comprehensively documented and easy to extend. | Now that computers run much of the developed world's economies and businesses, and many [[Science|scientific]] and [[Technology|technological]] projects, that software development is [[Project management|well-managed]] and reduces the potential for user error. Software that comes out of a good development process tends to be [[Software testing|well-tested]], comprehensively documented and easy to extend. | ||
Due to the nature of software development, it is not always amenable to normal management techniques. The | Due to the nature of software development, it is not always amenable to normal management techniques. The [[United States of America|American]] software engineer [[Fred Brooks]] wrote an influential book in 1975 called ''[[The Mythical Man-Month]]'', describing common flaws in software development (Brooks managed the team at [[IBM]] which built [[OS/360]]). The main idea is that because of the time required to train programmers on a project, it does not reduce the time taken to build a piece of software if you add more programmers (see [[Brooks's law]]). He also noted that most first attempts to build a piece of software tend to bring up some fundamental flaws in the design, and that once you have learned this, you should throw it away - which he described as "plan to throw one away". | ||
In recent years, a model of software development called [[Agile software development|Agile]] has become popular that stresses the need for rapid iterative development, prototyping (often in a higher-level scripting language like [[Ruby (programming language)|Ruby]] or [[Python programming language|Python]], before being implemented in a lower-level language if necessary), collaboration and adaptability. To this end, those working on projects following Agile methodology attempt to perform 'continous build' - that is to say that software is developed, built and tested in rapid cycles, so that errors can be fixed quickly, rather than waiting until the testing period. Many also use [[unit testing]], a system that allows developers to see how changes to parts of the codebase affect other parts, some even adopting a design principle based on the heavy use of testing - [[test-driven development]]. | In recent years, a model of software development called [[Agile software development|Agile]] has become popular that stresses the need for rapid iterative development, prototyping (often in a higher-level scripting language like [[Ruby (programming language)|Ruby]] or [[Python programming language|Python]], before being implemented in a lower-level language if necessary), collaboration and adaptability. To this end, those working on projects following Agile methodology attempt to perform 'continous build' - that is to say that software is developed, built and tested in rapid cycles, so that errors can be fixed quickly, rather than waiting until the testing period. Many also use [[unit testing]], a system that allows developers to see how changes to parts of the codebase affect other parts, some even adopting a design principle based on the heavy use of testing - [[test-driven development]].[[Category:Suggestion Bot Tag]] |
Latest revision as of 16:01, 19 October 2024
Software development is the process of satisfying the requirements of a user by creating a piece of software that matches those needs. The process itself has a great many arguments and philosophies as to the best way to develop software that is reliable, scalable, amenable to changing requirements and best meeting the often vague and unspecified needs of the client.
Developing software includes collecting the requirements of the user, turning these into an implementable functional specification, figuring out how these will be architected, designed, implemented and deployed, while making it easy to maintain and extend.
Now that computers run much of the developed world's economies and businesses, and many scientific and technological projects, that software development is well-managed and reduces the potential for user error. Software that comes out of a good development process tends to be well-tested, comprehensively documented and easy to extend.
Due to the nature of software development, it is not always amenable to normal management techniques. The American software engineer Fred Brooks wrote an influential book in 1975 called The Mythical Man-Month, describing common flaws in software development (Brooks managed the team at IBM which built OS/360). The main idea is that because of the time required to train programmers on a project, it does not reduce the time taken to build a piece of software if you add more programmers (see Brooks's law). He also noted that most first attempts to build a piece of software tend to bring up some fundamental flaws in the design, and that once you have learned this, you should throw it away - which he described as "plan to throw one away".
In recent years, a model of software development called Agile has become popular that stresses the need for rapid iterative development, prototyping (often in a higher-level scripting language like Ruby or Python, before being implemented in a lower-level language if necessary), collaboration and adaptability. To this end, those working on projects following Agile methodology attempt to perform 'continous build' - that is to say that software is developed, built and tested in rapid cycles, so that errors can be fixed quickly, rather than waiting until the testing period. Many also use unit testing, a system that allows developers to see how changes to parts of the codebase affect other parts, some even adopting a design principle based on the heavy use of testing - test-driven development.