| content | |||||||||||||||||||||||||
| Software development process | |
| Activities and steps | |
|---|---|
| Requirements · Specification Architecture · Design Implementation · Testing Deployment · Maintenance |
|
| Models | |
| Agile · Cleanroom · Iterative · RAD RUP · Spiral · Waterfall · XP · Scrum |
|
| Supporting disciplines | |
| Configuration management Documentation Quality assurance (SQA) Project management User experience design |
|
| Tools | |
| Performance analysis Debugger |
|
Software development is the translation of a user need or marketing goal into a software product.[1][2] Software development is sometimes understood to encompass the processes of software engineering combined with the research and goals of software marketing to develop computer software products.[3] This is in contrast to marketing software, which may or may not involve new product development.
It is often difficult to isolate whether engineering or marketing is more responsible for the success or failure of a software product to satisfy customer expectations. This is why it is important to understand both processes and facilitate collaboration between both engineering and marketing in the total software development process. Engineering and marketing concerns are often balanced in the role of a project manager that may or may not use that title.
Because software development may involve compromising or going beyond what is required by the client, a software development project may stray into processes not usually associated with engineering such as market research, human resources, risk management, intellectual property, budgeting, crisis management, etc. These processes may also cause the role of business development to overlap with software development.
In the book "Great Software Debates", Alan M. Davis states in the chapter "Requirements", subchapter "The Missing Piece of Software Development":
| “ | Students of engineering learn engineering and are rarely exposed to finance or marketing. Students of marketing learn marketing and are rarely exposed to finance or engineering. Most of us become specialists in just one area. To complicate matters, few of us meet interdisciplinary people in the workforce, so there are few roles to mimic. Yet, software product planning is critical to the development success and absolutely requires knowledge of multiple disciplines.[4] | ” |
Contents |
Various approaches to software development
There are several different approaches to software development, much like the various views of political parties toward governing a country. Some take a more structured, engineering-based approach to developing business solutions, whereas others may take a more incremental approach, where software evolves as it is developed piece-by-piece. Most methodologies share some combination of the following stages of software development:
- Gathering requirements for the proposed business solution
- Analyzing the problem
- Devising a plan or design for the software-based solution
- Implementation (coding) of the software
- Testing the software
- Maintenance and bug fixing
These stages are often referred to collectively as the software development lifecycle, or SDLC. Different approaches to software development may carry out these stages in different orders, or devote more or less time to different stages. The level of detail of the documentation produced at each stage of software development may also vary. These stages may also be carried out in turn (a “waterfall” based approach), or they may be repeated over various cycles or iterations (a more “Xtreme” approach). The more extreme approach usually involves less time spent on planning and documentation, and more time spent on coding and development of automated tests. More “extreme” approaches also promote continuous testing throughout the development lifecycle, as well as having a working (or bug-free) product at all times. More structured or “waterfall” based approaches attempt to assess the majority of risks and develop a detailed plan for the software before implementation (coding) begins, and avoid significant design changes and re-coding in later stages of the software development lifecycle.
There are significant advantages and disadvantages to the various methodologies, and the best approach to solving a problem using software will often depend on the type of problem. If the problem is well understood and a solution can be effectively planned out ahead of time, the the more "waterfall" based approach may work the best. If, on the other hand, the problem is unique (at least to the development team) and the structure of the software solution cannot be easily envisioned, then a more "extreme" incremental approach may work best.
See also
References
- ^ Birrell, N.D. (1985). A Practical Handbook for Software Development. Cambridge University Press. ISBN 0-521-25462-0.
- ^ DRM Associates (2002). "New Product Development Glossary". Retrieved on 2006-10-29.
- ^ Jim McCarthy. "Dynamics of Software Development" (August 1, 1995), pp:10-30
- ^ Alan M. Davis. Great Software Debates (October 8, 2004), pp:125-128 Wiley-IEEE Computer Society Press
Further reading
- Luke Hohmann. "Beyond Software Architecture: Creating and Sustaining Winning Solutions" (January 30, 2003)
- Jim McCarthy. "Dynamics of Software Development" (August 1, 1995), pp:10-30
- Robert K. Wysocki. "Effective Software Project Management" (March 27, 2006), pp:72-75
- PhD, CISM, John Rittinghouse. "Managing Software Deliverables: A Software Development Management Methodology" (November 12, 2003)
- Dan Conde. "Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales" (September 1, 2002), pp:24-29
- Edward Hasted. "Software That Sells : A Practical Guide to Developing and Marketing Your Software Project" (June 10, 2005)
- A. M. Davis, "Just enough requirements management: where software development meets marketing" (May 30, 2005)
- John W. Horch, "Two Orientations On How To Work With Objects," IEEE Software, vol. 12, no. 2, pp. 117-118, Mar., 1995.
- Karl E. Wiegers, "More About Software Requirements: Thorny Issues and Practical Advice" (December 20, 2005)
