Software Myths: The types of software-related myths are

(i) Management Myths:

Myth 1: We have all the standards and procedures available for software development.
Fact:
• Software experts do not know all the requirements for the software development.
• And all existing processes are incomplete as new software development is based on new and different
problem.
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:
With the addition of more people and program planners to Software development can help meet project
deadlines (If lagging behind).
Fact:
• If software is late, adding more people will merely make the problem worse. This is because the people
already working on the project now need to spend time educating the newcomers, and are thus taken
away from their work. The newcomers are also far less productive than the existing software engineers,
and so the work put into training them to work on the software does not immediately meet with an
appropriate reduction in work.

(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.
• Unambiguous requirements (usually derived iteratively) are developed only through effective and
continuous communication between customer and developer.
Myth 2: Software requirements continually change, but change can be easily accommodated because software is
flexible
Fact:
• It is true that software requirements change, but the impact of change varies with the time at which it is
introduced. When requirements changes are requested early (before design or code has been started), the
cost impact is relatively small. However, as time passes, the cost impact grows rapidly—resources have
been committed, a design framework has been established, and change can cause upheaval that requires
additional resources and major design modification.
(iii)Practitioner’s Myths:
Myths 1: They believe that their work has been completed with the writing of the plan.
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, until it is “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, the right document brochures and booklets are also required to provide
guidance & software support.
Myth 4: Engineering software will enable us to build powerful and unnecessary document & always delay us.
Fact:
• Software engineering is not about creating documents. It is about creating a quality product. Better quality
leads to reduced rework. And reduced rework results in faster delivery times
A GENERIC VIEW OF PROCESS :-
A generic process framework for software engineering defines five framework activities—communication, planning,
modelling, construction, and deployment. In addition, a set of umbrella activities—project tracking and control, risk
management, quality assurance, configuration management, technical reviews, and others—are applied throughout
the process
SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY.
Software engineering as a layered technology" is a conceptual framework that views software development as a
process
composed of layers, each building upon the other. Similarly, in software engineering, the layers represent different
stages or aspects of the development process, from requirements gathering to deployment and maintenance.
1. Requirements Layer: This is the foundation where the needs and specifications for the software are
defined through communication with stakeholders.
2. Design Layer: Based on the requirements, this layer involves designing the architecture, user interface, and
other structural elements of the software.
3. Implementation Layer: Here, the actual code is written according to the design specifications. This involves
programming, debugging, and testing.
4. Testing Layer: Once the code is written, it undergoes rigorous testing to identify and fix any errors or bugs.
5. Deployment Layer: After successful testing, the software is deployed or released to the end-users.
6. Maintenance Layer: Even after deployment, software requires continuous maintenance to address issues,
implement updates, and add new features.
Each layer is interconnected, and changes in one layer can affect others. This layered approach helps in managing
the complexity of software development, promoting modularity, scalability, and maintainability. Additionally, it
provides a structured framework for collaboration among different teams involved in the development process.

PROCESS FRAMEWORK :
A process framework is a basic structure where all the activities are described in detail to achieve the task. This
is further divided into five generic software engineering framework activities for a better approach and to
ensure that no detail is missed.
1. Communication
Communication is the most basic yet important step in the software engineering framework. Here, the software
engineer and the user or the client discuss the functioning of the application. It is important to note down all
the details. Even if a small detail is missed or ignored, it may cause a problem in the later steps.
2. Planning
Planning is a more technical part of the software engineering frameworks. It requires the engineer to formulate
a work plan that shall be successful and foolproof. It also contains a list of all the requirements and risks.
Further, it has a detailed timetable on how work shall be scheduled ahead.
3. Modeling
A model is designed with the help of analyzing the data collected and the rough plan for the framework
software engineering. This helps get a rough idea of how the application would function. It also helps
significantly identify any loopholes or problems the application may have.
4. Construction
Construction is the step where the application is generated with the help of a code. The application is also
tested, and all the identified bugs or glitches are fixed. This is also known as software design mapping.
5. Deployment
This is the step of collecting feedback from the client. Irrespective of whether the application is complete or
incomplete, the client is shown it's working. The client or the user shares their updates. Based on this, the
software engineer modifies or edits the system to suit the client.

PROCESS PATTERNS :-
Patterns can be defined at any level of abstraction. In some cases, a pattern might be used to describe a problem
(and solution) associated with a complete process model (e.g., prototyping). In other situations, patterns can be used
to describe a problem (and solution) associated with a framework activity (e.g., planning) or an action within a
framework activity (e.g., project estimating). Ambler [Amb98] has proposed a template for describing a process
pattern:
Pattern Name : The pattern is given a meaningful name describing it within the context of the software process (e.g.,
Technical Reviews).
Forces : The environment in which the pattern is encountered and the issues that make the problem visible and may
affect its solution.
Type :The pattern type is specified. Ambler [Amb98] suggests three types:
1. Stage pattern—defines a problem associated with a framework activity for the process. Since a framework activity
encompasses multiple actions and work tasks, a stage pattern incorporates multiple task patterns (see the following)
that are relevant to the stage (framework activity). An example of a stage pattern might be Establishing
Communication. This pattern would incorporate the task pattern Requirements Gathering and others.
2. Task pattern—defines a problem associated with a software engineering action or work task and relevant to
successful software engineering practice (e.g., Requirements Gathering is a task pattern). 3. Phase pattern—define
the sequence of framework activities that occurs within the process, even when the overall flow of activities is
iterative in nature. An example of a phase pattern might be Spiral Model or Prototyping.3
Initial context : Describes the conditions under which the pattern applies. Prior to the initiation of the pattern:
(1) What organizational or team-related activities have already occurred?
(2) What is the entry state for the process?
(3) What software engineering information or project information already exists?

PROCESS ASSESSMENT :
• The existence of a software process is no guarantee that software will be delivered on time, that it will
meet the customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term
quality characteristics.
• In addition, the process itself can be assessed to ensure that it meets a set of basic process criteria that
have been shown to be essential for a successful software engineering.
• A number of different approaches to software process assessment and improvement have been proposed
over the past few decades:
• Standard CMMI Assessment Method for Process Improvement
• (SCAMPI)—provides a five-step process assessment model that incorporates five phases: initiating,
diagnosing, establishing, acting, and learning.

PROCESS MODES
1. WATERFALL MODEL :-
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of
the project. In "The Waterfall" approach, the whole process of software development is divided into
separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next
phase sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.

• Requirement Gathering and analysis − All possible requirements of the system to be developed are captured
in this phase and documented in a requirement specification document.
• System Design − The requirement specifications from first phase are studied in this phase and the system
design is prepared. This system design helps in specifying hardware and system requirements and helps in
defining the overall system architecture.
• Implementation − With inputs from the system design, the system is first developed in small programs called
units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is
referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are integrated into a system
after testing of each unit. Post integration the entire system is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the product is deployed in
the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To fix those issues, patches
are released. Also to enhance the product some better versions are released. Maintenance is done to deliver
these changes in the customer environment.
When to use waterfall model :
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 :
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

Disadvantages :
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and
uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or
business bottleneck or challenges early.

2. INCREMENTAL PROCESS MODEL :-

Incremental Model is a 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.
 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. 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.
4. 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
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.

3. EVOLUTIONARY PROCESS MODEL :-

The evolutionary model is based on the concept of making an initial product and then evolving the
software product over time with iterative and incremental approaches with proper feedback. In this type
of model, the product will go through several iterations and come up when the final product is built
through multiple iterations. The development is carried out simultaneously with the feedback during the
development. This model has a number of advantages such as customer involvement, taking feedback
from the customer during development, and building the exact product that the user wants. Because of
the multiple iterations, the chances of errors get reduced and the reliability and efficiency will increase.
Types of Evolutionary Process Models
1. Iterative Model
2. Incremental Model
3. Spiral Model
The spiral model combines the idea of iterative development with the systematic, controlled aspects of the
waterfall model. This Spiral model is a combination of iterative development process model and sequential
linear development model i.e. the waterfall model with a very high emphasis on risk analysis. It allows
incremental releases of the product or incremental refinement through each iteration around the spiral.
Spiral Model - Design
The spiral model has four phases. A software project repeatedly passes through these phases in iterations
called Spirals.
(i) Identification
 This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals
as the product matures, identification of system requirements, subsystem requirements and unit
requirements are all done in this phase.
This phase also includes understanding the system requirements by continuous communication between
the customer and the system analyst. At the end of the spiral, the product is deployed in the identified
market.
(ii) Design
The Design phase starts with the conceptual design in the baseline spiral and involves architectural design,
logical design of modules, physical product design and the final design in the subsequent spirals.
(iii) Construct or Build
The Construct phase refers to production of the actual software product at every spiral. In the baseline
spiral, when the product is just thought of and the design is being developed a POC (Proof of Concept) is
developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working model of
the software called build is produced with a version number. These builds are sent to the customer for
feedback.
(iv) Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management
risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the
customer evaluates the software and provides feedback.
The following illustration is a representation of the Spiral Model, listing the activities in each phase.

Based on the customer evaluation, the software development process enters the next iteration and
subsequently follows the linear approach to implement the feedback suggested by the customer. The process of
iterations along the spiral continues throughout the life of the software.
The advantages of the Spiral SDLC Model are as follows −
• Changing requirements can be accommodated.
• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the risky parts can be developed earlier which helps
in better risk management.
The disadvantages of the Spiral SDLC Model are as follows −
• Management is more complex.
• End of the project may not be known early.
• Not suitable for small or low risk projects and could be expensive for small projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive documentation.

4. THE UNIFIED MODEL :-

5. AGILE MODEL :-
Agile SDLC model is a combination of iterative and incremental process models with focus on process
adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break
the product into small incremental builds. These builds are provided in iterations. Each iteration typically
lasts from about one to three weeks. Every iteration involves cross functional teams working
simultaneously on various areas like −
• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and important stakeholders.
Agile model believes that every project needs to be handled differently and the existing methods need to be
tailored to best suit the project requirements. In Agile, the tasks are divided to time boxes (small time frames)
to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each build is
incremental in terms of features; the final build holds all the features required by the customer.

The Agile thought process had started early in the software development and started becoming popular
with time due to its flexibility and adaptability.
The advantages of the Agile Model are as follows −
• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing re quirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.
The disadvantages of the Agile Model are as follows −
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must without which it will not work.
• Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet
the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong
direction.
• There is a very high individual dependency, since there is minimum documentation generated.
• Transfer of technology to new team members may be quite challenging due to lack of documentation.

6. RAD MODEL :-
The RAD (Rapid Application Development) model is based on prototyping and iterative development
with no specific planning involved. The process of writing the software itself involves the planning
required for developing the product.

Rapid Application Development focuses on gathering customer requirements through workshops or

focus groups, early testing of the prototypes by the customer using iterative concept, reuse of the
existing prototypes (components), continuous integration and rapid delivery.

Rapid application development is a software development methodology that uses minimal planning in
favor of rapid prototyping.
In the RAD model, the functional modules are developed in parallel as prototypes and are integrated to
make the complete product for faster product delivery. Since there is no detailed preplanning, it makes
it easier to incorporate the changes within the development process.
 RAD Model Design
RAD model distributes the analysis, design, build and test phases into a series of short, iterative
development cycles.
Following are the various phases of the RAD Model –
Business Modelling
The business model for the product under development is designed in terms of flow of information
and the distribution of information between various business channels. A complete business analysis is
performed to find the vital information for business, how it can be obtained, how and when is the
information processed and what are the factors driving successful flow of information
Data Modelling
The information gathered in the Business Modelling phase is reviewed and analyzed to form sets of
data objects vital for the business. The attributes of all data sets is identified and defined. The relation
between these data objects are established and defined in detail in relevance to the business model.
Process Modelling
The data object sets defined in the Data Modelling phase are converted to establish the business
information flow needed to achieve specific business objectives as per the business model. The
process model for any changes or enhancements to the data object sets is defined in this phase.
Process descriptions for adding, deleting, retrieving or modifying a data object are given.
Application Generation
The actual system is built and coding is done by using automation tools to convert process and data
models into actual prototypes.
Testing and Turnover
The overall testing time is reduced in the RAD model as the prototypes are independently tested
during every iteration. However, the data flow and the interfaces between all the components need to
be thoroughly tested with complete test coverage. Since most of the programming components have
already been tested, it reduces the risk of any major issues.

The advantages of the RAD Model are as follows −

• Changing requirements can be accommodated.

• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
 • Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.

The disadvantages of the RAD Model are as follows −

• Dependency on technically strong team members for identifying business requirements.

• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on Modelling skills.
• Inapplicable to cheaper projects as cost of Modelling and automated code generation is very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.