Spiral model

What is Spiral model- advantages, disadvantages and when to use it?

The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ that is ‘Business Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’.

Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions.  A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.

Engineering Phase: In this phase software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done.

Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

Diagram of Spiral model:

Advantages of Spiral model:

• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

Disadvantages of Spiral model:

• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

 When to use Spiral model:

• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)

Agile Model Pros and Cons

What is Agile model – advantages, disadvantages and when to use it?

Agile development model is also a type of Incremental model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is used for time critical applications. Extreme Programming (XP) is currently one of the most well-known agile development life cycle model.

Diagram of Agile model:

Advantages of Agile model:

§  Customer satisfaction by rapid, continuous delivery of useful software.

§  People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.

§  Working software is delivered frequently (weeks rather than months).

§  Face-to-face conversation is the best form of communication.

§  Close, daily cooperation between business people and developers.

§  Continuous attention to technical excellence and good design.

§  Regular adaptation to changing circumstances.

§  Even late changes in requirements are welcomed

Disadvantages of Agile model:

§  In case of some software deliverable, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

§  There is lack of emphasis on necessary designing and documentation.

§  The project can easily get taken off track if the customer representative is not clear what final outcome that they want.

§  Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

When to use agile model:

§  When new changes are needed to be implemented. The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced.

§  To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it.

§  Unlike the waterfall model in agile model very limited planning is required to get started with the project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT world. Changes can be discussed and features can be newly effected or removed based on feedback. This effectively gives the customer the finished system they want or need.

§  Both system developers and stakeholders alike, find they also get more freedom of time and options than if the software was developed in a more rigid sequential way. Having options gives them the ability to leave important decisions until more or better data or even entire hosting programs are available; meaning the project can continue to move forward without fear of reaching a sudden standstill.

Intro to Agile Modeling

An Introduction to Agile Modeling

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices> for modeling software that can be applied on a software development project in an effective and light-weight manner. As you see in Figure 1 AM is meant to be tailored into other, full-fledged methodologies such as XP or RUP, enabling you to develop a software process which truly meets your needs. In fact, this tailoring work has already been done for you in the form of the Disciplined Agile Delivery (DAD) process framework. 

- See more at: http://www.agilemodeling.com/essays/introductionToAM.htm#sthash.xzJr8hw5.dpuf

The values of AM, adopting and extending those of extreme Programming v1, are communication, simplicity, feedback, courage, and humility. The keys to modeling success are to have effective communication between all project stakeholders, to strive to develop the simplest solution possible that meets all of your needs, to obtain feedback regarding your efforts often and early, to have the courage to make and stick to your decisions, and to have the humility to admit that you may not know everything, that others have value to add to your project efforts.

AM is based on a collection of principles, such as the importance of assuming simplicity when you are modeling and embracing change as you are working because requirements will change over time. You should recognize that incremental change of your system over time enables agility and that you should strive to obtain rapid feedback on your work to ensure that it accurately reflects the needs of your project stakeholders. You should model with a purpose, if you don't know why you are working on something or you don't know what the audience of the model/document actually requires then you shouldn't be working on it. Furthermore, you need multiple models in your intellectual toolkit to be effective. A critical concept is that models are not necessarily documents, a realization that enables you travel light by discarding most of your models once they have fulfilled their purpose. Agile modelers believe that content is more important than representation, that there are many ways you can model the same concept yet still get it right. To be an effective modeler you need to recognize that open and honest communication is often the best policy to follow to ensure effective teamwork. Finally, a focus on quality work is important because nobody likes to produce sloppy work and that local adaptation of AM to meet the exact needs of your environment is important.

To model in an agile manner you will apply AM's practices as appropriate. Fundamental practices include creating several models in parallel, applying the right artifact(s) for the situation, and iterating to another artifact to continue moving forward at a steady pace. Modeling in small increments, and not attempting to create the magical "all-encompassing model" from your ivory tower, is also fundamental to your success as an agile modeler. Because models are only abstract representations of software, abstractions that may not be accurate, you should strive to prove it with code to show that your ideas actually work in practice and not just in theory Active stakeholder participation is critical to the success of your modeling efforts because your project stakeholders know what they want and can provide you with the feedback that you require. The principle of assume simplicity is a supported by the practices of creating simple content by focusing only on the aspects that you need to model and not attempting to creating a highly detailed model, depicting models simply via use of simple notations, and using the simplest tools to create your models. You travel light by single sourcing information, discarding temporary models and updating models only when it hurts. Communication is enabled by displaying models publicly, either on a wall or internal web site, through collective ownership of your project artifacts, through applying modeling standards, and by modeling with others. Your development efforts are greatly enhanced when you apply patterns gently. Because you often need to integrate with other systems, including legacy databases as well as web-based services, you will find that you need to formalize contract models with the owners of those systems. Read this article for a better understanding of how AM's practices fit together.

Figure 2. Agile Model Driven Development (AMDD).

I would argue that AM is an agile approach to modeling that at its core AM is simply a collection of practices that reflect the principles and values shared by many experienced software developers. With an Agile Model Driven Development (AMDD) (see Figure 2) approach you typically do just enough high-level modeling at the beginning of a project to understand the scope and potential architecture of the system, and then during development iterations you do modeling as part of your iteration planning activities and then take a just in time (JIT) model storming approach where you model for several minutes as a precursor to several hours of coding.

Rapid Application Development (RAD) 

As the name suggests Rapid Application Development (RAD) model is an incremental software process model that focuses on short development cycle time. This model is a “high-speed” model which adapts many steps from waterfall model in which rapid development is achieved by using component based construction approach.

In case if project requirements are well understood and project scope is well known then RAD process enables a development team to create a fully functional system i.e. software product within a very short time period may be in days.

RAD model is like other process models maps into the common and major framework activities.

Phases of RAD Model

Communication is an activity which works to understand the business problem and the information characteristics that should be accommodate by the software.

In RAD model Planning is required because numerous software teams works in parallel on different system functions.

Modelling includes 3 major phases –

1.      Business modeling

2.      Data modeling

3.      Process modeling

Construction focuses mainly on the use of existing software components and the application of automatic code generation.

Deployment establishes a basis for subsequent iterations if necessary.

A business application which can be modularize in a way that allows each major function to be completed in less than three months is useful for RAD. Each major function can be addressed individually by a separate RAD and then integrated to form a whole application.

 Diagram of RAD Model 

Advantages of RAD Model

1.      Flexible and adaptable to changes.

2.      Prototyping applications gives users a tangible description from which to judge whether critical system requirements are being met by the system. Report output can be compared with existing reports. Data entry forms can be reviewed for completeness of all fields, navigation, data access (drop down lists, check-boxes, radio buttons, etc.).

3.      RAD generally incorporates short development cycles – users see the RAD product quickly.

4.      RAD involves user participation thereby increasing chances of early user community acceptance.

5.      RAD realizes an overall reduction in project risk.

6.      Pareto’s 80 – 20 Rule usually results in reducing the costs to create a custom system.

Disadvantages of RAD Model

1.      Unknown cost of product. As mentioned above, this problem can be alleviated by the customer agreeing to a limited amount of rework in the RAD process.

2.      It may be difficult for many important users to commit the time required for success of the RAD process.

Drawbacks of RAD Model

1.      RAD requires sufficient human resources to create the right number of RAD teams

2.      If developers and customers are not committed to the rapid, rapid-fire activities necessary to complete the system in a much abbreviated time frame, RAD projects will fail.

3.      For RAD system should be properly modularize otherwise it creates lots of problems to the RAD model.

4.      Rad approach does not work properly if high performance is a major issue, and performance is to be achieved through tuning the interface to system components.

5.      When technical risks are high RAD may not be a suitable option. This may be possible while an application heavy uses a new technology.

When to use RAD model:

§  RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.

§  It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.

§  RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).

Incremental Model

What is Incremental model- advantages, disadvantages and when to use it?

In incremental model the whole requirement is divided into various builds. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle.  Cycles are divided up into smaller, more easily managed modules.  Each module passes through the requirements, design, implementation and testing phases. A working version of software is produced during the first module, so you have working software early on during the software life cycle. Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved.

For example:

In the diagram above when we work incrementally we are adding piece by piece but expect that each piece is fully finished. Thus keep on adding the pieces until it’s complete. As in the image above a person has thought of the application. Then he started building it and in the first iteration the first module of the application or product is totally ready and can be demoed to the customers. Likewise in the second iteration the other module is ready and integrated with the first module. Similarly, in the third iteration the whole product is ready and integrated. Hence, the product got ready step by step.

Diagram of Incremental model:

Advantages of Incremental model:

§  Generates working software quickly and early during the software life cycle.

§  This model is more flexible – less costly to change scope and requirements.

§  It is easier to test and debug during a smaller iteration.

§  In this model customer can respond to each built.

§  Lowers initial delivery cost.

§  Easier to manage risk because risky pieces are identified and handled during it’d iteration.

Disadvantages of Incremental model:

§  Needs good planning and design.

§  Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.

§  Total cost is higher than waterfall.

When to use the Incremental model:

§  This model can be used when the requirements of the complete system are clearly defined and understood.

§  Major requirements must be defined; however, some details can evolve with time.

§  There is a need to get a product to the market early.

§  A new technology is being used

§  Resources with needed skill set are not available

§  There are some high risk features and goals.