|
Author |
Article |
Year |
Read |
|
Benefits and Effective Application of Software Engineering Standards |
2002 |
12-Aug-12 |
|
|
Key words |
|||
|
Quality Management, medical device, software development standard, |
|||
|
Summarizing comments |
|||
|
The primary purpose of this paper (Tuohey, 2002) is to document lessons learned and insights gained over several years in applying software engineering standards in the Aerospace sector. This article triggered my interest as it relates to sw engineering environments which need to address safety issues. Coming from the medical device industry and now working in defense industry I expected to engage easily with this article and be able to compare and contrast my own insights with the ones presented by Tuohey. One of the first observation Tuohey mentions is the application of software engineering standards within the context of other system aspects. In the NCIA Nato Programming Centre, this is certainly the case and we typically do not treat software engineering so differently than system engineering. RTCA/DO-178B is a standard widely used in the aerospace factor. I do not know if our Air Command and Control Systems are compliant with this standard, but I am certain the standard applied by ` is pretty alike to RTCA/DO-178B. Specifically as RTCA/DO-178B targets data link communications. In (RTCA/DO-178B, 1992), software is viewed as part of a wider system or equipment and the primary focus is on certifying that system or equipment. The standard recognizes 5 categories for systems based on their impact in case of failure, comparable to the safety levels within the medical device industry. Systems or parts of the system which provides higher risk severity, are subject to more and tougher process and documentation criteria. The second standard introduced is the ESA PSS-05-0 (1991), which is said to be more directive and specific, to the level of to the level of prescribing the use of specific document templates. There is no safety level and it is left to the interpreter to decide what level of tailoring is suitable for the systems under development. I consider this an invitation to treat every part of the system alike. The third standard introduced is IEC 61508-3 as a product safety standard, but the author quickly recognizes that it is highly compatible to RTCA/DO-178B. The last standard is the one that I am most familiar with: the USA Food & Drugs Administration’s guidelines for medical device software, particular the different documentation requirements for 510(k) premarket submissions of minor, moderate or major level of concern medical device software. Tuohey claims the flow chart to determine your level of concern is clear. It probably is; it was just that I was tasked to argue that Pie Medical Imaging’s products were considered a ‘minor level of concern’ and I had to try to find arguments to justify this conclusion. Therefor I probably have struggled with this flow chart to decide on the ‘level of concern’. I actually have difficulties to see the lessons learned aspect of applying these standards. Tuohey refers to an article by T. McGibbon (1999) how software Levels C and D “fit” in the context of investigations of the business case for software process improvements, particularly in terms of providing guidance on how to prioritize improvement measures. McGibbon reports significant benefits due to collective software improvement measures such as moving an organization from CMM Level 1 to Level 2. McGibbon also reports on the results of some specific process improvements and finds, in particular, very substantial benefits (better and earlier detection of errors, savings in test and integration, improved teamwork, etc.) due to the introduction of inspections. Tuohey recognizes that the standards are predominantly targeting implementation at the level of a single software development project, whereas the organization-wide implementation is considered widely as important. The article continues with lists of process improvement aspects, which I do not consider to fit that well. On a number of occasions, I have been confused by the title of an article related to standards. How often does a title talk about the benefits of a standard, but then in the main body predominantly talk about the benefits of the activities that the standard has mentioned. I don’t necessarily need a cooking book to be able to prepare food and still my family’s hunger. I do not need a software development standard telling me to manage my requirements to actually manage and meet them in my software product. What is the contribution of these reference documents? I see their benefits in pre-defining the arrangements as a bench mark to tailor and adapt the activities, in the defined terminology they provide to communicate the actual arrangements and in their ability to provide confidence that the work will be done up to a desirable quality. |
|||
|
Interesting quotes |
|||
|
“In the past, rigorous software engineering standards were imposed mainly on certain kinds of software development, particularly those with safety impact or with stringent reliability requirements or of a clearly mission-critical nature (such as the onboard control of an unmanned satellite)” “there is a need to apply and extend what has been learned in applying strict software engineering standards in relatively specialized areas to much wider fields” |
|||
|
Actions |
Due date |
Status |
|
|
1. Read and summarize |
14-Aug-12 |
Done |
|
|
2. Read McGibbon (1999) A business case for software process improvement revised—measuring return on investment from software engineering and management, Air Force Research aboratory contractno. SP0700-98-4000, http://dacs.dtic.mil/techs/roispi2, Data & Analysis Center for Software (DACS), ITT Industries, Advanced Engineering and Sciences Division, 775 Daedalian Drive, Rome, NY 13441-4909 |
01-Sep-12 |
Open |
|
Personal Blogs
Tuohey (2002) - Benefits and Effective Application of Software Engineering Standards
Heston & Phifer (2011) The multiple quality models paradox: how much 'best practice' is just enough?
|
Author |
Article |
Year |
Read |
||
|
The multiple quality models paradox: how much ‘best practice’ is just enough? |
2011 |
12-Aug-12 |
|||
|
Key words |
|||||
|
Quality management, Standards, Quality models, |
|||||
|
Summarizing comments |
|||||
|
The title of this article (Heston & Phifer, 2011) left me with the expectations of an academic paper into a struggle between standardization and formality vs. flexibility and speed to best meet current and future business objectives. The article does not meet these expectations and is predominantly an outline of characteristics of typical standards / models / best practices used within the software industry (ISO 9001, CMMI, ITIL, ISO 27001, eSCM-SP, Six Sigma, Lean). Heston and Phifer argue that implementing one or more of these should not be a goal on its own and claims that many organizations are putting effort in implementation of these without taking full advantage of such implementation. They encourage the purposeful application of parts of these models/standards to best meet the organization’s needs. They are using the terms ‘Process DNA’ and ‘Quality Genes’ as building blocks of each standard/model and compare how each standard/model focusses on each of these. I don’t know how they came to the selection of the Reference model capabilities to map the ‘Q-genes’ of each standard/model. The explanation provided is that it represents an’ initial, high-level view of many elements that currently are incorporated into the reference models and standards in scope for this paper’. The paper suggests that this list could be easily expanded with other comparison criteria, attuned to the specific needs from the organization. The article provides 4 different scenario’s where different type of organizations are selecting different best practices from different model/standards based upon their culture, their needs (I skipped these scenarios; I can see the point). The message of the article is a little lost in the amount of tables delivering the comparisons. The tables are poorly positioned and also poorly introduced. At a number of occasions, I had to go backward and forward to understand why the table was there. Their content, however, the comparisons of the different models/standards is useful for my project and for my normal work too. Paragraph 6 provides a nice overview of common challenges and risks when pursuing process improvements and suggests mitigations. · Lack of focus on people change management · Lack of skills in process improvements · Belief in silver bullet · Belief, compromises and conflicts on what is enough (actually what triggered me reading this article; the authors introduce the 80/20 rule and suggest that you move to maintenance mode once you have reached your business objective) · Being model centric This article feels as a rush-rush job, insufficiently filtering the information required for the reader to take in the case; it just uses everything available. Valid points, but not really contributing to the case (for instance this list of common challenges and risks with their mitigations). The conclusion is not really following the line set out in the article. The conclusion suddenly mentions the costs of implementation of standards as a major issue. I do not disagree; I just don’t think it should be an important part of the conclusion if it hasn’t been a major part of the article. |
|||||
|
|||||
|
Actions |
Due date |
Status |
|||
|
1. Skim read and summarize |
12-Aug-12 |
Closed |
|||
|
2. |
|||||
Ford (2012) The road to maturity: Process management and integration of SHRM
|
Author |
Article |
Year |
Read |
|
Ford |
The road to maturity: process management and integration of Strategic Human Resources processes |
2012 |
25-Jul-12 |
|
Key words |
|||
|
Human resources, improvement, quality management, structure, integration |
|||
|
Summarizing comments |
|||
|
Ford’s article is rather surprising, as it presents process thinking as a new concept within strategic HR management. Anno 2012, and with an appreciation of capability management etc within quality management, I did expect that this interest had been bidirectional. Ford provides a nice definition for integration as a state of association among organizational processes that promotes unified, harmonious effort towards the effective achievement of organizational goals. I intend to deliberate on this definition and what it could mean to me. Ford recognizes that Strategic HR Management is focusing on best HR practices to enhance performance. The article list 7 basic HR processes driving excellent performance (employment security, selective hiring, self-managed teams, performance based compensation, extensive training, reduction of status differences and information sharing). However it recognizes that practice-based implementation does not provide the strategic impact as implementation of a practice is insufficiently embedded within the organizational infrastructure; It may lack an evolutionary path to learn and to adapt in a best-fit. An easy to implement practice with the accepted impact could just as easy be imitated by the competitor and not give any strategic advantage at all. Ford argues to view SHRM through a process perspective, where the notion of linkae between processes is central. Within the relations between processes is culture and its interrelated evolution makes it hard to imitate and fosters integration and encourages collaboration. Not only between HR processes, but certainly also with for instance operational processes Ford then looks into the coordination dimension of integration, as a skillful and balanced movement of different parts at the same time, facilitation collaborative efforts to progress towards effective outcomes. Processes and process integration benefits here through higher transparency on responsibilities and information flow and encouraged management review. Ford refers to a Malcolm Baldrige model, which I have never heard of. Maybe it is specifically targeting HR processes. Baldrige refers to integration as the harmonization of plans, processes, information, resource dicisions, results and analysis to support key organizationwide goals. Integration is achieved when individual components of a performance management system operate as an interconnected unit. Baldrige indentifies 4 different process maturity levels (based on level of integration, repeatability and improvement. Ford’s article reports on research done to measure maturity of SHRM systems based upon the Baldrige criteria. The study itself is of less interest tp me. I like the introduction, particularly as I appreciate the angle starting from HR towards performance, instead of having performance as the prime focus and human resources as awkward and unpredictable necessities. I am not certain how this article fits in shaping my ideas around my project. Nevertheless it has been fun to step outside my normal Technology Management box. |
|||
|
Actions |
Due date |
Status |
|
|
1. Skim read article and summarize the content and my insights |
25-Jul-12 |
Done |
|
|
2. Deliberate on the definition on Integration |
|||
This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.