Scribd
Upload
18 views24 pages

03-Sdlc Models (II)

Uploaded by

akrajput1504
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views24 pages

03-Sdlc Models (II)

Uploaded by

akrajput1504
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 24

SOFTWARE CONSTRUCTION

AND DEVELOPMENT
SE-351

Muhammad Waheed Khan


SDLC Models Overview (cont.)
Software Process Models
Spiral Model
• Suggested by Boehm (1988)

• The spiral model represents a paradigm shift from the waterfall’s


specification driven approach to a risk-driven one.

• Combines development activities with risk management to minimize and


control risks

• It is in some way the iterative development.


Software Process Models
Spiral Model
• The model is presented as a spiral in which each iteration is represented
by a circuit around four major activities
✓ Plan
✓ Determine goals, alternatives, and constraints
✓ Evaluate alternatives and risks
✓ Develop and test
• As each cycle within the spiral progresses, a prototype is built, verified
against its requirements and validated through testing.
• Prior to this, risks are identified and analyzed to manage them.
Software Process Models
Spiral Model (cont.)

• With each iteration, the risk analysis weighs different alternatives


considering the requirements and constraints.

• The prototyping verifies feasibility or desirability before a particular


alternative is chosen.

• When risks are identified, the project managers decide how to eliminate
or minimize the risk.

- for example, to minimize the risk of choosing an interface that will


prevent productive use of the new system, the designer can prototype
each interface and run tests to see which is preferred.
Software Process Models
Spiral Model (cont.)
RAD (Rapid Application Development)
• It is a type of incremental model. In RAD model the components
or functions are developed in parallel as if they were mini projects.
• The developments are time boxed, delivered and then assembled
into a working prototype to rapidly produce a high-quality
system
• Advantages:
 active involvement of users in the development process
 speeds the development process
 reduces development costs
 can create applications that are easier to maintain and modify
• Disadvantages:
 may result in systems with limited functionality and adaptability for change
RAD (Rapid Application Development)

 In RAD Model, development should be done in specified time frame.


 RAD Model is suitable for the small project where all the requirements are gathered
before starting development of the project and no any concrete plan required
 Development starts as soon as requirement gathered and delivered initial working
prototype to the client to get the feedback
Advantages /Disadvantages of RAD Model:
Advantages of RAD Model Disadvantages of RAD Model:

• Fast application development and delivery. • High skilled resources required.

• Lest testing activity required. • On each development phase client’s feedback


required.
• Visualization of progress.
• Automated code generation is very costly.
• Less resources required.
• Difficult to manage.
• Review by the client from the very beginning of
development so very less chance to miss the • Not a good process for long term and big projects.
requirements.
• Proper modularization of project required.
• Very flexible if any changes required.

• Cost effective.

• Good for small projects.


Software Process Models
Rational Unified Process (RUP)

The Rational Unified Process has four phases:


• Inception - Define the scope of project

• Elaboration - Plan project, specify features, baseline architecture

• Construction - Build the product

• Transition - Transition the product into end user community


Software Process Models: RUP Model
Inception
• Establishing the project's software scope and boundary conditions,
including:
• an operational vision
• acceptance criteria
• what is intended to be in the product
• what is not.
• Discriminating
• the critical use cases of the system
• the primary scenarios of operation that will drive the major design trade-offs.
• Exhibiting, and maybe demonstrating, at least one candidate
architecture against some of the primary scenarios
Inception
• Estimating
• the overall cost
• and schedule for the entire project
• and more detailed estimates for the elaboration phase that will
immediately follow
• Estimating potential risks (the sources of unpredictability)
• Preparing the supporting environment for the project.
Inception Artifacts
• Vision: The project's core requirements, key features, and main constraints are
documented. Stakeholders …

• Glossary: defines important terms used by the project.

• Business Case: provides the necessary information from a business standpoint to


determine whether or not this project is worth investing in.

• Software Development Plan: all information required to manage the project. (Risk,
time and durations, needed tools, changes, documentations)

• Use-case model: a model of the system's intended functions and its environment and
serves as a contract between the customer and the developers.
Elaboration
To ensure stability of:
• Architecture;
• Requirements;
• Plans.
To be able to predictably determine:
• Cost;
• Schedule.
• To address all significant risks of the project, and to ensure all
of them will be mitigated.
• To establish a baseline architecture
• Derived from addressing the architectural significant scenarios
Elaboration Activities

• To produce an evolutionary prototype

• Verify baseline architecture


• Demonstrate that the architecture will support requirements of the
system at a reasonable cost and time.

• To establish a supporting environment.


Elaboration Activities

• Defining, validating the baseline architecture.

• Refining the Vision.

• Creating detail of iteration plans for the construction phase.

• Refining the development case and putting in place the


development environment

• Refining the architecture and selecting components.


Elaboration Artifacts
• Software Architecture Document: provides a comprehensive architectural overview of the
system, using a number of different architectural views to depict different aspects of the system.

• Prototypes: One or more executable architectural prototypes have been created to explore
critical functionality and architecturally significant scenarios.

• Design model: an object model describing the realization of use cases and serves as an
abstraction of the implementation model and its source code.

• Data model: a subset of the implementation model which describes the logical and physical
representation of persistent data in the system.

• Testing Mechanisms and refining previous Iteration’s artifacts.


Construction
• Completing the analysis, design, development and testing of all required
functionality.

• Achieving useful versions (alpha, beta, and other test releases)

• Achieving adequate quality as rapidly as practical

• To decide if the software, the sites, and the users are all ready for the
application to be deployed.

• Minimizing development costs by optimizing resources and avoiding


unnecessary scrap and rework.

• To achieve some degree of parallelism in the work of development teams.


Construction Activities

• Resource management, control and process optimization

• Complete component development and testing against the


defined evaluation criteria

• Assessment of product releases against acceptance criteria for


the vision.
Construction Artifacts

• The System: The executable system itself, ready to begin


"beta" testing.

• Training materials: the material that is used in training


programs or courses to assist the end-users with product use,
operation and/or maintenance.

• Testing results and refining previous Iteration’s artifacts.


Transition

• Beta testing to validate the new system against user expectations

• Beta testing and parallel operation relative to a legacy system that


it's replacing

• Training of users and maintainers

• Roll-out to the marketing, distribution and sales forces

• Tuning activities such as bug fixing, enhancement for performance


and usability
Transition activities
• Executing deployment plans

• Finalizing end-user support material

• Testing the deliverable product at the development site

• Creating a product release

• Getting user feedback

• Fine-tuning the product based on feedback

• Making the product available to end users


Transition Artifacts
• Product.
• Release Notes: identify changes and known bugs in a version of a
build or deployment unit that has been made available for use.
• Installation Artifacts: refer to the software and documented
instructions required to install the product.
• End-User Support Material: Materials that assist the end-user in
learning, using, operating and maintaining the product.
• Testing results and refining previous Iteration’s artifacts.

You might also like