Software Engineering Processes

Linda Westfall
03/18/2009

Traceability is one of the essential activities of good requirements management.  Traceability is used to ensure that the right products are being built at each phase of the software development life cycle, to trace the progress of that development and to reduce the effort required to determine the impacts of requested changes.  This article explores:

    What is traceability?
    Why is traceability a good practice?

    How is traceability performed?

Original: February 28, 2006

Revised: March 18, 2009

Scott Duncan
02/01/2007

My involvement with standards, methodology and process issues brings me in contact with people who ask what agile methods are or what they are about.  Many have not heard of the Agile Manifesto and associated principles.  When I ask what they have heard about agile methods, I am told things like pair programming, no documentation, refactoring, iterative development, no planning, daily “stand-up” meetings, etc.  Of course, none of these get at the heart of what agile methods are “about” (beyond the fact that some are not true).

Based on listening to the creators of agile methods and reading what they have written on the subject, agile methods, above all else, seem to me to be about expanding the bandwidth and frequency of communication and about being open to change.  Essential to both of these is the existence of effective feedback, which is required for meaningful communication and productive change. The values, principles and practices of agile methods seem to flow from seeking to achieve these objectives.

Linda Westfall
03/01/2006

If the software requirements aren’t right, you won’t end up with the software that you need.  The original version of this paper was presented by Linda Westfall at the World Conference on Quality and Improvement 2005.  The updated version was published in the ASQ's Software Quality Professional Journal.  This article discusses:

  • Why: the benefits of having the right software requirements
  • What: the various levels and types of requirements that need to be defined
  • Who: identifying the stakeholders of the software requirements and getting them involved in the process
  • When: requirements activities throughout the software development lifecycle
  • How: techniques for eliciting, analyzing, specifying and validating software requirements

Date Original Version Posted: May 7, 2005

Date Updated Version Posted: March 1, 2006

Scott Duncan
09/05/2005

What’s the “right” method to use for a software development project according to all the “best practices” advice?  How would you answer this question or is this really a sensible question to ask?  Many folks advocating “lite” or agile methods would suggest there is no “best” practice you can apply across the board.  Articles and columns in IEEE and ACM publications have addressed this very point.  On the other hand, advocates of “disciplined” methods (to use the term Boehm and Turner have in their book on agile and more formal methods) would say there is vast industry experience pointing to “best practices.”  This paper, from Scott Duncan's presentation/discussion session at the 14th International Conference on Software Quality, is about beginning the process of answering some methodology related questions.

Agile Alliance - agilealliance.com

Agile Project Leadership Network - apln.org

ASQ Software Division - asq.org/software

Association for Computer Machinery - acm.org

Crosstalk, The Journal of Defense Software Engineering - stsc.hill.af.mil/crosstalk

Cyber Security & Information Systems Information Analysis Center (CSIAC) - thecsiac.com

Dilbert - dilbert.com

Extreme Programming - (XP) xprogramming.com

Extreme Programming (XP)-embedded -  xp-embedded.com

Feature Driven Development - featuredrivendevelopment.com

IEEE - Institute of Electrical and Electronics Engineers - ieee.org

IEEE Computer Society - computer.org

International Organization for Standards - iso.org

The IT Metrics and Productivity Institute - itmpi.org

Object Management Group, Unified Modeling Language (UML) - omg.org

Open Web Application Security Project (OWASP) - owasp.org

Process Impact, Karl Wieger’s website - processimpact.com

Scrum Aliance - scrumalliance.org

SEI - Software Engineering Institute - sei.cmu.edu

Software Program Managers Network - spmn.com

Software Testing and Quality Engineering -  stickyminds.com

Software Assurance: Community Resources and Information Clearing House Sponsored by the US Department of Homeland Security Cyber Security Division - buildsecurityin.us-cert.gov/swa/

SWEBOK - Software Engineering Body of Knowledge - computer.org/portal/web/swebok

Wikipedia - wikipedia.org

The Certified Software Quality Engineer Handbook, Linda Westfall, ASQ Quality Press, Milwaukee, WI, 2009.

Software Requirements, 3rd Edition, Karl E. Wiegers and Joy Beatty, Microsoft Press, Redmond, WA, 2013.

Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Suzanne Robertson and James Robertson, Addison-Wesley, Upper Saddle River, NJ, 2012.

Requirements by Collaboration, Ellen Gottesdiener, Addison-Wesley, Boston, 2002.

Writing Effective Use Cases, Alistair Cockburn, Addison-Wesley, Boston, 2001.

Capability Maturity Model Integration (CMMI) for Development, Version 1.3, Carnegie Mellon University Software Engineering Institute, Pittsburgh, PA, 2010, (available on the SEI website).

Software Architecture in Practice, 2nd Edition, SEI Series in Software Engineering, Len Bass, Paul Clements and Risk Kazman, Addison-Wesley, Boston, 2003.

Extreme Programming Explained: Embrace Change, 2nd Edition, Kent Beck and Cynthia Andres, 2004.

© 1999-2017 Westfall Team, Inc.