Tutorial : Why do we need methods?

1.The author of the above article notes that “the development groups were isolated from one another - one group was doing analysis, one group was doing software design and a separate group was doing implementation”.
Why would this arrangement be a recipe for disaster?

When the development groups were isolated one another , how can they share information of part they do like analysis, software design, implementation . They cant connecting together how one group can discuss to other group . One group was doing analysis they have many idea to do project make it very interesting and unique but this group cant talk to group was doing software design that means group was doing analysis is useless because all of their ideas can't share to group doing software design , group was doing software design need find their own ideas to design software.And a group was doing implementation still need find their own ideas to completed project. I think if the development groups were isolated from one another, each group just do different project. One group unrelated to another they can completed project easier and less make mistake than when group were isolated from one another. The development groups were isolated from another this arrangement is really to be a recipe for disaster.

Tutorial: Why do we need methods?

2.    The author also quotes the Standish Report stating “the statistics demonstrate that the larger the budget and the bigger the team, the more likely the project is to fail. Nine out of ten large projects experience severe problems. With regard to software development projects, bigger is almost never better”.

 Why do you think that large projects with big budgets are more likely to fail?

Answer (XUAN TRUONG)

Large projects with big budgets are more likely to fail because of many reasons . Compare computer industry to other industry like bridge building . As you know all of the bridge building projects are large and in computer industry there are many large projects too . According the chaos report , bridges are normally built on time , on budget and do not fall down while software never comes on time , on budget and it always break down . If a bridge fall down , it's investigated and a report is written on cause of the failure . This is not so in the computer industry where failures are cover ignored, and as a result, we keep making the same mistakes over and over again .

Many report show that large project means the project is very complexity . Very complexity make more uncertainties . More Uncertainties make project is harder to estimate . Hard to estimate make low estimates . Low estimates lead cost overruns . And even if a large project has been launch, it still can be failure . Here is examples : 

Picture 1

Here is a illustrates the distribution of success and failure across project size : 

Picture 2

The large project fail much more than small and medium project . Why ? According the Gartner Survey , to know it we based on 6  causes of project failure :

1. Functionality issues
2. Substantially late
3. Quality issues
4. High cost variance
5. Canceled after launch
6. Rejected or not implemented for other reasons

Based on these causes we have illustrates the percentage of failures : 

Picture 3 

As we see , in functionality issues , the percentage of three project size is almost equivalent as other reason issues . In substantially late , large IT projects is higher than the other project because is large project , it take much more time to done and business conditions keep changing after the project scope has been set and it make the project time overruns . About high cost variance you can review picture 2 to for more examples . Poor quality of large IT projects is lower because large project cant develop with poor quality if u want it success . In canceled after launch , the percentage is lower because you can't launch a large project with many issues with function or time overruns especially the cost overruns . If large project fail , it fail during development.

The last problem is with big team , the large project still more likely to fail . Let take a look at an examples : In a develop team have 10 person , it's easy to see which developer needs help . In a team have 50 person , it's hard to see who needs help . In a team have 100 person , it's even harder . Even they memos their problems , u don't have enough time to help each person and it will cause your project time and cost overruns. So why don't we hired a small develop team to develop large project ? We don't do that because this may cause the developer have less responsibility with their work . One person have many work to do so they just finish their function or statement then work with the next function or statement with low quality even without testing . So that make project fail too.

Tutorial: Why do we need methods? (Nguyen Nang Chung & Nguyen Anh Tung)

3.    The author mentions both incremental development and iterative

development within the case study.

a.       Explain both of these terms

b.      Why would the approach taken to incremental and iterative development described in the case study contribute to the project failure?

 

3a. Explain both of these terms

1. Definition:  Iterative mean?

Iterative development is a methodology of software development that divides a project into many releases. The main idea of iterative development is to create small projects that have a well-defined scope and duration and constantly do builds and updates as soon as possible.

Diagram of Iterative model:

When to use iterative model:

§  Requirements of the complete system are clearly defined and understood.

§  When the project is big.

§  Major requirements must be defined; however, some details can evolve with time.

2. Definition:  Incremental mean?

Incremental model in software engineering is a one which combines the elements of waterfall model which are then applied in an iterative manner. It basically delivers a series of releases called increments which provide progressively more functionality for the client as each increment is delivered.

Diagram of Incremental model:

When to use the Incremental model:

§  This model can be used when the requirements of the complete system are clearly defined and understood.

§  Major requirements must be defined; however, some details can evolve with time.

§  There is a need to get a product to the market early.

§  A new technology is being used

§  Resources with needed skill set are not available

§  There are some high risk features and goals.

3b. Why would the approach taken to incremental and iterative development described in the case study contribute to the project failure?

In recent years, the failure of IT projects have received a lot of attention in the press and in the boardroom. Especially, the approach taken to incremental and iterative development described in the case study contribute to the project failure.

·         Firstly, The risk of failure of a software project can be due to the increase in complexity and difficulty of predicting how complex systems will behave. At that time, we will lose control of the change in the project, particularly as project requirements misinterpreted or some requests neglected.

·         Secondly, Although the major requirement has been identified; However, given the length of most software projects, the requirements will have changed over time and could well change numerous times during a project lifespan. Therefore, the error rate increased sharply, rising at a much higher rate than the average rate at a certain stage, particularly in end-stage . With this condition, we will take a lot of time to fix bugs or rewrite code. At that time, we will lose control project progress, appear a mismatch and lack of uniformity between the project's progress and the report progress.

Tutorial: Why do we need methods?(Vuong Tan vs Hoang Tuan Long)

4.    The case study tells us that: “Testing appeared to be non-existent – developers tested their own code but not part of an integrated testing strategy”.

        Why is this flagged as a problem? What would be a more effective way of testing within a development environment?

Why is this flagged as a problem?

Answer(Hoang Tuan Long)

The problem here is that the developers  only tested their own code and did not apply integration testing. They did unit testing on the individual module they were working on which is fine, but they completely failed when not even locally integrating all of those individual modules to test as a group or as the whole system.

A typical software project consists of multiple software modules, coded by different programmers. Integration testing focuses on checking data communication amongst these modules. So, the biggest defect of system modules experiencing unit testing but not integration testing is that we only know the single module works on its own but we don’t know if all modules work well and error-free with each other.

For example, assume that we have a bank simulation application which already has 2 different modules: Current Balance and Transfer. Each module woks fine separately. However, when it comes to the integration of Current Balance module to Transfer, the whole thing might not work at all. You may have 1000 dollars displayed nicely in Current Balance module, you navigate to the Transfer module to transfer 500 dollar to another account. Now you navigate back to the Current Balance module expecting that the latest balance should be 500 by now but actually it is not. The money is already transferred and updated into the database but somehow it does not show right away in the Current Balance module and maybe with a page refresh the new balance is now correctly shown. That's the error we need to fix and that's why we need integrated testing strategy.

        What would be a more effective way of testing within a development environment?

        Answer(Vuong Tan)

The more effective way of testing would be Agile testing. Agile testing is a software testing practice that is dependent on Agile principles. In Agile development, testing is not a separate stage, it is integrated into the development; so it is the integral part of core software development and participates through out coding process. An Agile team must have Testers. Testing occurs continuously in real time, so testers must always be there in the team working, testing the system, and collaborating actively with the development team to notify them of any identified issues by documentation. Testing and coding are done incrementally and iteratively, building up each feature until it provides enough value to release to the complete final product.

Advantages of agile testing would be:

·         Better communication: 
Since testers and developers work on the same team, they can more easily communicate with each other. Also, Testing requirements are discussed and refined as a team allowing the whole team to better address the business/technical aspects of the requirement.

·         Defects are easy to fix: 
Because the testers work with the developers on the same team, they are able to give almost immediate feedback which lets the developer fix the bug while the code is still fresh in his mind.

·         Flexible to requirement changes: 
Changes to requirement means changes to test cases. However, agile limit the development team to short sprints letting the team focus on completing a small set of features. The contents of the next sprint, however, are entirely up for discuss. That includes adding new, unplanned features and modifying already existing ones if that is what is best. So the whole system is very flexible for testing.

Tutorial 1 - Gall's Basic Systems Axioms (Nguyen Quang Hiep)

26.The larger the system, the greater the possibility of unexpected failure

        When we want make the large system,we can easy make mistake and stuck in trouble .The system can easy unexpected failure. When we are doing build the large system, we need focus each part of the large system. It helping we can control the large system and prevent make mistake. Build the large system very hard. It requires we need a lot of time for testing work process of the system and fixing some error dangerous for the system.

        Opposed to build the large system. When we build small system, we can easy focus and need less time to testing work process and fixing some error of the system. the possibility of unexpected failure will less then when we build large system.Also when we build the larger the system will get greater the possibility of unexpected failure.

Tutorial 1 - Gall's Basic Systems Axioms (TRAN XUAN TRUONG)

2. New systems generate new problems
Answer (XUAN TRUONG)

As we know , a new system will eliminate more problems than it generates but we don't know that when you create a new system or renew a system, they generate many more problems . In our university , each term we have to do a big project. All requirements of system is in a document our teacher sends us . First we think if we just follow the requirements and we could do it easily but when we start to work on it , many problems appear and if u don't have many experiences, you will face some problems like functions written wrong , the wrong queries database, etc ... It will take a lot of time to solve it.Even when you solve all of them and begin to test the system , there are still many more new problems. Then u can't fix all that problems , u decide to renew your system , u hope it will eliminate all problems of your system but in fact is worse than the old system like how to change this function to be suitable for new system and many problems appear and take u a lot of time to fix it again . That just a example , in fact there are many factors can cause your system's failure when u build a new system.

Tutorial 1 - Gall's Basic Systems Axioms (VUONG TAN)

23. A complex system can fail in an infinite number of ways

Answer (Vuong Tan)

The word ‘infinite’ here does not really mean infinite, it is a exaggeration, but it still makes sense because complex systems tend to show a big number of failures in different number of ways. Complex systems includes many parts and those parts interact with each other, and these interactions can cause unexpected problems. There are only few ways for a system to properly operate and perform the few core functions it is designed for. For example, a calculator system is designed to solve the calculating problems like addition, substraction, multiplication and division and this system only has few ways to do handle those above operations because there are only few limited ways to do that in mathematics. In constrast, there are thousand ways to fail this system, some of which might be: input an alphabetic character, input nothing at all, input spaces only, input  a very long paragraph... 

The above calculator system is only a simple system, but it still has to face many ways of failure. Thus, the number of ways of failure becomes very huge, maybe close to infinite when it comes to complex systems.

Tutorial 1 - Gall's Basic Systems Axioms (Nguyen Nang Chung)

13.     A simple system may or may not work 

Modern operating systems are increasingly complex and require a large number of individual subsystems and procedures, operators also must cooperate to make them function. Not only a complex system fail or happen errors but also the simple system may or may not work.As you know all systems can fail in an infinite number of ways, but they can work in only a few ways. In other words, the success rate is not high.If you can’t guarantee success and do not prepare for any situation can be happened,  then the best you can do is try to improve the odds. The most effective way to do so is to follow the old principle (Keep It Simple, Stupid).

For example : When you had a simple assignment or simple project, but you underestimated the project and consider it very simple.After that you've subjective and worked with that thought. Unluckily, your software happened a lot of problems. It didn’t work.Which means it is not all guarantee that all simple software must work.

Tutorial 1 - Gall's Basic Systems Axioms (Hoang Tuan Long)

16. A complex system designed from scratch never works and cannot be patched up to make it work; you have to start over, beginning with a working simple system.

Answer(Hoang Tuan Long)

Building a big complicated system from scratch and expecting it to work flawlessly is like an impossible misson, which forces you to start from a working simple system first. It’s like you cannot make a good working car if you have not owned a working start engine which is a smaller and simpler component of any car first. Maybe the start engine doesn’t work but you have to try to fix it into working mode in order to move on to work on other smaller and simpler components which are essential to a working car and one more time you work hard and carefully to make them perfect, make them work. That’s the shortest path of success, otherwise  you end up having no working car at all.

Let us take a look at  an IT example. Let’s say the most popular search engine over the world – Google. Google search engine has evolved over the years with many extra features added for searching optimization. When first started, Google used the algorithm called “PageRank”  to rank websites in their search engine results and also used many other different options for customized search such as exclusion, alternatives and wildcards, all of which use Boolean operators. They worked well with each other. However, it is the story of the last decade; search demands of today are shown to be a lot more challenging.  Regardless of how challenging as it is, Google already had a good working system to base on, they only needed to extend from there. In 2013, they put a new search algorithm called Hummingbird to use. One of Google people said: “The old search engine might focus on finding matches for words — finding a page that says “buy” and “iPhone 5s” from the query  “What’s the closest place to buy the iPhone 5s to my home?” Hummingbird should better focus on the meaning behind the words. It may better understand the actual location of your home, if you’ve shared that with Google. It might understand that “place” means you want an actual store. It might get that “iPhone 5s” is a particular type of electronic device carried by certain stores. Knowing all these meanings may help Google go beyond just finding pages with matching words”.

Tutorial 1 - Gall's Basic Systems Axioms (Nguyen Anh Tung)

15. “A complex system that works is invariably found to have evolved from a simple system that worked.” - John Gall

Answer (Nguyen Anh Tung)

I think this is a very correct opinion and profound implications in the life of each of us. Whenever we want to achieve big goals, long-term nature, is in the beginning we must outline panorama at the time we succeed. When we want to do anything, we have to do from the most simple things. We cannot create complexity at the beginning.

We should set specific goals, from the best simple, easily to perform to the more complex goal, more difficult. When we have specific targets, all that's left to do is to try to complete the job in the best way. 

In short, when you start to think big, please do from the small things. These small changes will bring us great success in an unexpected way that we do not anticipate. 

Messers Porter and Brewer hit the nail on the head: "Our brains can handle complexity, but they crave simplicity"