Build and Fix Model

SOFTWARE ENGINEERING NOTES PART 5 BUILD AND FIX MODEL Build and fix model is also called ad hoc model. In this the software is developed without any design or specification. And testing is also mostly ignored in this. This is the simplest model of software life cycle development. There are less requirements for making software in it. Through this model, when any initial software is ready, then it is delivered to the user. The user checks it, if he does not like the software, then the functions are added, modified and deleted in the software and this process continues until the user is satisfied with the software. But due to lack of software design and constant changes in it, very few users use such software. For this reason, software engineers rarely use this development approach. Phases of build and fix model There are two phases in this model: - 1:- Build:- In this phase the software code is developed and sent to the next phase. 2:- Fix:- In this phase the code is corrected and modified as per the requirement of the user. And the code is made error free. Advantages of build and fix model (Ad-hoc model): Its benefits are as follows:- 1: - Very little experience is required to develop software in this. 2: - In this, deep planning does not have to be done for software development. 3: - Initial software is prepared in this. Disadvantage of build and fix model:Its disadvantages are as follows:1: - The cost of making software in this is very high because it has to work in the software until the user is satisfied. 2: - The quality of the software is negligible. 3:- There are many risks in this. 4: - Maintenance of this software is very difficult. 5: - In this the design of the software is informal SOFTWARE MYTHS Software development requires dedication and understanding on the developer part. But sometimes a problem arises while developing some software and this problem is due to software myths. "Myth" means rumor or illusion, such things which are like a rumor or illusion are called myth. When the software is created or developed, then the developer has some myths, due to which the problem arises in developing the software. Software myths generate false beliefs and confusion in the mind of the developer. But it is just a myth, reality or reality is something else. Here we will compare the myth and reality of software development, what is the myth for the manager, user and developers while developing the software while the reality is something else. Because of which software can easily be made of good quality, work in budget, and in less time. Software myths are of three types – management myth user myth developer myth 1: - Management myth: - Managers are those who have the responsibility of developing the software. In software development, the manager has the pressure of better quality of software, budget, time constraints and many things. Managers have some myths to develop software – a) information :Myth - It is a myth to the manager that the developer should have complete information to make any software and this information is available to them from the manual, in which the procedure, principal and standard of making the software are given. Reality - The reality is that you can start developing software even with a little knowledge. Often the standard manual of the organization becomes outdated with time. And those who are developers do not know the manual of the organization, due to which the software delivery time increases by working according to the manual, so the developers use the manual very less. b) Scheduling :Myth - When the time to deliver the software starts to exceed the fixed time, then it is thought by the manager of some companies and organizations that the more developers there are to develop the software, the sooner the software will develop. Reality – But the reality is that some developers are new or even fresher, who take time to understand and develop the software, due to which the software delivery time increases further. c) Outsourcing :Myth – When a manager outsources (contracting) a third person to develop software, then he feels that now he can rest, there is no need to supervise him. Their software will be made third person door. Reality – But it is not like this, the reality is that even when the manager gives software to a third person for software development, he has to take care whether it is being done properly by that third person or not. Because if the third person does not do it properly, then there may be an internal problem in the software, due to which the organization may have to suffer later. 2: - User myth: - Most of the users have misconceptions about the software because the manager and developers do not try to remove the misconceptions of the user, due to which the user is never satisfied with the software. Some software myths of the user regarding software – a) requirements Myth – The user feels that it is enough to tell a little requirement in the beginning, later for software development, the rest of the requirement will be told in later stages. Reality – But for software development, the complete requirement has to be told in the beginning itself, because telling the requirement later takes extra resources and time, due to which the cost of the software also increases. b) Software flexibility:Myth – The user feels that the software has become the same after that it cannot be changed over time. Reality – While this is not the case in reality, software is flexible, it can be changed in the future with time and as per the need. 3: - Developer myth: - Developers have some software myths regarding software development a) Software deliver – Myth – The developer is under the illusion that after the coding of the software the software is complete and after the software delivery his work is over. Reality – The developer has to work even after the delivery of the software. The work of the developer does not end there. The developer has to do maintenance work even after software delivery. b) Project quality – Myth – The developer thinks that if the quality of the product for the project is good, then the software will also be good. Reality – It is not necessary that the good quality product that is being used for software development should also make the software better. Dedication and understanding is required to make software good. c) Documentation section – Myth - The developer is under the illusion that there is no need to create software requirement and specification (SRS). This will slow down software development.. Reality – software engineering creates software of good quality. And the documentation section improves the quality of the software. Due to the documentation, there is facility in re-working and maintenance on the software. V MODEL V-model is also called verification and validation (V&V) model. v-model is an SDLC model where the process is executed in V shape. The v-model is useful for each phase of the software development life cycle. The v-model which is an extension of the waterfall model. And it determines that each development phase is linked to the testing phase. This means that for each phase of software development there is a testing phase. This is a very disciplined model, in which the next phase starts only until the previous phase is completed. In the figure, there are verification phases in the left side and validation phases in the right side. This whole picture is looking like V, hence it is called V-model. PHASES OF V MODEL v-model verification phases:1: - requirements analysis: - This is the first phase of the development cycle, in which the requirements of the product are analyzed according to the needs of the customer. In this phase, the requirements related to the product are collected from the customer. This is a very important phase because this phase determines the phases to come. In this phase, acceptance tests are designed for later use. 2:- System design:- When we get the requirements of the product, now we prepare a complete design of the system. In this, a complete description of the hardware and all the technical components required to make the product is made. 3: - Architectural design: - In this phase the architectural specifications are designed. It contains the specification that how the software will be internally and externally linked with all the components. That's why this phase is also called high level design (HLD). 4: - Module design: - In this phase, the internal design of all the modules of the system is specified. That's why it is called low level design (LLD). It is very important that the design of all the modules is according to the system architecture. Unit tests are also designed in the module design phase. 5:- Coding phase:- In the coding phase, the coding of the design and specification done in the previous phases is done. This phase takes the most time. Suitable programming language is selected for coding and they are reviewed repeatedly while writing the code. validation phases:1: - Unit testing: - In the unit testing phase, the unit tests created during the module design phase are executed. Unit testing is code level testing, it only verifies the technical design. That's why it is not able to test all the defects. 2: - Integration testing: - In integration testing, the integration tests created in the architectural design phase are executed. Integration testing ensures that all modules are working well with each other. 3: - System testing: - In system testing, the system tests created in the system design phase are executed. System tests check the complete functionality of the system. In this, more attention is paid to performance testing and regression testing. 4: - Acceptance Testing: - In acceptance testing, the acceptance tests created in the requirement analysis phase are executed. This testing ensures that the system is compatible with other systems. And in this non-functional issues like: load time, performance etc. are tested in the user environment. Advantage of v-model:Following are the advantages of v-model:1: - This is a very disciplined model, in which only one phase is completed at a time. 2: - This is a very simple model, it can be easily understood and used. 3: - Due to the stiffness (hardness) of this model, it can be easily managed. 4:- In this planning and tests designing is done before coding which saves time. 5:- Defects in this are detected only in early stages. 6: - It is very good for small projects where the requirements can be understood well. 7: - Resources can be utilized well in this. Disadvantages of V-Model:Following are the disadvantge of v-model. 1: - There is a lot of risk and uncertainty in this. 2: - This model is not correct for large, difficult and object oriented projects. 3: - This is not a flexible model. 4:- If any change is made in between, then the test documents also have to be changed. SYSTEM MODELLING AND THEIR TYPES System modeling is also called system model. System modeling is a process. This process develops the entire structure of a system. This process develops an abstract model of the system, in which each model presents a different view or perspective of the system. Many models are involved in system modeling, that is, it is made up of many models. All the models in the system model are represented in a graphical way (in the form of pictures). We use graphical structure or graphical notation to represent the entire model or structure of any system which is based on a language called UML (unified modeling language). What is system modeling, it helps to understand the functionality of the system and model by analyzing it. Which is used to communicate with the customer. System perspective – There are four types of system perspective in system modeling – External perspective Interaction perspective structural perspective Behavioral perspective External perspective - External perspective is the perspective that is used to model or design an external environment of the system. Interaction perspective – An interaction perspective is the perspective, where we model (design) the interaction between a system and its environment or between the components of a system. Structural perspective – A structural perspective is the perspective where you model the organization of the system or the structure of the data processed by the system. Behavioral perspective - behavioral perspective is the perspective, where we design the dynamic behavior of the system. And let's see how it responds to events. UNIFIED MODELLING LANGUAGE (UML) The full form of UML is unified modeling language. Which is a standard for representing real world objects in an object oriented design methodology. That is, UML is a standard modeling language that contains a group of diagrams. Which helps developers to make models. UML diagram types – Here are five types of UML diagrams that represent the system design or architecture for any organization. Activity diagram - Activity diagram shows the activities involved in a process or in data processing. Use-case diagram - Use-case diagram shows the interaction between a system and its environment. Sequence diagram - The sequence diagram shows the interaction between the system and the components of the system. Class digram - Class digram shows the association between object classes and these classes in the system. State diagram - The state diagram shows how the system reacts to internal and external events. Types of system models There are many types of system models in which some models are described below – data model object model context model Behavioral model 1: – Data model – In the data model, we represent how our data is moving from one module to another. Data modeling is a type of system model. In the data model, the flow of input, output and processing data is represented by graphical notation. It is also called E-R modeling or E-R Notation. Different types of notation for the flow of data (data flow notation) – Rectangle shape - This shape is used to represent the external entities of any system. Data store – This shape is used to store many types of information or data in the data base. Data process / circle – This shape is used for processing any information or data in this notation. Diamond shape / decision making digram – This shape is used to represent the relationship between entities. Arrow – This shape is used to represent the movement of data left to right, right to left, top to bottom or bottom to top. Perception (SCHEMA) of data model – There are three types of perception to present the data model – Physical perception – In this, the database schema creates and checks how our database schema is related to each other. Conceptual perception – It is also called logical perception. In this, we see how our data is being inserted, deleted and updated. External perception – It is also called end user perception. In this, we see how and in which environment our data is being processed. 2: - Object model Object model is a type of system model. In which all real world problems are solved using objects. The object model which is the object, classes and the association between them describes the system. In the object model, complex projects can be easily developed with complete security. Classes are used in the object model to bind data information and their associated functions. In this model, we hide irrelevant or unnecessary information from end users. Various object models are used to produce object oriented approach which are as follows:Inheritance model - In this model, information or attribute of one class is inherited from another class. A class from which information is inherited by another class is called a super class and a class that inherits information from another class is called a subclass. Aggregation model - In aggregation model, we will show how classes are surrounded by other classes. In this model we will represent the relationship between the classes. Interaction model - In this model, we show how our data moves from one object to another. In the interaction model, the movement of data from one object to another is an important role of the interaction model. 3: - Context model Context model is a graphical representation. In this it is necessary to decide some basic things like cost and time. In this it is also decided that what functionality is to be put in the system and it is told that how a particular element is to be displayed. The context model is used to describe the operational context of a system. This system represents the environment in which the system is working. It decides the boundary using the requirement of the system. Its main goal is to produce a formal or semiformal description of context information in any system. 4: - Behavioral model The behavioral model is a type of system model. The behavioral model is used to describe the overall behavior of any system. In this model, we describe the data flow from one state to another and also describe the changes of state during the execution of the process. The following models are used to describe the behavior of any system – Data processing model – The data processing model describes the flow of data in the system. We use DFD to describe the flow of data. The full form of DFD is data flow diagram. DFD is a graphical notation which is used to represent the flow of data in the system. State machine model - State machine model describes the behavior of any system. It responds to external and internal events. The state machine model describes system states as nodes and events as arcs. When an event occurs, the system moves from one state to another.