BCO5001_Assignment_2014_15(2) (1).docx

of 17

STUDENT NAME: PROGRAMME:

STUDENT NUMBER: YEAR:2014/15 GROUP:

Module Number:BCO5001 Term 1 and 2 Module Title: Systems Development & Design

Tutor Responsible For Marking This Assignment: Stuart McNeil

Module Leader: Stuart McNeil

Assignment 2 Due Date: End of term 2 Hand In Date: End of Term 2

ASSIGNMENT TITLE: Systems Development and Design – Report (assignment 2)

FEEDBACK DATE (Return of assignments to students): 2-4 weeks post submission.

SECTION A: SELF ASSESSMENT (TO BE COMPLETED BY THE STUDENT)

In relation to each of the set assessment criteria, please identify the areas in which you feel you have strengths and those in which you need to improve. Provide evidence to support your self-assessment with reference to the content of your assignment.STRENGTHS AREAS FOR IMPROVEMENT

I certify that this assignment is a result of my own work and that all sources have been acknowledged:

Signed:______________________________________________ Date___________________________

SECTION B: TUTOR FEEDBACK(based on assignment criteria, key skills and where appropriate, reference to professional

standards)

STRENGTHS AREAS FOR IMPROVEMENT AND TARGETS FOR FUTURE ASSIGNMENTS

MARK/GRADE AWARDED DATE: SIGNED

ASSIGNMENT MODERATED BY: DATE

MODERATOR’S COMMENTS:

Learning OutcomesOn completion of this unit the student will:

assignment exam

Demonstrate an understanding of the main

Systems Development & Design:Module Aim:This module is intended to lead the student through the stages of Information systems strategy, defining systems requirements and designing, assuring and implementing requirements. The module focuses on the identification, analysis and implementation of computerised business systems to support the management, control and administration of an organisation. The module compares and contrasts Structured Systems Analysis and Design Methodology (SSADM) with alternative approaches to information systems development.

Mapping Report:Individual component (100%) REPORT (Term 1)

1. An introduction

We all use numerous systems every day, systems are essentially a group of processes working together. This way of viewing the system and its components may help you understand the system as a whole. In this assignment you are tasked with diagrammatically representing a system, utilising the specified diagrams and models within this brief.

The specific system that you will be modelling will be for an events management system. You will need to work within some specific boundaries, such as staffing and venue (please staff list for more details), however the rest of the brief will be detailed by you.

1.1. You are required to represent these through the following diagrams:1.1.1.Use Case Diagram 1.1.2.Physical Data Flow Diagram1.1.3.Logical Data Flow Diagram1.1.4.Sequence Diagram1.1.5.Entity Life History1.1.6.Class Diagram1.1.7.Interaction Diagram

1.2. You are to accompany each diagram with text to highlight and express specific elements contain within. This text should be sufficient to enable the reader to grasp the specific nuances contained within the diagram, detailing its requirements and explaining its context. You are likely to grasp and subsequently map these findings via a method of eliciting the requirements. Consider the specific parameters that each modelling diagram embodies; use these elements to assist you in its application.

of 17

1.3. Staffing List:1.3.1.Lighting engineers (2)1.3.2.Caterers (4)1.3.3.Florists (1)1.3.4.Security (10)1.3.5.Marshalls (4)1.3.6.Bar staff (6)1.3.7.Ticket Office (3)1.3.8.Merchandising (2)1.3.9.Hospitality (5)1.3.10. Management (3)

2. Venue: TBC

Submission Date for report: End of Term 2. Please review the VLE to see notifications of the exact date.

of 17

Marking criteria for ReportAThe requirements detailed in the specification are met fully.In particular, the contents laid out are all present and are of a high standard. The report is formatted to contain all relevant sections as discussed in lectures & in ‘Report Guidelines’ below. Throughout, the report is excellently presented, coherently written, with a good logical flow of content.Higher grades of A will show evidence of creativity & extra effort such as reading around the subject or commenting on the merits or otherwise of the system documented.

BThe content will be complete and will be to a competent but less exacting standard than for an A.In general, the report will contain all the essential sections, it will be well written but the high standard may be less consistent in some sections of the report than others.

CThe content will be complete, and will be of an acceptable level. The report will contain all the essential sections, written to an average level.

DBoth the content will be to an acceptable level, although there may be minor omissions and inconsistencies.

EAlthough not of sufficient standard to gain a pass, there is evidence to suggest that, with a reasonable amount of additional effort, an acceptable standard could be reached.

FContent and presentation are lacking in all aspects.

of 17

Report guidelines(see also the information given in presentation on Report Writing)

Title page – use pro forma below.

Executive Summary – write this after completing the rest of the report

List of contents – students to decide whether or not needed

Terms of Reference – as a minimum, this should detail the initiator of project, who did it & the finish date

Introduction / background(Apart from the executive Summary, most of the content above will come from the SCOPE exercise as discussed in seminars.)

Findings

Conclusions / Recommendations Appendices / References

of 17

Assessment criteria:

90-100% A quite exceptional and outstanding answer, providing insights which would not be available publicly, and would, with some editing, be publishable. In addition to the features of the next section, this range is distinguished by superior organisation, economic use of language and totally comprehensive, given the conditions of the exercise.

80-89% An answer which demonstrates an excellent understanding of the question and of the complexity of the issues involved. There is a sound basis of relevant factual knowledge and/or the theoretical issues involved. Most of the important issues are dealt with in a detailed, specific and systematic way. There is either some measure of original thinking in the answer or an accurate and comprehensive account is given in a way which demonstrates understanding, for example by structuring the material such that it could not have been based just on reproduction of lecture notes and course material. Evidence of creativity, critical approach, and wide reading beyond the core subject matter.

70-80% Excellent structure and flow, use of English and essay writing skills. No grammatical or spelling errors. Lively and interesting discussion, introducing original ideas and thoughts into the focus of the assignment. References and bibliography accurately included and listed according to the required standard. Well-focused with evidence to support individual contribution and all aspects of the assignment requirements. Detailed evidence of appropriate reading, reflective evaluation and a critical analysis of the key issues involved.

60-69% Good structure and flow use of English and essay writing skills. Few grammatical or spelling errors. Interesting discussion incorporating evidence of original thought into the focus of the assignment. Few errors in the citing of and listing of references/bibliography. Good focus to the essay with evidence of individual contribution and most of the aspects of the assignment requirements. Good level of evidence with regard to appropriate reading, reflective evaluation, and a critical analysis of the key issues involved.

50-59% Satisfactory structure and flow with minimal errors displayed in the use of English and essay writing skills. Some evidence of original thought and a satisfactory level of discussion. Some errors in the citing and listing of references/bibliography. Satisfactory focus to the essay with some evidence of individual contribution and various aspects of the assignment requirements. Satisfactory level of evidence with

of 17

regard to background reading, reflective evaluation, and critical analysis of the key issues involved.

40-49% A basic attention to structure and flow, use of English and essay writing skills. No evidence of original thought, and discussion at a basic level only. Several errors in the citing and listing of references/bibliography. A basic focus to the essay with minimal evidence of individual contribution and other aspects of the assignment requirements. Basic level of evidence with regard to background reading, reflective evaluation, and critical analysis of the key issues involved.

30-39% Inappropriate structure and flow, use of English and essay writing skills. No evidence of original thought and a poor demonstration of discussion skills. References erratically and/or incorrectly cited both in the text and within the listing (including bibliography). Unsatisfactory focus to the essay with little or no evidence of individual contribution or other aspects of the assignment requirements. Little or no evidence of background reading, reflective evaluation, or critical analysis of the key issues involved.

20-29% The answer may meander around the general area of the question, but with very little coherence or structure. There is no evidence of criticism, synthesis or evaluation.

10-19% Some notes relevant to the question, but without coherence.

1-9% Notes of little relevance to the question or only an introductory paragraph and one or two scattered thoughts.

0% No answer is presented. A zero mark may also be warranted for unfair practice such as plagiarism or collusion.

of 17

Recommended Reading & Required Reading:Required Reading/Learning MaterialsSkidmore, S. & Eva M. (2003), Introducing Systems Development. Palgrave Macmillan.

Recommended Reading/Learning MaterialsLejk, M. & Deekes, (2002), An Introduction to Systems Analysis Techniques. 2nd Edition. Addison Wesley.

Kendall, K. & Kendall, J. (2010), Systems Analysis and Design. 8th Edition. Prentice Hall.

Curtis, G. & Cobham, D. (2008), Business Information Systems, Analysis, Design and Practice. 6th Edition. Prentice Hall.

Bowman, K . (2003), Systems Analysis a beginner’s guide. Palgrave Macmillan.

Yeates, M. & Wakefield, T. (2004), Systems Analysis and Design. 2nd Edition. Prentice Hall.

This module is extensively supported via Blackboard

3. Diagrams 3.1. Use case diagram

3.1.1.Behavioural3.1.2.Whiteboard sketch3.1.3.The use-case diagram depicts a collection of use cases, actors, their associations, and

optionally a system boundary box. When modelling requirements a use case diagram can be used to model the context of your system, indicating the major external entities that your system interacts with

3.1.4.See more at: http://agilemodeling.com/essays/agileRequirements.htm#sthash.9Z24pidL.dpuf

3.2. Data flow diagram (DFD)3.2.1.Behavioral3.2.2.Whiteboard drawing3.2.3.A data-flow diagram (DFD) shows the movement of data within a system between

processes, entities, and data stores. When modeling requirements a DFD can be used to model the context of your system, indicating the major external entities that your system interacts with

3.2.4.- See more at: http://agilemodeling.com/essays/agileRequirements.htm#sthash.9Z24pidL.dpuf

of 17

http://agilemodeling.com/essays/agileRequirements.htm#sthash.9Z24pidL.dpuf


4. Techniques for Eliciting Requirements4.1. Active Stakeholder Participation Extends On-Site Customer to also have stakeholders

(customers) actively involved with the modelling of their requirements.4.1.1.Highly collaborative technique4.1.2.The people with the domain knowledge define the requirements4.1.3.Information is provided to the team in a timely manner4.1.4.Decisions are made in a timely manner4.1.5.Many stakeholders need to learn modelling skills4.1.6.Stakeholders often aren't available 100% of the time4.1.7.Airs your dirty laundry to stakeholders4.1.8.It doesn't get more agile than this

4.2. Electronic Interviews: You interview a person over the phone, through video conferencing, or via email.

4.2.1.Supports environments with dispersed stakeholders4.2.2.Provides a permanent record of the conversation4.2.3.Restricted interaction technique4.2.4.Limited information can be conveyed electronically4.2.5.Risky when it is your only means of communication4.2.6.Ideally used to support other techniques, not as your primary means of elicitation4.2.7.Face-to-face interviews should be preferred over electronic ones

4.3. Face-to-Face Interviews: You meet with someone to discuss their requirements. Although interviews are sometimes impromptu events, it is more common to schedule a specific time and place to meet and to provide at least an informal agenda to the interviewee. It is also common to provide a copy of your interview notes to the interviewee, along with some follow up questions, for their review afterward. One danger of interviews is that you'll be told how the person ideally wants to work, not how they actually work. You should temper interviews with actual observation.

4.3.1.Collaborative technique4.3.2.You can elicit a lot of information quickly from a single person4.3.3.People will tell you things privately that they wouldn't publicly4.3.4.Interviews must be scheduled in advance4.3.5.Interviewing skills are difficult to learn4.3.6.Be prepared to follow-up4.3.7.Hold the interview at a whiteboard, so that you can sketch as you talk, turning the

interview into a model storming session4.3.8.Actively listen to what they're saying

4.4. Focus Groups: You invite a group of actual and/or potential end users to review the current system, if one exists, and to brain storm requirements for the new one.

4.4.1.Collaborative technique4.4.2.Significant amounts of information can be gathered quickly4.4.3.Works well with dispersed stakeholders4.4.4.Works well when actual users do not yet exist4.4.5.Must be planned in advance4.4.6.Lots of unimportant information will be conveyed4.4.7.It's difficult to identify the right people4.4.8.Focus groups can be diverted by a single strong-willed individual4.4.9.Hold it in a room with whiteboards or flip chart paper so people can drawn as they talk

of 17

4.5. Joint Application Design (JAD): A JAD is a facilitated and highly structured meeting that has specific roles of facilitator, participant, scribe, and observer. JADs have defined rules of behaviour including when to speak, and typically use a U-shaped table. It is common practice to distribute a well-defined agenda and an information package which everyone is expected to read before a JAD. Official meeting minutes are written and distributed after a JAD, including a list of action items assigned during the JAD that the facilitator is responsible for ensuring are actually performed.

4.5.1.Facilitator can keep the group focused4.5.2.Significant amounts of information can be gathered quickly4.5.3.Works well with dispersed stakeholders4.5.4.Restricted interaction technique4.5.5.Facilitation requires great skill4.5.6.JADs must be planned in advance4.5.7.Loosen the rules about when people can talk4.5.8.Hold it in a room with whiteboards or flip chart paper so people can drawn as they talk

4.6. Legacy Code Analysis You work through the code, and sometimes data sources, of an existing application to determine what it does.

4.6.1.Identifies what has been actually implemented4.6.2.Restricted interaction technique4.6.3.The actual requirements usually differ from what you currently have4.6.4.It can be very difficult to extract requirements from legacy code, even with good tools4.6.5.Must be tempered with more interactive techniques such as interviews and active

stakeholder participation.4.7. Observation You sit and watch end users do their daily work to see what actually happens in

practice, instead of the often idealistic view which they tell you in interviews or JADs. You should take notes and then ask questions after an observation session to discover why the end users were doing what they were doing at the time.

4.7.1.Helps to identify what people actually do4.7.2.Provides significant insight to developers regarding their stakeholder environments4.7.3.Restricted interaction technique4.7.4.It is hard to merely observe, you also want to interact4.7.5.Seems like a waste of time because you're "just sitting there"4.7.6.Can be difficult to get permission4.7.7.Observation is best done passively

4.8. On-Site Customer In XP the customer role is filled by one or more people who are readily available to provide domain-related information to the team and to make requirements-related decisions in a timely manner.

4.9. Collaborative technique4.9.1.Information is provided to the team in a timely manner4.9.2.Decisions are made in a timely manner4.9.3.Airs your dirty laundry to stakeholders4.9.4.Stakeholders need to be educated in their role4.9.5.Get your stakeholders involved with development by evolving towards an active

stakeholder participation approach4.10. Reading There is often a wealth of written information available to you from which

you can discern potential requirements or even just to understand your stakeholders better. Internally you may have existing (albeit out of date) system documentation and vision documents written by your project management office (PMO) to justify your project. Externally there may be web sites describing similar systems, perhaps the sites of your competitors, or even text books describing the domain in which you're currently working.

of 17

4.10.1. Opportunity to learn the fundamentals of the domain before interacting with stakeholders

4.10.2. Restricted interaction technique4.10.3. Practice usually differs from what is written down4.10.4. There are limits to how much you can read, and comprehend, and a single sitting4.10.5. Read details in a just-in-time (JIT) manner4.10.6. See more at:


Appendix:

Technique Description Strength(s) Weakness(es) Staying Agile

Active Stakeholder Participation

Extends On-Site Customer to also have stakeholders (customers) actively involved with the modelling of their requirements.

Highly collaborative technique

The people with the domain knowledge define the requirements

Information is provided to the team in a timely manner

Decisions are made in a timely manner

Many stakeholders need to learn modelling skills

Stakeholders often aren't available 100% of the time

Airs your dirty laundry to stakeholders

It doesn't get more agile than this

Electronic Interviews

You interview a person over the phone, through video

Supports environments with dispersed stakeholders

Restricted interaction technique

Limited

Ideally used to support other techniques, not as your primary

of 17

conferencing, or via email.

Provides a permanent record of the conversation

information can be conveyed electronically

Risky when it is your only means of communication

means of elicitation

Face-to-face interviews should be preferred over electronic ones

Face-to-Face Interviews

You meet with someone to discuss their requirements. Although interviews are sometimes impromptu events, it is more common to schedule a specific time and place to meet and to provide at least an informal agenda to the interviewee. It is also common to provide a copy of your interview notes to the interviewee, along with some follow up questions, for their review afterward. One danger of interviews is that you'll be told how the person ideally wants to work, not how they actually work.

Collaborative technique

You can elicit a lot of information quickly from a single person

People will tell you things privately that they wouldn't publicly

Interviews must be scheduled in advance

Interviewing skills are difficult to learn

Be prepared to follow-up

Hold the interview at a whiteboard, so that you can sketch as you talk, turning the interview into a model storming session

Actively listen to what they're saying

of 17

You should temper interviews with actual observation.

Focus Groups

You invite a group of actual and/or potential end users to review the current system, if one exists, and to brain storm requirements for the new one.


Significant amounts of information can be gathered quickly

Works well with dispersed stakeholders

Works well when actual users do not yet exist

Must be planned in advance

Lots of unimportant information will be conveyed

It's difficult to identify the right people

Focus groups can be diverted by a single strong-willed individual

Hold it in a room with whiteboards or flip chart paper so people can drawn as they talk

Joint Application Design (JAD)

A JAD is a facilitated and highly structured meeting that has specific roles of facilitator, participant, scribe, and observer. JADs have defined rules of behavior including when to speak, and typically use a U-shaped table. It is common practice to distribute a well-defined agenda and an information

Facilitator can keep the group focused

Significant amounts of information can be gathered quickly

Works well with dispersed stakeholders


Facilitation requires great skill

JADs must be planned in advance

Loosen the rules about when people can talk

Hold it in a room with whiteboards or flip chart paper so people can drawn as they talk

of 17

package which everyone is expected to read before a JAD. Official meeting minutes are written and distributed after a JAD, including a list of action items assigned during the JAD that the facilitator is responsible for ensuring are actually performed.

Legacy Code Analysis

You work through the code, and sometimes data sources, of an existing application to determine what it does.

Identifies what has been actually implemented


The actual requirements usually differ from what you currently have

It can be very difficult to extract requirements from legacy code, even with good tools

Must be tempered with more interactive techniques such as interviews and active stakeholder participation.

Observation You sit and watch end users do their daily work to see what actually happens in practice, instead of the often idealistic view which they tell you

Helps to identify what people actually do

Provides significant insight to developers regarding their stakeholder environments


It is hard to merely observe, you also want to interact

Seems like a waste of time because you're "just sitting

Observation is best done passively

of 17

in interviews or JADs. You should take notes and then ask questions after an observation session to discover why the end users were doing what they were doing at the time.

there" Can be difficult

to get permission

On-Site Customer

In XP the customer role is filled by one or more people who are readily available to provide domain-related information to the team and to make requirements-related decisions in a timely manner.


Information is provided to the team in a timely manner

Decisions are made in a timely manner

Airs your dirty laundry to stakeholders

Stakeholders need to be educated in their role

Get your stakeholders involved with development by evolving towards an active stakeholder participation approach

Reading There is often a wealth of written information available to you from which you can discern potential requirements or even just to understand your stakeholders better. Internally you may have existing (albeit

Opportunity to learn the fundamentals of the domain before interacting with stakeholders


Practice usually differs from what is written down

There are limits to how much you can read, and comprehend, and a single sitting

Read details in a just-in-time (JIT) manner

of 17

out of date) system documentation and vision documents written by your project management office (PMO) to justify your project. Externally there may be web sites describing similar systems, perhaps the sites of your competitors, or even text books describing the domain in which you're currently working.

- See more at: http://agilemodeling.com/essays/agileRequirements.htm#sthash.9Z24pidL.dpuf

of 17


BCO5001_Assignment_2014_15(2) (1).docx

Documents

Transcript of BCO5001_Assignment_2014_15(2) (1).docx