Why did I create this blog?
During my second year of bachelor in Computer Science I studied in the United States for a semester, thanks to a scholarship sponsored by the Erasmus+ Program. My home college, Free University of Bolzano (IT), has several partner universities in Europe and around the world and offers exchange opportunities through the so-called “Bilateral agreements”.
So I spent five months at College of Charleston (SC) during the Fall semester 2015 and I attended some courses required by my home university program. Among these was Software Engineering (aka CSCI-362) taught by the amazing professor J. Bowring.
As homework assignment we had to answer questions taken from the book Software Engineering by I. Sommerville, and often add personal thoughts and reflections as well.
This blog, which every student had to set up and use to publish their answers, is the result of a four-month-long work focused on software analysis and development, theory of computer science and also technical writing. The latter was perhaps the most challenging aspect at the beginning, since English is not my mother-tongue.
Although some posts might appear purely academic, some others include more interesting reflections that I believe are still worth some space in my personal website – if only to remind me my great days in Charleston.
Hope you enjoy it 🙂
Some cool stuff:
College of Charleston
Professor J. Boring
Software Engineering course page – Fall 2015
25.10. Describe five factors that should be taken into account by engineers during the process of building a release of a large software system.
Important factors that engineers must take into account when building a software release are:
- System quality: if the actual version of a system has problems that many users experience in large scale, a new version to fix the reported errors should be developed;
- Platform compatibility: the same program may not be compatible with different operating systems or may not work properly. A new release can be developed to adapt to different systems or work on updated versions of the same ones;
- Customer change proposal: specific changes and additional requirements in a program can be explicitly requested by the customer, in order to be released as soon as they have been developed;
- Lehman’s law: an important change in a program, for example the introduction of a new functionality, may introduce new bugs that affect the overall performance of the system. A software release should take into account all these changes and fix any problem that it may cause;
- Marketing and competition: market plays a major role in maintaining a program. For instance, software developer may decide to develop a new release to stay ahead of a competing system.
24.6. Explain why program inspections are an effective technique for discovering errors in a program. What types of error are unlikely to be discovered through inspections?
Inspecting a program means reviewing and checking it by a team member who has not directly dealt with that code, therefore he can judge it “from outside” with a more objective point of view. This process is useful to find bugs and faults, because it is based on a checklist and follows standards practices and techniques.
However, engineers who use extreme programming argue that pair coding is more effective: in program inspection an external team member may not be able to find deep errors that require a complete knowledge and understanding of the code, which could increase the time and cost needed. Instead, two pair programmers work on the same code at the same time, which increases the likelihood that a fault is immediately corrected, since both programmers have a deep understanding of the program.
I took part in many group works during my school and university career and I think these have always been the most challenging projects I was assigned to. Someone could say that “unity is strength” and if one person can complete a task in a certain amount of time, four people should be able to do it much faster and maybe with a better result. Unfortunately, I realised that this is not always true, especially on one occasion: my team was born spontaneously, without the “imposition” from a professor. I thought that a group of close friends would have cooperate as a single body, yet there never was that total, reciprocal understanding I hoped. I believe the reason in any case is that team means a group of people with different skills, experiences and thoughts.
This, however, has a big advantage: even if one member has more abilities and is able to take charge of much of the work, for the other members this represents a great occasion to expand their knowledge. I think it is the case of our team: some of us know more about Linux, for example; however every time a problem or a question arises, who has more knowledge makes it available to others, and each member seems willing to get involved and learn new concepts and skills.
Our work on the project is progressing well. So far we have managed to meet the deadlines and now the testing framework has all the 25 test cases: next step will be voluntarily injecting controlled faults in the software code, as “counterexample”.
From now on I think we should focus on providing an adequate documentation, which was proved to be one of the greatest weaknesses of the project, so that the final report can be coherent and well understandable.
22.6. Fixed-price contracts, where the contractor bids a fixed price to complete a system development, may be used to move project risk from client to contractor. If anything goes wrong, the contractor has to pay. Suggest how the use of such contracts may increase the likelihood that product risks will arise.
Fixed-price contracts may increase the amount of product risks, because the development price can only be estimated but not strictly established a priori. Unexpected problems may arise and each unforeseen event has a cost that affects the budget: financial resources cannot be endless of course, but in a fixed-price contract an unexpected cost must be subtracted from the total resource. If a part of the system requires an higher cost than estimated, developers will be forced to save money on the remaining components, and this will affect and likely damage the overall performance of the system.
21.4. Explain why an object-oriented approach to software development may not be suitable for real-time systems.
As our text well explains, in object-oriented programming data representations and attribute are hidden “inside an object” and cannot be directly accessed, unless a definite method of that object is invoked.
The need for additional code to obtain these data negatively affects the performance of the entire system.
This is why real-time systems require a different approach from the object-oriented development.
17.10. Your company wishes to move from using desktop applications to accessing the same functionality remotely as services. Identify three risks that might arise and suggest how these risks may be reduced.
Three common problems that may arise when a software is remotely accessed and not allocated on a physical device could mainly affect the availability and the security of a system.
If many users access the remote service at the same time, the overall performance of the system may be damaged, because of a network unavoidable delays. Additionally, if a failure occurs on a desktop application only that machine will stop working properly, whereas if the general systems fails then every connected machine would no more be able to access it until the problem is fixed.
Therefore, an effective distributed system should be developed in order to be as much fault-tolerant as possible, so that when a problem occurs the system will not completely crash but will maintain some functionality. Moreover, a remote service could be stored on multiple, independent servers, which would help maintain the availability and manage many simultaneous users.
Since distributed systems are based on networks, security is an important issue, because a remote service might more easily be attacked and personal data could be intercepted and stolen. In this case an appropriate encryption of these data should be very helpful to make the whole system more secure.
Sometimes system requirements must be modified due to new necessities that arose at a later time, and this inevitably causes a cost. However, usually experienced developers are immediately aware that the requirements were formulated in a poor way and they will likely require expensive changes: I think that silencing on these problems and taking advantage of the needed modifications to charge a higher cost means at least bad faith, which is considered unethical from the perspective of a developer.
Software development is a very complex process that often requires an unforeseen additional cost: a costumer should have a guarantee that he will not have to pay an unnecessary cost for changes that could have been avoided through more transparency during development.
19.3. Why is it impossible to infer the emergent properties of a complex system from the properties of the system components?
A complex system is not simply the sum of all its parts, since there are emergent properties that belong to the whole system and not to one or more particular components. The emergent properties can be functional (a program produces some output thanks to the interaction of all its components) or non-functional (properties like dependability, safety, performance…) and they can be inferred only when the parts have been put together as a unique system, because they depend on the components and on the relations among them.