Found it (includes chapter 15 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

System testing goes almost along construction, as you should make a system test before and after you are trying to integrate new code into the project. But, how can you test your project? If you have been following the guides from chapter to chapter, you should have a user interface and a user manual by now, and using those you can make test cases even before the code is implemented. The way you test the project is made by simply checking if it passes the test cases that you have developed.

With the approach followed on McConnell’s book you won’t find that many errors, this is because before passing by the system testing, everything has already passed by a review  during user-interface prototyping, User Manual/Requirements Specification review, architecture review, detailed design review, and code review. And everything will have been both unit tested and integration tested by its developer. Plus the daily smoke test. This will avoid entering a cycle of infinite errors.

At the start of each stage you should add new test cases, so the requirements in that stage are fulfilled. If a build doesn’t pass a test, it will go back to development. If an error is found, it should be corrected, not ignored, this sounds obvious, but it doesn’t always happen.

When many errors arise on a routine, don’t waste time on solving the errors separately, redesign that routine and reimplement it. Chances are you’ll waste less time and money.

As a developer, I both like and don’t like finding errors, it means more work, but it also means that the thing that I’m doing can improve, as a tip, I would recommend focusing on the “it can improve” part, when the error is gone, you’ll be happier, because you now know that your code won’t

Continue reading "Found it (includes chapter 15 Software Project | Survival Guide)"

Build it guys (includes chapter 14 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Construction is the stage where software comes to life. If previous stages have been done well, this will go smoothly, as features are added incrementally, the team should be able to test them and track the progress of the project. The team should keep the focus on simplifying the software.

Constructing can either be fun or disgusting, it all depends on how you planned it, if you planned it poorly, you’ll be struggling just to save your building from falling apart, but if you made the necessary preparations, you’ll even be able to choose the color of the paint for your walls.

Use code standards, they’ll help you in the task of making a code understandable to many developers, not only one. Keep the standard from project to project, that way, developers won’t have to learn a new standard each project, and they’ll be able to reuse code.

In order to add more code to the main build, the book recommends following some steps:

  1. Developer develops a piece of code.
  2. Developer unit tests the code.
  3. Developer steps through every line of code, including all exception and error cases, in an interactive debugger.
  4. Developer integrates this preliminary code with a private version of the main build.
  5. Developer submits code for technical review.
  6. Developer informally turns code over to testing for test case preparation.
  7. Code is reviewed.
  8. Developer fixes any problems identified during the review.
  9. Fixes are reviewed.
  10. Developer integrates final code with the main build.
  11. Code is declared “complete.”

I, as a developer, agree with this steps, they reduce the number of errors, and when done right, you can be sure that the code submitted is done, and the feature it covers is complete. Continuously coding without revisions will lead you to a loop where you’ll always  be searching for

Continue reading "Build it guys (includes chapter 14 Software Project | Survival Guide)"

Just as a checklist (includes chapter 13 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

On this chapter, detailed design was discussed, it can affect the whole project and it extends design work done during the architecture stage. During stage 1, detailed design  requires verifying the quality of the architecture, if it has bad quality, it’s time to correct it.

Detailed design also uses a staged approach, at each stage developers design the features that’ll be delivered at the end of that stage. A good architecture will let you focus on the current stage. During detailed design is when developers check if they can reuse components.

At the start of each stage, requirements must be clear, if a requirement is not clear is either resolved during that stage, or resolved in a later one, but the leadership should be informed about this delay. Delaying a requirement is a bad idea, if you do it too often you’ll end up delaying the project. And remember, a project is delivered a year late one day at a time.

Requirements flow from requirements to architecture to detailed design to code and test cases. Developers must continue doing detailed design until they get miniature milestones for construction. But how much does that is? It depends on the experience of the developers and the difficulty of the project, the more experienced the team, and the easier the project, the less detailed design you’ll need. Still, more is safer.

After done, detailed design should be reviewed,  and it must have correctness (will it work?), completeness (for everything we intend it to work?) and understandability(is it clear how it works?). With detailed design reviews, more than one person knows each part of the project, so if someone goes missing, you’ll have at least a plan B.

Be sure to use detailed design on your projects, a little

Continue reading "Just as a checklist (includes chapter 13 Software Project | Survival Guide)"

The Blue Prints of Software

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell

When I was in my senior year, struggling through which university I was going to, I had a very important decision to make, and that was which major I was going to choose. My first option was architecture. I liked the way buildings look, and how you transform simple spaces into something great. But then, I changed my mind because I figured out that it wasn’t the major for me. Then I decided to choose a major in computer science, because is something that I felt very attracted to (and I chose right). Then I started my major, and I noticed that was going to have a class of software architecture. At first, I thought that software was as simple as one, two, three, but then I realized that it is more complicated that it seems. I came to a realization, that building software is something that needs to be thought, and that it needs an architecture to build it right, just like a good building.

3770016707_525907e28c_o.png
“Blueprint” flickr photo by Will Scullin https://www.flickr.com/photos/wscullin/3770016707

In every software project, there needs to be a plan to be able to construct the architecture. Even if you have a small project, you need to take time to think about how the software is going to be made. After you have your requirements, well defined, is time to start building the architecture. There a some some characteristics that makes up a good architecture, like:

Software Project Survival Guide chapters 18-19 and Wrap up

--Originally published at Jose Ramon Romano

I think this blog post will be a wrap up of this book, the last two chapters are brief, I will still talk about them a bit, I was expect this book to be something else, I really liked it a lot, somethings I found them so useful, other things I personally think everyone with some basic knowledge knows them, I’m glad I made this posts about the book, in this way I could check my summary about it, I found the earlier chapters a bit more interesting because I do think that a solid base will make things a lot easier. I believe there is nothing else to say, I believe everything I think about of the chapters is in my blog, so, that’s it, last two chapters.

Chapter 18

This chapter talks about the project history, I find this part very interesting and I just thought about this, I was thinking that having a good project history will make you a better analyzer of your work, it has the same principle as data mining which is to look to your data, analyses it, and create a better plan with it. This way you can create better projects in the future.

Chapter 19

Resultado de imagen para nasa

This chapter just makes a guideline combining guidelines from this book and the NASA’s software Engineering Laboratory, there is nothing else to say.

TL; DR: End of the book, check post to read about it. Ch 18 make a project history to analyse what you did. Ch19 read it.

In the book:

  • Check the survival Crib Notes

Software Project Survival Guide chapters 15-17

--Originally published at Jose Ramon Romano

Chapter 15

System Testing is a very important part of the software, it enhances the quality of it, and prevents a lot of failures plus it looks pretty cool when your software passes al the test you imagined, there is no much to say about this, in all of my career years my teachers have always told me to test, I had a class about testing, so I think everyone should test, including you, the readers.

Chapter 16

This chapter really got me, while I was reading it I arrived to a section that talks about when to release the software, after I read the questions you have to ask yourself which are: “Is the software good enough to release now?” and “When will the software be good enough to release” all I could think of was: “Come on, hahaha, everyone could answer those questions”, but then I kept reading and I found out some cool stuff. The book just gives you some techniques you can use and believe me, they are worth the reading, I plan to use them, I see myself using them.

Chapter 17

In the wrap up I think it is important to look back to what you did, check your times, make a complete analysis of the project you just did, this in order to deliver the next one in better conditions, if you did something wrong, write it so you can consider it in your next project, after a while practice will make you master and you will do this fluently, check for mistakes everywhere, and even if you didn’t have a mistake try to see where you can improve, what took you longer and how you can make it better in a shorter time, always seek improvement and the only way to

Continue reading "Software Project Survival Guide chapters 15-17"

Stage by stage (includes chapter 12 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Staged planning is something that is done at the start of every staged delivery cycle, where the project team creates an individual stage plan for each stage. It describes how to conduct detailed design, coding, technical reviews, tests, integration, and other activities.

When doing the plan for a stage, use mini milestones, they help you track progress and reduce risks. Staged planning is somewhat a plan with many mini plans.

Remember that the project is guided by the software development plan, but each stage is guided by a stage plan, which is much shorter, each stage plan must be included in the software development plan.

In other words, each stage is like a miniature project. And smaller projects involve less risks. Big projects that are poorly planned, tend to have a shaky development and rarely get delivered. Plan for the mini, aim for the whole.

Basically a stage plan is a miniature version of a software development plan, and it should include every update to the requirements (requirements will change while you get to know better your project), revisions on the design, including the project architecture, the coding of the current stage, test cases, time for technical reviews and defect corrections, also there should be a space for designing teams coordination, like developers and testers teams. But the thing where you should focus the most is in risk management, if you keep track of the top priorities on the survival of the project at the start of each stage, you project will get higher chances of being developed and delivered. At the end of each stage you should have a deliverable product, and you should review the progress.

But, as much as you plan, plan doable things, milestones are either done or not done, don’t trick yourself. If a well

Continue reading "Stage by stage (includes chapter 12 Software Project | Survival Guide)"

Prepare for it (includes chapter 11 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

When doing the final preparations, the team is ready to create estimates and develop a plan for the critical functionality delivery. In other words, what needs to be done is this:

  • Create estimates for: effort, cost, and schedule.
  • Estimates must be written, and they should include time for all normal activities, from coding, to being sick.
  • Don’t depend on overtime, add extra time to your estimates, that way you’ll have a backup plan if anything happens, and believe me, something always happens.
  • Use an estimation software. Calibrate the estimation software with your own projects.
  • Let the developers review the estimates, you want them to be happy. Reestimate several times. Estimates must be under change control.

Manage the project with a staged delivery plan. Some perks of doing this that I noticed while reading are:

  • You’ll meet the customer’s critical needs faster.
  • You’ll be less pressured by needy customers.
  • You’ll be able to identify stages by themes, and this will help on the classification of features.
  • You’ll deliver by themes, from the critical one to the not so critical ones.

Staged Delivery Plan should be under change control.

Last but not least, I’ll list the activities that you should be doing continually; at all times you need to be managing risks, checking that the project is still following the original vision, authorities and people who can take decisions about the direction of the project need to be focused on the project goals, always help them, update the software development plan when needed and keep the team healthy, a healthy team has a healthy morale, and a team with a healthy morale will most likely be productive.


Software architecture (includes chapter 10 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Chapter ten of  McConnell’s book talks about the software architecture document, which describes the program organization, having a good software architecture means that your project will be an easy one, on the other hand, if you have a bad software architecture you shouldn’t even try it, chances are it will fail.

During this phase is when the software gets mapped through design diagrams, trying to make a clearer view of what is going to be done, it serves as a base for a more detailed design.

You should start making the software architecture document when about 80% of the requirements are known. It needs to cover topics like a general view of the project, with the major design alternatives, the reasons for those approaches, and the reasons for not choosing other alternatives.

Keep it under 100 pages, and full of diagrams. The chosen approach must be logic, because the solution to the problem needs to feel natural if you want your product to be used. Also, the document should define the major subsystems of the program. And by subsystem McConnell means a cluster of functionality, your software document shouldn’t be complex, don’t overdo it, 5 subsystems are fine, more than 9 not so much.

Take account of change scenarios, don’t make the mistake of setting all of your project with the tools provided by someone else, if that someone else disappears, you are doomed. But reuse and buy, building is not always necessary, this last thing may reduce production costs and times.

In this document you also need to keep track of requirements, if you discover new ones, celebrate, it’s better to know them now than later. With this create a traceability matrix. Make all of this in a way that you can use staged delivery, the idea is to have

Continue reading "Software architecture (includes chapter 10 Software Project | Survival Guide)"

Do it right (includes chapter 9 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Chapter 9 of the book talks about quality assurance, but, why is it important? The answer is quite simple, if you keep defects under control you’ll develop faster, and your costs will go down.

Getting support for poorly planned software costs a lot, and raising a project on a shaky base won’t work either, maintainance prices will rise higher than NASA rockets, and I think that I’m saying the truth when stating you don’t want that to happen.

As all other activities we have talked so far, quality assurance must be planned and written too, test planning comes at the same time as the requirements, and the plan must include activities like:

  • Defect tracking
  • Unit testing
  • Source-code tracing
  • Technical reviews
  • Integration testing
  • System testing

In other words, quality assurance must look for errors and document them, check every single function in the code, debug line by line, review what has been done, check interactions between functions, and check the whole system working.

Gathering all this information will speed your project and will help you make better estimates for future projects.

On a separate note, reviews help on upstream activities (since the beginning), and system testing (when you have a prototype) focuses on downstream activities, do them at the right time.

Keep testing, test at all times, why? because testing gives you a scope of the quality of the software, it won’t solve your problems, but it’ll help you identify them, and then you can plan a good aproach for those problems. It would be bad if some bug went untracked for a long time, and discovered on a critical stage of the project.

If your software will be delivered to thousands, make a beta test, this will help testing on different systems, verifying compatibility, without the cost of spending on

Continue reading "Do it right (includes chapter 9 Software Project | Survival Guide)"