Friday, January 28, 2005

Prototyping Methodology

Prototyping is one modern method of development. The first Apple computer was developed in the manner in 1976/77 by Steve Wozniak in Steve Job's garage with off the self parts in a wooden case.

Compared to SDLC:
This method is less structured, planned organized than the SDLC (Software Development Life Cycle). It is often off the hip last min assembly, testing or development. It is more or less for a smaller project often done as a proof of concept to test ideas, processes and systems before committing vast about of resources to a larger project.

A recent advancement in a fairly med size project in prototyping and testing unproven methods and ideas would be SpaceShipOne http://www.xprize.com/ with it's historical flight into space. It tested light weight materials, new engine designs, new methods of a control re-entry without heat shielding, new wind breaking systems, new computer systems and how it performs when the computers systems fails. Lastly it proved that space flight is not limited to government dollars and budgets. It's flight is in comparison to the first Apple computer as prototyping and leading to new production systems changing the world in the process.

Advantages:
It allows for more creativity and possibly new world changing solutions could be developed, where they might be hindered on the SDLC's control process.

Disadvantages:
In prototyping scope creep, cost over runs, miss management, and lack of focus are more likely to occur in this type of project. SpaceShipOne is a good example. It required Paul Allan and Virgin Records additional funding to complete the project. The total cost of the mission was 20 million dollars and the X-Prize was only 10 million dollars. While they did go over budget, I should point out it was one of the cheapest space flights in history, using less than 10% of the budget of a simple satellite launch that is not a manned flight.

While I am sure that SpaceShipOne had some type of development plan, prototyping can include a whole host of unknown variables that can not be determined until testing has been completed.

Prototyping is not a best practice method for getting your project completed, but it does have a place in developing something new.

Thursday, January 27, 2005

Analysis Phase of the SDLC

Valuable/important to the Analysis Phase of the SDLC

All the items that are listed could have some impact on the SDLC (Software Development Life Cycle), depending upon what type of information they contained. I use all the items all the time. However one should note that the information contained in each of the ones listed may be dated, obsolete or incorrect. Having to choose one I choose the Data Flow Diagrams.
Although systems flowcharts provide a useful tool for analyzing a physical description they may impede the design process.


Why is it so valuable?
It is the heart of the system design. It gives the design and flow of data across many systems, databases and sites.
  • Identifies the major processes.
  • Identifies the major data sources, sinks and stores.
  • Identifies the major data flows.
  • Names the data flows, processes, sources, sinks and stores.

What information does it contain?
It shows all the pathways and connects to the varies systems, and databases. It would give the overall concept and configurations of the systems. It can also be data flows at varies levels of detail. It can be an overall view, then drilling down to a nuts and bolts view of great detail.

Data flow diagrams assist in building a logical model of the system independent of physical commitments. They show the various flows of data between the processes that transform it. Data stores and the points at which data enters and leaves a system are also shown.


How does it move the Analysis Phase forward?
It provides a place where to start looking first to begin your analysis. It would give you a base line to compare your findings, and prepare a number of questions. It is the base line data design that strip away the hardware layer and focuses more on the logic design and can allow for a clear understanding of the process. It could even make it possible to see new ways to improve the design. It's layering allows for the scaling of ideas, sections and data flows to different degrees of detail.

The data flow design is an important tool of structured analysis and design. It ensures that a top-down approach is taken. This promotes a logical, as opposed to physical, view of data stores, flows and processes.

Learning from Failure

Having worked in IT for many years, I have seen a lot of failure. I do not consider failure as being a bad thing. In IT in many cases it can be a good thing. Sometimes when things go very wrong, initially no one may know what is the cause of a problem. A series of failures can be like bread crumbs leading to the real problem. Being a good sleuth to read, understand and interpret the failures as to what are they telling us, leading us, or NOT telling us is just as important.

Having a problem and having no failures to help guide you to a successful resolution can take a lot of time and resources. It can be very frustrating just trying to identify the root cause of a problem.

So I embrace failure as a key to solving the root of a problem.

Wednesday, January 26, 2005

Qualify the Project

One of the very first questions that should get asked right up front is "Who is paying for the project?".

If this is an internal project then it may be a special budget, or a specific department or multiple budgets or departments.

If it is a customer external to the organization it is best to qualify them to see if they are willing to pay x dollars for projects and check their payment history.

The last thing you want to do is a lot of leg work only to find out the customer never had any intention of buying or they did not realize the scope of the project that they were asking for or there is no budget or funding for the project.

Tuesday, January 25, 2005

What's in a Title for System Analyst?

You may find when working for a very large company that a system analyst maybe a generic title/term associated with a pay grade. However your title being a system analyst you may be limited to a certain area in a certain department.

I have two real world examples:

Employee A & B works for the worlds largest drug company. His & Her title(s) are both systems analyst and they both have the same pay grade within the company. Both work in the MIS Group. Employee A works as a Lotus Notes Administrator. Employee B works as a Java Developer. Neither do what is described in the text as a systems analyst.

Employee X & Y works for the worlds largest bank. Both are systems analysts and have the same pay grade. One is a network engineer and the other builds servers for the enterprise.

Neither of these big companies follow what a systems analyst description is. So when applying for a systems analyst job, make sure you understand the duties and responsibility of a systems analyst are for that job.

I am not trying to confuse what a systems analyst is. I am just trying to make you aware of a potential surprise.

Improving Your SDLC

I am sure that you will find that the US bugs are much different that the Belgium bugs!!! I found out the hard way with my own database development project.

When we first started beta testing of the application we had a Canadian company that makes plastic parts for cars that was Japanese own/run company call us to be a beta test site. So we went there and installed the application on site with the customer, as we were still a year away from a production version, but they really wanted to beta test it anyway. Then we went to enter their data into our system. We could not get their data into the application. We could not completely fill out and use the contact information for employees, vendors and their customers. We use this information throughout the program to prevent having to re-enter the data and save time on data entry.

Why? Silly me I used the Microsoft wizards to set the format masking on the fields for currency, phone numbers and zip codes. Well duh! Canada does NOT use the same formats. So it was cripple before we started. That night in the hotel I had to edit over a hundred places and strip out all field format masking to allow for Canadian formats so they could use the application.

Since then we have had an equal response from overseas test sites that I had to make allowances for more localization and date formats. We never thought we would get the response we have from over seas. We even worked with the local University in Costa Rica to allow for special characters and assistance with translation into Spanish for a major drug manufacturing company that makes plastic parts. We had only envisioned the good ole USA.

We did NOT make the connection or observation that US companies would also have plants in other countries. So the moral here is our version of the SDLC did not include or consider localization issues for other countries.

Monday, January 24, 2005

Not Using the SDLC

What if there is a small company that does not believe in the SDLC process?? Does this mean they will fail as a company???

Of course not! As with all things, there are several ways to do the same thing. A small business method could not follow the SDLC at all, but upon closer examination it might have traces of the SDLC process and they do not even know they are using it regardless of their belief.

When your home computer is broken and/or you want to upgrade it, you take it to your favorite computer store or you do it yourself. This meets the definition of a project.

http://dictionary.reference.com/search?r=67&q=project

Does a simple repair or upgrade require an elaborate SDLC? ...for the most part no. It is reasonable and manageable to do it without SDLC.

Now lets scale this a bit. Lets say you have 5 computers that need service. Would you need a SDLC? ...for the most part no, because the number of devices and the complexity are still minimized.

Ok, lets scale this a little more. Lets say you have 35 computers to upgrade. Would you need a SDLC. ...yes and no. I would highly recommend that you come up with an action plan and costs before taking on such a project both for your sake and the customers.

Finally let really scale this up. Lets say you now have 10,000 computers to upgrade. Would you need a SDLC. Absolutely yes There are too many devices and too many variables that not having a SDLC could result is a huge disaster and be very costly. Then everything that is being taught in the lecture and text are applicable to a very high degree, and yes you had better have your CYA component in place.

Sunday, January 23, 2005

Systems Analyst

What are the attributes/skills of an effective Systems Analyst?

Attributes:
  • Analytical skills: The ability to understand the organization and its functions, to identify opportunities and problems, and to analyze and solve problems.
  • Technical skills: The ability to understand the potential and the limitations of information technology.
  • Management skills: The ability to manage projects, resources, risk, and change.
  • Interpersonal skills: The ability to work with end-users, other analysts and programmers. You must also act as the liaison between users, programmers, and other systems professionals.
  • Additional skills not listed in the lecture or the reading text that are a must are self discipline, the ability to work alone without direction and a healthy dose of problem solving skills. These can apply and enhance the four skills listed above.


Two ways a person can develop those attributes/skills.

Skill development is a life long process that is never ending. We are all imperfect and have areas that could use refinement, and enhancement. The moment you stop developing your skills is the moment that you could handicap yourself in certain areas.

First you must poses the desire for self improvement.

Second you must poses persistence. You must be determined to get backup on your feet after you have been knocked on the ground. Dust your self off and resume professionally your task at hand. Without persistence your desire can be squash by unforeseen events.

Next is simply do. Practice, Practice, Practice, Practice!

Next, do not fear failure. Embrace it and use it as a learning tool to achieve success. Learning from ones mistakes can lead to huge rewards in the future. Also learning from others failures is just as important.


Developing your Systems Analyst skills in your working environment.

There is opportunity of every moment of every day where one has the opportunity to develop their skills. Even though I have been out of traditional school for a very long time. I have never stopped learning, practicing and enhancing my skills. Sometimes it is easy; sometime it is hard. Sometimes it is very successful; sometimes it is a failure.

I was once told that you fail 100% of the time you do not try. This is something that I always keep in the back of my mind when evaluating my next move.

Scale usage of the SDLC

What if there is a small company that does not believe in the SDLC process? Does this mean they will fail as a company??

Of course not! As with all things, there are several ways to do the same thing. A small business method could not follow the SDLC (Software Development Life Cycle) at all, but upon closer examination it might have traces of the SDLC process and they do not even know they are using it regardless of their belief.

When your home computer is broken and/or you want to upgrade it, you take it to your favorite computer store or you do it yourself. This meets the definition of a project.

http://dictionary.reference.com/search?r=67&q=project

Does a simple repair or upgrade require an elaborate SDLC? ...for the most part no. It is reasonable and manageable to do it without SDLC.

The scale usage of SDLC:
  • BIG: Use SDLC in all it's glory for big business and big projects, but not as company LAW.
  • MEDIUM: Use a scaled down version(s) of SDLC for medium size business and projects.
  • SMALL: Use a checklist type format and/or quick evals without all the massive detail of a formal SDLC.
  • REALLY SMALL: For really small projects and small business hardly any SDLC at all is needed.
Now lets scale this a bit. Lets say you have 5 computers that need service. Would you need a SDLC? ...for the most part no, because the number of devices and the complexity are still minimized.

Ok, lets scale this a little more. Lets say you have 35 computers to upgrade. Would you need a SDLC. ...yes and no. I would highly recommend that you come up with an action plan and costs before taking on such a project both for your sake and the customers.

Finally let really scale this up. Lets say you now have 10,000 computers to upgrade. Would you need a SDLC. Absolutely yes There are too many devices and too many variables that not having a SDLC could result is a huge disaster and be very costly. Then everything that is being taught in the lecture and text are applicable to a very high degree, and yes you had better have your CYA component in place.

Small Business and SDLC

The SDLC (Software Development Life Cycle) is not as attractive to smaller business and projects. The business dynamics between the two are very much different in many ways. Small business and small projects are low budget and need to react quickly. Since the small budgets and business have very limited resources there is a great need to compress the timeframe and detail analysis. Since the smaller projects have less of an impact and do not cascade multiple sites and millions of dollars the risk analysis and assessments are much more limited and easier to scope. Therefore that teams and recourses would be a few people doing most all the work.

As a small business every moment of my time is tied to a billable resources in which I am accountable in order to pay the bills and put food on the table. The needs of volume and scope of work is not as great as an SAP type project. To attempt a full formal SDLC process would be too costly for both the customer and myself.

In the stages in the lecture where there is a lot of analysis prior to proceeding on the project, your company is paying the tab for the evaluation as both the developer and the customer. In my case we are separate and one is paying the other for the analysis. In your lecture everyone is getting paid as being part of the big organization. In my case I would have to create and estimate for each phase of the project and the customer would have to sign off at each phase and pay.

If I am asked to create a simple program or utility that would take me several hours as I do now. It would greatly increase the time and cost using a formal SDLC. So a $1,000 project without SDLC might cost the customer $6,000 with a formal SDLC. If the customer knows it may cost $6,000 for a small utility, then there may not be a project and that would be zero dollars earned. Do that 100 times a year and one would have made far less with the formal SDLC than compressing the scale of SDLC or none at all.

So profitably for the vendor and cost saving for the customer with working on a small project would be a definite reason NOT to follow a full formal SDLC.

The SDLC is a very delicate engine that requires a lot of fine tuning and self discipline to keep it on track and working. It can easily break down if all parties are not participating equally. In some cases they do not and you have to be flexible to compensate for the absence of their effort.

The SDLC is usually driven by management as they are the ultimate responsible person. That said having been a consulting analyst working for a large company you can be pigeon holed into just one area and not aloud to work in multiple areas at once or gain additional experience.

On a large scale project where there is a budget and people get paid no matter the outcome for a larger organization, I agree that SDLC should be used and have no argument with the text and your lecture in that respect.

So the moral here is use the right size hammer for the project.