5720045
Description
Flashcards by minal Kotwal, updated more than 1 year ago
|
Created by minal Kotwal
about 8 years ago
|
|
| Question | Answer |
| User Stories: - Requirement analysis is an imp part of software development - if its not done right, it can create a lot of issues later - User stories help get the high level picture of requirements - It is mostly prepared by the product owner - Its a living document like the product backlog - that means it keeps evolving throughout the length of the project | - Think of written requirements and then think of some verbal requirements - Written requirements : * can be well through through, reviewed and edited * They provide a permanent record * They're more easily shared with groups of people * They're time consuming to produce -Verbal requirements: * They allow you to get instantaneous feedback and clarification * They're information packed exchange * They're easier to clarify and gain common understanding * Can sark idea about problems and opportunities - Now think of a picture that can describe some of the requirements What do we get? We get user stories User stories seek to combine the strengths of written requirements and verbal communication, where possible supported by a picture It is a concise, written description of a piece of functionality that will be valuable to a user or owner of the software |
| User story description: As a [user role] I want to [goal] so i can [reason/benefit] Eg: As a registred user I want to log in so I can access subscriber-only content But then someone also needs to define what a successful registration is so that the above user story can be tested for its validity and completion - that is acceptance criteria - Each user story has an acceptance criteria | User stories characteristics: 1 - independent - should be as independent as possible -Negotiable - They are not a contract. They're not a detailed specs. They're reminders of features for the team to discuss and collaborate to clarify the details near the time of development - Valuable - should be valuable to the user of the solution. They should be written in user language. They should be features not tasks |
| User story characteristics - 2 - Estimable - User stories need to be possible to estimate. They need to provide enough info to estimate, without being too detailed - Small - they should be small. Not too small or too big. They should be detailed enough for the team to start work from. Further details can be established and clarified at the time of development - Testable - they need to be worded in a way that is testable. ie: Not too subject and to provide clear details of how they user story should be tested | next |
| - User stories should be independent - It is best to avoid dependency between stories because they lead to difficulty while prioritising and planning - User stories are negotiable - stories do not include all details - too many details give the impression of false precision or completeness - that there's no need to talk further - They need some flexibility so that we can adjust how much of the story get implemented | - User stories should be small - Larger stories often hide assumption which create ambiguity during the development |
| Which users should you target while writing user stories? - Broaden the scope instead of looking at one user - Allow user to vary by: * What they use the software for * How they user the software * Background * Familiarity with the software /computers - Used extensively in usage-centrered design - Definition: A user role is a collection of defining attributes that characterise a population of users and their intended interactions with the system | next |
| Quality and metrics: CMMI - Capability maturity model is a set of rules and recommendations which should lead to improvements within and organisation - It puts best practices used in software development and service management - CMMI may also be thought as a framework to recognise and improve processes within an organisation. - Because of its abstraction it can be for all kinds of manufacturers - CMMI levels is a set of steps which each organisation can obtain in order to increase it value on the market. It requires a lot of involvement and effort to get to level 5 | CMMI - A maturity level is a well-defined state towards achieving a mature software process - Each maturity level provides a layer in the the foundation for continuous process improvement - In CMMI model with a staged representation, there are 5 maturity levels designated by the number 1 to 5 * initial * managed * defined * quantitatively managed * optimising |
| Maturity level details: - Maturity level consist of a predefined set of process areas - they are measure by the achievement of the specific and generic goals that apply to each predefined set of process areas | |
| next | |
| Quality assurance: - Agile or no Agile, quality is important - only arrogant and novice organisation ignore equality assurance. - It fits in the project planning, monitoring and control phase of the project lifecycle What is quality? - Super or non-inferior - of high standard Why is quality a cause for concern? - Quality supports dependability - Dependability supports speed - Speed supports flexibility - Flexibility supports cost | Quality movement: Quality control and quality assurance branched out of this quality movement - Quality control - testing and inspection - Quality assurance - process compliance |
| Software quality assurance: is the function of software quality that assures that the - standards - procedures - processes are appropriate for the project and have been correctly implemented | Standard and procedures: Why are the important? - They provide framework from which software evolves - Establish the prescribed methods for developing software - SQA activities of process monitoring, product evaluation and auditing rely upon proper documentation/definitions of standards and procedures How do they come about? Driven by the needs and problems of the technical and managerial staff General categories: - Industry standard and procedures - Company specific standards and procedures |
| What are standards? Established criteria for product. They specify details for - documentation, design and coding Types: Industry Standard - International Organisation for Standardisation (ISO) - Institute of Electrical and Electronics Engineers (IEEE) -US Department of Defence (DoD | Standards are also compliance certifications: Example: ISO:9000 – Quality Systems. It is a model for Quality Assurance in: – Design – Development – Production – Installation & Servicing |
| What are procedures? -Established criteria for development and control process - Explicit steps to be followed in carrying out a process - All processes have well documented procedures | SQA Activities: Product evaluation - assuring standards are being followed Process monitoring - ensure appropriate steps are being followed to carry out a process Auditing - looks at both, processes, and products in depth |
Want to create your own Flashcards for free with GoConqr? Learn more.