SW Development Methodologies

863 views

Published on

  • Be the first to comment

SW Development Methodologies

  1. 1. ITA – CE237 Chapter 14: Software Development Methodologies Thiago Ferreira Software Quality Engineer
  2. 2. Agenda <ul><li>Overview </li></ul><ul><li>Methodology Types </li></ul><ul><li>Software Development Life Cycle </li></ul><ul><li>Defining Requirements </li></ul><ul><li>Methodology maturity </li></ul><ul><li>Project Staff competency and experience </li></ul><ul><li>Configuration Management </li></ul><ul><li>Measuring the Impact of the SW Development Process </li></ul>
  3. 3. Software Development Methodologies <ul><li>It provides guidelines for how to build software. In early days, Software Project Manager ( called from now as SPM ) had two responsibilities: To develop a process for building software, and to follow that process to project completion </li></ul><ul><li>Since all project leaders need a software development methodology , standardized process were developed. Some organizations create their own development methodology, whereas others acquire from suppliers </li></ul>01/22
  4. 4. Methodology Types <ul><li>Thousands of different methodologies are used to build the SW </li></ul><ul><li>None has proven to be best! </li></ul><ul><li>Most work, but some may not fit the needs of the specific project </li></ul><ul><li>This creates a dilemma for the SPM! </li></ul>02/22
  5. 5. Methodology Types <ul><li>Waterfall Methodology : It follows a logical progression of defining requirements, design, building and placing the system in operation. Assumes that requirements are know at the end of requirements phase (!!) </li></ul>03/22
  6. 6. Methodology Types <ul><li>Rapid Application Development Methodology : its objective is a quick turnaround time which emphasis on requirements definition, which is accomplished by heavy user involvement throughout all development phases. It makes extensive use of tools, and its effectiveness is due to rapid movement from one phase to the next. </li></ul>04/22
  7. 7. Methodology Types <ul><li>Spiral Methodology : Focus: Objectives, alternatives, Constraints and risks. It heavily involves the users as well. At each part of the spiral development, all those items are evaluated to make possible the best possible system from a business perspective. </li></ul>05/22
  8. 8. Methodology Types <ul><li>Incremental Methodology : Objective is develop the system in parts (or increments) It can be effective in reducing the risk of investing and building the entire system when the outcome is questionable. Unlike the prototyping, it focuses on the delivery of an operational product with each increment. </li></ul>06/22
  9. 9. Methodology Types <ul><li>The V Methodology : Mostly associated with software testing. It develops two process: one for building the system and another one for testing the system => they are interrelated as a V methodology </li></ul>07/22
  10. 10. Methodology Types <ul><li>The iterative V Methodology : Results of former V-Cycles are reused in later V-Cycles. Changes from one delivery to next one result from: 1. Planned implement of requirements; 2. Change Requests (internal/external); 3. Bug Fixes. </li></ul>08/22
  11. 11. Software Development Life Cycle <ul><li>Although no single generally accepted developmental methodology exists, all of them share some attributes </li></ul><ul><li>Most common shared attributes are: the phases required, the individuals involved and their roles and responsibilities, and the deliverables produced. </li></ul>09/22
  12. 12. Software Development Life Cycle <ul><li>Six common phases on a SDLC: </li></ul><ul><li>Initiation ( recognition of a problem and identification of a need) </li></ul><ul><li>Definition ( functional requirements are defined, as well detailed planning) </li></ul><ul><li>System Design ( specification of the problem solution) </li></ul><ul><li>Programming and Testing ( programs that are ready for unit testing) </li></ul><ul><li>Evaluation and Acceptance (integration and system tests) </li></ul><ul><li>Installation and Operation </li></ul>10/22
  13. 13. Software Development Life Cycle <ul><li>Roles and Responsibilities: </li></ul><ul><li>Sponsor/user </li></ul><ul><li>Project Manager </li></ul><ul><li>System Security Specialist ( does the project meet the security policy?) </li></ul><ul><li>Internal control specialist ( does the project meet internal control req.?) </li></ul><ul><li>Contracting officer (does the contractor meet the terms of the contract?) </li></ul><ul><li>IT Manager </li></ul><ul><li>Quality assurance specialist </li></ul>11/22
  14. 14. Defining Requirements <ul><li>Software Projects require that requirements be well defined, both for the system's analyst and the user: </li></ul><ul><li>Definitions of requirement (as used in a software project) </li></ul><ul><li>Requirement: An attribute or characteristic to be possessed by a product or service </li></ul><ul><li>Requirement Definition: A process by which customer and producers reach an understanding of requirements </li></ul><ul><li>Statement of requirements: A specification deliverable produced as a result of a requirements definition </li></ul>12/22
  15. 15. Defining Requirements <ul><li>Attributes of a requirement do not define what something &quot;should do&quot;. Attributes define what something &quot;should be&quot;. Desired attributes are the following: </li></ul><ul><li>Clear </li></ul><ul><li>Complete </li></ul><ul><li>Consistent </li></ul><ul><li>Correct </li></ul><ul><li>Modifiable </li></ul><ul><li>Pure </li></ul><ul><li>Relevant </li></ul><ul><li>Testable </li></ul><ul><li>Traceable </li></ul><ul><li>Usable </li></ul>13/22
  16. 16. Requirements Measures <ul><li>Verifying and validating requirements is ultimately a subjective assessment based on the agreement of all stakeholders </li></ul><ul><li>By providing measurement scales that focus on different aspects of requirement quality, the subjective assessments can be made more objective </li></ul><ul><li>Criticality, Measurability, Controllability, Completeness, Correctness, Clearness, Consistency, Relevance, Testability, Traceability, Pureness, Usability, Modifiability </li></ul><ul><li>The IEEE has several process standards that relate to requirements </li></ul>14/22
  17. 17. Methodology Maturity 15/22
  18. 18. Used Methodologies in Automotive Domain 16/22
  19. 19. Competence Required <ul><li>The Quality Assurance Institute has also defined skills specially needed by SW Developers and skills specially needed by software testers </li></ul><ul><li>The skills are divided into five categories: Process-Selection, Project Management, People Management, Build Software and Testing Software Skills </li></ul>17/22
  20. 20. Staff Experience <ul><li>A good process used by an untrained individual may not work, and it it does work , it might not be nearly as efficient of effective as that process when used by someone with experience. </li></ul><ul><li>The team should be knwoledgeable in the software development methodology and their role and responsibilities in the building of software system. </li></ul><ul><li>No single method can fully asses experience. Some criteria to evaluate experience are: Training courses built, number of software systems built, years of experience etc. </li></ul>18/22
  21. 21. Configuration Management <ul><li>Configuration management (CM) is one of the components of software project management that differentiates software project management from general project management => SW CM involves much more than only check-out/in </li></ul><ul><li>Basic CM Requirements are: </li></ul><ul><li>Configuration Identification </li></ul><ul><li>Configuration control </li></ul><ul><li>Configuration-status accounting </li></ul><ul><li>Configuration audits </li></ul>19/22 CM should be the first process when thinking in SW process improvement!
  22. 22. Measuring the Impact of SDP <ul><li>It is important for testers to measure the impact that using the software development methodology has on the resources and time needed to test effectively. </li></ul><ul><li>When testers know that inadequate time or resources have been allocated to testing, they can redirect the test effort to the high-risk components of the Software </li></ul>20/22
  23. 23. Work-Paper 14-1 21/22
  24. 24. Questions?? 22/22

×