--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.

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

 

 

--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.

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.

 

--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.

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.

--Originally published at Ce qui est chouette

This post will cover Chapter 14 of Software Project Survival Guide and Chapter 5 & 6 of the Pragmatic Programmer

---

Let’s get developers catcalling each other’s code in the construction phase by defining a coding standard. This will give the code a general look and feel, that helps developers read each other’s code. When in construction, developers should also look for ways to optimize the project goals, as well a simplifying the program, making it less complex; when a program starts getting too complex, it becomes a risk, as it becomes less comprehensible. When constructing in the first stage, developers should provide a skeleton on which to mount the rest of the project in future stages.

On integrating a particular module into the main build, the code must first be reviewed and reported as done, in a binary manner, then integrated into the main build. I suggest doing additional tests and reviews on the main build after this addition; this is part of the daily build and smoke test, in which the main program is built and tested to see if anything fails when run, if it smokes.

Construction is a key-phase where progress must be tracked. Whenever a milestone is completed, report and record it, as well as the time taken. Make everything available for the whole team to see. Hold a review to check how the project’s faring against the estimations.

It’s also during construction, especially if the software is being used, when pleads for change drown the team if a change board is not formally defined, to filter changes that ought to be made from the universe of suggestions. This board will also aid in keeping the team protected from distractions and thus be able to deliver the software altogether.

On construction and optimization, let’s take a look at the practices proposed by The Pragmatic Programmer. Avoid coupling between modules, it will only bring about trouble when debugging or trying to change something in the code. Technology choices should be included as configuration options in metadata, not as integrations into the code.

Always aim at the general case, the abstract, when coding; the metadata can hold the specifics outside the code. You may want to use that code for later. For this, design for concurrency, future you will thank you when wantin to run several programs at once.

To make effective code during this phase, keep away from coincidence, you have to know why your code doesn’t work. Let’s talk efficiency, never code one way because it’s easier, always aim to use less complex algorithms and analyze them using Big O notation. When some part of your code strikes you as wrong, look for the cause, it may be needing refactoring, you may be repeating yourself or excessively coupling modules; to easily find mistakes in your work, code so that it’s easy to test with different cases, so as to ensure you find almost every bug.

Keep your cool, the construction dude.

--Originally published at Ce qui est chouette

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

I have found the single best part of Software Project Survival Guide. Steve McConnell is a comedy genius.

Detailed Design expands on the work done for the Architecture:

Program Organization. While developing the architecture the team focused on the program’s role at system-level; at detailed design, developers are concerned at the class and routine level.

Reuse Analysis. The team will explore in detail resources to use, like classes and routine previously developed, frameworks and libraries.

Requirements Resolution. If there are requirements awaiting definition, any requirements that affect the release at each stage must be dealt with at their respective stage or deferred to another detailed design phase of a stage, but putting a marker on it.

Requirements Traceablity. Keep an eye out for the path each requirement follows and that it follows one to completion.

Construction. Similar to the construction described in previous posts, the developers generate a construction plan and a list of miniature milestones for the construction phase of each stage. This list must come about, as it will serve as a guide for development and progress tracking.

Correction of Defects in the Architecture. Fill in the holes found in the architecture, cut some things off and resolve any inconsistencies.

To determine how much to invest in detailed design, the expertise of the developers and the difficulty of the project come into play as described by the following diagram:

When the detailed design of a component is done, a technical review must be held to account for functional defects and requirements defects (missing or unrequired). Side effects of technical reviews include reviewing for project objectives, when reviewing, other developers may step in to adjust the design to fit the objectives of the project or making a more responsive solution; cross-training, this section fascinated me so I will transcribe it as is:

A benefit of design reviews is the insurance they provide against the what-if-our-key-developer-Joe-gets-hit-by-a-beer-truck syndrome. The two or more reviewers who have reviewed Joe’s designs will be familiar with Joe’s work and capable of stepping into his place. Joe’s untimely demise will be a cause for mourning, but not for canceling the project. Design reviews provide similar insurance against the what-if-Joe-turns-out-to-be-a-complete-jerk-but-we’re-totally-dependent-on-him syndrome. Think of reviews as a kind of “jerk insurance.”  – McConnell, 1997

This detailed design is meant to be put in a defined format, maybe follow some UML standards, throw in some diagrams to beautify, put some glitter on, I don’t know, whatever you feel like adding.

Au revoir, glittery me.

---

REFERENCES

MCCONNELL, S. (1997). SOFTWARE PROJECT SURVIVAL GUIDE. MICROSOFT PRESS. [KINDLE EDITION]

--Originally published at Ce qui est chouette

This post will cover Chapter 12 of Software Project Survival Guide. If you, reader, find a CC Licensed photo of some kind of miniature Rolling Stones, do tell.

---

In a Staged Delivery Plan, planning before each stage ensures the team to converge the software for each stage, having it at a releasable state. This reduces the risks of low quality software, going past the schedule and lack of status visibility.

At each stage, a short Stage Plan should be manufactured, including the following:

Requirements Update.  At the start, requirements will usually stay as is; later on, external factors may call for changes in requirements. The team should allocate time to evaluate whether changes will be made to requirements at each stage.

Detailed Design. Developers pick apart the detailed design to ensure it fits with the work to be done at each stage, revise the architecture if a flaw’s uncovered.

Construction. The same team that created the detailed design of a specific part codes it in this part.

Test Case Creation. It may be in parallel, or right after construction; the testers come up with cases to test the full functionality of the code described in each stage.

User Documentation Updates. End-user documentation like help files and manuals are added and updated so as to include software built at each stage.

Technical Reviews. Peer-to-peer reviews amongst the developers in the post-architecture stages.

Defect Corrections. Any bugs found while testing or at a technical reviews are corrected. The risk of low quality software is mitigated by verifying the defects have been corrected through testing and additional technical reviews.

Technical Coordination. Time to coordinate the different teams of the project.

Risk Management. Review the Top 10 Risks List to see if it addresses current risks.

Project Tracking. Tack completed activities at the end of each stage.

Integration and Release. After defects are corrected, the developers integrate the code for that release. It can be released in several manners, for external or in-house users to test and review, and various combinations of these.

End-of-stage Wrap Up. The team should pause to review progress and make any necessary adjustments.

For Project Tracking there’s a detailed technique called Miniature Milestones. These are binary milestones defined for each stage that developers meet frequently. This milestones should be updated after they’re met at each stage, check if they were fully met, if not look for the cause and do some adjustments. Miniature Milestones are micromanagement, but not the excessive kind; they, insead, aim to keep the team focused on the most important features.

Management should be done by someone who’s getting their hands dirty, someone who knows the software inside-out.

Keep on Managing, the about fellow.

--Originally published at Ce qui est chouette

This post will cover Chapter 11 of Software Project Survival Guide and Chapter 7 of The Pragmatic Programmer.

---

When the requirements of the project are completely set, estimates can come in. The procedure of estimating is better when written down, on a white board, a series of post-it notes or a virtual document is enough; that way the team can come back to the reasons behind an estimate. For the estimations, one should define the time that each activity will take and never assume team members will work overtime. If a project has already been done, take a look at the time recorded per activity as reference. Reestimate along the way by keeping the estimation under change control. The Software Development Plan ought to include estimated dates based on this work for the following milestones of the project: Architecture complete, Stage 1, 2 and 3 complete, and release.

Staged Delivery Plan. Each stage must aim to deliver functional software that covers a part of the requirements, the first delivery will provide the foundations upon which the rest of the stages will build. As a general rule, try to deliver from most essential to least essential functionality. Giving a theme to each stage gives this rule a hand in defining what to include. The team decides, as well, if they’ll release a stage, if any, to the public; this can also work with beta testers.

In the final stages there are still some ongoing planning activities to be dealt with. Regarding risk management, be on the lookout for newly emerged risks and track progress on previously found risks. Check if the project is aligned with the vision defined at the start. Update the Software Development Plan for a final polish. Feel the pulse of your personnel, are they still alive and happy?

If you’ve somehow gotten lost on requirements, let’s review them as presented in The Pragmatic Programmer. Dig deep for requirements, a requirement’s a statement that describes something to be accomplished. Work closely with your user at this stage in particular, let their mind be the lot in which you’ll dig for requirements. Abstract definitions may seem hazy at first, but when dealing with modules it may provide more freedom to work, especially if a glossary with previously defined entities and their role is being kept by the team.

Requirements collection is also the time to clarify each and every doubt, don’t dare put your fingers on that keyboard until your mind’s at peace. However, there exists the case in which trying to describe a process is way harder that just implementing it, in this case you’ll have to weigh the cost of each alternative to determine the course of action.

Laters, Me.

 

--Originally published at Ce qui est chouette

This post will cover Chapter 10 of Software Project Survival Guide and Chapter 4 of The Pragmatic Programmer.

---

Software Architecture. This architect isn’t the one dude who liked drawing so he decided to dedicate his life to drawing buildings and building little model constructions (says the guy who doesn’t really know what an architect does), nor is he the guy from How I Met Your Mother. Have you met him, though?

The architecture phase of a software project is when the software is mapped out using design diagrams and prototypes. It provides a means of exploring alternatives that may cost less, like using a Red Black Tree instead of a Priority Queue for scheduling, looking at you Linux Scheduler. If you’d like to read more on the Completely-Fair Scheduler, I suggest the following article by M. Jones: Inside the Linux 2.6 Completely Fair Scheduler.

During the architecture phase, back to the topic at hand, the architect partitions the system into subsystems, specifying the interaction between them and documents technical plans. This phase, however, shouldn’t really start until the Planning Checkpoint Review is held.

The architecture document should include the following:

System Overview. A brief description of the system without going into specifics, so as to provide a picture for the developer. It should include a discussion of the alternatives considered and why some weren’t selected and some where.

Conceptual Integrity. The architecture document should be created in such a way that the solution provided for the problem seems almost obvious, keeping it simple. The document should be short and include several diagrams. Keep it natural and easy.

Subsystems and Organizations. Define the major subsystems as clusters of functionality, of a certain aspect of the system. Describe the responsiblities of each subsystem and how they communicate with one another; this communication should be restricted, as in Object-Oriented Programming, to keep a certain level of modularity.

Notation. Describe the notation that’ll be used for diagrams and pseudocode, such as UML and the Cormen’s weird but useful pseudocode notation.

Change Scenarios and Change Strategy. List the parts of the software that are likely to need changes and how the team should go about those changes.

Reuse analysis and build vs. Build decisions. Define what components will be written from scratch, reused from other projects (if any) or bought (if any). In any of the two latter cases, the rest of the software has to be built around the framework bought (or reused).

Approach to Standard Functional Areas. The architecture document should include the following regarding to the functional areas of the software:

• External Software Interfaces. Is any external software used? Include how to interact with it.
• User Interfaces. How is it isolated from the rest of the software.
• Database Organization. How’s it organized and what does it contain.
• Data Storage. What’s not stored in the database, the file formats, are there any major data structures.
• Key Algorithms. Are they defined or should they be defined later on?
• Memory Management. How memory’s allocated.
• String Storage. Messages used.
• Concurrency/Threads. Whether the software is multithreaded.
• Security. Is there a requirement to operate in a secure environment?
• Localization. How the software will work on countries with other languages.
• Networking. How it supports network operations.
• Portability. How it runs on other environments (UNIX-based or Windows systems).
• Programming Language. Can it be implemened on any or does it have to be in a specific language?
• Error Handling. What the error-handling strategy is.

Requirements Traceablity. Make sure that every requirement is taken care of by one of the subsystems.

Support for a Staged Delivery Plan. Describe how the software will adjust to fit a staged delivery, how’s it going to be developed in each stage and delivery of planned functionality.

Software Architecture is really never done, but at some point implementation must begin, so aim at simplicity, minimalism and coverage of all requirements to know when it’s reasonable to start coding.

Now, onto being pragmatic. You may plan all you want, but every programmer must face the truth, there’s no perfect software. That’s a good thing, actually, the pressure for perfection isn’t there. Yet, one can still strive toward it. Some techniques will be furthered discussed:

Design by Contract. Taking advantage of the concept of invariants, document your code using  the pre-conditions and post-conditions of a module/method/loop. This way you’ll be able to write code that meets these requirements and nothing more. No fancy business here.

A crash in the development phase is a message brought from heaven that reads “fix this, you twit”. As previously stated in my posts on Software Project Survival Guide, upstream fixes are cheaper than those downstream. Regarding crashes, an attitude following Murphy’s Law closely resembles the pragmatic approach; in software anything that can go wrong, will go wrong fits the real world frighteningly well. Assertions are a tool that checks whenever one of these things that may go wrong, do go wrong. Keeping assertions in a deployed product allow catching those crashes that barely escaped the tests.

This wasn’t that later, your neighborhood pragmatic-man.

--Originally published at Ce qui est chouette

This post will cover Chapter 9 of Software Project Survival Guide and Chapter 3 of The Pragmatic Programmer.

---

A definition for quality that McConnell provides is the following: “the degree to which the software satisfies both stated and implied requirements” (1997).

Quality is important in software, because as time passes what the user will remember is his experience with the software, delivering late is not even that important, as the user will use the software anyway. What they’ll remember is whether they liked their experience with the software.

To ensure quality the team ought to commit. Meaning planning quality assurance activites and write them down, starting them before or during software requirements activites, assign a knowledgeable group to quality assurance, and provide the required funding.

It’s important to keep in the pipeline a Quality Assurance Plan which consists of the following:

Defect Tracking. Keep record of each defect, where and when it was detected, when and how it was resolved. This information should be made public through change control, so that team members are aware of the defect and the whole staff can keep track of how many defects remain in the software.

Unit Testing. Carried out by the developer of the unit (subroutine, module, class).

Source-code Tracing. Carried out by the programmer that wrote the source code. They go through the code line-by-line using a debugger.

Technical Reviews. Carried out by team members on work they didn’t do themselves. Consists of checking if quality is met on the UI, requirements specification, architecture and design. It’s advisable that senior developers review junior developers work, not just to assure quality, but to encourage that interaction. Technical Reviews follow a general pattern:

• Notification and distribution. The developer notifies reviewers (or a moderator) that the their work product is ready to be reviewed, then the material is distributed for review.
• Preparation. Reviewers review the work product, usually against a checklist of common errors, and schedule a review meeting.
• Review Meeting. Reviewers, the developer (and moderator) meet to review together the work product, keeping focus on detecting defects.
• Review Report. Results and statistics are commited to a written document, including defects detected and information needed to add them to defect tracking.
• Follow-Up. The developer or some other person makes changes (if they were required), these changes are reviewed and the product is declared to have passed the review. Add the material to a list of materials that have been reviewed already.

Integration Testing. Carried out by the developer of the new code, they test it with other code that’s been integrated already.

System Testing. Carried out by a designated group or by the quality assurance group (independent to the development). Consists of executing the software to find defects. System testing alone won’t be enough to assure quality, it must be combined with the aforementioned stepts for that purpose.

Some companies, instead of keeping system testing inside the team, deploy what’s called a beta version of the software to the consumers. Beta testing is performed for several reasons like building a relationship with the user, getting expert consulting or polishing the user-interface according to usage.

To ensure that quality is met overall, the team must designate a group to wield the quality assurance baton. Whoever holds the stick has the responsibility of ensuring quality assurance activities are performed and is responsible for determining whether the software is ready for release; this must be determined according to measurable criteria, meaning “no more than 2 bugs” and the likes.

Following The Pragmatic Programmer, a must for software design is to consider plain text, at least at the phase of prototyping and reviewing. Using actual text to name variables and methods to make it readable.

Going off on a tangent to talk about the more technical aspects of The Pragmatic Programmer’s third chapter. Know your tools, this affects individual software development. The shell is your friend, get to know it and master an editor (preferably Vim, suck it Emacs). Use source control and learn to debug. My personal favorite debugging techniques are visualizing the program and the data changing through it, usually combined with Rubber Ducking; which consists basically of talking out your code, line by line, preferably to a Rubber Duck, further explanation on wiki.c2.

Laters, a pragmatically-quality-assured fellow.

---

References

McConnell, S. (1997). Software Project Survival Guide. Microsoft Press. [Kindle Edition]