Escolar Documentos
Profissional Documentos
Cultura Documentos
History
The "waterfall model", documented in 1970 by Royce was the first publicly documented
life cycle model. The model was developed to help cope with the increasing complexity
of aerospace products. The waterfall model followed a documentation driven paradigm.
The next revolutionary new look at the development lifecycle was the "spiral model",
presented by Boehm in 1985. The spiral model is focused on risk management.
Methods
Life cycle models describe the interrelationships between software development phases.
The common life cycle models are:
• spiral model
• waterfall model
• throwaway prototyping model
• evolutionary prototyping model
• incremental/iterative development
• reusable software model
• automated software synthesis
Because the life cycle steps are described in very general terms, the models are adaptable
and their implementation details will vary among different organizations. The spiral
model is the most general. Most life cycle models can in fact be derived as special
instances of the spiral model. Organizations may mix and match different life cycle
models to develop a model more tailored to their products and capabilities.
Learn
A software life cycle model depicts the significant phases or activities of a software
project from conception until the product is retired. It specifies the relationships between
project phases, including transition criteria, feedback mechanisms, milestones, baselines,
reviews, and deliverables. Typically, a life cycle model addresses the following phases of
a software project: requirements phase, design phase, implementation, integration,
testing, operations and maintenance. Much of the motivation behind utilizing a life cycle
model is to provide structure to avoid the problems of the "undisciplined hacker".
Evaluate
Spiral Model
The spiral model is the most generic of the models. Most life cycle models can be derived
as special cases of the spiral model. The spiral uses a risk management approach to
software development. Some advantages of the spiral model are:
Waterfall Model
The least flexible and most obsolete of the life cycle models. Well suited to projects that
has low risk in the areas of user interface and performance requirements, but high risk in
budget and schedule predictability and control.
Useful in "proof of concept" or situations where requirements and user's needs are
unclear or poorly specified. The approach is to construct a quick and dirty partial
implementation of the system during or before the requirements phase.
Use in projects that have low risk in such areas as losing budget, schedule predictability
and control, large-system integration problems, or coping with information sclerosis, but
high risk in user interface design.
Incremental/iterative Development
The process for constructing several partial deliverables, each having incrementally more
functionality.
This process relies on tools to transform requirements into operational code. Formal
requirements are created and maintained using specification tools. This is an active
research area, and practical tools for this approach are yet to be developed.
Life Cycle of Testing
This article explains about Differant steps in Life Cycle of Testing Process. in Each phase of the
development process will have a specific input and a specific output. Once the project is
confirmed to start, the phases of the development of project can be divided into the following
phases:
In the whole development process, testing consumes highest amount of time. But
most of the developers oversee that and testing phase is generally neglected. As a
consequence, erroneous software is released. The testing team should be involved right
from the requirements stage itself.
The various phases involved in testing, with regard to the software development life cycle
are:
1. Requirements stage
2. Test Plan
3. Test Design.
4. Design Reviews
5. Code Reviews
6. Test Cases preparation.
7. Test Execution
8. Test Reports.
9. Bugs Reporting
10. Reworking on patches.
11. Release to production.
Requirements Stage
Normally in many companies, developers itself take part in the requirements stage.
Especially for product-based companies, a tester should also be involved in this stage.
Since a tester thinks from the user side whereas a developer can’t. A separate panel
should be formed for each module comprising a developer, a tester and a user. Panel
meetings should be scheduled in order to gather everyone’s view. All the requirements
should be documented properly for further use and this document is called “Software
Requirements Specifications”.
Test Plan
Without a good plan, no work is a success. A successful work always contains a good
plan. The testing process of software should also require good plan. Test plan document is
the most important document that brings in a process – oriented approach. A test plan
document should be prepared after the requirements of the project are confirmed. The test
plan document must consist of the following information:
Test Design
Test Design is done based on the requirements of the project. Test has to be
designed based on whether manual or automated testing is done. For automation testing,
the different paths for testing are to be identified first. An end to end checklist has to be
prepared covering all the features of the project.
The test design is represented pictographically. The test design involves various stages.
These stages can be summarized as follows:
Then the design is drawn. The test design is the most critical one, which decides the test
case preparation. So the test design assesses the quality of testing process.
• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios
This article talks about many interesting things like what's the Case for Automated Testing,
Why Automate the Testing Process?, Using Testing Effectively, Reducing Testing Costs,
Replicating testing across different platforms, Greater Application Coverage, Results Reporting,
Understanding the Testing Process, Typical Testing Steps, Identifying Tests Requiring
Automation, Task Automation and Test Set-Up and Who Should Be Testing?.
In the past, most software tests were performed using manual methods. This required a
large staff of test personnel to perform expensive and time-consuming manual test
procedures. Owing to the size and complexity of today’s advanced software applications,
manual testing is no longer a viable option for most testing situations.
By definition, testing is a repetitive activity. The methods that are employed to carry out
testing (manual or automated) remain repetitious throughout the development life cycle.
Automation of testing processes allows machines to complete the tedious, repetitive work
while human personnel perform other tasks. Automation eliminates the required “think
time” or “read time” necessary for the manual interpretation of when or where to click
the mouse. An automated test executes the next operation in the test hierarchy at machine
speed, allowing test to be completed many times faster than the fastest individual.
Automated test also perform load/stress testing very effectively.
Automation allows the testing organization to perform consistent and repeatable test.
When applications need to be deployed across different hardware or software platforms,
standard or benchmark tests can be created and repeated on target platforms to ensure that
new platforms operate consistently.
The productivity gains delivered by automated testing allow and encourage organization
to test more often and more completely. Greater application test coverage also reduces the
risk if exposing users to malfunctioning or non-compliant software.
Results Reporting
Full-featured automated testing systems also produce convenient test reporting and
analysis. These reports provide a standardized measure of test status and results, thus
allowing more accurate interpretation of testing outcomes. Manual methods require the
user to self-document test procedures and test results.
Usability Engineering, an empirical science has quite a simple definition. It studies the human
interaction and cognitive behavior of an individual with respect to performing as task. It could
be as simple as a driving a vehicle or using a product. Users interaction in performing a task
should be in sync with the workflow of the product. Usability Engineering as a science helps in
achieving this goal.
A Product should be usable. It means that people can use a product easily and efficiently
to accomplish their own tasks. A product, which is usable, enables workers to concentrate
on their tasks and to do real work, rather than on the tools they use to perform their tasks.
Usability applies to every aspect of a product with which a person interacts (hardware,
software, menus, icons, messages, documentation, training, and on-line help). Every
design and development decision made throughout the product cycle has an impact on
that product’s usability.
As customers depend more and more on software to get their jobs done and become more
critical consumers, usability can be the critical factor that ensures that products will be
used.
For example, as processes are being engineered and requirements are being developed,
observations and interviews may be the techniques of choice. Later in the development
cycle, as the “look and feel” of a product is being designed, benchmarking, prototyping
and participatory design may be useful techniques. Once a design has been determined,
usability testing may be used more appropriately. Usability is an iterative process, just
like software development. The usability process works best if it is done in partnership
with product development.
1. User and task observations – observing users at their jobs, identifying their typical
work tasks and procedures, analyzing their work processes, and understanding people in
the context of their work.
2. Interviews, focus groups and questionnaires – meeting with users, finding out about
their preferences, experiences and needs.
8. Usability testing - observing users performing real tasks with the application,
recording what they do, analyzing the results and recommending appropriate changes.
Metrics
• Overall feedback rating given by customer on execution of project / product
service
• Effort Variance
• Schedule Variance
• Cost of Quality
• Test Design Productivity
• Testing Productivity
• Testing efficiency
• Customer Issues
• Utilization of allocated effort
• Test design coverage
• Test execution coverage