4 stages of Testing

5 key STEPS in Project Management

Black box and White Box Testing

Bottom-up Integration Testing

Change Management Process

Defect

Encapsulation

Enterprise Architecture Views

Inheritance

Integration Testing and Systems Integration Testing

Limitations of Testing

Non-functional Requirements Classifications

Object-oriented Paradigm

Phases of the Project Life Cycle

Polymorphism

Problem and Model

Process and Product Quality

Process-based Quality

Risks in Waterfall and Iterative Methods

Software Configuration Management Process

Stakeholder and User Needs-Features-Software Requirements

Stakeholders & Their Concerns

SWEBOK V3

Systems, Models and Views

The Cost of Change in Waterfall and Iterative Methods

The Requirements Engineering Process

TOGAF - Architecture Types

TOGAF - Solution Architecture and EA

Top-down Integration Testing

Versions/Variants/Releases

What is a Project?

What is an Architecture?

What is Quality?

What is Software Configuration Management?

What is Software Engineering?

What is Testing?

V-model

4 stages of Testing

*Unit Test *Integration Test *System Test *Acceptance Test

Back

5 key STEPS in Project Management

1) Initiation - Establish objectives, stakeholders, deliverables and limitations of cost and time. 2) Planning - Establish a baseline which itemizes all activities and resources and estimates materials and time scales. 3) Execution - Perform the planned activities to make sure that essential work is done and the goal is achieved. 4) Tracking - Monitor the progress of each activity and modify the schedule as necessary 5) Closing - Deliverables are produced and the project is evaluated to learn lessons for the next time.

Back

Black box and White Box Testing

*Black Box Testing 1) No knowledge of internal design or code required. 2) Tests are based on requirements and functionality *White Box Testing 1) Knowledge of the internal program design and code required. 2) Tests are based on coverage of code statements,branches,paths,conditions.

Back

Bottom-up Integration Testing

Integrate individual components in levels until the complete system is created

Back

Change Management Process

*Customer - 1) Customer generates a change request 2) Customer approves changes *Project Manager - Manager assigns change request to software engineer *Dev Team - 1) Software engineer checks out necessary configuration objects 2) SE completes necessary changes 3) SE checks in modified configuration objects and notifies CM *Configration Manager - 1) CM creates new system vaseline 2) CM prepares new system release for operation if necessary

Back

Defect

Unfortunately—depending on your point of view—testing uncovers defects. A defect is a kind of change request, and may lead to a fix in some subsequent build or iteration. Defects are a useful source of metrics that the project manager will be able to use to understand not only the quality of the product over time, but also the quality of the process, and the quality and efficiency of the test process itself. You should be careful, though, to clearly differentiate a defect in the application from a defect in the test itself.

Back

Encapsulation

Encapsulation is the mechanism that binds together code and the data it manipulates. It keeps both safe from outside interference and misuse. In object – oriented language code and data may be combined in such a way that a self-contained "black box" is created. Code and data are linked together in this fashion, an object is created. We can say this as an object is the device that supports encapsulation. Within an object, code, data, or both may be private to that object or public. An object is a variable of a user-defined type. We can use it as like variable. However, in object-oriented programming, Each time you define a new type of object, you are creating a new data type. Each specific instance of this data type is a compound variable.

Back

Enterprise Architecture Views

*Business Architecture (What) 1) What do they do 2) Who does it 3) Which information do they use 4) Where is it done *Information Architecture (How)1) Data Architecture 2) Integration Architecture 3) Application Architecture *Technology Architecture (Where) 1) Systems Architecture 2) Infrastructure 3) Network 4) Hardware

Back

Inheritance

A class inherits state and behavior from its superclass. Inheritance provides a powerful and natural mechanism for organizing and structuring software programs. Inheritance is the process by which one object can acquire the properties of another object like son has some father’s characters. This is important because it supports the concept of classification. Without inheritance we have to define properties or behaviour explicitly for each and every class even those are related to some one.

Back

Integration Testing and Systems Integration Testing

*Integration testing - Testing of combined parts of an application to determine their functional correctness. ** Objectives - To technically verify proper interfacing between modules, and within sub-systems. When - After modules are unit tested. Input - 1) Internal and External Application Design 2) Master Test Plan 3) Integration Test Plan. Output - Integration Test report *Systems Integration Testing - Objectives 1) To test co-existence of products and applications that are required to perform together in the production-like operational environment. 2) To ensure that the system functions together with all the components of its environment as a total system. 3) To ensure that the system relases can be deployed in the current environment. When - 1) After system testing 2) Often performed outside of project life-cycle. Input - 1) Test Strategy 2) Master Test Plan 3) Systems Integration Test Plan. Output - Systems Integration

Back

Limitations of Testing

To test all possible inputs is impractical or impossible. To test all possible paths is impractical or impossible. Dijkstra, 1972. Testing can be used to show the presence of bugs, but never their absence. Goodenough and Gerhart, 1975. Testing is successful if the program fails. The (modest) goal of testing. Testing cannot guarantee the correctness of software but can be effectively used to find errors (of certain types)

Back

Non-functional Requirements Classifications

*Product requirements - Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. *Organisational requirements - Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. *External requirements - Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Back

Object-oriented Paradigm

Everything is an object. A program is a bunch of objects telling each other what to do by sending messages. Each object has its own memory made up of other objects. Every object has a type. All objects of a particular type can receive the same messages.

Back

Phases of the Project Life Cycle

Project Feasibility - Project Implementation. Concept - Development - Implementation - Close-out. Management Plan - Project Plan - Last work package - Completed work // Preliminary cost estimate - Budgetary cost estimate - Definitive cost estimate - Lessons Learned. Performance reports - Customer acceptance . Sample deliverables for each phase

Back

Polymorphism

The ability to appear in many forms. In object-oriented programming, polymorphism refers to a programming language's ability to process objects differently depending on their data type or class. It is the ability to redefine methods for derived classes. E.g. e-bike Acceleration system. Electronically / Mechanically Polymorphism is characterized by the phrase "one interface, multiple methods”. Polymorphism is the attribute that allows one interface to control access to a general class of actions. The specific action selected is determined by the exact nature of the situation.

Back

Problem and Model

The model defines an abstract view to the problem. This implies that the model focusses only on problem related stuff and that you try to define properties of the problem. These properties include 1) the data which are affected and 2) the operations which are identified.

Back

Process and Product Quality

The quality of a developed product is influenced by the quality of the production process. Particularly important in software development as some product quality attributes are hard to assess. However, there is a very complex and poorly understood between software processes and product quality

Back

Process-based Quality

Straightforward link between process and product in manufactured goods. Care must be taken not to impose inappropriate process standards. More complex for software because: 1) The application of individual skills and experience is particularly important in software development 2)External factors such as the novelty of an application or the need for an accelerated development schedule may impair product quality

Back

Risks in Waterfall and Iterative Methods

Back

Software Configuration Management Process

The SCM process defines a series of tasks: 1) Identfication of objects in the software configration. 2) Version Control 3) Change Control 4) Configuration Audit 5) Reporting **SCIs

Back

Stakeholder and User Needs-Features-Software Requirements

*NEEDS It seems obvious that the development team will build a better system only if it understands the true needs of the stakeholder. That knowledge will give the team the information it needs to make better decisions in the definition and implementation of the system. This set of inputs, which we call stakeholder or user needs, or just user needs for short. *FEATURES Feature is a service the system provides to fulfill one or more stakeholder needs. *SOFT Once we have established the feature set and have gained agreement with the customer, we can move on to defining the more specific requirements we will need to impose on the solution. If we build a system that conforms to those requirements, we can be certain that the system we develop will deliver the features we promised. In turn, since the features address one or more stakeholder needs, we will have addressed those needs directly in the solution. These more specific requirements are the software requirements. *SOFT We'll represent them as a block within our pyramid in a manner similar to the features. We also note that these appear pretty far down on the pyramid, and this implies, correctly, that we have much work to do before we get to that level of specificity.

Back

Stakeholders & Their Concerns

1) Maintainer, End User, Customer, Sales, Dev Manager, Developer, Sys Admin 2) Functionality, Price, Dev Costs, On Time Delivery, Performance, Stability and Maintainability, Ease of Use, Ease of Debugging, Modifiability, Testability and Traceability, Structure and dependency between component, Ease of Installation, Ease of Integration

Back

SWEBOK V3

Software requirements, Software design, Software construction, Software testing, Software maintenance, Software configuration management, Software engineering management, Software engineering process, Software engineering models and methods, Software quality, Software engineering professional practice, Software engineering economics, Computing foundations, Mathematical foundations, Engineering foundations, Software security specialized knowledge area

Back

Systems, Models and Views

*A model is an abstraction describing a subset of a system *A view depicts selected aspects of a model *A notation is a set of graphical or textual rules for depicting views *Views and models of a single system may overlap each other. Examples: System: Aircraft /Models: Flight simulator, scale model /Views: All blueprints, electrical wiring, fuel system

Back

The Cost of Change in Waterfall and Iterative Methods

The error is tyically 100 times more expensive to correct in the maintenance phase than in the requirements phase.

Back

The Requirements Engineering Process

Processes used to discover, analyse and validate,manage, system requirements. However, there are a number of generic activities common to all processes *Requirements elicitation *Requirements analysis *Requirements specification *Requirements validation/verification *Requirements management

Back

TOGAF - Architecture Types

*Business (Process) Architecture -- addresses the needs of users, planners, and business management *Data (Information) Architecture -- addresses the needs of database designers, database administrators, and system engineers *Application Architecture -- addresses the needs of system and software engineers *Technology Architecture -- addresses the needs of acquirers, operators, administrators, and managers.

Back

TOGAF - Solution Architecture and EA

*Business (Process) Architecture 1) Business strategy, governance 2) Key business processes 3) Actors, organization *Information Architecture 1) Information object 2) Logical and physical data 3) Data management 4) Metadata *Applications Architecture 1) Application portfolio 2) Functional services 3) Integration 4) Application platforms *Technology Architecture 1) Databases, middleware 2) Servers, workstations 3) Networking 4) Security solutions

Back

Top-down Integration Testing

Start with high-level system and integrate from the top-down replacing individual components by stubs where appropriate

Back

Versions/Variants/Releases

*Version - An instance of a system which is functionally distinct in some way from other system instances *Variant - An instance of a system which is functionally identical but non-functionally distinct from other instances of a system. *Release - An instance of a system which is distributed to users outside of the development team.

Back

What is a Project?

Has a start and an end date. Has schedule, cost, and quality constraints. Is a unique endeavor and contains risk. Has a certain scope that needs to occur.

Back

What is an Architecture?

A software architecture is the structure of structures of a system, which comprise elements, their externally-visible properties, and the relationships among them. The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

Back

What is Quality?

Quality, simplistically, means that a product should meet its specification. This is problematical for software systems 1) Tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.) 2)Some quality requirements are difficult to specify in an unambiguous way 3) Software specifications are usually incomplete and often inconsistent

Back

What is Software Configuration Management?

*Definition: 1) A set of management disciplines within the software engineering process to develop a baseline. *Description: 1) Software Configuration Management encompasses the disciplines and techniques of initiating, evaluating and controlling change to software products during and after the software engineering process. *Standards (approved by ANSI) 1) IEEE 828: Software Configuration Management Plans 2) IEEE 1042: Guide to Software Configuration Management

Back

What is Software Engineering?

Software engineering is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; the application of engineering to software

Back

What is Testing?

Testing is a process to detect defect in any application in order to reduce various risks associated with the application and improve the quality of the application.

Back

V-model

Requirements- Functional specfication - Architecture design - Module design - *Coding* - Unit testing - Integration testing - System testing - Acceptance testing

Back