SOFTWARE DEVELOPMENT LIFE CYCLE(SDLC) Pt 2

 

Feasibility study

This post is a continuation of my previous article.

2.Feasibility Study

Feasibility study is an assessment of the practicality of a proposed project or system. In simple terms, a feasibility study involves taking a judgment call on whether a project is doable. The  criteria to judge feasibility are cost required and value to be delivered.

A feasibility study evaluates the project’s potential for success. The perceived objectivity is an important factor in the credibility of the study for potential investors and lending institutions. [Source: Wikipedia]

There are some aspects that the feasibility study tackles that as developers we normally forget that they exist. One example is the legal implications of creating and deploying a system.

Five Areas of Project Feasibility:

  1. Technical Feasibility : Assessment is centered on the technical resources available to the organization. It helps organizations asses if the technical resources meet capacity and whether the technical team is capable of converting the ideas into working systems. Technical feasibility also involves evaluation of the hardware and the software requirements of the proposed system.
  2. Economic Feasibility  : It helps organizations assess the viability, cost, and benefits associated with projects before financial resources are allocated. It also serves as an independent project assessment, and enhances project credibility, as a result. It helps decision-makers determine the positive economic benefits to the organization that the proposed system will provide, and helps quantify them. This assessment typically involves a cost/ benefits analysis of the project.
  3. Legal Feasibility – investigates if the proposed system conflicts with legal requirements like data protection acts or social media laws.
  4. Operational Feasibility : It involves undertaking a study to analyze and determine whether your business needs can be fulfilled by using the proposed solution. It also measures how well the proposed system solves problems and takes advantage of the opportunities identified during scope definition. Operational feasibility studies also analyze how the project plan satisfies the requirements identified in the requirements analysis phase of system development. To ensure success, desired operational outcomes must inform and guide design and development. These include such design-dependent parameters such as reliability, maintainability, supportability, usability, disposability, sustainability, affordability, and others.
  5. Scheduling Feasibility  : It is the most important for project success. A project will fail if not completed on time. In scheduling feasibility, we estimate how much time the system will take to complete, and with our technical skills we need to estimate the period to complete the project using various methods of estimation.[Source: Simplilearn]

Benefits of Conducting a Feasibility Study

  1. Saves money on development hours that may be lost developing a product that may end up not making it to the market.
  2. Gives project teams more focus and provides an alternative outline.
  3. Narrows the business alternatives.
  4. Identifies a valid reason to undertake the project.
  5. Enhances the success rate by evaluating multiple parameters.
  6. Aids decision-making on the project.

Next will cover system analysis and design.

 

 

 

 

 

 

 

 

Software Development Life Cycle(SDLC)

Development-Life-Cycle2

What Is A Software Development Life Cycle (SDLC)?

The Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages in software engineering to develop the intended software product.A framework that describes the activities performed at each stage of a software development project.

SDLC has a series of steps to be followed to design and develop a software product efficiently. The framework includes the following steps:

  1. Requirements Gathering
  2. Feasibility study
  3. System analysis
  4. Software design
  5. Coding
  6. Testing
  7. Integration
  8. Implementation
  9. Operation and Maintenance
  10. Disposition

 

1.Requirements Gathering

Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. Requirements gathering sounds like common sense, but surprisingly, it’s an area that is given far too little attention.

Many projects start with the barest headline list of requirements, only to find later the customer’s needs have not been adequately understood.

*10 Rules for Successful Requirements Gathering

To be successful in requirements gathering and to give your project an increased likelihood of success, follow these rules:

  1. Don’t assume you know what the customer wants – always ask.
  2. Involve the users from the start.
  3. Define and agree on the scope of the project.
  4. Ensure that the requirements are SMART: Specific, Measurable, Agreed upon, Realistic and Time-based.
  5. Gain clarity if there is any doubt.
  6. Create a clear, concise and thorough requirements document and share it with the customer.
  7. Confirm your understanding of the requirements alongside the customer (play them back).
  8. Avoid talking technology or solutions until the requirements are fully understood.
  9. Get the requirements agreed with the stakeholders before the project starts.
  10. Create a prototype, if necessary, to confirm or refine the customer’s requirements.

Common Mistakes

Be careful to avoid making these mistakes:

  • Basing a solution on complex or cutting-edge technology and then discovering that it cannot easily be rolled out in the ‘real world’.
  • Not prioritizing the requirements, for example, ‘must have’, ‘should have’, ‘could have’ and ‘would have’ – known as the MoSCoW principle.
  • Insufficient consultation with real users and practitioners.
  • Solving the ‘problem’ before you know what the problem is.
  • Lacking a clear understanding and making assumptions rather than asking.

Requirements gathering is about creating a clear, concise and agreed set of customer requirements that allow you to provide what the customer wants.

To be continued…