Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Development Methodologies and Effective Requirements Analysis Andrew Aken for BA562 Summer 2006.

Similar presentations


Presentation on theme: "Software Development Methodologies and Effective Requirements Analysis Andrew Aken for BA562 Summer 2006."— Presentation transcript:

1

2 Software Development Methodologies and Effective Requirements Analysis Andrew Aken for BA562 Summer 2006

3 Software Development Methodologies and Effective Requirements Analysis 2 Traditional Software Development Process

4 Software Development Methodologies and Effective Requirements Analysis 3 What are the attributes of good software? Should deliver the required functionality and performance to the user and should be maintainable, dependable and usable Should deliver the required functionality and performance to the user and should be maintainable, dependable and usable Maintainability Maintainability Software must evolve to meet changing needs Software must evolve to meet changing needs Dependability Dependability Software must be trustworthy Software must be trustworthy Efficiency Efficiency Software should not make wasteful use of system resources Software should not make wasteful use of system resources Usability Usability Software must be usable by the users for which it was designed Software must be usable by the users for which it was designed

5 Software Development Methodologies and Effective Requirements Analysis 4 System dependability The most important system property is dependability The most important system property is dependability Dependability of a system reflects the user’s degree of trust in that system. Dependability of a system reflects the user’s degree of trust in that system. Usefulness and trustworthiness are not the same thing. Usefulness and trustworthiness are not the same thing. A system does not have to be trusted to be useful. A system does not have to be trusted to be useful.

6 Software Development Methodologies and Effective Requirements Analysis 5 Importance of dependability Systems that are not dependable and are unreliable, unsafe or insecure may be rejected by users Systems that are not dependable and are unreliable, unsafe or insecure may be rejected by users High costs of system failure High costs of system failure Undependable systems may cause information loss with a high consequent recovery cost Undependable systems may cause information loss with a high consequent recovery cost

7 Software Development Methodologies and Effective Requirements Analysis 6 Software Development Methodologies A methodology is: a collection of procedures, techniques, principles, and tools that help developers build computer system There are two main approaches to development methodologies: Traditional monumental or waterfall methodologies Agile or lightweight methodologies

8 Software Development Methodologies and Effective Requirements Analysis 7 Most firms don’t use a single standard methodology “Is a standard methodology — or set of methodologies — used by all of the development organizations in your company (e.g., each business unit’s IT department)?” (2004) Base: 83 companies

9 Software Development Methodologies and Effective Requirements Analysis 8 Development process taxonomy All development processes WaterfallIterative Agile

10 Software Development Methodologies and Effective Requirements Analysis 9 Waterfall versus iterative Project A: Waterfall development process JFMAMJJASOND Requirements definitionFormal approval process for requirements change Release Opportunity for requirements change Opportunity for requirements change Opportunity for requirements change Opportunity for requirements change Project B: Iterative development process JFMAMJJASOND Release 1 Iteration 0 Release 2Release 3Release 5Release 4

11 Software Development Methodologies and Effective Requirements Analysis 10 Agile iterations are not mini- waterfalls Activities like design, development, and testing are nearly concurrent. Activities like design, development, and testing are nearly concurrent. “Just enough upfront design,” “real-time specification,” and “continuous testing.” “Just enough upfront design,” “real-time specification,” and “continuous testing.”

12 Software Development Methodologies and Effective Requirements Analysis 11 Which of the following development methodologies are currently in use by any development organizations in your company? (2004) (multiple responses accepted) Base: 83 companies Homegrown processes prevail. Waterfall processes, though largely discredited, are still in common usage.

13 Software Development Methodologies and Effective Requirements Analysis 12 Base: 911 software and services decision-makers at North American and European enterprises Base: 346 software and services decision-makers at North American and European enterprises that are aware of but not already using Agile Agile processes slowly gain interest “How aware are you of Agile processes?” “How interested are you in adopting Agile processes?” Source: Forrester’s Business Technographics ® November 2005 North American And European Enterprise Software And Services Survey

14 Software Development Methodologies and Effective Requirements Analysis 13 The Software Development Lifecycle (SDLC) All practical software development methodologies must account for the following phases of the SDLC All practical software development methodologies must account for the following phases of the SDLC AnalysisDesignImplementationMaintenance

15 Software Development Methodologies and Effective Requirements Analysis 14 Boehm’s “Waterfall” Model

16 Software Development Methodologies and Effective Requirements Analysis 15 Boehm’s Spiral of Death Model

17 Software Development Methodologies and Effective Requirements Analysis 16 Other Methodologies Formalized Requirements Analysis: Formalized Requirements Analysis: Asynchronous Network Developed Reusable End-user Widgets (ANDREW) Asynchronous Network Developed Reusable End-user Widgets (ANDREW) Hierarchy Plus Input-Process-Output II (HIPO-II) Accommodates 4 groups of stakeholders: Hierarchy Plus Input-Process-Output II (HIPO-II) Accommodates 4 groups of stakeholders: Project managers Project managers End users End users Programmers Programmers Systems analysts Systems analysts No formalized Requirements Analysis: No formalized Requirements Analysis: Agile Agile eXtreme Programming (XP) eXtreme Programming (XP)

18 Software Development Methodologies and Effective Requirements Analysis 17 Requirements Analysis Most software projects fail in the requirements analysis phase of the SDLC Most software projects fail in the requirements analysis phase of the SDLC There are some well-known examples of failures in the “implementation” phase There are some well-known examples of failures in the “implementation” phase Mars Climate Orbiter Mars Climate Orbiter F16 flying over the equator F16 flying over the equator

19 Software Development Methodologies and Effective Requirements Analysis 18 Requirements Analysis Approximately 85 percent of the defects in developed software originate in the requirements Approximately 85 percent of the defects in developed software originate in the requirements Defects embedded in the requirements tend to resist removal Defects embedded in the requirements tend to resist removal They are extremely difficult to find via testing They are extremely difficult to find via testing It is consequently crucial that training be required for requirements analysts and engineers that explains how to reduce the common types of requirements errors It is consequently crucial that training be required for requirements analysts and engineers that explains how to reduce the common types of requirements errors incorrect assumptions (49 percent) incorrect assumptions (49 percent) omitted requirements (29 percent) omitted requirements (29 percent) inconsistent requirements (13 percent) inconsistent requirements (13 percent) ambiguities (5 percent) ambiguities (5 percent) Young, R. (2002) “Recommended Requirements Gathering Practices.” CrossTalk The Journal of Defense Software Engineering Young, R. (2002) “Recommended Requirements Gathering Practices.” CrossTalk The Journal of Defense Software Engineering

20 Software Development Methodologies and Effective Requirements Analysis 19 Focus on the User Requirements The usefulness of using Use Cases The usefulness of using Use Cases One methodology utilized as a component of the requirements analysis One methodology utilized as a component of the requirements analysis A textual description of how a system interacts with its surroundings A textual description of how a system interacts with its surroundings while performing a function for one of its users while performing a function for one of its users and details how the system should behave when various things go wrong and details how the system should behave when various things go wrong Or: a Use Case is a segmented textual description of goal-directed interactions between a primary interactor (person or external system) and the system being used Or: a Use Case is a segmented textual description of goal-directed interactions between a primary interactor (person or external system) and the system being used

21 Software Development Methodologies and Effective Requirements Analysis 20 Use Case History Ivar Jacobson began writing usage scenarios while defining the architecture for Ericsson's AXE system in 1967 Ivar Jacobson began writing usage scenarios while defining the architecture for Ericsson's AXE system in 1967 Those usage scenarios were informal and meant to give a broad idea of how the AXE system was to function Those usage scenarios were informal and meant to give a broad idea of how the AXE system was to function Jacobson further developed the process he termed anvendningsfall (usage case) in the mid-1980s Jacobson further developed the process he termed anvendningsfall (usage case) in the mid-1980s Cockburn formalized the process in 2000 in the book Writing Effective Use Cases Cockburn formalized the process in 2000 in the book Writing Effective Use Cases

22 Software Development Methodologies and Effective Requirements Analysis 21 How to Write Use Cases Understand the limits of use cases Understand the limits of use cases Determine which format to use Determine which format to use Or whether Use Cases are even appropriate Or whether Use Cases are even appropriate Structure Use Cases with Goals Structure Use Cases with Goals Include what happens when goals fail Include what happens when goals fail Include Stakeholders and Interests Include Stakeholders and Interests The end-user is only one of the stakeholders The end-user is only one of the stakeholders

23 Software Development Methodologies and Effective Requirements Analysis 22 Structuring Use Cases A use case is composed of 2 sections: A use case is composed of 2 sections: 1. The sequence of actions which take place when everything goes well 2. Various small sequences which detail what happens when the various goals and sub-goals fail Goals are hierarchical and the cases must detail which level the current Use Case is pertaining to Goals are hierarchical and the cases must detail which level the current Use Case is pertaining to E.g. Getting a loan to buy a house E.g. Getting a loan to buy a house Every action in a Use Case is written as a smaller goal that succeeds Every action in a Use Case is written as a smaller goal that succeeds

24 Software Development Methodologies and Effective Requirements Analysis 23 Including Various Stakeholders The “primary actor” (e.g. end-user) is only one of the stakeholders The “primary actor” (e.g. end-user) is only one of the stakeholders Other stakeholders could include the bank, the homeowner, the real-estate agent, government regulatory agencies, etc. Other stakeholders could include the bank, the homeowner, the real-estate agent, government regulatory agencies, etc. List each of the stakeholders and their interests (however casual or informal you want) and their requirements List each of the stakeholders and their interests (however casual or informal you want) and their requirements Every action the system takes is tied to a stakeholder’s interest Every action the system takes is tied to a stakeholder’s interest The system will accept information, validate values, update internal state, or generate output The system will accept information, validate values, update internal state, or generate output

25 Software Development Methodologies and Effective Requirements Analysis 24 Determine the Appropriate Format There are 3 degrees of detail that can be utilized when developing Use Case requirements There are 3 degrees of detail that can be utilized when developing Use Case requirements Use case brief: 2-4 sentences summarizing the use case, business priority, technical complexity, & other planning info Use case brief: 2-4 sentences summarizing the use case, business priority, technical complexity, & other planning info Casual use case: a few paragraphs of text covering the same data as the case brief Casual use case: a few paragraphs of text covering the same data as the case brief Fully dressed Use Case: long template with fields for stakeholders, minimum guarantees, post-conditions, business rules, performance constraints, etc. Fully dressed Use Case: long template with fields for stakeholders, minimum guarantees, post-conditions, business rules, performance constraints, etc.

26 Software Development Methodologies and Effective Requirements Analysis 25 Limitations of Use Case Use cases are useful for determining behavioral requirements Use cases are useful for determining behavioral requirements Use cases shouldn’t be used for: Use cases shouldn’t be used for: detailing system design detailing system design UI design UI design feature lists feature lists testing testing Use cases can be utilized as input for these design elements, but should not be confused with these other parts of the design process Use cases can be utilized as input for these design elements, but should not be confused with these other parts of the design process

27 Software Development Methodologies and Effective Requirements Analysis 26 Common Mistakes in Use Cases 2 most common (and costly) mistakes when utilizing Use Cases: 2 most common (and costly) mistakes when utilizing Use Cases: Including too many details Including too many details Including User Interface specifics (e.g. click on the Next >> button) Including User Interface specifics (e.g. click on the Next >> button) Use Case scenarios should be between 3 and 9 steps Use Case scenarios should be between 3 and 9 steps Don’t include design specifics Don’t include design specifics Greatest value of Use Cases lie in the alternative behaviors Greatest value of Use Cases lie in the alternative behaviors If the main scenario were 35 steps long, the Use Case would probably explode to over 10 pages If the main scenario were 35 steps long, the Use Case would probably explode to over 10 pages

28 Software Development Methodologies and Effective Requirements Analysis 27 RA Summary A comprehensive requirements analysis is essential to successful software development A comprehensive requirements analysis is essential to successful software development Use Cases can be an effective tool when developing system requirements Use Cases can be an effective tool when developing system requirements They are, however, only one component of the SAD process They are, however, only one component of the SAD process They are especially effective when utilized in interviews with users and also in RAD sessions They are especially effective when utilized in interviews with users and also in RAD sessions The Mars Climate Orbiter was actually an example of poor requirements analysis The Mars Climate Orbiter was actually an example of poor requirements analysis

29 Software Development Methodologies and Effective Requirements Analysis 28 Introduction – Agile methodologies Extreme Programming, also known as XP Extreme Programming, also known as XP Dynamic Systems Development Method (DSDM) Dynamic Systems Development Method (DSDM) SCRUM SCRUM Feature Driven Design (FDD) Feature Driven Design (FDD) Crystal Crystal Agile modeling Agile modeling Lean Software Development Lean Software Development

30 Software Development Methodologies and Effective Requirements Analysis 29 Agile manifesto I Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements, even late in development, Agile processes harness change for the customer’s advantage Welcome changing requirements, even late in development, Agile processes harness change for the customer’s advantage Business people and developers must work together daily throughout the project Business people and developers must work together daily throughout the project

31 Software Development Methodologies and Effective Requirements Analysis 30 Agile manifesto II Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Build projects around motivated individuals Build projects around motivated individuals Give them the environment and support they need, and trust them to get the job done Give them the environment and support they need, and trust them to get the job done

32 Software Development Methodologies and Effective Requirements Analysis 31 Agile manifesto III The most efficient and effective method of conveying information to and within a development team is face-to-face conversation The most efficient and effective method of conveying information to and within a development team is face-to-face conversation Working software is the primary measure of progress Working software is the primary measure of progress

33 Software Development Methodologies and Effective Requirements Analysis 32 Agile manifesto IV Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely Continuous attention to technical excellence and good design enhances agility Continuous attention to technical excellence and good design enhances agility

34 Software Development Methodologies and Effective Requirements Analysis 33 Agile manifesto V Simplicity -- the art of maximizing the amount of work not done -- is essential Simplicity -- the art of maximizing the amount of work not done -- is essential The best architectures, requirements, and designs emerge from self-organizing teams The best architectures, requirements, and designs emerge from self-organizing teams At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly


Download ppt "Software Development Methodologies and Effective Requirements Analysis Andrew Aken for BA562 Summer 2006."

Similar presentations


Ads by Google