David L. Parnas: "Risks of Undisciplined Development", in Communications of the ACM, 10/2010.
"Recent experiences reminded me that the activity we (euphemistically) call software engineering does not come close to deserving a place among the traditional engineering disciplines. [...]
Many of us preach about the importance of determining the requirements a software product must satisfy, but we do not show students how to organize their work so they can systematically produce a requirements specification that removes all user-visible choices from the province of the programmer. [...]
We are caught in a catch-22 situation:
* Until customers demand evidence that the designers were qualified and disciplined, they will continue to get sloppy software.
* As long as there is no better software, we will buy sloppy software.
* As long as we buy sloppy software, developers will continue to use undisciplined development methods.
* As long as we fail to demand that developers use disciplined methods, we run the risk—nay, certainty—that we will continue to encounter software full of bugs."
Pagine
Visualizzazione post con etichetta rischi. Mostra tutti i post
Visualizzazione post con etichetta rischi. Mostra tutti i post
sabato 27 novembre 2010
sabato 23 maggio 2009
Accreditare i software engineer?
"Licensing Software Engineers?" è un articolo di Philippe Krutchen su IEEE Software, nov/dec 2008.
Krutchen parte citando Dilbert di Scott Adams: "The goal of a software engineer is to retire without having caused any major catastrophe", e argomenta in modo convincente in favore di una qualche forma di accreditamento per chi progetta sistemi critici.
Afferma tra l'altro: "Accreditare i software engineer non c'entra nulla con l'escludere qualcuno dallo sviluppo software. Solo alcuni devono mettere la firma su un progetto di software critico, che può causare la morte di persone. Non tutti quelli che lavorano in un ospedale devono essere dottori ."
Krutchen parte citando Dilbert di Scott Adams: "The goal of a software engineer is to retire without having caused any major catastrophe", e argomenta in modo convincente in favore di una qualche forma di accreditamento per chi progetta sistemi critici.
Afferma tra l'altro: "Accreditare i software engineer non c'entra nulla con l'escludere qualcuno dallo sviluppo software. Solo alcuni devono mettere la firma su un progetto di software critico, che può causare la morte di persone. Non tutti quelli che lavorano in un ospedale devono essere dottori ."
mercoledì 30 maggio 2007
The Sarbanes-Oxley Act: implications for large-scale IT outsourcing
James A. Hall, Stephen L. Liedtka, "The Sarbanes-Oxley Act: implications for large-scale IT outsourcing", Comm ACM 03-2007
"Until they are certain that outsourcing IT management is the best possible option, firms would do well to maintain and invest in their own in-house IT assets.
[...]
Two sections of SOX are especially important to corporate IT departments:
Section 404. Called “Management Assessment of Internal Controls,” it mandates that corporate CEOs implement internal controls over their financial reporting systems, physically test these controls, and certify in writing that they function correctly. As a practical matter, the vast majority of controls are embedded in computer technologies that involve virtually
all of an organization’s financial transaction processing systems; and
Section 302. Called “Corporate Responsibility for Incident Reports,” it requires senior financial executives to disclose deficiencies in internal controls and fraud (whether material or not). Also, public accounting firms must attest in their audit opinions to the adequacy
and function of their client firms’ internal controls. Prior to SOX, auditing standards required
auditors only to be “familiar” with internal controls.
[...]
While large-scale IT outsourcing may appear to be a way to address the costs of SOX compliance, outsourcing contracts can actually increase the likelihood that a firm will fail to
comply with both the detail and the spirit of SOX.
Specifically, large-scale IT outsourcing increases the risk that top management and boards of directors will be unable to fulfill their oversight duties; that firms will employ ineffective internal controls over financial statements; that financial reports will be inaccurate
and/or misleading; and that firms will fail to protect shareholder wealth.
[...]
Finally, we note that an outsourcing client’s competitive success depends on the vendor’s ability to perform. Electronic Data Systems Corp. (EDS) has demonstrated the potential for vendor failures to have drastic, perhaps unforeseeable, financial repercussions.
EDS has struggled due to a variety of factors, including its own financial reporting failures and the bankruptcies of two of its largest customers—WorldCom and US Airways. In order to cut costs, EDS terminated 7,000 employees, which affected its ability to serve its clients. Following an 11-year low in share prices in 2002, EDS stockholders filed a class-action
lawsuit against the company. Vendors experiencing such serious financial and legal problems clearly threaten the viability of their strategic partners, as well as their ability to maintain internal controls and completely and accurately present financial information."
"Until they are certain that outsourcing IT management is the best possible option, firms would do well to maintain and invest in their own in-house IT assets.
[...]
Two sections of SOX are especially important to corporate IT departments:
Section 404. Called “Management Assessment of Internal Controls,” it mandates that corporate CEOs implement internal controls over their financial reporting systems, physically test these controls, and certify in writing that they function correctly. As a practical matter, the vast majority of controls are embedded in computer technologies that involve virtually
all of an organization’s financial transaction processing systems; and
Section 302. Called “Corporate Responsibility for Incident Reports,” it requires senior financial executives to disclose deficiencies in internal controls and fraud (whether material or not). Also, public accounting firms must attest in their audit opinions to the adequacy
and function of their client firms’ internal controls. Prior to SOX, auditing standards required
auditors only to be “familiar” with internal controls.
[...]
While large-scale IT outsourcing may appear to be a way to address the costs of SOX compliance, outsourcing contracts can actually increase the likelihood that a firm will fail to
comply with both the detail and the spirit of SOX.
Specifically, large-scale IT outsourcing increases the risk that top management and boards of directors will be unable to fulfill their oversight duties; that firms will employ ineffective internal controls over financial statements; that financial reports will be inaccurate
and/or misleading; and that firms will fail to protect shareholder wealth.
[...]
Finally, we note that an outsourcing client’s competitive success depends on the vendor’s ability to perform. Electronic Data Systems Corp. (EDS) has demonstrated the potential for vendor failures to have drastic, perhaps unforeseeable, financial repercussions.
EDS has struggled due to a variety of factors, including its own financial reporting failures and the bankruptcies of two of its largest customers—WorldCom and US Airways. In order to cut costs, EDS terminated 7,000 employees, which affected its ability to serve its clients. Following an 11-year low in share prices in 2002, EDS stockholders filed a class-action
lawsuit against the company. Vendors experiencing such serious financial and legal problems clearly threaten the viability of their strategic partners, as well as their ability to maintain internal controls and completely and accurately present financial information."
domenica 25 febbraio 2007
Articoli su outsourcing
Hazel Taylor – Critical Risks in Outsourced IT Projects: the Intractable and the Unforeseen – Comm ACM November 2006
Phillip G. Armour – Agile... and Offshore - Comm ACM January 2007
Phillip G. Armour – Agile... and Offshore - Comm ACM January 2007
Iscriviti a:
Post (Atom)