CASoft Blog     CASoft Blog

         Communication Aspects in Software Engineering

31 March 2009

Unambiguous and understandable UML

Filed under: UML — Tags: , — admin @ 17:59

The original and fundamental phylosophy of UML is to be unambiguous and understable by most, without requiring an in-depth knowledge of a complex semantique.
This phylosophy had for objective to facilitate the communication in between the different stakeholders of Software Engineering projects and to federate the notations to promote common understanding and shared vision.
It is obvious to me that the original phylosophy is getting diluted progressively amongst the different additions that have been made to the standard over the years.

I do find myself very much in tune with this presentation umlbooch.ppt made by Grady Booch, and which promotes the need to address the increasing complexity of the systems to develop.
My personal vision is to try to keep UML unambiguous and understandable by most, in order to get as many people on board as possible and to address the problematic of the increasing complexity.

29 March 2009

Project Take Over

Filed under: Project Management — Tags: — admin @ 11:43

Taking over a new project, a new role or a new job… Restarting.

The objectives a project take over are (in this order):

  1. Ensure long-term success of the Project Manager
  2. Ensure success of the project

In order to take over a project successfully, the following steps shall be undertaken:

  • Establish authority and leadership with confidence
  • Establish relationships with every individual – learn about each one of them, what are their skills, experience, what type of management get the most of them, what are their motivators, personality and character.
  • Assess Project – take ownership of the project plan and the schedule, and assume resposibility from there on – if plan does seem achievable, perform the foolwing actions in this order: 1. try to reduce scope, 2. try technical simplifications, 3. justify and ask for more resources, and 4. propose to replan the project.
  • Assess and document Risks and Issues – perform a complete risk analysis, in order to confirm that the project objectives are achievable
  • Document Vision and Action Plan – based on well know methodology
  • Establish Project Management Master Mind

Spend a fair amount of your time improving your leadership ability:

  • Provide navigation
  • Establish solid ground
  • Influence
  • Process knowledge
  • Get momentum
  • Focus on victory
  • Establish inner cycle
  • Maintain priorities

23 March 2009

Project Management Master-Mind

Filed under: Project Management — Tags: , — admin @ 07:20

The Master Mind principle consists in a group of capable and as much as possible complementary people, who cooperate in the spirit of harmony, in order to gain power.
Plans are useless without the power to translate them into action…

The idea behind a Project Management Master Mind is the organisation of a group of professionals dedicated to manage projects, a bit like an informal Project management Office.

A Project Management Master Mind aims at achieving the following objectives:

  • Managing projects to successful completion
  • Sharing knowledge and information – power is ‘organised knowledge’
  • Sharing brainstorming power, decision power and responsibilities
  • Sharing a common vision
  • Providing coherent answers and solutions to project stakeholders – maximising credibility
  • Ability to keep functioning at near full strength, when one member is temporarily missing

The best source to create your Master Mind is within your team.
In your Project Management Master Mind it is recommended to include people with different backgrounds, experience and responsibilities, as for example:

  • Business – such as Business Analyst
  • Technical – Such as Technical Leader / Architect
  • Resource Management – Such as Manager

For the organisation of your Master Mind, you may also want to consider the following:

  • Master Mind members should be located close to each other as much as possible, in order to facilitate the communication as per the points below
  • They should keep each other informed first and systematically – so each member of the Master Mind is credible when standing on his own
  • They should meet often, with regular formal and informal meetings, such as when higher-management or customer is seeking information / answers or decisions need to be made
  • They should seek each other’s agreement for every significant decision – decision that are decided by a group in harmony are more sound and much more difficult to shoot down
  • They should assume full responsibility – The Project management Team is responsible for everything that is going on within the project!
  • They should support and be loyal to each other – discuss any issue or sensitive subject with the person face to face and nobody else, and give empathy

22 March 2009

Maintaining a Shared Vision

Filed under: Project Management — Tags: — admin @ 21:08

Creating a shared vision consists of establishing and actively maintaining agreement and commitment about what is to be done and how it will be done.
A shared vision is a result of an ongoing dialog among all the people working on the project.

The objectives of a shared vision are:
-Facilitating people working together.
-Helping people to attain unity of purpose.
-Creating a common understanding.

Attention: unrealistic proclamations can transform the shared vision into a source of frustration

Define the focus, for example:

The main focus is the success of the project and the customer satisfaction, all along the project life.

Define the Project Structure:

The project structure describes the caps (or roles) and relationships (or interfaces) for a software development project:
-Several caps may be put on one head.
-One cap may be worn by several heads.
-The represented relationships would describe the official communication stream (or process).

Obtain Assignment Acceptance:

People and activities assignments result from an agreement between Project Manager and Assigned person.
When no solution can be found, or for important responsibilities, the acceptance of higher-level management and/or other stakeholders will be required.

Other Areas to be considered:

  • Common Values
  • Team Empowerment and Independence
  • Decision Making
  • Conflict Resolution
  • Proposed Products and Tools
  • Constraints
  • Expectations

16 March 2009

Processes & Methodologies

Filed under: Methodology — Tags: — admin @ 21:26

What do you know about Processes?

Dictionary definition: Processes are operational systems for supplying or realising products. Processes may include separate stages with clearly defined end-points, which represent significant new or enhanced steps towards a final result.
Processes are usually integrated within a “more comprehensive” Methodology.
Methodologies could be and must be tailored, according to company’s and project’s objectives.

Does it ensure quality?
Yes… It helps ensuring products meet quality requirements, providing best practices to implement and standards to meet.

Does it make everybody’s life easier?
Yes… It helps reducing stress and frustrations, providing a frame for organisation, so people know what to expect and what is expected from them.

Does it save money?
Yes… It helps saving money, ensuring that the cost of adding new features and maintaining the product does not increase exponentially with time, which often force companies to redevelop their products from scratch after a while…

Conventional methodologies

The Capacity Maturity Model Integration (CMMI)
• developed by the US Department of Defence (DoD) in order to manage uncontrollable costs
• currently undertaken by Boeing or the NASA for example
• defines 24 different processes

The Rational Unified Process (RUP)
• developed by Rational, now merged with IBM
• very trendy in Europe
• defines 9 different processes

IT Infrastructure Library (ITIL)
• global methodology, not just software development
• developed by the UK Office of Government Commerce (OGC) in order to reduce costs
• defines a lot of different processes, packaged within 7 CDs

Project IN Controlled Environment (PRINCE2)
• project management method
• developed by the OGC
• defines 9 different processes

Agile Programming methodologies

eXtreme Programming (XP)
• developed by an individual, Kent Beck
• in use within Mercedes-Benz and Ford for example
• defines 7 practices (or processes)

Feature Driven Development (FDD)
• an Australian methodology
• trademark of the company Nebulon Pty Ltd
• in use within ‘Yes’ OPTUS telecommunication in Brisbane
• defines 5 processes

What are the main differences between Conventional and Agile Programming Methodologies?

Conventional methodologies
• requirements are unearthed at the start / elaboration phase
• models hold the design
• documentation is important

Agile programming methodologies
• requirements are unearthed again for each delivery
• code holds the design
• persons are important

What is it that all the methodologies are trying to eliminate?

Fire-fighting mode:
When some individuals, acting as heroes, are jumping from problem to problem, constantly saving the project from burning down completely.

Panic mode:
When the defined rules are not followed anymore, left aside, in order to rush forward (or to “fly by the seat of one’s pants”).

Conventional or Agile?

Up to recently, Conventional methods were considered the only option for large projects, while Agile ones were considered fast and practical for smaller projects.
Nowadays, Conventional methodologies claim to be more agile, and Agile ones claim to be able to manage larger projects…
Whatever the method, it must be tailored to meet project’s and company’s needs…

Are tools needed to implement a methodology?

NO… Not necessarily.
Tools can help, in certain situations, to increase productivity, however Processes are not about tools…
They are about people!

11 March 2009

Hollywood Secrets of Project Management Success

Filed under: Book Review — Tags: — admin @ 21:29

Very good and entertaining book written by James R. Persse on Project Management best practices.

Get it from Fishpond.com.au:

18 Lessons are listed and thoughly documented, using examples from reknown Hollywood projects.
This book will convince you of the necessity to have in place a Project Management System and to follow it.

It will also encourage you to learn more on subjects such as Portfolio Management.

9 March 2009

TFS – Federating Software Engineering

Filed under: Agile,Project Management — Tags: , — admin @ 19:58

Years ago in the manufacturing industry, ERP solutions federated all the information in one place, in order to optimise processes and costs.

The coming generation of tools for Software Engineering Project Management are on their way to doing just that. There is still a long way to go, but the trend is there.

Team Foundation Server (TFS) is a Microsoft offering for source control, data collection, reporting, and project tracking, and is intended for collaborative software development projects.

It is one of the best tools out there today for managing and federating the information of Software Engineering projects and for Project Management.

When creating a project within TFS, there are 2 project templates to choose from:
–MSF Agile provides Work items and Processes that support Agile programming approach
–MSF CMMI is based on MSF Agile, and it stretches the Agile approach to comply with CMMI Maturity level 3. It is 150% larger than MSF Agile, for example MSF Agile has 25 work product artifacts, MSF CMMI has 59.

In TFS, everything in managed as a Work Item. The Work Items available, when using MSF Agile, are Scenario, Task, Bug, Risk and Quality of Service Requirement.
It is however possible and easy to add other work items, such as Test Case and Requirement.

In their presentations about TFS, Microsoft recommend the following links organisation:
Queries can be created to research Work Items.

Reports can be developed and run to provide all sorts of information and calculated measures about Work Items and projects, such as Bugs rate and Remaining work for example.

SharePoint Web Access is the Web Interface that provides access to all the TFS functionality through a web-based application. Timesheets can be entered using SharePoint Web Access.

Customers can be given access to the information about their projects through SharePoint Web Access, and can monitor their progress. This can decrease significantly the need for reporting.

The TFS solution also provides a Portal as a single point of storage for documents, which can be organised by project for example. It also has a wiki-like feature.

It possible to export the information in TFS into EXCEL spreadsheets, which can be updated / refreshed at the click of a button. This information can be instanciated in tables or in pivot-tables. It is also possible to modify the information in the spreadsheet and upload it back in TFS. Some teams choose to upload their requirements this way.

They are also add-ins that allow integration with third party products, such as Caliber and Test Director.

The Power Tools, which must be downloaded and installed separately, allow to create and edit processes and work items, and much more.

The 2010 edition of TFS will provide the following functionality:

  • Architecture Explorer provide a graphical visualisation of the code
  • 7 UML diagrams will be supported (the Microsoft Diagrams won’t be supported, though Microsoft is working on their Oslo model-driven development strategy)
  • Tools for test cases management
  • Test Impact View – run tests impacted by a code change only
  • Enhanced Vision Control – gated check-in, branch visualisation and build worklfow

What do you like or dislike about TFS? leave comments below.

Initiation to UML

Filed under: UML — Tags: , — admin @ 16:38

I organise several Initiation to UML courses, which include hands-on exercises, such as:

  • Requirements Analysis using UML
  • Software Architecture Analysis using UML
  • Software Design Analysis using UML

These 3 courses are usually intended for Software Developers, Architects and System Analysts, and form one entity that provides a coherent overview of UML and a methodology based on RUP.

A complete UML course will normally take 5 days, but I like to taylor the presentations and exercises to the client’s needs.

When people start learning UML, they want to know and usually focus on the syntax. I believe the philosophy and approach are far more important, and the syntax can readily be found on the Internet or in books.

Believing in UML and its capacity to improve communication, robutness and predictability in the Software Engineering industry, I am always keen to promote it.

I also provide coaching and mentoring.

I would be delighted to have a brainstorming session or chit-chat with you on the subject any time. Contact me at jjacquet@writeup.com.au.

Older Posts »

Powered by WordPress and Writeup.com.au