Saturday, January 22, 2005

The Important Stages of the SDLC

Explain why the first phases of the Software Development Life Cycle (SDLC) are more important than the later steps. Reasons why they are and/or reasons why they are not.

Explain why the first phases of the SDLC are more important than the later steps.

Setting: Large company with deep pockets.

Why: The first three phases in the text is very important as it is the foundation upon which the project is based and are the most important. A great deal of leg work in preparation is required. It requires a great deal of time and effort to compile and analyze the project long before a single line of code is written.


STAGE 1 DETERMINATION OF SCOPE AND OBJECTIVES
I believe that this is self explanatory.

STAGE 2 SYSTEMS INVESTIGATION AND FEASIBILITY STUDY
This phase in the text is very weak in its explanation. It is basically a simple analysis "Do we think we have the resources, man powers and money to do this?" What assets can we utilization, sharing or do we need to acquisition of new capital hardware and/or expenses?

STAGE 3 SYSTEMS ANALYSIS
There are a lot of variation on what needs to do at this stage. I agree with what has been published about this phase, however it is not all inclusive. There are additional items that need to be look at during this phase.
  • Risk analysis: (to company, people, process)
  • Security Analysis (to company, people, process)
  • Impact Analysis (to company, people, process)
  • Regulatory Analysis (for company, people, process)
  • Company Policy Analysis (for company, people, process)
  • What are the Bench marks, water marks, goals achievement points (for company, people, process)

STAGE 4 SYSTEMS DESIGN
Wow, now we get to start writing code...


Reasons why they are and/or reasons why they are not.

As with anything situation dictates the need. The bottom-line is there is no magic bullet for all situations. The reading text SDLC theory is great for a large organization with really deep pockets and does a good job of keeping the giant wheel balanced.

For the small projects, a lot can be knocked out with simple evaluations of the situation, it's impact and gains. An elaborate SDLC is not required in many cases, and would be too costly for the smaller projects. The need for a structured development process should be used, but not in all cases.

Examples a user needs to convert data from one data source to another. This is a one time thing and will not be needed again. A quick assessment by the developer that it will only take about 8 hours to do the data conversion by writing a small program. The SDLC process would be too much over kill as one can quickly assess that all the above analysis is not needed.

So bigger projects SDLC is a good fit, but may require a bit of modification. SDLC for smaller projects can be skipped for the most part as the assessment can determined that the SDLC is not needed in its entire form.


Large Projects and the SDLC


This is a good example where Software Development Life Cycles (SDLC) is appropriate and needed. A very large project, being done over a very long time where lots of money, people and resources are required is a when the SDLC should be used.

However the larger the project it can be frustrating manage and coordinate. The more people added to the mix the more personality collide and defenders of territory come into play. SDLC would help guide the project, but it does create an unavoidable human element of frustration with other groups, areas, vendors, consultants or departments.

This is not a project that I would recommend go without some type of SDLC process.

CYA: If a formal SDLC is not in place, the initial formation of a SDLC could meet resistance from the existing management structure and org chart. The initial formation can be stifled by politics and personal agendas. After it is established and everyone understand the process then Ray is correct. It aids in damping the effects of politics.

This is a good concept for vendor to customer relationship and maybe in some business organizations, however this will not work in all cases. Every large company has different polices and procedures. It is more difficult to be creative and to correct a known customer requested design flaw with this method. It also greatly extents the development cycle which is why SAP, Peoplesoft and other very large deployments take so long.

The level of detail and interpretation between the customer and vendor can be annoying. The steps of clarification by phases so the customer knows exactly what they got matches what they asked for can take time. That is not a billable process in some cases.

However it is a good tool to keep things in check. It is good where it is appropriate.

Friday, January 21, 2005

When Not to use the SDLC

Reasons and Examples why developers or support analysts would NOT want to use a FORMAL Software Development Life Cycle?

There are a number of reasons why a formal SDLC is not a good fit.

The following are contributing factors that directly affect the formation of the SDLC process, its structure and organization.

  • Logistics
  • Costs
  • Available Skill sets of people
  • Number of people in the project
  • Budget, Funding, Retainer or PO
  • Available tools (software, hardware, communications and connectivity)
  • Collaboration tools (software, hardware, remote access)
  • The utilization of the most current RAD tools
  • Leadership Skills
  • Team Developer Skills
  • End User process knowledge and skills
  • Time-Frame
  • Project "In-Demand" need
  • The personal motivations of all the people involved in the project
  • This is NOT and all inclusive list. There are many more factors too.

With each factor being a variable the SDLC structure as presented in the text does not allow for flexibility. A development process success is dependant upon many factors to include all parties being flexible to change as things change. The only constant in IT is change.

Areas of application development were SDLC is not a good fit are:

  • Proof of Concept Testing
  • Running a series of never before performed processes, functions or methods.
  • Running a series of combination tests to see what happens.
  • Running a series of tests to intentionally try to break the application process to examine for security and potential points of failure.
  • Running a series of unorthodox user tests to observe the reaction and behavior of untrained or unskilled users to trap for the unexpected use of the applications.
  • Experimentation
  • Developing algorithms to perform tasks that do not yet exist.
  • Refining existing methods and procedures for better performance and smaller footprint.
    Individual Projects
  • An individual user doing small utility development.
  • There are many more, but these are a few.

One might argue that these are individual components of the SDLC. Situation dictates the scale and perception of where and when the SDLC process begins and ends. The SDLC can be a used by single user or by a massive army of developers. In the development community the term SDLC is not used. Common terms that mean the same thing are process development, application development, team development and systems development. The life cycle part is a MBA buzz word.

SDLC can provide structure where chaos is, however if the SDLC is in acted as company Law it can actually impede, hinder and prevent creative application development.

Examples of where the SDLC was NOT used that resulted in creative and industry changing applications.

  • Compaq's original IBM compatible XT PC
  • The original Compaq system BIOS
  • The original Apple computer
  • Tim Berners-Lee development of HTML and the first Mozilla Browser
  • Shawn Fanning's development of Napster
  • The development of the original UNIX and DOS OS's
  • The original spreadsheet application
  • The original email application
  • I could go on and on....

So the moral here is for the carpenter to apply the right size hammer to the right size nail.


Using the Software Development Life Cycle

Why is a formal systems development process needed for developing IT systems? What are its advantages and how does it help prevent a systems development effort from failing? Give an example where you think it could help.


Why is a formal systems development process needed for developing IT systems?

A skilled leader and skilled teammates drive the development process. The theory in the text leads you to believe that the Software Development Life Cycle (SDLC) is the end all be all to development. That is simply not the case. The SDLC is a tool like a hammer. The carpenter is the one that uses the hammer to drive the nail. The hammer is useless without the skilled carpenter. Likewise the carpenter needs to know how to use the hammer. He also needs to understand that there are different hammers for different nails. If the hammer is too big, use a smaller one. If the hammer appears to not work, make one that will.


What are its advantages and how does it help prevent a systems development effort from failing?

The SDLC is a formal process and not a law, it is a guide that should be modified for the need. The SDLC is a process that was developed after many failed or inefficient attempts at success. The SDLC is to provide a better way of doing things, but is not the only way to do process development.


Give an example where you think it could help.

Since SDLC is not part of the three worlds largest software developers vocabulary, I would think that the Longhorn development team at Microsoft could use a skilled carpenter with a big hammer. If they continue to chop off major portions of the proposed product from 4 years ago, then there will not be much of a product left to use.