Explain What are 5 common problems in the software development process?
Submitted by: AdministratorProblems
•Poor requirements - if the requirements are not clear,
unfinished, too common, and not testable, then there will
be problems.
•Unrealistic schedule - if too much work is given in too
little time, problems are inevitable.
•Inadequate testing - no one will know whether or not the
program is any good until the customer complain or systems
collide.
•Futurities - requests to pile on new features after
development is underway; extremely common.
•Miscommunication - if developers do not know what's needed
or customer's have wrong expectations, problems are assured.
Solutions
•Solid requirements - clear, complete, detailed, cohesive,
attainable, testable requirements that are agreed to by all
players. Use prototypes to help nail down requirements.
In 'agile'-type environments, continuous close coordination
with customers/end-users is necessary.
•Realistic schedules - allow adequate time for planning,
design, testing, bug fixing, re-testing, changes, and
documentation; personnel should be able to complete the
project without burning out.
•Adequate testing - start testing early on, re-test after
fixes or changes, plan for adequate time for testing and
bug-fixing. 'Early' testing ideally includes unit testing
by developers and built-in testing and diagnostic
capabilities.
•Stick to initial requirements as much as possible - be
prepared to defend against excessive changes and additions
once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be
adequately reflected in related schedule changes. If
possible, work closely with customers/end-users to manage
expectations. This will provide them a higher comfort level
with their requirements decisions and minimize excessive
changes later on.
•Communication - require walkthroughs and inspections when
appropriate; make extensive use of group communication
tools - groupware, bug-tracking tools and change management
tools, intranet capabilities, etc.; insure that
information/documentation is available and up-to-date -
preferably electronic, not paper; promote teamwork and
cooperation; use prototypes and/or continuous communication
with end-users if possible to clarify expectations.
Submitted by: Administrator
•Poor requirements - if the requirements are not clear,
unfinished, too common, and not testable, then there will
be problems.
•Unrealistic schedule - if too much work is given in too
little time, problems are inevitable.
•Inadequate testing - no one will know whether or not the
program is any good until the customer complain or systems
collide.
•Futurities - requests to pile on new features after
development is underway; extremely common.
•Miscommunication - if developers do not know what's needed
or customer's have wrong expectations, problems are assured.
Solutions
•Solid requirements - clear, complete, detailed, cohesive,
attainable, testable requirements that are agreed to by all
players. Use prototypes to help nail down requirements.
In 'agile'-type environments, continuous close coordination
with customers/end-users is necessary.
•Realistic schedules - allow adequate time for planning,
design, testing, bug fixing, re-testing, changes, and
documentation; personnel should be able to complete the
project without burning out.
•Adequate testing - start testing early on, re-test after
fixes or changes, plan for adequate time for testing and
bug-fixing. 'Early' testing ideally includes unit testing
by developers and built-in testing and diagnostic
capabilities.
•Stick to initial requirements as much as possible - be
prepared to defend against excessive changes and additions
once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be
adequately reflected in related schedule changes. If
possible, work closely with customers/end-users to manage
expectations. This will provide them a higher comfort level
with their requirements decisions and minimize excessive
changes later on.
•Communication - require walkthroughs and inspections when
appropriate; make extensive use of group communication
tools - groupware, bug-tracking tools and change management
tools, intranet capabilities, etc.; insure that
information/documentation is available and up-to-date -
preferably electronic, not paper; promote teamwork and
cooperation; use prototypes and/or continuous communication
with end-users if possible to clarify expectations.
Submitted by: Administrator
Read Online Design Patterns Job Interview Questions And Answers
Top Design Patterns Questions
☺ | Identify three types of systems or system upgrades that may be ideal candidates for a Waterfall Development Model strategy? |
☺ | What is difference between GoF and J2EE patterns? |
☺ | What is design pattern? |
☺ | What is difference between Function Oriented Design and |
☺ | Suppose we have file(ps), dont know how many records are there. move half of the records to 2 files. how can we do? |
Top Software System Design Categories
☺ | Technical Writer Interview Questions. |
☺ | Requirements Management Interview Questions. |
☺ | Project Planning Interview Questions. |
☺ | Design Patterns Interview Questions. |
☺ | Software Design Tools Interview Questions. |