Of the two different approaches to process improvement, the agile approach makes the most sense to me. In general, throughout the development process there will be many changes. Although requirements should be defined before development even starts, it's important to be aware that there will be changes to those requirements many times. This will prove to be especially true if the company keeps in frequent communication with its customers. There should be a constant stream of feedback at every major milestone in the project.
Despite even the best organizational efforts, a project's prototypes, requirements, expectations, etc will change. This is not a bad thing, a project should be flexible and changing. Although development will begin with a clear goal in mind it's important to not be so focused on that goal that you ignore any other input or variables. Perhaps in the midst of developing a feature you discover that there is an open source project that does much of the same. Potentially you could apply the sunk cost fallacy and think "well I've already worked so much on this feature. I should just finish it." Or you could be reasonable and agile: consider the consequences (good and bad) of either continuing your development or adopting this open source library.
Unfortunately due to strict deadlines, oftentimes there will be trade offs to be evaluated. It's important to look at all potential results of a decision. This requirement could be made better with x improvement, but we would have to switch development gears and potentially lose some time. It's easiest to evaluate things that can be measured such as time, cost, people available and decide the best course of action from there.
Thursday, November 20, 2014
Thursday, November 13, 2014
Configuration Management
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.
The main factors that should be considered are prioritized needs, version control, external libraries + dependencies, documentation and package.
1. In change management there is a process of prioritizing and organizing needs by analyzing costs and benefits. The goal is to ensure that the system evolution is a managed process and not just allowed to grow in random ways.By keeping the requirements organized engineers can ensure that the work flow is well documented and organized.
2. Version management holds the most interest to me, and is very important. It is a wholly under appreciated skill to learn that, when mastered, can completely and vastly improve one's coding work flow. Branching is especially important, as you can hold stable code in one (usually master) branch, while you can test and break your code in separate branches (usually test or development). This removes the fear of losing or breaking your code, as you can always go back to a stable or older version. In addition if you commit regularly and have good commit messages then you can view a complete change log of code which can assist in rolling back any changes, or simply analyzing your work flow. If version control is done well then it can be integrated seamlessly with the final build and keep everyone better organized.
(Side note: After learning to use SVN I still maintain that git is much better to work with!)
3. External libraries and dependencies are becoming increasingly popular in their integration with systems. Especially with the increased use of open-source code there is a declining need to re-write processes or libraries, because there is always something out there that will do the same thing. In addition that open-source library will have a support system, documentation and a community behind it. Because of their use however, one must ensure that their system works well with those dependencies. If there are version or integration issues then it's quite bad.
4. Documentation is very important. It must be complete enough to allow anyone to construct the system, preferably it will be automatically generated at every step during the development process.
5. The package is a conglomeration of the previous four elements. At this point it is important to check that everything is functioning, versions and dependencies are working correctly together. The package should be generated properly with no errors.
The main factors that should be considered are prioritized needs, version control, external libraries + dependencies, documentation and package.
1. In change management there is a process of prioritizing and organizing needs by analyzing costs and benefits. The goal is to ensure that the system evolution is a managed process and not just allowed to grow in random ways.By keeping the requirements organized engineers can ensure that the work flow is well documented and organized.
2. Version management holds the most interest to me, and is very important. It is a wholly under appreciated skill to learn that, when mastered, can completely and vastly improve one's coding work flow. Branching is especially important, as you can hold stable code in one (usually master) branch, while you can test and break your code in separate branches (usually test or development). This removes the fear of losing or breaking your code, as you can always go back to a stable or older version. In addition if you commit regularly and have good commit messages then you can view a complete change log of code which can assist in rolling back any changes, or simply analyzing your work flow. If version control is done well then it can be integrated seamlessly with the final build and keep everyone better organized.
(Side note: After learning to use SVN I still maintain that git is much better to work with!)
3. External libraries and dependencies are becoming increasingly popular in their integration with systems. Especially with the increased use of open-source code there is a declining need to re-write processes or libraries, because there is always something out there that will do the same thing. In addition that open-source library will have a support system, documentation and a community behind it. Because of their use however, one must ensure that their system works well with those dependencies. If there are version or integration issues then it's quite bad.
4. Documentation is very important. It must be complete enough to allow anyone to construct the system, preferably it will be automatically generated at every step during the development process.
5. The package is a conglomeration of the previous four elements. At this point it is important to check that everything is functioning, versions and dependencies are working correctly together. The package should be generated properly with no errors.
Quality Management
Quality management and assurance is a very important and often overlooked portion of software development. It is important to hold your software up to a certain standard and ensure that any requirements are not just lazily fulfilled, but are fulfilled to the best capabilities of the developers.
In larger organizations there is often a dedicated quality assurance team that is responsible for testing and finding ways to optimize previously developed code. In order to assist this team there must be some level of organization. Firstly you want to initialize an organizational framework, then apply specific quality processes and lastly establish a quality plan for the project itself.
Quality assurance and quality management vary from place to place, sometimes there is a huge focus on it and sometimes not. Sometimes QA and QM are separate branches, and sometimes they are one in the same.
There is not much of an emphasis on QA in schooling however. We are often told that there may be a better or more optimal way to do something, but it is not an emphasis. A few classes have mention of optimization (going over the best sorts and searches, O(), etc). It would be nice to be directed in how to look for ways in which to improve the quality of our code. Many a time I have looked at code I've written years ago and gone "oh no". I understand that we begin with learning the basics, but we aren't told what to look for in cases of improving our code quality, it's a bit of trial and error in learning this.
In larger organizations there is often a dedicated quality assurance team that is responsible for testing and finding ways to optimize previously developed code. In order to assist this team there must be some level of organization. Firstly you want to initialize an organizational framework, then apply specific quality processes and lastly establish a quality plan for the project itself.
Quality assurance and quality management vary from place to place, sometimes there is a huge focus on it and sometimes not. Sometimes QA and QM are separate branches, and sometimes they are one in the same.
There is not much of an emphasis on QA in schooling however. We are often told that there may be a better or more optimal way to do something, but it is not an emphasis. A few classes have mention of optimization (going over the best sorts and searches, O(), etc). It would be nice to be directed in how to look for ways in which to improve the quality of our code. Many a time I have looked at code I've written years ago and gone "oh no". I understand that we begin with learning the basics, but we aren't told what to look for in cases of improving our code quality, it's a bit of trial and error in learning this.
Monday, November 10, 2014
Reflection on Team Progress II
Since the last reflection on team progress there has been a slight decline in team communication. I suppose this could be attributed to the fact that there was little to discuss, as we completed the code portion of the deliverable well in advance. I would have liked to have been a bit more proactive and completed the written deliverable early as well, but as I said, there wasn't a lot of communication despite some efforts on my behalf.
There was also fall break right before the deliverable deadline, so that was another factor. In the end we completed the deliverable the day before it was due, with little issue (thankfully).
These concerns were something we foresaw in the beginning. We did identify that deliverable 4 would hold the most potential for procrastination due to that fall break placement. But it was completed on time and I suppose that's all we can ask for.
I hope that we will have a bit more involved participation and communication for deliverable 5 and for the final project.
There was also fall break right before the deliverable deadline, so that was another factor. In the end we completed the deliverable the day before it was due, with little issue (thankfully).
These concerns were something we foresaw in the beginning. We did identify that deliverable 4 would hold the most potential for procrastination due to that fall break placement. But it was completed on time and I suppose that's all we can ask for.
I hope that we will have a bit more involved participation and communication for deliverable 5 and for the final project.
STM Career Fair
The Science, Technology and Math Career fair was a wonderful addition this year. I had attended the regular Career Fair in years prior, and while there were a few participating companies who were looking for Computer Science students or students with specific technical skills, the majority of companies were seeking employees with other skill sets.
The STM Career fair was a vast improvement, not only because of the inclusion of several local tech companies (most of which I was interested in working for) but because of the fact that they had developers representing those companies. Previously, there would only be HR representatives, or individuals with limited technical understanding of the companies. I would merely get handed a pamphlet or told to look online. None of the non-technical individuals could answer questions regarding the companies in a technical manner, ask me relevant questions, or tell me in-depth about the positions they were hiring for.
Since developers were present at all of the booths I stopped at, I was able to have relaxed conversations regarding the company, what they wanted, what they did, why they enjoyed it, etc. It wasn't a one-sided or stilted exchange of superfluous pleasantries, it was an actual conversation between knowledgeable individuals. That really made all the difference for me.
The one thing I would hope for the future is that they bring more companies in and that teachers encourage their students to attend. Career fairs can be an invaluable way to get your foot in the door at a company you're interested in working at.
The STM Career fair was a vast improvement, not only because of the inclusion of several local tech companies (most of which I was interested in working for) but because of the fact that they had developers representing those companies. Previously, there would only be HR representatives, or individuals with limited technical understanding of the companies. I would merely get handed a pamphlet or told to look online. None of the non-technical individuals could answer questions regarding the companies in a technical manner, ask me relevant questions, or tell me in-depth about the positions they were hiring for.
Since developers were present at all of the booths I stopped at, I was able to have relaxed conversations regarding the company, what they wanted, what they did, why they enjoyed it, etc. It wasn't a one-sided or stilted exchange of superfluous pleasantries, it was an actual conversation between knowledgeable individuals. That really made all the difference for me.
The one thing I would hope for the future is that they bring more companies in and that teachers encourage their students to attend. Career fairs can be an invaluable way to get your foot in the door at a company you're interested in working at.
Project Planning
As mentioned in the previous blog there are several challenges that can occur when planning and organizing a project. If these challenges are well understood then they can be met and dealt with during each stage of planning. Regarding this, the book mentions the several stages in which the project manager must plan and re-plan. These stages are: the proposal stage, the project startup phase and periodically throughout the project. It's important that during all stages of planning, the manager and the proposed plans are very flexible. Due to the ever changing nature of software and development it's important to be ready to change plans at any point.
Often times a plan developed during the proposal stage will sound great, and the manager will be resistant to change. Again, the importance of the manager having the same or similar understanding as the developers arises. It is important that the manager listens to any concerns brought up by the developers, especially if they don't have that all-encompassing understanding. Problems will always occur, and sometimes a plan at the beginning will not hold up under the stress of ongoing development.
Additionally, at the start of planning, it is important to have a good understanding of all of the requirements. Having good foresight will assist in having a strong plan that will require fewer adjustments as the project evolves. Organization is of tantamount importance and as long as the requirements are understood the plan will hold up well.
Often times a plan developed during the proposal stage will sound great, and the manager will be resistant to change. Again, the importance of the manager having the same or similar understanding as the developers arises. It is important that the manager listens to any concerns brought up by the developers, especially if they don't have that all-encompassing understanding. Problems will always occur, and sometimes a plan at the beginning will not hold up under the stress of ongoing development.
Additionally, at the start of planning, it is important to have a good understanding of all of the requirements. Having good foresight will assist in having a strong plan that will require fewer adjustments as the project evolves. Organization is of tantamount importance and as long as the requirements are understood the plan will hold up well.
Project Management
There are many considerations to be made when managing a software development project. Sometimes there can be a conflict of interests and goals in keeping within the budget, keeping within a deadline and meeting the expectations of the customer. In the process of software development there is a lot of potential variability. Sometimes, despite extensive organization and management efforts projects can run over budget, be unfinished before deadlines and generally become a big mess.
It is not always possible to define or determine the potential limits for a specific project. This can be especially difficult if the project manager is not knowledgeable regarding the technical limitations of a development project. A task may seem simple when it is in reality complicated, and deadlines set based on limited understandings may create unreasonable time constraints on developers.
There are also complications that can crop up often between individuals working on a project, especially in software development groups. A project manager must be knowledgeable on everything being done by each member, and help facilitate communication and collaboration between each person in the group.
The software development process varies between each organization, it's different for every business, every team, and every individual. This means there are no general guidelines for defining deadlines or organizing teams. Everything will change on a case-by-case basis.
It is not always possible to define or determine the potential limits for a specific project. This can be especially difficult if the project manager is not knowledgeable regarding the technical limitations of a development project. A task may seem simple when it is in reality complicated, and deadlines set based on limited understandings may create unreasonable time constraints on developers.
There are also complications that can crop up often between individuals working on a project, especially in software development groups. A project manager must be knowledgeable on everything being done by each member, and help facilitate communication and collaboration between each person in the group.
The software development process varies between each organization, it's different for every business, every team, and every individual. This means there are no general guidelines for defining deadlines or organizing teams. Everything will change on a case-by-case basis.
Subscribe to:
Posts (Atom)