Information System Management

LAB 2

I. Introduction
This report base on the question “Why do we need methods”. In this document, we will give
the reason to explain, answer for each question that should be listed below .

II. Content
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, they can't share
information of part they do like analysis, software design, implementation. They can't
unify the idea together how one group can discuss to other group. For example, analysis
group have many idea to do project make it very interesting and unique but this group
can't 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. Moreover, a group
was doing implementation still need to find their own ideas to completed project.
In addition, no group developers for testing is one big mistake, they using incremental
development but not iterative, so if one step going wrong they can’t go back to fix that
problem. Project will be fail.

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 1. 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?

1
 According to the Mckinsey & Company’s research in collaboration with University of
Oxford, 17% of large IT projects (budgets $15M+) go so badly they threaten the existence
of the company. The reason which cause a many large projects with big budgets fail is that
large projects are often completed in long time. Especially with information technology
projects, technology changes every 18 months and investing time usually appear very high
risk. Moreover, the large projects need much capital and human resources, they also need
more stitching work organization allocated as needed good leaders. In addition, large
projects often difficult to manage risks by the scale of the project as well as money may
collapse at any time. It is difficult to manage the project’s scope and it is not easy to
measure the unexpected arise in large projects. Finally, we have to spend a lot of money
and effort to control the quality of products of a large project with big budgets.

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?

Iterative advancement is a methodology of software development that partitions a

venture into many discharges. The primary thought of iterative advancement is to make
little activities that have a well-defined scope and duration and constantly do builds and
updates as soon as possible. Moreover, the incremental model is a method of software
development where the model is outlined, executed and tested incrementally until the
product is finished. It involves both development and maintenance. The product is defined
as finished when it fulfills the majority of its necessities. This model consolidates the
components of the waterfall model with the iterative philosophy of prototyping.

Most code written is never used, the above factors combine to ensure much of what
is coded, while it may work technically, is never used. For example, working features that
are not required, or were never really relevant. The time and cost taken to build these
non-required features is large. One study found that 45% large, complex projects are
more likely to fail. The chances of failure of software projects increase with their size and
most likely due to the increase in complexity and difficult of predicting how complex
systems will behave. By splitting large projects into smaller, manageable iterations (each
one effectively a mini project of its own), Agile seeks to simplify this complexity in an
attempt to reduce the chances of failure.

4. The case study tells us that :" testing appeared to be non-existent developer 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 ?

Developers test their own code . Since testers and developers work on the same team,
they can more easily communicate with each other. However, errors will occur because

2
many developers use different methods for coding. 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. They use so when they incorporate their code it will not occur much errors.

There are six tips for testing within a development environment.

Firstly, using your production environment . Your production environment is the ideal
environment for testing . There is no need for replications, and it always includes those
background processes and environment variables that affect performance and are often
missed. When using a production environment for testing, make sure to back up
production data so that you can quickly revert to the real environment once testing is
done, isolate or disable third-party applications such as payment systems and use fictitious
entities (such as user accounts) to simulate the activity you want to test.

Secondly ,making an exact replica of your production environment. You should

replicate your production environment in every aspect: machine profiles, configuration,
database, network architecture, load balancers, firewalls, etc. One method is to create
complete images of production machines to be duplicated in your test environment.

Thirdly, replicating a customer environment. The most effective way would be to

duplicate a customer’s production environment. Try working with select customers with
the assurance that you’ll protect or remove critical data, and offer to provide discounts or
free support.

Furthermore ,building a real environment from scratch. You will have to build a load
testing environment from scratch because you’ll have no production environment to copy.
Moreover, taking into account different types of potential deployments you might want to
test. With each address, the number of users configured, how many records are in the
database, create configurations as similar as possible to the typical production—security,
hardware, software, network,… Add third-party integrations used in the live production
system, such as payment systems, reporting or support and so on.

In addition, establishing a procedure to quickly set up your test environment because

once you have your environment working and configured, create a snapshot or image so
that you can recreate it in minutes. There also are many configuration management and IT
automation tools you can use to quickly set up a server environment, such as Saltstack,
Ansible, Docker, and Vagrant.

Finally, isolating the test environment is that building a realistic test environment is
essential for the success of your load testing. We simply cannot do without it, and it will
eliminate the chances of catastrophic failures. Moreover, Computing resources are always
scarce, and test machines are often the solution. It’s important that your test network is
isolated so it is not affected by other company activities you may not be aware of.

3
III. Conclusion

In conclusion, due to these questions above, we can learn a lot about incremental
development and have some experience in software development. We can learn from this
experience to test the projects carefully and make sure that our projects will not fail in the
future.

IV. References

1. http://blog.systemsltd.com/it-projects-failures-introduction-and-reasons
2. http://sdmfgroup6.blogspot.com/

4
5