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 ModelPhases:

1) Requirement : In this phase we gather necessary information which willuse for development of any project . For above example we gather information likewhich types of characteristics client wants. It also defines system requirementspecification. 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 algorithms3) 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...likeour 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 workwith 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 areDetermine 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

ComparisonProperties of Model Water-Fall Model Incremental Model Spiral Model Rapid Model

Planning in early stage Yes Yes Yes No

Returning to an earlier

phase

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

Specifications

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

Properties of Model Water-Fall Model Incremental Model Spiral Model Rapid Model

Testing After completion of

coding phase

After every iteration At the end of the

engineering phase

After completion of

coding

Overlapping Phases No Yes (As parallel

development is there)

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

availability

At the end of the life-

cycle

At the end of every

iteration

At the end of every

iteration

At the end of the life

cycle

Objective High Assurance Rapid Development High Assurance Rapid development

Team size Large Team Not Large Team Large Team Small Team

Customer control over

administrator

Very Low Yes Yes Yes