Software Engineering unit 1

Unit 1 Chapter-1

Software and Software Engineering:

1.Software Engineering:

The term is made of two words, software and engineering.

Software is more than just a program code. A program is an executable

code, which serves some computational purpose. Software is considered to be collection of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product.

Engineering on the other hand, is all about developing products, using well-defined, scientific principles and methods.

Software engineering is an engineering branch associated with

development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product.

software engineering is a systematic, disciplined, and quantifiable approach.

Software Crisis

Software Crisis is a term used in computer science for the difficulty of writing useful and efficient computer programs in the required time. The software crisis was due to using the same workforce, same methods, same tools even though rapidly increasing in software demand, the complexity of software, and software challenges. With the increase in the complexity of software, many software problems arise because existing methods were insufficient. If we will use the same workforce, same methods, and same tools after the fast increase in software demand, software complexity, and software challenges, then there arise some problems like software budget problems, software efficiency problems, software quality problems, software managing and delivering problem, etc. This condition is called a software crisis.

 

Causes of Software Crisis:

 

·        The  cost  of   owning  and   maintaining         software was        as expensive as developing the software

·        At that time Projects were running over-time

·        At that time Software was very inefficient

·        The quality of the software was low quality

·        Software often did not meet user requirements

·        The average software project overshoots its schedule by half

·        At that time Software was never delivered

·        Non-optimal resource utilization.

·        Difficult to alter, debug, and enhance.

·        The software complexity is harder to change.

Let’s   now   understand which   factors   are           contributing                    to           the software crisis.

·        Poor project management.

·        Lack of adequate training in software engineering.

·        Less skilled project members.

·        Low productivity improvements.

Solution of Software Crisis:

 

There is no single solution to the crisis. One possible solution to a software crisis is Software Engineering because software engineering is a systematic, disciplined, and quantifiable approach. For preventing software crises, there are some guidelines:

·        Reduction in software over budget.

·        The quality of software must be high.

·        Less time is needed for a software project.

·        Experienced and skilled people working over the software project.

·        Software must be delivered.

·        Software must meet user requirements.

 

Software Development Lifecycle

 

SDLC (Software Development Life Cycle) is essentially a process that consists of a series of planned activities to develop, alter, or manage the software or pieces of software. SDLC is a structure to develop a software product that defines the process of planning, implementation, testing, documentation, deployment, and ongoing maintenance and support. The methodology within the SDLC process can vary across industry and organization, but the steps or phases remain same.

 

Following are the phases of SDLC

1.    Requirement gathering

2.    Analysis

3.    Design

4.    Implementation (Coding)

5.    Testing

6.    Deployment

7.    Maintenance

 

Requirement gathering

This is a fundamental phase of SDLC where user requirement or business requirement is gathered. The requirement is often gathered as an answer to the following questions.

·        What is the purpose of developing software?

·        Who is going to use the software?

·        How the end user will use the software?

·        What should be the input for software?

·        What will be the output of the software?

·        Where will the software be used?

Requirements are usually written in natural language and supplemented by diagrams for better understanding. This phase may include Functional and Non-functional requirements.

·        A functional requirement defines a function of a system or its components. A function is described as a set of inputs, the behavior, and outputs.

·        The non-functional requirements define system attributes, such as Performance, Scalability, Capacity, Availability, Reliability, Recoverability, Maintainability, and Serviceability.

Analysis

Analysis represents the “What” (What are the actual requirements?) and “How” (How are requirements accomplished independently?) phase. After requirement gathering, the requirement will be analyzed for validity and fulfillment.

 

The analysis phase starts with the document delivered by the requirement gathering phase and maps it into a full architecture. Detailed information on a programming language, the environment to accomplish the task, team, resources, platforms and algorithms etc. are established in this phase.

 

Design

In this phase, all systems and software designs are prepared from the specification which comes from the analysis phase. The design phase clearly defines all modules of a system with the help of relational diagrams. Testers will also define their “Test Strategy” (like what to test and how to test) in this phase.

 

The clear determination of how the system will look and how it will function can be done in a detailed manner.

 

Implementation (Coding)

Given the architecture document from the design phase and the requirement document from the analysis phase, the team should implement or build exactly what has been requested through programming code. The main focus of the developer is code here. High-level programming languages are used for coding (such as C#, JAVA, PHP etc). In this phase, the system can be ready to deploy in the user’s live environment.

Testing

Simply everyone knows the quality of the system is very important and the testing phase helps to create good quality. At this phase the whole system is tested to make sure that the system actually fulfills the entire requirement gathered in the Requirement Phase.

 

As everyone knows, it is hard to find one's own mistake and a fresh eye can find it better. So, the testing team finds defects, flaws, errors or bugs that can be made by the developer and resends it to the respective phase to fix it. All the Functional Testing like Unit Testing, Integration Testing, System Testing, and Non-Functional Testing will be done at this phase.

 

Deployment

Once the system is developed and tested properly, it will be ready to deploy, which means ready to deliver to the user. The system is not released fully in the first place or we can say that release can be done in a limited segment first and tested. It is called “Beta Version”. If any bugs are found at this stage, it will be reported to the engineering team and after solving it the final deployment will take place.

 

Maintenance

Once the system is delivered to the customer, the maintenance phase starts. While using the system, if the user gets any problem it will be solved in this phase by the organizations’ support team. The team at this stage makes sure that the released system will not make any problems for the users who are using it.

 

SDLC Models

There are various Software Development Life Cycle Models that have been defined according to different requirements. Each model has its unique series of steps or approaches to successfully accomplish user requirements.

Following are some popular SDLC models/ Process Models,

·        Waterfall Model

·        Spiral Model

·        V Model

·        Incremental Model

·        RAD Model and etc..

 

THE EVOLUTION OF SOFTWARE

Evolution of Software Engineering

The field of software engineering has evolved significantly since its inception, influenced by advances in technology, changes in user requirements, and the increasing complexity of software systems. Lets see the key stages and milestones in the evolution of software engineering.

1. Early Years (1940s-1960s):

1940s-1950s: The Dawn of Computing

Birth of Software Development: Software development began with the creation of the first electronic computers, such as ENIAC (Electronic Numerical Integrator and Computer).

Assembly Language and Machine Code: Early programming was done using machine code and assembly languages, which were low-level and hardware-specific.

1960s: The Software Crisis

Increased Complexity: As software systems grew more complex, the industry faced a "software crisis" characterized by project delays, budget overruns, and software failures.

Introduction of High-Level Languages: High-level programming languages n like FORTRAN and COBOL were developed to improve productivity and manage complexity.

Formal Methods: Early attempts at formalizing software development practices began, focusing on structured programming and flowcharting.

2. The Birth of Software Engineering (1968-1980s):

1968: NATO Conference on Software Engineering

Coining the Term: The term "software engineering" was coined at the NATO Software Engineering Conference to emphasize the need for disciplined engineering approaches to software development.

Focus on Methodologies: The conference highlighted the need for systematic methodologies to address the software crisis.

1970s: Methodologies and Tools

Waterfall Model: Winston W. Royce introduced the Waterfall Model, a linear sequential approach to software development.

Structured Programming: Concepts like modularity, top-down design and stepwise refinement were promoted by pioneers.

Software Tools: Development of tools like compilers, debuggers, and version control systems began to support the software development process.

3. The Rise of Software Engineering Practices (1980s - 1990s):

1980s: Object-Oriented Programming

OOP Paradigm: Object-oriented programming (OOP) languages like C++ and Smalltalk gained popularity, promoting concepts like encapsulation, inheritance, and polymorphism.

Software Reusability: Emphasis on creating reusable software components to improve development efficiency.

1990s: The Internet and Agile Methods

Internet Boom: The rise of the internet and web technologies transformed software development, requiring new approaches to handle distributed and dynamic systems.

Agile Manifesto (2001): In response to the limitations of traditional methodologies, the Agile Manifesto was published, promoting iterative development, collaboration and flexibility.

Unified Modelling Language (UML): UML became the standard for modeling and designing software systems.

4. Modern Software Engineering (2000s - Present):

2000s: Agile and DevOps

Agile Adoption: Agile methodologies like Scrum and Extreme Programming (XP) became mainstream, emphasizing iterative development, customer feedback, and cross-functional teams.

DevOps Movement: The DevOps movement emerged, integrating development and operations to improve deployment frequency and reliability.

 

2010s: Cloud Computing and Microservices

Cloud Computing: The advent of cloud computing platforms like AWS, Azure, and Google Cloud revolutionized software deployment and scalability.

Microservices Architecture: Adoption of microservices architecture enabled building scalable. maintainable, and loosely coupled systems.

2020s: AI, ML, and Automation

Learn Intern

Artificial Intelligence (AI) and Machine Learning (ML): Integration of AI and ML into software development for predictive analytics, automation, and intelligent systems.

Automation and CI/CD: Widespread adoption of continuous integration and continuous deployment (CI/CD) practices for faster and more reliable software releases.

Key Trends and Future Directions:

1. AI and Machine Learning Integration:

Leveraging AI and ML for smarter development tools, automated testing, and enhanced decision-making.

2. Blockchain Technology:

Exploring blockchain for secure, decentralized applications and smart contracts.

3. Quantum Computing:

Research into quantum computing for solving complex computational problems.

4. Ethical and Responsible AI:

Emphasis on ethical considerations, bias mitigation, and transparency in Al system stern

5. Cybersecurity:

Increased focus on building secure software to combat growing cyber threats.

Conclusion

The evolution of software engineering reflects the ongoing efforts to manage increasing complexity, improve development processes, and meet changing user needs. From the early days of coding with machine languages to the current era of AI-driven development and cloud computing, software engineering continues to adapt and innovate, shaping the future of technology and society.

 

 

Characteristics of Software

There’re many characters for good software. They include the following.

Ø Software is developed or engineered, but not Manufactured.

Ø Software does not wear out.

Ø Software is built Customer.

 

Ø Correctness

Correctness is important for good software. There shouldn’t be faults with specification, design or implementation.

Ø Usability

Users should be able to learn and use a system easily.

 

Ø Efficiency

 

The less resource a piece of software uses, the better. Processor, memory and disk space usage should be minimized.

Ø Reliability

A system that can perform the required functions stably is important. Failures should be as rare as possible.

Ø Integrity

Security should be taken into account. Our software should let attackers access unauthorized resources.

 

Also, data validation is important so that bad data can’t be saved into the system.

 

Ø Adaptability

A system that can be used without modification for different situations it’s good.

Ø Accuracy

The accuracy of its outputs is good. This measures if the software outputs the right results for users.

Ø Robustness

If a system is still working after getting invalid inputs and stressful environmental conditions, then it’s good for our system.

Ø Maintainability

The ease in which an existing system can be changed is important. The easier that we can make changes, the better.

 

Ø Portability

A system that operates in different environments from which it’s originally designed makes it good.

Ø Reusability

The more reusable parts that a piece of software has, the better.

 

Using reusable parts means that we don’t have to reuse them from scratch.

 

Ø Readability

Easy to read code is easy to change code. If we understand them faster, then we can make changes faster and in a less error-prone way.

Ø Testability

Making our software system testable is critical. If our code is easy to write unit tests for, then that’s good.

Ø Understandability

The ability for us to understand our system in a global view or at the detailed code level is important.

Easier to understand systems are more coherent.

 

With good software, it’s harder for us to create defects, and it’s faster to make changes.

Importance of Software Engineering

 

 

 

The importance of Software engineering is as follows:

1.    Reduces complexity:

Big software is always complicated and challenging to progress. Software engineering has a great solution to reduce the complication of any project. Software engineering divides big problems into various small issues. And then start solving each small issue one by one. All these small problems are solved independently to each other.

2.    To minimize software cost:

Software needs a lot of hardwork and software engineers are highly paid experts. A lot of manpower is required to develop software with a large number of codes. But in software engineering, programmers project everything and decrease all those things that are not needed. In turn, the cost for software productions becomes less as compared to any software that does not use software engineering method.

3.    To decrease time:

Anything that is not made according to the project always wastes time. And if you are making great software, then you may

need to run many codes to get the definitive running code. This is a very time-consuming procedure, and if it is not well handled, then this can take a lot of time. So if you are making your software according to the software engineering method, then it will decrease a lot of time.

 

 

4.    Reliable software:

Software should be secure, means if you have delivered the software, then it should work for at least its given time or subscription. And if any bugs come in the software, the company is responsible for solving all these bugs. Because in software engineering, testing and maintenance are given, so there is no worry of its reliability.

5.    Effectiveness:

Effectiveness comes if anything has made according to the standards. Software standards are the big target of companies to make it more effective. So Software becomes more effective in the act with the help of software engineering.

 

 

SOFTWARE DEVELOPMENT PROJECTS

 

What is Software Development?

 

Software Development is defined as the process of designing, creating, testing, and maintaining computer programs and applications. Software development plays an important role in our daily lives. It empowers smartphone apps and supports businesses worldwide.

Software developers develop the software, which itself is a set of instructions in order to perform a specific task. software have three types.

 

Types of Software

 

There are three basic types of Software

1. System Software

System software is software that directly operates computer hardware and provides basic functionality to users as well as other software for it to run smoothly.

2. Application Software

Application software is a software that is designed for end-user to complete a specific task. It is a product or program that is only intended to meet the needs of end users. It includes word processors, spreadsheets, database management, inventory, and payroll software, among other things.

3. Programming Software

Programming software is a software that is designed for programmers to develop program. It consist of code editor, compiler, interpreter, debugger etc.

Under Software Development, developers develop all the software that comes under these three category.

 

Types of Software Development Projects

You might be surprised to know that there are different types of software development projects, each with its own flavor and challenges.

·        Waterfall Model: Think of it as a waterfall cascading down, each stage flowing seamlessly into the next. This traditional model is structured and linear, with clear deadlines and deliverables. It's perfect for projects with well-defined requirements, but can be less flexible if changes arise.

·        Agile Model: Imagine a team of agile athletes, adapting quickly to changes and reaching their goals. This iterative approach focuses on flexibility and collaboration, with frequent feedback loops and adjustments. Agile is a favorite for complex projects where requirements might change often.

·        DevOps Model: Think of it as a seamless symphony of development and operations teams, working in harmony. DevOps emphasizes automation, continuous integration, and collaboration between these teams. This model is popular for organizations looking for rapid deployments and enhanced stability.

·         

Stages of a Software Development Project

 

Let's break down the typical stages of a software development project. It's a journey that requires careful planning, execution, and communication.

1.    Planning: This is where the foundation is laid. Here you define the project's scope, requirements, and deliverables. Think of it as the blueprint for your software.

2.    Design: The architectural phase. This involves designing the software's structure, user interface, and database. It's about bringing the blueprint to life.

3.    Development: The core of the project. This is where the coding takes place, transforming the design into a working application. It's the construction phase.

4.    Testing: Ensuring quality. This stage involves testing the software to identify and fix bugs and ensure it meets the requirements. It's like a quality inspection.

5.    Deployment: Launching your masterpiece. This involves making the software available to users, either through a release or a cloud deployment. It's the grand opening!

6.    Maintenance: Keeping the software running smoothly. This ongoing stage involves fixing bugs, implementing updates, and providing support to users. Think of it as ongoing maintenance of your house.

 

 

Exploratory Style of Software Development

 

In the early’s 60, there were no Software Engineering Processes and Guidelines such as SDLC. They were following the Exploratory Software Development Process, also called build and fix style. It only focuses on detecting errors at the testing phase and quickly fixes them, and does the same repeatedly until the time all the errors are being fixed for that release.

 

Steps for Exploratory Style of Software Development

·        A dirty program is quickly developed.

·        The bugs are fixed as and when they are noticed.

However, this approach can be followed when a single developer handles a project or assignment. The code sizes are manageable and within the grasp of an individual. The major advantage of following this style is that no need to document everything. It depends on the individual to decide which part needs to be documented and how to proceed. An individual may follow any of the following sequences:

·        Code -> Test -> Design

·        Code -> Design -> Test -> Change code

·        Specify -> Code -> Design -> Test

Why does this type of style not work or scale well with a bigger size of projects?

A small program has just a few variables or few logic components, and in this case, it is easy to grasp individual modules or logic components. But, as the number of independent logic components increases. It quickly exceeds the grasping power of an individual and requires an unduly large effort to master the problem. (This is because of human cognitive limitations). This may lead to Software Crisis.

 

Emergence of Software Engineering

 

Software engineering emerged in the late 1960s as a new engineering discipline that addressed all aspects of software production:

 

Background

 

The roots of software engineering can be traced back to the 1940s and 1950s, when software was considered part of computer science. However, as computers became more complex, the need for specialized software developers became apparent.

 

The "software crisis"

 

The term "software engineering" was first used at the 1968 NATO Software Engineering Conference in Garmisch, Germany. The conference was held in response to the "software crisis", a period when it was difficult to deliver reliable and efficient software on time.

 

Key figures

 

Key figures in the early development of software engineering include Dijkstra, Brooks, and Knuth.

 

Systematic approach

 

Software engineering emphasizes a systematic, disciplined approach to software development. This includes:

• Concept creation

* Requirements specification

* Design

* Implementation 

* Integration  

* Testing

* Deployment 

* Maintenance

 

Software quality

 

High-quality software is characterized by:

• Dependability 

* Efficiency

* Usability

* Accessibility  

* Maintainability

 

 

 

 

THE CHANGING NATURE OF SOFTWARE:

The   7   broad   categories   of   computer         software    present continuing challenges for software engineers:

*   System software

*   Application software

*   Engineering/scientific software

*   Embedded software

*   Product-line software

*   Web-applications software

*   Artificial intelligence software.

System software:

System software is a collection of programs written to service other programs. The systems software is characterized by heavy interaction with computer hardware heavy usage by multiple users concurrent operation that requires scheduling, resource sharing, and sophisticated process management complex data structures multiple external interfaces

E.g. compilers, editors and file management utilities.

Application software:

Application software consists of standalone programs that solve a specific business need. It facilitates business operations or management/technical decision making. It is used to control business functions in real-time

E.g. point-of-sale transaction processing, real-time manufacturing process control.

Engineering/Scientific software:

Engineering and scientific applicationsrange -from astronomy to volcanology - from automotive stress analysis to space shuttle orbital dynamics - from molecular biology to automated manufacturing

E.g. computer aided design, system simulation and other interactive applications.

Embedded software: Embedded software resides within a product or system and is used to implement and control features and functions for the end-user and for the system itself. It can perform limited and esoteric functions or provide significant function and control capability. SOFTWARE ENGINEERING Page 3

E.g. Digital functions in automobile, dashboard displays, braking systems etc.

Product-line software:

Designed to provide a specific capability for use by many different customers, product-line software can focus on a limited and esoteric market place or address mass consumer markets

E.g. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications

Web-applications:

WebApps are evolving into sophisticated computing environments that not only provide standalone features, computing functions, and content to the end user, but also are integrated with corporate databases and business applications.

Artificial intelligence software:

AI software makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Application within this area includes robotics, expert systems, pattern recognition, artificial neural networks, theorem proving, and game playing.

 

Notable changes in software development practices

 

Some notable changes in software development practices include: 

 

Artificial intelligence (AI)

 

AI is increasingly used in many software applications, from computer vision to predictive analytics.

 

Blockchain

 

Blockchain technology is being used more in software development for secure data storage, identity verification, and supply chain management.

 

DevOps

 

DevOps integrates development and operations to improve efficiency, reduce time-to-market, and improve software quality. 

 

Version control

 

Version control systems help developers track changes and collaborate.  

 

Cybersecurity

 

Cybersecurity is an important part of modern software solutions, as hackers and security providers are constantly developing new technologies to outsmart each other.

 

Edge computing

 

Edge computing brings computation and storage closer to where data is generated, allowing for real-time analysis and processing.

 

Quantum computing

 

Quantum computing uses quantum bits, or qubits, instead of classical bits, allowing for faster data processing. 

 

Automation

 

Automation technology can help minimize human involvement. 

 

Deployment

 

Deployment is the process of making a system available to end-users after the testing phase is complete. 

 

 

Other notable changes in software development practices include: 

 

* Low-code and no-code development

* Cloud computing

* Rust programming language

* Internet of Things (IoT)

* Progressive Web Apps (PWAs)

* Microservices architecture

* DevSecOps approach

 

 

Software Myths

 

Software Myths:

Most, experienced experts have seen myths or superstitions (false beliefs or interpretations) misleading attitudes (naked users) which creates Major problems for management and technical people. The opposite Types of software-related myths are listed below.

 

Types of Software Myths

 

(i) Management Myths:

Manages with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality.

 

Myth 1:

We have all the standards and procedures available for software development i.e. the software developer has all the reqd.

Fact:

·        Software experts do not know that there are all of them levels.

·        Such practices may or may not be expired at present / modern software engineering methods.

·        And all existing processes are incomplete.

 

Myth 2:

The addition of the latest hardware programs will improve the software development.

Fact:

·        The role of the latest hardware is not very high on standard software development; instead (CASE) Engineering tools help the computer they are more important than hardware to produce quality and productivity.

·        Hence, the hardware resources are misused.

 

Myth 3:

 

 

 

Fact:

·        Managers think that, with the addition of more people and program planners to Software development can help meet project deadlines (If lagging behind).

 

·        Software development is not, the process of doing things like production; here the addition of people in previous stages can reduce the time it will be used for productive development, as the newcomers would take time existing developers of definitions and understanding of the file project. However, planned additions are organized and organized It can help complete the project.

 

(ii) Customer Myths:

The customer can be the direct users of the software, the technical team, marketing / sales department, or other company. Customer has myths

Leading to false expectations (customer) & that’s why you create dissatisfaction with the developer.

Myth 1 :

A general statement of intent is enough to start writing plans (software development) and details of objectives can be done over time.

Fact:

·        Official and detailed description of the database function, ethical performance, communication, structural issues and the verification process are important.

·        It is happening that the complete communication between the customer and the developer is required.

 

Myth 2 :

·        Project requirements continue to change, but change can be easy location due to the flexible nature of the software.

Fact:

·        Changes were made to the final stages of software development but cost to make those changes grow through the latest stages of Development.

·        A detailed analysis of user needs should be done to minimize change requirement.

 

(iii) Practitioner’s Myths:

Myths that are still believed by software practitioners: during the early days of software, programming was viewed as an art from old ways and attitudes die hard.

 

Myths 1 :

They believe that their work has been completed with the writing of the plan and they received it to work.

Fact:

·        It is true that every 60-80% effort goes into the maintenance phase (as of the latter software release). Efforts are required, where the product is available first delivered to customers.

 

Myths 2:

There is no other way to achieve system quality, behind it done running.

Fact:

·        Systematic review of project technology is the quality of effective software verification method. These updates are quality filters and more accessible than test.

Myth 3:

An operating system is the only product that can be successfully exported project.

Fact:

·        A working system is not enough, it is just the right document brochures and booklets are also reqd. To provide for guidance & software support.

Myth4:

Engineering   software   will   enable   us   to   build                      powerful  and unnecessary document & always delay us.

Fact:

·        Software engineering does not deal with text building, rather while creating better quality leads to reduced recycling & this is being studied for rapid product delivery.

Unit -1   Chapter-2

 

 

Software Process and Process Models

 

 

Software Process

A software process (also known as software methodology) is a set of related activities that leads to the production of the software. These activities may involve the development of the software from the scratch, or, modifying an existing system.

 

Any software process must include the following four activities:

 

1.    Software specification (or requirements engineering): Define the main functionalities of the software and the constraints around them.

2.    Software design and implementation: The software is to be designed and programmed.

3.    Software verification and validation: The software must conform to its specification and meet the customer's needs.

4.    Software evolution (software maintenance): The software is being modified to meet customer and market requirements changes.

Software engineering - Layered technology

Software Engineering is a layered technology. It is the application of principles uses in the field of engineering, which usually deals with

physical systems, to the design, development, testing, deployment and management of systems.

The main objective of software engineering layers is to help software developers obtain high-quality software. There are four types of layers in Software Engineering such as – Tools, methods, process, A quality focus.

 

·      Software engineering is a fully layered technology.

·      To develop a software, we need to go from one layer to another.

·      All these layers are related to each other and each layer demands the fulfillment of the previous layer.

 

 

 

The              layered             technology             consists                    of:

 

1.   Quality focus:

It is a culture that ultimately leads to the development of software engineering.

The characteristics of good quality software are:

·      Correctness of the functions required to be performed by the software.

·      Maintainability of the software

·      Integrity i.e. providing security so that the unauthorized user cannot access information or data.

·      Usability i.e. the efforts required to use or operate the software.

2.   Process

A process defines who is doing what, when and how to reach a certain goal. The software process forms the basis for management control of software projects. It establishes the context in which technical methods are applied for work products are produced.

·      It   is   the  base  layer  or   foundation  layer  for  the software engineering.

·      The software process is the key to keep all levels together.

·      It defines a framework that includes different activities and tasks.

·      In short, it covers all activities, actions and tasks required to be carried out for software development.

3.   Methods

·      The method provides the answers of all 'how-to' that are asked during the process.

·      It provides the technical way to implement the software.

·      It includes collection of tasks starting from communication, requirement analysis, analysis and design modelling, program construction, testing and support.

4.   Tools

·      The software engineering tool is an automated support for the software development.

·      The tools are integrated i.e the information created by one tool can be used by the other tool.

·      For example: The Microsoft publisher can be used as a web designing tool.

 

Software Process Framework

·        A process framework establishes the foundation for a complete software process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity.

·        In addition, the process framework encompasses a set of activities that are applicable across the entire software process.

·        Referring the following figure, each framework activity is populated by an asset of software engineering actions- a

collection of related tasks that produces a major software engineering work product (e.g. design is a software engineering action).

·        Each action is populated with individual work tasks that accomplish some part of the work implied by the action.

·        The following generic process (used as a basis for the description of process models in subsequent chapters) is applicable to the vast majority of software projects:

1.   Communication

This framework activity involves heavy communication and collaboration with the customer (and other stakeholders) and encompasses requirements gathering and other related activities.

2.   Planning

This activity establishes a plan for the software engineering work that follows. It describes the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule.

3.   Modelling

This activity encompasses the creation of models the developer and the customer to better understand software requirements and the design that will achieve those requirements.

4.   Construction

This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.

5.   Deployment

The software (as a complete entity or as a partially completed increment) is delivered to the customers who evaluates the delivered product and provide feedback based on the evaluation.

UMBRELLA ACTIVITIES:

The following are the set of Umbrella Activities.

1)   Software project tracking and control – allows the software team to assess progress against the project plan and take necessary action to maintain schedule.

2)   Risk Management - assesses risks that may effect the outcome of the project or the quality of the product.

3)   Software Quality Assurance - defines and conducts the activities required to ensure software quality.

4)   Formal Technical Reviews - assesses software engineering work products in an effort to uncover and remove errors before they are propagated to the next action or activity.

5)    Measurement - define and collects process, project and product measures that assist the team in delivering software that needs customer’s needs, can be used in conjunction with all other framework and umbrella activities.

6)    Software configuration management - manages the effects of change throughout the software process.

7)   Reusability management - defines criteria for work product reuse and establishes mechanisms to achieve reusable components.

8)    Work Product preparation and production - encompasses the activities required to create work products such as models, document, logs, forms and lists.

 

Software   Engineering   Institute   Capability                  Maturity        Model (SEICMM) / CMMI

The Capability Maturity Model (CMM) is a procedure used to develop and refine an organization's software development process.

The model defines a five-level evolutionary stage of increasingly organized and consistently more mature processes.

CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center promote by the U.S. Department of Defense (DOD).

Capability Maturity Model is used as a benchmark to measure the maturity of an organization's software process.

In CMMI models with a staged representation, there are five maturity levels designated by the numbers 1 through 5

1.    Initial

2.    Repeatable

3.    Defined

4.    Quantitatively Managed

5.    Optimizing

 

 

Level 1: Initial

At maturity level 1, processes are usually ad hoc. The organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes.

Maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects.

Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes.

Level 2: Repeatable

At this level, the fundamental project management practices like tracking cost and schedule are established. maturity level 2 helps to ensure that existing practices are retained during times of stress. When

these practices are in place, projects are performed and managed according to their documented plans.

Level 3: Defined

At  maturity  level  3,  an  organization  has  achieved  all the specific and generic goals of the process areas assigned to maturity levels 2 and 3.

At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods.

At this level, the methods for both management and development activities are defined and documented. There is a common organization-wide understanding of operations, roles, and responsibilities. The ways through defined, the process and product qualities are not measured.

Level 4: Managed

At maturity level 4, an organization has achieved all the specific goals of the process areas assigned to maturity levels 2, 3, and 4 and the generic goals assigned to maturity levels 2 and 3.

At maturity level 4 Subprocesses are selected that significantly contribute to overall process performance. These selected subprocesses are controlled using statistical and other quantitative techniques.

A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.

Level 5: Optimizing

At maturity level 5, an organization has achieved all the specific goals of the process areas assigned to maturity levels 2, 3, 4, and 5 and the generic goals assigned to maturity levels 2 and 3.

Processes are continually improved based on a quantitative understanding of the common causes of variation inherent in processes.

Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements.

Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement.

 

The Process and Product Process:

Process is a set of sequence steps that have to be followed to create a project. The main purpose of a process is to improve the quality of the project. The process serves as a template that can be used through the creation of its examples and is used to direct the project.

 

Product:

 

In the context of software engineering, Product includes any software manufactured based on the customer’s request. This can be a problem solving software or computer based system. It can also be said that this is the result of a project.

Let’s see the difference between Product and Process:-

 

S.NO	Product	Process
1.	Product     is     the                 final production of the project.	While the process is a set of sequence steps that have to be followed to create a project.
2.	A product focuses on the final result.	Whereas the process is focused on completing each step being developed.
3.	In the case of products, the firm guidelines are followed.	In contrast, the process consistently                                    follows guidelines.
4.	A   product   tends   to      be short-term.	Whereas the process tends to be long-term.
5.	The   main   goal   of         the product is to complete the work successfully.	While   the   purpose   of             the process is to make the quality of the project better.

 

 

software process models

Software processes are the activities for designing, implementing, and testing a software system.

A software process model is an abstraction of the software development process. The models specify the stages and order of a process. So, think of this as a representation of the order of activities of the process and the sequence in which they are performed.

*NOTE* The goal of a software process model is to provide guidance for controlling and coordinating the tasks to achieve the end product and objectives as effectively as possible.

There are many kinds of process models for meeting different requirements. We refer to these as SDLC models (Software Development Life Cycle models). The most popular and important SDLC models are as follows:

·        Waterfall model

·        V model

·        Incremental model

·        RAD model

·        Spiral model

 

 

Waterfall Model

The waterfall model is a sequential, plan driven-process where you must plan and schedule all your activities before starting the project. Each activity in the waterfall model is represented as a separate phase arranged in linear order.

This model has five phases:

·        Requirements

·        Design

·        Implementation

·        Testing

·        Deployment

·        Maintenance

The steps always follow in this order and do not overlap. The developer must complete every phase before the next phase begins. This model is named "Waterfall Model", because its diagrammatic representation resembles a cascade of waterfalls.

The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of

the previous one and corresponds to a specialisation of tasks. The approach is typical for certain areas of engineering design.

The waterfall model is easy to understand and follow. It doesn’t require a lot of customer involvement after the specification is done. Since it’s inflexible, it can’t adapt to changes. There is no way to see or try the software until the last phase.

The waterfall model has a rigid structure, so it should be used in cases where the requirements are understood completely and unlikely to radically change.

1. Requirements analysis and specification phase:

The aim of this phase is to understand the exact requirements of the customer and to document them properly. Both the customer and the software developer work together so as to document all the functions, performance, and interfacing requirement of the software. It describes the "what" of the system to be produced and not "how."In this phase, a large document called Software Requirement Specification (SRS) document is created which contained a detailed description of what the system will do in the common language.

2.     Design Phase:

This phase aims to transform the requirements gathered in the SRS into a suitable form which permits further coding in a programming language. It defines the overall software architecture together with high level and detailed design. All this work is documented as a Software Design Document (SDD).

3.     Implementation and unit testing:

During this phase, design is implemented. If the SDD is complete, the implementation or coding phase proceeds smoothly, because all the information needed by software developers is contained in the SDD. During testing, the code is thoroughly examined and modified. Small modules are tested in isolation initially. After that these modules are tested by writing some overhead code to check the interaction between these modules and the flow of intermediate output.

4.    Integration and System Testing: This phase is highly crucial as the quality of the end product is determined by the effectiveness of the testing carried out. The better output will lead to satisfied customers, lower maintenance costs, and accurate results. Unit testing determines the efficiency of individual modules. However, in this phase, the modules are tested for their interactions with each other and with the system.

5.          Operation and maintenance phase: Maintenance is the task performed by every user once the software has been delivered to the customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:

o   When the requirements are constant and not changed regularly.

o   A project is short

o   The situation is calm

o   Where the tools and technology used is consistent and is not changing

o   When resources are well prepared and are available to use.

Advantages of Waterfall model

o   This model is simple to implement also the number of resources that are required for it is minimal.

o   The requirements are simple and explicitly declared; they remain unchanged during the entire project development.

o   The start and end points for each phase is fixed, which makes it easy to cover progress.

o   The release date for the complete product, as well as its final cost, can be determined before development.

o   It gives easy to control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model

o   In this model, the risk factor is higher, so this model is not suitable for more significant and complex projects.

o   This model cannot accept the changes in requirements during development.

o   It becomes tough to go back to the phase. For example, if the application has now shifted to the coding phase, and there is a change in requirement, It becomes tough to go back and change it.

o   Since the testing done at a later stage, it does not allow identifying the challenges and risks in the earlier phase, so the risk reduction strategy is difficult to prepare.

INCREMENTAL PROCESS MODELS:

i)   The incremental model

ii)   The RAD model

(i)                         Incremental Model

The incremental build model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished.

In this process of software development where requirements divided into multiple standalone modules of the software development cycle. In this model, each module goes through the requirements, design, implementation and testing phases. Every subsequent release of the module adds function to the previous release. The process continues until the complete system achieved.

It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. Each iteration passes through the requirements, design, coding and testing phases.

The various phases of incremental model are as follows:

1.   Requirement analysis: In the first phase of the incremental model, the product analysis expertise identifies the requirements. And the system functional requirements are understood by the requirement analysis team. To develop the software under the incremental model, this phase performs a crucial role.

2.   Design & Development: In this phase of the Incremental model of SDLC, the design of the system functionality and the development

method are finished with success. When software develops new practicality, the incremental model uses style and development phase.

3.  Implementation: Implementation phase enables the coding phase of the development system. It involves the final coding that design in the designing and development phase and tests the functionality in the testing phase. After completion of this phase, the number of the product working is enhanced and upgraded up to the final system product

4.    Testing: In the incremental model, the testing phase checks the performance of each existing function as well as additional functionality. In the testing phase, the various methods are used to test the behavior of each task.

When we use the Incremental Model?

o   When the requirements are superior.

o   A project has a lengthy development schedule.

o   When Software team are not very well skilled or trained.

o   When the customer demands a quick release of the product.

o   You can develop prioritized requirements first.

Advantage of Incremental Model

o   Errors are easy to be recognized.

o   Easier to test and debug

o   More flexible.

o   Simple to manage risk because it handled during its iteration.

o   The Client gets important functionality early.

Disadvantage of Incremental Model

o   Need for good planning

o   Total Cost is high.

o   Well defined module interfaces are needed.

(ii)             RAD (Rapid Application Development) Model

Rapid Application Development (RAD) is an incremental software process model that emphasizes a short development cycle.

The RAD model is a “high-speed” adaption of the waterfall model, in which rapid development is achieved by using a component base construction approach.

If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a “fully functional system” within very short time periods (e.g., 60 to 90 days)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The RAD approach maps into the generic framework activities: Communication:

works to understand the business problem and the information characteristics that the software must accommodate.

 

Planning:

Is essential because multiple software teams works in parallel on different system functions.

 

Modeling:

encompasses three major phases- business modeling, data modelling and process modeling- and establishes design representation that serve existing software components and the application of automatic code generation.

Business modeling.:

The information flow among business functions is modeled in a way that answers the following questions: What information drives the business process? What information is generated? Who generates it? Where does the information go? Who processes it?

 

Data modeling.:

The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics (called attributes) of each object are identified and the relationships between these objects

defined.

 

Process modeling:

The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.

 

Construction:

 

Application generation:

RAD assumes the use of fourth generation techniques i.e, automated tools are used to facilitate construction of the software.

 

Testing :

Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised.

 

Deployment:

Establishes a basis for subsequent iterations.

When to use RAD Model?

o   When  the   system  should  need   to   create  the  project that modularizes in a short span time (2-3 months).

o   When the requirements are well-known.

o   When the technical risk is limited.

o   When there's a necessity to make a system, which modularized in 2-3 months of period.

o   It should be used only if the budget allows the use of automatic code generating tools.

Advantage of RAD Model

o   This model is flexible for change.

o   In this model, changes are adoptable.

o   Each phase in RAD brings highest priority functionality to the customer.

o   It reduced development time.

o   It increases the reusability of features.

Disadvantage of RAD Model

o   It required highly skilled designers.

o   All application is not compatible with RAD.

o   For smaller projects, we cannot use the RAD model.

o   On the high technical risk, it's not suitable.

o   Required user involvement.

Spiral model

The spiral model, first described by Barry Boehm in 1986, is a risk- driven software development process model which was introduced for dealing with the shortcomings in the traditional waterfall model. A spiral model looks like a spiral with many loops. The exact number of loops of the spiral is unknown and can vary from project to project. This model supports risk handling, and the project is delivered in

loops. Each loop of the spiral is called a Phase of the software development process.

The initial phase of the spiral model in the early stages of Waterfall Life Cycle that is needed to develop a software product. The exact number of phases needed to develop the product can be varied by the project manager depending upon the project risks. As the project manager dynamically determines the number of phases, so the project manager has an important role to develop a product using a spiral model.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The functions of these four quadrants are discussed below-

1.    Objectives determination and identify alternative solutions: Requirements are gathered from the customers and the objectives are identified, elaborated, and analyzed at the start of every phase. Then alternative solutions possible for the phase are proposed in this quadrant.

2.    Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the best possible solution. Then the risks associated with that solution are identified and the risks are resolved using the best possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution.

3.    Develop next version of the Product: During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the next version of the software is available.

4.    Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far developed version of the software. In the end, planning for the next phase is started.

When to use Spiral Model?

o   When deliverance is required to be frequent.

o   When the project is large

o   When requirements are unclear and complex

o   When changes may require at any time

o   Large and high budget projects

Advantages

o   High amount of risk analysis

o   Useful for large and mission-critical projects.

Disadvantages

o   Can be a costly model to use.

o   Risk analysis needed highly particular expertise

o   Doesn't work well for smaller projects.

V -Model

The V-model represents a development process that may be considered an extension of the waterfall model and is an example of the more general V-model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the

typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.

V- Model also referred to as the Verification and Validation Model. In this, each phase of SDLC must complete before the next phase starts. It follows a sequential design process same as the waterfall model. Testing of the device is planned in parallel with a corresponding stage of development.

 

Verification: It involves a static analysis method (review) done without executing code. It is the process of evaluation of the product development process to find whether specified requirements meet.

Validation: It involves dynamic analysis method (functional, non- functional), testing is done by executing code. Validation is the process to classify the software after the completion of the development process

to determine whether the software meets the customer expectations and requirements.

So V-Model contains Verification phases on one side of the Validation phases on the other side. Verification and Validation process is joined by coding phase in V-shape. Thus it is known as V-Model.

There are the various phases of Verification Phase of V-model:

1.    Business requirement analysis: This is the first step where product requirements understood from the customer's side. This phase contains detailed communication to understand customer's expectations and exact requirements.

2.    System Design: In this stage system engineers analyze and interpret the business of the proposed system by studying the user requirements document.

3.    Architecture Design: The baseline in selecting the architecture is that it should understand all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology detail, etc. The integration testing model is carried out in a particular phase.

4.    Module Design: In the module design phase, the system breaks down into small modules. The detailed design of the modules is specified, which is known as Low-Level Design

5.    Coding Phase: After designing, the coding phase is started. Based on the requirements, a suitable programming language is decided. There are some guidelines and standards for coding. Before checking in the repository, the final build is optimized for better performance, and the code goes through many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1.    Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is

the smallest entity which can independently exist, e.g., a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/ units.

2.    Integration Testing: Integration Test Plans are developed during the Architectural Design Phase. These tests verify that groups created and tested independently can coexist and communicate among themselves.

3.    System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and Integration Test Plans, System Tests Plans are composed by the client?s business team. System Test ensures that expectations from an application developer are met.

4.    Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It includes testing the software product in user atmosphere. Acceptance tests reveal the compatibility problems with the different systems, which is available within the user atmosphere. It conjointly discovers the non-functional problems like load and performance defects within the real user atmosphere.

When to use V-Model?

o   When the requirement is well defined and not ambiguous.

o   The V-shaped model should be used for small to medium-sized projects where requirements are clearly defined and fixed.

o   The V-shaped model should be chosen when sample technical resources are available with essential technical expertise.

Advantage (Pros) of V-Model:

1.    Easy to Understand.

2.    Testing Methods like planning, test designing happens well before coding.

3.    This saves a lot of time. Hence a higher chance of success over the waterfall model.

4.    Avoids the downward flow of the defects.

5.    Works  well for small plans where requirements are easily understood.

Disadvantage (Cons) of V-Model:

1.    Very rigid and least flexible.

2.    Not a good for a complex project.

3.    Software is developed during the implementation stage, so no early prototypes of the software are produced.

4.    If any changes happen in the midway, then the test documents along with the required documents, has to be updated.

 

 

 

Agile Development Models – Software Engineering

 

In earlier days, the Iterative Waterfall Model was very popular for completing a project. But nowadays, developers face various problems while using it to develop software. The main difficulties included handling customer change requests during project development and the high cost and time required to incorporate these changes. To overcome these drawbacks of the Waterfall Model, in the mid-1990s the Agile Software Development model was proposed.

 

What is Agile Model?

The Agile Model was primarily designed to help a project adapt quickly to change requests. So, the main aim of the Agile model is to facilitate quick project completion. To accomplish this task, agility is required. Agility is achieved by fitting the process to the project and removing activities that may not be essential for a specific project. Also, anything that is a waste of time and effort is avoided. The Agile Model refers to a group of development processes. These processes share some basic characteristics but do have certain subtle differences among themselves.

Agile SDLC Models/Methods

Given below are some Agile SDLC Models:

 

·        Crystal Agile methodology: The Crystal Agile Software Development Methodology places a strong emphasis on fostering effective communication and collaboration among team members, as well as taking into account the human elements that are crucial for a successful development process. This methodology is particularly beneficial for projects with a high degree of uncertainty, where requirements tend to change frequently.

·        Dynamic Systems Development Method (DSDM): DSDSM methodology is tailored for projects with moderate to high uncertainty where requirements are prone to change frequently. Its clear-cut roles and responsibilities focus on delivering working software in short time frames. Governance practices set it apart and make it an effective approach for teams and projects.

·        Feature-driven development (FDD): FDD approach is implemented by utilizing a series of techniques, like creating feature lists, conducting model evaluations, and implementing a design-by-feature method, to meet its goal. This methodology is particularly effective in ensuring that the end product is delivered on time and that it aligns with the requirements of the customer.

·        Scrum: Scrum methodology serves as a framework for tackling complex projects and ensuring their successful completion. It is led by a Scrum Master, who oversees the process, and a Product Owner, who establishes the priorities. The Development Team, accountable for delivering the software, is another key player.

·        Extreme Programming (XP): Extreme Programming uses specific practices like pair programming, continuous integration, and test-driven development to achieve these goals. Extreme programming is ideal for projects that have high levels of uncertainty and require frequent changes, as it allows for quick adaptation to new requirements and feedback.

·        Lean Development: Lean Development is rooted in the principles of lean manufacturing and aims to streamline the process by identifying and removing unnecessary steps and activities. This is achieved through practices such as continuous improvement, visual management, and value stream mapping, which helps in identifying areas of improvement and implementing changes accordingly. 

·        Unified Process: Unified Process is a methodology that can be tailored to the specific needs of any given project. It combines elements of both waterfall and Agile methodologies, allowing for an iterative and incremental approach to development. This means that the UP is characterized by a series of iterations, each of which results in a working product increment, allowing for continuous improvement and the delivery of value to the customer.

All Agile Software Development Methodology discussed above share the same core values and principles, but they may differ in their implementation and specific practices. Agile development requires a high degree of collaboration and communication among team members, as well as a willingness to adapt to changing requirements and feedback from customers.

In the Agile model, the requirements are decomposed into many small parts that can be incrementally developed. The Agile model adopts Iterative development. Each incremental part is developed over an iteration. Each iteration is intended to be small and easily manageable and can be completed within a couple of weeks only. At a time one iteration is planned, developed, and deployed to the customers. Long-term plans are not made. 

 

Steps in the Agile Model

The agile model is a combination of iterative and incremental process models. The steps involve in agile SDLC models are: 

·        Requirement gathering

·        Design the Requirements

·        Construction / Iteration

·        Testing / Quality Assurance

·        Deployment

·        Feedback

 

 

 

 

 

 

Steps in Agile Model

1.    Requirement Gathering:- In this step, the development team must gather the requirements, by interaction with the customer. development team should plan the time and effort needed to build the project. Based on this information you can evaluate technical and economical feasibility.

2.    Design the Requirements:- In this step, the development team will use user-flow-diagram or high-level UML diagrams to show the working of the new features and show how they will apply to the existing software. Wireframing and designing user interfaces are done in this phase.

3.    Construction / Iteration:- In this step, development team members start working on their project, which aims to deploy a working product.

4.    Testing / Quality Assurance:- Testing involves Unit Testing, Integration Testing, and System Testing. A brief introduction of these three tests is as follows:

·        Unit Testing:- Unit testing is the process of checking small pieces of code to ensure that the individual parts of a program work properly on their own. Unit testing is used to test individual blocks (units) of code.

·        Integration Testing:- Integration testing is used to identify and resolve any issues that may arise when different units of the software are combined.

·        System Testing:- Goal is to ensure that the software meets the requirements of the users and that it works correctly in all possible scenarios.

5.    Deployment:- In this step, the development team will deploy the working project to end users.

6.    Feedback:- This is the last step of the Agile Model. In this, the team receives feedback about the product and works on correcting bugs based on feedback provided by the customer.

The time required to complete an iteration is known as a Time Box. Time-box refers to the maximum amount of time needed to deliver an iteration to customers. So, the end date for an iteration does not change. However, the development team can decide to reduce the delivered functionality during a Time-box if necessary to deliver it on time. The Agile model’s central principle is delivering an increment to the customer after each Time-box. 

 

Principles of the Agile Model

·        To establish close contact with the customer during development and to gain a clear understanding of various requirements, each Agile project usually includes a customer representative on the team. At the end of each iteration stakeholders and the customer representative review, the progress made and re-evaluate the requirements.

·        The agile model relies on working software deployment rather than comprehensive documentation.

·        Frequent delivery of incremental versions of the software to the customer representative in intervals of a few weeks.

·        Requirement change requests from the customer are encouraged and efficiently incorporated.

 

Characteristics of the Agile Process

·        Agile processes must be adaptable to technical and environmental changes. That means if any technological changes occur, then the agile process must accommodate them.

·        The development of agile processes must be incremental. That means, in each development, the increment should contain some functionality that can be tested and verified by the customer.

·        The customer feedback must be used to create the next increment of the process.

·        The software increment must be delivered in a short span of time.

·        It must be iterative so that each increment can be evaluated regularly.

 

When To Use the Agile Model?

·        When frequent modifications need to be made, this method is implemented.

·        When a highly qualified and experienced team is available.

·        When a customer is ready to have a meeting with the team all the time.

·        when the project needs to be delivered quickly.

·        Projects with few regulatory requirements or not certain requirements.

·        projects utilizing a less-than-strict current methodology

·        Those undertakings where the product proprietor is easily reachable

·        Flexible project schedules and budgets.

 

Advantages of the Agile Model

·        Working through Pair programming produces well-written compact programs which have fewer errors as compared to programmers working alone.

·        It reduces the total development time of the whole project.

·        Agile development emphasizes face-to-face communication among team members, leading to better collaboration and understanding of project goals.

·        Customer representatives get the idea of updated software products after each iteration. So, it is easy for him to change any requirement if needed.

·        Agile development puts the customer at the center of the development process, ensuring that the end product meets their needs.

 

Disadvantages of the Agile Model

·        The lack of formal documents creates confusion and important decisions taken during different phases can be misinterpreted at any time by different team members.

·        It is not suitable for handling complex dependencies.

·        The agile model depends highly on customer interactions so if the customer is not clear, then the development team can be driven in the wrong direction.

 

 

 

The End