2 of Plato’s regimes – MMM Ch. 4

--Originally published at That Class Blog

Conceptual integrity is to maintain the good initial ideas, even if it implies not making that many features. This is better than having lots of uncoordinated ideas.

Likewise, functionality and simplicity. Which is better? There have been software projects that have an outstanding performance in one of both.  But we have to say that it’s a combination of simplicity and straightforwardness. Every part must use the same philosophies, same semantics and syntax and the, you have conceptual integrity.

And how, or more precisely, who will achieve that integrity? Either one mind (Surgical team), the equivalent to an aristocracy; or a handful of minds, with a division of architecture and implementation, the equivalent to a democracy.

And it’s no bad to desire a democracy, but it has several problems. The people in charge of the architecture should consider methods to implement their architecture; the implementers, when suggesting ideas must preserve the integrity of the architects.
That’s why at the end, the aristocracy (Surgical team) is better because as long as the design and implementation are clear in the surgeon’s mind, everything is ok. Or at least, an aristocracy of architects, who have a clear idea of how the system should behave, and they should decide how to maintain integrity, even if that means to leave the implementers with practically no voice, at the end, what must endure the most is the design, not the implementation.

2 of Plato’s regimes – MMM Ch. 4
Using CC (BY-SA). Published by Jocelyn Kinghorn. From https://www.flickr.com/photos/joceykinghorn/11487085615

 


2 of Plato’s regimes – MMM Ch. 4

The Surgical Team – MMM Ch. 3

--Originally published at That Class Blog

The dream: To develop a project with a small team you can know, and trust in their abilities. Forget the big teams, integrated by mediocre developers. In fact, by spending the double on a very good programmer, 10 times the performance could be expected. We can do this all by ourselves. Ah… The dream…

The reality: Big and complex problems need to be done and big teams are needed to do this.

How? Harlan Mills offers a solution. To make several teams, where only one member of each attacks the problem, and the rest only assist him in achieving maximum productivity. You keep a few number of people in the building design, but a lot of them in the actual construction. Just like a surgical team.

Here are the roles of this approach:

  • The surgeon: Define functional and performance specification. Designs, codes, tests the program and writes its documentation.
  • The copilot: Is a less-experienced surgeon. He advises the surgeon, and he can listen to him, or not. He knows the code perfectly but isn’t responsible for it.
  • The administrator: Even though the surgeon is the boss, he needs someone to be in charge of his administrative (Money, personnel, machines…) decisions. The administrator can serve 2 teams.
  • The editor: He writes the external and internal documentation. He reworks the draft of the surgeon.
  • Two secretaries: One for the administrator and the other one for the editor.
  • The program clerk:  He is in charge of the maintenance of the machine and user readable files.
  • The toolsmith: File, text and debugging services. Made fast and with quality
  • The tester: Design test cases and data.
  • The language lawyer: Master of the language selected for development. Can work with 2 or 3 surgeons.

Because the purpose of this team organization such that everyone is represented as just one, the surgeon. At the end, instead of organizing a 200 people team, you just have to deal with 20 surgeons.

The Surgical Team – MMM Ch. 3
Using CC (BY-NC-ND). Published by UCD School of Medicine in https://www.flickr.com/photos/76652722@N04/6878041625

The Surgical Team – MMM Ch. 3

Interpolación de Newton y Lagrange

--Originally published at That Class Blog

Antecedentes

Ambas interpolaciones son métodos que permiten la creación de un polinomio de n -1 grado, donde n es el número de datos que se poseen. Ambos métodos asumen que no existe ruido en sus mediciones de datos, es decir, que el polinomio generado por el método pasara por todas las coordenadas insertadas al método.

A menos que se conozca la función original (Lo cual es prácticamente imposible al aplicarlos en la vida real), no hay manera de calcular algún error.

Justificación y propósito

El propósito de ambos métodos es poder generar una función para la cual se puedan introducir todos los datos originales y obtener 0 error, pues la curva se va modelando punto a punto. Al obtener una función, se puede crear aproximaciones y estimaciones.
(En nuestros métodos, no proporcionamos al usuario la función, solamente el valor f(x) para la x deseada)

El método de Newton utiliza la formula de polinomios de Newton:

N(x)=[y_{0}]+[y_{0},y_{1}](x-x_{0})+cdots +[y_{0},ldots ,y_{k}](x-x_{0})(x-x_{1})cdots (x-x_{{k-1}}).
Donde las “y” entre corchetes se refieren al calculo de diferencias dividas, el cual es un algoritmo usado para computar tablas de funciones logarítmicas y trigonométricas, usando división recursiva.

El método de Larange obtiene una misma función, pero elimina por completo la necesidad de usar diferencias divididas:

L(x):=sum _{j=0}^{k}y_{j}ell _{j}(x)

donde

ell _{j}(x):=prod _{begin{smallmatrix}0leq mleq k\mneq jend{smallmatrix}}{frac {x-x_{m}}{x_{j}-x_{m}}}={frac {(x-x_{0})}{(x_{j}-x_{0})}}cdots {frac {(x-x_{j-1})}{(x_{j}-x_{j-1})}}{frac {(x-x_{j+1})}{(x_{j}-x_{j+1})}}cdots {frac {(x-x_{k})}{(x_{j}-x_{k})}},

Los polinomios de lagrange son más fáciles de computar, pues elimina la necesidad de recurrir a métodos de recursión,

Explicación gráfica de la interpolación

Diagrama de flujo

Newton

Interpolación de Newton y Lagrange

Lagrange

Interpolación de Newton y Lagrange

Código en C++

Ejemplos resueltos


Interpolación de Newton y Lagrange

Quality Meter: Ch. 9 SG

--Originally published at That Class Blog

Let’s do this fast folks, because this chapter was looooooooong.

So, first things first. What is quality? We have to thank McConnel for this simple definition: “the degree to which the software satisfies both stated and implied requirements”. Easy to understand. Perfect.

But why is this important? Because keeping defects controlled affects the development speed, cost and characteristics. A delivered low-quality software increases the cost of end-user support, among other things. McConnel emphasizes in remembering that the end-user tends to forget the delivery time of the software, but not if they liked using it. They forgive taking even taking more time than expected if they will enjoy using the software.

And how to keep the quality up at all times? Using the Quality Assurance Plan. The team must commit to the QA Plan. The activities of the QA must be planed and committed to writing, the QA must be established at least at the same time as the project requirements, a group that will take care of the quality must exist, with capable people, and finally, all the QA activities must be well funded.

And which activities conform the QA Plan?

  • Defect Tracking: Keep record of every defect that is found during development. The moment of detection, and the moment where the defect was resolved (And how). Its important to keep the information public, so the team can adjust the estimates, and see progress.
  • Unit Testing: Testing made by the developer who wrote the code. The unit can refer to any programming entity. It’s informal.
  • Source-Code Tracing: Carried out also by the person who wrote the code. Consist in going through the code, line-by-line, using a debugger.
  • Technical Reviews: This are reviews made by the peers of the code author. Usually are given by the full team, and the QA staff just makes sure this reviews are being carried out. Technical reviews have a pattern:
    • Notification and distribution: The code’s author notifies to the QA team that the work is ready to be reviewed. The material is distributed to the corresponding people.
    • Preparation: Reviewers review the work, using checklists of common errors. They schedule a review meeting.
    • Review meeting: Evaluate the work alongside the developers and a moderator. The main objective is to detect defects.
    • Review report: The results of the meeting are written to paper, committed, and added to the defect tracking.
    • Follow-up: The developer applies the changes, which are evaluated again, and if approved and passes the review, the material is added to the list of materials that have been successfully reviewed.
  • Integration Testing: Test the code developed with already tested code, which has been integrated to the complete system.
  • System Testing: Execute the complete software to find defects. This is by no means a complete way to find all of the defects.

Sometimes companies also use Beta Testing. Even if the book doesn’t recommend it as much as the other tactics (Which are internal), it might be helpful to consider using it, because of the great final-user feedback the developers might receive.

And that’s it. Let’s not stop the testing, until we run out of cake…

Quality Meter: Ch. 9 SG
Used under CC 2.0 (BY-SA). Published in: https://www.flickr.com/photos/chripell/3409348666

Quality Meter: Ch. 9 SG

Quality Meter: Ch. 9 SG

--Originally published at That Class Blog

Let’s do this fast folks, because this chapter was looooooooong.

So, first things first. What is quality? We have to thank McConnel for this simple definition: “the degree to which the software satisfies both stated and implied requirements”. Easy to understand. Perfect.

But why is this important? Because keeping defects controlled affects the development speed, cost and characteristics. A delivered low-quality software increases the cost of end-user support, among other things. McConnel emphasizes in remembering that the end-user tends to forget the delivery time of the software, but not if they liked using it. They forgive taking even taking more time than expected if they will enjoy using the software.

And how to keep the quality up at all times? Using the Quality Assurance Plan. The team must commit to the QA Plan. The activities of the QA must be planed and committed to writing, the QA must be established at least at the same time as the project requirements, a group that will take care of the quality must exist, with capable people, and finally, all the QA activities must be well funded.

And which activities conform the QA Plan?

  • Defect Tracking: Keep record of every defect that is found during development. The moment of detection, and the moment where the defect was resolved (And how). Its important to keep the information public, so the team can adjust the estimates, and see progress.
  • Unit Testing: Testing made by the developer who wrote the code. The unit can refer to any programming entity. It’s informal.
  • Source-Code Tracing: Carried out also by the person who wrote the code. Consist in going through the code, line-by-line, using a debugger.
  • Technical Reviews: This are reviews made by the peers of the code author. Usually are given by the full team, and the QA staff just makes sure this reviews are being carried out. Technical reviews have a pattern:
    • Notification and distribution: The code’s author notifies to the QA team that the work is ready to be reviewed. The material is distributed to the corresponding people.
    • Preparation: Reviewers review the work, using checklists of common errors. They schedule a review meeting.
    • Review meeting: Evaluate the work alongside the developers and a moderator. The main objective is to detect defects.
    • Review report: The results of the meeting are written to paper, committed, and added to the defect tracking.
    • Follow-up: The developer applies the changes, which are evaluated again, and if approved and passes the review, the material is added to the list of materials that have been successfully reviewed.
  • Integration Testing: Test the code developed with already tested code, which has been integrated to the complete system.
  • System Testing: Execute the complete software to find defects. This is by no means a complete way to find all of the defects.

Sometimes companies also use Beta Testing. Even if the book doesn’t recommend it as much as the other tactics (Which are internal), it might be helpful to consider using it, because of the great final-user feedback the developers might receive.

And that’s it. Let’s not stop the testing, until we run out of cake…

Quality Meter: Ch. 9 SG
Used under CC 2.0 (BY-SA). Published in: https://www.flickr.com/photos/chripell/3409348666

Quality Meter: Ch. 9 SG

The end is nigh.

--Originally published at Ce qui est chouette

This post will cover Chapter 17 & 18 & 19 of Software Project Survival Guide and Chapter 8 of The Pragmatic Programmer.

Let’s get to wrapping. To wrap up first hold a change board meeting at the end of each stage that includes the whole staff to evaluate changes that were deferred during each stage. Wrap-up is time to recalibrate estimates, see if milestones were met, whether necessary tasks were omitted, and in general if the project scope still aligns with the estimated at the start.

Evalutate performance against the project plan, whether the team performed technical reviews, kept track of progress and follow the plan. If the plan wasn’t followed, see why, if the plan resulted impossible to follow, replan.

The end is nigh.
The end by Christ Lofqvist on flickr under a CC License

To fully conclude a stage archive the environment that was used to create the software, in the future the team might need to recreate the software at a certain stage, and collect data into logs to serve as reference for future work and estimates. This is stored in Project History.

At the end of the project as a whole, gather all the data you can, e-mails, summaries, and most important, subjective opinions of team members. Hold a meeting, why not? Everybody loves meetings. In it, team members will discuss candidly their insights; a questionnare can be an alternative to this meeting.

To complete the Project History Document include both objective, quantitative information about the project and the team’s subjective, qualitative impressions. Now this document will serve as reference. For full reaping of this document in the future, conclude it in the following two ways: create a planning checklist based on the work done for the project and add the major risks to a general Top 10 Risks List template.

To fully conclude, a list of Do’s.

  • Create and follow a Software Development Plan.
  • Empower project personnel.
  • Minimize the bureaucracy.
  • Define the requirements baseline, and manage changes to it.
  • Replan when necessary.
  • Reestimate system size, effort, and schedule periodically.
  • Define and manage phase transitions.
  • Foster a team spirit.
  • Start the project with a small senior staff.

Now onto the Don’ts:

  • Don’t let team members work in an unsystematic way.
  • Don’t set unreasonable goals.
  • Don’t implement changes without assessing their impact.
  • Don’t let additional complexity creep in.
  • Don’t overstaff.
  • Don’t relax standards.

Onto the last Pragmatic advice. This time it’s pragmatism for the whole team. Teams should be divided based around functionality, some team will cover a certain subsystem defined in the architecture, another will serve as the change board, and so on. Automate everything that must be done systematically, people aren’t as efficient at standard procedures as one may think. Leave testing and installations to machines. Design a test case that can be performed without any human intervention, this way test can be performed more frequently.

No phase can be counted as done until it passes every test designed for it. A fun but risky way to assure a module, class or routine is fully done is to design a project saboteur, to branch out their version of the current software and introduce bugs to see if the automated testing will catch it. Regarding bugs, once a developer finds one, they should make it their mission that no one else finds that bug, put it under change control to be dealt with.

On documentation, it should be done in parallel to development. Each module should be accompanied by its respective documentation, in code and in a separate markup language document, signed by its developer in some way, be proud of your work, developer.

This is it, the about guy

 

 


The end is nigh.

It is time. Or is it?

--Originally published at Ce qui est chouette

This post will cover Chapter 16 of Software Project Survival Guide.

The entire team must gather around a common goal: driving the software to a releasable state. By doing this, quality is ensured by focusing on polishing key factors of the code at each stage. Developers may begin to work on the next stage’s detailed design, when they’re ready to release the current stage, but must be ready to drop everything and go back to correct any defects.

It is time. Or is it?
Noel Gallagher by Peter Hutchins on flickr under a CC License

As to when to release, there are some techniques, the most basic one consists on defect counting if the defect count is under a certain number by the end of the stage, it is determined to be ready for release; defect density consists on averaging out the number of defects per line of code; defect pooling, for this keep two pools of defects with arbitrarily separated defects, report defects into the first and report into the second, the number of unique defects is given by the union of both pools, compare this against the approximate total number of defects given by the product of both pools divided over their intersection; defect seeding consists in planting errors in the code and having another team find them.

The development team along with the testing team should keep a public note of the defects detected and work being done on them. A public space such as the break room, an office or meeting room is usually OK, a private website could also work.

Keeping a release checklist can help review the release and on being prepared for it. It should consist on the critical release activities the team wouln’t like to forget in the heat of the moment. Similarly a release sign-off form ensures that every member of the project team is in accordance to releasing the software at each stage.

I’m now singing In the Heat of The Moment, your wonderwall guy.

 


It is time. Or is it?

Should it crash when I click here?

--Originally published at Ce qui est chouette

This post will cover Chapter 15 of Software Project Survival Guide.

System testing is a part of the development of the project that should be done in parallel with its construction or right after. Testers play an important role in quality assurance in ensuring that the system’s quality is high enough to support the integration of new code, and also reporting to developers any defects to be immediately dealt with.

Test cases are to be implemented with any implementation of the software, testers build these based on detailed design and informal versions of the software given to them as it’s submitted for its code review. System tests should test the entirety of the system, so as to assure that each requirement already met is implemented and the code executes without errors. The smoke test that’s done during construction will determine whether the software is ready for a system test.

Should it crash when I click here?
170320-N-BL637-062 by US Pacific Fleet on flickr under a CC License

Testers are to be treated well by developers, really well, who ought to heed their command as they call for a defect to be corrected. No one should have to deal with your buggy code, Joe.

A way to assure quality is to use defect tracking for routines causing bugs, if one causes more than a defined number, redesign it completely, it’s time for a make-over.

Testing, 1. 2. 3. Me.


Should it crash when I click here?