ICM EPG Evaluation for Assignment - Software Engineering | CSCI 577A, Assignments of Software Engineering

Material Type: Assignment; Class: Software Engineering; Subject: Computer Science; University: University of Southern California; Term: Fall 2008;

Typology: Assignments

Pre 2010

Uploaded on 02/24/2010

koofers-user-yi2-1
koofers-user-yi2-1 🇺🇸

9 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
GabrielAlcocer
CSCI577a,Fall2008
USCID:6121430328
ICMEPGEvaluation
ClientInteractionReport
1) No,theICMEPGonlygivesaveryshortdescriptionofwhattheartifactis.Itdescribesitasa
reportthatcapturesthefirstsitevisit,butdoesnotspecifyexactlywhatcontentthereport
shouldcontain.
2) Yes,theentiredescriptionoftheexpecteddatacontentismissing.
3) No,becausethereisnoexpecteddatacontent,sotherearenocriticalissues,concerns,orrisks
regardingtheexpecteddatacontent.
4) No,theICMEPGdoesnotprovideatemplateforthisartifact.
5) N/AbecausetheICMEPGdoesnotprovideatemplateforthisartifact.
6) N/AbecausetheICMEPGdoesnotprovideatemplateforthisartifact.
7) No,theICMEPGdoesnotprovideanexampledocumentofthisartifact.
8) N/AbecausetheICMEPGdoesnothaveanexampledocumentforthisartifact.
9) N/AbecausetheICMEPGdoesnothaveanexampledocumentforthisartifact.
10) Yes,toacertainextent.TheICMEPGgivesashortdescriptionofitsintendedusewhichisto
documenttheinformationtheteamsgathersduringthefirstclientsitevisit.Theartifactisalso
supposedtohelptheteambettercomprehendthecurrentworkprocessandtheneedsforthe
newsystemtheteamwillbedeveloping.1Thelinktothisis:
http://greenbay.usc.edu/IICMSw/index.htm#practice.tech.opt_con_development.base/workpro
ducts/client_interaction_report_E543244B.html
11) No,Ithinkthatthedescription,thoughitisveryshort,givesagoodoverviewofthescopeofthe
intentoftheartifact.
12) Yes,Ithinkthatthereisaminorconcernthatcanbegleanedfromitsintendedusedescription
whichistheideaofwhatartifactwouldbeusedtocaptureinformationfromsubsequentclient
visitsifit’sbeforetheWinWinnegotiationsession.Thedescriptionoftheclientvisitreportsays
thatit’sforthefirstvisit,soonemayassumethatitisexclusivelyforthatusesothisconcernis
unaddressed.
FeasibilityEvidenceDescription
1) No,theICMEPGdoesnotdirectlyspecifytheexpectdatacontentforeachsectionofthe
artifact.ThesectionsareidentifiedindirectlythroughtheexampleFeasibilityEvidence
Descriptionbutarenotexplainedindetail.ThesectionsaretheIntroduction,BusinessCase
Analysis,ArchitectureFeasibility,ProcessFeasibility,RiskAssessment,andtheNDI
InteroperabilityAnalysis.
2) Yes,thereissomethingmissingfromtheexpectedcontentofthisartifactbecausetheexpected
contentisnotspecifiedthereatall.ItwouldbehelpfulifitwereexplicitlystatedintheICMEPG
ratherthanindirectlyintheexampleortemplate.
pf3
pf4

Partial preview of the text

Download ICM EPG Evaluation for Assignment - Software Engineering | CSCI 577A and more Assignments Software Engineering in PDF only on Docsity!

Gabriel Alcocer CSCI 577a, Fall 2008 USC ID: 6121430328

ICM EPG Evaluation

  • Client Interaction Report
    1. No, the ICM EPG only gives a very short description of what the artifact is. It describes it as a report that captures the first site visit, but does not specify exactly what content the report should contain.
    2. Yes, the entire description of the expected data content is missing.
    3. No, because there is no expected data content, so there are no critical issues, concerns, or risks regarding the expected data content.
    4. No, the ICM EPG does not provide a template for this artifact.
    5. N/A because the ICM EPG does not provide a template for this artifact.
    6. N/A because the ICM EPG does not provide a template for this artifact.
    7. No, the ICM EPG does not provide an example document of this artifact.
    8. N/A because the ICM EPG does not have an example document for this artifact.
    9. N/A because the ICM EPG does not have an example document for this artifact.
    10. Yes, to a certain extent. The ICM EPG gives a short description of its intended use which is to document the information the teams gathers during the first client site visit. The artifact is also supposed to help the team better comprehend the current work process and the needs for the new system the team will be developing.^1 The link to this is: http://greenbay.usc.edu/IICMSw/index.htm#practice.tech.opt_con_development.base/workpro ducts/client_interaction_report_E543244B.html
    11. No, I think that the description, though it is very short, gives a good overview of the scope of the intent of the artifact.
    12. Yes, I think that there is a minor concern that can be gleaned from its intended use description which is the idea of what artifact would be used to capture information from subsequent client visits if it’s before the WinWin negotiation session. The description of the client visit report says that it’s for the first visit, so one may assume that it is exclusively for that use so this concern is unaddressed.
  • Feasibility Evidence Description
    1. No, the ICM EPG does not directly specify the expect data content for each section of the artifact. The sections are identified indirectly through the example Feasibility Evidence Description but are not explained in detail. The sections are the Introduction, Business Case Analysis, Architecture Feasibility, Process Feasibility, Risk Assessment, and the NDI Interoperability Analysis.
    2. Yes, there is something missing from the expected content of this artifact because the expected content is not specified there at all. It would be helpful if it were explicitly stated in the ICM EPG rather than indirectly in the example or template.
  1. Yes, the critical issue is that the expected data content is not specified explicitly in the ICM EPG, as stated in #2. Without this, it makes it difficult for the reader to learn what the content of the document should be.
  2. Yes, it does and the sections are as defined in #1. This is the link to the template document: http://greenbay.usc.edu/IICMSw/practice.mgmt.feasibility_evidence_development.base/guidan ces/templates/resources/IICMSw_FED_Template.doc
  3. Yes, there is an area for improvement in the template. The template could also give a brief description of what each section is about, just to reinforce that with the reader.
  4. No, there are no critical issues, concerns, or risks regarding the template.
  5. Yes, the ICM EPG does provide an example document of the artifact. It is located here: http://greenbay.usc.edu/IICMSw/practice.mgmt.feasibility_evidence_development.base/guidan ces/examples/resources/FED_OCP_S07b_T03_V10.0.doc
  6. No, there is nothing missing or wrong with the example document.
  7. No, there are no critical issues, concerns, or risk regarding the example document. The document seems to adequately address each of the sections outlined in the Feasibility Evidence Description.
  8. No, the ICM EPG does not directly provide information about the intended use of the artifact. It is only provided indirectly in the example document which states that the purpose of the FED is to show evidence that the artifacts generated by the team, such as the requirements, architecture, and plans, can feasibly be developed in the delivered system.^2
  9. Yes, the ICM EPG is missing a direct explanation of the Feasibility Evidence Description ’s intended use. This is only partially found in the example listed in #7 above.
  10. No, there are no critical issues with its intended use, at least what’s briefly described in the example Evidence Description , though it is a critical issue in itself that a description of its intended use is omitted altogether in the ICM EPG.
  • Initial Prototype Report
    1. Yes, in a sense the ICM EPG does specify expected data content, but only in a general sense in the main description. The Initial Prototype Report is meant to document in detail the comments, suggestions, and reactions of the client after their evaluation of the first prototype for the new system. The artifact is also supposed to capture the critical issues and risks that can be discovered and mitigated through prototyping.^3 The information can be found here: http://greenbay.usc.edu/IICMSw/index.htm#practice.tech.opt_con_development.base/workpro ducts/initial_prototype_report_16F618F9.html
    2. No, there is nothing missing or anything wrong with the expected data content identified in this document. The basic ideas of what the artifact should contain are captured in the brief description listed in #1.
    3. No, there are no critical issues, concerns, or risks regarding the expected data content in the Initial Prototype Report as described in the ICM EPG.
    4. No, the ICM EPG does not provide a template for the Initial Prototype Report.
    5. N/A because the ICM EPG does not provide a template for this artifact.
    6. N/A because the ICM EPG does not provide a template for this artifact.
  1. The only possible area that I see missing from the example is what I identified as a possibility in the template in #5 above, though this would of course be inherent to the example since it followed the template.
  2. No, I do not see any critical issues, concerns, or risks regarding this example.
  3. Yes, the ICM EPG provides a brief description of its use which is that the OCD will be used throughout the project’s lifecycle during development based on new operational concepts. It will be used even more during the beginning of the development process as requirements are still being gathered and the creation of the design is still underway.^4 Here is the link: http://greenbay.usc.edu/IICMSw/index.htm#practice.tech.opt_con_development.base/workproducts/o perational_concept_description_3E1ACE76.html
  4. No, I do not see anything missing or wrong with the information about its intended use. The description could be a little bit longer, but that is simply a preference.
  5. No, I do not see any critical issues, concerns, or risks regarding the artifact’s intended use.

References: (^1) Incremental Commitment Model‐ Electronic Process Guidelines, Client Interaction Report ,

http://greenbay.usc.edu/IICMSw/index.htm#practice.tech.opt_con_development.base/workproducts/cl ient_interaction_report_E543244B.html, visited on September 14, 2008. (^2) Incremental Commitment Model‐ Electronic Process Guidelines, Feasibility Evidence Description

Example, http://greenbay.usc.edu/IICMSw/practice.mgmt.feasibility_evidence_development.base/guidances/exa mples/resources/FED_OCP_S07b_T03_V10.0.doc, visited on September 14, 2008. (^3) Incremental Commitment Model‐ Electronic Process Guidelines, Initial Prototype Report,

http://greenbay.usc.edu/IICMSw/index.htm#practice.tech.opt_con_development.base/workproducts/i nitial_prototype_report_16F618F9.html, visited on September 14, 2008. (^4) Incremental Commitment Model‐ Electronic Process Guidelines, Operational Concept Description,

http://greenbay.usc.edu/IICMSw/index.htm#practice.tech.opt_con_development.base/workproducts/o perational_concept_description_3E1ACE76.html, visited on September 16, 2008.