Starting from the bottom the first test level is "Unit Testing". It involves checking that each feature specified in the "Component Design" has been implemented in the component. In theory an independent tester should do this, but in practice the developer usually does it, as they are the only people who understand how a component works. The problem with a component is that it performs only a small part of the functionality of a system, and it relies on co-operating with other parts of the system, which may not have been built yet. To overcome this, th e developer either builds, or uses special software to trick the component into believe it is working in a fully functional system. Integration Testing As the components are constructed and tested they are then linked together to check if they work with each other. It is a fact that two components that have passed all their tests, when connected to each other produce one new component full of faults. These tests can be done by specialists, or by the developers. Integration Testing is not focused on what the components are doing but on how they communicate with each other, as specified in the "System Design". The "System Design" defines relationships between components. The tests are organized to check all the interfaces, until all the components have been built and interfaced to each other producing the whole system. System Testing Once the entire system has been built then it has to be tested against the "System Specification" to check if it delivers the features required. It is still developer focused, although specialist developers known as systems testers are normally employed to do it. In essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In fact it is one giant component. System testing can involve a number of specialist types of test to see if all the functional and non - functional requirements have been met. In addition to functional requirements these may include the following types of testing for the non - functional requirements: Performance - Are the performance criteria met? Volume - Can large volumes of information be handled? Stress - Can peak volumes of information be handled? Documentation - Is the documentation usable for the system? Robustness - Does the system remain stable under adverse circumstances? There are many others, the need for which is dictated by how the system is supposed to perform. Acceptance Testing Page 20 of 215
Acceptance Testing checks the system against the "Requirements". It is similar to systems testing in that the whole system is checked but the important difference is the change in focus: Systems testing checks that the system that was specified has been delivered. Acceptance Testing checks that the system will deliver what was requested. The customer should always do acceptance testing and not the developer. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment. This testing is more of getting the answer for whether is the software delivered as defined by the customer. It’s like getting a green flag from the customer that the software is up to the expectation and ready to be used. Figure 1.4: - V model cycle flow Which is the best model? In the previous section we looked through all the models. But in real projects, hardly one complete model can fulfill the entire project requirement. In real projects, tailor model are proven to be the best because they share features from all models such as Waterfall, Iterative, Evolutionary models etc and can fit in to real life time projects. Tailor model are most productive and benefited for many organization. As it is an educational book we will build up virtual project for clear understanding the process so we will use Big Bang waterfall model. In waterfall project output of every stage will be freezed as explained earlier no changes will be accepted once the requirement document is freezed. Page 21 of 215
Essential documentation in projects In the previous section we discussed the various SDLC lifecycle models. For every stage in the model we have documents created according to phases such as: - Requirement stage we have the Use case document Design stage we have the Technical document Build stage we have the source code Test stage we have the Test result document Deliver stage we have the sign off document There are different documentation for every project and these documents change from company to company and project to project. For instance, some company will have 3 documents and some will have 12 documents in a project depending upon project manager or the policy of the company to execute a project. This book will include only 5 documents in a project which are as follows: - Requirement document Estimation document Use case document Technical document Test plan document Source code Let’s try to understand in detail each document used in a software project Requirement document: -A requirement document can be a single English document, probably a recorded audio or video conversation or can be a complicated use case. In short it’s something raw which comes from the end client. Estimation document: - After getting requirement from the user we can judge cost for the project. In this book we will be using the function point estimation model . There is a complete chapter which is dedicated to function point in this book. Use case document: - This is a section of UML which basically describes in detail the requirement document which serves as an input to the Design stage Technical document: -This document contains detail of how the project being executed such as pseudo code, class diagram, objects diagram, etc. Test result document : - This document is written by the testers which describe the test plan which needs to be executed and thus giving project a green flag to production. Source code: - This is not basically a document but one of the important deliverable which maps to the execution phase of SDLC cycle. Note: - See the SDLC in action figure given above which shows how the documents are mapped to SDLC cycle. UML The main object of UML is to make the project understanding more crisp and clear. It is a global computer industry modeling language to communicate between software professional in a project. UML helps us to create documents, artifacts & also give Page 22 of 215
visualization so that we can understand the complex software engineering process of a project. Three views of the project from UML perspective There are 12 diagrams in UML they are divided into 3 main views as below: - Structure diagram Behavior diagram Model management diagram Structure diagram They are used to show static structure of an application. Let’s try to understand what the word static signifies. For instance in a civil construction when the engineer makes a model of a civil construction. The outer structure of the building and bridge will remain same but yes the inner part of the structure for instance the structure of room and passages (one room, two rooms etc) can vary. Same holds true when we talk about software industry there are static part and dynamic part of project. For example classes in project will rarely change. Yes the attributes and methods in the class will change as user adds new functionalities. For instance in the below figure you can see the Invoice header will have multiple invoice details. The structure and relation between Invoice header and Invoice detail will never change. But yes the invoice can pass through multiple stages like open invoice, closed invoice or pending invoice which is dynamic. Figure 1.5: - Project static nature UML has four types of structure diagram : - 1) Class diagrams 2) Object diagrams 3) Component diagrams Page 23 of 215
4) Deployment diagrams Behavior diagram UML gives us five Behavior diagram. They are used to show dynamic structure of an application. Let’s try to understand what does a dynamic structure of a project means. In a typical software project we can have business validations. Business validations of a project are of very dynamic nature. For instance an invoice can have lot of states for instance open invoice, closed invoice and paid invoice. And your software will change the invoice object from one state to other state. This is a dynamic nature of the project. Figure 1.6: - Project behavior in action The above figure shows how the invoice section moves dynamically by making transition from one state to other state. In UML to represent this kind of dynamic nature there are five diagrams. 1. Use Case diagrams 2. Sequence diagrams 3. Activity diagrams 4. Collaboration diagrams 5. State chart diagrams Model management diagram Model management diagram gives a view how different application modules are managed , grouped and classified. For instance the below figure shows how Accounting, Payment and common routines are grouped and organized. Page 24 of 215
Figure 1.7: - Model Management diagram in action UML provides three diagrams by which we can get the Model Management view. Below are the three diagrams: - 1. Packages 2. Subsystems 3. Models Overall Explanation of the UML diagrams Class diagram Use to show real -world entities, elements of analysis and design, or implementation classes and their relationships Object diagram Use to show a specific or illustrative example of objects and their links. Often used to indicate the conditions for an event, such as a test or an operation call Composite structure diagram Use to show the how something is made. Especially useful in complex structures-of-structures or component-based design. Page 25 of 215
Deployment diagram Use to show the run-time architecture of the system, the hardware platforms, software artifacts (deliverable or running software items), and software environments (like operating systems and virtual machines). Component diagram Use to show organization and relationships among the system deliverables Package diagram Use to organize model elements and show dependencies among them Activity diagram Use to the show data flow and/ or the control flow of a behavior Captures workflow among cooperating objects Use case diagram Use to show the services that actors can request from a system in actor and role form. State machine diagram / Protocol state machine diagram Use to show the life cycle of a particular object, or the sequences an object goes through or that an interface must support. Overview diagram Use to show many different inter- action scenarios (sequences of behavior) for the same collaboration (a set of elements working together to accomplish a goal) Sequence diagram Use to focus on message exchange between a group of objects and the order of the messages. Communication diagram Use to focus on the messages between a group of objects and the underlying relationship of the objects Timing diagram Use to show changes and their relationship to clock times in real -time or embedded Systems work Which diagram is important In above section we have seen the basic definitions of all the UML diagrams. But in real projects we do not draw all the diagrams instead we look towards the complexity of the project or necessity of the project and accordingly we decide the diagrams and then Page 26 of 215
diagrams are added to the technical document or the requirement document. So in this book we will use two basic diagrams extensively: - Use case diagrams Class diagrams The other diagram will be used if required and their respective explanation will be provided at the same time. Let’s try to understand in detail the two basic diagram used in the project. The first one is the Use case diagram and explained as the follows Use case diagram over view It’s a user functionality which the user wants to be completed by the system. For example Travel Company’s director wants to book ticket, cancel ticket, refund ticket done by the system. So basically it defines the actions of the user in the system. It basically defines verbs of the system. The best way to identify a use case is by extracting verbs of the requirement document given by the end customer. Actors and Goals Every use case will have the below two components actors and goals. Actors are stake holders of the system. Stake holders provide requirement to your project and oppose in case of any issues. Normally software users are the actors. For instance in an accounting application accountant forms as an actor and for the same accounting application we have cashier and charted accountant as another form of actors for the system. Every actor has goal to perform when using the system. There are two types of actors: - Primary Actor: -This actor actually initiates the use case on the system. Secondary Actor: -While Secondary Actor contacts other actors or use cases to meet the Primary Actor’s goal. In the below example we have Ticket Reservation system here travel agent is a actor who is using reserving ticket application and booking a ticket, canceling a ticket and refunding a ticket. So booking, canceling and refunding of a ticket are goals performed by an actor. The figure below shows the diagrammatic view to represent relationship between actors and goals. But the diagram does not show the details of the goals. Page 27 of 215
Figure 1.8:- Actors and Goals in action So for the same we need to document it using use case documents which is explained in the coming section. In the next section we will go through a use case template which we will use in most of the project. Use case templates can be used to expand on the above diagram in more detail manner. Detail Explanation of the Use Case template Below is the use case template which we will be using in most of our project. So let’s understand every section of the template. Use case: - In order to identify particular use case we do unique numbering to it like UC001, UC002 or QUEST POND 001, QUEST POND 002 etc as there are N number of use cases in a project. Use case name: - It is a particular action taken by the user on the system or task get done from the system in the form such as booking a ticket, Canceling a ticket etc in actual which represents an action. Description:-It basically describes the details of a user case in a textual form. Primary actor: -Primary Actor is nothing but the user who actually initiates the goal. For example in a travel agency the director sees the report booking done by customers. So here the director acts as a primary actor who is fully interested in how much booking is done over a period of time. But he is not interested in making a booking as that’s the work of the travel agent. So in “Make booking” use case the travel agent acts as a primary actor and the director as the secondary actor. But in case of “View booking” use case the travel agent acts as a secondary actor and the director as a primary actor. Page 28 of 215
Acceptance Testing checks the system against the "Requirements". It is similar to systems testing in that the whole system is checked but the important difference is the change in focus: Systems testing checks that the system that was specified has been delivered. Acceptance Testing checks that the system will deliver what was requested. The customer should always do acceptance testing and not the developer. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment. This testing is more of getting the answer for whether is the software delivered as defined by the customer. It’s like getting a green flag from the customer that the software is up to the expectation and ready to be used. Figure 1.4: - V model cycle flow Which is the best model? In the previous section we looked through all the models. But in real projects, hardly one complete model can fulfill the entire project requirement. In real projects, tailor model are proven to be the best because they share features from all models such as Waterfall, Iterative, Evolutionary models etc and can fit in to real life time projects. Tailor model are most productive and benefited for many organization. As it is an educational book we will build up virtual project for clear understanding the process so we will use Big Bang waterfall model. In waterfall project output of every stage will be freezed as explained earlier no changes will be accepted once the requirement document is freezed. Page 21 of 215
Essential documentation in projects In the previous section we discussed the various SDLC lifecycle models. For every stage in the model we have documents created according to phases such as: - Requirement stage we have the Use case document Design stage we have the Technical document Build stage we have the source code Test stage we have the Test result document Deliver stage we have the sign off document There are different documentation for every project and these documents change from company to company and project to project. For instance, some company will have 3 documents and some will have 12 documents in a project depending upon project manager or the policy of the company to execute a project. This book will include only 5 documents in a project which are as follows: - Requirement document Estimation document Use case document Technical document Test plan document Source code Let’s try to understand in detail each document used in a software project Requirement document: -A requirement document can be a single English document, probably a recorded audio or video conversation or can be a complicated use case. In short it’s something raw which comes from the end client. Estimation document: - After getting requirement from the user we can judge cost for the project. In this book we will be using the function point estimation model . There is a complete chapter which is dedicated to function point in this book. Use case document: - This is a section of UML which basically describes in detail the requirement document which serves as an input to the Design stage Technical document: -This document contains detail of how the project being executed such as pseudo code, class diagram, objects diagram, etc. Test result document : - This document is written by the testers which describe the test plan which needs to be executed and thus giving project a green flag to production. Source code: - This is not basically a document but one of the important deliverable which maps to the execution phase of SDLC cycle. Note: - See the SDLC in action figure given above which shows how the documents are mapped to SDLC cycle. UML The main object of UML is to make the project understanding more crisp and clear. It is a global computer industry modeling language to communicate between software professional in a project. UML helps us to create documents, artifacts & also give Page 22 of 215
visualization so that we can understand the complex software engineering process of a project. Three views of the project from UML perspective There are 12 diagrams in UML they are divided into 3 main views as below: - Structure diagram Behavior diagram Model management diagram Structure diagram They are used to show static structure of an application. Let’s try to understand what the word static signifies. For instance in a civil construction when the engineer makes a model of a civil construction. The outer structure of the building and bridge will remain same but yes the inner part of the structure for instance the structure of room and passages (one room, two rooms etc) can vary. Same holds true when we talk about software industry there are static part and dynamic part of project. For example classes in project will rarely change. Yes the attributes and methods in the class will change as user adds new functionalities. For instance in the below figure you can see the Invoice header will have multiple invoice details. The structure and relation between Invoice header and Invoice detail will never change. But yes the invoice can pass through multiple stages like open invoice, closed invoice or pending invoice which is dynamic. Figure 1.5: - Project static nature UML has four types of structure diagram : - 1) Class diagrams 2) Object diagrams 3) Component diagrams Page 23 of 215
4) Deployment diagrams Behavior diagram UML gives us five Behavior diagram. They are used to show dynamic structure of an application. Let’s try to understand what does a dynamic structure of a project means. In a typical software project we can have business validations. Business validations of a project are of very dynamic nature. For instance an invoice can have lot of states for instance open invoice, closed invoice and paid invoice. And your software will change the invoice object from one state to other state. This is a dynamic nature of the project. Figure 1.6: - Project behavior in action The above figure shows how the invoice section moves dynamically by making transition from one state to other state. In UML to represent this kind of dynamic nature there are five diagrams. 1. Use Case diagrams 2. Sequence diagrams 3. Activity diagrams 4. Collaboration diagrams 5. State chart diagrams Model management diagram Model management diagram gives a view how different application modules are managed , grouped and classified. For instance the below figure shows how Accounting, Payment and common routines are grouped and organized. Page 24 of 215
Figure 1.7: - Model Management diagram in action UML provides three diagrams by which we can get the Model Management view. Below are the three diagrams: - 1. Packages 2. Subsystems 3. Models Overall Explanation of the UML diagrams Class diagram Use to show real -world entities, elements of analysis and design, or implementation classes and their relationships Object diagram Use to show a specific or illustrative example of objects and their links. Often used to indicate the conditions for an event, such as a test or an operation call Composite structure diagram Use to show the how something is made. Especially useful in complex structures-of-structures or component-based design. Page 25 of 215
Deployment diagram Use to show the run-time architecture of the system, the hardware platforms, software artifacts (deliverable or running software items), and software environments (like operating systems and virtual machines). Component diagram Use to show organization and relationships among the system deliverables Package diagram Use to organize model elements and show dependencies among them Activity diagram Use to the show data flow and/ or the control flow of a behavior Captures workflow among cooperating objects Use case diagram Use to show the services that actors can request from a system in actor and role form. State machine diagram / Protocol state machine diagram Use to show the life cycle of a particular object, or the sequences an object goes through or that an interface must support. Overview diagram Use to show many different inter- action scenarios (sequences of behavior) for the same collaboration (a set of elements working together to accomplish a goal) Sequence diagram Use to focus on message exchange between a group of objects and the order of the messages. Communication diagram Use to focus on the messages between a group of objects and the underlying relationship of the objects Timing diagram Use to show changes and their relationship to clock times in real -time or embedded Systems work Which diagram is important In above section we have seen the basic definitions of all the UML diagrams. But in real projects we do not draw all the diagrams instead we look towards the complexity of the project or necessity of the project and accordingly we decide the diagrams and then Page 26 of 215
diagrams are added to the technical document or the requirement document. So in this book we will use two basic diagrams extensively: - Use case diagrams Class diagrams The other diagram will be used if required and their respective explanation will be provided at the same time. Let’s try to understand in detail the two basic diagram used in the project. The first one is the Use case diagram and explained as the follows Use case diagram over view It’s a user functionality which the user wants to be completed by the system. For example Travel Company’s director wants to book ticket, cancel ticket, refund ticket done by the system. So basically it defines the actions of the user in the system. It basically defines verbs of the system. The best way to identify a use case is by extracting verbs of the requirement document given by the end customer. Actors and Goals Every use case will have the below two components actors and goals. Actors are stake holders of the system. Stake holders provide requirement to your project and oppose in case of any issues. Normally software users are the actors. For instance in an accounting application accountant forms as an actor and for the same accounting application we have cashier and charted accountant as another form of actors for the system. Every actor has goal to perform when using the system. There are two types of actors: - Primary Actor: -This actor actually initiates the use case on the system. Secondary Actor: -While Secondary Actor contacts other actors or use cases to meet the Primary Actor’s goal. In the below example we have Ticket Reservation system here travel agent is a actor who is using reserving ticket application and booking a ticket, canceling a ticket and refunding a ticket. So booking, canceling and refunding of a ticket are goals performed by an actor. The figure below shows the diagrammatic view to represent relationship between actors and goals. But the diagram does not show the details of the goals. Page 27 of 215
Figure 1.8:- Actors and Goals in action So for the same we need to document it using use case documents which is explained in the coming section. In the next section we will go through a use case template which we will use in most of the project. Use case templates can be used to expand on the above diagram in more detail manner. Detail Explanation of the Use Case template Below is the use case template which we will be using in most of our project. So let’s understand every section of the template. Use case: - In order to identify particular use case we do unique numbering to it like UC001, UC002 or QUEST POND 001, QUEST POND 002 etc as there are N number of use cases in a project. Use case name: - It is a particular action taken by the user on the system or task get done from the system in the form such as booking a ticket, Canceling a ticket etc in actual which represents an action. Description:-It basically describes the details of a user case in a textual form. Primary actor: -Primary Actor is nothing but the user who actually initiates the goal. For example in a travel agency the director sees the report booking done by customers. So here the director acts as a primary actor who is fully interested in how much booking is done over a period of time. But he is not interested in making a booking as that’s the work of the travel agent. So in “Make booking” use case the travel agent acts as a primary actor and the director as the secondary actor. But in case of “View booking” use case the travel agent acts as a secondary actor and the director as a primary actor. Page 28 of 215
ليست هناك تعليقات:
إرسال تعليق