Building the software: Ch. 10 SG

Software architecture provides the technical structure for a project. The time in which the software is mapped to diagrams and prototypes, and the program is partitioned into systems and subsystems.
Everything is described in the software architecture document, that contains the software organization, support for changes, reuse or purchase of components, and design of functionalities.

This document has the following categories:

  • System Overview: Describe the system in general terms. Help build the developer the idea of what is he going to build. As well as a description of the design alternatives that were considered, and why were or weren’t chosen.
  • Conceptual Integrity: Descriptions and diagrams of the almost obvious solution to the problem. Simple, short, and easy.
  • Subsystems and Organization: Here the major clusters of functionality must be defined (Output formatting, data storage, analysis, user input…). Usually a complete system hast five to nine subsystems. The responsibilities of each subsystem are stated, and how are they intercommunicated and restricted.
  • Notation: Describe the notation that will be used for the pseudocode and diagrams (Such as UML)
  • Change Scenarios and Change Strategy: List what parts of the software will need (Most likely) to be changed, and how the team must approach this changes.
  • Reuse Analysis and Build vs. Build Decisions: Define what components are going to be developed from scratch, reused (If available) or bought.
  • Approach to Standard Functional Areas: Functional areas that the architecture must address:
    • External software interfaces: How is the software expected to communicate with other software.
    • User interfaces: How is it isolated, so that the changes made to the interface won’t affect to the system (And reverse).
    • Database organization: Organization and content of the DB.
    • Data storage: Major data structures and what isn’t stored in the DB.
    • Key algorithms: Defined, or for later definition.
    • Memory management: Allocation of memory.
    • String storage: How is the text stored and retrieved.
    • Concurrency/Threads: How is the concurrency going to be handled if the software is multithreaded.
    • Security: Is the software going to operate in a secure environment?
    • Localization: Is the software going to be translated for other countries or regions to use?
    • Networking: Network operations.
    • Portability: Handle other environments (Android/iOS, Windows/UNIX)
    • Programming language: Specific language?
    • Error handling: Strategy to handle errors.
  • Requirements Traceability: Assign each of the requirements to a subsystem.
  • Support for a Staged Delivery Plan: Describe how the project will adjust to support staged delivery. What is going to be delivered on each stage.

Quality Meter: Ch. 9 SG

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…

Used under CC 2.0 (BY-SA). Published in:

Requirements: Ch. 8 SG

The first “real” ideas of the project are reflected in UI prototypes and user manuals. But before doing that, something essential for the whole project needs to be gathered: The Requirements. How? Doing interviews to users and comparing products (Just remember that the difficult part is not to record what the user wants, but making him understand what he wants). And then? Write them, specify them, analyze, compare, build storyboards and prototypes. After all of that you have your requirements.

Overview of the process

  1. Identify end users that can define the product: They should be interested in the product in a way that you can deposit your complete trust in their criteria.
  2. Interview those end users: Here you will obtain the basic set of requirements.
  3. Build simple interactive UI: Really, as simple as possible. But make different alternatives. In paper storyboards are an easy way to present the requirements in a way everyone can understand.
  4. Show the UI to the end users and receive feedback. Work on the feedback on show it again. Do this until the end user is satisfied.
  5. Develop a style guide: The standards of the product look and feel.
  6. Extend the prototype to include every functionality: Now that you have every requirement defined and how each one must look, you can introduce everything. Still, it’s a throwaway, but lets try to work on a single one.
  7. Treat that prototype as the base line: Because you know what to reach, you can start giving formal estimates to the boss.
  8. Write the end user documentation: What will the user see, the basic “how does it work” and how to interact with it.
  9. Write the non end user documentation: The things that the user doesn’t care about, but someone else might. Like another team that might make an upgrade, and maybe needs to understand how the algorithms work, how the software interacts with the hardware, etc.

And that’s it.

Planning in advance: Ch. 7 SG

Even thought someone might say that its impossible to plan before knowing which are the requirements, but… THAT ISN’T TRUE! There are several thing to do. More specifically, 7 things.

Project Vision

For a team to share a vision and final objectives (Objectives aren’t requirements), the team functioned effectively. This will make improvements in very aspect of the team; from organizational and administrative improvements, such as decision making; to motivation and influence on the team.

The vision must be specific and motivational, but the most important characteristic is that it must be achievable. Finally, everyone must commit to the vision.

Executive Sponsorship

This refers to designate the support that the team or person that has heavy decision impact on the project. This person or team will approve every feature, user interface, release…  And it’s important that if this entity is a team, each member must represent a different interest.
Because no one likes to have the same boss multiple times… Imagine the same reproach by each boss when you get something wrong.

Project Scope Targets

Features, schedule and budget are things that can and should be declared before any real requirements definition. Well… an exact definition of theses 3 things can’t really be done, but  a real tentative target must be defined. A recommended technique to define this sort of things is to define an upper and lower limit for everything, this provides a margin to deal with the uncertainty.

Publicizing Plans and Projects

Big mistake: TO KEEP THE PLANNING SECRET. People need and should know what are they going to face in the future. If the manager doesn’t inform the programmers or the testers, considerations might not be taken to make a plan that can adapt to them. So, because there isn’t a plan that they approve, or at least that they can prepare for, people run out of control. What should always be public? You ask:

  • List of tasks completed
  • Defect statistics
  • Top 10 risk list
  • Percent of schedule used
  • Percent of resources used
  • Status reports given to upper management

Risk Management

Every project must commit to risk management. What does this mean? Well, to provide the all the necessary means to predict, act and resolve risks. What should be provided? An approach, resources and funds, and make the assessment of risk impact the project (I mean, if you know something is coming, let’s act on it). And which are the approaches available? Here, have a list:

  • Risk officer: Spotter of emerging risks. A “pessimistic” person that will try to find every possible problem during development.
  • To 10 risk list: A list, with possible risks and how is currently being fought.
  • Risk tracing: A system that prioritizes risks, if they are open or closed to process, and who is working on them.

Remember that each entry of the top 10 risk list needs to have a reason to be there. Answer why is that a risk and needs management, how is it going to be resolved, what steps are needed to solve it, who will do each step, when can a step be started, how much is going to cost. The answers need to be recorded.

Oh, and there can be a channel, available to everyone to report risks. The managers and officers can’t see everything.

Personnel Strategies

Basic knowledge to staff buildup: Senior staff at the requirements stage, add more staff to the development stage. And just because you need staff, you shouldn’t hire available people, you need to hire good and skilled people, even if that means to wait a little bit.

The team roles (For you to remember) are:

  • Project manager
  • Product manager
  • Architect
  • UI designer
  • End-user liaison (interact with users)
  • Developers
  • QA/Testers
  • Tool smith (develop utilities for the development)
  • Build coordinator (running daily builds)
  • Risk officer
  • End-user documentation specialist
  • Optional: Tiger teams (2 people temporary teams to solve problems fast)

Oh, and a last thing

Time accounting

Just… keep track on how is the personnel spending their time. OK? Good. This will help when making estimates, and presenting those estimates to the upper management.

And that’s it…

It’s a lot to take in. But when you do all of this, you have finally a SOFTWARE DEVELOPMENT PLAN.





Let’s change it all: Ch 6 SG

In life, you should control the changes made, don’t let life control them. In an affective project, changes are controlled by it, an ineffective one lets changes control it. That it’s why change control is created, to let changes be made, while ensuring that their impact is truly understood.

The procedure to approve changes is rather simple.

  • If the changes are made during the initial development (Requirements definition, architecture construction, etc.), no further procedure is needed. Changes are made freely
    At the end of the initial development, a technical review is made, to approve the work is done.
    Finally, the initial development is presented to the change board, which approves the content of the phase. It ensures all parties are satisfied and considered.
  • Version control is implemented. Is a system that stores changes made (mainly to the source code). It archives all the versions of the code.
  • Systematical Change Proposals are done now. Every change is proposed to a board. The proposal contains the changes to be made and the impact (In cost and benefits). Then, the board notifies the parties affected by the changes, which give their viewpoint. At the end, the final decision of the approval is made by the board. Which notifies to all concerned parties of the resolution

The main benefit of implementing change control, is that is will always do what is meant to be done. To protect the project from unnecessary changes.

The main problem is to incorrectly consider a change (Either by approving it, or not). In the book, a number of question the board should ask is listed. This, to make the decisión with more certainty,

To be successful at staging: Ch 5 SG

The software projects are always divided into stages. The first divisions we can make are the intellectuals. There are 3 intellectual stages, which exist at the same time, because there is no successful project which doesn’t let all the phases to coexist:

  1. Discovery: State the real user requirements. Convert uncertainty into certainty through interviews and building prototypes.
  2. Invention: Creation of architecture and design for the project, and classes and functions. Again, the objective is to gain certainty, even more than in the discovery phase.
  3. Implementation: Convert the potential of the certainty created in the previous phases, and map it to a real project.

And continuing with the division of a project into stages, behold, the Stage Delivery Plan. A plan to develop software, where after 3 phases of requirements definition, n deliveries are made (Once per stage). Each stage delivery is release that is given to the client, to approve or to make changes, so the next delivery approaches to what the client desires. The main benefits of the Staged Delivery Plan are:

  • Functionality (At least, the most important) is implemented very early. So the client can start to see a “product” since the start.
  • Because at the end of each stage there is a delivery, risks of integration and user requirements are reduced. At the final delivery, the integration of all functionality shouldn’t be a problem, and the requirements are mostly all accounted for.
  • The problems are detected early. If since the first stages, the project is in trouble, there is a problem. You don’t need to wait until the project is almost done to find out.
  • Developers don’t lose time making status and progress reports, because there is no accurate report than the working software.
  • Making almost releasable software at the end of each stage, gives more options to choose at the end.
  • There is no problem making large estimations for the whole project, because smaller estimates are done instead, for each stage.

The only considerable downside is that Staged Delivery Plan can cost more, but not that much. Usually people tend to think there are a lot of extra costs, but the truth is that most of those expenses would happen on any method. The only truly extra cost is the expense of releasing software at each stage.

It is expected that all the steps at each stage tend to overlap, and coexist at the same time. It is accepted, but one should try to do at least 80% of the work of the activity, before starting another one. Mainly because the errors can be contained to the step where they were created.

During the first phase, of this plan, requirements and the architecture are constructed. Here, the effort is lower than the implementation phase, where mini cycles of design, construction and testing are made (One per stage). After “50%” off the project development, the effort stays flat. This happens because the last part isn’t just testing, or transitioning to delivery (Like in linear models), but still, the mini cycles are still done at each stage. It’s important to remember that the percentage of schedule assigned to an activity, isn’t equal to the percentage of effort.

Regarding how much code is written, in Stage Delivery Plan, it grows in a S shape. Little code at the start, then increments in the middle stages, and flattens on the final ones, as less creation of code is done and more fixing is made.

Finally, there should be, as always, milestones and deliveries stated formally, so there can be an easy way to track progress. The book’s page has all the details.



Surviving: Chapter 3 & 4 of the Survival Guide

First: Chapter 3

Well… Chapter three named “Survival concepts”talked all about the software processes. What are software processes, what aren’t and its benefits and costs compared to a project without a good software process. First, lets start with giving a basic definition of a process. A software process is a developed system that by creating a detailed and systematic plan to work, provides an assurance at the end of the project.
The book explains how there is a community that views this way of work as a very costly and inefficient system, when the truth is that having a process provides to the team a better way to find, report, and correct mistakes, in a way that might not change the budget or schedule in a meaningful way.
It is normal, that project that don’t implement a process find out that they are expending a lot of valuable time thrashing (Correcting defects, rather than implementing new stuff), but at this moment, any process implementation won’t be useful, and the project might be canceled.
That is why, at the long term, investing in processes is beneficial, even if at the beginning it might seem that the time dedicated to process designing is consuming valuable time. At the end, the team is working fast, productively and correcting errors immediately, with no cost at large.
Finally, the book also encourages the use of processes because studies have found that they increment the creativity and morale, because a programmer feels best if they feel productive.
This chapter also talked about two main parts of the development: Upstream (Creating the requirements, architecture and development) and downstream (Construction and testing). It focuses on how it is very important to contain the detection and correction of errors in the phase they are created. So that the cost to fix the defect don’t escalate as the project.

And chapter 4:

This chapter talks about two main concepts of the project skills. To plan the project so the project is visible an support the team, and to address the project’s risks by involving the users and maintaining the focus to a minimal feature set.
Lets talk about planning. Well… planning is the capacity of a project to accept small errors (planned) by getting rid of big and costly mistakes. Some ways of planning are: Creating a development plan, to map the course of the project; creating estimates, so the budget, staff and schedule are set adequately; a quality assurance, plan to make several tests and reviews; staging checkpoints and order of deliverables.One big concept of planning is the checkpoint review, where the manager request funds for a “Exploratory Phase” (Where at most 20% of the project is done), and after a meeting where the checkpoint review is shown, a second and final fund is requested. This meeting is made with the objective of showing to the owners prototypes, quality plans, development plans, user manual, style guides, goals and estimates.
Now lets talk about risk management, the second main concept of the chapter. The main risk in every project are: fail to make a plan, fail to follow the plan, and fail to change the plan according to the project. And the main methods to deal with these risks are:

  • Control: To control the project (Not the people). Selecting a software cycle, making coding standards and making a plan.
  • Visibility: To determine the true status of the project. Planning the checkpoint review, compare performance, hold milestones and revise estimates.
  • Peopleware: To maintain the team on board with the development. Align the interests of the developer with the assigned work, show appreciation, provide a good atmosphere for work, and provide privacy to work.
  • User involvement: To maintain a constant involvement of the final user, to provide a result they will love. Ask what they want, show what you have, ask if they like it.
  • Product minimalism: To make a project as simple as possible. Avoid complications.
  • Shipping: To have a clear focus on making the software until the shipping.