Term
| Software development life cycle |
|
Definition
the overall sequence of steps needed to complete a large-scale software project
1. Before implementation: feasibility study, problem specification, program design, algorithm selection or development and analysis (10-20% of total time)
2. Implementation: coding, debugging (25-40% of total time)
3. after implementation: testing verification and benchmarking, documentation, maintenance (40-65% of total time) |
|
|
Term
|
Definition
-applied to large scale software development
-entail estimation of costs and budgets, personnel management, and scheduling issues |
|
|
Term
|
Definition
-1st step before implementation in the software development life cycle
-evaluates a proposed project and compares the costs and benefits of various solutions
-purpose is to make all project stakeholders aware of the costs, risks, and benefits of various development |
|
|
Term
|
Definition
-expressed the resulting recommendations at the end of the feasibility study
-can be a very complex process involving considerations that are the provinces of business, law, management, economics, psychology, and accounting, as well as computer science |
|
|
Term
|
Definition
-2nd step before implementation in the software development life cycle
-involves developing a clear, concise, and unambiguous statement of the exact problem the software is to solve
-the software developers and their customers must resolve each and every inconsistency, ambiguity, and gap |
|
|
Term
| problem specification document |
|
Definition
-commits the final and complete problem specification to paper and guides the software developers in all subsequent decisions
-describes exactly how a program behaves in all circumstances not only in majority cases, but even under the most unusual conditions
-includes a description of the data expected to be input and what results should be computed and how these results are to be displayed as output |
|
|
Term
|
Definition
-3rd step before implementation in the software development life cycle
- the time to plan how the program is to be done |
|
|
Term
| divide-and-conquer/top-down decomposition |
|
Definition
-program design phase, traditional approach
-tasks are broken down into subtasks which are broken down into sub-subtasks and so on until each piece is small enough to code comfortably |
|
|
Term
|
Definition
| breaks the problem down into subtasks and sub-subtasks, or into various classes. May be documented graphically through structure charts or class diagrams that give properties and functions of each class. Must be a complete specification of each module (what it is to do, what info it needs to know in order to do it, and what the rest of the program needs to get from it when it is done) |
|
|
Term
| algorithm selection or development, and analysis |
|
Definition
-4th step before implementation in the software development life cycle
-once the various subtasks have been identified, algorithms must be found to carry them out. If there is a choice of algorithms, it must be determined which is more suitable for the particular task and which is more efficient
-documentation includes a description of the algorithms chosen or developed, perhaps in pseudocode, and the rationale for their use |
|
|
Term
|
Definition
-1st step in implementation in the software development life cycle
-the process of translating the detailed designs into computer code. Should be a routine job is design is carefully developed
-documentation is a written listing of the program code itself |
|
|
Term
|
Definition
-2nd step in implementation in the software development life cycle
-the process of locating and correcting program errors and it can be a slow and expensive operation that requires as much effort as writing the program in the first place
-documentation includes notes on the problems found and on how the code was changed to solve them |
|
|
Term
|
Definition
-debugging
-errors that occur because a program statement fails to follow the correct rules of syntax, which makes the statement unrecognizable by the compiler and results in an error
-accompanied by messages from the compiler that help pinpoint the problem |
|
|
Term
|
Definition
-debugging
-occur only when the program is run using certain sets of data that result in some illegal operation, such as dividing by 0
-system software provides messages to pinpoint these errors |
|
|
Term
|
Definition
-debugging
-errors in the algorithm used to solve the problem. Some incorrect steps result in wrong answers are performed, but there are no error messages to help pinpoint the problem |
|
|
Term
| testing, verification, and benchmarking |
|
Definition
-1st step after implementation in the software development life cycle
-approaches to confirming a program's correctness
-at the completion there should be a correct and efficient program that is ready for delivery
-documentation is committed to paper as evidence that the program met its specifications |
|
|
Term
|
Definition
-testing, verification, and benchmarking
-design a special set of test cases and run the program using test data. Test data that is carefully chosen to exercise all the different logic paths through a program can help uncover errors |
|
|
Term
|
Definition
-testing, verification, and benchmarking
-takes place on each module (subtask code) as it is completed |
|
|
Term
|
Definition
-testing, verification, and benchmarking
-as tested modules are combined to work together, this is done to see that the modules communicate the necessary data between and among themselves and that all modules work together smoothly |
|
|
Term
|
Definition
-testing, verification, and benchmarking
-used to prove that if the input data to a program satisfies certain conditions, then, after the program has been run on these data, the output satisfies certain other conditions
-can be difficult and time consuming |
|
|
Term
|
Definition
-testing, verification, and benchmarking
-means running the program on many data sets to be sure its performance falls within those required limits. |
|
|
Term
|
Definition
-2nd step after implementation of the software development life cycle
-all of the written material that makes a program understandable, goes on throughout the whole life cycle
-includes internal, external, and technical |
|
|
Term
|
Definition
-documentation
-part of the program code itself
-good forms of this consist of choosing meaningful names for the program identifiers, using plenty of comments to explain the code, and separating the program into short modules, each of which does one specific subtask |
|
|
Term
|
Definition
-documentation
-consists of any materials assembled to clarify the program's design and implementation |
|
|
Term
|
Definition
-one form of final, finished documentation
-enables programmers who later have to modify the program to understand the code
-structured charts, class diagrams, descriptions of algorithms, and program listings |
|
|
Term
|
Definition
-one form of final, finished documentation
-helps users run the program, includes online tutorials or help systems that the user can bring up while running the program, and (less often) written user's manuals |
|
|
Term
|
Definition
-3rd step after implementation in the software development life cycle
-the process of adapting an existing software product, may consume as much as 65% of he total software development life cycle budget.
-easier if the program have been well planned, carefully designed, well coded, thoroughly tested, and well documented |
|
|
Term
| Integrated Development Environment (IDE) |
|
Definition
-most programming languages are now presented in this
-lets the programmer perform a # of tasks within the shell of a single application program, rather than having to use a separate program for each task
-modern form of this provides a text editor, a file manager, a compiler, a linker and loader, and tools for debgging |
|
|
Term
|
Definition
| allows miscommunications between the user and the programmer to be identified and corrected early in the development process |
|
|
