Software Standards
2 likes4,083 views
This document discusses software standards, including: - De jure standards are formally defined and documented standards developed through a rigorous process by independent standards bodies, while de facto standards emerge through widespread use but are managed by an individual organization. - Standards can be open, allowing public participation, or closed/proprietary, only allowing participation by the standard's custodians. - Software standards are important for interoperability, reusability, tool support, and economies of scale, but when adopting a standard there are tradeoffs between being an early influencer versus waiting for maturity.
Software Standards
- 1. Software Standards http://www.isaca.lk/ info@isaca.lk This work is licensed under a Creative Commons Attribution 3.0 Unported License. Parakum Pathirana vice.president@isaca.lk CISA, CISM, CGEIT, MSc, FBCS, CISSP, ISO 27001 LA, MCP, CHFI, QCS, ITIL
- 2. Agenda •What are standards? •De jure and de facto standards •Examples of de jure and de facto •Gray-area Standards •Open Vs. Closed •Why standardize? •Software Standards: Why? •Why standardize? Software perspective •Key software and software related standards •When to adopt a standard?
- 3. What are standards? •Definition: a standard is a form of agreement between parties •Many kinds of standards •For notations, tools, processes, organizations, domains •There is a prevalent view that complying to standard ‘X’ ensures that a constructed system has high quality •This is almost never strictly true •But that doesn’t mean standards are worthless •Here, we will attempt to put standards in perspective
- 4. De jure and de facto standards •Some standards are controlled by a body considered authoritative •ANSI, ISO, ECMA, W3C, IETF •These standards are called de jure (“from law”) •De jure standards are (usually) •are formally defined and documented •are evolved through a rigorous, well-known process •are managed by an independent body, governmental agency, or multi-organizational coalition rather than a single individual or company
- 5. De jure and de facto standards (cont’d) •Some standards emerge through widespread awareness and use •These standards are called de facto (“in practice”) •De facto standards usually •are created by a single individual organization to address a particular need •are adopted due to technical superiority or market dominance of the creating organization •evolve through an emergent, market-driven process •are managed by the creating organization or the users themselves, rather than through a formal custodial body
- 6. Examples of de jure and de facto •De jure standards •UML (managed by OMG) •CORBA (also managed by OMG) •HTTP protocol (managed by IETF) •De facto standards •PDF format (managed by Adobe) •May become de jure through ISO •Windows (managed by Microsoft) •There is a substantial gray area between these two
- 7. Gray-area Standards •HTML •Officially standardized by W3C, indicating de jure •Flavors and browser-specific extensions developed by Microsoft, Netscape, and others, creating de facto variants •None of these has power to force users to use standard •JavaScript •Developed by Netscape; copied (as JScript) by Microsoft •After substantial adoption and possibly under threat of forking/splintering, Netscape submits it to ECMA •Now standardized as ECMAScript (de jure) •JavaScript and variants continue to be developed as compatible extensions of ECMAScript
- 8. Open Vs. Closed •Standards (whether de jure or de facto) can be: •Open •Allow public participation in the standardization process •Anyone can submit ideas or changes for review •Closed (a.k.a. proprietary) •Only the custodians of a standard can participate in its evolution
- 9. Why standardize? •Technological perspective •Social perspective •Economic perspective
- 10. Software Standards: Why? •Software development is still plagued with low degree reusability, inconsistent data definitions, lack of standardization in processes covering the entire development cycle •Creativity in software development could lead to adopting non standardizes approaches
- 11. Why standardize? Software perspective •To ensure interoperability between products developed by different organizations •To carry engineering knowledge from one project to another •As an effort to attract tool vendors •To create economies of scale •To attempt to control the standard’s evolution in your favor
- 12. Key software and software related standards
- 13. When to adopt a standard? (cont’d) •Early adoption •Benefits •Improved ability to influence the standard •Get your own goals incorporated; exclude competitors •Early to market •If standard becomes successful, early marketers will profit •Early experience •Leverage enhanced experience to your benefit
- 14. When to adopt a standard? •Early adoption •Drawbacks •Risk of failure •Standard may not be successful for reasons out of your control •Moving target •Early standards tend to evolve and ‘churn’ more than mature ones, and may be ‘buggy’ •Lack of support •Early standards tend to have immature (or no) support from tool and solution vendors
- 15. When to adopt a standard? (cont’d) •Late adoption •Benefits •Maturity of standard •Better support •Drawbacks •Inability to influence the standard •Restriction of innovation
- 16. Thank you