1 / 24

CPSC 372

CPSC 372. John D. McGregor MCS1 Conformance and Certification. Basic elements. Software development process Requirements Design Coding Integration . Validation & Verification Reviews Analyses Tests. The basic set.

morgan
Télécharger la présentation

CPSC 372

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CPSC 372 John D. McGregor MCS1 Conformance and Certification

  2. Basic elements • Software development process • Requirements • Design • Coding • Integration • Validation & Verification • Reviews • Analyses • Tests

  3. The basic set • DO-178B (as well as A, C, D) are sets of guidelines for verifying software used in life critical systems in planes, trains, and automobiles as well as health care. • Verification takes the form of an argument to “prove” that a product is safe. • The argument is termed an “assurance case.”

  4. High-level process • Requirements – captures functional and non-functional • Design – structures the system based on non-functional requirements • Coding – design translated to executable statements • Integration – components from multiple teams are brought together to form larger portions of the system

  5. Verification • Software Verification Process Framework, consisting of three techniques to perform the validation of the process: • Reviews: Provide a qualitative assessment of correctness • Analyses: Provide repeatable evidence of correctness • Tests: Dynamic execution of the product

  6. Reviews and Analyses of the Software Architecture • Compatibility with the high-level requirements • Consistency • Compatibility with the target computer • Verifiability • Conformance to standards • Partitioning integrity

  7. Reviews and Analyses of the Source Code • Compliance with the software architecture • Conformance to standards • Accuracy and consistency • Think SONAR

  8. Requirements-Based Testing Methods • Requirements-based Software Integration Testing • Requirements-Based Low-Level Testing • Structural Coverage Analysis Resolution • Dead code • Deactivated code

  9. Software Configuration Management Process Activities • Change Review • Configuration Status Accounting • Must assure that the build contains the correct units • Must assure that deployment packages must contain the correct units

  10. Software Design Standards • Naming conventions to be used. • Constraints on design, for example, exclusion of recursion • Complexity restrictions, for example, maximum level of nested calls

  11. Software Code Standards • Programming language(s) to be used and/or defined subset(s). • Naming conventions for components, subprograms, variables, and constants. • Conditions and constraints imposed on permitted coding conventions, such as the degree of coupling between software components

  12. An example of conformance testing • http://files.ctia.org/pdf/CTIA_Bluetooth_CC_PMD_Rev_3.1.pdf • Testing the conformance to the Bluetooth standard • Many standards come complete with a test suite that evaluates conformance • Not a substitute for product testing

  13. Independent labs • Labs become certified to test conformance • They must meet criteria • They may have to pay a fee to the standard owner

  14. More on deployment • Enterprise programs – big, handles lots of data, embodies the firm’s business • Local programs – small, change quickly, embody a set of rules • Create a complete package, often tools such as Ant are used to automate package creation from a tested script • Many platforms usually mean multiple scripts

  15. Deployment do’s & don’ts • Have a common language for each type of release • All release activity is documented in an issue tracking system • Absolutely everything must be in version control • Each environment has a single, well-defined responsibility • A software version is represented by an SCM tag • Every step of the release process is scripted and can be run by anyone with sufficient privileges • Plan for failure • Don’t treat servers like your laptop; nuke and pave!

  16. Deployment • Types of deployment • Media-based – a set of discs that contain an application that validates the platform and installs • Web-based – software is downloaded and a file is unzipped • Local service – Windows has a local service • Remote service – a remote service controls the deployment

  17. Administrative actions

  18. The latest - DevOps • An integration of development and operations teams • Automation of deployment • Automation of feedback at all points • Paths of communication

  19. IBM’s perspective • http://www.ibm.com/ibm/devops/us/en/ • Download and read the DevOps for Dummies book from this web site • Culture, Process, and Tools • Plan and measure • Develop and test • Release and deploy • Monitor and optimize

  20. LifeCycle

  21. Case Study • This company is an online healthcare information provider offering consumers information on improving health or treating an illness. Based in the United States, the company employs approximately 1,500 people. The company’s health information services systems consist of more than 200 applications. • Business need: To quickly deliver an engaging customer experience with the most up-to-date information, this company needed a more efficient and reliable process to deploy new products and features. • Solution: The organization implemented IBM® UrbanCode Deploy software to automate and improve its application deployment processes. • Benefits: The company now achieves faster, continuous delivery of new functionality and value to customers. The solution helps reduce deployment risk and supports a more collaborative culture.

  22. Case study 2 • Headquartered in Chicago, Cars.com is a leading destination for online car shoppers, visited by more than 11 million users each month. The site offers credible and easy-to-understand information from consumers and experts that can help users formulate opinions on what to buy, where to buy and how much to pay for a car. The site includes comprehensive pricing information, side-by-side comparison tools, photo galleries, videos, editorial content and a large inventory of new and used vehicles. Founded in 1998, Cars.com is a division of Classified Ventures, LLC. • Business need: To eliminate a backlog of projects and improve staff efficiency and morale, Cars.com wanted to overhaul its development processes, moving from waterfall methods to agile methodology. • Solution: Working with IBM and IBM Business Partner Ascendant Technology, LLC, Cars.com implemented IBM Rational Build Forge and IBM Rational Automation Framework software. • Benefits: Using the new platform, Cars.com company decreased the time to deploy releases by 77 percent. The company now averages 300 new product releases a year versus the 30 to 40 it deployed in the past.

  23. http://www.coverity.com/library/pdf/Coverity-Meeting-DO-178B-Requirements.pdfhttp://www.coverity.com/library/pdf/Coverity-Meeting-DO-178B-Requirements.pdf • http://technet.microsoft.com/en-us/library/bb742421.aspx • http://emphaticsolutions.com/2009/09/06/the-rules-of-software-deployment.html

More Related