Essays collection 2012
Home Home SK
Group 7
Franta Martin

Abstract. The essay deals with risk management for Web-based projects. Web engineering, as a separate part of software engineering, has its own specific assumptions and resulting risks. Web applications creators faces to decision how to manage these risks, promptly react to user requirements at the same time and not losing market position. In the introduction, essay appoints possible risks involved with Web-based development. It focuses on risks of leading development and compares them to risks resulting from technology specifics in given environment. The essay presents the key questions that product owners and managers should pose before development begins, or before the final product is deployed. Risk management is approached with question how to lead project dynamically while responsibly.


Gajdoš Martin

Abstract. This essay deals with the issue of the work environment employee cooperation. Communication is the key factor, while creating product using mutual effort. It often determines if we achieve the final goal. Means of communication at workplace differs from those, we use at our spare time. That is why, we will try to focus on these differences and analyze them. We’ll set priority to those aspects, which can be influenced by communication manager and which have the biggest impact on the team efficiency. However, common means of communication won’t be our frontier. New, more sophisticated processes are emerging. Those can be utilized for more efficient teamwork. Put to use incorrectly, opposite effect could take place. So clarifying feasibility of their usage shall be another objective of this essay.


Habdák Martin

Abstract. Monitoring is often used for better project planning. It follows the state of the project and helps to uncover errors which cause problems in software development. Monitoring provides a view on team behavior too. We can rate it on the basis of collected data. Results can be inaccurate when improper metrics are used. This Essay describes how can such a vagueness lead to bad relationships in a team. Many well established metrics can be used by the team members to pretend that they have done more work. Therefore various conflicts emerge. They tend to reflect on the project development. Team morale and efficiency is also reduced. Project managers often use easy to follow metrics, which incite such team problems. This essay shows that such metrics are unsuitable and presents alternatives to their use.


Horváth Róbert

Abstract. Planning and scheduling are the activities we do in our everyday life and oftentimes we do not even think about them. Those processes take place not just in our life, but in software project development as well. To create a quality schedule, which is a necessity for further stages of software development, we can choose from several methods. It could be hard to choose proper method, which fits our project specifics, just by its definition. In this essay I describe my opinion on which method to use based on project specifics. I focus on their advantages and disadvantages. Problem is that choosing a right method does not guarantee creation of a good schedule. It is easy to make mistakes in the process, which could lead to failure. Therefore I identify the most common mistakes in process of planning to help managers with avoiding them.


Jurčík Peter

Abstract. Technical documentation is a substantial component of the overall product. Even though in comparison to software development it is regarded as of little importance. There are more reasons why this happens. Quality documentation is much more than just a user manual. It can provide valuable information for programmers and also for managers of development team. Writing of clear comments in source code is absolute minimum how can programmers contribute to the process of creating documentation. From these comments can be extracted the draft of the documentation using the tools for automatic source code documentation. These very comments are also helpful for programmers to better orientate in the created source code. Even the fact it is very difficult to measure the quality of the technical documentation objectively, we name the basic rules for producing high-quality documentation.


Kocian Róbert

Abstract. Requirements for faster software development and quality are getting higher and higher, so for programmers it is more and more challenging. Development of a high-quality and comprehensive application with continuously increasing requirements is extremely difficult task in this accelerating time so this situation requires the use of extreme development methods making this problem largely eliminated so it is possible to develop high-quality software in the shortest time. Appropriate use of pair programming depends on the size of the project as well as the size of the team. This leads to question. Is Pair programming a suitable method for small teams working on smaller projects? If so, is it possible to do pair programming in smaller teams in order to achieve the required criteria imposed on the project?


Macko Peter

Abstract. Part of each team project is communication of its members. Developing in team without communication is very difficult even impossible. Team without communication is early doomed. Coming of modern technology opened up new horizons for team members. Since the world is connected with network Internet delegated development is even easier and does not require a physical meeting of the team members. That's why I was in this essay focused mainly on the use of modern communication technologies in the team. These communication technologies I have divided into two main groups and tried to identify which group of communications technology is the right for a professional development in team. Last but not least I map the modern technology to work in a team as is group. I discuss their advantages and reasons for use them in product development.


Ruman Vladimír

Abstract. Formal technical review is of great importance for the quality control and for the development of software as such. Formal technical review is a formal meeting of a group of people, whose task is to discover potential errors and problems, whereby the quality of the given software product increases. The people participating in the review have human features and shortcomings that influence the process and the success of the whole review. For this reason it is useful to ask questions, whose answering could help to increase the usefulness and the quality of formal technical reviews. Which mistakes causing problems should be avoided? How to motivate the participants of the review the best? How to conduct the review most considerately of the people? I give answers to the raised questions, based not only on the experience and knowledge of experts in this field, but also on my own opinions. In the essay I deal with the well-known and frequent problems that occur during the formal technical reviews and I discuss their possible solutions.


Sládeček Peter

Abstract. In the execution phase of a project, the hidden mistakes are brought into the creating solution. If they are not discovered, they brought the fatal consequences like an unsuccessful release of the project. The mistakes can be eliminated at the beginning with an application of monitoring metrics, when their fixing takes just a few hours. So why do project managers not make more effort and finance costs to the monitoring? Do they worry about inefficiency, which are adopted? Do they hold an opinion, that planning and managing are the sufficient conditions of the successful? A main goal of this essay is brought the readers to the necessity of using monitoring in small and big teams. It will be showed that managers can be use received information in the planning and managing this or future project.


Ubreži Maroš

Abstract. Supportive measures are now an integral part of the process of developing new software. One of the most important is a version control system. Thanks to him, more people can work organized on a project at the same time. But how to choose the most suitable for our project? First, you need to choose versioning approach. Nobody will ever tell you that one approach is certainly better than the other. The choice always depends on the specifics of project. Based on my own experience and opinion of experts, I discuss the basic needs of business, school and community team. I identify the approach that best supports them. Then it is necessary to choose a particular tool from selected category. I think about questions whose answers provide guidance and help in choosing the most suitable. Reading this essay you will find out that when it is appropriate to use a centralized approach and when distributed. And also reasons why I claim this. When you will be choosing a particular tool you can use the answers from questions.


Vacula Matúš

Abstract. Software project in its life-cycle encounters numerous risks. One of the considerable risk are human resources. Each team-member has his own individual skills (e.g. programming, organizing or communication) and individual commitment to do his best. It is very difficult for manager of a newly formed team or fresh manager of an already existing team which he is not familiar with to estimate the capabilities of the team when a crisis shows up. This situations can be prevented by performing a stress test on the team. Test would not only evaluate employees' performance but also identify the hidden flaws in the processes of the project. The test results can help to reach more precise planning and quality risk management.


Vrablecová Petra

Abstract. Support tools are very important part of software development process. They can be seen as another team member who helps us with software development. But many teams do not see them this way and take them for granted. Hence they attach no importance to the choice of these tools and they do not realize what consequences they will take if they choose badly. This essay describes how poor choice of tools to support software development process can negatively affect project resources, time, etc. and what criteria should be considered during the tools selection process. Before the team chooses a tool, an analysis of team requirements, team resources (technical, financial, etc.) and team itself (experience of work with tools, preferred tools, learning ability, ability to perceive and process information) should be performed. Considering mentioned criteria evidently helps to choose the right tools to support software development process. The right tools can be seen as the reliable team member and helper rather than an enemy who steals your time.


Zimová Zuzana

Abstract. Essay discusses the graphical representation of the project plan. More detailed Gantt chart is given, in particular its use software project planning. It discusses how is it possible to avoid some risks that occur in software development, especially in terms of planning, by using the Gantt chart. It addresses the particular risks of the project delays, inadequate distribution of tasks between team members and risk team members who threaten completion of the project on time. Layout of the project using Gantt chart allows you to view a comprehensive overview detailing the tasks to individual members with their lifetime expectancy. It also allows you to view time spent by team members with tasks and allows detecting late termination of tasks. At the end of the essay there is a summary of the reasons for which the use of a Gantt chart for project planning is appropriate.


Left Separator
monitoring software project metrics function points plan planning software product risk management test driven development error effective communication sofware metrics software development team problems development software quality development support management extreme programming pair programming Scrum communication relations control progress subversion git critical path method project planning estimation agile development risks motivation requirement collection testing use case points support tools support tools outsourcing team size estimation version management quality cooperation risk documentation project software versioning conflict