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…

 

My Reading List For 2017

Reading list
That’s not me of course
Every year towards my birthday I review my previous year to check how far I’ve gone with respect to my goals and plans.
I also take time to create reading list for the year ahead.
Today i would share some of the books that i will be devouring in 2017.
The books that interest me usually have to do with computer science,leadership and of course my faith which is Christianity.
I will focus on computer science or programming.

Computer Science/Programming

Algorithms
Introduction to algorithms

1.Introduction to algorithms

This is my all time favourite book,when it comes to the study of algorithms and data structures.
I am a huge fan of algorithms and data structures,for any beginning programmer i will recommend this book anytime as it covers the basics of algorithms and which are very important in programming and distinguish between a good software developer and a great developer

2.Clean Code:A Handbook of Agile Software Craftsmanship

That’s another book i have read a couple of times.It keeps me grounded on how to construct software.
I am a huge fan of Robert C.Martin,i would pick up any book by him.

3.Clean Architecture: A Craftsman’s Guide to Software Structure and Design

Another book by Robert C.Martin,I’m sure it will be a great read.Its due to be released later during the year.

4.Soft Skills: The software developer’s life manual

Every developer needs soft skills,that is one area where most developers struggle.
Somnez covers that aspect of a developer in great detail.
I have been following John’s blog for some time now,so i trust that his book will be a good read.

5.Code Complete: A Practical Handbook of Software Construction

 

That’s my reading list for 2017,if you want me to share my whole list on other categories just leave comments in the comments section.
keep coding!!

Dependency Inversion Principle(DIP)

Dependency Inversion Principle(DIP)

What Is Dependency Inversion Principle(DIP)?

In object-oriented design, the dependency inversion principle(DIP) refers to a specific form of decoupling software modules.
Dependency Inversion Principle or DIP has two key points:
1.Abstractions should not depend upon details;
2.Details should depend upon abstractions.
The principle could be rephrased as use the same level of abstraction at a given level. Interfaces should depend on other interfaces. Don’t add concrete classes to method signatures of an interface. However, use interfaces in your class methods.

Simple Example Of Dependency Inversion Principle

Consider the case of the Button object and the Door object.
The Button object senses the external environment. On receiving the Poll message, the Button object determines whether a user has “pressed” it. It doesn’t matter what the sensing mechanism is.
It could be a button icon on a GUI, a physical button being pressed by a human finger, or even a motion detector in a home security system. The Button object detects that a user has either activated or deactivated it.
The Door object affects the external environment. On receiving a TurnOn message, the Door object opens the door. On receiving a Close message, it closes that door.
How can we design a system such that the Button object controls the Door object?  The Button object receives Poll messages, determines whether the button has been pressed, and then simply sends the Open or Close message to the Door.

Consider the C# code implied by this model (above). Note that the Button class depends directly on the Door class. This dependency implies that Button will be affected by changes to Door. Moreover, it will not be possible to reuse Button to control a Motor object. In this model, Button objects control Door objects and only Door objects.

public class Button  
{  
private Door door;  
public void Poll()  
{  
if (/*some condition*/)  
door.Open();  
}  
}  
The above solution violates DIP.The abstractions have not been separated from the details.Without such a separation, the high-level policy automatically depends on the low-level modules, and the abstractions automatically depend on the details.

Finding the Underlying Abstraction

What is the high-level policy? It is the abstraction that underlies the application, the truths that do not vary when the details are changed. It is the system inside the systemit is the metaphor. In the
Button/Door example, the underlying abstraction is to detect an open/close gesture from a user and relay that gesture to a target object.
What mechanism is used to detect the user gesture? Irrelevant! What is the target object? Irrelevant!
These are details that do not impact the abstraction.
The model in above can be improved by inverting the dependency upon the Lamp object. In model below, we see that the Button now holds an association to something called a ButtonServer,which provides the interfaces that Button can use to turn something on or off. Door implements the ButtonServer interface.
Thus, Door is now doing the depending rather than being depended on.
The design above allows a Button to control any device that is willing to implement the ButtonServer interface. This gives us a great deal of flexibility. It also means that Button objects will be able to control objects that have not yet been invented.
However, this solution also puts a constraint on any object that needs to be controlled by a Button.
Such an object must implement the ButtonServer interface. This is unfortunate, because these objects may also want to be controlled by a Switch object or some kind of object other than a Button.
By inverting the direction of the dependency and making the Door do the depending instead of being depended on, we have made Door depend on a different detail: Button. Or have we?
Door certainly depends on ButtonServer, but ButtonServer does not depend on Button. Any kind of object that knows how to manipulate the ButtonServer interface will be able to control a Door .
Thus,the dependency is in name only. And we can fix that by changing the name of ButtonServer to something a bit more generic, such as SwitchableDevice. We can also ensure that Button and SwitchableDevice are kept in separate libraries, so that the use of SwitchableDevice does not imply the use of Button.
In this case, nobody owns the interface. We have the interesting situation whereby the interface can be used by lots of different clients, and implemented by lots of different servers. Thus, the interface needs to stand alone without belonging to either group. In C#, we would put it in a separate namespace and library.
Further Reading

1.Agile Software Development, Principles, Patterns, and Practices By Robert C.Martin

2. Head First Design Patterns by Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bert, Bates

3.Object Solutions: Managing the Object-Oriented Project by Grady Booch,

Liskov Substitution Principle

If you’ve been following my blog,you’ll know that we have been covering the SOLID Principles,in my previous posts i covered The Single Responsibility Principle,the “S” in the SOLID Acronym,then we covered The Open Closed Principle,today  my focus will be on The Liskov Substitution Principle,the “L” in the SOLID Principles acronym.

What is LSP?

This principle is credited to Barbara Liskov,she wrote this principle in 1988 and she said:

“What is wanted here is something like the following substitution property: If for each object o1
of type S there is an object o2 of type T such that for all programs P defined in terms of T, the
behaviour of P is unchanged when o1 is substituted for o2 then S is a sub-type of T.”

In simple terms the above statement means:

“Subtypes must be substitutable for their base types.”

or more simply:

“It means that we must make sure that new derived classes are extending the base classes without changing their behaviour” 

A Simple Example Using C#

We’ll use the classic Rectangle-Square problem to demonstrate this principle. Let’s imagine that we need to find the area of any rectangle.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace SOLIDPrinciplesDemo
{
// If any module is using a Base class then the reference to that Base class can be replaced with a Derived class without affecting the functionality of the module.
// Or
// While implementing derived classes, one needs to ensure that, derived classes just extend the functionality of base classes without replacing the functionality of base classes.
class Rectangle
{
 protected int mWidth = 0 ;
 protected int mHeight = 0;
public virtual void SetWidth(int width)
{
mWidth = width;
}
public virtual void SetHeight(int height)
{
mHeight = height;
}
public virtual int GetArea()
{
  return mWidth * mHeight;
}
}
// While implementing derived class if one replaces the functionality of base class then,
// it might result into undesired side effects when such derived classes are used in existing program modules.
class Square : Rectangle
{
// This class modifies the base class functionality instead of extending the base class functionality
// Now below methods implementation will impact base class functionality.
public override void SetWidth(int width)
{
mWidth = width;
mHeight = width;
}
public override void SetHeight(int height)
{
mWidth = height;
mHeight = height;
}
}
class LiskovSubstitutionPrincipleDemo
{
private static Rectangle CreateInstance()
{
// As per Liskov Substitution Principle "Derived types must be completely substitutable for their base types".
  bool SomeCondition = false;
if (SomeCondition == true)
{
  return new Rectangle();
}
else
{
  return new Square();
}
}
public static void LSPDemo()
{
Console.WriteLine("\n\nLiskov Substitution Principle Demo ");
Rectangle RectangleObject = CreateInstance();
// User assumes that RectangleObject is a rectangle and (s)he is able to set the width and height as for the base class
RectangleObject.SetWidth(5);
RectangleObject.SetHeight(10);
// Now this results into the area 100 (10 * 10 ) instead of 50 (10 * 5).
Console.WriteLine("Liskov Substitution Principle has been violated and returned wrong result : " + RectangleObject.GetArea());
// So once again I repeat that sub classes should extend the functionality, sub classes functionality should not impact base class functionality.
}
}
}

I know the example above doesn’t exhaust the LSP principle,but im sure it gave you an idea what the principle stands for.

Benefits

This principle aims to keep functionality intact. The main purpose is to guarantee that objects lower in a relational hierarchy can be treated as though they are objects higher in the hierarchy. Basically, any child class should be able to do anything the parent can do.

Further Reading

1.Data Abstraction and Hierarchy,” Barbara Liskov, SIGPLAN Notices, 23(5) (May 1988)

2.Bertrand Meyer, Object-Oriented Software Construction, 2d. ed., Prentice Hall, 1997

3.Rebecca Wirfs-Brock et al. , Designing Object-Oriented Software, Prentice Hall,
1990.

4.Agile.Principles.Patterns.and Practices.In.C#[Robert.C.Martin]

That’s it for this week,next i will be covering Interface Segregation Principle(ISP),the letter “I” in the SOLID acronym.

****Happy Holidays and be safe****