Tampilkan postingan dengan label Sofware. Tampilkan semua postingan
Tampilkan postingan dengan label Sofware. Tampilkan semua postingan

Minggu, 11 Oktober 2020

Rapid Application Development (RAD)

Rapid Application Development (RAD) model has the following phases −

  • Requirements Planning phase − In the requirements planning phase, aworkshop needs to be conducted to discuss business problems in a structured manner.

  • User Description phase − In the User Description phase, automated tools are used to capture information from users.

  • Construction phase − In the Construction phase, productivity tools, such as code generators, screen generators, etc. are used inside a time-box, with a “Do until Done” approach.

  • Cut Over phase − In the Cut over phase, installation of the system, user acceptance testing and user training are performed.

RAD Phases

Rapid Application Development Model – Strengths

The advantages or strengths of the Rapid Application Development model are as follows −

  • Reduced cycle time and improved productivity with fewer team members would mean lower costs.

  • Customer’s involvement throughout the complete cycle minimizes the risk of not achieving customer satisfaction and business value.

  • Focus moves to the code in a what-you-see-is-what-you-get mode (WYSIWYG). This brings clarity on what is being built is the right thing.

  • Uses modelling concepts to capture information about business, data, and processes.

Rapid Application Development Model – Weaknesses

The disadvantages or strengths of Rapid Application Development model are as follows −

  • Accelerated development process must give quick responses to the user.

  • Risk of never achieving closure.

  • Hard to use with legacy systems.

  • Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

When to Use Rapid Application Development Model?

Rapid Application Development model can be used when −

  • User can be involved throughout the life cycle.
  • Project can be time-boxed.
  • Functionality can be delivered in increments.

Though the strengths of Rapid Application Development model are appreciated, it is sparingly used in the industry.

SDLC - Interative Incremental Model

In an Iterative Incremental model, initially, a partial implementation of a total system is constructed so that it will be in a deliverable state. Increased functionality is added. Defects, if any, from the prior delivery are fixed and the working product is delivered. The process is repeated until the entire product development is completed. The repetitions of these processes are called iterations. At the end of every iteration, a product increment is delivered.

Iterations

Iterative Incremental Model – Strengths

The advantages or strengths of Iterative Incremental model are −

  • You can develop prioritized requirements first.

  • Initial product delivery is faster.

  • Customers gets important functionality early.

  • Lowers initial delivery cost.

  • Each release is a product increment, so that the customer will have a working product at hand all the time.

  • Customer can provide feedback to each product increment, thus avoiding surprises at the end of development.

  • Requirements changes can be easily accommodated.

Iterative Incremental Model – Weaknesses

The disadvantages of the Iterative Incremental model are −

  • Requires effective planning of iterations.

  • Requires efficient design to ensure inclusion of the required functionality and provision for changes later.

  • Requires early definition of a complete and fully functional system to allow the definition of increments.

  • Well-defined module interfaces are required, as some are developed long before others are developed.

  • Total cost of the complete system is not lower.

When to Use Iterative Incremental Model?

Iterative Incremental model can be used when −

  • Most of the requirements are known up-front but are expected to evolve over time.

  • The requirements are prioritized.

  • There is a need to get the basic functionality delivered fast.

  • A project has lengthy development schedules.

  • A project has new technology.

  • The domain is new to the team.

SDLC - Waterfall Model

The Waterfall model is a classic SDLC model that is widely known, understood and commonly used. It was introduced by Royce in 1970 and is still being followed as a common approach for software development in various organizations across the industry.

In Waterfall model, each lifecycle phase can start only after the earlier lifecycle phase is complete. Thus, it is a linear model with no feedback loops.

Waterfall Lifecycle

Waterfall Model – Strengths

The strengths of the Waterfall model are −

  • Easy to understand, easy to use.
  • Provides structure to inexperienced development team.
  • Milestones are well understood.
  • Sets requirements stability.
  • Ideal for management control (planning, monitoring, reporting).
  • Works well when quality is more important than cost or schedule.

Waterfall Model – Weaknesses

The weaknesses or the disadvantages of the Waterfall model are −

  • Idealised − It does not match reality well.

  • Unrealistic − cannot expect accurate requirements early in the project.

  • Does not reflect iterative nature of exploratory development that is more common.

  • Difficult and expensive to make changes.

  • Software is delivered only at the end of the project. Due to this −

    • Delays discovery of serious defects.

    • Possibility of delivery of obsolete requirements.

  • Significant management overhead, which can be costly for small teams and projects.

  • Requires experienced resources at every phase − analysts, designers, developers, testers.

  • Testing starts only after the development is complete and the testers are not involved in any of the earlier phases.

  • The expertize of the cross-functional teams is not shared as each phase is executed in silos.

When to Use Waterfall Model?

You can use the Waterfall model if −

  • Requirements are very well known.

  • Product definition is stable.

  • Technology is well understood.

  • New version of an existing product.

  • Porting an existing product to a new platform.

  • Large organization with structured cross-functional teams.

  • Communication channels are well established within the organization and with the customer as well.

Evolutionary Prototyping Model

In software development using Evolutionary Prototyping model, the developers build a prototype during the requirements phase. The end users then evaluate the prototype and give feedback. The feedback can be corrections to the prototype or additional functionality. Based on the feedback, the developers further refine the prototype.

Thus, the product evolves through the Prototype → Feedback → Refined Prototype Cycles and hence the name Evolutionary Prototyping. When the user is satisfied with the functionality, and working of the product, the prototype code is brought up to the required standards for the final product delivery.

Final Product Delivery

Evolutionary Prototyping Model – Strengths

The strengths or the advantages of an Evolutionary Prototyping model are −

  • Customers/end users can visualize the system requirements as they are gathered looking at the prototype.

  • Developers learn from customers and hence no ambiguities regarding domain or production environment.

  • Allows flexible design and development.

  • Interaction with the prototype stimulates the awareness of additionally needed functionality.

  • Unexpected requirements and requirements changes are easily accommodated.

  • Steady and visible signs of progress are produced.

  • Delivery of an accurate and maintainable end-product.

Evolutionary Prototyping Model – Weaknesses

The weaknesses or disadvantages of the Evolutionary Prototyping model are as follows −

  • Tendency to abandon structured development in the code-and-fix development, though it is not what is prescribed by the model.

  • This model received bad reputation for the quick-and-dirty methods.

  • Overall maintainability can possibly be overlooked.

  • The customer can possibly ask for the delivery of the prototype as the final, not giving the opportunity for the developers to execute the final step i.e. standardization of the end-product.

  • Project can continue forever (with continuous scope creep) and the management may not appreciate it.

When to Use Evolutionary Prototyping Model?

You can use the Evolutionary Prototyping model −

  • When requirements are unstable or have to be clarified
  • As the requirements clarification stage of a waterfall model
  • To develop user interfaces
  • For short-lived demonstrations
  • For new or original development
  • For implementing a new technology

SDLC model is a framework - evolution

A Software Development Life Cycle (SDLC) model is a framework that describes the activities performed at each stage of a software development project.

In a Software Development Life Cycle, the activities are performed in five phases −

  • Requirements Gathering − Requirements for a software to be developed are gathered. These requirements will be in a language that is understood by the customer / user. Domain specific terminology is recommended.

  • Analysis − The gathered requirements are analyzed from implementation point of view and the software specifications are written to cover both, the functional requirements and the non-functional requirements.

  • Design − This phase involves arriving at the software architecture and implementation specifics based on technology chosen for development.

  • Construction − In this phase, the code is developed, unit tested, integrated, integration tested and the build is produced.

  • Testing − Functional testing of the built software is done in this phase. This also includes the testing of non-functional requirements.

There are two approaches to performing these activities −

  • Prescriptive − The SDLC models that will provide you ways of performing the activities in a prescribed manner as defined by the framework.

  • Adaptive − The SDLC models that will give you flexibility in performing the activities, with certain rules that need to be followed. The agile methods mostly follow this approach, with each one having its rules. However, following an adaptive or agile approach does not mean that the software is developed without following any discipline. This would lead to a chaos.

You need to understand that we cannot say that a specific SDLC model is good or bad. Each of them has its own strengths and weaknesses and thus are suitable in certain contexts.

When you choose an SDLC model for your project, you need to understand −

  • Your Organization Context
  • Your Technology Context
  • Your Team Composition
  • Your Customer Context

For example, if the software development is predictable, you can use a Prescriptive approach. On the other hand, if the software development is unpredictable, i.e. requirements are not entirely known, or the development team does not have prior exposure to the current domain or technology, etc. then Adaptive approach is the best choice.

In the following sections, you will understand the most prevalent SDLC models that are evolved during the execution of software development projects across the industry. You will also get to know the strengths and weaknesses of each of them and in what contexts they are suitable.

INTRODUCTION

What is Agile?

In literary terms, the word “agile” means someone who can move quickly and easily or someone who can think and act quickly and clearly. In business, “agile” is used for describing ways of planning and doing work wherein it is understood that making changes as needed is an important part of the job. Business “agility” means that a company is always in a position to take account of the market changes.

In software development, the term “agile” is adapted to mean “the ability to respond to changes − changes from Requirements, Technology and People.”

Agile Manifesto

The Agile Manifesto was published by a team of software developers in 2001, highlighting the importance of the development team, accommodating changing requirements and customer involvement.

The Agile Manifesto is −

We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value −

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

Characteristics of Agility

Following are the characteristics of Agility −

  • Agility in Agile Software Development focuses on the culture of the whole team with multi-discipline, cross-functional teams that are empowered and selforganizing.

  • It fosters shared responsibility and accountability.

  • Facilitates effective communication and continuous collaboration.

  • The whole-team approach avoids delays and wait times.

  • Frequent and continuous deliveries ensure quick feedback that in in turn enable the team align to the requirements.

  • Collaboration facilitates combining different perspectives timely in implementation, defect fixes and accommodating changes.

  • Progress is constant, sustainable, and predictable emphasizing transparency.

Agile Methodologies

Early implementations of Agile methods include Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM). These are now collectively referred to as the Agile methodologies, after the Agile manifesto was published in 2001.

In this tutorial, we will learn the Agile Methodology − Adaptive Software Development.

What is Adaptive Software Development?

Adaptive Software Development is a move towards adaptive practices, leaving the deterministic practices in the context of complex systems and complex environments. Adaptive Software Development focuses on collaboration and learning as a technique to build complex systems. It is evolved from the best practices of Rapid Application Development (RAD) and Evolutionary Life Cycles. Adaptive Software Development was then extended to include adaptive approaches for the management, with speculation replacing Planning.

ASD Lifecycle

Jim Highsmith published a book on Adaptive Software Development in 2000. In Highsmith’s words −

“Adaptive Software Development is cyclical like the evolutionary model, with the phase names Speculate, collaborate, learn reflecting the unpredictable realm of increasingly complex systems. Adaptive development goes further than its evolutionary heritage in two key ways. First, it explicitly replaces determinism with emergence. Second, it goes beyond a change in Life Cycle to a deeper change in management style.”