This is a podcast of my thoughts about this awesome book while I compare it with the book that we’ve been discussing through all the series. Hope you enjoy it.
Podcast: Click here!
The Mythical Man-Month
Author: edygtzblog
The history repeats itself
We’re born, we grow, we have children, we die, and our children repeat the cycle, and the cycle repeats over and over again; thus, that’s the circle of life (Lion king music in the background). So we reach the final chapter of this awesome series where I and my gorgeous way of writing, told you bedtime stories about software development and the staged delivery method.
As everything begins, it must certainly end, and as well as this series of blogs, once you have survived and succeeded on delivering your project to your client, it’s time for you to gather the pieces of your exhausted, but triumphant team, and start gathering the experience that will make your personnel grow and future projects easier.
Gathering Data
After the storm has calmed you need to make some question to your team on what they think it worked well, and what would they like to be changed. This might be a subjective impression, but it’s very important to take it into consideration, not only for keeping your team happy but they might be right and you might not notice. Do it quick, cause the most recent impression is what counts.
Review meeting: this method is good for having a continuous discussion and debate of the different ideas and opinions. Maybe someone is right, maybe they had a wrong view of the problem and change their mind. The important thing is to listen carefully and have a good moderator so that everyone’s point of view is heard.
Review Questionnaire: another good, and more individual oriented reflexional, method is a questionnaire. This can be sent by e-mail and the data can be stored electronically and used for analysis later. This method can use a more specific approach through certain target questions and also can have a more honest feedback if it is solicited anonymously.
Project History Document
At the end, quantitative and qualitative information about the project needs to be stored somewhere to be used in future projects. This will become the pillars of experience that will make other projects less difficult and make better estimates on time, money and personnel.
The Project History Document should include the following:
- Introduction: software purpose, vision, statement, detailed objectives and general information.
- Historical Overview: Describe all the phases, project planning information that was used, milestones and major risks addressed.
- Project Data: This describes the executive sponsors, organizational structure, project participants, and the defined roles.
- Lessons learned: described the mistakes that were made and the lessons that were learned.
- Conclusion: list future things to be addressed in the preliminary planning, and also list the top ten risks that were identified through the project.
At the end, distribute a copy of this document to everyone involved in the project. Its objective is for everyone to learn of their mistakes and their achievement, and have a personal growth.
Nasa’s success checklist
For the cherry on top, the book summarizes all of the books teachings into a list of to do’s a not to do’s based on the Nasa’s software success checklist. What kind of guy will I be if I don’t share it with you? I’m not THAT evil… Am I?
Do’s
- Create and follow a software development plan
- Empower project personnel
- Minimize the bureaucracy
- Define the requirement baseline, and manages changes to it
- Take periodic snapshots of project health and progress, replan if necessary
- Reestimate system size, effort, and schedules periodically
- Define and manage phase transitions
- Foster a team spirit
- Start the project with a small senior staff
Don’ts
- Don’t let team members work on unsystematic ways
- Don’t set unreasonable goals
- Don’t implement changes without assessing their impact and obtaining approval of the change board
- Implement only what it’s required
- Don’t overstaff
- Don’t assume that a schedule slip in the middle of a phase will be made up later
- Don’t relax standards in order to cut costs or shorten schedules
- Don’t assume large amount of documentation ensures success
I’m such a good guy. As you can see these topics were addressed throughout the series maybe with different names. They’re there and I encourage you to find them. It’s time to say goodbye, but I’ll be back with more interesting stuff I promise. Hope you’ve find this useful. See ya later folks.
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
Experience, learn, move forward and repeat
There’s something in videogames that sadly life doesn’t have, that’s called a checkpoint. That’s right, that beautiful part of the game where a weird icon appears, normally in a corner of a screen, that indicates 2 things. The first one is that something that will make your progress more difficult is about to happen, and second, that you’ll probably die a lot of times and that it’s a good planning point to rethink your courses of action and strategies in the case of it. Videogames give you an infinite amount of chances to learn from your mistakes, maybe polish a strategy or change your view entirely. Sadly, life is not as good guy as videogames are. Life doesn’t give you a second chance to repeat a scene or a moment, if you did wrong, you did wrong, and you can’t keep on repeating until you get it right. Time is linear and the only thing you can do is get the fullest of the experience, learn and try to not make the same mistakes in similar, yet not equal, situations.
Nevertheless, what life does allow us is to take a certain amount of time to meditate our course of action. It’s not that of a douchebag that will keep enemies spawning and not giving any armor. No, life is comprehensive to a certain point, and in the stage delivery method, each end of stage is a good “checkpoint” to meditate our agains and never-agains so that we don’t keep repeating the same errors over and over again. Thank you not so douchebag life.
Propose changes and recalibrate estimates
The end-of-stage wrap-up is a good moment to speak up. If you would like to propose a change in the process or aggregate a certain feature there’s no better time for this than when things are going to be replanned and the pace has slowed down a bit. This end-of-stage part can be also a great moment to better prioritize some change proposals. It’s important that to have a moment of meditation like this one because if changes and aggregated features where continuously proposed during the middle of the stage, the change board will have continuous work and many deliverables will be put on hold until the changes are decided. These little holds will add and add up until they’ll generate a serious schedule slip.
It can also be a good moment to evaluate the project schedule performance against the actual performance and recalibrate some of the estimates that were made at the beginning of the stage by examining some of the factors that were taken into consideration in the creation of the first estimate. Consider the next questions:
- Have the features, level of performance or robustness of the project changed?
- Has the development team been as productive as expected?
- Have some of the necessary tasks omitted from the estimates?
If the project has taken more than expected it’s time to start wondering what changes need to be made and if an schedule or budget extension is necessary. Be sure to know the difference between a reestimation and a slip. A reestimation is more of a refinement of the current resources of the project for a better productivity, while a slip is an error in the estimation. Make sure to educate your stakeholder into knowing the difference and it’s very important that you understand that if a budget or a schedule slip has occurred you NEED to reschedule, it’s is well known that projects hardly compensate for the lost time. So never think is that easy as to catch up.
The project plan needs to also be taken into consideration in this part. You need to start evaluating the progress made against the vision that was discussed in the project plan. It’s common for teams to abandon the project plan because of the following reasons.
- They can find the plan
- The team was not involved in the plan creation.
- The project isn’t humanly achievable
- The plan is not updated
If you developed a good project plan that doesn’t stress the team in the ways discussed above, then the end of the stage is an appropriate time to compare your progress and maybe update the project plan if the vision has change drastically in order to always have a global and common view of the goal.
Archive project media and update the project log
At the end of each stage there should be archives of all the resources and materials that were used to create the software until that point in time. Should the need arise to go back to the version of the software at that point in time, there should be all the necessary documentation to achieve it. The project should archive its progress in the following:
- CD’s, packages, diskettes, documentation and collateral material.
- Source code and version control
- Database and datafiles
- Commercial libraries and resource compilers
- Graphical materials like videos and sound resources contained in the video
Also, effective organizations collect all the information that can be collected from the project. This information can have a use in future projects and can serve a good picture of the dynamic advance that the project has had since the beginning.
So, experience the best of it, learn from both achievement and errors, and keep track of everything because it will help you take wise decisions in the future. Life doesn’t have a checkpoint and the only wrong path there exist is the one that is taken based on ignorance. Be cool.
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
The wingmen
Imagine yourself at a bar, there’s a beautiful/handsome girl/guy and you want to conquer her/his heart with your sparkling personality, but he/she is surrounded by his/her hideous friends that won’t let you get nearby. You need someone to help you take the target friends far away, to create a distraction and give you the opportunity you’ve been mourning for. That angel in disguise is called a wingman (either men or women are called like that… I think). He creates the distraction you need in order to get close to your target and whether you achieve or not your goal it’s up to you, but you can’t deny you got all the support that you needed, and you know who also need a lot of support to achieve the quality desired in the code they’re developing? Developers of course, and you know who are their wingmen? Testers.
Testing and why is important?
Sometimes you’re so drunk in love by your own creation that you can’t see all the errors and defects it has. Sometimes you just need that outsider look that gives you objective feedback, and that is the testers job. In order to achieve the desired quality for the project, and for it to accept and integrate more code there needs to be a certain testing process that assures that quality and that can guarantee that the code won’t break with further integration of more code. This can earn a lot of debugging hours in the integration testing, because if it unit is correctly tested, then you can be sure that the only thing you need to test is integration problems and not unit problems. Your schedule and budget will thank you later.
The testing way of life and how much is enough?
Testing is not a process but a way of living (or a coding approach). There’s actually little respect for this activity. Many developers think that if the program compiles and a certain input generates the correct output, then the program Is perfect, and it will never crash. This is an utterly wrong way of thinking. Without the adequate preparation for testing activities, the software will surely be released with a set of yet-to-be-found errors.
Basically, the quality of the program depends mostly on the testing activities. System testing should test the entire scope of the program so that it can assure that in all lines of code an error doesn’t exist. Each little unit should have its own test cases and also each stage should have and integration and regression testing where the whole unit integration are tested and also the interaction between new code and the old code. This makes error count reduce largely.
Daily testing and developer support
There needs to be testing on a daily basis and it’s called smoke testing. Normally, each day the developers will make a build of a code, and that code need to be thoroughly examined and stressed so that its quality can be assured. A smoke test refers to a half an hour or less testing procedure that in case of the build not passing it, it will be kicked back immediately to the developers for quick correction.
Developers need to support the testing philosophy as well on the daily basis so smoke test failure don’t become a recurrent habit. In order to develop a fast but not buggy performance of the team, it’s is recommended that you force programmers to maintain their error count under 10 before declaring a build ready for smoke testing. Programmers won’t like this way of coding because they prefer the creative process more than the repairing process. Nevertheless, they need to guarantee at least a certain amount of quality even before testing, this will make the tester’s job easier, making them focus on real problems and not sloppy ones, also their teammates job, when integrating their code with others code they can spend less time fixing someone else’s code and focus more on developing and testing theirs.
Strategic quality assurance
It’s the case, that sometime some procedure, stage or programmer will generate more errors. This of course are caught in the testing process, but testing can serve not only as a net to caught these errors, but also to take strategic actions to raise the quality of a certain process, replanning if necessary of giving a programmer an extra help or orientation as needed.
As the book tells us, 80 percent of the time is spent on unplanned work activities and rework. Focusing a small amount of time on performing strategic replanned rework will greatly improve the project overall productivity into a more quality oriented process.
Now that you know the hard lives that the testers need to endure for the project, is time to have some respect for these unsung heroes. You might as well learn a thing or two about them and start seeing the world through their eyes, a world full of bugs that need to be corrected in order to achieve true happiness… glorious I dare say.
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
A whole new world
Hello everyone!
Today we’re going to change our usual method because I made you a prezi. Hope you like it because it was a pain in the…
Click HERE! => The Prezi
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
Divide et impera
In the middle of the war there’s no time for hesitation, there need to be quick actions and quick responses to enemy retaliation and the mission of the ruler is to stay calm and lead his army to victory. One famous phrase, and so ancient as well, is the rule of divide and conquer. This rule states that in order to achieve victory, it can be applied to war, politics and sociology; you need to divide the intended group, either a government or an army, into smaller more manageable groups in order to strike. Is easier to carry pieces of a rock than a huge block as well as killing a man is easier than a group of 20.
Applying this approach to software development it’s time to start analyzing how to break our project into manageable stages, and how to break those stages into even smaller parts called miniature milestone, and breaking THOSE MINIATURE MILESTONES INTO EVEN MORE, wait… that’s it, miniature milestones Is the atomic part. Well let’s see how to do it.
Stage planning and its parts
I know by this time around you’re absolutely tired of the word planning, but I swear that it’s something absolutely necessary. Please believe me! As I was saying, the beginning of each stage is about planning a detailed course of action; there needs to be and individual stage plan describing how to conduct individual design, coding, technical review, testing, integration and other needed activities. The most difficult part is to divide each stage into miniature deliverable milestones that help you track the progress of completion of each stage and the visibility status.
Stage delivery means turning a big project into little, more manageable projects, and each stage cycle being a mini project needs to be equally divided for a better management. Each stage planning is guided by the Software Development Plan described in the Preliminary Planning, and each time a stage is planned the detailed overview is annexed into it. Each stage should be divided and planned as followed, and these activities should be described on a Stage Plan
- Requirements updates
- Detailed design
- Construction
- Test case creation
- User documentation updates
- Technical reviews
- Defect correction
- Technical coordination
- Risk management
- Project tracking
- Intregration and release
- End of stage wrap-up
Each of these will be explained in more detail in future post, but the overview is that all of these need to be planned before each stage, so that each stage has a goal, a status, quality and serves as a pillar for the next stage.
Creating miniature milestones
In each stage you need, at least, to know where are you standing. You need to know how much you have left, and how much have you done. This is called progress tracking and is essential for the project completion. This is like the annoying kid that’s always asking if are already there, it might be annoying but at least he keep us asking ourselves, how much time so the kid to shuts up.
Miniature milestones are targets that project members and developers need to meet frequently. This is a way to generate motivation, helps the team focus on the most important tasks and generates a set of to do’s that need to be achieved at least once a week so that there is a constant progress on the project.
The completion of a milestone is binary, this means that it’s either done or not done. There are not halves or 90% done. If you know for certain that a task is done or not done you have good certainty of where are you standing, and how much its left to the end. The process of defining milestones is the following:
Create a milestone list
In defining a miniature milestone, the team needs to plan a route for the next major landmark. You need to trace the route with the information you can see. That’s why milestones are define 2 time during the project. First, you define the major milestones that will let you make it through detail design and when you finish it you define the second set of milestones to get through the software release.
The list should include every task needed that you can think about. There shouldn’t been any “off the list tasks”. The developers need to develop the good practice of putting all the work into revision and management. This way, during technical review, the milestone completion can be correctly track and any missing task can be tracked. That way incomplete milestones can be flush and put into revision in each review.
Achieving desired quality
Having correct quality control during milestone completion and review is essential for correct project progress. Having quality review helps rising the motivation on generating quality software because low quality software will not be accepted and the developers know it, so they’ll make an effort to pass the quality test. The quality control is the one that declares the milestone to be done or not. As we said earlier, there are not halves completed milestones, so this control helps to put a checkmark on a milestone or pass it to defect control. Allowing low quality software to be the pillar of a completed milestone will have a terrible effect on oncoming stages and other milestones. This will increase the effort on testing and correction that can affect the schedule tremendously. That’s why a tight control and quality culture needs to be fomented and apply in order to achieve the objectives stablished.
Concluding, in the beginning of each stage there needs to be more planning. Each stage needs to be subdivided into more mini goals that will let keep good track of the software progress. This will give correct visibility and also help us achieve the quality desired assuring that the project is right on track and that the schedule and budget are being used efficiently. Thank you. (Applauses in the distance)
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
The calm before the storm
There’s a certain calm that you experience when something is going to go inevitably wrong. The animals are silent, there’s no air waving, people stay inside their houses and the environment feels obscure and heavy. Some people say that this is the calm before the storm, before everything and everyone is violently threatened, and you need to put into test all the surviving skills that you learned in this blog. But, you still have time to prepare and grab any tool or resources that you might’ve forgotten. These are the final preparations.
Creating Project Estimates
After the quality and change boards are set, the preliminary planning has been done, the requirements have been stablished and the architecture designed, it’s time to start taking a guess on how much time, money and staff is going to be needed to achieve the project at hand. You need to have a good estimate in order to ask sufficient resources and the books suggests a series of rules of thumb to take into consideration while estimating.
- It’s possible to estimate software projects accurately so stay calm.
- Accurate estimates take time.
- Accurate estimates take a quantitative approach, preferably one supported by a software estimation tool.
- The most accurate estimates are based on data from projects completed by the same company that’s making this project
- Estimates require refinement as the project progresses.
Keep this rules as mantras because the estimation process could be a stressful one in certain steps are not taken into consideration, but good guy McConnell gives us a guideline so that we don’t stress ourselves to much. He says the following:
- The estimation procedure should be written.
- Estimation should include time for all normal activities (even sick days).
- The project plan should not assume the team will work overtime.
- Estimates should be created using estimation software.
- Estimates should be based on data from completed projects.
- Watch for estimates that developers don’t accept.
- The project team should plan to reestimate at several specific times during the project.
- Estimates should be placed under change control.
After taken into considerations the guidelines above, it’s time to set start dividing the project into deliverable milestones, so that everyone understands when and what should be expected to track the progress. The biggest milestones of this approach that need to be written down are the following:
- Architecture (Complete)
- Stage 1 complete
- Stage 2 complete
- Stage 3 complete
- Software release (assuming only three stages)
As we can observe, the estimation process is much complex that we might thought it was. Also, keep in mind that many parties will be affected by these estimations so be sure that all the stakeholder agree with the estimations given. You don’t want developers rebelling themselves or everyone quitting the company because you make them work overtime through most of the project because your estimations where wrong and you didn’t want to reestimate.
Writing a Staged Delivery Plan
The biggest milestones have been set, but stage 1 complete sound a bit too shallow. We need to be a little more specific, and for that, as always, planning is required. Under the process of this book we need to remember that the most important functionality is delivered first so that the user’s needs are met quick. The sooner the better, right? The first stage deliverable should take this into consideration and the rest of the stages should be designed under this concept and aggregate more functionalities on top of the first run. Thus, planning by stages needs detailed technical planning, careful management, and solid architecture.
An effective way of diving the deliverables by stages are dividing the project into themes. The approach that needs to be taken is to have in mind that it should be divided from most important functionalities first to the least at last. An example from the book of how a division looks like is the following:
As you can see, the sooner you can show the client that the needs are being met, the better. Of course, it’s not necessary to show the client the status of the project each stage. It’s better to have something more robust to show that just some lines of code or a useless interface. Unless your client ask to you should keep the meetings the further the better.
At the end, the stage delivery plan is just as any other document that we’ve been talking about. Make sure that it goes under change control, but also remember that this specific document will be on constant update. So, treat it as something that will be revisited many time.
Performing ongoing planning activities
The final preparation stage is also a time of checking if everything is still in good conditions, so we need to step back and revisit some of the previous activities that were stated during the preliminary planning, for example:
- Risk Management: As project tasks become better defined, so do risks. Be sure to update the top ten risk list to reflect what are the new risks that were encountered.
- Project Vision: Through careful planning, design and documentation the project starts becoming something more tangible and less conceptual. Many thing have been learnt and they need to be incorporated into the project vision.
- Decision Making Authority: It’s time to have all the issues and concerns put in the table again and make sure that the decision-making authority that was designated during the preliminary planning knows the changes and decisions that had been made since the first talk.
- Personnel: before starting the trip let’s check the wheels of our car, or the gears of our clock in this case. Is the morale up? Is there someone problematic in the team? Does everyone in the team feel comfortable with the challenge ahead? This is an appropriate time to assure that the team’s health is good state.
- Software Development Plan: The software delivery plan should be updated and revised as many things have been learn and modify since the first time it was created.
The tools have been checked, new provisions have been bought, and need that we didn’t know we had have been found. Can we be better prepared for the challenge that lies ahead of us? Maybe, maybe not. Experience will teach us over time, but right now it’s time to have a high morale and to have always in mind that we will survive the storm and return home triumphant.
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
I think this just might be my masterpiece
First there is the concept and then comes the sketching. That’s the process of every great masterpiece in this world. The artists can’t sleep, he has something up in his mind that doesn’t let him reconcile sleep. Then comes the divine illumination, where the artist knows exactly what he wants and need to sketch it, pull it aside his turbulent thoughts. At the end, comes the masterpiece, the expression of the idea, the peak of the creativity… the masterpiece. We’re not quite to the part of the masterpiece yet, but the architecture is the sketching part, let us talk about it.
What is Architecture?
The architecture is the technical structure of the project at glance. If you want to make the rest of the project easy, you want a good architecture, else please mess up this part, you’ll sure regret it. Or maybe this is one of those times we’re people who love terrible news, receive good news, am I right? Nevertheless, this is the blueprint part before the construction. In software development, we refer to the blueprint part as the phase where we describe the software with diagrams and prototypes, so that the developers get the general idea of what to code.
During this phase, the architecture special task team, sounds cool, divides the system into little subsystems, specify the interaction among them and document the technical plan of the software at a top-level. They also specify the correct approach to handle errors, memory specifications and technical overviews. This will help conceive, in a more smoothly manner, the integrity of the conceptual part in future stages
Characteristics of a good architecture
What makes a good architecture? How can we be sure we’re not drawing doodles instead of The Mona Lisa? Deep into the design the team will encounter certain issues that they need to address in the best way possible to achieve architecture quality.
System overview: the designers need to achieve a broad description of the system that encompasses all the important functionalities and requirements. Without this overview developers might get lost in all the specific details of modules and classes. A top-level view of the project must be there in order to show the way to any lost soul.
Conceptual integrity: the architects should conceive a solution in the most efficient and simple way as possible. Everyone should see the architecture and understand it to the point that everyone thinks that if they were the architect they could have done it as well. In order to achieve a good conceptual integrity, the architecture document should be short, easy to read and you should see how the solution fits perfectly and is not forced to fit.
Subsystems and organization: the architects should divide the program into few subsystems that contain the most important functionality and should specify with detail how these subsystems interact with each other, making their interaction achieve the intended goal. A good system partition is explained as followed:
The architects should address with seriousness the restraints in the communication between the systems. When the architects focus on the system simplicity they will spend more time restraining and taking away, that putting in.
Notation: This part is really simple but necessary. Notation refers to everyone understanding what the blueprints mean, and that everyone speaks the same language. Traditionally, this books suggests that the UML notation is the standard for large project, but for smaller project you’re free to use whatever notation you want as long as everyone understands it.
Change scenarios and change strategy: a good architecture should also address where is the design most likely to change and what to do in such case. How can someone predict a change? We’ll normally good architects can detect probable future changes through shaky requirements. Having a list of this requirements, how can they affect the design, and what to do in those cases is a key for a good architecture. Also, sometimes the use of a certain technology, such as a compiler or a language library, can create an unpredicted change due to deprecation, upgrade or the company that provided the technology went bankrupt. The architects should provide certain possible scenario changes and they shouldn’t rely in a specific technology.
Reuse Analysis and Buy vs Build Decisions: the book says that one of the most powerful ways to shorten schedule and reduce costs is by reusing existing software of buying components. It not only refers to source code, but also to documents, data, designs, test cases and plans. The approach to reuse or build will have a tremendous effect in the project. For example, if the project is meant to rely in a certain framework, all the design must take this into consideration. Therefore, this decision should be taken in the architecture stage and not on future stages.
Approaches to Standard Functional Areas: the architecture design should address the interaction between common functional areas such as the next: user interfaces, software interfaces, security, database organization, algorithms, memory management, string storage, networking, portability, language, programming language, etc.
Requirements Traceability: the architects should also have track of the requirements that are being fulfilled. Even though this part sound like the most tedious one, it’s better to realize that you didn’t consider a requirement in the upstream phases that in the downstream because all the discussions we have had in other blogs. Read my blogs if you haven’t dammit!
Completeness
The architecture is complete when the architecture team is willing to bet their life on it. It’s is impossible to have a 100% perfect architecture, but you need to move forward and keep that in mind all the time. The book reminds us of a phrase said by the ones that developed the Algol program, “The best is the enemy of the good”.
The software architecture document
When the architecture team bet their lives, wives and houses on the design it is time, like in everything else, to put everything a little and beautiful document with all the things stated above. The document should also contain information on how the architecture addresses correctly all the requirements and supports the staged delivery planning in a specified way, if you’re following this approach, which we are. Once written the document is put under change control. I love that board, they’re like the illuminati, guarding all the information and controlling the project beneath the surface.
Well, the Mona Lisa has been drawn in pencil. It’s time to move on and start building what we once dream of and turn it into art. Moving on to the next blog post.
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
Obsessive Compulsive Disorder… for quality
Don’t you get this unknow urge to clean something? Can’t you stand seeing your bed dirty? Do you fill like they will tear your insides when people chew with their mouth open? Is it necessary to turn the light off and on 24 times before leaving your house? Will you kill everyone at your office because of inferior quality software? If your answer was yes to only the last of those questions then this blog post is for you, and you’re cut to do the job I will describe here. If you said yes to any other questions please go right away to your nearest psychiatrist.
Why quality matters?
Quality in the software development word can be confused with testing exclusively. If it doesn’t crash then is good to go, but that is not necessarily the case. Good quality software encompasses many things such as clear and understandable code that can be documented or reused in future projects, that it’s scalable, trustworthy and obviously that it satisfies the implied and stated requirements without burdening the end user. So, quality mean good for the developer, good for the system and good for the user, and having a good control on quality will help detect bugus code that can lead to risks in future stages that will create big economic damages to the project. Then how can we achieve that such quality levels?
Quality assurance plan
You need to set your own standards of quality and everyone should commit to them. If any of the project parts, either documents or software modules do not comply with these standards the project should not be allowed to continue until these issues had been addressed and everyone should be ok with it. Some of the elements involved in this plan are the next:
- Planning on quality assurance activities
- Any quality assurance activity must be written down
- These activities should start through the requirement’s stage
- There should be a designated budget for this plan
- There should be a team to perform quality activities
An excellent quality assurance plan should address the next activities:
- Defect tracking: it refers to keeping record of the different defects found though the project, its source, when was it detected, when and how was it resolved and so on. Good defect tracking helps determine how far the project is from release, its quality, and where does the potential for improvement lies.
- Unit testing: refers to informal testing of the source code by the developer who code it. Even though it’s informal it should be needed before including the code into the master source or before independent review by the team of testers. One example of unit testing can be source code tracing where the developer steps through his code line by line.
- Technical reviews: refers to reviews conducted by the development team to the work of their peers like the User Interface Prototype, architecture, designs, etc. This is of great help to detect errors upstream and need to be considered as important as any other activity in this quality assurance plan.
- Integration testing: refers to the informal testing of the code that integrates other modules from the developer that is integrating them. It’s as crucial as the unit testing. After doing so the integration is past for independent review as well.
- System Testing: this activity is crucial for avoiding errors in the downstream phase. Refers to the execution of the software for the purpose of finding mistakes and it’s is performed by an independent testing group. This needs to be done through all stages and it’s imperative that it’s done by a group which only purpose is to break the code. The same developer that made the source code won’t be as good as finding mistakes as this group and it’s of vital importance.
Of course, there need to be a quality assurance group that assures that these activities are being carried out and keeps track of the defects. The job of these team is not to carry out the activities but to force others into the quality assurance religion. Making a multilayered approach for these activities will help ensure the quality of your product as well as help to detect as much errors as possible as early as possible.
Perfect, this has been very useful, now go out there and find your group of OCD individuals for your team, and if you’re one of those, let me first apologize for any orthographic mistakes and tell you that theirs is someone out there in need of your superpowers.
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
Not the requirements we want, but the requirements we need
Sometimes we are lost in life. We are not sure of the path we need to choose. Is this the right door? How do I know if I go this way I’ll not close a very precious path? Will I regret it on the future? Sometimes these fears won’t let use even move and in the end, we choose not to choose, which ironically is a choice. But how to we fight these nonsenses? Well I’m a true believer that the right path is chosen based on knowledge and wisdom, and to achieve those we need to experience more things in life and make ourselves more questions, even though sometime the experience will be learnt through harsh leaving experiences and may be not what we want, but it’s what we need.
Applying these beautiful words of wisdom, that come from the deep blackholes of my mind, into software development, to choose the right path we need to ask the right questions or have leaved lots of similar projects. Unfortunately, most of your clients will be different, and will come with needs that are very different each and every time, due to the constant change in the software industry. That’s why the only way to cut our way through is by engineering into their minds and capturing the right… wait for it… requirements. Thank you.
Requirements development
Software requirements refers to stablishing the needs that the stakeholder wants to solve through the software project, and requirement development refers to the processes that are to be done in order to find those needs.
The requirement development stage is extremely important because from here on the foundation of the project will be defined. The architecture, the design, schedule, personnel, discovery phase and almost the product vision is defined in this stage. It is a priority that most of the errors are find in this stage and that the end user is totally and completely sure that all need has been satisfied correctly by the proposals transmitted in this stage. Errors and even any modification in future phases can have a very serious impact on cost and time.
How to achieve good requirements?
Sadly, one of the most common problems in this stage is that not even the end user knows what he wants, and being as an important stage as it is there needs to be a way, a process that squishes all the need out the end user and stakeholders mind without him consciously knowing, and the book proposes some steps to accomplish them. Sounds so evil.
Step 1: Identify a set of key end user
Identifying the people that will eventually be the ones that will use the software, and will be happy or pissed on how the software interacts with them is essential to drawing the correct path for the development of the project. This set of users will give you confidence on the features that need to be included, that maybe you thought that wouldn’t be needed, and on the features that can be left out, that you thought where essential. If you lack the confidence on what to do in a moment designing what will meant to be the product, you can always look the answer in this set of people.
Step 2: Interview end users
Asking questions that help you empathize with the vision that the set of key users, that you identified in the previous step want, will help you elicit the preliminary set of requirements. This set then, will be used to build a simple User Interface Prototype.
Step 3: Build a simple User Interface Prototype
The objective of the prototype is to demonstrate how the software looks and feels with the least amount of work possible. You can program a really really really simple program that will help demonstrate what the software will do, or you can always use online design tools or mockup paper work to show what you’re thinking. It’s very important that you understand that the prototype is just a throwaway work that can be completely modified if need and that the users understand as well that it’s just a prototype and don’t raise grand expectations just because their imagination can run wild.
You need to iterate through this part until the users are excited about the prototype and all your doubts and questions have been fulfilled. Remember that this is the pillar that will set everything going and if the user is not satisfied, there’s no point in moving forward. Stay as much time as needed, but not that much time. You need a group of senior developers that know what they’re doing and how to do it for this part of the project.
Step 4: Develop a style guide
Once everyone agrees how the project needs to look and feel, the developers should create a User Style Guide so that there is a standard of how to approach the design. This guide should be put under change control because any modification could drastically change the design, and it should be thoroughly revised to address any issues in the initial stages. This will create consistency and uniformity in the future stages.
Step 5: Fully extend the prototype
Now that the initial requirements have been set and that the style guideline has been stablished, you can extend more the prototype to address the full breadth of the software functionality and show it to the users. This can be crucial in the future because this fully extended prototype can be treated as the baseline for the architecture and design of the project. Thus, this new prototype should be committed to change control and all the teams should be on board with the development of what the product may look like at the end.
Step 6: Create the documentation
- End user documentation: this document is treated more of a tutorial of the end to end interaction of the user with the software. Documenting this interactions with the interface will help address any inconsistency in an early stage, also to avoid a more technical documentation in the future that the user won’t be able to understand as much.
- Non-user interface documentation: this document should detail the algorithms, interactions with hardware, performance requirements, memory usage, and many more technical specifications for the developers to have a baseline and reference in this project and in future projects as well.
Choosing the right path is not an easy task and sometimes can be frustrating, but through years of experience and developing a good process that helps you achieve the answers you seek you can be sure that there will be no regrets on the path you chose; and if you make a mistake, be confident that it’ll not cost you as much as you fear.
References
McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.
Turn your thoughts into code 