Information and Methods DSDM Atern (2) tutorial (Trần Xuân Trường)

2. A number of problems (4 in total) could have had a major impact upon the tight delivery deadlines. What were these problems? How did the project team use DSDM to help overcome these problems?

Answer :

According case-study, these problems are :

1. The diverse range of stakeholders presented major challenges.Not only were there 12 of them, drawn from both the public and the private sector, but they had very different ways of working and perceptions of risk.
2. The project was impacted by a major office move and complete change of team by one of the key project stakeholders around the time the system was due to go live.
3. Resistance to the ‘iterative’ and ‘appropriate level of rigour’ approach of DSDM for the project had to be overcome.
4. The requirements for a major part of the system were more complex than first thought and were changing as part of the review of the regulations.

As we know DSDM Atern principles 3 "Collaborate" encourages increased understanding, greater speed and shared ownership which enable teams to perform at a level that exceeds the sum of their parts. With problem 1, It's help the project team DSDM’s focus on collaboration, facilitation and stakeholder engagement helped ensure that everyone worked together and any issues were dealt with quickly.

With problem 2, the project team follow DSDM Atern principles 6 "Develop Iteratively" to help them to cope with changing requirements and personnel.Change is inevitable, It's allows for change and harnesses its benefits. Within the constraints of time and cost, change is actively encouraged in order to evolve the most appropriate solution. Atern uses iteration and constant review to make sure that what is being developed is what the business really needs.

The project team need to deliver the project on time however DSDM presented cultural difficulties for one of the key stakeholders, The project team intergrate DSDM Atern into an existing Prince2 Environment in order to help them to quickly establish or enable their own agile capability and overcome resistance to the ‘iterative’ and ‘appropriate level of rigour’ approach of DSDM for the project.

And final problem, The project team realised that the only sensible time for this to go live was 1st September, at the time only 3 months away. So with DSDM Atern principles 1 "Focus on the business need", it's help them to overriding project goal, which is to deliver what the business needs it to deliver, when it needs to be delivered by using MoSCoW prioritisation. Using this techniques it became clear that this functionality was a ‘should have’ rather than ‘must have’ for delivery and so was re-scheduled for the following year.

DSDM Atern – tutorial 1 (Trần Xuân Trường)

2. Principle 2: Deliver on time

In order to fulfil on-time delivery principle Atern teams need to : 

• ·         Use timebox approach
• ·         Focus on business priorities
• ·         Always hit deadlines.

Timeboxing the work of projects is a powerful practice which truly helps facilitate on-time delivery. A timebox is a fixed period of time at the end of which one or more deliverables have been completed. What we are focusing on here is the completion of deliverables by the exact deadlines and a timebox is only successfully achieved by then. Timeboxing takes advantages of iterative development approach as it breaks down the project into small fixed periods of time, usually two and four weeks which is a reasonable time span for development team to meet the objective of that timebox. Longer timeboxes, say 6 weeks, usually would cause the team to lose focus and it is logical and common sense that short timeboxes always push development team into hard working mode to fulfil the requirements agreed on at the beginning of the timebox.

On top of that, there is this Daily Standup part in all timeboxes in which development team together shares information on what each member has been doing to achieve the timebox’s objective and what he  will be doing till the next standup , as well as any problems he has been having that prevents him or the team from achieving the objective. Daily Standups would help identify problems earlier, so that the development team can fix them in early stage, save time and do not miss the deadlines.

DSDM pratice uses MoSCoW prioritisation for business priorities, which also help keep product deliveries on time.  As stated in the MoSCoW rules, the total effort invested in Must Haves should not above 60%, so it makes sure that development team can at least guarantee to deliver those Must Haves and present a usable product on time. Even if the team do both Must Haves and Should Haves, the total effort is still no more than 80%. We only use 80% of the development time to bring out a fine usable product, therefore we definitely deliver the product on time.

In conclustion, the combination of timeboxing and reasonable MoSCoW prioritisation allows the development team to predict the time of deliveries and always hit deadlines.

DSDM Atern – tutorial 1 (Nguyễn Quang Hiệp & Nguyễn Năng Chung)

Focus on the Business need

Explain what is meant by the term ‘Business case’. Why is the business case so important when delivering a system within a Rapid Application Development environment?

The term "Business case" is really means the business proposal. It helps us know about project overview, strategic goal, current situation and problem, critical assumption and constraints, analysis of option and recommendation, preliminary project requirement, potential risk of the project. When we have project description with strategic goal and we can confirm time to do project, functions, technology will use and give requirements for each group the project will very clear."Business case" giving exactly all of the elements need when we do the project. Projects requirement clear, easy to divide small project, know how much resources to divide group to do project. "Business case" is necessary and important when delivering a system within a rapid application development environment.

Tutorial 3: MoSCoW rules (Hoang Tuan Long and Vuong Tan)

Question 2. MoSCoW rules

a. Using the MoSCoW rules discussed in class, prioritise the above requirements into one of the four categories.

1.      Customer database – customer data entry, querying and updating

2.      Quotation database – data entry, querying and updating of premiums

3.      Quotation screens – enabling telesales staff to quote prices to customers

4.      Phone acceptance of insurance policy (and ensuing processes)

5.      Printing of insurance certificates and insurance schedules

6.      Automatic printing of renewal reminders

7.      Phone acceptance of renewals

8.      Automatic printing of payment reminders

9.      Phone acceptance of payment via credit/debit cards

10. Management reports detailing daily/weekly/monthly premium sales

11. Management reports detailing new customer business v. existing customer renewal

12. Management reports profiling customer type/motor vehicle type/type of insurance

13. Automatic back-up of database on a transaction-by-transaction basis

14. Telesales security system with graded access to system functionality

MoSCoW prioritization

Must	Should	Could	Won’t
1,2,3,4	5, 7, 9, 13	6, 8, 10	11, 12, 14

The requirements 1, 2, 3, 4 must be MUST HAVEs. Obviously, customer and quotation are the two objects this telesales system is all about, therefore customer and quotation datababase is very crucial to the main operation. On top of that, the core business requirements of this system are to enable the telesales staff to quote prices to customers and for customers to accept the insurance policy, which is why requirements 3, 4 belong to the MUST HAVE. There is no point in implementing a telesales system which does not meet these requirements.

The SHOULD HAVEs of the system are 5, 7, 9, 13, because the system can work without them (the telesales still can quote prices to customers and customers still can accept the insurance policy by phone) and moreover these requirements really affect the business case. The phone acceptance of renewals or the phone acceptance of payment via credit/debit cards are the absolutely necessary functionalities for customers if they want to renew their insurance or make payment, so why are they not in MUST HAVE? It is because this system is urgent as the scenario describes; the renewals will not happen in couple of months, and there are many other ways to make payment, so they can wait.

The requierements 6, 8, 10 belong to COULD HAVEs, simply because they don’t really affect the business case here. The management reports detailing daily/weekly/monthly premium sales kinda help figure out good and bad points of the current sales activities, thus the system could have this function. We can say that these requirements are additional features it is nicer to have them.

Finally, there are requirements 11, 12, 14 in the WON’T HAVEs. These requirements have very little business value and the system does work really fine without them.

b.  Do you think the MoSCoW rules are an effective way of prioritising functionality?  What problems (if any) do you perceive with using this approach?

I think MoSCoW rules are an effective way of prioritising functionalities because:

·        They help indentify the functionalities which bring the most business value.

·        They help indentify the most important functionalities earlier, so developers can do them first.

·        They help indentify the functionalities which bring less business value, so developers can consider doing them later or not at all.

·        They help reduce confusion of different options from stakeholders because they force all the relevant stakeholders (customer, product owner, project sponsor and users) to be in one place to talk through their different options on what to be done and eventually reach the final agreement of prioritization.

However, we may encounter the problem of not being able to balance the 60% effort for MUST HAVEs and the other 40% for SHOULDs and COULDs. Once the requirements are placed in the MUST HAVE category, it is likely that the efforts invested in these requirements are too many and enough to take up almost all the project time. Eventually, the MUST HAVE functionalities are delivered perfectly, but maybe there are no functionalities coming from SHOULD or COULD HAVEs. This means we only bring out a system that works, not stably and beautifully works. Furthermore, this technique is supposed to prioritize functionalities, not removing them off the list like that. In conclusion, it is recommended that no more than 60% effort for MUST HAVEs for a project, with 40% SHOULDs and COULDs. Anything higher than 60% poses a risk to the success and predictability of the project, unless the environment is well understood, the team is established and the external risks are minimal.

Rapid Application Development (Nguyễn Năng Chung - Nguyễn Quang Hiệp)

3.         Timeboxes

Give a simple definition of a timebox. Explain how a timebox enables an iterative and incremental approach to delivery.

Timeboxing Models: 

Answer : 

a) Definition :Timebox is a technique for organizing software delivery and it can be used for planning or scheduling. It refers to the act of putting strict time boundaries around an action or activity.

  

_Another definition :(http://tynerblain.com/blog/2006/04/12/how-to-use-timeboxes-for-scheduling-software-delivery/)

  A timebox is a fixed unit of development capacity. An easy way to visualize a timebox is as a two-dimensional graph. Along the vertical axis is the cost of the development team (per unit time). Along the horizontal axis is time. The longer an iteration is, the wider a timebox is.

The important thing to notice is that with Cost and Time fixed, the capacity of the timebox is fixed. There is only so much that can be accomplished with a given team and a given amount of time.

b) how a timebox enables an iterative and incremental approach to delivery :

In the timeboxing model, the development is done in a series of fixed duration time boxes – the functionality to be developed in an iteration is selected in a manner that it can “fit” into the time box. Each time box is divided into a sequence of fixed duration stages, with a dedicated team for each stage. As a team completes its task for a time box, it passes the outputs to the team for the next stage, and starts working on its task for the next time box. Due to pipelining, the turnaround time for each release is reduced substantially, without increasing the effort requirement.

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"