Vous êtes sur la page 1sur 1

goal of software methodologists is to understand how high quality software can be developed efficiently <>Four major software development

methodologies can be classified as:. OStructured analysis and design (SAD), developed in late 1960s and 1970s Object-oriented analysis and design (OOAD), developed in 1980s and 1990s Agile software development (ASD), developed in late 1990s and 2000s Aspect-oriented software development (AOSD), developed in 2000s <>Agility is both a development philosophy and a collection of concepts embedded into development methodologies. <>Decisive Methodological Factors Software quality can be greatly improved by paying attention to factors such as traceability, testing, measurement, and security. 1. Traceability Software development process starts with an initial artifact, such as customer statement of work, and ends with source code. 2. Testing The key idea of Test-Driven Development (TDD) is that every step in the development process must start with a plan of how to verify that the result meets some goal. 3. Measurement While testing is universally practiced and TDD widely adopted, metrics and measurement are relatively rarely used, particularly for assessing software productquality. 4. Security Most computers, telephones, and other computing devices are nowadays connected to the public Internet. Requirements engineering helps software engineers understand the problem they are to solve. It involves activities that lead to understanding the business context, what the customer wants, how end-users will interact with the software, and what the business impact will be. Requirements engineering starts with the problem definition: customer statement of work (also known as customer statement of requirements) stakeholder is an individual, team, or organization with interests in, or concerns related to, the system-to-be. Requirements process in different methodologie 1. Requirements gathering (also known as requirements elicitation) helps the developer understand the business context 2. Requirements analysis involves refining of and reasoning about the requirements received from the customer during requirements gathering 3. Requirements specification represents the problem statement in a semiformal or formal manner to ensure clarity, consistency, and completeness. A test case is a particular choice of input values to be used in testing a program and expected output values. A test is a finite collection of test cases. For example, for the requirement REQ3, the customer may suggest these test cases: Test with the valid key of a current tenant on his or her apartment (pass) Test with the valid key of a current tenant on someone elses apartment (fail) Test with an invalid key on any apartment (fail)

Test with the key of a removed tenant on his or her previous apartment (fail) Test with the valid key of a just-added tenant on his or her apartment (pass) use case is a description of how a user will use the planned system to accomplish business goals A system sequence diagram represents in a visual form a usage scenario that an actor experiences while trying to obtain a service from the system A business process risk is the chance of something happening that will have an impact on the process objectives, such as financial or reputational damage, and is measured in terms of likelihood and consequence Analysis: Building the Domain Model 1. Identifying Concepts 2. Concept Associations and Attributes 3. Domain Analysis 4. Contracts: Preconditions and Postconditions Class diagram is created simply by reading the class names and their operations off of the interaction diagrams. Regression testing seeks to expose new errors, or regressions, in existing functionality after changes have been made to the system. System testing ensures that the whole system complies with the functional and non-functional requirements. Black box testing refers to analyzing a running program by probing it with various inputs. White box testing chooses test data with knowledge of the implementation, such as knowledge of the system architecture, used algorithms, or program code Test coverage measures the degree to which the specification or code of a software program has been exercised by tests. Equivalence testing is a black-box testing method that divides the space of all possible inputs into equivalence groups such that the program behaves the same on each group Boundary testing is a special case of equivalence testing that focuses on the boundary values of input parameters. Control Flow Testing Statement coverage selects a test set such that every elementary statement in the program is executed at least once by some test case in the test set. Edge coverage selects a test set such that every edge (branch) of the control flow is traversed at least once by some test case. Condition coverage (also known as predicate coverage) selects a test set such that every condition (Boolean statement) takes TRUE and FALSE outcomes at least once in some test case. Path coverage determines the number of distinct paths through the program that must be traversed (travelled over) at least once to verify the correctness State-based testing defines a set of abstract states that a software unit can take and tests the units behavior by comparing its actual states to the expected states refactoring of existing code is a transformation that improves its design while preserving its behavior.

Vous aimerez peut-être aussi