SHORT ANSWER QUESTION FOR LEARNING
Abstract Class : In object-oriented programming, a class designed only as a parent from which sub-classes may be derived, but which is not itself suitable for instantiation. Often used to "abstract out" incomplete sets of features which may then be shared by a group of sibling sub-classes which add different variations of the missing pieces.
ACM :
Association for Computing Machinery
Active object :
Active object An object that encompasses its own thread of control.
Activity Diagram :
Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system.
Actors :
An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.
API :
API (Application Program Interface)
APP :
AAP The Association of American Publishers: engaged in standardisation efforts in document preparation
Association :
Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line.
Byte :
Byte A data unit of several bits smaller than a computer word: usually 8 bits.
Cache :
Cache A small fast memory holding recently-accessed data, designed to speed up further access
CAUSE :
CAUSE An international (mainly North American) nonprofit association for
managing and using information technology in higher education
CMM : CMM (Software Capability Maturity Model)
Composability : Ability to compose systems from plug-and-play components
COMSOFT : COMSOFT Consortium for the Management of Emerging Software Technologies
COTS : COTS (commercial off-the-shelf software)
DLL : DLL (dynamic link library)
Evolvability:
Support for new capabilities or ability to exploit new technologies
Functional Requirement :
Functional requirements describe the functionality of the product. They describe
exactly what tasks the software must perform. Functional requirements define the
scope of the system, the product boundaries, and its connections to adjacent
systems. Functional requirements also define the business rules. Business rules are
the rules that the system must conform to, based on the individual business. This
includes defining the data that must be tracked. The business rules are the most
important type of functional requirements and most of your requirements will be of
this type.
ISO : ISO (International Standards Association)
JAD : JAD (Joint Application Development)
Localizability:
Ability to make adaptations due to regional differences
Modifiability
:
:
Ability to add (unspecified) future functionality
Non-Functional Requirement :
Non-Functional requirements describe the look and feel of the system. This includes the visual properties of the system, its usability, and the performance requirements – how big, how fast, etc. Non-Functional requirements also include the product’s intended operating environment and any maintainability, portability and security issues. Non-Functional requirements also include cultural and political issues as well as legal requirements that the software must conform to.
OOA : OOA (object oriented analysis)
OOD :
OOD (object oriented design)
OOP :
OOP (object oriented programming)
Quality :
Quality is the degree of match between the product requirements (stated or otherwise) and the actual product. It is defined from the point of view of the user’s perception, expectation and goals or need.
RAD : RAD (Rapid Applications Development)
Reusability : Ability to (re)use in future systems
SRS : The Software Requirements Specification (SRS) is a collection and organization of all the requirements surrounding a project. As the Vision
Document was a broad statement of user needs, goals and objectives, and features of the system, the SRS begins the detailing of those needs and features, and how they are going to be implemented in the solution. The SRS is a collection, or package, of artifacts that describe the complete external behavior of the system
UCD : UCD (user centred design)
UML : UML (Unified Modelling Language)
Use cases :
A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
Abstract Class : In object-oriented programming, a class designed only as a parent from which sub-classes may be derived, but which is not itself suitable for instantiation. Often used to "abstract out" incomplete sets of features which may then be shared by a group of sibling sub-classes which add different variations of the missing pieces.
ACM :
Association for Computing Machinery
Active object :
Active object An object that encompasses its own thread of control.
Activity Diagram :
Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system.
Actors :
An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.
API :
API (Application Program Interface)
APP :
AAP The Association of American Publishers: engaged in standardisation efforts in document preparation
Association :
Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line.
Byte :
Byte A data unit of several bits smaller than a computer word: usually 8 bits.
Cache :
Cache A small fast memory holding recently-accessed data, designed to speed up further access
CAUSE :
CAUSE An international (mainly North American) nonprofit association for
managing and using information technology in higher education
CMM : CMM (Software Capability Maturity Model)
Composability : Ability to compose systems from plug-and-play components
COMSOFT : COMSOFT Consortium for the Management of Emerging Software Technologies
COTS : COTS (commercial off-the-shelf software)
DLL : DLL (dynamic link library)
Evolvability:
Support for new capabilities or ability to exploit new technologies
Functional Requirement :
Functional requirements describe the functionality of the product. They describe
exactly what tasks the software must perform. Functional requirements define the
scope of the system, the product boundaries, and its connections to adjacent
systems. Functional requirements also define the business rules. Business rules are
the rules that the system must conform to, based on the individual business. This
includes defining the data that must be tracked. The business rules are the most
important type of functional requirements and most of your requirements will be of
this type.
ISO : ISO (International Standards Association)
JAD : JAD (Joint Application Development)
Localizability:
Ability to make adaptations due to regional differences
Modifiability
:
:
Ability to add (unspecified) future functionality
Non-Functional Requirement :
Non-Functional requirements describe the look and feel of the system. This includes the visual properties of the system, its usability, and the performance requirements – how big, how fast, etc. Non-Functional requirements also include the product’s intended operating environment and any maintainability, portability and security issues. Non-Functional requirements also include cultural and political issues as well as legal requirements that the software must conform to.
OOA : OOA (object oriented analysis)
OOD :
OOD (object oriented design)
OOP :
OOP (object oriented programming)
Quality :
Quality is the degree of match between the product requirements (stated or otherwise) and the actual product. It is defined from the point of view of the user’s perception, expectation and goals or need.
RAD : RAD (Rapid Applications Development)
Reusability : Ability to (re)use in future systems
SRS : The Software Requirements Specification (SRS) is a collection and organization of all the requirements surrounding a project. As the Vision
Document was a broad statement of user needs, goals and objectives, and features of the system, the SRS begins the detailing of those needs and features, and how they are going to be implemented in the solution. The SRS is a collection, or package, of artifacts that describe the complete external behavior of the system
UCD : UCD (user centred design)
UML : UML (Unified Modelling Language)
Use cases :
A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
No comments:
Post a Comment