Balendin Software Solutions, has a well defined software development approach and has a value proposition that includes faster turnaround times, trained pool of engineers with decent exposure to processes and best practices followed for the entire SDLC.

• Requirements: This defines needed information, function, behavior, performance and interfaces.
• Design: Data structures, software architecture, interface representations, algorithmic details.
• Implementation: source code, database, user documentation, testing.
• Test
• Installation
• Maintenance

• Easy to understand, easy-to-use.
• Provides structure to inexperienced staff
• Milestones are better understood
• Sets requirements stability
• • Good for management control (plan, staff, track)
• • Works well when quality is more important than cost or schedule.

• Requirements are well-known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform

A variant of the waterfall that emphasizes the verification and validation of the product Testing of the product is planned in parallel with a corresponding phase of development.

Project and requirements planning – allocate resources Product Requirements and specification analysis – complete specification of Software System Architecture or hi-level design – defines how software functions fulfill the design Detailed Design - Develop algorithms for each architectural development Production, Operation and maintenance – provide for enhancements and corrections System and Acceptance Testing – check the entire Software System in its environment. Integration and Testing – check that modules interconnect correctly

Coding – transform algorithms into software

Strengths

• Emphasize planning for verification and validation of the product in early stages of product development
• Each deliverable must be testable
• Project management can track projects by milestones
• Easy to use.

When To Use?

• Excellent choice for systems requiring high reliability – eg. Hospital patient control applications
• All requirements are known upfront
• When it can be modified to handle changing environments beyond analysis phase
• Solution and technology are known

Structured Evolutionary Prototyping Model

Description

• Developers build a prototype during the requirement phase
• Prototype is evaluated by end users
• Users give correct feedback
• Developers further refine the prototype
• When the user is satisfied, the prototype code is brought up to the standards needed for a final product.

Steps

• A preliminary project plan is developed
• A partial high-level paper model is created
• The model is source of a partial requirements specification
• A prototype is built with basic and critical attributes
• The designer builds the database, user interface, algorithmic functions
• The designer demonstrates the prototype, the user evaluates for problems and suggests improvements
• This loop continues until the user is satisfied

Strengths

• Customers can “see” the system requirements as they are being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates awareness of additional needed functionality

When To Use?

• Requirements are unstable or have to be clarified
• Develop user interfaces
• Short-lived demonstrations
• New, original development

• Construct a partial implementation of a total system
• Then slowly add increased functionality
• The incremental model prioritizes requirements of the system and then implements them in groups.
• Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

Strengths

• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced

When To Use?

• Risk, funding, schedule, program complexity, or need for early realization of benefits.
• Most of the requirements are known up-front but are expected to evolve over time
• A need to get basic functionality to the market early
• On projects which have lengthy development schedules
• On a project with new technology

Spiral SDLC Model

• Adds risk analysis, and 4gl RAD prototyping to the waterfall model
• Each cycle involves the same sequence of steps as the waterfall process model

Steps

Determine objectives, alternatives and constraints

• Objectives: functionality, performance, hardware/software interface, critical success factors, etc.
• Alternatives: build, reuse, buy, sub-contract, etc.
• Constraints: cost, schedule, interface, etc.

Evaluate alternatives, identify and resolve risks

• Study alternatives relative to objectives and constraints
• Identify risks (lack of experience, new technology, tight schedules, poor process, etc.
• Resolve risks (evaluate if money could be lost by continuing system development

Develop next-level product
Typical activities

• Create a design
• Review design
• Develop code
• Inspect code
• Test product

• Develop project plan
• Develop configuration management plan
• Develop a test plan
• Develop an installation plan

Strengths

• Provides early indication of insurmountable risks, without much cost
• Users see the system early because of rapid prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently

• When creation of a prototype is appropriate
• 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

• Rapid Application Development (RAD)
• Scrum
  
  

When To Use Agile Methods?

• When it is difficult for a product manager to nail down all the requirements that a design team requires, the Agile model works best. This generally happens if you are working on a complicated solution. It might also happen for a very small solution where the requirements are not written on time with due diligence.
• Agile methodologies are very easily applied to projects that are user-interface driven.
• If your organization thrives in chaos (usually startups), and getting requirements is not easy, and you go from quarter to quarter, agile is an ideal model for you because it gets results faster and allows you have a product at all times.
• If you are using unknown technologies, an Agile approach allows you to lower down the risk of using these unknown technologies. It also allows you to review your designs with what was found about these technologies in the previous iteration.
  
  

Rapid Application Development (RAD) Method

Steps

• Requirements planning phase (a workshop utilizing structured discussion of business problems)
• User description phase – automated tools capture information from users
• Construction phase – productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”)
• Cutover phase - installation of the system, user acceptance testing and user training
  
  

Strengths

• Reduced cycle time and improved productivity with fewer people means lower costs
• Time-box approach mitigates cost and schedule risk
• Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs
• Focus moves from documentation to code (What you see is what you get).
• Uses modeling concepts to capture information about business, data, and processes.
  
  

When To Use?

• Reasonably well-known requirements
• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized
  
  

Scrum Development Method

Scrum is based on a "Sprint," which is generally a 30-day period for delivering a working part of the system. Each Sprint starts with a two to three-hour planning session that includes the customer (product owner), the facilitator (Scrum Master) and the cross-functional team. The customer describes the highest priority in the backlog, and after the team agrees on how much of it to do, it is left alone to do it. To keep the team synchronized, there is a 15-minute meeting every day. At the end of the Sprint, the results are delivered and reviewed, and the next Sprint is started.

Steps

• Education: Select those involved in the project rollout and if you have a project already selected, involve the business sponsor, business manager, and key business users.
• Project Definition / Selection: Once everyone is clear on the vision and direction, a project can get started. The project may have been identified sooner but how the project is chosen or what criteria was used needs to be understood. We need to make sure that risks at this level are addressed to help ensure success for both project and process. The criteria for selecting the project needs to include the solution’s level of complexity, visibility, resources, and integrations.
• Execute Project: Go through the project kickoff; explain the methodology, roles, responsibilities, timeline, deliverables, etc.; fairly standard project details and lay the scope from all project documents, thoughts, and discussions. Work on the backlog, feature negotiations, the sprints, scrum meetings, demos, etc. Once a sprint is done, do a retrospective and refine the processes for the next sprint and the next project. Once solution is in production, conduct a tuning sprint. This is a special sprint we do at AmbitSoft to ensure 100% adoption by implementing adoption boosting features and conducing both solution performance and platform tuning in the production environment.
• Perform Project Retrospective: Apply lessons learned to subsequent projects and refine other processes. Note that this process improvement will involve support staff and dynamics between project teams. One of the things we often encounter is that support organizations cannot move as fast as the project sprints and tend to delay Agile projects. Similarly, non-agile projects have a difficult time addressing the integrations with agile projects. As you execute your first project, you will find that you may need to bend or even break some rules to keep your project on track as defined by your time box. Therefore at the end of the project, you will need to work with support and other internal staff to establish new protocols or processes specific to Agile projects.
• Iterate the steps above: it is very necessary to educate everyone on the project on the company’s approach to Agile.
  
  

When To Use?
Scrum is most perfectly (easily) applied to scenarios with less number of product owners, and teams with common goals. However, It is relatively easy to scale scrum across multiple teams with multiple product owners too assuming they share common goals.