Embedded Development Life

Cycle (EDLC)
 Conceptualization
The conceptualization phase of a project
occurs in the initial design activity when the
scope of the project is drafted and a list of the
desired design features and requirements is
created.
 Linear / Waterfall Model
The waterfall development model originates in the manufacturing and
construction industries: highly structured physical environments in which after-
the-fact changes are prohibitively costly, if not impossible. Since no formal
software development methodologies existed at the time, this hardware-oriented
model was simply adapted for software development.
The steps are:
1.Specification.
2.Preliminary design.
3.Design review
4.Detailed design.
5.Design review.
6.Implementation.
7.Review.
 Linear / Waterfall Model
Phases:
1) Requirement : In this phase we gather necessary information which will
use for development of any project . For above example we gather information like
which types of characteristics client wants. It also defines system requirement
specification. This phase defines what to do.
2) Design: In design phase we then construct design to how to implement that
requirements gathered into phase 1 .This phase define how to do .For this phase
we then write algorithms
3) Coding: Now base on design phase we then write actual code to implement
algorithms. This code should be efficient.
4)Testing : This phase use to test our coding part it checks all the validation...like
our code should work for each and every possibilities of input if any bug occur
then we have to report that bug to design phase or development phase.
5) Maintenance: In this phase we need keep updating information.
1. The implementation process contains software preparation and transition
activities, such as the conception and creation of the maintenance plan; the
preparation for handling problems identified during development; and the follow
up on product configuration management.
 Linear / Waterfall Model
2. The problem and modification analysis process, which is executed once the
application has become the responsibility of the maintenance group. The
maintenance programmer must analyze each request, confirm it (by reproducing
the situation) and check its validity, investigate it and propose a solution,
document the request and the solution proposal,
and, finally, obtain all the required authorizations to apply the modifications.
3. The process considering the implementation of the modification itself.
4. The process acceptance of the modification, by confirming the modified work
with the individual who submitted the request in order to make sure the
modification provided a solution.
5. The migration process is exceptional, and is not part of daily maintenance tasks.
If the software must be ported to another platform without any change in
functionality, this process will be used and a maintenance project team is likely to
be assigned to this task.
6. Finally, the last maintenance process, also an event which does not occur on a
daily basis, is the retirement of a piece
 Strength and Weakness
Model/feature Strengths Weaknesses When to Use

Waterfall • Easy to understand and implement. • All requirements must be known upfront • When quality is more
• Widely used and known. • Inflexible. important than cost or
• Define before design, and design before • Backing up to solve mistakes is difficult, schedule.
coding. once an application is in • When requirements
• Being a linear model, it is very simple to the testing stage, it is very difficult to go are very well known,
implement. back and change something that was not clear, and fixed.
• Works well on mature products and provides well-thought out in the concept stage. • New version of existing
structure to inexperienced teams. • A non-documentation deliverable only product is needed.
• Minimizes planning overhead. produced at the final phase. • Porting an existing
• Phases are processed and completed one at a • Client may not be clear about what they product to a new
time. want and what is needed. platform
• Customers may have little opportunity to
preview the system until it may be too
late.
• It is not a preferred model for complex
and object-oriented projects.
• High amounts of risk and uncertainty,
thus, small changes or errors that arise in
the completed software may cause a lot
The Rapid prototyping model is intended to provide a rapid
implementation of high level portions of both the software
and the hardware . The approach allows developers
to construct working portion of hardware and software in
incremental stages.Each stage through the cycle,one
incorporates a little more of the intended functionality.The
prototype is useful for both the designer and the customer.
The prototype can be either evolutionary or throughway. It
has the advantage of having a working system early in
development process
 Spiral Model
The steps in spiral model life cycle are
Determine objective,alternatives,and
constraints.
Identify and resolve risks.
Evaluate alternatives.
Develop deliverables-verify that they are
correct.
Plan the next iteration.
Commit to an approach for the next iteration.
Spiral Model
 Comparison
Properties of Model Water-Fall Model Incremental Model Spiral Model Rapid Model

Planning in early stage Yes Yes Yes No

Returning to an earlier No Yes Yes Yes

Handle Large-Project Not Appropriate Not Appropriate Appropriate Not Appropriate

Detailed Documentation Necessary Yes but not much Yes Limited

Cost Low Low Expensive Low

Requirement Beginning Beginning Beginning Time boxed release

Flexibility to change Difficult Easy Easy Easy

User Involvement Only at beginning Intermediate High Only at the beginning

Maintenance Least Promotes Maintainability Typical Easily Maintained

Duration Long Very long Long Short

Risk Involvement High Low Medium to high risk Low

Framework Type Linear Linear + Iterative Linear + Iterative Linear

Testing After completion of After every iteration At the end of the After completion of
coding phase engineering phase coding

Overlapping Phases No Yes (As parallel No Yes

Maintenance Least Maintainable Maintainable Yes Easily Maintainable

Re-usability Least possible To some extent To some extent Yes

Time-Frame Very Long Long Long Short

Working software At the end of the life- At the end of every At the end of every At the end of the life
availability cycle iteration iteration cycle

Objective High Assurance Rapid Development High Assurance Rapid development

Team size Large Team Not Large Team Large Team Small Team

Customer control over Very Low Yes Yes Yes