Perfection Never Ends... KISS brings us closer

Last night I was chatting with a friend of mine who is working on the launch of a new project. I asked, "How far are you from launching?" His unexpected reply was "We will miss this year's launch and do it next year, I want to make sure everything is complete and people get to say wow"

The question we need to consider "Is it better to launch today when there is need, but have a modest service offering?, or to spend another year perfecting the service offering and miss the boat on this year's demand?"

KISS (Keep it Simple & Short) brings us closer to deployment and reality.. apply agility... get something working out the door, serve the need, use the opportunity to make further improvements in later releases... perfection never ends.

The Assertive Systems Engineer

So you are on a project to help the team develop a successful system. You notice things that don't make sense, or are not they way they should be. You raise your concern, "Hey, team we need a process to automate testing". Everyone looks at you as if you are some wacko, and then moves on with their business. Two weeks later and after 4 more team meetings you raise the concern again, and again. Finally one team member says "We always did testing this way, and we don't have the money or time to develop the automation, so don't keep repeating this".

What do you do? Shut up? Go with the flow? or be stubborn, resist to work in a chaotic environment? Actually the reaction should be neither. Smart systems engineers need to be adaptive, flexible and understanding of the business constraints and technical limitations. They also need to be assertive and counselors of best practices and approaches.

Document your technical opinion, the problem as you see it, the proposed solution, the rationale for the solution and consequences of not addressing the problem. Be assertive about your technical opinion, and also flexible to adjust the solution as needed to meet the laws of physics and constraints the team must abide with.

Remember systems engineering is all about engineering a system with the most optimum means, in accordance to sound decisions and rationale

ISO IEC 15288 / INCOSE SEBoK v3.0 Life Cycle Stages

Life-cycle definition is an important aspect of any system. By defining a life-cycle we can establish a framework for meeting stakeholder needs in an orderly fashion.

This order comes from the presence of stages in the life-cycle, and decision-making at the end of each stage to determine the readiness to move on. Stakeholders are concerned with the business case, funding and capability of a system at each stage.

INCOSE SEBoK ver 3.0 defines seven life-cycle phases. Each of these phases are listed below. Phases 2 - 7 are the same as the six phases defined in ISO 15288.

Pre-concept Phase:
Inputs: New ideas
Process: Creative systems engineering and requirements definition
Outputs: Identified enabling technologies

Concept Phase:
Inputs: Studies, experiments, models
Process: Requirements identification (if not done in pre-concept), indepth feasibility studies, prototypes, risk evaluation, early validation
Outputs: System requirements, feasible design solution

Development Phase:
Input: System requirements
Process: Development, integration, verification and validation
Outputs: Developed, verified and validated system

Production Phase:
Input: Tested system
Process: Modifications, re-verification, cost reduction
Output: Manufactured product

Utilization Stage:
Input: Performance reports, change requests, operational work orders
Process: Operations, change management
Output: Operational product, upgrades

Support Stage:
Inputs: Modifications, change requests
Process: Change control, maintenance, cost reduction, support
Output: Sustainable service and supported mission

Retirement Stage:
Inputs: change requests, competing systems
Process: System migration, removal, disposal
Output: Disposed system

System Sustainability: No Longer an Option

System developers rarely analyze or even worry about the long term sustainability of a system. The main focus is usually on today's and the near future's needs. The client says "I need to consolidate these two billing systems by next January".

Everyone on the projects starts to focus on this requirement. It becomes an architectural driving requirement, functions and operations of the new system will be based on this requirement and dependencies will start appearing, which if traced will be found to have largely come from that main requirement - consolidate by January.

No one gives thoughts to what happens after January. How and what will the new consolidated system look like and need to do to remain sustainable and not turn obsolete in a year or two and require another consolidation project with something else at the time.

Last year I was fortunate to do some research work under the supervision of Dr. Peter Sandborn of the University of Maryland. We looked into this topic - how to create sustainable software - and have come up with a model that might help extend the life-cycle of software systems.

With news that countries like Oman will run out of oil in 40 years popping up, sustainability in all aspects is no longer an option, but a requirement.

Agile In a Nutshell

Agile development is all about short iterations. Using what is known as a scrum process requirements are iterated and turned into use cases which are tested and so on.

The goal in agile is to test early, to identify early defects; and use continuous stakeholder feedback to deliver high-quality consumable code through use cases, and a series of short time-boxed iterations.

A New Buzzword in Town - Cloud Computing

So first it was Application Service Providers (ASPs) then Utility Computing and now comes Cloud Computing... It seems that every couple of years the industry needs a new set of buzzwords to keep the PR machine running.

Well there might be some slight differences between utility and cloud computing, but I would not really identify them as differences, I would just note them as the same with a slightly different scope. Instead of renting computing resources - utility computing - cloud computing rents applications and IT services.

So what is this cloud computing after all? Reading through various articles it seems to be nothing more than an application service provider hosting enterprise IT services for its clients. Its just technology improved from what was available in the mid-nineties, and vendor are looking for a way to get over the unsuccessful connotation of ASPs by relabeling the concept into cloud computing.

Some links on the topic from various trade rags for those interested:

http://gigaom.com/2008/02/28/how-cloud-utility-computing-are-different/
http://www.businessweek.com/magazine/content/07_52/b4064048925836.htm
http://www.gartner.com/it/products/research/cloud_computing/cloud_computing.jsp
http://www.technologyreview.com/Infotech/19397/?a=f
http://www.businessweek.com/technology/content/nov2007/tc20071116_379585.htm

What is RUP?

RUP short for Rational Unified Process is a process for software engineering. Originally develped by Rational Software, Inc. - now acquired by IBM.

RUP focuses on the following best practices:

1. Four major phases in a software development cycle (inception, elaboration, construction and transition)

2. Within each phase RUP allows for iteration and incremental development. this supports refined requirements, risk reduction and results oriented management.

3. Disciplines which group activities by nature. There are nine disciplines defined (business modeling, requirements, analysis and design, implementation, test, deployment, configuration management, project management and environment). These disciplines spread across the four phases of a software project.

4. Manage requirements using tools that support traceability, prioritization, validation and quality management.

5. Develop component-based architectures, where components are primary concepts for design. They are self-contained modules with clear interfaces that can provide a well-defined function.

6. Visually model software using languages such as UML, or SysML. Numerous tools on the market support these languages such as IBM's Rational Suite, IBM's Telelogic DOORS, iRise, Visual Use Case, Visual Paradigm and many others.

7. Verify software quality, especially in the areas of functional, performance and reliability compliance.

8. Control changes to software through a traceable and end-to-end approach.