> For the complete documentation index, see [llms.txt](https://mwf.gitbook.io/maa-world-foundation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mwf.gitbook.io/maa-world-foundation/resource-center/computer-science/software-engineering/introduction.md).

# Introduction

## 1. What is Software?

**Program:** A step-by-step instruction to perform a specific task on a computer in a&#x20;programming language is called program.

**Software:** Is a program along with proper documentation (requirement analysis, design,&#x20;coding, testing) and user manuals which mainly includes installation guide and other manuals.

Software = Program + Documentation

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FytWiSXuxLHPn7vNfw0nm%2F14.png?alt=media&amp;token=030505c3-e44a-44f0-b0bb-74c3928163f7" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

## 2. Software Components

\--> A program is a subset of software, and it becomes software only if documentation and an operating procedure&#x20;manual is prepared.

* Program
* Documents\
  Software documentation consist of all the description, programs, graphics and instructions pertaining to  &#x20;design, coding, testing and preparation of software.
* Operating Procedure (User Manual & Operational Manual)\
  Provides information about what software is how to work with it how to install it on your system and  \
  how to control all the activities of the software.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FSjOB7wIo9CsTnT1NSgzp%2F1.png?alt=media&amp;token=49169298-e687-4da5-9d09-31e34ad9b6b6" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

## 3. Software Crisis

Problems with software?

* The major problem with current scenario in Software industry is, software usually  &#x20;overrun their development cost, they exceed their development duration limits, are  &#x20;usually of poor quality.
* As long as there were no machines, programming was no problem at all; when we had a  &#x20;few weak computers, programming became a mild problem, and now we have gigantic  &#x20;computers, programming has become an equally gigantic problem. — Edsger Dijkstra, The  \
  Humble Programmer (EWD340), Communications of the ACM

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FP98vVNPiSuCWPQKDNbD8%2F2.png?alt=media&amp;token=804ed354-3bad-48b7-b29f-6959719e427d" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

## 4. What is Software Engineering&#x20;

* In software industry we understand that there is an urgent need to use a proper strategy,  \
  process and development cycles so that we can produce, or we can design quality products  \
  that are within budget, with in time and must satisfy the requirement of their users.

&

* Software engineering is the systematic application of engineering principles and methods to  \
  the design, development, testing, and maintenance of software products. It involves the use  \
  of various tools, techniques, and methodologies to manage the software development  &#x20;process and ensure the quality, reliability, and maintainability of software products.

## 5. Characteristics of Software&#x20;

1. Software Developemnt vs Manufacturing:\
   \---> Software is crafted through a process of coding and development.\
   \---> Unlike physical products, it isn't produced in factories through a   &#x20;manufacturing process.
2. No Physical Wear and Tear:\
   \---> Software doesn't deteriorate over time like physical object.\
   \---> Its performance doesn't degrade due to physical use.
3. Custom-Built Nature:\
   \---> Most software is specially designed to meet specific needs.\
   \---> It's often not just a combination of pre-existing components but requires   &#x20;unique coding. and design
4. Intangibility of Software\
   \---> Software can't be touched or handled physically.\
   \---> It exists as code and functions within computers or digital devices.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FYyExM5ku2HdzMvNPKjZR%2F3.png?alt=media&amp;token=4f2be2b3-bb43-44ff-9911-34644f837937" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

## 6. Major Problems in Softwarge Development

1. Inadequate Requirements Gathering:   \
   • Ambiguous or incomplete requirements   \
   • Lack of communication between stakeholder
2. Poor Project Management:   \
   • Inadequate planning, monitoring, and control   \
   • Lack of risk assessment and mitigation   \
   • Multiplicity of software development life cycle   \
   • Selection of wrong technology or tool for development
3. &#x20;Insufficient Time and Budget:   \
   • Unrealistic deadlines and resource constraints   \
   • Inefficient resource allocation and prioritization
4. Lack of Skilled Personnel:   \
   • Inadequate expertise in the development team   \
   • High turnover rates and loss of experienced staff
5. Resistance to Change:   \
   • Difficulty in adapting to new technologies or processes   \
   • Reluctance to modify established practices or mindsets   \
   • Rapid technology advancement

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FFkR4AwbSlIvpAecyRFsC%2F4.png?alt=media&amp;token=74346ced-47a9-4876-9f23-818068b381f3" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

## 7. Similarity and Differences from conventional Engineering Process

* Nature of the Product:\
  \---> Similarity: Both processes aim to create high-quality, reliable products\
  \---> Difference: Conventional engineering focuses on physical systems, while  &#x20;software engineering deals with intangible software systems
* Design Flexibility and Iteration:\
  \---> Similarity: Both processes involve iterative design and prototyping\
  \---> Difference: Software engineering allows for greater flexibility and ease of  &#x20;modification due to the non-physical nature of software
* Quality Assurance and Testing:\
  \---> Similarity: Both processes emphasize the importance of testing and quality  \
  assurance to ensure product performance and reliability\
  \---> Difference: Conventional engineering often involves physical testing of  &#x20;prototypes, while software engineering relies on various types of software  &#x20;testing, such as unit, integration, and system testing
* Project Management and Collaboration:\
  \---> Similarity: Both processes require effective project management, team  \
  collaboration, and communication among stakeholders\
  \---> Difference: Software engineering projects may involve distributed teams and  &#x20;rely more heavily on digital communication and collaboration tools
* Maintenance and Evolution:\
  \---> Similarity: Both processes involve maintenance and support activities to  &#x20;ensure the ongoing performance and reliability of the product\
  \---> Difference: Software engineering typically demands more frequent updates,  &#x20;patches, and evolution due to the rapidly changing nature of technology and  &#x20;user requirements

For hardware Same production cost every time, for software production cost only for the first\
time and then only maintenance cost.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FMD3fUJtvTgBdNaC4S8TA%2F5.png?alt=media&amp;token=1a0450c4-4864-4971-8d32-1f90f116b282" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

## 8. Software Quality Attributes

\--> Correctness: The ability of the software to perform its intended tasks effectively and meet\
user requirements.

\--> Usability: The ease with which users can learn, operate, and navigate the software.

\--> Reliability: The software's consistency in producing accurate results and maintaining\
performance over time.

\--> Efficiency: The optimal use of system resources, such as memory and processing power, to&#x20;achieve desired outcomes.&#x20;

\--> Maintainability: The ease of updating, modifying, and fixing the software to accommodate&#x20;changing requirements or fix issues.

\--> Portability: The ability of the software to operate on different platforms or environments\
without significant modifications.

\--> Scalability: The software's capacity to handle increased workloads or user demands without&#x20;compromising performance.

\--> Security: The software's ability to protect against unauthorized access, data breaches, and&#x20;other potential threats

\--> Modularity: The degree to which the software's components are organized into separate,\
manageable units that can be independently developed or updated.

\--> Reusability: The potential for the software's components to be used in other applications or&#x20;contexts, reducing development time and costs

\--> Testability: The ease with which the software can be tested to ensure it meets its&#x20;requirements and performs as expected.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2F64uatl0PhjdJOxLqyP5h%2F6.png?alt=media&amp;token=3aabb916-2c72-4ea2-af4b-f18e6724d7c4" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

9. Software Process   \
   A software process (also known as software methodology) is a set of related   activities that lead to the production of the software. These activities may   involve the development of the software from the scratch, or, modifying an   existing system.   \
   \---> Feasibility study   \
   • Find abstract definition of the problem   \
   • Majorly checking the financial and technical feasibility   \
   • Analysis of cost and befit ratio   \
   • Checking availability of infrastructure and human resource   \
   • Examination of alternative solution strategies   \
   \---> Requirement analysis and specification   \
   • Try to understand the exact and complete requirement of the customer and document   \
   them properly.   \
   • Try to collect and analysis all data related to the project.   \
   • In last, a large document will be written in the natural language which will describe what   \
   the system will do without describing it how, called (SRS) Software Requirement   Specification.   \
   • Very critical phase because, a small error hear can result of sever problem in later stages   \
   \---> Designing   \
   • We transform the requirements into a structure that is suitable for implementation of the   \
   code in a specific programming language.   \
   • Overall architecture and the algorithmic strategy are chosen (Coupling and cohesion).   \
   • Lastly will prepare a document called SDD (software design description), which will   \
   describe how the system will perform functionality.   \
   \---> Coding   \
   • Goal of coding is to translate the design of the system into a code of   programming language.   \
   • It affects both testing and maintenance, so also critical feature.   \
   • We will be discussing some guidelines for how to write maintainable and   readable code.   \
   \---> Testing   \
   • Because of human errors there will be a bug or fault in the code and   if that bug/fault is executed it become a failure.   \
   • Software testing is a process of executing a program with the   intention of finding bugs or fault in the code.   \
   \---> Implementation   \
   • Software is installed on the user site and training of the user   and h/w requirement check is done.   \
   \---> Maintenance   \
   • Any change made in the software after its official release is called   \
   maintenance. It could be because of various reasons.   \
   • Adaptive   \
   • Corrective   \
   • Perfective

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FWr09wSChNJEiRdPSlSDX%2F7.png?alt=media&amp;token=18f75d69-1b34-4a0f-8800-c2579fa06944" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

## 10 Software Development Life Cycle (SDLC)

\--> Software development organization follows some process when developing a s/w product, in&#x20;mature organization this is well defined and managed.

\--> In SDLC we development s/w in a systematic and disciplined manner. SDLC will define entry&#x20;and exit for every stage. It makes assessment possible, time prediction, cost prediction,\
scheduling, to identify faults early possible.

\--> Selection of a correct development model play an important role in cost, quality, overall\
success of the project.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2F5IPcXU5ZiOosu9fvoWzI%2F8.png?alt=media&amp;token=3db2ac37-e00a-45e2-ae2c-511856c6cfda" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

### 10.1 Waterfall Model

Developed in the 1970s by Winston W. Royce. & Inspired by manufacturing and construction\
processes, where each step relies on the&#x20;completion of the previous one.

* It is a simplest SDLC in which phases are  &#x20;organised in a linear and sequential order
* It is called waterfall model as its  &#x20;diagrammatic representation resembles as  \
  like a waterfall, also known as classical life  &#x20;cycle model
* his type of model is basically used for the  &#x20;Small to medium-sized projects with clear,  \
  well-defined requirements. When the  &#x20;technology and tools to be used are well known and stable.
* Projects where minimal changes are  &#x20;expected during the development process,  &#x20;and predictability is prioritized over  &#x20;adaptability.

\---> Advantages:

1. Easy to understand and implement, with   &#x20;well-defined stages and clear milestones.
2. Each phase has well defined input and   &#x20;output, phases are processed and   &#x20;completed one at a time. Phases do not   &#x20;overlap.
3. Low cost and easy to schedule, as all staff   &#x20;do not work concurrently on the same   &#x20;project, so can work on different projects.

\---> Disadvantages:

1. Not suitable to accommodate any change   &#x20;or iteration once development has begun. It   &#x20;is always difficult to acquire of the   &#x20;requirement in the starting.
2. Working version is produced in the last   &#x20;level, so not good for large size   &#x20;sophisticated projects.
3. High amounts of risk and uncertainty.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FyZGf2YzeMrBkH2kHK70K%2F9.png?alt=media&amp;token=348e7b08-6197-482e-a1ed-60f19ae939a1" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

### 10.2 Prototype Model

* Most of the customer are not sure about the  &#x20;functionality they require from the software, as  \
  a result the final s/w is not according too exact  &#x20;demand.
* It is an iterative approach, which involves  &#x20;developing an early working model of the  &#x20;software based on the currently known  &#x20;requirements with limited functionalities, low  &#x20;reliability and untrusted performance.
* Refining it through user feedback, and repeating  &#x20;the process until a satisfactory solution is  \
  achieved.
* Then shown to the user, as per the feedback of  &#x20;the user prototype is rebuilt and modified and  \
  again, shown to the user, the process continues  &#x20;till the customer is not satisfied.
* After this process the final SRS document is  &#x20;developed.
* Developing the prototype help in building the  &#x20;actual design.
* Prototype model is of two types  \
  &#x20;— Evolutionary prototype  \
  &#x20;— Throwaway prototype

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2Fi5pAGKddIJB8AQ9lrqTi%2Fimage.png?alt=media&amp;token=132811d4-2dce-4f09-ae18-0fb879861095" alt=""><figcaption><p>Source: Google</p></figcaption></figure>

**Evolutionary prototype** —> Also known as incremental or iterative prototyping, develops a working\
prototype, gradually improving and refining it based on user feedback

Prototype evolves into the final product over time with feature additions and&#x20;modifications. Accommodates changing requirements during the development&#x20;process.

**Throwaway prototype** --> Throwaway prototyping, also known as rapid or exploratory prototyping, involves&#x20;creating a temporary, simplified version of the software to validate the feasibility of\
specific features, test ideas, or gain user feedback on the initial design. The&#x20;throwaway prototype is not intended to be used in the final product; instead, it is&#x20;discarded once it has served its purpose.

Once the developers have gathered the necessary information, they can then start&#x20;developing the actual software product from scratch, using the lessons learned from&#x20;the prototype. This approach is particularly useful for testing complex or risky&#x20;features, as it helps to minimize the potential impact of these features on the overall&#x20;project.

\---> Advantages

1. Customers get a chance to see the product early in the life cycle, and give   &#x20;important feedback.
2. There is a scope to accommodate new requirements.
3. Developer and more confident, and hence risk is reduced.

\---> Disadvantages

1. After seeing the early prototype use demand the actual system soon.
2. If not managed properly the iterative process can run for a long time.
3. If user is not satisfied, he may lose its interest in the project

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2F62wYBSOmcIYzgX7TJYj6%2F10.png?alt=media&amp;token=898ac8b5-90b1-462d-acc2-a972be836589" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

### 10. 3 Spiral Model

Barry boehm recognised the project risk factor into a life cycle model, the result&#x20;was the spiral model, which was presented in 1986.

* The radial dimensions of the model represent  &#x20;the cumulative costs.&#x20;
* Each path around the spiral is the indicative of  &#x20;the increased cost.
* The angular dimensions represent the progress  &#x20;made in the completing each cycle, each loop  \
  of the spiral from X-axis clockwise through 360  &#x20;represent one phase, which is divided into four  &#x20;sectors.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FDTrxO66xdBN3VE1z6cDK%2Fimage.png?alt=media&amp;token=69ad761f-2890-489b-ae3c-f38098cfcbab" alt=""><figcaption><p>Source: Google</p></figcaption></figure>

\---> Advantages

1. Provide early and frequent feedback of the customer, Additional Functionality   &#x20;can be added at a later date.
2. Management control of quality, correctness, cost, schedule is improved   &#x20;through review at the conclusion of each iteration.
3. Resolve all the possible risk involved in the product early in the life cycle.
4. Allows for incremental releases and testing.

\---> Disadvantages

1. Not suitable for small size project as the cost of risk analysis may exceed the   &#x20;actual cost of the project, High administrative overhead.
2. It is complex and time-consuming to use.
3. Risk analysis requires highly specific expertise.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FoaYEoXfPX4SYmdDKBzW0%2F11.png?alt=media&amp;token=08660aaa-f551-4f31-bdfc-279ee83a0332" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

### 10.4 Incremental Development Model

* Incremental development is based on the idea of developing an initial implementation,  &#x20;exposing this to user feedback, and evolving it through several versions until an  &#x20;acceptable system has been developed.
* In incremental model the whole requirement is divided into various builds. Multiple Development cycles take place here, making the life cycle a “multi-waterfall”  &#x20;cycle. Cycles are divided up into smaller, more easily managed modules. Each module  &#x20; passes through the requirements, design, implementation and testing phases.
* A working version of software is produced during the first module, so you have  &#x20;working software early on during the software life cycle.  Each subsequent release of the module adds function to the previous release.  &#x20;The process continues till the complete system is achieved.
* Generally, the early increments of the system should include the most important  &#x20;or most urgently required functionality. tries to combine the benefits of both prototyping and the waterfall model.                                                   &#x20;

\---> Advantages

1. Generates working software quickly and early during the software life   cycle.
2. This model is more flexible – less costly to change scope and   &#x20;requirements.
3. It is easier to test and debug during a smaller iteration.
4. In this model customer can respond to each built.
5. Easier to manage risk because risky pieces are identified and handled   &#x20;during it’d iteration.

\---> Disadvantages

1. Needs good planning and design.
2. Needs a clear and complete definition of the whole system before it   &#x20;can be broken down and built incrementally.
3. Total cost is higher than waterfall.

<figure><img src="https://1033994504-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCufZCbqF905Wb25LzPGj%2Fuploads%2FvfQh7yZ4D3N5YZwr00xs%2F12.png?alt=media&amp;token=97a62cf9-df6b-4dc0-8cf1-108cc6d93927" alt=""><figcaption><p>Source: Maa World Foundation</p></figcaption></figure>

<table><thead><tr><th width="143.60000610351562">Aspect</th><th width="346.5999755859375">Evolutionary Development Models</th><th width="348.8000183105469">Iterative Enhancement Models</th></tr></thead><tbody><tr><td>Focus</td><td>Adaptation and evolution of software in<br>response to changing requirements and user feedback.</td><td>Continuous improvement and refinement<br>of a software system in iterations.</td></tr><tr><td>Initial Release</td><td>May start with a basic prototype or a partially functional system to gather feedback.</td><td>Begins with a basic version of the software,<br>usually with minimal functionality.</td></tr><tr><td>Development<br>Approach</td><td>Develops through repeated cycles (e.g.,<br>prototypes or increments) with each cycle<br>refining and expanding the software.</td><td>Focuses on enhancing and refining an<br>existing system through multiple iterations.</td></tr><tr><td>Feedback<br>Integration</td><td>Heavily relies on user feedback to guide each evolutionary stage, often with significant changes between stages.</td><td>Uses feedback to make improvements in<br>each iteration, usually with smaller,<br>incremental changes.</td></tr><tr><td>Examples</td><td>Prototyping Model, Spiral Model, Agile<br>Development, RAD</td><td>Agile Development (as a specific approach<br>focusing on enhancement and refinement),<br>Iterative Development Model.</td></tr></tbody></table>

***

Next Page -->


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://mwf.gitbook.io/maa-world-foundation/resource-center/computer-science/software-engineering/introduction.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
