Unit 1

Introduction to Software Engineering

Q. 1) What is the software process?

Ans: Software Process

It is important to go through a series of predictable steps as you work to create a product or system - a road map that helps you produce a timely, high-quality result.

A " software process" is called the road map that you follow.

Technical definition:

The software process is a structure for the operations, activities and tasks needed to create high-quality software.

The term software specifies to the set of computer programs, procedures and

Associated documents (Flowcharts, manuals, etc.) that describe the program and

How they are to be used.

A software process is the set of activities and associated outcome that produce a

Software product. Software engineers mostly carry out these activities. These are

Four key process activities, which are common to all software processes.

These activities are:

1. Software specifications: The functionality of the software and constraints on

Its operation must be defined.

2. Software development: The software to meet the requirement must be

Produced.

3. Software validation: The software must be validated to ensure that it does

What the customer wants.

4. Software evolution: The software must evolve to meet changing client

Needs.

Q. 2) What do you mean by Nature of software?

Ans: Nature of Software

For systems engineering (SE) of software-intensive systems, the essence of the software medium has many implications. It is distinguished from other types of engineering objects by four software properties, taken together.

Such four properties are the following:

➢      Complexity

➢      Changeability

➢      Conformity

➢      invisibility

Brooks states:

“Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine — open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.”

Complexity:

The complexity of software emerges from the large number of specific components in a software system that communicate with each other.

The sections are special because they are encapsulated instead of being repeated as functions, subroutines, or objects, and invoked as necessary. There are many different types of interactions with software modules, including serial and concurrent invocations, state transformations, data couplings, and database and external device interfaces.

To illustrate the various static structures, dynamic couplings, and modes of interaction that occur in computer software, the depiction of a software object also involves many different design representations. Complexity within the components and in the relations between components requires significant design rigour and regression testing for modifications. For modules that are embedded, distributed and data based, software provides functionality.

As well as complicated algorithms and heuristics, software can implement simple control loops.

Complexity can cover defects that cannot be easily detected, requiring considerable additional and unplanned rework.

Changeability:

Software coordinates the operation of physical components and, in software-intensive systems, provides much of the features. Because software in a software-intensive system is the most malleable (easily changed) element, it is the most frequently changed element.

During the late stages of a development project and during system maintenance, this is particularly true. This does not mean, however, that software is easy to modify. Complexity and the need for conformity will make it an incredibly difficult task to update software.

In other parts of the system, modifying one aspect of a software system often results in undesired side effects, requiring further adjustments before the software can work at maximum performance.

Conformity:

Unlike a physical product, software has no fundamental natural rules that it must adhere to, such as the laws of motion of Newton. However, in the representation of and of its components, in the interfaces to other internal parts and in the connections to the world in which it works, the program must comply with exacting requirements.

A compiler may detect a missing semicolon or other syntactic error, but it may be difficult to detect a defect in the program logic or a timing error until it is encountered during operation.

Lack of conformity will trigger problems when it is not feasible to reuse an existing software feature as designed because it does not meet the needs of the product under development. This needs (usually) an unplanned allocation of resources which can delay completion of the project.

Invisibility:

Software, since it has no physical properties, is said to be invisible. Although the results of software execution on a digital device are measurable, it is not possible to see, taste, smell, touch, or hear the software itself. Software is an intangible entity because it is unable to be sensed directly by our five human senses.

Job products such as descriptions of specifications, design documents, source code and object code are software representations, but they are not software.

Software remains in the magnetization and current flow at the most elementary stage in an enormous number of electronic elements inside a digital system. Since software has no physical presence, in an effort to image the essentially intangible object, software engineers must use various representations at different levels of abstraction.

Uniqueness:

The uniqueness of software is another point about the existence of software that Brooks alludes to but does not specifically call out. For the following reasons, software and software projects are unique:

●      There are no physical properties for software;

●      The product of intellect-intensive team work is software;

●      Software developers' productivity varies more broadly than other engineering disciplines' productivity.

●      Software project risk management is primarily process-oriented;

●      Software alone, as it is often a part of a larger scheme, is useless, and

●      The most frequently updated aspect in software intensive systems is software.

Q. 3) Define Generic Process model.

Ans: Generic Process Model

The method is defined as a set of tasks, activities and tasks performed when a work product is to be produced. The acts and tasks of each of these activities are based on a structure or model that determines their relationship with the process and with each other.

A process model (also termed as software life cycle model) is a pictorial and diagrammatic representation of the software life cycle. A life cycle model represents

All the methods required to make a software product transit through its life cycle stages. It also captures the structure in which these methods are to be undertaken.

The software process is depicted schematically, with a collection of software engineering activities populating each framework activity.

A task set that defines the work tasks to be completed is defined by each software engineering activity.

The working products to be made, the points of quality assurance that will be needed, and the milestones to be used to demonstrate progress.

A generic system of process work for software engineering framework tasks -

➢      Communication

➢      Planning

➢      Modeling

➢      construction

➢      Deployment

Five application activities for communication, planning, modelling, construction, and deployment describe a common process framework for software engineering. In addition, a range of umbrella practices are implemented throughout the process: project monitoring and tracking, risk management, quality assurance, configuration management, technical reviews, and others. (called process flow)

Q. 4) Describe the linear sequential development model.

Ans: Linear Sequential development model

Often referred to as the classic life cycle or waterfall model. This model implies a sequential approach to software development that starts at the system level and progresses through analysis, coding, help, testing, etc.

Each of the five framework activities is carried out by a linear process flow, such as:

1) Information/System Engineering and Modeling

Software is part of a larger system or organization, work starts by defining for all system components and then assigning to software some subset of these requirements. Such modelling is important for the purpose of interaction.

2) Design

In reality, software design is a multi-step process that focuses on different programme attributes, such as data structure, software architecture, representations of interfaces, and procedural information. The design method transforms specifications into a software representation that can be checked for consistency before the beginning of coding.

3) Code generation

A machine-readable type must be converted into the design. This task is performed by the code generating stage. If construction is carried out in a comprehensive way, it is possible to work mechanistically in code generation. The code generator is supposed to produce code that is correct in an exact way.

4) Testing

Program testing starts after code creation. The testing process focuses on the software's logical internals, ensuring that all claims have been tested, and on the externals that perform tests to detect errors and ensure that specified input produces real results that comply with the results needed. Unit testing in computer programming is the process by which code source, sets of one or more computer programme modules along with associated control data are tested to determine if they are fit for use.

5) Support

After distribution to the client, the programme can change. There will be improvements because failures have been found as a result of changes in the external world. Changes can occur in the operating system or due to peripheral device errors.

Q. 5) What is the Iterative Development Model?

Ans: Iterative Development Model

The Life Cycle of Software Development (SDLC) is extremely vast and full of diverse practices, methodologies, methods, resources, and more for development and testing. Intense planning and management, estimation and training are involved. It is only after integrating all these attempts of the software engineers that a programme or software is successfully developed. The Iterative Model is also a part of the life cycle of software development.

It is a basic implementation of a life cycle of software development that focuses on an original, simpler implementation, which then gradually gains more complexity and a wider feature set before the final framework is complete. In brief, iterative development is a way of breaking down a big application's software development into smaller parts.

An iterative life cycle model does not start with a complete requirement specification. The development of this model starts by defining and implementing only part of the programme, which is then reviewed to decide further specifications. In addition, the iterative process begins with a basic implementation of a small set of software specifications in the iterative model, which iteratively develops the developing iterations until the entire framework is implemented and ready for deployment. In a particular and defined time span, which is called iteration, each release of the Iterative Model is created.

The iterative model is then used in the following scenarios:

●      When the parameters of the whole scheme are clearly described and understood.

●      The key requirements are established, while some features and requested changes change with the development phase process.

●      The development team is using a new technology and is learning it as they are working on the project.

●      If there are some high-risk attributes and priorities, these may change in the future.

●      When the tools with the appropriate skill sets are not available and are scheduled to be used for particular iterations on a contract basis.

Process of iterative model:

In comparison to the more conventional models that rely on a systematic step-by-step development process, the Iterative Model process is cyclic. In this phase, a handful of steps are repeated again and again until the initial planning is finished, with the end of each step refining and iterating on the programme incrementally.

The following defines other steps of the iterative model:

1. Planning Phase

This is the first step of the iterative model, where the team carries out proper preparation to assist them in mapping the documentation of the specifications, defining criteria for software or hardware and generally preparing for the next phases of the cycle.

2.     Analysis and Design Phase

If the preparation for the cycle is complete, an analysis is carried out to determine the required business logic, database models and to understand any other specifications of this specific level. In addition, in this step of the iterative model, the design phase also takes place, where technical specifications are defined that will be used to satisfy the need for the analysis phase.

3.     Implement Phase

This is the third step of the iterative model and the most critical one. Here, the method of actual implementation and coding is performed. In this initial iteration of the project, all planning, specification, and design documents up to this stage are coded and implemented.

4.     Testing Phase

Testing is started in the period after the current build version is coded and implemented to detect and find any possible vulnerabilities or problems that may have been in the programme.

5.     Evaluation Phase

The final stage of the Iterative life cycle is the assessment step, in which the whole team, along with the client, reviews the project status and validates whether it is up to the criteria proposed.

Q. 6) What do you mean by test driven development?

Ans: Test driven development

Plan-driven procedures are systems in which all process operations are carried out.

Designed in advance, and progress toward this strategy is calculated. Different device types include various software processes.

In the software process, agile approaches to software development consider design and execution to be the core activities. They introduce other tasks into the design and execution, such as the elicitation and testing of specifications.

By comparison, a software engineering plan-driven approach describes different phases in the software process with outputs associated with each step. As a basis for planning the following process operation, the outputs from one stage are used.

Iteration happens through tasks in an agile approach.

The specifications and the design are thus established together, rather than separately. Not necessarily a waterfall model of a plan-driven software operation, plan driven, incremental development and execution is feasible.

Allocating criteria and planning the design and development process as a sequence of increments is perfectly feasible. An agile process is not inevitably code-focused and some design documentation may be created.

Not necessarily a waterfall model of a plan-driven software operation, plan driven, incremental development and execution is feasible. It is entirely feasible to assign specifications and schedule the design and development process as a sequence of increments.

There are components of plan-driven and agile processes in most projects. It depends on technological, human and organizational issues to determine the balance:

1. Before moving to implementation, is it necessary to have a very comprehensive specification and design? If so, a plan-driven technique typically needs to be used by a software engineer.

2.     Is an incremental distribution approach practical, where the software developer delivers the software to customers and receives fast input from them? Consider using agile strategies if so.

3.     In order to help device growth, what technologies are available? Agile techniques rely on good instruments to keep track of a changing architecture

4.     What kind of scheme is being created? For programmes that require a lot of study before implementation, plan-driven approaches might be needed (e.g. Real-time system with complex timing requirements).

5.     What is the predicted lifetime of a system? In order to convey the original goals of the system developers to the support team, longer-life systems can require further design documentation.

6.     How big is the scheme that is being created? Where the framework can be built with a small co-located team who can communicate informally, agile approaches are most successful. For complex systems that need larger development teams, this may not be feasible, so a plan-driven approach may have to be used.

Q. 7) Describe the incremental Development Model.

Ans:  Incremental Development Model

The software development process that is often implemented is an incremental model. In software development, there are several models that have been developed to achieve various goals. These models define how the software is designed to enforce these phases at each point of iteration and process.

The choice of model depends entirely on the company and its software purpose, and this model choice also has a high influence on the methodologies for research. Agile, Waterfall, Gradual, RAD, Iterative, Spiral etc. include some of the popular models. We will look at one such model, known as the incremental model, in this article.

Incremental Model is one of the most common software development system models where in the life cycle of software development the software requirement is broken down into several standalone modules. Once the modules are divided, incremental development will be carried out in steps covering all the research, design, execution, performing all the testing or verification and maintenance required.

There will be a review at each incremental point on the basis of which the decision on the next move will be made.

The phases and progress of each incremental step are outlined below in the diagram:

You will see that we are going through research, design code and test process at each point of incremental growth, and by doing so we ensure that the different incremental phases are consistent and cumulative in helping to achieve the software's necessary goals.

Phase of incremental model:

Let us look at each stage in the growth of each incremental phase.

1. Requirement analysis

The review is completed on the requirement and how to make sure that this requirement is consistent with previously defined requirements.

2.     Design

Once I understand and clearly understand the criteria for this specific increase, design will be drawn up on how this requirement can be enforced and archived.

3.     Code

The coding is now carried out in compliance with the criteria to achieve the objective. Without any defaults and redundant hard codes, all the coding standards will be followed.

4.     Test

This is the last step in the incremental stage in which aggressive testing on the established code is carried out and defects are identified and corrected.

Q. 8) Write agility principles.

Ans: Agility Principles

For the methodologies used under the title "The Agile Movement," the Twelve Principles are the guiding principles. They define a community in which change is welcome, and the work focuses on the client. As stated by Alistair Cockburn, one of the signatories to the Agile Manifesto, they also illustrate the purpose of the movement to bring growth in line with business needs.

Agile development's twelve concepts include:

1. Customer satisfaction through early and continuous software delivery –

       Instead of waiting for long periods of time between launches, consumers are happier when they receive working apps at regular intervals.

2.     Accommodate changing requirements throughout the development process –

If a requirement or function request changes, the opportunity to avoid delays.

3.     Frequent delivery of working software –

As the team works in software sprints or iterations that ensure daily delivery of working software, scrum complies with this idea.

4.     Collaboration between the business stakeholders and developers throughout the project -

When the company and technical staff are aligned, better decisions are made.

5.     Support, trust, and motivate the people involved –

Motivated teams are more likely than dissatisfied teams to perform their best work.

6.     Enable face-to-face interactions –

When development teams are co-located, communication is more effective.

7.     Working software is the primary measure of progress –

The ultimate element that measures success is providing usable applications to the consumer.

8.     Agile processes to support a consistent development pace –

Teams set a repeatable and maintainable rate at which they will produce working software, and with each release they repeat it.

9.     Attention to technical detail and design enhances agility –

The right skills and good design ensure that the team can maintain the pace, enhance the product consistently, and manage change.

10. Simplicity –

Create just enough for the moment to get the job done.

11. Self-organizing teams encourage great architectures, requirements, and designs –

Professional and empowered members of the team who have decision-making authority, take responsibility, engage with other members of the team frequently, and exchange ideas that produce quality goods.

12. Regular reflections on how to become more effective –

Self-improvement, method improvement, capabilities enhancement, and strategies enable team members to work more effectively.

Q. 9) What are the Agile methods?

Ans: Agile methods

The Iterative Waterfall model was very common in earlier days to complete a project. But today, when using it to create a program, developers face different problems. During project growth, the key challenges included managing change requests from clients and the high cost and time needed to implement these changes. To counter these limitations of the Waterfall model, the Agile Software Development model was proposed in the mid-1990s

The Agile model was primarily designed to help a project to adapt to change requests quickly. So, the main aim of the Agile model is to facilitate quick project completion. Agility is necessary to achieve this mission. Agility is accomplished by adapting the approach to the project, eliminating behaviours that may not be important for a particular project. Something that is a waste of time and money is also stopped.

The Agile model actually applies to a community of production processes. Such procedures share certain fundamental features, but there are some subtle variations between them. Below are a few Agile SDLC models –

The specifications are decomposed into several small parts in the Agile model that can be built gradually. Iterative production is embraced by the Agile model. Over an iteration, each incremental component is created. Each iteration is intended to be small and simple to handle, and can only be completed in a few weeks. One version is scheduled, produced and deployed to the clients at a time. They do not make long-term plans.

The fusion of iterative and incremental process models is the Agile model. In agile SDLC models, the steps involved are:

The time for an iteration to be completed is known as a Time Box. The time-box refers to the maximum amount of time available for clients to deliver an iteration. So, it does not change the end date for an iteration. But, if required to produce it on time, the development team may decide to decrease the supplied functionality during a Time-box.

Q. 10) Describe Refactoring, and also write the benefits.

Ans: Refactoring

Refactoring consists of strengthening the internal structure of the source code of an existing application, while retaining its external actions.

The noun "refactoring" refers to one specific transformation that preserves actions, such as "Extract Method" or "Introduce Parameter."

Refactoring does "not" imply that:

Refactoring is dangerous in the absence of protections against the introduction of errors (i.e. breaching the condition of 'behaviour preserving'). Safeguards include regression testing aids, which include automated unit tests or automated acceptance tests, and formal reasoning aids, such as type systems.

The process of clarifying and simplifying the functionality of the current code without altering its behaviour is code refactoring. Agile teams retain and expand their code from iteration to iteration a great deal, and this is hard to do without constant refactoring. This is because code that is un-refactored appears to rust. Rot takes several forms: Unhealthy class or package dependencies, poor class responsibility allocation, way too many responsibilities per process or class, redundant code, and many other forms of uncertainty and clutter.

Code refactoring ruthlessly removes rot, keeping the code simple to maintain and expand. This versatility is the reason for refactoring and is the measure of its efficiency. But remember that if we have comprehensive unit test suites of the type we get if we work test-first, it is only "safe" to refactor the code this extensively. After each small step in refactoring, we run the risk of introducing bugs without being able to run certain tests.

Benefits:

The following benefits of refactoring are claimed:

Unit 1

Introduction to Software Engineering

Q. 1) What is the software process?

Ans: Software Process

It is important to go through a series of predictable steps as you work to create a product or system - a road map that helps you produce a timely, high-quality result.

A " software process" is called the road map that you follow.

Technical definition:

The software process is a structure for the operations, activities and tasks needed to create high-quality software.

The term software specifies to the set of computer programs, procedures and

Associated documents (Flowcharts, manuals, etc.) that describe the program and

How they are to be used.

A software process is the set of activities and associated outcome that produce a

Software product. Software engineers mostly carry out these activities. These are

Four key process activities, which are common to all software processes.

These activities are:

1. Software specifications: The functionality of the software and constraints on

Its operation must be defined.

2. Software development: The software to meet the requirement must be

Produced.

3. Software validation: The software must be validated to ensure that it does

What the customer wants.

4. Software evolution: The software must evolve to meet changing client

Needs.

Q. 2) What do you mean by Nature of software?

Ans: Nature of Software

For systems engineering (SE) of software-intensive systems, the essence of the software medium has many implications. It is distinguished from other types of engineering objects by four software properties, taken together.

Such four properties are the following:

➢      Complexity

➢      Changeability

➢      Conformity

➢      invisibility

Brooks states:

“Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine — open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.”

Complexity:

The complexity of software emerges from the large number of specific components in a software system that communicate with each other.

The sections are special because they are encapsulated instead of being repeated as functions, subroutines, or objects, and invoked as necessary. There are many different types of interactions with software modules, including serial and concurrent invocations, state transformations, data couplings, and database and external device interfaces.

To illustrate the various static structures, dynamic couplings, and modes of interaction that occur in computer software, the depiction of a software object also involves many different design representations. Complexity within the components and in the relations between components requires significant design rigour and regression testing for modifications. For modules that are embedded, distributed and data based, software provides functionality.

As well as complicated algorithms and heuristics, software can implement simple control loops.

Complexity can cover defects that cannot be easily detected, requiring considerable additional and unplanned rework.

Changeability:

Software coordinates the operation of physical components and, in software-intensive systems, provides much of the features. Because software in a software-intensive system is the most malleable (easily changed) element, it is the most frequently changed element.

During the late stages of a development project and during system maintenance, this is particularly true. This does not mean, however, that software is easy to modify. Complexity and the need for conformity will make it an incredibly difficult task to update software.

In other parts of the system, modifying one aspect of a software system often results in undesired side effects, requiring further adjustments before the software can work at maximum performance.

Conformity:

Unlike a physical product, software has no fundamental natural rules that it must adhere to, such as the laws of motion of Newton. However, in the representation of and of its components, in the interfaces to other internal parts and in the connections to the world in which it works, the program must comply with exacting requirements.

A compiler may detect a missing semicolon or other syntactic error, but it may be difficult to detect a defect in the program logic or a timing error until it is encountered during operation.

Lack of conformity will trigger problems when it is not feasible to reuse an existing software feature as designed because it does not meet the needs of the product under development. This needs (usually) an unplanned allocation of resources which can delay completion of the project.

Invisibility:

Software, since it has no physical properties, is said to be invisible. Although the results of software execution on a digital device are measurable, it is not possible to see, taste, smell, touch, or hear the software itself. Software is an intangible entity because it is unable to be sensed directly by our five human senses.

Job products such as descriptions of specifications, design documents, source code and object code are software representations, but they are not software.

Software remains in the magnetization and current flow at the most elementary stage in an enormous number of electronic elements inside a digital system. Since software has no physical presence, in an effort to image the essentially intangible object, software engineers must use various representations at different levels of abstraction.

Uniqueness:

The uniqueness of software is another point about the existence of software that Brooks alludes to but does not specifically call out. For the following reasons, software and software projects are unique:

●      There are no physical properties for software;

●      The product of intellect-intensive team work is software;

●      Software developers' productivity varies more broadly than other engineering disciplines' productivity.

●      Software project risk management is primarily process-oriented;

●      Software alone, as it is often a part of a larger scheme, is useless, and

●      The most frequently updated aspect in software intensive systems is software.

Q. 3) Define Generic Process model.

Ans: Generic Process Model

The method is defined as a set of tasks, activities and tasks performed when a work product is to be produced. The acts and tasks of each of these activities are based on a structure or model that determines their relationship with the process and with each other.

A process model (also termed as software life cycle model) is a pictorial and diagrammatic representation of the software life cycle. A life cycle model represents

All the methods required to make a software product transit through its life cycle stages. It also captures the structure in which these methods are to be undertaken.

The software process is depicted schematically, with a collection of software engineering activities populating each framework activity.

A task set that defines the work tasks to be completed is defined by each software engineering activity.

The working products to be made, the points of quality assurance that will be needed, and the milestones to be used to demonstrate progress.

A generic system of process work for software engineering framework tasks -

➢      Communication

➢      Planning

➢      Modeling

➢      construction

➢      Deployment

Five application activities for communication, planning, modelling, construction, and deployment describe a common process framework for software engineering. In addition, a range of umbrella practices are implemented throughout the process: project monitoring and tracking, risk management, quality assurance, configuration management, technical reviews, and others. (called process flow)

Q. 4) Describe the linear sequential development model.

Ans: Linear Sequential development model

Often referred to as the classic life cycle or waterfall model. This model implies a sequential approach to software development that starts at the system level and progresses through analysis, coding, help, testing, etc.

Each of the five framework activities is carried out by a linear process flow, such as:

1) Information/System Engineering and Modeling

Software is part of a larger system or organization, work starts by defining for all system components and then assigning to software some subset of these requirements. Such modelling is important for the purpose of interaction.

2) Design

In reality, software design is a multi-step process that focuses on different programme attributes, such as data structure, software architecture, representations of interfaces, and procedural information. The design method transforms specifications into a software representation that can be checked for consistency before the beginning of coding.

3) Code generation

A machine-readable type must be converted into the design. This task is performed by the code generating stage. If construction is carried out in a comprehensive way, it is possible to work mechanistically in code generation. The code generator is supposed to produce code that is correct in an exact way.

4) Testing

Program testing starts after code creation. The testing process focuses on the software's logical internals, ensuring that all claims have been tested, and on the externals that perform tests to detect errors and ensure that specified input produces real results that comply with the results needed. Unit testing in computer programming is the process by which code source, sets of one or more computer programme modules along with associated control data are tested to determine if they are fit for use.

5) Support

After distribution to the client, the programme can change. There will be improvements because failures have been found as a result of changes in the external world. Changes can occur in the operating system or due to peripheral device errors.

Q. 5) What is the Iterative Development Model?

Ans: Iterative Development Model

The Life Cycle of Software Development (SDLC) is extremely vast and full of diverse practices, methodologies, methods, resources, and more for development and testing. Intense planning and management, estimation and training are involved. It is only after integrating all these attempts of the software engineers that a programme or software is successfully developed. The Iterative Model is also a part of the life cycle of software development.

It is a basic implementation of a life cycle of software development that focuses on an original, simpler implementation, which then gradually gains more complexity and a wider feature set before the final framework is complete. In brief, iterative development is a way of breaking down a big application's software development into smaller parts.

An iterative life cycle model does not start with a complete requirement specification. The development of this model starts by defining and implementing only part of the programme, which is then reviewed to decide further specifications. In addition, the iterative process begins with a basic implementation of a small set of software specifications in the iterative model, which iteratively develops the developing iterations until the entire framework is implemented and ready for deployment. In a particular and defined time span, which is called iteration, each release of the Iterative Model is created.

The iterative model is then used in the following scenarios:

●      When the parameters of the whole scheme are clearly described and understood.

●      The key requirements are established, while some features and requested changes change with the development phase process.

●      The development team is using a new technology and is learning it as they are working on the project.

●      If there are some high-risk attributes and priorities, these may change in the future.

●      When the tools with the appropriate skill sets are not available and are scheduled to be used for particular iterations on a contract basis.

Process of iterative model:

In comparison to the more conventional models that rely on a systematic step-by-step development process, the Iterative Model process is cyclic. In this phase, a handful of steps are repeated again and again until the initial planning is finished, with the end of each step refining and iterating on the programme incrementally.

The following defines other steps of the iterative model:

1. Planning Phase

This is the first step of the iterative model, where the team carries out proper preparation to assist them in mapping the documentation of the specifications, defining criteria for software or hardware and generally preparing for the next phases of the cycle.

2.     Analysis and Design Phase

If the preparation for the cycle is complete, an analysis is carried out to determine the required business logic, database models and to understand any other specifications of this specific level. In addition, in this step of the iterative model, the design phase also takes place, where technical specifications are defined that will be used to satisfy the need for the analysis phase.

3.     Implement Phase

This is the third step of the iterative model and the most critical one. Here, the method of actual implementation and coding is performed. In this initial iteration of the project, all planning, specification, and design documents up to this stage are coded and implemented.

4.     Testing Phase

Testing is started in the period after the current build version is coded and implemented to detect and find any possible vulnerabilities or problems that may have been in the programme.

5.     Evaluation Phase

The final stage of the Iterative life cycle is the assessment step, in which the whole team, along with the client, reviews the project status and validates whether it is up to the criteria proposed.

Q. 6) What do you mean by test driven development?

Ans: Test driven development

Plan-driven procedures are systems in which all process operations are carried out.

Designed in advance, and progress toward this strategy is calculated. Different device types include various software processes.

In the software process, agile approaches to software development consider design and execution to be the core activities. They introduce other tasks into the design and execution, such as the elicitation and testing of specifications.

By comparison, a software engineering plan-driven approach describes different phases in the software process with outputs associated with each step. As a basis for planning the following process operation, the outputs from one stage are used.

Iteration happens through tasks in an agile approach.

The specifications and the design are thus established together, rather than separately. Not necessarily a waterfall model of a plan-driven software operation, plan driven, incremental development and execution is feasible.

Allocating criteria and planning the design and development process as a sequence of increments is perfectly feasible. An agile process is not inevitably code-focused and some design documentation may be created.

Not necessarily a waterfall model of a plan-driven software operation, plan driven, incremental development and execution is feasible. It is entirely feasible to assign specifications and schedule the design and development process as a sequence of increments.

There are components of plan-driven and agile processes in most projects. It depends on technological, human and organizational issues to determine the balance:

1. Before moving to implementation, is it necessary to have a very comprehensive specification and design? If so, a plan-driven technique typically needs to be used by a software engineer.

2.     Is an incremental distribution approach practical, where the software developer delivers the software to customers and receives fast input from them? Consider using agile strategies if so.

3.     In order to help device growth, what technologies are available? Agile techniques rely on good instruments to keep track of a changing architecture

4.     What kind of scheme is being created? For programmes that require a lot of study before implementation, plan-driven approaches might be needed (e.g. Real-time system with complex timing requirements).

5.     What is the predicted lifetime of a system? In order to convey the original goals of the system developers to the support team, longer-life systems can require further design documentation.

6.     How big is the scheme that is being created? Where the framework can be built with a small co-located team who can communicate informally, agile approaches are most successful. For complex systems that need larger development teams, this may not be feasible, so a plan-driven approach may have to be used.

Q. 7) Describe the incremental Development Model.

Ans:  Incremental Development Model

The software development process that is often implemented is an incremental model. In software development, there are several models that have been developed to achieve various goals. These models define how the software is designed to enforce these phases at each point of iteration and process.

The choice of model depends entirely on the company and its software purpose, and this model choice also has a high influence on the methodologies for research. Agile, Waterfall, Gradual, RAD, Iterative, Spiral etc. include some of the popular models. We will look at one such model, known as the incremental model, in this article.

Incremental Model is one of the most common software development system models where in the life cycle of software development the software requirement is broken down into several standalone modules. Once the modules are divided, incremental development will be carried out in steps covering all the research, design, execution, performing all the testing or verification and maintenance required.

There will be a review at each incremental point on the basis of which the decision on the next move will be made.

The phases and progress of each incremental step are outlined below in the diagram:

You will see that we are going through research, design code and test process at each point of incremental growth, and by doing so we ensure that the different incremental phases are consistent and cumulative in helping to achieve the software's necessary goals.

Phase of incremental model:

Let us look at each stage in the growth of each incremental phase.

1. Requirement analysis

The review is completed on the requirement and how to make sure that this requirement is consistent with previously defined requirements.

2.     Design

Once I understand and clearly understand the criteria for this specific increase, design will be drawn up on how this requirement can be enforced and archived.

3.     Code

The coding is now carried out in compliance with the criteria to achieve the objective. Without any defaults and redundant hard codes, all the coding standards will be followed.

4.     Test

This is the last step in the incremental stage in which aggressive testing on the established code is carried out and defects are identified and corrected.

Q. 8) Write agility principles.

Ans: Agility Principles

For the methodologies used under the title "The Agile Movement," the Twelve Principles are the guiding principles. They define a community in which change is welcome, and the work focuses on the client. As stated by Alistair Cockburn, one of the signatories to the Agile Manifesto, they also illustrate the purpose of the movement to bring growth in line with business needs.

Agile development's twelve concepts include:

1. Customer satisfaction through early and continuous software delivery –

       Instead of waiting for long periods of time between launches, consumers are happier when they receive working apps at regular intervals.

2.     Accommodate changing requirements throughout the development process –

If a requirement or function request changes, the opportunity to avoid delays.

3.     Frequent delivery of working software –

As the team works in software sprints or iterations that ensure daily delivery of working software, scrum complies with this idea.

4.     Collaboration between the business stakeholders and developers throughout the project -

When the company and technical staff are aligned, better decisions are made.

5.     Support, trust, and motivate the people involved –

Motivated teams are more likely than dissatisfied teams to perform their best work.

6.     Enable face-to-face interactions –

When development teams are co-located, communication is more effective.

7.     Working software is the primary measure of progress –

The ultimate element that measures success is providing usable applications to the consumer.

8.     Agile processes to support a consistent development pace –

Teams set a repeatable and maintainable rate at which they will produce working software, and with each release they repeat it.

9.     Attention to technical detail and design enhances agility –

The right skills and good design ensure that the team can maintain the pace, enhance the product consistently, and manage change.

10. Simplicity –

Create just enough for the moment to get the job done.

11. Self-organizing teams encourage great architectures, requirements, and designs –

Professional and empowered members of the team who have decision-making authority, take responsibility, engage with other members of the team frequently, and exchange ideas that produce quality goods.

12. Regular reflections on how to become more effective –

Self-improvement, method improvement, capabilities enhancement, and strategies enable team members to work more effectively.

Q. 9) What are the Agile methods?

Ans: Agile methods

The Iterative Waterfall model was very common in earlier days to complete a project. But today, when using it to create a program, developers face different problems. During project growth, the key challenges included managing change requests from clients and the high cost and time needed to implement these changes. To counter these limitations of the Waterfall model, the Agile Software Development model was proposed in the mid-1990s

The Agile model was primarily designed to help a project to adapt to change requests quickly. So, the main aim of the Agile model is to facilitate quick project completion. Agility is necessary to achieve this mission. Agility is accomplished by adapting the approach to the project, eliminating behaviours that may not be important for a particular project. Something that is a waste of time and money is also stopped.

The Agile model actually applies to a community of production processes. Such procedures share certain fundamental features, but there are some subtle variations between them. Below are a few Agile SDLC models –

The specifications are decomposed into several small parts in the Agile model that can be built gradually. Iterative production is embraced by the Agile model. Over an iteration, each incremental component is created. Each iteration is intended to be small and simple to handle, and can only be completed in a few weeks. One version is scheduled, produced and deployed to the clients at a time. They do not make long-term plans.

The fusion of iterative and incremental process models is the Agile model. In agile SDLC models, the steps involved are:

The time for an iteration to be completed is known as a Time Box. The time-box refers to the maximum amount of time available for clients to deliver an iteration. So, it does not change the end date for an iteration. But, if required to produce it on time, the development team may decide to decrease the supplied functionality during a Time-box.

Q. 10) Describe Refactoring, and also write the benefits.

Ans: Refactoring

Refactoring consists of strengthening the internal structure of the source code of an existing application, while retaining its external actions.

The noun "refactoring" refers to one specific transformation that preserves actions, such as "Extract Method" or "Introduce Parameter."

Refactoring does "not" imply that:

Refactoring is dangerous in the absence of protections against the introduction of errors (i.e. breaching the condition of 'behaviour preserving'). Safeguards include regression testing aids, which include automated unit tests or automated acceptance tests, and formal reasoning aids, such as type systems.

The process of clarifying and simplifying the functionality of the current code without altering its behaviour is code refactoring. Agile teams retain and expand their code from iteration to iteration a great deal, and this is hard to do without constant refactoring. This is because code that is un-refactored appears to rust. Rot takes several forms: Unhealthy class or package dependencies, poor class responsibility allocation, way too many responsibilities per process or class, redundant code, and many other forms of uncertainty and clutter.

Code refactoring ruthlessly removes rot, keeping the code simple to maintain and expand. This versatility is the reason for refactoring and is the measure of its efficiency. But remember that if we have comprehensive unit test suites of the type we get if we work test-first, it is only "safe" to refactor the code this extensively. After each small step in refactoring, we run the risk of introducing bugs without being able to run certain tests.

Benefits:

The following benefits of refactoring are claimed: