Creative Hive - blogs
Address: 23 Croft Street, Salford, Greater Manchester, M7 1LR
Education & Qualifications
2013 – Present University of Salford
BA (Hons) Photography degree
2006-2013 Carrickfergus Grammar School
GCSE Results: Mathematics (A), Spanish (A), Business and Communication Studies (A), Art (A), Additional Mathematics (B), English Language (B), English Literature (B), Biology (B), Physical Education (B), Child Development (B), Religious Education (C)
A-Level Results: Photography (B), Art (C), Mathematics (C), Biology (AS Level) (C)
2012 Neil Harrison Photography
1 weeks work experience with Neil Harrison, a self employed photographer, working with various car and house sales companies, gaining skills in working with businesses and people. I also worked alongside the Queens University Theatre Company photographing their latest performance, which was out of my comfort zone but allowed me to develop new skills.
1 weeks work experience working with Matthew. Having a keen interest in sports photography, I was able to work alongside the Ulster Rugby team, photographing their training as well as the Irish Superbike Races. This allowed me to develop and strengthen my abilities within sports photography as well as working alongside professionals in the field. I also gained experience in PR photography, taking photographs for local businesses and writing up articles with them for small local business magazines.
Summer 2014: Molly Malone’s (Fish and Chip Shop)
Employer – Lois Neely (07515415069)
Summer Job: June – August 2014
Good knowledge of office applications including Word, PowerPoint and Excel as well as Photoshop and Lightroom.
I have Grade 4 piano and Grade 4 violin and am self-taught in both guitar and drums. I have performed at various charity events and small gigs as well as my university’s Journalism Awards.
Between 2006 and 2013 I played for my school’s 2ndXI Hockey team, 1stXI Football team and top Volleyball team as well as training and playing volleyball for Jordanstown Ladies.
In 2012/2013 I was a member of the Islandmagee Camera Club in which I attended a night class every Tuesday, gaining knowledge in Photoshop, Lightroom and studio lighting.
In 2012 I started doing photography for my school’s magazine and in 2013 I was made head photographer for all school events.
In my final two years at school, I was both a peer and academic mentor for junior pupils who were struggling either socially or academically and provided one-on-one sessions as well as organizing group activities.
Duke of Edinburgh:
In 2011 I achieved my silver Duke of Edinburgh Award
I have recently finshed putting togehter my first Architecture photographic Portfolio! I narrowed down what I felt was my best work to 8 images to include in the portfolio, I could of added more but I wanted the quality to be maintained throughout and needed the images to work together well as a set.
Some of the images are viewable in my image bank for everyone to see so take a look when you can, they are in low resolution however!
Hello Creative Hive,
My name is Sophie and I am a photography student at the University of Salford.
I don’t specialise in any particular type of photography as I like to vary my images from one style to the next. I do this because I have always viewed the world differently to other people. I observe everything with curiosity and closeness. I often find myself focusing on the details on an atomic level or on the universe as a whole. My images could be a portrait one day and an up close and personal macro one the next. However my work always seems to have an element of the controversial on as I enjoy the strange and unusual.
One of my favourite photographers is called Tyler Sheilds as his work often contains or revolves around controversy and transgression. He always breaks the boundaries of whats right or wrong but his work is beautifully orchestrated and presented. Another photographer who inspires me is called Taryn Simon. Her work explores the world behind the boundaries placed by authorities and lets people see the unknown and inaccessible places.
Thanks for visiting my page. I hope you enjoy
Hello there, my names Livy. I am a student photographer currently studying photography at The University of Salford.
The kind of photography I specialise in is studio and commercial work; this varies from things such as new-borns to pets, as you can see on my slideshow. In the past year I begun working as a freelance photographer and I have been able to explore and push myself to try out new things such as weddings and working with babies. About a year ago I didn't really have a direction, but whilst i have been completely the project 'Professional Frameworks 2' I have begun to choose a path and found myself within the photography industry.
One of my favourite photographers is Henri Cartier-Bresson, he is without a doubt one of my inspirations. His message more so than his images are what inspired me, to capture the moment. I feel like photography is something that opens our eyes to things we may not see, and opens up a whole new outlook on things. It allows us as photographers, to express and explore ourselves.
Rosy Martin has also been one of my inspirations recently. She explores memories within her photographs and the passing of time. I feel like i use photography as a way to document life as it is, and i enable people and myself to then hold onto these precious memories for as long as the photograph shall remain.
When i think about photograph, it’s not just a photograph to me, it’s a feeling, it’s a memory, it’s a documentation of something i or somebody else wants to hold onto.
Please feel free to contact me with any query’s or questions; i am always welcome for a chat!
Thank you for visiting my page and i hope you enjoy.
Although some may feel that a life in retail banking can be quite monotonous, a career in this field allows for a wide scope of progression in to other sectors and allows you to expand your career in to departments other than the front desk dealing with customers. Retail bankers traditionally work in banks and building societies usually found on the High Street although they are now expanding to online and supermarkets which offer banking services. The role of a banker is to primarly help the financial needs of customers who visit the branch providing assistance with face to face queries, loans, overdrafts, opening of accounts and money transfers.
Although beyond this, there is a wide scope for development. As I am looking in sight for a career in retail banking, this is something I would be focusing on acheiving, using the junior retail banking roles mentioned as a guide ladder to progress me further. Opportunites for progression involve team leaders, assistant managers of a branch, branch manager and regional manager. If it is decided that I would like move out of branch completely, the role of a retail banker could put me in central office position such as marketing, project management, product development and risk management. This is only a few examples of the large variety a career in retail banking can offer.
There is also the possibility to apply for retail graduate schemes and programmes. These allow a graduate to either focus on one particular department in a branch or give them the opportunity to access all areas of the daily operations. This is something I would be interested in as it would help me decide which areas I would be most interested.
Upon gaining an Business with Economics degree at the University of Salford, hopefully this would give me an advantage in to the banking sector over others who do not possess a degree and may have to gain entry at a lower foundation level. A career in retail banking requires a candidadate to have a customer service based focus, be sales orientated, be flexible and open to changing conditions and have excellent verbal and written communication skills. After studying my degree for the past three years and being in jobs dealing with customers face to face, I feel upon graduating, a career in retail banking would be an ideal start to my future.
Week 6/7 Blog
During week 6 the main topic that was up for discussion was requirements engineering. We basically looked at why requirements engineering is so important and why it is essential for stopping projects from failing at the first hurdle. If the requirements of any project aren’t fully reviewed and agreed upon before it’s even been started there is very little hope for the project being successful. Firstly I learnt that the need for engineering is to generate certain system specifications such as recording agreed decisions, reduces misunderstandings massively, forms communication medium and could possibly provide a basis for testing system behaviour. During discussion time in lecture 6 we were given an widely known example of a project that has had problems due to engineering requirements not being up to standard and this was ‘universal credit’. Whilst reading parts of the article we basically recognised that the problems they gained occurred by not having a detailed blueprint/structure of how universal credit was going to work. With millions of pounds on the line in a project of this magnitude it makes you wonder how this could possibly happen, however it did and the government eventually increased its initial write-off of a failed IT system for universal credit by £6 million to £40.1 million which is rather worrying (Patrick Wintour, The Guardian, 2013).
After this we then went on to discuss the actual requirements in more thorough detail. We went on to discuss how the actual requirements are acquired for example some of the ways which were brought up were questionnaires, public surveys, different scenarios etc. these are required to find out as much as possible about the clients organisations, past problems and what they exactly expect from the system that is going to be built. If these aren’t correct and detailed enough to work on then this will be a big problem when it comes to the designing phase.
In week 7 we started off by briefly reviewing engineering requirements again from the previous week and then we were introduced to systems development life cycle models. I was anticipating this subject massively because I have previous experience learning about types of life cycles models and their roles whilst at college. Firstly we discussed the two frequently used lifecycle models which are the ‘waterfall lifecycle’ and ‘prototyping lifecycle’. “The classical waterfall model considers the transition between two phases to be similar to a waterfall. That is, once a phase is complete, the various activities during the phase are assumed to be flawlessly done and there is no scope for rework at a later time” (Rajib Mall, Fundamentals of software Engineering, 2013, PHI learning) A lifecycle Alternate to the waterfall model is the prototype model which again was thoroughly discussed in the lecture and is basically built to demonstrate or test a concept. This was model came about because of many failures happening in the final phase of software application developed using the waterfall lifecycle approach. The main advantage of this model is that quicker feedback is available to faster, better solutions. The main disadvantage that I found was it could have too much involvement from the client which will more than likely not be preferred by the developer.
Thanks for reading.
Rajib Mall, Fundamentals of software Engineering, 2013, PHI learning
Week 6/7 blog
The topics that were covered in week 6/7 one of the topic was requirement engineering and looking have things can be forgotten and things that need to be remembered to meet the requirements that have been agreed. We also looked at other reasons that could be behind projects failing and a third of the reason for projects failing would be the requirements because things are changed as a project progresses or the person who the project is for changes his mind on the requirements. “A statement of a system service or constraint” (Kotonya & Sommerville) this is the description of a requirement in simpler terms.
In these weeks we was also shown the life cycle of requirement engineering and explained to us how this lifecycle was used in proper practise. In these weeks we was also told about requirement acquisition this is where the designer of the software has to find out about the clients company and what the company would need out of the software that is being designed for the company. This is used to get an idea of the client and the company’s problems so this is an information gathering tactic for the engineer. We also touched on the types of information that would be gathered by using this tactic.
We also have to look at the two different types of requirement which is functional and non-functional, functional looks at specific types of behaviour of certain functions whereas non-functional looks at the overall system for example its usability and its performance.
We also looked at the types of acquisition that could be used so that the client and the software being designed could have a close relationship so they know how the development is going and if it is meeting the requirements and if the engineer creates a prototype then the client could be entitled to make some changes. We also touched on why you should write a requirement specification we came to realise that this is the basis of communication for the client and the user and also some clients may include this in the contract of creating the software.
We also looked at prioritising requirements and how not all requirements will be able to be reached in a given development and we also learned that the simple approach it more easily grasped by a client rather than trying to squeeze all the requirements in one and end up having to go back and change the requirements and this could also cause the project to fail and cost the client more money if this isn’t done correctly.
We also looked at different types of models firstly how the waterfall model is used and how it looks like the simplest method because it is broke down into different stages and that one stage needs to be completed and signed off before the other stage can started the only thing with this model is that you can’t go back once a stage is complete. The alternative to the waterfall model is the prototype model this is different because once you produce a protype and done the testing in this model you can go back on the prototype until it meets the needs of the client.
Blog Weeks 6 and 7
During these two weeks, we have learnt been able to identify the market in which the digital market operates in, the requirements of a system, the relationship that exists between Technology, Business and Society, and also different methodology of requirements in a system.
We learnt that there are three interacting sub-processes during the Requirements Engineering phase, and these are split into Requirements Acquisition, Requirements Specification and Requirements Validation, with all three going around in a cycle. The acquirement of information occurs when the client gives out their requirements, to figure out the inherit problems of the client, and the expectations the client has for the system in the process of creation, which can be done through a number of methods, including but not limited to documentation inspection, interviews and structured meetings etc. One particular method that is usually highlighted is the rich picture method, which we have spent an extended amount of time in class, working in groups, have defined as “A Rich Picture is a way to explore, acknowledge and define a situation and express it through diagrams to create a preliminary mental model. A rich picture helps to open discussion and come to a broad, shared understanding of a situation.”(Better Evaluation, 2014).
We have focused on two essential variants of the Systems Development Lifecycles, or SDLC in short. There is the Waterfall Lifecycle, which is also known as the Sequential Lifecycle, where everything is carried out in order, step by step, where the Feasibility Study takes place first, then the Systems Analysis and Design, followed by Program and Unit test, then System and Acceptance test, finally rounding off with operations. The special point that has been made about this method is that there is no going back once the system is finalised. The methodology does not allow any backtracking to be viable, but time will be saved as the complexity of this method is significantly less then the following method. The second method is the Prototyping Lifecycle, which is also known as the Iterative Lifecycle. This method has the same Feasibility Study stage, but then is followed up by the initial prototype, then this prototype is reviewed constantly, with enhancements and testing going on, in order to create the best system, then the system test is initiated, and finally operation. This method allows the creators of the system to be able to go back and change what has already been created, and this provides an advantage over the waterfall system. The main disadvantages of this method is the sheer complexity of going back and reviewing everything, since there is always something that can be done better.
All of these can be applied in a real life scenario, such as a business I had experience with in the past. I have been an employee of an online digital services provider, and through this I have been able to use their website to locate clients and communicate with them and provide services to them. I have given many reviews to the creators of the system, and since they were using the Iterative Lifecycle method, they were able to edit and make changes, which, in my own personal experience, is more feasible.
HEINZE, A, KANE, S. (2015, 16th March). Principles of Systems Development
week 7. [PowerPoint slides]. Presented at a Newton234 lecture at University of Salford.
Rich Pictures. (n.d.). Retrieved March 13, 2015, from http://betterevaluation.org/evaluation-options/richpictures
Blog Week 6 & 7 Lecture
Week 6 (Lecture)
Welcome to my blog, I’m glad you’re reading it.
Week 6 we covered requirement engineering in lecture, it was an interesting subject.
Main aspect of this subject involved why should we engineer requirement capture and what is involved also what makes a good requirement.
Requirements is a statement of a system service or constraint, it is used to describe user-level facility, general system property etc.(Kotonya & Sommerville).
The reason it’s important to engineering requirement is to generate system specification, without specification developers won’t progress nor the stakeholder. Other reasons for engineering requirement is to reduce and remove misunderstanding also forms a communication medium between stakeholders and developers, this helps to form the basis of a contract with clients.
Furthermore more discussion relating to project failure: requirement related problems consisting of unrealistic expectation, changes in requirement and specifications.
Example of project failure is Universal Credit this is because the developers lacked a detailed view of how Universal Credit is meant to work also lack of a detailed blueprint, architecture and target operating model for Universal Credit. This cause the system to be wrote off costing up to 40 million pounds and won’t be completed on the year as originally planned (THE GUARDIAN, 2013).
Requirement acquisition is used to find out about the clients organisation, expectation and current problems. Methods that can be applied during a requirement engineering process are MoSCoW, Rich pictures, Interviews, Scenarios etc.
In my opinion to make a good requirement developer must find out the user level facility, general system property and the specification constraints on the system, it gives the developer a form of material to determine possible outcomes. The MoSCoW method should be applied to prioritise requirement so developer knows what is most important.
Week 7 (Lecture)
Discussion on system development life cycle, this involves 2 essential variants; waterfall and prototype Lifecycle.
• Waterfall Lifecycle - sequential
• Prototype Lifecycle - Iterative
Waterfall lifecycle is basic form of development allowing project to be broken down into sequential stages which is to be completed and signed off before approaching other stages.
Prototyping is another method of system development lifecycle, this is the man alternative to waterfall lifecycle, prototype is iterative and allows you to build a model for testing or to be demonstrated as a concept. It doesn't require signing off at end of each stage, the prototyping uses iterative approach to elucidate the requirement of the system which makes things clear for stakeholder as well as other developer.
Both development Lifecycle have their advantages and drawbacks. The advantage aspect of sequential waterfall system is that it’s quicker also well planned out and doesn't overlap. However the Drawbacks for Waterfall Lifecycle is that you can’t go back and change it after it’s been signed off also you only have one chance to have a go at the given task even after signed off.
Prototyping Lifecycle can be iterated this gives an edge over the waterfall lifecycle, advantages is that it allows developers to go back and alter their programs until it’s suitable for the stakeholder and organisation. The draw back to prototyping is that is take time to complete.
We was asked to choose which we find most suitable, my option was the Prototyping, although it take a long time to complete but it’s guaranteed that the final product will be accurate as there will be lots of time for testing to find out if it suit the user and stakeholders need. Lastly we was given a task.
Thanks for Reading my Blog, hope you find it interesting.
• Requirements Engineering: Processes and Techniques (Worldwide Series in Computer Science) Gerald Kotonya, Ian Sommerville – 27 Apr 1998 (Accessed 18th March 2015)
• http://www.theguardian.com/politics/2013/dec/09/universal-credit-it-writeoff-iain-duncan-smith – Monday 9th December 2013 (Accessed 19th March 2015)
Find out more on system not working according to plan on the following link:
• When systems don’t work (Online checkout) - https://www.youtube.com/watch?v=3Sk7cOqB9Dk (Accessed 18th March 2015)
• When system don’t work (Real life search) https://www.youtube.com/watch?v=cbtf1oyNg-8 (Accessed 18th March 2015)
Hello reader, thanks for viewing my blog.
In week six’s lecture we learnt about requirements engineering and discussed issues related to the requirements process and the capture of user requirements. Firstly, we talked about the needs for engineering and why projects fails. During this discussion we were given the example of “Universal Credit” – a project that failed due to its requirements not being consistent and detailed enough (Computer Weekly, 2013). We then discussed requirements. When talking about this topic most of the focus was on methods of acquiring requirements such as questionnaires, scenarios and rich pictures – which we were then showed an example of. We also watched a video that used a supermarket as an example to show what would happen if a system didn’t meet our expectations in a real-life, tangible situation. (Google Analytics In Real Life - Online Checkout, 2011). I found this video interesting as it helped me to understand just how easy a system can fail if its requirements aren’t clear. To conclude the lecture we carried out the task of developing a rich picture for withdrawing money from an ATM in our groups. Each member of my group drew a stage of the scenario. I thought my group’s work was simple yet clear to understand. Perhaps a tad too simple after viewing our peers’ rich pictures, which were a lot more detailed.
In week 7’s lecture we were introduced to Systems Development Life Cycle (SDLC) methods. More specifically, we learnt about the two essential variants of SDLCs: the waterfall lifecycle and the prototyping lifecycle. We then discussed the advantages and drawbacks of each method and what method we thought would be most appropriate when writing our blogs. My group came to the conclusion that the waterfall model would be the most appropriate as we agreed that it was easiest to write blogs in a step by step process, rather than keep changing it until satisfied. To conclude the lecture we were set a group task to plan and write a blog about a topic of our choice. My group chose to do a blog titled “How to take free kicks like Cristiano Ronaldo”, a blog with step by step instructions on how to use the “knuckleball” technique of striking a football. Other than the instructions, we included a link to a video of Ronaldo scoring a free kick during a football match using the “knuckleball” technique and for the call to action we included a link to information about local football leagues, in case a reader would be interested in joining a team and try the “knuckleball” technique in a competitive match situation. I thought my group’s blog was useful, clear and contained important information from external sources.
If you would like to view reviews of some of the alternative SDLC models other than Waterfall and Prototyping, please feel free to click on this link: http://software-security.sans.org/resources/paper/cissp/comparison-software-development-lifecycle-methodologies (SANS, 2015).
Thanks for reading. Until next time.
- COMPUTER WEEKLY. (2013) DWP writes off millions of pounds on Universal Credit IT. [Online] Available from: http://www.computerweekly.com/news/2240204715/DWP-writes-off-millions-of-pounds-on-Universal-Credit-IT-damning-NAO-report-reveals [Accessed: 18th March 2015].
- Google Analytics. 2011. Google Analytics In Real Life - Online Checkout. [Online] [Accessed: 18th March 2015]. Available from: https://www.youtube.com/watch?v=3Sk7cOqB9Dk
- SANS, 2015. Comparison of Software Development Lifecycle Methodologies. [Online] Available From: http://software-security.sans.org/resources/paper/cissp/comparison-software-development-lifecycle-methodologies [Accessed: 19th March 2015].
Today’s blog will interest you in the topics that I was taught in the lectures held in weeks 6 and 7. It may also help in expanding your knowledge (I HOPE!) just as it did with mine.
In week 6, I learnt about “Requirements Engineering”. Switch your brains processing chips on because I am now going to outline the needs for engineering, which includes;
- Generating Systems Specifications;
- Records decisions that have been agreed on
- Forms communication mediums
- Reduces and/or removes any misunderstandings
- Provides a basis for testing system behaviour and for forming a contract with the client
- To form a set of acceptable good common practices
“Requirements are a statement of a system service or constraint” – (Kotonya & Sommerville)
In this lecture, I learnt about the art of using rich pictures. Rich Pictures usually consists of symbols, sketches or doodles and contains information in pictures which is deemed necessary. It is part of the understanding process and not just a recording of an understanding of any given situation.
I was shown an example which was part of a rich picture showing a telephone helpline situation. After looking at this, an activity was given where I had to participate in group work where we were to analyse different situations and come up with its rightful solutions. Upon completing this, we had a chance to put our artistic skills to the test (not that I have any lol J ). In this we had to pick a scenario and produce its ‘Rich Picture’. My group decided to choose the scenario showing the ATM machine and how to withdraw cash.
The steps illustrated on the Rich Picture showed;
- The person walking to the ATM machine
- Taking the card out of his wallet
- Inserting the card into the card reader on the ATM machine
- Entering the pin
- Choosing the option to withdraw cash
- Selecting the amount e.g; £10
- Waiting for the cash to come out
- Removing cash and card
- Walking away, happy!
A week later for the 7Th lecture, I learnt about the two different types of SDLC (System Development Lifecycle;
- Waterfall Lifecycle
- Prototype Lifecycle
This is the basic lifecycle and it breaks the project down into sequential stages which require each stage to be completed and marked off before continuing to the next stage. The stages consist of;
- Feasibility Study
- System Analysis and Design
- Program and Unit Test
- System and Acceptance Test
This is the main alternative to the Waterfall Lifecycle, a model built to test or demonstrate a concept. The sequences of stages are
- Feasibility Study
- System and Acceptance Test
The prototype stage can be later broken down into;
- Initial Prototype
- Test and discuss Prototype
- Enhance Prototype.
Have you worked your socks off and sacrificed your free time to write your own original content on a website, only to have someone “borrow” it? That’s not right!
Copyright is a huge distress and for some individuals can cause anxiety for those who spend precious time and their efforts on creating their own unique work.
Why should others get it handed to them on a plate? Without difficulty and with ease. Some would argue people should just tolerate people to use their work, but the way I see it is that why should they get away with it? Furthermore I believe requesting the possessor’s permission before “borrowing” his/her work is a more appropriate way of using their content.
It’s not only people’s work that can be plagiarised, there are countless things such as; books, films, dramas, songs, brand names and the list goes on. One that caught my eye was the famous phrase from the ring announcer Michael Buffer. He is massive in the sport of Boxing. The legendary and well-known phrase “Let’s get ready to rumble” is his very own trademark. His thriving voice, good appearances and natural charm demand attention, while his catchphrase 'Let's Get Ready to Rumble,' makes him remarkable. His catchphrase has casted in over 20 films and television shows, from the well-known film "Rocky" to the animated series "South Park" to the new film "2012," Michael gives the scene an authenticity viewers demand.
By trademarking his catchphrase, Michael has grossed over $400 million in income, marketing the rights to songs, entertainment, games, merchandise and even through making individual live presences. His business scheme is so successful. Michael does not even have to perform his phrase to make money. He earns more from the trademark than he does announcing in the ring on a boxing event. <iframe width="420" height="315" src="https://www.youtube.com/embed/I6eQ78HCGEA" frameborder="0" allowfullscreen></iframe>
When a piece of content belongs to you, you must write copyright on it and make sure it’s visible if you do not want other individuals to steal your effort. Or else it is permitted for others to take. If you later then realise that someone has taken your efforts and used your work you cannot do anything about it if it is not copyrighted. The Copyright act was cleverly put into place in 1956 by the British government.
If someone did steal your work and it was copyrighted you could sue them. According to The Copyright Law it is illegal for someone to take someone else’s content.
If you would like to read more on The Copyright Law I would suggest you take at the link I posted below.
Be careful when you share your content to always remember trademark it if you do not want others to copy it! Also make sure you ask permission before using someone else’s!
Berman, John, and Michael Milberger. ''Let's Get Ready To Rumble' Worth $400M'. abc news 2009. Web. 19 Mar. 2015.
Hi all, In this weeks blog I will be talking about what we have looked at in weeks 6 and 7 lectures of Principles of Systems Development. In this time we have looked into requirements of engineering and an introduction to systems development lifecycle.
In week 6 we had covered the requirements of engineering. We looked into the need for engineering and the reasons we had when looking at this were, engineering is used in order to:
- will generate a system specification
- it will be able to record agreed decisions
- help raise communication
- less chance of a misunderstanding
- allows the system to be tested
- could help when with clients in ordeer to for a contract
After looking at the needs for requirements we move on to looking at why projects fail. Unsuprisingly a figure that struck me was incomplete requirements being 13.1% of the reason as to why projects fail. Being honest I believe that this should not be a problem in why projects fail as if someone is undertaking a project they should make sure their requirments are fully met before moving on. The other reasons to why they fail have been due to unrealistic expectations which had a figure of 9.9% I believe that this can happen when people over shoot themselves to quick, making them believe they can reach something when realisticly it is not possible. Also with 8.7% of this being due to changing specification/requirements it is proving that the specifications/requirements which were agreed should all be documented.
In week 7 we looked at two Lifecycle models, which were 'The Waterfall Lifecycle Model' and the 'Prototype Lifecycle Model'.
Starting with the waterfall lifecycle model, we learned that this is a system that needs one stage to be competed in order to move onto the stage, hence the term waterfall, (for example the water falls down from rock to rock). The stages of this method are the
- Feasibility Study - this can be technically, financially or ethically .
- System Analysis and Design - this would be the businesses needs, their decisions and the design of the program.
- Program and Unit Test - this would be the programming, and running tests.
- System and Acceptance Test - this would be the tests from both project teams and users.
- Operations - this would be putting everything from the other phases into effect.
The Prototype Lifecycle
This is something which is built to demonstrate and test the concept of a model. The reason for this is to find any problems that this may have, and change/improve the model in order for it to work to its full potential by the project team. As you will see from the stages they are very similar although the protoype will go round in stage 2 of prototype, which is when testing as they will use ideas and any problems that occur to improve the model. Similar to the Waterfall Lifecycle it has a sequence of stages which are:
- Feasibility Study
- Prototype - intital prototype - Test and discuss Prototype and then Enhance Prototype
- System and Acceptance Test
By: Yaqoob Alkaabi
Welcome to my 2nd blog.
We reached weeks six and seven and are still in the process of learning more and more from this module. Many interesting topics have been covered and many discussions have been carried out. The aim of week six was to understand the basics of Requirement Engineering and the issues related to the requirements process and information about web and application accessibility. During the seventh week, our knowledge was increased when we were enlightened with the two essential variants of system development lifecycles, such as the Waterfall, which is sequential, and the prototyping lifecycle, which is Iterative.
Over the past week I have worked hard to broaden my knowledge about engineering requirements and the information that helps to develop a system. Without having an idea about the required system, it’s impossible for an engineer to create the system specified. During a group work session, we have discovered that there is certain information that is required to be elicited in order to build a system. Examples of these include background information, which is information about the company, such as measurement or statistics about the company, company procedures and any forms, standards, policies which are used on a regular basis.
There are a few issues that have the possibility of occurrence during the process of information collection, such as misunderstanding with communication while you are seeking information to build a system.
We have learnt how to differentiate between the functional and non-functional requirements in a system. There are Functional Requirements (such as business rules, external interfaces and historical data) and Non-Functional Requirements (such as, usability, performance and security). However, the main distinction between the two types is that the Non-Functional Requirements describe how the system works, while the Functional Requirements describe what the system should do.
During the lecture that occurred during the course of week six, I learnt the concepts of rich pictures. “A Rich Picture is a way to explore, acknowledge and define a situation and express it through diagrams to create a preliminary mental model.” (BetterEvaluation,2014 ).
In groups, we were given a few scenarios to choose from, then we were asked to create the rich picture for the aforementioned system scenario . I personally think that rich picture helps to open discussion and it also helps with sharing my understanding of the situation with others.
In the news, we have always read about reasons as to why information systems fail, where some of the reasons include incomplete requirements, unrealistic expectation and changing in requirements and specification. However, the best example of project failure is represented by Universal Credit.
During our seminar in week six, Accessibility Techniques were also discussed and we deeply focused on applications and web accessibility issues. Generally, accessibility is defined as the process that allows everyone (regardless of disability etc.) to gain access and to use a website or application. I have gained some knowledge on how to apply Lang Attributes into my homepage.
Lifecycle is the stage was the developers must go through in order to create an information system. The two variants of system development lifecycle were introduced to us during week seven. Sequential is a sequence of an event where we can start from plan A to plan Z without going back a step to change it and is metaphorically referred to as a type of waterfall. The Iterative is the process of reviewing previously created steps and making a change, in accordance to the requirements or needs of a client, thus defining it as a prototyping lifecycle. The main difference between the two essential variants is that the Sequential is a step by step process and Iterative helps the developer to make easily make changes accordingly.
During week seven, we reviewed the definitions of the two different variants of Systems Development lifecycles, Sequential and Iterative, with the former being a step by step walkthrough of steps and the latter being able to make changes to previously created steps, with a disadvantage in the time department.
As a group, we were asked if our blogs were a waterfall type or a prototype. I personally think that our blogs are of prototype because I could always go back and make a change before the submission deadline. Furthermore, we were given a blog template and we had to identify who our audience was going to be, the key takeaways, brainstorm few possible titles, creating an outline, writing introduction, writing the body and finally writing the conclusion.
We were addressed with an important subject during the week seven seminar. Copyright. It is known to us as “The exclusive right to make copies, license, and otherwise exploit a literary, musical, or artistic work, whether printed, audio, video, etc.: works granted such right by law on or after January 1, 1978, are protected for the lifetime of the author or creator and for a period of 50 years after his or her death.”(Dictionary.com,2010).
On the security side, the concept of hacking was explained and we were taught how to protect websites and keep them secure. By closing every insecure hole that has been located within the site, this prevents hackers from trying to weaken the security of the website. At the end of the session, we were asked to complete our holding page.
· BetterEvaluation. (2014). Rich Pictures, Retrieved from http://betterevaluation.org/evaluation-options/richpictures
· Dictonariy.com.(2010) Copyright, Retrieved from http://dictionary.reference.com/browse/copyright
By: Katie Louise
Do you realise how easy you are making it for hackers? During this week's entry I will be giving a brief overview of how you can adapt some of the writing requirement specification steps for your own website security to efficiently be user friendly by creating a website that is trustworthy and known for being reliable, which ties in to why using strong website security is important. Just by being more aware that you can be hacked by anyone can help to make you think twice before picking your easy to remember password and how if you aren't careful or don't fully understand your own settings this won't be secure enough. I have been looking in to some of the useful ways you can avoid being hacked or releasing virus's. Personally I'd hate someone to feel like they have the upper hand when it comes to my personal information and security.
The first question that came to mind when I heard of hacking was why? Why hack someone else's personal account? Are hackers just incredibly nosey people with nothing better to do? I now realize how hacking is much more serious than just finding out who you were talking to a few nights ago, Hackers can gather your bank details, contact numbers, address or even corrupt your work whilst stealing all of your passwords. Mostly hackers which retrieve your bank details are trying to access your or the company's money, some hackers want information they aren't entitled to and then there is the other types of hackers that just enjoy the sense of control they feel when they have intruded on someone else's life and made the adjustments as they see fit. There are ways to avoid this kind of intrusion, it is suggested by every form of hosting company that it is really important to keep updating your software and browsers, they don't just pop up with these suggestions to irritate you, they really do know what they are doing. In reference to(Geek Beat) They discuss how a lot of businesses today still have many unencrypted files and hackers know this, they also mention that hackers usually work within the IT environment trace encrypted free date then take their laptops out at lunch connect to another free wifi away from the company and enjoy hacking into people's information that are sat around them).
It's becoming pretty common knowledge that installing effective anti malware and Anti Spyware is the best way for your computer to protect you from the cheeky pop us that seem to sit behind your browsers until you minimize and think "Hmm I don't play casino poker? When did that happen?" Obviously overtime Internet hosts have improved their security as well as newer operating systems have, my laptop asks me every single time I want to download something and actually run it, which is a really good way of making you think twice before opening just anything up on your screen.
When you are creating your own website whether it is a business or personal site you want it to work and you want it to safe, the great part about making your own websites is you can basically decide how you want everything to go, if you are alone on this learning some coding would help but never the less you make the rules and ideally you want other people to be able to access and view your website with ease as well as not having some irritating pop in the corner every two seconds so when you are specifying your requirements bear in mind all of the irritating things that make you want to leave a website.
To Hackers are everywhere and just think it really doesn't take that long to let your software update it's like a fresh coat of paint everyone feels better afterwards the computer was able to in a way learn a little more and you have allowed yourself to be more secure, so every time you go no to a new website you don't have to worry thinking you have opened up a world of problems for you and your system. Thinking from a business perspective the signs people look for when not trusting a site make it safe and friendly so they can just discover who you are.
Week 6 Lecture
In week 6 we moved onto requirements engineering and in this we started off by discussing the definitions of engineering and what it means to be an engineer. Moving on from this we started to talk about the need for engineering and we look at a slide which showed the needs for example; Reduces misunderstanding, this occurs due the ability to make a system which is more compatible to the user and if the system is fit around the users it is better for both parties. We then looked at what is needed to make a good design of the software through looking at requirements, in this we looked at a sketch called ‘Dilbert’ by Scott Adams which showed what happens if you don’t have requirements before you begin to look at designing something. It seemed crucial and on the next slide it showed percentages of why projects failed and ranking at the top at 13.1% was ‘Incomplete requirement s’ showing the need for requirements. We then was shown examples of project failures and it was about “universal credits” a scheme which was seen to bring six benefits schemes together had been originally estimated at £6m but rose to £40.1m and further may increase to £90m and with that it has fallen behind schedule and will not be complete by its original timescale in 2017. Finally we looked who is involved in the requirement process and we discussed that the stakeholders would be a major player and what requirements are EG: User level facility etc. And then looked at how we can acquire these requirements and look at methods such as interviews etc.
Week 7 lecture
In this lecture we moved on reviewed requirements engineering and moved onto Systems development life cycle (SDLC), in the first part we reviewed what we did in lecture six and then got straight into SDLC and firstly looked at two models in the: Waterfall lifecycle and the Prototyping life cycle. With that we then went into more detail about the two and firstly talked about the Waterfall lifecycle: In this you break down projects into sequences;
•Feasibility study (Technical, Financial, Ethical)
•Systems Analysis and Design (Business needs, decision, design)
•Program and Unit Test (Programming)
•System and Acceptance Test (systems test – project team, acceptance test – users)
•Operations (Total Implementation, Phased implementation – through parallel system usage)
We learned that these sequences all need to be completed and signed off in order for the next stage to start. As seen in the brackets next to them it shows what actually goes into each sequence. We then moved onto Prototype life cycle and similarly it is split into sequences as well:
o Initial Prototype (Concentrate on core functions, demonstrative to the user)
o Test and discuss (Initial prototype quickly written and tested)
•Systems Acceptance Test (Testing the final for technical integrity)
•Operations (Installation of the system)
We then went onto discussing possible advantages and disadvantages of the two systems.
In my last post I declared my belief that the internet belongs to everyone and that we all have a responsibility to be more considerate with respect to what we put on the web and how we treat others. Since then I have recognised some ignorance on my part, because this should apply to not only what we do online, but should start with the development of the web itself.
Week 6’s tutorial introduced us to the topic of Web Accessibility and how we can develop our websites to be accessible to users with impairments that affect their interaction with the web.
I am embarrassed to admit that this wasn’t something that I had really reflected on much before. Our tutor explained how objects without descriptions, such as hyperlinks, images and tables, make accessing and interacting with the web much more difficult for visually impaired users. And it doesn’t stop there. Users with hearing, physical, speech, cognitive and neurological disabilities all experience accessibility barriers. Luckily though, there’s a range of ways that can help make content more accessible for everyone.
In the tutorial we looked at the use of ‘alt’ attributions within HTML code, which makes it possible for content publishers to describe what’s being displayed. We also tried using the 'Accesskey' and 'Tabindex' attributes which enable users to skip to a specific link using keyboard buttons.
In researching other ways to improve accessibility, I discovered that one of the most prevalent and earliest figures in web usage is Dr Jakob Nielsen. While most of his work focuses around general user experience and design, he brings forth some interesting and important ideas for creating sites with disabled users in mind.
He discusses this topic in an interview with ‘…For Dummies’ and ‘…In Easy Steps’ writer, Sean McManus (Nielsen, 2002). Nielsen discusses the importance of accessibility as an issue we’ll all come to be affected by as we grow old. He suggests the following tips for accessibility development:
Dr Jakob Nielsen (NN Group, 2015)
- Web accessibility is conveyed as expensive, but it’s not if you do it from the start! So aim for it right from the beginning.
- Consider using available software that assist in pointing out accessibility errors. However, where it can point out issues such as text size, it can’t identify content issues, such as poor descriptions, so keep that in mind.
- Avoid confusion and complication. Reduce the use of pop-ups or multiple windows. Visually impaired users won’t get the multitasking view.
- Keep it simple. If using in-site applications, focus on core features and reduce secondary features. This will improve usability for everyone.
- If visual layout and aesthetic expectations are restricting accessibility, perhaps develop a separate version, but ideally aesthetics should be combined with accessibility.
These tips used in combination with HTML attributions will help to develop a more inclusive web. With the World Wide Web becoming more accessible to a global range of communities, everyone should have the opportunity to give and receive content. It feels rewarding to become more informed and hopefully, this post can be of use to others!
Please also take a moment to watch this fun video on the importance of web accessibility.
It was created by the Australian government, but as this is a global issue, I still think the message is very relevant and applicable!
Nielsen, J. (2002) ‘Jakob Nielsen on accessibility’. Edited by S. McManus. Available at: http://www.sean.co.uk/a/webdesign/jakobaccessibility.shtm (Accessed: 19 March 2015).
NN Group, (2015), Jakob Nielsen [Image]. Available at: http://s3.amazonaws.com/media.nngroup.com/media/people/photos/jakob-nielsen_cropped.jpg.400x400_q95_crop_upscale.jpg (Accessed 19 March 15).