John F. Bergin               

Bellevue, WA

(425) 242-1394

John.F.Bergin@Comcast.net                            Resume

Word Formatted Resume (Right Click and "Save Target As")

Cover Letter                                                    White Papers                                            Code Examples

Senior Software Engineer                                                                                                                                                                                                          

Work In Progress...!

Software Engineering Strategies

by John F. Bergin

    Software Engineering Methodology

    One of the benefits of working as a consultant in the Software Engineering field is the opportunity to observe and take part in the different approaches 

    to developing software by different companies in different industries.  Each industry has different requirements and challenges with respect to the quality

    of software, and their engineering methods differ to reflect their tolerance for defects.  Catastrophic failure in the Telecommunications industry could cost

    millions of dollars, whereas the same severity defect in the Aerospace industry could cost lives.  Although each industry strives for bug-free code, the 

    tolerance for defects is obviously different.

    The Methodology Pendulum

    A big problem facing many software engineering organizations is the "Methodology Pendulum", where the formality of the software engineering

    process swings back and forth between too much, and too little.  Over the years I have witnessed organizations swing back and forth from too much 

    formality, to practically none, and then back to too much.  It has been my experience, and it is my prediction, that shortcuts first undermine overbearing 

    methods, and eventually the entire process is abandoned within a year or two.

    The Natural Level of Formality

    The solution to the Methodology Pendulum is to find the organization's "Natural Level of Formality", where the level of process reflects the organization's

    quality requirements, and engineering resources.  The law of diminishing returns states that the number of defects found will decrease as the amount of

    testing accumulates.  In addition to this, the chances of finding catastrophic failures also decreases with more and more testing.  The determining factor is

    that the cost of engineering resources also increases, so at what point are your quality requirements satisfied?  This defect threshold is one of the determining

    factors in finding the organizations natural level of formality.

    The level of formality can be offset by the quality and breadth of an organizations' engineering resources.  The quality of engineering resources can be measured 

    in the experience of the personnel and the length of time they have been working on the project.  The size of an organization can also play a part, as larger 

    organizations usually require more process than smaller, close-knit groups.  Other considerations, such as turnover rates and budget constraints should also be 

    factored in when determining an organizations natural level of formality.

    Approach to Software Engineering

    Once the natural level of formality has been determined, one of the better ways to implement the process is with a combination of the classic waterfall approach,

    and an iterative, or "spiral" lifecycle approach.  Agile Technology uses a spiral lifecycle approach, where the classic waterfall method is distributed over smaller 

    iterations or chunks.  Each chunk contains elements of design, code, and test, and a series of prototypes are developed over the life of the development effort. 

    Although the spiral lifecycle approach is a good way of implementing software designs, the waterfall approach is still useful for release planning.  From a high level

    perspective, there are 3 basic phases of any software development effort.  The initial phase is where the objectives of the release are determined, and the initial

    design is implemented.  The intermediate phase is where the design is developed and refined, with defects documented, fixed, and re-tested.  The final phase is 

    after coding has concluded, where integration and end-to-end system tests are performed.  Although spread out over smaller iterations of the spiral lifecycle,

    all of the elements of the waterfall approach should be considered when planning the release activities. 

    Software Quality Assurance

    One of the most important and least understood disciplines in software engineering is the concept of Software Quality Assurance. Many people mistakenly

    confuse Software Quality Assurance with Software Testing. Software Quality Assurance strives to identify and improve the software engineering process,

    of which Software Testing is only a part.  Improving the software engineering process drives quality into the software products being produced.  One goal of 

    Software Quality Assurance should be to attain the natural level of formality!

    Documentation

    Software Engineering Tools

    Software Testing

    by John F. Bergin

____________________________

Copyright © 2010 by John F. Bergin.

Home