embedded development life cycle (edlc) · linear / waterfall model the waterfall development model...
TRANSCRIPT
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