Final exam Flashcards
Product Support Life Cycle (in order)
i) Plan and Prepare for support and maintenance
ii) The Product is Released
iii) Defect and Non-Defect support run in parallel
(1) Defects are bugs in the program that cause errors.
(2) Non-Defects are user issues and other issues that are not the result of a program bug or error. Like bad UI design or training deficiencies or a user just getting confused.
iv) Announcement of new release or replacement
v) Reduction in Defect support. Only the most severe are worked on and all others ignored. Non-Defect support also stops.
vi) User migration to new software
vii) Product Withdrawal from the market.
b) Sun-setting
i) Stop any product’s additional feature and enhancement
ii) Fix only the high severity problems
iii) Announce new replacement product
iv) Encourage new and existing customers to move to new product
v) Notify all old users on the old product of the planned termination date
vi) Provide names of the other vendors who are willing to support the old product to the customers who chooses to stay
vii) Terminate the customer product and withdraw the product from the market
20) Problem arrival curve
a) During the period right after release, many problems are discovered and reported.
b) The amount of problems discovered eventually decreases; at the same time the nature of the problems discovered become more difficult to diagnose.
19) Software Configuration management
Software Configuration Management is the process of keeping all your “artifacts” of the creation process being updated and managed.
b) Software Configuration Management is composed of:
i) Understanding the policy, process activities, and the resulting artifacts that need to be managed.
ii) Determining and defining the framework that needs to be used to manage these artifacts
iii) Determining and bringing in any tools that need to be brought in to facilitate the management of these artifacts
iv) Training and ensuring that the agreed-upon configuration management process is practiced and adhered to.
v) An Organization may choose to manage the following artifacts for example
(1) Requirements specification
(2) Design specification
(3) Source code
(4) Executable code
(5) Test cases
a) Seed Process
i) This is a technique used to test how good the QA team is. The idea is to pepper the program with a number of defects and note how many the testers catch
b) Error Estimation
i) The Error Estimation is taking the number of unfound seeded defects and applying the ratio to the unseeded defects.
a) Boundary Values
i) Past experiences show that “Boundaries” are error-prone and should be tested rigorously.
v) Boundary-Values Analysis
(1) Test cases are designed on the boundaries of acceptable input domain.
ii) Do Equivalence-class partitioning and add test cases for boundaries (at boundary, outside, inside)
b) Black box
i) Also known as “data-driven testing” - it relies on a module description to devise test cases and treats the module like a “black box” where how it works is unknown.
(1) I.e. you can’t see the inner workings of the box, just what goes in and comes out.
ii) Uses the architectural design, including inputs, functionality, and outputs.
iii) Black box test cases should be designed before coding/implementation phase ends.
c) White box
i) Often called “structural testing” - it relies on analysis of a module’s source code to design a test case.
(1) Treats the module like a “white-box” where we can see and test the inner workings of the box.
(2) Test cases designed as needed on a case-by-case basis.
ii) More close analysis of the detailed design of a module.
iii) White box testing should supplement and not replace black box testing.
16) Refactoring
a) Improving your code style without affecting its behavior. Basically, clean up your code.
b) Things to fix by Refactoring
i) Duplicated code – Stuff that is clearly a waste
ii) Long method – Excessively large or long methods perhaps should be subdivided into smaller more cohesive ones.
iii) Large class – Same problem as long methods.
iv) Switch Statement – In object-oriented code, switch statements can in most cases be replaced with polymorphism, making the code clearer.
v) Feature Envy – in which a method tends to use more of an object from a class different to the one it belongs.
vi) Inappropriate Intimacy – in which a class refers too much to private parts of other classes.
c) Ways to Refactor
i) Extract Method – A process that turns a code fragment into its own method, with an appropriate name, and calls the method.
ii) Substitute algorithm – A process that replaces the body of a method with a new algorithm that is clearer, and returns the same result.
iii) Move Method – A process that moves an algorithm from one class to another where it makes more sense.
iv) Extract Class – A process that divides into two.
15) Test driven development principles
a) Write unit-test cases BEFORE the code!
b) The test cases become the requirements for the program. It must pass all tests to meet requirements and be considered successful.
c) Forces development in small steps
steps for test driven dev
i) Write test case and code
ii) Verify that the test case fails
iii) Modify the code so it succeeds in the test – The goal is to write the simplest code you can, without worrying about the future tests or requirements.
iv) Rerun test case and previous tests – Verify that it works and still passes all previous tests without failing and has not introduced any new defects.
v) Refactor until success and satisfaction – make it pretty.
Cloud Advantages
i) flexibility and scalability; we can create servers for just a few minutes or hours, and the companies developing the cloud services usually make them scale to almost any size.
ii) We do not need as much effort to manage cloud services as if we were managing our own servers
iii) Usually cloud services require much less initial capital investment
iv) more services moving to the cloud
Cloud disadvantages
i) we still need to manage the services, and we lose control over the servers, which may introduce problems.
ii) might have trust or legal problems
iii) The servers may be in a different country and so subject to different laws, which might be a problem. We might have privacy, security, or legal requirements that make using other companies’ servers more difficult.
iv) the operating costs might be higher than owning the individual servers.
v) chances are many organizations will end up with hybrid applications, with some servers owned by the organization, some in the cloud, and some applications being managed directly, some in a platform as a service and using some cloud-provided services
