Read each part and create a 100-150 word response to the discussion with reference to back the claim. Basically, read the discussion and create a reply based on the discussion that has valid points and reference to back the point.
Part 1: 100-150 words with references (discussion onAll six methods of information gathering discussed in this week lecture take a lot of time. Do you think that there are some ways that systems analysts could collect the required information while saving time? Please offer your opinion on this issue.)
• The issue with these long requirement gathering methods is that it normally they lead to a project never reaching completion. These methods are more prevalent in the waterfall methodology which lead to only around a 30 percent success rate in projects. The way to bypass the requirements gathering is phases is to gather requirements while you build.
Agile is very good at this process. In an agile environment requirements are gathered enough in the beginning in order to start the project and then in user stories drive the project for changes in requirements. Scrum which is the most popular agile methodology is flexible and very scalable throughout the project so that if more requirements are defined than it is easy to add them into the project.
The issue with waterfall is much time is spent on requirements then when something changes it leads to major changes in the application that significantly delay projects. Scrum incorporates many of the requirement gathering techniques into its framework by having two week iterations that solicit client feedback and even integrate surveys. Agile has been gaining a lot of steam in recent years do to its scalability and how it makes the best use of time.
Work Cited:
Agile Project Requirements Gathering: Techniques to Identify User Stories.
Part 2: 100-150 words with reference (discussion based on During the systems development life cycle (SDLC), certain key problems discovered in the later stages could be directly traced back to inadequate and/or poor efforts in the requirements phase and industry studies show that over 50% of systems problems belong to this case.
In addition, as mentioned in this notes "the cost of errors in requirements that weren't discovered until later" may go up to 1,000 times. As a systems analyst, what should we do to minimize this problem? How might this be avoided?)
• Preventing Scope Creep
Preventing scope creep is one of the most difficult aspects of project management. A clear scope agreement is imperative in addition to a clear process for managing changes. A project scope statement and requirements document should not only be a guide for the project team, but an agreement between the client and vendor.
New ideas always immerge during a project and, if not properly managed, can balloon a project's scope. There might be something the client forgot about or an opportunity that became apparent part way through the project.
In any case, if there is an agreed to requirements document with little ambiguity, there is a clear recourse leading to change management procedures and renegotiation of the contract.
Once the project requirements are agreed to, the project manager must be careful not to make verbal agreements based on a vague recollection of the scope. The PM must be disciplined enough to stop the conversation and refer back to the written requirements (Harned, 2015).
That can be an uncomfortable situation at times, as the PM is also a customer service agent. However, other than a poorly defined requirements document, off-the-cuff verbal agreements are one of the biggest causes of scope creep. I have personally been on the client side of this situation. Asking for a very small thing here and there is easy and an undisciplined PM who agrees to many small things can find the scope ballooning out of control.
References
Harned, B. (2015). Taming the Scope Creep. A Guide to Project Management.
Part 3: 100-150 Words with References (Discussion based on Discuss the role of object-oriented abstraction to Big Data applications.)
• According to Techopedia, "abstraction is the act of representing essential features without including the background details or explanations...the abstraction principle is used to reduce complexity and allow efficient design and implementation of complex software systems."
Abstraction is used in object-oriented databases in order to hide the noise behind the objects. This plays a major role in Big data applications because its reduces the noise level for a database. In order for Big data applications to do their job which is to analyze large set of data efficiently, it must sift through a lot of information, and object-oriented abstraction helps by hiding everything but what is relevant to the object. The focus and makes it more efficient for a big data application.
Reference
Rouse, M. (2014, June). What is abstraction?
Techopedia. (n.d.). What is abstraction?
Part 4: 100-150 Words with references (discussion based on Discuss the applicability of object-oriented databases for complex data types.)
• Object-oriented databases are also called Object Database Management Systems (ODBMS). Object databases store objects rather than data such as integers, strings or real numbers. Objects are used in object oriented languages such as Smalltalk, C++, Java, and others.
Objects basically consist of the following:
Attributes - Attributes are data which defines the characteristics of an object. This data may be simple such as integers, strings, and real numbers or it may be a reference to a complex object.
Methods - Methods define the behavior of an object and are what was formally called procedures or functions.
Object databases should be used when there is complex data and/or complex data relationships. This includes a many to many object relationship. Object databases should not be used when there would be few join tables and there are large volumes of simple transactional data.
Object-oriented databases work well with:
• CAS Applications (CASE-computer aided software engineering, CAD-computer aided design, CAM-computer aided manufacture)
• Multimedia Applications
• Object projects that change over time.
• Commerce
References
Object Oriented Databases. (n.d.).