COEPD Prep Exam 3 PDF
COEPD Prep Exam 3 PDF
COEPD Prep Exam 3 PDF
Answer :
Boundary Classes :
The Boundary class is a class that is the boundary of the system and other
system or user ( which is actor in the use case diagram ).
1. This class is more easy to be changed than the Entity and Control
class.
2. The attribute of this class and screen layout are defined at the basic
design.
3. In a class diagram , there are cases that the stereotype
(<<boundary>>) is added.
4. In a class diagram , there are cases that is shown by the following
icon.
Controller classes :
1. There are many cases that this objects of this class are perpetuated 1 in
the DB.
2. The extraction of the class is like ER diagram 2.
3. This class is related to the DOA (Data-oriented approach) 2.
4. The module cohesion of this class is high 3, and is not easy to be
changed.
5. In a class diagram , there are cases that the stereotype (<<entity>>) is
added.
6. In a class diagram , there are cases that is shown by the following
icon.
Q3. Place these classes on a three tier Architecture. - 2 Marks
Q4. Explain Domain Model for Customer making payment through Net
Banking - 2 Marks
Q5. Draw a sequence diagram for payment done by Customer Net
Banking - 2 Marks
Q6. Explain Conceptual Model for this Case - 2 Marks
Ans :
o MVC has the feature of scalability that in turn helps the growth
of application.
o The components are easy to maintain because there is less
dependency.
o A model can be reused by multiple views that provides
reusability of code.
o The developers can work with the three layers (Model, View,
and Controller) simultaneously.
o Using MVC, the application becomes more understandable.
o Using MVC, each layer is maintained separately therefore we
do not require to deal with massive code.
o The extending and testing of application is easier.
Ans:
The business analyst will verify the product is delivered as per the
requirements and it is meeting the business need. Maintenance: Once the
implementation is done the team has to give support by installing patches,
handling change requests, etc.
This is the initial stage of the project where is an involvement of the BA. BA is
responsible for preparing BRD document (Bussiness Requirement
Document )
Designing:
In this phase the artitect will start designing the system based on the
bussiness analyst inputs and requirement documents. The BA helps him to
clear the doubts about the requirements.
Artifacts: Design Documents and UML diagrams get ready in this phase.
Coding :
This phase is quite lengthy as the core development starts in this phase.
Developer start product development based on the requirement document
prepared by the BA. Developer may ask questions to BA regarding the
requirement and he needs to answer the questions as and when required.
Artifacts: Code
Testing :
After coding, the testing phase will start, In this phase BA helps the testing
team to understand the requirements so that they will build proper functional
test cases. BA has to review whether the test cases covering the whole
functionality.
Deployment:
Once the code is developed and tested,It is ready to deploy in the production
environment. The BA will verify the product is delivered as per the
requirements and it is meeting the business needs.
Artifacts: Implementation Review document.
Maintenance:
Once the implementation is done the team has to give support by instaling
patches, Handling change requests, Etc.
A BA is the personwho knows every nook and corner of the project. So every
change request has to be reviewed by him and based on his inputs and
reports the team will respond.
This model describes the two core dimensions while choosing a mode of
conduct in a situation of conflict: ‘assertiveness’ and ‘cooperativeness’.
Assertiveness is the extent to which you try to solve and resolve for your
preferred outcomes. Think of this as the factor on the Y-Axis of a graph. On
the other hand, Cooperativeness is the level to which you try to resolve the
other party’s problems. This is the factor on the X-Axis of the graph.
Competing
Accommodating
Avoiding
Collaborating
Compromising
Ans:
1. Poor planning
objectives should be clearly defined, so as time goes by, you’ll know if you’re
doing what’s right or not. Remember that choosing measurable goals helps
you better visualize your progress and helps you see how close you are to
achieving your results.
4. Lack of detail control
It’s essential that everyone involved in the projects have complete project
visibility so that it doesn’t fail – not only the project manager, but other team
members too.
This includes clear communication, good document management, and
transparency about tasks’ status, all of which can be achieved with
centralized, all-digital files.
6. Lack of communication
Among the ways projects fail, a very common one is scope creep. This
concept refers to changes requested when the project has already started
which had not been planned before. This is very common when projects are
not appropriately documented and defined beforehand.
8. Unrealistic expectations
When you want to do something fast, with a limited budget, and a reduced
team, it can really make your project fail. You should be realistic when it
comes to your teams’ capabilities, deadlines, and the resources available –
only then can you obtain the results you want.
9. Lack of monitoring
When each team member receives their responsibilities clearly, they will know
what, when, and how to perform their activities without someone needing to
constantly ask for it.
A BA is responsible for multiple tasks at the same time. From handling the
projects, maintaining client relationships, interacting with stakeholders, and
managing project deadlines, Business Analysts got a lot on their plate. Read
below to find out the challenges faced by business analysts and a possible
solution to them
It might happen more once, even for the exact requirement, making
it one of the most frequent issues. These adjustments could have an
impact on the Business Analysis effort as well as the total project
effort, cost, and schedule.
5. Unrealistic Timelines
As a Business Analyst, you may find yourself in a problematic
situation where timelines might be the concern. In that case,
pressure is created, which might hamper your work. In that case,
understand how to tackle such a situation while maintaining the
quality of the work.
6. Technical Skills
When it comes to Business Analysts, it’s a myth that they don’t
require technical skills. On the contrary, most of them are
champions in coding, know how to maintain business processes, and
have a knack for technically undertaking the requirements.
Moreover, Business Analysts are involved in every step of the
product development cycle; hence, they must understand the
technical and functional side of the business as well.
7. Professionalism
Business analysts are one of the most underappreciated, underpaid,
and ignored members of the IT world. They frequently serve as the
binding agent between a project’s technical and business aspects.
They are the one who contributes to the development of the project
plan and who supports the project from beginning to end. They will
collaborate with developers to ensure the project is constructed
following the most current standards and satisfies the business’
expectations.
8. Managing Communication
When you communicate effectively, you aid developers in
understanding the needs, limits, and requirements of the
business.You contribute to the development of solutions that benefit
the client as well as the company. You guarantee the work is
completed on schedule and to the required standards. But
communicating the point is difficult. It involves a variety of abilities
and trade secrets.
10. Mindset
Business analysts must be prepared to deal with various difficulties
throughout their work, from limitations of the technologies they
employ to pushback from stakeholders and other team members.
But how one approaches their task can significantly alter if they are
ready for the most typical obstacles.
Ans:
Correct - /…/Orientation/20181105SchdlVlntrs.pdf
Incorrect -
The_schedule_and_volunteers_for_Orientation_Nov_18.pdf
Correct - /…/Doe/Events/KidsNSibs/20181105BnceHsRsrvtn.pdf
Incorrect - /
…/Doe/Events/KidsNSibs/20181105KidsNSibsBounceHouseReservati
on.pdf
Ans.
1-Every problem of Client has uniqueness, so talk to the client with a
plain mind with no assumptions from your previous experience.
2-Never come to any conclusion before listening or understanding
all the aspect of requirement from client, if you have a slight
amount of doubt about any demand or change it’s always preferable
to clear it with the client, subject matter expert, or with your team
member.
8-Always try to build a repo with your senior, colleague and your
team, Take care not to break confidentiality, earn their trust.
9-Make sure that you have gathered all the requirements from the
stakeholder for your project , missing out any information can
results to unwanted redo the work as well as delay projects and
increase cost.
Ans:
Packages
A Packages is a grouping and organizing element in which other
elements reside, which must be uniquely named. In the UML,
packages are used in a manner similar to the way directories and
folders in an operating system group and organize files. For
example, the project management system may be decomposed into
a collection of classes organized into packages as follows:
Sub-Systems :
Recall that a system is an organized collection of elements that may
be recursively decomposed into smaller subsystems and eventually
into non decomposable primitive elements. For example, the project
management system may be decomposed into the following:
A user interface subsystem responsible for providing a user
interface through which users may interact with the system
A business processing subsystem responsible for implementing
business functionality
A data subsystem responsible for implementing data storage
functionality.
Ans.
Q18. What is API. Explain how you would use API integration
in the case of your application Date format is dd-mm-yyyy
and it is accepting some data from Other Application from
US whose Date Format is mm-dd-yyyy 3 Marks
Ans:
An API, is Application Programming Interface, is a software-to-
software interface. APIs provide a secure and standardized way for
applications to work with each other and deliver the information or
functionality requested without user intervention.
An API, or application programming interface, is a set of defined
rules that enable different applications to communicate with each
other. It acts as an intermediary layer that processes data transfers
between systems, letting companies open their application data and
functionality to external third-party developers, business partners,
and internal departments within their companies.
Q19. What is the difference between Brainstorming and JAD
Sessions? 2 Marks
Ans:
Brain storming:brain storming technique contain group of stake
holders to give deep thought about particular topic.This
technique basically useful in developing new ideas.
JAD: JAD is conducted by bringing Stake holder and developer
together at same place. JAD provide high accurate level of
requirement.Though JAD are conducted for different types
purpose in SDLC JAD is Mostly conducted in two Ways, One is as
eliciting technique and second is to clarify development teams
doubts.
Brainstorming: group discussion among stakeholders to collect
ideas to include the relevant requirements.
JAD session: the session conduct among selected stakeholders
(business client+system developer) to get more refined
requirements.
Brainstorming : Brainstorming can be done either individually or
in groups. The ideas collected can then be reviewed/analyzed
and where relevant included within the system requirements.
JAD technique is an extended, facilatated workshop. It involves
collaboration between stakeholders and systems analysts to
identify needs or requirements in a concentrated and focused
effort.
Brain Storming tehniques last for about 2-3 hours
JAD Sessions last for about 2-3 days
Brain Storming covers all of the mentioned subjects.
JAD covers technology used for the development.
Setup
Game Time
Observers No Yes
Self
Family member
Friend
Colleague
On behalf of a business
Other
Ans
Ans:
Most requirements are interdependent and you will hardly find any
requirement that exists independently. To understand why we need
a dependency map – let us take a scenario where you have 8
requirements X,Y,Z,P,Q,R,M,O and N with priorities, on a 5- level
scale where 1 is most critical and 5 least critical, as
1,2,1,4,5,1,2,2,3. So, with these priorities it would be logical to begin
with requirements X, Z and R
Must have (or Minimum Usable Subset) – These are features that
must be included before the product can be launched.
Should haves are features that are not critical for the launch, but
are considered to be important and of a high value to the user.
Could haves are features that are nice to have and could
potentially be included without incurring too much effort or cost
Won’t have - are features that have been requested but are
explicitly excluded from scope for the planned duration and may
be included in a future phase of development.
MUST (M)
Defines a requirement that has to be satisfied for the final solution
to be acceptable e.g. The HR system “must” store employee leave
history.
SHOULD (S)
COULD (C)
Ans:
Ans:
Minutes is to create an official record of the actions taken at a
Meeting. Minutes serve to both memorialize the actions taken for
those attending the Meeting as well as for those who were unable to
attend the Meeting.
MEETING AGENDA
Meeting/Projec Sprint Review Meeting
t Name:
1. Meeting Objective
2. Attendees
3. Meeting Agenda
In this approach, requirements are fixed, and budget and time get
agreed on earlier. For this reason, teams often face budget and
timeline problems with this approach. You can?t use traditional
project management to develop complex products, as this approach
leaves no room for changing the requirements. However, studies
suggested that the waterfall or traditional approach?s failure rate is
nearly 21% while the agile failure rate is 8%.
Agile model:
Ans: