Syllabus

Module I: INTRODUCTION TO SOFTWARE ENGINEERING

Software Engineering definition, Software Engineering characteristics, applications, life cycle models
– Waterfall (classical and iterative), Prototyping & RAD models, Scope of each model and their
comparison.

Module II: REQUIREMENTS MODELING AND DESIGN

Requirements Engineering-crucial steps, types of requirements, Requirement’s documentation –

nature of SRS, characteristics of a good SRS, use case diagrams with guidelines, DFD (level 0, 1 and
2), SRS Structure, Introduction to software design, Modularity and Function-oriented design.

Module III: SOFTWARE PROJECT PLANNING

Cost estimation– Static, Single variable and Multivariable Models (SEL, Watson Felix model),
COCOMO: basic and intermediate model, Cost-benefit evaluation techniques (Net Profit, Payback
period, ROI, NPV and IRR computation), numerical problems on cost estimation and cost-benefit
evaluation methods.

Module IV: SOFTWARE METRICS

Understanding metrics: definition, process metrics, product and project metrics. Size metrics – LOC
and Function Count, Albrecht FPA. Product metrics – Metrics for source code; metrics for testing
(Halstead metrics) and its numerical, Metrics for software maintenance.

Module V: SOFTWARE TESTING

Understanding software testing, its need and objectives; Error, mistake, bug, fault and failure, testing
strategies, test case and test suite, Verification and Validation, Black Box and White box testing –
concept and comparison, Boundary Value Analysis and Equivalence Partitioning with numerical
problems, Basis Path testing (flow graph) and Cyclomatic complexity with numerical problems.

Module VI: SOFTWARE QUALITY AND RISK MANAGEMENT

Importance of software quality, McCall quality factors, ISO and CMM Model, Risk Management –
importance, types, process and phases, qualitative and quantitative risk analysis,

Module VII: PROJECT SELECTION AND SCOPE MANAGEMENT

Project Selection and its methods, analysis of each method, Role and responsibilities of Project
manager, Issues in project staffing, Project Scope, Project life cycle phases and its deliverables,
Project life cycle vs. product life cycle.

INTRODUCTION TO SOFTWARE ENGINEERING

The term software engineering is composed 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 a 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. So, we can define software engineering as an engineering branch associated
with the development of software product using well-defined scientific principles, methods and
procedures. The outcome of software engineering is an efficient and reliable software product.

IEEE defines software engineering as:

The application of a systematic, disciplined, quantifiable approach to the development, operation and
maintenance of software.

Software engineering is an engineering branch associated with development of software product using
well-defined scientific principles, methods and procedures.
Software engineering is important as it enables to build complex system in a timely manner and with
high quality.

On the other hand, Project management involves:

• Planning
• Monitoring
• Control

We can alternatively view it as a systematic collection of past experience. The experience is arranged
in the form of methodologies and guidelines. A small program can be written without using software
engineering principles. But if one wants to develop a large software product, then software
engineering principles are absolutely necessary to achieve a good quality software cost effectively.

Without using software engineering principles, it would be difficult to develop large programs. In
industry it is usually needed to develop large programs to accommodate multiple functions. A
problem with developing such large commercial programs is that the complexity and difficulty levels
of the programs increase exponentially with their sizes. Software engineering helps to reduce this
programming complexity. Software engineering principles use two important techniques to reduce
problem complexity: abstraction and decomposition. The principle of abstraction implies that a
problem can be simplified by omitting irrelevant details. In other words, the main purpose of
abstraction is to consider only those aspects of the problem that are relevant for certain purpose and
suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved,
then the omitted details can be taken into consideration to solve the next lower-level abstraction, and
so on.

Abstraction is a powerful way of reducing the complexity of the problem. The other approach to
tackle problem complexity is decomposition. In this technique, a complex problem is divided into
several smaller problems and then the smaller problems are solved one by one. However, in this
technique any random decomposition of a problem into smaller parts will not help. The problem has
to be decomposed such that each component of the decomposed problem can be solved independently
and then the solution of the different components can be combined to get the full solution. A good
decomposition of a problem should minimize interactions among various components. If the different
subcomponents are interrelated, then the different components cannot be solved separately and the
desired reduction in complexity will not be realized.

7 principles of Software Engineering

Seven principles have been determined which form a reasonably independent and complete set.
These are:

1. Manage using a phased life-cycle plan.

2. Perform continuous validation.
3. Maintain disciplined product control.
4. Use modern programming practices.
5. Maintain clear accountability for results.
6. Use better and fewer people.
7. Maintain a commitment to improve the process.

NEED OF SOFTWARE ENGINEERING

The need of software engineering arises because of higher rate of change in user requirements
and environment on which the software is working.
 Large software - It is easier to build a wall than to a house or building, likewise, as the
size of software become large engineering has to step to give it a scientific process.
 Scalability- If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing one.
 Cost- As hardware industry has shown its skills and huge manufacturing has lower
down the price of computer and electronic hardware. But the cost of software
remains high if proper process is not adapted.
 Dynamic Nature- The always growing and adapting nature of software hugely
depends upon the environment in which the user works. If the nature of software is
always changing, new enhancements need to be done in the existing one. This is
where software engineering plays a good role.
 Quality Management- Better process of software development provides better and
quality software product.

The software problem: Cost, Schedule and Quality, Scale and Change:

In the industrial-strength software domain, there are three basic forces at play—cost, schedule, and
quality. The software should be produced at reasonable cost, in a reasonable time, and should be of
good quality. These three parameters often drive and define a software project.

Cost:
Industrial-strength software is very expensive primarily due to the fact that software development is
extremely labor-intensive. To get an idea of the costs involved, let us consider the current state of
practice in the industry. Lines of code (LOC) or thousands of lines of code (KLOC) delivered is by far
the most commonly used measure of software size in the industry. As the main cost of producing
software is the manpower employed, the cost of developing software is generally measured in terms
of person-months of effort spent in development. And productivity is frequently measured in the
industry in terms of LOC (or KLOC) per person-month.

Schedule:

Schedule is another important factor in many projects. Business trends are dictating that the time to
market of a product should be reduced; that is, the cycle time from concept to delivery should be
small. For software this means that it needs to be developed faster, and within the specified time.
Unfortunately, the history of software is full of cases where projects have been substantially late.

Clearly, therefore, reducing the cost and the cycle time for software development are central goals
of software engineering. Productivity in terms of output (KLOC) per person-month can adequately
capture both cost and schedule concerns. If productivity is higher, it should be clear that the cost in
terms of person-months will be lower (the same work can now be done with fewer person-months).
Similarly, if productivity is higher, the potential of developing the software in less time improves—a
team of 8 higher productivity will finish a job in less time than a same-size team with lower
productivity. (The actual time the project will take, of course, depends also on the number of people
allocated to the project.) Hence, pursuit of higher productivity is a basic driving force behind
software engineering and a major reason for using the different tools and techniques.

Quality:

Besides cost and schedule, the other major factor driving software engineering is quality. Today,
quality is one of the main mantras, and business strategies are designed around it. Unfortunately, a
large number of instances have occurred regarding the unreliability of software—the software often
does not do what it is supposed to do or does something it is not supposed to do.

Clearly, developing high-quality software is another fundamental goal of software engineering.

However, while cost is generally well understood, the concept of quality in the context of software
needs further elaboration. The international standard on software product quality [55] suggests that
software quality comprises six main attributes:

 Functionality: The capability to provide functions which meet stated and implied needs
when the software is used.
 Reliability: The capability to provide failure-free service.
 Usability: The capability to be understood, learned, and used.
 Efficiency: The capability to provide appropriate performance relative to the number of
resources used.
 Maintainability: The capability to be modified for purposes of making corrections,
improvements, or adaptation.
 Portability: The capability to be adapted for different specified environments without
applying actions or means other than those provided for this purpose in the product.
Scale and Change:

Scale:

SE must deal with problem of scale

 methods for solving small problems do not scale up for large problems
 industrial strength SW problems tend to be large
SE methods must be scalable. Two clear dimensions in this
 engineering methods
 project management
For small, both can be informal or ad-hoc, for large both have to be formalized.

 An illustration of issue of scale is counting the number of people in a room vs taking a census
 Both are counting problems
 Methods used in first not useful for census
 For large scale counting problem, must use different techniques and models.
 Management will become critical.

Change:
 Only constant in business is change!
 Software must change to support the changing business needs
 SE practices must accommodate change
 Methods that disallow change, even if high Q and P, are of little value

Importance of software engineering

1. Reducing complexity
 Big software is always complex and difficult to develop. Software engineering has a great
solution to decrease the complexity of any project.

2. To minimize software cost

Software requires a lot of hard work and software engineers are highly paid professionals.
But in Software engineering, programmers plan everything and reduce all the things that are
not required. In turn, cost for software productions become less.

3. To decrease time
If you are making big software then you may need to run many codes to get the ultimate
running code. This is a very time consuming so if you are making your software according to
software engineering approach then it will reduce a lot of time.

4. Handling big projects

Big projects are not made in few days and they require lots of patience, so to handle big
projects without any problem, organization has to go for software engineering approach.

5. Reliable software
Software should be reliable, means if you have delivered the software then it should work
for at least it’s given time.

6. Effeteness
Effectiveness comes if anything has made according to the standards. So, software become
more effective in performance with the help of software engineering.

7. Productivity
If programs fail to meet its standard at any stage, then programmers always improve the
code of software to make it sure that software maintains its standards.

Software Characteristics

Different individuals judge software on different basis. This is because they are involved with the
software in different ways.

For example:
users want the software to perform according to their requirements. Similarly, developers involved
in:

 Designing
 Coding
 Maintenance
Of the software evaluate the software by looking at its internal chrematistics, before delivering it to
the user.
Functionality:

Sub-characteristics are:
1. Suitability
2. Accuracy
3. Interoperability
4. Security
5. Functional Compliance
Refers to the degree of performance of the software against its intended purpose.

This is the most crucial point for customer. With incorrect results, unsuitable models and software
which cannot interoperate with their environments, our software is useless. A software which has
not the functionality needed, is never accepted by customers.

Reliability:

Sub- characteristics are:

1. Maturity
2. Fault Tolerance
3. Recoverability
4. Reliability compliance
Refers to the ability of the software to provide desired functionality under the given conditions.

Reliability is the second most important point in software development. As soon as the software has
a certain functionality, this functionality needs to be available. This is needed to generate a constant
revenue, to provide services to end user for their satisfaction or to monitor safety critical operations.
A weak reliability will lead to loss of revenue, loss of customers and in critical area to injuries and
deaths.

Usability:

The sub-characteristics are:

1. Understandability
2. Learnability
3. Operability
 4. Attractiveness
5. Usability Compliance
Refers to the extent to which the software can be used with ease.

Our customers and clients want software which is self-explanatory and easy to use. We should keep
in mind to keep our customers happy with nice usable GUIs, too.

Efficiency:

Sub-characteristics are:

1. Time Behavior
2. Resource utilization
3. Efficiency Compliance
Refers to ability of the software to use system resources in the most effective and efficient manner.

Our customers have fabs where they try to increase the throughput on daily basis. Our software
needs to be performant, too. We should pay some attention to performance and resource usage.
But this must not be on cost of maintainability. Ask your senior about the right decisions if unsure.

Maintainability:

Sub-characteristics are:
1. Analyzability
2. Changeability
3. Stability
4. Testability
5. Maintainability Compliance
Refers to the ease with which the modifications can be made in a software system to extend its
functionality, improve its performance, or correct errors.

This is the most important point for ourselves! Code which is not maintainable leads to code which
cannot be changed, cannot be kept stable and secures and may lead into a product which cannot be
sold. On the other side, we can make our life much easier with easy to read and to write code.

Portability:

Sub-characteristics are:

1. Adaptability
2. Install ability
3. Co-Existence
4. Replaceability
5. Portability Compliance
This point is of minor importance, but should kept in mind by architects. The system itself and
technologies used within our products are meant to change in future. We should build system in a
way, that sub-systems may be changed without too much work.
7 Software Applications

• System software:
System Software is necessary to manage the computer resources and support the
execution of application programs. Software like operating systems, compilers, editors and
drivers etc., come under this category. A computer cannot function without the presence
of these. Operating systems are needed to link the machine dependent needs of a
program with the capabilities of the machine on which it runs. Compilers translate
programs from high-level language to machine language. 
• Application software
It solves a specific Business need. It is needed to convert the business function in real time.
Example -point of sale, Transaction processing, real time manufacturing control.
• Embedded software
There are software control systems that control and manage hardware devices. Example-
software in mobile phone, software in Anti Lock Braking in car, software in microwave oven
to control the cooking process.
• Engineering/Scientific software
Applications like based on astronomy, automotive stress analysis, molecular Biology,
volcanology, space Shuttle orbital dynamic, automated manufacturing.
• Product software
It is designed to provide a specific capability for used by many different customers. It can
focus on unlimited or esoteric Marketplace like inventory control products. Or address mass
market place like: Spreadsheets, computer graphics, multimedia, entertainment, database
management, personal, business financial applications.
• Web Applications
It is also called " web apps ", are evolving into sophisticated computing environment that not
only provide stand alone features, computing functions, and content to the end user but
also are integrated with corporate database and business applications.
• Artificial intelligence software
This includes- robotic, expert system, pattern recognition, image and voice, artificial neural
network, game playing, theorem proving ... It solves Complex problems.

Difference between Hardware and Software

• Software is easier to change than hardware. The cost of change is much higher for hardware
than for software.
• Software products evolve through multiple releases by adding new features and re-writing
existing logic to support the new features. Hardware products consist of physical
components that cannot be “refactored” after manufacturing, and cannot add new
capabilities that require hardware changes.
• Designs for new hardware is often based upon earlier-generation products, but commonly
rely on next-generation components not yet present.
• Hardware designs are constrained by the need to incorporate standard parts.
 • Specialized hardware components can have much longer lead times for acquisition than is
true for software.
• Hardware design is driven by architectural decisions. More of the architectural work must be
done up front compared to software products. o The cost of development for software
products is relatively flat over time. However, the cost of hardware development rises
rapidly towards the end of the development cycle. Testing software commonly requires
developing thousands of test cases. Hardware testing involves far fewer tests.
• Software testing is done by specialized Quality Assurance (QA) engineers, while hardware
testing is commonly done by the engineers who are creating the product.
• Hardware must be designed and tested to work over a range of time and environmental
conditions, which is not the case for software.
• Hardware development incorporates four parallel, synchronized projects:

SOFTWARE DEVELOPMENT LIFE CYCLE

What is SDLC?
SDLC is a process followed for a software project, within a software organization. It consists of a
detailed plan describing how to develop, maintain, replace and alter or enhance specific software.
The life cycle defines a methodology for improving the quality of software and the overall
development process. The following figure is a graphical representation of the various stages of a
typical SDLC.

Planning

Development Defining

SDLC
Designing
Testing

Building

Stage 1: Planning and Requirement Analysis Requirement analysis

Is the most important and fundamental stage in SDLC. It is performed by the senior members of the
team with inputs from the customer, the sales department, market surveys and domain experts in
the industry. This information is then used to plan the basic project approach and to conduct
product feasibility study in the economical, operational and technical areas.
Planning for the quality assurance requirements and identification of the risks associated with the
project is also done in the planning stage. The outcome of the technical feasibility study is to define
the various technical approaches that can be followed to implement the project successfully with
minimum risks.

Stage 2: Defining Requirements Once the requirement analysis

Is done the next step is to clearly define and document the product requirements and get them
approved from the customer or the market analysts. This is done through an SRS (Software
Requirement Specification) document which consists of all the product requirements to be designed
and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the product to
be developed. Based on the requirements specified in SRS, usually more than one design approach
for the product architecture is proposed and documented in a DDS - Design Document Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as risk
assessment, product robustness, design modularity, budget and time constraints, the best design
approach is selected for the product. A design approach clearly defines all the architectural modules
of the product along with its communication and data flow representation with the external and
third-party modules (if any). The internal design of all the modules of the proposed architecture
should be clearly defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code
is generated as per DDS during this stage. If the design is performed in a detailed and organized
manner, code generation can be accomplished without much hassle. Developers must follow the
coding guidelines defined by their organization and programming tools like compilers, interpreters,
debuggers, etc. are used to generate the code. Different high level programming languages such as
C, C++, Pascal, Java and PHP are used for coding. The programming language is chosen with respect
to the type of software being developed

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are
mostly involved in all the stages of SDLC. However, this stage refers to the testing only stage of the
product where product defects are reported, tracked, fixed and retested, until the product reaches
the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometimes product deployment happens in stages as per the business strategy of that
organization. The product may first be released in a limited segment and tested in the real business
environment (UAT- User acceptance testing). Then based on the feedback, the product may be
released as it is or with suggested enhancements in the targeting market segment. After the product
is released in the market, its maintenance is done for the existing customer base.

THE NEED FOR A SOFTWARE LIFE CYCLE MODEL

The development team must identify a suitable life cycle model for the particular project and then
adhere to it. Without using of a particular life cycle model, the development of a software product
would not be in a systematic and disciplined manner. When a software product is being developed
by a team there must be a clear understanding among team members about when and what to do.
Otherwise, it would lead to chaos and project failure. This problem can be illustrated by using an
example. Suppose a software development problem is divided into several parts and the parts are
assigned to the team members. From then on, suppose the team members are allowed the freedom
to develop the parts assigned to them in whatever way they like. It is possible that one member
might start writing the code for his part, another might decide to prepare the test documents first,
and some other engineer might begin with the design phase of the parts assigned to him. This would
be one of the perfect recipes for project failure. A software life cycle model defines entry and exit
criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So,
without software life cycle model the entry and exit criteria for a phase cannot be recognized.
Without software life cycle models, it becomes difficult for software project managers to monitor
the progress of the project.

SDLC Models
There are various software development life cycle models defined and designed which are followed
during the software development process. These models are also referred as Software Development
Process Models". Each process model follows a Series of steps unique to its type to ensure success in
the process of software development.
Following are the most important and popular SDLC models followed in the industry:
 Classical Waterfall Model
 Iterative Waterfall Model
 Prototyping Model
 Spiral Model

Waterfall SDLC Model (Classical)

Waterfall model is an example of a Sequential model. In this model, the software development
activity is divided into different phases and each phase consists of series of tasks and has different
objectives.

It is divided into phases and output of one phase becomes the input of the next phase. It is
mandatory for a phase to be completed before the next phase starts. In short, there is no
overlapping in Waterfall model.
In waterfall, development of one phase starts only when the previous phase is complete. Because of
this nature, each phase of waterfall model is quite precise well defined. Since the phases fall from
higher level to lower level, like a waterfall, it’s named as waterfall model.

Pros and Cons of waterfall model:

Advantages of using Waterfall model:

 Simple and easy to understand and use.

 For smaller projects, waterfall model works well and yield the appropriate results.
 Since the phases are rigid and precise, one phase is done one at a time, it is easy to maintain.
 The entry and exit criteria are well defined, so it easy and systematic to proceed with quality.
 Results are well documented.

Disadvantages of using Waterfall model:

 Cannot adopt the changes in requirements

 It becomes very difficult to move back to the phase. For example, if the application has now
moved to the testing stage and there is a change in requirement, it becomes difficult to go back
and change it.
 Delivery of the final product is late as there is no prototype which is demonstrated
intermediately.
 For bigger and complex projects, this model is not good as a risk factor is higher.
 Not suitable for the projects where requirements are changed frequently.
 Does not work for long and ongoing projects.
 Since the testing is done at a later stage, it does not allow identifying the challenges and risks in
the earlier phase so the risk mitigation strategy is difficult to prepare.

Conclusion: In the waterfall model, it is very important to take the sign off of the deliverables of
each phase. As of today, most of the projects are moving with Agile and Prototype models, Waterfall
model still holds good for smaller projects. If requirements are straightforward and testable,
Waterfall model will yield the best results.
When to use classic waterfall model:

• The requirements are precisely documented

• Product definition is stable
• The technologies stack is predefined which makes it not dynamic
• No ambiguous requirements
• The project is short

Iterative Waterfall SDLC Model

An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which can
then be reviewed in order to identify further requirements. This process is then repeated, producing
a new version of the software for each cycle of the model.

In the diagram above when we work iteratively, we create rough product or product piece in one
iteration, then review it and improve it in next iteration and so on until it’s finished. As shown in the
image above, in the first iteration the whole painting is sketched roughly, then in the second
iteration colors are filled and in the third iteration finishing is done. Hence, in iterative model the
whole product is developed step by step.
Advantages of Iterative model:

 In iterative model we can only create a high-level design of the application before we actually
begin to build the product and define the design solution for the entire product. Later on, we can
design and built a skeleton version of that, and then evolved the design based on what had been
built.
 In iterative model we are building and improving the product step by step. Hence, we can track
the defects at early stages. This avoids the downward flow of the defects.
 In iterative model we can get the reliable user feedback. When presenting sketches and
blueprints of the product to users for their feedback, we are effectively asking them to imagine
how the product will work.
 In iterative model less time is spent on documenting and more time is given for designing.

Disadvantages of Iterative model:

 Each phase of an iteration is rigid with no overlaps

 Costly system architecture or design issues may arise because not all requirements are gathered
up front for the entire lifecycle.
When to use iterative model:

 Requirements of the complete system are clearly defined and understood.

 When the project is big.
 Major requirements must be defined; however, some details can evolve with time.

Spiral Model

The Spiral model of software development is shown in picture below. The diagrammatic
representation of this model appears like a spiral with many loops. The exact number of loops in
the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For
example, the innermost loop might be concerned with feasibility study, the next loop with
requirements specification, the next one with design, and so on. Each phase in this model is split
into four sectors (or quadrants) as shown in picture below. The following activities are carried out
during each phase of a spiral model.
First quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.

Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk that the requirements are
inappropriate, a prototype system may be developed.
Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified risks.
Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the next iteration around the
spiral.
• Progressively more complete version of the software gets built with each iteration around the
spiral.

Why Spiral Model is called Meta Model?

The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However, this
model is much more complex than the other models – this is probably a factor deterring its use in
ordinary projects.
How many phases are in the Spiral model?

• Planning Phase:

Requirements are studied and gathered.

Feasibility study.
Reviews and walkthroughs to streamline the requirements.

• Risk Analysis
Requirements are studied and brain storming sessions are done to identify the potential
risks
Once the risks are identified, risk mitigation strategy is planned and finalized.

• Engineering Phase
Actual development and testing if the software takes place in this phase.

• Evaluation Phase
Customers evaluate the software and provide their feedback and approval

When to Use Spiral model?

 When the project is large.
 Where the software needs continuous risk evaluation.
 Requirements are a bit complicated and require continuous clarification.
 Software requires significant changes.
 Where enough time frame is their to get end user feedback.
 Where releases are required to be frequent.

Advantages of using Spiral model

 Development is fast
 Larger projects / software is created and handled in a strategic way
 Risk evaluation is proper.
 Control towards all the phases of development.
 More and more features are added in a systematic way.
 Software is produced early.
 Has room for customer feedback and the changes are implemented faster.

Disadvantages of Spiral model

 Risk analysis is important phase so requires expert people.
 Is not beneficial for smaller projects.
 Spiral may go infinitely.
 Documentation is more as it has intermediate phases.
 It is costly for smaller projects.
Conclusion:

Each spiral can be termed as a loop and each loop is a separate development process in a spiral
model. The four activities (Planning, Risk analysis, engineering and evaluation) form the intermediary
phases of a spiral model and is repeated again for each loop.

This model is very good to use for larger projects where you can develop and deliver smaller
prototypes and can enhance it to make the larger software. The implementation of this model
requires experienced resources as risk analysis is a very integral part of this model and risk analysis
requires expertise and as a result this model becomes costly.

Prototyping SDLC Model:

A prototype is a toy implementation of the system. A prototype usually exhibits limited functional
capabilities, low reliability, and inefficient performance compared to the actual software. A
prototype is usually built using several shortcuts. The shortcuts might involve using inefficient,
inaccurate, or dummy functions. The shortcut implementation of a function, for example, may
produce the desired results by using a table look-up instead of performing the actual computations.
A prototype usually turns out to be a very crude version of the actual system.
 The basic idea in Prototype model is that instead of freezing the requirements before a
design or coding can proceed, a throwaway prototype is built to understand the
requirements.
 This prototype is developed based on the currently known requirements. Prototype model is
a software development model. By using this prototype, the client can get an “actual feel” of
the system, since the interactions with prototype can enable the client to better understand
the requirements of the desired system.
 Prototyping is an attractive idea for complicated and large systems for which there is no
manual process or existing system to help determining the requirements.
 The prototype are usually not complete systems and many of the details are not built in the
prototype. The goal is to provide a system with overall functionality.
Need for prototype in software development

There are several uses of a prototype. An important purpose is to illustrate the input data formats,
messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for
gaining better understanding of the customer’s needs:
 how the screens might look like
 how the user interface would behave
 how the system would produce outputs

Another reason for developing a prototype is that it is impossible to get the perfect product in the
first attempt. Many researchers and engineers advocate that if you want to develop a good product
you must plan to throw away the first version. The experience gained in developing the prototype
can be used to develop the final product.
A prototyping model can be used when technical solutions are unclear to the development team. A
developed prototype can help engineers to critically examine the technical issues associated with
the product development. Often, major design decisions depend on issues like the response time of
a hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances, a
prototype may be the best or the only way to resolve the technical issues.
A prototype of the actual product is preferred in situations such as:
• User requirements are not complete
• Technical issues are not clear.

Advantages of Prototype model:

 Users are actively involved in the development

 Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily.

Disadvantages of Prototype model:

 Leads to implementing and then repairing way of building systems.

 Practically, this methodology may increase the complexity of the system as scope of the system
may expand beyond original plans.

When to use Prototype model:

 Prototype model should be used when the desired system needs to have a lot of interaction
with the end users.
 Typically, online systems, web interfaces have a very high amount of interaction with end users,
are best suited for Prototype model. It might take a while for a system to be built that allows ease
of use and needs minimal training for the end user.
  Prototyping ensures that the end users constantly work with the system and provide a feedback
which is incorporated in the prototype to result in a useable system. They are excellent for
designing good human computer interface systems.

Comparison of different life-cycle models

The classical waterfall model can be considered as the basic model and all other life cycle models as
embellishments of this model. However, the classical waterfall model cannot be used in practical
development projects, since this model supports no mechanism to handle the errors committed
during any of the phases.
This problem is overcome in the iterative waterfall model. The iterative waterfall model is probably
the most widely used software development model evolved so far. This model is simple to
understand and use. However, this model is suitable only for well-understood problems; it is not
suitable for very large projects and for projects that are subject to many risks.

The prototyping model is suitable for projects for which either the user requirements or the
underlying technical aspects are not well understood. This model is especially popular for
development of the user-interface part of the projects.

The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However, this
model is much more complex than the other models – this is probably a factor deterring its use in
ordinary projects.

The different software life cycle models can be compared from the viewpoint of the customer.
Initially, customer confidence in the development team is usually high irrespective of the
development model followed. During the lengthy development process, customer confidence
normally drops off, as no working product is immediately visible.
Developers answer customer queries using technical slang, and delays are announced. This gives rise
to customer resentment.
On the other hand, an evolutionary approach lets the customer experiment with a working product
much earlier than the monolithic approaches. Another important advantage of the incremental
model is that it reduces the customer’s trauma of getting used to an entirely new system. The
gradual introduction of the product via incremental phases provides time to the customer to adjust
to the new product. Also, from the customer’s financial viewpoint, incremental development does
not require a large upfront capital outlay. The customer can order the incremental versions as and
when he can afford them.
Rapid Application Development Model (RAD)
Rapid Application Development or RAD model is one of the approaches for writing software. is less
long-term planning involved in the process, and more focus is paid to the adaptability of the
development workflow.
The RAD model takes information gathered during workshops and other focus groups created to
identify what customers want from the product. The initial product is also tested, which helps in the
creation of the final product and continued use of the parts of the product that have been proven to
be effective.
RAD is a type of software development that does not dedicate a lot of time or resources on planning
and instead uses a method of prototyping to introduce the product.
A prototype is a version of the product that mimics what that actual product will look like, and it can
complete the same functions, which allows for a faster output of the created element.

The structure of the RAD lifecycle is thus designed to ensure that developers build the systems that
the users really need. This lifecycle, through the following four stages, includes all of the activities
and tasks required to scope and define business requirements and design, develop, and implement
the application system that supports those requirements.

 Requirements Planning
Also known as the Concept Definition Stage, this stage defines the business functions and
data subject areas that the system will support and determines the system’s scope.
 User Design
Also known as the Functional Design Stage, this stage uses workshops to model the system’s
data and processes and to build a working prototype of critical system components.
 Construction
Also known as the Development Stage, this stage completes the construction of the physical
application system, builds the conversion system, and develops user aids and
implementation work plans.
 Implementation
Also known as the Deployment Stage, this stage includes final user testing and training, data
conversion, and the implementation of the application system.
Essential Aspects of RAD
It is critical that all the aspects mentioned above are adequate to ensure high-speed development.
Development life cycles, which make up these aspects together as effectively as possible, are of the
utmost importance. Various aspects of RAD are:

1. Methodology: Important features of RAD methodology include:

 Combining the best available techniques and specifying the sequence of tasks that
will make those techniques most effective.
 Using evolutionary prototypes that are eventually transformed into the final product.
 Using workshops, instead of interviews, to gather requirements and review design.
 Selecting a set of tools to support modelling, prototyping and code reusability, as well
as automating many of the combinations of techniques.
 Implementing time-boxed development that allows development teams to quickly
build the core of the system and implement refinements in subsequent releases.
 Providing guidelines for success and describing the pitfalls to avoid.

2. People: In RAD there are 5 typical user roles:

 RAD Facilitator who plans and manage the project

 The Information specialists who translate the end users’ needs.
 The End users
 The scribe who documents the sessions
 The developers.

3. Management:
It is important that the management is completely committed to RAD to enable high-speed
development. Managers must motivate the IT team and end users for faster system building.
Managers should also focus on ‘Early Adapters’, who see value in new methodologies and
 lead the way in making it practical to use. The best way for managers to introduce RAD is to
start small. Original Construction Teams of two to four people should be established and their
members should be thoroughly trained in the use of the tools and techniques. As these
teams gain experience, they will be able to fine-tune the development lifecycle to improve its
effectiveness in their environment.

4. Tools:
Examples of tools that can be used in RAD projects are Computer-Assisted Software
Engineering (CASE) tools. These tools play a pivotal role in eradicating some problems that
exist in other models of software development. For example, CASE tools can be used to
develop models (using e.g. UML diagrams) and directly generate code based on those models
instead of hard coding.

When to use RAD Model?

 When the system should need to create the project that modularizes in a short span time (2-
3 months).
 When the requirements are well-known.
 When the technical risk is limited.
 When there's a necessity to make a system, which modularized in 2-3 months of period.
 It should be used only if the budget allows the use of automatic code generating tools.

Advantage of RAD Model

 This model is flexible for change.
 In this model, changes are adoptable.
 Each phase in RAD brings highest priority functionality to the customer.
 It reduced development time.
 It increases the reusability of features.

Disadvantage of RAD Model

 It required highly skilled designers.
 All application is not compatible with RAD.
 For smaller projects, we cannot use the RAD model.
 On the high technical risk, it's not suitable.
 Required user involvement.
 Traditional SDLC vs. RAD

RAD TRADITIONAL SDLC

The stages are laid out clearly and structured

The stages are not strictly defined.
sequentially.

Here, once one step is complete, it is not reviewed

This model is iterative and different stages of the
and iterations or changes are not made. Every phase
app development can be reviewed when needed.
is completed before the next one starts.

The development of apps using this model is

faster because automated RAD Tools and App development takes longer time and effort.
techniques are used.

It is not essential to know all the requirements of All the requirements of the project must be known
the project beforehand as they can be added and and laid out clearly beforehand because they cannot
changed as development is going on. be changed later on.

Changes are difficult to implement because of the

Changes can be implemented easily.
sequential nature of the model.

This methodology relies very much on feedback

Minimal customer feedback is used.
from customers to build the software.